From owner-ccamp@ops.ietf.org Mon Oct 03 01:57:36 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMJKS-00036X-El for ccamp-archive@megatron.ietf.org; Mon, 03 Oct 2005 01:57:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA20677 for ; Mon, 3 Oct 2005 01:57:35 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EMJSs-0003vo-8L for ccamp-archive@ietf.org; Mon, 03 Oct 2005 02:06:18 -0400 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EMJ9K-000N3y-LD for ccamp-data@psg.com; Mon, 03 Oct 2005 05:46:06 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [80.168.70.143] (helo=relay3.mail.uk.clara.net) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EMJ9J-000N3m-OZ for ccamp@ops.ietf.org; Mon, 03 Oct 2005 05:46:05 +0000 Received: from du-069-0107.access.clara.net ([217.158.132.107] helo=Puppy) by relay3.mail.uk.clara.net with smtp (Exim 4.46) id 1ELgWG-000E3h-FM for ccamp@ops.ietf.org; Sat, 01 Oct 2005 13:31:13 +0100 Message-ID: <000501c5c684$68d68880$6b849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Reminder: ASON Routing evaluation Last Call Date: Sat, 1 Oct 2005 11:56:36 +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 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Content-Transfer-Encoding: 7bit Just a reminder that this WG last call ends on 2nd October. I recall that in Paris there were a couple of comments that "few minor editorial changes" were needed. If you don't comment during the last call, could be that you have changed your mind. Thanks, Adrian From owner-ccamp@ops.ietf.org Mon Oct 03 02:11:12 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMJXa-0000fw-BS for ccamp-archive@megatron.ietf.org; Mon, 03 Oct 2005 02:11:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA01845 for ; Mon, 3 Oct 2005 02:11:09 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EMJfy-0004EB-GH for ccamp-archive@ietf.org; Mon, 03 Oct 2005 02:19:52 -0400 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EMJQO-000OiH-Ol for ccamp-data@psg.com; Mon, 03 Oct 2005 06:03:44 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [80.168.70.143] (helo=relay3.mail.uk.clara.net) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EMJQO-000Oi0-1w for ccamp@ops.ietf.org; Mon, 03 Oct 2005 06:03:44 +0000 Received: from du-069-0417.access.clara.net ([217.158.145.163] helo=Puppy) by relay3.mail.uk.clara.net with smtp (Exim 4.46) id 1ELKU2-000EMa-Ft; Fri, 30 Sep 2005 13:59:27 +0100 Message-ID: <074c01c5c5bf$34289f30$be849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Wijnen, Bert \(Bert\)" , , , Cc: References: <7D5D48D2CAA3D84C813F5B154F43B155082FB10F@nl0006exch001u.nl.lucent.com> Subject: Re: MIB Dr. review of draft-ietf-ccamp-gmpls-te-mib-09.txt Date: Fri, 30 Sep 2005 14:01:32 +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 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit Bert, > I have explained repeatedly (and it has been in the MIB review guidelines > (now RFC4181) for a long time), the 32 char limit is relaxed. > > And in general, consistency is MUCH more important (I think) than > limiting to 32 chars. Yes, yes. But you are replying to an old message from before you made that point. As soon as you made the point I acquiesced and have made many changes in the new versions we are working on. Thanks, Adrian From info@mail.kjgjd.com Mon Oct 03 11:13:12 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMS07-0003Yj-Kw for ccamp-archive@megatron.ietf.org; Mon, 03 Oct 2005 11:13:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11518 for ; Mon, 3 Oct 2005 11:13:08 -0400 (EDT) Received: from [58.180.198.206] (helo=mail.kjgjd.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EMS8a-0002US-7g for ccamp-archive@ietf.org; Mon, 03 Oct 2005 11:21:56 -0400 Received: (qmail 23460 invoked by uid 509); 3 Oct 2005 22:47:20 +0900 Date: 3 Oct 2005 22:47:20 +0900 Message-ID: <20051003134720.23459.qmail@mail.kjgjd.com> From: info@kjgjd.com To: ccamp-archive@ietf.org Subject: $B$R$H$_!J!|!0(Bo$B!0!|!K$G$9(B X-Spam-Score: 2.9 (++) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c $B$"$J$?$KL$JV;v$ND>$N$*M6$$MzNr$,;D$C$F$$$^$9!#(B $B$I$&$5$l$^$9$+!)(B $B!TD>(BID 101212$B!!$R$H$_!U$5$s"M(B $B!X$O$8$a$^$7$F"v6a$$$N$G%S%C%/%j$7$^$7$?!*(B $BNI$+$C$?$iOC$7$^$;$s$+!)JV;vBT$C$F$^$9%M!y!Y(B $B"(:#=5EZMKF|$r2a$.$^$9$HMzNr:o=|$5$l$^$9!#(B $B"(EEOC$O%a!<%kAw?.8e2DG=(B($BHV9fG'>ZI,?\(B)$B!#(B http://www.jumpb2.net/?korekore $B$R$H$_MM$N4uK>$h$j$"$J$?$NEPO?A4$FL5NA$G$9!#(B $BMzNr:o=|(B (Refusal Adress) iranai@jumpb2.net From owner-ccamp@ops.ietf.org Mon Oct 03 15:59:11 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMWSt-00041W-FW for ccamp-archive@megatron.ietf.org; Mon, 03 Oct 2005 15:59:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29009 for ; Mon, 3 Oct 2005 15:59:09 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EMWbP-0002dK-TF for ccamp-archive@ietf.org; Mon, 03 Oct 2005 16:08:01 -0400 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EMWK6-000LiT-Kq for ccamp-data@psg.com; Mon, 03 Oct 2005 19:50:06 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=3.1.0 Received: from [132.151.6.50] (helo=newodin.ietf.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1EMWK6-000Lhk-0G for ccamp@ops.ietf.org; Mon, 03 Oct 2005 19:50:06 +0000 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EMWK2-0006KW-51; Mon, 03 Oct 2005 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-inter-domain-rsvp-te-02.txt Message-Id: Date: Mon, 03 Oct 2005 15:50:02 -0400 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.4 (/) 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 : Inter domain GMPLS Traffic Engineering - RSVP-TE extensions Author(s) : A. Ayyangar, J. Vasseur Filename : draft-ietf-ccamp-inter-domain-rsvp-te-02.txt Pages : 24 Date : 2005-10-3 This document describes extensions to Generalized Multi-Protocol Label Switching (GMPLS) Resource ReserVation Protocol - Traffic Engineering (RSVP-TE) signaling required to support mechanisms for the establishment and maintenance of GMPLS Traffic Engineering (TE) Label Switched Paths (LSPs), both packet and non-packet, that traverse multiple domains. For the purpose of this document, a domain is considered to be any collection of network elements within a common realm of address space or path computation responsibility. Examples of such domains include Autonomous Systems, IGP areas and GMPLS overlay networks. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-inter-domain-rsvp-te-02.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-inter-domain-rsvp-te-02.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-inter-domain-rsvp-te-02.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: <2005-10-3121247.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-inter-domain-rsvp-te-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-inter-domain-rsvp-te-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-10-3121247.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ccamp@ops.ietf.org Mon Oct 03 15:59:20 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMWT2-000421-FL for ccamp-archive@megatron.ietf.org; Mon, 03 Oct 2005 15:59:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29022 for ; Mon, 3 Oct 2005 15:59:18 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EMWbZ-0002dk-T7 for ccamp-archive@ietf.org; Mon, 03 Oct 2005 16:08:10 -0400 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EMWK4-000LhS-7F for ccamp-data@psg.com; Mon, 03 Oct 2005 19:50:04 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=3.1.0 Received: from [132.151.6.50] (helo=newodin.ietf.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1EMWK3-000Lgc-DP for ccamp@ops.ietf.org; Mon, 03 Oct 2005 19:50:03 +0000 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EMWK2-0006Kb-5z; Mon, 03 Oct 2005 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-rsvp-restart-ext-04.txt Message-Id: Date: Mon, 03 Oct 2005 15:50:02 -0400 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.4 (/) 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 : Extensions to GMPLS RSVP Graceful Restart Author(s) : A. Satyanarayana, et al. Filename : draft-ietf-ccamp-rsvp-restart-ext-04.txt Pages : 24 Date : 2005-10-3 This document describes extensions to the RSVP Graceful Restart mechanisms defined in RFC 3473. The extensions enable the recovery of RSVP signaling state based on the Path message last sent by the node being restarted. Previously defined Graceful Restart mechanisms, also called recovery from nodal faults, permit recovery of signaling state from adjacent nodes when the data plane has retained the associated forwarding state across a restart. These mechanisms do not fully support signaling state recovery on ingress nodes or recovery of all RSVP objects. The presented extensions use the RSVP Hello extensions defined in RFC 3209, and extensions for state recovery on nodal faults defined in RFC 3473. With the presented extensions the restarting node can recover all previously transmitted Path state including the Explicit Route Object and the downstream (outgoing) interface identifiers. The extensions can also be used to recover signaling state after the restart of an ingress node. The extensions optionally support the use of Summary Refresh, defined in RFC 2961, to reduce the number of messages exchanged during the Recovery Phase when the restarting node has recovered signaling state locally for one or more LSPs. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rsvp-restart-ext-04.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-rsvp-restart-ext-04.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-rsvp-restart-ext-04.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: <2005-10-3121452.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-rsvp-restart-ext-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-rsvp-restart-ext-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-10-3121452.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ccamp@ops.ietf.org Tue Oct 04 01:46:49 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMfdX-0004eS-F5 for ccamp-archive@megatron.ietf.org; Tue, 04 Oct 2005 01:46:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14751 for ; Tue, 4 Oct 2005 01:46:46 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EMfm3-0006Gf-9g for ccamp-archive@ietf.org; Tue, 04 Oct 2005 01:55:42 -0400 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EMfTP-000Enz-3T for ccamp-data@psg.com; Tue, 04 Oct 2005 05:36:19 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [80.168.70.142] (helo=relay2.mail.uk.clara.net) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EMfTM-000Enj-2M for ccamp@ops.ietf.org; Tue, 04 Oct 2005 05:36:16 +0000 Received: from du-069-0233.access.clara.net ([217.158.132.233] helo=Puppy) by relay2.mail.uk.clara.net with smtp (Exim 4.50) id 1EM0ac-000P3m-8o; Sun, 02 Oct 2005 10:57:07 +0100 Message-ID: <008f01c5c738$0b006b40$6b849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Dimitri Papadimitriou" , "Dimitri Papadimitriou" , "Christian E Hopps" , "Lyndon Ong" , "Jonathan Sadler" , "Dave Ward" , "Stephen Shew" Cc: Subject: Last call comments on draft-ietf-ccamp-gmpls-ason-routing-eval-01.txt Date: Sun, 2 Oct 2005 10:58:29 +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 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 1.2 (+) X-Scan-Signature: 4515df9441674711565101d9d5c4f63f Content-Transfer-Encoding: 7bit Hi, Here are my comments on this I-D. Most of these comments are very minor editorial nits. We need to try to get these resolved at this stage because it will improve the speed at which the IESG can review the I-D and reduce the time in the RFC Editor process. However, there are a few more substantial questions hidden in the middle of what I have written. I suspect that this email will take some while to show up at the CCAMP mailing list because psg (which hosts the CCAMP list) is in dispute with my ISP. Sorry about that. Thanks, Adrian ==== Section 4 The following functionality is expected from GMPLS routing protocol s/protocol/protocols/ Section 4 - Processing of routing information exchanged between adjacent levels of the hierarchy (i.e. Level N+1 and N) including reachability and upon policy decision summarized topology information. s/and upon policy decision summarized/and (upon policy decision) summarized Section 4 - Self-consistent information at the receiving level resulting from any transformation (filter, summarize, etc.) and forwarding of information from one Routing Controller (RC) to RC(s) at different levels when multiple RCs bound to a single RA. s/bound/are bound/ Section 4 As ASON does not restrict the control plane architecture choice used, either a co-located architecture or a physically separated architecture may be used. A collection of links and nodes such as a s/architecture choice used/architecture choice/ s/co-locate/collocate/ Section 5 This section evaluates support of existing IETF routing protocols with respect to the requirements summarized from [ASON-RR] in Section 4. Candidate routing protocols are IGP (OSPF and IS-IS) and BGP. The latter in not addressed in the current version of this document. There will be no future versions of this document (we hope). What should you then say about BGP? Probably that BGP is not considered a candidate protocol because... Section 5.1 - Li is a logical control plane entity that is associated to a single data plane (abstract) node. The Li is identified by the TE Router_ID. The latter is a control plane identifier defined as . RFC 3630: Router_Address (top level) TLV of the Type 1 TE LSA . RFC 3784: Traffic Engineering Router ID TLV (Type 134) s/data plane (abstract) node/physical node/ 1. Use same terminology as defined in previous bullet 2. Why say "abstract" for something that is physical? Section 5.1 This contains multiple references to RFCs. Can you please insert square bracket citations. Section 5.1 - Li is a logical control plane entity that is associated to a single data plane (abstract) node. The Li is identified by the TE Router_ID. The latter is a control plane identifier defined as . RFC 3630: Router_Address (top level) TLV of the Type 1 TE LSA . RFC 3784: Traffic Engineering Router ID TLV (Type 134) Note: this document does not define what the TE Router ID is. This document simply states the use of the TE Router ID to identify the Li. Other documents (the referenced RFC 3630 and RFC 3784) provide the definitions. There appear to be two contradictory paragraphs here. The first says "...defined as...". The second says "...does not define..." Need to tweak the words. Section 5.1 Thus, the routing protocol MUST be able to advertise multiple TE Router IDs. You need to comment on whether this requires a modification to the protocols as currently specified or not. This is, after all, the purpose of this document. Section 5.1 [ASON-REQ], does not enter into the identification of the logical s/ASON-REQ/ASON-RR/ Section 5.2 Under these conditions, GMPLS link state routing protocols provide the capability for RA Identification. Add "without further modification" Section 5.3 We focus on routing information exchange between Ri entities (through routing adjacencies) within single hierarchical level. s/within single/within a single/ Section 5.3 Routing information mapping between levels may require specific guidelines. ...and these are out of scope? Section 5.3 The control plane does not transport Pi information as these are data plane addresses for which the Li/Pi mapping is kept (link) local - see for instance the transport LMP document [LMP-T] where s/information/identifiers/ Section 5.3 (three times) Are "666B.F999.AF10.222C" and "1.1.1.1" intended to be representative of specific address forms. If the latter is an IPv4 address, you should pick one from the range allowed for example IP addresses. Section 5.3 You should conclude with a statement that "OSPF and IS-IS therefore carry sufficient node identification information without further modification." Section 5.3 3) when using OSPF or ISIS as the IGP in support of traffic engineering, RFC 3477 RECOMMENDS that the Li value (referred to the "LSR Router ID") to be set to the TE Router ID value. Please add citation for [RFC3477]. Section 5.3.1 From the list of link attributes and characteristics (detailed in [ASON-RR], the Local Adaptation support information is missing as TE link attribute. GMPLS routing does not currently consider the use of dedicated TE link attribute(s) to describe the cross/inter-layer relationships. All other TE link attributes and characteristics are currently covered (see Table 1.) I think this could be written more clearly. Try... [ASON-RR] provides a list of link attributes and characteristics that need to be advertised by a routing protocol. All TE link attributes and characteristics are currently handled by OSPF and IS-IS (see Table 1) with the exception of Local Adaptation support. GMPLS routing does not currently consider the use of dedicated TE link attribute(s) to describe the cross/inter-layer relationships. Section 5.3.1 However, the representation of bandwidth requires further analysis i.e. GMPLS Routing defines an Interface Switching Capability Descriptor (ISCD) that delivers information about the (maximum/ minimum) bandwidth per priority an LSP can make use of. s/an LSP can make use of/of which an LSP can make use/ Section 5.3.1 The latter also may require definition of additional signal types (from those defined in [RFC 3496]) to represent contiguous concatenation i.e. STS-(3xN)c SPE / VC-4-Nc, N = 4, 16, 64, 256. s/also may/may also/ s/RFC 3496/RFC3946/ !!! Note that 3946 is a signaling I-D. It does not mention routing advertisement. You may need to add some detail here to explain how this RFC is relevant. Section 5.3.1 perspective. However, it introduces some lost of information. This lost of information affects the number of signals that can be used but not the range they cover. On the other hand, if additional technology specific information (such as capabilities) are s/lost/loss/ (twice) s/capabilities) are/capabilities) is/ Section 5.3.1 sub-TLV [GMPLS-OSPF] GMPLS-OSPF is not in the references. Section 5.3.1 Local SNPP link ID Link local part of the TE link identifier sub-TLV [GMPLS-ISIS] GMPLS-ISIS is not in the references. Section 5.3.1 Note: Link Attributes represent layer resource capabilities and their utilization. Undoubtedly true, but missing a little context? Section 5.3.2 Nodes attributes include the "Logical Node ID" (as detailed in Section 5.1) and the reachability information as described in Section 5.3.3. The use of "include" implies there are other node attributes not discussed here. Either discuss them (if they exist) or fix the text by s/include/are/ Section 5.3.3 defined per address family, e.g., IPv4 and IPv6). However, [OSPF- NODE] restricts to advertisement of Host addresses and not prefixes, and therefore requires enhancement (see below). s/restricts to advertisement/is restricted to advertisement/ Section 5.3.3 A similar mechanism does not exist for IS-IS as the Extended IP Reachability TLV [RFC3784] focuses on IP reachable end-points (terminating points), as its name indicates. I assume you mean that "An extension similar to [OSPF-NODE] is not required for IS-IS because the function is already included in the Reachability TLV. However, both the Reachability TLV and [OSPF-TLV] do not support the advertisement of reachability prefixes." Section 5.4. hence no specific capabilities are added to the routing protocol s/are/need to be/ Section 5.5 level hierarchy, and disallow the advertising of routing information s/disallow/disallows/ Section 5.5 downward in the hierarchy. [RFC2966] defines the up/down bit to [RFC2966] is not in the references. Section 5.5 [RFC1195] allows only advertising routing information upward in the RFC 1195 is not in the references. Section 5.5 downward in the hierarchy. [RFC2966] defines the up/down bit to RFC 2966 is not in the references. Section 5.5 OSPFv2 prevents that inter-area routes, which are learned from area 0 are not passed back to area 0. However, GMPLS makes use of Type 10 Rewrite as... OSPFv2 prevents inter-area routes (which are learned from area 0) from being passed back to area 0. However, GMPLS makes use of Type 10 Section 5.5 (area-local scope) LSA to propagate TE information [RFC3630], [GMPLS- s/LSA/LSAs/ Section 5.5 which Type 10 Opaque LSA may carry the information that particular s/LSA/LSAs/ s/particular/a particular piece of/ Section 5.5 back into an higher level RC. s/an/a/ Section 5.6 Link state protocols have been designed to detect topological changes (such as interface failures, link attributes modification). Convergence period is short and involves a minimum of routing information exchange. Do link state protocols detect the changes or propagate them? s/Convergence/The convergence/ s/and involves/and convergence involves/ Section 5.7 behalf multiple Li's creates the following issue as there is no more a 1:1 relationship between the Router_ID and the TE Router_ID but a /more/longer/ Section 5.7 and link remote (unnumbered) ID association may be not unique per s/be not/not be/ Section 5.7 retrieve the [Li;Lj] relationship(s). In brief, as unnumbered links The RFC Ed. prefers that square brackets [] are used only for citations. Can you use {}? Section 6 respectively case 1), 2), 3) and 4). Additional base scenarios (being not combinations or decomposition of entities) may further complete this set in a future revision of this document. Remove this sentence. Section 6 In the below Figure 1: s/In the below Figure 1:/In Figure 1 below: Section 6 Please add captions to the figures. At the moment it is not completely clear that cases 1, 2 and 3 appear in Figure 1, while case 4 appears in Figure 3, and Figure 2 is a special representation of case 1. New Section 7 Please add a new section after Section 6 "Summary of Necessary Additions to OSPF and IS-IS" It is too hard for the reader to extract these from the I-D with complete certainty. Section 8.1 Is [LMP-T] really normative? Is [OSPF-NODE] really normative? The draft will progress better if it is not. [RFC3667] and [RFC3668] don't need to be listed. [RFC3946] is not referenced. Section 8.2 [ASON-RR] is surely normative. From owner-ccamp@ops.ietf.org Tue Oct 04 03:23:42 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMh9K-0007d7-9H for ccamp-archive@megatron.ietf.org; Tue, 04 Oct 2005 03:23:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02123 for ; Tue, 4 Oct 2005 03:23:40 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EMhHx-0008NT-9u for ccamp-archive@ietf.org; Tue, 04 Oct 2005 03:32:38 -0400 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EMh3Y-000ND1-FP for ccamp-data@psg.com; Tue, 04 Oct 2005 07:17:44 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-5.1 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from localhost ([127.0.0.1]) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EMh3R-000NCH-ED; Tue, 04 Oct 2005 07:17:38 +0000 Message-ID: <43422CA4.2050203@psg.com> Date: Tue, 04 Oct 2005 09:17:56 +0200 From: dimitri papadimitriou Reply-To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.11) Gecko/20050728 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Adrian Farrel CC: Dimitri Papadimitriou , Christian E Hopps , Lyndon Ong , Jonathan Sadler , Dave Ward , Stephen Shew , ccamp@ops.ietf.org Subject: Re: Last call comments on draft-ietf-ccamp-gmpls-ason-routing-eval-01.txt References: <008f01c5c738$0b006b40$6b849ed9@Puppy> In-Reply-To: <008f01c5c738$0b006b40$6b849ed9@Puppy> 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: 16a2b98d831858659c646b3dec9ed22b Content-Transfer-Encoding: 7bit hi adrian Adrian Farrel wrote: > Hi, > > Here are my comments on this I-D. Most of these comments are very minor > editorial nits. We need to try to get these resolved at this stage because > it will improve the speed at which the IESG can review the I-D and reduce > the time in the RFC Editor process. thank for commenting here this will help in progressing the document > However, there are a few more > substantial questions hidden in the middle of what I have written. will provide on the list how these comments have been addressed when document will be re-submitted (assuming that the last call is over now) > I suspect that this email will take some while to show up at the CCAMP > mailing list because psg (which hosts the CCAMP list) is in dispute with > my ISP. Sorry about that. > > Thanks, > Adrian > > ==== > > Section 4 > > The following functionality is expected from GMPLS routing protocol > s/protocol/protocols/ > > Section 4 > - Processing of routing information exchanged between adjacent > levels of the hierarchy (i.e. Level N+1 and N) including > reachability and upon policy decision summarized topology > information. > s/and upon policy decision summarized/and (upon policy decision) > summarized > > Section 4 > - Self-consistent information at the receiving level resulting from > any transformation (filter, summarize, etc.) and forwarding of > information from one Routing Controller (RC) to RC(s) at different > levels when multiple RCs bound to a single RA. > s/bound/are bound/ > > Section 4 > As ASON does not restrict the control plane architecture choice used, > either a co-located architecture or a physically separated > architecture may be used. A collection of links and nodes such as a > s/architecture choice used/architecture choice/ > s/co-locate/collocate/ > > Section 5 > This section evaluates support of existing IETF routing protocols > with respect to the requirements summarized from [ASON-RR] in Section > 4. Candidate routing protocols are IGP (OSPF and IS-IS) and BGP. The > latter in not addressed in the current version of this document. > There will be no future versions of this document (we hope). > What should you then say about BGP? > Probably that BGP is not considered a candidate protocol because... > > Section 5.1 > - Li is a logical control plane entity that is associated to a > single data plane (abstract) node. The Li is identified by the > TE Router_ID. The latter is a control plane identifier defined as > . RFC 3630: Router_Address (top level) TLV of the Type 1 TE LSA > . RFC 3784: Traffic Engineering Router ID TLV (Type 134) > s/data plane (abstract) node/physical node/ > 1. Use same terminology as defined in previous bullet > 2. Why say "abstract" for something that is physical? > > Section 5.1 > This contains multiple references to RFCs. Can you please insert square > bracket citations. > > Section 5.1 > - Li is a logical control plane entity that is associated to a > single data plane (abstract) node. The Li is identified by the > TE Router_ID. The latter is a control plane identifier defined as > . RFC 3630: Router_Address (top level) TLV of the Type 1 TE LSA > . RFC 3784: Traffic Engineering Router ID TLV (Type 134) > > Note: this document does not define what the TE Router ID is. This > document simply states the use of the TE Router ID to identify > the Li. Other documents (the referenced RFC 3630 and RFC > 3784) provide the definitions. > There appear to be two contradictory paragraphs here. The first says > "...defined as...". The second says "...does not define..." Need to tweak > the words. > > Section 5.1 > Thus, the routing protocol MUST be able to advertise multiple TE > Router IDs. > You need to comment on whether this requires a modification to the > protocols as currently specified or not. This is, after all, the purpose > of this document. > > Section 5.1 > [ASON-REQ], does not enter into the identification of the logical > s/ASON-REQ/ASON-RR/ > > Section 5.2 > Under these conditions, GMPLS link state routing protocols provide > the capability for RA Identification. > Add "without further modification" > > Section 5.3 > We focus on routing information exchange between Ri entities > (through routing adjacencies) within single hierarchical level. > s/within single/within a single/ > > Section 5.3 > Routing information mapping between levels may require specific > guidelines. > ...and these are out of scope? > > Section 5.3 > The control plane does not transport Pi information as these are > data plane addresses for which the Li/Pi mapping is kept (link) > local - see for instance the transport LMP document [LMP-T] where > s/information/identifiers/ > > Section 5.3 (three times) > Are "666B.F999.AF10.222C" and "1.1.1.1" intended to be representative of > specific address forms. If the latter is an IPv4 address, you should pick > one from the range allowed for example IP addresses. > > Section 5.3 > You should conclude with a statement that "OSPF and IS-IS therefore carry > sufficient node identification information without further modification." > > Section 5.3 > 3) when using OSPF or ISIS as the IGP in support of traffic > engineering, RFC 3477 RECOMMENDS that the Li value (referred to the > "LSR Router ID") to be set to the TE Router ID value. > Please add citation for [RFC3477]. > > Section 5.3.1 > From the list of link attributes and characteristics (detailed in > [ASON-RR], the Local Adaptation support information is missing as TE > link attribute. GMPLS routing does not currently consider the use of > dedicated TE link attribute(s) to describe the cross/inter-layer > relationships. All other TE link attributes and characteristics are > currently covered (see Table 1.) > I think this could be written more clearly. Try... > [ASON-RR] provides a list of link attributes and characteristics > that need to be advertised by a routing protocol. All TE link > attributes and characteristics are currently handled by OSPF and > IS-IS (see Table 1) with the exception of Local Adaptation support. > GMPLS routing does not currently consider the use of dedicated TE > link attribute(s) to describe the cross/inter-layer relationships. > > Section 5.3.1 > However, the representation of bandwidth requires further analysis > i.e. GMPLS Routing defines an Interface Switching Capability > Descriptor (ISCD) that delivers information about the (maximum/ > minimum) bandwidth per priority an LSP can make use of. > s/an LSP can make use of/of which an LSP can make use/ > > Section 5.3.1 > The latter > also may require definition of additional signal types (from those > defined in [RFC 3496]) to represent contiguous concatenation i.e. > STS-(3xN)c SPE / VC-4-Nc, N = 4, 16, 64, 256. > s/also may/may also/ > s/RFC 3496/RFC3946/ !!! > Note that 3946 is a signaling I-D. It does not mention routing > advertisement. You may need to add some detail here to explain how this > RFC is relevant. > > Section 5.3.1 > perspective. However, it introduces some lost of information. This > lost of information affects the number of signals that can be used > but not the range they cover. On the other hand, if additional > technology specific information (such as capabilities) are > s/lost/loss/ (twice) > s/capabilities) are/capabilities) is/ > > Section 5.3.1 > sub-TLV [GMPLS-OSPF] > GMPLS-OSPF is not in the references. > > Section 5.3.1 > Local SNPP link ID Link local part of the TE link identifier > sub-TLV [GMPLS-ISIS] > GMPLS-ISIS is not in the references. > > Section 5.3.1 > Note: Link Attributes represent layer resource capabilities and > their utilization. > Undoubtedly true, but missing a little context? > > Section 5.3.2 > Nodes attributes include the "Logical Node ID" (as detailed in > Section 5.1) and the reachability information as described in > Section 5.3.3. > The use of "include" implies there are other node attributes not discussed > here. > Either discuss them (if they exist) or fix the text by s/include/are/ > > Section 5.3.3 > defined per address family, e.g., IPv4 and IPv6). However, [OSPF- > NODE] restricts to advertisement of Host addresses and not prefixes, > and therefore requires enhancement (see below). > s/restricts to advertisement/is restricted to advertisement/ > > Section 5.3.3 > A similar mechanism does not exist for IS-IS as the Extended IP > Reachability TLV [RFC3784] focuses on IP reachable end-points > (terminating points), as its name indicates. > I assume you mean that "An extension similar to [OSPF-NODE] is not > required for IS-IS because the function is already included in the > Reachability TLV. However, both the Reachability TLV and [OSPF-TLV] do not > support the advertisement of reachability prefixes." > > Section 5.4. > hence no specific capabilities are added to the routing protocol > s/are/need to be/ > > Section 5.5 > level hierarchy, and disallow the advertising of routing information > s/disallow/disallows/ > > Section 5.5 > downward in the hierarchy. [RFC2966] defines the up/down bit to > [RFC2966] is not in the references. > > Section 5.5 > [RFC1195] allows only advertising routing information upward in the > RFC 1195 is not in the references. > > Section 5.5 > downward in the hierarchy. [RFC2966] defines the up/down bit to > RFC 2966 is not in the references. > > Section 5.5 > OSPFv2 prevents that inter-area routes, which are learned from area > 0 are not passed back to area 0. However, GMPLS makes use of Type 10 > Rewrite as... > OSPFv2 prevents inter-area routes (which are learned from area 0) > from being passed back to area 0. However, GMPLS makes use of Type 10 > > Section 5.5 > (area-local scope) LSA to propagate TE information [RFC3630], [GMPLS- > s/LSA/LSAs/ > > Section 5.5 > which Type 10 Opaque LSA may carry the information that particular > s/LSA/LSAs/ > s/particular/a particular piece of/ > > Section 5.5 > back into an higher level RC. > s/an/a/ > > Section 5.6 > Link state protocols have been designed to detect topological > changes (such as interface failures, link attributes modification). > Convergence period is short and involves a minimum of routing > information exchange. > Do link state protocols detect the changes or propagate them? > s/Convergence/The convergence/ > s/and involves/and convergence involves/ > > Section 5.7 > behalf multiple Li's creates the following issue as there is no more > a 1:1 relationship between the Router_ID and the TE Router_ID but a > /more/longer/ > > Section 5.7 > and link remote (unnumbered) ID association may be not unique per > s/be not/not be/ > > Section 5.7 > retrieve the [Li;Lj] relationship(s). In brief, as unnumbered links > The RFC Ed. prefers that square brackets [] are used only for citations. > Can you use {}? > > Section 6 > respectively case 1), 2), 3) and 4). Additional base scenarios > (being not combinations or decomposition of entities) may further > complete this set in a future revision of this document. > Remove this sentence. > > Section 6 > In the below Figure 1: > s/In the below Figure 1:/In Figure 1 below: > > Section 6 > Please add captions to the figures. At the moment it is not completely > clear that cases 1, 2 and 3 appear in Figure 1, while case 4 appears in > Figure 3, and Figure 2 is a special representation of case 1. > > New Section 7 > Please add a new section after Section 6 > "Summary of Necessary Additions to OSPF and IS-IS" > It is too hard for the reader to extract these from the I-D with complete > certainty. > > Section 8.1 > Is [LMP-T] really normative? > Is [OSPF-NODE] really normative? The draft will progress better if it is > not. > [RFC3667] and [RFC3668] don't need to be listed. > [RFC3946] is not referenced. > > Section 8.2 > [ASON-RR] is surely normative. > > > . > From owner-ccamp@ops.ietf.org Tue Oct 04 04:41:43 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMiMo-0006ZL-Km for ccamp-archive@megatron.ietf.org; Tue, 04 Oct 2005 04:41:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05031 for ; Tue, 4 Oct 2005 04:41:40 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EMiVL-0001tD-JG for ccamp-archive@ietf.org; Tue, 04 Oct 2005 04:50:39 -0400 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EMiGM-0003w5-8g for ccamp-data@psg.com; Tue, 04 Oct 2005 08:35:02 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [80.168.70.141] (helo=relay1.mail.uk.clara.net) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EMiGJ-0003vd-DF for ccamp@ops.ietf.org; Tue, 04 Oct 2005 08:34:59 +0000 Received: from du-069-0146.access.clara.net ([217.158.132.146] helo=Puppy) by relay1.mail.uk.clara.net with smtp (Exim 4.46) id 1ELNXq-000EsC-H8; Fri, 30 Sep 2005 17:15:36 +0100 Message-ID: <07f401c5c5da$9a3fc4e0$be849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: , , Cc: , References: <3.0.1.32.20050908215948.014706d4@pop.mindspring.com> <11aa01c5bf75$b2750720$28849ed9@Puppy> <027b01c5c564$8fcff820$0500a8c0@jlucianilaptop> Subject: Re: MIB Dr. review of draft-ietf-ccamp-gmpls-te-mib-09.txt Date: Fri, 30 Sep 2005 17:15:21 +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 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Content-Transfer-Encoding: 7bit Hi Joan, > > > 7) gmplsTunnelUnnumIf > > > > > > What IF-MIB object are referring to in the DESCRIPTION? > > > Could you state which object in the description? > > > > Ack > > An entry in ifTable. > > Could you specify the ifType(s)? Yup. It'll be 166 (MPLS). Added to document. > > > Section 11.2.1. IANA-GMPLS-MIB Definition > > > ----------------------------------------- > > > > > 38) I believe that the TC > > > > > > IANAGmplsAdminStatusFlags ::= TEXTUAL-CONVENTION > > > > > > should be put in the GMPLS-TC-STD-MIB or should just > > > remain in the GMPLS-TE-STD-MIB. The reason is that this > > > is not an assigned numbers list maintained by IANA, so > > > should not be in the IANA GMPLS MIB. If I am incorrect > > > about this please let me know, but I didn't see an IANA > > > maintained Administrative Status Information enum. > > > > Nack > > There are no fewer than three requests in CCAMP I-Ds that have passed WG > > last call for this space to be managed by IANA. > > Is this going to be managed by IANA soon? (just curious) Cerainly it'll happen before this I-D is an RFC. Soon? I wouldn't want to comment on the IESG review process and RFC Editor process (but I am serving on the PESCI team). > > > 39) Several comments on the SYNTAX clause: > > > > > > 40a) smicngPRO gives the error > > > > > > E: f(IANA-GMPLS-MIB.my), (252,22) Named bits for BITS > > > must be in contiguous positions > > > > > > SYNTAX BITS { > > > delInProgress (0), > > > adminDown (1), > > > testing (2), > > > reflect (31) > > > } > > > > > > > > > RFC2578 specifies that BITS should be contiguous > > > (although there are exceptions to this, but this > > > object does not seem to be an exception). > > > > Nack > > > > To quote the DESCRIPTION... > > The relationship between the assignment of > > gmplsTunnelAdminStatusFlags values and of the bit flags > > in the Admin Status object or TLV within the GMPLS > > signaling protocols is solely the purview of IANA and is > > subject to change without notice." > > However, it seems to us that making the bits match the flags in the > > Admin Status object is a Good Idea (TM). > > > > Here is the TLV that the object represents: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |R| Reserved |T|A|D| > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Reflect (R): 1 bit > Reserved: 28 bits > Testing (T): 1 bit > Administratively down (A): 1 bit > Deletion in progress (D): 1 bit > > The BITS as specified look backwards when viewing the TLV. > Are the BITS correctly specified? > > I consulted with other MIB Doctors and the following was suggested: > SYNTAX BITS { > delInProgress (0), > adminDown (1), > testing (2), > reserved3(3), -- 0 on send, ignored on receive > reserved4(4), -- 0 on send, ignored on receive > .. > reserved30(30), -- 0 on send, ignored on receive > reflect (31) > } > > Would this be acceptable? We can fill in the gaps. Thanks once again for engaging. Adrian From kian@a1.mbn.or.jp Wed Oct 05 11:00:36 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENAl2-00029R-N4 for ccamp-archive@megatron.ietf.org; Wed, 05 Oct 2005 11:00:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29011 for ; Wed, 5 Oct 2005 11:00:34 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ENAtq-0006K1-JG for ccamp-archive@ietf.org; Wed, 05 Oct 2005 11:09:48 -0400 Received: from [61.96.12.235] (helo=61.96.12.235) by mx2.foretec.com with smtp (Exim 4.24) id 1EN9tH-0003Mv-Sh for ccamp-archive@ietf.org; Wed, 05 Oct 2005 10:05:08 -0400 Message-ID: From: "Paul A. Davis" To: ccamp-archive@ietf.org Subject: =?iso-8859-1?B?Q2lhbGlzIC0gTm8gcHJlc2NyaXB0aW9uIG5lZWRlZCE=?= Date: Wed, 05 Oct 2005 11:50:36 +0000 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0000_4EC0C9CD.6687A06E" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express V6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 1.2 (+) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab This is a multi-part message in MIME format. ------=_NextPart_000_0000_4EC0C9CD.6687A06E Content-Type: multipart/alternative; boundary="----=_NextPart_001_0001_E30B21A1.ECE82310" ------=_NextPart_001_0001_E30B21A1.ECE82310 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Viagra (only $1.56/pill) | Viagra Softtabs (only $1.89/pill) Cialis (only $3.00/pill) | Cialis Softtabs (only $3.33/pill) Levitra (only $2.78/pill) http://www.vippills.net ________________________________ To change your mail preferences, go here ________________________________ ------=_NextPart_001_0001_E30B21A1.ECE82310 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 7bit

Viagra (only $1.56/pill) | Viagra Softtabs (only $1.89/pill)
Cialis (only $3.00/pill) | Cialis Softtabs (only $3.33/pill)
Levitra (only $2.78/pill)

http://www.vippills.net


________________________________
To change your mail preferences, go here
________________________________

------=_NextPart_001_0001_E30B21A1.ECE82310-- ------=_NextPart_000_0000_4EC0C9CD.6687A06E-- From info@mail.fdjays.com Wed Oct 05 16:58:47 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENGLf-0003NX-Eb for ccamp-archive@megatron.ietf.org; Wed, 05 Oct 2005 16:58:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22150 for ; Wed, 5 Oct 2005 16:58:44 -0400 (EDT) Received: from [58.180.196.230] (helo=mail.fdjays.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ENGUa-0001fA-3f for ccamp-archive@ietf.org; Wed, 05 Oct 2005 17:08:02 -0400 Received: (qmail 1905 invoked by uid 510); 6 Oct 2005 01:58:50 +0900 Date: 6 Oct 2005 01:58:50 +0900 Message-ID: <20051005165850.1904.qmail@mail.fdjays.com> From: info@fdjays.com To: ccamp-archive@ietf.org Subject: $B7n5k$H9M$($F$$$^$9!#(B X-Spam-Score: 3.6 (+++) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 $B!!@iN$$5$s$N4uK>$h$j5.J}MM$rL5NA2q0w$H$7$FG'DjCW$7$^$9!#$3$N%a!<%k$K$F5.J}$N!zL5NA2q0w;q3J!z$rH/I=$5$;$FD:$-$^$9!#(B $B"(G'>Z%J%s%P!pJsNA$r$9$Y$F!ZL5NA![$H$5$;$FD:$-$^$9!#(B $BG'>Z%Z!<%8!!(B http://www.lovegal2.net?check ----------------------------------------------------------- $B!Z@iN$2q0w![$N8D?M%Z!<%8$b:\$;$F$"$j$^$9$N$G!"$43NG'$r$*4j$$$7$^$9(B($B8D?M>pJsJ]8n$N0Y!"B>?M$N8x3+$7$J$$$h$&$*4j$$CW$7$^$9(B)$B!#(B $BG/Np!'(B33$B:P(B $B4il$G:G6aK0$-$F$7$^$$$^$7$?!#;d$NAjl$r@5D>$K65$($F$[$7$$$G$9$M!#l=j$r7hDj$7$?$$$G$9$,!"$*JV;v$r3Z$7$a$K$7$F$$$^$9!#!W(B http://www.lovegal2.net?tisato $B$4EPO?8e!"CO0h40A40lCW$N9b<}F~(B($B7n<}(B35$BK|!A(B)$B=w@-!N#3L>!O$r%T%C%/%"%C%W$7!"Ev;~>R2p$r9T$$$^$9$N$G!"=w@-2q0w$ND>%a!<%k$h$j>pJs$r3NG'$r$*4j$$$7$^$9!#(B $B5qH]$NJ}$O%3%A%i(B Please inform the following address if this mail is unnecessary. nomore@lovegal2.net From owner-ccamp@ops.ietf.org Thu Oct 06 11:02:47 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENXGg-0003JN-KR for ccamp-archive@megatron.ietf.org; Thu, 06 Oct 2005 11:02:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09164 for ; Thu, 6 Oct 2005 11:02:44 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ENXPg-0003cV-Pe for ccamp-archive@ietf.org; Thu, 06 Oct 2005 11:12:11 -0400 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1ENWwk-000HcH-LM for ccamp-data@psg.com; Thu, 06 Oct 2005 14:42:10 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, DATE_IN_PAST_03_06 autolearn=ham version=3.1.0 Received: from [62.241.162.31] (helo=galaxy.systems.pipex.net) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1ENWwi-000Hbr-Cm for ccamp@ops.ietf.org; Thu, 06 Oct 2005 14:42:09 +0000 Received: from pc6 (1Cust89.tnt106.lnd4.gbr.da.uu.net [213.116.60.89]) by galaxy.systems.pipex.net (Postfix) with SMTP id 41AB6E000133; Thu, 6 Oct 2005 15:41:51 +0100 (BST) Message-ID: <036501c5ca7b$a2c16a60$0601a8c0@pc6> Reply-To: "Tom Petch" From: "Tom Petch" To: "Adrian Farrel" , , Cc: References: <3.0.1.32.20050908215948.014706d4@pop.mindspring.com> <11aa01c5bf75$b2750720$28849ed9@Puppy> <027b01c5c564$8fcff820$0500a8c0@jlucianilaptop> Subject: Re: MIB Dr. review of draft-ietf-ccamp-gmpls-te-mib-09.txt Date: Thu, 6 Oct 2005 12:36:06 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.8 (/) X-Scan-Signature: 3da7e5d5ca82d58872786934e4963616 Content-Transfer-Encoding: 7bit Adrian I am still unsure about MSB/LSB in IANAGmplsAdminStatusFlags. This has reflect (31) while RFC3471 has reflect as bit 0. As Joan says, "The BITS as specified look backwards when viewing the TLV". This is fine if one is MSB, the other LSB (although that might be worth adding a note about). Tom Petch ----- Original Message ----- From: To: "Adrian Farrel" ; ; Cc: ; Sent: Friday, September 30, 2005 4:13 AM Subject: Re: MIB Dr. review of draft-ietf-ccamp-gmpls-te-mib-09.txt > > hi Adrian, > > Please see comments inline below, I have snipped parts where we > are in agreement. > > thanks, joan > > > > ----- Original Message ----- > From: Adrian Farrel > To: ; ; > Cc: ; > Sent: Thursday, September 22, 2005 8:59 AM > Subject: Re: MIB Dr. review of draft-ietf-ccamp-gmpls-te-mib-09.txt > > > > Hi Joan, > > > > Last but not least, the GMPLS TE MIB module. > > > > > Here are some comments on draft-ietf-ccamp-gmpls-te-mib-09.txt. > > > All 3 docs show a good deal of work. > > > > Yes, but fortunatley most of the work appears to be editorial with only > > very minor changes to the basis of the module. > > > > Please find acks and nacks in line below. > > > > We will also include the comments made by David and Tom Petch. > > > > Cheers, > > Adrian > > > > > > > > Section 8. GMPLS Traffic Engineering MIB Module > > > ----------------------------------------------- > > > > > > smicngPRO gives the following: > > > > > > W: f(GMPLS-TE-STD-MIB), (1181,14) Item "gmplsTunnelErrorTLVs" should > > have > > > SIZE specified > > > > Ack > > Understood this to be optional, but planning to add size as per David's > > comments > > > > > W: f(GMPLS-TE-STD-MIB), (1362,13) For "gmplsTunnelDirection", syntax is > > > identical > > > W: f(GMPLS-TE-STD-MIB), (1371,13) For "gmplsTunnelPathComp", syntax is > > > identical > > > W: f(GMPLS-TE-STD-MIB), (1382,14) For "gmplsTunnelUpNotRecip", syntax is > > > identical > > > W: f(GMPLS-TE-STD-MIB), (1389,14) For "gmplsTunnelDownNotRecip", syntax > > is > > > identical > > > W: f(GMPLS-TE-STD-MIB), (1401,14) For "gmplsTunnelExtraParamsPtr", > > syntax > > > is identical > > > > Nack > > Meaningless warning message. Cannot fix without explanation. > > > The object is defined as: > > > gmplsTunnelDirection OBJECT-TYPE > SYNTAX INTEGER { > forward (0), > bidirectional (1) > } > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "Whether this tunnel carries forward data only (is > unidirectional) or is bidirectional. > > Values of this object other than 'forward' are meaningful > only if gmplsTunnelLSPEncoding is not set to > 'tunnelLspNotGmpls'." > DEFVAL { forward } > ::= { gmplsTunnelEntry 8 } > > > The following (part of the ReadOnly compliance statement) is causing > the warning because the SYNTAX defined in the object and the > SYNTAX below are the same. (Following the OBJECT are a > few alternatives.) > > OBJECT gmplsTunnelDirection > SYNTAX INTEGER { > forward (0), > bidirectional (1) > } > MIN-ACCESS read-only > DESCRIPTION > "Only forward (0) is required." > > > If you do intend for the SYNTAX in both the OBJECT-TYPE and > the OBJECT to be the same, then removing it from the OBJECT > would get rid of the warning. This is not a blocking issue, but > it is duplicate info that does not need to be duplicated. > So here is what the OBJECT statement would like: > > OBJECT gmplsTunnelDirection > MIN-ACCESS read-only > DESCRIPTION > "Only forward (0) is required." > > Another alternative would be to specify forward(0) only since > this is what the DESCRIPTION is specifying, however, it is > likely that you are probably allowing both, so I don't think this > is what you intend, but this would also solve the compiler warning: > > OBJECT gmplsTunnelDirection > SYNTAX INTEGER { > forward (0), > } > MIN-ACCESS read-only > DESCRIPTION > "Only forward (0) is required." > > > > > > > 5) gmplsTunnelTable > > > > > > DESCRIPTION > > > > > > "The row status of an entry in this table is controlled by > > > mplsTunnelRowStatus in the corresponding entry in > > > mplsTunnelTable. That is, it is not permitted to create a row in > > > this table, nor to modify an existing row, when the > > > corresponding mplsTunnelRowStatus has value active(1).... > > > > > > The sentence beginning with "That is," is awkward. Could you say > > > something like: A row in this table is created when a row is created > > > in the mplsTunnelTable. Entries in this table cannot be modified > > > when the corresponding mplsTunnelRowStatus has a value of active(1). > > > The exception.... > > > > > > Please also update this other places in this MIB (e.g > > gmplsTunnelHopTable). > > > > Nack > > "A row in this table is created when a row is created in the > > mplsTunnelTable" is false. > > Will attempt to reword to make this clearer. > > > > > 6) gmplsTunnelEntry > > > DESCRIPTION: > > > "... > > > An entry can be created by a network administrator or by an SNMP > > > agent as instructed by a signaling protocol." > > > > > > Please change the above to: > > > > > > "An entry can be created by a network administrator via SNMP SET > > commands, or > > > by the network management entity as instructed by a signaling > > > protocol." > > > > Nack > > "network management entity" implies a remote entity such as an NMS. > > Yes, I should have said, "network management entity (e.g., snmp agent). > > > > Will change to: > > > > "An entry can be created by a network administrator via SNMP SET > > commands, or in response to signaling protocol events." > > > > good. > > > > 7) gmplsTunnelUnnumIf > > > > > > What IF-MIB object are referring to in the DESCRIPTION? > > > Could you state which object in the description? > > > > Ack > > An entry in ifTable. > > > > Could you specify the ifType(s)? > > > > 8) gmplsTunnelAttributes > > > Could you specify what happens when the bit is set (i.e. 1) > > > vs. 0? > > > > Ack > > Don't want to restate the protocol I-D, so this text will simply > > replace "This flag indicates that" with "This flag is set to indicate > > that" > > > > > 9) gmplsTunnelLSPEncoding > > > > > > The DESCRIPTION states: > > > ...A value of 'tunnelLspNotGmpls' indicates that GMPLS signaling > > is > > > not in use. Some objects in this MIB module may be of use for > > > MPLS signaling extensions that do not use GMPLS signaling. By > > > setting this object to 'tunnelLspNotGmpls', an application may > > > indicate that only those objects meaningful in MPLS should be > > > examined.... > > > > > > I believe that such objects should be put in to an MPLS MIB module > > > and not included in this GMPLS MIB module. This is also true with > > > the gmplsTunnelErrorTable. > > > > Nack > > We strongly disagree with any implication that MPLS and GMPLS should be > > separated in this way. GMPLS protocol extensions are likely to be > > moved into MPLS implementations piecemeal and there is no clear > > separation that you imply. The G in GMPLS stands for "generalized". > > > > Can you please indicate whether this is a sticking point for you. > > > > As was suggested in an email on draft-ietf-ccamp-gmpls-lsr-mib, could > you put these objects in a separate object group? Also, please separate > MPLS and MPLS-TE objects into separate object groups. > > > > > > > 12) gmplsTunnelUpNotRecip > > > > > > Need to use InetAddressType and InetAddress. IpAddress > > > is not used in MIBs anymore. Please be sure to support > > > both v4 and v6 IP address Types. If you can't support > > > v6 for some reason, that should be stated clearly. > > > > Ack per exchange with David. > > > > > Please change the name of this object to: > > > gmplsTunnelUpstreamRecipientForNotify > > > > Nack > > We are trying to keep to the (mythical?) 32 character limit. > > How about: > > gmplsTunnelUpNotifyRecipient > > How about gmplsTunnelUpstreamNotifyRecipient > > As for the 32 char limit, we've already addressed that, so won't > repeat that discussion. > > > > > > 13) gmplsTunnelDownNotRecip > > > Same comment as above wrt to IpAddress. > > > > Ack > > > > > Please change the name to gmplsTunnelDownstreamRecipientForNotify > > > > Nack as above > > How about: > > gmplsTunnelDownNotifyRecipient > > How about gmplsTunnelDownstreamNotifyRecipient > > > >> > 18) gmplsTunnelHopExpLabel and gmplsTunnelHopExpLabelPtr > > > > > > Need to add the word "Forward" in here as in > > > gmplsTunnelHopExpForwardLabel and gmplsTunnelHopExpForwardLabelPtr > > > > > > That way it will be consistent with the Reverse counterparts. > > > > Nack > > Please see point 21 about name lengths. > > We will insert "Fwd" > > > > > 19) gmplsTunnelHopExpRvrsLabel and gmplsTunnelHopExpReverseLabelPtr > > > > > > Please change Rvrs to Reverse. > > > > Nack > > Please see point 21 about name lengths > > In other objects in this MIB module are named using the entire > word Reverse ( e.g. > GmplsTunnelReversePerfEntry ::= SEQUENCE { > gmplsTunnelReversePerfPackets Counter32, > gmplsTunnelReversePerfHCPackets Counter64, > gmplsTunnelReversePerfErrors Counter32, > gmplsTunnelReversePerfBytes Counter32, > gmplsTunnelReversePerfHCBytes Counter64 > }) > > So please either change these to all use Rvrs or instead of Rvrs use > the entire word, Reverse. Similarly with the use of Fwd and Forward, > if you decide to use Reverse, then please use the entire word, Forward. > If you decide to use Rvrs, then please use Fwd. I prefer the words > spelled out but just please be consistent. > > > > > > 21) gmplsTunnelARHopExpLable and gmplsTunnelARHopExpLabelPtr > > > > > > Need to add the word "Forward" in here as in > > > gmplsTunnelARHopExpForwardLabel and gmplsTunnelARHopExpForwardLabelPtr > > > > Nack > > Would excede 32 characters. > > Will use "Fwd" > > See discussion above wrt Rvrs and Reverse. > > > > > > 22) gmplsTunnelARHopExpRvrsLabel and gmplsTunnelARHopExpRvrsLabelPtr > > > > > > Please change Rvrs to Reverse > > > > Nack > > See point 21 > > > > > 23) gmplsTunnelARHopProtection OBJECT-TYPE > > > > > > Please add what the BIT set (i.e. 1) vs. 0 means in the > > > DESCRIPTION. > > > > Ack > > Limited change as before. > > > > > 24) gmplsTunnelCHopLabelTable objects > > > > > > Similar comments regarding the objects in this table > > > to those above with regard to naming > > > conventions (Forward and Reverse) and DESCRIPTIONs. Will not repeat the > > > details, please refer to above comments on the > > > prior 2 tables. > > > > Nack > > Same answers as before. > > Will use "Fwd" > > > > > 25) gmplsTunnelReversePerfTable > > > Please add to the DESCRIPTION how a user knows if > > > this is a bidirectional tunnel (i.e. what object > > > or objects in the gmplsTunnelTable need to have > > > what values?). > > > > Ack > > > > > 26) gmplsTunnelReversePerfPackets > > > > > > Does this object represent the 32-bit > > > value of the least significant part of the > > > 64-bit value (which is contained in gmplsTunnelReversePerfHCPackets)? > > > > Ack > > > > > 27) gmplsTunnelReversePerfBytes > > > > > > Does this object represent the 32-bit > > > value of the least significant part of the > > > 64-bit value (which is contained in gmplsTunnelReversePerfHCBytes)? > > > > Ack > > > > > 28) gmplsTunnelErrorTable OBJECT-TYPE > > > > > > Since this table applies to MPLS, it should be > > > put in a separate MIB module which is MPLS specific. The > > > prefix of gmpls could be confusing. > > > > Nack > > This is applicable across MPLS and GMPLS. > > Error TLVs are not present in MPLS RSVP-TE at this time. They may be added > > later. > > > > Discussed previously about separate OBJECT groups. > > > > 31) Compliance > > > > > > Please move some of the following comment in the > > > DESCRIPTION of gmplsTeModuleFullCompliance > > > > > > -- The mandatory group has to be implemented by all LSRs that > > > -- originate, terminate or act as transit for TE-LSPs/tunnels. > > > -- In addition, depending on the type of tunnels supported, other > > > -- groups become mandatory as explained below. > > > > Ack > > > > > 32) gmplsTunnelUnnumIf does not appear in the ReadOnly compliance > > > and it probably should. > > > > Ack > > > > > Section 11.2.1. IANA-GMPLS-MIB Definition > > > ----------------------------------------- > > > > > 38) I believe that the TC > > > > > > IANAGmplsAdminStatusFlags ::= TEXTUAL-CONVENTION > > > > > > should be put in the GMPLS-TC-STD-MIB or should just > > > remain in the GMPLS-TE-STD-MIB. The reason is that this > > > is not an assigned numbers list maintained by IANA, so > > > should not be in the IANA GMPLS MIB. If I am incorrect > > > about this please let me know, but I didn't see an IANA > > > maintained Administrative Status Information enum. > > > > Nack > > There are no fewer than three requests in CCAMP I-Ds that have passed WG > > last call > > for this space to be managed by IANA. > > Is this going to be managed by IANA soon? (just curious) > > > > > > Additionally, this should be renamed to > > > GmplsAdminStatusInformation which more closely matches rfc3471. > > > > Ack > > > > > 39) Several comments on the SYNTAX clause: > > > > > > 40a) smicngPRO gives the error > > > > > > E: f(IANA-GMPLS-MIB.my), (252,22) Named bits for BITS > > > must be in contiguous positions > > > > > > SYNTAX BITS { > > > delInProgress (0), > > > adminDown (1), > > > testing (2), > > > reflect (31) > > > } > > > > > > > > > RFC2578 specifies that BITS should be contiguous > > > (although there are exceptions to this, but this > > > object does not seem to be an exception). > > > > Nack > > > > To quote the DESCRIPTION... > > The relationship between the assignment of > > gmplsTunnelAdminStatusFlags values and of the bit flags > > in the Admin Status object or TLV within the GMPLS > > signaling protocols is solely the purview of IANA and is > > subject to change without notice." > > However, it seems to us that making the bits match the flags in the > > Admin Status object is a Good Idea (TM). > > > > Here is the TLV that the object represents: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |R| Reserved |T|A|D| > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Reflect (R): 1 bit > Reserved: 28 bits > Testing (T): 1 bit > Administratively down (A): 1 bit > Deletion in progress (D): 1 bit > > The BITS as specified look backwards when viewing the TLV. > Are the BITS correctly specified? > > I consulted with other MIB Doctors and the following was suggested: > SYNTAX BITS { > delInProgress (0), > adminDown (1), > testing (2), > reserved3(3), -- 0 on send, ignored on receive > reserved4(4), -- 0 on send, ignored on receive > .. > reserved30(30), -- 0 on send, ignored on receive > reflect (31) > } > > Would this be acceptable? > > > > > Could delInProgress, be renamed to deleteInProgress ? > > > Could adminDown be renamed to administrativelyDown? > > > These names more closely match 3471. > > > > Ack > > > > > From info@mail.kjgjd.com Fri Oct 07 09:17:43 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENs6Z-0007tR-43 for ccamp-archive@megatron.ietf.org; Fri, 07 Oct 2005 09:17:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17418 for ; Fri, 7 Oct 2005 09:17:40 -0400 (EDT) Received: from [58.180.198.203] (helo=mail.kjgjd.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ENsFp-0005y4-Q7 for ccamp-archive@ietf.org; Fri, 07 Oct 2005 09:27:19 -0400 Received: (qmail 6378 invoked by uid 509); 7 Oct 2005 19:00:30 +0900 Date: 7 Oct 2005 19:00:30 +0900 Message-ID: <20051007100030.6377.qmail@mail.kjgjd.com> From: info@kjgjd.com To: ccamp-archive@ietf.org Subject: $BL$Mh$G$9!#(B X-Spam-Score: 3.6 (+++) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 $BFMA3$N%a!<%k$G?=$7Lu$"$j$^$;$s!#$3$N%a!<%k$rITMW!&ITL{2w$K46$8$i$l$?J}!"??$K?=$7Lu$"$j$^$;$s$G$7$?!#Ev%0%k!<%W$G$O8=:_!"=w@-$N2q0w?t$KCK@-$N2q0w?t$,DI$$$D$+$J$$>u67$H$J$C$F$*$j$^$9!#$=$3$G!"7G<(HD$K=q$-9~$_$rD:$$$?$*5RMM$K%a!<%k$r$5$;$F$$$?$@$-$^$7$?!#$b$7!"2x$7$$$H;W$C$?$j!"$^$C$?$/6=L#$,$J$$J}$O$3$N%a!<%k$rGK4~$7$F$/$@$5$$$^$9$h$&$h$m$7$/$*4j$$CW$7$^$9!#(B $BEvHVAH$OF|!9=w@-$+$i>R2p4uK>$rpJs$rCO0hCK@-2q0w$K8x3+$7$F$*$j$^$9!#K\F|5.J}MM$K$4>R2p$7$?$$$N$O:!J}$N=w@-2q0w$G$9!#(B $BEPO?L>A0!'L$Mh(B $B"#G/Np!!!j(B29$B:M(B $B"#?&6H!!2qR2p$rMj$_$^$7$?!#;E;v$O;vL3$J$N$G=w@-$@$1$N?&>l$G$9!#KhF|;E;v$H2H$N1}I|$P$C$+$j$GB`6~$7$F$$$^$9!#(B $B@h7nR2p$5$l$?J}$OEPO?!&>R2p$J$I$NHqMQ$O0l@ZD:$-$^$;$s$N$G!"$40B?42<$5$$!#(B $B!!!!!!(B http://www.otakkujp.net?MIRAI ($BL5NAEPO?MQ(B) $B!Z@bL@![(B $B5.J}$+$i$N%a!<%k$,E~Ce%a!<%k$K$F=w@-$H$NO"MmJ}K!$r$4O"Mm?=$7>e$2$^$9!#(B $B5qH](B (Refusal Adress) iranai@otakkujp.net From info@mail.kusydg.com Fri Oct 07 15:12:14 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENxde-00022e-KF for ccamp-archive@megatron.ietf.org; Fri, 07 Oct 2005 15:12:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07295 for ; Fri, 7 Oct 2005 15:12:10 -0400 (EDT) Received: from [58.180.198.219] (helo=mail.kusydg.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ENxmw-0004Jn-CQ for ccamp-archive@ietf.org; Fri, 07 Oct 2005 15:21:52 -0400 Received: (qmail 18696 invoked by uid 509); 8 Oct 2005 00:23:39 +0900 Date: 8 Oct 2005 00:23:39 +0900 Message-ID: <20051007152339.18695.qmail@mail.kusydg.com> From: info@kusydg.com To: ccamp-archive@ietf.org Subject: $BL$Mh$G$9!#(B X-Spam-Score: 3.6 (+++) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 $BFMA3$N%a!<%k$G?=$7Lu$"$j$^$;$s!#$3$N%a!<%k$rITMW!&ITL{2w$K46$8$i$l$?J}!"??$K?=$7Lu$"$j$^$;$s$G$7$?!#Ev%0%k!<%W$G$O8=:_!"=w@-$N2q0w?t$KCK@-$N2q0w?t$,DI$$$D$+$J$$>u67$H$J$C$F$*$j$^$9!#$=$3$G!"7G<(HD$K=q$-9~$_$rD:$$$?$*5RMM$K%a!<%k$r$5$;$F$$$?$@$-$^$7$?!#$b$7!"2x$7$$$H;W$C$?$j!"$^$C$?$/6=L#$,$J$$J}$O$3$N%a!<%k$rGK4~$7$F$/$@$5$$$^$9$h$&$h$m$7$/$*4j$$CW$7$^$9!#(B $BEvHVAH$OF|!9=w@-$+$i>R2p4uK>$rpJs$rCO0hCK@-2q0w$K8x3+$7$F$*$j$^$9!#K\F|5.J}MM$K$4>R2p$7$?$$$N$O:!J}$N=w@-2q0w$G$9!#(B $BEPO?L>A0!'L$Mh(B $B"#G/Np!!!j(B29$B:M(B $B"#?&6H!!2qR2p$rMj$_$^$7$?!#;E;v$O;vL3$J$N$G=w@-$@$1$N?&>l$G$9!#KhF|;E;v$H2H$N1}I|$P$C$+$j$GB`6~$7$F$$$^$9!#(B $B@h7nR2p$5$l$?J}$OEPO?!&>R2p$J$I$NHqMQ$O0l@ZD:$-$^$;$s$N$G!"$40B?42<$5$$!#(B $B!!!!!!(B http://www.otakkujp.net?MIRAI ($BL5NAEPO?MQ(B) $B!Z@bL@![(B $B5.J}$+$i$N%a!<%k$,E~Ce%a!<%k$K$F=w@-$H$NO"MmJ}K!$r$4O"Mm?=$7>e$2$^$9!#(B $B5qH](B (Refusal Adress) iranai@otakkujp.net From owner-ccamp@ops.ietf.org Sun Oct 09 22:09:35 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EOn6d-0002X6-94 for ccamp-archive@megatron.ietf.org; Sun, 09 Oct 2005 22:09:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24518 for ; Sun, 9 Oct 2005 22:09:33 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EOnGN-00057M-LD for ccamp-archive@ietf.org; Sun, 09 Oct 2005 22:19:44 -0400 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EOmu1-000OCJ-3J for ccamp-data@psg.com; Mon, 10 Oct 2005 01:56:33 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=3.1.0 Received: from [209.86.89.68] (helo=smtpauth08.mail.atl.earthlink.net) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EOmu0-000OBv-Ek for ccamp@ops.ietf.org; Mon, 10 Oct 2005 01:56:32 +0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=WjgBY3rKMJkY5V6KIYHmCpQEOpRkvGO08ICdDUWGJKJVDjFW0DUsif8C+s/VLl1C; 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 [66.167.248.235] (helo=jlucianilaptop) by smtpauth08.mail.atl.earthlink.net with asmtp (Exim 4.34) id 1EOmtq-0008Ck-W6; Sun, 09 Oct 2005 21:56:23 -0400 Message-ID: <015c01c5cd3d$bbe87500$0500a8c0@jlucianilaptop> From: To: "Adrian Farrel" , "Tom Petch" , "Thomas D. Nadeau" , Cc: References: <3.0.1.32.20050908215948.014706d4@pop.mindspring.com> <11aa01c5bf75$b2750720$28849ed9@Puppy> <027b01c5c564$8fcff820$0500a8c0@jlucianilaptop> <036501c5ca7b$a2c16a60$0601a8c0@pc6> <00c701c5ccc3$ee1db320$f2849ed9@Puppy> Subject: Re: MIB Dr. review of draft-ietf-ccamp-gmpls-te-mib-09.txt Date: Sun, 9 Oct 2005 21:55:47 -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: 4d68bbe9cb71969ea344cf2d1a8e60840a9da525759e265497e4cc97a9b884ac909bcfff23141ff5c839d1b4ccd7d4ce350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 66.167.248.235 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.4 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: 7bit Adrian, Please add a note as to why the bits are reversed for the managed object. Thanks, Joan ----- Original Message ----- From: Adrian Farrel To: Tom Petch ; Thomas D. Nadeau ; Cc: Sent: Sunday, October 09, 2005 7:18 AM Subject: Re: MIB Dr. review of draft-ietf-ccamp-gmpls-te-mib-09.txt > Hi Tom, > > > I am still unsure about MSB/LSB in IANAGmplsAdminStatusFlags. This has > reflect > > (31) while RFC3471 has reflect as bit 0. > > > > As Joan says, "The BITS as specified look backwards when viewing the > TLV". > > > > This is fine if one is MSB, the other LSB (although that might be worth > adding a > > note about). > > You are both right. > We have reversed the order of the bits in the IANA MIB and also filled the > gap with "reserved" bits. > > Cheers, > Adrian > From owner-ccamp@ops.ietf.org Mon Oct 10 00:41:43 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EOpTr-0005FC-AS for ccamp-archive@megatron.ietf.org; Mon, 10 Oct 2005 00:41:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA00476 for ; Mon, 10 Oct 2005 00:41:40 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EOpdV-0008Om-Uq for ccamp-archive@ietf.org; Mon, 10 Oct 2005 00:51:53 -0400 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EOpOj-000Adc-0l for ccamp-data@psg.com; Mon, 10 Oct 2005 04:36:25 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.0 Received: from [62.241.163.7] (helo=blaster.systems.pipex.net) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EOpOh-000AdK-5N for ccamp@ops.ietf.org; Mon, 10 Oct 2005 04:36:23 +0000 Received: from dnni.com (81-178-2-190.dsl.pipex.com [81.178.2.190]) by blaster.systems.pipex.net (Postfix) with ESMTP id 596E8E0001AD for ; Sun, 9 Oct 2005 12:17:51 +0100 (BST) Received: from Puppy ([217.158.132.242] RDNS failed) by dnni.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 9 Oct 2005 12:14:40 +0100 Message-ID: <008b01c5ccc3$0c4d03b0$f2849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Fw: 64th IETF - DRAFT Agenda Date: Sun, 9 Oct 2005 12:01:36 +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: 09 Oct 2005 11:14:40.0875 (UTC) FILETIME=[A4B193B0:01C5CCC2] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit Hi, Early plans have CCAMP scheduled as MONDAY, November 7, 2005 0900-1130 Morning Session I RTG ccamp Common Control and Measurement Plane WG This may get changed. Cheers, Adrian From owner-ccamp@ops.ietf.org Mon Oct 10 00:41:43 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EOpTr-0005FD-BF for ccamp-archive@megatron.ietf.org; Mon, 10 Oct 2005 00:41:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA00477 for ; Mon, 10 Oct 2005 00:41:40 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EOpdS-0008Oc-Ms for ccamp-archive@ietf.org; Mon, 10 Oct 2005 00:51:53 -0400 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EOpOk-000Adx-Lo for ccamp-data@psg.com; Mon, 10 Oct 2005 04:36:26 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.0 Received: from [62.241.163.7] (helo=blaster.systems.pipex.net) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EOpOk-000Adg-0f for ccamp@ops.ietf.org; Mon, 10 Oct 2005 04:36:26 +0000 Received: from dnni.com (81-178-2-190.dsl.pipex.com [81.178.2.190]) by blaster.systems.pipex.net (Postfix) with ESMTP id 290DDE0001CE; Sun, 9 Oct 2005 12:30:02 +0100 (BST) Received: from Puppy ([217.158.132.242] RDNS failed) by dnni.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 9 Oct 2005 12:20:59 +0100 Message-ID: <00c701c5ccc3$ee1db320$f2849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Tom Petch" , "Thomas D. Nadeau" , Cc: References: <3.0.1.32.20050908215948.014706d4@pop.mindspring.com> <11aa01c5bf75$b2750720$28849ed9@Puppy> <027b01c5c564$8fcff820$0500a8c0@jlucianilaptop> <036501c5ca7b$a2c16a60$0601a8c0@pc6> Subject: Re: MIB Dr. review of draft-ietf-ccamp-gmpls-te-mib-09.txt Date: Sun, 9 Oct 2005 12:18:41 +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: 09 Oct 2005 11:20:59.0989 (UTC) FILETIME=[86A9C850:01C5CCC3] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit Hi Tom, > I am still unsure about MSB/LSB in IANAGmplsAdminStatusFlags. This has reflect > (31) while RFC3471 has reflect as bit 0. > > As Joan says, "The BITS as specified look backwards when viewing the TLV". > > This is fine if one is MSB, the other LSB (although that might be worth adding a > note about). You are both right. We have reversed the order of the bits in the IANA MIB and also filled the gap with "reserved" bits. Cheers, Adrian From owner-ccamp@ops.ietf.org Mon Oct 10 09:14:55 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EOxUV-00070m-HM for ccamp-archive@megatron.ietf.org; Mon, 10 Oct 2005 09:14:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08216 for ; Mon, 10 Oct 2005 09:14:53 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EOxeL-0004b2-Nz for ccamp-archive@ietf.org; Mon, 10 Oct 2005 09:25:10 -0400 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EOxLA-000261-5O for ccamp-data@psg.com; Mon, 10 Oct 2005 13:05:16 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=3.1.0 Received: from [209.86.89.68] (helo=smtpauth08.mail.atl.earthlink.net) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EOxL9-00025n-F5 for ccamp@ops.ietf.org; Mon, 10 Oct 2005 13:05:15 +0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=S6Yae/GU7ykdeCLXu2Www1+fEtQj6qjmLNx3LV3dygMiuSvWeZUG1lqHUiKM9glm; 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 [66.167.248.235] (helo=jlucianilaptop) by smtpauth08.mail.atl.earthlink.net with asmtp (Exim 4.34) id 1EOxL6-0000B6-T4; Mon, 10 Oct 2005 09:05:13 -0400 Message-ID: <01b901c5cd9b$0a274d60$0500a8c0@jlucianilaptop> From: To: "Adrian Farrel" , "Tom Petch" , "Thomas D. Nadeau" , Cc: References: <3.0.1.32.20050908215948.014706d4@pop.mindspring.com> <11aa01c5bf75$b2750720$28849ed9@Puppy> <027b01c5c564$8fcff820$0500a8c0@jlucianilaptop> <036501c5ca7b$a2c16a60$0601a8c0@pc6> <00c701c5ccc3$ee1db320$f2849ed9@Puppy> <015c01c5cd3d$bbe87500$0500a8c0@jlucianilaptop> <00f101c5cd88$1957d4c0$f2849ed9@Puppy> Subject: Re: MIB Dr. review of draft-ietf-ccamp-gmpls-te-mib-09.txt Date: Mon, 10 Oct 2005 09:03: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: 4d68bbe9cb71969ea344cf2d1a8e60840a9da525759e26541cdced10c7372554e9fe0b62a15c27e2350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 66.167.248.235 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.4 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: 7bit ----- Original Message ----- From: Adrian Farrel To: ; Tom Petch ; Thomas D. Nadeau ; Cc: Sent: Monday, October 10, 2005 6:40 AM Subject: Re: MIB Dr. review of draft-ietf-ccamp-gmpls-te-mib-09.txt > Hi Joan, > > > Please add a note as to why the bits are reversed for the managed > object. > > No, no, no, no! :-) > > I said... > > > > You are both right. > > > We have reversed the order of the bits in the IANA MIB and also filled > the > > > gap with "reserved" bits. > > That means we have changed the order from what it used to be to what you > have asked for. Okay, sorry for my confusion. -Joan > > Thanks, > Adrian > > From owner-ccamp@ops.ietf.org Tue Oct 11 01:46:11 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPCxk-0000zM-NW for ccamp-archive@megatron.ietf.org; Tue, 11 Oct 2005 01:46:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA16792 for ; Tue, 11 Oct 2005 01:46:03 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPD7T-000506-Ez for ccamp-archive@ietf.org; Tue, 11 Oct 2005 01:56:28 -0400 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EPCoM-0002Ze-R4 for ccamp-data@psg.com; Tue, 11 Oct 2005 05:36:26 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.0 Received: from [62.241.163.7] (helo=blaster.systems.pipex.net) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EPCoK-0002ZA-Oy for ccamp@ops.ietf.org; Tue, 11 Oct 2005 05:36:24 +0000 Received: from dnni.com (81-178-2-190.dsl.pipex.com [81.178.2.190]) by blaster.systems.pipex.net (Postfix) with ESMTP id 12F74E0001F3; Mon, 10 Oct 2005 11:45:16 +0100 (BST) Received: from Puppy ([217.158.145.105] RDNS failed) by dnni.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 10 Oct 2005 11:45:11 +0100 Message-ID: <00f101c5cd88$1957d4c0$f2849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: , "Tom Petch" , "Thomas D. Nadeau" , Cc: References: <3.0.1.32.20050908215948.014706d4@pop.mindspring.com> <11aa01c5bf75$b2750720$28849ed9@Puppy> <027b01c5c564$8fcff820$0500a8c0@jlucianilaptop> <036501c5ca7b$a2c16a60$0601a8c0@pc6> <00c701c5ccc3$ee1db320$f2849ed9@Puppy> <015c01c5cd3d$bbe87500$0500a8c0@jlucianilaptop> Subject: Re: MIB Dr. review of draft-ietf-ccamp-gmpls-te-mib-09.txt Date: Mon, 10 Oct 2005 11:40:38 +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: 10 Oct 2005 10:45:12.0916 (UTC) FILETIME=[B1523140:01C5CD87] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit Hi Joan, > Please add a note as to why the bits are reversed for the managed object. No, no, no, no! :-) I said... > > You are both right. > > We have reversed the order of the bits in the IANA MIB and also filled the > > gap with "reserved" bits. That means we have changed the order from what it used to be to what you have asked for. Thanks, Adrian From owner-ccamp@ops.ietf.org Tue Oct 11 08:52:58 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPJcl-00039J-Vz for ccamp-archive@megatron.ietf.org; Tue, 11 Oct 2005 08:52:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21156 for ; Tue, 11 Oct 2005 08:52:54 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPJmr-0007zg-TZ for ccamp-archive@ietf.org; Tue, 11 Oct 2005 09:03:23 -0400 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EPJOw-000Bbu-6o for ccamp-data@psg.com; Tue, 11 Oct 2005 12:38:38 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [64.102.122.149] (helo=rtp-iport-2.cisco.com) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EPJOv-000Bbd-Ev for ccamp@ops.ietf.org; Tue, 11 Oct 2005 12:38:37 +0000 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 11 Oct 2005 08:38:36 -0400 X-IronPort-AV: i="3.97,198,1125892800"; d="scan'208"; a="73488979:sNHT23061328" Received: from [10.83.15.51] (rtp-tnadeau-vpn2.cisco.com [10.83.15.51]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with SMTP id j9BCcWQm023317; Tue, 11 Oct 2005 08:38:33 -0400 (EDT) In-Reply-To: <00c701c5ccc3$ee1db320$f2849ed9@Puppy> References: <3.0.1.32.20050908215948.014706d4@pop.mindspring.com> <11aa01c5bf75$b2750720$28849ed9@Puppy> <027b01c5c564$8fcff820$0500a8c0@jlucianilaptop> <036501c5ca7b$a2c16a60$0601a8c0@pc6> <00c701c5ccc3$ee1db320$f2849ed9@Puppy> Mime-Version: 1.0 (Apple Message framework v734) X-Priority: 3 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: "Tom Petch" , , Content-Transfer-Encoding: 7bit From: "Thomas D. Nadeau" Subject: Re: MIB Dr. review of draft-ietf-ccamp-gmpls-te-mib-09.txt Date: Tue, 11 Oct 2005 08:38:26 -0400 To: "Adrian Farrel" X-Mailer: Apple Mail (2.734) Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: 7bit Sorry, just getting back to my emails... > Hi Tom, > > >> I am still unsure about MSB/LSB in IANAGmplsAdminStatusFlags. >> This has >> > reflect > >> (31) while RFC3471 has reflect as bit 0. >> >> As Joan says, "The BITS as specified look backwards when viewing the >> > TLV". > >> >> This is fine if one is MSB, the other LSB (although that might be >> worth >> > adding a > >> note about). >> > > You are both right. > We have reversed the order of the bits in the IANA MIB and also > filled the > gap with "reserved" bits. Just a clarification Tom P., we will add a statement to the object explaining what Adrian posted above, which will hopefully allay future questions on the object. --Tom From owner-ccamp@ops.ietf.org Tue Oct 11 15:18:48 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPPeC-0008OB-JT for ccamp-archive@megatron.ietf.org; Tue, 11 Oct 2005 15:18:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23295 for ; Tue, 11 Oct 2005 15:18:46 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPPoM-0005Em-E2 for ccamp-archive@ietf.org; Tue, 11 Oct 2005 15:29:19 -0400 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EPPVg-000GSc-Ef for ccamp-data@psg.com; Tue, 11 Oct 2005 19:10:00 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [171.71.176.71] (helo=sj-iport-2.cisco.com) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EPPVe-000GSF-VE for ccamp@ops.ietf.org; Tue, 11 Oct 2005 19:09:59 +0000 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-2.cisco.com with ESMTP; 11 Oct 2005 12:09:53 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j9BJ9Ev5010715; Tue, 11 Oct 2005 12:09:49 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 11 Oct 2005 12:09:48 -0700 Received: from [10.21.89.137] ([10.21.89.137]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 11 Oct 2005 12:09:46 -0700 Message-ID: <434C0DFA.80102@cisco.com> Date: Tue, 11 Oct 2005 12:09:46 -0700 From: Arun Satyanarayana Organization: Cisco Systems User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Adrian Farrel , Kireeti Kompella CC: ccamp@ops.ietf.org, Lou Berger , Dimitri Papadimitriou , Dimitri Papadimitriou , Anca Zamfir , Reshad Rahman , Junaid Israr , "Arun Satyanarayana (asatyana)" Subject: Re: I-D ACTION:draft-ietf-ccamp-rsvp-restart-ext-04.txt Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Oct 2005 19:09:47.0013 (UTC) FILETIME=[58808B50:01C5CE97] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: bf422c85703d3d847fb014987125ac48 Content-Transfer-Encoding: 7bit Hi Adrian, Kireeti, Following are the mods to version -03, based on last call comments. Can we go through another short last call on this rev please? - Section 2 Terminology: Fix bad text < The reader is assumed to be familiar with the terminology defined in < xref target="RFC3209" /> and [RFC3473]. > The reader is assumed to be familiar with the terminology defined in > [RFC3209] and [RFC3473]. - Section 4.2 Capability Object: Reverse ordering of definitions of T and R bits to match ordering in object - Full I-D: Change "Restart_Caps" to "Restart_Cap" (to match definition in 3473). - Section 4.4.1 Procedures for the Downstream Neighbor Clarify text: the downstream neighbor must send the T-bit in all Hellos < If the downstream RSVP neighbor of a restarting node is capable of < sending RecoveryPath messages to the restarting node, it MUST include < the Capability object with the RecoveryPath Transmit Enabled (T) bit < set (1) in all its Hello messages sent to the restarting node. > If a node is capable of sending RecoveryPath messages, it MUST > include the Capability object with the RecoveryPath Transmit Enabled > (T) bit set (1) in all its Hello messages. - Section 4.4.2 Procedures for the Restarting Node Clarify text: the restarting node must send the R-bit in all Hellos < A restarting node that expects to recover RSVP state by the receipt < and processing of RecoveryPath messages according to procedures < defined in this document, MUST include the Capability object with the < RecoveryPath Desired (R) bit set (1) in its RSVP Hello messages to < its neighbors, during the Recovery Period. The node MUST also < include the Restart_Caps object as defined in [RFC3473], in all those < Hello messages. > A node that expects to recover RSVP state by the receipt and > processing of RecoveryPath messages according to procedures defined > in this document, MUST include the Capability object with the > RecoveryPath Desired (R) bit set (1) in its RSVP Hello messages to > its neighbors. The node MUST also include the Restart_Cap object as > defined in [RFC3473], in all those Hello messages. - Section 4.5.2 Procedures for the Restarting Node Change response to received RecoveryPath messages outside the Recovery Period: < These procedures apply during the "state recovery process" and < "Recovery Period" as defined in Section 9.5.2 in [RFC3473]. Any < RecoveryPath message received after the Recovery Period has expired < MUST be discarded. If no LSP state matching the RecoveryPath message < is located, the restarted node MAY send a PathTear message < constructed from the RecoveryPath message, to expedite the cleanup of < unrecovered RSVP and associated forwarding state downstream of the < restarted node. > These procedures apply during the "state recovery process" and > "Recovery Period" as defined in Section 9.5.2 in [RFC3473]. Any > RecoveryPath message received after the Recovery Period has expired > SHOULD be matched against local LSP state. If matching fully > resynchronized state is located, the node SHOULD send a Path message > downstream. If non-resynchronized or no LSP state matching the > RecoveryPath message is located, the restarted node MAY send a > PathTear message constructed from the RecoveryPath message, to > expedite the cleanup of unrecovered RSVP and associated forwarding > state downstream of the restarted node. - Section 5.2.1 Procedures (Srefresh mechanism), clarify text: the restarting node must send the R-bit in all Hellos < To indicate to an RSVP neighbor that selective transmission of < RecoveryPath messages is desired, a restarting node MUST set (1) the < S-bit in the Capability object in all Hello messages it sends during < the Recovery Period to the neighbor. When the restarting node does > To indicate to an RSVP neighbor that selective transmission of > RecoveryPath messages is desired, a node MUST set (1) the S-bit in > the Capability object in all Hello messages it sends. When the - Section 7. Acknowledgments Add Pavan Beeram. - Section 8. IANA Considerations Suggest values for the RecoveryPath msg and the Capability object < A new RSVP object using a Class-Number of form 10bbbbbb called the < Capability Object is defined in Section 4.2 in this document. The < Class-Number is TBA by IANA. > A new RSVP object using a Class-Number of form 10bbbbbb called the > Capability Object is defined in Section 4.2 in this document. The > Class-Number is TBA by IANA. A value of 132 is suggested. < A new RSVP message type called a RecoveryPath message is defined in < Section 4.1 of this document. The RSVP message type is TBA by IANA. > A new RSVP message type called a RecoveryPath message is defined in > Section 4.1 of this document. The RSVP message type is TBA by IANA. > A value of 30 is suggested. - Section 8. IANA Considerations Fix typo in the bit names < +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ < | |S|P|R| < +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | |T|R|S| > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Thanks, Arun (and co-authors) ============================================================== -------- Original Message -------- Subject: I-D ACTION:draft-ietf-ccamp-rsvp-restart-ext-04.txt Date: Mon, 03 Oct 2005 15:50:02 -0400 From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org CC: ccamp@ops.ietf.org 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 GMPLS RSVP Graceful Restart Author(s) : A. Satyanarayana, et al. Filename : draft-ietf-ccamp-rsvp-restart-ext-04.txt Pages : 24 Date : 2005-10-3 This document describes extensions to the RSVP Graceful Restart mechanisms defined in RFC 3473. The extensions enable the recovery of RSVP signaling state based on the Path message last sent by the node being restarted. Previously defined Graceful Restart mechanisms, also called recovery from nodal faults, permit recovery of signaling state from adjacent nodes when the data plane has retained the associated forwarding state across a restart. These mechanisms do not fully support signaling state recovery on ingress nodes or recovery of all RSVP objects. The presented extensions use the RSVP Hello extensions defined in RFC 3209, and extensions for state recovery on nodal faults defined in RFC 3473. With the presented extensions the restarting node can recover all previously transmitted Path state including the Explicit Route Object and the downstream (outgoing) interface identifiers. The extensions can also be used to recover signaling state after the restart of an ingress node. The extensions optionally support the use of Summary Refresh, defined in RFC 2961, to reduce the number of messages exchanged during the Recovery Phase when the restarting node has recovered signaling state locally for one or more LSPs. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rsvp-restart-ext-04.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-rsvp-restart-ext-04.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-rsvp-restart-ext-04.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. From owner-ccamp@ops.ietf.org Tue Oct 11 15:53:06 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPQBO-0002Oz-9f for ccamp-archive@megatron.ietf.org; Tue, 11 Oct 2005 15:53:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25779 for ; Tue, 11 Oct 2005 15:53:03 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPQLY-0006Z6-24 for ccamp-archive@ietf.org; Tue, 11 Oct 2005 16:03:36 -0400 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EPQ4p-000JQe-0T for ccamp-data@psg.com; Tue, 11 Oct 2005 19:46:19 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.0 Received: from [62.241.163.6] (helo=astro.systems.pipex.net) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EPQ4n-000JQF-2d for ccamp@ops.ietf.org; Tue, 11 Oct 2005 19:46:17 +0000 Received: from dnni.com (81-178-2-190.dsl.pipex.com [81.178.2.190]) by astro.systems.pipex.net (Postfix) with ESMTP id 1FD17E0000DF; Tue, 11 Oct 2005 20:46:04 +0100 (BST) Received: from Puppy ([217.158.132.232] RDNS failed) by dnni.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 11 Oct 2005 20:45:57 +0100 Message-ID: <295c01c5ce9c$d0ac9b00$f2849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Cc: "Lou Berger" , "Dimitri Papadimitriou" , "Dimitri Papadimitriou" , "Anca Zamfir" , "Reshad Rahman" , "Junaid Israr" , "Arun Satyanarayana \(asatyana\)" , "Kireeti Kompella" References: <434C0DFA.80102@cisco.com> Subject: Further Working Group last call: draft-ietf-ccamp-rsvp-restart-ext-04.txt Date: Tue, 11 Oct 2005 20:48:44 +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: 11 Oct 2005 19:45:59.0315 (UTC) FILETIME=[674B8630:01C5CE9C] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 325b777e1a3a618c889460b612a65510 Content-Transfer-Encoding: 7bit Thanks for the note Arun, It looks to me that while most of these changes are editorial, the change to 4.5.2 is substantive. Therefore we will have a further short WG last call. The last call will complete on Wednesday 19th October at 12 noon GMT. Send your comments to the list please. Thanks, Adrian ----- Original Message ----- From: "Arun Satyanarayana" To: "Adrian Farrel" ; "Kireeti Kompella" Cc: ; "Lou Berger" ; "Dimitri Papadimitriou" ; "Dimitri Papadimitriou" ; "Anca Zamfir" ; "Reshad Rahman" ; "Junaid Israr" ; "Arun Satyanarayana (asatyana)" Sent: Tuesday, October 11, 2005 8:09 PM Subject: Re: I-D ACTION:draft-ietf-ccamp-rsvp-restart-ext-04.txt > Hi Adrian, Kireeti, > > Following are the mods to version -03, based on last call comments. Can > we go through another short last call on this rev please? > > - Section 2 Terminology: > Fix bad text > < The reader is assumed to be familiar with the terminology defined in > < xref target="RFC3209" /> and [RFC3473]. > > The reader is assumed to be familiar with the terminology defined in > > [RFC3209] and [RFC3473]. > > - Section 4.2 Capability Object: > Reverse ordering of definitions of T and R bits to match ordering in > object > > - Full I-D: > Change "Restart_Caps" to "Restart_Cap" (to match definition in 3473). > > - Section 4.4.1 Procedures for the Downstream Neighbor > Clarify text: the downstream neighbor must send the T-bit in all > Hellos > < If the downstream RSVP neighbor of a restarting node is capable of > < sending RecoveryPath messages to the restarting node, it MUST > include > < the Capability object with the RecoveryPath Transmit Enabled (T) bit > < set (1) in all its Hello messages sent to the restarting node. > > If a node is capable of sending RecoveryPath messages, it MUST > > include the Capability object with the RecoveryPath Transmit Enabled > > (T) bit set (1) in all its Hello messages. > > - Section 4.4.2 Procedures for the Restarting Node > Clarify text: the restarting node must send the R-bit in all Hellos > < A restarting node that expects to recover RSVP state by the receipt > < and processing of RecoveryPath messages according to procedures > < defined in this document, MUST include the Capability object with the > < RecoveryPath Desired (R) bit set (1) in its RSVP Hello messages to > < its neighbors, during the Recovery Period. The node MUST also > < include the Restart_Caps object as defined in [RFC3473], in all those > < Hello messages. > > A node that expects to recover RSVP state by the receipt and > > processing of RecoveryPath messages according to procedures defined > > in this document, MUST include the Capability object with the > > RecoveryPath Desired (R) bit set (1) in its RSVP Hello messages to > > its neighbors. The node MUST also include the Restart_Cap object as > > defined in [RFC3473], in all those Hello messages. > > - Section 4.5.2 Procedures for the Restarting Node > Change response to received RecoveryPath messages outside the Recovery > Period: > < These procedures apply during the "state recovery process" and > < "Recovery Period" as defined in Section 9.5.2 in [RFC3473]. Any > < RecoveryPath message received after the Recovery Period has expired > < MUST be discarded. If no LSP state matching the RecoveryPath message > < is located, the restarted node MAY send a PathTear message > < constructed from the RecoveryPath message, to expedite the cleanup of > < unrecovered RSVP and associated forwarding state downstream of the > < restarted node. > > These procedures apply during the "state recovery process" and > > "Recovery Period" as defined in Section 9.5.2 in [RFC3473]. Any > > RecoveryPath message received after the Recovery Period has expired > > SHOULD be matched against local LSP state. If matching fully > > resynchronized state is located, the node SHOULD send a Path message > > downstream. If non-resynchronized or no LSP state matching the > > RecoveryPath message is located, the restarted node MAY send a > > PathTear message constructed from the RecoveryPath message, to > > expedite the cleanup of unrecovered RSVP and associated forwarding > > state downstream of the restarted node. > > - Section 5.2.1 Procedures > (Srefresh mechanism), clarify text: the restarting node must send > the R-bit in all Hellos > < To indicate to an RSVP neighbor that selective transmission of > < RecoveryPath messages is desired, a restarting node MUST set (1) the > < S-bit in the Capability object in all Hello messages it sends during > < the Recovery Period to the neighbor. When the restarting node does > > To indicate to an RSVP neighbor that selective transmission of > > RecoveryPath messages is desired, a node MUST set (1) the S-bit in > > the Capability object in all Hello messages it sends. When the > > - Section 7. Acknowledgments > Add Pavan Beeram. > > - Section 8. IANA Considerations > Suggest values for the RecoveryPath msg and the Capability object > < A new RSVP object using a Class-Number of form 10bbbbbb called the > < Capability Object is defined in Section 4.2 in this document. The > < Class-Number is TBA by IANA. > > A new RSVP object using a Class-Number of form 10bbbbbb called the > > Capability Object is defined in Section 4.2 in this document. The > > Class-Number is TBA by IANA. A value of 132 is suggested. > > < A new RSVP message type called a RecoveryPath message is defined in > < Section 4.1 of this document. The RSVP message type is TBA by IANA. > > A new RSVP message type called a RecoveryPath message is defined in > > Section 4.1 of this document. The RSVP message type is TBA by IANA. > > A value of 30 is suggested. > > - Section 8. IANA Considerations > Fix typo in the bit names > < +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > < | |S|P|R| > < +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | |T|R|S| > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Thanks, > Arun (and co-authors) > ============================================================== > -------- Original Message -------- > Subject: I-D ACTION:draft-ietf-ccamp-rsvp-restart-ext-04.txt > Date: Mon, 03 Oct 2005 15:50:02 -0400 > From: Internet-Drafts@ietf.org > To: i-d-announce@ietf.org > CC: ccamp@ops.ietf.org > > 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 GMPLS RSVP Graceful Restart > Author(s) : A. Satyanarayana, et al. > Filename : draft-ietf-ccamp-rsvp-restart-ext-04.txt > Pages : 24 > Date : 2005-10-3 > > This document describes extensions to the RSVP Graceful Restart > mechanisms defined in RFC 3473. The extensions enable the recovery > of RSVP signaling state based on the Path message last sent by the > node being restarted. Previously defined Graceful Restart > mechanisms, also called recovery from nodal faults, permit recovery > of signaling state from adjacent nodes when the data plane has > retained the associated forwarding state across a restart. These > mechanisms do not fully support signaling state recovery on ingress > nodes or recovery of all RSVP objects. The presented extensions use > the RSVP Hello extensions defined in RFC 3209, and extensions for > state recovery on nodal faults defined in RFC 3473. With the > presented extensions the restarting node can recover all previously > transmitted Path state including the Explicit Route Object and the > downstream (outgoing) interface identifiers. The extensions can also > be used to recover signaling state after the restart of an ingress > node. The extensions optionally support the use of Summary Refresh, > defined in RFC 2961, to reduce the number of messages exchanged > during the Recovery Phase when the restarting node has recovered > signaling state locally for one or more LSPs. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rsvp-restart-ext-04.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-rsvp-restart-ext-04.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-rsvp-restart-ext-04.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. > > > From owner-ccamp@ops.ietf.org Wed Oct 12 15:59:09 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPmkn-0006DN-0e for ccamp-archive@megatron.ietf.org; Wed, 12 Oct 2005 15:59:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16801 for ; Wed, 12 Oct 2005 15:59:05 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPmv6-0006R5-I8 for ccamp-archive@ietf.org; Wed, 12 Oct 2005 16:09:50 -0400 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EPmc4-0007eE-4S for ccamp-data@psg.com; Wed, 12 Oct 2005 19:50:08 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=3.1.0 Received: from [132.151.6.50] (helo=newodin.ietf.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1EPmc3-0007dx-FU for ccamp@ops.ietf.org; Wed, 12 Oct 2005 19:50:07 +0000 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EPmby-0000XR-1F; Wed, 12 Oct 2005 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-10.txt Message-Id: Date: Wed, 12 Oct 2005 15:50:02 -0400 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.4 (/) 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, et al. Filename : draft-ietf-ccamp-gmpls-te-mib-10.txt Pages : 61 Date : 2005-10-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-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-te-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-te-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: <2005-10-12121307.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-gmpls-te-mib-10.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-gmpls-te-mib-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-10-12121307.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ccamp@ops.ietf.org Wed Oct 12 16:31:16 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPnFs-0001im-IC for ccamp-archive@megatron.ietf.org; Wed, 12 Oct 2005 16:31:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00760 for ; Wed, 12 Oct 2005 16:31:13 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPnQF-0003Fr-4F for ccamp-archive@ietf.org; Wed, 12 Oct 2005 16:42:00 -0400 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EPnBn-000Azn-0u for ccamp-data@psg.com; Wed, 12 Oct 2005 20:27:03 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.0 Received: from [62.241.162.31] (helo=galaxy.systems.pipex.net) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EPnBm-000Azb-5p for ccamp@ops.ietf.org; Wed, 12 Oct 2005 20:27:02 +0000 Received: from dnni.com (81-178-2-190.dsl.pipex.com [81.178.2.190]) by galaxy.systems.pipex.net (Postfix) with ESMTP id 5680BE000279 for ; Wed, 12 Oct 2005 21:26:54 +0100 (BST) Received: from Puppy ([217.158.132.178] RDNS failed) by dnni.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 12 Oct 2005 21:21:37 +0100 Message-ID: <2d3501c5cf6a$f7c987b0$f2849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Agenda slot requests for Vancouver Date: Wed, 12 Oct 2005 20:09:22 +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 Oct 2005 20:21:38.0247 (UTC) FILETIME=[8C9C6570:01C5CF6A] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7bit Hi, I know I am going to regret this, but... Please send me your requests to go on the agenda in Vancouver. Given the positive and encouraging feedback that our AD gave us in Paris, I would like to try to limit our work to issues and items that will benefit from face to face discussion. Thus, presentation of status (this is the 37th revision of our I-D, we hope to be finished in early 2012, we have made 209 small and insignificant typographical changes) will be frowned upon. Similarly, presentation of the content of I-Ds will not be welcome except where this is a new I-D and the content is interesting ;-) What I would really like is: - problem statements and requests for discussion of solutions - suggested solutions where the authors are not sure and want feedback In other words, I would like presenters to be actively soliciting input from the meeting. If you don't need input from the meeting, then you don't need to stand up at the front of the room. Anyway, over to you guys. Thanks, Adrian From owner-ccamp@ops.ietf.org Wed Oct 12 16:43:28 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPnRe-0005IC-T2 for ccamp-archive@megatron.ietf.org; Wed, 12 Oct 2005 16:43:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04237 for ; Wed, 12 Oct 2005 16:43:23 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPnc0-0004Z2-QU for ccamp-archive@ietf.org; Wed, 12 Oct 2005 16:54:10 -0400 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EPnNY-000CYQ-Ho for ccamp-data@psg.com; Wed, 12 Oct 2005 20:39:12 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.0 Received: from [62.241.162.31] (helo=galaxy.systems.pipex.net) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EPnNX-000CY6-GW for ccamp@ops.ietf.org; Wed, 12 Oct 2005 20:39:11 +0000 Received: from dnni.com (81-178-2-190.dsl.pipex.com [81.178.2.190]) by galaxy.systems.pipex.net (Postfix) with ESMTP id 58378E000257; Wed, 12 Oct 2005 21:39:10 +0100 (BST) Received: from Puppy ([217.158.132.178] RDNS failed) by dnni.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 12 Oct 2005 21:38:51 +0100 Message-ID: <2d5c01c5cf6d$601f0e00$f2849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Cc: "Thomas D. Nadeau" References: Subject: New versions of GMPLS MIBs Date: Wed, 12 Oct 2005 21:41:46 +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 Oct 2005 20:38:52.0693 (UTC) FILETIME=[F5305450:01C5CF6C] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Content-Transfer-Encoding: 7bit Hi, We have been working on the GMPLS MIBs after MIB Doctor comments. The revisions just being posted have addressed all of the nits and editorial issues except: - conformance/compliance - lint - compilation Tom has just been working on these issues and the ball is now back with me to integrate his changes and republish. I hope to do this in the next couple of days. In the mean time, if you have any comments on the revised versions then please let us know. Cheers, Adrian ----- Original Message ----- From: To: Cc: Sent: Wednesday, October 12, 2005 8:50 PM Subject: I-D ACTION:draft-ietf-ccamp-gmpls-te-mib-10.txt > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. > > Title : Generalized Multiprotocol Label Switching > (GMPLS) Traffic Engineering Management Information Base > Author(s) : T. Nadeau, et al. > Filename : draft-ietf-ccamp-gmpls-te-mib-10.txt > Pages : 61 > Date : 2005-10-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-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-te-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-te-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. > -------------------------------------------------------------------------- ------ > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/i-d-announce > From owner-ccamp@ops.ietf.org Wed Oct 12 21:42:26 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPs6z-00016M-W4 for ccamp-archive@megatron.ietf.org; Wed, 12 Oct 2005 21:42:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16609 for ; Wed, 12 Oct 2005 21:42:23 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPsHI-0002pa-TS for ccamp-archive@ietf.org; Wed, 12 Oct 2005 21:53:12 -0400 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EPrz9-000AYp-AE for ccamp-data@psg.com; Thu, 13 Oct 2005 01:34:19 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [192.240.0.5] (helo=fujitsu0.fujitsu.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1EPrz8-000AYa-1Q for ccamp@ops.ietf.org; Thu, 13 Oct 2005 01:34:18 +0000 Received: from fujitsu0.fujitsu.com (localhost [127.0.0.1]) by fujitsu0.fujitsu.com (8.13.1/8.13.1) with ESMTP id j9D1YFGa010291 for ; Wed, 12 Oct 2005 18:34:15 -0700 (PDT) Received: from fujitsuii.fna.fujitsu.com ([133.164.253.2]) by fujitsu0.fujitsu.com (8.13.1/8.13.1) with ESMTP id j9D1YExY010288 for ; Wed, 12 Oct 2005 18:34:14 -0700 (PDT) Received: from mailserv.fla.fujitsu.com (localhost [127.0.0.1]) by fujitsuii.fna.fujitsu.com (8.13.2/8.13.2) with ESMTP id j9D1YEqP014325; Wed, 12 Oct 2005 18:34:14 -0700 (PDT) Received: from [133.164.61.82] (localhost [127.0.0.1]) by mailserv.fla.fujitsu.com (8.11.6/8.11.6) with ESMTP id j9D1YDW20587; Wed, 12 Oct 2005 18:34:13 -0700 (PDT) Message-ID: <434DB995.5090301@us.fujitsu.com> Date: Wed, 12 Oct 2005 18:34:13 -0700 From: Richard Rabbat Organization: Fujitsu Labs of America User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ccamp@ops.ietf.org CC: "Shiba, Sidney" , Richard Rabbat Subject: draft announcement: draft-shiba-ccamp-gmpls-lambda-labels-00.txt Content-Type: multipart/mixed; boundary="------------030704080901000402020100" Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c This is a multi-part message in MIME format. --------------030704080901000402020100 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear all, we have submitted the following draft for consideration by the CCAMP WG. http://www.ietf.org/internet-drafts/draft-shiba-ccamp-gmpls-lambda-labels-00.txt Subject: I-D ACTION:draft-shiba-ccamp-gmpls-lambda-labels-00.txt Date: 2005-10-07 19:50:02 GMT (5 days, 1 hour and 21 minutes ago) A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Generalized Labels of Lambda-Switching Capable Label Switching Routers (LSR)s Author(s) : S. Shiba, R. Rabbat Filename : draft-shiba-ccamp-gmpls-lambda-labels-00.txt Pages : 10 Date : 2005-10-7 Technology in the optical domain is constantly evolving and as a consequence equipment providing true lambda switching capability has been developed and is currently being deployed. [RFC3471] has defined that a wavelength label (section 3.2.1.1) "only has significance between two neighbors". However, in a network composed of "true" lambda switch capable equipments, the label should have global meaning similarly to the label defined for SONET/SDH technology (SUKLM format defined in [RFC3946]). This document is a companion to the Generalized Multi-Protocol Label Switching (GMPLS) signaling. It defines the Label Switching Capable (LSC) technology specific information needed when using GMPLS. -- We look forward to feedback from ccamp members. Specifically, is the problem statement well posed? Is this a topic that CCAMP would like to address? Richard & Sidney. --------------030704080901000402020100 Content-Type: text/x-vcard; charset=utf-8; name="richard.vcf" Content-Disposition: attachment; filename="richard.vcf" Content-Transfer-Encoding: 7bit begin:vcard fn:Richard Rabbat n:Rabbat;Richard org:Fujitsu Labs of America;IP Networking Research 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 --------------030704080901000402020100-- From owner-ccamp@ops.ietf.org Wed Oct 12 22:10:09 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPsXp-0000WK-03 for ccamp-archive@megatron.ietf.org; Wed, 12 Oct 2005 22:10:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17553 for ; Wed, 12 Oct 2005 22:10:06 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPsi9-0003Mk-CA for ccamp-archive@ietf.org; Wed, 12 Oct 2005 22:20:55 -0400 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EPsU0-000DMp-It for ccamp-data@psg.com; Thu, 13 Oct 2005 02:06:12 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [66.226.64.2] (helo=pro.abac.com) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EPsTx-000DMS-Qc for ccamp@ops.ietf.org; Thu, 13 Oct 2005 02:06:09 +0000 Received: from [192.168.0.105] (c-67-164-6-194.hsd1.ca.comcast.net [67.164.6.194]) (authenticated bits=0) by pro.abac.com (8.13.4/8.13.4) with ESMTP id j9D260o1083822 for ; Wed, 12 Oct 2005 19:06:02 -0700 (PDT) (envelope-from gregb@grotto-networking.com) Message-ID: <434DC106.1040906@grotto-networking.com> Date: Wed, 12 Oct 2005 19:05:58 -0700 From: Greg Bernstein User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ccamp@ops.ietf.org Subject: VCAT/LCAS draft update: draft-bernstein-ccamp-gmpls-vcat-lcas-01 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.1 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit Folks the latest, significantly shortened version of the VCAT/LCAS GMPLS draft is now available at: http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-gmpls-vcat-lcas-01.txt This draft points out how GMPLS and VCAT/LCAS get along and how they might play nicer together. We'll be proposing something along these lines getting adopted as a workgroup item at the Vancouver meeting. Regards Greg B. --------------------- Dr. Greg Bernstein, Grotto Networking From owner-ccamp@ops.ietf.org Thu Oct 13 15:58:44 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ9Dw-0004pL-Tm for ccamp-archive@megatron.ietf.org; Thu, 13 Oct 2005 15:58:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09479 for ; Thu, 13 Oct 2005 15:58:41 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQ9OW-0006AO-LY for ccamp-archive@ietf.org; Thu, 13 Oct 2005 16:09:41 -0400 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EQ95g-0006a6-7Y for ccamp-data@psg.com; Thu, 13 Oct 2005 19:50:12 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=3.1.0 Received: from [132.151.6.50] (helo=newodin.ietf.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1EQ95f-0006Zp-JP for ccamp@ops.ietf.org; Thu, 13 Oct 2005 19:50:11 +0000 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EQ95V-0004mL-Gq; Thu, 13 Oct 2005 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-08.txt Message-Id: Date: Thu, 13 Oct 2005 15:50:01 -0400 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.4 (/) 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, et al. Filename : draft-ietf-ccamp-gmpls-tc-mib-08.txt Pages : 9 Date : 2005-10-13 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-08.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-08.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-08.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: <2005-10-13142503.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-gmpls-tc-mib-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-gmpls-tc-mib-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-10-13142503.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ccamp@ops.ietf.org Thu Oct 13 15:58:46 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ9Dy-0004pX-7c for ccamp-archive@megatron.ietf.org; Thu, 13 Oct 2005 15:58:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09485 for ; Thu, 13 Oct 2005 15:58:42 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQ9OY-0006AZ-34 for ccamp-archive@ietf.org; Thu, 13 Oct 2005 16:09:42 -0400 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EQ95a-0006Z1-83 for ccamp-data@psg.com; Thu, 13 Oct 2005 19:50:06 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=3.1.0 Received: from [132.151.6.50] (helo=newodin.ietf.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1EQ95Z-0006Yc-JF for ccamp@ops.ietf.org; Thu, 13 Oct 2005 19:50:05 +0000 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EQ95V-0004mT-Ir; Thu, 13 Oct 2005 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-09.txt Message-Id: Date: Thu, 13 Oct 2005 15:50:01 -0400 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.4 (/) 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 : Generalized Multiprotocol Label Switching (GMPLS) Label Switching Router (LSR) Management Information Base Author(s) : T. Nadeau, et al. Filename : draft-ietf-ccamp-gmpls-lsr-mib-09.txt Pages : 43 Date : 2005-10-13 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-09.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-09.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-09.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: <2005-10-13144205.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-gmpls-lsr-mib-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-gmpls-lsr-mib-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-10-13144205.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ccamp@ops.ietf.org Thu Oct 13 16:50:22 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQA1t-0003Gh-SV for ccamp-archive@megatron.ietf.org; Thu, 13 Oct 2005 16:50:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16482 for ; Thu, 13 Oct 2005 16:50:18 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQACT-0000dF-SD for ccamp-archive@ietf.org; Thu, 13 Oct 2005 17:01:18 -0400 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EQ9uV-000Cpn-5X for ccamp-data@psg.com; Thu, 13 Oct 2005 20:42:43 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00, DATE_IN_PAST_03_06 autolearn=ham version=3.1.0 Received: from [62.241.163.7] (helo=blaster.systems.pipex.net) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EQ9uT-000CpK-GR for ccamp@ops.ietf.org; Thu, 13 Oct 2005 20:42:41 +0000 Received: from pc6 (1Cust48.tnt101.lnd4.gbr.da.uu.net [213.116.50.48]) by blaster.systems.pipex.net (Postfix) with SMTP id 3D961E00032C; Thu, 13 Oct 2005 21:42:35 +0100 (BST) Message-ID: <067a01c5d02e$24fc1360$0601a8c0@pc6> Reply-To: "Tom Petch" From: "Tom Petch" To: "Adrian Farrel" , Cc: "Thomas D. Nadeau" References: <2d5c01c5cf6d$601f0e00$f2849ed9@Puppy> Subject: IANA-GMPLS-TC-MIB was New versions of GMPLS MIBs Date: Thu, 13 Oct 2005 17:50:51 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.8 (/) X-Scan-Signature: 7e439b86d3292ef5adf93b694a43a576 Content-Transfer-Encoding: 7bit Adrian I am still uncomfortable with the apparent lack of constraints for the allocation of new values in IANA-GMPLS-TC-MIB. There is now "The rules for additions or changes to the IANA-GMPLS-TC-MIB are outlined in the DESCRIPTION clause associated with its MODULE-IDENTITY statement." but I do not see anything about this in the DESCRIPTION clause. Rather, it is the DESCRIPTION clauses of individual TCs that contain the information, e.g. "This textual convention is strongly tied to the Switching Types sub-registry of the GMPLS Signaling Parameters registry managed by IANA. Values should be assigned by IANA in step with the Switching Types sub-registry and using the same registry management rules. However, the actual values used in this textual convention are solely within the purview of IANA and do not necessarily match the values in the values in the Switching Types sub-registry. Requests for new values should be made to IANA via email (iana@isi.edu)." . It is that "However ..." that bugs me; coupled with the final sentence, I still see an e-mail from anyone in any SDO or elsewhere causing IANA to allocate a new value regardless of on-going work in the IETF. Perhaps unlikely given the close-knit world of GMPLS but I would still like to see tighter control, Expert Review would be my choice. But I am also unclear what change control was intended by the wording in the latest draft. As with my my earlier e-mail, "Somewhat bigger issue; I am concerned that no constraint is placed on the allocation by IANA of new values in the IANA MIB module, where the base documents call for more stringent action (although there is some disagreement as to what that is). As it stands, it seems to me that anyone in the world can e-mail IANA and get a new value assigned in the IANA MIB module, whereas I think it should be the appearance of an RFC, eg draft-ietf-ccamp-gmpls-routing or draft-ietf-ccamp-ospf-gmpls-extensions, which triggers that action, perhaps by Expert Review ie the existence of a new name/number mapping is documented in an RFC or I-D and Expert Review allows that mapping to be added to IANA MIB module. We could require the RFC that introduces a new mapping to have an IANA section that updates the MIB module but I fear that most editors would forget to include it, so Expert Review seems best. Tom Petch ----- Original Message ----- From: "Adrian Farrel" To: Cc: "Thomas D. Nadeau" Sent: Wednesday, October 12, 2005 10:41 PM Subject: New versions of GMPLS MIBs > Hi, > > We have been working on the GMPLS MIBs after MIB Doctor comments. > The revisions just being posted have addressed all of the nits and > editorial issues except: > > - conformance/compliance > - lint > - compilation > > Tom has just been working on these issues and the ball is now back with me > to integrate his changes and republish. I hope to do this in the next > couple of days. > > In the mean time, if you have any comments on the revised versions then > please let us know. > > Cheers, > Adrian > > > ----- Original Message ----- > From: > To: > Cc: > Sent: Wednesday, October 12, 2005 8:50 PM > Subject: I-D ACTION:draft-ietf-ccamp-gmpls-te-mib-10.txt > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > This draft is a work item of the Common Control and Measurement Plane > Working Group of the IETF. > > > > Title : Generalized Multiprotocol Label Switching > > (GMPLS) Traffic Engineering Management > Information Base > > Author(s) : T. Nadeau, et al. > > Filename : draft-ietf-ccamp-gmpls-te-mib-10.txt > > Pages : 61 > > Date : 2005-10-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-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-te-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-te-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. > > > > > -------------------------------------------------------------------------- > ------ > > > > _______________________________________________ > > I-D-Announce mailing list > > I-D-Announce@ietf.org > > https://www1.ietf.org/mailman/listinfo/i-d-announce > > > > From owner-ccamp@ops.ietf.org Fri Oct 14 03:21:00 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQJsC-0003cF-2b for ccamp-archive@megatron.ietf.org; Fri, 14 Oct 2005 03:21:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22581 for ; Fri, 14 Oct 2005 03:20:54 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQK2e-0002Cd-KN for ccamp-archive@ietf.org; Fri, 14 Oct 2005 03:32:02 -0400 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EQJgO-0000CC-NH for ccamp-data@psg.com; Fri, 14 Oct 2005 07:08:48 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO, HTML_40_50,HTML_MESSAGE autolearn=ham version=3.1.0 Received: from [62.241.162.31] (helo=galaxy.systems.pipex.net) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EQJgM-0000Bq-5s for ccamp@ops.ietf.org; Fri, 14 Oct 2005 07:08:47 +0000 Received: from dnni.com (81-178-2-190.dsl.pipex.com [81.178.2.190]) by galaxy.systems.pipex.net (Postfix) with ESMTP id 01589E0001CB; Fri, 14 Oct 2005 01:55:15 +0100 (BST) Received: from Puppy ([66.255.177.98] RDNS failed) by dnni.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 14 Oct 2005 01:52:00 +0100 Message-ID: <027801c5d059$e5117340$230ca8c0@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Tom Petch" , Cc: "Thomas D. Nadeau" References: <2d5c01c5cf6d$601f0e00$f2849ed9@Puppy> <067a01c5d02e$24fc1360$0601a8c0@pc6> Subject: Re: IANA-GMPLS-TC-MIB was New versions of GMPLS MIBs Date: Fri, 14 Oct 2005 01:54:47 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0275_01C5D062.41B090B0" 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 Oct 2005 00:52:00.0184 (UTC) FILETIME=[7C0D4B80:01C5D059] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.5 (/) X-Scan-Signature: a89bc6ca33b14646e47592488f7eaef6 This is a multi-part message in MIME format. ------=_NextPart_000_0275_01C5D062.41B090B0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Tom, OK, I think I understand your concerns better now. Would your issue be solved by the inclusion of a statement like... Values of IANAGmplsSwitchingType are reserved for switching types that correspond to entries in the=20 Switching Types sub-registry of the GMPLS Signaling Parameters registry managed by IANA. Since that registry is controlled by allocation policies already agreed = by IETF consensus, this text would ensure that new allocations within = the textual convention would be equally controlled. I want to retain the "However, the actual values..." text because I do = not want to force the values used in the textual conventions to match = the values used in the protocol elements. For example, if the relevant = working group decided to assign widely discontiguous values for a = protocol field, I would not want to force the IANA to use those = identical values in the textual convention. It would be adequate that = they assigned values that corresponded but were not equal. A concrete example is provided by IANAGmplsSwitchingType. This takes = values to correspond to the GMPLS switching types, but these have values = in the IANA registry of 1, 2, 3, 4, 51, 100, 150, 200. The IANA may = consider that it is inappropriate to assign enumerations in a TC that = are discontiguous, and could assign values 0 through 8 rather than those = suggested in the draft. You are correct that the text in section 11.2 is broken and should point = to the description clauses of the individual TCs. Thanks for catching = this. Question: does all this address your concerns? Note: We have just submitted new revisions of the MIB modules to fix = compilation issues, and those revisions do not attempt to address this = issue. Cheers, Adrian > I am still uncomfortable with the apparent lack of constraints for the > allocation of new values in IANA-GMPLS-TC-MIB. There is now >=20 > "The rules for additions or changes to the IANA-GMPLS-TC-MIB are > outlined in the DESCRIPTION clause associated with its > MODULE-IDENTITY statement." >=20 > but I do not see anything about this in the DESCRIPTION clause. = Rather, it is > the DESCRIPTION clauses of individual TCs that contain the = information, e.g. >=20 > "This textual convention is strongly tied to the Switching > Types sub-registry of the GMPLS Signaling Parameters > registry managed by IANA. Values should be assigned by = IANA > in step with the Switching Types sub-registry and using = the > same registry management rules. However, the actual = values > used in this textual convention are solely within the > purview of IANA and do not necessarily match the values = in > the values in the Switching Types sub-registry. > > Requests for new values should be made to IANA via > email (iana@isi.edu)." > . > It is that "However ..." that bugs me; coupled with the final = sentence, I still > see an e-mail from anyone in any SDO or elsewhere causing IANA to = allocate a new > value regardless of on-going work in the IETF. Perhaps unlikely given = the > close-knit world of GMPLS but I would still like to see tighter = control, Expert > Review would be my choice. >=20 > But I am also unclear what change control was intended by the wording = in the > latest draft. >=20 > As with my my earlier e-mail, >=20 > "Somewhat bigger issue; I am concerned that no constraint is placed on = the > allocation by IANA of new values in the IANA MIB module, where the = base > documents call for more stringent action (although there is some = disagreement as > to what that is). As it stands, it seems to me that anyone in the = world can > e-mail IANA and get a new value assigned in the IANA MIB module, = whereas I think > it should be the appearance of an RFC, eg = draft-ietf-ccamp-gmpls-routing or > draft-ietf-ccamp-ospf-gmpls-extensions, which triggers that action, = perhaps by > Expert Review ie the existence of a new name/number mapping is = documented in an > RFC or I-D and Expert Review allows that mapping to be added to IANA = MIB module. > We could require the RFC that introduces a new mapping to have an IANA = section > that updates the MIB module but I fear that most editors would forget = to include > it, so Expert Review seems best. >=20 >=20 > Tom Petch >=20 > ----- Original Message ----- > From: "Adrian Farrel" > To: > Cc: "Thomas D. Nadeau" > Sent: Wednesday, October 12, 2005 10:41 PM > Subject: New versions of GMPLS MIBs >=20 >=20 > > Hi, > > > > We have been working on the GMPLS MIBs after MIB Doctor comments. > > The revisions just being posted have addressed all of the nits and > > editorial issues except: > > > > - conformance/compliance > > - lint > > - compilation > > > > Tom has just been working on these issues and the ball is now back = with me > > to integrate his changes and republish. I hope to do this in the = next > > couple of days. > > > > In the mean time, if you have any comments on the revised versions = then > > please let us know. > > > > Cheers, > > Adrian > > > > > > ----- Original Message ----- > > From: > > To: > > Cc: > > Sent: Wednesday, October 12, 2005 8:50 PM > > Subject: I-D ACTION:draft-ietf-ccamp-gmpls-te-mib-10.txt > > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > > This draft is a work item of the Common Control and Measurement = Plane > > Working Group of the IETF. > > > > > > Title : Generalized Multiprotocol Label Switching > > > (GMPLS) Traffic Engineering Management > > Information Base > > > Author(s) : T. Nadeau, et al. > > > Filename : draft-ietf-ccamp-gmpls-te-mib-10.txt > > > Pages : 61 > > > Date : 2005-10-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-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-te-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-te-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. > > > > > > > > > = -------------------------------------------------------------------------= - > > ------ > > > > > > > _______________________________________________ > > > I-D-Announce mailing list > > > I-D-Announce@ietf.org > > > https://www1.ietf.org/mailman/listinfo/i-d-announce > > > > > > > >=20 >=20 > ------=_NextPart_000_0275_01C5D062.41B090B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Tom,
 
OK, I think I understand your = concerns better=20 now.
 
Would your issue be solved by the = inclusion of a=20 statement like...
 
        =20 Values of IANAGmplsSwitchingType are reserved for
       =20  switching types that correspond to entries in the =
        =20 Switching Types sub-registry of the GMPLS Signaling
       =20  Parameters registry managed by IANA.
 
Since that registry is controlled by = allocation=20 policies already agreed by IETF consensus, this text would ensure that = new=20 allocations within the textual convention would be equally=20 controlled.
 
I want to retain the "However, the = actual=20 values..." text because I do not want to force the values used in the = textual=20 conventions to match the values used in the protocol elements. For = example, if=20 the relevant working group decided to assign widely discontiguous values = for a=20 protocol field, I would not want to force the IANA to use those = identical values=20 in the textual convention. It would be adequate that they assigned = values that=20 corresponded but were not equal.
 
A concrete example is provided by=20 IANAGmplsSwitchingType. This takes values to correspond to the GMPLS = switching=20 types, but these have values in the IANA registry of 1, 2, 3, 4, = 51, 100,=20 150, 200. The IANA may consider that it is inappropriate to assign = enumerations=20 in a TC that are discontiguous, and could assign values 0 through 8 = rather than=20 those suggested in the draft.
 
You are correct that the text in = section 11.2 is=20 broken and should point to the description clauses of the individual = TCs. Thanks=20 for catching this.
 
 
Question: does all this address your=20 concerns?
 
Note: We have just submitted new = revisions of the=20 MIB modules to fix compilation issues, and those revisions do not = attempt to=20 address this issue.
 
 
Cheers,
Adrian
 
 
>=20 I am still uncomfortable with the apparent lack of constraints for = the
>=20 allocation of new values in IANA-GMPLS-TC-MIB.  There is = now
>=20
> "The rules for additions or changes to the IANA-GMPLS-TC-MIB=20 are
>    outlined in the DESCRIPTION clause associated = with=20 its
>    MODULE-IDENTITY statement."
>
> = but I do=20 not see anything about this in the DESCRIPTION clause.  Rather, it=20 is
> the DESCRIPTION clauses of individual TCs that contain the=20 information, e.g.
>
> "This textual convention is strongly = tied to=20 the Switching
>=20              = Types=20 sub-registry of the GMPLS Signaling Parameters
>=20              = registry managed by IANA. Values should be assigned by IANA
>=20              = in step=20 with the Switching Types sub-registry and using the
>=20              = same=20 registry management rules. However, the actual values
>=20              = used in=20 this textual convention are solely within the
>=20              = purview=20 of IANA and do not necessarily match the values in
>=20              = the=20 values in the Switching Types sub-registry.
> <snip>
> =              = Requests for new values should be made to IANA via
>=20              = email=20 (iana@isi.edu)."
> .
> It=20 is that "However ..." that bugs me; coupled with the final sentence, I=20 still
> see an e-mail from anyone in any SDO or elsewhere causing = IANA to=20 allocate a new
> value regardless of on-going work in the = IETF. =20 Perhaps unlikely given the
> close-knit world of GMPLS but I would = still=20 like to see tighter control, Expert
> Review would be my = choice.
>=20
> But I am also unclear what change control was intended by the = wording=20 in the
> latest draft.
>
> As with my my earlier=20 e-mail,
>
> "Somewhat bigger issue; I am concerned that no=20 constraint is placed on the
> allocation by IANA of new values in = the IANA=20 MIB module, where the base
> documents call for more stringent = action=20 (although there is some disagreement as
> to what that is).  = As it=20 stands, it seems to me that anyone in the world can
> e-mail IANA = and get=20 a new value assigned in the IANA MIB module, whereas I think
> it = should=20 be the appearance of an RFC, eg draft-ietf-ccamp-gmpls-routing = or
>=20 draft-ietf-ccamp-ospf-gmpls-extensions, which triggers that action, = perhaps=20 by
> Expert Review ie the existence of a new name/number mapping = is=20 documented in an
> RFC or I-D and Expert Review allows that = mapping to be=20 added to IANA MIB module.
> We could require the RFC that = introduces a new=20 mapping to have an IANA section
> that updates the MIB module but = I fear=20 that most editors would forget to include
> it, so Expert Review = seems=20 best.
>
>
> Tom Petch
>
> ----- = Original=20 Message -----
> From: "Adrian Farrel" <adrian@olddog.co.uk>
> To:=20 <ccamp@ops.ietf.org>
> Cc:=20 "Thomas D. Nadeau" <tnadeau@cisco.com>
> Sent: Wednesday, October 12, 2005 10:41 PM
> = Subject:=20 New versions of GMPLS MIBs
>
>
> > Hi,
>=20 >
> > We have been working on the GMPLS MIBs after MIB = Doctor=20 comments.
> > The revisions just being posted have addressed = all of the=20 nits and
> > editorial issues except:
> >
> > = -=20 conformance/compliance
> > - lint
> > - = compilation
>=20 >
> > Tom has just been working on these issues and the ball = is now=20 back with me
> > to integrate his changes and republish. I hope = to do=20 this in the next
> > couple of days.
> >
> > = In the=20 mean time, if you have any comments on the revised versions then
> = >=20 please let us know.
> >
> > Cheers,
> >=20 Adrian
> >
> >
> > ----- Original Message=20 -----
> > From: <Internet-Drafts@ietf.org>
>=20 > To: <i-d-announce@ietf.org>
>=20 > Cc: <ccamp@ops.ietf.org>
> >=20 Sent: Wednesday, October 12, 2005 8:50 PM
> > Subject: I-D=20 ACTION:draft-ietf-ccamp-gmpls-te-mib-10.txt
> >
> = >
>=20 > > A New Internet-Draft is available from the on-line=20 Internet-Drafts
> > directories.
> > > This draft = is a work=20 item of the Common Control and Measurement Plane
> > Working = Group of=20 the IETF.
> > >
> > > Title : Generalized = Multiprotocol=20 Label Switching
> >=20 >           &nb= sp;           &nbs= p;  =20 (GMPLS) Traffic Engineering Management
> > Information = Base
>=20 > > Author(s) : T. Nadeau, et al.
> > > Filename :=20 draft-ietf-ccamp-gmpls-te-mib-10.txt
> > > Pages : = 61
> >=20 > Date : 2005-10-12
> > >
> > > This memo = defines a=20 portion of the Management Information Base (MIB)
> >=20 >    for use with network management protocols in the = Internet=20 community.
> > >    In particular, it = describes=20 managed objects for Generalized
> > >   =20 Multiprotocol Label Switching (GMPLS) based traffic engineering.
> = >=20 >
> > > A URL for this Internet-Draft is:
> > = >=20 http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-te-mi= b-10.txt
> > >
> > > To remove = yourself from the=20 I-D Announcement list, send a message to
> > > i-d-announce-request@ietf.org with=20 the word unsubscribe in the body of
> > the message.
> = > >=20 You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce> > > to change your subscription = settings.
>=20 > >
> > >
> > > Internet-Drafts are also = available=20 by anonymous FTP. Login with the
> > username
> > > = "anonymous" and a password of your e-mail address. After logging = in,
>=20 > > type "cd internet-drafts" and then
> > > "get=20 draft-ietf-ccamp-gmpls-te-mib-10.txt".
> > >
> > = > A=20 list of Internet-Drafts directories can be found in
> > > = http://www.ietf.org/shadow.html
> > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> > >
> > >
> > = >=20 Internet-Drafts can also be obtained by e-mail.
> > = >
> >=20 > Send a message to:
> > > mailserv@ietf.org.
> > >=20 In the body type:
> > > "FILE=20 /internet-drafts/draft-ietf-ccamp-gmpls-te-mib-10.txt".
> >=20 >
> > > NOTE: The mail server at ietf.org can return the = document=20 in
> > > MIME-encoded form by using the "mpack" = utility.  To=20 use this
> > > feature, insert the command "ENCODING mime" = before=20 the "FILE"
> > > command.  To decode the response(s), = you will=20 need "munpack" or
> > > a MIME-compliant mail reader. =20 Different MIME-compliant mail readers
> > > exhibit = different=20 behavior, especially when dealing with
> > > "multipart" = MIME=20 messages (i.e. documents which have been split
> > > up into = multiple messages), so check your local documentation on
> > = > how=20 to manipulate these messages.
> > >
> > = >
> >=20 > Below is the data which will enable a MIME compliant mail = reader
>=20 > > implementation to automatically retrieve the ASCII version of=20 the
> > > Internet-Draft.
> > >
> = >
>=20 >
> >=20 -------------------------------------------------------------------------= -
>=20 > ------
> >
> >
> > >=20 _______________________________________________
> > > = I-D-Announce=20 mailing list
> > > I-D-Announce@ietf.org
> >=20 > https://www1.ietf.org/mailman/listinfo/i-d-announce> > >
> >
> >
> =
>=20
> ------=_NextPart_000_0275_01C5D062.41B090B0-- From owner-ccamp@ops.ietf.org Fri Oct 14 08:07:10 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQOL8-0007cT-M0 for ccamp-archive@megatron.ietf.org; Fri, 14 Oct 2005 08:07:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05735 for ; Fri, 14 Oct 2005 08:07:05 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQOVq-0001Kk-3x for ccamp-archive@ietf.org; Fri, 14 Oct 2005 08:18:15 -0400 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EQOCb-0008Ct-6Z for ccamp-data@psg.com; Fri, 14 Oct 2005 11:58:21 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [195.101.245.16] (helo=p-mail2.rd.francetelecom.com) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EQOCa-0008CK-5k for ccamp@ops.ietf.org; Fri, 14 Oct 2005 11:58:20 +0000 Received: from FTRDMEL2.rd.francetelecom.fr ([10.193.117.153]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211); Fri, 14 Oct 2005 13:58:17 +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: GMPLS for MS-SPRing Date: Fri, 14 Oct 2005 13:58:16 +0200 Message-ID: <7DBAFEC6A76F3E42817DF1EBE64CB02602A447CA@FTRDMEL2.rd.francetelecom.fr> Thread-Topic: GMPLS for MS-SPRing Thread-Index: AcXQsqQJgLCOmC2uRmSRf3ODA27bdAAAwSJw From: "MEURIC Julien RD-CORE-LAN" To: "Diego Caviglia" Cc: "ccamp" X-OriginalArrivalTime: 14 Oct 2005 11:58:17.0359 (UTC) FILETIME=[904E19F0:01C5D0B6] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: quoted-printable Hello Diego. I have just read your draft-caviglia-ccamp-gmpls-msspring-req-00.txt = about GMPLS requirements for MS-SPRing. I am glad to see you have again = a pragmatic approach to ease operators' migration from legacy SDH to = GMPLS. In paragraph "2.1 LSP Set-Up", you mention a "RingId" required by the = management plane and useless for the data plane itself. I am not = questionning this necessity (I am not a management expert), but I do not = really understand why it should be handled by the control plane. I = imagine this is related to communication between control and management, = but a clarification may be required here. Thanks Julien From owner-ccamp@ops.ietf.org Fri Oct 14 09:58:41 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQQ53-00019H-5j for ccamp-archive@megatron.ietf.org; Fri, 14 Oct 2005 09:58:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11665 for ; Fri, 14 Oct 2005 09:58:35 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQQFe-0004EV-RJ for ccamp-archive@ietf.org; Fri, 14 Oct 2005 10:09:46 -0400 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EQPsB-000LMV-Ui for ccamp-data@psg.com; Fri, 14 Oct 2005 13:45:23 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [62.241.163.7] (helo=blaster.systems.pipex.net) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EQPsA-000LMH-8G for ccamp@ops.ietf.org; Fri, 14 Oct 2005 13:45:22 +0000 Received: from pc6 (1Cust120.tnt29.lnd3.gbr.da.uu.net [62.188.120.120]) by blaster.systems.pipex.net (Postfix) with SMTP id 3CC19E0002D8; Fri, 14 Oct 2005 14:45:10 +0100 (BST) Message-ID: <00ca01c5d0bd$01c7e100$0601a8c0@pc6> Reply-To: "Tom Petch" From: "Tom Petch" To: "Adrian Farrel" , Cc: "Thomas D. Nadeau" , "joan cucchiara" References: <2d5c01c5cf6d$601f0e00$f2849ed9@Puppy> <067a01c5d02e$24fc1360$0601a8c0@pc6> <027801c5d059$e5117340$230ca8c0@Puppy> Subject: Re: IANA-GMPLS-TC-MIB was New versions of GMPLS MIBs Date: Fri, 14 Oct 2005 14:40:06 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: f0b5a4216bfa030ed8a6f68d1833f8ae Content-Transfer-Encoding: 7bit Aaaah, now I see; I had not imagined that the values in the MIB registry would be different to those in the GMPLS registry (but I understand why they might). Since I have been confused, I suggest expanding that sentence to "However, the numerical values used in this textual convention are solely within the purview of IANA and, for a given enumeration, will not necessarily be the same as the value in the Switching Types sub-registry. This might arise if the values in the Switching Types sub-registry are unsuitable for use in SMIv2." I am fine with your other sentence below (with similar sentences for each TC). Tom Petch ----- Original Message ----- From: "Adrian Farrel" To: "Tom Petch" ; Cc: "Thomas D. Nadeau" Sent: Friday, October 14, 2005 2:54 AM Subject: Re: IANA-GMPLS-TC-MIB was New versions of GMPLS MIBs Hi Tom, OK, I think I understand your concerns better now. Would your issue be solved by the inclusion of a statement like... Values of IANAGmplsSwitchingType are reserved for switching types that correspond to entries in the Switching Types sub-registry of the GMPLS Signaling Parameters registry managed by IANA. Since that registry is controlled by allocation policies already agreed by IETF consensus, this text would ensure that new allocations within the textual convention would be equally controlled. I want to retain the "However, the actual values..." text because I do not want to force the values used in the textual conventions to match the values used in the protocol elements. For example, if the relevant working group decided to assign widely discontiguous values for a protocol field, I would not want to force the IANA to use those identical values in the textual convention. It would be adequate that they assigned values that corresponded but were not equal. A concrete example is provided by IANAGmplsSwitchingType. This takes values to correspond to the GMPLS switching types, but these have values in the IANA registry of 1, 2, 3, 4, 51, 100, 150, 200. The IANA may consider that it is inappropriate to assign enumerations in a TC that are discontiguous, and could assign values 0 through 8 rather than those suggested in the draft. You are correct that the text in section 11.2 is broken and should point to the description clauses of the individual TCs. Thanks for catching this. Question: does all this address your concerns? Note: We have just submitted new revisions of the MIB modules to fix compilation issues, and those revisions do not attempt to address this issue. Cheers, Adrian > I am still uncomfortable with the apparent lack of constraints for the > allocation of new values in IANA-GMPLS-TC-MIB. There is now > > "The rules for additions or changes to the IANA-GMPLS-TC-MIB are > outlined in the DESCRIPTION clause associated with its > MODULE-IDENTITY statement." > > but I do not see anything about this in the DESCRIPTION clause. Rather, it is > the DESCRIPTION clauses of individual TCs that contain the information, e.g. > > "This textual convention is strongly tied to the Switching > Types sub-registry of the GMPLS Signaling Parameters > registry managed by IANA. Values should be assigned by IANA > in step with the Switching Types sub-registry and using the > same registry management rules. However, the actual values > used in this textual convention are solely within the > purview of IANA and do not necessarily match the values in > the values in the Switching Types sub-registry. > > Requests for new values should be made to IANA via > email (iana@isi.edu)." > . > It is that "However ..." that bugs me; coupled with the final sentence, I still > see an e-mail from anyone in any SDO or elsewhere causing IANA to allocate a new > value regardless of on-going work in the IETF. Perhaps unlikely given the > close-knit world of GMPLS but I would still like to see tighter control, Expert > Review would be my choice. > > But I am also unclear what change control was intended by the wording in the > latest draft. > > As with my my earlier e-mail, > > "Somewhat bigger issue; I am concerned that no constraint is placed on the > allocation by IANA of new values in the IANA MIB module, where the base > documents call for more stringent action (although there is some disagreement as > to what that is). As it stands, it seems to me that anyone in the world can > e-mail IANA and get a new value assigned in the IANA MIB module, whereas I think > it should be the appearance of an RFC, eg draft-ietf-ccamp-gmpls-routing or > draft-ietf-ccamp-ospf-gmpls-extensions, which triggers that action, perhaps by > Expert Review ie the existence of a new name/number mapping is documented in an > RFC or I-D and Expert Review allows that mapping to be added to IANA MIB module. > We could require the RFC that introduces a new mapping to have an IANA section > that updates the MIB module but I fear that most editors would forget to include > it, so Expert Review seems best. > > > Tom Petch > > ----- Original Message ----- > From: "Adrian Farrel" > To: > Cc: "Thomas D. Nadeau" > Sent: Wednesday, October 12, 2005 10:41 PM > Subject: New versions of GMPLS MIBs > > > > Hi, > > > > We have been working on the GMPLS MIBs after MIB Doctor comments. > > The revisions just being posted have addressed all of the nits and > > editorial issues except: > > > > - conformance/compliance > > - lint > > - compilation > > > > Tom has just been working on these issues and the ball is now back with me > > to integrate his changes and republish. I hope to do this in the next > > couple of days. > > > > In the mean time, if you have any comments on the revised versions then > > please let us know. > > > > Cheers, > > Adrian > > > > > > ----- Original Message ----- > > From: > > To: > > Cc: > > Sent: Wednesday, October 12, 2005 8:50 PM > > Subject: I-D ACTION:draft-ietf-ccamp-gmpls-te-mib-10.txt > > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > > This draft is a work item of the Common Control and Measurement Plane > > Working Group of the IETF. > > > > > > Title : Generalized Multiprotocol Label Switching > > > (GMPLS) Traffic Engineering Management > > Information Base > > > Author(s) : T. Nadeau, et al. > > > Filename : draft-ietf-ccamp-gmpls-te-mib-10.txt > > > Pages : 61 > > > Date : 2005-10-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-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-te-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-te-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. > > > > > > > > > -------------------------------------------------------------------------- > > ------ > > > > > > > _______________________________________________ > > > I-D-Announce mailing list > > > I-D-Announce@ietf.org > > > https://www1.ietf.org/mailman/listinfo/i-d-announce > > > > > > > > > > From owner-ccamp@ops.ietf.org Fri Oct 14 10:28:12 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQQXc-0003Ia-Hm for ccamp-archive@megatron.ietf.org; Fri, 14 Oct 2005 10:28:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13772 for ; Fri, 14 Oct 2005 10:28:06 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQQiL-00059j-16 for ccamp-archive@ietf.org; Fri, 14 Oct 2005 10:39:18 -0400 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EQQRc-0000GU-HW for ccamp-data@psg.com; Fri, 14 Oct 2005 14:22:00 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [128.87.251.112] (helo=smtpoutuk01.marconi.com) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EQQRa-0000G6-Pf for ccamp@ops.ietf.org; Fri, 14 Oct 2005 14:21:59 +0000 Received: from cvdgwy01.uk.marconicomms.com (cvis26.uk.marconicomms.com [128.87.251.109]) by smtpoutuk01.marconi.com (8.12.11/8.12.11) with ESMTP id j9EELnFt018337; Fri, 14 Oct 2005 15:21:49 +0100 (envelope-from Diego.Caviglia@marconi.com) Subject: Re: GMPLS for MS-SPRing To: julien.meuric@francetelecom.com Cc: ccamp@ops.ietf.org X-Mailer: Lotus Notes Release 5.0.12 February 13, 2003 Message-ID: From: "Diego Caviglia" Date: Fri, 14 Oct 2005 16:21:34 +0200 X-MIMETrack: Serialize by Router on CVDGWY01/S/EXT/MC1(5012HF354 | August 26, 2003) at 14/10/2005 15:21:44 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: 31247fb3be228bb596db9127becad0bc Hi Julien, is always a pleasure to discuss this topics with you. You are right and a clarification is definitely needed here. Basically Ring ID parameter is a common identifier for all the TE links belonging to the same ring. In such a way, in a no-control plane/pre-GMPLS scenario, from a management plane point of view it is possible to discern if a given node belongs to a given ring by checking its Ring ID. In an advanced scenario, where a control plane (GMPLS based) is in place "between" data and management plane, the Ring ID parameter keeps on doing the same function of making possible the association of a given TE link with the ring it belongs to. Why is this information needed at control plane level? Think of a routing protocol deployed over control plane, say GOSPF-TE. When we come at dealing with MSSPRING inherent requirements that control plane has to be compliant with, there are spring related informations that a routing protocol has to flood over the network (as opaque) to make possible correct operation. Among them there could be (depending on the strategy that'll be followed) the information about a TE link as belonging or not to a ring and, if yes, to which ring. In this case Ring ID serves the purpose. For a ingress node running Path Computation Engine it is important to know this attribute of a TE link to take special routing decisions or to try to satisfy given requirements involving MSSPRING traversing. In addition, ring ID information could be used if some information interests only the TNE's belonging to a given ring and has to be flooded only to the TNEs in that ring. In this case Ring ID could be used by a TNE belonging to a ring to check if its OSPF neighbor belongs tho the same ring and hence if a given LSA has to be sent to it or not. These are examples of possible usage of Ring ID within control plane. Apart from these specifc uses, there could be other cases to be defined where a similar identifier is needed. Of course it depends on which strategy is chosen to handle MSSPRING management and requirements from control plane. Hope this clarify. Best Regards Diego "MEURIC Julien RD-CORE-LAN" @ops.ietf.org on 14/10/2005 13.58.16 Sent by: owner-ccamp@ops.ietf.org To: "Diego Caviglia" cc: "ccamp" Subject: GMPLS for MS-SPRing Hello Diego. I have just read your draft-caviglia-ccamp-gmpls-msspring-req-00.txt about GMPLS requirements for MS-SPRing. I am glad to see you have again a pragmatic approach to ease operators' migration from legacy SDH to GMPLS. In paragraph "2.1 LSP Set-Up", you mention a "RingId" required by the management plane and useless for the data plane itself. I am not questionning this necessity (I am not a management expert), but I do not really understand why it should be handled by the control plane. I imagine this is related to communication between control and management, but a clarification may be required here. Thanks Julien From owner-ccamp@ops.ietf.org Fri Oct 14 10:49:01 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQQrl-0001Z8-17 for ccamp-archive@megatron.ietf.org; Fri, 14 Oct 2005 10:49:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14888 for ; Fri, 14 Oct 2005 10:48:57 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQR2R-0005iz-LT for ccamp-archive@ietf.org; Fri, 14 Oct 2005 11:00:07 -0400 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EQQj7-0002HD-SC for ccamp-data@psg.com; Fri, 14 Oct 2005 14:40:05 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-1.2 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [68.142.200.151] (helo=web30808.mail.mud.yahoo.com) by psg.com with smtp (Exim 4.52 (FreeBSD)) id 1EQQj6-0002EN-3B for ccamp@ops.ietf.org; Fri, 14 Oct 2005 14:40:04 +0000 Received: (qmail 88361 invoked by uid 60001); 14 Oct 2005 14:39:56 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=faFV4eZJhp+YB5veoXYT+fj/FINoRmAvozVdQmSEtmVjATz2aCit4sA+iDuS4VAFRM7c0od5SBFMsoi9xuFhpclSkydXHJMK6c/YrX8yB5ihskUDSJddU4wgvkyD2AMRbTZHeQv/vli6Ly0uAaD59UJnR0x4/otxwInZBZEPRE8= ; Message-ID: <20051014143956.88356.qmail@web30808.mail.mud.yahoo.com> Received: from [68.100.80.11] by web30808.mail.mud.yahoo.com via HTTP; Fri, 14 Oct 2005 07:39:55 PDT Date: Fri, 14 Oct 2005 07:39:55 -0700 (PDT) From: Igor Bryskin Subject: Re: GMPLS for MS-SPRing To: Diego Caviglia , julien.meuric@francetelecom.com Cc: ccamp@ops.ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.6 (/) X-Scan-Signature: 87a3f533bb300b99e2a18357f3c1563d Content-Transfer-Encoding: 8bit Hi Diego, One thing that I'd suggest adding to your draft is ability to compute and signal LSP paths in terms of rings rather than in terms of links, and let ring border LSRs to expend the paths - provide paths within the rings. This mechanism is especially handy when there is a need for path-segment recovery on per-ring basis. Igor --- Diego Caviglia wrote: > > Hi Julien, > is always a pleasure to discuss this > topics with you. > > You are right and a clarification is definitely > needed here. > Basically Ring ID parameter is a common identifier > for all the TE links > belonging to the same ring. > > In such a way, in a no-control plane/pre-GMPLS > scenario, from a management > plane point of view it is possible to > discern if a given node belongs to a given ring by > checking its Ring ID. > > In an advanced scenario, where a control plane > (GMPLS based) is in place > "between" data and management plane, the Ring ID > parameter keeps on > doing the same function of making possible the > association of a given TE > link with the ring it belongs to. > > Why is this information needed at control plane > level? Think of a routing > protocol deployed over control plane, say GOSPF-TE. > When we come at dealing > with MSSPRING inherent requirements that control > plane has to be compliant > with, there are spring related informations that a > routing protocol has to > flood over the network (as opaque) to make possible > correct operation. > Among them there could be (depending on the strategy > that'll be followed) > the information about a TE link as belonging or not > to a ring and, if yes, > to which ring. In this case Ring ID serves the > purpose. > For a ingress node running Path Computation Engine > it is important to know > this attribute of a TE link to take special routing > decisions or to try to > satisfy given requirements involving MSSPRING > traversing. > > In addition, ring ID information could be used if > some information > interests only the TNE's belonging to a given ring > and has to be flooded > only to the TNEs in that ring. In this case Ring ID > could be used by a TNE > belonging to a ring to check if its OSPF neighbor > belongs tho the same ring > and hence if a given LSA has to be sent to it or > not. > > These are examples of possible usage of Ring ID > within control plane. Apart > from these specifc uses, there could be other cases > to be defined where a > similar identifier is needed. Of course it depends > on which strategy is > chosen to handle MSSPRING management and > requirements from control plane. > > Hope this clarify. > > Best Regards > > Diego > > > > > "MEURIC Julien RD-CORE-LAN" > @ops.ietf.org > on 14/10/2005 13.58.16 > > Sent by: owner-ccamp@ops.ietf.org > > > To: "Diego Caviglia" > cc: "ccamp" > > Subject: GMPLS for MS-SPRing > > Hello Diego. > > I have just read your > draft-caviglia-ccamp-gmpls-msspring-req-00.txt about > GMPLS requirements for MS-SPRing. I am glad to see > you have again a > pragmatic approach to ease operators' migration from > legacy SDH to GMPLS. > > In paragraph "2.1 LSP Set-Up", you mention a > "RingId" required by the > management plane and useless for the data plane > itself. I am not > questionning this necessity (I am not a management > expert), but I do not > really understand why it should be handled by the > control plane. I imagine > this is related to communication between control and > management, but a > clarification may be required here. > > Thanks > > Julien > > > > > > > > __________________________________ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com From owner-ccamp@ops.ietf.org Fri Oct 14 10:53:12 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQQvo-0003m3-Jg for ccamp-archive@megatron.ietf.org; Fri, 14 Oct 2005 10:53:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15838 for ; Fri, 14 Oct 2005 10:53:03 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQR6P-00066P-7D for ccamp-archive@ietf.org; Fri, 14 Oct 2005 11:04:11 -0400 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EQQpj-00030M-Od for ccamp-data@psg.com; Fri, 14 Oct 2005 14:46:55 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [128.87.251.112] (helo=smtpoutuk01.marconi.com) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EQQpi-000301-Fi for ccamp@ops.ietf.org; Fri, 14 Oct 2005 14:46:55 +0000 Received: from cvdgwy01.uk.marconicomms.com (cvis26.uk.marconicomms.com [128.87.251.109]) by smtpoutuk01.marconi.com (8.12.11/8.12.11) with ESMTP id j9EEkjoK021436; Fri, 14 Oct 2005 15:46:45 +0100 (envelope-from Diego.Caviglia@marconi.com) Subject: Re: GMPLS for MS-SPRing To: "Igor Bryskin Cc: "julien.meuric" , "ccamp" X-Mailer: Lotus Notes Release 5.0.12 February 13, 2003 Message-ID: From: "Diego Caviglia" Date: Fri, 14 Oct 2005 16:46:21 +0200 X-MIMETrack: Serialize by Router on CVDGWY01/S/EXT/MC1(5012HF354 | August 26, 2003) at 14/10/2005 15:46:40 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 2.4 (++) X-Scan-Signature: 0cff8c3ec906d056784362c06f5f88c1 Hi Igor, I agree with you but the ID is only a requiremet ID, we tried to avoid possible signalling and routing implementation that can satisfy the requiremnts. If there is interest in the community about this topic we'll produce IDs to satisfy the requiremets. Regards Diego Igor Bryskin on 14/10/2005 16.39.55 To: Diego Caviglia , julien.meuric@francetelecom.com cc: ccamp@ops.ietf.org Subject: Re: GMPLS for MS-SPRing Hi Diego, One thing that I'd suggest adding to your draft is ability to compute and signal LSP paths in terms of rings rather than in terms of links, and let ring border LSRs to expend the paths - provide paths within the rings. This mechanism is especially handy when there is a need for path-segment recovery on per-ring basis. Igor --- Diego Caviglia wrote: > > Hi Julien, > is always a pleasure to discuss this > topics with you. > > You are right and a clarification is definitely > needed here. > Basically Ring ID parameter is a common identifier > for all the TE links > belonging to the same ring. > > In such a way, in a no-control plane/pre-GMPLS > scenario, from a management > plane point of view it is possible to > discern if a given node belongs to a given ring by > checking its Ring ID. > > In an advanced scenario, where a control plane > (GMPLS based) is in place > "between" data and management plane, the Ring ID > parameter keeps on > doing the same function of making possible the > association of a given TE > link with the ring it belongs to. > > Why is this information needed at control plane > level? Think of a routing > protocol deployed over control plane, say GOSPF-TE. > When we come at dealing > with MSSPRING inherent requirements that control > plane has to be compliant > with, there are spring related informations that a > routing protocol has to > flood over the network (as opaque) to make possible > correct operation. > Among them there could be (depending on the strategy > that'll be followed) > the information about a TE link as belonging or not > to a ring and, if yes, > to which ring. In this case Ring ID serves the > purpose. > For a ingress node running Path Computation Engine > it is important to know > this attribute of a TE link to take special routing > decisions or to try to > satisfy given requirements involving MSSPRING > traversing. > > In addition, ring ID information could be used if > some information > interests only the TNE's belonging to a given ring > and has to be flooded > only to the TNEs in that ring. In this case Ring ID > could be used by a TNE > belonging to a ring to check if its OSPF neighbor > belongs tho the same ring > and hence if a given LSA has to be sent to it or > not. > > These are examples of possible usage of Ring ID > within control plane. Apart > from these specifc uses, there could be other cases > to be defined where a > similar identifier is needed. Of course it depends > on which strategy is > chosen to handle MSSPRING management and > requirements from control plane. > > Hope this clarify. > > Best Regards > > Diego > > > > > "MEURIC Julien RD-CORE-LAN" > @ops.ietf.org > on 14/10/2005 13.58.16 > > Sent by: owner-ccamp@ops.ietf.org > > > To: "Diego Caviglia" > cc: "ccamp" > > Subject: GMPLS for MS-SPRing > > Hello Diego. > > I have just read your > draft-caviglia-ccamp-gmpls-msspring-req-00.txt about > GMPLS requirements for MS-SPRing. I am glad to see > you have again a > pragmatic approach to ease operators' migration from > legacy SDH to GMPLS. > > In paragraph "2.1 LSP Set-Up", you mention a > "RingId" required by the > management plane and useless for the data plane > itself. I am not > questionning this necessity (I am not a management > expert), but I do not > really understand why it should be handled by the > control plane. I imagine > this is related to communication between control and > management, but a > clarification may be required here. > > Thanks > > Julien > > > > > > > > __________________________________ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com From owner-ccamp@ops.ietf.org Fri Oct 14 11:15:58 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQRHp-0000pG-Ro for ccamp-archive@megatron.ietf.org; Fri, 14 Oct 2005 11:15:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22962 for ; Fri, 14 Oct 2005 11:15:53 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQRSV-0000PS-Kk for ccamp-archive@ietf.org; Fri, 14 Oct 2005 11:27:04 -0400 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EQRDP-0006Tj-Mk for ccamp-data@psg.com; Fri, 14 Oct 2005 15:11:23 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [70.158.43.219] (helo=jera.movaz.com) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EQRDO-0006TU-LO for ccamp@ops.ietf.org; Fri, 14 Oct 2005 15:11:22 +0000 Received: from ib (vpn14.atlanta.movaz.com [172.18.0.14]) by jera.movaz.com (Postfix) with SMTP id C8FE660BDD; Fri, 14 Oct 2005 11:11:20 -0400 (EDT) Message-ID: <004901c5d0d1$877cc310$6601a8c0@movaz.com> From: "Igor Bryskin" To: "Igor Bryskin , "Diego Caviglia" Cc: "julien.meuric" , "ccamp" References: Subject: Re: GMPLS for MS-SPRing Date: Fri, 14 Oct 2005 11:11:18 -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: 2.4 (++) X-Scan-Signature: 93df555cbdbcdae9621e5b95d44b301e Content-Transfer-Encoding: 7bit Sure, Would be happy to work on this together. Igor ----- Original Message ----- From: "Diego Caviglia" To: "Igor Bryskin Cc: "julien.meuric" ; "ccamp" Sent: Friday, October 14, 2005 10:46 AM Subject: Re: GMPLS for MS-SPRing > > Hi Igor, > I agree with you but the ID is only a requiremet ID, we tried to > avoid possible signalling and routing implementation that can satisfy the > requiremnts. > > If there is interest in the community about this topic we'll produce IDs to > satisfy the requiremets. > > Regards > > Diego > > > > Igor Bryskin on 14/10/2005 16.39.55 > > To: Diego Caviglia , > julien.meuric@francetelecom.com > cc: ccamp@ops.ietf.org > > Subject: Re: GMPLS for MS-SPRing > > Hi Diego, > > One thing that I'd suggest adding to your draft is > ability to compute and signal LSP paths in terms of > rings rather than in terms of links, and let ring > border LSRs to expend the paths - provide paths within > the rings. This mechanism is especially handy when > there is a need for path-segment recovery on per-ring > basis. > > Igor > > --- Diego Caviglia wrote: > > > > > Hi Julien, > > is always a pleasure to discuss this > > topics with you. > > > > You are right and a clarification is definitely > > needed here. > > Basically Ring ID parameter is a common identifier > > for all the TE links > > belonging to the same ring. > > > > In such a way, in a no-control plane/pre-GMPLS > > scenario, from a management > > plane point of view it is possible to > > discern if a given node belongs to a given ring by > > checking its Ring ID. > > > > In an advanced scenario, where a control plane > > (GMPLS based) is in place > > "between" data and management plane, the Ring ID > > parameter keeps on > > doing the same function of making possible the > > association of a given TE > > link with the ring it belongs to. > > > > Why is this information needed at control plane > > level? Think of a routing > > protocol deployed over control plane, say GOSPF-TE. > > When we come at dealing > > with MSSPRING inherent requirements that control > > plane has to be compliant > > with, there are spring related informations that a > > routing protocol has to > > flood over the network (as opaque) to make possible > > correct operation. > > Among them there could be (depending on the strategy > > that'll be followed) > > the information about a TE link as belonging or not > > to a ring and, if yes, > > to which ring. In this case Ring ID serves the > > purpose. > > For a ingress node running Path Computation Engine > > it is important to know > > this attribute of a TE link to take special routing > > decisions or to try to > > satisfy given requirements involving MSSPRING > > traversing. > > > > In addition, ring ID information could be used if > > some information > > interests only the TNE's belonging to a given ring > > and has to be flooded > > only to the TNEs in that ring. In this case Ring ID > > could be used by a TNE > > belonging to a ring to check if its OSPF neighbor > > belongs tho the same ring > > and hence if a given LSA has to be sent to it or > > not. > > > > These are examples of possible usage of Ring ID > > within control plane. Apart > > from these specifc uses, there could be other cases > > to be defined where a > > similar identifier is needed. Of course it depends > > on which strategy is > > chosen to handle MSSPRING management and > > requirements from control plane. > > > > Hope this clarify. > > > > Best Regards > > > > Diego > > > > > > > > > > "MEURIC Julien RD-CORE-LAN" > > @ops.ietf.org > > on 14/10/2005 13.58.16 > > > > Sent by: owner-ccamp@ops.ietf.org > > > > > > To: "Diego Caviglia" > > cc: "ccamp" > > > > Subject: GMPLS for MS-SPRing > > > > Hello Diego. > > > > I have just read your > > draft-caviglia-ccamp-gmpls-msspring-req-00.txt about > > GMPLS requirements for MS-SPRing. I am glad to see > > you have again a > > pragmatic approach to ease operators' migration from > > legacy SDH to GMPLS. > > > > In paragraph "2.1 LSP Set-Up", you mention a > > "RingId" required by the > > management plane and useless for the data plane > > itself. I am not > > questionning this necessity (I am not a management > > expert), but I do not > > really understand why it should be handled by the > > control plane. I imagine > > this is related to communication between control and > > management, but a > > clarification may be required here. > > > > Thanks > > > > Julien > > > > > > > > > > > > > > > > > > > > > > __________________________________ > Yahoo! Mail - PC Magazine Editors' Choice 2005 > http://mail.yahoo.com > > > > > > > From owner-ccamp@ops.ietf.org Fri Oct 14 14:45:44 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQUYq-00021w-9m for ccamp-archive@megatron.ietf.org; Fri, 14 Oct 2005 14:45:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04704 for ; Fri, 14 Oct 2005 14:45:38 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQUjW-0006Gt-Of for ccamp-archive@ietf.org; Fri, 14 Oct 2005 14:56:52 -0400 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EQUS8-0006tF-4X for ccamp-data@psg.com; Fri, 14 Oct 2005 18:38:48 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [64.102.122.149] (helo=rtp-iport-2.cisco.com) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EQUS7-0006t2-Jm for ccamp@ops.ietf.org; Fri, 14 Oct 2005 18:38:47 +0000 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 14 Oct 2005 14:38:47 -0400 X-IronPort-AV: i="3.97,215,1125892800"; d="scan'208"; a="73760174:sNHT22737656" 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 j9EIcFF6017410; Fri, 14 Oct 2005 14:38:44 -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); Fri, 14 Oct 2005 14:38:40 -0400 Received: from swallow-mini-mac.local ([10.86.242.18]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 14 Oct 2005 14:38:40 -0400 Received: from cisco.com (localhost [127.0.0.1]) by swallow-mini-mac.local (Postfix) with ESMTP id B6BC4154FBF; Fri, 14 Oct 2005 14:38:39 -0400 (EDT) To: "Diego Caviglia" Cc: "Igor Bryskin , "julien.meuric" , "ccamp" Cc: swallow@cisco.com Subject: Re: GMPLS for MS-SPRing In-reply-to: Your message of "Fri, 14 Oct 2005 16:46:21 +0200." From: George Swallow X-Mailer: MH-E 7.4.3; nmh 1.1-RC3; GNU Emacs 21.2.1 Date: Fri, 14 Oct 2005 14:38:39 -0400 Message-Id: <20051014183839.B6BC4154FBF@swallow-mini-mac.local> X-OriginalArrivalTime: 14 Oct 2005 18:38:40.0332 (UTC) FILETIME=[7F1CE0C0:01C5D0EE] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Diego - Is there anything that's General about this? All that I can think of off the top of my head is MPLS specific. If this is the case, then the draft belongs in MPLS. ...George ======================================================================== George Swallow Cisco Systems (978) 936-1398 1414 Massachusetts Avenue Boxborough, MA 01719 From owner-ccamp@ops.ietf.org Fri Oct 14 14:46:20 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQUZQ-00023W-Bm for ccamp-archive@megatron.ietf.org; Fri, 14 Oct 2005 14:46:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04723 for ; Fri, 14 Oct 2005 14:46:14 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQUkB-0006HJ-5N for ccamp-archive@ietf.org; Fri, 14 Oct 2005 14:57:28 -0400 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EQUMY-0006LZ-9e for ccamp-data@psg.com; Fri, 14 Oct 2005 18:33:02 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [64.102.122.148] (helo=rtp-iport-1.cisco.com) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EQUMX-0006LM-H3 for ccamp@ops.ietf.org; Fri, 14 Oct 2005 18:33:01 +0000 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 14 Oct 2005 11:33:01 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.97,215,1125903600"; d="scan'208"; a="13220629:sNHT20308872" 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 j9EIWFFK016509; Fri, 14 Oct 2005 14:32:58 -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); Fri, 14 Oct 2005 14:32:39 -0400 Received: from swallow-mini-mac.local ([10.86.242.18]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 14 Oct 2005 14:32:38 -0400 Received: from cisco.com (localhost [127.0.0.1]) by swallow-mini-mac.local (Postfix) with ESMTP id 53643154ECD; Fri, 14 Oct 2005 14:32:38 -0400 (EDT) To: Igor Bryskin Cc: Diego Caviglia , julien.meuric@francetelecom.com, ccamp@ops.ietf.org Cc: swallow@cisco.com Subject: Re: GMPLS for MS-SPRing In-reply-to: Your message of "Fri, 14 Oct 2005 07:39:55 PDT." <20051014143956.88356.qmail@web30808.mail.mud.yahoo.com> From: George Swallow X-Mailer: MH-E 7.4.3; nmh 1.1-RC3; GNU Emacs 21.2.1 Date: Fri, 14 Oct 2005 14:32:38 -0400 Message-Id: <20051014183238.53643154ECD@swallow-mini-mac.local> X-OriginalArrivalTime: 14 Oct 2005 18:32:38.0847 (UTC) FILETIME=[A7A6A4F0:01C5D0ED] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 > One thing that I'd suggest adding to your draft is > ability to compute and signal LSP paths in terms of > rings rather than in terms of links, and let ring > border LSRs to expend the paths - provide paths within > the rings. This mechanism is especially handy when > there is a need for path-segment recovery on per-ring > basis. Perhaps I'm reading too much into this as I note that you only talked about signalling and not routing. But if you want to accurately show the state of the ring (e.g. bandwidth), then you have to advertise each segment of the ring. I worked out a lot of the details quite a long time ago. Be glad to help out on the protocol part. ...George ======================================================================== George Swallow Cisco Systems (978) 936-1398 1414 Massachusetts Avenue Boxborough, MA 01719 From owner-ccamp@ops.ietf.org Fri Oct 14 14:56:08 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQUiu-0004If-F1 for ccamp-archive@megatron.ietf.org; Fri, 14 Oct 2005 14:56:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05019 for ; Fri, 14 Oct 2005 14:56:03 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQUtf-0006Sx-Fb for ccamp-archive@ietf.org; Fri, 14 Oct 2005 15:07:16 -0400 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EQUe6-0008RL-Tn for ccamp-data@psg.com; Fri, 14 Oct 2005 18:51:10 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [64.102.122.148] (helo=rtp-iport-1.cisco.com) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EQUe6-0008R7-CA for ccamp@ops.ietf.org; Fri, 14 Oct 2005 18:51:10 +0000 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 14 Oct 2005 11:51:09 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.97,215,1125903600"; d="scan'208"; a="13221824:sNHT18633416" 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 j9EIp129015364; Fri, 14 Oct 2005 14:51:07 -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); Fri, 14 Oct 2005 14:51:06 -0400 Received: from swallow-mini-mac.local ([10.86.242.18]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 14 Oct 2005 14:51:05 -0400 Received: from cisco.com (localhost [127.0.0.1]) by swallow-mini-mac.local (Postfix) with ESMTP id 54F0615521A; Fri, 14 Oct 2005 14:51:05 -0400 (EDT) Cc: "Diego Caviglia" , "Igor Bryskin , "julien.meuric" , "ccamp" Cc: swallow@cisco.com Subject: Re: GMPLS for MS-SPRing In-reply-to: Your message of "Fri, 14 Oct 2005 14:38:39 EDT." <20051014183839.B6BC4154FBF@swallow-mini-mac.local> From: George Swallow X-Mailer: MH-E 7.4.3; nmh 1.1-RC3; GNU Emacs 21.2.1 Date: Fri, 14 Oct 2005 14:51:05 -0400 Message-Id: <20051014185105.54F0615521A@swallow-mini-mac.local> X-OriginalArrivalTime: 14 Oct 2005 18:51:05.0894 (UTC) FILETIME=[3B809C60:01C5D0F0] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Ignore my last post! Acronym dyslexia on my part. Looked at SPRing and thought I saw SRPring... ...George ======================================================================== George Swallow Cisco Systems (978) 936-1398 1414 Massachusetts Avenue Boxborough, MA 01719 From owner-ccamp@ops.ietf.org Fri Oct 14 15:13:45 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQUzx-0002R0-1p for ccamp-archive@megatron.ietf.org; Fri, 14 Oct 2005 15:13:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05657 for ; Fri, 14 Oct 2005 15:13:39 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQVAg-0006q3-K5 for ccamp-archive@ietf.org; Fri, 14 Oct 2005 15:24:53 -0400 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EQUsQ-000B0b-DJ for ccamp-data@psg.com; Fri, 14 Oct 2005 19:05:58 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [213.46.243.17] (helo=amsfep12-int.chello.nl) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EQUsO-000B06-Rs for ccamp@ops.ietf.org; Fri, 14 Oct 2005 19:05:57 +0000 Received: from [192.168.1.4] (really [24.132.27.149]) by amsfep12-int.chello.nl (InterMail vM.6.01.04.04 201-2131-118-104-20050224) with ESMTP id <20051014190553.YWTN17934.amsfep12-int.chello.nl@[192.168.1.4]> for ; Fri, 14 Oct 2005 21:05:53 +0200 Message-ID: <43500190.3050604@chello.nl> Date: Fri, 14 Oct 2005 21:05:52 +0200 From: Huub van Helvoort User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ccamp Subject: Re: GMPLS for MS-SPRing 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.1 (/) X-Scan-Signature: cd3fc8e909678b38737fc606dec187f0 Content-Transfer-Encoding: 7bit Hello Diego, You wrote: > Hi Igor, > I agree with you but the ID is only a requiremet ID, we tried to > avoid possible signalling and routing implementation that can satisfy the > requiremnts. I agree with you that adding more specific/implementation information will change the scope of theis I-D. Kind regards, Huub. == > If there is interest in the community about this topic we'll produce IDs to > satisfy the requiremets. > > Regards > > Diego > > > Igor Bryskin on 14/10/2005 16.39.55 > > To: Diego Caviglia , > julien.meuric@francetelecom.com > cc: ccamp@ops.ietf.org > > Subject: Re: GMPLS for MS-SPRing > > Hi Diego, > > One thing that I'd suggest adding to your draft is > ability to compute and signal LSP paths in terms of > rings rather than in terms of links, and let ring > border LSRs to expend the paths - provide paths within > the rings. This mechanism is especially handy when > there is a need for path-segment recovery on per-ring > basis. > > Igor > > --- Diego Caviglia wrote: > >>Hi Julien, >> is always a pleasure to discuss this >>topics with you. >> >>You are right and a clarification is definitely >>needed here. >>Basically Ring ID parameter is a common identifier >>for all the TE links >>belonging to the same ring. >> >>In such a way, in a no-control plane/pre-GMPLS >>scenario, from a management >>plane point of view it is possible to >>discern if a given node belongs to a given ring by >>checking its Ring ID. >> >>In an advanced scenario, where a control plane >>(GMPLS based) is in place >>"between" data and management plane, the Ring ID >>parameter keeps on >>doing the same function of making possible the >>association of a given TE >>link with the ring it belongs to. >> >>Why is this information needed at control plane >>level? Think of a routing >>protocol deployed over control plane, say GOSPF-TE. >>When we come at dealing >>with MSSPRING inherent requirements that control >>plane has to be compliant >>with, there are spring related informations that a >>routing protocol has to >>flood over the network (as opaque) to make possible >>correct operation. >>Among them there could be (depending on the strategy >>that'll be followed) >>the information about a TE link as belonging or not >>to a ring and, if yes, >>to which ring. In this case Ring ID serves the >>purpose. >>For a ingress node running Path Computation Engine >>it is important to know >>this attribute of a TE link to take special routing >>decisions or to try to >>satisfy given requirements involving MSSPRING >>traversing. >> >>In addition, ring ID information could be used if >>some information >>interests only the TNE's belonging to a given ring >>and has to be flooded >>only to the TNEs in that ring. In this case Ring ID >>could be used by a TNE >>belonging to a ring to check if its OSPF neighbor >>belongs tho the same ring >>and hence if a given LSA has to be sent to it or >>not. >> >>These are examples of possible usage of Ring ID >>within control plane. Apart >>from these specifc uses, there could be other cases >>to be defined where a >>similar identifier is needed. Of course it depends >>on which strategy is >>chosen to handle MSSPRING management and >>requirements from control plane. >> >>Hope this clarify. >> >>Best Regards >> >>Diego >> >> >>"MEURIC Julien RD-CORE-LAN" >>@ops.ietf.org >>on 14/10/2005 13.58.16 >> >>Sent by: owner-ccamp@ops.ietf.org >> >> >>To: "Diego Caviglia" >>cc: "ccamp" >> >>Subject: GMPLS for MS-SPRing >> >>Hello Diego. >> >>I have just read your >>draft-caviglia-ccamp-gmpls-msspring-req-00.txt about >>GMPLS requirements for MS-SPRing. I am glad to see >>you have again a >>pragmatic approach to ease operators' migration from >>legacy SDH to GMPLS. >> >>In paragraph "2.1 LSP Set-Up", you mention a >>"RingId" required by the >>management plane and useless for the data plane >>itself. I am not >>questionning this necessity (I am not a management >>expert), but I do not >>really understand why it should be handled by the >>control plane. I imagine >>this is related to communication between control and >>management, but a >>clarification may be required here. >> >>Thanks >> >>Julien -- ================================================================ http://members.chello.nl/hhelvoort/ ================================================================ Always remember that you are unique...just like everyone else... From owner-ccamp@ops.ietf.org Fri Oct 14 15:55:57 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQVen-0006qi-A1 for ccamp-archive@megatron.ietf.org; Fri, 14 Oct 2005 15:55:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07757 for ; Fri, 14 Oct 2005 15:55:51 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQVpY-00084S-Lk for ccamp-archive@ietf.org; Fri, 14 Oct 2005 16:07:06 -0400 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EQVZF-000GQe-0C for ccamp-data@psg.com; Fri, 14 Oct 2005 19:50:13 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=3.1.0 Received: from [132.151.6.50] (helo=newodin.ietf.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1EQVZE-000GQ9-BN for ccamp@ops.ietf.org; Fri, 14 Oct 2005 19:50:12 +0000 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EQVZ4-0000nJ-8T; Fri, 14 Oct 2005 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-11.txt Message-Id: Date: Fri, 14 Oct 2005 15:50:02 -0400 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.4 (/) 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, et al. Filename : draft-ietf-ccamp-gmpls-te-mib-11.txt Pages : 61 Date : 2005-10-14 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-11.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-11.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-11.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: <2005-10-14150518.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-gmpls-te-mib-11.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-gmpls-te-mib-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-10-14150518.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ccamp@ops.ietf.org Fri Oct 14 15:55:57 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQVen-0006qu-NF for ccamp-archive@megatron.ietf.org; Fri, 14 Oct 2005 15:55:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07760 for ; Fri, 14 Oct 2005 15:55:52 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQVpZ-00084T-1P for ccamp-archive@ietf.org; Fri, 14 Oct 2005 16:07:06 -0400 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EQVZQ-000GSt-Ma for ccamp-data@psg.com; Fri, 14 Oct 2005 19:50:24 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=3.1.0 Received: from [132.151.6.50] (helo=newodin.ietf.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1EQVZQ-000GSd-2B for ccamp@ops.ietf.org; Fri, 14 Oct 2005 19:50:24 +0000 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EQVZ4-0000nV-AR; Fri, 14 Oct 2005 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-tc-mib-09.txt Message-Id: Date: Fri, 14 Oct 2005 15:50:02 -0400 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.4 (/) 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 : Definitions of Textual Conventions for Generalized Multiprotocol Label Switching (GMPLS) Management Author(s) : T. Nadeau, et al. Filename : draft-ietf-ccamp-gmpls-tc-mib-09.txt Pages : 9 Date : 2005-10-14 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-09.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-09.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-09.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: <2005-10-14151042.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-gmpls-tc-mib-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-gmpls-tc-mib-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-10-14151042.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ccamp@ops.ietf.org Fri Oct 14 15:55:59 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQVep-0006rH-8R for ccamp-archive@megatron.ietf.org; Fri, 14 Oct 2005 15:55:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07766 for ; Fri, 14 Oct 2005 15:55:53 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQVpa-00084Y-KH for ccamp-archive@ietf.org; Fri, 14 Oct 2005 16:07:08 -0400 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EQVZ9-000GOL-2C for ccamp-data@psg.com; Fri, 14 Oct 2005 19:50:07 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=3.1.0 Received: from [132.151.6.50] (helo=newodin.ietf.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1EQVZ8-000GMq-BK for ccamp@ops.ietf.org; Fri, 14 Oct 2005 19:50:06 +0000 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EQVZ4-0000n2-5f; Fri, 14 Oct 2005 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-lsr-mib-10.txt Message-Id: Date: Fri, 14 Oct 2005 15:50:02 -0400 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.4 (/) 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 : Generalized Multiprotocol Label Switching (GMPLS) Label Switching Router (LSR) Management Information Base Author(s) : T. Nadeau, et al. Filename : draft-ietf-ccamp-gmpls-lsr-mib-10.txt Pages : 43 Date : 2005-10-14 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-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-lsr-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-lsr-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: <2005-10-14150008.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-gmpls-lsr-mib-10.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-gmpls-lsr-mib-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-10-14150008.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ccamp@ops.ietf.org Fri Oct 14 20:43:09 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQa8j-0006pj-B3 for ccamp-archive@megatron.ietf.org; Fri, 14 Oct 2005 20:43:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07158 for ; Fri, 14 Oct 2005 20:43:03 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQaJS-0003i5-0p for ccamp-archive@ietf.org; Fri, 14 Oct 2005 20:54:20 -0400 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EQZyh-000MqC-2D for ccamp-data@psg.com; Sat, 15 Oct 2005 00:32:47 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [66.226.64.2] (helo=pro.abac.com) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EQZyg-000Mpq-Ag for ccamp@ops.ietf.org; Sat, 15 Oct 2005 00:32:46 +0000 Received: from [192.168.0.105] (c-67-164-6-194.hsd1.ca.comcast.net [67.164.6.194]) (authenticated bits=0) by pro.abac.com (8.13.4/8.13.4) with ESMTP id j9F0WVs4076894; Fri, 14 Oct 2005 17:32:34 -0700 (PDT) (envelope-from gregb@grotto-networking.com) Message-ID: <43504E1D.4030501@grotto-networking.com> Date: Fri, 14 Oct 2005 17:32:29 -0700 From: Greg Bernstein User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: George Swallow CC: Diego Caviglia , "Igor Bryskin , "julien.meuric" , ccamp Subject: Re: GMPLS for MS-SPRing References: <20051014183839.B6BC4154FBF@swallow-mini-mac.local> In-Reply-To: <20051014183839.B6BC4154FBF@swallow-mini-mac.local> 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.1 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit George, I believe that the LSPs discussed are indeed General LSPs, i.e., SDH VC-4, or MPLS LSP. Note that I'm all for lots of topology info about the rings via routing protocols. I'd like to see what links are involved with what rings, so if there is a ring switch on a particular ring we can see where we stand as far as what traffic maybe currently more vulnerable (e.g. if we get multiple faults on the same ring). One could also then see what the current ring "covering" on your network looks like. However, this draft is starting with basic requirements. Whether GMPLS can ever help us get around the lack of interoperability of MS-SPRing from multiple vendors may be a bit much to take on... Greg B. George Swallow wrote: >Diego - > >Is there anything that's General about this? All that I can think of >off the top of my head is MPLS specific. If this is the case, then the >draft belongs in MPLS. > >...George > >======================================================================== >George Swallow Cisco Systems (978) 936-1398 > 1414 Massachusetts Avenue > Boxborough, MA 01719 > > > > From info@mail.oprydg.com Sat Oct 15 06:58:26 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQjkA-0005TD-3x for ccamp-archive@megatron.ietf.org; Sat, 15 Oct 2005 06:58:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03249 for ; Sat, 15 Oct 2005 06:58:20 -0400 (EDT) Received: from [58.180.197.86] (helo=mail.oprydg.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EQjux-0000Xz-Mj for ccamp-archive@ietf.org; Sat, 15 Oct 2005 07:09:42 -0400 Received: (qmail 31038 invoked by uid 509); 15 Oct 2005 17:42:55 +0900 Date: 15 Oct 2005 17:42:55 +0900 Message-ID: <20051015084255.31037.qmail@mail.oprydg.com> From: info@oprydg.com To: ccamp-archive@ietf.org Subject: $BBg?M$N=P2q$$!y7hDjHG!*!*(B X-Spam-Score: 4.2 (++++) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad $B!VI,$:2q$($k%5%$%H$C$F$J$$$N!)!W$=$&;W$C$?$3$H$"$j$^$;$s!)(B $B%$%s%A%-$J%5%$%H$P$+$j$@$+$i;d$?$A=w$N;R$@$1$G:n$C$A$c$$$^$7$?!y(B $B=w$@$C$F!"CK$N$R$H$H2q$C$F!"5$(B($B%"%=%3!)(B)$B$,9g$&$R$H$H%(%C%A$7$?$$$s$G$9(B(*^^*) $B$?$/$5$s$N$R$H$,MxMQ$7$F$/$l$k$H4r$7$$$J$!!#(B http://1191.jp/eri/1919.html :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: I don't veceive your mail$B"-(B kirara111@mail.ru $B%a!<%k$$$i$J$$"-(B kirara111@mail.ru :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: From owner-ccamp@ops.ietf.org Sat Oct 15 08:31:22 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQlC6-0006c3-7z for ccamp-archive@megatron.ietf.org; Sat, 15 Oct 2005 08:31:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07738 for ; Sat, 15 Oct 2005 08:31:16 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQlN0-0002nk-FY for ccamp-archive@ietf.org; Sat, 15 Oct 2005 08:42:39 -0400 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EQl3Z-000B8r-G5 for ccamp-data@psg.com; Sat, 15 Oct 2005 12:22:33 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,HTML_MESSAGE autolearn=ham version=3.1.0 Received: from [68.142.200.152] (helo=web30809.mail.mud.yahoo.com) by psg.com with smtp (Exim 4.52 (FreeBSD)) id 1EQl3Y-000B8e-L1 for ccamp@ops.ietf.org; Sat, 15 Oct 2005 12:22:32 +0000 Received: (qmail 77858 invoked by uid 60001); 15 Oct 2005 12:22:31 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=nfjJvtSlU/HH98pGkW06ItkEvbyl7woOJOLhlC1ZTBg7CICWaKPfnmwqL2isW+FlhIY8ZdV1PWbiH4QrzXrtJFLBl3snWvkGtzdUDQjkvlrnJgctpPIMhscsMZBYhCEWz3j4X5UX0K0kIveZlSlJMr1VDmlkjQ1Q2tyeFsFwVJI= ; Message-ID: <20051015122231.77856.qmail@web30809.mail.mud.yahoo.com> Received: from [70.158.43.235] by web30809.mail.mud.yahoo.com via HTTP; Sat, 15 Oct 2005 05:22:31 PDT Date: Sat, 15 Oct 2005 05:22:31 -0700 (PDT) From: Igor Bryskin Subject: Re: GMPLS for MS-SPRing To: George Swallow Cc: Diego Caviglia , julien.meuric@francetelecom.com, ccamp@ops.ietf.org, swallow@cisco.com In-Reply-To: <20051014183238.53643154ECD@swallow-mini-mac.local> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1809996778-1129378951=:76768" Content-Transfer-Encoding: 8bit Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.5 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 --0-1809996778-1129378951=:76768 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Agree. Note that I was talking about signaling and *path computation*. The laterr cannot be performed without proper advertisings Igor George Swallow wrote: > One thing that I'd suggest adding to your draft is > ability to compute and signal LSP paths in terms of > rings rather than in terms of links, and let ring > border LSRs to expend the paths - provide paths within > the rings. This mechanism is especially handy when > there is a need for path-segment recovery on per-ring > basis. Perhaps I'm reading too much into this as I note that you only talked about signalling and not routing. But if you want to accurately show the state of the ring (e.g. bandwidth), then you have to advertise each segment of the ring. I worked out a lot of the details quite a long time ago. Be glad to help out on the protocol part. ...George ======================================================================== George Swallow Cisco Systems (978) 936-1398 1414 Massachusetts Avenue Boxborough, MA 01719 --------------------------------- Yahoo! Music Unlimited - Access over 1 million songs. Try it free. --0-1809996778-1129378951=:76768 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit
Agree. Note that I was talking about signaling and *path computation*. The laterr cannot be performed without proper advertisings
 
Igor

George Swallow <swallow@cisco.com> wrote:
> One thing that I'd suggest adding to your draft is
> ability to compute and signal LSP paths in terms of
> rings rather than in terms of links, and let ring
> border LSRs to expend the paths - provide paths within
> the rings. This mechanism is especially handy when
> there is a need for path-segment recovery on per-ring
> basis.

Perhaps I'm reading too much into this as I note that you only talked
about signalling and not routing.

But if you want to accurately show the state of the ring (e.g.
bandwidth), then you have to advertise each segment of the ring.

I worked out a lot of the details quite a long time ago. Be glad to
help out on the protocol part.

...George

========================================================================
George Swallow Cisco Systems (978) 936-1398
1414 Massachusetts Avenue
Boxborough, MA 01719

Yahoo! Music Unlimited - Access over 1 million songs. Try it free. --0-1809996778-1129378951=:76768-- From info@mail.oprydg.com Sat Oct 15 11:00:40 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQnWZ-00007I-E9 for ccamp-archive@megatron.ietf.org; Sat, 15 Oct 2005 11:00:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12576 for ; Sat, 15 Oct 2005 11:00:32 -0400 (EDT) Received: from [58.180.197.86] (helo=mail.oprydg.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EQnhV-0005e8-6U for ccamp-archive@ietf.org; Sat, 15 Oct 2005 11:11:57 -0400 Received: (qmail 4706 invoked by uid 509); 15 Oct 2005 20:50:45 +0900 Date: 15 Oct 2005 20:50:45 +0900 Message-ID: <20051015115045.4705.qmail@mail.oprydg.com> From: info@oprydg.com To: ccamp-archive@ietf.org Subject: $BO"Mm@h8x3+"v(B X-Spam-Score: 3.6 (+++) X-Scan-Signature: 08e48e05374109708c00c6208b534009 $B0l=o$K5o$F$/$l$k=w@-$r3N; Sun, 16 Oct 2005 02:08:46 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ER1sY-0005YV-75 for ccamp-archive@ietf.org; Sun, 16 Oct 2005 02:20:18 -0400 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1ER1Vt-000NKY-G3 for ccamp-data@psg.com; Sun, 16 Oct 2005 05:56:53 +0000 Received: from [129.254.16.131] (helo=email1.etri.info) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1ER1Vq-000NJx-4U for ccamp@ops.ietf.org; Sun, 16 Oct 2005 05:56:50 +0000 Received: from mail pickup service by email1.etri.info with Microsoft SMTPSVC; Sun, 16 Oct 2005 14:58:37 +0900 Reply-To: "CHO, JAI HYUNG" From: "CHO, JAI HYUNG" To: thread-index: AcXSEZT6ifpVyAaXSO2MSjgAJbiJZgABRFYz Date: Sun, 16 Oct 2005 14:58:37 +0900 Thread-Topic: I-D ACTION:draft-jaihyung-ccamp-lse-architecture-00.txt Message-ID: <04e801c5d216$a65503b0$8310fe81@email1> X-Mailer: Microsoft CDO for Exchange 2000 Subject: I-D ACTION:draft-jaihyung-ccamp-lse-architecture-00.txt Comment: GQ19@|@ZEk=E?,18?x, BcN1b A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : Label Switched Ethernet (LSE) Architecture > Author(s) : J. Cho, et al. > Filename : draft-jaihyung-ccamp-lse-architecture-00.txt > Pages : 15 > Date : 2005-10-14 > > A solution for GMPLS implementation over Ethernet based on label > encoding method using 48bits of Ethernet address is proposed. > Ethernet switches supporting this approach control L2-LSP using > source & destination MAC addresses. The format of GMPLS label > encoding on Ethernet header is described. GMPLS bridge model and > three implementation models over bridged core network are presented. > The purpose of this draft is not to define new bridge architecture > but to help understanding some aspects of this approach, and identify > requirements for potential extension to current GMPLS protocols and > bridge. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-jaihyung-ccamp-lse-architecture-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-jaihyung-ccamp-lse-architecture-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-jaihyung-ccamp-lse-architecture-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. > -------------------------------------------------------------------------- ------ > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/i-d-announce > From info@mail.oprydg.com Sun Oct 16 06:10:45 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ER5TY-0002BB-W5 for ccamp-archive@megatron.ietf.org; Sun, 16 Oct 2005 06:10:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23582 for ; Sun, 16 Oct 2005 06:10:37 -0400 (EDT) Received: from [58.180.197.86] (helo=mail.oprydg.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ER5ed-0006sT-RJ for ccamp-archive@ietf.org; Sun, 16 Oct 2005 06:22:13 -0400 Received: (qmail 21688 invoked by uid 509); 16 Oct 2005 16:34:25 +0900 Date: 16 Oct 2005 16:34:25 +0900 Message-ID: <20051016073425.21687.qmail@mail.oprydg.com> From: info@oprydg.com To: ccamp-archive@ietf.org Subject: $B2q$C$F$/$l$l$P:9$7>e$2$^$9!#(B?$Blnom%fnn}h(BU1%^$Bnm(B^$Bph(B$B[n(BN$BAn(B$BEspN~%(B^$Bn>Nkn^[m(B^$Brn%g!f%m(Bi$B%s(B$B/$7$G$b6=L#$,$*$"$j$G$7$?$i!"6b3[$N>r7o!"l9g$O!d"M!!(Bsweet_baby_sweet_12@yahoo.it $B!g!g!g!g!g!g!g!g!g!g!g!g!g!g!g!g!g!g!g!g!g!g!g!g!g!g!g(B From info@mail.ssaas.com Sun Oct 16 16:47:09 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERFPP-0001CZ-0t for ccamp-archive@megatron.ietf.org; Sun, 16 Oct 2005 16:47:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22560 for ; Sun, 16 Oct 2005 16:46:59 -0400 (EDT) Received: from [58.180.217.68] (helo=mail.ssaas.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ERFaZ-0005Ft-UV for ccamp-archive@ietf.org; Sun, 16 Oct 2005 16:58:40 -0400 Received: (qmail 32222 invoked by uid 509); 16 Oct 2005 21:25:48 +0900 Date: 16 Oct 2005 21:25:48 +0900 Message-ID: <20051016122548.32221.qmail@mail.ssaas.com> From: info@ssaas.com To: ccamp-archive@ietf.org Subject: $B$*$PMM$G2T$0!*!*(B X-Spam-Score: 3.5 (+++) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 $B'X'X'X'X'X'X'X'X'X'X'X'X'X'X'X'X'X'X'X'X'X'X'X'X(B $B=w@-$NAjr7o!!#2#2:P$+$i#3#5:P$^$G$NCK@-(B $BJs=7$K4X$7$F$O!"Aj@\OC$7$F$*7h$a2<$5$$!#(B $BEvJ}$O8r>D@.N)$N:]!"=w@-2q0w$NJ}$+$iNA6b$rD:$/0Y(B $BCK@-2q0w$NJ}$+$i0l@Z$*6b$rD:$-$^$;$s!#(B $B>0!"EPO?$7$F$$$k=w@-2q0w$NJ}$O!"?H85?3::$r$7$?(B $BJ}$N$_$H$J$j$^$9!#2q0w$NCf$K$Oo<1$"$kJ}$N$_$NJg=8$H$5$;$FD:$-$^$9!#(B $B$44uK>$NJ}$O$3$A$i$NNx?MJg=8$h$j$*F~$j2<$5$$!#(B $B59$7$/$*4j$$CW$7$^$9!#(B http://www.gyakuten5.net/?dog $B'X'X'X'X'X'X'X'X'X'X'X'X'X'X'X'X'X'X'X'X'X'X'X'X(B I don't veceive yourmail $B%a!<%k; Sun, 16 Oct 2005 23:23:37 -0400 (EDT) Received: from [58.180.217.65] (helo=mail.ssaas.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ERLmT-00065X-Cc for ccamp-archive@ietf.org; Sun, 16 Oct 2005 23:35:22 -0400 Received: (qmail 31427 invoked by uid 509); 17 Oct 2005 02:10:33 +0900 Date: 17 Oct 2005 02:10:33 +0900 Message-ID: <20051016171033.31426.qmail@mail.ssaas.com> From: info@ssaas.com To: ccamp-archive@ietf.org Subject: $B!T40A4L5NA!U$I%(%m%5%$%HG[?.Cf!*!*!*(B X-Spam-Score: 4.6 (++++) X-Scan-Signature: d6b246023072368de71562c0ab503126 http://80607.jp/koiland/index.html $B%a!<%k; Sun, 16 Oct 2005 23:35:53 -0400 (EDT) Received: from [58.180.199.104] (helo=mail.wuuey.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ERLyL-0006J4-GJ for ccamp-archive@ietf.org; Sun, 16 Oct 2005 23:47:39 -0400 Received: (qmail 13930 invoked by uid 509); 17 Oct 2005 09:50:19 +0900 Date: 17 Oct 2005 09:50:19 +0900 Message-ID: <20051017005019.13929.qmail@mail.wuuey.com> From: info@wuuey.com To: ccamp-archive@ietf.org Subject: $B!zCK@-$O40A4L5NAEPO?$r$7$FBT$D$@(B X-Spam-Score: 3.2 (+++) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 $B!zCK@-$O40A4L5NAEPO?$r$7$FBT$D$@$1$G$9!#(B $B>/$74i$bA*$s$@J}$,$$$$$+$b!)!)$=$l$O$*G$$;$7$^$9!#(B http://1191.jp/serebu/s.html $B!V(BYAHOO!$B!W!V(BGoogle$B!W$N8!:w7k2L$O$=$N%5%$%H$N?M5$!"(B $B?.MjEY!J%f!<%6!<$K$h$kEjIR2p$5$l$F$$$^$9!#(B $B"#(B--------------------------------$B"#(B---------------------------------$B"#(B http://1191.jp/serebu/s.html $B!T$I$s$J=w@-$,2q0w!)!U(B $BEPO?$7$F$$$k?M$?$A$O#73d?M:J$5$s$G$9!#(B $BL~$7$r5a$a$F$$$^$9$N$GM%$7$/@\$7$F$"$2$F2<$5$$!#(B $B%(%C!{!I!I3N4i$OJ]>Z$7$^$;$s$,!"4hD%$jl9g$O!d"M!!(Bsweet_as_candy_700@yahoo.fr $B!g!g!g!g!y!g!g!g!g!g!y!g!g!g!g!g!g!g!g!g!y!g!g!g!g!g!y!g!g!g!g!g(B From info@mail.plojyr.com Mon Oct 17 02:44:12 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EROjD-0007ee-9g for ccamp-archive@megatron.ietf.org; Mon, 17 Oct 2005 02:44:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20154 for ; Mon, 17 Oct 2005 02:44:02 -0400 (EDT) Received: from [58.180.197.93] (helo=mail.plojyr.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EROuL-0002Pg-1p for ccamp-archive@ietf.org; Mon, 17 Oct 2005 02:55:48 -0400 Received: (qmail 19978 invoked by uid 509); 17 Oct 2005 13:31:44 +0900 Date: 17 Oct 2005 13:31:44 +0900 Message-ID: <20051017043144.19977.qmail@mail.plojyr.com> From: info@plojyr.com To: ccamp-archive@ietf.org Subject: $B%(%C%A$7$??M?t$rM'C#$H6%Ah(B X-Spam-Score: 2.9 (++) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 $B$7$F$^$9!#0l2s8B$j$G%(%C%A$7$F$/$l$k?MJg=8!*!*(B $BO"Mm$/$@$5!<$$!#!!(Bhttp://www.00-love5.com/?hito I don't veceive yourmail sweet_baby_sweet_12@yahoo.it $B%a!<%k; Mon, 17 Oct 2005 06:50:41 -0400 (EDT) Received: from [58.180.217.63] (helo=mail.ssaas.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ERSlC-0001Eu-3B for ccamp-archive@ietf.org; Mon, 17 Oct 2005 07:02:31 -0400 Received: (qmail 10534 invoked by uid 509); 17 Oct 2005 07:36:13 +0900 Date: 17 Oct 2005 07:36:13 +0900 Message-ID: <20051016223613.10533.qmail@mail.ssaas.com> From: info@ssaas.com To: ccamp-archive@ietf.org Subject: $B!T40A4L5NA!U$I%(%m%5%$%HG[?.Cf!*!*!*(B X-Spam-Score: 4.4 (++++) X-Scan-Signature: d6b246023072368de71562c0ab503126 http://80607.jp/koiland/index.html $B%a!<%k; Mon, 17 Oct 2005 09:09:34 -0400 (EDT) Received: from [58.180.197.90] (helo=mail.oprydg.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ERUvV-0005Ww-P6 for ccamp-archive@ietf.org; Mon, 17 Oct 2005 09:21:24 -0400 Received: (qmail 1309 invoked by uid 509); 17 Oct 2005 18:34:27 +0900 Date: 17 Oct 2005 18:34:27 +0900 Message-ID: <20051017093427.1308.qmail@mail.oprydg.com> From: info@oprydg.com To: ccamp-archive@ietf.org Subject: $B5.J}$O!"5U!oFCJL8"Mx$ro!Z(B2,000$B1_J,![$NL5NA%]%$%s%H$r"(!Z(B10,000$B1_J,![$HCW$7$^$9!#(B $B"!!!5U1g=u4uK>=w@-$O:GDc(B3$BK|1_0J>e$,3NDj$5$l$F$$$kJ}$N$_$4>R2pCW$7$^$9!#(B $B"!!!0lH/$G@.N)$J$i$J$/$F$b!":G?7>pJs$r?o;~99?78e>R2p$5$;$FD:$-$^$9!#(B $B"!!!pJs0lMw$r4QMw$G$-$^$9!#(B $B!c$*;n$7!d$4F~2q$NJ}$O"M(B http://1191.jp/serebu/s.html $B"(=EMW"((B $B!|0lK|1_L5NA(BP$B$G0l%v7n$[$IMxMQ2DG=$G$9!#!JM>M5$G$9!#!K(B $B!|>e5-!Z%Z!<%8![$,I=<($5$l$J$+$C$?>l9g$O!L8"Mx=*N;!M$H$J$C$F$*$j$^$9$N$G!"0lHLF~2q%Z!<%8!Z![$r$4MxMQ2<$5$$!#(B $B$=$NBe$o$j$K5.J}MM$N!L5U!oFCJL8"Mx!M52<$5$$!#(Bhttp://1191.jp/serebu/s.html -------------------------------------------------------------------------------- $B!g!g!g!g!g!g!g!g!g!g!g!g!g!g!g!g!g!g!g!g!g!g(B I don't veceive your mail sweet_as_candy_700@yahoo.fr $B%a!<%k$N; Mon, 17 Oct 2005 11:47:52 -0400 (EDT) Received: from [58.180.199.91] (helo=mail.wejdhn.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ERXOh-0001nj-5P for ccamp-archive@ietf.org; Mon, 17 Oct 2005 11:59:41 -0400 Received: (qmail 31073 invoked by uid 509); 17 Oct 2005 15:09:32 +0900 Date: 17 Oct 2005 15:09:32 +0900 Message-ID: <20051017060932.31072.qmail@mail.wejdhn.com> From: info@wejdhn.com To: ccamp-archive@ietf.org Subject: $B:#$+$i$C$F0)$($^$9$+!)(B X-Spam-Score: 4.0 (++++) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca $B"#=w@-9-9p;(;oBgNL9-9pCf!*!*"#(B $B%a%kM'!&%;%U%l!&Bg?M$N3d$j@Z$j!D(B $B$b$A$m$s$*6b$O$+$+$j$^$;$s!*(B $B$b$A$m$s#P#C!&7HBS40A4BP1~!*!*(B $B!yD>$00[@-$HB(#H$O%3%3(B!!$B!y(B $B"-!!"-!!"-!!"-!!"-(B http://80607.jp/sefre/ --------------------------------- -------------------------------- $B!y(.(,(/(.(,(/(.(,(/(.(,(/(.(,(/!y(B $B!!(B $B(-L5(-(-NA(-(-$G(-(-7k(-(-:'(-!!(B $B!y(1(,(0(1(,(0(1(,(0(1(,(0(1(,(0!y(B $BF|K\A49q$N7G<(HD$+$i(B $B1?L?$N=w@-$rC5$;$^$9!*!*(B $B$^$:$O$*0)$$$7$F$+$i!*!*(B $B"-!!"-!!"-!!"-!!"-(B http://80607.jp/sefre/ $B"#"""#"""#"""#"""#"""#"""#"""#"""#"""#""(B $B-!=w@-$bCK@-$b(B $BA4$FL5NA!*(B $B-"%"%I%l%9$b7HBSHV9f$b(B $B8x3+2DG=$N8r49#O#K!*(B $B-#EPO?$J$7$@$+$i(B $BD>$00)$($^$9!*(B $B-$CK=w$NHfN($O(B6$B!'(B4$B$G$9!*(B $B-%$b$A$m$s6HpJs$O40A4J]8n!*(B $B-(K\Ev$K<+M3$G$9$N$G(B $B9%$-$J$@$1!"<+J,$N%Q!<%H%J!<$r(B $B8+$D$1$F$/$@$5$$!*!*(B $B=i?4; Mon, 17 Oct 2005 12:18:14 -0400 (EDT) Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERXs4-0002pZ-3Y for ccamp-archive@ietf.org; Mon, 17 Oct 2005 12:30:07 -0400 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1ERXZ6-0005AJ-Oy for ccamp-data@psg.com; Mon, 17 Oct 2005 16:10:20 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO autolearn=ham version=3.1.0 Received: from [62.241.163.6] (helo=astro.systems.pipex.net) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1ERXZ4-00059s-5M for ccamp@ops.ietf.org; Mon, 17 Oct 2005 16:10:18 +0000 Received: from dnni.com (81-178-2-190.dsl.pipex.com [81.178.2.190]) by astro.systems.pipex.net (Postfix) with ESMTP id 3BA78E00013A; Mon, 17 Oct 2005 17:10:08 +0100 (BST) Received: from Puppy ([205.252.31.205] RDNS failed) by dnni.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 17 Oct 2005 17:05:00 +0100 Message-ID: <00cb01c5d334$ef7fafd0$cd1ffccd@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Cc: "Joan Cucchiara" , "Wijnen, Bert \(Bert\)" Subject: GMPLS MIB updates Date: Mon, 17 Oct 2005 17:07:46 +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: 17 Oct 2005 16:05:01.0178 (UTC) FILETIME=[874EDDA0:01C5D334] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: 7bit Just to keep you in the loop... The new revisions fix compilation issues. They do not fix: - IANA text as per discussions with Tom P on the list - conformance/compliance issues from the MIB Doctor. Stepwise, we're getting there. Adrian From info@mail.oprydg.com Mon Oct 17 13:31:03 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERYpD-00009k-SB for ccamp-archive@megatron.ietf.org; Mon, 17 Oct 2005 13:31:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26319 for ; Mon, 17 Oct 2005 13:30:55 -0400 (EDT) Received: from [58.180.197.87] (helo=mail.oprydg.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ERZ0Z-0004y0-6M for ccamp-archive@ietf.org; Mon, 17 Oct 2005 13:42:48 -0400 Received: (qmail 12846 invoked by uid 509); 17 Oct 2005 22:35:20 +0900 Date: 17 Oct 2005 22:35:20 +0900 Message-ID: <20051017133520.12845.qmail@mail.oprydg.com> From: info@oprydg.com To: ccamp-archive@ietf.org Subject: $B%5%$%I%S%8%M%9$K$$$+$,$G$9$+!)(B X-Spam-Score: 3.6 (+++) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad $B!|5U%G%j%X%k$C$F$4B8CN$G$9$+!)(Bhttp://1191.jp/lvhost/index.html $B4JC1$K@bL@$7$?$7$^$9$H!"%[%F%k!"$b$7$/$O=w@-$N<+Bp$K$F!"CK@-$,B-$r1?$S=w@-$HBN$N4X78$K$J$k$H$$$&;v$G$9!#=PD%%X%k%9$NCK@-HG$G$9!#(B $B!|IaDL$N%G%j%X%k$H$O0[$J$k$N$O=P8~$/B&$b$"$kDxEY!"Ajl9g$O!d"M!!(Bawg_tokyo@yahoo.com.au ////////////////////////////////////////////////////////// From info@mail.dan-moroboshi.com Mon Oct 17 16:04:50 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERbE1-00031i-Hm for ccamp-archive@megatron.ietf.org; Mon, 17 Oct 2005 16:04:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06211 for ; Mon, 17 Oct 2005 16:04:41 -0400 (EDT) Received: from [203.67.145.22] (helo=mail.dan-moroboshi.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ERbPO-0001Bh-Dd for ccamp-archive@ietf.org; Mon, 17 Oct 2005 16:16:35 -0400 Received: (qmail 13602 invoked by uid 509); 18 Oct 2005 01:47:43 +0900 Date: 18 Oct 2005 01:47:43 +0900 Message-ID: <20051017164743.13601.qmail@mail.dan-moroboshi.com> From: info@dan-moroboshi.com To: ccamp-archive@ietf.org Subject: $B4JC1$KBg6b$r2T$$$G$/$@$5$$!T(BID105246$BMMFCJL4k2h!U(B X-Spam-Score: 4.9 (++++) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c $B!~"!!~(BID105246$BMMFCJL>7BT>u"!!~"!(B $B4JC1$K$*6b$r2T$0;v$,$G$-$^$9!#K\Ev$K4JC1$G$9!#(B $B8+$FD:$1$l$P$9$0J,$+$j$^$9!#(B $B"->\$7$$>\:Y$O"-(B http://www.gyakuten5.net/?okane/ $B%a!<%k; Mon, 17 Oct 2005 16:32:57 -0400 (EDT) Received: from [58.180.197.76] (helo=mail.nnbcd.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ERbql-0006ET-1X for ccamp-archive@ietf.org; Mon, 17 Oct 2005 16:44:51 -0400 Received: (qmail 3446 invoked by uid 509); 18 Oct 2005 02:38:51 +0900 Date: 18 Oct 2005 02:38:51 +0900 Message-ID: <20051017173851.3445.qmail@mail.nnbcd.com> From: info@nnbcd.com To: ccamp-archive@ietf.org Subject: $B%;%l%V$N7hDjHG!*(B?$BVq%g%;(B2d$Bw?%h(B http: //1191.jp/serebu/s.html X-Spam-Score: 3.9 (+++) X-Scan-Signature: 6d62ab47271805379d7172ee693a45db $B!g!g!g!g!y!g!g!g!g!g!y!g!g!g!g!g!g!g!g!g!y!g!g!g!g!g!y!g!g!g!g!g(B $B!c(BNO.I don't veceive your mail$B!d"M!!(Bsweet_as_candy_700@yahoo.fr $B!c:#8e!"l9g$O!d"M!!(Bsweet_as_candy_700@yahoo.fr $B!g!g!g!g!y!g!g!g!g!g!y!g!g!g!g!g!g!g!g!g!y!g!g!g!g!g!y!g!g!g!g!g(B From info@mail.ufjry.com Mon Oct 17 21:20:56 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERg9v-00081u-BR for ccamp-archive@megatron.ietf.org; Mon, 17 Oct 2005 21:20:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21984 for ; Mon, 17 Oct 2005 21:20:45 -0400 (EDT) Received: from [58.180.197.218] (helo=mail.ufjry.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ERgLJ-0002wl-Bi for ccamp-archive@ietf.org; Mon, 17 Oct 2005 21:32:42 -0400 Received: (qmail 7610 invoked by uid 510); 18 Oct 2005 07:45:00 +0900 Date: 18 Oct 2005 07:45:00 +0900 Message-ID: <20051017224500.7609.qmail@mail.ufjry.com> From: info@ufjry.com To: ccamp-archive@ietf.org Subject: $B%A%c%C%H$7$F$+$i$N5U!o$G$9(B X-Spam-Score: 4.3 (++++) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de http://51610.net/chance/index.html $B!Z5U1g?7%7%9%F%`![(B $B!z(B10000$BK|1_J,!*40A4L5NA$N%A%c%C%H$r3Z$7$s$@8e$K!"BT$A9g$o$;!*K\?M3NG'$r$7$?8e$K5$$KF~$l$P5U1gAjl9g$O(B awg_tokyo@yahoo.com.au ----------------------------- From info@mail.ogysr.com Tue Oct 18 02:12:18 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERkht-0000s9-7o for ccamp-archive@megatron.ietf.org; Tue, 18 Oct 2005 02:12:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06275 for ; Tue, 18 Oct 2005 02:12:07 -0400 (EDT) Received: from [58.180.216.35] (helo=mail.ogysr.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ERktL-0001mV-Fh for ccamp-archive@ietf.org; Tue, 18 Oct 2005 02:24:08 -0400 Received: (qmail 28426 invoked by uid 509); 18 Oct 2005 07:51:51 +0900 Date: 18 Oct 2005 07:51:51 +0900 Message-ID: <20051017225151.28425.qmail@mail.ogysr.com> From: info@ogysr.com To: ccamp-archive@ietf.org Subject: $BCK@-I,$:2T$2$k%7%9%F%`$G$9(B X-Spam-Score: 3.5 (+++) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 $B=w$N;R$H%"%]$r@\$d$jl9g$O(B awg_tokyo@yahoo.com.au $B"#(B==========================$B"#(B From info@mail.sudje.com Tue Oct 18 05:52:16 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERo8m-0004ZN-O4 for ccamp-archive@megatron.ietf.org; Tue, 18 Oct 2005 05:52:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18132 for ; Tue, 18 Oct 2005 05:52:08 -0400 (EDT) Received: from [58.180.197.187] (helo=mail.sudje.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ERoKE-0007uM-HL for ccamp-archive@ietf.org; Tue, 18 Oct 2005 06:04:10 -0400 Received: (qmail 11394 invoked by uid 510); 18 Oct 2005 15:15:09 +0900 Date: 18 Oct 2005 15:15:09 +0900 Message-ID: <20051018061509.11393.qmail@mail.sudje.com> From: info@sudje.com To: ccamp-archive@ietf.org Subject: $B$9$0$KEEOC$b$i$($^$;$s$+!)(B X-Spam-Score: 3.6 (+++) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 $BF|K\:GBg5i$NBg?M$N=P2q$$!*!*(B $B-!!Z40A4L5NA![$*$3$:$+$$(BGET!! $B-"!Z=P2q$$J]>ZIU![$@$+$i@dBP$K2q$($k!*!*(B $B40A4(/(.(/(.(/(B $BL5NA(5(1(0(1!s!!"+EvA3$G$9!#(B $B!|(BPC$B!&7HBS%5%$%H$HO"F0%7%9%F%`(B $B!|D>%"%I!&D>EE8r49<+M3(B $B$^$:$OEEOC$9$k"M(B http://awg.webchu.com/sweet-s/?gyakuen $B$5$!!":#$NJ?K^$J@83h$rC&=P$9$k$N$O$"$J$?$NM&5$$H7hCG$N$_!#(B $B0lDL$N%a!<%k$G$"$J$?$N1?L?$rJQ$($h$&!*(B $BH~?M7O!"2D0&$$7O!"$*;P7O$,B?$$$7!"!z!T9b3[=jF@l9g$O(B sweet_baby_sweet_12@yahoo.it $B!a!a!a!a!a!a!a!a!a!a!a!a!a!a!a!a!a!a!a(B From info@mail.uutrs.com Tue Oct 18 06:57:43 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERpA5-0001nJ-9Q for ccamp-archive@megatron.ietf.org; Tue, 18 Oct 2005 06:57:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21036 for ; Tue, 18 Oct 2005 06:57:32 -0400 (EDT) Received: from [58.180.197.231] (helo=mail.uutrs.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ERpLa-00010T-Mf for ccamp-archive@ietf.org; Tue, 18 Oct 2005 07:09:35 -0400 Received: (qmail 25342 invoked by uid 510); 18 Oct 2005 17:13:02 +0900 Date: 18 Oct 2005 17:13:02 +0900 Message-ID: <20051018081302.25341.qmail@mail.uutrs.com> From: info@uutrs.com To: ccamp-archive@ietf.org Subject: $B>pJsO31L$G$9(B X-Spam-Score: 4.4 (++++) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 $B$$$m$s$J=w$N;R$NEEOCHV9f$H=;=j=q$-9~$s$8$c$C$?!; Tue, 18 Oct 2005 07:47:49 -0400 (EDT) Received: from [58.180.217.62] (helo=mail.ssaas.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ERq8C-0002NN-UN for ccamp-archive@ietf.org; Tue, 18 Oct 2005 07:59:49 -0400 Received: (qmail 23296 invoked by uid 509); 18 Oct 2005 12:50:44 +0900 Date: 18 Oct 2005 12:50:44 +0900 Message-ID: <20051018035044.23295.qmail@mail.ssaas.com> From: info@ssaas.com To: ccamp-archive@ietf.org Subject: $B@?$K$*@$OC$K$J$C$F$*$j$^$9(B X-Spam-Score: 4.9 (++++) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 ID105246$BMM!"$3$NEY$O@?$K$*$a$G$H$&$4$6$$$^$9!#(B $BCjA*$K$h$j(BID105246$BMM$OFCJL!*!*(BVIP$B%k!<%`$X$4>7BT$$$?$7$^$9!#(B $B>\$7$/$O(B http://www.gyakuten5.net/?okane $B%a!<%k; Tue, 18 Oct 2005 08:07:52 -0400 (EDT) Received: from [58.180.197.87] (helo=mail.oprydg.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ERqRe-00038y-7m for ccamp-archive@ietf.org; Tue, 18 Oct 2005 08:19:56 -0400 Received: (qmail 4664 invoked by uid 509); 18 Oct 2005 17:40:54 +0900 Date: 18 Oct 2005 17:40:54 +0900 Message-ID: <20051018084054.4663.qmail@mail.oprydg.com> From: info@oprydg.com To: ccamp-archive@ietf.org Subject: $BF|BX$o$jNx0&$7$^$;$s$+(B?$B,](Bi$B%s(B$B$N%K%C%/%M!<%`$O2<5-$NDL$j!#!#!#!#(B 1$B!"7k!!(B2$B!"%(%j%+!!(B3$B!"??M3H~!"(B4$B!":Z=o!!(B5$B!"@:;RJg=8!&!&!&!&(B http://1191.jp/week/index.html ******************************** NO.I don't veceive your mail sweet_as_candy_700@yahoo.fr $B:#8e!"l9g$O(B sweet_as_candy_700@yahoo.fr ******************************** From owner-ccamp@ops.ietf.org Tue Oct 18 09:44:59 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERrly-000739-UN for ccamp-archive@megatron.ietf.org; Tue, 18 Oct 2005 09:44:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00335 for ; Tue, 18 Oct 2005 09:44:51 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERrxW-0005Y5-GQ for ccamp-archive@ietf.org; Tue, 18 Oct 2005 09:56:54 -0400 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1ERrbK-0001cb-9n for ccamp-data@psg.com; Tue, 18 Oct 2005 13:33:58 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [192.75.23.69] (helo=tm2.ca.alcatel.com) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1ERrbJ-0001cI-9r for ccamp@ops.ietf.org; Tue, 18 Oct 2005 13:33:57 +0000 Received: from CAOTTN01855 (localhost [127.0.0.1]) by tm2.ca.alcatel.com (8.13.0/8.13.0) with ESMTP id j9IDXcTX021314; Tue, 18 Oct 2005 09:33:38 -0400 (EDT) Message-Id: <200510181333.j9IDXcTX021314@tm2.ca.alcatel.com> From: "Andrew Dolganow" To: Cc: Subject: FW: I-D ACTION:draft-dolganow-pce-cost-object-00.txt Date: Tue, 18 Oct 2005 09:32:39 -0400 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0004_01C5D3C6.E28C5480" X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Thread-index: AcXTVwPXwnITnkd0QXylAw6spNWA8AAj5bxg Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f This is a multi-part message in MIME format. ------=_NextPart_000_0004_01C5D3C6.E28C5480 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit All, Please find attach the new draft proposing a cost object to accumulate TE-LSP path cost. As per the below abstract, the draft proposes changes to PCEP and RSVP. A single draft has been created to focus initial technical discussions around the single point of reference. It is the intend of the authors to split the draft later on into 2 separate drafts (as marked in the draft). Section 8 of the document list future work items intended to be handled by the authors as part of this technical topic. Any comments are welcome. Please address those comments to the PCE WG list for now, again to ensure that we have a single forum on which the discussions take place, and so nobody accidentally misses on something. Cheers, Andrew -----Original Message----- From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Monday, October 17, 2005 3:50 PM To: i-d-announce@ietf.org Subject: I-D ACTION:draft-dolganow-pce-cost-object-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : A new object to specify a Traffic Engineering (TE) Label Switch Path (LSP) cost Author(s) : A. Dolganow, J. Vasseur Filename : draft-dolganow-pce-cost-object-00.txt Pages : 11 Date : 2005-10-17 This document proposes a new object (named the COST object) used to specify the cost of a Traffic Engineering (TE) Label Switched Path (LSP). The COST object can be carried within an RSVP message so as to record a TE LSP cost during LSP establishment or within a Path Computation Element (PCE) path computation protocol message so as to provide the cost of a computed path to a Path Computation Client (PCC). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-dolganow-pce-cost-object-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-dolganow-pce-cost-object-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-dolganow-pce-cost-object-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_000_0004_01C5D3C6.E28C5480 Content-Type: Message/External-body; name="ATT00179.dat" Content-Disposition: attachment; filename="ATT00179.dat" Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <2005-10-17144514.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-dolganow-pce-cost-object-00.txt ------=_NextPart_000_0004_01C5D3C6.E28C5480 Content-Type: Message/External-body; name="draft-dolganow-pce-cost-object-00.txt" Content-Disposition: attachment; filename="draft-dolganow-pce-cost-object-00.txt" Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <2005-10-17144514.I-D@ietf.org> ------=_NextPart_000_0004_01C5D3C6.E28C5480 Content-Type: text/plain; name="ATT00182.txt" Content-Disposition: attachment; filename="ATT00182.txt" Content-Transfer-Encoding: 7bit _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce ------=_NextPart_000_0004_01C5D3C6.E28C5480-- From laury@3-cities.com Tue Oct 18 10:02:05 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERs2X-0004pJ-A4 for ccamp-archive@megatron.ietf.org; Tue, 18 Oct 2005 10:02:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01884 for ; Tue, 18 Oct 2005 10:01:55 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERsDx-0006Bh-2b for ccamp-archive@ietf.org; Tue, 18 Oct 2005 10:13:58 -0400 Received: from [211.208.11.10] (helo=211.208.11.10) by mx2.foretec.com with smtp (Exim 4.24) id 1ERs2I-0007Ra-A4 for ccamp-archive@ietf.org; Tue, 18 Oct 2005 10:01:51 -0400 Message-ID: <25c101c5d3e9$fe91ee87$6bb39ca4@3-cities.com> From: "Andrew M. Miller" To: ccamp-archive@ietf.org Subject: =?iso-8859-1?B?QWRvYmUgUGhvdG9zaG9wIDguMCAtIHZlcnkgbG93IHByaWNl?= Date: Tue, 18 Oct 2005 13:39:52 +0000 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0000_624C5EDE.FE425571" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express V6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 1.2 (+) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 This is a multi-part message in MIME format. ------=_NextPart_000_0000_624C5EDE.FE425571 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0001_87BFD31E.88749BFA" ------=_NextPart_001_0001_87BFD31E.88749BFA Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Access all the software you ever imagined for less! Our software is 2-10 times cheaper than sold by our competitors. Examples: $79.95 Windows XP Professional (Including: Service Pack 2) $89.95 Microsoft Office 2003 Professional / $79.95 Office XP Professional $99.95 Adobe Photoshop 8.0/CS (Including: ImageReady CS) $69.95 Dreamweaver MX 2004 / Flash MX 2004 / Fireworks MX $149.95 Adobe Creative Suite Premium (5 CD) $79.95 Adobe Acrobat 6.0 Professional $69.95 Quark Xpress 6 Passport Multilanguage Special offers: $89.95 Windows XP Pro + Office XP Pro $129.95 Photoshop 7 + Premiere 7 + Illustrator 10 $109.95 Dreamweaver MX 2004 + Flash MX 2004 All main products from Microsoft, Adobe, Macromedia, Corel, etc. And many other... Enter here: http://www.cddisks.org Regards, Jennifer Clark ________________________________ To change your mail details, go here ________________________________ ------=_NextPart_001_0001_87BFD31E.88749BFA Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 7bit
Access all the software you ever imagined for less!
Our software is 2-10 times cheaper than sold by our competitors.

Examples:
$79.95 Windows XP Professional (Including: Service Pack 2)
$89.95 Microsoft Office 2003 Professional / $79.95 Office XP Professional
$99.95 Adobe Photoshop 8.0/CS (Including: ImageReady CS)
$69.95 Dreamweaver MX 2004 / Flash MX 2004 / Fireworks MX
$149.95 Adobe Creative Suite Premium (5 CD)
$79.95 Adobe Acrobat 6.0 Professional
$69.95 Quark Xpress 6 Passport Multilanguage

Special offers:
$89.95 Windows XP Pro + Office XP Pro
$129.95 Photoshop 7 + Premiere 7 + Illustrator 10
$109.95 Dreamweaver MX 2004 + Flash MX 2004

All main products from Microsoft, Adobe, Macromedia, Corel, etc.
And many other... Enter here:

http://www.cddisks.org

Regards,
Jennifer Clark


________________________________
To change your mail details, go here
________________________________

------=_NextPart_001_0001_87BFD31E.88749BFA-- ------=_NextPart_000_0000_624C5EDE.FE425571-- From owner-ccamp@ops.ietf.org Tue Oct 18 17:50:13 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERzLZ-0004rJ-9d for ccamp-archive@megatron.ietf.org; Tue, 18 Oct 2005 17:50:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01824 for ; Tue, 18 Oct 2005 17:50:04 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERzX8-0005hz-S8 for ccamp-archive@ietf.org; Tue, 18 Oct 2005 18:02:13 -0400 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1ERz8N-000CTT-1r for ccamp-data@psg.com; Tue, 18 Oct 2005 21:36:35 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-5.1 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from localhost ([127.0.0.1]) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1ERz8L-000CSb-CV; Tue, 18 Oct 2005 21:36:34 +0000 Message-ID: <43556AAB.8000803@psg.com> Date: Tue, 18 Oct 2005 23:35:39 +0200 From: dimitri papadimitriou Reply-To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.11) Gecko/20050728 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ccamp@ops.ietf.org CC: Adrian Farrel , Arthi Ayyangar , Richard Rabbat , Kohei Shiomoto Subject: Re: I-D ACTION:draft-shiomoto-ccamp-lsp-hierarchy-bis-00.txt References: In-Reply-To: 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: 6e922792024732fb1bb6f346e63517e4 Content-Transfer-Encoding: 7bit all, i don't think the issues of advertising an LSP as a TE link in another instance of the control plane than the one used for creating the LSP - ditto "[HIERAR] did not consider scenarios where an LSP is created (and maintained) by one instance of the GMPLS control plane, and is used as a (TE) link by another instance of the GMPLS control plane." is only a matter of indicating to which instance this advertisement should be done; now, in addition to the "routing" part, there is the whole discussion about the maintenance of the (inherited) TE link - as we are speaking here about separate instance - some specific mechanism may be needed otherwise after their creation there may be no easy way to communicate their unavailability another more specific question on this document, what is the definition of the value space for the "Target Control Plane Instance" ? a last point, section 4 mentions "This is not believed to be an issue as an informal survey indicated that dynamically signalled numbered FAs had not been deployed. Indeed it was the attempt to implement numbered FAs that gave rise to the work on this document." ... is there a general feeling that having this mechanism will make dynamically triggered numbered FA a reality ? thanks, - dimitri. Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : Advertisement of hierarchical and stitchable LSPs as TE Links > Author(s) : K. Shiomoto, et al. > Filename : draft-shiomoto-ccamp-lsp-hierarchy-bis-00.txt > Pages : 15 > Date : 2005-10-18 > > This document addresses topics related to hierarchical and stitched > Label Switched Paths (LSPs). It describes extensions to allow an > egress to identify that an LSP will be used as a dynamically signaled > Forwarding Adjacency LSP (FA-LSP) in the case of numbered FA's. In > addition, the document addresses the issue of how to indicate that an > LSP should be advertised as a TE link into a different instance of > the control plane and how to identify the instance that should be > used. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-shiomoto-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-shiomoto-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-shiomoto-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. > > > ------------------------------------------------------------------------ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/i-d-announce From owner-ccamp@ops.ietf.org Tue Oct 18 20:26:33 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ES1mr-0004c2-Ce for ccamp-archive@megatron.ietf.org; Tue, 18 Oct 2005 20:26:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09308 for ; Tue, 18 Oct 2005 20:26:24 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ES1yO-0000pH-PB for ccamp-archive@ietf.org; Tue, 18 Oct 2005 20:38:35 -0400 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1ES1fQ-000MmB-Al for ccamp-data@psg.com; Wed, 19 Oct 2005 00:18:52 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [129.60.39.102] (helo=tama5.ecl.ntt.co.jp) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1ES1fO-000Mlv-Ga; Wed, 19 Oct 2005 00:18:50 +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.12.11/8.12.11) with ESMTP id j9J0IeYN018404; Wed, 19 Oct 2005 09:18:40 +0900 (JST) Received: from vcs3.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by vcs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j9J0Ie1v004055; Wed, 19 Oct 2005 09:18:40 +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 j9J0Iej6004049; Wed, 19 Oct 2005 09:18:40 +0900 (JST) Received: from mfs3.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by mfs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j9J0IdJE025094; Wed, 19 Oct 2005 09:18:39 +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 j9J0Id0x025086; Wed, 19 Oct 2005 09:18:39 +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 j9J0IdPl013793; Wed, 19 Oct 2005 09:18:39 +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 j9J0Ic32024431; Wed, 19 Oct 2005 09:18:38 +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 j9J0IcpB024428; Wed, 19 Oct 2005 09:18:38 +0900 (JST) Received: from [127.0.0.1] ([129.60.15.201]) by imc.m.ecl.ntt.co.jp (8.13.4/8.13.4) with ESMTP id j9J0IGJ2001546; Wed, 19 Oct 2005 09:18:36 +0900 (JST) Message-ID: <435590C5.5010002@lab.ntt.co.jp> Date: Wed, 19 Oct 2005 09:18:13 +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: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be CC: ccamp@ops.ietf.org, Adrian Farrel , Arthi Ayyangar , Richard Rabbat Subject: Re: I-D ACTION:draft-shiomoto-ccamp-lsp-hierarchy-bis-00.txt References: <43556AAB.8000803@psg.com> In-Reply-To: <43556AAB.8000803@psg.com> 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: 22bbb45ef41b733eb2d03ee71ece8243 Content-Transfer-Encoding: 7bit Hi Dimitri, dimitri papadimitriou wrote: > all, > > i don't think the issues of advertising an LSP as a TE link in another > instance of the control plane than the one used for creating the LSP - > ditto > > "[HIERAR] did not consider scenarios where an LSP is created (and > maintained) by one instance of the GMPLS control plane, and is used as a > (TE) link by another instance of the GMPLS control plane." > > is only a matter of indicating to which instance this advertisement > should be done; I am happy if you could point out what is missing. > > now, in addition to the "routing" part, there is the whole discussion > about the maintenance of the (inherited) TE link - as we are speaking > here about separate instance - some specific mechanism may be needed > otherwise after their creation there may be no easy way to communicate > their unavailability The draft proposes the method to advertise the LSP created in the GMPLS domain to the different routing instance, MPLS domain for instance. > another more specific question on this document, what is the definition > of the value space for the "Target Control Plane Instance" ? Good question. We use a 32-bit space at this time. If you have any recommendation, I would be happy to hear that. You think that RD might be a good choice for instance, don't you. > > a last point, section 4 mentions > > "This is not believed to be an issue as an informal survey indicated > that dynamically signalled numbered FAs had not been deployed. Indeed > it was the attempt to implement numbered FAs that gave rise to the work > on this document." ... is there a general feeling that having this > mechanism will make dynamically triggered numbered FA a reality ? I hope so. Thank you for your comments. --- Kohei PS I am now about to be on trip. I may not be able to respond timely. I apologize. > > thanks, > - dimitri. > > Internet-Drafts@ietf.org wrote: > >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> >> Title : Advertisement of hierarchical and stitchable LSPs >> as TE Links Author(s) : K. Shiomoto, et al. >> Filename : draft-shiomoto-ccamp-lsp-hierarchy-bis-00.txt >> Pages : 15 >> Date : 2005-10-18 >> >> This document addresses topics related to hierarchical and stitched >> Label Switched Paths (LSPs). It describes extensions to allow an >> egress to identify that an LSP will be used as a dynamically signaled >> Forwarding Adjacency LSP (FA-LSP) in the case of numbered FA's. In >> addition, the document addresses the issue of how to indicate that an >> LSP should be advertised as a TE link into a different instance of the >> control plane and how to identify the instance that should be used. >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-shiomoto-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-shiomoto-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-shiomoto-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. >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org From owner-ccamp@ops.ietf.org Tue Oct 18 20:42:15 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ES223-0003VH-N0 for ccamp-archive@megatron.ietf.org; Tue, 18 Oct 2005 20:42:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09883 for ; Tue, 18 Oct 2005 20:42:06 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ES2DQ-000171-Il for ccamp-archive@ietf.org; Tue, 18 Oct 2005 20:54:17 -0400 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1ES1wl-000Nmn-RV for ccamp-data@psg.com; Wed, 19 Oct 2005 00:36:47 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO autolearn=ham version=3.1.0 Received: from [62.241.162.32] (helo=ranger.systems.pipex.net) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1ES1wk-000NmZ-I2 for ccamp@ops.ietf.org; Wed, 19 Oct 2005 00:36:46 +0000 Received: from dnni.com (81-178-2-190.dsl.pipex.com [81.178.2.190]) by ranger.systems.pipex.net (Postfix) with ESMTP id 16D6FE000358; Tue, 18 Oct 2005 15:22:23 +0100 (BST) Received: from Puppy ([205.252.31.205] RDNS failed) by dnni.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 18 Oct 2005 15:22:24 +0100 Message-ID: <027e01c5d3ef$c56210b0$cd1ffccd@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "CHO, JAI HYUNG" , References: <04e801c5d216$a65503b0$8310fe81@email1> Subject: Re: I-D ACTION:draft-jaihyung-ccamp-lse-architecture-00.txt Date: Tue, 18 Oct 2005 15:22:10 +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: 18 Oct 2005 14:22:24.0755 (UTC) FILETIME=[5C350430:01C5D3EF] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 3971661e40967acfc35f708dd5f33760 Content-Transfer-Encoding: 7bit Hi Jaihyung, Thank you for this draft. You are correct that the selection of a label encoding is fundamental to the success of GMPLS control of Ethernet switches, and we must be careful to select a solution that is applicable to all target environments, and which (ideally) is extensible to environments and scenarios that we have not yet determined. As you know, a BoF meeting is planned for Vancouver. The GMPLS controlled Ethernet Label Switching (GELS) BOF agenda and description can be seen at http://www3.ietf.org/proceedings/05nov/agenda/gels.txt One of the objectives of this BoF will be to determine whether the work for Ethernet label switching should be carried out within CCAMP or in a new working group (if the work is done in the IETF at all). The BoF has a proposed scope, but (of course) that will be part of the discussion. Once we know the scope of the work we are doing, and once the location of the work has been determined, it will be appropriate to get into the details of the solutions and what labels we use. In the mean time, your draft is a valuable contribution to the debate about what form that label should take and I would urge people to think about different potential label formats (there are several suggestions circulating) so that we are ready to move forward if/when the work is chartered. Thanks, Adrian ----- Original Message ----- From: "CHO, JAI HYUNG" To: Sent: Sunday, October 16, 2005 6:58 AM Subject: I-D ACTION:draft-jaihyung-ccamp-lse-architecture-00.txt > > > Dear All, > > Following is an announcement of new I-D proposing a solution for > GMPLS implementation over Ethernet. > In last 63rd Paris meeting, it was agreed that this issue belong to > CCAMP work scope. > > Any feedback or participation in this approach will be appreciated. > > % Note : Currently a new BoF (GELS) of similar work is being formed, > however, it is not clear whether the matrerial included in this I-D > fit in the scope of GELS. In particular, this proposal aims to > apply in bridged core network, as well as access network > where GELS precludes in the proposed work scope. > When this I-D is acknowledged in the scope of GELS, > the discussion may be moved to the BoF. > > Thanks > > Jaihyung Cho > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > > > > Title : Label Switched Ethernet (LSE) Architecture > > Author(s) : J. Cho, et al. > > Filename : draft-jaihyung-ccamp-lse-architecture-00.txt > > Pages : 15 > > Date : 2005-10-14 > > > > A solution for GMPLS implementation over Ethernet based on label > > encoding method using 48bits of Ethernet address is proposed. > > Ethernet switches supporting this approach control L2-LSP using > > source & destination MAC addresses. The format of GMPLS label > > encoding on Ethernet header is described. GMPLS bridge model and > > three implementation models over bridged core network are presented. > > The purpose of this draft is not to define new bridge architecture > > but to help understanding some aspects of this approach, and identify > > requirements for potential extension to current GMPLS protocols and > > bridge. > > > > > > A URL for this Internet-Draft is: > > > http://www.ietf.org/internet-drafts/draft-jaihyung-ccamp-lse-architecture-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-jaihyung-ccamp-lse-architecture-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-jaihyung-ccamp-lse-architecture-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. > > > > > ------------------------------------------------------------------------ -- > ------ > > > > _______________________________________________ > > I-D-Announce mailing list > > I-D-Announce@ietf.org > > https://www1.ietf.org/mailman/listinfo/i-d-announce > > > > > > > > > > > > > > From info@mail.rfdef.com Tue Oct 18 20:54:20 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ES2Dk-000089-1I for ccamp-archive@megatron.ietf.org; Tue, 18 Oct 2005 20:54:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10510 for ; Tue, 18 Oct 2005 20:54:10 -0400 (EDT) Received: from [58.180.197.111] (helo=mail.rfdef.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ES2PG-0001RO-5w for ccamp-archive@ietf.org; Tue, 18 Oct 2005 21:06:21 -0400 Received: (qmail 22060 invoked by uid 509); 19 Oct 2005 07:39:17 +0900 Date: 19 Oct 2005 07:39:17 +0900 Message-ID: <20051018223917.22059.qmail@mail.rfdef.com> From: info@rfdef.com To: ccamp-archive@ietf.org Subject: $B"(=w@-;o!&=54);o$G>R2p$5$l$?M-L>$I$3(B X-Spam-Score: 3.2 (+++) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 $B"($"$J$?@lMQ$NNx$9$k2s@~$r$4MQ0U$7$F$*$j$^$9!#(B http://1191.jp/kinjyo/index.html $B"(?M:J@lMQ2s@~$b$"$j!*!J?M:J%A%c%C%H2s@~!K(B http://1191.jp/kinjyo/index.html $B8}@b$$$FBT$A9g$o$;=PMh$^$9!#(B80$B!s$N3NN)!*!*5.J}l9g$O"M"*!!(Bsweet_as_candy_700@yahoo.fr $B!y!A!y!A!y!A!y!A!y!A!y!A!y!A!y!A!y!A!y!A!y!A!y!A!y!A!y!A!y!A!y(B From owner-ccamp@ops.ietf.org Tue Oct 18 22:45:43 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ES3xX-00061T-1P for ccamp-archive@megatron.ietf.org; Tue, 18 Oct 2005 22:45:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14774 for ; Tue, 18 Oct 2005 22:45:34 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ES48v-0003gt-Rw for ccamp-archive@ietf.org; Tue, 18 Oct 2005 22:57:45 -0400 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1ES3on-0003A0-RB for ccamp-data@psg.com; Wed, 19 Oct 2005 02:36:41 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-1.1 required=5.0 tests=AWL,BAYES_00, RCVD_IN_WHOIS_INVALID autolearn=no version=3.1.0 Received: from [129.254.16.131] (helo=email1.etri.info) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1ES3om-00039g-PM for ccamp@ops.ietf.org; Wed, 19 Oct 2005 02:36:40 +0000 Received: from mail pickup service by email1.etri.info with Microsoft SMTPSVC; Wed, 19 Oct 2005 11:38:29 +0900 Thread-Topic: Re: I-D ACTION:draft-jaihyung-ccamp-lse-architecture-00.txt thread-index: AcXUVjB/KM5nWPfeQ1O3pH8SVA/SzQ== Reply-To: "CHO, JAI HYUNG" From: "CHO, JAI HYUNG" To: "Adrian Farrel" , Subject: RE: Re: I-D ACTION:draft-jaihyung-ccamp-lse-architecture-00.txt Date: Wed, 19 Oct 2005 11:38:29 +0900 Comment: GQ19@|@ZEk=E?,18?x, BcN1b MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft CDO for Exchange 2000 Content-Class: urn:content-classes:message Importance: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.181 X-OriginalArrivalTime: 19 Oct 2005 02:38:29.0802 (UTC) FILETIME=[30A060A0:01C5D456] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 86f85b2f88b0d50615aed44a7f9e33c7 Content-Transfer-Encoding: 7bit Thank you Adrian, I hope the GELS BoF is fine place to harmonize both Ethernet community and GMPLS. I look forward the BoF meeting in Vancouver and community support. I also hope we achieve best solution for this issue out of broad discussion on many potential solutions. Thank you. Regards Jaihyung -----?? ???----- From: "Adrian Farrel" From Date: 2005-10-18 ?? 11:22:10 To: "CHO, JAI HYUNG" , "ccamp@ops.ietf.org" Cc: Subject: Re: I-D ACTION:draft-jaihyung-ccamp-lse-architecture-00.txt Hi Jaihyung, Thank you for this draft. You are correct that the selection of a label encoding is fundamental to the success of GMPLS control of Ethernet switches, and we must be careful to select a solution that is applicable to all target environments, and which (ideally) is extensible to environments and scenarios that we have not yet determined. As you know, a BoF meeting is planned for Vancouver. The GMPLS controlled Ethernet Label Switching (GELS) BOF agenda and description can be seen at http://www3.ietf.org/proceedings/05nov/agenda/gels.txt One of the objectives of this BoF will be to determine whether the work for Ethernet label switching should be carried out within CCAMP or in a new working group (if the work is done in the IETF at all). The BoF has a proposed scope, but (of course) that will be part of the discussion. Once we know the scope of the work we are doing, and once the location of the work has been determined, it will be appropriate to get into the details of the solutions and what labels we use. In the mean time, your draft is a valuable contribution to the debate about what form that label should take and I would urge people to think about different potential label formats (there are several suggestions circulating) so that we are ready to move forward if/when the work is chartered. Thanks, Adrian ----- Original Message ----- From: "CHO, JAI HYUNG" To: Sent: Sunday, October 16, 2005 6:58 AM Subject: I-D ACTION:draft-jaihyung-ccamp-lse-architecture-00.txt > > > Dear All, > > Following is an announcement of new I-D proposing a solution for > GMPLS implementation over Ethernet. > In last 63rd Paris meeting, it was agreed that this issue belong to > CCAMP work scope. > > Any feedback or participation in this approach will be appreciated. > > % Note : Currently a new BoF (GELS) of similar work is being formed, > however, it is not clear whether the matrerial included in this I-D > fit in the scope of GELS. In particular, this proposal aims to > apply in bridged core network, as well as access network > where GELS precludes in the proposed work scope. > When this I-D is acknowledged in the scope of GELS, > the discussion may be moved to the BoF. > > Thanks > > Jaihyung Cho > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > > > > Title : Label Switched Ethernet (LSE) Architecture > > Author(s) : J. Cho, et al. > > Filename : draft-jaihyung-ccamp-lse-architecture-00.txt > > Pages : 15 > > Date : 2005-10-14 > > > > A solution for GMPLS implementation over Ethernet based on label > > encoding method using 48bits of Ethernet address is proposed. > > Ethernet switches supporting this approach control L2-LSP using > > source & destination MAC addresses. The format of GMPLS label > > encoding on Ethernet header is described. GMPLS bridge model and > > three implementation models over bridged core network are presented. > > The purpose of this draft is not to define new bridge architecture > > but to help understanding some aspects of this approach, and identify > > requirements for potential extension to current GMPLS protocols and > > bridge. > > > > > > A URL for this Internet-Draft is: > > > http://www.ietf.org/internet-drafts/draft-jaihyung-ccamp-lse-architecture-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-jaihyung-ccamp-lse-architecture-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-jaihyung-ccamp-lse-architecture-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. > > > > > ------------------------------------------------------------------------ -- > ------ > > > > _______________________________________________ > > I-D-Announce mailing list > > I-D-Announce@ietf.org > > https://www1.ietf.org/mailman/listinfo/i-d-announce > > > > > > > > > > > > > > From owner-ccamp@ops.ietf.org Wed Oct 19 08:43:54 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESDIO-0008Kz-0P for ccamp-archive@megatron.ietf.org; Wed, 19 Oct 2005 08:43:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13443 for ; Wed, 19 Oct 2005 08:43:42 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESDU7-0002AX-O4 for ccamp-archive@ietf.org; Wed, 19 Oct 2005 08:56:00 -0400 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1ESD9h-0003jw-6Y for ccamp-data@psg.com; Wed, 19 Oct 2005 12:34:53 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-5.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from localhost ([127.0.0.1]) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1ESD9g-0003jf-4g; Wed, 19 Oct 2005 12:34:52 +0000 Message-ID: <43563D39.4080200@psg.com> Date: Wed, 19 Oct 2005 14:34:01 +0200 From: dimitri papadimitriou Reply-To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.11) Gecko/20050728 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kohei Shiomoto CC: dimitri.papadimitriou@alcatel.be, ccamp@ops.ietf.org, Adrian Farrel , Arthi Ayyangar , Richard Rabbat Subject: Re: I-D ACTION:draft-shiomoto-ccamp-lsp-hierarchy-bis-00.txt References: <43556AAB.8000803@psg.com> <435590C5.5010002@lab.ntt.co.jp> In-Reply-To: <435590C5.5010002@lab.ntt.co.jp> 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: 3fbd9b434023f8abfcb1532abaec7a21 Content-Transfer-Encoding: 7bit hi kohei Kohei Shiomoto wrote: > Hi Dimitri, > > dimitri papadimitriou wrote: > >>all, >> >>i don't think the issues of advertising an LSP as a TE link in another >>instance of the control plane than the one used for creating the LSP - >>ditto >> >>"[HIERAR] did not consider scenarios where an LSP is created (and >>maintained) by one instance of the GMPLS control plane, and is used as a >>(TE) link by another instance of the GMPLS control plane." >> >>is only a matter of indicating to which instance this advertisement >>should be done; > > I am happy if you could point out what is missing. it is a matter of knowing whether the head-end (of the "LSP") is 1. within the same area than the tail-end 2. the advertisement generated by the tail-end is going to reach the head-end and vice versa (as i think the draft makes no assumption about the routing adjacencies that allows exchanging this information) - note: this condition was kind of implicitly guaranteed in the [HIER] document >>now, in addition to the "routing" part, there is the whole discussion >>about the maintenance of the (inherited) TE link - as we are speaking >>here about separate instance - some specific mechanism may be needed >>otherwise after their creation there may be no easy way to communicate >>their unavailability > > The draft proposes the method to advertise the LSP created in the GMPLS > domain to the different routing instance, MPLS domain for instance. the difference is now that either you rely on the signaling capabilities to tell you (Notify, PathErr) whether the LSP is down - but you have to pass the information to the upper instance - or you are being made aware from the upper instance advertisement but the convergence time may be higher now there is a side issue here a loss of routing adjacency may be such that you loss a TE link even if the TE link is not down >>another more specific question on this document, what is the definition >>of the value space for the "Target Control Plane Instance" ? > > Good question. We use a 32-bit space at this time. If you have any > recommendation, I would be happy to hear that. You think that RD might > be a good choice for instance, don't you. what do you mean by RD ? i would say for instance the Area ID in OSPF >>a last point, section 4 mentions >> >>"This is not believed to be an issue as an informal survey indicated >>that dynamically signalled numbered FAs had not been deployed. Indeed >>it was the attempt to implement numbered FAs that gave rise to the work >>on this document." ... is there a general feeling that having this >>mechanism will make dynamically triggered numbered FA a reality ? > > I hope so. it may be a good sense to know whether provisioned numbered FAs where used before advising a specific mechanism for triggered once - do we have some feedback on this ? thanks, - dimitri. > Thank you for your comments. > --- > Kohei > > PS > I am now about to be on trip. I may not be able to respond timely. I > apologize. > > >>thanks, >>- dimitri. >> >>Internet-Drafts@ietf.org wrote: >> >> >>>A New Internet-Draft is available from the on-line Internet-Drafts >>>directories. >>> >>> >>> Title : Advertisement of hierarchical and stitchable LSPs >>>as TE Links Author(s) : K. Shiomoto, et al. >>> Filename : draft-shiomoto-ccamp-lsp-hierarchy-bis-00.txt >>> Pages : 15 >>> Date : 2005-10-18 >>> >>>This document addresses topics related to hierarchical and stitched >>>Label Switched Paths (LSPs). It describes extensions to allow an >>>egress to identify that an LSP will be used as a dynamically signaled >>>Forwarding Adjacency LSP (FA-LSP) in the case of numbered FA's. In >>>addition, the document addresses the issue of how to indicate that an >>>LSP should be advertised as a TE link into a different instance of the >>>control plane and how to identify the instance that should be used. >>>A URL for this Internet-Draft is: >>>http://www.ietf.org/internet-drafts/draft-shiomoto-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-shiomoto-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-shiomoto-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. >>> >>> >>>------------------------------------------------------------------------ >>> >>>_______________________________________________ >>>I-D-Announce mailing list >>>I-D-Announce@ietf.org > > > > . > From owner-ccamp@ops.ietf.org Wed Oct 19 10:31:48 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESEyq-000558-3i for ccamp-archive@megatron.ietf.org; Wed, 19 Oct 2005 10:31:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20447 for ; Wed, 19 Oct 2005 10:31:39 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESFAT-0005KF-EC for ccamp-archive@ietf.org; Wed, 19 Oct 2005 10:43:57 -0400 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1ESEqr-0009FT-Ck for ccamp-data@psg.com; Wed, 19 Oct 2005 14:23:33 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO autolearn=ham version=3.1.0 Received: from [62.241.163.7] (helo=blaster.systems.pipex.net) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1ESEqq-0009FG-6G for ccamp@ops.ietf.org; Wed, 19 Oct 2005 14:23:32 +0000 Received: from dnni.com (81-178-2-190.dsl.pipex.com [81.178.2.190]) by blaster.systems.pipex.net (Postfix) with ESMTP id 8D8C5E000725; Wed, 19 Oct 2005 14:54:47 +0100 (BST) Received: from Puppy ([205.252.31.205] RDNS failed) by dnni.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 19 Oct 2005 14:54:43 +0100 Message-ID: <002d01c5d4b5$1273df80$cd1ffccd@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Akira NAGATA" Cc: References: <20050819200548.46A5.NAGATA.AKIRA@jp.fujitsu.com> Subject: Re: Question on Administratively down bit Date: Wed, 19 Oct 2005 14:57: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: 19 Oct 2005 13:54:43.0454 (UTC) FILETIME=[A86859E0:01C5D4B4] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Content-Transfer-Encoding: 7bit Hi Akira, I have been thinking about your question and discussing it with a few people. The general consensus is that it is important to have well-defined mechanisms for the signaling exchange of the Admin Status bits, but that the actions to take on receipt of some the bits may be dependent on local policy or on data plane technology. Thus an implementation may decide that certain alarms should be suppressed during LSP establishment because it knows them to be "false" alarms triggered by the process of establishing the LSP. On the other hand, an implementation may decide that other alarms that are first raised during LSP establishment represent a different set of circumstances and should be raised. I would be worried if we tried to list and categorise all such alarms within the CCAMP working group. It might be useful to consider whether the behavior of switch under alarm suppression conditions should be configurable to allow the operator to select consistent behavior, or whether this is adding too much complexity. Cheers, Adrian ----- Original Message ----- From: "Akira NAGATA" To: Cc: "Akira_NAGATA" Sent: Friday, August 19, 2005 12:13 PM Subject: Question on Administratively down bit > Mr. Lou Berger and editors of RFC3471 and RFC3473, > > This is my first time to send e-mail to ccamp. > Thanks in advance. > > I'd like to ask one question about the handling of Administratively down bit > in GMPLS RSVP-TE's Admin_Status object. > > RFC3471 introduces "inhibiting alarm reporting" as an example application > of local action to "down" state (that is, A-bit=1) in Section 8. > But I can't find any other explicit descriptions about this procedure > in RFC3471 or 3473. > > I understand that actions to be taken by each node receiving Admin_Status > object shall be based on local policy. > > With regard to inhibition of alarm reporting, however, in order to achieve it > through end-to-end, I believe that we had better take a unified action > as a response to A-bit ("down" or "up"). > Operator will expect this feature. > > (Here I mean alarm report is not reporting via RSVP messages as described > in ID-alarm-spec, but one from NE to external system such as network > management system.) > > Are there any considerations, drafts or RFCs to define it? > > Thanks, > --- > Akira NAGATA > > > > From info@mail.qoaiu.com Wed Oct 19 13:46:39 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESI1P-0003a4-4N for ccamp-archive@megatron.ietf.org; Wed, 19 Oct 2005 13:46:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01191 for ; Wed, 19 Oct 2005 13:46:29 -0400 (EDT) Received: from [58.180.216.149] (helo=mail.qoaiu.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ESIDA-0002WJ-Mp for ccamp-archive@ietf.org; Wed, 19 Oct 2005 13:58:49 -0400 Received: (qmail 19197 invoked by uid 509); 19 Oct 2005 20:52:56 +0900 Date: 19 Oct 2005 20:52:56 +0900 Message-ID: <20051019115256.19196.qmail@mail.qoaiu.com> From: info@qoaiu.com To: ccamp-archive@ietf.org Subject: $B40A4L5NA$G9,$;C5$7(B X-Spam-Score: 3.5 (+++) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f $B"c"dF|K\?M0J30$N=w@-$bB??t:_@RCf"d(B $B"(F|K\:_=;$N=w@-Cf?4$G$9!#(B http://1191.jp/kensaku/index.html $B5U1g!&%(%C%A$J%A%c%C%H$dEEOC!"%a!<%k8r49!&(B1-$BBP(B-1$B$N%;%C%/%9!&HkL)$N4X78!&(BSM$B4X78!&=wAu$dCKAu!&!&!&!&!&!&!&!&$+$iA*$s$G%T%C%?%7$N=w@-$r$*C5$7$/$@$5$$!#(B http://1191.jp/kensaku/index.html $B$*;n$7EPO?$NJ}$K40A4(B10000$B1_J,:9$7>e$2$^$9!#(B *********************************** $B!|(BNO.I don't veceive your mail$B!|(B sweet_as_candy_700@yahoo.fr $B!|:#8e!"l9g$O!|(B sweet_as_candy_700@yahoo.fr *********************************** 18$B:PL$K~$N$4MxMQ$O1sN8$/$@$5$$(B From info@mail.qoaiu.com Wed Oct 19 21:02:39 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESOpL-00048c-Mj for ccamp-archive@megatron.ietf.org; Wed, 19 Oct 2005 21:02:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA00425 for ; Wed, 19 Oct 2005 21:02:29 -0400 (EDT) Received: from [58.180.216.152] (helo=mail.qoaiu.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ESP1B-0002CX-7o for ccamp-archive@ietf.org; Wed, 19 Oct 2005 21:14:53 -0400 Received: (qmail 28563 invoked by uid 509); 20 Oct 2005 03:41:39 +0900 Date: 20 Oct 2005 03:41:39 +0900 Message-ID: <20051019184139.28562.qmail@mail.qoaiu.com> From: info@qoaiu.com To: ccamp-archive@ietf.org Subject: $B40A4L5NA$G9,$;C5$7(B X-Spam-Score: 3.5 (+++) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f $B"c"dF|K\?M0J30$N=w@-$bB??t:_@RCf"d(B $B"(F|K\:_=;$N=w@-Cf?4$G$9!#(B http://1191.jp/kensaku/index.html $B5U1g!&%(%C%A$J%A%c%C%H$dEEOC!"%a!<%k8r49!&(B1-$BBP(B-1$B$N%;%C%/%9!&HkL)$N4X78!&(BSM$B4X78!&=wAu$dCKAu!&!&!&!&!&!&!&!&$+$iA*$s$G%T%C%?%7$N=w@-$r$*C5$7$/$@$5$$!#(B http://1191.jp/kensaku/index.html $B$*;n$7EPO?$NJ}$K40A4(B10000$B1_J,:9$7>e$2$^$9!#(B *********************************** $B!|(BNO.I don't veceive your mail$B!|(B sweet_as_candy_700@yahoo.fr $B!|:#8e!"l9g$O!|(B sweet_as_candy_700@yahoo.fr *********************************** 18$B:PL$K~$N$4MxMQ$O1sN8$/$@$5$$(B From info@mail.ssaas.com Wed Oct 19 21:11:35 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESOxz-0000eT-4Q for ccamp-archive@megatron.ietf.org; Wed, 19 Oct 2005 21:11:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA00891 for ; Wed, 19 Oct 2005 21:11:24 -0400 (EDT) Received: from [58.180.217.64] (helo=mail.ssaas.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ESP9o-0002T9-ES for ccamp-archive@ietf.org; Wed, 19 Oct 2005 21:23:49 -0400 Received: (qmail 24694 invoked by uid 509); 20 Oct 2005 01:13:16 +0900 Date: 20 Oct 2005 01:13:16 +0900 Message-ID: <20051019161316.24693.qmail@mail.ssaas.com> From: info@ssaas.com To: ccamp-archive@ietf.org Subject: $B2q$C$F$/$l$l$P:9$7>e$2$^$9!#(B X-Spam-Score: 3.5 (+++) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de $B$O$8$a$^$7$F!"_7ED$H?=$7$^$9!#$$$-$J$j$N%a!<%k$G?=$7Lu$4$6$$$^$;$s!#(B $B:#;d$O!"/$7$G$b6=L#$,$*$"$j$G$7$?$i!"6b3[$N>r7o!"l9g$O!d"M!!(Bgyakuten_angel@yahoo.com.au From info@mail.wsdccf.com Thu Oct 20 02:32:39 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESTye-0001re-Gp for ccamp-archive@megatron.ietf.org; Thu, 20 Oct 2005 02:32:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA14991 for ; Thu, 20 Oct 2005 02:32:25 -0400 (EDT) Received: from [58.180.199.102] (helo=mail.wsdccf.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ESUAV-0002TH-Kq for ccamp-archive@ietf.org; Thu, 20 Oct 2005 02:44:53 -0400 Received: (qmail 23175 invoked by uid 509); 20 Oct 2005 12:19:04 +0900 Date: 20 Oct 2005 12:19:04 +0900 Message-ID: <20051020031904.23174.qmail@mail.wsdccf.com> From: info@wsdccf.com To: ccamp-archive@ietf.org Subject: $B!y=EMW!y(B X-Spam-Score: 3.6 (+++) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d $B(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(B $B(.(#(#(B $BG.$$$4MWK>$K$*1~$($7$F$D$$$KL5NA%]%$%s%HBgI}(BUP$B!*(B $B(.(.(#(B $BATG/$NJ}$K$b$4Gx$7=k$$F|!9$,B3$-$^$9$,!"$*Hh$l$G$O$"$j$^$;$s$+!)(B $B!VL~$5$l$?$$!W(B $B!V$3$N2F$O$^$@(BH$B$J=P2q$$$,L5$$!W(B $B!V$*6b$,L5$$!W(B $BEy!9$*G:$_$G$O$"$j$^$;$s$+!)(B $B$?$@:#!"=w@-;o9-9pBgNL7G:\Cf$K$D$-!"6/NO$K$"$J$?$NM_K>$rK~$?$9=P2q$$$r;Y1gCW$7$^$9!*(B $B"(!V%5%/%i!W(B $B!V6Hl$rDs6!$7$F$*$j$^$9!#(B $B"(A4$F%*!<%W%s$K$7$F$*$j$^$9$N$G0B?4$7$F$*3Z$7$_2<$5$$!#(B $B:#$9$0EPO?$7$FD:$$$?J}$K$O!";O$a$K(B10000$B1_J,$N%]%$%s%H$rL5NA$G:9$7>e$2$F$*$j$^$9"v(B $BEPO?$O$3$A$i"*(B http://www.00-love5.com/?0yen $B!y(B*$B!&(B*$B!y(B*$B!&(B*$B!y(B*$B!&(B*$B!y(B*$B!&(B*$B!y(B*$B!&(B*$B!y(B*$B!&(B*$B!y(B*$B!&(B*$B!y(B*$B!&!y(B*$B!&(B*$B!y(B*$B!&(B*$B!y(B $B!}L5NA%]%$%s%H$GAjEvM7$Y$^$9$N$G@'Hs$*;n$72<$5$$"v(B $B!}$[$H$s$I$NJ}$,L5NA%]%$%s%HFb$G!"=w@-$r(BGET$B$7$F$^$9!*!*(B $B!};HMQ$7$F$_$F!V$3$l$O!*!W$H;W$C$FD:$$$?J}$N$_M-NA$X$*?J$_2<$5$$!*(B $B;n$7$F$_$k!*"*(B http://www.00-love5.com/?0yen $B!]!&!]!&!]!&!]!&!]!&!]!&!]!&!]!&!]!&!]!&!]!&!]!&!]!&!]!&!]!&!]!&!]!&!]!&!]!&!]!&(B $B$b$7!"5.J}$,AGE($J=P2q$$$r5a$a$F$$$i$C$7$c$i$J$1$l$P$*OM$S?=$7>e$2$^$9!#(B $B$*; Thu, 20 Oct 2005 14:55:22 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESfla-0004UU-TM for ccamp-archive@ietf.org; Thu, 20 Oct 2005 15:07:56 -0400 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1ESfQ7-000ITS-SJ for ccamp-data@psg.com; Thu, 20 Oct 2005 18:45:43 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [70.158.43.219] (helo=jera.movaz.com) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1ESfQ6-000ITF-TD for ccamp@ops.ietf.org; Thu, 20 Oct 2005 18:45:43 +0000 Received: from ib (unknown [172.16.24.122]) by jera.movaz.com (Postfix) with SMTP id 5596954F0E; Thu, 20 Oct 2005 14:45:30 -0400 (EDT) Message-ID: <011101c5d5a6$72136bd0$7a1810ac@movaz.com> From: "Igor Bryskin" To: "Kohei Shiomoto" Cc: , "Adrian Farrel" , "Arthi Ayyangar" , "Richard Rabbat" References: <43556AAB.8000803@psg.com> <435590C5.5010002@lab.ntt.co.jp> <43563D39.4080200@psg.com> Subject: Re: I-D ACTION:draft-shiomoto-ccamp-lsp-hierarchy-bis-00.txt Date: Thu, 20 Oct 2005 14:45:30 -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: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: 7bit Hi, I believe the draft could be very useful. I have several suggestions that IMO would make it stronger. 1.. It is possible that the same H-LSP is advertised into several control planes (for example, L1VPN provider H-LSP could be advertised into several VPNs in the Virtual Link mode) each time with different link IDs (possibly sometimes as numbered and sometimes as unnumbered). This fact could be negotiated between the H-LSP ends by including several LSP_TUNNEL_INTERFACE_ID objects (one per target control plane) into Path/Resv message. I've probably missed it, but I didn't see anywhere in the draft an explicit statement of such possibility. 2.. There are no currently any signaling mechanisms for negotiating how parallel H-LSPs should be bundled together before advertising them as a TE link. Normally, such negotiation is provided via LMP. However, you suggest (and rightfully so) to avoid using LMP for TE links based on H-LSPs, hence, all negotiations should be achieved via signaling. Note that bundling schemes could be different for each target control plane. One way of achieving this is by introducing a new sub-TLV of the LSP_TUNNEL_INTERFACE_ID object - let's call it BUNDLE sub-TLV - and have the ends of the H-LSPs to bundle those H-LSPs which share the same bundle ID for the same target control plane. Note also that bundle ID could be used as a link ID when advertising the bundle as a single TE link 3.. H-LSP does not necessarily have to be advertised as a TE link into any control plane. For instance, an H-LSP could be used as a dedicated protection for some other H-LSP or as a data link for a higher layer LSPs (note that not all data links are advertised as TE links). However, in order for such H-LSP to be capable to nest other LSPs the ends of the H-LSP need to know at least that the LSP is intended to be used as H-LSP (that is, resources will be dynamically allocated within the LSP) as well as remote link IDs (otherwise, it would impossible to map the information in the PHOP object with the local end of the link). Again, usually this is the job of the LMP. One way to signal an H-LSP that needs not to be advertised into any control plane is to specify some special value (e.g. NULL) as a target control plane ID. Regards, Igor From owner-ccamp@ops.ietf.org Thu Oct 20 18:57:01 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESjLJ-0008Rl-Ii for ccamp-archive@megatron.ietf.org; Thu, 20 Oct 2005 18:57:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21632 for ; Thu, 20 Oct 2005 18:56:51 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESjXJ-0005FJ-U9 for ccamp-archive@ietf.org; Thu, 20 Oct 2005 19:09:27 -0400 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1ESjEZ-0007sU-Gl for ccamp-data@psg.com; Thu, 20 Oct 2005 22:50:03 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=3.1.0 Received: from [132.151.6.50] (helo=newodin.ietf.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1ESjEY-0007rx-P8 for ccamp@ops.ietf.org; Thu, 20 Oct 2005 22:50:02 +0000 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1ESjEX-00066P-RN; Thu, 20 Oct 2005 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-inter-domain-pd-path-comp-01.txt Message-Id: Date: Thu, 20 Oct 2005 18:50:01 -0400 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.4 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db --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 : A Per-domain path computation method for establishing Inter-domain Traffic Engineering (TE) Label Switched Paths (LSPs) Author(s) : J. Vasseur, et al. Filename : draft-ietf-ccamp-inter-domain-pd-path-comp-01.txt Pages : 18 Date : 2005-10-20 This document specifies a per-domain path computation technique for establishing inter-domain Traffic Engineering (TE) Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Label Switched Paths (LSPs). In this document a domain refers to a collection of network elements within a common sphere of address management or path computational responsibility such as IGP areas and Autonomous Systems. Per-domain computation applies where the full path of an inter-domain TE LSP cannot be or is not determined at the ingress node of the TE LSP, and is not signaled across domain boundaries. This is most likely to arise owing to TE visibility limitations. The signaling message indicates the destination and nodes up to the next domain boundary. It may also indicate further domain boundaries or domain identifiers. The path through each domain, possibly including the choice of exit point from the domain, must be determined within the domain. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-inter-domain-pd-path-comp-01.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-inter-domain-pd-path-comp-01.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-inter-domain-pd-path-comp-01.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: <2005-10-20173251.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-inter-domain-pd-path-comp-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-inter-domain-pd-path-comp-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-10-20173251.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ccamp@ops.ietf.org Fri Oct 21 02:11:56 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESq8C-0004G0-2e for ccamp-archive@megatron.ietf.org; Fri, 21 Oct 2005 02:11:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29270 for ; Fri, 21 Oct 2005 02:11:45 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESqK7-0002br-KW for ccamp-archive@ietf.org; Fri, 21 Oct 2005 02:24:25 -0400 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1ESpot-0002YM-Ez for ccamp-data@psg.com; Fri, 21 Oct 2005 05:51:59 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00, UNPARSEABLE_RELAY autolearn=ham version=3.1.0 Received: from [192.51.44.36] (helo=fgwmail6.fujitsu.co.jp) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1ESpos-0002Y1-8j for ccamp@ops.ietf.org; Fri, 21 Oct 2005 05:51:58 +0000 Received: from m6.gw.fujitsu.co.jp ([10.0.50.76]) by fgwmail6.fujitsu.co.jp (Fujitsu Gateway) id j9L5prIH014397 for ; Fri, 21 Oct 2005 14:51:53 +0900 (envelope-from nagata.akira@jp.fujitsu.com) Received: from s13.gw.fujitsu.co.jp by m6.gw.fujitsu.co.jp (8.12.10/Fujitsu Domain Master) id j9L5pq8F008781 for ; Fri, 21 Oct 2005 14:51:53 +0900 (envelope-from nagata.akira@jp.fujitsu.com) Received: from s13.gw.fujitsu.co.jp (s13 [127.0.0.1]) by s13.gw.fujitsu.co.jp (Postfix) with ESMTP id CF5961CC106 for ; Fri, 21 Oct 2005 14:51:52 +0900 (JST) Received: from flabmail.flab.fujitsu.co.jp (flabmail.flab.fujitsu.co.jp [10.25.192.4]) by s13.gw.fujitsu.co.jp (Postfix) with ESMTP id 7E3E91CC103 for ; Fri, 21 Oct 2005 14:51:52 +0900 (JST) Received: from flabmail.flab.fujitsu.co.jp by flabmail.flab.fujitsu.co.jp (8.9.3p2/3.7W-030703-Fujitsu Labs. Domain Mail Master (NAVGW)) id OAA16001; Fri, 21 Oct 2005 14:51:52 +0900 (JST) Received: from goofy.dream.flab.fujitsu.co.jp ([10.25.144.14]) by flabmail.flab.fujitsu.co.jp (NAVGW 2.5.2.9) with SMTP id M2005102114515113410 ; Fri, 21 Oct 2005 14:51:51 +0900 Received: from [127.0.0.1] (mark [10.25.144.221]) by goofy.dream.flab.fujitsu.co.jp (8.9.3+3.2W/3.7W) with ESMTP id OAA16471; Fri, 21 Oct 2005 14:51:53 +0900 Date: Fri, 21 Oct 2005 14:51:33 +0900 From: Akira NAGATA To: "Adrian Farrel" Subject: Re: Question on Administratively down bit Cc: Akira_NAGATA , In-Reply-To: <002d01c5d4b5$1273df80$cd1ffccd@Puppy> References: <20050819200548.46A5.NAGATA.AKIRA@jp.fujitsu.com> <002d01c5d4b5$1273df80$cd1ffccd@Puppy> Message-Id: <20051021133213.6ADC.NAGATA.AKIRA@jp.fujitsu.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.20 [ja] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f Content-Transfer-Encoding: 7bit Hi Adrian, Thank you for your discussing this issue. I understand that a hardware behavior triggered by AdminStatus bit will differ from one vendor to another. Alarm inhibition is just an example of application by A-bit, RFC3471 or 3473 can not achieve interoperability on the hardware behavior itself triggered by A-bit in multi-vendor network. Is it right? In a fact, I think it cannot be helped. I believe, however, RFC3471 or 3473 shall achieve interoperability on AdminStatus bit including A-bit from the perspective of message handling, at least. RFC3473 has no explicit clarification of handling A-bit or T-bit, where it has an explicit description of handling the pair of D and R-bit (in Section 7.2). In order to achieve interoperability at message level, more explicit description will be needed for A-bit or T-bit like the case of D+R-bit. How do you think about this point? According to my understanding using examples from D+R-bit in Sec 7.2.1, Path/Resv sequence for alarm report inhibition by A-bit (i.e. degradation of established LSP) can be shown as following: Path (A=1, R=1) ingress -------------------> egress node Resv (A=1, R=0) node <------------------ Similarly, Path/Resv sequence for enabling alarm report by A-bit (i.e. activation of degradated LSP) can be shown as following: Path (A=0, R=1) ingress -------------------> egress node Resv (A=0, R=0) node <------------------ Would you mind letting me know if something wrong? best regards, Akira On Wed, 19 Oct 2005 14:57:35 +0100 "Adrian Farrel" san wrote: > Hi Akira, > > I have been thinking about your question and discussing it with a few > people. > > The general consensus is that it is important to have well-defined > mechanisms for the signaling exchange of the Admin Status bits, but that > the actions to take on receipt of some the bits may be dependent on local > policy or on data plane technology. > > Thus an implementation may decide that certain alarms should be suppressed > during LSP establishment because it knows them to be "false" alarms > triggered by the process of establishing the LSP. On the other hand, an > implementation may decide that other alarms that are first raised during > LSP establishment represent a different set of circumstances and should be > raised. I would be worried if we tried to list and categorise all such > alarms within the CCAMP working group. > > It might be useful to consider whether the behavior of switch under alarm > suppression conditions should be configurable to allow the operator to > select consistent behavior, or whether this is adding too much complexity. > > Cheers, > Adrian > > ----- Original Message ----- > From: "Akira NAGATA" > To: > Cc: "Akira_NAGATA" > Sent: Friday, August 19, 2005 12:13 PM > Subject: Question on Administratively down bit > > > > Mr. Lou Berger and editors of RFC3471 and RFC3473, > > > > This is my first time to send e-mail to ccamp. > > Thanks in advance. > > > > I'd like to ask one question about the handling of Administratively down > bit > > in GMPLS RSVP-TE's Admin_Status object. > > > > RFC3471 introduces "inhibiting alarm reporting" as an example > application > > of local action to "down" state (that is, A-bit=1) in Section 8. > > But I can't find any other explicit descriptions about this procedure > > in RFC3471 or 3473. > > > > I understand that actions to be taken by each node receiving > Admin_Status > > object shall be based on local policy. > > > > With regard to inhibition of alarm reporting, however, in order to > achieve it > > through end-to-end, I believe that we had better take a unified action > > as a response to A-bit ("down" or "up"). > > Operator will expect this feature. > > > > (Here I mean alarm report is not reporting via RSVP messages as > described > > in ID-alarm-spec, but one from NE to external system such as network > > management system.) > > > > Are there any considerations, drafts or RFCs to define it? > > > > Thanks, > > --- > > Akira NAGATA > > > > > > > > > --- Akira NAGATA Photonic Node Laboratory, Photonics Networking Laboratories, Fujitsu Laboratories Ltd. TEL: +81-44-754-2765 FAX: +81-44-754-2741 From owner-ccamp@ops.ietf.org Fri Oct 21 07:21:34 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESuxp-00041L-TR for ccamp-archive@megatron.ietf.org; Fri, 21 Oct 2005 07:21:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14748 for ; Fri, 21 Oct 2005 07:21:23 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESv9x-0004sl-OA for ccamp-archive@ietf.org; Fri, 21 Oct 2005 07:34:06 -0400 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1ESunP-000ImC-W1 for ccamp-data@psg.com; Fri, 21 Oct 2005 11:10:47 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [171.68.10.87] (helo=sj-iport-5.cisco.com) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1ESunO-000Ilq-Pm for ccamp@ops.ietf.org; Fri, 21 Oct 2005 11:10:46 +0000 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-5.cisco.com with ESMTP; 21 Oct 2005 04:10:46 -0700 X-IronPort-AV: i="3.97,239,1125903600"; d="scan'208"; a="222409814:sNHT28618040" 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 j9LBAOJp011365; Fri, 21 Oct 2005 04:10:43 -0700 (PDT) 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); Fri, 21 Oct 2005 07:10:41 -0400 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: Question on Administratively down bit Date: Fri, 21 Oct 2005 07:10:40 -0400 Message-ID: Thread-Topic: Question on Administratively down bit Thread-Index: AcXWBAEvn6sBhSpVTaqywiT34yEgfwAKhEBw From: "Zafar Ali \(zali\)" To: "Akira NAGATA" , "Adrian Farrel" Cc: X-OriginalArrivalTime: 21 Oct 2005 11:10:41.0664 (UTC) FILETIME=[1311E000:01C5D630] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 25eb6223a37c19d53ede858176b14339 Content-Transfer-Encoding: quoted-printable Hi Akira,=20 The sequence you mentioned is correct. Also this is my understanding that when an LSP is in "Admin.A =3D 1", an optical node may be = performing some power monitoring and adjustment related to the commissioning process (again, this is a local action by an optical node). From a router's prospective, I do see a need for router NOT to send any data traffic on the LSP that is in "Admin.A=3D1", in addition of suppressing alarm on the interface in question. I.e., an LSP can ONLY carrying data traffic when it is back to "Admin.A=3D0". =20 Comments/ additions?=20 Thanks Regards... Zafar=20 > -----Original Message----- > From: owner-ccamp@ops.ietf.org=20 > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Akira NAGATA > Sent: Friday, October 21, 2005 1:52 AM > To: Adrian Farrel > Cc: Akira_NAGATA; ccamp@ops.ietf.org > Subject: Re: Question on Administratively down bit >=20 > Hi Adrian, >=20 > Thank you for your discussing this issue. >=20 > I understand that a hardware behavior triggered by=20 > AdminStatus bit will differ from one vendor to another. >=20 > Alarm inhibition is just an example of application by A-bit, > RFC3471 or 3473 can not achieve interoperability on the=20 > hardware behavior itself triggered by A-bit in multi-vendor=20 > network. Is it right? > In a fact, I think it cannot be helped. >=20 > I believe, however, RFC3471 or 3473 shall achieve=20 > interoperability on AdminStatus bit including A-bit from the=20 > perspective of message handling, at least. >=20 > RFC3473 has no explicit clarification of handling A-bit or=20 > T-bit, where it has an explicit description of handling the=20 > pair of D and R-bit (in Section 7.2). > In order to achieve interoperability at message level, more=20 > explicit description will be needed for A-bit or T-bit like=20 > the case of D+R-bit. >=20 > How do you think about this point? >=20 > According to my understanding using examples from D+R-bit in=20 > Sec 7.2.1, Path/Resv sequence for alarm report inhibition by=20 > A-bit (i.e. > degradation > of established LSP) can be shown as following: >=20 > Path (A=3D1, R=3D1) > ingress -------------------> egress > node Resv (A=3D1, R=3D0) node > <------------------ >=20 > Similarly, Path/Resv sequence for enabling alarm report by=20 > A-bit (i.e. activation of degradated LSP) can be shown as following: >=20 > Path (A=3D0, R=3D1) > ingress -------------------> egress > node Resv (A=3D0, R=3D0) node > <------------------ >=20 > Would you mind letting me know if something wrong? >=20 > best regards, > Akira >=20 > On Wed, 19 Oct 2005 14:57:35 +0100 > "Adrian Farrel" san wrote: >=20 > > Hi Akira, > >=20 > > I have been thinking about your question and discussing it=20 > with a few=20 > > people. > >=20 > > The general consensus is that it is important to have well-defined=20 > > mechanisms for the signaling exchange of the Admin Status bits, but=20 > > that the actions to take on receipt of some the bits may be=20 > dependent=20 > > on local policy or on data plane technology. > >=20 > > Thus an implementation may decide that certain alarms should be=20 > > suppressed during LSP establishment because it knows them to be=20 > > "false" alarms triggered by the process of establishing the LSP. On=20 > > the other hand, an implementation may decide that other alarms that=20 > > are first raised during LSP establishment represent a=20 > different set of=20 > > circumstances and should be raised. I would be worried if=20 > we tried to=20 > > list and categorise all such alarms within the CCAMP working group. > >=20 > > It might be useful to consider whether the behavior of switch under=20 > > alarm suppression conditions should be configurable to allow the=20 > > operator to select consistent behavior, or whether this is=20 > adding too much complexity. > >=20 > > Cheers, > > Adrian > >=20 > > ----- Original Message ----- > > From: "Akira NAGATA" > > To: > > Cc: "Akira_NAGATA" > > Sent: Friday, August 19, 2005 12:13 PM > > Subject: Question on Administratively down bit > >=20 > >=20 > > > Mr. Lou Berger and editors of RFC3471 and RFC3473, > > > > > > This is my first time to send e-mail to ccamp. > > > Thanks in advance. > > > > > > I'd like to ask one question about the handling of=20 > Administratively=20 > > > down > > bit > > > in GMPLS RSVP-TE's Admin_Status object. > > > > > > RFC3471 introduces "inhibiting alarm reporting" as an example > > application > > > of local action to "down" state (that is, A-bit=3D1) in Section 8. > > > But I can't find any other explicit descriptions about this=20 > > > procedure in RFC3471 or 3473. > > > > > > I understand that actions to be taken by each node receiving > > Admin_Status > > > object shall be based on local policy. > > > > > > With regard to inhibition of alarm reporting, however, in order to > > achieve it > > > through end-to-end, I believe that we had better take a unified=20 > > > action as a response to A-bit ("down" or "up"). > > > Operator will expect this feature. > > > > > > (Here I mean alarm report is not reporting via RSVP messages as > > described > > > in ID-alarm-spec, but one from NE to external system such=20 > as network=20 > > > management system.) > > > > > > Are there any considerations, drafts or RFCs to define it? > > > > > > Thanks, > > > --- > > > Akira NAGATA > > > > > > > > > > > > > >=20 >=20 > --- > Akira NAGATA Photonic Node=20 > Laboratory, Photonics Networking Laboratories, Fujitsu=20 > Laboratories Ltd. > TEL: +81-44-754-2765 FAX: +81-44-754-2741 >=20 >=20 From owner-ccamp@ops.ietf.org Fri Oct 21 10:09:29 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESxaI-0007S0-Sy for ccamp-archive@megatron.ietf.org; Fri, 21 Oct 2005 10:09:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23743 for ; Fri, 21 Oct 2005 10:09:15 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESxmC-0002Nl-4o for ccamp-archive@ietf.org; Fri, 21 Oct 2005 10:22:00 -0400 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1ESxNg-0001GU-Bm for ccamp-data@psg.com; Fri, 21 Oct 2005 13:56:24 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,HTML_40_50, HTML_MESSAGE autolearn=ham version=3.1.0 Received: from [47.164.128.120] (helo=zctfs063.nortelnetworks.com) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1ESxNe-0001GG-Bj for ccamp@ops.ietf.org; Fri, 21 Oct 2005 13:56:23 +0000 Received: from zharhxm1.corp.nortel.com (zharhxm1.corp.nortel.com [47.165.48.149]) by zctfs063.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j9LDu6324522; Fri, 21 Oct 2005 15:56:06 +0200 (MEST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C5D647.2A748015" Subject: draft-bernstein-ccamp-gmpls-vcat-lcas-01 comments Date: Fri, 21 Oct 2005 14:55:56 +0100 Message-ID: X-MS-Has-Attach: yes Thread-Topic: draft-bernstein-ccamp-gmpls-vcat-lcas-01 comments Thread-Index: AcXWRyhSnwEmYcnETpaSNdiLS6oWKw== From: "Trevor Wilson" To: Cc: , Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.5 (/) X-Scan-Signature: be6fad690f337c95d0bf991fa23bce15 This is a multi-part message in MIME format. ------_=_NextPart_001_01C5D647.2A748015 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C5D647.2A748015" ------_=_NextPart_002_01C5D647.2A748015 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Greg et al, I have read your latest "draft-bernstein-ccamp-gmpls-vcat-lcas-01" and have inserted some comments and made some suggested modifications using the 'track-changes' feature in word. I apologise if the indentations etc. are not fully correct. If you require further information please do not hesitate to contact me. Best regards, Trevor Trevor Wilson Nortel Networks Belfast Lab Tel: +44 2890 363701 ESN 751 3701 > This is the Way. This is Nortel.=20 >=20 >=20 <>=20 Confidentiality Notice: This message and any attachments may contain information that is privileged and confidential. If you have reason to believe that you are not the intended recipient or a person responsible for delivering this message to an intended recipient, you are hereby notified that any review, dissemination, distribution, or copying of this message is strictly prohibited. If you have reason to believe that you are not the intended recipient or a person responsible for delivering this message to an intended recipient, please contact the sender immediately by reply email and destroy all copies of the original message. ------_=_NextPart_002_01C5D647.2A748015 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable draft-bernstein-ccamp-gmpls-vcat-lcas-01 comments

Greg et al,

I have read your latest = "draft-bernstein-ccamp-gmpls-vcat-lcas-01" and have inserted some comments and made some suggested = modifications using the 'track-changes' feature in word.

I apologise if the indentations etc. = are not fully correct.

If you require further information = please do not hesitate to contact me.

Best regards,

Trevor

Trevor Wilson
Nortel Networks
Belfast Lab
Tel: +44 2890 363701
       = ESN 751 3701
This is the Way. This is = Nortel.


= <<draft-bernstein-ccamp-gmpls-vcat-lcas-01_tw-2110-comments.doc>= >
Confidentiality = Notice:  This = message and any attachments may contain information that is privileged = and confidential. If you have reason to believe that you are not the = intended recipient or a person responsible for delivering this message = to an intended recipient, you are hereby notified that any review, = dissemination, distribution, or copying of this message is strictly = prohibited. If you have reason to believe that you are not the intended = recipient or a person responsible for delivering this message to an = intended recipient, please contact the sender immediately by reply email = and destroy all copies of the original message.


------_=_NextPart_002_01C5D647.2A748015-- ------_=_NextPart_001_01C5D647.2A748015 Content-Type: application/msword; name="draft-bernstein-ccamp-gmpls-vcat-lcas-01_tw-2110-comments.doc" Content-Transfer-Encoding: base64 Content-Description: draft-bernstein-ccamp-gmpls-vcat-lcas-01_tw-2110-comments.doc Content-Disposition: attachment; filename="draft-bernstein-ccamp-gmpls-vcat-lcas-01_tw-2110-comments.doc" Content-Transfer-Encoding: base64 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAADAAAADQEAAAAAAAAA EAAADwEAAAEAAAD+////AAAAAAYBAAATAQAADgEAAP////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////s pcEAW0AJBAAA8BK/AAAAAAAAMAAAAAAABgAAbu0AAA4AYmpiajQDNAMAAAAAAAAAAAAAAAAAAAAA AAAJBBYAKO4AAFZpAQBWaQEAUHMAAAAAAAAAAAAAAAAAAJIGAAAAAAAAAAAAAAAAAAD//w8AAAAA AAAAAAD//w8AAAAAAAAAAAD//w8AAAAAAAAAAAAAAAAAAAAAAIgAAAAAAIoCAAAAAAAAigIAAIoC AAAAAAAAigIAAAAAAACmAgAANgEAAH4EAAAsAAAAqgQAABQAAAAAAAAAAAAAAL4EAAAAAAAABs4A AAAAAAAGzgAAAAAAAAbOAAAAAAAABs4AAIwAAACSzgAAFAEAAL4EAAAAAAAAceYAAGgBAACyzwAA AAAAALLPAAAAAAAAss8AAAAAAACyzwAAAAAAALLPAAAAAAAAjdAAAAAAAACN0AAAAAAAAI3QAAAA AAAApOUAAAIAAACm5QAAAAAAAKblAAAAAAAApuUAAAAAAACm5QAAAAAAAKblAAAAAAAApuUAACQA AADZ5wAAUgIAACvqAADGAAAAyuUAADkAAAAAAAAAAAAAAAAAAAAAAAAAigIAABwAAAAE0wAAEgAA AAAAAAAAAAAAAAAAAAAAAACN0AAAAAAAAI3QAAAAAAAAFtMAAAwAAAAi0wAACAAAAMrlAAAAAAAA AAAAAAAAAACKAgAAAAAAAIoCAAAAAAAAss8AAAAAAAAAAAAAAAAAALLPAADbAAAAA+YAADIAAADA 5AAAAAAAAMDkAAAAAAAAwOQAAAAAAAAq0wAAqgIAAIoCAAAAAAAAss8AAAAAAACKAgAAAAAAALLP AAAAAAAApOUAAAAAAAAAAAAAAAAAALDkAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAABNMAAAAAAACk5QAAAAAAAMDkAAAwAAAAwOQAAAAAAAAAAAAA AAAAAPDkAAAAAAAAigIAAAAAAACKAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA8OQAAAAAAACyzwAAAAAAAKbPAAAMAAAAgPlWgkbW xQEAAAAAAAAAAAbOAAAAAAAA1NUAAAoMAADw5AAAAAAAAAAAAAAAAAAApOUAAAAAAAA15gAAPAAA AHHmAAAAAAAA8OQAAAAAAADx6gAAAAAAAN7hAACkAgAA8eoAAAAAAADw5AAAAAAAAAAAAAAAAAAA vgQAAAAAAAC+BAAAAAAAAIoCAAAAAAAAigIAAAAAAACKAgAAAAAAAIoCAAAAAAAAAAAAAAAAAAAA AAAAAAAAAPHqAAAAAAAAAAAAAAAAAADcAwAAogAAAPDkAAC0AAAAjdAAAHYAAAAD0QAAVAAAAJ7k AAASAAAAV9EAAEQAAACb0QAAaQEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAjdAA AAAAAACN0AAAAAAAAI3QAAAAAAAAyuUAAAAAAADK5QAAAAAAAL4EAAAAAAAAvgQAAKRkAABiaQAA pGQAAAAAAAAAAAAAguQAABwAAAC+BAAAAAAAAL4EAAAAAAAAYmkAAAAAAAACAAEBAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA0NQ0NB TVAgd29ya2luZyBHcm91cCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg Ry4gQmVybnN0ZWluDUludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBHcm90dG8gTmV0d29ya2luZw1FeHBpcmVzOiBBcHJpbCAxNCwgMjAwNiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgRC4gQ2F2aWdsaWENICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBNYXJj b25pDSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIFIuIFJhYmJhdA0gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIEZ1aml0c3UNICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBPY3RvYmVyIDExLCAyMDA1DQ0NT3Bl cmF0aW5nIFZpcnR1YWwgY29uY2F0ZW5hdGlvbiAoVkNBVCkgYW5kIHRoZSAgTGluayBDYXBhY2l0 eSBBZGp1c3RtZW50DSBTY2hlbWUgKExDQVMpIHdpdGggR2VuZXJhbGl6ZWQgTXVsdGktUHJvdG9j b2wgTGFiZWwgIFN3aXRjaGluZyAoR01QTFMpDSAgICAgICAgICAgICAgICBkcmFmdC1iZXJuc3Rl aW4tY2NhbXAtZ21wbHMtdmNhdC1sY2FzLTAxDQ1TdGF0dXMgb2YgdGhpcyBNZW1vDQ0gICBCeSBz dWJtaXR0aW5nIHRoaXMgSW50ZXJuZXQtRHJhZnQsIGVhY2ggYXV0aG9yIHJlcHJlc2VudHMgdGhh dCBhbnkNICAgYXBwbGljYWJsZSBwYXRlbnQgb3Igb3RoZXIgSVBSIGNsYWltcyBvZiB3aGljaCBo ZSBvciBzaGUgaXMgYXdhcmUNICAgaGF2ZSBiZWVuIG9yIHdpbGwgYmUgZGlzY2xvc2VkLCBhbmQg YW55IG9mIHdoaWNoIGhlIG9yIHNoZSBiZWNvbWVzDSAgIGF3YXJlIHdpbGwgYmUgZGlzY2xvc2Vk LCBpbiBhY2NvcmRhbmNlIHdpdGggU2VjdGlvbiA2IG9mIEJDUCA3OS4NDSAgIEludGVybmV0LURy YWZ0cyBhcmUgd29ya2luZyBkb2N1bWVudHMgb2YgdGhlIEludGVybmV0IEVuZ2luZWVyaW5nDSAg IFRhc2sgRm9yY2UgKElFVEYpLCBpdHMgYXJlYXMsIGFuZCBpdHMgd29ya2luZyBncm91cHMuICBO b3RlIHRoYXQNICAgb3RoZXIgZ3JvdXBzIG1heSBhbHNvIGRpc3RyaWJ1dGUgd29ya2luZyBkb2N1 bWVudHMgYXMgSW50ZXJuZXQtDSAgIERyYWZ0cy4NDSAgIEludGVybmV0LURyYWZ0cyBhcmUgZHJh ZnQgZG9jdW1lbnRzIHZhbGlkIGZvciBhIG1heGltdW0gb2Ygc2l4IG1vbnRocw0gICBhbmQgbWF5 IGJlIHVwZGF0ZWQsIHJlcGxhY2VkLCBvciBvYnNvbGV0ZWQgYnkgb3RoZXIgZG9jdW1lbnRzIGF0 IGFueQ0gICB0aW1lLiAgSXQgaXMgaW5hcHByb3ByaWF0ZSB0byB1c2UgSW50ZXJuZXQtRHJhZnRz IGFzIHJlZmVyZW5jZQ0gICBtYXRlcmlhbCBvciB0byBjaXRlIHRoZW0gb3RoZXIgdGhhbiBhcyAi d29yayBpbiBwcm9ncmVzcy4iDQ0NICAgVGhlIGxpc3Qgb2YgY3VycmVudCBJbnRlcm5ldC1EcmFm dHMgY2FuIGJlIGFjY2Vzc2VkIGF0DSAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaWV0Zi8xaWQtYWJz dHJhY3RzLnR4dC4NDSAgIFRoZSBsaXN0IG9mIEludGVybmV0LURyYWZ0IFNoYWRvdyBEaXJlY3Rv cmllcyBjYW4gYmUgYWNjZXNzZWQgYXQNICAgaHR0cDovL3d3dy5pZXRmLm9yZy9zaGFkb3cuaHRt bC4NDSAgIFRoaXMgSW50ZXJuZXQtRHJhZnQgd2lsbCBleHBpcmUgb24gQXByaWwgMTQsIDIwMDYu DQ1Db3B5cmlnaHQgTm90aWNlDQ0gICBDb3B5cmlnaHQgKEMpIFRoZSBJbnRlcm5ldCBTb2NpZXR5 ICgyMDA1KS4NDUFic3RyYWN0DQ0gICBUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyB0aGUgdXNlIG9m IHRoZSBHZW5lcmFsaXplZCBNdWx0aS1Qcm90b2NvbA0gICBMYWJlbCBTd2l0Y2hpbmcgKEdNUExT KSBjb250cm9sIHBsYW5lIGluIGNvbmp1bmN0aW9uIHdpdGggdGhlIFZpcnR1YWwNICAgQ29uY2F0 ZW5hdGlvbiAoVkNBVCkgbGF5ZXIgMSBpbnZlcnNlIG11bHRpcGxleGluZyBtZWNoYW5pc20gYW5k IGl0cw0gICBjb21wYW5pb24gTGluayBDYXBhY2l0eSBBZGp1c3RtZW50IFNjaGVtZSAoTENBUykg d2hpY2ggY2FuIGJlIHVzZWQNDQ0NQmVybnN0ZWluLCBldCBhbC4gICAgICAgIEV4cGlyZXMgQXBy aWwgMTQsIDIwMDYgICAgICAgICAgICAgICAgIFtQYWdlIDFdDQwNSW50ZXJuZXQtRHJhZnQgICAg ICAgICAgICBHTVBMUywgVkNBVCBhbmQgTENBUyAgICAgICAgICAgICAgT2N0b2JlciAyMDA1DQ0N ICAgZm9yIGhpdGxlc3MgZHluYW1pYyByZXNpemluZyBvZiB0aGUgaW52ZXJzZSBtdWx0aXBsZXgg Z3JvdXAuICBUaGVzZQ0gICB0ZWNobmlxdWVzIGFwcGx5IHRvIHRoZSBPcHRpY2FsIFRyYW5zcG9y dCBOZXR3b3JrIChPVE4pLCBTeW5jaHJvbm91cw0gICBPcHRpY2FsIE5ldHdvcmsgKFNPTkVUKSwg U3luY2hyb25vdXMgRGlnaXRhbCBIaWVyYXJjaHkgKFNESCkgYW5kDSAgIFBsZXNpb2Nocm9ub3Vz IERpZ2l0YWwgSGllcmFyY2h5IChQREgpIHNpZ25hbHMuDQ0NVGFibGUgb2YgQ29udGVudHMNDSAg IDEuICBPdmVydmlldyBvZiBWQ0FUIGFuZCBMQ0FTICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAgMw0gICAgIDEuMS4gIFZDQVQgc2lnbmFscyBhbmQgY29tcG9uZW50cyAgLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDMNICAgICAxLjIuICBWQ0FUIENhcGFiaWxpdGll cyBhbmQgTGltaXRhdGlvbnMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAzDSAgICAgMS4zLiAg VGhlIExDQVMgUHJvdG9jb2wgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAgNA0gICAyLiAgUHJvYmxlbSBTdGF0ZW1lbnQgYW5kIEN1cnJlbnQgU3VwcG9ydCAgLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gIDUNICAgICAyLjEuICBEaXNjb3Zlcnkgb2YgRW5hYmxlZCBFbmQg U3lzdGVtcyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA1DSAgICAgMi4yLiAgQ2xpZW50IHRv IEVuZCBQb2ludCBNYXBwaW5ncyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgNQ0gICAg IDIuMy4gIFZDQVQgY29uZmlndXJhdGlvbiB3aXRob3V0IExDQVMgIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gIDYNICAgICAyLjQuICBWQ0FUIGNvbmZpZ3VyYXRpb24gd2l0aCBMQ0FTIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA3DSAgICAgMi41LiAgQ29tcG9uZW50IFNpZ25hbCBD b25maWd1cmF0aW9uIFNjZW5hcmlvcyAuIC4gLiAuIC4gLiAuIC4gLiAgOA0gICAzLiAgUG9zc2li bGUgRXh0ZW5zaW9ucyB0byBHTVBMUyB0byBzdXBwb3J0IGFkZGl0aW9uYWwNICAgICAgIFZDQVQv TENBUyBzY2VuYXJpb3MgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IDEwDSAgICAgMy4xLiAgTWVjaGFuaXNtcyBmb3IgRGlzY292ZXJ5IG9mIFZDQVQvTENBUyAgLiAu IC4gLiAuIC4gLiAuIC4gLiAxMA0gICAgIDMuMi4gIE1lY2hhbmlzbSB0byBTdXBwb3J0IE11bHRp cGxlIENsaWVudCB0byBFbmQgUG9pbnQNICAgICAgICAgICBNYXBwaW5ncyAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDEwDSAgICAgMy4zLiAgU3VwcG9y dCBmb3IgQ29tcG9uZW50IFNpZ25hbCBDb25maWd1cmF0aW9uIFNjZW5hcmlvcyAuIC4gLiAxMA0g ICA0LiAgUmVmZXJlbmNlcyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gMTANICAgQXBwZW5kaXggQS4gIEFja25vd2xlZGdlbWVudHMgIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDEyDSAgIEF1dGhvcnMnIEFkZHJlc3NlcyAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxMw0gICBJbnRlbGxl Y3R1YWwgUHJvcGVydHkgYW5kIENvcHlyaWdodCBTdGF0ZW1lbnRzIC4gLiAuIC4gLiAuIC4gLiAu IC4gMTQNDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ1CZXJuc3RlaW4sIGV0IGFsLiAgICAgICAgRXhw aXJlcyBBcHJpbCAxNCwgMjAwNiAgICAgICAgICAgICAgICAgW1BhZ2UgMl0NDA1JbnRlcm5ldC1E cmFmdCAgICAgICAgICAgIEdNUExTLCBWQ0FUIGFuZCBMQ0FTICAgICAgICAgICAgICBPY3RvYmVy IDIwMDUNDQ0xLiAgT3ZlcnZpZXcgb2YgVkNBVCBhbmQgTENBUw0NICAgVmlydHVhbCBDb25jYXRl bmF0aW9uIChWQ0FUKSBpcyBhIHN0YW5kYXJkaXplZCBsYXllciAxIGludmVyc2UNICAgbXVsdGlw bGV4aW5nIHRlY2huaXF1ZSB0aGF0IGNhbiBiZSBhcHBsaWVkIHRvIE9UTiBbNl0sIFNPTkVUIFsz XSwgU0RIDSAgIFsyXSwgYW5kIFBESCBbNV0gY29tcG9uZW50IHNpZ25hbHMuICBCeSBpbnZlcnNl IG11bHRpcGxleGluZyB3ZSBtZWFuDSAgIGEgbWV0aG9kIHRoYXQgY29tYmluZXMgbXVsdGlwbGUg bGlua3MgYXQgYSBwYXJ0aWN1bGFyIGxheWVyIGludG8gYW4NICAgYWdncmVnYXRlIGxpbmsgdG8g YWNoaWV2ZSBhIGNvbW1lbnN1cmF0ZSBpbmNyZWFzZSBpbiBhdmFpbGFibGUNICAgYmFuZHdpZHRo IGNhcGFjaXR5IG9uIHRoYXQgYWdncmVnYXRlIGxpbmsuICBNb3JlIGZvcm1hbGx5LCBWQ0FUIGVz c2VudGlhbGx5DSAgIGNvbWJpbmVzIHRoZSBwYXlsb2FkIGJhbmR3aWR0aCBvZiBtdWx0aXBsZSBw YXRoIGxheWVyIG5ldHdvcmsgc2lnbmFscw0gICAob3IgdHJhaWxzKSB0byBzdXBwb3J0IGEgc2lu Z2xlIGNsaWVudCAoZS5nLiAgRXRoZXJuZXQpIGxheWVyIGxpbmsuDSAgIEZvciBhIG1vcmUgZGV0 YWlsZWQgaW50cm9kdWN0aW9uIHNlZSBbMV0uDQ0xLjEuICBWQ0FUIHNpZ25hbHMgYW5kIGNvbXBv bmVudHMNDSAgIEluIHRoZSBmb2xsb3dpbmcgd2Ugd2lsbCB1c2UgU0RIIHRlcm1pbm9sb2d5IHJh dGhlciB0aGFuIGJvdGggU09ORVQNICAgYW5kIFNESCB0ZXJtaW5vbG9neS4gIEluIFNESCBWaXJ0 dWFsIENvbmNhdGVuYXRpb24gKFZDQVQpIGNhbiBiZQ0gICBhcHBsaWVkIHRvIHRoZSBmb2xsb3dp bmcgY29tcG9uZW50IHRpbWUgZGl2aXNpb24gbXVsdGlwbGV4IChURE0pDSAgIHNpZ25hbHMgcmVm ZXJyZWQgdG8gYXMgVmlydHVhbCBDb250YWluZXJzIChWQ3MpOiBWQy0xMSwgVkMtMTIsIFZDLTIs DSAgIFZDLTMsIGFuZCBWQy00DQ0gICBPbmx5IGxpa2UgY29tcG9uZW50IHNpZ25hbHMgY2FuIGJl IGFnZ3JlZ2F0ZWQgaW50byBhIFZDQVQgZ3JvdXAgKFZDRykuDSAgIFRoZXNlIGdyb3VwcyBWQ0dz IGFyZSByZXNwZWN0aXZlbHkga25vd24gYXM6IFZDLTExLVh2LCBWQy0xMi1YdiwgVkMtMi1YdiwN ICAgVkMtMy1YdiwgYW5kIFZDLTQtWHYuICBJbiB0aGUgcHJldmlvdXMgZGVzaWduYXRpb25zIFgg aXMgYW4gaW50ZWdlciBpbmRpY2F0aW5nIHRoZSBudW1iZXIgb2YgbWVtYmVycyBpbiB0aGUgVkNH LiBUaGUgdmFsdWUgb2YgWCBmb3IgaGlnaCBvcmRlciBWQ3MgKFZDLTMgYW5kIFZDLTQpY2FuIGJl IGZyb20gMSB0byAyNTY7IGFuZCBmb3IgbG93IG9yZGVyIFZDcyAoVkMtMTEgVkMtMTIgYW5kIFZD LTIpIHRoZSB2YWx1ZSBvZiBYIGNhbiBiZSAxIHRvIDY0LiANICAgcnVubmluZyBmcm9tIDEgdG8g YSB2YWx1ZSBOIGRlcGVuZGVudCB1cG9uIHRoZSBjb21wb25lbnQgdHlwZS4gIFNlZQ0gICBbMl0g Zm9yIGRldGFpbHMuDQ0gICBWQ0FUIGNhbiBiZSBhcHBsaWVkIHRvIHRoZSBmb2xsb3dpbmcgUERI IHNpZ25hbHMgYXMgc3BlY2lmaWVkIGluDSAgIHJlZmVyZW5jZSBbNV06IERTMSxFMSwgRTMsIERT My4gIFNpbWlsYXIgdG8gdGhlIFNPTkVUL1NESCBjYXNlIHRoZXNlDSAgIGNvbXBvbmVudCBzaWdu YWxzIGNhbiBvbmx5IGJlIGNvbWJpbmVkIHdpdGggbGlrZSBzaWduYWxzIHRvIHByb2R1Y2UNICAg YWdncmVnYXRlcy4gIEZvciBzb21lIHJlYXNvbiB0aGUgdmlydHVhbCBjb25jYXRlbmF0aW9uIGdy b3VwVkNHcyBvZiB0aGUNICAgUERIIHNpZ25hbHMgd2VyZSBub3QgZ2l2ZW4gdW5pcXVlIGRlc2ln bmF0aW9ucyBpbiBbNV0gc28gd2Ugc2hhbGwNICAgYWRvcHQgYSBzaW1pbGFyIG5vdGF0aW9uIHRv IHRoZSBTREggVkNBVCBzaWduYWxzIGZvciB0aGUgcGVybWl0dGVkDSAgIFBESCBWQ0FUIHNpZ25h bHMgdGhhdCBmb2xsb3c6IERTMS1YdiwgRTEtWHYsIEUzLVh2LCBEUzMtWHYuBQ0NICAgQ29uY2F0 ZW5hdGlvbiBpbiB0aGUgb3B0aWNhbCB0cmFuc3BvcnQgbmV0d29yayAoT1ROKSBpcyByZWFsaXpl ZCBieQ0gICBtZWFucyBvZiB2aXJ0dWFsIGNvbmNhdGVuYXRpb24gb2YgT3B0aWNhbCBDaGFubmVs IFBheWxvYWQgVW5pdCAoT1BVKQ0gICBzaWduYWxzLiAgT1BVayBzaWduYWxzIChrPTEsIDIsIDMp IGNhbiBiZSBjb25jYXRlbmF0ZWQgaW50byBPUFVrLVh2DSAgIGFnZ3JlZ2F0ZXMgd2l0aCBYPSAx LC4uLiwgMjU2LiAgU2VlIHJlZmVyZW5jZSBbNl0gZm9yIGRldGFpbHMuDQ0xLjIuICBWQ0FUIENh cGFiaWxpdGllcyBhbmQgTGltaXRhdGlvbnMNDSAgIFZDQVQgcGVyZm9ybXMgaW52ZXJzZSBtdWx0 aXBsZXhpbmcgYnkgb2N0ZXQvYnl0ZSBkZS1pbnRlcmxlYXZpbmcgb2YNICAgdGhlIGVuY2Fwc3Vs YXRlZCBjbGllbnQgYml0IHN0cmVhbSBpbnRvIHRoZSBpbmRpdmlkdWFsIFZDcyBvZiB0aGUgVkNH IGFuZCB0aGVzZSBWQ3MgYXJlIHRyYW5zcG9ydGVkIGFjcm9zcyB0aGUgbmV0d29yayBpbmRlcGVu ZGVudGx5IGZyb20gZWFjaCBvdGhlci4gRHVlIHRvIHRoZSBwb3NzaWJsZSBkaWZmZXJlbnQgcHJv cGFnYXRpb24gdGltZXMgb2YgdGhlIFZDcywgYSBkaWZmZXJlbnRpYWwgZGVsYXkgbWF5IG9jY3Vy IGJldHdlZW4gdGhlIGluZGl2aWR1YWwgVkNzIGF0IHRoZSBwYXRoIHRlcm1pbmF0aW9uLiBUaGlz IGRpZmZlcmVudGlhbCBkZWxheSBoYXMgdG8gYmUgY29tcGVuc2F0ZWQgYW5kIHRoZSBWQ3MgaGF2 ZSB0byBiZSByZWFsaWduZWQuLiAgSGVuY2UgdGhlIG1haW4gbGltaXRhdGlvbiBvZiBhbnkNICAg VkNBVCBzdGFuZGFyZCBvciBpbXBsZW1lbnRhdGlvbiBpcyB0aGUgYW1tb3VudCBvZiBkaWZmZXJl bnRpYWwgZGVsYXkNICAgdGhhdCBjYW4gYmUgYWNjb21vZGF0ZWQgYmV0d2VlbiB0aGUgY29tcG9u ZW50IHNpZ25hbHMuICBUaGVzZSBhcmVUaGlzIGlzIA0gICBzdW1tYXJpemVkIGZvciB0aGUgZGlm ZmVyZW50IHNpZ25hbCB0eXBlcyBpbiByZWZlcmVuY2UgWzFdIHdpdGgNICAgZGV0YWlscyBnaXZl biBpbiB0aGUgcmVzcGVjdGl2ZSBzdGFuZGFyZHMgZG9jdW1lbnRzIFsyXSBbM10uDQ0NDQ1CZXJu c3RlaW4sIGV0IGFsLiAgICAgICAgRXhwaXJlcyBBcHJpbCAxNCwgMjAwNiAgICAgICAgICAgICAg ICAgW1BhZ2UgM10NDA1JbnRlcm5ldC1EcmFmdCAgICAgICAgICAgIEdNUExTLCBWQ0FUIGFuZCBM Q0FTICAgICAgICAgICAgICBPY3RvYmVyIDIwMDUNDQ0xLjMuICBUaGUgTENBUyBQcm90b2NvbA0N ICAgVGhlIExpbmsgQ2FwYWNpdHkgQWRqdXN0bWVudCBTY2hlbWUgZm9yIFZDQVQgc2lnbmFscyBp cyBhIHByb3RvY29sDSAgIGZvciBkeW5hbWljYWxseSBhbmQgaGl0bGVzc2x5IGNoYW5naW5nIChp LmUuLCBpbmNyZWFzaW5nIGFuZA0gICBkZWNyZWFzaW5nKSB0aGUgY2FwYWNpdHkgb2YgYSBWQ0FU IGdyb3VwVkNHLiAgTENBUyBhbHNvIHByb3ZpZGVzDSAgIHN1cnZpdmFiaWxpdHkgY2FwYWJpbGl0 aWVzLCBhdXRvbWF0aWNhbGx5IGRlY3JlYXNpbmcgdGhlIGNhcGFjaXR5IGlmDSAgIGEgbWVtYmVy IG9mIHRoZSBWQ0FUIGdyb3VwVkNHIGV4cGVyaWVuY2VzIGEgZmFpbHVyZSBpbiB0aGUgbmV0d29y aywgYW5kDSAgIGluY3JlYXNpbmcgdGhlIGNhcGFjaXR5IHdoZW4gdGhlIG5ldHdvcmsgZmF1bHQg aXMgcmVwYWlyZWQuICBMQ0FTLA0gICBpdHNlbGYsIHByb3ZpZGVzIGEgbWVjaGFuaXNtIGZvciBp bnRlcndvcmtpbmcgYmV0d2VlbiBMQ0FTIGFuZCBub24tDSAgIExDQVMgVkNBVCBlbmQgcG9pbnRz LiAgVkNBVCBkb2VzIG5vdCByZXF1aXJlIExDQVMgZm9yIGl0cyBvcGVyYXRpb24uDQ0gICBMQ0FT IGZ1bmN0aW9uYWxpdHkgZG9lcyBub3Qgb3ZlcmxhcCBvciBjb25mbGljdCB3aXRoIEdNUExTJyBy b3V0aW5nDSAgIG9yIHNpZ25hbGluZyBmdW5jdGlvbmFsaXR5IGZvciB0aGUgZXN0YWJsaXNobWVu dCBvZiBjb21wb25lbnQgbGlua3MNICAgb3IgZW50aXJlIFZDQVQgZ3JvdXBWQ0dzLiAgTENBUyBp bnN0ZWFkIGlzIHVzZWQgdG8gY29udHJvbCB3aGV0aGVyIGENICAgcGFydGljdWxhciBjb21wb25l bnQgc2lnbmFsIGlzIGFjdHVhbGx5IHB1dCBpbnRvIHNlcnZpY2UgY2FycnlpbmcNICAgdHJhZmZp YyBmb3IgdGhlIFZDQVQgZ3JvdXBWQ0cuDQ0gICBMQ0FTIHByb3ZpZGVzIGZvciBncmFjZWZ1bCBk ZWdyYWRhdGlvbiBvZiBmYWlsZWQgbGlua3MgYnkgaGF2aW5nIHRoZQ0gICBzaW5rIGVuZChzKSBy ZXBvcnQgYmFjayB0aGUgcmVjZWl2ZSBzdGF0dXMgb2YgYWxsIG1lbWJlciBjb21wb25lbnRzLiAg SW4NICAgdGhlIGNhc2Ugb2YgYSByZXBvcnRlZCBtZW1iZXIgZmFpbHVyZSwgdGhlIHNvdXJjZSBl bmQgd2lsbCBzdG9wIHVzaW5nDSAgIHRoZSBmYWlsZWQgY29tcG9uZW50IG1lbWJlciBhbmQgZGlz dHJpYnV0ZSB0aGUgZGF0YSBvdmVyIHRoZSByZW1haW5pbmcgkWdvb2SSIG1lbWJlcnMsIHRodXMg dHJhbnNtaXNzaW9uIGlzIHJlc3RvcmVkIHRvIGEgcmVkdWNlZCBiYW5kd2lkdGggY2FwYWNpdHku IGFuZCB0VGhlIHNvdXJjZSBlbmQgd2lsbCBzZW5kIGFuIExDQVMgbWVzc2FnZSB0byB0aGUNICAg c2luayBlbmQgdGhhdCBpdCBpcyBub3QgdHJhbnNtaXR0aW5nIGRhdGEgb24gdGhhdCBjb21wb25l bnRtZW1iZXIuICBUaGUNICAgd29yc3QgY2FzZSBub3RpZmljYXRpb24gdGltZXMgYXJlIHN1bW1h cml6ZWQgaW4gWzFdLgUNDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDUJlcm5zdGVpbiwgZXQg YWwuICAgICAgICBFeHBpcmVzIEFwcmlsIDE0LCAyMDA2ICAgICAgICAgICAgICAgICBbUGFnZSA0 XQ0MDUludGVybmV0LURyYWZ0ICAgICAgICAgICAgR01QTFMsIFZDQVQgYW5kIExDQVMgICAgICAg ICAgICAgIE9jdG9iZXIgMjAwNQ0NDTIuICBQcm9ibGVtIFN0YXRlbWVudCBhbmQgQ3VycmVudCBT dXBwb3J0DQ0gICBJbiB0aGlzIHNlY3Rpb24gd2UgbGlzdCBhIG51bWJlciBvZiBWQ0FUL0xDQVMg dXNhZ2Ugc2NlbmFyaW9zIGFuZA0gICB0aGVpciBjdXJyZW50IGxldmVsIG9mIHN1cHBvcnQuICBX ZSB3aWxsIGV2YWx1YXRlIHRoZSBhcHBsaWNhYmlsaXR5DSAgIG9mIEdNUExTIHRvIHRoZXNlIHNj ZW5hcmlvcyBhbmQgZm9yIHRob3NlIHNjZW5hcmlvcyB0aGF0IEdNUExTIGRvZXMNICAgbm90IGN1 cnJlbnRseSBzdXBwb3J0IHdlIGRlc2NyaWJlIHBvc3NpYmxlIEdNUExTIGV4dGVuc2lvbnMgaW4N ICAgU2VjdGlvbiAzLiAgTm90ZSB0aGUgdGVybSAiY29tcG9uZW50IiBzaWduYWwgaW4gdGhlIHRl eHQgaXMgdXNlZCBhcyBhDSAgIHNpbXBsaWZpZWQgbm90aW9uIHRvIHRoZSBtb3JlIGZvcm1hbCBj b25jZXB0cyBvZiBWQy1uLCBPRFVrLCBhbmQgUERIDSAgIHRlcm1pbmF0aW9uIGZ1bmN0aW9uIGFz IHdlbGwgYXMgVkMtbiwgT0RVayBhbmQgUERIIHBhdGgvdHJhaWwuDQ0yLjEuICBEaXNjb3Zlcnkg b2YgRW5hYmxlZCBFbmQgU3lzdGVtcw0NICAgRGlzY292ZXJpbmcgVkNBVDogVkNBVCBzb3VyY2Vz IGNhbiBvbmx5IGNvbW11bmljYXRlIHdpdGggVkNBVCBjYXBhYmxlDSAgICAgIHNpbmtzLiAgSGVu Y2UgdGhlIFZDQVQgY2FwYWJpbGl0aWVzIG9mIGEgUERILCBTREgsIG9yIE9UTiBwYXRoDSAgICAg IHRlcm1pbmF0aW9uIHBvaW50cyBuZWVkIHRvIGJlIGtub3duLg0NICAgICAgQ3VycmVudGx5IG5v IHN1cHBvcnQgZm9yIGRpc2NvdmVyeSBvZiBWQ0FUIG9yIExDQVMgYXByaW9yaSwgaS5lLiwNICAg ICAgdmlhIHJvdXRpbmcgaW5mb3JtYXRpb24uICBTdXBwb3J0IGZvciAiZGlzY292ZXJ5IiBvZiBW Q0FUDSAgICAgIGNhcGFiaWxpdHkgYXQgY29ubmVjdGlvbiBlc3RhYmxpc2htZW50IHRpbWUgdmlh IHNpZ25hbGluZywgaS5lLiwNICAgICAgd2UgY2FuIHJlcXVlc3QgVkNBVCBjb25uZWN0aW9uIGFu ZCBpZiB0aGUgZW5kIHN5c3RlbSBjYW5ub3QNICAgICAgc3VwcG9ydCBpdCxpdCB3b3VsZCByZWZ1 c2UgdGhlIGNvbm5lY3Rpb24uICBUQkQgLS0gaXMgdGhlcmUgYQ0gICAgICBzcGVjaWZpYyBlcnJv ciBjb2RlIGNvbmNlcm5pbmcgIlZDQVQgbm90IHN1cHBvcnRlZCIuDQ0gICBEaXNjb3ZlcmluZyBM Q0FTOiBMQ0FTIG9mZmVycyBhZGRpdGlvbmFsIGZ1bmN0aW9uYWxpdHkgYmV0d2VlbiBWQ0FUDSAg ICAgIGNhcGFibGUgc291cmNlcyBhbmQgc2lua3MuICBIZW5jZSB0aGUgTENBUyBjYXBhYmlsaXRp ZXMgb2YgVkNBVA0gICAgICBlbmFibGVkIHBhdGggdGVybWluYXRpb24gcG9pbnRzIGNhbiBiZSB1 c2VmdWwgdG8ga25vdyBpbiBhZHZhbmNlDSAgICAgIG9mIGNvbXBvbmVudCBzaWduYWwgc2V0dXAu DQ0gICAgICBDdXJyZW50bHkgdGhlcmUgaXMgbm8gbWVjaGFuaXNtIHRvIGFzayBmb3IgYW4gTENB UyBlbmFibGVkIGVuZA0gICAgICBwb2ludCBub3IgaXMgdGhlcmUgYSB3YXkgdG8gZmluZCBvdXQg aWYgdGhlIG90aGVyIGVuZCBpcyBMQ0FTDSAgICAgIGVuYWJsZWQgdW50aWwgYWZ0ZXIgdGhlIGNv bm5lY3Rpb24gaXMgZXN0YWJsaXNoZWQuICBUaGlzIGlzIGENICAgICAgcHJvYmxlbSBpZiB3ZSBz cGVjaWZpY2FsbHkgd2FudCBoaXRsZXNzIGR5bmFtaWMgcmVzaXppbmcgb3IgZmFzdA0NICAgICAg Z3JhY2VmdWwgZGVncmFkYXRpb24gZm9yIGEgVkNBVCBncm91cFZDRy4NDTIuMi4gIENsaWVudCB0 byBFbmQgUG9pbnQgTWFwcGluZ3MNDSAgIEZpeGVkIENsaWVudCB0byBFbmQgcG9pbnQgTWFwcGlu ZzogUGVyIGNsaWVudCBzaWduYWwgdGhlcmUgaXMgYQ0gICAgICBWQy1uLVh2IGNpcmN1aXQgaW4g d2hpY2ggdGhlIFggVkMtbiB0ZXJtaW5hdGlvbiBwb2ludHMgYXJlDSAgICAgIGRlZGljYXRlZCB0 byB0aGlzIGNsaWVudCBzaWduYWwuICBBdCBhbnkgcG9pbnQgaW4gdGltZSwgWSBYYSAoYWN0aXZl IG1lbWJlcnMpIG91dCBvZiBYbSAobWF4aW11bSBtZW1iZXJzKQ0gICAgICBWQy1uIHRlcm1pbmF0 aW9uIHBvaW50cyBtYXkgYmUgc2V0IHVwIHRvIGNhcnJ5IGNsaWVudCB0cmFmZmljLg0gICAgICBG b3IgZXhhbXBsZSB3aGVuIFZDQVQgaXMgZGVwbG95ZWQgb24gYSBSb3V0ZXIsIHRoZSBWQ0FUIGdy b3VwVkNHDSAgICAgIGNvbm5lY3RzIGRpcmVjdGx5IHRvIG9uZSBTVE0tTiBpbnRlcmZhY2UgcG9y dCAoaW4gYWJzZW5jZSBvZiBhIEhPDSAgICAgIG9yIExPIHN3aXRjaCBmYWJyaWMgaW4gdGhlIHJv dXRlcikuICBUaGUgdHJhbnNwb3J0IG5ldHdvcmsgd2lsbG1heQ0gICAgICB0aGVuIHNwbGl0IHRo ZSBWQ0FUIGdyb3VwIGludG8gdHdvIG9yIG1vcmUgc3ViZ3JvdXBzIG9mDSAgICAgIGNvbXBvbmVu dHMsIGVhY2ggdHJhbnNwb3J0IHRoZSBpbmRpdmlkdWFsIFZDcyBiZWluZyByb3V0ZWQgdmlhIG9u ZSBvciBtb3JlIGRpdmVyc2Ugcm91dGVzLiBEaXZlcnNlIHJvdXRpbmcgd2lsbCBpbmN1ciBhIGRp ZmZlcnRpYWwgZGVsYXkuDQ0NDQ0NDUJlcm5zdGVpbiwgZXQgYWwuICAgICAgICBFeHBpcmVzIEFw cmlsIDE0LCAyMDA2ICAgICAgICAgICAgICAgICBbUGFnZSA1XQ0MDUludGVybmV0LURyYWZ0ICAg ICAgICAgICAgR01QTFMsIFZDQVQgYW5kIExDQVMgICAgICAgICAgICAgIE9jdG9iZXIgMjAwNQ0N DSAgIFZhcmlhYmxlIENsaWVudCB0byBFbmQgcG9pbnQgTWFwcGluZzogRm9yIGEgc2V0IG9mIE0g Y2xpZW50IHNpZ25hbHMNICAgICAgdGhlcmUgYXJlIE0qIFZDLW4tWHYgVkNBVCBlbmRwb2ludHMg c2hhcmluZyBhIHNldCBvZiBOIChOPk0pIFZDLW4NICAgICAgdGVybWluYXRpb24gcG9pbnRzLiAg VHlwaWNhbGx5IEl0IGlzIHBvc3NpYmxlIHRoYXQgTXhYID4gTiAoZXhhbXBsZTogTT0xMCwgWD03 LCBOPTY0KTsNICAgICAgaS5lLiB0aGVyZSBpcyBtYXkgYmUgYSBraW5kIG9mIG92ZXJib29raW5n LiAgSW1wbGljYXRpb246IG11c3QgYmUgYWJsZSB0bw0gICAgICBhY2NvbW1vZGF0ZSBtdWx0aXBs ZSBkaWZmZXJlbnQgc2l6ZWQgVkNBVCBncm91cFZDR3MgYXQgYW4NICAgICAgImludGVyZmFjZSIu ICBGb3IgZXhhbXBsZSBhbiBTVE0tNjQgaW50ZXJmYWNlIGNhbiBzdXBwb3J0IG1hbnkNICAgICAg ZGlmZmVyZW50IFZDLTQtWHYgZ3JvdXBzLCBwcm92aWRpbmcgdGhlIHRvdGFsIG51bWJlciBvZiBW Q3MgZG9lcyBub3QgZXhjZWVkIHRoZSBpbnRlcmZhY2UgdG90YWwgY2FwYWNpdHkuDQ0gICBJbXBs aWNhdGlvbnM6IEluIGJvdGggdGhlc2UgY2FzZXMgd2UgY2FuIGhhdmUgbW9yZSB0aGFuIG9uZSBW Q0FUDSAgICAgIGdyb3VwVkNHIHBlciBHTVBMUyBsaW5rLiAgSW4gZ2VuZXJhbCBpdCBpcyB0aGUg cmVzcG9uc2liaWxpdHkgb2YgdGhlDSAgICAgIHNpZ25hbGluZyBlbnRpdHkgYXQgdGhlIHNvdXJj ZSBhbmQgZGVzdGluYXRpb24gZW5kcyB0byBjaG9vc2UgdGhlDSAgICAgIGFwcHJvcHJpYXRlIFZD LW4gdGVybWluYXRpb24gcG9pbnRzIGZvciB0aGUgVkNBVCBncm91cFZDRyBhbmQgaW4gdGhlDSAg ICAgIGNhc2Ugb2YgInZhcmlhYmxlIGNsaWVudCBtYXBwaW5nIiB0byBwZXJmb3JtIG5lZWRlZCBp bnRlcm5hbA0gICAgICBjb25maWd1cmF0aW9uLiAgSG93ZXZlciBtdWx0aXBsZSBWQ0FUIGdyb3Vw VkNHcyBwZXIgR01QTFMgbGluayBvcg0gICAgICBHTVBMUyBhZGRyZXNzZWQgZW50aXR5IGludHJv ZHVjZXMgYW4gdW5yZXNvbHZhYmxlIGFtYmlndWl0eSB3aGVuDSAgICAgIGRpc2pvaW50BSBjb25u ZWN0aW9ucyBhcmUgc2V0IHVwIG9yIGR5bmFtaWMgcmVzaXppbmcgaXMgYXBwbGllZA0gICAgICBz aW5jZSB0aGVyZSBpcyBjdXJyZW50bHkgbm8gIlZDQVQgZ3JvdXBWQ0cgaWRlbnRpZmllciIgaW4g R01QTFMNICAgICAgc2lnbmFsaW5nLg0NMi4zLiAgVkNBVCBjb25maWd1cmF0aW9uIHdpdGhvdXQg TENBUw0NICAgQmFzZSBDb25maWd1cmF0aW9uOiBGb3IgVkNBVCB0byBvcGVyYXRlIHRoZSBzaW5r IGVuZCBuZWVkcyB0byBiZQ0gICAgICBpbmZvcm1lZCBvZiBob3cgbWFueSBjb21wb25lbnRzIGFy ZSBpbiB0aGUgVkNBVCBncm91cFZDRy4gIEl0IGhhcyBubw0gICAgICBvdGhlciB3YXkgb2Yga25v d2luZyBpZiBpdCBpcyBjdXJyZW50bHkgcmVjZWl2aW5nIGFsbCBjb21wb25lbnRzDSAgICAgIGlu dGVuZGVkIHRvIGJlIGluIHRoZSBncm91cC4NDSAgICAgIEZpeGVkIHNpemVkIGNvLXJvdXRlZCBn cm91cHMgYXJlIHN1cHBvcnRlZCB3aXRoIGN1cnJlbnQgR01QTFMNICAgICAgc2lnbmFsaW5nLiAg RGlzam9pbnRseSBEaXZlcnNlbHkgcm91dGVkIGdyb3VwcyBhcmUgbm90IGN1cnJlbnRseSBzdXBw b3J0ZWQuBQ0NICAgR3JvdXAgUmVzaXppbmc6IEFkZGl0aW9ucyBvciByZW1vdmFscyBvZiBjb21w b25lbnRzIGZyb20gYSBub24tTENBUyBWQ0FUIGdyb3VwVkNHDSAgICAgIHdpdGhvdXQgYXJlIG5v dCBoaXRsZXNzLCB0aGF0IGlzIGRhdGEgbG9zcyB3aWxsIG9jY3VyIHdoaWxlIHRoZQ0gICAgICBz b3VyY2UgYW5kIHNpbmsgYmVjb21lIHN5bmNocm9uaXplZGFyZSByZXByb3Zpc2lvbmVkIGFzIHRv IHRoZSBudW1iZXIgb2YgbWVtYmVycyBpbg0gICAgICB0aGUgZ3JvdXAuDQ0gICAgICBDdXJyZW50 bHkgbm90IHN1cHBvcnRlZCB3aXRoaW4gR01QTFMuICBJbiBwYXJ0aWN1bGFyLCB3aXRoIGVhY2gN ICAgICAgYWRkaXRpb24gb3IgcmVtb3ZhbCBvZiBhIGNvbXBvbmVudCB0aGUgc2luayBlbmQgcG9p bnQgbmVlZHMgdG8gYmUNICAgICAgdG9sZCB0aGUgZXhwZWN0ZWQgbnVtYmVyIG9mIGNvbXBvbmVu dHMgaW4gdGhlIGdyb3VwLg0NICAgRmFpbHVyZSBDb25kaXRpb25zOiBGYWlsdXJlIG9mIGEgY29t cG9uZW50IG11c3QgZGV0ZWN0ZWQgZXh0ZXJuYWwgdG8NICAgICAgVkNBVCBzeXN0ZW0uICBUaGUg ZW50aXJlIGdyb3VwIGlzIHJlbmRlcmVkIGlub3BlcmFibGUgdW50aWwgc291cmNlDSAgICAgIHRh a2VzIHRoZSBmYWlsZWQgY29tcG9uZW50IGlzIHRha2VuIG91dCBvZiBzZXJ2aWNlIChvciByZXBs YWNlZCkgYW5kIHNpbmsgZW5kIGlzIG5vdGlmaWVkDSAgICAgIHRvIHRha2UgY29tcG9uZW50IG91 dCBvZiBzZXJ2aWNlYnkgcmUtcHJvdmlzaW9uaW5nIGJvdGggc291cmNlIGFuZCBzaW5rIHRvIHRo YXQgZWZmZWN0Lg0NICAgICAgQ3VycmVudGx5IG5vdCBzdXBwb3J0ZWQgd2l0aGluIEdNUExTLiAg VGhlIHNvdXJjZSBhbmQgc2luayBuZWVkcyB0byBiZSB0b2xkDSAgICAgIHdoYXQgY29tcG9uZW50 IGhhcyBmYWlsZWQgYW5kIHJlbW92ZSBpdCBmcm9tIHNlcnZpY2UuLCB0aGVuIHRoZQ0gICAgICBz aW5rIG11c3QgYmUgdG9sZCB0byBhbHNvIHJlbW92ZSBpdCBmcm9tIHNlcnZpY2UuDQ0NDQ0NDUJl cm5zdGVpbiwgZXQgYWwuICAgICAgICBFeHBpcmVzIEFwcmlsIDE0LCAyMDA2ICAgICAgICAgICAg ICAgICBbUGFnZSA2XQ0MDUludGVybmV0LURyYWZ0ICAgICAgICAgICAgR01QTFMsIFZDQVQgYW5k IExDQVMgICAgICAgICAgICAgIE9jdG9iZXIgMjAwNQ0NDTIuNC4gIFZDQVQgY29uZmlndXJhdGlv biB3aXRoIExDQVMNDSAgIEJhc2UgQ29uZmlndXJhdGlvbjogU2luayBlbmQgKGFuZCBzb3VyY2Ug ZW5kKSBhcmUgZmlyc3QgY29uZmlndXJlZA0gICAgICB3aXRoIHRoZSB2YWx1ZSBvZiAiWSJYbSAo dGhlIG1heGltdW0gbnVtYmVyIG9mIGNvbXBvbmVudHMpLCBhbmQgdGhlIGFjdGl2ZSBjb21wb25l bnRzIFhhIGFyZSBhbGxvY2F0ZWQgKFhtIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAABlIiAAWABhACkAYQBuAGQAIABtAG8AcgBlAA0AIAAgACAA IAAgACAAcwBwAGUAYwBpAGYAaQBjAGEAbABsAHkAIAB3AGgAaQBjAGgAIABvAGYAIAB0AGgAZQAg AFgAIAAoAGUALgBnAC4AIAAgAFYAQwAtAG4AKQAgAGEAYwBjAGUAcwBzACAAcABvAGkAbgB0AHMA IAAoAGEAbgBkACAAdABoAHUAcwANACAAIAAgACAAIAAgACgAVgBDAC0AbgApACAAdABlAHIAbQBp AG4AYQB0AGkAbwBuACAAZgB1AG4AYwB0AGkAbwBuAHMAKQAgAGEAcgBlACAAYQBsAGwAbwBjAGEA dABlAGQAIAB0AG8AIAB0AGgAZQAgAFYAQwBBAFQAIABnAHIAbwB1AHAAIAB3AGkAdABoAA0AIAAg ACAAIAAgACAAWQAgACgAVgBDAC0AbgApACAAYwBvAG0AcABvAG4AZQBuAHQAcwAuACAAIABMAEMA QQBTACAAdABoAGUAbgAgAGQAZQB0AGUAYwB0AHMAIABhAHUAdABvAG0AYQB0AGkAYwBhAGwAbAB5 ACAAdABoAGUAIABYAGEAIAB3AGgAaQBjAGgAIABvAGYADQAgACAAIAAgACAAIAB0AGgAbwBzAGUA IABZACAAKABWAEMALQBuACkAIABjAG9tcG9uZW50cyBpcyBjYXJyeWluZyBhY3R1YWwgdHJhZmZp YyBhbmQgcHV0cyB0aGVtDSAgICAgIGludG8gc2VydmljZSBmb3IgdGhlIGdyb3VwLg0NICAgICAg Q3VycmVudGx5IGJvdGggY28tcm91dGVkIGFuZCBkaXNqb2ludGx5IGRpdmVyc2VseSByb3V0ZWQg VkNBVCBncm91cFZDR3MgY2FuIGJlDSAgICAgIHN1cHBvcnRlZCBpZiB0aGVyZSBpcyBubyBWQ0FU IGdyb3VwVkNHIGFtYmlndWl0eS4NDSAgIENvbXBvbmVudCBBZGRpdGlvbjogV2hlbiBhIG5ldyBj b21wb25lbnQgc2lnbmFsIGhhcyB0byBiZSBhZGRlZCB0byBhDSAgICAgIFZDQVQgZ3JvdXBWQ0cg dGhlIGZvbGxvd2luZyBwcm9jZWR1cmUgYXBwbGllcy4NDSAgICAgIDEuCUVzdGFibGlzaCBhIGNv bm5lY3Rpb24gdXNpbmcgb25lIG9mIHRoZSBpbi1hY3RpdmUgbWVtYmVycyBvZiB0aGUgVkNHDQky LglQcm92aXNpb24gdGhlIFNvdXJjZSB0byB1c2UgdGhlIJFuZXeSIG1lbWJlciBhcyBvbmUgb2Yg dGhlIGFjdGl2ZSBncm91cC4gVGhpcyBlbnRhaWxzIHNlbmRpbmcgdGhlIEFERCBjb21tYW5kLg0J My4JUHJvdmlzaW9uIHRoZSBTaW5rIHRvIHJlY29nbml6ZSB0aGUgkW5ld5IgbWVtYmVyIG9mIHRo ZSBWQ0cuDQ0JVGhlIG9yZGVyIG9mIGRvaW5nIHRoZSBhYm92ZSBpcyBub3QgaW1wb3J0YW50LiBX aGVuIHRoZSBBREQgY29tbWFuZCBpcyByZWNlaXZlZCBieSB0aGUgc2luayBpdCB3aWxsIHJldHVy biBhbiCRT0uSIHRvIHRoZSBTb3VyY2UgYXQgd2hpY2ggdGltZSB0aGUgU291cmNlIHdpbGwgdXNl IGFsbCBhY3RpdmUgbWVtYmVycyAob2xkICsgbmV3KSB0byB0cmFuc3BvcnQgdGhlIGNsaWVudCB0 cmFmZmljLg0xLiAgQ29uZmlndXJlIHRoZSBhZGFwdGF0aW9uIHNvdXJjZS9zaW5rIGZ1bmN0aW9u cyBhbmQgY2hhbmdlIHRoZQ0gICAgICAgICAgbnVtYmVyIG9mIGNvbXBvbmVudHMsIFksIHRvIFkr MSBieSBpZGVudGlmeWluZyB3aGljaCBvZiB0aGUNICAgICAgICAgIFgtWSAoZS5nLiAgVkMtbikg YWNjZXNzIHBvaW50cyBjdXJyZW50bHkgb3V0c2lkZSB0aGUgZ3JvdXAgaXMNICAgICAgICAgIGFk ZGVkIHRvIHRoZSBncm91cDsNDSAgICAgIDIuICBUaGUgbmV3IGNvbXBvbmVudCBpcyBjcmVhdGVk LCBlLmcuLCB0aGUgY3Jvc3MtY29ubmVjdGlvbnMgYXJlDSAgICAgICAgICBlc3RhYmxpc2ggYWxv bmcgdGhlIGNvbXBvbmVudHMgcGF0aC4NDSAgICAgIDMuICBBcyBzb29uIGFzIExDQVMgcHJvdG9j b2wgaW5mb3JtYXRpb24gZXhjaGFuZ2UgaXMgZmluaXNoZWQsDSAgICAgICAgICBpLmUuLCB0aGUg c3RhdGUgTk9STSBpcyByZWFjaGVkLCBjbGllbnQgdHJhZmZpYyBpcyBzZW50IG9uIHRoZQ0gICAg ICAgICAgYWRkZWQgY29tcG9uZW50Lg0NICAgICAgVGhpcyBwcm9jZWR1cmUgZG9lcyBub3QgYWZm ZWN0IHRoZSBhbHJlYWR5IGVzdGFibGlzaGVkIExDQVMNICAgICAgbWVtYmVycywgdGhhdCBpcywg Y2xpZW50IHRyYWZmaWMgaXMgbm90IHNlbnQgb24gdGhlIG5ldyBjb21wb25lbnQNICAgICAgdW50 aWwgdGhlIExDQVMgcHJvY2VkdXJlIGlzIGNvbXBsZXRlOw0NICAgICAgVGhpcyBjYW4gYmUgc3Vw cG9ydGVkIHdpdGhpbiBHTVBMUyBpZiwgYWZ0ZXIgR01QTFMgaGFzDSAgICAgIHN1Y2Nlc3NmdWxs eSBlc3RhYmxpc2hlZCBhIHBvdGVudGlhbCBuZXcgY29tcG9uZW50LCB0aGUgc291cmNlIGVuZA0g ICAgICBMQ0FTIGlzIChpbnRlcm5hbGx5KSB0b2xkIHRvIGFkZCBpdCB0byB0aGUgZ3JvdXAuDQ0g ICBDb21wb25lbnQgUmVtb3ZhbDogV2hlbiBhIGNvbXBvbmVudCBpcyByZW1vdmVkIHRoZSBmb2xs b3dpbmcNICAgICAgcHJvY2VkdXJlIGFwcGxpZXM6DQ0JMS4gCU9uIHJlY2VpcHQgb2YgYSByZW1v dmUgY29tbWFuZCAoZm9yIGEgcGFydGljdWxhciBtZW1iZXIpIGZyb20gdGhlIG1hbmFnZW1lbnQg c3lzdGVtLCBMQ0FTIFNvdXJjZSB3aWxsIHN0b3AgdXNpbmcgdGhhdCBtZW1iZXI7IHRoZSBTaW5r IHdpbGwgcmVjb2duaXplIHRoYXQgdGhhdCBtZW1iZXIgbm8gbG9uZ2VyIGNhcnJpZXIgY2xpZW50 IHRyYWZmaWMgYW5kIHdpbGwgdXNlIG9ubHkgdGhlIHJlbWFpbmluZyBtZW1iZXJzIHRvIHJlY29u c3RpdHV0ZSB0aGUgY2xpZW50IHNpZ25hbC4gTm90ZTogVGhlIGN1cnJlbnQgTENBUyBwcm90b2Nv bCBhbGxvd3MgZm9yIHRoZSCRZGVjcmVhc2WSIGNvbW1hbmQgdG8gYmUgaW5pdGlhdGVkIGF0IGVp dGhlciB0aGUgTENBUyBzb3VyY2Ugb3IgdGhlIExDQVMgc2luazsgaWYgaXQgaXMgaW5pdGlhdGVk IGF0IHRoZSBzaW5rIHRoZXJlIHdpbGwgYmUgYSBoaXQgdG8gdGhlIHJlY29uc3RydWN0ZWQgZGF0 YS4gDQkNCTIuCVRoZSBjb25uZWN0aW9uLCBzb3VyY2UgcHJvdmlzaW9uaW5nIGFuZCBzaW5rIHBy b3Zpc2lvbmluZyBvZiB0aGF0IG1lbWJlciBjYW4gdGhlbiBiZSByZW1vdmVkIGZyb20gdGhlIFZD Ry4NDSAgICAgIDEuICBMQ0FTIHByb3RvY29sIGlzIHVzZWQgdG8gcmVtb3ZlIHRoZSBjb21wb25l bnQgZnJvbSB0aGUgZ3JvdXAsDSAgICAgICAgICB0aGF0IGlzLCBpbmNvbWluZyB0cmFmZmljIGNs aWVudCBkYXRhIGlzIHRyYW5zbWl0dGVkIG9uIHRoZQ0gICAgICAgICAgb3RoZXIgVkNBVCBjb21w b25lbnQocykgdG8gYXNzdXJlIHRoYXQgdGhlIHByb2NlZHVyZSBpcyBub3QNICAgICAgICAgIHRy YWZmaWMgYWZmZWN0aW5nDQ0gICAgICAyLiAgQ29uZmlndXJlIHRoZSBhZGFwdGF0aW9uIHNvdXJj ZS9zaW5rIGZ1bmN0aW9ucyBhbmQgY2hhbmdlIHRoZQ0gICAgICAgICAgbnVtYmVyIG9mIGNvbXBv bmVudHMgWSB0byBZLTE7IGkuZS4gcmVtb3ZlIHRoZSBWQy1uIGFjY2Vzcw0gICAgICAgICAgcG9p bnQgZnJvbSB0aGUgZ3JvdXAuDQ0NDQ1CZXJuc3RlaW4sIGV0IGFsLiAgICAgICAgRXhwaXJlcyBB cHJpbCAxNCwgMjAwNiAgICAgICAgICAgICAgICAgW1BhZ2UgN10NDA1JbnRlcm5ldC1EcmFmdCAg ICAgICAgICAgIEdNUExTLCBWQ0FUIGFuZCBMQ0FTICAgICAgICAgICAgICBPY3RvYmVyIDIwMDUN DQ0gICAgICAzLiAgVGhlIGNvbXBvbmVudCBjb25uZWN0aW9uIGNhbiBiZSwgaWYgbmVlZGVkLCBy ZW1vdmVkIGZyb20gdGhlDSAgICAgICAgICB0cmFuc3BvcnQgbmV0d29yay4NDSAgICAgIFRoaXMg Y2FuIGJlIHN1cHBvcnRlZCB3aXRoaW4gR01QTFMgaWYsIGJlZm9yZSBHTVBMUyB0ZWFycyBkb3du IGENICAgICAgY29tcG9uZW50LCBMQ0FTIGlzIHRvbGQgKGxvY2FsIHRvIHNvdXJjZSBlbmQpIHRv IHJlbW92ZSB0aGUNICAgICAgY29tcG9uZW50IGZyb20gc2VydmljZSBpbiB0aGUgZ3JvdXAuDQ0N ICAgQ29tcG9uZW50IEZhaWx1cmU6IFdoZW4gYSBjb21wb25lbnQgZmFpbHM6LCANDQkxLgl0VGhl IExDQVMgc2luayBkZXRlY3RzIHRoZSANICAgICAgZmFpbHVyZSAoaG93IHRoaXMgaXMgZG9uZSBp cyBvdXRzaWRlIHRoZSBzY29wZSBvZiB0aGlzIElEKSBhbmQgDSAgICAgIGluZm9ybXMgdGhlIHNv dXJjZSBvZiB0aGlzIGZhaWx1cmUgdmlhIHRoZSBtZW1iZXIgc3RhdHVzIChNU1QpDSAgICAgIGlu Zm9ybWF0aW9uLiAgVGhlIHNvdXJjZSB0aGVuOg0NDSAgICAgIDIxLgkgIFRoZSBzb3VyY2UgdGhl biBUdGFrZXMgdGhlIGZhaWxlZCBjb21wb25lbnQgb3V0IG9mIHNlcnZpY2UgYW5kIGFuZCB1c2Vz IG9ubHkgdGhlIHJlbWFpbmluZyCRZ29vZJIgbWVtYmVycyB0byB0cmFuc3BvcnQgdGhlIGNsaWVu dCB0cmFmZmljLiBOb3RlOiBObyByZS1zZXF1ZW5jaW5nIG9mIHRoZSBWQ0cgaXMgZG9uZSBhdCB0 aGlzIHRpbWUuaWYgbmVjZXNzYXJ5DSAgICAgICAgICByZWFycmFuZ2VzIHRoZSBzZXF1ZW5jaW5n IG9mIHRoZSBWQ0FUIGdyb3VwLg0NICAgICAgMi4gIEluZm9ybXMgdGhlIHNpbmsgYWJvdXQgdGhl IGNvbXBvbmVudCByZW1vdmVkIGZyb20gc2VydmljZSBhbmQNICAgICAgICAgIGFueSByZS1hcnJh bmdpbmcgb2YgdGhlIFZDQVQgZ3JvdXAuDQ0gICAgICBXaGVuIHRoZSBmYWlsZWQgY29tcG9uZW50 IGlzIHJlcGFpcmVkLCBMQ0FTIGNhbiBhdXRvbWF0aWNhbGx5IGFkZA0gICAgICB0aGUgcmVwYWly ZWQgY29tcG9uZW50IGJhY2sgdG8gdGhlIGdyb3VwLCBvciBhbHRlcm5hdGl2ZWx5IGEgbmV3DSAg ICAgIGNvbXBvbmVudCBjYW4gYmUgYWRkZWQgdG8gYnJpbmcgdGhlIGdyb3VwIGJhY2sgdG8gaXRz IG9yaWdpbmFsDSAgICAgIHNpemUuICBOb3RlIHRoYXQgY29tcG9uZW50IGZhaWx1cmUgaXMgbm90 IGhpdGxlc3MsIGJ1dCBub3RlIHRoZQ0gICAgICBmYXN0IG5vdGlmaWNhdGlvbiB0aW1lcyBvZiBb QmVybkRpZWdvUmFiYmF0XS4FDQ0gICAgICBDdXJyZW50bHkgc3VwcG9ydGVkIHNpbmNlIG5vIGFj dGlvbiByZXF1aXJlZCBvZiBHTVBMUy4FDQ0yLjUuICBDb21wb25lbnQgU2lnbmFsIENvbmZpZ3Vy YXRpb24gU2NlbmFyaW9zDQ0gICBIZXJlIHdlIHVzZSB0aGUgdGVybSAiZ3JvdXAiIHRvIHJlZmVy IHRvIHRoZSBlbnRpcmUgVkNBVCBncm91cFZDRyBhbmQNICAgdGhlIHRlcm1pbm9sb2d5ICJzZXQi IGFuZCAic3Vic2V0IiB0byByZWZlciB0byB0aGUgY29sbGVjdGlvbiBvZg0gICBwb3RlbnRpYWwg VkNBVCBncm91cFZDRyBtZW1iZXIgc2lnbmFscwUuICBOb3RlIHRoYXQgYWxsIGFzc2VzbWVudHMg b2YNICAgd2hldGhlciBhIHNjZW5hcmlvIGlzIGN1cnJldGx5IHN1cHBvcnRlZCBhc3N1bWVzIGVp dGhlciAoYSkgYSBzaW5nbGUNICAgVkNBVCBncm91cFZDRyBwZXIgR01QTFMgYWRkcmVzc2FibGUg ZW50aXR5LCBvciAoYikgYSBtZWNoYW5pc20gaXMgaW4NICAgcGxhY2UgdG8gZGlzYW1iaWd1YXRl IG11bHRpcGxlIFZDQVQgZ3JvdXBWQ0dzIChzZWUgU2VjdGlvbiAyLjIpLg0NICAgRml4ZWQsIENv LXJvdXRlZDogQSBmaXhlZCBiYW5kd2lkdGggVkNBVCBncm91cFZDRywgd2l0aCBhbGwgbWVtYmVy cyB0cmFuc3BvcnRlZCBvdmVyIGENICAgICAgY28tcm91dGVkIHNldCBvZiBtZW1iZXIgc2lnbmFs c3RoZSBzYW1lIHJvdXRlLiAgVGhpcyBpcyB0aGUgY2FzZSB3aGVyZSB0aGUNICAgICAgaW50ZW5k ZWQgYmFuZHdpZHRoIG9mIHRoZSBWQ0FUIGdyb3VwVkNHIGRvZXMgbm90IGNoYW5nZSBhbmQgYWxs DSAgICAgIG1lbWJlciBzaWduYWxzIGZvbGxvdyBhIHNpbWlsYXJ0aGUgc2FtZSByb3V0ZS4gIFRo ZSBpbnRlbnQgaGVyZSBpcyB0aGUNICAgICAgY2FwYWJpbGl0eSB0byBhbGxvY2F0ZSB0aGUgInJp Z2h0IiBhbW91bnQgb2YgYmFuZHdpZHRoLg0NICAgICAgQ3VycmVudGx5IHN1cHBvcnRlZCBpbiBH TVBMUy4NDSAgIEZpeGVkLCBEaXNqb2ludERpdmVyc2Utcm91dGVzOiBBIGZpeGVkIGJhbmR3aWR0 aCBWQ0FUIGdyb3VwVkNHLCB3aXRoIHRoZSBtZW1iZXJzIHRyYW5zcG9ydGVkIG92ZXIgYXQNICAg ICAgbGVhc3QgdHdvIGRpc2pvaW50bHkgZGlmZmVyZW50IHJvdXRlZCBzdWJzZXRzIG9mIG1lbWJl ciBzaWduYWxzcm91dGVzLiAgVGhlIGludGVudA0gICAgICBoZXJlIGlzIGFkZGl0aW9uYWwgcmVz aWxpZW5jZSBhbmQgZ3JhY2VmdWwgZGVncmFkYXRpb24gaW4gdGhlIGNhc2UNICAgICAgb2YgZmFp bHVyZS4NDQ0NDUJlcm5zdGVpbiwgZXQgYWwuICAgICAgICBFeHBpcmVzIEFwcmlsIDE0LCAyMDA2 ICAgICAgICAgICAgICAgICBbUGFnZSA4XQ0MDUludGVybmV0LURyYWZ0ICAgICAgICAgICAgR01Q TFMsIFZDQVQgYW5kIExDQVMgICAgICAgICAgICAgIE9jdG9iZXIgMjAwNQ0NDSAgICAgIElmIExD QVMgaXMgcHJlc2VudCB0aGlzIHNjZW5hcmlvIGlzIHN1cHBvcnRlZCB1bmRlciBHTVBMUy4gIE5v dA0gICAgICBzdXBwb3J0ZWQgd2l0aG91dCBMQ0FTIHNpbmNlIHdlIG5lZWQgdHdvLXdheSBjb21t dW5pY2F0aW9ucyBvZg0gICAgICBzb21lIHR5cGUgYmV0d2VlbiBzb3VyY2UgYW5kIHNpbmsgdG8g Y29vcmRpbmF0ZSB3aGljaCBtZW1iZXJzIGFyZQ0gICAgICB0byBiZSB1c2VkIGluIHRoZSBncm91 cCBpbiBhIGZhaWx1cmUgc2NlbmFyaW8uDQ0gICBEeW5hbWljLCBDby1yb3V0ZWQ6IEEgZHluYW1p YyBWQ0FUIGdyb3VwVkNHIChiYW5kd2lkdGggY2FuIGJlIGluY3JlYXNlZA0gICAgICBvciBkZWNy ZWFzZWQgdmlhIHRoZSBhZGRpdGlvbiBvciByZW1vdmFsIG9mIG1lbWJlciBzaWduYWxzKSwNICAg ICAgd2l0aCBhbGwgdGhlIG1lbWJlcnMgdHJhbnNwb3J0ZWQgb3ZlciBhIGNvLXJvdXRlZCBzZXQg b2YgbWVtYmVyc3RoZSBzYW1lIHJvdXRlLiAgSW50ZW50IGhlcmUgaXMNICAgICAgZHluYW1pYyBz aXppbmcgb2YgYmFuZHdpZHRoLg0NICAgICAgSWYgTENBUyBwcmVzZW50IHRoaXMgc2NlbmFyaW8g aXMgY3VycmVudGx5IHN1cHBvcnRlZCBieSBHTVBMUy4NICAgICAgSW1wbGljYXRpb25zOiBMQ0FT IGlzIG5lZWRlZCBmb3IgaGl0bGVzcyByZXNpemluZy4gIE5vdGUgYmVmb3JlDSAgICAgIExDQVMg Y2FuIGRvIGl0cyBwYXJ0IG9mIGdldHRpbmcgdHJhZmZpYyBvdmVyIHRoZSBtb2RpZmllZCBWQ0FU DSAgICAgIGdyb3VwVkNHLCB0aGUgdHdvIFZDQVQvTENBUyBlbmRwb2ludHMgbmVlZCB0byBiZSBj b25maWd1cmVkIChZIC0+IFkrMQ0gICAgICBvciBZIC0+IFktMSlYbSBhbmQgWGE7IHRoaXMgcmVx dWlyZXMgZWl0aGVyICJjb21tdW5pY2F0aW9uIiBiZXR3ZWVuIHRoZSB0d28NICAgICAgZW5kcG9p bnRzICh3aGVuIG9uZSBvZiB0aGUgZW5kcG9pbnRzIGlzIGNvbmZpZ3VyZWQgYnkgY2FsbC8NICAg ICAgY29ubmVjdGlvbiBjb250cm9sbGVyLCBvciBzaW1wbGUgY29tbXVuaWNhdGlvbiBvZiB0aGUg Y2FsbC8NICAgICAgY29ubmVjdGlvbiBjb250cm9sbGVyIHdpdGggYm90aCBlbmRwb2ludHMuICBX aXRob3V0IExDQVMgd2Ugc3RpbGwNICAgICAgbmVlZCB0d28gd2F5IGNvbW11bmljYXRpb25zIGJl dHdlZW4gc291cmNlIGFuZCBzaW5rIHRvIGNvb3JkaW5hdGUNICAgICAgd2hpY2ggbWVtYmVycyBh cmUgdXNlZCBpbiB0aGUgZ3JvdXAgYW5kBSBjaGFuZ2VzIHdpbGwgbm90IGJlDSAgICAgIGhpdGxl c3MuDQ0gICBEeW5hbWljLCBEaXNqb2ludERpdmVyc2Utcm91dGVzOiBBIGR5bmFtaWMgVkNBVCBn cm91cFZDRywgd2l0aCB0aGUgbWVtYmVycyB0cmFuc3BvcnRlZCBvdmVyIGF0IGxlYXN0DSAgICAg IHR3byBkaXNqb2ludGx5IGRpZmZlcmVudCByb3V0ZWQgc3Vic2V0cyBvZiBtZW1iZXIgc2lnbmFs c3JvdXRlcy4gIEludGVudCBoZXJlIGlzDSAgICAgIGR5bmFtaWMgcmVzaXppbmcgYW5kIHJlc2ls aWVuY2UuDQ0gICAgICBDdXJyZW50bHkgc3VwcG9ydCBhbmQgaW1wbGljYXRpb25zIHNpbWlsYXIg dG8gdGhlICJkeW5hbWljLCBjby0NICAgICAgcm91dGVkIiBhbmQgImZpeGVkLCBkaXNqb2ludGRp dmVyc2Utcm91dGVzIiBjYXNlcy4NDSAgIFNoYXJlZCBQb29sOiBUd28gb3IgbW9yZSBWQ0FUIGdy b3VwVkNHcyBiZXR3ZWVuIHRoZSBzYW1lIHNvdXJjZSBhbmQgc2luaw0gICAgICB3aG8gZGVzaXJl IHRvIHNoYXJlIGEgcG9vbCBvZiBjb21wb25lbnQgc2lnbmFscyBiZXR3ZWVuIHRoZW0uDSAgICAg IEVhY2ggVkNBVCBncm91cFZDRyBtYXkgaGF2ZSBhIGRlZGljYXRlZCBzZXQgb2YgbWVtYmVycywg YW5kIG1heSBhbHNvDSAgICAgIG9idGFpbiBhZGRpdGlvbmFsIG1lbWJlcnMgZnJvbSBhICJjb21t b24gcG9vbCIgb2YgY29tcG9uZW50cy4NICAgICAgTm90ZSB0aGF0IGF0IGFueSBnaXZlbiBwb2lu dCBpbiB0aW1lIGEgY29tcG9uZW50IHNpZ25hbCBjYW4gYmVsb25nDSAgICAgIHRvIGF0IG1vc3Qg b25lIFZDQVQgZ3JvdXBWQ0cuICBUaGUgaW50ZW50IGhlcmUgaXMgdG8gYWxsb3cgZHluYW1pYw0g ICAgICByZXNpemluZyBvZiBWQ0FUIGdyb3VwVkNHcyB2aWEgdGhlIHNoYXJpbmcgb2YgYSBwb29s IG9mIGVzdGFibGlzaGVkDSAgICAgIGNvbXBvbmVudCBzaWduYWxzIHdpdGhvdXQgcmVxdWlyaW5n IGNvbXBsZXRlIGNpcmN1aXQgcHJvdmlzaW9uaW5nLA0gICAgICBpLmUuLCBvbmx5IHRoZSBncm91 cCBtZW1iZXJzaGlwIG9mIHRoZSBjb21wb25lbnQgc2lnbmFsIHdvdWxkDSAgICAgIGNoYW5nZS4F DQ0gICAgICBDdXJyZW50bHkgbm90IHN1cHBvcnRlZCBieSBHTVBMUy4gIEltcGxpY2F0aW9uczog YSBjb21tdW5pY2F0aW9ucw0gICAgICBtZWNoYW5pc20gYmV0d2VlbiBzb3VyY2UgYW5kIHNpbmsg dG8gaW5kaWNhdGUgZHVyaW5nIGEgImNoYW5nZSINICAgICAgd2hpY2ggZ3JvdXAgYSBjb21wb25l bnQgc2hvdWxkIG5vdyBiZWxvbmcuDQ0NDQ0NDQ0NQmVybnN0ZWluLCBldCBhbC4gICAgICAgIEV4 cGlyZXMgQXByaWwgMTQsIDIwMDYgICAgICAgICAgICAgICAgIFtQYWdlIDldDQwNSW50ZXJuZXQt RHJhZnQgICAgICAgICAgICBHTVBMUywgVkNBVCBhbmQgTENBUyAgICAgICAgICAgICAgT2N0b2Jl ciAyMDA1DQ0NMy4gIFBvc3NpYmxlIEV4dGVuc2lvbnMgdG8gR01QTFMgdG8gc3VwcG9ydCBhZGRp dGlvbmFsIFZDQVQvTENBUw0gICAgc2NlbmFyaW9zDQ0gICBIZXJlIHdlIGxvb2sgYXQgd2hhdCBt aWdodCBiZSByZWFzb25hYmxlIHRvIGFkZCB0byBHTVBMUyB0byBzdXBwb3J0DSAgIHRoZSBpbnRl cmVzdCBzY2VuYXJpb3Mgb2YgU2VjdGlvbiAyIHRoYXQgd2VyZSBub3QgY3VycmVudGx5IGNvdmVy ZWQuDQ0zLjEuICBNZWNoYW5pc21zIGZvciBEaXNjb3Zlcnkgb2YgVkNBVC9MQ0FTDQ0gICBXb3Vs ZCBsaWtlIHRvIGdldCBib3RoIFZDQVQgYW5kIExDQVMgY2FwYWJpbGl0eSBvZiBlbmQgc3lzdGVt cyB2aWENICAgcm91dGluZy4uLg0NICAgV291bGQgbGlrZSB0byBiZSBhYmxlIHRvIHNwZWNpZmlj YWxseSBhc2sgZm9yIExDQVMgY2FwYWJpbGl0eSB2aWENICAgc2lnbmFsaW5nLi4uDQ0zLjIuICBN ZWNoYW5pc20gdG8gU3VwcG9ydCBNdWx0aXBsZSBDbGllbnQgdG8gRW5kIFBvaW50IE1hcHBpbmdz DQ0gICBUaGlzIGlzIGEgdmVyeSBpbXBvcnRhbnQgY2FwYWJpbGl0eSBhbmQgaXQgaXMgdmVyeSBz aW1pbGFyIHRvIG9uZQ0gICB0aGF0IGlzIGJlaW5nIHByb3Bvc2VkIGluIHRoZSBlbmQtdG8tZW5k IHNpZ25hbGluZyBmb3IgcmVjb3ZlcnkgSS1ELg0gICBJbiBwYXJ0aWN1bGFyIHRoZSBBU1NPQ0lB VElPTiBvYmplY3QuICBOb3RlLCBob3dldmVyLCBzaW5jZSB0aGVyZSBpcw0gICBhIHJhdGhlciBo aWdoIHByb2JhYmlsaXR5IHRoYXQgYXQgc29tZSBwb2ludCB3ZSBtaWdodCB1c2UgVkNBVC9MQ0FT DSAgIHdpdGggR01QTFMgYmFzZWQgcHJvdGVjdGlvbiB3ZSB3b3VsZCByZWFsbHkgbmVlZCBhbiBB U1NPQ0lBVElPTg0gICBvYmplY3QgdHlwZSBzcGVjaWZpYyB0byBWQ0FULiAgQXNzb2NpYXRpb24g b2JqZWN0cyBhcmUgbm90IHVuaXF1ZSBhbmQNICAgdGhlcmVmb3JlIGFkZGluZyBhIG5ldyB0eXBl IHRvIHRoZSBBc3NvY2lhdGlvbiBvYmplY3Qgd291bGQgbWFrZSBpdCBhDSAgIGdvb2QgY2FuZGlk YXRlIHRvIHN1cHBvcnQgdGhpcyByZXF1aXJlbWVudC4NDTMuMy4gIFN1cHBvcnQgZm9yIENvbXBv bmVudCBTaWduYWwgQ29uZmlndXJhdGlvbiBTY2VuYXJpb3MNDSAgIFRCRCBiYXNlZCBvbiBhbmFs eXNpcyBvZiB1c2Ugb2YgYWRtaW4tc3RhdHVzIG9iamVjdC4gIElmIHRoZSBhZG1pbi0NICAgc3Rh dHVzIG9iamVjdCBpcyBzdWZmaWNpZW50IHdlIHdpbGwgZGV0YWlsIGl0cyB1c2UgaW4gdGhpcw0g ICBhcHBsaWNhdGlvbiBzaW5jZSBpdCBpcyBjdXJyZW50bHkgYW4gb3B0aW9uYWwgb2JqZWN0Lg0N NC4gIFJlZmVyZW5jZXMNDSAgIFsxXSAgQmVybnN0ZWluLCBHLiwgQ2F2aWdsaWEsIEQuLCBhbmQg Ui4gUmFiYmF0LCAiVkNBVC9MQ0FTIGluIGENICAgICAgICBDbGFtc2hlbGwiLCBUbyBCZSBQdWJs aXNoZWQgYXZhaWxhYmxlIGF0IGh0dHA6Ly8NICAgICAgICB3d3cuZ3JvdHRvLW5ldHdvcmtpbmcu Y29tL3BhZ2VzL1ZDQVQtaW4tYS1DbGFtc2hlbGwtRFJBRlQucGRmLA0gICAgICAgIE9jdG9iZXIg MjAwNS4NDSAgIFsyXSAgSW50ZXJuYXRpb25hbCBUZWxlY29tbXVuaWNhdGlvbnMgVW5pb24sICJO ZXR3b3JrIG5vZGUgaW50ZXJmYWNlDSAgICAgICAgZm9yIHRoZSBzeW5jaHJvbm91cyBkaWdpdGFs IGhpZXJhcmNoeSAoU0RIKSIsIElUVS0NICAgICAgICBUIFJlY29tbWVuZGF0aW9uIEcuNzA3LCBE ZWNlbWJlciAyMDAzLg0NICAgWzNdICBBbWVyaWNhbiBOYXRpb25hbCBTdGFuZGFyZHMgSW5zdGl0 dXRlLCAiU3luY2hyb25vdXMgT3B0aWNhbA0gICAgICAgIE5ldHdvcmsgKFNPTkVUKSAtIEJhc2lj IERlc2NyaXB0aW9uIGluY2x1ZGluZyBNdWx0aXBsZXgNICAgICAgICBTdHJ1Y3R1cmUsIFJhdGVz LCBhbmQgRm9ybWF0cyIsIEFOU0kgVDEuMTA1LTIwMDEsIDIwMDEuDQ0gICBbNF0gICJMaW5rIGNh cGFjaXR5IGFkanVzdG1lbnQgc2NoZW1lIChMQ0FTKSBmb3IgdmlydHVhbCBjb25jYXRlbmF0ZWQN ICAgICAgICBzaWduYWxzIiwgSVRVLVQgUmVjb21tZW5kYXRpb24gRy43MDQyLCBGZWJydWFyeSAy MDA0Lg0NDQ1CZXJuc3RlaW4sIGV0IGFsLiAgICAgICAgRXhwaXJlcyBBcHJpbCAxNCwgMjAwNiAg ICAgICAgICAgICAgICBbUGFnZSAxMF0NDA1JbnRlcm5ldC1EcmFmdCAgICAgICAgICAgIEdNUExT LCBWQ0FUIGFuZCBMQ0FTICAgICAgICAgICAgICBPY3RvYmVyIDIwMDUNDQ0gICBbNV0gICJWaXJ0 dWFsIGNvbmNhdGVuYXRpb24gb2YgcGxlc2lvY2hyb25vdXMgZGlnaXRhbCBoaWVyYXJjaHkgKFBE SCkNICAgICAgICBzaWduYWxzIiwgSVRVLVQgUmVjb21tZW5kYXRpb24gRy43MDQzLCBKdWx5IDIw MDQuDQ0gICBbNl0gICJJbnRlcmZhY2VzIGZvciB0aGUgT3B0aWNhbCBUcmFuc3BvcnQgTmV0d29y ayAoT1ROKSIsIElUVS0NICAgICAgICBUIFJlY29tbWVuZGF0aW9uIEcuNzA5LCBNYXJjaCAyMDAz Lg0NICAgWzddICBTa2xvd2VyLCBLLiwgTGxveWQsIEIuLCBNY0dyZWdvciwgRy4sIENhcnIsIEQu LCBhbmQgVC4NICAgICAgICBDb3JhZGV0dGksICJUaGUgUFBQIE11bHRpbGluayBQcm90b2NvbCAo TVApIiwgUkZDIDE5OTAsDSAgICAgICAgQXVndXN0IDE5OTYuDQ0gICBbOF0gICJJbmZvcm1hdGlv biB0ZWNobm9sb2d5IC0gVGVsZWNvbW11bmljYXRpb25zIGFuZCBpbmZvcm1hdGlvbg0gICAgICAg IGV4Y2hhbmdlIGJldHdlZW4gc3lzdGVtcyAtIExvY2FsIGFuZCBtZXRyb3BvbGl0YW4gYXJlYSBu ZXR3b3Jrcw0gICAgICAgIC0gU3BlY2lmaWMgcmVxdWlyZW1lbnRzIC0gUGFydCAzOiBDYXJyaWVy IHNlbnNlIG11bHRpcGxlIGFjY2Vzcw0gICAgICAgIHdpdGggY29sbGlzaW9uIGRldGVjdGlvbiAo Q1NNQS9DRCkgYWNjZXNzIG1ldGhvZCBhbmQgcGh5c2ljYWwNICAgICAgICBsYXllciBzcGVjaWZp Y2F0aW9ucyIsIElFRUUgU3RhbmRhcmQgODAyLjMsIE1hcmNoIDIwMDIuDQ0gICBbOV0gIEJlcm5z dGVpbiwgRy4sIFJhamFnb3BhbGFuLCBCLiwgYW5kIEQuIFNhaGEsICJPcHRpY2FsIE5ldHdvcmsN ICAgICAgICBDb250cm9sOiBBcmNodGVjdHVyZSwgUHJvdG9jb2xzIiwgQWRkaXNvbi1XZXNsZXks IDIwMDQuDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDUJlcm5zdGVpbiwgZXQgYWwu ICAgICAgICBFeHBpcmVzIEFwcmlsIDE0LCAyMDA2ICAgICAgICAgICAgICAgIFtQYWdlIDExXQ0M DUludGVybmV0LURyYWZ0ICAgICAgICAgICAgR01QTFMsIFZDQVQgYW5kIExDQVMgICAgICAgICAg ICAgIE9jdG9iZXIgMjAwNQ0NDUFwcGVuZGl4IEEuICBBY2tub3dsZWRnZW1lbnRzDQ0gICBUaGUg YXV0aG9ycyB3b3VsZCBsaWtlIHRvIHRoYW5rIE1hYXJ0ZW4gVmlzc2VycyBmb3IgZXh0ZW5zaXZl IHJldmlld3MNICAgYW5kIGNvbnRyaWJ1dGlvbnMgdG8gdGhpcyBkcmFmdC4NDQ0NDQ0NDQ0NDQ0N DQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ1CZXJuc3RlaW4sIGV0IGFsLiAgICAg ICAgRXhwaXJlcyBBcHJpbCAxNCwgMjAwNiAgICAgICAgICAgICAgICBbUGFnZSAxMl0NDA1JbnRl cm5ldC1EcmFmdCAgICAgICAgICAgIEdNUExTLCBWQ0FUIGFuZCBMQ0FTICAgICAgICAgICAgICBP Y3RvYmVyIDIwMDUNDQ1BdXRob3JzJyBBZGRyZXNzZXMNDSAgIEdyZWcgQmVybnN0ZWluDSAgIEdy b3R0byBOZXR3b3JraW5nDQ0gICBQaG9uZTogKzEgNTEwIDU3MyAyMjM3DSAgIEVtYWlsOiBncmVn YkBncm90dG8tbmV0d29ya2luZy5jb20NDQ0gICBEaWVnbyBDYXZpZ2xpYQ0gICBNYXJjb25pDQ0g ICBFbWFpbDogRGllZ28uQ2F2aWdsaWFAbWFyY29uaS5jb20NDQ0gICBSaWNoYXJkIFJhYmJhdA0g ICBGdWppdHN1DQ0gICBQaG9uZTogKzEgNDA4IDUzMCA0NTM3DSAgIEVtYWlsOiByaWNoYXJkQHVz LmZ1aml0c3UuY29tDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ1CZXJuc3RlaW4sIGV0 IGFsLiAgICAgICAgRXhwaXJlcyBBcHJpbCAxNCwgMjAwNiAgICAgICAgICAgICAgICBbUGFnZSAx M10NDA1JbnRlcm5ldC1EcmFmdCAgICAgICAgICAgIEdNUExTLCBWQ0FUIGFuZCBMQ0FTICAgICAg ICAgICAgICBPY3RvYmVyIDIwMDUNDQ1JbnRlbGxlY3R1YWwgUHJvcGVydHkgU3RhdGVtZW50DQ0g ICBUaGUgSUVURiB0YWtlcyBubyBwb3NpdGlvbiByZWdhcmRpbmcgdGhlIHZhbGlkaXR5IG9yIHNj b3BlIG9mIGFueQ0gICBJbnRlbGxlY3R1YWwgUHJvcGVydHkgUmlnaHRzIG9yIG90aGVyIHJpZ2h0 cyB0aGF0IG1pZ2h0IGJlIGNsYWltZWQgdG8NICAgcGVydGFpbiB0byB0aGUgaW1wbGVtZW50YXRp b24gb3IgdXNlIG9mIHRoZSB0ZWNobm9sb2d5IGRlc2NyaWJlZCBpbg0gICB0aGlzIGRvY3VtZW50 IG9yIHRoZSBleHRlbnQgdG8gd2hpY2ggYW55IGxpY2Vuc2UgdW5kZXIgc3VjaCByaWdodHMNICAg bWlnaHQgb3IgbWlnaHQgbm90IGJlIGF2YWlsYWJsZTsgbm9yIGRvZXMgaXQgcmVwcmVzZW50IHRo YXQgaXQgaGFzDSAgIG1hZGUgYW55IGluZGVwZW5kZW50IGVmZm9ydCB0byBpZGVudGlmeSBhbnkg c3VjaCByaWdodHMuICBJbmZvcm1hdGlvbg0gICBvbiB0aGUgcHJvY2VkdXJlcyB3aXRoIHJlc3Bl Y3QgdG8gcmlnaHRzIGluIFJGQyBkb2N1bWVudHMgY2FuIGJlDSAgIGZvdW5kIGluIEJDUCA3OCBh bmQgQkNQIDc5Lg0NICAgQ29waWVzIG9mIElQUiBkaXNjbG9zdXJlcyBtYWRlIHRvIHRoZSBJRVRG IFNlY3JldGFyaWF0IGFuZCBhbnkNICAgYXNzdXJhbmNlcyBvZiBsaWNlbnNlcyB0byBiZSBtYWRl IGF2YWlsYWJsZSwgb3IgdGhlIHJlc3VsdCBvZiBhbg0gICBhdHRlbXB0IG1hZGUgdG8gb2J0YWlu IGEgZ2VuZXJhbCBsaWNlbnNlIG9yIHBlcm1pc3Npb24gZm9yIHRoZSB1c2Ugb2YNICAgc3VjaCBw cm9wcmlldGFyeSByaWdodHMgYnkgaW1wbGVtZW50ZXJzIG9yIHVzZXJzIG9mIHRoaXMNICAgc3Bl Y2lmaWNhdGlvbiBjYW4gYmUgb2J0YWluZWQgZnJvbSB0aGUgSUVURiBvbi1saW5lIElQUiByZXBv c2l0b3J5IGF0DSAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaXByLg0NICAgVGhlIElFVEYgaW52aXRl cyBhbnkgaW50ZXJlc3RlZCBwYXJ0eSB0byBicmluZyB0byBpdHMgYXR0ZW50aW9uIGFueQ0gICBj b3B5cmlnaHRzLCBwYXRlbnRzIG9yIHBhdGVudCBhcHBsaWNhdGlvbnMsIG9yIG90aGVyIHByb3By aWV0YXJ5DSAgIHJpZ2h0cyB0aGF0IG1heSBjb3ZlciB0ZWNobm9sb2d5IHRoYXQgbWF5IGJlIHJl cXVpcmVkIHRvIGltcGxlbWVudA0gICB0aGlzIHN0YW5kYXJkLiAgUGxlYXNlIGFkZHJlc3MgdGhl IGluZm9ybWF0aW9uIHRvIHRoZSBJRVRGIGF0DQ0gICBpZXRmLWlwckBpZXRmLm9yZy4NDQ1EaXNj bGFpbWVyIG9mIFZhbGlkaXR5DQ0gICBUaGlzIGRvY3VtZW50IGFuZCB0aGUgaW5mb3JtYXRpb24g Y29udGFpbmVkIGhlcmVpbiBhcmUgcHJvdmlkZWQgb24gYW4NICAgIkFTIElTIiBiYXNpcyBhbmQg VEhFIENPTlRSSUJVVE9SLCBUSEUgT1JHQU5JWkFUSU9OIEhFL1NIRSBSRVBSRVNFTlRTDSAgIE9S IElTIFNQT05TT1JFRCBCWSAoSUYgQU5ZKSwgVEhFIElOVEVSTkVUIFNPQ0lFVFkgQU5EIFRIRSBJ TlRFUk5FVA0gICBFTkdJTkVFUklORyBUQVNLIEZPUkNFIERJU0NMQUlNIEFMTCBXQVJSQU5USUVT LCBFWFBSRVNTIE9SIElNUExJRUQsDSAgIElOQ0xVRElORyBCVVQgTk9UIExJTUlURUQgVE8gQU5Z IFdBUlJBTlRZIFRIQVQgVEhFIFVTRSBPRiBUSEUNICAgSU5GT1JNQVRJT04gSEVSRUlOIFdJTEwg Tk9UIElORlJJTkdFIEFOWSBSSUdIVFMgT1IgQU5ZIElNUExJRUQNICAgV0FSUkFOVElFUyBPRiBN RVJDSEFOVEFCSUxJVFkgT1IgRklUTkVTUyBGT1IgQSBQQVJUSUNVTEFSIFBVUlBPU0UuDQ0NQ29w eXJpZ2h0IFN0YXRlbWVudA0NICAgQ29weXJpZ2h0IChDKSBUaGUgSW50ZXJuZXQgU29jaWV0eSAo MjAwNSkuICBUaGlzIGRvY3VtZW50IGlzIHN1YmplY3QNICAgdG8gdGhlIHJpZ2h0cywgbGljZW5z ZXMgYW5kIHJlc3RyaWN0aW9ucyBjb250YWluZWQgaW4gQkNQIDc4LCBhbmQNICAgZXhjZXB0IGFz IHNldCBmb3J0aCB0aGVyZWluLCB0aGUgYXV0aG9ycyByZXRhaW4gYWxsIHRoZWlyIHJpZ2h0cy4N DQ1BY2tub3dsZWRnbWVudA0NICAgRnVuZGluZyBmb3IgdGhlIFJGQyBFZGl0b3IgZnVuY3Rpb24g aXMgY3VycmVudGx5IHByb3ZpZGVkIGJ5IHRoZQ0gICBJbnRlcm5ldCBTb2NpZXR5Lg0NDQ0NQmVy bnN0ZWluLCBldCBhbC4gICAgICAgIEV4cGlyZXMgQXByaWwgMTQsIDIwMDYgICAgICAgICAgICAg ICAgW1BhZ2UgMTRdDQwNBVdoaWxlIEkgYWdyZWUgd2l0aCB5b3VyIG5vbWVuY2xhdHVyZSBmb3Ig VkNBVHRlZCBQREggc2lnbmFscywgaXQgc2hvdWxkIGJlIHBvaW50ZWQgb3V0IHRoYXQgdGhpcyBo YXMgbm90IHlldCBiZWVuIHByb3Bvc2VkIG9yIGFjY2VwdGVkIHdpdGhpbiB0aGUgSVRVLVQgU0cx NS4NBUkgZG9uknQgaGF2ZSB0aGlzIHJlZmVyZW5jZSwgYnV0IHRoaW5rIGl0IHdvdWxkIGJlIHVz ZWZ1bCBmb3IgdGhlIHJlYWRlciB0byBiZSB0b2xkIHRoYXQgdGhlIG9wZXJhdGlvbiB0aW1lIG9m IExDQVMgYXJlIHNvbGUgZGVwZW5kYW50IG9uICgxKSB0aGUgcHJvcGFnYXRpb24gdGltZSBmb3Jt IFNvIHRvIFNrIGFuZCB0aGUgdGltZSB0aGF0IExDQVMgdGFrZXMgdG8gkWN5Y2xlkiByb3VuZCB0 byB0aGUgYXBwcm9wcmlhdGUgTVNUIGJ5dGUgdGhhdCBjb250YWlucyB0aGUgTVNUIGZvciB0aGUg cmVsZXZhbnQgbWVtYmVyLiBUaGUgd29yc3QgY2FzZSBjeWNsZSB0aW1lIGZvciBITyBpcyA2NCBt cyBhbmQgZm9yIExPIGl0IGlzIDEyOCBtcy4gTm90ZSB0aGlzIGRvZXMgbm90IHRha2UgaW50byBh Y2NvdW50IHRoZSBwcm9wYWdhdGlvbiB0aW1lKHMpLg0FSZJtIG5vdCBzdXJlIHdoYXQgaXMgbWVh bnQgaGVyZS4gSWYgkWRpdmVyc2Ugcm91dGluZ5IgaXMgbWVhbnQsIHRoZW4gSSB0aGluayB0aGlz IGlzIHRoZSB0ZXJtIHRoYXQgc2hvdWxkIGJlIHVzZWQ7IGhvd2V2ZXIgSSBhbSBub3QgZmFtaWxp YXIgZW5vdWdoIHdpdGggR01QTFMgdG8gY29tbWVudCBvbiB0aGlzIHN0YXRlbWVudC4NBUkgYW0g bm90IGZhbWlsaWFyIGVub3VnaCB3aXRoIEdNUExTIHRvIHVuZGVyc3RhbmQgd2h5IHRoaXMgaXMg c28uIFRoZSBWQ0FUIChvciBMQ0FTKSBmdW5jdGlvbiBkb2VzIG5vdCBrbm93IG9yIGNhcmUgYWJv dXQgdGhlIHJvdXRpbmcgb2YgdGhlIGluZGl2aWR1YWwgbWVtYmVycyBvZiB0aGUgVkNHOyBleGNl cHQgb2YgY291cnNlIHRoZSBkaWZmZXJlbnRpYWwgZGVsYXkgbXVzdCBiZSBrZXB0IHdpdGhpbiBt ZWFzdXJhYmxlIGFuZCBjb21wZW5zYXRhYmxlIGxpbWl0cy4NBVNlZSBwcmV2aW91cyBjb21tZW50 IGluIHNlY3Rpb24gMS4zLg0FVG8gYWRkIGFuIGFsdGVybmF0aXZlIG1lbWJlciBpbiBwbGFjZSBv ZiB0aGUgZmFpbGVkIG1lbWJlciB3aWxsIHJlcXVpcmUgbWFuYWdlbWVudCBpbnRlcnZlbnRpb24u DQVJIGJlbGlldmUgdGhlIHVzZSBvZiB0aGUgdGVybSBzdWJzZXQgaXMgZGFuZ2Vyb3VzIHNpbmNl IHNvbWUgcGVvcGxlIHdpbGwgdGhpbmsgb2YgYSBzdWJzZXQgYXMgYW5vdGhlciBWQ0cuIA0FU2hv dWxkIHRoaXMgYmUgkW9ykiA/Pw0FAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYAALMZAADI GQAA1hkAAN8ZAABlHAAAaxwAAHYcAAB9HAAAgBwAAIIcAAAAHQAADB0AACwdAAA9HQAAXx0AAGwd AABwHQAAcx0AAIsdAAChHQAAwR0AAMUdAAAFHgAAFR8AADAfAAAzHwAABSAAAPnj+dn5z/m5r6L5 z5iOhI6YeoRwZvlQ+bmv+QAAAAAAAAAAAAAAAAAAAAAAAAAAACsACIEVaAIIoAAWaCRU7gAXaBV2 PwBjSAEAZGgAAAAAZGgAAAAAZGjrcpqmEwEIgQRIAQAFaOtymqYWaBV2PwATAQiBBEgBAAVo5HKa phZoRQrKABMBCIEESAEABWjjcpqmFmgVdj8AEwEIgQRIAQAFaOpymqYWaBV2PwATAQiBBEgBAAVo 4XKaphZoFXY/ABMBCIEESAEABWjhcpqmFmhFCsoAGQEIgQRIAQAFaIZzmqYVaAIIoAAWaEJaFwAT AQiBBEgBAAVohnOaphZoQloXACsACIEVaAIIoAAWaCRU7gAXaEJaFwBjSAEAZGgAAAAAZGgAAAAA ZGiGc5qmEwEIgQRIAQAFaOBymqYWaEUKygATAQiBBEgBAAVo3nKaphZoRQrKACsACIEVaAIIoAAW aCRU7gAXaEUKygBjSAEAZGgAAAAAZGgAAAAAZGjecpqmDBVoAgigABZoJFTuABsABgAAAQgAAAII AABLCAAAlAgAAN0IAAAmCQAAbwkAALgJAAABCgAAAgoAAAMKAABMCgAAlAoAAM0KAADOCgAA4goA AOMKAAApCwAAbgsAALQLAAD4CwAA+QsAAD4MAACCDAAAxQwAANAMAADRDAAAGg0AAGINAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAAAAAAAEDwBnZAIIoAAAHQAGAADAfAAAbe0A AP7+AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAQECYg0AAKQNAADjDQAA 5A0AAB4OAABNDgAATg4AAJIOAAC2DgAAtw4AAO0OAADuDgAA/w4AAAAPAAAuDwAALw8AADgPAAA5 DwAAfg8AAMcPAAAOEAAAVBAAAFUQAABWEAAAVxAAAKAQAACiEAAA6xAAAOwQAADtEAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAAAAAAABA8AZ2QCCKAAAB3tEAAANBEAAHwRAADA EQAA8xEAAPQRAAD1EQAABxIAAAgSAABREgAAmhIAAOMSAAAsEwAAdRMAAL4TAAAHFAAAUBQAAJkU AADiFAAAHBUAAGUVAACuFQAA6xUAADQWAAB9FgAAxhYAAA8XAABYFwAAoRcAAKIXAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAAAAAAAEDwBnZAIIoAAAHaIXAACjFwAApBcAAKUX AACmFwAApxcAAKgXAACpFwAAqhcAAKsXAACsFwAArRcAAK4XAACvFwAAsBcAALEXAACyFwAAsxcA ALQXAAC1FwAAthcAALcXAAC4FwAAARgAAAMYAABMGAAATRgAAE4YAABsGAAAbRgAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAAAAAAAAQPAGdkAgigAAAdbRgAAK8YAAD4GAAAQBkA AIcZAADJGQAAGBoAAGEaAACoGgAA1RoAANYaAAD4GgAA+RoAAEAbAACEGwAAyBsAABAcAAAiHAAA IxwAAG0cAAC6HAAAwh0AAAkeAAAdHgAAHh4AAGIeAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA9QAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA8AAAAAAA AAAAAAAAAN0AAAAAAAAAAAAAAADYAAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAAAAAAAAQPAGdkFXY/ABMPAGdkFXY/AG/GBwEBAOtymqZkJgEPhGgBEYSY /l6EaAFghJj+AAQPAGdkQloXAAAEDwBnZEUKygAABA8AZ2QCCKAAABliHgAAqh4AAPEeAAA8HwAA gR8AAMcfAAAHIAAACCAAAE8gAACXIAAA3iAAACAhAAAhIQAASSEAAEohAACRIQAALCMAAHQjAADB IwAABCQAAEQkAABFJAAARiQAAEckAABIJAAAkSQAAJMkAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPUAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AADqAAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAOUAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEDwBnZP0qhQALDwBn ZOYcywBvxgcBAQB6kppGZCYBAAQPAGdkQloXAAAEDwBnZAIIoAAAGgUgAAAGIAAAtiEAAOQhAAAq IgAANSIAAD4iAABUIgAAWSIAAGMiAABkIgAAeyIAAH4iAACfIgAAoSIAALciAAC4IgAAuSIAALoi AAAHIwAACCMAAK0jAACvIwAAuCMAAMAjAAA6JAAAQiQAAJ4lAACoJQAA7ufd08m/ybXJq8m1yaHJ ocmhyZeB52th52HnSwAAAAAAACsACIEVaAIIoAAWaCRU7gAXaMA9rwBjSAEAZGgAAAAAZGgAAAAA ZGiCc5qmEwEIgQRIAQAFaCpzmqYWaP0qhQArAAiBFWgCCKAAFmgkVO4AF2j9KoUAY0gBAGRoAAAA AGRoAAAAAGRoKnOapisACIEVaAIIoAAWaCRU7gAXaP0qhQBjSAEAZGgAAAAAZGgAAAAAZGgpc5qm EwEIgQRIAQAFaClzmqYWaP0qhQATAQiBBEgBAAVo+XKaphZoZ2EkABMBCIEESAEABWgmc5qmFmj9 KoUAEwEIgQRIAQAFaHqSmkYWaOYcywATAQiBBEgBAAVoeZKaRhZo5hzLABMBCIEESAEABWj4cpqm FmhnYSQAEwEIgQRIAQAFaPJymqYWaBV2PwATAQiBBEgBAAVo8XKaphZoFXY/AAwVaAIIoAAWaCRU 7gAAIgNqAAAAABZoFXY/ADBKEAA8CIFPSgAAUUoAAFUIAV5KAAAckyQAANwkAADdJAAA3iQAAPYk AAD3JAAAPSUAAH0lAADBJQAACSYAAFQmAACaJgAA4SYAACknAAAqJwAAcScAALgnAAAAKAAARSgA AGcoAABoKAAAsCgAAPwoAABFKQAAEyoAAF4qAACXKgAAmCoAAJkqAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPUA AAAAAAAAAAAAAAD1AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAEDwBnZEZgKQAABA8AZ2QCCKAAAByoJQAAqyUAABwmAAAmJgAAKSYA AMUnAADPJwAA0icAAFgoAABiKAAAZSgAALsoAAC+KAAATCkAAFMpAABdKQAAYykAAGQpAACfKQAA 3SkAAN4pAADjKQAA5CkAAEgqAABRKgAAVyoAAJUqAACWKgAA/DEAAAYyAAAJMgAA8jIAAPXu2PXu 2PXu2PXuzu7ErqSXjYN5Y3nurqTuUe7Y9e4AAAAiA2oAAAAAFmhzXAwAMEoQADwIgU9KAABRSgAA VQgBXkoAAAArAAiBFWgCCKAAFmgkVO4AF2hGYCkAY0gBAGRoAAAAAGRoAAAAAGRoaXOaphMBCIEE SAEABWhpc5qmFmhGYCkAEwEIgQRIAQAFaGhzmqYWaEZgKQATAQiBBEgBAAVoZ3OaphZoRmApABkB CIEESAEABWhlc5qmFWgCCKAAFmhGYCkAEwEIgQRIAQAFaGVzmqYWaEZgKQArAAiBFWgCCKAAFmgk VO4AF2hGYCkAY0gBAGRoAAAAAGRoAAAAAGRoZXOaphMBCIEESAEABWhcc5qmFmiVP4cAEwEIgQRI AQAFaFtzmqYWaJU/hwArAAiBFWgCCKAAFmgkVO4AF2jAPa8AY0gBAGRoAAAAAGRoAAAAAGRognOa pgwVaAIIoAAWaCRU7gAAEwEIgQRIAQAFaIJzmqYWaMA9rwAAH5kqAACaKgAAmyoAAJwqAACdKgAA nioAAJ8qAACgKgAAoSoAAKIqAACjKgAApCoAAKUqAACmKgAApyoAAKgqAACpKgAAqioAAKsqAACs KgAArSoAAK4qAACvKgAAsCoAALEqAACyKgAAsyoAAPwqAAD+KgAARysAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAAAAAAAAQPAGdkAgigAAAdRysAAEgrAABJKwAAcysAAHQrAAC5 KwAAACwAAEcsAACJLAAA0iwAABotAABcLQAAXS0AAIQtAACFLQAAzi0AABMuAAA+LgAAPy4AAIcu AADHLgAADi8AAFAvAACULwAAzy8AANAvAAAXMAAAXTAAAKQwAADFMAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAAAAAAABA8AZ2QCCKAAAB3FMAAAxjAAAAsxAABPMQAAkzEAANsx AAALMgAADDIAAC8yAAAwMgAAczIAALQyAAAkMwAAaTMAALAzAAD4MwAAQTQAAH80AAAPNQAAEDUA ABE1AAASNQAAEzUAABQ1AAAVNQAAXjUAAGA1AACpNQAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD1AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA 8AAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAADrAAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAAAAAAAAAAAAAEDwBnZIMH bwAABA8AZ2TAPa8AAAQPAGdk5yR1AAAEDwBnZAIIoAAAG/IyAAD0MgAABzMAAAgzAAAQMwAAIzMA AKIzAACsMwAArzMAADk0AAA9NAAAQDQAAEw0AABWNAAAYDQAAJY0AACvNAAAszQAALg0AAC/NAAA xDQAAMc0AADQNAAA6d/Sy9/LtavLlYvLdbV1a2FLdctBYQAAAAAAAAAAAAAAAAAAAAATAQiBBEgB AAVomnOaphZogwdvACsACIEVaAIIoAAWaCRU7gAXaMA9rwBjSAEAZGgAAAAAZGgAAAAAZGh6c5qm EwEIgQRIAQAFaIlzmqYWaEJaFwATAQiBBEgBAAVoiHOaphZoQloXACsACIEVaAIIoAAWaCRU7gAX aEJaFwBjSAEAZGgAAAAAZGgAAAAAZGiIc5qmEwEIgQRIAQAFaHlzmqYWaMA9rwArAAiBFWgCCKAA FmgkVO4AF2jAPa8AY0gBAGRoAAAAAGRoAAAAAGRoeXOaphMBCIEESAEABWiCc5qmFmjAPa8AKwAI gRVoAgigABZoJFTuABdowD2vAGNIAQBkaAAAAABkaAAAAABkaIJzmqYMFWgCCKAAFmgkVO4AABkB CIEESAEABWiJkppGFWgCCKAAFmjnJHUAEwEIgQRIAQAFaImSmkYWaOckdQArAAiBFWgCCKAAFmgk VO4AF2jnJHUAY0gBAGRoAAAAAGRoAAAAAGRoiZKaRgAW0DQAANg0AADfNAAACjUAAA41AAADNgAA BDYAAAU2AABVNgAAXzYAAHI2AABzNgAAqDYAAKs2AACxNgAAsjYAABI3AAAcNwAAHzcAAIo3AADp 4tjO4sSu4piOgeJrYVTiPjTiAAAAAAATAQiBBEgBAAVognOaphZowD2vACsACIEVaAIIoAAWaCRU 7gAXaMA9rwBjSAEAZGgAAAAAZGgAAAAAZGiCc5qmGQEIgQRIAQAFaIuSmkYVaAIIoAAWaOckdQAT AQiBBEgBAAVoi5KaRhZo5yR1ACsACIEVaAIIoAAWaCRU7gAXaOckdQBjSAEAZGgAAAAAZGgAAAAA ZGiLkppGGQEIgQRIAQAFaHtzmqYVaAIIoAAWaMA9rwATAQiBBEgBAAVoe3OaphZowD2vACsACIEV aAIIoAAWaCRU7gAXaMA9rwBjSAEAZGgAAAAAZGgAAAAAZGh7c5qmKwAIgRVoAgigABZoJFTuABdo 5yR1AGNIAQBkaAAAAABkaAAAAABkaIqSmkYTAQiBBEgBAAVoipKaRhZo5yR1ABMBCIEESAEABWib c5qmFmiDB28AEwEIgQRIAQAFaJpzmqYWaIMHbwAMFWgCCKAAFmgkVO4AACsACIEVaAIIoAAWaCRU 7gAXaIMHbwBjSAEAZGgAAAAAZGgAAAAAZGiac5qmABOpNQAAqjUAAKs1AADyNQAAOjYAAJc2AADn NgAAJzcAAGw3AADcNwAA3TcAACE4AABsOAAAtDgAAP84AABCOQAAijkAANE5AAAXOgAAXToAAG46 AABvOgAAlToAAJY6AADaOgAAJTsAAGw7AACPOwAAkDsAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD1AAAAAAAAAAAAAAAA8AAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAAA BA8AZ2TnJHUAAAQPAGdkwD2vAAAEDwBnZAIIoAAAHIo3AADMNwAA0jcAANo3AAAcOAAALDgAAC84 AADmOAAA8DgAAPM4AABpOQAAczkAAHY5AADfOQAA4DkAADo6AABEOgAARzoAAAs7AAAVOwAAGDsA AOY7AADxOwAA+jsAAPs7AAAlPAAA9ev15M7E5K6k5K6k5JLkrqTkfHLkXFJF5AAAAAAAAAAAABkB CIEESAEABWjic5qmFWgCCKAAFmjBG28AEwEIgQRIAQAFaOJzmqYWaMEbbwArAAiBFWgCCKAAFmgk VO4AF2jBG28AY0gBAGRoAAAAAGRoAAAAAGRo4nOaphMBCIEESAEABWiDc5qmFmjAPa8AKwAIgRVo AgigABZoJFTuABdowD2vAGNIAQBkaAAAAABkaAAAAABkaINzmqYiA2oAAAAAFmjnJHUAMEoQADwI gU9KAABRSgAAVQgBXkoAAAATAQiBBEgBAAVognOaphZowD2vACsACIEVaAIIoAAWaCRU7gAXaMA9 rwBjSAEAZGgAAAAAZGgAAAAAZGiCc5qmEwEIgQRIAQAFaIRzmqYWaEJaFwArAAiBFWgCCKAAFmgk VO4AF2hCWhcAY0gBAGRoAAAAAGRoAAAAAGRohHOapgwVaAIIoAAWaCRU7gAAEwEIgQRIAQAFaIuS mkYWaOckdQATAQiBBEgBAAVozXOaphZo9yF5AAAZkDsAANQ7AAAnPAAAKDwAAH08AADDPAAAHT0A AC49AAAvPQAAdT0AAL09AAD4PQAA+T0AAEE+AACKPgAA6j4AAEg/AABJPwAAmz8AAOE/AAAZQAAA G0AAABxAAAAdQAAAHkAAAB9AAABoQAAAakAAALNAAAD6AAAAAAAAAAAAAAAA9QAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA9QAAAAAAAAAAAAAAAPUAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPUAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAEDwBnZMEbbwAABA8AZ2QCCKAAABwlPAAAJjwAAGY8AABvPAAAeTwAAHw8AACDPAAA izwAANk8AADsPAAA/TwAAIM+AACWPgAAqz4AALQ+AADCPgAA0D4AANE+AAAQPwAARj8AAIE/AACK PwAAjj8AAI8/AADVPwAA1j8AABhAAAA3QQAA7ufdx73np+en3eeR54fnfeeRh+dz513nc13nAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAArAAiBFWgCCKAAFmgk VO4AF2jBG28AY0gBAGRoAAAAAGRoAAAAAGRo53OaphMBCIEESAEABWjnc5qmFmjBG28AEwEIgQRI AQAFaKGSmkYWaMRXOgATAQiBBEgBAAVo5nOaphZowRtvACsACIEVaAIIoAAWaCRU7gAXaMEbbwBj SAEAZGgAAAAAZGgAAAAAZGjmc5qmKwAIgRVoAgigABZoJFTuABdowRtvAGNIAQBkaAAAAABkaAAA AABkaORzmqYTAQiBBEgBAAVog3OaphZowD2vACsACIEVaAIIoAAWaCRU7gAXaMA9rwBjSAEAZGgA AAAAZGgAAAAAZGiDc5qmEwEIgQRIAQAFaORzmqYWaMEbbwAMFWgCCKAAFmgkVO4AACIDagAAAAAW aMRXOgAwShAAPAiBT0oAAFFKAABVCAFeSgAAG7NAAAC0QAAAtUAAANhAAADZQAAAH0EAABxCAACq QgAAPEMAANRDAAAzRAAAVUQAAFZEAACrRAAA40QAAOREAAAsRQAAYUUAAGJFAACwRQAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD1AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAADqAAAAAAAAAAAAAAAA5QAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA4AAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA 0QAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAPDwBnZBVt0ABv xgcBAQAijJomZCYBDcYFAAHsBIAABA8AZ2TBG28AAAQPAGdkiySxAAsPAGdkiySxAG/GBwEBADeL miZkJgEABA8AZ2TBNrQAAAQPAGdkAgigAAATN0EAADpBAAA7QQAAPEEAAEJBAABKQQAAYUEAAGVB AAB+QQAAjUEAAABCAAACQgAABEIAAAhCAAAKQgAAEEIAABxDAAAwQwAAcEMAALRDAADCQwAA6d/S y9/LwbetoJOtk4lzXUddyz0AAAAAAAAAAAAAAAAAAAAAAAATAQiBBEgBAAVoNouaJhZoiySxACsA CIEVaAIIoAAWaCRU7gAXaMA9rwBjSAEAZGgAAAAAZGgAAAAAZGiDc5qmKwAIgRVoAgigABZoJFTu ABdoiySxAGNIAQBkaAAAAABkaAAAAABkaDaLmiYrAAiBFWiLJLEAFmgkVO4AF2iLJLEAY0gBAGRo AAAAAGRoAAAAAGRoNouaJhMBCIEESAEABWg1i5omFmiLJLEAGQEIgQRIAQAFaDSLmiYVaIsksQAW aIsksQAZAQiBBEgBAAVoM4uaJhVoiySxABZoiySxABMBCIEESAEABWgzi5omFmiLJLEAEwEIgQRI AQAFaDKLmiYWaIsksQATAQiBBEgBAAVoopKaRhZoxFc6AAwVaAIIoAAWaCRU7gAAGQEIgQRIAQAF aK6KmiYVaIsksQAWaME2tAATAQiBBEgBAAVoroqaJhZowTa0ACsACIEVaAIIoAAWaCRU7gAXaME2 tABjSAEAZGgAAAAAZGgAAAAAZGiuipomABTCQwAA7EMAAPBDAAD+QwAACkQAACVEAAB5RAAAhEQA AI1EAACORAAAlUQAAJ9EAACiRAAAykQAANREAADXRAAAMkUAADxFAAA/RQAAaEUAAGtFAADURQAA +0UAACJGAAA6RgAAYkYAAHpGAADp0+nM6cy2rJ/MiX/MiX/MiX/MdWthV2FNVwAAAAAAAAAAAAAA AAAAAAAAAAAAEwEIgQRIAQAFaCSMmiYWaBVt0AATAQiBBEgBAAVoJYyaJhZoFW3QABMBCIEESAEA BWgjjJomFmgVbdAAEwEIgQRIAQAFaCKMmiYWaBVt0AATAQiBBEgBAAVoIYyaJhZoFW3QABMBCIEE SAEABWiDc5qmFmjAPa8AKwAIgRVoAgigABZoJFTuABdowD2vAGNIAQBkaAAAAABkaAAAAABkaINz mqYZAQiBBEgBAAVo6XOaphVoAgigABZowRtvABMBCIEESAEABWjpc5qmFmjBG28AKwAIgRVoAgig ABZoJFTuABdowRtvAGNIAQBkaAAAAABkaAAAAABkaOlzmqYMFWgCCKAAFmgkVO4AACsACIEVaAII oAAWaCRU7gAXaHV9AABjSAEAZGgAAAAAZGgAAAAAZGjFipomKwAIgRVoAgigABZoJFTuABdoiySx AGNIAQBkaAAAAABkaAAAAABkaDeLmiYAGrBFAAAjRgAAZEYAAKMAAAAAAAAAAAAAAABHAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAWw8A QyQBRcaAAAABACOMmiYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAABnZBVt0ABvxgcBAQAjjJomZCYBDcYIAALQAuwEwIAPhOwEEYQU +16E7ARghBT7AFsPAEMkAUXGgAAAAQAijJomAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAZ2QVbdAAb8YHAQEAI4yaJmQmAQ3GCAAC 0ALsBMCAD4TsBBGEFPtehOwEYIQU+wACZEYAAGVGAABJRwAAowAAAAAAAAAAAAAAAEcAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABbDwBD JAFFxoAAAAEAJYyaJgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAGdkBSbKAG/GBwEBACmMmiZkJgENxggAAtAC7ATAgA+E7AQRhBT7 XoTsBGCEFPsAWw8AQyQBRcaAAAABACWMmiYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABnZBVt0ABvxgcBAQAjjJomZCYBDcYIAALQ AuwEwIAPhOwEEYQU+16E7ARghBT7AAJ6RgAAlUYAAEFHAABCRwAAR0cAAEhHAABJRwAAq0cAAKxH AABZSQAAKUsAACpLAAA9SwAAiUsAAJBLAACVSwAAtUsAADNMAAA6TAAAQUwAAIpMAACTTAAAokwA AKdMAAC1TAAAukwAAL5MAADJTAAA0kwAAPXr4evh18GrwaSakIZ8hnxyaHJeVF5KXkpeSlQAAAAA EwEIgQRIAQAFaKWrmqYWaPRw8AATAQiBBEgBAAVopquaphZo9HDwABMBCIEESAEABWikq5qmFmj0 cPAAEwEIgQRIAQAFaKOSmkYWaMRXOgATAQiBBEgBAAVoL4yaJhZoBSbKABMBCIEESAEABWgujJom FmgFJsoAEwEIgQRIAQAFaC2MmiYWaAUmygATAQiBBEgBAAVoLIyaJhZoBSbKABMBCIEESAEABWgs jJomFmgkVO4ADBVoAgigABZoJFTuAAArAAiBFWgCCKAAFmgkVO4AF2goDXgAY0gBAGRoAAAAAGRo AAAAAGRoCIyaJisACIEVaAIIoAAWaCRU7gAXaAUmygBjSAEAZGgAAAAAZGgAAAAAZGgrjJomEwEI gQRIAQAFaCqMmiYWaBVt0AATAQiBBEgBAAVoKoyaJhZoBSbKABMBCIEESAEABWgpjJomFmgFJsoA EwEIgQRIAQAFaCWMmiYWaAUmygAAHElHAACLRwAA0UcAABlIAAA3SAAAOEgAAIBIAACvSAAAsEgA APVIAAA+SQAAWUkAAFpJAACcSQAA5EkAABBKAAARSgAATkoAAJdKAADPSgAA0EoAALcAAAAAAAAA AAAAAACyAAAAAAAAAAAAAAAArQAAAAAAAAAAAAAAAK0AAAAAAAAAAAAAAACtAAAAAAAAAAAAAAAA rQAAAAAAAAAAAAAAAK0AAAAAAAAAAAAAAACtAAAAAAAAAAAAAAAArQAAAAAAAAAAAAAAAK0AAAAA AAAAAAAAAACtAAAAAAAAAAAAAAAArQAAAAAAAAAAAAAAAK0AAAAAAAAAAAAAAACtAAAAAAAAAAAA AAAArQAAAAAAAAAAAAAAAK0AAAAAAAAAAAAAAACtAAAAAAAAAAAAAAAArQAAAAAAAAAAAAAAAK0A AAAAAAAAAAAAAACtAAAAAAAAAAAAAAAAAAAABA8AZ2QCCKAAAAQPAGdkKA14AABHDwBDJAFFxoAA AAEAIoyaJgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAGdkAgigAAAU0EoAABBLAAApSwAAKksAAA9NAAARTQAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAACyAAAAAAAAAAAAAAAAmQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAWw8AQyQBRcaAAAABADCMmiYAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABnZAUm ygBvxgcBAQAujJomZCYBDcYIAALQAuwEQEAPhOwEEYQU+16E7ARghBT7ABgPAGdk9HDwAG/GBwEB AKermqZkJgENxggAAtAC7ARAQA+E7AQRhBT7XoTsBGCEFPsARw8AQyQBRcaAAAABACyMmiYAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AABnZAIIoAAABA8AZ2QCCKAAAAXSTAAA00wAANRMAAD6TAAADE0AAA1NAAAPTQAAak0AAH5NAAB/ TQAAgE0AAIFNAACHTQAAHk8AAABRAAABUQAAAlEAAANRAAAJUQAAClEAAAtRAAAjUQAAJFEAACtR AABpUQAAalEAAHFRAACvUQAAtlEAAMRRAADTUQAA1VEAAPXr9ev14dfNw7myq5Wri3Wri19Vq1Vf q1Vfq1+rX6sAAAAAAAAAAAAAABMBCIEESAEABWg2jJomFmgjNwEAKwAIgRVoAgigABZoJFTuABdo IzcBAGNIAQBkaAAAAABkaAAAAABkaDaMmiYrAAiBFWgCCKAAFmgkVO4AF2gjNwEAY0gBAGRoAAAA AGRoAAAAAGRoNYyaJhMBCIEESAEABWg1jJomFmgjNwEAKwAIgRVoAgigABZoJFTuABdoIzcBAGNI AQBkaAAAAABkaAAAAABkaDKMmiYMFWgCCKAAFmgkVO4AAAwVaAIIoAAWaCM3AQAAEwEIgQRIAQAF aDGMmiYWaAUmygATAQiBBEgBAAVoMYyaJhZoIzcBABMBCIEESAEABWgyjJomFmgjNwEAEwEIgQRI AQAFaDCMmiYWaAUmygATAQiBBEgBAAVoL4yaJhZoBSbKABMBCIEESAEABWinq5qmFmj0cPAAEwEI gQRIAQAFaKWrmqYWaPRw8AAAHxFNAACATQAAgU0AAMlNAAAPTgAAVU4AAHFOAAByTgAAowAAAAAA AAAAAAAAAEcAAAAAAAAAAAAAAABCAAAAAAAAAAAAAAAAQgAAAAAAAAAAAAAAAEIAAAAAAAAAAAAA AABCAAAAAAAAAAAAAAAAQgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEDwBnZAIIoAAAWw8AQyQBRcaA AAABADGMmiYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAABnZAUmygBvxgcBAQAujJomZCYBDcYIAALQAuwEQEAPhOwEEYQU+16E7ARg hBT7AFsPAEMkAUXGgAAAAQAwjJomAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAZ2QjNwEAb8YHAQEAMoyaJmQmAQ3GCAAC0ALsBEBA D4TsBBGEFPtehOwEYIQU+wAHck4AALpOAAD/TgAAH08AACBPAAAhTwAAIk8AACNPAABsTwAAbk8A ALdPAAC4TwAAuU8AAABQAAAdUAAAHlAAAGVQAACnUAAA0lAAANRQAAAEUQAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAABA8AZ2QCCKAAABQEUQAABVEAACVRAABrUQAAsFEAANVRAADWUQAAtwAAAAAAAAAAAAAA AFsAAAAAAAAAAAAAAABBAAAAAAAAAAAAAAAAQQAAAAAAAAAAAAAAAEEAAAAAAAAAAAAAAAC3AAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGg8AQyQBZ2QjNwEAb8YHAQEANoyaJmQm AQ3GCAAC0ALsBEBAD4TsBBGEFPtehOwEYIQU+wBbDwBDJAFFxoAAAAEANYyaJgAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGdkIzcB AG/GBwEBADaMmiZkJgENxggAAtAC7ARAQA+E7AQRhBT7XoTsBGCEFPsARw8AQyQBRcaAAAABADWM miYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAABnZAIIoAAABtVRAADWUQAA11EAAN1RAADeUQAA31EAAOBRAADhUQAA41EAAPNRAAD0 UQAA9VEAAB5SAAAiUgAAKlIAACtSAAAwUgAAZ1IAAKVSAADdUgAA51IAAOhSAADqUgAA9e7n3cfn vaeahL3np3pwvXBmUDpQ5wAAKwAIgRVoAgigABZoJFTuABdowD2vAGNIAQBkaAAAAABkaAAAAABk aINzmqYrAAiBFWgCCKAAFmgkVO4AF2gjNwEAY0gBAGRoAAAAAGRoAAAAAGRoNIyaJhMBCIEESAEA BWg0jJomFmgjNwEAEwEIgQRIAQAFaDOMmiYWaCM3AQATAQiBBEgBAAVopJKaRhZoNhlHACsACIEV aAIIoAAWaCRU7gAXaCM3AQBjSAEAZGgAAAAAZGgAAAAAZGg2jJomGQEIgQRIAQAFaDaMmiYVaAII oAAWaCM3AQArAAiBFWgCCKAAFmgkVO4AF2gjNwEAY0gBAGRoAAAAAGRoAAAAAGRoN4yaJhMBCIEE SAEABWg3jJomFmgjNwEAKwAIgRVoAgigABZoJFTuABdoniG1AGNIAQBkaAAAAABkaAAAAABkaFmM miYTAQiBBEgBAAVoWYyaJhZoniG1AAwVaAIIoAAWaCRU7gAADBVoAgigABZoIzcBAAATAQiBBEgB AAVoNYyaJhZoJFTuAAAW1lEAANdRAACyUgAA6VIAAOpSAAAyUwAAYFMAAGFTAACpUwAA8FMAADVU AAB7VAAAsFQAALFUAADvVAAA8FQAAB9VAAAgVQAAaVUAAK1VAAD2VQAAPlYAAIZWAADKVgAA+gAA AAAAAAAAAAAAAOMAAAAAAAAAAAAAAADKAAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAAAAAAAAAAAAAAAGA8AZ2QjNwEAb8YHAQEAN4yaJmQmAQ3GCAAC0ALsBACAD4Ts BBGEFPtehOwEYIQU+xcPAGdkNhlHAG/GBwEBAKSSmkZkJgENxgUAAewEgA+E7AQRhBT7XoTsBGCE FPsABA8AZ2QCCKAAABfqUgAAVFMAAF5TAABgUwAArlQAAK9UAADtVAAA7lQAAFdVAABhVQAAZFUA ALpVAADEVQAAx1UAANZVAADXVQAAQVYAAEtWAABOVgAAqFYAALJWAAC1VgAA8lYAAPxWAAD/VgAA AVcAABJXAAAjVwAASlcAAFhXAACWVwAAoFcAAKNXAADYVwAA6dPpzLrMqMzTnszTnsyMzNOezNOe zNOezILMbGLM057MAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEwEIgQRIAQAFaFCMmiYWaH4q BwArAAiBFWgCCKAAFmgkVO4AF2h+KgcAY0gBAGRoAAAAAGRoAAAAAGRoUIyaJhMBCIEESAEABWhP jJomFmh+KgcAIgNqAAAAABZofioHADBKEAA8CIFPSgAAUUoAAFUIAV5KAAAAEwEIgQRIAQAFaINz mqYWaMA9rwAiA2oAAAAAFmgjNwEAMEoQADwIgU9KAABRSgAAVQgBXkoAAAAiA2oAAAAAFmhzXAwA MEoQADwIgU9KAABRSgAAVQgBXkoAAAAMFWgCCKAAFmgkVO4AACsACIEVaAIIoAAWaCRU7gAXaMA9 rwBjSAEAZGgAAAAAZGgAAAAAZGiDc5qmKwAIgRVoAgigABZoJFTuABdoIzcBAGNIAQBkaAAAAABk aAAAAABkaDiMmiYAIcpWAADLVgAAJVcAAHZXAAC8VwAACVgAAEdYAABIWAAAbFgAAG1YAADVWAAA LlkAAHdZAACJWQAAilkAAItZAACMWQAAjVkAANZZAADYWQAAIVoAACJaAAAjWgAAaVoAAK5aAAD2 WgAAK1sAACxbAAD6AAAAAAAAAAAAAAAA7wAAAAAAAAAAAAAAAOoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA6gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAADqAAAAAAAAAAAAAAAA6gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAAAAAAAAAAEDwBnZH4qBwALDwBnZH4qBwBvxgcBAQBRjJomZCYB AAQPAGdkAgigAAAb2FcAAOFXAADpVwAAd1gAAH9YAACBWAAAhlgAAIdYAACMWAAAjVgAAKFYAACr WAAArlgAALBYAADBWAAA5VgAAPBYAADyWAAA+VgAAPpYAAAaWQAAIFkAAE1bAABXWwAAWlsAAMBb AADVWwAA6d/YwrWroZeN2Hdt2GPYwpdjtU1j2Hdt2EMTAQiBBEgBAAVoU4yaJhZoykpfACsACIEV aAIIoAAWaCRU7gAXaH4qBwBjSAEAZGgAAAAAZGgAAAAAZGhSjJomEwEIgQRIAQAFaFKMmiYWaH4q BwATAQiBBEgBAAVog3OaphZowD2vACsACIEVaAIIoAAWaCRU7gAXaMA9rwBjSAEAZGgAAAAAZGgA AAAAZGiDc5qmEwEIgQRIAQAFaFWMmiYWaMpKXwATAQiBBEgBAAVoS4yaJhZofioHABMBCIEESAEA BWhXjJomFmjKSl8AEwEIgQRIAQAFaEuMmiYWaMpKXwAZAQiBBEgBAAVoS4yaJhVoAgigABZofioH ACsACIEVaAIIoAAWaCRU7gAXaH4qBwBjSAEAZGgAAAAAZGgAAAAAZGhLjJomDBVoAgigABZoJFTu AAATAQiBBEgBAAVoUYyaJhZofioHACsACIEVaAIIoAAWaCRU7gAXaH4qBwBjSAEAZGgAAAAAZGgA AAAAZGhRjJomABosWwAAd1sAALpbAAAgXAAAQ1wAAERcAACJXAAAz1wAABRdAABgXQAAsl0AAPRd AAA2XgAAfl4AAMZeAAAJXwAAGF8AABlfAACBXwAA2F8AAP9fAAAAYAAARmAAAH9gAACAYAAAzGAA ABBhAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPUAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAOIAAAAA AAAAAAAAAADiAAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPUA AAAAAAAAAAAAAAD1AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA9QAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA AAAAAAAAABMPAGdkykpfAG/GBwEBAFSMmiZkJgEPhNACEYQw/V6E0AJghDD9AAQPAGdkykpfAAAE DwBnZAIIoAAAGtVbAADmWwAAAFwAAA5cAAAPXQAAH10AACJdAABWXQAAcl0AAHtdAADzXgAA9F4A ACVfAAAtXwAAL18AADRfAAA1XwAAO18AAEdfAABRXwAA+ePZ+cO5+aOZ+Yf5cWRaUFr5OgAAAAAA AAAAAAAAAAAAAAAAKwAIgRVoAgigABZoJFTuABdowD2vAGNIAQBkaAAAAABkaAAAAABkaINzmqYT AQiBBEgBAAVoVoyaJhZoykpfABMBCIEESAEABWhVjJomFmjKSl8AGQEIgQRIAQAFaFWMmiYVaAII oAAWaMpKXwArAAiBFWgCCKAAFmgkVO4AF2jKSl8AY0gBAGRoAAAAAGRoAAAAAGRoVYyaJiIDagAA AAAWaMpKXwAwShAAPAiBT0oAAFFKAABVCAFeSgAAABMBCIEESAEABWhUjJomFmjKSl8AKwAIgRVo AgigABZoJFTuABdoykpfAGNIAQBkaAAAAABkaAAAAABkaFSMmiYTAQiBBEgBAAVomHOaphZogwdv ACsACIEVaAIIoAAWaCRU7gAXaIMHbwBjSAEAZGgAAAAAZGgAAAAAZGiYc5qmEwEIgQRIAQAFaFOM miYWaMpKXwArAAiBFWgCCKAAFmgkVO4AF2jKSl8AY0gBAGRoAAAAAGRoAAAAAGRoU4yaJgwVaAII oAAWaCRU7gATUV8AAFRfAABWXwAAZ18AAItfAACWXwAAmF8AAJ9fAACgXwAAwF8AAMZfAABgYAAA aGAAAGpgAAB2YAAAnGAAAKZgAACpYAAAG2EAACVhAAAoYQAA/WEAAAdiAAAKYgAAQ2IAAE1iAABQ YgAAFWMAABZjAAC/fAAAwHwAAMF8AABffQAAYH0AAAt/AAAMfwAA9e7k7s7B5MHO5O6rnpTufvXu fvXufvXufvXubO5oXlpeWl4ABhZo9HDwAAATA2oAAAAAFmj0cPAAMEoQAFUIAQYWaAIIoAAAIgNq AAAAABZohTfEADBKEAA8CIFPSgAAUUoAAFUIAV5KAAAAKwAIgRVoAgigABZoJFTuABdowD2vAGNI AQBkaAAAAABkaAAAAABkaINzmqYTAQiBBEgBAAVoV4yaJhZoykpfABkBCIEESAEABWhXjJomFWgC CKAAFmjKSl8AKwAIgRVoAgigABZoJFTuABdoykpfAGNIAQBkaAAAAABkaAAAAABkaFeMmiYZAQiB BEgBAAVoVoyaJhVoAgigABZoykpfACsACIEVaAIIoAAWaCRU7gAXaMpKXwBjSAEAZGgAAAAAZGgA AAAAZGhWjJomEwEIgQRIAQAFaFaMmiYWaMpKXwAMFWgCCKAAFmgkVO4AABMBCIEESAEABWiDc5qm FmjAPa8AACMQYQAAW2EAAJ9hAADoYQAAMWIAAHtiAADEYgAACGMAABdjAAAYYwAAYGMAAKZjAADX YwAA2GMAANljAADaYwAA22MAANxjAADdYwAA3mMAAN9jAAAoZAAAKmQAAHNkAAB0ZAAAdWQAALZk AADEZAAAxWQAAAxlAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAAAAAAAEDwBn ZAIIoAAAHQxlAABUZQAAVWUAAIFlAACCZQAAyGUAANZlAADXZQAAHGYAACxmAAAtZgAAbmYAAG9m AAC0ZgAA/GYAAERnAACLZwAAzmcAABdoAABgaAAAj2gAAJBoAADLaAAAzGgAABNpAABRaQAAimkA AItpAACaaQAAm2kAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAAAAAAAAQPAGdk AgigAAAdm2kAAN9pAAAYagAAX2oAAHVqAAB2agAAvmoAAPlqAAAoawAAKWsAAG1rAACtawAA7WsA AO5rAAA3bAAAdWwAAHZsAAB3bAAAeGwAAMFsAADDbAAADG0AAA1tAAAObQAAV20AAJFtAACSbQAA 1W0AAAFuAAACbgAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAAAAAAABA8AZ2QC CKAAAB0CbgAAQW4AAIFuAACWbgAAl24AANxuAAAkbwAAbG8AALJvAADybwAA828AADlwAAB5cAAA enAAAHtwAAB8cAAAfXAAAH5wAAB/cAAAgHAAAIFwAACCcAAAg3AAAIRwAACFcAAAhnAAAIdwAACI cAAAiXAAAIpwAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAAAAAAAEDwBnZAII oAAAHYpwAACLcAAAjHAAAI1wAACOcAAAj3AAAJBwAACRcAAAknAAAJNwAACUcAAAlXAAAJZwAACX cAAAmHAAAJlwAACacAAA43AAAOVwAAAucQAAL3EAADBxAABOcQAAT3EAAJhxAAC8cQAAvXEAAL5x AAC/cQAAwHEAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAAAAAAAAQPAGdkAgig AAAdwHEAAMFxAADCcQAAw3EAAMRxAADFcQAAxnEAAMdxAADIcQAAyXEAAMpxAADLcQAAzHEAAM1x AADOcQAAz3EAANBxAADRcQAA0nEAANNxAADUcQAA1XEAANZxAADXcQAA2HEAANlxAADacQAA23EA ANxxAADdcQAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAAAAAAABA8AZ2QCCKAA AB3dcQAA3nEAAN9xAADgcQAA4XEAAOJxAADjcQAA5HEAAOVxAADmcQAA53EAAOhxAADpcQAA6nEA AOtxAAA0cgAANnIAAH9yAACAcgAAgXIAAJRyAACVcgAAp3IAALxyAAC9cgAA13IAAP1yAAD+cgAA /3IAABFzAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAAAAAAAEDwBnZAIIoAAA HRFzAAAccwAAHXMAAEJzAABDcwAARHMAAFZzAABhcwAAYnMAAHxzAACdcwAAnnMAAJ9zAACgcwAA oXMAAKJzAACjcwAApHMAAKVzAACmcwAAp3MAAKhzAACpcwAAqnMAAKtzAACscwAArXMAAK5zAACv cwAAsHMAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAAAAAAAAQPAGdkAgigAAAd sHMAALFzAACycwAAs3MAALRzAAC1cwAAtnMAALdzAAC4cwAAuXMAALpzAAC7cwAAvHMAAAV0AAAH dAAAUHQAAFF0AABSdAAAcnQAAHN0AAC4dAAAAXUAAEh1AACOdQAA1HUAAB12AABhdgAAgHYAAIF2 AADDdgAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAAAAAAABA8AZ2QCCKAAAB3D dgAAB3cAAFB3AACMdwAA1XcAAPF3AADydwAAOXgAAH14AADDeAAABXkAABt5AAAceQAAHXkAADR5 AAA1eQAAfnkAAMd5AAANegAAVHoAAJV6AADXegAAHXsAAB57AAAfewAAM3sAADR7AAB8ewAAwXsA AAZ8AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAAAAAAAEDwBnZAIIoAAAHQZ8 AAAHfAAACHwAABd8AAAYfAAAXHwAAHF8AAByfAAAc3wAAHR8AAB1fAAAvnwAAMB8AABffQAAC38A AMl/AADXgAAA/YAAAF+BAADMgQAA5IEAAGztAABt7QAAbu0AAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAA AAAAAPMAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA7gAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD4 AAAAAAAAAAAAAAAA6QAAAAAAAAAAAAAAAOcAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAABAAAABBEAZ2SFN8QAAAQRAGdkfioHAAAEEQBnZMRXOgAAAREAAAQPAGdkAgigAAAXDH8A AMl/AADKfwAA14AAANiAAAD9gAAA/oAAAF+BAABggQAAzIEAAM2BAADkgQAA5YEAAADsAABs7QAA be0AAG7tAAD88vzy/PL88vzy/PLw/OzoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAGFmgCCKAAAAYWaDNsGAAAA1UIARMDagAAAAAWaPRw8AAwShAAVQgBBhZo9HDwABAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFRoZSB1 c2Ugb2YgYSCRY29tbW9uIHBvb2ySIG9mIG1lbWJlcnMgaXMgb3V0c2lkZSB0aGUgc2NvcGUgb2Yg TENBUy4gVGhlIGNvbXBsaWNhdGlvbiBoZXJlIChmb3IgZGV0ZXJtaW5pc3RpYyBwdXJwb3Nlcykg aXMgdGhhdCB0aGVzZSBjb21wb25lbnRzIGFyZSBub3QgbWVtYmVycyBvZiBhbnkgVkNHIGFuZCBi ZWZvcmUgdGhleSBjYW4gYmUgdXNlZCBieSBMQ0FTIHRoZSBtYW5hZ2VtZW50IHN5c3RlbSB3b3Vs ZCBuZWVkIHRvIGFsbG9jYXRlIHRoZW0gdG8gYSBwYXJ0aWN1bGFyIFZDRzsgdGhpcyB3aWxsIGFk ZCBvcGVyYXRpb24gdGltZSB0byB0aGUgb3ZlcmFsbCB0aW1lIHRvIHB1dCBpdCh0aGVtKSBpbnRv IGFjdGl2ZSBzZXJ2aWNlLg0NDQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJgAxkGgB OnACCKAAH7DQLyCw4D0hsCcFIrAnBSOQoAUkkKAFJbAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFAAUABIAAQCcAA8AAwAA AAMAAAAAAEQAAEDx/wIARAAMAAAAAAAAAAAABgBOAG8AcgBtAGEAbAAAAAIAAAAcAENKGABfSA0E YUoYAG1ICQRuSAQIc0gJBHRIBAgAAAAAAAAAAAAAAAAAAAAAAABEAEFA8v+hAEQADAEAAAAAAAAA ABYARABlAGYAYQB1AGwAdAAgAFAAYQByAGEAZwByAGEAcABoACAARgBvAG4AdAAAAAAAUgBpAPP/ swBSAAwBAAAAAAAAAAAMAFQAYQBiAGwAZQAgAE4AbwByAG0AYQBsAAAAHAAX9gMAADTWBgABCgNs ADTWBgABBQMAAGH2AwAAAgALAAAAKABrAPT/wQAoAAABAAAAAAAAAAAHAE4AbwAgAEwAaQBzAHQA AAACAAAAAAAAAEQAWkABAPIARAAMAAAAAgigAAAACgBQAGwAYQBpAG4AIABUAGUAeAB0AAAAAgAP ABQAQ0oUAE9KBABRSgQAXkoEAGFKFABCACdAogABAUIADAEAABV2PwAAABEAQwBvAG0AbQBlAG4A dAAgAFIAZQBmAGUAcgBlAG4AYwBlAAAACABDShAAYUoQADwAHkABABIBPAAMAQAAFXY/AAAADABD AG8AbQBtAGUAbgB0ACAAVABlAHgAdAAAAAIAEQAIAENKFABhShQAQABqABEBEgFAAAwBAAAVdj8A AAAPAEMAbwBtAG0AZQBuAHQAIABTAHUAYgBqAGUAYwB0AAAAAgASAAYANQiBXAiBSACZQAEAMgFI AAwBAAAVdj8AAAAMAEIAYQBsAGwAbwBvAG4AIABUAGUAeAB0AAAAAgATABQAQ0oQAE9KBQBRSgUA XkoFAGFKEAANAFQAcgBlAHYAbwByACAAVwBpAGwAcwBvAG4ABRgAAJUiAADfMQAAJTQAAD5LAAB9 SwAAZkwAAINVAAClWQAA43kAAAIAVABXAAAAAAAAAAAAAAAAAAAAAAAAAAAA/////wIAVABXAAAA AAAAAAAAAAAAAAAAAAAAAAAA/////wIAVABXAAAAAAAAAAAAAAAAAAAAAAAAAAAA/////wIAVABX AAAAAAAAAAAAAAAAAAAAAAAAAAAA/////wIAVABXAAAAAAAAAAAAAAAAAAAAAAAAAAAA/////wIA VABXAAAAAAAAAAAAAAAAAAAAAAAAAAAA/////wIAVABXAAAAAAAAAAAAAAAAAAAAAAAAAAAA//// /wIAVABXAAAAAAAAAAAAAAAAAAAAAAAAAAAAAlz+BgIAVABXAAAAAAAAAAAAAAAAAAAAAAAAAAAA //////pymqYAAAAAAAAAAAAAAAAAALKSmkYAAAAAAAAAAAAAAAAAAKGSmkYAAAAAAAAAAAAAAAAA AKCSmkYAAAAAAAAAAAAAAAAAALKSmkYAAAAAAAAAAAAAAAAAAEmMmiYAAAAAAAAAAAAAAAAAAE6M miYAAAAAAAAAAAAAAAAAAFWMmiYAAAAAAAAAAAAAAAAAAKKrmqYAAAAAAAAAAAAAAAAAAAAAAACf AAAASwIAAAkDAAAXBAAAPQQAAJ8EAAAMBQAAJAUAAJEGAACUBgAAAAAAAON5AAAMAADuAAAAAP// //8AAAAAAQAAAAIAAABLAAAAlAAAAN0AAAAmAQAAbwEAALgBAAABAgAAAgIAAAMCAABMAgAAlAIA AM0CAADOAgAA4gIAAOMCAAApAwAAbgMAALQDAAD4AwAA+QMAAD4EAACCBAAAxQQAANAEAADRBAAA GgUAAGIFAACkBQAA4wUAAOQFAAAeBgAATQYAAE4GAACSBgAAtgYAALcGAADtBgAA7gYAAP8GAAAA BwAALgcAAC8HAAA4BwAAOQcAAH4HAADHBwAADggAAFQIAABVCAAAVggAAFcIAACgCAAAoggAAOsI AADsCAAA7QgAADQJAAB8CQAAwAkAAPMJAAD0CQAA9QkAAAcKAAAICgAAUQoAAJoKAADjCgAALAsA AHULAAC+CwAABwwAAFAMAACZDAAA4gwAABwNAABlDQAArg0AAOsNAAA0DgAAfQ4AAMYOAAAPDwAA WA8AAKEPAACiDwAAow8AAKQPAAClDwAApg8AAKcPAACoDwAAqQ8AAKoPAACrDwAArA8AAK0PAACu DwAArw8AALAPAACxDwAAsg8AALMPAAC0DwAAtQ8AALYPAAC3DwAAuA8AAAEQAAADEAAATBAAAE0Q AABOEAAAbBAAAG0QAACvEAAA+BAAAEARAACHEQAAyREAABgSAABhEgAAqBIAANUSAADWEgAA+BIA APkSAABAEwAAhBMAAMgTAAAQFAAAIhQAACMUAABtFAAAuhQAAMIVAAAJFgAAHRYAAB4WAABiFgAA qhYAAPEWAAA8FwAAgRcAAMcXAAAHGAAACBgAAE8YAACXGAAA3hgAACAZAAAhGQAASRkAAEoZAACR GQAALBsAAHQbAADBGwAABBwAAEQcAABFHAAARhwAAEccAABIHAAAkRwAAJMcAADcHAAA3RwAAN4c AAD2HAAA9xwAAD0dAAB9HQAAwR0AAAkeAABUHgAAmh4AAOEeAAApHwAAKh8AAHEfAAC4HwAAACAA AEUgAABnIAAAaCAAALAgAAD8IAAARSEAABMiAABeIgAAlyIAAJgiAACZIgAAmiIAAJsiAACcIgAA nSIAAJ4iAACfIgAAoCIAAKEiAACiIgAAoyIAAKQiAAClIgAApiIAAKciAACoIgAAqSIAAKoiAACr IgAArCIAAK0iAACuIgAAryIAALAiAACxIgAAsiIAALMiAAD8IgAA/iIAAEcjAABIIwAASSMAAHMj AAB0IwAAuSMAAAAkAABHJAAAiSQAANIkAAAaJQAAXCUAAF0lAACEJQAAhSUAAM4lAAATJgAAPiYA AD8mAACHJgAAxyYAAA4nAABQJwAAlCcAAM8nAADQJwAAFygAAF0oAACkKAAAxSgAAMYoAAALKQAA TykAAJMpAADbKQAACyoAAAwqAAAvKgAAMCoAAHMqAAC0KgAAJCsAAGkrAACwKwAA+CsAAEEsAAB/ LAAADy0AABAtAAARLQAAEi0AABMtAAAULQAAFS0AAF4tAABgLQAAqS0AAKotAACrLQAA8i0AADou AACXLgAA5y4AACcvAABsLwAA3C8AAN0vAAAhMAAAbDAAALQwAAD/MAAAQjEAAIoxAADRMQAAFzIA AF0yAABuMgAAbzIAAJUyAACWMgAA2jIAACUzAABsMwAAjzMAAJAzAADUMwAAJzQAACg0AAB9NAAA wzQAAB01AAAuNQAALzUAAHU1AAC9NQAA+DUAAPk1AABBNgAAijYAAOo2AABINwAASTcAAJs3AADh NwAAGTgAABs4AAAcOAAAHTgAAB44AAAfOAAAaDgAAGo4AACzOAAAtDgAALU4AADYOAAA2TgAAB85 AACeOQAA5TkAAC46AAB6OgAAwzoAAOU6AADmOgAAOzsAAHM7AAB0OwAAvDsAAPE7AADyOwAAQDwA ALM8AAD0PAAA9TwAANk9AAAbPgAAYT4AAKk+AADHPgAAyD4AABA/AAA/PwAAQD8AAIU/AADOPwAA 6T8AAOo/AAAsQAAAdEAAAKBAAAChQAAA3kAAACdBAABfQQAAYEEAAKBBAAC5QQAAukEAAJ9DAACh QwAAEEQAABFEAABZRAAAn0QAAOVEAAABRQAAAkUAAEpFAACPRQAAr0UAALBFAACxRQAAskUAALNF AAD8RQAA/kUAAEdGAABIRgAASUYAAJBGAACtRgAArkYAAPVGAAA3RwAAYkcAAGRHAACURwAAlUcA ALVHAAD7RwAAQEgAAGVIAABmSAAAZ0gAAEJJAAB5SQAAekkAAMJJAADwSQAA8UkAADlKAACASgAA xUoAAAtLAABASwAAQUsAAH9LAACASwAAr0sAALBLAAD5SwAAPUwAAIZMAADOTAAAFk0AAFpNAABb TQAAtU0AAAZOAABMTgAAmU4AANdOAADYTgAA/E4AAP1OAABlTwAAvk8AAAdQAAAZUAAAGlAAABtQ AAAcUAAAHVAAAGZQAABoUAAAsVAAALJQAACzUAAA+VAAAD5RAACGUQAAu1EAALxRAAAHUgAASlIA ALBSAADTUgAA1FIAABlTAABfUwAApFMAAPBTAABCVAAAhFQAAMZUAAAOVQAAVlUAAJlVAACoVQAA qVUAABFWAABoVgAAj1YAAJBWAADWVgAAD1cAABBXAABcVwAAoFcAAOtXAAAvWAAAeFgAAMFYAAAL WQAAVFkAAJhZAACnWQAAqFkAAPBZAAA2WgAAZ1oAAGhaAABpWgAAaloAAGtaAABsWgAAbVoAAG5a AABvWgAAuFoAALpaAAADWwAABFsAAAVbAABGWwAAVFsAAFVbAACcWwAA5FsAAOVbAAARXAAAElwA AFhcAABmXAAAZ1wAAKxcAAC8XAAAvVwAAP5cAAD/XAAARF0AAIxdAADUXQAAG14AAF5eAACnXgAA 8F4AAB9fAAAgXwAAW18AAFxfAACjXwAA4V8AABpgAAAbYAAAKmAAACtgAABvYAAAqGAAAO9gAAAF YQAABmEAAE5hAACJYQAAuGEAALlhAAD9YQAAPWIAAH1iAAB+YgAAx2IAAAVjAAAGYwAAB2MAAAhj AABRYwAAU2MAAJxjAACdYwAAnmMAAOdjAAAhZAAAImQAAGVkAACRZAAAkmQAANFkAAARZQAAJmUA ACdlAABsZQAAtGUAAPxlAABCZgAAgmYAAINmAADJZgAACWcAAApnAAALZwAADGcAAA1nAAAOZwAA D2cAABBnAAARZwAAEmcAABNnAAAUZwAAFWcAABZnAAAXZwAAGGcAABlnAAAaZwAAG2cAABxnAAAd ZwAAHmcAAB9nAAAgZwAAIWcAACJnAAAjZwAAJGcAACVnAAAmZwAAJ2cAAChnAAApZwAAKmcAAHNn AAB1ZwAAvmcAAL9nAADAZwAA3mcAAN9nAAAoaAAATGgAAE1oAABOaAAAT2gAAFBoAABRaAAAUmgA AFNoAABUaAAAVWgAAFZoAABXaAAAWGgAAFloAABaaAAAW2gAAFxoAABdaAAAXmgAAF9oAABgaAAA YWgAAGJoAABjaAAAZGgAAGVoAABmaAAAZ2gAAGhoAABpaAAAamgAAGtoAABsaAAAbWgAAG5oAABv aAAAcGgAAHFoAAByaAAAc2gAAHRoAAB1aAAAdmgAAHdoAAB4aAAAeWgAAHpoAAB7aAAAxGgAAMZo AAAPaQAAEGkAABFpAAAkaQAAJWkAADdpAABMaQAATWkAAGdpAACNaQAAjmkAAI9pAAChaQAArGkA AK1pAADSaQAA02kAANRpAADmaQAA8WkAAPJpAAAMagAALWoAAC5qAAAvagAAMGoAADFqAAAyagAA M2oAADRqAAA1agAANmoAADdqAAA4agAAOWoAADpqAAA7agAAPGoAAD1qAAA+agAAP2oAAEBqAABB agAAQmoAAENqAABEagAARWoAAEZqAABHagAASGoAAElqAABKagAAS2oAAExqAACVagAAl2oAAOBq AADhagAA4moAAAJrAAADawAASGsAAJFrAADYawAAHmwAAGRsAACtbAAA8WwAABBtAAARbQAAU20A AJdtAADgbQAAHG4AAGVuAACBbgAAgm4AAMluAAANbwAAU28AAJVvAACrbwAArG8AAK1vAADEbwAA xW8AAA5wAABXcAAAnXAAAORwAAAlcQAAZ3EAAK1xAACucQAAr3EAAMNxAADEcQAADHIAAFFyAACW cgAAl3IAAJhyAACncgAAqHIAAOxyAAABcwAAAnMAAANzAAAEcwAABXMAAE5zAABQcwAA73MAAJt1 AABZdgAAZ3cAAI13AADvdwAAXHgAAHR4AADheQAA5HkAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAA AAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAA AAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAA AJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACY AAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAA AA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAP MAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAA AAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAA AAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAA AACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAA gAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAA AACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAA gAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAA AAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAA AAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAA AAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAA AAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAA AJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACY AAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAA AA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAP MAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAA AAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAA AAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAA AACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAA gAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAA AACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAA gAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAA AAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAA AAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAHgAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAB4 AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAeAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAHgA AAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAB4AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAeAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAHgAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAB4AAAA AAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAeAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAA AJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACY AAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAA AA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAP MAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAA AAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAA AAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAA AACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAA gAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAA AACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAACACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAgAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAA gAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAA AAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAA AAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAA AAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAA AAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAA AJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACY AAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAA AA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAP MAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAA AAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAA AAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAA AACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAA gAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAA AACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAA gAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAA AAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAA AAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAA AAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAA AAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAA AJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACY AAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAA AA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAP MAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAA AAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAA AAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAA AACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAA gAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAA AACAAAAAAAAAAAAIAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAA gAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAA AAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAA AAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAA AAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAA AAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAIAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAA AJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACY AAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAA AA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAP MAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAA AAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAA AAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAA AACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAACACYAAAADzAAAAAAAAAA gAAAAIAAAAAAAAAAAAgAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAA AACAAAAAAAAAAAAIAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAA gAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAA AAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAA AAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAIAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAA AAAACACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAgAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAIAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAA AAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAA AJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAEACY AAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAABAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAQAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAEACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAABAAmAAA AA8wAAAAAAAAAIAAAACAAAAAAAAAAAAIAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAACACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAgAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAIAJgAAAAP MAAAAAAAAACAAAAAgAAAAAAAAAAACACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAgAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAIAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAACACYAAAADzAA AAAAAAAAgAAAAIAAAAAAAAAAAAgAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAIAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAACACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAA AAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAA AACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAA gAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAEACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAABAAmAAAAA8wAAAAAAAAAIAA AACAAAAAAAAAAAAQAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAEACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAIAJgAAAAPMAAAAAAAAACAAAAA gAAAAAAAAAAACAGYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAgBmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAIAZgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAACAGYAAAADzAAAAAAAAAAgAAAAIAA AAAAAAAAAAgBmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAIAZgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAAGYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAA AAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAA AAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAA AAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAA AJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAQAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAEACY AAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAgAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAIAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAACACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAA AA8wAAAAAAAAAIAAAACAAAAAAAAAAAAQAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAgAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAP MAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAgAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAIAZgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAA AAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAA AAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAA AACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAA gAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAA AACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAACACYQAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAABmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAA gAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAA AAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAA AAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAA AAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAA AAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAA AJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACY AAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAA AA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAACACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAgAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAP MAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAA AAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAA AAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAA AACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAA gAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAA AACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAA gAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAA AAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAA AAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAA AAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAA AAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAA AJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACY AAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAA AA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAP MAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAA AAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAA AAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAA AACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAA gAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAA AACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAA gAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAA AAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAA AAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAA AAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAA AAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAA AJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACY AAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAA AA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAP MAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAA AAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAA AAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAA AACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAA gAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAA AACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAA gAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAA AAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAA AAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAA AAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAA AAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAA AJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACY AAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAA AA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAP MAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAA AAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAA AAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAA AACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAA gAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAA AACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAA gAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAA AAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAA AAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAA AAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAA AAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAA AJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACY AAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAA AA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAP MAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAA AAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAA AAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAA AACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAA gAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAA AACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAA gAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAA AAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAA AAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAA AAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAA AAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAA AJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACY AAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAA AA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAP MAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAA AAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAA AAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAA AACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAA gAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAA AACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAA gAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAA AAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAA AAAAAAAAAJpAAAARMAAAAAAAAACAAAAAgAAAAAAAAAAAAASYQAAAETAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmEAAABEwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJhAAAARMAAAAAAAAACAAAAAgAAAAAAA AAAAAACYQAAAETAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmEAAABEwAAAAAAAAAIAAAACAAAAAAAAA AAAAAJhAAAARMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYQAAAETAAAAAAAAAAgAAAAIAAAAAAAAAA AAAAmEAAABEwAAAAAAAAAIAAAACAAAAAAAAAAAAABAoAAAAAMAAAAAAAAAAAAAAAAAAAyEjfDAoA AAcAAAAAAQAAAAIAAABLAAAAlAAAAN0AAAAmAQAAbwEAALgBAAABAgAAAgIAAAMCAABMAgAAlAIA AM0CAADOAgAA4gIAAOMCAAApAwAAbgMAALQDAAD4AwAA+QMAAD4EAACCBAAAxQQAANAEAADRBAAA GgUAAGIFAACkBQAA4wUAAOQFAAAeBgAATQYAAE4GAACSBgAAtgYAALcGAADtBgAA7gYAAP8GAAAA BwAALgcAAC8HAAA4BwAAOQcAAH4HAADHBwAADggAAFQIAABVCAAAVggAAFcIAACgCAAAoggAAOsI AADsCAAA7QgAADQJAAB8CQAAwAkAAPMJAAD0CQAA9QkAAAcKAAAICgAAUQoAAJoKAADjCgAALAsA AHULAAC+CwAABwwAAFAMAACZDAAA4gwAABwNAABlDQAArg0AAOsNAAA0DgAAfQ4AAMYOAAAPDwAA WA8AAKEPAACiDwAAow8AAKQPAAClDwAApg8AAKcPAACoDwAAqQ8AAKoPAACrDwAArA8AAK0PAACu DwAArw8AALAPAACxDwAAsg8AALMPAAC0DwAAtQ8AALYPAAC3DwAAuA8AAAEQAAADEAAATBAAAE0Q AABOEAAAbBAAAG0QAACvEAAA+BAAAEARAACHEQAAyREAABgSAABhEgAAqBIAANUSAADWEgAA+BIA APkSAABAEwAAhBMAAMgTAAAQFAAAIhQAACMUAABtFAAAuhQAAMIVAAAJFgAAHRYAAB4WAABiFgAA qhYAAPEWAAA8FwAAgRcAAMcXAAAHGAAACBgAAE8YAACXGAAA3hgAACAZAAAhGQAASRkAAEoZAACR GQAALBsAAHQbAADBGwAABBwAAEQcAABFHAAARhwAAEccAABIHAAAkRwAAJMcAADcHAAA3RwAAN4c AAD2HAAA9xwAAD0dAAB9HQAAwR0AAAkeAABUHgAAmh4AAOEeAAApHwAAKh8AAHEfAAC4HwAAACAA AEUgAABnIAAAaCAAALAgAAD8IAAARSEAABMiAABeIgAAlyIAAJgiAACZIgAAmiIAAJsiAACcIgAA nSIAAJ4iAACfIgAAoCIAAKEiAACiIgAAoyIAAKQiAAClIgAApiIAAKciAACoIgAAqSIAAKoiAACr IgAArCIAAK0iAACuIgAAryIAALAiAACxIgAAsiIAALMiAAD8IgAA/iIAAEcjAABIIwAASSMAAHMj AAB0IwAAuSMAAAAkAABHJAAAiSQAANIkAAAaJQAAXCUAAF0lAACEJQAAhSUAAM4lAAATJgAAPiYA AD8mAACHJgAAxyYAAA4nAABQJwAAlCcAAM8nAADQJwAAFygAAF0oAACkKAAAxSgAAMYoAAALKQAA TykAAJMpAADbKQAACyoAAAwqAAAvKgAAMCoAAHMqAAC0KgAAJCsAAGkrAACwKwAA+CsAAEEsAAB/ LAAADy0AABAtAAARLQAAEi0AABMtAAAULQAAFS0AAF4tAABgLQAAqS0AAKotAACrLQAA8i0AADou AACXLgAA5y4AACcvAABsLwAA3C8AAN0vAAAhMAAAbDAAALQwAAD/MAAAQjEAAIoxAADRMQAAFzIA AF0yAABuMgAAbzIAAJUyAACWMgAA2jIAACUzAABsMwAAjzMAAJAzAADUMwAAJzQAACg0AAB9NAAA wzQAAB01AAAuNQAALzUAAHU1AAC9NQAA+DUAAPk1AABBNgAAijYAAOo2AABINwAASTcAAJs3AADh NwAAGTgAABs4AAAcOAAAHTgAAB44AAAfOAAAaDgAAGo4AACzOAAAtDgAALU4AADYOAAA2TgAAB85 AACeOQAA5TkAAC46AAB6OgAAwzoAAOU6AADmOgAAOzsAAHM7AAB0OwAAvDsAAPE7AADyOwAAQDwA ALM8AAD0PAAA9TwAANk9AAAbPgAAYT4AAKk+AADHPgAAyD4AABA/AAA/PwAAQD8AAIU/AADOPwAA 6T8AAOo/AAAsQAAAdEAAAKBAAAChQAAA3kAAACdBAABfQQAAYEEAAKBBAAC5QQAAukEAAJ9DAACh QwAAEEQAABFEAABZRAAAn0QAAOVEAAABRQAAAkUAAEpFAACPRQAAr0UAALBFAACxRQAAskUAALNF AAD8RQAA/kUAAEdGAABIRgAASUYAAJBGAACtRgAArkYAAPVGAAA3RwAAYkcAAGRHAACURwAAlUcA ALVHAAD7RwAAQEgAAGVIAABmSAAAZ0gAAEJJAAB5SQAAekkAAMJJAADwSQAA8UkAADlKAACASgAA xUoAAAtLAABASwAAQUsAAH9LAACASwAAr0sAALBLAAD5SwAAPUwAAIZMAADOTAAAFk0AAFpNAABb TQAAtU0AAAZOAABMTgAAmU4AANdOAADYTgAA/E4AAP1OAABlTwAAvk8AAAdQAAAZUAAAGlAAABtQ AAAcUAAAHVAAAGZQAABoUAAAsVAAALJQAACzUAAA+VAAAD5RAACGUQAAu1EAALxRAAAHUgAASlIA ALBSAADTUgAA1FIAABlTAABfUwAApFMAAPBTAABCVAAAhFQAAMZUAAAOVQAAVlUAAJlVAACoVQAA qVUAABFWAABoVgAAj1YAAJBWAADWVgAAD1cAABBXAABcVwAAoFcAAOtXAAAvWAAAeFgAAMFYAAAL WQAAVFkAAJhZAACnWQAAqFkAAPBZAAA2WgAAZ1oAAGhaAABpWgAAaloAAGtaAABsWgAAbVoAAG5a AABvWgAAuFoAALpaAAADWwAABFsAAAVbAABGWwAAVFsAAFVbAACcWwAA5FsAAOVbAAARXAAAElwA AFhcAABmXAAAZ1wAAKxcAAC8XAAAvVwAAP5cAAD/XAAARF0AAIxdAADUXQAAG14AAF5eAACnXgAA 8F4AAB9fAAAgXwAAW18AAFxfAACjXwAA4V8AABpgAAAbYAAAKmAAACtgAABvYAAAqGAAAO9gAAAF YQAABmEAAE5hAACJYQAAuGEAALlhAAD9YQAAPWIAAH1iAAB+YgAAx2IAAAVjAAAGYwAAB2MAAAhj AABRYwAAU2MAAJxjAACdYwAAnmMAAOdjAAAhZAAAImQAAGVkAACRZAAAkmQAANFkAAARZQAAJmUA ACdlAABsZQAAtGUAAPxlAABCZgAAgmYAAINmAADJZgAACWcAAApnAAALZwAADGcAAA1nAAAOZwAA D2cAABBnAAARZwAAEmcAABNnAAAUZwAAFWcAABZnAAAXZwAAGGcAABlnAAAaZwAAG2cAABxnAAAd ZwAAHmcAAB9nAAAgZwAAIWcAACJnAAAjZwAAJGcAACVnAAAmZwAAJ2cAAChnAAApZwAAKmcAAHNn AAB1ZwAAvmcAAL9nAADAZwAA3mcAAN9nAAAoaAAATGgAAE1oAABOaAAAT2gAAFBoAABRaAAAUmgA AFNoAABUaAAAVWgAAFZoAABXaAAAWGgAAFloAABaaAAAW2gAAFxoAABdaAAAXmgAAF9oAABgaAAA YWgAAGJoAABjaAAAZGgAAGVoAABmaAAAZ2gAAGhoAABpaAAAamgAAGtoAABsaAAAbWgAAG5oAABv aAAAcGgAAHFoAAByaAAAc2gAAHRoAAB1aAAAdmgAAHdoAAB4aAAAeWgAAHpoAAB7aAAAxGgAAMZo AAAPaQAAEGkAABFpAAAkaQAAJWkAADdpAABMaQAATWkAAGdpAACNaQAAjmkAAI9pAAChaQAArGkA AK1pAADSaQAA02kAANRpAADmaQAA8WkAAPJpAAAMagAALWoAAC5qAAAvagAAMGoAADFqAAAyagAA M2oAADRqAAA1agAANmoAADdqAAA4agAAOWoAADpqAAA7agAAPGoAAD1qAAA+agAAP2oAAEBqAABB agAAQmoAAENqAABEagAARWoAAEZqAABHagAASGoAAElqAABKagAAS2oAAExqAACVagAAl2oAAOBq AADhagAA4moAAAJrAAADawAASGsAAJFrAADYawAAHmwAAGRsAACtbAAA8WwAABBtAAARbQAAU20A AJdtAADgbQAAHG4AAGVuAACBbgAAgm4AAMluAAANbwAAU28AAJVvAACrbwAArG8AAK1vAADEbwAA xW8AAA5wAABXcAAAnXAAAORwAAAlcQAAZ3EAAK1xAACucQAAr3EAAMNxAADEcQAADHIAAFFyAACW cgAAl3IAAJhyAACncgAAqHIAAOxyAAABcwAAAnMAAANzAAAEcwAABXMAAE5zAABQcwAA73MAAJt1 AABZdgAAZ3cAAI13AADvdwAAXHgAAHR4AADheQAA5HkAADw7ATAAMAAAAAAAAAEAAAABAAAAAAAA AAAAgAE8OwEwADAAAAAAAAABAAAAAQAAAAAAAAAAAIABPDsBMAAwAAAAAAAAAQAAAAEAAAAAAAAA AACAATw7ATAAMAAAAAAAAAEAAAABAAAAAAAAAAAAgAE8OwEwADAAAAAAAAABAAAAAQAAAAAAAAAA AIABPDsBMAAwAAAAAAAAAQAAAAEAAAAAAAAAAACAATw7ATAAMAAAAAAAAAEAAAABAAAAAAAAAAAA gAE8OwEwADAAAAAAAAABAAAAAQAAAAAAAAAAAIABPDsBMAAwAAAAAAAAAQAAAAEAAAAAAAAAAACA ATw7ATAAMAAAAAAAAAEAAAABAAAAAAAAAAAAgAE8OwEwADAAAAAAAAABAAAAAQAAAAAAAAAAAIAB PDsBMAAwAAAAAAAAAQAAAAEAAAAAAAAAAACAATw7ATAAMAAAAAAAAAEAAAABAAAAAAAAAAAAgAE8 OwEwADAAAAAAAAABAAAAAQAAAAAAAAAAAIABPDsBMAAwAAAAAAAAAQAAAAEAAAAAAAAAAACAATw7 ATAAMAAAAAAAAAEAAAABAAAAAAAAAAAAgAE8OwEwADAAAAAAAAABAAAAAQAAAAAAAAAAAIABPDsB MAAwAAAAAAAAAQAAAAEAAAAAAAAAAACAATw7ATAAMAAAAAAAAAEAAAABAAAAAAAAAAAAgAE8OwEw ADAAAAAAAAABAAAAAQAAAAAAAAAAAIABPDsBMAAwAAAAAAAAAQAAAAEAAAAAAAAAAACAATw7ATAA MAAAAAAAAAEAAAABAAAAAAAAAAAAgAE8OwEwADAAAAAAAAABAAAAAQAAAAAAAAAAAIABPDsBMAAw AAAAAAAAAQAAAAEAAAAAAAAAAACAATw7ATAAMAAAAAAAAAEAAAABAAAAAAAAAAAAgAE8OwEwADAA AAAAAAABAAAAAQAAAAAAAAAAAIABPDsBMAAwAAAAAAAAAQAAAAEAAAAAAAAAAACAATw7ATAAMAAA AAAAAAEAAAABAAAAAAAAAAAAgAE8OwEwADAAAAAAAAABAAAAAQAAAAAAAAAAAIABPDsBMAAwAAAA AAAAAQAAAAEAAAAAAAAAAACAATw7ATAAMAAAAAAAAAEAAAABAAAAAAAAAAAAgAE8OwEwADAAAAAA AAABAAAAAQAAAAAAAAAAAIABPDsBMAAwAAAAAAAAAQAAAAEAAAAAAAAAAACAATw7ATAAMAAAAAAA AAEAAAABAAAAAAAAAAAAgAE8OwEwADAAAAAAAAABAAAAAQAAAAAAAAAAAIABPDsBMAAwAAAAAAAA AQAAAAEAAAAAAAAAAACAATw7ATAAMAAAAAAAAAEAAAABAAAAAAAAAAAAgAE8OwEwADAAAAAAAAAB AAAAAQAAAAAAAAAAAIABPDsBMAAwAAAAAAAAAQAAAAEAAAAAAAAAAACAATw7ATAAMAAAAAAAAAEA AAABAAAAAAAAAAAAgAE8OwEwADAAAAAAAAABAAAAAQAAAAAAAAAAAIABPDsBMAAwAAAAAAAAAQAA AAEAAAAAAAAAAACAATw7ATAAMAAAAAAAAAEAAAABAAAAAAAAAAAAgAE8OwEwADAAAAAAAAABAAAA AQAAAAAAAAAAAIABPDsBMAAwAAAAAAAAAQAAAAEAAAAAAAAAAACAATw7ATAAMAAAAAAAAAEAAAAB AAAAAAAAAAAAgAE8OwEwADAAAAAAAAABAAAAAQAAAAAAAAAAAIABPDsBMAAwAAAAAAAAAQAAAAEA AAAAAAAAAACAATw7ATAAMAAAAAAAAAEAAAABAAAAAAAAAAAAgAE8OwEwADAAAAAAAAABAAAAAQAA AAAAAAAAAIABPDsBMAAwAAAAAAAAAQAAAAEAAAAAAAAAAACAATw7ATAAMAAAAAAAAAEAAAABAAAA AAAAAAAAgAE8OwEwADAAAAAAAAABAAAAAQAAAAAAAAAAAIABPDsBMAAwAAAAAAAAAQAAAAEAAAAA AAAAAACAATw7ATAAMAAAAAAAAAEAAAABAAAAAAAAAAAAgAE8OwEwADAAAAAAAAABAAAAAQAAAAAA AAAAAIABPDsBMAAwAAAAAAAAAQAAAAEAAAAAAAAAAACAATw7ATAAMAAAAAAAAAEAAAABAAAAAAAA AAAAgAE8OwEwADAAAAAAAAABAAAAAQAAAAAAAAAAAIABPDsBMAAwAAAAAAAAAQAAAAEAAAAAAAAA AACAATw7ATAAMAAAAAAAAAEAAAABAAAAAAAAAAAAgAE8OwEwADAAAAAAAAABAAAAAQAAAAAAAAAA AIABPDsBMAAwAAAAAAAAAQAAAAEAAAAAAAAAAACAATw7ATAAMAAAAAAAAAEAAAABAAAAAAAAAAAA gAE8OwEwADAAAAAAAAABAAAAAQAAAAAAAAAAAIABPDsBMAAwAAAAAAAAAQAAAAEAAAAAAAAAAACA ATw7ATAAMAAAAAAAAAEAAAABAAAAAAAAAAAAgAE8OwEwADAAAAAAAAABAAAAAQAAAAAAAAAAAIAB PDsBMAAwAAAAAAAAAQAAAAEAAAAAAAAAAACAATw7ATAAMAAAAAAAAAEAAAABAAAAAAAAAAAAgAE8 OwEwADAAAAAAAAABAAAAAQAAAAAAAAAAAIABPDsBMAAwAAAAAAAAAQAAAAEAAAAAAAAAAACAATw7 ATAAMAAAAAAAAAEAAAABAAAAAAAAAAAAgAE8OwEwADAAAAAAAAABAAAAAQAAAAAAAAAAAIABPDsB MAAwAAAAAAAAAQAAAAEAAAAAAAAAAACAATw7ATAAMAAAAAAAAAEAAAABAAAAAAAAAAAAgAE8OwEw ADAAAAAAAAABAAAAAQAAAAAAAAAAAIABPDsBMAAwAAAAAAAAAQAAAAEAAAAAAAAAAACAATw7ATAA MAAAAAAAAAEAAAABAAAAAAAAAAAAgAE8OwEwADAAAAAAAAABAAAAAQAAAAAAAAAAAIABPDsBMAAw AAAAAAAAAQAAAAEAAAAAAAAAAACAATw7ATAAMAAAAAAAAAEAAAABAAAAAAAAAAAAgAE8OwEwADAA AAAAAAABAAAAAQAAAAAAAAAAAIABPDsBMAAwAAAAAAAAAQAAAAEAAAAAAAAAAACAATw7ATAAMAAA AAAAAAEAAAABAAAAAAAAAAAAgAE8OwEwADAAAAAAAAABAAAAAQAAAAAAAAAAAIABPDsBMAAwAAAA AAAAAQAAAAEAAAAAAAAAAACAATw7ATAAMAAAAAAAAAEAAAABAAAAAAAAAAAAgAE8OwEwADAAAAAA AAABAAAAAQAAAAAAAAAAAIABPDsBMAAwAAAAAAAAAQAAAAEAAAAAAAAAAACAATw7ATAAMAAAAAAA AAEAAAABAAAAAAAAAAAAgAE8OwEwADAAAAAAAAABAAAAAQAAAAAAAAAAAIABPDsBMAAwAAAAAAAA AQAAAAEAAAAAAAAAAACAATw7ATAAMAAAAAAAAAEAAAABAAAAAAAAAAAAgAE8OwEwADAAAAAAAAAB AAAAAQAAAAAAAAAAAIABPDsBMAAwAAAAAAAAAQAAAAEAAAAAAAAAAACAATw7ATAAMAAAAAAAAAEA AAABAAAAAAAAAAAAgAE8OwEwADAAAAAAAAABAAAAAQAAAAAAAAAAAIABPDsBMAAwAAAAAAAAAQAA AAEAAAAAAAAAAACAATw7ATAAMAAAAAAAAAEAAAABAAAAAAAAAAAAgAE8OwEwADAAAAAAAAABAAAA AQAAAAAAAAAAAIABPDsBMAAwAAAAAAAAAQAAAAEAAAAAAAAAAACAATw7ATAAMAAAAAAAAAEAAAAB AAAAAAAAAAAAgAE8OwEwADAAAAAAAAABAAAAAQAAAAAAAAAAAIABPDsBMAAwAAAAAAAAAQAAAAEA AAAAAAAAAACAATw7ATAAMAAAAAAAAAEAAAABAAAAAAAAAAAAgAE8OwEwADAAAAAAAAABAAAAAQAA AAAAAAAAAIABPDsBMAAwAAAAAAAAAQAAAAEAAAAAAAAAAACAATw7ATAAMAAAAAAAAAEAAAABAAAA AAAAAAAAgAE8OwEwADAAAAAAAAABAAAAAQAAAAAAAAAAAIABmAAAAA8wAAAAAAAAAIAAAACAAAAA AAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAA AAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAADAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAA AAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAA AJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACY AAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAMAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAwAAAAAAAAmAAA AA8wAAAAAAAAAIAAAACAAAAAMAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAADAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAwAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAMAAAAAAAAJgAAAAP MAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAgAAAAAIAAmAAAAA8w AAAAAAAAAIAAAACAAAAAIAAAAACAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAA AAAAAAAAgAAAAIAAAAAgAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAIAAAAACAAJgAAAAPMAAA AAAAAACAAAAAgAAAABgAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAgAAAAAIAAmAAAAA8wAAAA AAAAAIAAAACAAAAAMAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAACgAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAgAAAAAIAAmAAAAA8wAAAAAAAAAIAAAACAAAAAIAAAAAAAAJgAAAAPMAAAAAAA AACAAAAAgAAAACAAAAAAgACYAAAADzAAAAAAAAAAgAAAAIAAAAAgAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAMAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAACAAAAAAgACYAAAADzAAAAAAAAAA gAAAAIAAAAAQAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAIAAAAACAAJgAAAAPMAAAAAAAAACA AAAAgAAAABgAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAoAAAAAAAAmAAAAA8wAAAAAAAAAIAA AACAAAAAIAAAAACAAJgAAAAPMAAAAAAAAACAAAAAgAAAADAAAAAACAeYAAAADzAAAAAAAAAAgAAA AIAAAAAgAAAAAIgAmAAAAA8wAAAAAAAAAIAAAACAAAAAIAAAAACAAJgAAAAPMAAAAAAAAACAAAAA gAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAA AAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAA AAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAA AAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAA AAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAA AJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACY AAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAA AA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAP MAAAAAAAAACAAAAAgAAAAAAAAAAAAAeYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAA AAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAA AAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAA AACAAAAAgAAAADAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAwAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAMAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAADAAAAAAAACYAAAADzAAAAAAAAAA gAAAAIAAAAAgAAAAAIAAmAAAAA8wAAAAAAAAAIAAAACAAAAAMAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAACAAAAAAgACYAAAADzAAAAAAAAAAgAAAAIAAAAAwAAAAAAAAmAAAAA8wAAAAAAAAAIAA AACAAAAAIAAAAACAAJgAAAAPMAAAAAAAAACAAAAAgAAAADAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAgAAAAAIAAmAAAAA8wAAAAAAAAAIAAAACAAAAAMAAAAAAAAJgAAAAPMAAAAAAAAACAAAAA gAAAACAAAAAAgACYAAAADzAAAAAAAAAAgAAAAIAAAAAwAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAIAAAAACAAJgAAAAPMAAAAAAAAACAAAAAgAAAACgAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAA AABAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAIAAAAACAAJgAAAAPMAAAAAAAAACAAAAAgAAA ACAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAA AAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAA AAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAA AAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAA AJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACY AAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAA AA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAP MAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAA AAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAA AAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAADAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAA AACAAAAAgAAAADAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAMAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAACAAAAAAgAeYAAAADzAAAAAAAAAA gAAAAIAAAAAwAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAADAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAwAAAAAAAAmAAAAA8wAAAAAAAAAIAA AACAAAAAAAAAAAAIAJgAAAAPMAAAAAAAAACAAAAAgAAAADAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAYAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAQAAAAAAAAJgAAAAPMAAAAAAAAACAAAAA gAAAACAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAgAAAAAIAAmAAAAA8wAAAAAAAAAIAAAACA AAAAMAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAACAAAAAAgACYAAAADzAAAAAAAAAAgAAAAIAA AAAgAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAQAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAA AAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAABmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAA AAAAAAGYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAADAAAAAAAAeYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAA AAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAIAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAA AJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAAeY AAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAA AA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAP MAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAAeYAAAADzAA AAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAAGYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAHmAAAAA8wAAAA AAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAA AACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAMAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAACAGYAAAADzAAAAAAAAAA gAAAAIAAAAAwAAAAAAgHmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAPMAAAAAAAAACA AAAAgAAAADAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAA8wAAAAAAAAAIAA AACAAAAAMAAAAAAIB5gAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAAeYAAAADzAAAAAAAAAAgAAA AIAAAAAwAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAA gAAAADAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAMAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAA AAAgAAAAAIAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAA AAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAIB5gAAAAPMAAAAAAAAACAAAAAgAAAAAAA AAAACAGYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAgBmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAIAZgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAAeYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAA AAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AAeYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAA AJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAEAE8 OwEwYzEAAAAAAAABAAAAAQAAAAAAAAAAABABmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAQAZgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAEAE8OwEwZjEAAAAAAAABAAAAAQAAAAAAAAAAABABmAAA AA8wAAAAAAAAAIAAAACAAAAAAAAAAAAIB5gAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAACAeYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAgHmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAIB5gAAAAP MAAAAAAAAACAAAAAgAAAAAAAAAAACAeYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAgHmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAIB5gAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAACAeYAAAADzAA AAAAAAAAgAAAAIAAAAAAAAAAAAgHmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAIB5gAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAACAeYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAA AAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAA AACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAwAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAMAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAA gAAAAIAAAAAwAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAADAAAAAAEAE8OwEwfjEAAAAAAAABAAAAAQAAAAAAAAAAABAHmAAAAA8wAAAAAAAAAIAA AACAAAAAMAAAAAAQATw7ATCAMQAAAAAAAAEAAAABAAAAAAAAAAAAEAeYAAAADzAAAAAAAAAAgAAA AIAAAAAwAAAAAAABmAAAAA8wAAAAAAAAAIAAAACAAAAAGAAAAAAIB5gAAAAPMAAAAAAAAACAAAAA gAAAABgAAAAACAeYAAAADzAAAAAAAAAAgAAAAIAAAAAYAAAAAAgHmAAAAA8wAAAAAAAAAIAAAACA AAAAKAAAAAAIB5hAAAAPMAAAAAAAAACAAAAAgAAAACgAAAAACAeYAAAADzAAAAAAAAAAgAAAAIAA AAAoAAAAAAgHmAAAAA8wAAAAAAAAAIAAAACAAAAAKAAAAAAIB5gAAAAPMAAAAAAAAACAAAAAgAAA ACgAAAAAAAeYAAAADzAAAAAAAAAAgAAAAIAAAAAoAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAA KAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAACgAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAo AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAKAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAACAA AAAAgACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAA AAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAA AJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAQAZgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAEAGY AAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAgHmEAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAIAZhA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAACAGYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAA AA8wAAAAAAAAAIAAAACAAAAAAAAAAAAQAZgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAgHmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAP MAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAgHmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAIB5gAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAA AAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAA AAAAAIAAAACAAAAAAAAAAAAAB5gAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAHmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAA AACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAwAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAADAAAAAAAACYAAAADzAAAAAAAAAA gAAAAIAAAAAAAAAAAAAHmAAAAA8wAAAAAAAAAIAAAACAAAAAMAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAADAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAwAAAAAAAAmAAAAA8wAAAAAAAAAIAA AACAAAAAAAAAAAAAAJhAAAAPMAAAAAAAAACAAAAAgAAAADAAAAAACAGYQAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAABmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAPMAAAAAAAAACAAAAA gAAAAAAAAAAAAAGYAAAADzAAAAAAAAAAgAAAAIAAAAAgAAAAAIAAmAAAAA8wAAAAAAAAAIAAAACA AAAAGAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAADAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAA AAAgAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAMAAAAAAAB5gAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAAeYAAAADzAAAAAAAAAAgAAAAIAAAAAgAAAAAIAAmAAAAA8wAAAAAAAAAIAAAACAAAAA IAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAEAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAg AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAIAAAAACAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAA AAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAgAAAAAIAAmAAAAA8wAAAAAAAAAIAAAACAAAAAGAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAA AAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAA AJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACY AAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAHmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAA AA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAACAGYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAgBmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAB5gAAAAP MAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAA AAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAHmAAAAA8wAAAA AAAAAIAAAACAAAAAAAAAAAAAB5gAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAA AACAAAAAgAAAAAAAAAAAAAeYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAA gAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAMAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAADAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAA AACAAAAAMAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAwAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAB5gAAAAPMAAAAAAAAACAAAAA gAAAACAAAAAAgACYAAAADzAAAAAAAAAAgAAAAIAAAAAgAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAOAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAACgAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAA AAAgAAAAAIAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA ACAAAAAAgACYAAAADzAAAAAAAAAAgAAAAIAAAAAoAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAA QAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAACAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAg AAAAAIAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAACAA AAAAgACYAAAADzAAAAAAAAAAgAAAAIAAAAAgAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAA AAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAA AJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACY AAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAA AA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAP MAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAA AAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAA AAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAA AACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAA gAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAA AACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAMAAAAAAAAJgAAAAPMAAAAAAAAACAAAAA gAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAwAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAADAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAA AAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAIAAAAACAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAgAAAAAIAAmAAAAA8wAAAAAAAAAIAAAACAAAAA AAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAACAAAAAAgACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAIAAAAACAAJgAAAAPMAAAAAAAAACAAAAAgAAAACAA AAAAgACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAA AAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAA AJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACY AAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAA AA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAADAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAP MAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAA AAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAA AAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAA AACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAA gAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAMAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAADAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAwAAAAAAAAmAAAAA8wAAAAAAAAAIAA AACAAAAAMAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAACAAAAAAgACYAAAADzAAAAAAAAAAgAAA AIAAAAAYAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAIAAAAACAAJgAAAAPMAAAAAAAAACAAAAA gAAAADAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAgAAAAAIAAmAAAAA8wAAAAAAAAAIAAAACA AAAAGAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAADAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAA AAAgAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAIAAAAACAAJgAAAAPMAAAAAAAAACAAAAAgAAA ADAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAgAAAAAIAAmAAAAA8wAAAAAAAAAIAAAACAAAAA IAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAEAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAg AAAAAIAAmAAAAA8wAAAAAAAAAIAAAACAAAAAIAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAA AAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAA AAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAA AJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACY AAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAA AA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAP MAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAA AAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAA AAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAA AACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAA gAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAA AACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAADAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAMAAAAAAAAJgAAAAPMAAAAAAAAACAAAAA gAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAwAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAADAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAA AAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAMAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAwAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAA AAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAACAAAAAAgACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAA AAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAA AAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAA AJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACY AAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAA AA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAP MAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAA AAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAA AAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAA AACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAADAAAAAAAACYAAAADzAAAAAAAAAA gAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAMAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAwAAAAAAAAmAAAAA8wAAAAAAAAAIAA AACAAAAAIAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAACAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAgAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAIAAAAAAAAJgAAAAPMAAAAAAAAACAAAAA gAAAACAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAgAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAIAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAACAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAA AAAgAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAIAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA ACAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAgAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAA IAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAACAAAAAAgACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAA AAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAA AAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAA AJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACY AAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAA AA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAP MAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAA AAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAwAAAAAAAAmAAAAA8wAAAA AAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAADAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAMAAAAAAAAJgAAAAPMAAAAAAA AACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAwAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAADAAAAAAAACYAAAADzAAAAAAAAAA gAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAMAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAgAAAAAIAAmAAAAA8wAAAAAAAAAIAA AACAAAAAGAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAADAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAgAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAIAAAAACAAJgAAAAPMAAAAAAAAACAAAAA gAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAgAAAAAIAAmAAAAA8wAAAAAAAAAIAAAACA AAAAIAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAEAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAA AAAgAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAIAAAAACAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAgAAAAAIAACAAAAAAwAAAAAAAAAAAAAAAA4QDU AVMECgAAB5hAAAARMAAAAAAAAACAAAAAgAAAAAAAAAAAAAeYQAAAADAAAAAAAAAAgAAAAIAAAAAA AAAAAIABmEAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAACAAZhAAAAAMAAAAAAAAACAAAAAgAAAAAAA AAAAgAGYQAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAIAHmEAAAAAwAAAAAAAAAIAAAACAAAAAAAAA AACAAZhAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAgAGYQAAAADAAAAAAAAAAgAAAAIAAAAAAAAAA AIABmEAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAACABwgAAAAAMAAAAAAAAAAAAAAAAOEAjErfDAoA AAcABgAABSAAAKglAADyMgAA0DQAAIo3AAAlPAAAN0EAAMJDAAB6RgAA0kwAANVRAADqUgAA2FcA ANVbAABRXwAADH8AAG7tAABBAAAASQAAAEsAAABPAAAAUAAAAFIAAABUAAAAVgAAAFcAAABaAAAA XQAAAGEAAABjAAAAZQAAAGcAAABoAAAAdAAAAAAGAABiDQAA7RAAAKIXAABtGAAAYh4AAJMkAACZ KgAARysAAMUwAACpNQAAkDsAALNAAACwRQAAZEYAAElHAADQSgAAEU0AAHJOAAAEUQAA1lEAAMpW AAAsWwAAEGEAAAxlAACbaQAAAm4AAIpwAADAcQAA3XEAABFzAACwcwAAw3YAAAZ8AABu7QAAQgAA AEQAAABFAAAARgAAAEcAAABIAAAASgAAAEwAAABNAAAATgAAAFEAAABTAAAAVQAAAFgAAABZAAAA WwAAAFwAAABeAAAAXwAAAGAAAABiAAAAZAAAAGYAAABpAAAAagAAAGsAAABsAAAAbQAAAG4AAABv AAAAcAAAAHEAAAByAAAAcwAAAAAGAABt7QAAQwAAAA8AAPA4AAAAAAAG8BgAAAACCAAAAgAAAAEA AAABAAAAAQAAAAIAAABAAB7xEAAAAP//AAAAAP8AgICAAPcAABAADwAC8JIAAAAQAAjwCAAAAAEA AAABBAAADwAD8DAAAAAPAATwKAAAAAEACfAQAAAAAAAAAAAAAAAAAAAAAAAAAAIACvAIAAAAAAQA AAUAAAAPAATwQgAAABIACvAIAAAAAQQAAAAOAABTAAvwHgAAAL8BAAAQAMsBAAAAAP8BAAAIAAQD CQAAAD8DAQABAAAAEfAEAAAAAQAAAP//CAAAAAYAHUgMAAAAAQAcW8wCBgAeSAwAAAABAGxczAIG AB9IDAAAAAEAjJwZAAYAIEgMAAAAAQD0zxcABgAhSAwAAAABAGw8zgIGACJIDAAAAAEAzFPOAgYA I0gMAAAAAQBMnBkABgAkSAwAAAABAAzQwAKdAAAA8AEAAN0GAAB4CAAA2Q8AAGkcAADUIgAANi0A AOR5AAAAAAAAAQABAAAAAQACAAAAAQADAAAAAQAEAAAAAQAFAAAAAQAGAAAAAQAHAAAAAQCrAAAA AAIAAOsGAACGCAAA5w8AAHccAADiIgAARC0AAOR5AAAAAAAAAQAAAAIAAAADAAAABAAAAAUAAAAG AAAABwAAAAEAAAA4AAAACAAAACqAdXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6c21h cnR0YWdzBIBkYXRlAIAMAAABAQAAAAkAAAACgDEwAoAxMQKAMTQEgDIwMDUEgDIwMDYBgDQDgERh eQWATW9udGgEgFllYXIIAAMAAAAHAAAABQAAAAYAAAACAAAACAAAAAQAAAAIAAMAAAAHAAAAAAAA AAYAAAABAAAACAAAAAMAAAAIAAMAAAAHAAAABQAAAAYAAAACAAAACAAAAAQAAAAIAAMAAAAHAAAA BQAAAAYAAAACAAAACAAAAAQAAAAIAAMAAAAHAAAABQAAAAYAAAACAAAACAAAAAQAAAAIAAMAAAAH AAAABQAAAAYAAAACAAAACAAAAAQAAAAIAAMAAAAHAAAABQAAAAYAAAACAAAACAAAAAQAAAAIAAMA AAAHAAAABQAAAAYAAAACAAAACAAAAAQAAAD//wEACgAAAAABAlz+Bv////+AVQAAUnMAAAAAAACD VQAAUnMAAAAAAADUAAAA3AAAAGgBAABuAQAAPgUAAEcFAADDCQAA0QkAAH0UAACBFAAAMBcAADQX AACkGAAAqBgAANYYAADaGAAAVB0AAF0dAAC+HgAAyh4AAM8fAADTHwAADCUAABAlAABDJQAARyUA AHgmAAB/JgAAXicAAGMnAAD0KgAA9ioAAA8rAAARKwAA/SwAAActAABzLgAAdi4AABwvAAAgLwAA czEAAHcxAAC1MQAAwTEAAPA0AAD9NAAAOjkAADw5AAB7OQAAfTkAAI05AACPOQAAkjkAAJQ5AABu OgAAcDoAAC87AAAzOwAAmEMAAJxDAACiQwAAo0MAAC1LAAA8SwAAeEwAAIJMAACfTAAAp0wAAEJN AABGTQAAAlQAAARUAAAJVAAAC1QAADZXAAA6VwAA3VgAAOFYAABCYAAASmAAAFdgAABdYAAAsGAA AO1gAADAYwAAzmMAAJpkAAChZAAA2WQAAOJkAACaZgAApWYAALJmAAC2ZgAA2mYAAOVmAAACaAAA CWgAAApoAAARaAAAmGkAAKBpAADfaQAA5WkAAFBzAAB6cwAAgXMAAJ50AACgdAAAUXcAAF53AADh eQAA5HkAAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcA HAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAc AAcAHAAHABwABwADAAcABwAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwA BwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHAAcAHAAHABwABwAc AAcABwAAAAAALgIAADcCAAB7AgAAiwIAAKQCAADMAgAALAMAADYDAABxAwAAdQMAALcDAAC8AwAA QQQAAHYEAACFBAAAigQAAMgEAADPBAAAHQUAACAFAABlBQAAaQUAAKcFAACvBQAAEQcAABQHAAAR CAAAGggAAFcIAABoCAAA8AgAAPMIAAA3CQAAQQkAAFkKAABgCgAAogoAAKkKAADrCgAA8QoAAH0L AACJCwAAxgsAAM8LAAAPDAAAFgwAAFgMAABfDAAAoQwAAK0MAABtDQAAeg0AALYNAADCDQAAPA4A AEYOAADJDgAA1A4AALgPAADJDwAAshAAAL4QAABDEQAARBEAAIoRAACTEQAAzBEAANURAAAbEgAA IxIAAGUSAABnEgAAkhIAAKcSAADZEgAA4BIAAEMTAABGEwAAhxMAAI4TAADLEwAA0hMAABMUAAAY FAAAvRQAAMUUAABeFQAAYhUAABAWAAATFgAAZRYAAG4WAACtFgAAthYAAPQWAAD+FgAAhBcAAIkX AAD+FwAAARgAAFIYAABXGAAAmhgAAKEYAADhGAAA6xgAACQZAAArGQAAlBkAAJcZAADEGwAAzhsA AAccAAAOHAAASBwAAFkcAADhHAAA5xwAAEAdAABDHQAAgB0AAIodAADEHQAA0R0AAAweAAANHgAA Vx4AAGEeAACdHgAAox4AAOQeAAD5HgAAdB8AAHYfAAC7HwAAvR8AAAMgAAANIAAASCAAAE8gAACz IAAAtyAAAP8gAAACIQAASCEAAEshAAAWIgAAGiIAAGEiAABmIgAAsyIAAMQiAAC8IwAAwSMAAAMk AAAFJAAASiQAAE0kAACMJAAAliQAANUkAADfJAAAHSUAACglAABgJQAAbCUAANQlAADZJQAAGSYA ACQmAACEJgAAhiYAAI0mAACQJgAAzSYAANcmAAAUJwAAFicAAFYnAABdJwAAmicAAKInAAAdKAAA JCgAAGMoAABqKAAAqigAAKwoAAARKQAAFikAAFUpAABcKQAAmSkAAKApAADhKQAA6SkAAA8qAAAY KgAAuioAAMMqAAC2KwAAvisAAP4rAAAALAAARywAAEssAACWLAAAnywAABUtAAAmLQAA+C0AAP0t AABALgAASy4AAJ0uAACgLgAA7S4AAPguAAAuLwAANy8AAHIvAAB7LwAALDAAAD8wAAByMAAAezAA ALowAADFMAAABTEAAAkxAABIMQAAVTEAANcxAADfMQAAHTIAACIyAABjMgAAbDIAAHIyAAB5MgAA 4DIAAOgyAAArMwAAMDMAAHIzAAB6MwAA2jMAAOMzAACLNAAAjjQAAMk0AADPNAAAIzUAACY1AAA1 NQAAWjUAAHs1AACDNQAAwzUAAMc1AABHNgAAUzYAAJY2AACZNgAAEDcAABI3AABPNwAAdDcAAKE3 AAClNwAAHzgAADA4AAC4OAAAvzgAAPU4AAANOQAAJTkAACk5AACPOgAAmToAAMk6AADNOgAAQTsA AEo7AAAyQAAAOUAAAHpAAAB/QAAA5EAAAPBAAACmQQAAr0EAALNFAADERQAAmkYAAKNGAAD7RgAA BEcAAD1HAABGRwAAu0cAAMJHAAABSAAACEgAAEZIAABRSAAAP0oAAEJKAACGSgAAj0oAAMtKAADP SgAAEUsAABVLAABHSwAAfUsAAINLAACPSwAA/EsAAP9LAABATAAASUwAAIlMAACQTAAA9UwAAPxM AAAZTQAAHk0AANpNAADdTQAADE4AABROAABSTgAAWE4AAJ9OAACpTgAA3k4AAPtOAABrTwAAcE8A AMRPAADITwAADVAAAA9QAAAdUAAALlAAAP9QAAAIUQAARFEAAEhRAACMUQAAjlEAAA1SAAAPUgAA UFIAAFRSAAC2UgAAvVIAAEhUAABRVAAAilQAAJRUAADMVAAA1lQAABRVAAAYVQAAXFUAAGFVAACf VQAAplUAABdWAAAaVgAAblYAAHVWAADcVgAA4lYAAGJXAABlVwAA8VcAAPdXAAB+WAAAgFgAAMdY AADPWAAAEVkAABpZAACeWQAApFkAAK5ZAADPWQAA9lkAAP9ZAAA8WgAAQVoAAG9aAACAWgAASlsA AFNbAACfWwAAolsAAOhbAAD1WwAAW1wAAGJcAACvXAAAuFwAAMBcAADMXAAAR10AAEtdAACPXQAA tF0AANddAADYXQAAHl4AACJeAABhXgAAZ14AAKpeAACzXgAA814AAPdeAAAjXwAALV8AAKZfAACs XwAA5F8AAO9fAAAwYAAAPGAAAAthAAAbYQAAVmEAAFlhAAC+YQAAyWEAAINiAACHYgAAz2IAANZi AAAIYwAAGWMAAKNjAACnYwAA72MAAPZjAAAnZAAAK2QAAJdkAAChZAAALGUAADBlAAB0ZQAAfGUA AARmAAAIZgAASmYAAE9mAACIZgAAlGYAACpnAAA7ZwAAwGcAAMtnAAAraAAALmgAAHtoAACMaAAA TGoAAF1qAACUawAAm2sAANtrAADfawAAIWwAACZsAABnbAAAa2wAALBsAACybAAA9GwAAPlsAABW bQAAYG0AAJptAAChbQAA420AAOdtAAAfbgAALG4AAMxuAADWbgAAEG8AABZvAABWbwAAWm8AAGpx AACscQAA1XEAANhxAAAPcgAAEXIAAFRyAABacgAA73IAAABzAAAFcwAAFnMAAFBzAABseAAAc3gA AOF5AADkeQAABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAH ADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAz AAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAH ADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAz AAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAH ADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAz AAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAH ADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAz AAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAH AAcAMwAHAAcAAAAAADUaAAA+GgAAVBoAAFkaAAB7GgAAfhoAAJUiAACWIgAA9CoAAAcrAAAIKwAA CCsAABArAAAjKwAAAy4AAAQuAAAFLgAABS4AAKsuAACxLgAAsi4AALIuAADMLwAA0i8AAN8xAADg MQAAJTQAACY0AADCNgAA0DYAAGE5AABlOQAAw0IAAMpCAADRQgAAnUMAAG1IAABuSAAAb0gAAG9I AABwSAAAcUgAAHJIAABySAAAc0gAAINIAACESAAAhUgAALJIAAC6SAAAu0gAAMBIAADuSQAA7kkA AD5LAAA/SwAAfUsAAH5LAABmTAAAZ0wAAJFNAACiTQAAs00AALNNAADaTQAA6E0AAAZOAAAGTgAA cU4AAHlOAAAPTwAAD08AABFPAAAdTwAAQE8AAFFPAACATwAAiU8AAIpPAACKTwAAqk8AALBPAABQ UgAAZVIAAJBSAACeUgAAAlQAAAtUAACDVQAAhFUAAL1VAAC9VQAAv1UAAMtVAADmVQAA91UAACZW AAAmVgAAKFYAAC9WAAAwVgAAMFYAAFBWAABWVgAA+FYAAPhWAAD6VgAABlcAAKVZAACmWQAAT3MA AOR5AAADAAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQA AwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAEAAMABAAD AAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAEAAMA BAADAAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAH AAAAAACYQwAAnEMAAFBzAADkeQAABwAEAAcABwAAAAAA5HkAAMMHAAAIAAAADJEQAAAAAQAAAAQA AAAAAAIA//8EAAAABABTAGgAZQB3AAAADQBUAHIAZQB2AG8AcgAgAFcAaQBsAHMAbwBuAAAAJwAA AAQAAAAIAAAA5QAAAAAAAAAmAAAAdX0AACM3AQB+KgcAc1wMAEJaFwAzbBgAZ2EkAEZgKQDEVzoA FXY/ADYZRwAPEVQAlw1VAOVxVQAmAV4AykpfAFoDYQAEaGEAPh9jAIMHbwDBG28A5yR1ACgNeAD3 IXkA/SqFAJU/hwACCKAAwD2vAIsksQDBNrQAniG1AIU3xABFCsoABSbKAOYcywAVbdAAHTfuACRU 7gD0cPAA/0AAgAEAAAAAAAAAAABIEXwTAQABAAAAAAAAAAAAAAAAAAAAAAACNAAAAAAAAACQOQAA kDoAAHV4AADjeQAAwAAAEABAAADAAABCAAAAAMAAAIgAQAAAwAAA2AFAAAD//wIAAAAHAFUAbgBr AG4AbwB3AG4ADQBUAHIAZQB2AG8AcgAgAFcAaQBsAHMAbwBuAP//AgAIAAAAAAAAAAAAAAAAAAAA AAAAAAEA//8CAAAAAAAAAP//AAACAP//AAAAAP//AAACAP//AAAAAAYAAABHFpABAAACAgYDBQQF AgMEh3oAIAAAAIAIAAAAAAAAAP8BAAAAAAAAVABpAG0AZQBzACAATgBlAHcAIABSAG8AbQBhAG4A AAA1FpABAgAFBQECAQcGAgUHAAAAAAAAABAAAAAAAAAAAAAAAIAAAAAAUwB5AG0AYgBvAGwAAAAz JpABAAACCwYEAgICAgIEh3oAIAAAAIAIAAAAAAAAAP8BAAAAAAAAQQByAGkAYQBsAAAAOwaQAYYH AgEGAAMBAQEBAQMAAAAAAA4IEAAAAAAAAAABAAQAAAAAAFMAaQBtAFMAdQBuAAAAi1tTTwAAPzWQ AQAAAgcDCQICBQIEBId6ACAAAACACAAAAAAAAAD/AQAAAAAAAEMAbwB1AHIAaQBlAHIAIABOAGUA dwAAADUmkAEAAAILBgQDBQQEAgSHegAhAAAAgAgAAAAAAAAA/wEBAAAAAABUAGEAaABvAG0AYQAA ACIABAAxiIwYAPDQAgAAaAEAAAAAs6uaprOrmqYAAAAAAgABAAAANREAABtiAAABADoAAAAEAAMQ 0QAAADURAAAbYgAAAQA6AAAA0QAAAAAAAAAhAwDwEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAnBaAFtAC0AIGBMjQAABAAGQBkAAAAGQAAABZzAAAWcwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAAAAAAAAAAAgzg3EA8BAA CAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAASAAAAAAAKPD/DwEAAT8AAAAAAACzEQAA//// f////38AAAAA////f////3////9/AgigAP//EgAAAAAAAAA9AEMAQwBBAE0AUAAgAHcAbwByAGsA aQBuAGcAIABHAHIAbwB1AHAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAg ACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgAEcAAAAAAAAABABTAGgA ZQB3AA0AVAByAGUAdgBvAHIAIABXAGkAbABzAG8AbgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD+/wAABQACAAAAAAAAAAAAAAAA AAAAAAABAAAA4IWf8vlPaBCrkQgAKyez2TAAAACsAQAAEQAAAAEAAACQAAAAAgAAAJgAAAADAAAA 4AAAAAQAAADsAAAABQAAAPwAAAAGAAAACAEAAAcAAAAUAQAACAAAACgBAAAJAAAAQAEAABIAAABM AQAACgAAAGgBAAAMAAAAdAEAAA0AAACAAQAADgAAAIwBAAAPAAAAlAEAABAAAACcAQAAEwAAAKQB AAACAAAA5AQAAB4AAAA+AAAAQ0NBTVAgd29ya2luZyBHcm91cCAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgRwAgAB4AAAABAAAAAENBTR4AAAAFAAAAU2hldwAgd28eAAAA AQAAAABoZXceAAAAAQAAAABoZXceAAAACwAAAE5vcm1hbC5kb3QAbh4AAAAOAAAAVHJldm9yIFdp bHNvbgBHch4AAAACAAAAMgBldh4AAAAUAAAATWljcm9zb2Z0IFdvcmQgMTAuMABAAAAAAEbDIwAA AABAAAAAAHoLeEbWxQFAAAAAAHoLeEbWxQEDAAAAAQAAAAMAAAA1EQAAAwAAABtiAAADAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/v8AAAUAAgAAAAAAAAAAAAAAAAAAAAAAAgAA AALVzdWcLhsQk5cIACss+a5EAAAABdXN1ZwuGxCTlwgAKyz5rnQBAAAwAQAADAAAAAEAAABoAAAA DwAAAHAAAAAFAAAAiAAAAAYAAACQAAAAEQAAAJgAAAAXAAAAoAAAAAsAAACoAAAAEAAAALAAAAAT AAAAuAAAABYAAADAAAAADQAAAMgAAAAMAAAAEgEAAAIAAADkBAAAHgAAABAAAABOb3J0ZWwgTmV0 d29ya3MAAwAAANEAAAADAAAAOgAAAAMAAAAWcwAAAwAAAE8aCgALAAAAAAAAAAsAAAAAAAAACwAA AAAAAAALAAAAAAAAAB4QAAABAAAAPgAAAENDQU1QIHdvcmtpbmcgR3JvdXAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIEcADBAAAAIAAAAeAAAABgAAAFRpdGxlAAMAAAAB AAAAgAEAAAcAAAAAAAAAQAAAAAEAAADMAAAAAgAAANQAAAADAAAA3AAAAAQAAAAoAQAABQAAAEwB AAAGAAAAdAEAAAUAAAACAAAAFAAAAF9BZEhvY1Jldmlld0N5Y2xlSUQAAwAAAA4AAABfRW1haWxT dWJqZWN0AAQAAAANAAAAX0F1dGhvckVtYWlsAAUAAAAYAAAAX0F1dGhvckVtYWlsRGlzcGxheU5h bWUABgAAABkAAABfUmV2aWV3aW5nVG9vbHNTaG93bk9uY2UAAgAAAOQEAAADAAAArpqBLh4AAABB AAAAVkNBVC9MQ0FTIGRyYWZ0IHVwZGF0ZTogZHJhZnQtYmVybnN0ZWluLWNjYW1wLWdtcGxzLXZj YXQtbGNhcy0wMQBlAEMeAAAAGgAAAHNkc2hld0BhbWVyaWNhc20wMS5udC5jb20AYWYeAAAAHgAA AFNoZXcsIFN0ZXBoZW4gW0NBUjpRVDMwOkVYQ0hdAGJlHgAAAAEAAAAAaGV3AAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAACAAAAAwAAAAQAAAAFAAAABgAAAAcAAAAIAAAACQAA AAoAAAALAAAADAAAAA0AAAAOAAAADwAAABAAAAARAAAAEgAAABMAAAAUAAAAFQAAABYAAAAXAAAA GAAAABkAAAAaAAAAGwAAABwAAAAdAAAAHgAAAB8AAAAgAAAAIQAAACIAAAAjAAAAJAAAACUAAAAm AAAAJwAAACgAAAApAAAAKgAAACsAAAAsAAAALQAAAC4AAAAvAAAAMAAAADEAAAAyAAAAMwAAADQA AAA1AAAANgAAADcAAAA4AAAAOQAAADoAAAA7AAAAPAAAAD0AAAA+AAAAPwAAAEAAAABBAAAAQgAA AEMAAABEAAAARQAAAEYAAABHAAAASAAAAEkAAABKAAAASwAAAEwAAABNAAAATgAAAE8AAABQAAAA UQAAAFIAAABTAAAAVAAAAFUAAABWAAAAVwAAAFgAAABZAAAAWgAAAFsAAABcAAAAXQAAAF4AAABf AAAAYAAAAGEAAABiAAAAYwAAAGQAAABlAAAAZgAAAGcAAABoAAAAaQAAAGoAAABrAAAAbAAAAG0A AABuAAAAbwAAAHAAAABxAAAAcgAAAHMAAAB0AAAAdQAAAHYAAAB3AAAA/v///3kAAAB6AAAAewAA AHwAAAB9AAAAfgAAAH8AAAD+////gQAAAIIAAACDAAAAhAAAAIUAAACGAAAAhwAAAIgAAACJAAAA igAAAIsAAACMAAAAjQAAAI4AAACPAAAAkAAAAJEAAACSAAAAkwAAAJQAAACVAAAAlgAAAJcAAACY AAAAmQAAAJoAAACbAAAAnAAAAJ0AAACeAAAAnwAAAKAAAAChAAAAogAAAKMAAACkAAAApQAAAKYA AACnAAAAqAAAAKkAAACqAAAAqwAAAKwAAACtAAAArgAAAK8AAACwAAAAsQAAALIAAACzAAAAtAAA ALUAAAC2AAAAtwAAALgAAAC5AAAAugAAALsAAAC8AAAAvQAAAL4AAAC/AAAAwAAAAMEAAADCAAAA wwAAAMQAAADFAAAAxgAAAMcAAADIAAAAyQAAAMoAAADLAAAAzAAAAM0AAADOAAAAzwAAANAAAADR AAAA0gAAANMAAADUAAAA1QAAANYAAADXAAAA2AAAANkAAADaAAAA2wAAANwAAADdAAAA3gAAAN8A AADgAAAA4QAAAOIAAADjAAAA5AAAAOUAAADmAAAA5wAAAOgAAADpAAAA6gAAAOsAAADsAAAA7QAA AO4AAADvAAAA8AAAAPEAAADyAAAA8wAAAPQAAAD1AAAA/v////cAAAD4AAAA+QAAAPoAAAD7AAAA /AAAAP0AAAD+/////wAAAAABAAABAQAAAgEAAAMBAAAEAQAABQEAAP7////9/////f////3///8K AQAA/v////7////+//////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /////////////////////////1IAbwBvAHQAIABFAG4AdAByAHkAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAWAAUB//////////8DAAAABgkCAAAAAADAAAAAAAAA RgAAAAAAAAAAAAAAAABJaYJG1sUBDAEAAIAAAAAAAAAARABhAHQAYQAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAoAAgH///////////////8A AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB4AAAAABAAAAAAAAAxAFQAYQBiAGwA ZQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADgAC AQEAAAAGAAAA/////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAADx6gAA AAAAAFcAbwByAGQARABvAGMAdQBtAGUAbgB0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAaAAIBAgAAAAUAAAD/////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAACjuAAAAAAAABQBTAHUAbQBtAGEAcgB5AEkAbgBmAG8AcgBtAGEAdABpAG8AbgAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACgAAgH///////////////8AAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAD2AAAAABAAAAAAAAAFAEQAbwBjAHUAbQBlAG4AdABTAHUAbQBt AGEAcgB5AEkAbgBmAG8AcgBtAGEAdABpAG8AbgAAAAAAAAAAAAAAOAACAQQAAAD//////////wAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP4AAAAAEAAAAAAAAAEAQwBvAG0AcABP AGIAagAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAASAAIA ////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGoAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAD///////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAABAAAA/v////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /////////////////////wEA/v8DCgAA/////wYJAgAAAAAAwAAAAAAAAEYYAAAATWljcm9zb2Z0 IFdvcmQgRG9jdW1lbnQACgAAAE1TV29yZERvYwAQAAAAV29yZC5Eb2N1bWVudC44APQ5snEAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAUgBvAG8AdAAgAEUAbgB0AHIAeQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAABYABQH//////////wMAAAAGCQIAAAAAAMAAAAAAAABGAAAA AAAAAAAAAAAA8D9oKEfWxQESAQAAAAQAAAAAAABEAGEAdABhAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACgACAf///////////////wAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHgAAAAAEAAAAAAAADEAVABhAGIAbABlAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAOAAIBAQAA AAYAAAD/////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAAAPHqAAAAAAAA VwBvAHIAZABEAG8AYwB1AG0AZQBuAHQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAABoAAgECAAAABQAAAP////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAKO4AAAAAAAD////////////////////////////////9//////////////////////// ////////////EQEAAP3////+/////v////7///8QAQAA/f////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /////////////////wEAAAD+////AwAAAAQAAAAFAAAABgAAAAcAAAAIAAAACQAAAAoAAAALAAAA DAAAAA0AAAAOAAAADwAAAP7///////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ////////////////QAAAAAEAAADwAAAAAgAAAPgAAAADAAAAAAEAAAQAAABsAQAABQAAAKwBAAAH AAAA+AEAAAYAAAACAAAAFAAAAF9BZEhvY1Jldmlld0N5Y2xlSUQAAwAAAA4AAABfRW1haWxTdWJq ZWN0AAQAAAANAAAAX0F1dGhvckVtYWlsAAUAAAAYAAAAX0F1dGhvckVtYWlsRGlzcGxheU5hbWUA BgAAABkAAABfUmV2aWV3aW5nVG9vbHNTaG93bk9uY2UABwAAABwAAABfUHJldmlvdXNBZEhvY1Jl dmlld0N5Y2xlSUQAAgAAAOQEAAADAAAAiwgt9x8AAAAyAAAAZAByAGEAZgB0AC0AYgBlAHIAbgBz AHQAZQBpAG4ALQBjAGMAYQBtAHAALQBnAG0AcABsAHMALQB2AGMAYQB0AC0AbABjAGEAcwAtADAA MQAgAGMAbwBtAG0AZQBuAHQAcwAAAB8AAAAbAAAAdwBpAGwAcwBvAG4AdABAAGEAbQBlAHIAaQBj AGEAcwBtADAAMQAuAG4AdAAuAGMAbwBtAAAAAAAfAAAAIQAAAFcAaQBsAHMAbwBuACwAIABUAHIA ZQB2AG8AcgAgAFsASQBSAEUAMAA3ADoAUQA4ADQAMAA6AEUAWABDAEgAXQAAAAAAAwAAAK6agS4A AAAAAAAAAAAAAAAFAFMAdQBtAG0AYQByAHkASQBuAGYAbwByAG0AYQB0AGkAbwBuAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAKAACAf///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAPYAAAAAEAAAAAAAAAUARABvAGMAdQBtAGUAbgB0AFMAdQBtAG0AYQByAHkA SQBuAGYAbwByAG0AYQB0AGkAbwBuAAAAAAAAAAAAAAA4AAIBBAAAAP//////////AAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAAHQDAAAAAAAAAQBDAG8AbQBwAE8AYgBqAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABIAAgD///////// //////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAagAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAP///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAEA/v8DCgAA/////wYJAgAAAAAAwAAAAAAAAEYYAAAATWljcm9zb2Z0IFdvcmQg RG9jdW1lbnQACgAAAE1TV29yZERvYwAQAAAAV29yZC5Eb2N1bWVudC44APQ5snEAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/v8AAAUAAgAAAAAAAAAAAAAAAAAAAAAAAgAAAALVzdWc LhsQk5cIACss+a5EAAAABdXN1ZwuGxCTlwgAKyz5rnQBAAAwAQAADAAAAAEAAABoAAAADwAAAHAA AAAFAAAAiAAAAAYAAACQAAAAEQAAAJgAAAAXAAAAoAAAAAsAAACoAAAAEAAAALAAAAATAAAAuAAA ABYAAADAAAAADQAAAMgAAAAMAAAAEgEAAAIAAADkBAAAHgAAABAAAABOb3J0ZWwgTmV0d29ya3MA AwAAANEAAAADAAAAOgAAAAMAAAAWcwAAAwAAAE8aCgALAAAAAAAAAAsAAAAAAAAACwAAAAAAAAAL AAAAAAAAAB4QAAABAAAAPgAAAENDQU1QIHdvcmtpbmcgR3JvdXAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIEcADBAAAAIAAAAeAAAABgAAAFRpdGxlAAMAAAABAAAAAAIA AAcAAAAAAAAAgQAAAIIAAACDAAAAhAAAAIUAAACGAAAAhwAAAIgAAACJAAAAigAAAIsAAACMAAAA jQAAAI4AAACPAAAAkAAAAJEAAACSAAAAkwAAAJQAAACVAAAAlgAAAJcAAACYAAAAmQAAAJoAAACb AAAAnAAAAJ0AAACeAAAAnwAAAKAAAAChAAAAogAAAKMAAACkAAAApQAAAKYAAACnAAAAqAAAAKkA AACqAAAAqwAAAKwAAACtAAAArgAAAK8AAACwAAAAsQAAALIAAACzAAAAtAAAALUAAAC2AAAAtwAA ALgAAAC5AAAAugAAALsAAAC8AAAAvQAAAL4AAAC/AAAAwAAAAMEAAADCAAAAwwAAAMQAAADFAAAA xgAAAMcAAADIAAAAyQAAAMoAAADLAAAAzAAAAM0AAADOAAAAzwAAANAAAADRAAAA0gAAANMAAADU AAAA1QAAANYAAADXAAAA2AAAANkAAADaAAAA2wAAANwAAADdAAAA3gAAAN8AAADgAAAA4QAAAOIA AADjAAAA5AAAAOUAAADmAAAA5wAAAOgAAADpAAAA6gAAAOsAAADsAAAA7QAAAO4AAADvAAAA8AAA APEAAADyAAAA8wAAAPQAAAD1AAAA/v////cAAAD4AAAA+QAAAPoAAAD7AAAA/AAAAP0AAAD+//// //////////8= ------_=_NextPart_001_01C5D647.2A748015-- From owner-ccamp@ops.ietf.org Fri Oct 21 11:35:51 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESyvv-0001tT-HJ for ccamp-archive@megatron.ietf.org; Fri, 21 Oct 2005 11:35:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10952 for ; Fri, 21 Oct 2005 11:35:39 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESz80-0001aU-UZ for ccamp-archive@ietf.org; Fri, 21 Oct 2005 11:48:25 -0400 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1ESynk-0006zS-QY for ccamp-data@psg.com; Fri, 21 Oct 2005 15:27:24 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [70.158.43.219] (helo=jera.movaz.com) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1ESynj-0006zG-JL for ccamp@ops.ietf.org; Fri, 21 Oct 2005 15:27:23 +0000 Received: from ib (vpn17.atlanta.movaz.com [172.18.0.17]) by jera.movaz.com (Postfix) with SMTP id 1EF614885D; Fri, 21 Oct 2005 11:27:21 -0400 (EDT) Message-ID: <007a01c5d653$ec5302e0$6601a8c0@movaz.com> From: "Igor Bryskin" To: , "Arthi Ayyangar" Cc: References: Subject: Re: I-D ACTION:draft-ietf-ccamp-inter-domain-pd-path-comp-01.txt Date: Fri, 21 Oct 2005 11:27: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 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: 2ed806e2f53ff1a061ad4f97e00345ac Content-Transfer-Encoding: 7bit Arthi, JP I have a problem with the auto-discovery mechanism you described in the draft (one that is based on query to IGP or BGP to determine outgoing ABR/ASBR). 1. Destination ID must be network unique but it does not have to be IP routable, for example, it could be a numbered link ID. 2. Even in case when destination is IP address, the path computing node can only obtain the ID of an ABR or ASBR that advertises IP route to the destination, which would be one that knows about the shortest IP path to the destination. However, it does not mean that properly constrained TE path from this ABR/ASBR to the destination or the next ABR/ASBR exist, or is not suboptimal compared to one from some other ABR/ASBR which knows about worse IP path to the destination and hence will not be reported to the computing entity by the routing sub-system. I wonder why not to use the remote PCE service for this purpose. For instance a PCC may ask a PCE to determine either the ID of the outgoing domain border node or entire path in terms of domain border nodes. You may ask why not to request explicit path(s) in this case? Several reasons why the PCC wouldn't want to do so: a) it could be easier and faster for the PCE to determine domain border node in direction towards the destination rather than explicit path(s). For instance, the latter may require cooperation of other PCEs; b) security considerations - PCE may not want to reveal remote domain topology(ies) c) it may be desirable to compute and setup services on per-domain basis, for instance, to have each domain take separate care for service restoration. What do you think? Igor ----- Original Message ----- From: To: Cc: Sent: Thursday, October 20, 2005 6:50 PM Subject: I-D ACTION:draft-ietf-ccamp-inter-domain-pd-path-comp-01.txt > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. > > Title : A Per-domain path computation method for establishing > Inter-domain Traffic Engineering (TE) Label Switched Paths (LSPs) > Author(s) : J. Vasseur, et al. > Filename : draft-ietf-ccamp-inter-domain-pd-path-comp-01.txt > Pages : 18 > Date : 2005-10-20 > > This document specifies a per-domain path computation technique for > establishing inter-domain Traffic Engineering (TE) Multiprotocol Label > Switching (MPLS) and Generalized MPLS (GMPLS) Label Switched Paths > (LSPs). In this document a domain refers to a collection of network > elements within a common sphere of address management or path > computational responsibility such as IGP areas and Autonomous Systems. > > Per-domain computation applies where the full path of an inter-domain > TE LSP cannot be or is not determined at the ingress node of the TE > LSP, and is not signaled across domain boundaries. This is most likely > to arise owing to TE visibility limitations. The signaling message > indicates the destination and nodes up to the next domain boundary. It > may also indicate further domain boundaries or domain identifiers. The > path through each domain, possibly including the choice of exit point > from the domain, must be determined within the domain. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-inter-domain-pd-path-comp-01.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-inter-domain-pd-path-comp-01.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-inter-domain-pd-path-comp-01.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. > From owner-ccamp@ops.ietf.org Fri Oct 21 13:35:57 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ET0o9-0005jd-Aq for ccamp-archive@megatron.ietf.org; Fri, 21 Oct 2005 13:35:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20643 for ; Fri, 21 Oct 2005 13:35:47 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ET103-0007AL-Ni for ccamp-archive@ietf.org; Fri, 21 Oct 2005 13:48:33 -0400 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1ET0gU-000DS0-GV for ccamp-data@psg.com; Fri, 21 Oct 2005 17:28:02 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.0 Received: from [62.241.162.32] (helo=ranger.systems.pipex.net) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1ET0gS-000DRn-70 for ccamp@ops.ietf.org; Fri, 21 Oct 2005 17:28:00 +0000 Received: from dnni.com (81-178-2-190.dsl.pipex.com [81.178.2.190]) by ranger.systems.pipex.net (Postfix) with ESMTP id 1E380E00008D; Fri, 21 Oct 2005 18:27:48 +0100 (BST) Received: from Puppy ([217.158.132.74] RDNS failed) by dnni.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 21 Oct 2005 18:25:51 +0100 Message-ID: <01a101c5d664$e4e76210$ca00470a@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Cc: "Lou Berger" , "Dimitri Papadimitriou" , "Dimitri Papadimitriou" , "Anca Zamfir" , "Reshad Rahman" , "Junaid Israr" , "Arun Satyanarayana (asatyana)" , "Kireeti Kompella" References: <434C0DFA.80102@cisco.com> <295c01c5ce9c$d0ac9b00$f2849ed9@Puppy> Subject: Re: Further Working Group last call: draft-ietf-ccamp-rsvp-restart-ext-04.txt Date: Fri, 21 Oct 2005 18:27:12 +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: 21 Oct 2005 17:25:52.0671 (UTC) FILETIME=[7CACF2F0:01C5D664] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 83867a50fd8f547996ccdaf89af24437 Content-Transfer-Encoding: 7bit Hi, This last call completed without further comment. Arun needs to make one minor format modification to appease the RFC editor and then we will pass this on to the AD. Thanks, Adrian ----- Original Message ----- From: "Adrian Farrel" To: Cc: "Lou Berger" ; "Dimitri Papadimitriou" ; "Dimitri Papadimitriou" ; "Anca Zamfir" ; "Reshad Rahman" ; "Junaid Israr" ; "Arun Satyanarayana (asatyana)" ; "Kireeti Kompella" Sent: Tuesday, October 11, 2005 8:48 PM Subject: Further Working Group last call: draft-ietf-ccamp-rsvp-restart-ext-04.txt > Thanks for the note Arun, > > It looks to me that while most of these changes are editorial, the change > to 4.5.2 is substantive. > > Therefore we will have a further short WG last call. > > The last call will complete on Wednesday 19th October at 12 noon GMT. > > Send your comments to the list please. > > Thanks, > Adrian > ----- Original Message ----- > From: "Arun Satyanarayana" > To: "Adrian Farrel" ; "Kireeti Kompella" > > Cc: ; "Lou Berger" ; "Dimitri > Papadimitriou" ; "Dimitri Papadimitriou" > ; "Anca Zamfir" ; "Reshad Rahman" > ; "Junaid Israr" ; "Arun > Satyanarayana (asatyana)" > Sent: Tuesday, October 11, 2005 8:09 PM > Subject: Re: I-D ACTION:draft-ietf-ccamp-rsvp-restart-ext-04.txt > > > > Hi Adrian, Kireeti, > > > > Following are the mods to version -03, based on last call comments. Can > > we go through another short last call on this rev please? > > > > - Section 2 Terminology: > > Fix bad text > > < The reader is assumed to be familiar with the terminology defined in > > < xref target="RFC3209" /> and [RFC3473]. > > > The reader is assumed to be familiar with the terminology defined > in > > > [RFC3209] and [RFC3473]. > > > > - Section 4.2 Capability Object: > > Reverse ordering of definitions of T and R bits to match ordering in > > object > > > > - Full I-D: > > Change "Restart_Caps" to "Restart_Cap" (to match definition in 3473). > > > > - Section 4.4.1 Procedures for the Downstream Neighbor > > Clarify text: the downstream neighbor must send the T-bit in all > > Hellos > > < If the downstream RSVP neighbor of a restarting node is capable of > > < sending RecoveryPath messages to the restarting node, it MUST > > include > > < the Capability object with the RecoveryPath Transmit Enabled (T) bit > > < set (1) in all its Hello messages sent to the restarting node. > > > If a node is capable of sending RecoveryPath messages, it MUST > > > include the Capability object with the RecoveryPath Transmit > Enabled > > > (T) bit set (1) in all its Hello messages. > > > > - Section 4.4.2 Procedures for the Restarting Node > > Clarify text: the restarting node must send the R-bit in all Hellos > > < A restarting node that expects to recover RSVP state by the receipt > > < and processing of RecoveryPath messages according to procedures > > < defined in this document, MUST include the Capability object with > the > > < RecoveryPath Desired (R) bit set (1) in its RSVP Hello messages to > > < its neighbors, during the Recovery Period. The node MUST also > > < include the Restart_Caps object as defined in [RFC3473], in all > those > > < Hello messages. > > > A node that expects to recover RSVP state by the receipt and > > > processing of RecoveryPath messages according to procedures defined > > > in this document, MUST include the Capability object with the > > > RecoveryPath Desired (R) bit set (1) in its RSVP Hello messages to > > > its neighbors. The node MUST also include the Restart_Cap object > as > > > defined in [RFC3473], in all those Hello messages. > > > > - Section 4.5.2 Procedures for the Restarting Node > > Change response to received RecoveryPath messages outside the > Recovery > > Period: > > < These procedures apply during the "state recovery process" and > > < "Recovery Period" as defined in Section 9.5.2 in [RFC3473]. Any > > < RecoveryPath message received after the Recovery Period has expired > > < MUST be discarded. If no LSP state matching the RecoveryPath > message > > < is located, the restarted node MAY send a PathTear message > > < constructed from the RecoveryPath message, to expedite the cleanup > of > > < unrecovered RSVP and associated forwarding state downstream of the > > < restarted node. > > > These procedures apply during the "state recovery process" and > > > "Recovery Period" as defined in Section 9.5.2 in [RFC3473]. Any > > > RecoveryPath message received after the Recovery Period has expired > > > SHOULD be matched against local LSP state. If matching fully > > > resynchronized state is located, the node SHOULD send a Path > message > > > downstream. If non-resynchronized or no LSP state matching the > > > RecoveryPath message is located, the restarted node MAY send a > > > PathTear message constructed from the RecoveryPath message, to > > > expedite the cleanup of unrecovered RSVP and associated forwarding > > > state downstream of the restarted node. > > > > - Section 5.2.1 Procedures > > (Srefresh mechanism), clarify text: the restarting node must send > > the R-bit in all Hellos > > < To indicate to an RSVP neighbor that selective transmission of > > < RecoveryPath messages is desired, a restarting node MUST set (1) the > > < S-bit in the Capability object in all Hello messages it sends during > > < the Recovery Period to the neighbor. When the restarting node does > > > To indicate to an RSVP neighbor that selective transmission of > > > RecoveryPath messages is desired, a node MUST set (1) the S-bit in > > > the Capability object in all Hello messages it sends. When the > > > > - Section 7. Acknowledgments > > Add Pavan Beeram. > > > > - Section 8. IANA Considerations > > Suggest values for the RecoveryPath msg and the Capability object > > < A new RSVP object using a Class-Number of form 10bbbbbb called the > > < Capability Object is defined in Section 4.2 in this document. The > > < Class-Number is TBA by IANA. > > > A new RSVP object using a Class-Number of form 10bbbbbb called the > > > Capability Object is defined in Section 4.2 in this document. The > > > Class-Number is TBA by IANA. A value of 132 is suggested. > > > > < A new RSVP message type called a RecoveryPath message is defined in > > < Section 4.1 of this document. The RSVP message type is TBA by IANA. > > > A new RSVP message type called a RecoveryPath message is defined in > > > Section 4.1 of this document. The RSVP message type is TBA by > IANA. > > > A value of 30 is suggested. > > > > - Section 8. IANA Considerations > > Fix typo in the bit names > > < +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > < | |S|P|R| > > < +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | |T|R|S| > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > Thanks, > > Arun (and co-authors) > > ============================================================== > > -------- Original Message -------- > > Subject: I-D ACTION:draft-ietf-ccamp-rsvp-restart-ext-04.txt > > Date: Mon, 03 Oct 2005 15:50:02 -0400 > > From: Internet-Drafts@ietf.org > > To: i-d-announce@ietf.org > > CC: ccamp@ops.ietf.org > > > > 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 GMPLS RSVP Graceful Restart > > Author(s) : A. Satyanarayana, et al. > > Filename : draft-ietf-ccamp-rsvp-restart-ext-04.txt > > Pages : 24 > > Date : 2005-10-3 > > > > This document describes extensions to the RSVP Graceful Restart > > mechanisms defined in RFC 3473. The extensions enable the recovery > > of RSVP signaling state based on the Path message last sent by the > > node being restarted. Previously defined Graceful Restart > > mechanisms, also called recovery from nodal faults, permit recovery > > of signaling state from adjacent nodes when the data plane has > > retained the associated forwarding state across a restart. These > > mechanisms do not fully support signaling state recovery on ingress > > nodes or recovery of all RSVP objects. The presented extensions use > > the RSVP Hello extensions defined in RFC 3209, and extensions for > > state recovery on nodal faults defined in RFC 3473. With the > > presented extensions the restarting node can recover all previously > > transmitted Path state including the Explicit Route Object and the > > downstream (outgoing) interface identifiers. The extensions can > also > > be used to recover signaling state after the restart of an ingress > > node. The extensions optionally support the use of Summary Refresh, > > defined in RFC 2961, to reduce the number of messages exchanged > > during the Recovery Phase when the restarting node has recovered > > signaling state locally for one or more LSPs. > > > > A URL for this Internet-Draft is: > > > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rsvp-restart-ext-04.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-rsvp-restart-ext-04.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-rsvp-restart-ext-04.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. > > > > > > > > > > From owner-ccamp@ops.ietf.org Fri Oct 21 14:28:15 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ET1cl-0005Hz-Rf for ccamp-archive@megatron.ietf.org; Fri, 21 Oct 2005 14:28:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24028 for ; Fri, 21 Oct 2005 14:28:05 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ET1ox-0000oA-8k for ccamp-archive@ietf.org; Fri, 21 Oct 2005 14:40:51 -0400 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1ET1XF-000GLQ-Gs for ccamp-data@psg.com; Fri, 21 Oct 2005 18:22:33 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.0 Received: from [62.241.162.32] (helo=ranger.systems.pipex.net) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1ET1XD-000GLD-Th for ccamp@ops.ietf.org; Fri, 21 Oct 2005 18:22:32 +0000 Received: from dnni.com (81-178-2-190.dsl.pipex.com [81.178.2.190]) by ranger.systems.pipex.net (Postfix) with ESMTP id CB027E0002DC; Fri, 21 Oct 2005 19:22:13 +0100 (BST) Received: from Puppy ([217.158.132.74] RDNS failed) by dnni.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 21 Oct 2005 19:18:24 +0100 Message-ID: <028501c5d66c$3d075570$ca00470a@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Igor Bryskin" , , "Arthi Ayyangar" Cc: References: <007a01c5d653$ec5302e0$6601a8c0@movaz.com> Subject: Re: I-D ACTION:draft-ietf-ccamp-inter-domain-pd-path-comp-01.txt Date: Fri, 21 Oct 2005 19:20:30 +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: 21 Oct 2005 18:18:25.0830 (UTC) FILETIME=[D41AD460:01C5D66B] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 311e798ce51dbeacf5cdfcc8e9fda21b Content-Transfer-Encoding: 7bit Hi Igor, I think you have to set the context of this I-D carefully, and then understand the limited scope that is additionally proposed. The context of the I-D is limited to the per-domain computation case. Hence, consulting an external PCE is out of scope. This is not to say that it is not valid to consult a PCE (in fact, you might expect JP and me to support that technique), but this I-D is demonstrating what we can do and how we can solve the problem without using PCE. With respect to the use of the IP reachability, you may recall that I raised this concern in Paris and on the list. The conclusion was that if you have no other way of determining an exit router for your domain, then attempting to use the IP reachability is no worse than giving up, and may be much better. In the cases you raise: 1. Yes, an interface address may be unreachable. Do we lose anything by consulting IP reachability in this case? No. 2. Yes, the IP reachability may give us a sub-optimal TE path. Is this path worse than no path? No. So I asked the authors to be clear that what they are suggesting has limitations, and should not be applied in some specific cases. I haven't looked at the text yet, but I hope they have covered this. Cheers, Adrian ----- Original Message ----- From: "Igor Bryskin" To: ; "Arthi Ayyangar" Cc: Sent: Friday, October 21, 2005 4:27 PM Subject: Re: I-D ACTION:draft-ietf-ccamp-inter-domain-pd-path-comp-01.txt > Arthi, JP > > > > I have a problem with the auto-discovery mechanism you described in the > draft (one that is based on query to IGP or BGP to determine outgoing > ABR/ASBR). > > > > 1. Destination ID must be network unique but it does not have to be IP > routable, for example, it could be a numbered link ID. > > 2. Even in case when destination is IP address, the path computing node can > only obtain the ID of an ABR or ASBR that advertises IP route to the > destination, which would be one that knows about the shortest IP path to the > destination. However, it does not mean that properly constrained TE path > from this ABR/ASBR to the destination or the next ABR/ASBR exist, or is not > suboptimal compared to one from some other ABR/ASBR which knows about worse > IP path to the destination and hence will not be reported to the computing > entity by the routing sub-system. > > > > I wonder why not to use the remote PCE service for this purpose. For > instance a PCC may ask a PCE to determine either the ID of the outgoing > domain border node or entire path in terms of domain border nodes. You may > ask why not to request explicit path(s) in this case? Several reasons why > the PCC wouldn't want to do so: > > > > a) it could be easier and faster for the PCE to determine domain border node > in direction towards the destination rather than explicit path(s). For > instance, the latter may require cooperation of other PCEs; > > > > b) security considerations - PCE may not want to reveal remote domain > topology(ies) > > > > c) it may be desirable to compute and setup services on per-domain basis, > for instance, to have each domain take separate care for service > restoration. > > > > What do you think? > > > > Igor > > > > ----- Original Message ----- > > From: > > To: > > Cc: > > Sent: Thursday, October 20, 2005 6:50 PM > > Subject: I-D ACTION:draft-ietf-ccamp-inter-domain-pd-path-comp-01.txt > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > This draft is a work item of the Common Control and Measurement Plane > Working Group of the IETF. > > > > Title : A Per-domain path computation method for establishing > > Inter-domain Traffic Engineering (TE) Label > Switched Paths (LSPs) > > Author(s) : J. Vasseur, et al. > > Filename : draft-ietf-ccamp-inter-domain-pd-path-comp-01.txt > > Pages : 18 > > Date : 2005-10-20 > > > > This document specifies a per-domain path computation technique for > > establishing inter-domain Traffic Engineering (TE) Multiprotocol Label > > Switching (MPLS) and Generalized MPLS (GMPLS) Label Switched Paths > > (LSPs). In this document a domain refers to a collection of network > > elements within a common sphere of address management or path > > computational responsibility such as IGP areas and Autonomous Systems. > > > > Per-domain computation applies where the full path of an inter-domain > > TE LSP cannot be or is not determined at the ingress node of the TE > > LSP, and is not signaled across domain boundaries. This is most likely > > to arise owing to TE visibility limitations. The signaling message > > indicates the destination and nodes up to the next domain boundary. It > > may also indicate further domain boundaries or domain identifiers. The > > path through each domain, possibly including the choice of exit point > > from the domain, must be determined within the domain. > > > > A URL for this Internet-Draft is: > > > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-inter-domain-pd-path-comp-01.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-inter-domain-pd-path-comp-01.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-inter-domain-pd-path-comp-01.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. > > > > > > From owner-ccamp@ops.ietf.org Fri Oct 21 14:40:17 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ET1oP-0002S7-53 for ccamp-archive@megatron.ietf.org; Fri, 21 Oct 2005 14:40:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24778 for ; Fri, 21 Oct 2005 14:40:06 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ET20b-0001IB-45 for ccamp-archive@ietf.org; Fri, 21 Oct 2005 14:52:53 -0400 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1ET1g3-000Gt2-8A for ccamp-data@psg.com; Fri, 21 Oct 2005 18:31:39 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [70.158.43.219] (helo=jera.movaz.com) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1ET1g1-000Gsp-PA for ccamp@ops.ietf.org; Fri, 21 Oct 2005 18:31:38 +0000 Received: from ib (vpn23.atlanta.movaz.com [172.18.0.23]) by jera.movaz.com (Postfix) with SMTP id BF78A3AA9B; Fri, 21 Oct 2005 14:31:35 -0400 (EDT) Message-ID: <00cf01c5d66d$a8af7ea0$6601a8c0@movaz.com> From: "Igor Bryskin" To: "Adrian Farrel" , , "Arthi Ayyangar" Cc: References: <007a01c5d653$ec5302e0$6601a8c0@movaz.com> <028501c5d66c$3d075570$ca00470a@Puppy> Subject: Re: I-D ACTION:draft-ietf-ccamp-inter-domain-pd-path-comp-01.txt Date: Fri, 21 Oct 2005 14:31:30 -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: 76c7db407a166e4c39f35d8215d8dd32 Content-Transfer-Encoding: 7bit Adrian, I understand and agree with what you are saying. My point was that a) when PCE is available, the PCE service could be a better way for determining the outgoing domain border node, and b) per-domain path computation could be useful even when you have PCE service available. In other words I was just suggesting an alternative method for per-domain path computation, that's all. Igor ----- Original Message ----- From: "Adrian Farrel" To: "Igor Bryskin" ; ; "Arthi Ayyangar" Cc: Sent: Friday, October 21, 2005 2:20 PM Subject: Re: I-D ACTION:draft-ietf-ccamp-inter-domain-pd-path-comp-01.txt > Hi Igor, > > I think you have to set the context of this I-D carefully, and then > understand the limited scope that is additionally proposed. > > The context of the I-D is limited to the per-domain computation case. > Hence, consulting an external PCE is out of scope. This is not to say that > it is not valid to consult a PCE (in fact, you might expect JP and me to > support that technique), but this I-D is demonstrating what we can do and > how we can solve the problem without using PCE. > > With respect to the use of the IP reachability, you may recall that I > raised this concern in Paris and on the list. The conclusion was that if > you have no other way of determining an exit router for your domain, then > attempting to use the IP reachability is no worse than giving up, and may > be much better. > > In the cases you raise: > 1. Yes, an interface address may be unreachable. > Do we lose anything by consulting IP reachability in this case? > No. > 2. Yes, the IP reachability may give us a sub-optimal TE path. > Is this path worse than no path? > No. > > So I asked the authors to be clear that what they are suggesting has > limitations, and should not be applied in some specific cases. I haven't > looked at the text yet, but I hope they have covered this. > > Cheers, > Adrian > ----- Original Message ----- > From: "Igor Bryskin" > To: ; "Arthi Ayyangar" > Cc: > Sent: Friday, October 21, 2005 4:27 PM > Subject: Re: I-D ACTION:draft-ietf-ccamp-inter-domain-pd-path-comp-01.txt > > > > Arthi, JP > > > > > > > > I have a problem with the auto-discovery mechanism you described in the > > draft (one that is based on query to IGP or BGP to determine outgoing > > ABR/ASBR). > > > > > > > > 1. Destination ID must be network unique but it does not have to be IP > > routable, for example, it could be a numbered link ID. > > > > 2. Even in case when destination is IP address, the path computing node > can > > only obtain the ID of an ABR or ASBR that advertises IP route to the > > destination, which would be one that knows about the shortest IP path to > the > > destination. However, it does not mean that properly constrained TE path > > from this ABR/ASBR to the destination or the next ABR/ASBR exist, or is > not > > suboptimal compared to one from some other ABR/ASBR which knows about > worse > > IP path to the destination and hence will not be reported to the > computing > > entity by the routing sub-system. > > > > > > > > I wonder why not to use the remote PCE service for this purpose. For > > instance a PCC may ask a PCE to determine either the ID of the outgoing > > domain border node or entire path in terms of domain border nodes. You > may > > ask why not to request explicit path(s) in this case? Several reasons > why > > the PCC wouldn't want to do so: > > > > > > > > a) it could be easier and faster for the PCE to determine domain border > node > > in direction towards the destination rather than explicit path(s). For > > instance, the latter may require cooperation of other PCEs; > > > > > > > > b) security considerations - PCE may not want to reveal remote domain > > topology(ies) > > > > > > > > c) it may be desirable to compute and setup services on per-domain > basis, > > for instance, to have each domain take separate care for service > > restoration. > > > > > > > > What do you think? > > > > > > > > Igor > > > > > > > > ----- Original Message ----- > > > > From: > > > > To: > > > > Cc: > > > > Sent: Thursday, October 20, 2005 6:50 PM > > > > Subject: I-D ACTION:draft-ietf-ccamp-inter-domain-pd-path-comp-01.txt > > > > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > > This draft is a work item of the Common Control and Measurement Plane > > Working Group of the IETF. > > > > > > Title : A Per-domain path computation method for establishing > > > Inter-domain Traffic Engineering (TE) Label > > Switched Paths (LSPs) > > > Author(s) : J. Vasseur, et al. > > > Filename : draft-ietf-ccamp-inter-domain-pd-path-comp-01.txt > > > Pages : 18 > > > Date : 2005-10-20 > > > > > > This document specifies a per-domain path computation technique for > > > establishing inter-domain Traffic Engineering (TE) Multiprotocol Label > > > Switching (MPLS) and Generalized MPLS (GMPLS) Label Switched Paths > > > (LSPs). In this document a domain refers to a collection of network > > > elements within a common sphere of address management or path > > > computational responsibility such as IGP areas and Autonomous Systems. > > > > > > Per-domain computation applies where the full path of an inter-domain > > > TE LSP cannot be or is not determined at the ingress node of the TE > > > LSP, and is not signaled across domain boundaries. This is most likely > > > to arise owing to TE visibility limitations. The signaling message > > > indicates the destination and nodes up to the next domain boundary. It > > > may also indicate further domain boundaries or domain identifiers. The > > > path through each domain, possibly including the choice of exit point > > > from the domain, must be determined within the domain. > > > > > > A URL for this Internet-Draft is: > > > > > > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-inter-domain-pd-path-comp-01.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-inter-domain-pd-path-comp-01.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-inter-domain-pd-path-comp-01.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. > > > > > > > > > > > > From owner-ccamp@ops.ietf.org Fri Oct 21 16:07:28 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ET3Ak-0005pE-Rc for ccamp-archive@megatron.ietf.org; Fri, 21 Oct 2005 16:07:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07079 for ; Fri, 21 Oct 2005 16:07:15 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ET3Mk-0007IA-Qk for ccamp-archive@ietf.org; Fri, 21 Oct 2005 16:19:51 -0400 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1ET331-000Llf-6f for ccamp-data@psg.com; Fri, 21 Oct 2005 19:59:27 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [70.158.43.219] (helo=jera.movaz.com) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1ET32z-000LlC-SA for ccamp@ops.ietf.org; Fri, 21 Oct 2005 19:59:26 +0000 Received: from ib (vpn20.atlanta.movaz.com [172.18.0.20]) by jera.movaz.com (Postfix) with SMTP id AF2232E669; Fri, 21 Oct 2005 15:59:23 -0400 (EDT) Message-ID: <010201c5d679$ec6f9650$6601a8c0@movaz.com> From: "Igor Bryskin" To: "Adrian Farrel" , , "Arthi Ayyangar" Cc: References: <007a01c5d653$ec5302e0$6601a8c0@movaz.com> <028501c5d66c$3d075570$ca00470a@Puppy> Subject: Re: I-D ACTION:draft-ietf-ccamp-inter-domain-pd-path-comp-01.txt Date: Fri, 21 Oct 2005 15:59:18 -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: bfe538a859d88717fa3c8a6377d62f90 Content-Transfer-Encoding: 7bit Adrian, On a closer look: > In the cases you raise: > 1. Yes, an interface address may be unreachable. > Do we lose anything by consulting IP reachability in this case? > No. This is not what I was talking about, which was a destination located in some remote domain and TE reachable to the source while not IP routable (because destination is a numbered link ID, this is a very usual case in a multi-area GMPLS non-packet network). The only guy who would know about such destination is a PCE with sufficient TE visibility. There is no point in such case to consult IP routing and we do loose by doing so rather than consulting PCE (provided, of course, that PCE is available) > 2. Yes, the IP reachability may give us a sub-optimal TE path. > Is this path worse than no path? > No. Again, the path provided by IP has nothing to do with the TE path, and PCE is certainly in a better position to provide (albeit loose) path specifying a list of proper border nodes or just the next border node. The bottom line: when PCE is available one should never consult IP routing to determine the outgoing border node when one performs per-domain path computation. If PCE is not available, than in case of IP network, I agree, there is a value to consult IP routing. This is because in IP world TE resources are still tightly coupled with IP interfaces. In the non-IP world, I'd say, consulting IP routing makes much lesser sense: it could give you a path when no TE path exists or, more importantly, fail the request when one or more TE paths do exist. I'd suggest in this case rather than consulting IP (which is as useful IMO as consulting somebody's Outlook address book) to route the LSP towards any known domain border node and hope that the latter will crankback the request specifying the proper border node if necessary. Cheers, Igor ----- Original Message ----- From: "Adrian Farrel" To: "Igor Bryskin" ; ; "Arthi Ayyangar" Cc: Sent: Friday, October 21, 2005 2:20 PM Subject: Re: I-D ACTION:draft-ietf-ccamp-inter-domain-pd-path-comp-01.txt > Hi Igor, > > I think you have to set the context of this I-D carefully, and then > understand the limited scope that is additionally proposed. > > The context of the I-D is limited to the per-domain computation case. > Hence, consulting an external PCE is out of scope. This is not to say that > it is not valid to consult a PCE (in fact, you might expect JP and me to > support that technique), but this I-D is demonstrating what we can do and > how we can solve the problem without using PCE. > > With respect to the use of the IP reachability, you may recall that I > raised this concern in Paris and on the list. The conclusion was that if > you have no other way of determining an exit router for your domain, then > attempting to use the IP reachability is no worse than giving up, and may > be much better. > > In the cases you raise: > 1. Yes, an interface address may be unreachable. > Do we lose anything by consulting IP reachability in this case? > No. > 2. Yes, the IP reachability may give us a sub-optimal TE path. > Is this path worse than no path? > No. > > So I asked the authors to be clear that what they are suggesting has > limitations, and should not be applied in some specific cases. I haven't > looked at the text yet, but I hope they have covered this. > > Cheers, > Adrian > ----- Original Message ----- > From: "Igor Bryskin" > To: ; "Arthi Ayyangar" > Cc: > Sent: Friday, October 21, 2005 4:27 PM > Subject: Re: I-D ACTION:draft-ietf-ccamp-inter-domain-pd-path-comp-01.txt > > > > Arthi, JP > > > > > > > > I have a problem with the auto-discovery mechanism you described in the > > draft (one that is based on query to IGP or BGP to determine outgoing > > ABR/ASBR). > > > > > > > > 1. Destination ID must be network unique but it does not have to be IP > > routable, for example, it could be a numbered link ID. > > > > 2. Even in case when destination is IP address, the path computing node > can > > only obtain the ID of an ABR or ASBR that advertises IP route to the > > destination, which would be one that knows about the shortest IP path to > the > > destination. However, it does not mean that properly constrained TE path > > from this ABR/ASBR to the destination or the next ABR/ASBR exist, or is > not > > suboptimal compared to one from some other ABR/ASBR which knows about > worse > > IP path to the destination and hence will not be reported to the > computing > > entity by the routing sub-system. > > > > > > > > I wonder why not to use the remote PCE service for this purpose. For > > instance a PCC may ask a PCE to determine either the ID of the outgoing > > domain border node or entire path in terms of domain border nodes. You > may > > ask why not to request explicit path(s) in this case? Several reasons > why > > the PCC wouldn't want to do so: > > > > > > > > a) it could be easier and faster for the PCE to determine domain border > node > > in direction towards the destination rather than explicit path(s). For > > instance, the latter may require cooperation of other PCEs; > > > > > > > > b) security considerations - PCE may not want to reveal remote domain > > topology(ies) > > > > > > > > c) it may be desirable to compute and setup services on per-domain > basis, > > for instance, to have each domain take separate care for service > > restoration. > > > > > > > > What do you think? > > > > > > > > Igor > > > > > > > > ----- Original Message ----- > > > > From: > > > > To: > > > > Cc: > > > > Sent: Thursday, October 20, 2005 6:50 PM > > > > Subject: I-D ACTION:draft-ietf-ccamp-inter-domain-pd-path-comp-01.txt > > > > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > > This draft is a work item of the Common Control and Measurement Plane > > Working Group of the IETF. > > > > > > Title : A Per-domain path computation method for establishing > > > Inter-domain Traffic Engineering (TE) Label > > Switched Paths (LSPs) > > > Author(s) : J. Vasseur, et al. > > > Filename : draft-ietf-ccamp-inter-domain-pd-path-comp-01.txt > > > Pages : 18 > > > Date : 2005-10-20 > > > > > > This document specifies a per-domain path computation technique for > > > establishing inter-domain Traffic Engineering (TE) Multiprotocol Label > > > Switching (MPLS) and Generalized MPLS (GMPLS) Label Switched Paths > > > (LSPs). In this document a domain refers to a collection of network > > > elements within a common sphere of address management or path > > > computational responsibility such as IGP areas and Autonomous Systems. > > > > > > Per-domain computation applies where the full path of an inter-domain > > > TE LSP cannot be or is not determined at the ingress node of the TE > > > LSP, and is not signaled across domain boundaries. This is most likely > > > to arise owing to TE visibility limitations. The signaling message > > > indicates the destination and nodes up to the next domain boundary. It > > > may also indicate further domain boundaries or domain identifiers. The > > > path through each domain, possibly including the choice of exit point > > > from the domain, must be determined within the domain. > > > > > > A URL for this Internet-Draft is: > > > > > > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-inter-domain-pd-path-comp-01.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-inter-domain-pd-path-comp-01.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-inter-domain-pd-path-comp-01.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. > > > > > > > > > > > > From info@mail.swkds.com Fri Oct 21 18:47:12 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ET5fL-0004ld-RJ for ccamp-archive@megatron.ietf.org; Fri, 21 Oct 2005 18:47:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23068 for ; Fri, 21 Oct 2005 18:46:59 -0400 (EDT) Received: from [58.180.217.149] (helo=mail.swkds.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ET5rX-00016S-Mo for ccamp-archive@ietf.org; Fri, 21 Oct 2005 18:59:50 -0400 Received: (qmail 11347 invoked by uid 509); 22 Oct 2005 00:44:56 +0900 Date: 22 Oct 2005 00:44:56 +0900 Message-ID: <20051021154456.11346.qmail@mail.swkds.com> From: info@swkds.com To: ccamp-archive@ietf.org Subject: $BFMA3$9$_$^$;$s!#;d$N:J$rHH$7$F2<$5$$(B X-Spam-Score: 3.5 (+++) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a $B@8;`$K4X$o$k;v0U30A4$F#O#K(B $B;d$K8+$;$FD:$1$l$P!"8fNi$H$7$F#1#0K|1_:9$7>e$2$^$9(B $B$4O"MmD:$$$?;~!"4JC1$J7W2h$r$*OC$7$5$;$FD:$-$^$9!#(B $B>0!"ET9g>e$3$A$i$N%5%$%HFb$r;HMQ$7$FO"Mm$r; Fri, 21 Oct 2005 18:49:12 -0400 (EDT) Received: from [58.180.217.62] (helo=mail.ssaas.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ET5ti-0001Aw-Jk for ccamp-archive@ietf.org; Fri, 21 Oct 2005 19:02:03 -0400 Received: (qmail 29427 invoked by uid 509); 22 Oct 2005 01:46:43 +0900 Date: 22 Oct 2005 01:46:43 +0900 Message-ID: <20051021164643.29426.qmail@mail.ssaas.com> From: info@ssaas.com To: ccamp-archive@ietf.org Subject: $B9%$-$J;~$K3Z$7$/$K2T$0!*!*(B X-Spam-Score: 3.5 (+++) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 $B'X'X'X'X'X'X'X'X'X'X'X'X'X'X'X'X'X'X'X'X'X'X'X'X'X'X'X'X'X'X'X'X'X'X'X'X'X'X'X'X(B http://awg.webchu.com/gyakuten/?baito $B3X@8$5$s$b!u%Y%F%i%s$5$s$b!u2q; Sat, 22 Oct 2005 04:11:18 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ETEfi-0005Cs-Jm for ccamp-archive@ietf.org; Sat, 22 Oct 2005 04:24:13 -0400 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1ETEK7-000ADW-Vv for ccamp-data@psg.com; Sat, 22 Oct 2005 08:01:51 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [213.46.243.15] (helo=amsfep17-int.chello.nl) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1ETEK6-000ADJ-La for ccamp@ops.ietf.org; Sat, 22 Oct 2005 08:01:51 +0000 Received: from [192.168.1.4] (really [24.132.27.149]) by amsfep17-int.chello.nl (InterMail vM.6.01.04.04 201-2131-118-104-20050224) with ESMTP id <20051022080132.WYUF6138.amsfep17-int.chello.nl@[192.168.1.4]>; Sat, 22 Oct 2005 10:01:32 +0200 Message-ID: <4359F1DB.1010504@chello.nl> Date: Sat, 22 Oct 2005 10:01:31 +0200 From: Huub van Helvoort User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ccamp@ops.ietf.org CC: tsg15q11@itu.int, tsg15q9@itu.int Subject: Re: draft-bernstein-ccamp-gmpls-vcat-lcas-01 comments References: <43595C77.4090805@chello.nl> In-Reply-To: <43595C77.4090805@chello.nl> 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.1 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit Hello Greg et al, One additional comment: Depending on the level of detail to be provided in this document. In section 2.4 VCAT configuration with LCAS (MI_LCASEnable=true) The value of Xm is not only technology dependent, it can also be implementation dependent. E.g. in a routerinterface with STM-64 line rate for a VC-4-Xv based VCG Xm = 64 and not 256. Xm cannot be provisioned, it can be retreived from the VCG (as well as Xa). Have a nice weekend, Huub. -- ================================================================ http://members.chello.nl/hhelvoort/ ================================================================ Always remember that you are unique...just like everyone else... From owner-ccamp@ops.ietf.org Sat Oct 22 05:30:21 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETFhl-0002MS-6h for ccamp-archive@megatron.ietf.org; Sat, 22 Oct 2005 05:30:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28283 for ; Sat, 22 Oct 2005 05:30:09 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ETFty-0007ZS-RZ for ccamp-archive@ietf.org; Sat, 22 Oct 2005 05:43:05 -0400 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1ETFcE-000F6w-Lj for ccamp-data@psg.com; Sat, 22 Oct 2005 09:24:38 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [213.46.243.17] (helo=amsfep20-int.chello.nl) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1ETFcD-000F6h-E3 for ccamp@ops.ietf.org; Sat, 22 Oct 2005 09:24:37 +0000 Received: from [192.168.1.4] (really [24.132.27.149]) by amsfep20-int.chello.nl (InterMail vM.6.01.04.04 201-2131-118-104-20050224) with ESMTP id <20051022092424.APE1323.amsfep20-int.chello.nl@[192.168.1.4]>; Sat, 22 Oct 2005 11:24:24 +0200 Message-ID: <435A0545.5000902@chello.nl> Date: Sat, 22 Oct 2005 11:24:21 +0200 From: Huub van Helvoort User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ccamp@ops.ietf.org Subject: Re: draft-bernstein-ccamp-gmpls-vcat-lcas-01 comments - delay References: <43595C77.4090805@chello.nl> <4359F1DB.1010504@chello.nl> In-Reply-To: <4359F1DB.1010504@chello.nl> 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.1 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit FYI, before sending the email quoted below I already did send two other emails, one with comments and the other with the forgotten attachment. Without the attachment the comment below is worthless. Sofar these messages have not appeared on the ccamp list (but they did on the SG15/Q9 and SG15/Q11 lists). So maybe they are in the ccamp spam-trap. If they do not re-appear soon I will repost them. Sorry for the inconvenience. regards, Huub. =============================================================== Huub van Helvoort wrote: > Hello Greg et al, > > One additional comment: > > Depending on the level of detail to be provided in this document. > > In section 2.4 VCAT configuration with LCAS (MI_LCASEnable=true) > > The value of Xm is not only technology dependent, it can also be > implementation dependent. E.g. in a routerinterface with STM-64 > line rate for a VC-4-Xv based VCG Xm = 64 and not 256. > Xm cannot be provisioned, it can be retreived from the VCG > (as well as Xa). > > Have a nice weekend, Huub. > -- ================================================================ http://members.chello.nl/hhelvoort/ ================================================================ Always remember that you are unique...just like everyone else... From owner-ccamp@ops.ietf.org Sat Oct 22 17:17:47 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETQkN-0000Sc-3t for ccamp-archive@megatron.ietf.org; Sat, 22 Oct 2005 17:17:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00124 for ; Sat, 22 Oct 2005 17:17:35 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ETQwl-0005Lp-3N for ccamp-archive@ietf.org; Sat, 22 Oct 2005 17:30:37 -0400 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1ETQY1-00099D-QE for ccamp-data@psg.com; Sat, 22 Oct 2005 21:05:01 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-5.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from localhost ([127.0.0.1]) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1ETQXz-00098B-S8; Sat, 22 Oct 2005 21:05:00 +0000 Message-ID: <435AA948.8070409@psg.com> Date: Sat, 22 Oct 2005 23:04:08 +0200 From: dimitri papadimitriou Reply-To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.11) Gecko/20050728 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Adrian Farrel CC: Igor Bryskin , jpv@cisco.com, Arthi Ayyangar , ccamp@ops.ietf.org Subject: Re: I-D ACTION:draft-ietf-ccamp-inter-domain-pd-path-comp-01.txt References: <007a01c5d653$ec5302e0$6601a8c0@movaz.com> <028501c5d66c$3d075570$ca00470a@Puppy> In-Reply-To: <028501c5d66c$3d075570$ca00470a@Puppy> 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: 83867a50fd8f547996ccdaf89af24437 Content-Transfer-Encoding: 7bit hi, i have specific comments - on the kernel section of this document (starting at section 4) " - If the domain is PSC (Packet Switch Capable) and uses in-band control channel " which domain ? and how to ensure the sequence of domains to reach the "next-hop" are satisfying this constraint ? "If the next-hop is reachable, then it SHOULD find a domain boundary LSR (domain boundary point) to get to the next-hop. The determination of domain boundary point based on routing information is what we term as "auto-discovery" in this document. In the absence of such an auto-discovery mechanism, a) the ABR in the case of inter-area TE or the ASBR in the next-hop AS in the case of inter-AS TE should be the signaled loose next-hop in the ERO and hence should be accessible via the TED" i don't understand the "the signaled loose next-hop in the ERO and hence should be accessible via the TED" would it be possible to clarify ? i have some troubles to understand the sentence: the ingress ASBR receives a ERO being e.g. a collection of ASs and then performs expansion e.g. strict route until the head-end ABR and then loose-hop until the tail-end ASBR within that AS but the latter will not necessarily be in the TED; still the procedure works this is classical loose routing; hence, the process shall be defined such as being recursive, and the "signaled loose next-hop" must be process as the initial "non-TE reachable but IP reachable next-hop" by the head-end ABR receiving the incoming ERO on the other side, what is the specific "auto-discovery" mechanism ? and what is the "domain boundary point" ? the concern i have here is that the default loose routing case appears like the particular case when not delivering a mechanism which is not specified ? the document should be constructed such that the process can provide BASE loose routing computation (local domain strict routing based on TE information and loose routing based on IP reachability) and allow for accommodating additional mechanism (and so information) when possible not the other way around; thanks for clarifying, ps: what the purpose of sections 3.2, 3.3, 4.1, and 4.2 ? - dimitri. Adrian Farrel wrote: > Hi Igor, > > I think you have to set the context of this I-D carefully, and then > understand the limited scope that is additionally proposed. > > The context of the I-D is limited to the per-domain computation case. > Hence, consulting an external PCE is out of scope. This is not to say that > it is not valid to consult a PCE (in fact, you might expect JP and me to > support that technique), but this I-D is demonstrating what we can do and > how we can solve the problem without using PCE. > > With respect to the use of the IP reachability, you may recall that I > raised this concern in Paris and on the list. The conclusion was that if > you have no other way of determining an exit router for your domain, then > attempting to use the IP reachability is no worse than giving up, and may > be much better. > > In the cases you raise: > 1. Yes, an interface address may be unreachable. > Do we lose anything by consulting IP reachability in this case? > No. > 2. Yes, the IP reachability may give us a sub-optimal TE path. > Is this path worse than no path? > No. > > So I asked the authors to be clear that what they are suggesting has > limitations, and should not be applied in some specific cases. I haven't > looked at the text yet, but I hope they have covered this. > > Cheers, > Adrian > ----- Original Message ----- > From: "Igor Bryskin" > To: ; "Arthi Ayyangar" > Cc: > Sent: Friday, October 21, 2005 4:27 PM > Subject: Re: I-D ACTION:draft-ietf-ccamp-inter-domain-pd-path-comp-01.txt > > > >>Arthi, JP >> >> >> >>I have a problem with the auto-discovery mechanism you described in the >>draft (one that is based on query to IGP or BGP to determine outgoing >>ABR/ASBR). >> >> >> >>1. Destination ID must be network unique but it does not have to be IP >>routable, for example, it could be a numbered link ID. >> >>2. Even in case when destination is IP address, the path computing node > > can > >>only obtain the ID of an ABR or ASBR that advertises IP route to the >>destination, which would be one that knows about the shortest IP path to > > the > >>destination. However, it does not mean that properly constrained TE path >>from this ABR/ASBR to the destination or the next ABR/ASBR exist, or is > > not > >>suboptimal compared to one from some other ABR/ASBR which knows about > > worse > >>IP path to the destination and hence will not be reported to the > > computing > >>entity by the routing sub-system. >> >> >> >>I wonder why not to use the remote PCE service for this purpose. For >>instance a PCC may ask a PCE to determine either the ID of the outgoing >>domain border node or entire path in terms of domain border nodes. You > > may > >>ask why not to request explicit path(s) in this case? Several reasons > > why > >>the PCC wouldn't want to do so: >> >> >> >>a) it could be easier and faster for the PCE to determine domain border > > node > >>in direction towards the destination rather than explicit path(s). For >>instance, the latter may require cooperation of other PCEs; >> >> >> >>b) security considerations - PCE may not want to reveal remote domain >>topology(ies) >> >> >> >>c) it may be desirable to compute and setup services on per-domain > > basis, > >>for instance, to have each domain take separate care for service >>restoration. >> >> >> >>What do you think? >> >> >> >>Igor >> >> >> >>----- Original Message ----- >> >>From: >> >>To: >> >>Cc: >> >>Sent: Thursday, October 20, 2005 6:50 PM >> >>Subject: I-D ACTION:draft-ietf-ccamp-inter-domain-pd-path-comp-01.txt >> >> >> >> >>>A New Internet-Draft is available from the on-line Internet-Drafts >> >>directories. >> >>>This draft is a work item of the Common Control and Measurement Plane >> >>Working Group of the IETF. >> >>>Title : A Per-domain path computation method for establishing >>> Inter-domain Traffic Engineering (TE) Label >> >>Switched Paths (LSPs) >> >>>Author(s) : J. Vasseur, et al. >>>Filename : draft-ietf-ccamp-inter-domain-pd-path-comp-01.txt >>>Pages : 18 >>>Date : 2005-10-20 >>> >>>This document specifies a per-domain path computation technique for >>>establishing inter-domain Traffic Engineering (TE) Multiprotocol Label >>>Switching (MPLS) and Generalized MPLS (GMPLS) Label Switched Paths >>>(LSPs). In this document a domain refers to a collection of network >>>elements within a common sphere of address management or path >>>computational responsibility such as IGP areas and Autonomous Systems. >>> >>>Per-domain computation applies where the full path of an inter-domain >>>TE LSP cannot be or is not determined at the ingress node of the TE >>>LSP, and is not signaled across domain boundaries. This is most likely >>>to arise owing to TE visibility limitations. The signaling message >>>indicates the destination and nodes up to the next domain boundary. It >>>may also indicate further domain boundaries or domain identifiers. The >>>path through each domain, possibly including the choice of exit point >>>from the domain, must be determined within the domain. >>> >>>A URL for this Internet-Draft is: >>> >> > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-inter-domain-pd-path-comp-01.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-inter-domain-pd-path-comp-01.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-inter-domain-pd-path-comp-01.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. >>> >> >> >> >> > > > > . > From owner-ccamp@ops.ietf.org Sat Oct 22 22:19:31 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETVSK-0004Yx-M9 for ccamp-archive@megatron.ietf.org; Sat, 22 Oct 2005 22:19:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09658 for ; Sat, 22 Oct 2005 22:19:17 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ETVec-0004WR-9i for ccamp-archive@ietf.org; Sat, 22 Oct 2005 22:32:21 -0400 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1ETVJE-00029C-Vt for ccamp-data@psg.com; Sun, 23 Oct 2005 02:10:04 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.0 Received: from [62.241.162.32] (helo=ranger.systems.pipex.net) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1ETVJD-00025V-H0 for ccamp@ops.ietf.org; Sun, 23 Oct 2005 02:10:03 +0000 Received: from dnni.com (81-178-2-190.dsl.pipex.com [81.178.2.190]) by ranger.systems.pipex.net (Postfix) with ESMTP id E0C64E00036F; Sat, 22 Oct 2005 16:50:06 +0100 (BST) Received: from Puppy ([217.158.132.189] RDNS failed) by dnni.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 22 Oct 2005 16:45:44 +0100 Message-ID: <041601c5d720$167419c0$ca00470a@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Huub van Helvoort" , References: <43595C77.4090805@chello.nl> <4359F1DB.1010504@chello.nl> <435A0545.5000902@chello.nl> Subject: Re: draft-bernstein-ccamp-gmpls-vcat-lcas-01 comments - delay Date: Sat, 22 Oct 2005 16:45:46 +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: 22 Oct 2005 15:45:45.0408 (UTC) FILETIME=[AA7B1C00:01C5D71F] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Content-Transfer-Encoding: 7bit Huub, I don't see them in the spam bucket, but given the rate of arrival of new spam it is possible they went out the over flow before I got there :-( Please post again. In general, attachments can be a bit risky as they are more likely to be excised. In line text is better. Cheers, Adrian ----- Original Message ----- From: "Huub van Helvoort" To: Sent: Saturday, October 22, 2005 10:24 AM Subject: Re: draft-bernstein-ccamp-gmpls-vcat-lcas-01 comments - delay > FYI, > > before sending the email quoted below I already did send > two other emails, one with comments and the other with the > forgotten attachment. Without the attachment the comment > below is worthless. > > Sofar these messages have not appeared on the ccamp list > (but they did on the SG15/Q9 and SG15/Q11 lists). > > So maybe they are in the ccamp spam-trap. > If they do not re-appear soon I will repost them. > Sorry for the inconvenience. > > regards, Huub. > =============================================================== > Huub van Helvoort wrote: > > > Hello Greg et al, > > > > One additional comment: > > > > Depending on the level of detail to be provided in this document. > > > > In section 2.4 VCAT configuration with LCAS (MI_LCASEnable=true) > > > > The value of Xm is not only technology dependent, it can also be > > implementation dependent. E.g. in a routerinterface with STM-64 > > line rate for a VC-4-Xv based VCG Xm = 64 and not 256. > > Xm cannot be provisioned, it can be retreived from the VCG > > (as well as Xa). > > > > Have a nice weekend, Huub. > > > > -- > ================================================================ > http://members.chello.nl/hhelvoort/ > ================================================================ > Always remember that you are unique...just like everyone else... > > > From info@mail.ssaas.com Sun Oct 23 01:59:50 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETYtZ-0004rT-J7 for ccamp-archive@megatron.ietf.org; Sun, 23 Oct 2005 01:59:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA16439 for ; Sun, 23 Oct 2005 01:59:35 -0400 (EDT) Received: from [58.180.217.65] (helo=mail.ssaas.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ETZ63-0001bs-CN for ccamp-archive@ietf.org; Sun, 23 Oct 2005 02:12:43 -0400 Received: (qmail 904 invoked by uid 509); 23 Oct 2005 07:28:23 +0900 Date: 23 Oct 2005 07:28:23 +0900 Message-ID: <20051022222823.903.qmail@mail.ssaas.com> From: info@ssaas.com To: ccamp-archive@ietf.org Subject: $B$"$d$G$9!#(B X-Spam-Score: 3.5 (+++) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 http://80607.jp/baitoru/index.html $B$"$d$C$F$$$$$^$9!#2K$J$i2q$C$F%(%C%A$7$^$;$s$+!)5^$K%S%C%/%j$G$9$h$M!#(B $B$I$&$7$F$b%(%C%A$,$7$?$7$?$/$F!"%(%C%A$,;d$O:#$+$i$G$bJ?5$$G$9!#(B $Bl9g$O!d"M(B gyakuten_angel@yahoo.com.au $B!!(B ////////////////////////////////////////////////////////// From owner-ccamp@ops.ietf.org Sun Oct 23 09:59:58 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETgOC-0004vo-5E for ccamp-archive@megatron.ietf.org; Sun, 23 Oct 2005 09:59:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05961 for ; Sun, 23 Oct 2005 09:59:44 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ETgae-0002Xp-Lz for ccamp-archive@ietf.org; Sun, 23 Oct 2005 10:12:55 -0400 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1ETgEa-000Gs8-EU for ccamp-data@psg.com; Sun, 23 Oct 2005 13:50:00 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [213.46.243.17] (helo=amsfep20-int.chello.nl) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1ETgEX-000Grq-IZ for ccamp@ops.ietf.org; Sun, 23 Oct 2005 13:49:58 +0000 Received: from [192.168.1.4] (really [24.132.27.149]) by amsfep13-int.chello.nl (InterMail vM.6.01.04.04 201-2131-118-104-20050224) with ESMTP id <20051023093048.UNVT12936.amsfep13-int.chello.nl@[192.168.1.4]> for ; Sun, 23 Oct 2005 11:30:48 +0200 Message-ID: <435B5845.2040502@chello.nl> Date: Sun, 23 Oct 2005 11:30:45 +0200 From: Huub van Helvoort User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ccamp Subject: Re: draft-bernstein-ccamp-gmpls-vcat-lcas-01 comments - 3rd try Content-Type: text/plain; charset=windows-1252; format=flowed Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 5f02d6646f83ade536724b616ceb2e16 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id JAA05961 Thanks Adrian, > Huub, I don't see them in the spam bucket, but given the rate of arriva= l > of new spam it is possible they went out the over flow before I got the= re > :-( >=20 > Please post again. OK, the resend with attachment did not work, this time in-line without diff-marks. My comments are based on ITU-T recommendation G.806 clause 10 and appendix VII. This may be a good reference to add at the end of the draft. If you need more information, please feel free to ask me or read all about VCAT, LCAS (and GFP) in my book: "Next generation SDH/SONET: Evolution or Revolution?" John Wiley & Sons ISBN: 0-470-09120-7 Cheers, Huub. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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... @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ CCAMP working Group G. Bernstein Internet-Draft Grotto Networking Expires: April 14, 2006 D. Caviglia Marconi R. Rabbat Fujitsu October 11, 2005 Operating Virtual concatenation (VCAT) and the Link Capacity Adjustment Scheme (LCAS) with Generalized Multi-Protocol Label Switching (GMPLS) draft-bernstein-ccamp-gmpls-vcat-lcas-01 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 14, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This document describes the use of the Generalized Multi-Protocol Label Switching (GMPLS) control plane in conjunction with the Virtual Concatenation (VCAT) layer 1 inverse multiplexing mechanism and its companion Link Capacity Adjustment Scheme (LCAS) which can be used Bernstein, et al. Expires April 14, 2006 [Page 1] Internet-Draft GMPLS, VCAT and LCAS October 2005 for hitless dynamic resizing of the inverse multiplex group. These techniques apply to the Optical Transport Network (OTN), Synchronous Optical Network (SONET), Synchronous Digital Hierarchy (SDH) and Plesiochronous Digital Hierarchy (PDH) signals. Table of Contents 1. Overview of VCAT and LCAS . . . . . . . . . . . . . . . . . . 3 1.1. VCAT signals and components . . . . . . . . . . . . . . . 3 1.2. VCAT Capabilities and Limitations . . . . . . . . . . . . 3 1.3. The LCAS Protocol . . . . . . . . . . . . . . . . . . . . 4 2. Problem Statement and Current Support . . . . . . . . . . . . 5 2.1. Discovery of Enabled End Systems . . . . . . . . . . . . . 5 2.2. Client to End Point Mappings . . . . . . . . . . . . . . . 5 2.3. VCAT configuration without LCAS . . . . . . . . . . . . . 6 2.4. VCAT configuration with LCAS . . . . . . . . . . . . . . . 7 2.5. Component Signal Configuration Scenarios . . . . . . . . . 8 3. Possible Extensions to GMPLS to support additional VCAT/LCAS scenarios . . . . . . . . . . . . . . . . . . . . . 10 3.1. Mechanisms for Discovery of VCAT/LCAS . . . . . . . . . . 10 3.2. Mechanism to Support Multiple Client to End Point Mappings . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.3. Support for Component Signal Configuration Scenarios . . . 10 4. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 Intellectual Property and Copyright Statements . . . . . . . . . . 14 Bernstein, et al. Expires April 14, 2006 [Page 2] Internet-Draft GMPLS, VCAT and LCAS October 2005 1. Overview of VCAT and LCAS Virtual Concatenation (VCAT) is a standardized layer 1 inverse multiplexing technique that can be applied to OTN [6], SONET [3], SDH [2], and PDH [5] component signals. By inverse multiplexing we mean a method that combines multiple links at a particular layer into an aggregate link to achieve a commensurate bandwidth capacity on that aggregate link. More formally, VCAT essentially combines the payload bandwidth of multiple path layer network signals (or trails) to suppo= rt a single client (e.g. Ethernet) layer link. For a more detailed introduction see [1]. 1.1. VCAT signals and components In the following we will use SDH terminology rather than both SONET a= nd SDH terminology. In SDH Virtual Concatenation (VCAT) can be applied = to the following component time division multiplex (TDM) signals=20 referred to as Virtual Containers (VCs): VC-11, VC-12, VC-2, VC-3, and VC-4. Only like component signals can be aggregated into a VCAT group (VCG). These VCGs are respectively known as: VC-11-Xv, VC-12-Xv, VC-2-Xv, VC-3-Xv, and VC-4-Xv. In the previous designations X is an integer=20 indicating the number of members in the VCG. The value of X for high=20 order VCs (VC-3 and VC-4)can be from 1 to 256; and for low order VCs=20 (VC-11 VC-12 and VC-2) the value of X can be 1 to 64. See [2] for details. VCAT can be applied to the following PDH signals as specified in=20 reference [5]: DS1,E1, E3, DS3. Similar to the SONET/SDH case these component signals can only be combined with like signals to produce=20 aggregates. For some reason the VCGs of the PDH signals were not given unique=20 designations in [5] so we shall adopt a similar notation to the SDH VCAT signals f= or the permitted PDH VCAT signals that follow: DS1-Xv, E1-Xv, E3-Xv,=20 DS3-Xv. Concatenation in the optical transport network (OTN) is realized by means of virtual concatenation of Optical Channel Payload Unit (OPU) signals. OPUk signals (k=3D1, 2, 3) can be concatenated into OPUk-Xv aggregates with X=3D 1,..., 256. See reference [6] for details. 1.2. VCAT Capabilities and Limitations VCAT performs inverse multiplexing by octet/byte de-interleaving of t= he encapsulated client bit stream into the individual VCs of the VCG=20 and the VCs are transported across the network independently from each=20 other. Due to the possible different propagation times of the VCs, a differentia= l delay may occur between the individual VCs at the path termination. T= his differential delay has to be compensated and the VCs have to be=20 realigned. This is summarized for the different signal types in reference [1] wi= th details given in the respective standards documents [2] [3]. Bernstein, et al. Expires April 14, 2006 [Page 3] Internet-Draft GMPLS, VCAT and LCAS October 2005 1.3. The LCAS Protocol The Link Capacity Adjustment Scheme for VCAT signals is a protocol for dynamically and hitlessly changing (i.e., increasing and decreasing) the capacity of a VCG. LCAS also provides survivability capabilities, automatically decreasing the capacity if a member of th= e VCG experiences a failure in the network, and increasing the capacity when the network fault is repaired. LCAS, itself, provides a mechani= sm for interworking between LCAS and non-LCAS VCAT end points. VCAT doe= s not require LCAS for its operation. LCAS functionality does not overlap or conflict with GMPLS' routing o= r signaling functionality for the establishment of component links or entire VCGs. LCAS instead is used to control whether a particular component signal is actually put into service carrying traffic for=20 the VCG. LCAS provides for graceful degradation of failed links by having the=20 sink end(s) report back the receive status of all member components. In t= he case of a reported member failure, the source end will stop using the failed member and distribute the data over the remaining =91good=92 m= embers, thus transmission is restored to a reduced bandwidth capacity. The=20 source end will send an LCAS message to the sink end that it is not=20 transmitting data on that failed member. The worst case notification times are summarized in [1]. Bernstein, et al. Expires April 14, 2006 [Page 4] Internet-Draft GMPLS, VCAT and LCAS October 2005 2. Problem Statement and Current Support In this section we list a number of VCAT/LCAS usage scenarios and their current level of support. We will evaluate the applicability of GMPLS to these scenarios and for those scenarios that GMPLS does not currently support we describe possible GMPLS extensions in Section 3. Note the term "component" signal in the text is used as a simplified notion to the more formal concepts of VC-n, ODUk, and PDH termination function as well as VC-n, ODUk and PDH path/trail. 2.1. Discovery of Enabled End Systems Discovering VCAT: VCAT sources can only communicate with VCAT capable sinks. Hence the VCAT capabilities of a PDH, SDH, or OTN path termination points need to be known. Currently no support for discovery of VCAT or LCAS apriori, i.e., via routing information. Support for "discovery" of VCAT capability at connection establishment time via signaling, i.e., we can request VCAT connection and if the end system cannot support it,it would refuse the connection. TBD -- is there a specific error code concerning "VCAT not supported". Discovering LCAS: LCAS offers additional functionality between VCAT capable sources and sinks. Hence the LCAS capabilities of VCAT enabled path termination points can be useful to know in advance of component signal setup. Currently there is no mechanism to ask for an LCAS enabled end point nor is there a way to find out if the other end is LCAS enabled until after the connection is established. This is a problem if we specifically want hitless dynamic resizing or fast graceful degradation for a VCG. 2.2. Client to End Point Mappings Fixed Client to End point Mapping: Per client signal there is a VC-n-Xv circuit in which the X VC-n termination points are dedicated to this client signal. At any point in time, Xa (active members) out of Xp (provisioned members) VC-n termination points m= ay be set up to carry client traffic. For example when VCAT is deployed on a Router, the VCG connects directly to one STM-N interface port (in absence of a HO or LO swi= tch fabric in the router). The transport network may then transport t= he individual VCs via one or more routes. Diverse routing will incur= a differtial delay. Bernstein, et al. Expires April 14, 2006 [Page 5] Internet-Draft GMPLS, VCAT and LCAS October 2005 Variable Client to End point Mapping: For a set of M client signals there are M*VC-n-Xv VCAT endpoints sharing a set of N (N>M) VC-n termination points. It is possible that M*X > N (example: M=3D10,= X=3D7, N=3D64); i.e. there may be a kind of overbooking. Implication: mu= st be able to accommodate multiple different sized VCGs at an "interface= ". For example an STM-64 interface can support many different VC-4-Xv groups, providing the total number of VCs does not exceed the=20 interface total capacity. Implications: In both these cases we can have more than one VCG per=20 GMPLS link. In general it is the responsibility of the signaling entity= at the source and destination ends to choose the appropriate VC-n termination points for the VCG and in the case of "variable client mapping" to perform needed internal configuration. However multip= le VCGs per GMPLS link or GMPLS addressed entity introduces an unresolvable ambiguity when disjoint connections are set up or dynamic resizing is applied since there is currently no "VCG identifier" in GMPLS signaling. 2.3. VCAT configuration without LCAS (MI_LCASEnable=3Dfalse) Base Configuration: For VCAT to operate the sink end needs to be informed of how many components are in the VCG. It has no other way of knowing if it is currently receiving all components intended to be in the group. Fixed sized co-routed groups are supported with current GMPLS signaling. Diversely routed groups are not currently supported. Group Resizing: Additions or removals of components from a non-LCAS V= CG are not hitless, that is data loss will occur while the source and sink are reprovisioned as to the number of members in the group. Currently not supported within GMPLS. In particular, with each addition or removal of a component the sink end point needs to be told the expected number of components in the group. Failure Conditions: Failure of a component must detected external to VCAT system. The entire group is rendered inoperable until the=20 failed component is taken out of service (or replaced) by=20 re-provisioning both source and sink to that effect. Currently not supported within GMPLS. The source and sink need=20 to be told what component has failed and remove it from service. Bernstein, et al. Expires April 14, 2006 [Page 6] Internet-Draft GMPLS, VCAT and LCAS October 2005 2.4. VCAT configuration with LCAS (MI_LCASEnable=3Dtrue) Base Configuration: Sink end (and source end) are first configured wi= th the value of Xp (the provisioned number of members), out of Xm (th= e technology specific maximum number of members) with Xm =B3 Xp. LC= AS then determines automatically the number of active members Xa and puts them into service for the group. NOTE: The value of Xm is not only technology dependent, it can also be implementation dependent. E.g. in a routerinterface with STM-64 line=20 rate for a VC-4-Xv based VCG Xm =3D 64 and not 256. Xm cannot be=20 provisioned, it can be retreived from the VCG (as well as Xa). Currently both co-routed and diversely routed VCGs can be supported if there is no VCG ambiguity. Component Addition: When a new component signal has to be added to a VCG the following procedure applies. 1. Establish a connection from Source to Sink for the member to=20 be added. 2. Provision the Source to use the =91new=92 member as one of the active= =20 group (Xp -> Xp+1). This entails sending the ADD command by the new membe= r. 3. Provision the Sink to recognize the =91new=92 member of the VCG (Xp -= >=20 Xp+1). The order of doing the above is not important. When the ADD command is=20 received by the sink it will return an =91OK=92 to the Source at which ti= me=20 the Source will use all active members (old + new) to transport the=20 client traffic. This procedure does not affect the already established LCAS member= s, that is, client traffic is not sent on the new component=20 until the LCAS procedure is complete; This can be supported within GMPLS if, after GMPLS has successfull= y established a potential new component, the source end LCAS is (internally) told to add it to the group. Component Removal: When a component is removed the following procedur= e applies: 1. On receipt of a remove command (for a particular member) from the=20 management system, LCAS Source will stop using that member; the Sink=20 will recognize that that member no longer carrier client traffic and=20 will use only the remaining members to reconstitute the client signal.=20 Note: The current LCAS protocol allows for the =91decrease=92 command to = be=20 initiated at either the LCAS source or the LCAS sink; if it is initiated=20 at the sink there will be a hit to the reconstructed data. 2. The connection, source provisioning and sink provisioning of that=20 member can then be removed from the VCG. Bernstein, et al. Expires April 14, 2006 [Page 7] Internet-Draft GMPLS, VCAT and LCAS October 2005 3. The component connection can be, if needed, removed from the transport network. This can be supported within GMPLS if, before GMPLS tears down a component, LCAS is told (local to source end) to remove the component from service in the group. Component Failure: When a component fails: 1. The LCAS sink detects the failure (how this is done is outside the=20 scope of this ID) and informs the source of this failure via the member=20 status (MST)information. : 2. The source then takes the failed component out of service and=20 uses only the remaining =91good=92 members to transport the client traffi= c=20 (Xa -> Xa-1). Note: No re-sequencing of the VCG is done at this time. When the failed component is repaired, LCAS can automatically add the repaired component back to the group, or alternatively a new component can be added to bring the group back to its original size. Note that component failure is not hitless, but note the fast notification times of [BernDiegoRabbat]. Currently supported since no action required of GMPLS. 2.5. Component Signal Configuration Scenarios Here we use the term "group" to refer to the entire VCG and the terminology "set" and "subset" to refer to the collection of potential VCG member signals. Note that all assesments of whether a scenario is currently supported assumes either (a) a single VCG per GMPLS addressable entity, or (b) a mechanism is in place to disambiguate multiple VCGs (see Section 2.2). Fixed, Co-routed: A fixed bandwidth VCG, with all members=20 transported over the same route. This is the case where the intended bandwidth of the VCG does not change and all member signals follow the same route. The intent here is the capability to allocate the "right" amount of bandwidth. Currently supported in GMPLS. Fixed, Diverse-routes: A fixed bandwidth VCG, with the members=20 transported over at least two different routes. The intent here is additional resilience and graceful degradation in the case of failure. Bernstein, et al. Expires April 14, 2006 [Page 8] Internet-Draft GMPLS, VCAT and LCAS October 2005 If LCAS is present this scenario is supported under GMPLS. Not supported without LCAS since we need two-way communications of some type between source and sink to coordinate which members are to be used in the group in a failure scenario. Dynamic, Co-routed: A dynamic VCG (bandwidth can be increased or decreased via the addition or removal of member signals), with all the members transported over the same route. Intent here= is dynamic sizing of bandwidth. If LCAS present this scenario is currently supported by GMPLS. Implications: LCAS is needed for hitless resizing. Note before LCAS can do its part of getting traffic over the modified VCG,=20 the two VCAT/LCAS endpoints need to be configured (Xp -> Xp+1 or Xp ->=20 Xp-1); this requires either "communication" between the two endpoints (when one of the endpoints is configured by call/ connection controller, or simple communication of the call/ connection controller with both endpoints. Without LCAS we still need two way communications between source and sink to coordinate which members are used in the group and changes will not be hitless. Dynamic, Diverse-routes: A dynamic VCG, with the members transported=20 over at least two different routes. Intent here is dynamic resizing and resilience. Currently support and implications similar to the "dynamic, co- routed" and "fixed, diverse-routes" cases. Shared Pool: Two or more VCGs between the same source and sink who desire to share a pool of component signals between them. Each VCG may have a dedicated set of members, and may also obtain additional members from a "common pool" of components. Note that at any given point in time a component signal can belong to at most one VCG. The intent here is to allow dynamic resizing of VCGs via the sharing of a pool of established component signals without requiring complete circuit provisioning, i.e., only the group membership of the component signal would chan= ge. Currently not supported by GMPLS. Implications: a communications mechanism between source and sink to indicate during a "change" which group a component should now belong. Bernstein, et al. Expires April 14, 2006 [Page 9] Internet-Draft GMPLS, VCAT and LCAS October 2005 3. Possible Extensions to GMPLS to support additional VCAT/LCAS scenarios Here we look at what might be reasonable to add to GMPLS to support the interest scenarios of Section 2 that were not currently covered. 3.1. Mechanisms for Discovery of VCAT/LCAS Would like to get both VCAT and LCAS capability of end systems via routing... Would like to be able to specifically ask for LCAS capability via signaling... 3.2. Mechanism to Support Multiple Client to End Point Mappings This is a very important capability and it is very similar to one that is being proposed in the end-to-end signaling for recovery I-D. In particular the ASSOCIATION object. Note, however, since there is a rather high probability that at some point we might use VCAT/LCAS with GMPLS based protection we would really need an ASSOCIATION object type specific to VCAT. Association objects are not unique and therefore adding a new type to the Association object would make it a good candidate to support this requirement. 3.3. Support for Component Signal Configuration Scenarios TBD based on analysis of use of admin-status object. If the admin- status object is sufficient we will detail its use in this application since it is currently an optional object. 4. References [1] Bernstein, G., Caviglia, D., and R. Rabbat, "VCAT/LCAS in a Clamshell", To Be Published available at http:// www.grotto-networking.com/pages/VCAT-in-a-Clamshell-DRAFT.pdf, October 2005. [2] International Telecommunications Union, "Network node interface for the synchronous digital hierarchy (SDH)", ITU- T Recommendation G.707, December 2003. [3] American National Standards Institute, "Synchronous Optical Network (SONET) - Basic Description including Multiplex Structure, Rates, and Formats", ANSI T1.105-2001, 2001. [4] "Link capacity adjustment scheme (LCAS) for virtual concatenated signals", ITU-T Recommendation G.7042, February 2004. Bernstein, et al. Expires April 14, 2006 [Page 10] Internet-Draft GMPLS, VCAT and LCAS October 2005 [5] "Virtual concatenation of plesiochronous digital hierarchy (PDH) signals", ITU-T Recommendation G.7043, July 2004. [6] "Interfaces for the Optical Transport Network (OTN)", ITU- T Recommendation G.709, March 2003. [7] Sklower, K., Lloyd, B., McGregor, G., Carr, D., and T. Coradetti, "The PPP Multilink Protocol (MP)", RFC 1990, August 1996. [8] "Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Specific requirements - Part 3: Carrier sense multiple access with collision detection (CSMA/CD) access method and physical layer specifications", IEEE Standard 802.3, March 2002. [9] Bernstein, G., Rajagopalan, B., and D. Saha, "Optical Network Control: Archtecture, Protocols", Addison-Wesley, 2004. Bernstein, et al. Expires April 14, 2006 [Page 11] Internet-Draft GMPLS, VCAT and LCAS October 2005 Appendix A. Acknowledgements The authors would like to thank Maarten Vissers for extensive reviews and contributions to this draft. Bernstein, et al. Expires April 14, 2006 [Page 12] Internet-Draft GMPLS, VCAT and LCAS October 2005 Authors' Addresses Greg Bernstein Grotto Networking Phone: +1 510 573 2237 Email: gregb@grotto-networking.com Diego Caviglia Marconi Email: Diego.Caviglia@marconi.com Richard Rabbat Fujitsu Phone: +1 408 530 4537 Email: richard@us.fujitsu.com Bernstein, et al. Expires April 14, 2006 [Page 13] Internet-Draft GMPLS, VCAT and LCAS October 2005 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Bernstein, et al. Expires April 14, 2006 [Page 14] From info@mail.fcze.com Sun Oct 23 15:09:26 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETlDi-0004ga-2M for ccamp-archive@megatron.ietf.org; Sun, 23 Oct 2005 15:09:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20592 for ; Sun, 23 Oct 2005 15:09:11 -0400 (EDT) Received: from [125.57.106.196] (helo=mail.fcze.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ETlQI-0003UF-Qz for ccamp-archive@ietf.org; Sun, 23 Oct 2005 15:22:27 -0400 Received: (qmail 29502 invoked by uid 510); 23 Oct 2005 19:26:12 +0900 Date: 23 Oct 2005 19:26:12 +0900 Message-ID: <20051023102612.29501.qmail@mail.fcze.com> From: info@fcze.com To: ccamp-archive@ietf.org Subject: $B!T40A4L5NA!U$I%(%m%5%$%HG[?.Cf!*!*!*(B X-Spam-Score: 4.6 (++++) X-Scan-Signature: d6b246023072368de71562c0ab503126 http://80607.jp/koiland/index.html $B%a!<%k; Sun, 23 Oct 2005 16:14:22 -0400 (EDT) Received: from [125.57.107.132] (helo=mail.hclj.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ETmRM-0005Y7-BP for ccamp-archive@ietf.org; Sun, 23 Oct 2005 16:27:36 -0400 Received: (qmail 29863 invoked by uid 510); 23 Oct 2005 21:05:50 +0900 Date: 23 Oct 2005 21:05:50 +0900 Message-ID: <20051023120550.29862.qmail@mail.hclj.com> From: info@hclj.com To: ccamp-archive@ietf.org Subject: $B=w$N;R$r;t$$$^$;$s$+!)(B X-Spam-Score: 4.9 (++++) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a $B=w$N;R$rHNGd$5$;$FD:$-$^$9!#:#2s$N=PIJ?M?t$O#8L>$G$9!#(B $BG/Np$O(B18$B!A(B20$B:P!!=P?H9q%"%8%"=t9q(B $BE~Ce$O:#7nKv$K$J$kM=Dj$G$9!#(B $BDL>oDL$j$N%*!<%/%7%g%s7A<0$H$J$j$^$9$N$G(B $B>\:Y!";22C$r4uK>$5$l$kJ}$O!"(B $B$3$A$i$NHVAH$NCf$K$"$kNx?MJg=8N"%5%$%H$h$j$*F~$j2<$5$$!#(B http://www.gyakuten5.net/?asia $B%a!<%k; Sun, 23 Oct 2005 18:12:08 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EToHK-0000O0-9C for ccamp-archive@ietf.org; Sun, 23 Oct 2005 18:25:25 -0400 Received: from pool-141-149-244-68.buff.east.verizon.net ([141.149.244.68]) by mx2.foretec.com with smtp (Exim 4.24) id 1ETo4f-00086I-RF for ccamp-archive@ietf.org; Sun, 23 Oct 2005 18:12:19 -0400 Received: from sHZ@localhost by 2un.int (8.11.6/8.11.6); Sun, 23 Oct 2005 20:07:16 -0300 Message-ID: From: "Rubin Kruse" Reply-To: "Rubin Kruse" To: ietf-outbound.03@ietf.org, internet@ietf.org, ccamp-archive@ietf.org Subject: Finally, you can afford software by Microsoft Office XP & Photoshop Date: Sun, 23 Oct 2005 21:01:16 -0200 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.2730.2 X-Sender: OctavioHealy@boyjy.com Content-Type: multipart/mixed; boundary="--CnSgztohr9LjOuRw" X-Spam-Score: 0.4 (/) X-Scan-Signature: a4e5f67c5e230eddf754446d1a2201a4 cnbI ----CnSgztohr9LjOuRw Content-Type: text/html; Content-Transfer-Encoding: quoted-printable c
Opt-in Email Special Offer   = ;  unsubscribe me

<= td vAlign=3Dbottom> SEARCH
<= /tr>

<= b> TOP 10 NE= W TITLES
<= /tr>  = Adobe Illustrator 11= Customers also bought

 ON SALE NOW!

 1 Office Pro 2003
 2 Adobe Photoshop 9.0
 3 Windows XP Pro
4= Adobe Acrobat 7 Pro
5= Flash MX 2004
 6 Corel Draw 12
 7 Norton Antivirus 2005
 8 Windows 2003 Server
 9 Alias Maya 6 Wavefrt
 10
  See more by this manufacturer
   Microsoft
=    Symantec<= /a>
   Adobe
 
&n= bsp;  these other items= ..

Microsoft Office Professional Edition *2003*
Microsoft

Choose:
 

You Save:



Availability: Available for INSTANT downlo= ad!
Coupon Code: sAWNaf
 

Sales Rank: #1
System requirements  |  Other Versions
Date Coup= on Expires: August 31st, 2005
Average= Customer Review:3D"5 Based on 19135 reviews. Write a review.

List Price:$499.00
Price:$69.99
$429.01 (86%)

Adobe Photoshop CS2 V 9.0=
Adobe

=
Choose:
&nbs= p;

List Price:$599.00
Price:$69.99
You Save:<= /td>$529.01 (= 90%)



Availability: = Available for INSTANT download!
Coupon Code: z6006
 

Sales Rank: #2
System requirements  |=   Other Versions
Date Coupon Expires: August 31st, 2005
Average Customer Review:3D"5 Based on 1872 rev= iews. Write a review.

Microsoft Windows XP Professional or Longhorn Edition
= Microsoft

<= tr>
Choose:
&nbs= p;

List Price:$279.00
Price:$49.99
You Save:$229.0= 1 (85%)



Availability: Available for INSTANT download!
Coupon Code: Wdt0QrAK
&n= bsp;

Sales Rank: #3
System requirements&n= bsp; |  Other Versions
Date Coupon Expires: August 31st, 2005
Average Customer Review:=3D"5 Based on 16= 6648 reviews. Write a review.<= /p>

Adobe Acrobat Professional V 7.0
= Adobe

Choose:
<= a href=3Dhttp://ezsoftdl.net/?l>  <= /td>

= = =
List Price:$499.0= 0
Price:$69.99
You Save:$429.01 (85%)



Availability: Available for IN= STANT download!
Coupon Code: Gth8m
 

Sales Rank: #4
System requirements  |  Other Versions
Date Coupon Expires: August 31st, 2005
= Average Customer Review:3D"5 Based on 161879 reviews. Write a review.

----CnSgztohr9LjOuRw-- From owner-ccamp@ops.ietf.org Tue Oct 25 09:56:04 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUPHX-0001vW-9T for ccamp-archive@megatron.ietf.org; Tue, 25 Oct 2005 09:56:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18669 for ; Tue, 25 Oct 2005 09:55:48 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUPUM-0003Sr-Cu for ccamp-archive@ietf.org; Tue, 25 Oct 2005 10:09:27 -0400 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EUP6Q-000JuO-FR for ccamp-data@psg.com; Tue, 25 Oct 2005 13:44:34 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [130.104.229.109] (helo=info.ucl.ac.be) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EUP6O-000JuB-W9 for ccamp@ops.ietf.org; Tue, 25 Oct 2005 13:44:33 +0000 Received: from info.ucl.ac.be (astrolabe [130.104.229.109]) by info.ucl.ac.be (8.12.11/8.12.11) with ESMTP id j9PDi0Zx000082; Tue, 25 Oct 2005 15:44:21 +0200 (MET DST) Message-ID: <435E369D.10301@info.ucl.ac.be> Date: Tue, 25 Oct 2005 09:43:57 -0400 From: Cristel Pelsser User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040413 Debian/1.6-5 X-Accept-Language: us, en MIME-Version: 1.0 To: Igor Bryskin CC: ccamp@ops.ietf.org Subject: Re: I-D ACTION:draft-ietf-ccamp-inter-domain-pd-path-comp-01.txt References: <007a01c5d653$ec5302e0$6601a8c0@movaz.com> <028501c5d66c$3d075570$ca00470a@Puppy> <00cf01c5d66d$a8af7ea0$6601a8c0@movaz.com> In-Reply-To: <00cf01c5d66d$a8af7ea0$6601a8c0@movaz.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-INGI-MailScanner-Information: Please contact the ISP for more information X-INGI-MailScanner: Found to be clean Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 918f4bd8440e8de4700bcf6d658bc801 Content-Transfer-Encoding: 7bit Hi Igor, all, I made some simulations with a per-domain path computation where the border node is selected by the PCE. You can find a brief description of this path computation method at http://www.info.ucl.ac.be/~cpe/pelsser_conext2005.pdf and http://www.info.ucl.ac.be/~cpe/poster_conext_cpe.pdf Cristel Igor Bryskin wrote: >Adrian, > >I understand and agree with what you are saying. My point was that a) when >PCE is available, the PCE service could be a better way for determining the >outgoing domain border node, and b) per-domain path computation could be >useful even when you have PCE service available. > >In other words I was just suggesting an alternative method for per-domain >path computation, that's all. > >Igor > >----- Original Message ----- >From: "Adrian Farrel" >To: "Igor Bryskin" ; ; "Arthi Ayyangar" > >Cc: >Sent: Friday, October 21, 2005 2:20 PM >Subject: Re: I-D ACTION:draft-ietf-ccamp-inter-domain-pd-path-comp-01.txt > > > > >>Hi Igor, >> >>I think you have to set the context of this I-D carefully, and then >>understand the limited scope that is additionally proposed. >> >>The context of the I-D is limited to the per-domain computation case. >>Hence, consulting an external PCE is out of scope. This is not to say that >>it is not valid to consult a PCE (in fact, you might expect JP and me to >>support that technique), but this I-D is demonstrating what we can do and >>how we can solve the problem without using PCE. >> >>With respect to the use of the IP reachability, you may recall that I >>raised this concern in Paris and on the list. The conclusion was that if >>you have no other way of determining an exit router for your domain, then >>attempting to use the IP reachability is no worse than giving up, and may >>be much better. >> >>In the cases you raise: >>1. Yes, an interface address may be unreachable. >> Do we lose anything by consulting IP reachability in this case? >> No. >>2. Yes, the IP reachability may give us a sub-optimal TE path. >> Is this path worse than no path? >> No. >> >>So I asked the authors to be clear that what they are suggesting has >>limitations, and should not be applied in some specific cases. I haven't >>looked at the text yet, but I hope they have covered this. >> >>Cheers, >>Adrian >>----- Original Message ----- >>From: "Igor Bryskin" >>To: ; "Arthi Ayyangar" >>Cc: >>Sent: Friday, October 21, 2005 4:27 PM >>Subject: Re: I-D ACTION:draft-ietf-ccamp-inter-domain-pd-path-comp-01.txt >> >> >> >> >>>Arthi, JP >>> >>> >>> >>>I have a problem with the auto-discovery mechanism you described in the >>>draft (one that is based on query to IGP or BGP to determine outgoing >>>ABR/ASBR). >>> >>> >>> >>>1. Destination ID must be network unique but it does not have to be IP >>>routable, for example, it could be a numbered link ID. >>> >>>2. Even in case when destination is IP address, the path computing node >>> >>> >>can >> >> >>>only obtain the ID of an ABR or ASBR that advertises IP route to the >>>destination, which would be one that knows about the shortest IP path to >>> >>> >>the >> >> >>>destination. However, it does not mean that properly constrained TE path >>>from this ABR/ASBR to the destination or the next ABR/ASBR exist, or is >>> >>> >>not >> >> >>>suboptimal compared to one from some other ABR/ASBR which knows about >>> >>> >>worse >> >> >>>IP path to the destination and hence will not be reported to the >>> >>> >>computing >> >> >>>entity by the routing sub-system. >>> >>> >>> >>>I wonder why not to use the remote PCE service for this purpose. For >>>instance a PCC may ask a PCE to determine either the ID of the outgoing >>>domain border node or entire path in terms of domain border nodes. You >>> >>> >>may >> >> >>>ask why not to request explicit path(s) in this case? Several reasons >>> >>> >>why >> >> >>>the PCC wouldn't want to do so: >>> >>> >>> >>>a) it could be easier and faster for the PCE to determine domain border >>> >>> >>node >> >> >>>in direction towards the destination rather than explicit path(s). For >>>instance, the latter may require cooperation of other PCEs; >>> >>> >>> >>>b) security considerations - PCE may not want to reveal remote domain >>>topology(ies) >>> >>> >>> >>>c) it may be desirable to compute and setup services on per-domain >>> >>> >>basis, >> >> >>>for instance, to have each domain take separate care for service >>>restoration. >>> >>> >>> >>>What do you think? >>> >>> >>> >>>Igor >>> >>> >>> >>>----- Original Message ----- >>> >>>From: >>> >>>To: >>> >>>Cc: >>> >>>Sent: Thursday, October 20, 2005 6:50 PM >>> >>>Subject: I-D ACTION:draft-ietf-ccamp-inter-domain-pd-path-comp-01.txt >>> >>> >>> >>> >>> >>>>A New Internet-Draft is available from the on-line Internet-Drafts >>>> >>>> >>>directories. >>> >>> >>>>This draft is a work item of the Common Control and Measurement Plane >>>> >>>> >>>Working Group of the IETF. >>> >>> >>>>Title : A Per-domain path computation method for establishing >>>> Inter-domain Traffic Engineering (TE) Label >>>> >>>> >>>Switched Paths (LSPs) >>> >>> >>>>Author(s) : J. Vasseur, et al. >>>>Filename : draft-ietf-ccamp-inter-domain-pd-path-comp-01.txt >>>>Pages : 18 >>>>Date : 2005-10-20 >>>> >>>>This document specifies a per-domain path computation technique for >>>>establishing inter-domain Traffic Engineering (TE) Multiprotocol Label >>>>Switching (MPLS) and Generalized MPLS (GMPLS) Label Switched Paths >>>>(LSPs). In this document a domain refers to a collection of network >>>>elements within a common sphere of address management or path >>>>computational responsibility such as IGP areas and Autonomous Systems. >>>> >>>>Per-domain computation applies where the full path of an inter-domain >>>>TE LSP cannot be or is not determined at the ingress node of the TE >>>>LSP, and is not signaled across domain boundaries. This is most likely >>>>to arise owing to TE visibility limitations. The signaling message >>>>indicates the destination and nodes up to the next domain boundary. It >>>>may also indicate further domain boundaries or domain identifiers. The >>>>path through each domain, possibly including the choice of exit point >>>>from the domain, must be determined within the domain. >>>> >>>>A URL for this Internet-Draft is: >>>> >>>> >>>> >http://www.ietf.org/internet-drafts/draft-ietf-ccamp-inter-domain-pd-path-comp-01.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-inter-domain-pd-path-comp-01.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-inter-domain-pd-path-comp-01.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. >>>> >>>> >>>> >>> >>> >>> >>> > > > From owner-ccamp@ops.ietf.org Tue Oct 25 13:07:55 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUSHC-0006W9-8P for ccamp-archive@megatron.ietf.org; Tue, 25 Oct 2005 13:07:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05994 for ; Tue, 25 Oct 2005 13:07:40 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUSU7-0002oU-7F for ccamp-archive@ietf.org; Tue, 25 Oct 2005 13:21:20 -0400 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EUS93-0006bV-9c for ccamp-data@psg.com; Tue, 25 Oct 2005 16:59:29 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO, HTML_MESSAGE autolearn=ham version=3.1.0 Received: from [134.226.1.156] (helo=imx2.tcd.ie) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EUS91-0006bH-KE for ccamp@ops.ietf.org; Tue, 25 Oct 2005 16:59:28 +0000 Received: from Vams.imx2 (imx2.tcd.ie [134.226.1.156]) by imx2.tcd.ie (Postfix) with SMTP id E936768165 for ; Tue, 25 Oct 2005 17:59:26 +0100 (IST) Received: from imx2.tcd.ie ([134.226.1.156]) by imx2.tcd.ie ([134.226.1.156]) with SMTP (gateway) id A06869D7340; Tue, 25 Oct 2005 17:59:26 +0100 Received: from PC (ntrg023.cs.tcd.ie [134.226.55.23]) by imx2.tcd.ie (Postfix) with ESMTP id BAB5D68165 for ; Tue, 25 Oct 2005 17:59:26 +0100 (IST) From: "Marco Ruffini" To: Subject: draft-ietf-ccamp-lmp-10 comments Date: Tue, 25 Oct 2005 17:59:23 +0100 Message-ID: <002a01c5d985$73511aa0$1737e286@PC> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_002B_01C5D98D.D51582A0" 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 = A16869D7340 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.923) Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.2 (/) X-Scan-Signature: c40ff0c70161549dbde2f89c7946385a This is a multi-part message in MIME format. ------=_NextPart_000_002B_01C5D98D.D51582A0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, I was reading the draft-ietf-ccamp-lmp-10 document and in the paragraph = 5 I found a part which is not completely clear to me. =20 Suppose I want to verify the link connectivity between two transparent switches, A and B, where A is the node that initiates the procedure.=20 - One part of the text asserts that "to ensure proper = verification of data link connectivity, it is required that until the data links are allocated for user traffic, they must be opaque (i.e., lose their transparency).": from here I understand that node B has to terminate all = the ports that are not currently transmitting data (i.e. all the ports that = have not been already verified). - On another part I found: "There is no requirement that all = data links be terminated simultaneously, but at a minimum, the data links = MUST be able to be terminated one at a time": here it looks like B does not have = to terminate all the not-yet-verified ports at the same time. However in = this case B may not receive a message sent from node A over a certain link = even if that link is actually connecting node A to B (in fact the port of B relative to that link may be not terminated in that occasion). =20 Which one is the correct interpretation? Should node B have all the not-yet-verified ports terminated at the same time when node A starts = the link verification? =20 =20 This is the text of paragraph 5 I referred to: "A unique characteristic of transparent devices is that the data is not modified or examined in normal operation. This characteristic poses a challenge for validating the connectivity of the data links and establish the label mappings. Therefore, to ensure proper verification of data link connectivity, it is required that until the data links are allocated for user traffic, they must be opaque (i.e., lose their transparency). To support various degrees of opaqueness (e.g., examining overhead bytes, terminating the IP payload, etc.), and hence different mechanisms to transport the Test messages, a Verify Transport Mechanism field is included in the BeginVerify and BeginVerifyAck messages. =20 There is no requirement that all data links be terminated simultaneously, but at a minimum, the data links MUST be able to be terminated one at a time. Furthermore, for the link verification procedure it is assumed that the nodal architecture is designed so that messages can be sent and received over any data link. Note that this requirement is trivial for opaque devices since each data link is electrically terminated and processed before being forwarded to the next opaque device, but that in transparent devices this is an additional requirement." =20 =20 =20 Best Regards, Marco Ruffini. =20 CTVR, Trinity College,=20 Dublin 2, Ireland. Phone: +353-1-608 8442 =20 ------=_NextPart_000_002B_01C5D98D.D51582A0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

I was reading the draft-ietf-ccamp-lmp-10 = document and in the paragraph 5 I found a part which is not completely clear to = me.

 

Suppose I want to verify the link connectivity between two transparent switches, A and B, where A is the node that = initiates the procedure.

-          One part of the text = asserts that “to ensure proper verification of data link connectivity, it is required = that until the data links are allocated for user traffic, they must be opaque = (i.e., lose their transparency).”: from here I understand that node B has to terminate all the ports that are not currently transmitting data (i.e. = all the ports that have not been already verified).

-          On another part I found: = “There is no requirement that all data links be terminated simultaneously, but = at a minimum, the data links MUST be able to be terminated one at a = time”: here it looks like B does not have to terminate all the not-yet-verified = ports at the same time. However in this case B may not receive a message sent = from node A over a certain link even if that link is actually connecting node = A to B (in fact the port of B relative to that link may be not terminated in = that occasion).

 

Which one is the correct interpretation? = Should node B have all the not-yet-verified ports terminated at the same time when = node A starts the link verification?

 

 

This is the text of paragraph 5 I referred = to:

“A unique characteristic of transparent = devices is that the data is

   not modified or examined in = normal operation. This characteristic

   poses a challenge for validating = the connectivity of the data links

   and establish the label = mappings. Therefore, to ensure = proper

  = ; verification of data link connectivity, it is required that = until

  = ; the data links are allocated for user traffic, they must be = opaque

  = ; (i.e., lose their transparency). To support = various degrees of

   opaqueness (e.g., examining = overhead bytes, terminating the IP

   payload, etc.), and hence = different mechanisms to transport the Test

   messages, a Verify Transport = Mechanism field is included in the

   BeginVerify and BeginVerifyAck = messages.

 

   There is no requirement that all data links be = terminated

  = ; simultaneously, but at a minimum, the data links MUST be able to = be

  = ; terminated one at a time. Furthermore, for the link verification

   procedure it is assumed that the = nodal architecture is designed so

   that messages can be sent and = received over any data link. Note that

   this requirement is trivial for = opaque devices since each data link

   is electrically terminated and = processed before being forwarded to

   the next opaque device, but that = in transparent devices this is an

   additional = requirement.”

 

 

 

Best Regards,

Marco Ruffini.

 

CTVR, Trinity College, =

Dublin = 2,

Ireland.

Phone: +353-1-608 8442

 

------=_NextPart_000_002B_01C5D98D.D51582A0-- From owner-ccamp@ops.ietf.org Tue Oct 25 13:40:26 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUSmg-0004sm-1I for ccamp-archive@megatron.ietf.org; Tue, 25 Oct 2005 13:40:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07974 for ; Tue, 25 Oct 2005 13:40:12 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUSzg-0003ok-15 for ccamp-archive@ietf.org; Tue, 25 Oct 2005 13:53:52 -0400 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EUSi4-0008nZ-A1 for ccamp-data@psg.com; Tue, 25 Oct 2005 17:35:40 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.0 Received: from [62.241.162.32] (helo=ranger.systems.pipex.net) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EUSi3-0008n4-4L for ccamp@ops.ietf.org; Tue, 25 Oct 2005 17:35:39 +0000 Received: from dnni.com (81-178-2-190.dsl.pipex.com [81.178.2.190]) by ranger.systems.pipex.net (Postfix) with ESMTP id 714F2E000282; Tue, 25 Oct 2005 18:35:30 +0100 (BST) Received: from Puppy ([217.158.132.79] RDNS failed) by dnni.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 25 Oct 2005 18:35:28 +0100 Message-ID: <011f01c5d98a$e9292830$de849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Marco Ruffini" , References: <002a01c5d985$73511aa0$1737e286@PC> Subject: Re: draft-ietf-ccamp-lmp-10 comments Date: Tue, 25 Oct 2005 18:38:19 +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: 25 Oct 2005 17:35:29.0640 (UTC) FILETIME=[7E3A6E80:01C5D98A] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 93e7fb8fef2e780414389440f367c879 Content-Transfer-Encoding: 7bit Hi Marco, I think the first quote comes from a paragraph that begins "A unique characteristic of transparent devices" making clear that this text applies specifically to transparent devices, while the second quote comes from the subsequent paragraph and is more general, applying to opaque and transparent devices (as the text later in that paragraph makes clear). Thus there is no contradiction. The question may be phrased another way. In the case that you have a transparent switch, how will you send a test signal on a link? The answer is usually: I will turn off all signals except for the one I am testing. That means two things... 1. You need to turn off all other signals at the sender 2. You must not transparently forward signals at the receiver (because a. you would not notice the signal and b. the next downstream node would receive the signal) Cheers, Adrian ----- Original Message ----- From: "Marco Ruffini" To: Sent: Tuesday, October 25, 2005 5:59 PM Subject: draft-ietf-ccamp-lmp-10 comments Hi all, I was reading the draft-ietf-ccamp-lmp-10 document and in the paragraph 5 I found a part which is not completely clear to me. Suppose I want to verify the link connectivity between two transparent switches, A and B, where A is the node that initiates the procedure. - One part of the text asserts that "to ensure proper verification of data link connectivity, it is required that until the data links are allocated for user traffic, they must be opaque (i.e., lose their transparency).": from here I understand that node B has to terminate all the ports that are not currently transmitting data (i.e. all the ports that have not been already verified). - On another part I found: "There is no requirement that all data links be terminated simultaneously, but at a minimum, the data links MUST be able to be terminated one at a time": here it looks like B does not have to terminate all the not-yet-verified ports at the same time. However in this case B may not receive a message sent from node A over a certain link even if that link is actually connecting node A to B (in fact the port of B relative to that link may be not terminated in that occasion). Which one is the correct interpretation? Should node B have all the not-yet-verified ports terminated at the same time when node A starts the link verification? This is the text of paragraph 5 I referred to: "A unique characteristic of transparent devices is that the data is not modified or examined in normal operation. This characteristic poses a challenge for validating the connectivity of the data links and establish the label mappings. Therefore, to ensure proper verification of data link connectivity, it is required that until the data links are allocated for user traffic, they must be opaque (i.e., lose their transparency). To support various degrees of opaqueness (e.g., examining overhead bytes, terminating the IP payload, etc.), and hence different mechanisms to transport the Test messages, a Verify Transport Mechanism field is included in the BeginVerify and BeginVerifyAck messages. There is no requirement that all data links be terminated simultaneously, but at a minimum, the data links MUST be able to be terminated one at a time. Furthermore, for the link verification procedure it is assumed that the nodal architecture is designed so that messages can be sent and received over any data link. Note that this requirement is trivial for opaque devices since each data link is electrically terminated and processed before being forwarded to the next opaque device, but that in transparent devices this is an additional requirement." Best Regards, Marco Ruffini. CTVR, Trinity College, Dublin 2, Ireland. Phone: +353-1-608 8442 From kjell.nilsson@signumww.com Tue Oct 25 14:47:19 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUTpP-0005MR-4S for ccamp-archive@megatron.ietf.org; Tue, 25 Oct 2005 14:47:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12046 for ; Tue, 25 Oct 2005 14:47:04 -0400 (EDT) Received: from [203.200.33.226] (helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EUU2O-0005u6-CZ for ccamp-archive@ietf.org; Tue, 25 Oct 2005 15:00:46 -0400 Message-ID: <000001c5d993$7ec22600$0100007f@localhost> From: "Gael Anderson" To: Subject: cheap oem soft shipping //orldwide Date: Tue, 25 Oct 2005 18:51:26 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C5D993.7EC22600" 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.4 (++) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C5D993.7EC22600 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable.TOP.10.NEW.TITLES.ON.SALE.NOW!.1.Office.Pro.2003.2.Adobe.Photoshop.9.0.3.Windows.XP.Pro.4.Adobe.Acrobat.7.Pro.5.Flash.MX.2004.6.Corel.Draw.12.7.Norton.Antivirus.2005.8.Windows.2003.Se ListPrice: $550.00 OurPrice: $69.95 YouSave: $480.05 ( 87%) Availability: Available for INSTANT download! Sales Rank: #1 Average Customer Review: (based on 34 reviews) -------------------------------------------------------------------------------- Microsoft Windows XP Professional by Microsoft ListPrice: $200.00 OurPrice: $49.95 YouSave: $150.05 ( 75%) Availability: Available for INSTANT download! Sales Rank: #2 Average Customer Review: (based on 43 reviews) -------------------------------------------------------------------------------- Adobe Photoshop CS2 V 9.0 by Adobe ListPrice: $599.00 OurPrice: $69.95 YouSave: $529.05 ( 88%) Availability: Available for INSTANT download! Sales Rank: #3 Average Customer Review: (based on 38 reviews) -------------------------------------------------------------------------------- ------=_NextPart_000_0001_01C5D993.7EC22600 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Software

TOP 10 NEW TITLES

 ON SALE NOW!

  1 Office Pro 2003
  2 Adobe Photoshop 9.0
  3 Windows XP Pro
  4 Adobe Acrobat 7 Pro
  5 Flash MX 2004
  6 Corel Draw 12
  7 Norton Antivirus 2005
  8 Windows 2003 Server
  9 Alias Maya 6 Wavefrt
  10 Adobe Illustrator 11
  See more by this manufacturer
    Microsoft
    Symantec
    Adobe

Microsoft Office Professional Edition 2003
   by Microsoft

ListPrice: $550.00
OurPrice: $69.95
YouSave: $480.05 ( 87%)



Availability: Available for INSTANT download!


Sales Rank: #1
Average Customer Review: 3D"5
(based on 39 reviews)

Microsoft Windows XP Professional
   by Microsoft

ListPrice: ! $200.00
OurPrice: $49.95
YouSave: $150.05 ( 75%)



Availability: Available for INSTANT download!


Sales Rank: #2
Average Customer Review: 3D"5
(based on 40 reviews)

Adobe Photoshop CS2 V 9.0
   by Adobe

ListPrice: $599.00
OurPrice: $69.95
YouSave: $529.05 ( 88%)



Availability: Available for INSTANT download!


Sales Rank: #3
Average Customer Review: 3D"5
(based on 48 reviews)

------=_NextPart_000_0001_01C5D993.7EC22600-- From info@mail.iajp.com Tue Oct 25 16:52:57 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUVmy-0004AX-Oo for ccamp-archive@megatron.ietf.org; Tue, 25 Oct 2005 16:52:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10795 for ; Tue, 25 Oct 2005 16:52:40 -0400 (EDT) Received: from [125.57.107.167] (helo=mail.iajp.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EUVzy-0000Ws-Ok for ccamp-archive@ietf.org; Tue, 25 Oct 2005 17:06:23 -0400 Received: (qmail 18085 invoked by uid 510); 25 Oct 2005 23:29:03 +0900 Date: 25 Oct 2005 23:29:03 +0900 Message-ID: <20051025142903.18084.qmail@mail.iajp.com> From: info@iajp.com To: ccamp-archive@ietf.org Subject: $B?7HVAH%[%9%HJg=8!*(B X-Spam-Score: 3.8 (+++) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f $B$3$NEY?7$7$$HVAH$,;O$^$j$^$7$?!#$=$3$G5U1o%[%9%H$rJg=8$7$^$9!#(B $B;E;vFbMF$O$?$@HVAH$NCf$G=w@-2q0w$HOC$r$9$k$@$1!*!*(B $B40A4Jb9g@)$G$9$N$G$"$J$?$NOS(B http://www.gyakuten5.net/?baito $B%a!<%k; Tue, 25 Oct 2005 18:48:37 -0400 (EDT) Received: from [125.57.107.137] (helo=mail.htqj.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EUXoD-00055s-KQ for ccamp-archive@ietf.org; Tue, 25 Oct 2005 19:02:22 -0400 Received: (qmail 14065 invoked by uid 510); 26 Oct 2005 00:07:13 +0900 Date: 26 Oct 2005 00:07:13 +0900 Message-ID: <20051025150713.14064.qmail@mail.htqj.com> From: info@htqj.com To: ccamp-archive@ietf.org Subject: $B%"!; Tue, 25 Oct 2005 18:58:05 -0400 (EDT) Received: from [125.57.106.224] (helo=mail.fgqn.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EUXxN-0005sn-S7 for ccamp-archive@ietf.org; Tue, 25 Oct 2005 19:11:50 -0400 Received: (qmail 7685 invoked by uid 510); 25 Oct 2005 23:13:20 +0900 Date: 25 Oct 2005 23:13:20 +0900 Message-ID: <20051025141320.7684.qmail@mail.fgqn.com> From: info@fgqn.com To: ccamp-archive@ietf.org Subject: $B=C4/9%$-$G$9'f(B X-Spam-Score: 3.5 (+++) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 $BFMA3$9$_$^$;$s!##2#7:P$N(BOL$B%j%($G$9!#(B $B@'Hs!"$"$J$?$,;t$C$F$$$kF0J*$H8rHx$5$;$F2<$5$$!#(B $B=PMh$l$PBg$-$$F0J*$,4uK>$G$9!#(B $BNY$G8+$F$F$b$$$$$G$9$h!#!J$J$s$F!K(B $B0l1~; Tue, 25 Oct 2005 18:58:36 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUXxs-0005xe-QZ for ccamp-archive@ietf.org; Tue, 25 Oct 2005 19:12:21 -0400 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EUXcJ-000Pnu-NE for ccamp-data@psg.com; Tue, 25 Oct 2005 22:50:03 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=3.1.0 Received: from [132.151.6.50] (helo=newodin.ietf.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1EUXcI-000PnK-UZ for ccamp@ops.ietf.org; Tue, 25 Oct 2005 22:50:03 +0000 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EUXcH-0004Q3-TV; Tue, 25 Oct 2005 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-rsvp-restart-ext-05.txt Message-Id: Date: Tue, 25 Oct 2005 18:50:01 -0400 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.4 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 --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 GMPLS RSVP Graceful Restart Author(s) : A. Satyanarayana, R. Rahman Filename : draft-ietf-ccamp-rsvp-restart-ext-05.txt Pages : 24 Date : 2005-10-25 This document describes extensions to the RSVP Graceful Restart mechanisms defined in RFC 3473. The extensions enable the recovery of RSVP signaling state based on the Path message last sent by the node being restarted. Previously defined Graceful Restart mechanisms, also called recovery from nodal faults, permit recovery of signaling state from adjacent nodes when the data plane has retained the associated forwarding state across a restart. These mechanisms do not fully support signaling state recovery on ingress nodes or recovery of all RSVP objects. The presented extensions use the RSVP Hello extensions defined in RFC 3209, and extensions for state recovery on nodal faults defined in RFC 3473. With the presented extensions the restarting node can recover all previously transmitted Path state including the Explicit Route Object and the downstream (outgoing) interface identifiers. The extensions can also be used to recover signaling state after the restart of an ingress node. The extensions optionally support the use of Summary Refresh, defined in RFC 2961, to reduce the number of messages exchanged during the Recovery Phase when the restarting node has recovered signaling state locally for one or more LSPs. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rsvp-restart-ext-05.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-rsvp-restart-ext-05.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-rsvp-restart-ext-05.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: <2005-10-25161743.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-rsvp-restart-ext-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-rsvp-restart-ext-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-10-25161743.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ccamp@ops.ietf.org Tue Oct 25 22:53:50 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUbQE-0008KT-GN for ccamp-archive@megatron.ietf.org; Tue, 25 Oct 2005 22:53:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16125 for ; Tue, 25 Oct 2005 22:53:35 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUbdI-0007mP-T5 for ccamp-archive@ietf.org; Tue, 25 Oct 2005 23:07:21 -0400 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EUbK9-000KOF-8W for ccamp-data@psg.com; Wed, 26 Oct 2005 02:47:33 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [207.17.137.64] (helo=colo-dns-ext2.juniper.net) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.52 (FreeBSD)) id 1EUbK6-000KO0-Ds for ccamp@ops.ietf.org; Wed, 26 Oct 2005 02:47:30 +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 j9Q2lLBm018042; Tue, 25 Oct 2005 19:47:21 -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 j9Q2lKG38594; Tue, 25 Oct 2005 19:47:21 -0700 (PDT) (envelope-from arthi@juniper.net) Date: Tue, 25 Oct 2005 19:47:20 -0700 (PDT) From: Arthi Ayyangar To: Igor Bryskin cc: Adrian Farrel , jpv@cisco.com, ccamp@ops.ietf.org Subject: Re: I-D ACTION:draft-ietf-ccamp-inter-domain-pd-path-comp-01.txt In-Reply-To: <010201c5d679$ec6f9650$6601a8c0@movaz.com> Message-ID: <20051025192049.T10870@zircon.juniper.net> References: <007a01c5d653$ec5302e0$6601a8c0@movaz.com> <028501c5d66c$3d075570$ca00470a@Puppy> <010201c5d679$ec6f9650$6601a8c0@movaz.com> 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: f0b5a4216bfa030ed8a6f68d1833f8ae Hi Igor, Just to reiterate what Adrian said, this ID is only intended to cover the case where you do not have a PCE. I do, however, agree with what you say below in "The bottom line". thanks, -arthi > The bottom line: when PCE is available one should never consult IP routing > to determine the outgoing border node when one performs per-domain path > computation. If PCE is not available, than in case of IP network, I agree, > there is a value to consult IP routing. This is because in IP world TE > resources are still tightly coupled with IP interfaces. In the non-IP world, > I'd say, consulting IP routing makes much lesser sense: it could give you a > path when no TE path exists or, more importantly, fail the request when one > or more TE paths do exist. I'd suggest in this case rather than consulting > IP (which is as useful IMO as consulting somebody's Outlook address book) to > route the LSP towards any known domain border node and hope that the latter > will crankback the request specifying the proper border node if necessary. > > > > Cheers, > > Igor > > > > ----- Original Message ----- > From: "Adrian Farrel" > To: "Igor Bryskin" ; ; "Arthi Ayyangar" > > Cc: > Sent: Friday, October 21, 2005 2:20 PM > Subject: Re: I-D ACTION:draft-ietf-ccamp-inter-domain-pd-path-comp-01.txt > > >> Hi Igor, >> >> I think you have to set the context of this I-D carefully, and then >> understand the limited scope that is additionally proposed. >> >> The context of the I-D is limited to the per-domain computation case. >> Hence, consulting an external PCE is out of scope. This is not to say that >> it is not valid to consult a PCE (in fact, you might expect JP and me to >> support that technique), but this I-D is demonstrating what we can do and >> how we can solve the problem without using PCE. >> >> With respect to the use of the IP reachability, you may recall that I >> raised this concern in Paris and on the list. The conclusion was that if >> you have no other way of determining an exit router for your domain, then >> attempting to use the IP reachability is no worse than giving up, and may >> be much better. >> >> In the cases you raise: >> 1. Yes, an interface address may be unreachable. >> Do we lose anything by consulting IP reachability in this case? >> No. >> 2. Yes, the IP reachability may give us a sub-optimal TE path. >> Is this path worse than no path? >> No. >> >> So I asked the authors to be clear that what they are suggesting has >> limitations, and should not be applied in some specific cases. I haven't >> looked at the text yet, but I hope they have covered this. >> >> Cheers, >> Adrian >> ----- Original Message ----- >> From: "Igor Bryskin" >> To: ; "Arthi Ayyangar" >> Cc: >> Sent: Friday, October 21, 2005 4:27 PM >> Subject: Re: I-D ACTION:draft-ietf-ccamp-inter-domain-pd-path-comp-01.txt >> >> >>> Arthi, JP >>> >>> >>> >>> I have a problem with the auto-discovery mechanism you described in the >>> draft (one that is based on query to IGP or BGP to determine outgoing >>> ABR/ASBR). >>> >>> >>> >>> 1. Destination ID must be network unique but it does not have to be IP >>> routable, for example, it could be a numbered link ID. >>> >>> 2. Even in case when destination is IP address, the path computing node >> can >>> only obtain the ID of an ABR or ASBR that advertises IP route to the >>> destination, which would be one that knows about the shortest IP path to >> the >>> destination. However, it does not mean that properly constrained TE path >>> from this ABR/ASBR to the destination or the next ABR/ASBR exist, or is >> not >>> suboptimal compared to one from some other ABR/ASBR which knows about >> worse >>> IP path to the destination and hence will not be reported to the >> computing >>> entity by the routing sub-system. >>> >>> >>> >>> I wonder why not to use the remote PCE service for this purpose. For >>> instance a PCC may ask a PCE to determine either the ID of the outgoing >>> domain border node or entire path in terms of domain border nodes. You >> may >>> ask why not to request explicit path(s) in this case? Several reasons >> why >>> the PCC wouldn't want to do so: >>> >>> >>> >>> a) it could be easier and faster for the PCE to determine domain border >> node >>> in direction towards the destination rather than explicit path(s). For >>> instance, the latter may require cooperation of other PCEs; >>> >>> >>> >>> b) security considerations - PCE may not want to reveal remote domain >>> topology(ies) >>> >>> >>> >>> c) it may be desirable to compute and setup services on per-domain >> basis, >>> for instance, to have each domain take separate care for service >>> restoration. >>> >>> >>> >>> What do you think? >>> >>> >>> >>> Igor >>> >>> >>> >>> ----- Original Message ----- >>> >>> From: >>> >>> To: >>> >>> Cc: >>> >>> Sent: Thursday, October 20, 2005 6:50 PM >>> >>> Subject: I-D ACTION:draft-ietf-ccamp-inter-domain-pd-path-comp-01.txt >>> >>> >>> >>>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>>> This draft is a work item of the Common Control and Measurement Plane >>> Working Group of the IETF. >>>> >>>> Title : A Per-domain path computation method for establishing >>>> Inter-domain Traffic Engineering (TE) Label >>> Switched Paths (LSPs) >>>> Author(s) : J. Vasseur, et al. >>>> Filename : draft-ietf-ccamp-inter-domain-pd-path-comp-01.txt >>>> Pages : 18 >>>> Date : 2005-10-20 >>>> >>>> This document specifies a per-domain path computation technique for >>>> establishing inter-domain Traffic Engineering (TE) Multiprotocol Label >>>> Switching (MPLS) and Generalized MPLS (GMPLS) Label Switched Paths >>>> (LSPs). In this document a domain refers to a collection of network >>>> elements within a common sphere of address management or path >>>> computational responsibility such as IGP areas and Autonomous Systems. >>>> >>>> Per-domain computation applies where the full path of an inter-domain >>>> TE LSP cannot be or is not determined at the ingress node of the TE >>>> LSP, and is not signaled across domain boundaries. This is most likely >>>> to arise owing to TE visibility limitations. The signaling message >>>> indicates the destination and nodes up to the next domain boundary. It >>>> may also indicate further domain boundaries or domain identifiers. The >>>> path through each domain, possibly including the choice of exit point >>>> from the domain, must be determined within the domain. >>>> >>>> A URL for this Internet-Draft is: >>>> >>> >> > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-inter-domain-pd-path-comp-01.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-inter-domain-pd-path-comp-01.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-inter-domain-pd-path-comp-01.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. >>>> >>> >>> >>> >>> >> > From owner-ccamp@ops.ietf.org Wed Oct 26 06:30:24 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUiY4-0005X7-I4 for ccamp-archive@megatron.ietf.org; Wed, 26 Oct 2005 06:30:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10192 for ; Wed, 26 Oct 2005 06:30:08 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUilC-0004ba-IB for ccamp-archive@ietf.org; Wed, 26 Oct 2005 06:43:59 -0400 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EUiPd-000Irl-SW for ccamp-data@psg.com; Wed, 26 Oct 2005 10:21:41 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.0 Received: from [62.241.162.32] (helo=ranger.systems.pipex.net) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EUiPa-000IqU-S2 for ccamp@ops.ietf.org; Wed, 26 Oct 2005 10:21:39 +0000 Received: from dnni.com (81-178-2-190.dsl.pipex.com [81.178.2.190]) by ranger.systems.pipex.net (Postfix) with ESMTP id E1F02E0003A0; Wed, 26 Oct 2005 11:21:28 +0100 (BST) Received: from Puppy ([217.158.132.20] RDNS failed) by dnni.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 26 Oct 2005 11:13:14 +0100 Message-ID: <026401c5da16$4d552ad0$de849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Cc: "WG Milestone Tracker" , "Bill Fenner" , Subject: Publication request: draft-ietf-ccamp-rsvp-restart-ext-05.txt Date: Wed, 26 Oct 2005 11:12:19 +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: 26 Oct 2005 10:13:16.0085 (UTC) FILETIME=[E168FE50:01C5DA15] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: 7bit Hi Alex, This I-D has been through CCAMP working group last call (twice) and has been updated to my satisfaction. Could you please add it to the pile pending publication. Thanks, Adrian ----- Original Message ----- From: To: Cc: Sent: Tuesday, October 25, 2005 11:50 PM Subject: I-D ACTION:draft-ietf-ccamp-rsvp-restart-ext-05.txt > Title : Extensions to GMPLS RSVP Graceful Restart > Author(s) : A. Satyanarayana, R. Rahman > Filename : draft-ietf-ccamp-rsvp-restart-ext-05.txt > Pages : 24 > Date : 2005-10-25 > > This document describes extensions to the RSVP Graceful Restart > mechanisms defined in RFC 3473. The extensions enable the recovery > of RSVP signaling state based on the Path message last sent by the > node being restarted. Previously defined Graceful Restart > mechanisms, also called recovery from nodal faults, permit recovery > of signaling state from adjacent nodes when the data plane has > retained the associated forwarding state across a restart. These > mechanisms do not fully support signaling state recovery on ingress > nodes or recovery of all RSVP objects. The presented extensions use > the RSVP Hello extensions defined in RFC 3209, and extensions for > state recovery on nodal faults defined in RFC 3473. With the > presented extensions the restarting node can recover all previously > transmitted Path state including the Explicit Route Object and the > downstream (outgoing) interface identifiers. The extensions can also > be used to recover signaling state after the restart of an ingress > node. The extensions optionally support the use of Summary Refresh, > defined in RFC 2961, to reduce the number of messages exchanged > during the Recovery Phase when the restarting node has recovered > signaling state locally for one or more LSPs. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rsvp-restart-ext-05.txt From owner-ccamp@ops.ietf.org Wed Oct 26 07:36:57 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUjaS-0003p7-QW for ccamp-archive@megatron.ietf.org; Wed, 26 Oct 2005 07:36:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13000 for ; Wed, 26 Oct 2005 07:36:40 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUjnZ-0006R1-2N for ccamp-archive@ietf.org; Wed, 26 Oct 2005 07:50:32 -0400 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EUjUr-000N0A-Mw for ccamp-data@psg.com; Wed, 26 Oct 2005 11:31:09 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.0 Received: from [62.241.162.31] (helo=galaxy.systems.pipex.net) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EUjUn-000Mzo-Jd for ccamp@ops.ietf.org; Wed, 26 Oct 2005 11:31:05 +0000 Received: from dnni.com (81-178-2-190.dsl.pipex.com [81.178.2.190]) by galaxy.systems.pipex.net (Postfix) with ESMTP id ADDABE0001F6 for ; Wed, 26 Oct 2005 12:30:57 +0100 (BST) Received: from Puppy ([217.158.132.141] RDNS failed) by dnni.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 26 Oct 2005 12:26:46 +0100 Message-ID: <029001c5da20$90712530$de849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Correspondence from OIF Date: Wed, 26 Oct 2005 11:28:46 +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: 26 Oct 2005 11:26:47.0809 (UTC) FILETIME=[2700A710:01C5DA20] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 Content-Transfer-Encoding: 7bit Hi, Please find below the text of a correspondence from the OIF. This will be posted on the alternate CCAMP pages at http://www.olddog.co.uk/ccamp.htm No response is required, but we should follow up with RFC3946-bis and through the GELS BoF. Cheers, Adrian =========== To: Adrian Farrel and Kireeti Kompella, IETF CCAMP WG Co-Chairs From: Jim Jones, OIF TC Chair Copy: Alex Zinin and Bill Fenner, IETF Routing Area Directors Subject: Follow up questions concerning GMPLS parameters Dear Adrian and Kireeti, OIF very much appreciates your help with our questions concerning GMPLS parameters in your response liaison of October 2005. After discussion of your liaison letter, we had a number of follow-up questions (issues are numbered as in our liaison of July 2005): 1. NCC and RCC field values for STS-3c/VC-4 connections The revision to RFC 3946 proposed by CCAMP looks acceptable to us. We also agree that the receiving entity should be liberal in what it accepts, i.e., either 0 or 1 should be accepted at the receiver. We would ideally prefer that a single value be identified as the "recommended" value to use by the sender, to further remove any potential interoperability issue. 2. Setting of NVC for VCAT connections It is our understanding from CCAMP's response that NVC is always >0 for VCAT setup, e.g., if a single connection is being set up as part of a larger VCAT connection, the value NVC=1 would be used in the PATH message. We note that there may be more complex scenarios that need to be considered, such as connections being set up initially without being part of a VCAT group and subsequently being added to a VCAT group. An ITU-T Liaison with related discussion has been received by us and was also copied to CCAMP. 3. Length of the Switching Capability Descriptor We appreciate the verification from CCAMP. 4. Use of ADMIN_STATUS in the PATH message We appreciate CCAMP's advice. 5. Handling of multiple received ResvConf Request objects It is our understanding from CCAMP's response that a ResvConf Request object received in the Resv message should only trigger sending of the ResvConf message if there is a change in the Resv message, i.e., it is not a refresh message. If in fact it is desirable to trigger a new ResvConf message without making a change to an existing session and associated connection, we believe that a possible mechanism for doing this is to first send a Resv message removing the ResvConf Request object and then send a subsequent Resv message with the ResvConf Request object reinserted, thus differentiating the request from a refresh. We also noted the advice that the ADMIN_STATUS object offers a reliable mechanism as an alternative to ResvConf, however are unclear as to the procedure for triggering ADMIN_STATUS, for example, to determine when the originating endpoint is ready to receive signal during connection setup. 6. Symmetry of Refresh Reduction We appreciate the clarification from CCAMP. 7. Sending of ACKs bundled with RSVP Hello We appreciate the clarification from CCAMP. We did in fact mean "piggybacking" of ACKs with the Hello message, which we now understand is prohibited based on RFC 3209. 8. TSPEC format for Ethernet We appreciate CCAMP's interest in OIF requirements for Ethernet connection control. As a result of discussions within OIF and review of ITU-T G.8011 and MEF.6 and MEF.10, we have identified the following attributes as requiring support in signaling to specify the Ethernet bandwidth profile and request that CCAMP identify a mechanism for carrying this in the protocol, e.g., a new Sender_Tspec/Flowspec format for Ethernet : CIR (Committed Information Rate): Maximum rate required under normal conditions, service level guaranteed. CBS (Committed Burst Size): Limits the number of bytes for a burst while conforming to CIR. EIR (Excess Information Rate): Maximum rate required under burst conditions, no guarantee of performance. EBS (Excess Burst Size): Limits the number of bytes for a burst while conforming to EIR. CF (Coupling Flag) and CM (Colour Mode): Give a choice for different modes of operation. These are defined in the following references: 1.. [1] Metro Ethernet Forum, MEF.10 - Ethernet Services Attributes Phase 1, Nov. 2004 2.. [2] ITU-T Recommendation G.8011/Y.1307 (2004), Am. 1 (2005), "Ethernet Services Framework". We would like to also bring to CCAMP's attention that MEF has defined as set of TLVs for these attributes for use in their E-LMI (Ethernet Link Management Interface) specification and these may be of use to CCAMP in its work. Best regards, Jim Jones OIF Technical Committee Chair From owner-ccamp@ops.ietf.org Wed Oct 26 10:17:43 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUm63-0000pY-2L for ccamp-archive@megatron.ietf.org; Wed, 26 Oct 2005 10:17:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22540 for ; Wed, 26 Oct 2005 10:17:27 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUmJD-0003Fy-HA for ccamp-archive@ietf.org; Wed, 26 Oct 2005 10:31:20 -0400 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EUltB-0007B8-VI for ccamp-data@psg.com; Wed, 26 Oct 2005 14:04:25 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [70.158.43.219] (helo=jera.movaz.com) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EUltA-0007Au-Dm for ccamp@ops.ietf.org; Wed, 26 Oct 2005 14:04:24 +0000 Received: from ib (unknown [172.16.24.122]) by jera.movaz.com (Postfix) with SMTP id 7A9DD140EB; Wed, 26 Oct 2005 10:04:19 -0400 (EDT) Message-ID: <005101c5da36$19b30920$7a1810ac@movaz.com> From: "Igor Bryskin" To: "Arthi Ayyangar" Cc: "Adrian Farrel" , , References: <007a01c5d653$ec5302e0$6601a8c0@movaz.com> <028501c5d66c$3d075570$ca00470a@Puppy> <010201c5d679$ec6f9650$6601a8c0@movaz.com> <20051025192049.T10870@zircon.juniper.net> Subject: Re: I-D ACTION:draft-ietf-ccamp-inter-domain-pd-path-comp-01.txt Date: Wed, 26 Oct 2005 10:03:54 -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: 96d3a783a4707f1ab458eb15058bb2d7 Content-Transfer-Encoding: 7bit Arthi, I think we are in complete agreement here. Igor ----- Original Message ----- From: "Arthi Ayyangar" To: "Igor Bryskin" Cc: "Adrian Farrel" ; ; Sent: Tuesday, October 25, 2005 10:47 PM Subject: Re: I-D ACTION:draft-ietf-ccamp-inter-domain-pd-path-comp-01.txt > Hi Igor, > > Just to reiterate what Adrian said, this ID is only intended to cover the > case where you do not have a PCE. > > I do, however, agree with what you say below in "The bottom line". > > thanks, > -arthi > > > > The bottom line: when PCE is available one should never consult IP routing > > to determine the outgoing border node when one performs per-domain path > > computation. If PCE is not available, than in case of IP network, I agree, > > there is a value to consult IP routing. This is because in IP world TE > > resources are still tightly coupled with IP interfaces. In the non-IP world, > > I'd say, consulting IP routing makes much lesser sense: it could give you a > > path when no TE path exists or, more importantly, fail the request when one > > or more TE paths do exist. I'd suggest in this case rather than consulting > > IP (which is as useful IMO as consulting somebody's Outlook address book) to > > route the LSP towards any known domain border node and hope that the latter > > will crankback the request specifying the proper border node if necessary. > > > > > > > > Cheers, > > > > Igor > > > > > > > > ----- Original Message ----- > > From: "Adrian Farrel" > > To: "Igor Bryskin" ; ; "Arthi Ayyangar" > > > > Cc: > > Sent: Friday, October 21, 2005 2:20 PM > > Subject: Re: I-D ACTION:draft-ietf-ccamp-inter-domain-pd-path-comp-01.txt > > > > > >> Hi Igor, > >> > >> I think you have to set the context of this I-D carefully, and then > >> understand the limited scope that is additionally proposed. > >> > >> The context of the I-D is limited to the per-domain computation case. > >> Hence, consulting an external PCE is out of scope. This is not to say that > >> it is not valid to consult a PCE (in fact, you might expect JP and me to > >> support that technique), but this I-D is demonstrating what we can do and > >> how we can solve the problem without using PCE. > >> > >> With respect to the use of the IP reachability, you may recall that I > >> raised this concern in Paris and on the list. The conclusion was that if > >> you have no other way of determining an exit router for your domain, then > >> attempting to use the IP reachability is no worse than giving up, and may > >> be much better. > >> > >> In the cases you raise: > >> 1. Yes, an interface address may be unreachable. > >> Do we lose anything by consulting IP reachability in this case? > >> No. > >> 2. Yes, the IP reachability may give us a sub-optimal TE path. > >> Is this path worse than no path? > >> No. > >> > >> So I asked the authors to be clear that what they are suggesting has > >> limitations, and should not be applied in some specific cases. I haven't > >> looked at the text yet, but I hope they have covered this. > >> > >> Cheers, > >> Adrian > >> ----- Original Message ----- > >> From: "Igor Bryskin" > >> To: ; "Arthi Ayyangar" > >> Cc: > >> Sent: Friday, October 21, 2005 4:27 PM > >> Subject: Re: I-D ACTION:draft-ietf-ccamp-inter-domain-pd-path-comp-01.txt > >> > >> > >>> Arthi, JP > >>> > >>> > >>> > >>> I have a problem with the auto-discovery mechanism you described in the > >>> draft (one that is based on query to IGP or BGP to determine outgoing > >>> ABR/ASBR). > >>> > >>> > >>> > >>> 1. Destination ID must be network unique but it does not have to be IP > >>> routable, for example, it could be a numbered link ID. > >>> > >>> 2. Even in case when destination is IP address, the path computing node > >> can > >>> only obtain the ID of an ABR or ASBR that advertises IP route to the > >>> destination, which would be one that knows about the shortest IP path to > >> the > >>> destination. However, it does not mean that properly constrained TE path > >>> from this ABR/ASBR to the destination or the next ABR/ASBR exist, or is > >> not > >>> suboptimal compared to one from some other ABR/ASBR which knows about > >> worse > >>> IP path to the destination and hence will not be reported to the > >> computing > >>> entity by the routing sub-system. > >>> > >>> > >>> > >>> I wonder why not to use the remote PCE service for this purpose. For > >>> instance a PCC may ask a PCE to determine either the ID of the outgoing > >>> domain border node or entire path in terms of domain border nodes. You > >> may > >>> ask why not to request explicit path(s) in this case? Several reasons > >> why > >>> the PCC wouldn't want to do so: > >>> > >>> > >>> > >>> a) it could be easier and faster for the PCE to determine domain border > >> node > >>> in direction towards the destination rather than explicit path(s). For > >>> instance, the latter may require cooperation of other PCEs; > >>> > >>> > >>> > >>> b) security considerations - PCE may not want to reveal remote domain > >>> topology(ies) > >>> > >>> > >>> > >>> c) it may be desirable to compute and setup services on per-domain > >> basis, > >>> for instance, to have each domain take separate care for service > >>> restoration. > >>> > >>> > >>> > >>> What do you think? > >>> > >>> > >>> > >>> Igor > >>> > >>> > >>> > >>> ----- Original Message ----- > >>> > >>> From: > >>> > >>> To: > >>> > >>> Cc: > >>> > >>> Sent: Thursday, October 20, 2005 6:50 PM > >>> > >>> Subject: I-D ACTION:draft-ietf-ccamp-inter-domain-pd-path-comp-01.txt > >>> > >>> > >>> > >>>> A New Internet-Draft is available from the on-line Internet-Drafts > >>> directories. > >>>> This draft is a work item of the Common Control and Measurement Plane > >>> Working Group of the IETF. > >>>> > >>>> Title : A Per-domain path computation method for establishing > >>>> Inter-domain Traffic Engineering (TE) Label > >>> Switched Paths (LSPs) > >>>> Author(s) : J. Vasseur, et al. > >>>> Filename : draft-ietf-ccamp-inter-domain-pd-path-comp-01.txt > >>>> Pages : 18 > >>>> Date : 2005-10-20 > >>>> > >>>> This document specifies a per-domain path computation technique for > >>>> establishing inter-domain Traffic Engineering (TE) Multiprotocol Label > >>>> Switching (MPLS) and Generalized MPLS (GMPLS) Label Switched Paths > >>>> (LSPs). In this document a domain refers to a collection of network > >>>> elements within a common sphere of address management or path > >>>> computational responsibility such as IGP areas and Autonomous Systems. > >>>> > >>>> Per-domain computation applies where the full path of an inter-domain > >>>> TE LSP cannot be or is not determined at the ingress node of the TE > >>>> LSP, and is not signaled across domain boundaries. This is most likely > >>>> to arise owing to TE visibility limitations. The signaling message > >>>> indicates the destination and nodes up to the next domain boundary. It > >>>> may also indicate further domain boundaries or domain identifiers. The > >>>> path through each domain, possibly including the choice of exit point > >>>> from the domain, must be determined within the domain. > >>>> > >>>> A URL for this Internet-Draft is: > >>>> > >>> > >> > > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-inter-domain-pd-path-comp-01.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-inter-domain-pd-path-comp-01.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-inter-domain-pd-path-comp-01.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. > >>>> > >>> > >>> > >>> > >>> > >> > > From owner-ccamp@ops.ietf.org Wed Oct 26 12:53:31 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUoWp-0006WD-7m for ccamp-archive@megatron.ietf.org; Wed, 26 Oct 2005 12:53:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07009 for ; Wed, 26 Oct 2005 12:53:15 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUojz-0001b1-H0 for ccamp-archive@ietf.org; Wed, 26 Oct 2005 13:07:09 -0400 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EUoMQ-000Hyg-4W for ccamp-data@psg.com; Wed, 26 Oct 2005 16:42:46 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.0 Received: from [62.241.163.7] (helo=blaster.systems.pipex.net) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EUoMP-000HyT-87 for ccamp@ops.ietf.org; Wed, 26 Oct 2005 16:42:45 +0000 Received: from dnni.com (81-178-2-190.dsl.pipex.com [81.178.2.190]) by blaster.systems.pipex.net (Postfix) with ESMTP id 7580CE00026C for ; Wed, 26 Oct 2005 17:42:34 +0100 (BST) Received: from Puppy ([217.158.132.59] RDNS failed) by dnni.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 26 Oct 2005 17:37:00 +0100 Message-ID: <038601c5da4b$ea570120$de849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Draft agenda Date: Wed, 26 Oct 2005 17:39:54 +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: 26 Oct 2005 16:37:01.0403 (UTC) FILETIME=[7D91B2B0:01C5DA4B] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: 7bit Hi, You can see a draft agenda at http://www3.ietf.org/proceedings/05nov/agenda/ccamp.txt You'll notice it is pretty full (again). Our objective in formulating this agenda has been to prompt discussion that will make valuable use of face-to-face meeting time. Presentation of what is in your draft is not the main reason for addressing the room: you should be seeking input and discussion. In order to make this work a bit better than previously, the agenda is interspersed with questions that we want you to raise *not* answer. That is, you should be leading the discussion that will help the room debate and discuss these questions. If you turn up and just answer the questions leaving no room for discussion (or worse if you just present your draft) I will allow Kireeti to bite you. I know that there will be a few of you disappointed not to have your topics/drafts on the agenda. our decisions were made based on what we feel needs face-to-face discussion. In particular, if you have a new revision of an existing I-D that has progressed but has not made any radical changes, we will probably have left you off. Also, if you have a new I-D that has not been discussed on the mailing list, we may also have left you off. Thanks, Adrian PS We are very nearly there with a new set of milestones for CCAMP. This has reached the secretariat and should be up on the web page soon. PPS Don't forget the GELS BoF (GMPLS controlled Ethernet Label Switching) that is very relevant to several drafts first raised in CCAMP From owner-ccamp@ops.ietf.org Wed Oct 26 13:29:34 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUp5h-0000h6-LX for ccamp-archive@megatron.ietf.org; Wed, 26 Oct 2005 13:29:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08991 for ; Wed, 26 Oct 2005 13:29:17 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUpIr-0002h4-Th for ccamp-archive@ietf.org; Wed, 26 Oct 2005 13:43:12 -0400 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EUoz6-000KTF-9s for ccamp-data@psg.com; Wed, 26 Oct 2005 17:22:44 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00, DATE_IN_PAST_24_48 autolearn=no version=3.1.0 Received: from [64.102.122.148] (helo=rtp-iport-1.cisco.com) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EUoz0-000KSu-Jd for ccamp@ops.ietf.org; Wed, 26 Oct 2005 17:22:40 +0000 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 26 Oct 2005 10:22:38 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.97,254,1125903600"; d="scan'208"; a="13942826:sNHT26344612" 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 j9QHMI2H016114; Wed, 26 Oct 2005 13:22:34 -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); Wed, 26 Oct 2005 13:22:33 -0400 Received: from [161.44.65.166] ([161.44.65.166]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 26 Oct 2005 13:22:33 -0400 In-Reply-To: <20051025192049.T10870@zircon.juniper.net> References: <007a01c5d653$ec5302e0$6601a8c0@movaz.com> <028501c5d66c$3d075570$ca00470a@Puppy> <010201c5d679$ec6f9650$6601a8c0@movaz.com> <20051025192049.T10870@zircon.juniper.net> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0A644684-BDF3-43E4-845C-4C55AC97D5D9@cisco.com> Cc: Igor Bryskin , Adrian Farrel , "JP Vasseur (Cisco)" , ccamp@ops.ietf.org, Arthi Ayyangar Content-Transfer-Encoding: 7bit From: JP Vasseur Subject: Re: I-D ACTION:draft-ietf-ccamp-inter-domain-pd-path-comp-01.txt Date: Tue, 25 Oct 2005 09:51:42 -0400 To: Igor Bryskin X-Mailer: Apple Mail (2.734) X-OriginalArrivalTime: 26 Oct 2005 17:22:33.0480 (UTC) FILETIME=[DA039080:01C5DA51] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 46ad68ada464411807db2a0edd5648ae Content-Transfer-Encoding: 7bit Hi Igor, On Oct 25, 2005, at 10:47 PM, Arthi Ayyangar wrote: > Hi Igor, > > Just to reiterate what Adrian said, this ID is only intended to > cover the case where you do not have a PCE. > As I told you before the PCE case used to be in scenario 2 of the former inter-domain draft and will be resurrected and discussed in the PCE WG for IETF-65. JP. > I do, however, agree with what you say below in "The bottom line". > > thanks, > -arthi > > > >> The bottom line: when PCE is available one should never consult IP >> routing >> to determine the outgoing border node when one performs per-domain >> path >> computation. If PCE is not available, than in case of IP network, >> I agree, >> there is a value to consult IP routing. This is because in IP >> world TE >> resources are still tightly coupled with IP interfaces. In the non- >> IP world, >> I'd say, consulting IP routing makes much lesser sense: it could >> give you a >> path when no TE path exists or, more importantly, fail the request >> when one >> or more TE paths do exist. I'd suggest in this case rather than >> consulting >> IP (which is as useful IMO as consulting somebody's Outlook >> address book) to >> route the LSP towards any known domain border node and hope that >> the latter >> will crankback the request specifying the proper border node if >> necessary. >> >> >> >> Cheers, >> >> Igor >> >> >> >> ----- Original Message ----- >> From: "Adrian Farrel" >> To: "Igor Bryskin" ; ; "Arthi >> Ayyangar" >> >> Cc: >> Sent: Friday, October 21, 2005 2:20 PM >> Subject: Re: I-D ACTION:draft-ietf-ccamp-inter-domain-pd-path- >> comp-01.txt >> >> >> >>> Hi Igor, >>> >>> I think you have to set the context of this I-D carefully, and then >>> understand the limited scope that is additionally proposed. >>> >>> The context of the I-D is limited to the per-domain computation >>> case. >>> Hence, consulting an external PCE is out of scope. This is not to >>> say that >>> it is not valid to consult a PCE (in fact, you might expect JP >>> and me to >>> support that technique), but this I-D is demonstrating what we >>> can do and >>> how we can solve the problem without using PCE. >>> >>> With respect to the use of the IP reachability, you may recall >>> that I >>> raised this concern in Paris and on the list. The conclusion was >>> that if >>> you have no other way of determining an exit router for your >>> domain, then >>> attempting to use the IP reachability is no worse than giving up, >>> and may >>> be much better. >>> >>> In the cases you raise: >>> 1. Yes, an interface address may be unreachable. >>> Do we lose anything by consulting IP reachability in this case? >>> No. >>> 2. Yes, the IP reachability may give us a sub-optimal TE path. >>> Is this path worse than no path? >>> No. >>> >>> So I asked the authors to be clear that what they are suggesting has >>> limitations, and should not be applied in some specific cases. I >>> haven't >>> looked at the text yet, but I hope they have covered this. >>> >>> Cheers, >>> Adrian >>> ----- Original Message ----- >>> From: "Igor Bryskin" >>> To: ; "Arthi Ayyangar" >>> Cc: >>> Sent: Friday, October 21, 2005 4:27 PM >>> Subject: Re: I-D ACTION:draft-ietf-ccamp-inter-domain-pd-path- >>> comp-01.txt >>> >>> >>> >>>> Arthi, JP >>>> >>>> >>>> >>>> I have a problem with the auto-discovery mechanism you described >>>> in the >>>> draft (one that is based on query to IGP or BGP to determine >>>> outgoing >>>> ABR/ASBR). >>>> >>>> >>>> >>>> 1. Destination ID must be network unique but it does not have to >>>> be IP >>>> routable, for example, it could be a numbered link ID. >>>> >>>> 2. Even in case when destination is IP address, the path >>>> computing node >>>> >>> can >>> >>>> only obtain the ID of an ABR or ASBR that advertises IP route to >>>> the >>>> destination, which would be one that knows about the shortest IP >>>> path to >>>> >>> the >>> >>>> destination. However, it does not mean that properly constrained >>>> TE path >>>> from this ABR/ASBR to the destination or the next ABR/ASBR >>>> exist, or is >>>> >>> not >>> >>>> suboptimal compared to one from some other ABR/ASBR which knows >>>> about >>>> >>> worse >>> >>>> IP path to the destination and hence will not be reported to the >>>> >>> computing >>> >>>> entity by the routing sub-system. >>>> >>>> >>>> >>>> I wonder why not to use the remote PCE service for this purpose. >>>> For >>>> instance a PCC may ask a PCE to determine either the ID of the >>>> outgoing >>>> domain border node or entire path in terms of domain border >>>> nodes. You >>>> >>> may >>> >>>> ask why not to request explicit path(s) in this case? Several >>>> reasons >>>> >>> why >>> >>>> the PCC wouldn't want to do so: >>>> >>>> >>>> >>>> a) it could be easier and faster for the PCE to determine domain >>>> border >>>> >>> node >>> >>>> in direction towards the destination rather than explicit path >>>> (s). For >>>> instance, the latter may require cooperation of other PCEs; >>>> >>>> >>>> >>>> b) security considerations - PCE may not want to reveal remote >>>> domain >>>> topology(ies) >>>> >>>> >>>> >>>> c) it may be desirable to compute and setup services on per-domain >>>> >>> basis, >>> >>>> for instance, to have each domain take separate care for service >>>> restoration. >>>> >>>> >>>> >>>> What do you think? >>>> >>>> >>>> >>>> Igor >>>> >>>> >>>> >>>> ----- Original Message ----- >>>> >>>> From: >>>> >>>> To: >>>> >>>> Cc: >>>> >>>> Sent: Thursday, October 20, 2005 6:50 PM >>>> >>>> Subject: I-D ACTION:draft-ietf-ccamp-inter-domain-pd-path- >>>> comp-01.txt >>>> >>>> >>>> >>>> >>>>> A New Internet-Draft is available from the on-line Internet-Drafts >>>>> >>>> directories. >>>> >>>>> This draft is a work item of the Common Control and Measurement >>>>> Plane >>>>> >>>> Working Group of the IETF. >>>> >>>>> >>>>> Title : A Per-domain path computation method for establishing >>>>> Inter-domain Traffic Engineering (TE) >>>>> Label >>>>> >>>> Switched Paths (LSPs) >>>> >>>>> Author(s) : J. Vasseur, et al. >>>>> Filename : draft-ietf-ccamp-inter-domain-pd-path-comp-01.txt >>>>> Pages : 18 >>>>> Date : 2005-10-20 >>>>> >>>>> This document specifies a per-domain path computation technique >>>>> for >>>>> establishing inter-domain Traffic Engineering (TE) >>>>> Multiprotocol Label >>>>> Switching (MPLS) and Generalized MPLS (GMPLS) Label Switched Paths >>>>> (LSPs). In this document a domain refers to a collection of >>>>> network >>>>> elements within a common sphere of address management or path >>>>> computational responsibility such as IGP areas and Autonomous >>>>> Systems. >>>>> >>>>> Per-domain computation applies where the full path of an inter- >>>>> domain >>>>> TE LSP cannot be or is not determined at the ingress node of >>>>> the TE >>>>> LSP, and is not signaled across domain boundaries. This is most >>>>> likely >>>>> to arise owing to TE visibility limitations. The signaling message >>>>> indicates the destination and nodes up to the next domain >>>>> boundary. It >>>>> may also indicate further domain boundaries or domain >>>>> identifiers. The >>>>> path through each domain, possibly including the choice of exit >>>>> point >>>>> from the domain, must be determined within the domain. >>>>> >>>>> A URL for this Internet-Draft is: >>>>> >>>>> >>>> >>>> >>> >>> >> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-inter-domain- >> pd-path-comp-01.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-inter-domain-pd-path-comp-01.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-inter-domain-pd-path-comp-01.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. >>>>> >>>>> >>>> >>>> >>>> >>>> >>>> >>> >>> >> > From owner-ccamp@ops.ietf.org Wed Oct 26 15:56:15 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUrNf-0007M0-Ij for ccamp-archive@megatron.ietf.org; Wed, 26 Oct 2005 15:56:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19114 for ; Wed, 26 Oct 2005 15:56:00 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUras-0007yK-9U for ccamp-archive@ietf.org; Wed, 26 Oct 2005 16:09:55 -0400 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EUrHi-0004Or-R0 for ccamp-data@psg.com; Wed, 26 Oct 2005 19:50:06 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=3.1.0 Received: from [132.151.6.50] (helo=newodin.ietf.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1EUrHf-0004Nm-4t for ccamp@ops.ietf.org; Wed, 26 Oct 2005 19:50:03 +0000 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EUrHd-0006zu-UB; Wed, 26 Oct 2005 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-addressing-02.txt Message-Id: Date: Wed, 26 Oct 2005 15:50:01 -0400 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.4 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db --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 : Use of Addresses in Generalized Multi-Protocol Label Switching (GMPLS) Networks Author(s) : K. Shiomoto, et al. Filename : draft-ietf-ccamp-gmpls-addressing-02.txt Pages : 26 Date : 2005-10-26 This document explains and clarifies the use of addresses in Generalized Multi-Protocol Label Switching (GMPLS) networks. The aim of this document is to facilitate and ensure better interworking of GMPLS-capable Label Switching Routers (LSRs) based on experience gained in deployments and interoperability testing and proper interpretation of published RFCs. The document recommends a proper approach for the interpretation and choice of address and identifier fields within GMPLS protocols and references specific control plane usage models. It also examines some common GMPLS Resource Reservation Protocol-Traffic Engineering (RSVP-TE) signaling message processing issues and recommends solutions. Finally, it discusses how to handle IPv6 sources and destinations in the MPLS and GMPLS TE (Traffic Engineering) MIB (Management Information Base) modules. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-addressing-02.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-addressing-02.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-addressing-02.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: <2005-10-26104458.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-gmpls-addressing-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-gmpls-addressing-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-10-26104459.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ccamp@ops.ietf.org Wed Oct 26 17:22:06 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUsik-0001LQ-Cq for ccamp-archive@megatron.ietf.org; Wed, 26 Oct 2005 17:22:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27505 for ; Wed, 26 Oct 2005 17:21:50 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUsvy-0005m0-Vh for ccamp-archive@ietf.org; Wed, 26 Oct 2005 17:35:47 -0400 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EUsbe-000B9F-TF for ccamp-data@psg.com; Wed, 26 Oct 2005 21:14:46 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-5.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from localhost ([127.0.0.1]) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EUsbd-000B90-KT; Wed, 26 Oct 2005 21:14:46 +0000 Message-ID: <435FF197.3090408@psg.com> Date: Wed, 26 Oct 2005 23:13:59 +0200 From: dimitri papadimitriou Reply-To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be, dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.11) Gecko/20050728 X-Accept-Language: en-us, en MIME-Version: 1.0 To: yhwkim@etri.re.kr CC: ccamp@ops.ietf.org Subject: comments on draft-kim-ccamp-cpr-reqts-01.txt 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: 25eb6223a37c19d53ede858176b14339 Content-Transfer-Encoding: 7bit hi, to fuel the discussion (and even if the topic is not going to be discussed during the f2f meeting) here below some comments after a first reading 1. "Then, GMPLS based IP networks come to be capable of handling control channels separated from data channels. It means that channels carrying data and control packets do not have an impact upon each other. Several control channels such as SONET/SDH DCC channels and Ethernet OAM channels defined by the OIF, MPLS based LSPs applied as dedicated control channels, public IP networks, out-of-fiber based dedicated control channels, and so on can be configured independent from data channels for the purpose." indeed, but this has an architectural impact, we are currently dealing with "converged" networks hence if the control channels do involve the need for a separated control infrastructure even logically there is a price to pay - it would be of interest to have such considerations discussed in this document - 2. "- Standby control channels: Physical control channels which are not currently carrying the control information, but can carry them upon the failure of active control channel. Once one of standby control channels is used to carry the control information, the standby control channel becomes an active control channel." what is the purpose of maintaining "standby channels" this aspect should be further discussed is it to provide some rate shaping to the control traffic ? 3. "In traditional IP networks or MPLS networks, there is an implicit one-to-one association of a control channel to a data channel. Under the one-to-one association between control channels and data channels, the protection of control channels may be resolved using the protection schemes for data channels such as 1+1, 1:1, and 1:N protections. In other words, where there is fate sharing, failures of data channels could instantly influence the own control channels." why is there a distinction made with "MPLS networks" i.e. what does chnage here from having an label based forwarding ? 4. the distinction between the quasi and the non-associated mode is quite unclear "- Quasi-associated mode in which control packets between nodes A and B follow a predetermined routing path over several control channels while the traffic channels are routed directly between A and B; - Non-associated mode in which control packets between two network elements A and B are routed over several control channels, while traffic signals are routed directly between A and B." could you explain the difference between these two terms ? 5. "As recognized in the IP world, IP routing protocols have slow convergence time due to the hello interval and expiration times for the normal operation of IP networks. Under this situation, fast and reliable recovery is very difficult from one or more failures occurred over interfaces between adjacent nodes. " "slow" is not an absolute indication ... you should point out here "slow" compare to what ? by the way i am not in agreement with this statement there are currently ongoing efforts within IETF to allow for fast IP re-routing (meant to provde "simple" techniques) 6. "When RSVP variant protocols are used between adjacent nodes, if there is no self-refresh procedure, the failure of control channels may result effects such as unwanted connection teardown. In particular, as described in [ITU-G7712], such a failure that could not transport ASTN messages over the SCN may impact restoration when ASTN is used to provide restoration of existing connections. It is therefore critical for a control network to provide the resilience of control channels that could sufficiently use direct and indirect ones between adjacent nodes." indeed if you don't use a feature (in present case RSVP resilience to cnotrol channel failure) you can't benefit from it - the same would apply with whatever new mechanism you are going to define - hence this argument is not valid 7. it is totally unclear to me how with the previous section arguments you come out and require MPLS 1+1 for control plane resilience - that's probably a very nice and very cumbersome solution but i really doubt this is satisfying much specific requirements when designing the IP control plane topology 8. the rest of the document (as section 5.1) is solution specific thus beyond the scope of the document itself - this is not a document about LMP requirements for control channel management afaik note: more detailed comments could follow depending on the progress we are going to make on this specific topic thanks, - dimitri. -------- Original Message -------- Subject: I-D ACTION:draft-kim-ccamp-cpr-reqts-01.txt Date: Tue, 25 Oct 2005 10:50:01 -0400 From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Requirements for the Resilience of Control Plane Author(s) : Y. Kim Filename : draft-kim-ccamp-cpr-reqts-01.txt Pages : 13 Date : 2005-10-25 The resilience of control plane refers to the ability of control plane to continue its operation even under failure conditions of control components such as control entities, control nodes, and control channels. This document describes requirements for providing the resilience capability of control plane (in other words, control network) in non-(G)MPLS and (G)MPLS. This contribution, as a document that proposes a framework to provide the resilience capability of control plane, include terminologies, basic concepts of control networks, possible configurations, necessities and requirements, additional considerations including the relationship with other protocol such as LMP for the resilience of control plane. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-kim-ccamp-cpr-reqts-01.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-kim-ccamp-cpr-reqts-01.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-kim-ccamp-cpr-reqts-01.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. From info@mail.ltnu.com Wed Oct 26 18:40:31 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUtwd-0004PA-BB for ccamp-archive@megatron.ietf.org; Wed, 26 Oct 2005 18:40:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01703 for ; Wed, 26 Oct 2005 18:40:14 -0400 (EDT) Received: from [125.57.108.55] (helo=mail.ltnu.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EUu9j-0007zf-NE for ccamp-archive@ietf.org; Wed, 26 Oct 2005 18:54:12 -0400 Received: (qmail 24284 invoked by uid 510); 26 Oct 2005 23:47:43 +0900 Date: 26 Oct 2005 23:47:43 +0900 Message-ID: <20051026144743.24283.qmail@mail.ltnu.com> From: info@ltnu.com To: ccamp-archive@ietf.org Subject: $BMp8r%Q!<%F%#!<3+:E$7$^$9!*!*(B X-Spam-Score: 3.5 (+++) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 $BA02sBg@967$K=*$($?Mp8r%Q!<%F%#!!!:#2s$NCK@-Jg=8?M?t$O#1#6L>!!(B $B;22CHqEy$O!"$*;P$5$^J};}$A$H$J$j$^$9$N$G(B $BCK@-$NJ}$+$i0l@ZHqMQ$OD:$-$^$;$s!#C"$7!"$=$NJ,=w@-$KJt;E$7$FD:$-$^$9!#(B $BA02s$N%Q!<%F%#!<\:Y!";22C4uK>$NJ}$O$3$A$i$+$i$*F~$j$/$@$5$$!#(B http://www.1191.jp/ranko/index.html $B%a!<%k; Thu, 27 Oct 2005 04:27:07 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EV3Js-0002fz-QJ for ccamp-archive@ietf.org; Thu, 27 Oct 2005 04:41:09 -0400 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EV2vb-000P2M-0I for ccamp-data@psg.com; Thu, 27 Oct 2005 08:16:03 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-5.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from localhost ([127.0.0.1]) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EV2vY-000P1y-52 for ccamp@ops.ietf.org; Thu, 27 Oct 2005 08:16:01 +0000 Message-ID: <43608C91.8070109@psg.com> Date: Thu, 27 Oct 2005 10:15:13 +0200 From: dimitri papadimitriou Reply-To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be, dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.11) Gecko/20050728 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ccamp@ops.ietf.org" Subject: comments on draft-shiba-ccamp-gmpls-lambda-labels-00.txt Content-Type: multipart/mixed; boundary="------------010409090105030700040000" Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: ea10c7a57c6f5d0512401188e6188235 This is a multi-part message in MIME format. --------------010409090105030700040000 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit hi, there is a specific point to be clarified in this document: semanticless vs semanticful label (even here there is a distinction between spectral vs indexes i.e. using the wavelength index) domain-wide vs link local significant label so, the comparison from this perspective with TDM labels is difficult to parse, the latter is semanticful but link local now, i don't specifically see what has changed the late 90's, early y2k's, to have a change in the wavelength label definition; there are several solution possible - absolute values: the freq. of the wavelength: difficult to adopt because referenced values are nominal and knowing all interactions between wavelengths this knowledge is at the end of little practical usage; (introduces implicit ordering) - indexed values: the # of the wavelength: it does not provide for a future proof label space for inst. in case new frequencies are inserted in the grid (introduces explicit ordering) - diff. values e.g. freq spacing starting from a reference value: pauses the question of the reference value and does suffer from the former issue (introduces implicit ordering) - the solution available today - cumbersome in some control plane operations (e.g. label set translation) and not easy to troubleshoot but independent of any physical consideration (spectral), scale to any number of wavelength per fiber, does not introduce any ordering, the most flexible (since allowing each system to maintain its specific control operations) and the less constraining since maintaining the control plane operations independent of any data plane specifics --------------010409090105030700040000 Content-Type: text/plain; name="www.ietf.org/internet-drafts/draft-shiba-ccamp-gmpls-lambda-labels-00.txt" Content-Disposition: inline; filename="www.ietf.org/internet-drafts/draft-shiba-ccamp-gmpls-lambda-labels-00.txt" Content-Transfer-Encoding: 7bit CCAMP Working Group Sidney Shiba (Fujitsu) Internet Draft Richard Rabbat (Fujitsu) Updates: 3471 Proposed Category: Standards Track Expires: March 2006 September 2005 Generalized Labels of Lambda-Switching Capable Label Switching Routers (LSR)s draft-shiba-ccamp-gmpls-lambda-labels-00.doc.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119, reference [RFC2119]. Abstract Technology in the optical domain is constantly evolving and as a consequence new equipment providing lambda switching capability has been developed and is currently being deployed. [RFC3471] has defined that a wavelength label (section 3.2.1.1) "only has significance between two neighbors". However, in a network composed of a new Expires March 2006 [Page 1] Generalized Labels for LSC-Capable LSRs October 2005 generation of lambda switch-capable equipment, this document explains why the label should have global meaning similarly to the label defined for SONET/SDH technology (SUKLM format defined in [RFC3946]) and describes extensions to enable global meaning. This document is a companion to the Generalized Multi-Protocol Label Switching (GMPLS) signaling. It defines the Label Switching Capable (LSC) technology specific information needed when using GMPLS. Table of Contents 1. Introduction.....................................................2 1.1. Problem Description............................................2 2. Label Related Formats............................................4 2.1. Wavelength Labels..............................................4 2.2. Label Set Wavelength Subchannel................................4 2.3. RSVP-TE Extensions.............................................5 3. IANA Considerations..............................................5 4. Security Considerations..........................................5 5. Acknowledgements.................................................6 6. References.......................................................7 6.1. Normative References...........................................7 6.2. Informative Reference..........................................8 7. Copyright Statement.............................................10 8. Intellectual Property Statement.................................11 1. Introduction As described in [RFC3945], Generalized MPLS (GMPLS) extends MPLS from supporting only packet (Packet Switching Capable - PSC) interfaces and switching to also include support of four new classes of interfaces and switching: Layer-2 Switch Capable (L2SC), Time- Division Multiplex (TDM), Lambda Switch Capable (LSC) and Fiber- Switch Capable (FSC). A functional description of the extensions to MPLS signaling needed to support new classes of interfaces and switching is provided in [RFC3471]. 1.1. Problem Description This document presents details that are specific to the use of GMPLS with a new generation of Lambda Switch Capable (LSC) equipment as opposed to a the prior generation of LSC equipment composed of of Wavelength Division Multiplexing (WDM) + Photonic Cross Connect (PXC) combined system (shown below) that was originally considered at the time of writing of RFC 3471. Expires October 2005 [Page 2] Generalized Labels for LSC-Capable LSRs October 2005 Technologies such as Reconfigurable Optical Add/Drop Multiplex (ROADM) and Dynamic-OADM operate at the wavelength switching level. As such, the wavelength is important information that is necessary to successfully setup a wavelength LSP. _______ _______ _______ /|_|6 1|_|\ /|_|5 1|_|\ /|_|5 1|_|\ | |_|7 PXC 2|_| | WDM | |_|6 PXC 2|_| | WDM | |_|6 PXC 2|_| | WDM ===| |_|8 (1) 3|_| |=====| |_|7 (2) 3|_| |======| |_|7 (3) 3|_| |==== | |_|9 4|_| | | |_|8 4|_| | | |_|8 4|_| | \| |_______| |/ \| |_______| |/ \| |_______| |/ For technologies such as the ROADM and DOADM, the WDM port mapping does not provide sufficient information for selecting the required wavelength for an LSP. Here are four cases that highlight where it is important to have wavelength information available globally. 1. Label Set: A Label Set object may be used to limit the label choices of a downstream node (section 3.5 of RFC 3471). This Label Set object needs to carry one of the labels defined in section 3.2 of that same document, i.e. either port, wavelength label or waveband label. In order to be able to generate that wavelength information, it is important to have global dissemination of wavelength information. 2. Explicit Route Object/Record Route Object: Here as well, any meaningful information should be global, which implies the use of wavelength since a locally-significant label will have no meaning. 3. In SONET/SDH, one can think of the label with the set values of SUKLM bits as locally significant and set their values as a matter of policy to have global meaning. This would add undue burden on the operator to enforce policy. In addition, manual provisioning may lead to misconfiguration. 4. Finally, the values for the wavelengths need to be out of the same pool of values to have global meaning. Any representation of the lambdas needs to be the same on all nodes irrespective of the manufacturer. _______ _______ _______ | | | | | | WDM | LSC | WDM | LSC | WDM | LSC | WDM =======|1 2|=========|1 2|=========|1 2|======= | | | | | | |_______| |_______| |_______| Expires October 2005 [Page 3] Generalized Labels for LSC-Capable LSRs October 2005 The ITU-T frequency grid specified in [G.694.1] for Dense WDM (DWDM) and [G.694.2] for Coarse WDM (CWDM) are the labels that SHOULD be used by these LSC LSRs. 2. Label Related Formats To deal with the widening scope of MPLS into the optical and time domains, several new forms of "label" have been defined in [RFC3471]. This section contains clarifications for the Wavelength label and Label Set definition specific for LSC LSRs. 2.1. Wavelength Labels In section 3.2.1.1 of [RFC3471], a Wavelength label is defined to have significance between two neighbors, and the receiver may need to convert the received value into a value that has local significance. Equipment providing "true" lambda switching (LSC) uses multiple wavelengths controlled by a single control channel. In such case, the label indicates the wavelength to be used for the LSP. In order to allow global meaning, this document redefines the Wavelength label as being an IEEE floating point encoding of the wavelength. As an example of wavelength values, the reader is referred to [G.694.1] which lists the frequencies from the ITU-T DWDM frequency grid. The same can be done for CWDM technology by using the wavelength defined in [G.694.2]. The information carried in a Wavelength label is: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Label: 32 bits The label indicates the frequency value to be used. The value is IEEE Floating point encoded. This may be an ITU-T DWDM frequency. For convenience, Appendix 1 provides the list of IEEE Floating point values for the ITU-T DWDM frequency grid. 2.2. Label Set Wavelength Subchannel This document aligns with the general definition of Label Set in section 3.5 of [RFC3471]. However, it provides a clarification Expires October 2005 [Page 4] Generalized Labels for LSC-Capable LSRs October 2005 related to the subchannel value to be used by an LSC LSR. For this type of equipment the subchannel field SHOULD represent the Wavelength label (ITU-T DWDM frequency grid). 2.3. RSVP-TE Extensions In other to distinguish Wavelength label with local significance from the Wavelength label with global meaning, the latter SHOULD use the same format as the generalized label with the new C-Type (TBA). In the context of "true" lambda switching, the generalized label has the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | Class-Num (16)| C-Type (TBA) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ITU-T DWDM Frequency Grid Label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3. IANA Considerations IANA assigns values to RSVP protocol parameters. Within the current document an object is defined. This object contains a C-Type. This section defines the rules for the assignment of the related C-Type value. This section uses the terminology of BCP 26 "Guidelines for Writing an IANA Considerations Section in RFCs" [BCP26]. As per [RFC2205], C-Type is an 8-bit number that identifies the function of an object. All possible values except zero are available for assignment. The assignment of the C-Type value of the object defined in this document inherits C-Type from the Label object, i.e., object class number 16 [RFC3209]. The Wavelength Switching Label defined in this document has the following C-Type value to be assigned by IANA: o RSVP_LABEL (Class-Num = 16) - Wavelength Switching Label (C-Type = To Be Assigned) 4. Security Considerations Expires October 2005 [Page 5] Generalized Labels for LSC-Capable LSRs October 2005 There may be an argument that by giving the label global meaning, one would decrease security. The closest example of using global meaning is the label setting for SONET/SDH. By using a global meaning for its labels, SONET/SDH did not introduce any new security considerations. This serves as an indication that this document introduces no new security considerations to either [RFC3473] or [RFC3472]. GMPLS security is described in section 11 of [RFC3471] and refers to [RFC3209] for RSVP-TE and to [RFC3212] for CR-LDP. 5. Acknowledgements The authors would like to thank Adrian Farrel for his feedback and comments. Expires October 2005 [Page 6] Generalized Labels for LSC-Capable LSRs October 2005 6. References 6.1. Normative References [G.694.1] ITU-T Recommendation G.694.1, "Spectral grids for WDM applications: DWDM frequency grid", June 2002. [G.694.2] ITU-T Recommendation G.694.2, "Spectral grids for WDM applications: CWDM wavelength grid", December 2003. [IEEE754] "Standard for Binary Floating-Point Arithmetic", IEEE- 754, 1985. [RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) - Version 1 Functional Specification", RFC 2205, September 1997. [RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated Services", RFC 2210, September 1997. [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001. [RFC3212] Jamoussi, B., Andersson, L., Callon, R., Dantu, R., Wu, L., Doolan, P., Worster, T., Feldman, N., Fredette, A., Girish, M., Gray, E., Heinanen, J., Kilty, T., and A. Malis, "Constrained-Based LSP Setup using LDP", RFC 3212, January 2002. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels," BCP 14, IETF RFC 2119, March 1997. [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching (MPLS) Signaling Functional Description", RFC 3471, January 2003. [RFC3472] Ashwood-Smith, P. and L. Berger, "Generalized Multi- Protocol Label Switching (MPLS) Signaling - Constraint- based Routed Label Distribution Protocol (CR-LDP) Extensions", RFC 3472, January 2003. [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching (MPLS} Signaling - Resource ReserVation Protocol Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. Expires October 2005 [Page 7] Generalized Labels for LSC-Capable LSRs October 2005 [RFC3945] Mannie, E., Ed., "Generalized Multiprotocol Label Switching (GMPLS) Architecture", RFC 3945, October 2004. 6.2. Informative Reference [BCP26] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [RFC2026] Bradner, S., "The Internet Standards Process - Revision 3", BCP 9, RFC 2026, October 1996. Appendix 1 - ITU-T DWDM frequency grid and IEEE floating point The list below illustrates some nominal central frequencies within the C and L bands of the DWDM grid (12.5THz spacing) taken from [G.694.1]and their respective IEEE floating point (32 bits encoding) value [IEEE754]. Nominal central Wavelength label Frequency (THz) (IEEE Floating point) --------------------- ------------------------ . . . . . . 195.9375 0x4343F000 195.9250 0x4343ECCD 195.9125 0x4343E99A 195.9000 0x4343E666 195.8875 0x4343E333 195.8750 0x4343E000 195.8625 0x4343DCCD 195.8500 0x4343D99A 195.8375 0x4343D666 195.8250 0x4343D333 195.8125 0x4343D000 195.8000 0x4343CCCD 195.7875 0x4343C99A 195.7750 0x4343C666 195.7625 0x4343C333 195.7500 0x4343C000 195.7375 0x4343BCCD 195.7250 0x4343B99A 195.7125 0x4343B666 195.6875 0x4343B000 195.6750 0x4343ACCD Expires October 2005 [Page 8] Generalized Labels for LSC-Capable LSRs October 2005 195.6625 0x4343A99A . . . . . . . . . . . . 193.2375 0x43413CCD 193.2250 0x4341399A 193.2125 0x43413666 193.2000 0x43413333 193.1875 0x43413000 193.1750 0x43412CCD 193.1625 0x4341299A 193.1500 0x43412666 193.1375 0x43412333 193.1250 0x43412000 193.1125 0x43411CCD 193.1000 0x4341199A 193.0875 0x43411666 193.0750 0x43411333 193.0625 0x43411000 193.0500 0x43410CCD 193.0375 0x4341099A 193.0250 0x43410666 193.0125 0x43410333 193.0000 0x43410000 192.9875 0x4340FCCD 192.9750 0x4340F99A 192.9625 0x4340F666 . . . . . . . . . . . . 184.7750 0x4338C666 184.7625 0x4338C333 184.7500 0x4338C000 184.7375 0x4338BCCD 184.7250 0x4338B99A 184.7125 0x4338B666 184.7000 0x4338B333 184.6875 0x4338B000 184.6750 0x4338ACCD 184.6625 0x4338A99A 184.6500 0x4338A666 184.6375 0x4338A333 Expires October 2005 [Page 9] Generalized Labels for LSC-Capable LSRs October 2005 184.6250 0x4338A000 184.6125 0x43389CCD 184.6000 0x4338999A 184.5875 0x43389666 184.5750 0x43389333 184.5625 0x43389000 184.5500 0x43388CCD 184.5375 0x4338899A 184.5250 0x43388666 184.5125 0x43388333 184.5000 0x43388000 . . . . . . Authors' Addresses Sidney Shiba (Fujitsu) 2801 Telecom Parkway Richardson, TX 75082, USA Phone: +1 972 479 6041 Email: sidney.shiba@us.fujitsu.com Richard Rabbat (Fujitsu) 1240 East Arques Ave, MS 345 Sunnyvale, CA 94085, USA Phone: +1 408 530 4537 Email: richard@us.fujitsu.com Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 7. Copyright Statement Expires October 2005 [Page 10] Generalized Labels for LSC-Capable LSRs October 2005 Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 8. Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Expires October 2005 [Page 11] --------------010409090105030700040000-- From owner-ccamp@ops.ietf.org Thu Oct 27 05:17:00 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EV3sZ-0004QY-VU for ccamp-archive@megatron.ietf.org; Thu, 27 Oct 2005 05:17:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17299 for ; Thu, 27 Oct 2005 05:16:43 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EV45t-0003r8-O2 for ccamp-archive@ietf.org; Thu, 27 Oct 2005 05:30:47 -0400 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EV3nN-0002AQ-4t for ccamp-data@psg.com; Thu, 27 Oct 2005 09:11:37 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-5.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from localhost ([127.0.0.1]) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EV3nM-0002A4-Cu for ccamp@ops.ietf.org; Thu, 27 Oct 2005 09:11:36 +0000 Message-ID: <43609999.8020709@psg.com> Date: Thu, 27 Oct 2005 11:10:49 +0200 From: dimitri papadimitriou Reply-To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be, dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be, dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.11) Gecko/20050728 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ccamp@ops.ietf.org Subject: comments on draft-ietf-ccamp-gmpls-addressing-02.txt 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: b4a0a5f5992e2a4954405484e7717d8c Content-Transfer-Encoding: 7bit hi - some comment on this document after first reading (note: text has improved since last version but some shaded sub-sections remain and i still find some sentences with ambiguous/dual interpretation but this would be normally to be tackled during the editorial review) Section 7.1.1 " 4. Outgoing TE link ID optionally followed by Component Interface ID subobject and/or one or two Label subobjects " applies for so called egress control so there no such "optional" follow-up object; these are present by definition - see also RFC 4003 that clarifies the procedures for the control of the label used on an output/downstream interface of the egress node of an LSP " There is no way to specify in the ERO whether a subobject is associated with the incoming or outgoing TE link. This is unfortunate because the address specified in a loose subobject is used as a target for the path computation, and there is a big difference for the path selection process whether the intention is to reach the target node over the specified link (the case of incoming TE link) or to reach the node over some other link, so that it would be possible to continue the path to its final destination over the specified link (the case of outgoing TE link). In the case where a subobject in an ERO is marked as a loose hop and identifies an interface, the subobject SHOULD include the address of the Incoming interface specifying the TE link in the data plane. " but by definition the latter applies (it is not a "SHOULD" its de-facto) so why is this indication needed ? - see RFC3209 section 4.3.4 + would you drop a line on ERO processing at region boundaries per LSP-HIER (Section 8.2) Section 8.2 " If the control plane interface is unnumbered, the RECOMMENDED value for the control plane address is the TE Router-ID. " what does "control plane interface is unnumbered" means ? btw i thought IP source/dest. address settings were discussed in section 5. - why re-discuss this here ? Section 9 is this section really dealing with usage of addressing in GMPLS nets ? Section 10 For this feature to be used, all LSRs in the network MUST advertise a 32-bit value that can be used to identify the LSR. In this document, this is referred to as the 32-bit LSR ID. The 32-bit LSR ID is the OSPFv3 router ID [RFC2740] or the ISIS IPv4 TE Router ID [RFC3784]. Note that these are different from TE router ID (See Section 3). => in section 10 a new definition falls 'LSR ID'; i found the text confusing; it is different from the TE Router ID but it is named the TE Router ID; it is the Router ID of OSPFv3 and not sure it is the Traffic Engineering router ID TLV is TLV type 134 of IS-IS - last sentence seems to say the contrary From owner-ccamp@ops.ietf.org Thu Oct 27 06:28:21 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EV4zd-0003S0-8D for ccamp-archive@megatron.ietf.org; Thu, 27 Oct 2005 06:28:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20469 for ; Thu, 27 Oct 2005 06:28:04 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EV5Ct-0005fE-HU for ccamp-archive@ietf.org; Thu, 27 Oct 2005 06:42:09 -0400 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EV4ud-0006B0-QZ for ccamp-data@psg.com; Thu, 27 Oct 2005 10:23:11 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.0 Received: from [62.241.163.7] (helo=blaster.systems.pipex.net) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EV4uY-0006AC-Ox for ccamp@ops.ietf.org; Thu, 27 Oct 2005 10:23:07 +0000 Received: from dnni.com (81-178-2-190.dsl.pipex.com [81.178.2.190]) by blaster.systems.pipex.net (Postfix) with ESMTP id 3C5C7E000261; Thu, 27 Oct 2005 11:22:49 +0100 (BST) Received: from Puppy ([217.158.145.34] RDNS failed) by dnni.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 27 Oct 2005 11:11:28 +0100 Message-ID: <050d01c5dadf$374d6b70$de849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: , , References: <43608C91.8070109@psg.com> Subject: Re: comments on draft-shiba-ccamp-gmpls-lambda-labels-00.txt Date: Thu, 27 Oct 2005 10:44: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: 27 Oct 2005 10:11:29.0924 (UTC) FILETIME=[CC8BDC40:01C5DADE] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Content-Transfer-Encoding: 7bit Dimitri, Thanks for your work reviewing these recent I-Ds. It is really valuable and I'd welcome other people doing similar reviews. > there is a specific point to be clarified in this document: > > semanticless vs semanticful label (even here there is a distinction > between spectral vs indexes i.e. using the wavelength index) > > domain-wide vs link local significant label Without being too picky, I think all labels are semanticful otherwise, we would not know what resource they refered to. So the point reduces to whether the scope of the semantics are link-local or wider. > so, the comparison from this perspective with TDM labels is difficult to > parse, the latter is semanticful but link local > > now, i don't specifically see what has changed the late 90's, early > y2k's, to have a change in the wavelength label definition; This is the question I would like to get to the bottom of. In other words: do we need this function? It seems to me that the question being asked is this: If I want to compute a path that has some form of wavelength constraints, what information do I need access to? Another question might be: If I want to signal a path with wavelength constraints what information do I need to include in the signaling message? I'd suggest that when we started on GMPLS, we were enthusiastic about transparent optical networks, but we were not properly focusing wavelength constraints because lambda-switching PXCs didn't take off. Therefore we didn't examine the requirements for wavelength constraints in routing and signaling. The authors of this I-D are claiming new hardware requirements for the same function. > there are > several solution possible > > - absolute values: the freq. of the wavelength: difficult to adopt > because referenced values are nominal and knowing all interactions > between wavelengths this knowledge is at the end of little practical > usage; (introduces implicit ordering) > > - indexed values: the # of the wavelength: it does not provide for a > future proof label space for inst. in case new frequencies are inserted > in the grid (introduces explicit ordering) > > - diff. values e.g. freq spacing starting from a reference value: pauses > the question of the reference value and does suffer from the former > issue (introduces implicit ordering) > > - the solution available today - cumbersome in some control plane > operations (e.g. label set translation) and not easy to troubleshoot but > independent of any physical consideration (spectral), scale to any > number of wavelength per fiber, does not introduce any ordering, the > most flexible (since allowing each system to maintain its specific > control operations) and the less constraining since maintaining the > control plane operations independent of any data plane specifics > > From owner-ccamp@ops.ietf.org Thu Oct 27 09:34:35 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EV7tr-0007T0-PS for ccamp-archive@megatron.ietf.org; Thu, 27 Oct 2005 09:34:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29500 for ; Thu, 27 Oct 2005 09:34:20 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EV87D-0002BQ-VL for ccamp-archive@ietf.org; Thu, 27 Oct 2005 09:48:25 -0400 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EV7cq-000G4G-6x for ccamp-data@psg.com; Thu, 27 Oct 2005 13:17:00 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-5.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from localhost ([127.0.0.1]) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EV7co-000G3p-V0; Thu, 27 Oct 2005 13:16:59 +0000 Message-ID: <4360D31D.2010809@psg.com> Date: Thu, 27 Oct 2005 15:16:13 +0200 From: dimitri papadimitriou Reply-To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.11) Gecko/20050728 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Adrian Farrel CC: dimitri.papadimitriou@alcatel.be, ccamp@ops.ietf.org Subject: Re: comments on draft-shiba-ccamp-gmpls-lambda-labels-00.txt References: <43608C91.8070109@psg.com> <050d01c5dadf$374d6b70$de849ed9@Puppy> In-Reply-To: <050d01c5dadf$374d6b70$de849ed9@Puppy> 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: 6ffdee8af20de249c24731d8414917d3 Content-Transfer-Encoding: 7bit adrian - see in-line Adrian Farrel wrote: > Dimitri, > > Thanks for your work reviewing these recent I-Ds. It is really valuable > and I'd welcome other people doing similar reviews. > > >>there is a specific point to be clarified in this document: >> >>semanticless vs semanticful label (even here there is a distinction >>between spectral vs indexes i.e. using the wavelength index) >> >>domain-wide vs link local significant label > > > Without being too picky, I think all labels are semanticful otherwise, we > would not know what resource they refered to. actually you have unstructured label space whose interpretation can only be done in the context of the link associated to this label exchange and if you have an additional level of indirection -> "semanticless" as the value in itself (with its associated link) does not tell you more about the resource to be used (its just equivalent to an index) you need for instance to perform initial LMP exchange to know the data plane resource correspondance but you have also structured label spaces like TDM whose interpretation can be done (together with the associated link) since they provide you with the exact timeslot position in the SONET/SDH multiplexing tree -> so the label value space carries a semantic hope this clarifies - > So the point reduces to whether the scope of the semantics are link-local > or wider. see above - the discussion is important, in TDM this has been done in order to avoid timeslot position/index exchange while the structure is perfectly know and invariant - hence, draw an analogy with LSC requires careful thought >>so, the comparison from this perspective with TDM labels is difficult to >>parse, the latter is semanticful but link local >> >>now, i don't specifically see what has changed the late 90's, early >>y2k's, to have a change in the wavelength label definition; > > This is the question I would like to get to the bottom of. In other words: > do we need this function? > > It seems to me that the question being asked is this: > > If I want to compute a path that has some form of wavelength > constraints, what information do I need access to? you have at this level three type of constraints: spatial, spectral and link currently GMPLS for wavelegnth constraints works with source-driven spatial routing (constraint-based source-routing so implying both TE routing and signaling exchanges) and receiver-driven spectral routing (via the label set/acceptable label set mechanism so implying only signaling exchanges) > Another question might be: > > If I want to signal a path with wavelength constraints what > information do I need to include in the signaling message? shouldn't you ask the question, what's not workable with the present solution we have at hand in RFC3473 ? > I'd suggest that when we started on GMPLS, we were enthusiastic about > transparent optical networks, but we were not properly focusing wavelength > constraints because lambda-switching PXCs didn't take off. Therefore we > didn't examine the requirements for wavelength constraints in routing and > signaling. The authors of this I-D are claiming new hardware requirements > for the same function. adrian, i am not sure to understand ... hence, i would like to know from authors how the following cornerstone problem has been solved 1. either the network is pre-engineered and you don't need to take care about any spectral routing specifics for traffic engineering purposes 2. or the network is not pre-engineered and i would like to know if the specifics of analog transmission/switching have been addressed such as to be compatible with the constraint-based routing mechanisms used today while keeping a low blocking probability >>there are >>several solution possible >> >>- absolute values: the freq. of the wavelength: difficult to adopt >>because referenced values are nominal and knowing all interactions >>between wavelengths this knowledge is at the end of little practical >>usage; (introduces implicit ordering) >> >>- indexed values: the # of the wavelength: it does not provide for a >>future proof label space for inst. in case new frequencies are inserted >>in the grid (introduces explicit ordering) >> >>- diff. values e.g. freq spacing starting from a reference value: pauses >>the question of the reference value and does suffer from the former >>issue (introduces implicit ordering) >> >>- the solution available today - cumbersome in some control plane >>operations (e.g. label set translation) and not easy to troubleshoot but >>independent of any physical consideration (spectral), scale to any >>number of wavelength per fiber, does not introduce any ordering, the >>most flexible (since allowing each system to maintain its specific >>control operations) and the less constraining since maintaining the >>control plane operations independent of any data plane specifics >> >> > > -00.txt> > > > > . > From info@mail.gqow.com Thu Oct 27 11:21:03 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EV9Ys-0000tH-Nr for ccamp-archive@megatron.ietf.org; Thu, 27 Oct 2005 11:21:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13815 for ; Thu, 27 Oct 2005 11:20:46 -0400 (EDT) Received: from [125.57.107.92] (helo=mail.gqow.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EV9mD-0008Lc-Jw for ccamp-archive@ietf.org; Thu, 27 Oct 2005 11:34:52 -0400 Received: (qmail 10572 invoked by uid 510); 27 Oct 2005 16:16:13 +0900 Date: 27 Oct 2005 16:16:13 +0900 Message-ID: <20051027071613.10571.qmail@mail.gqow.com> From: info@gqow.com To: ccamp-archive@ietf.org Subject: $B=C4/9%$-$G$9'f(B X-Spam-Score: 3.5 (+++) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 $BFMA3$9$_$^$;$s!##2#7:P$N(BOL$B%j%($G$9!#(B $B@'Hs!"$"$J$?$,;t$C$F$$$kF0J*$H8rHx$5$;$F2<$5$$!#(B $B=PMh$l$PBg$-$$F0J*$,4uK>$G$9!#(B $BNY$G8+$F$F$b$$$$$G$9$h!#!J$J$s$F!K(B $B0l1~; Thu, 27 Oct 2005 11:23:11 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EV9oX-00009z-BZ for ccamp-archive@ietf.org; Thu, 27 Oct 2005 11:37:15 -0400 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EV9VM-000Npg-D6 for ccamp-data@psg.com; Thu, 27 Oct 2005 15:17:24 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.0 Received: from [62.241.162.32] (helo=ranger.systems.pipex.net) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EV9VI-000Nos-22 for ccamp@ops.ietf.org; Thu, 27 Oct 2005 15:17:20 +0000 Received: from dnni.com (81-178-2-190.dsl.pipex.com [81.178.2.190]) by ranger.systems.pipex.net (Postfix) with ESMTP id 51C93E000152 for ; Thu, 27 Oct 2005 16:17:12 +0100 (BST) Received: from Puppy ([217.158.132.32] RDNS failed) by dnni.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 27 Oct 2005 16:06:07 +0100 Message-ID: <05ad01c5db08$63e65d30$de849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Bouncing I-D submissions Date: Thu, 27 Oct 2005 16:06:50 +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: 27 Oct 2005 15:06:07.0954 (UTC) FILETIME=[F5792B20:01C5DB07] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit Hi, I am in the (un)fortunate position of being cc'ed when many of your attempts to submit I-Ds are rejected by the Secretariat. The Secretariat has to maintain certain standards for I-Ds before they can publish them, and it is particularly hard work for them in the immediate run-up to an IETF meeting. You can help them and yourselves by checking that your submissions conform to the requirements by running the idnits script available at: http://ietf.levkowetz.com/tools/idnits/ Thanks, Adrian From owner-ccamp@ops.ietf.org Thu Oct 27 12:19:16 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVATE-0005dD-DI for ccamp-archive@megatron.ietf.org; Thu, 27 Oct 2005 12:19:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09056 for ; Thu, 27 Oct 2005 12:18:59 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVAgc-00014i-9d for ccamp-archive@ietf.org; Thu, 27 Oct 2005 12:33:06 -0400 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EVAM5-000193-AZ for ccamp-data@psg.com; Thu, 27 Oct 2005 16:11:53 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-4.9 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from localhost ([127.0.0.1]) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EVAM3-00018a-Oa; Thu, 27 Oct 2005 16:11:52 +0000 Message-ID: <4360FC18.8090906@psg.com> Date: Thu, 27 Oct 2005 18:11:04 +0200 From: dimitri papadimitriou Reply-To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.11) Gecko/20050728 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Shiba, Sidney" CC: Adrian Farrel , dimitri.papadimitriou@alcatel.be, richard.rabbat@us.fujitsu.com, ccamp@ops.ietf.org Subject: Re: comments on draft-shiba-ccamp-gmpls-lambda-labels-00.txt References: <7CA873794E52904EAA980A074B076779B17C34@rchemx01.fnc.net.local> In-Reply-To: <7CA873794E52904EAA980A074B076779B17C34@rchemx01.fnc.net.local> 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: 03169bfe4792634a390035a01a6c6d2f Content-Transfer-Encoding: 7bit shiba Shiba, Sidney wrote: > Adrian, Dimitri, > > Thanks for reviewing these I-D. > > Wavelength continuity constraint does require the use of semanticful > label whether it is spectral or index. => see my reply to adrian on this specific point > I agree with Dimitri that the > wavelength indexing requires document updating each time a new > spectrum is introduced. => indeed and in addition it requires updating the already signaled path > The use of spectral label provides self maintainance, i.e., no need to > update any document and the use of the nominal value provides a common > semantic ground. => what do you mean by self-maintenance - would you provide a bit more detail => now i have a more specific question before being light-up how do you know the frequency that you can support ? if these differ from the nominal values how are you going to deal with these discrepancies ? this said i am not necessarily sure that having to maintain the data plane specifics as part of the control plane is really helping operations (is this method not just duplicating complexity ?) > I'm not sure if the draft needs to be updated before the face-to-face > meeting or after all comments are collected. Please advise. => suggest to keep discussion on - document update can be performed at a later stage > Thanks, > > Sidney > > >>-----Original Message----- >>From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On >>Behalf Of Adrian Farrel >>Sent: Thursday, October 27, 2005 4:45 AM >>To: dpapadimitriou@psg.com; dimitri.papadimitriou@alcatel.be; >>ccamp@ops.ietf.org >>Subject: Re: comments on draft-shiba-ccamp-gmpls-lambda-labels-00.txt >> >> >>Dimitri, >> >>Thanks for your work reviewing these recent I-Ds. It is >>really valuable >>and I'd welcome other people doing similar reviews. >> >> >>>there is a specific point to be clarified in this document: >>> >>>semanticless vs semanticful label (even here there is a distinction >>>between spectral vs indexes i.e. using the wavelength index) >>> >>>domain-wide vs link local significant label >> >>Without being too picky, I think all labels are semanticful >>otherwise, we >>would not know what resource they refered to. >> >>So the point reduces to whether the scope of the semantics >>are link-local >>or wider. >> >> >>>so, the comparison from this perspective with TDM labels is >> >>difficult to >> >>>parse, the latter is semanticful but link local >>> >>>now, i don't specifically see what has changed the late 90's, early >>>y2k's, to have a change in the wavelength label definition; >> >>This is the question I would like to get to the bottom of. In >>other words: >>do we need this function? >> >>It seems to me that the question being asked is this: >> >> If I want to compute a path that has some form of wavelength >> constraints, what information do I need access to? >> >>Another question might be: >> >> If I want to signal a path with wavelength constraints what >> information do I need to include in the signaling message? >> >> >>I'd suggest that when we started on GMPLS, we were enthusiastic about >>transparent optical networks, but we were not properly >>focusing wavelength >>constraints because lambda-switching PXCs didn't take off. >>Therefore we >>didn't examine the requirements for wavelength constraints in >>routing and >>signaling. The authors of this I-D are claiming new hardware >>requirements >>for the same function. >> >> >>>there are >>>several solution possible >>> >>>- absolute values: the freq. of the wavelength: difficult to adopt >>>because referenced values are nominal and knowing all interactions >>>between wavelengths this knowledge is at the end of little practical >>>usage; (introduces implicit ordering) >>> >>>- indexed values: the # of the wavelength: it does not provide for a >>>future proof label space for inst. in case new frequencies >> >>are inserted >> >>>in the grid (introduces explicit ordering) >>> >>>- diff. values e.g. freq spacing starting from a reference >> >>value: pauses >> >>>the question of the reference value and does suffer from the former >>>issue (introduces implicit ordering) >>> >>>- the solution available today - cumbersome in some control plane >>>operations (e.g. label set translation) and not easy to >> >>troubleshoot but >> >>>independent of any physical consideration (spectral), scale to any >>>number of wavelength per fiber, does not introduce any ordering, the >>>most flexible (since allowing each system to maintain its specific >>>control operations) and the less constraining since maintaining the >>>control plane operations independent of any data plane specifics >>> >>> >> >> > ambda-labels > -00.txt> > > . > From owner-ccamp@ops.ietf.org Thu Oct 27 12:30:47 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVAeN-0003Tt-4K for ccamp-archive@megatron.ietf.org; Thu, 27 Oct 2005 12:30:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12190 for ; Thu, 27 Oct 2005 12:30:30 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVArl-0002IY-7J for ccamp-archive@ietf.org; Thu, 27 Oct 2005 12:44:37 -0400 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EVAWV-00021N-1l for ccamp-data@psg.com; Thu, 27 Oct 2005 16:22:39 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-4.9 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from localhost ([127.0.0.1]) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EVAWT-00020X-PH; Thu, 27 Oct 2005 16:22:38 +0000 Message-ID: <4360FE9E.7080103@psg.com> Date: Thu, 27 Oct 2005 18:21:50 +0200 From: dimitri papadimitriou Reply-To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.11) Gecko/20050728 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Shiba, Sidney" CC: dimitri.papadimitriou@alcatel.be, Adrian Farrel , richard.rabbat@us.fujitsu.com, ccamp@ops.ietf.org Subject: Re: comments on draft-shiba-ccamp-gmpls-lambda-labels-00.txt References: <7CA873794E52904EAA980A074B076779B17C39@rchemx01.fnc.net.local> In-Reply-To: <7CA873794E52904EAA980A074B076779B17C39@rchemx01.fnc.net.local> 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: 515708a075ffdf0a79d1c83b601e2afd Content-Transfer-Encoding: 7bit shiba, see inline Shiba, Sidney wrote: > Dimitri, > > See inline > > >>-----Original Message----- >>From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On >>Behalf Of dimitri papadimitriou >>Sent: Thursday, October 27, 2005 8:16 AM >>To: Adrian Farrel >>Cc: dimitri.papadimitriou@alcatel.be; ccamp@ops.ietf.org >>Subject: Re: comments on draft-shiba-ccamp-gmpls-lambda-labels-00.txt >> >> >>adrian - see in-line >> >>Adrian Farrel wrote: >> >> >>>Dimitri, >>> >>>Thanks for your work reviewing these recent I-Ds. It is >> >>really valuable >> >>>and I'd welcome other people doing similar reviews. >>> >>> >>> >>>>there is a specific point to be clarified in this document: >>>> >>>>semanticless vs semanticful label (even here there is a distinction >>>>between spectral vs indexes i.e. using the wavelength index) >>>> >>>>domain-wide vs link local significant label >>> >>> >>>Without being too picky, I think all labels are semanticful >> >>otherwise, we >> >>>would not know what resource they refered to. >> >>actually you have unstructured label space whose >>interpretation can only >>be done in the context of the link associated to this label >>exchange and >>if you have an additional level of indirection -> >>"semanticless" as the >>value in itself (with its associated link) does not tell you >>more about >>the resource to be used (its just equivalent to an index) you >>need for >>instance to perform initial LMP exchange to know the data >>plane resource >>correspondance >> >>but you have also structured label spaces like TDM whose >>interpretation >>can be done (together with the associated link) since they >>provide you >>with the exact timeslot position in the SONET/SDH >>multiplexing tree -> >>so the label value space carries a semantic > > [Sidney] The use of spectral label allows to provide a consistent > solution from network engineering tool to the circuit provisioning. > No need to translate wavelength (engineering tool) to local id (ERO) > and back to wavelength (NE). > > Note that this is not the main reason for the spectral label but > can be considered as extra that comes with this approach. would be helphul to know the main reason then ? >>hope this clarifies - >> >> >>>So the point reduces to whether the scope of the semantics >> >>are link-local >> >>>or wider. >> >>see above - the discussion is important, in TDM this has been done in >>order to avoid timeslot position/index exchange while the >>structure is >>perfectly know and invariant - hence, draw an analogy with >>LSC requires >>careful thought >> >> >>>>so, the comparison from this perspective with TDM labels is >> >>difficult to >> >>>>parse, the latter is semanticful but link local >>>> >>>>now, i don't specifically see what has changed the late 90's, early >>>>y2k's, to have a change in the wavelength label definition; >>> >>>This is the question I would like to get to the bottom of. >> >>In other words: >> >>>do we need this function? >>> >>>It seems to me that the question being asked is this: >>> >>> If I want to compute a path that has some form of wavelength >>> constraints, what information do I need access to? >> >>you have at this level three type of constraints: spatial, >>spectral and link >> >>currently GMPLS for wavelegnth constraints works with source-driven >>spatial routing (constraint-based source-routing so implying both TE >>routing and signaling exchanges) and receiver-driven spectral routing >>(via the label set/acceptable label set mechanism so implying only >>signaling exchanges) > > [Sidney]We may need to increase the scope of this draft and add wavelength > availability for allowing to shift from the spectral routing to spatial > routing for optical networks. This approach would take care of wavelength > blocking issue for non pre-engineered circuits. well this is why i am asking the question, soon or later in order to benefit from these spectral labels you are going to come up with TE routing information exchange - before jumping there i would suggest that you take a look at the scaling properties of such approach >>>Another question might be: >>> >>> If I want to signal a path with wavelength constraints what >>> information do I need to include in the signaling message? >> >>shouldn't you ask the question, what's not workable with the present >>solution we have at hand in RFC3473 ? >> >> >>>I'd suggest that when we started on GMPLS, we were >> >>enthusiastic about >> >>>transparent optical networks, but we were not properly >> >>focusing wavelength >> >>>constraints because lambda-switching PXCs didn't take off. >> >>Therefore we >> >>>didn't examine the requirements for wavelength constraints >> >>in routing and >> >>>signaling. The authors of this I-D are claiming new >> >>hardware requirements >> >>>for the same function. >> >>adrian, i am not sure to understand ... hence, i would like >>to know from >>authors how the following cornerstone problem has been solved >> >>1. either the network is pre-engineered and you don't need to >>take care >>about any spectral routing specifics for traffic engineering purposes >> > > [Sidney] In most of the cases, the network is pre-engineered using > spectral data, which will require a mapping effort. Of course, this > is feasable but we are proposing an approach that does not require > mapping effort when possible. would it be possible that you provide with a real estimate of the effort required for such mapping - i did it and it just requires to have a single/common profile per wavelength/color that you can use based on the received label value index (in the pre-engineered case there properties are known) >>2. or the network is not pre-engineered and i would like to >>know if the >>specifics of analog transmission/switching have been >>addressed such as >>to be compatible with the constraint-based routing mechanisms >>used today >>while keeping a low blocking probability > > [Sidney] As I said previously, we might need to increase the scope > of the draft to include wavelength availability information for the > routing in order to keep low the blocking probability. yes but this is where all complexity lies, as you don't know about the routing/selection of the wavelenght you are creating a closed loop such that your network will convergence problems; the major issue with lambda switching is that locality principle is not preserved, setting up a path in a non pre-engineered network implies that a reservation on a link can have impact on other link along the path but even on links that are not followed by that - >>>>there are >>>>several solution possible >>>> >>>>- absolute values: the freq. of the wavelength: difficult to adopt >>>>because referenced values are nominal and knowing all interactions >>>>between wavelengths this knowledge is at the end of little practical >>>>usage; (introduces implicit ordering) >>>> >>>>- indexed values: the # of the wavelength: it does not provide for a >>>>future proof label space for inst. in case new frequencies >> >>are inserted >> >>>>in the grid (introduces explicit ordering) >>>> >>>>- diff. values e.g. freq spacing starting from a reference >> >>value: pauses >> >>>>the question of the reference value and does suffer from the former >>>>issue (introduces implicit ordering) >>>> >>>>- the solution available today - cumbersome in some control plane >>>>operations (e.g. label set translation) and not easy to >> >>troubleshoot but >> >>>>independent of any physical consideration (spectral), scale to any >>>>number of wavelength per fiber, does not introduce any ordering, the >>>>most flexible (since allowing each system to maintain its specific >>>>control operations) and the less constraining since maintaining the >>>>control plane operations independent of any data plane specifics >>>> >>>> >>> >>> >> > ambda-labels > >>-00.txt> >> >> >> >>. >> > > > . > From owner-ccamp@ops.ietf.org Thu Oct 27 13:11:16 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVBHW-0006uB-Pj for ccamp-archive@megatron.ietf.org; Thu, 27 Oct 2005 13:11:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16165 for ; Thu, 27 Oct 2005 13:10:58 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVBUv-0004Bc-Q4 for ccamp-archive@ietf.org; Thu, 27 Oct 2005 13:25:06 -0400 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EVBAF-0004XC-9H for ccamp-data@psg.com; Thu, 27 Oct 2005 17:03:43 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-4.9 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from localhost ([127.0.0.1]) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EVBAC-0004Wx-Ib; Thu, 27 Oct 2005 17:03:42 +0000 Message-ID: <4361083E.8010307@psg.com> Date: Thu, 27 Oct 2005 19:02:54 +0200 From: dimitri papadimitriou Reply-To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.11) Gecko/20050728 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Shiba, Sidney" CC: dimitri.papadimitriou@alcatel.be, Adrian Farrel , richard.rabbat@us.fujitsu.com, ccamp@ops.ietf.org Subject: Re: comments on draft-shiba-ccamp-gmpls-lambda-labels-00.txt References: <7CA873794E52904EAA980A074B076779B17C3B@rchemx01.fnc.net.local> In-Reply-To: <7CA873794E52904EAA980A074B076779B17C3B@rchemx01.fnc.net.local> 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: a069a8e8835d39ce36e425c148267a7b Content-Transfer-Encoding: 7bit shiba - see inline for some additional hints: >>Shiba, Sidney wrote: >> >>>Adrian, Dimitri, >>> >>>Thanks for reviewing these I-D. >>> >>>Wavelength continuity constraint does require the use of semanticful >>>label whether it is spectral or index. >> >>=> see my reply to adrian on this specific point >> >>>I agree with Dimitri that the >>>wavelength indexing requires document updating each time a new >>>spectrum is introduced. >> >>=> indeed and in addition it requires updating the already >>signaled path >> >>>The use of spectral label provides self maintainance, i.e., >>>no need to update any document and the use of the nominal value >>>provides a common semantic ground. >> >>=> what do you mean by self-maintenance - would you provide a >>bit more detail > > [Sidney]What I've meant here was that it was not necessary to > update any document when new wavelengths are inventoried. In the > case of indexing approach, it would require the wavelength indexing > document to be updated with implementation impacts. > > In the case, the nominal value is used, there is no need for > documentation update. ok - what you mean here is that you are going to make use of the already defined C-Type 2 - what about the specific encoding of the value space ? >>=> now i have a more specific question before being light-up >>how do you know the frequency that you can support ? > > [Sidney] Some new technologies integrate optical switch and mux/demux > capabilities, which allows the equipment to know the spectrum it supports. indeed - but the question is what does happen if the "detected" values (during initialization) do not match the nominal values ? you don't initialize then ? >>if these differ from the nominal values how are you going to deal with these >>discrepancies ? > > [Sidney] These new technologies uses the nominal value as reference. We can say > that a lightpath wavelength is identified by its nominal value. If the equipment > is drifting from this nominal value, it is considered as a failure. ok - but if the deviation is such you have overlap - how the control plane is going to be able to detect such failure ? >>this said i am not necessarily sure that having to maintain the data plane >>specifics as part of the control plane is really helping >>operations (is this method not just duplicating complexity ?) > > [Sidney] The wavelength is WDM specific as much as the SUKLM label encoding > is for SONET. The wavelegth/frequency nominal value is used to identify the > facilities to cross-connect. there is an equivalence but there is also a major difference, the structure is invariant independently of the state of the network, with spectral value space you may have labels that become unavailable due to non-local usage of wavelength in the network hence, there is also no real coupling to the data plane more than knowing the type of interface and some generic capabilities >>>I'm not sure if the draft needs to be updated before the >>>face-to-face meeting or after all comments are collected. Please advise. >> >>=> suggest to keep discussion on - document update can be >>performed at a later stage thanks, - dimitri. >>>>-----Original Message----- >>>>From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On >>>>Behalf Of Adrian Farrel >>>>Sent: Thursday, October 27, 2005 4:45 AM >>>>To: dpapadimitriou@psg.com; dimitri.papadimitriou@alcatel.be; >>>>ccamp@ops.ietf.org >>>>Subject: Re: comments on >> >>draft-shiba-ccamp-gmpls-lambda-labels-00.txt >> >>>> >>>>Dimitri, >>>> >>>>Thanks for your work reviewing these recent I-Ds. It is >>>>really valuable >>>>and I'd welcome other people doing similar reviews. >>>> >>>> >>>> >>>>>there is a specific point to be clarified in this document: >>>>> >>>>>semanticless vs semanticful label (even here there is a distinction >>>>>between spectral vs indexes i.e. using the wavelength index) >>>>> >>>>>domain-wide vs link local significant label >>>> >>>>Without being too picky, I think all labels are semanticful >>>>otherwise, we >>>>would not know what resource they refered to. >>>> >>>>So the point reduces to whether the scope of the semantics >>>>are link-local >>>>or wider. >>>> >>>> >>>> >>>>>so, the comparison from this perspective with TDM labels is >>>> >>>>difficult to >>>> >>>> >>>>>parse, the latter is semanticful but link local >>>>> >>>>>now, i don't specifically see what has changed the late 90's, early >>>>>y2k's, to have a change in the wavelength label definition; >>>> >>>>This is the question I would like to get to the bottom of. In >>>>other words: >>>>do we need this function? >>>> >>>>It seems to me that the question being asked is this: >>>> >>>> If I want to compute a path that has some form of wavelength >>>> constraints, what information do I need access to? >>>> >>>>Another question might be: >>>> >>>> If I want to signal a path with wavelength constraints what >>>> information do I need to include in the signaling message? >>>> >>>> >>>>I'd suggest that when we started on GMPLS, we were >> >>enthusiastic about >> >>>>transparent optical networks, but we were not properly >>>>focusing wavelength >>>>constraints because lambda-switching PXCs didn't take off. >>>>Therefore we >>>>didn't examine the requirements for wavelength constraints in >>>>routing and >>>>signaling. The authors of this I-D are claiming new hardware >>>>requirements >>>>for the same function. >>>> >>>> >>>> >>>>>there are >>>>>several solution possible >>>>> >>>>>- absolute values: the freq. of the wavelength: difficult to adopt >>>>>because referenced values are nominal and knowing all interactions >>>>>between wavelengths this knowledge is at the end of little >> >>practical >> >>>>>usage; (introduces implicit ordering) >>>>> >>>>>- indexed values: the # of the wavelength: it does not >> >>provide for a >> >>>>>future proof label space for inst. in case new frequencies >>>> >>>>are inserted >>>> >>>> >>>>>in the grid (introduces explicit ordering) >>>>> >>>>>- diff. values e.g. freq spacing starting from a reference >>>> >>>>value: pauses >>>> >>>> >>>>>the question of the reference value and does suffer from the former >>>>>issue (introduces implicit ordering) >>>>> >>>>>- the solution available today - cumbersome in some control plane >>>>>operations (e.g. label set translation) and not easy to >>>> >>>>troubleshoot but >>>> >>>> >>>>>independent of any physical consideration (spectral), scale to any >>>>>number of wavelength per fiber, does not introduce any >> >>ordering, the >> >>>>>most flexible (since allowing each system to maintain its specific >>>>>control operations) and the less constraining since maintaining the >>>>>control plane operations independent of any data plane specifics >>>>> >>>>> >>>> >>>>>> >>>ambda-labels >>>-00.txt> >>> >>>. >>> >> > > . > From owner-ccamp@ops.ietf.org Thu Oct 27 13:48:39 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVBrj-0003eF-2G for ccamp-archive@megatron.ietf.org; Thu, 27 Oct 2005 13:48:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18310 for ; Thu, 27 Oct 2005 13:48:22 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVC57-0005M9-Dm for ccamp-archive@ietf.org; Thu, 27 Oct 2005 14:02:30 -0400 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EVBjf-0006v1-Qa for ccamp-data@psg.com; Thu, 27 Oct 2005 17:40:19 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-4.9 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from localhost ([127.0.0.1]) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EVBjd-0006uf-0J; Thu, 27 Oct 2005 17:40:18 +0000 Message-ID: <436110D3.6070207@psg.com> Date: Thu, 27 Oct 2005 19:39:31 +0200 From: dimitri papadimitriou Reply-To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.11) Gecko/20050728 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Shiba, Sidney" CC: dimitri.papadimitriou@alcatel.be, Adrian Farrel , richard.rabbat@us.fujitsu.com, ccamp@ops.ietf.org Subject: Re: comments on draft-shiba-ccamp-gmpls-lambda-labels-00.txt References: <7CA873794E52904EAA980A074B076779B17C3C@rchemx01.fnc.net.local> In-Reply-To: <7CA873794E52904EAA980A074B076779B17C3C@rchemx01.fnc.net.local> 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: 93e7fb8fef2e780414389440f367c879 Content-Transfer-Encoding: 7bit shiba Shiba, Sidney wrote: [snip] >>>>>Another question might be: >>>>> >>>>> If I want to signal a path with wavelength constraints what >>>>> information do I need to include in the signaling message? >>>> >>>>shouldn't you ask the question, what's not workable with >>>>the present solution we have at hand in RFC3473 ? >>>> >>>>>I'd suggest that when we started on GMPLS, we were >>>>>enthusiastic about transparent optical networks, but we were >>>>>not properly focusing wavelength constraints because lambda- >>>>>switching PXCs didn't take off. >>>>> >>>>>Therefore we didn't examine the requirements for wavelength >>>>>constraints in routing and signaling. The authors of this I-D >>>>>are claiming new hardware requirements for the same function. >>>> >>>>adrian, i am not sure to understand ... hence, i would like >>>>to know from authors how the following cornerstone problem has >>>>been solved >>>> >>>>1. either the network is pre-engineered and you don't need to >>>>take care about any spectral routing specifics for traffic >>>>engineering purposes >> >>>[Sidney] In most of the cases, the network is pre-engineered using >>>spectral data, which will require a mapping effort. Of course, this >>>is feasable but we are proposing an approach that does not require >>>mapping effort when possible. >> >>would it be possible that you provide with a real estimate of >>the effort required for such mapping - i did it and it just >>requires to have a single/common profile per wavelength/color >>that you can use based on the received label value index (in >>the pre-engineered case there properties are known) > > [Sidney] An equipment that integrates an optical switch and mux/demux > can't use port mapping as the optical signal transmitted/received is > a waveband. As an analogy, the optical signal transmitted/received by > a SONET equipment is OCn and it is mux/demux internally to individual > STS-nC facilities. > > For the case of these new technology, the wavelength/frequency (nominal) > value is used to identify the facilities. but then we are in agreement there is no added value in this specific case for having such LSC value space - is my deduction from your reply correct ? >>>>2. or the network is not pre-engineered and i would like to >>>>know if the specifics of analog transmission/switching have been >>>>addressed such as to be compatible with the constraint-based routing >>>>mechanisms used today while keeping a low blocking probability >>> >>>[Sidney] As I said previously, we might need to increase the scope >>>of the draft to include wavelength availability information for the >>>routing in order to keep low the blocking probability. >> >>yes but this is where all complexity lies, as you don't know >>about the routing/selection of the wavelenght you are creating a >>closed loop such that your network will convergence problems; the >>major issue with lambda switching is that locality principle is not >>preserved, setting up a path in a non pre-engineered network implies >>that a reservation on a link can have impact on other link along the >>path but even on links that are not followed by that - > > [Sidney] You touched a very important point. What I propose is to > extend the scope of this discussion to include the wavelength availability > as LSA routing information in order to allow path computation to take > into account wavelength continuity constraint. For scalability the following > structure could be used: the issue here is the coupling between the spectral information to the TE routing advertisement, as the former does not respect any locality principle a given event may create instability in your TEDB (in fact it may never converge again) the reason is that lighting up a certain path is not only disabling the lambda on the link where used but may also disable usage of certain frequencies on links that are not traversed by this LSC LSP; the latter can subsequently enable other wavelength(s) that were previously not possible ... hence, you can reach state where you would be oscillating when there is no appropriate pre-engineering of the network > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Start Frequency | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Frequency spacing | Number of Frequencies | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Frequency Availability Bitmap | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Frequency Availability Bitmap (cont) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > - Start Frequency (32-bit) - this attribute indicates the first > frequency identified by the least significant bit in the Frequency > Availability bitmap field. IEEE Floating point value. > - Frequency Spacing (20-bit) - this attribute indicates the spacing > (in MHz) between adjacent frequencies. > - Number of Frequencies (12-bit) - this attribute indicates the number > of frequencies that is encoded in the Frequency Availability Bitmap > field. > - Frequency Availability Bitmap (variable) - This variable length > attribute is a bitmap structure where each bit indicates if a frequency > is available or not. When set to 0, the frequency is available and when > set to 1 it indicates that the frequency is already in use. The least > significant bit (LSB) identifies the start frequency. The remaining bits > indicate the subsequent frequencies in decrement of spacing. For example, > if bit0 = 195.70, bit1 = 195.60, bit2 = 195.50, and so on for a spacing > of 100 GHz. Each 32-bit word can encode the availability of 32 wavelengths. > As an example, a 40 wavelength capable system, 2 x 32-bit data structure > is necessary, where bit40 - bit63 are padding bits. the issue is not (only) about the representation (note that there are representation that are more efficient (it terms of encoding) than others) the issue is about feasibility, there is another specific issue about the amount of information that would need to be flooded but more importantly - the homogeneity - you seem to assume that spacing/and other properties are homogeneously distributed but this is not necessarily the case; hence how a given system would be able to process information of other systems for which it is not capable to process the specifics From owner-ccamp@ops.ietf.org Thu Oct 27 19:05:30 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVGoL-0005Er-Lt for ccamp-archive@megatron.ietf.org; Thu, 27 Oct 2005 19:05:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25456 for ; Thu, 27 Oct 2005 19:05:12 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVH1n-0004sT-Ek for ccamp-archive@ietf.org; Thu, 27 Oct 2005 19:19:23 -0400 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EVGcD-000OwI-D3 for ccamp-data@psg.com; Thu, 27 Oct 2005 22:52:57 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-4.6 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [147.28.0.62] (helo=usmovnazinin.alcatel.com) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EVGcC-000Ow4-DH; Thu, 27 Oct 2005 22:52:56 +0000 Date: Thu, 27 Oct 2005 15:52:40 -0700 From: Alex Zinin Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <15410687771.20051027155240@psg.com> To: "Adrian Farrel" CC: ccamp@ops.ietf.org, "Bill Fenner" , "'Kireeti Kompella'" Subject: Re: draft-ietf-ccamp-rsvp-node-id-based-hello-02.txt now back with AD In-Reply-To: <133501c5c03d$ba40e3c0$28849ed9@Puppy> References: <046701c5b3ed$8271e310$93849ed9@Puppy> <133501c5c03d$ba40e3c0$28849ed9@Puppy> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.8 (/) X-Scan-Signature: 3971661e40967acfc35f708dd5f33760 Content-Transfer-Encoding: 7bit Adrian, Just requested LC for it, extending it by 2 weeks b/c of the IETF meeting. -- Alex http://www.psg.com/~zinin Friday, September 23, 2005, 5:29:24 AM, Adrian Farrel wrote: > Hi Alex, > We held a further WG last call on this I-D after updating it to Proposed > Standard as you requested. > No-one objected to this change, so the I-D is now back with you for > approval. > Thanks, > Adrian > ----- Original Message ----- > From: "Adrian Farrel" > To: > Sent: Wednesday, September 07, 2005 9:48 PM > Subject: Short further last call on > draft-ietf-ccamp-rsvp-node-id-based-hello-02.txt >> Hi, >> >> Alex has reviewed this I-D as AD and says it is fine, but he thinks we >> should take it down the standards track as Proposed Standard not BCP as > it >> was previously marked. >> >> This revision changes: >> - proposed status >> - IPR boilerplate >> - IANA clause to be a little more (about 10 words) detailed >> >> Since we have changed the proposed status, we need to check back with > you >> guys. >> >> Let's have a two week last call on this change. >> >> If you do spot other issues as you go, then I guess we can handle them >> too. >> >> Last call will end 12 noon GMT on Thursday 22nd September. >> >> Thanks, >> Adrian >> >> >> ----- Original Message ----- >> From: >> To: >> Cc: >> Sent: Wednesday, September 07, 2005 8:50 PM >> Subject: I-D ACTION:draft-ietf-ccamp-rsvp-node-id-based-hello-02.txt >> >> >> > A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> > This draft is a work item of the Common Control and Measurement Plane >> Working Group of the IETF. >> > >> > Title : Node ID based RSVP Hello: A Clarification Statement >> > Author(s) : Z. Ali, et al. >> > Filename : draft-ietf-ccamp-rsvp-node-id-based-hello-02.txt >> > Pages : 7 >> > Date : 2005-9-7 >> > >> > Use of Node-ID based RSVP Hello messages is implied in a number of >> > cases, e.g., when data and control plan are separated, when TE > links >> > are unnumbered. Furthermore, when link level failure detection is >> > performed by some means other than exchanging RSVP Hello messages, >> > use of Node-ID based Hello session is optimal for detecting > signaling >> > adjacency failure for Resource reSerVation Protocol-Traffic >> > Engineering (RSVP-TE). Nonetheless, this implied behavior is > unclear >> > and this document formalizes use of Node-ID based RSVP Hello > session >> > as a best current practice (BCP) in some scenarios. The procedure >> > described in this document applies to both Multi-Protocol Label >> > Switching (MPLS) and Generalized MPLS (GMPLS) capable nodes. >> > >> > A URL for this Internet-Draft is: >> > >> > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rsvp-node-id-based-hello-02.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-rsvp-node-id-based-hello-02.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-rsvp-node-id-based-hello-02.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. >> > >> >> >> ------------------------------------------------------------------------ > -- >> ------ >> >> >> > _______________________________________________ >> > I-D-Announce mailing list >> > I-D-Announce@ietf.org >> > https://www1.ietf.org/mailman/listinfo/i-d-announce >> > >> >> >> >> From owner-ccamp@ops.ietf.org Thu Oct 27 20:15:46 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVHuM-0001Na-17 for ccamp-archive@megatron.ietf.org; Thu, 27 Oct 2005 20:15:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29405 for ; Thu, 27 Oct 2005 20:15:28 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVI7o-0006qI-UD for ccamp-archive@ietf.org; Thu, 27 Oct 2005 20:29:41 -0400 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EVHpq-0003PC-R5 for ccamp-data@psg.com; Fri, 28 Oct 2005 00:11:06 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=3.1.0 Received: from [128.9.160.161] (helo=boreas.isi.edu) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EVHpq-0003P1-51 for ccamp@ops.ietf.org; Fri, 28 Oct 2005 00:11:06 +0000 Received: from ISI.EDU (adma.isi.edu [128.9.160.239]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j9S0AWL16553; Thu, 27 Oct 2005 17:10:32 -0700 (PDT) Message-Id: <200510280010.j9S0AWL16553@boreas.isi.edu> To: ietf-announce@ietf.org Subject: RFC 4202 on Routing Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS) Cc: rfc-editor@rfc-editor.org, ccamp@ops.ietf.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Thu, 27 Oct 2005 17:10:32 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: rfc-ed@isi.edu Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.4 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b --NextPart A new Request for Comments is now available in online RFC libraries. RFC 4202 Title: Routing Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS) Author(s): K. Kompella, Ed., Y. Rekhter, Ed. Status: Standards Track Date: October 2005 Mailbox: kireeti@juniper.net, yakov@juniper.net Pages: 27 Characters: 57333 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-ccamp-gmpls-routing-09.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc4202.txt This document specifies routing extensions in support of carrying link state information for Generalized Multi-Protocol Label Switching (GMPLS). This document enhances the routing extensions required to support MPLS Traffic Engineering (TE). This document is a product of the Common Control and Measurement Plane Working Group of the IETF. This is now a Proposed Standard Protocol. 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 ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <051027170924.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc4202 --OtherAccess Content-Type: Message/External-body; name="rfc4202.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <051027170924.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- From owner-ccamp@ops.ietf.org Thu Oct 27 20:17:58 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVHwU-00022G-Mt for ccamp-archive@megatron.ietf.org; Thu, 27 Oct 2005 20:17:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29729 for ; Thu, 27 Oct 2005 20:17:41 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVI9w-0006yf-KM for ccamp-archive@ietf.org; Thu, 27 Oct 2005 20:31:53 -0400 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EVHsR-0003Xi-7Q for ccamp-data@psg.com; Fri, 28 Oct 2005 00:13:47 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=3.1.0 Received: from [128.9.160.161] (helo=boreas.isi.edu) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EVHsQ-0003XV-KB for ccamp@ops.ietf.org; Fri, 28 Oct 2005 00:13:46 +0000 Received: from ISI.EDU (adma.isi.edu [128.9.160.239]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j9S0BsL17198; Thu, 27 Oct 2005 17:11:54 -0700 (PDT) Message-Id: <200510280011.j9S0BsL17198@boreas.isi.edu> To: ietf-announce@ietf.org Subject: RFC 4203 on OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS) Cc: rfc-editor@rfc-editor.org, ccamp@ops.ietf.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Thu, 27 Oct 2005 17:11:54 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: rfc-ed@isi.edu Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.4 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 --NextPart A new Request for Comments is now available in online RFC libraries. RFC 4203 Title: OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS) Author(s): K. Kompella, Ed., Y. Rekhter, Ed. Status: Standards Track Date: October 2005 Mailbox: kireeti@juniper.net, yakov@juniper.net Pages: 11 Characters: 23130 Updates: 3630 I-D Tag: draft-ietf-ccamp-ospf-gmpls-extensions-12.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc4203.txt This document specifies encoding of extensions to the OSPF routing protocol in support of Generalized Multi-Protocol Label Switching (GMPLS). This document is a product of the Common Control and Measurement Plane Working Group of the IETF. This is now a Proposed Standard Protocol. 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 ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <051027171050.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc4203 --OtherAccess Content-Type: Message/External-body; name="rfc4203.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <051027171050.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- From owner-ccamp@ops.ietf.org Thu Oct 27 20:23:19 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVI1f-0003u1-Aw for ccamp-archive@megatron.ietf.org; Thu, 27 Oct 2005 20:23:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00741 for ; Thu, 27 Oct 2005 20:23:01 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVIF6-0007KC-Tx for ccamp-archive@ietf.org; Thu, 27 Oct 2005 20:37:14 -0400 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EVHxB-0003s6-SN for ccamp-data@psg.com; Fri, 28 Oct 2005 00:18:41 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=3.1.0 Received: from [128.9.160.161] (helo=boreas.isi.edu) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EVHxB-0003ru-85 for ccamp@ops.ietf.org; Fri, 28 Oct 2005 00:18:41 +0000 Received: from ISI.EDU (adma.isi.edu [128.9.160.239]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j9S0DBL17392; Thu, 27 Oct 2005 17:13:11 -0700 (PDT) Message-Id: <200510280013.j9S0DBL17392@boreas.isi.edu> To: ietf-announce@ietf.org Subject: RFC 4204 on Link Management Protocol (LMP) Cc: rfc-editor@rfc-editor.org, ccamp@ops.ietf.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Thu, 27 Oct 2005 17:13:11 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: rfc-ed@isi.edu Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.4 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f --NextPart A new Request for Comments is now available in online RFC libraries. RFC 4204 Title: Link Management Protocol (LMP) Author(s): J. Lang, Ed. Status: Standards Track Date: October 2005 Mailbox: jplang@ieee.org Pages: 86 Characters: 186515 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-ccamp-lmp-10.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc4204.txt For scalability purposes, multiple data links can be combined to form a single traffic engineering (TE) link. Furthermore, the management of TE links is not restricted to in-band messaging, but instead can be done using out-of-band techniques. This document specifies a link management protocol (LMP) that runs between a pair of nodes and is used to manage TE links. Specifically, LMP will be used to maintain control channel connectivity, verify the physical connectivity of the data links, correlate the link property information, suppress downstream alarms, and localize link failures for protection/restoration purposes in multiple kinds of networks. This document is a product of the Common Control and Measurement Plane Working Group of the IETF. This is now a Proposed Standard Protocol. 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 ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <051027171200.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc4204 --OtherAccess Content-Type: Message/External-body; name="rfc4204.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <051027171200.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- From owner-ccamp@ops.ietf.org Thu Oct 27 20:27:33 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVI5l-0005s3-CY for ccamp-archive@megatron.ietf.org; Thu, 27 Oct 2005 20:27:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01876 for ; Thu, 27 Oct 2005 20:27:15 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVIJD-0007k3-Qt for ccamp-archive@ietf.org; Thu, 27 Oct 2005 20:41:28 -0400 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EVI1b-0004Qa-Lk for ccamp-data@psg.com; Fri, 28 Oct 2005 00:23:15 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=3.1.0 Received: from [128.9.160.161] (helo=boreas.isi.edu) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EVI1b-0004QO-1j for ccamp@ops.ietf.org; Fri, 28 Oct 2005 00:23:15 +0000 Received: from ISI.EDU (adma.isi.edu [128.9.160.239]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j9S0LAL20987; Thu, 27 Oct 2005 17:21:10 -0700 (PDT) Message-Id: <200510280021.j9S0LAL20987@boreas.isi.edu> To: ietf-announce@ietf.org Subject: RFC 4207 on Synchronous Optical Network (SONET)/Synchronous Digital Hierarchy (SDH) Encoding for Link Management Protocol (LMP) Test Messages Cc: rfc-editor@rfc-editor.org, ccamp@ops.ietf.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Thu, 27 Oct 2005 17:21:10 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: rfc-ed@isi.edu Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.4 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e --NextPart A new Request for Comments is now available in online RFC libraries. RFC 4207 Title: Synchronous Optical Network (SONET)/Synchronous Digital Hierarchy (SDH) Encoding for Link Management Protocol (LMP) Test Messages Author(s): J. Lang, D. Papadimitriou Status: Standards Track Date: October 2005 Mailbox: jplang@ieee.org, dimitri.papadimitriou@alcatel.be Pages: 15 Characters: 29390 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-ccamp-lmp-test-sonet-sdh-04.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc4207.txt This document details the Synchronous Optical Network (SONET)/Synchronous Digital Hierarchy (SDH) technology-specific information needed when sending Link Management Protocol (LMP) test messages. This document is a product of the Common Control and Measurement Plane Working Group of the IETF. This is now a Proposed Standard Protocol. 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 ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <051027171637.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc4207 --OtherAccess Content-Type: Message/External-body; name="rfc4207.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <051027171637.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- From owner-ccamp@ops.ietf.org Thu Oct 27 20:34:51 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVICp-0006KH-FG for ccamp-archive@megatron.ietf.org; Thu, 27 Oct 2005 20:34:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05579 for ; Thu, 27 Oct 2005 20:34:34 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVIQG-0000ft-3u for ccamp-archive@ietf.org; Thu, 27 Oct 2005 20:48:44 -0400 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EVI8B-0004sN-T2 for ccamp-data@psg.com; Fri, 28 Oct 2005 00:30:03 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=3.1.0 Received: from [128.9.160.161] (helo=boreas.isi.edu) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EVI8B-0004rn-8K for ccamp@ops.ietf.org; Fri, 28 Oct 2005 00:30:03 +0000 Received: from ISI.EDU (adma.isi.edu [128.9.160.239]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j9S0NBL21587; Thu, 27 Oct 2005 17:23:11 -0700 (PDT) Message-Id: <200510280023.j9S0NBL21587@boreas.isi.edu> To: ietf-announce@ietf.org Subject: RFC 4208 on Generalized Multiprotocol Label Switching (GMPLS) User-Network Interface (UNI): Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Support for the Overlay Model Cc: rfc-editor@rfc-editor.org, ccamp@ops.ietf.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Thu, 27 Oct 2005 17:23:11 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: rfc-ed@isi.edu Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.4 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 --NextPart A new Request for Comments is now available in online RFC libraries. RFC 4208 Title: Generalized Multiprotocol Label Switching (GMPLS) User-Network Interface (UNI): Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Support for the Overlay Model Author(s): G. Swallow, J. Drake, H. Ishimatsu, Y. Rekhter Status: Standards Track Date: October 2005 Mailbox: swallow@cisco.com, John.E.Drake2@boeing.com, hirokazu.ishimatsu@g1m.jp, yakov@juniper.net Pages: 13 Characters: 28693 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-ccamp-gmpls-overlay-05.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc4208.txt Generalized Multiprotocol Label Switching (GMPLS) defines both routing and signaling protocols for the creation of Label Switched Paths (LSPs) in various switching technologies. These protocols can be used to support a number of deployment scenarios. This memo addresses the application of GMPLS to the overlay model. This document is a product of the Common Control and Measurement Plane Working Group of the IETF. This is now a Proposed Standard Protocol. 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 ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <051027172201.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc4208 --OtherAccess Content-Type: Message/External-body; name="rfc4208.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <051027172201.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- From owner-ccamp@ops.ietf.org Thu Oct 27 20:43:19 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVIL1-0003dL-8j for ccamp-archive@megatron.ietf.org; Thu, 27 Oct 2005 20:43:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06557 for ; Thu, 27 Oct 2005 20:43:01 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVIYT-00017L-8p for ccamp-archive@ietf.org; Thu, 27 Oct 2005 20:57:14 -0400 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EVIHW-0005Q5-9w for ccamp-data@psg.com; Fri, 28 Oct 2005 00:39:42 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [132.151.6.50] (helo=newodin.ietf.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1EVIHV-0005Pu-Of for ccamp@ops.ietf.org; Fri, 28 Oct 2005 00:39:41 +0000 Received: from apache by newodin.ietf.org with local (Exim 4.43) id 1EVIHR-0003ix-1N; Thu, 27 Oct 2005 20:39:37 -0400 X-test-idtracker: no To: IETF-Announce From: The IESG Subject: Last Call: 'Node ID based RSVP Hello: A Clarification Statement' to BCP Reply-to: iesg@ietf.org CC: Message-Id: Date: Thu, 27 Oct 2005 20:39:37 -0400 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 The IESG has received a request from the Common Control and Measurement Plane WG to consider the following document: - 'Node ID based RSVP Hello: A Clarification Statement ' as a BCP 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 2005-11-25. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rsvp-node-id-based-hello-02.txt From owner-ccamp@ops.ietf.org Fri Oct 28 06:09:43 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVRB9-0007U5-67 for ccamp-archive@megatron.ietf.org; Fri, 28 Oct 2005 06:09:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05260 for ; Fri, 28 Oct 2005 06:09:26 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVROc-0000Hw-E3 for ccamp-archive@ietf.org; Fri, 28 Oct 2005 06:23:43 -0400 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EVR4U-000I3O-Qq for ccamp-data@psg.com; Fri, 28 Oct 2005 10:02:50 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: ** X-Spam-Status: No, score=2.8 required=5.0 tests=AWL,BAYES_00,HTML_50_60, HTML_IMAGE_ONLY_16,HTML_MESSAGE,MIME_BASE64_NO_NAME,MIME_BASE64_TEXT, MIME_HTML_MOSTLY,RCVD_IN_WHOIS_INVALID autolearn=no version=3.1.0 Received: from [129.254.16.131] (helo=email1.etri.info) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EVR4T-000I3B-IN for ccamp@ops.ietf.org; Fri, 28 Oct 2005 10:02:49 +0000 Received: from mail pickup service by email1.etri.info with Microsoft SMTPSVC; Fri, 28 Oct 2005 19:04:20 +0900 X-ReadCheckName: ccamp%40ops.ietf.org Thread-Topic: Two Drafts for Resilience of Control Plane X-ReadCheckMessageID: <8630a6db-0c31-49ab-a798-13b0dda04553@etri.re.kr> thread-index: AcXbpva8X72puaIDTr2d5rSGc74m/g== Content-Transfer-Encoding: 7bit Reply-To: "Kim Young Hwa" From: "Kim Young Hwa" To: Subject: Two Drafts for Resilience of Control Plane Date: Fri, 28 Oct 2005 19:04:20 +0900 Comment: GQ19@|@ZEk=E?,18?x, OAM1b MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_92B4_01C5DBF2.66A6C060" X-Mailer: Microsoft CDO for Exchange 2000 Content-Class: urn:content-classes:message Importance: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.181 X-OriginalArrivalTime: 28 Oct 2005 10:04:20.0273 (UTC) FILETIME=[F6DE1210:01C5DBA6] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 4.5 (++++) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 This is a multi-part message in MIME format. ------=_NextPart_000_92B4_01C5DBF2.66A6C060 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: base64 ------=_NextPart_000_92B4_01C5DBF2.66A6C060 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: base64 PERJViBpZD1tc2dib2R5IHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBTeXN0 ZW0iPg0KPERJVj5EZWFyIGFsbCw8L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPkkgcG9z dGVkIHR3byBkcmFmdHMgZm9yIHRoZSByZXNpbGllbmNlIG9mIGNvbnRyb2wgcGxhbmUuPC9ESVY+ DQo8RElWPk9uZSBpcyBmb3IgcmVxdWlyZW1lbnRzIG9mIHRoZSByZXNpbGllbmNlIG9mIGNvbnRy b2wgcGxhbmUsIHRoZSBvdGhlciBpcyBmb3IgYSBwcm90b2NvbCBzcGVjaWZpY2F0aW9uIGFzIGEg c29sdXRpb24gb2YgdGhhdCAuPC9ESVY+DQo8RElWPlRoZXNlIGFyZSBub3cgYXZhaWxhYmxlIGF0 OjwvRElWPg0KPERJVj48QSBocmVmPSJodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC1raW0tY2NhbXAtY3ByLXJlcXRzLTAxLnR4dCIgdGFyZ2V0PV9ibGFuaz5odHRwOi8v d3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1raW0tY2NhbXAtY3ByLXJlcXRzLTAx LnR4dDwvQT48L0RJVj4NCjxESVY+PEEgaHJlZj0iaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5l dC1kcmFmdHMvZHJhZnQta2ltLWNjYW1wLWFjY3AtcHJvdG9jb2wtMDAudHh0IiB0YXJnZXQ9X2Js YW5rPmh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWtpbS1jY2FtcC1h Y2NwLXByb3RvY29sLTAwLnR4dDwvQT48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPkkg d2FudCB5b3VyIGNvbW1lbnRzLjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+UmVnYXJk czwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+WW91bmcuPC9ESVY+DQo8RElWPiZuYnNw OzwvRElWPg0KPERJVj49PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT08QlI+WW91 bmctSHdhIEtpbTxCUj5QcmluY2lwYWwgTWVtYmVyIC8gUGguRDxCUj5CY04gUmVzZWFyY2ggRGl2 aXNpb24sIEVUUkk8QlI+VGVsOiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyArODItNDItODYwLTU4 MTk8QlI+RmF4OiZuYnNwOyZuYnNwOyZuYnNwOyArODItNDItODYwLTU0NDA8QlI+ZS1tYWlsOiA8 QSBocmVmPSJtYWlsdG86eWh3a2ltQGV0cmkucmUua3IiPnlod2tpbUBldHJpLnJlLmtyPC9BPjxC Uj49PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT08L0RJVj48L0RJVj48aW1nIHN0 eWxlPSJkaXNwbGF5Om5vbmUiIHdpZHRoPTAgaGVpZ2h0PTAgc3JjPSJodHRwOi8vdW1haWwuZXRy aS5yZS5rci9FeHRlcm5hbF9SZWFkQ2hlY2suYXNweD9lbWFpbD1jY2FtcEBvcHMuaWV0Zi5vcmcm bmFtZT1jY2FtcCU0MG9wcy5pZXRmLm9yZyZmcm9tZW1haWw9eWh3a2ltQGV0cmkucmUua3ImbWVz c2FnZWlkPSUzQzg2MzBhNmRiLTBjMzEtNDlhYi1hNzk4LTEzYjBkZGEwNDU1M0BldHJpLnJlLmty JTNFIj4= ------=_NextPart_000_92B4_01C5DBF2.66A6C060-- From owner-ccamp@ops.ietf.org Fri Oct 28 06:14:18 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVRFZ-0002QF-3d for ccamp-archive@megatron.ietf.org; Fri, 28 Oct 2005 06:14:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05499 for ; Fri, 28 Oct 2005 06:14:00 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVRSr-0000QL-7z for ccamp-archive@ietf.org; Fri, 28 Oct 2005 06:28:17 -0400 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EVR9q-000IJB-RR for ccamp-data@psg.com; Fri, 28 Oct 2005 10:08:22 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO,HTML_50_60,HTML_MESSAGE autolearn=ham version=3.1.0 Received: from [62.241.162.32] (helo=ranger.systems.pipex.net) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EVR9p-000IIu-Pm for ccamp@ops.ietf.org; Fri, 28 Oct 2005 10:08:22 +0000 Received: from dnni.com (81-178-2-190.dsl.pipex.com [81.178.2.190]) by ranger.systems.pipex.net (Postfix) with ESMTP id EA84EE000341 for ; Fri, 28 Oct 2005 11:08:13 +0100 (BST) Received: from Puppy ([217.158.132.33] RDNS failed) by dnni.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 28 Oct 2005 11:08:10 +0100 Message-ID: <077001c5dba7$efd60850$de849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Startling news : new RFCs Date: Fri, 28 Oct 2005 11:10:50 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_076D_01C5DBB0.41536A80" 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: 28 Oct 2005 10:08:12.0762 (UTC) FILETIME=[817113A0:01C5DBA7] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.6 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 This is a multi-part message in MIME format. ------=_NextPart_000_076D_01C5DBB0.41536A80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, As you'll have seen, a few new RFCs have just been announced. The full list is as follows. RFC 4201 Link Bundling in MPLS Traffic Engineering (TE) RFC 4202 Routing Extensions in Support of Generalized=20 Multi-Protocol Label Switching (GMPLS) RFC 4203 OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS) RFC 4204 Link Management Protocol (LMP) RFC 4205 Intermediate System to Intermediate System (IS-IS) Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS) RFC 4206 Label Switched Paths (LSP) Hierarchy with=20 Generalized Multi-Protocol Label Switching (GMPLS) Traffic Engineering (TE) RFC 4207 Synchronous Optical Network (SONET)/Synchronous Digital Hierarchy (SDH) Encoding for Link Management Protocol (LMP) Test Messages RFC 4208 Generalized Multiprotocol Label Switching (GMPLS) User-Network Interface (UNI): Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Support for the Overlay Model RFC 4209 Link Management Protocol (LMP) for Dense=20 Wavelength Division Multiplexing (DWDM) Optical Line Systems (Note that RFC4209 doesn't appear to have been announced, but it has = been published any way.) The charter page will be updated to reflect this soon. Many thanks to everyone involved.=20 Adrian ------=_NextPart_000_076D_01C5DBB0.41536A80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,

As you'll have seen, a few = new RFCs=20 have just been announced.
The full list is as follows.

RFC = 4201 Link=20 Bundling in MPLS Traffic Engineering (TE)
RFC 4202 Routing Extensions = in=20 Support of Generalized =
        =20 Multi-Protocol Label Switching (GMPLS)
RFC 4203 OSPF Extensions in = Support of=20 Generalized
         = Multi-Protocol=20 Label Switching (GMPLS)
RFC 4204 Link Management Protocol = (LMP)
RFC 4205=20 Intermediate System to Intermediate System=20 (IS-IS)
         Extensions = in=20 Support of Generalized=20 Multi-Protocol
         Label = Switching (GMPLS)
RFC 4206 Label Switched Paths (LSP) Hierarchy with=20
         Generalized = Multi-Protocol=20 Label Switching = (GMPLS)
        =20 Traffic Engineering (TE)
RFC 4207 Synchronous Optical Network=20 (SONET)/Synchronous
         = Digital=20 Hierarchy (SDH) Encoding for=20 Link
         Management = Protocol=20 (LMP) Test Messages
RFC 4208 Generalized Multiprotocol Label = Switching=20 (GMPLS)
         User-Network = Interface (UNI):
         = Resource=20 ReserVation Protocol-Traffic=20 Engineering
         = (RSVP-TE)=20 Support for the Overlay Model
RFC 4209 Link Management Protocol (LMP) = for Dense
        =20 Wavelength Division Multiplexing (DWDM) Optical
       =20  Line Systems
 
(Note that RFC4209 doesn't appear to = have been=20 announced, but it has been published any way.)
 
The charter page will be updated to reflect this soon.

Many = thanks=20 to everyone involved.

Adrian
------=_NextPart_000_076D_01C5DBB0.41536A80-- From owner-ccamp@ops.ietf.org Fri Oct 28 10:21:14 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVV6Y-0004Z6-Lj for ccamp-archive@megatron.ietf.org; Fri, 28 Oct 2005 10:21:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19904 for ; Fri, 28 Oct 2005 10:20:58 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVVK6-0007FY-B5 for ccamp-archive@ietf.org; Fri, 28 Oct 2005 10:35:16 -0400 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EVUzk-00064h-TM for ccamp-data@psg.com; Fri, 28 Oct 2005 14:14:12 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE autolearn=ham version=3.1.0 Received: from [64.102.122.149] (helo=rtp-iport-2.cisco.com) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EVUzh-00064S-Qu for ccamp@ops.ietf.org; Fri, 28 Oct 2005 14:14:09 +0000 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 28 Oct 2005 10:14:09 -0400 X-IronPort-AV: i="3.97,263,1125892800"; d="scan'208,217"; a="74621505:sNHT36378980" 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 j9SEDU2b021664; Fri, 28 Oct 2005 10:14:06 -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); Fri, 28 Oct 2005 10:13:50 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5DBC9.D19D9A71" Subject: RE: Two Drafts for Resilience of Control Plane Date: Fri, 28 Oct 2005 10:13:49 -0400 Message-ID: Thread-Topic: Two Drafts for Resilience of Control Plane Thread-Index: AcXbpva8X72puaIDTr2d5rSGc74m/gAIju6g From: "Zafar Ali \(zali\)" To: "Kim Young Hwa" , X-OriginalArrivalTime: 28 Oct 2005 14:13:50.0560 (UTC) FILETIME=[D1DA9600:01C5DBC9] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.7 (/) X-Scan-Signature: 156eddb66af16eef49a76ae923b15b92 This is a multi-part message in MIME format. ------_=_NextPart_001_01C5DBC9.D19D9A71 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi All,=20 =20 I am unable to understand the problem we are trying to solve or fabricate. My control network is IP based and IP has proven resiliency (Internet *does* work), why would I like to take control plan resiliency problem at a layer *above-IP* and complicate my life. Did I miss something?=20 =20 Thanks =20 Regards... Zafar=20 ________________________________ From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Kim Young Hwa Sent: Friday, October 28, 2005 6:04 AM To: ccamp@ops.ietf.org Subject: Two Drafts for Resilience of Control Plane =09 =09 Dear all, =20 I posted two drafts for the resilience of control plane. One is for requirements of the resilience of control plane, the other is for a protocol specification as a solution of that . These are now available at: =09 http://www.ietf.org/internet-drafts/draft-kim-ccamp-cpr-reqts-01.txt =09 http://www.ietf.org/internet-drafts/draft-kim-ccamp-accp-protocol-00.txt =20 I want your comments. =20 Regards =20 Young. =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 Young-Hwa Kim Principal Member / Ph.D BcN Research Division, ETRI Tel: +82-42-860-5819 Fax: +82-42-860-5440 e-mail: yhwkim@etri.re.kr = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =09 =20 ------_=_NextPart_001_01C5DBC9.D19D9A71 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
Hi All,
 
I am unable to understand the problem we are = trying to=20 solve or fabricate. My control network is IP based and = IP has proven=20 resiliency (Internet *does* work), why would I like to take control plan = resiliency problem at a layer *above-IP* and complicate my life. Did I = miss=20 something?
 
Thanks
 
Regards... Zafar

From: owner-ccamp@ops.ietf.org=20 [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Kim Young=20 Hwa
Sent: Friday, October 28, 2005 6:04 AM
To:=20 ccamp@ops.ietf.org
Subject: Two Drafts for Resilience of = Control=20 Plane

Dear all,
 
I posted two drafts for the resilience of control plane.
One is for requirements of the resilience of control plane, the = other is=20 for a protocol specification as a solution of that .
These are now available at:
http://www.ietf.org/internet-drafts/draft-kim-ccamp-cpr-r= eqts-01.txt
http://www.ietf.org/internet-drafts/draft-kim-ccamp-accp-= protocol-00.txt
 
I want your comments.
 
Regards
 
Young.
 
=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Young-Hwa Kim
Principal = Member=20 / Ph.D
BcN Research Division, ETRI
Tel:    =20 +82-42-860-5819
Fax:    +82-42-860-5440
e-mail: = yhwkim@etri.re.kr
=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D
------_=_NextPart_001_01C5DBC9.D19D9A71-- From owner-ccamp@ops.ietf.org Fri Oct 28 11:59:26 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVWda-0005qF-5A for ccamp-archive@megatron.ietf.org; Fri, 28 Oct 2005 11:59:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26064 for ; Fri, 28 Oct 2005 11:59:09 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVWrA-0001pj-9i for ccamp-archive@ietf.org; Fri, 28 Oct 2005 12:13:29 -0400 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EVWUh-000Bk7-1F for ccamp-data@psg.com; Fri, 28 Oct 2005 15:50:15 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [68.142.200.149] (helo=web30806.mail.mud.yahoo.com) by psg.com with smtp (Exim 4.52 (FreeBSD)) id 1EVWUg-000Bjt-0W for ccamp@ops.ietf.org; Fri, 28 Oct 2005 15:50:14 +0000 Received: (qmail 73680 invoked by uid 60001); 28 Oct 2005 15:50:12 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=Xy/KC/QEQUOOD9b+s8ebToX45nE5kCMvHPscXK0oAaRP30jBIYeBx2+T9CSZOaFdvy7keIbVFd0ptAO23NxGGJ08g4ExLgMirGdKUoYSSsNcZxGpHSFdG2lq97NJrr6EgUuwcz4xNCfKREynW+qgX9F/m2ix5uwZaWGDxZwedKs= ; Message-ID: <20051028155012.73678.qmail@web30806.mail.mud.yahoo.com> Received: from [68.100.80.11] by web30806.mail.mud.yahoo.com via HTTP; Fri, 28 Oct 2005 08:50:12 PDT Date: Fri, 28 Oct 2005 08:50:12 -0700 (PDT) From: Igor Bryskin Subject: RE: Two Drafts for Resilience of Control Plane To: "Zafar Ali \(zali\)" , Kim Young Hwa , ccamp@ops.ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.6 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Content-Transfer-Encoding: 8bit Zafar, The problem arises when the control plane is decoupled from the data plane. The question is do we need such decoupling in IP networks? Consider, for example, the situation when several parallel PSC data links bundled together and controlled by a single control channel. Does it mean in this case that when the control channel fails all associated data links also fail? Do we need to reroute in this case LSPs that use the data links? Can we rely in this case on control plane indications to decide whether an associated data link is healthy or not (in other words, can we rely on RSVP Hellos or should we use, for example, BTD)? Should we be capable to recover control channels without disturbing data plane? I think control plane resilience is important for all layers. You are right, Internet does work, however, we do need for some reason TE and (fast) recovery in IP as much as in other layers,don't we? Cheers, Igor --- "Zafar Ali (zali)" wrote: > Hi All, > > I am unable to understand the problem we are trying > to solve or > fabricate. My control network is IP based and IP has > proven resiliency > (Internet *does* work), why would I like to take > control plan resiliency > problem at a layer *above-IP* and complicate my > life. Did I miss > something? > > Thanks > > Regards... Zafar > > > ________________________________ > > From: owner-ccamp@ops.ietf.org > [mailto:owner-ccamp@ops.ietf.org] > On Behalf Of Kim Young Hwa > Sent: Friday, October 28, 2005 6:04 AM > To: ccamp@ops.ietf.org > Subject: Two Drafts for Resilience of Control Plane > > > Dear all, > > I posted two drafts for the resilience of control > plane. > One is for requirements of the resilience of > control plane, the > other is for a protocol specification as a solution > of that . > These are now available at: > > http://www.ietf.org/internet-drafts/draft-kim-ccamp-cpr-reqts-01.txt > > http://www.ietf.org/internet-drafts/draft-kim-ccamp-accp-protocol-00.txt > > I want your comments. > > Regards > > Young. > > ==================================== > Young-Hwa Kim > Principal Member / Ph.D > BcN Research Division, ETRI > Tel: +82-42-860-5819 > Fax: +82-42-860-5440 > e-mail: yhwkim@etri.re.kr > ==================================== > > g&name=ccamp%40ops.ietf.org&fromemail=yhwkim@etri.re.kr&messageid=%3C863 > 0a6db-0c31-49ab-a798-13b0dda04553@etri.re.kr%3E> > > __________________________________ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com From owner-ccamp@ops.ietf.org Fri Oct 28 12:04:55 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVWit-0006t3-07 for ccamp-archive@megatron.ietf.org; Fri, 28 Oct 2005 12:04:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26411 for ; Fri, 28 Oct 2005 12:04:38 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVWwK-0001zO-78 for ccamp-archive@ietf.org; Fri, 28 Oct 2005 12:18:58 -0400 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EVWcf-000CDw-TI for ccamp-data@psg.com; Fri, 28 Oct 2005 15:58:29 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=3.1.0 Received: from [217.32.164.137] (helo=smtp1.smtp.bt.com) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EVWce-000CDT-TD for ccamp@ops.ietf.org; Fri, 28 Oct 2005 15:58:29 +0000 Received: from i2km98-ukbr.domain1.systemhost.net ([193.113.197.85]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 28 Oct 2005 16:58:27 +0100 Received: from i2km07-ukbr.domain1.systemhost.net ([193.113.197.26]) by i2km98-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Fri, 28 Oct 2005 16:58:26 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.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: Two Drafts for Resilience of Control Plane Date: Fri, 28 Oct 2005 16:58:26 +0100 Message-ID: <0536FC9B908BEC4597EE721BE6A35389121B05E7@i2km07-ukbr.domain1.systemhost.net> Thread-Topic: Two Drafts for Resilience of Control Plane Thread-Index: AcXb15NliMHpReJpQZqOhK30NpkCigAAN+7g From: To: , , , X-OriginalArrivalTime: 28 Oct 2005 15:58:26.0826 (UTC) FILETIME=[6ECCC6A0:01C5DBD8] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.3 (/) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 Content-Transfer-Encoding: quoted-printable To add..... There are some fairly significant differences between cl-ps mode, co-ps mode and co-cs mode networks. Indeed, in the co-cs mode an OOB control/management *network* is a forced solution. And note there are (at least) 2 different networks in the same networking system....and how one addresses resilience for these 2 networks is quite different. In fact because the control/management plane network is so important it should only ever take its design cues from the duct topology. And there are other ways to deal with resilience other than 'an IGP' here, cf the link-set in C7 (which btw is a cl-ps OOB network) as used in the PSTN..........don't knock it, its a very simple and excellent idea....maybe a researcher should look at it for some inspiration ;-) regards, Neil > -----Original Message----- > From: owner-ccamp@ops.ietf.org > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Igor Bryskin > Sent: 28 October 2005 16:50 > To: Zafar Ali (zali); Kim Young Hwa; ccamp@ops.ietf.org > Subject: RE: Two Drafts for Resilience of Control Plane >=20 >=20 > Zafar, >=20 > The problem arises when the control plane is decoupled > from the data plane. The question is do we need such decoupling in IP=20 > networks? Consider, for example, the situation when several parallel=20 > PSC data links bundled together and controlled by a single control=20 > channel. Does it mean in this case that when the control > channel fails all associated data links also fail? Do > we need to reroute in this case LSPs that use the data > links? Can we rely in this case on control plane > indications to decide whether an associated data link > is healthy or not (in other words, can we rely on RSVP > Hellos or should we use, for example, BTD)? Should we > be capable to recover control channels without > disturbing data plane? I think control plane > resilience is important for all layers. You are right, > Internet does work, however, we do need for some > reason TE and (fast) recovery in IP as much as in > other layers,don't we? >=20 > Cheers, > Igor >=20 > --- "Zafar Ali (zali)" wrote: >=20 > > Hi All, > > =20 > > I am unable to understand the problem we are trying > > to solve or > > fabricate. My control network is IP based and IP has > > proven resiliency > > (Internet *does* work), why would I like to take > > control plan resiliency > > problem at a layer *above-IP* and complicate my > > life. Did I miss > > something? > > =20 > > Thanks > > =20 > > Regards... Zafar > >=20 > >=20 > > ________________________________ > >=20 > > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On=20 > > Behalf Of Kim Young Hwa > > Sent: Friday, October 28, 2005 6:04 AM > > To: ccamp@ops.ietf.org > > Subject: Two Drafts for Resilience of Control Plane > > =09 > > =09 > > Dear all, > > =20 > > I posted two drafts for the resilience of control > > plane. > > One is for requirements of the resilience of > > control plane, the > > other is for a protocol specification as a solution > > of that . > > These are now available at: > > =09 > > > http://www.ietf.org/internet-drafts/draft-kim-ccamp-cpr-reqts-01.txt > > =09 > > > http://www.ietf.org/internet-drafts/draft-kim-ccamp-accp-proto col-00.txt > =20 > I want your comments. > =20 > Regards > =20 > Young. > =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 > Young-Hwa Kim > Principal Member / Ph.D > BcN Research Division, ETRI > Tel: +82-42-860-5819 > Fax: +82-42-860-5440 > e-mail: yhwkim@etri.re.kr > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > =09 > g&name=3Dccamp%40ops.ietf.org&fromemail=3Dyhwkim@etri.re.kr&messageid=3D%= 3C863 > 0a6db-0c31-49ab-a798-13b0dda04553@etri.re.kr%3E> >=20 >=20 =09 =09 __________________________________=20 Yahoo! Mail - PC Magazine Editors' Choice 2005=20 http://mail.yahoo.com From owner-ccamp@ops.ietf.org Fri Oct 28 12:35:50 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVXCo-0006oz-Cv for ccamp-archive@megatron.ietf.org; Fri, 28 Oct 2005 12:35:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27734 for ; Fri, 28 Oct 2005 12:35:33 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVXQO-0002nP-Q8 for ccamp-archive@ietf.org; Fri, 28 Oct 2005 12:49:54 -0400 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EVX5l-000EUT-Kx for ccamp-data@psg.com; Fri, 28 Oct 2005 16:28:33 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-4.9 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from localhost ([127.0.0.1]) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EVX5k-000EUD-Pz; Fri, 28 Oct 2005 16:28:33 +0000 Message-ID: <43625184.5020208@psg.com> Date: Fri, 28 Oct 2005 18:27:48 +0200 From: dimitri papadimitriou Reply-To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.11) Gecko/20050728 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Zafar Ali (zali)" CC: Kim Young Hwa , ccamp@ops.ietf.org Subject: Re: Two Drafts for Resilience of Control Plane References: In-Reply-To: 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: 52f7a77164458f8c7b36b66787c853da Content-Transfer-Encoding: 7bit zafar - Zafar Ali (zali) wrote: > Hi All, > > I am unable to understand the problem we are trying to solve or > fabricate. My control network is IP based and IP has proven resiliency > (Internet *does* work), why would I like to take control plan resiliency > problem at a layer *above-IP* and complicate my life. Did I miss > something? ... i don't think the issue is to invent new problems but at some point in time it may be become advisable to document the mechanisms available at hand and applicable to support control plane resilience - note they are disseminated in several I-Ds and RFCs today - at least this would prevent from re-discussing periodically this issue while at the end the initial problem has been covered progressively since CCAMP work started > Thanks > > Regards... Zafar > > > ________________________________ > > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] > On Behalf Of Kim Young Hwa > Sent: Friday, October 28, 2005 6:04 AM > To: ccamp@ops.ietf.org > Subject: Two Drafts for Resilience of Control Plane > > > Dear all, > > I posted two drafts for the resilience of control plane. > One is for requirements of the resilience of control plane, the > other is for a protocol specification as a solution of that . > These are now available at: > > http://www.ietf.org/internet-drafts/draft-kim-ccamp-cpr-reqts-01.txt > > http://www.ietf.org/internet-drafts/draft-kim-ccamp-accp-protocol-00.txt > > I want your comments. > > Regards > > Young. > > ==================================== > Young-Hwa Kim > Principal Member / Ph.D > BcN Research Division, ETRI > Tel: +82-42-860-5819 > Fax: +82-42-860-5440 > e-mail: yhwkim@etri.re.kr > ==================================== > > g&name=ccamp%40ops.ietf.org&fromemail=yhwkim@etri.re.kr&messageid=%3C863 > 0a6db-0c31-49ab-a798-13b0dda04553@etri.re.kr%3E> > > From owner-ccamp@ops.ietf.org Fri Oct 28 13:05:07 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVXf8-00046g-Ew for ccamp-archive@megatron.ietf.org; Fri, 28 Oct 2005 13:05:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28870 for ; Fri, 28 Oct 2005 13:04:49 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVXsi-0003U9-TZ for ccamp-archive@ietf.org; Fri, 28 Oct 2005 13:19:10 -0400 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EVXWz-000GFy-Ko for ccamp-data@psg.com; Fri, 28 Oct 2005 16:56:41 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-4.9 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from localhost ([127.0.0.1]) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EVXWy-000GFj-Dz; Fri, 28 Oct 2005 16:56:40 +0000 Message-ID: <4362581B.7050503@psg.com> Date: Fri, 28 Oct 2005 18:55:55 +0200 From: dimitri papadimitriou Reply-To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.11) Gecko/20050728 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Igor Bryskin CC: "Zafar Ali (zali)" , Kim Young Hwa , ccamp@ops.ietf.org Subject: Re: Two Drafts for Resilience of Control Plane References: <20051028155012.73678.qmail@web30806.mail.mud.yahoo.com> In-Reply-To: <20051028155012.73678.qmail@web30806.mail.mud.yahoo.com> 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: 7da5a831c477fb6ef97f379a05fb683c Content-Transfer-Encoding: 7bit igor - over time CCAMP came with a set of mechanims to improve control plane resilience (RSVP and LMP GR upon channel/node failure) other WG protocol work are also usable used here OSPF GR, etc. ... on the other side, mechanism such as link bundling have built-in resilience capabilities and most GMPLS control plane capabilities have been designed such as to be independent of the control plane realisation (in-band, out-of-band, etc.) so indeed i share the concern of Zafar what could we do more here than document these tools and provide our experience in using them; now, before stating there are (potential) problems(s) arising - would you please be more specific on what are these potential issue(s) and/or problems ? (not related to policy/config. - note: all the issues you have pointed here below are simply policy/config specific but none of them highlights a missing IP control plane resiliency feature) thanks, - dimitri. Igor Bryskin wrote: > Zafar, > > The problem arises when the control plane is decoupled > from the data plane. The question is do we need such > decoupling in IP networks? Consider, for example, the > situation when several parallel PSC data links bundled > together and controlled by a single control channel. > Does it mean in this case that when the control > channel fails all associated data links also fail? Do > we need to reroute in this case LSPs that use the data > links? Can we rely in this case on control plane > indications to decide whether an associated data link > is healthy or not (in other words, can we rely on RSVP > Hellos or should we use, for example, BTD)? Should we > be capable to recover control channels without > disturbing data plane? I think control plane > resilience is important for all layers. You are right, > Internet does work, however, we do need for some > reason TE and (fast) recovery in IP as much as in > other layers,don't we? > > Cheers, > Igor > > --- "Zafar Ali (zali)" wrote: > > >>Hi All, >> >>I am unable to understand the problem we are trying >>to solve or >>fabricate. My control network is IP based and IP has >>proven resiliency >>(Internet *does* work), why would I like to take >>control plan resiliency >>problem at a layer *above-IP* and complicate my >>life. Did I miss >>something? >> >>Thanks >> >>Regards... Zafar >> >> >>________________________________ >> >> From: owner-ccamp@ops.ietf.org >>[mailto:owner-ccamp@ops.ietf.org] >>On Behalf Of Kim Young Hwa >> Sent: Friday, October 28, 2005 6:04 AM >> To: ccamp@ops.ietf.org >> Subject: Two Drafts for Resilience of Control Plane >> >> >> Dear all, >> >> I posted two drafts for the resilience of control >>plane. >> One is for requirements of the resilience of >>control plane, the >>other is for a protocol specification as a solution >>of that . >> These are now available at: >> >> > > http://www.ietf.org/internet-drafts/draft-kim-ccamp-cpr-reqts-01.txt > >> >> > > http://www.ietf.org/internet-drafts/draft-kim-ccamp-accp-protocol-00.txt > >> >> I want your comments. >> >> Regards >> >> Young. >> >> ==================================== >> Young-Hwa Kim >> Principal Member / Ph.D >> BcN Research Division, ETRI >> Tel: +82-42-860-5819 >> Fax: +82-42-860-5440 >> e-mail: yhwkim@etri.re.kr >> ==================================== >> >> > > > g&name=ccamp%40ops.ietf.org&fromemail=yhwkim@etri.re.kr&messageid=%3C863 > >>0a6db-0c31-49ab-a798-13b0dda04553@etri.re.kr%3E> >> >> > > > > > > > __________________________________ > Yahoo! Mail - PC Magazine Editors' Choice 2005 > http://mail.yahoo.com > > > . > From owner-ccamp@ops.ietf.org Fri Oct 28 14:07:36 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVYdc-0005Nz-8B for ccamp-archive@megatron.ietf.org; Fri, 28 Oct 2005 14:07:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01372 for ; Fri, 28 Oct 2005 14:07:18 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVYr5-0005JX-Rs for ccamp-archive@ietf.org; Fri, 28 Oct 2005 14:21:40 -0400 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EVYSz-000Jpf-FA for ccamp-data@psg.com; Fri, 28 Oct 2005 17:56:37 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [130.76.32.69] (helo=blv-smtpout-01.boeing.com) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EVYSy-000JpR-3l; Fri, 28 Oct 2005 17:56:36 +0000 Received: from stl-av-01.boeing.com ([192.76.190.6]) by blv-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id KAA09573; Fri, 28 Oct 2005 10:56:27 -0700 (PDT) Received: from XCH-SWBH-04.sw.nos.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id j9SHuQY23135; Fri, 28 Oct 2005 12:56:26 -0500 (CDT) Received: from XCH-SW-42.sw.nos.boeing.com ([192.79.11.43]) by XCH-SWBH-04.sw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 28 Oct 2005 10:56:23 -0700 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: Two Drafts for Resilience of Control Plane Date: Fri, 28 Oct 2005 10:56:22 -0700 Message-ID: <626FC7C6A97381468FB872072AB5DDC83696FA@XCH-SW-42.sw.nos.boeing.com> Thread-Topic: Two Drafts for Resilience of Control Plane Thread-Index: AcXb4gqeAeS5AmH7SQKkqh+S5btlSgABlHCQ From: "Drake, John E" To: , , "Igor Bryskin" Cc: "Zafar Ali \(zali\)" , "Kim Young Hwa" , X-OriginalArrivalTime: 28 Oct 2005 17:56:23.0095 (UTC) FILETIME=[E895BC70:01C5DBE8] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 225414c974e0d6437992164e91287a51 Content-Transfer-Encoding: quoted-printable I agree with Zafar and Dimitri. If someone wanted to document the GMPLS control plane resiliency features, as was done for GMPLS addressing, that might be a useful activity. > -----Original Message----- > From: dimitri papadimitriou [mailto:dpapadimitriou@psg.com] > Sent: Friday, October 28, 2005 9:56 AM > To: Igor Bryskin > Cc: Zafar Ali (zali); Kim Young Hwa; ccamp@ops.ietf.org > Subject: Re: Two Drafts for Resilience of Control Plane >=20 > igor - >=20 > over time CCAMP came with a set of mechanims to improve control plane > resilience (RSVP and LMP GR upon channel/node failure) other WG protocol > work are also usable used here OSPF GR, etc. ... on the other side, > mechanism such as link bundling have built-in resilience capabilities > and most GMPLS control plane capabilities have been designed such as to > be independent of the control plane realisation (in-band, out-of-band, > etc.) >=20 > so indeed i share the concern of Zafar what could we do more here than > document these tools and provide our experience in using them; >=20 > now, before stating there are (potential) problems(s) arising - would > you please be more specific on what are these potential issue(s) and/or > problems ? (not related to policy/config. - note: all the issues you > have pointed here below are simply policy/config specific but none of > them highlights a missing IP control plane resiliency feature) >=20 > thanks, > - dimitri. >=20 >=20 > Igor Bryskin wrote: >=20 > > Zafar, > > > > The problem arises when the control plane is decoupled > > from the data plane. The question is do we need such > > decoupling in IP networks? Consider, for example, the > > situation when several parallel PSC data links bundled > > together and controlled by a single control channel. > > Does it mean in this case that when the control > > channel fails all associated data links also fail? Do > > we need to reroute in this case LSPs that use the data > > links? Can we rely in this case on control plane > > indications to decide whether an associated data link > > is healthy or not (in other words, can we rely on RSVP > > Hellos or should we use, for example, BTD)? Should we > > be capable to recover control channels without > > disturbing data plane? I think control plane > > resilience is important for all layers. You are right, > > Internet does work, however, we do need for some > > reason TE and (fast) recovery in IP as much as in > > other layers,don't we? > > > > Cheers, > > Igor > > > > --- "Zafar Ali (zali)" wrote: > > > > > >>Hi All, > >> > >>I am unable to understand the problem we are trying > >>to solve or > >>fabricate. My control network is IP based and IP has > >>proven resiliency > >>(Internet *does* work), why would I like to take > >>control plan resiliency > >>problem at a layer *above-IP* and complicate my > >>life. Did I miss > >>something? > >> > >>Thanks > >> > >>Regards... Zafar > >> > >> > >>________________________________ > >> > >> From: owner-ccamp@ops.ietf.org > >>[mailto:owner-ccamp@ops.ietf.org] > >>On Behalf Of Kim Young Hwa > >> Sent: Friday, October 28, 2005 6:04 AM > >> To: ccamp@ops.ietf.org > >> Subject: Two Drafts for Resilience of Control Plane > >> > >> > >> Dear all, > >> > >> I posted two drafts for the resilience of control > >>plane. > >> One is for requirements of the resilience of > >>control plane, the > >>other is for a protocol specification as a solution > >>of that . > >> These are now available at: > >> > >> > > > > http://www.ietf.org/internet-drafts/draft-kim-ccamp-cpr-reqts-01.txt > > > >> > >> > > > > http://www.ietf.org/internet-drafts/draft-kim-ccamp-accp-protocol-00.txt > > > >> > >> I want your comments. > >> > >> Regards > >> > >> Young. > >> > >> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >> Young-Hwa Kim > >> Principal Member / Ph.D > >> BcN Research Division, ETRI > >> Tel: +82-42-860-5819 > >> Fax: +82-42-860-5440 > >> e-mail: yhwkim@etri.re.kr > >> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >> > >> > > > > > > > g&name=3Dccamp%40ops.ietf.org&fromemail=3Dyhwkim@etri.re.kr&messageid=3D%= 3C863 > > > >>0a6db-0c31-49ab-a798-13b0dda04553@etri.re.kr%3E> > >> > >> > > > > > > > > > > > > > > __________________________________ > > Yahoo! Mail - PC Magazine Editors' Choice 2005 > > http://mail.yahoo.com > > > > > > . > > From owner-ccamp@ops.ietf.org Fri Oct 28 14:28:58 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVYyI-0006UG-Iw for ccamp-archive@megatron.ietf.org; Fri, 28 Oct 2005 14:28:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02120 for ; Fri, 28 Oct 2005 14:28:40 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVZBt-0005n9-Ho for ccamp-archive@ietf.org; Fri, 28 Oct 2005 14:43:03 -0400 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EVYsO-000LdU-OZ for ccamp-data@psg.com; Fri, 28 Oct 2005 18:22:52 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [64.102.122.149] (helo=rtp-iport-2.cisco.com) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EVYsN-000LdJ-N4 for ccamp@ops.ietf.org; Fri, 28 Oct 2005 18:22:51 +0000 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 28 Oct 2005 14:22:51 -0400 X-IronPort-AV: i="3.97,263,1125892800"; d="scan'208"; a="74643890:sNHT26393072" 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 j9SIMEF6029723; Fri, 28 Oct 2005 14:22:48 -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); Fri, 28 Oct 2005 14:22:29 -0400 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: Two Drafts for Resilience of Control Plane Date: Fri, 28 Oct 2005 14:22:28 -0400 Message-ID: Thread-Topic: Two Drafts for Resilience of Control Plane Thread-Index: AcXb11THC5FHtbFMShalW0lcPamnOgACYLyw From: "Zafar Ali \(zali\)" To: "Igor Bryskin" , "Kim Young Hwa" , X-OriginalArrivalTime: 28 Oct 2005 18:22:29.0541 (UTC) FILETIME=[8E426D50:01C5DBEC] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: Igor Bryskin [mailto:i_bryskin@yahoo.com]=20 > Sent: Friday, October 28, 2005 11:50 AM > To: Zafar Ali (zali); Kim Young Hwa; ccamp@ops.ietf.org > Subject: RE: Two Drafts for Resilience of Control Plane >=20 > Zafar, >=20 > The problem arises when the control plane is decoupled from=20 > the data plane.=20 But control network is still (and needs to be) an IP network.=20 >The question is do we need such decoupling in=20 > IP networks? Consider, for example, the situation when=20 > several parallel PSC data links bundled together and=20 > controlled by a single control channel. If this "single control channel" is "IP routing" the control packets, as long as there is resilience in the control network (i.e., alternate IP routes), we should be see "single control channel" as a deficiency. It's as best of resiliency that it gets.=20 > Does it mean in this case that when the control channel fails=20 > all associated data links also fail?=20 > Do we need to reroute in=20 > this case LSPs that use the data links?=20 We have (RSVP/ LMP) GR procedures for recovery of control network failures.=20 >Can we rely in this=20 > case on control plane indications to decide whether an=20 > associated data link is healthy or not (in other words, can=20 > we rely on RSVP Hellos or should we use, for example, BTD)?=20 > Should we be capable to recover control channels without=20 > disturbing data plane?=20 All these things are already addressed, please also see Dimitri's email on this.=20 > I think control plane resilience is=20 > important for all layers.=20 What is your definition of layers here? What I am saying is that having control network resilience build outside IP layer is "bad complexity".=20 > You are right, Internet does work,=20 > however, we do need for some reason TE and (fast) recovery in=20 > IP as much as in other layers,don't we? >=20 > Cheers, > Igor >=20 > --- "Zafar Ali (zali)" wrote: >=20 > > Hi All, > > =20 > > I am unable to understand the problem we are trying to solve or=20 > > fabricate. My control network is IP based and IP has proven=20 > resiliency=20 > > (Internet *does* work), why would I like to take control plan=20 > > resiliency problem at a layer *above-IP* and complicate my=20 > life. Did I=20 > > miss something? > > =20 > > Thanks > > =20 > > Regards... Zafar > >=20 > >=20 > > ________________________________ > >=20 > > From: owner-ccamp@ops.ietf.org > > [mailto:owner-ccamp@ops.ietf.org] > > On Behalf Of Kim Young Hwa > > Sent: Friday, October 28, 2005 6:04 AM > > To: ccamp@ops.ietf.org > > Subject: Two Drafts for Resilience of Control Plane > > =09 > > =09 > > Dear all, > > =20 > > I posted two drafts for the resilience of control plane. > > One is for requirements of the resilience of control=20 > plane, the other=20 > > is for a protocol specification as a solution of that . > > These are now available at: > > =09 > > > http://www.ietf.org/internet-drafts/draft-kim-ccamp-cpr-reqts-01.txt > > =09 > > > http://www.ietf.org/internet-drafts/draft-kim-ccamp-accp-proto > col-00.txt > > =20 > > I want your comments. > > =20 > > Regards > > =20 > > Young. > > =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 > > Young-Hwa Kim > > Principal Member / Ph.D > > BcN Research Division, ETRI > > Tel: +82-42-860-5819 > > Fax: +82-42-860-5440 > > e-mail: yhwkim@etri.re.kr > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > =09 > > > ps.ietf.or > > > g&name=3Dccamp%40ops.ietf.org&fromemail=3Dyhwkim@etri.re.kr&messag > eid=3D%3C863 > > 0a6db-0c31-49ab-a798-13b0dda04553@etri.re.kr%3E> > >=20 > >=20 >=20 >=20 >=20 > =09 > =09 > __________________________________ > Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com >=20 From owner-ccamp@ops.ietf.org Fri Oct 28 14:46:57 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVZFg-0005Vy-E1 for ccamp-archive@megatron.ietf.org; Fri, 28 Oct 2005 14:46:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02816 for ; Fri, 28 Oct 2005 14:46:38 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVZTI-0006EW-Vj for ccamp-archive@ietf.org; Fri, 28 Oct 2005 15:01:01 -0400 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EVZAV-000Mqa-KS for ccamp-data@psg.com; Fri, 28 Oct 2005 18:41:35 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=3.1.0 Received: from [70.158.43.219] (helo=jera.movaz.com) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EVZAU-000MqN-As for ccamp@ops.ietf.org; Fri, 28 Oct 2005 18:41:34 +0000 Received: by jera.movaz.com (Postfix, from userid 30) id AD73567200; Fri, 28 Oct 2005 14:41:29 -0400 (EDT) Received: from 68.100.80.11 (SquirrelMail authenticated user ibryskin) by webmail.movaz.com with HTTP; Fri, 28 Oct 2005 14:41:29 -0400 (EDT) Message-ID: <4618.68.100.80.11.1130524889.squirrel@webmail.movaz.com> In-Reply-To: <626FC7C6A97381468FB872072AB5DDC83696FA@XCH-SW-42.sw.nos.boeing.com> References: <626FC7C6A97381468FB872072AB5DDC83696FA@XCH-SW-42.sw.nos.boeing.com> Date: Fri, 28 Oct 2005 14:41:29 -0400 (EDT) Subject: RE: Two Drafts for Resilience of Control Plane From: ibryskin@movaz.com To: "Drake, John E" Cc: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be, "Igor Bryskin" , "Zafar Ali" , "Kim Young Hwa" , ccamp@ops.ietf.org User-Agent: SquirrelMail/1.4.1 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 Importance: Normal Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 1.2 (+) X-Scan-Signature: 0cff8c3ec906d056784362c06f5f88c1 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id OAA02816 Hi, Here is one of the problems that I=92ve been thinking for a while =96 con= trol plane partitioned LSPs. Suppose one or more signaling controllers managin= g some LSP went out of service leaving the LSP=92s data plane intact. As fa= r as the user is concerned such LSP is perfectly healthy and operational. Such situation could last for a considerable period of time. Do we need t= o manage such LSP via control plane? Sure, we must be capable to tear down such LSP, perform mb4b rerouting, distribute alarms between operational controllers, signal data plane faults and perform recovery switchover, modify LSP status, etc. Can we do this today? No, but with some (signaling) extensions the problem I believe is solvable. Is this some artificial, =93fabricated=94 problem? No, I think it is real. Does it fal= l under the control plane resilience problem space? I believe it does. Igor > I agree with Zafar and Dimitri. If someone wanted to document the GMPL= S > control plane resiliency features, as was done for GMPLS addressing, > that might be a useful activity. > >> -----Original Message----- >> From: dimitri papadimitriou [mailto:dpapadimitriou@psg.com] >> Sent: Friday, October 28, 2005 9:56 AM >> To: Igor Bryskin >> Cc: Zafar Ali (zali); Kim Young Hwa; ccamp@ops.ietf.org >> Subject: Re: Two Drafts for Resilience of Control Plane >> >> igor - >> >> over time CCAMP came with a set of mechanims to improve control plane >> resilience (RSVP and LMP GR upon channel/node failure) other WG > protocol >> work are also usable used here OSPF GR, etc. ... on the other side, >> mechanism such as link bundling have built-in resilience capabilities >> and most GMPLS control plane capabilities have been designed such as > to >> be independent of the control plane realisation (in-band, out-of-band, >> etc.) >> >> so indeed i share the concern of Zafar what could we do more here than >> document these tools and provide our experience in using them; >> >> now, before stating there are (potential) problems(s) arising - would >> you please be more specific on what are these potential issue(s) > and/or >> problems ? (not related to policy/config. - note: all the issues you >> have pointed here below are simply policy/config specific but none of >> them highlights a missing IP control plane resiliency feature) >> >> thanks, >> - dimitri. >> >> >> Igor Bryskin wrote: >> >> > Zafar, >> > >> > The problem arises when the control plane is decoupled >> > from the data plane. The question is do we need such >> > decoupling in IP networks? Consider, for example, the >> > situation when several parallel PSC data links bundled >> > together and controlled by a single control channel. >> > Does it mean in this case that when the control >> > channel fails all associated data links also fail? Do >> > we need to reroute in this case LSPs that use the data >> > links? Can we rely in this case on control plane >> > indications to decide whether an associated data link >> > is healthy or not (in other words, can we rely on RSVP >> > Hellos or should we use, for example, BTD)? Should we >> > be capable to recover control channels without >> > disturbing data plane? I think control plane >> > resilience is important for all layers. You are right, >> > Internet does work, however, we do need for some >> > reason TE and (fast) recovery in IP as much as in >> > other layers,don't we? >> > >> > Cheers, >> > Igor >> > >> > --- "Zafar Ali (zali)" wrote: >> > >> > >> >>Hi All, >> >> >> >>I am unable to understand the problem we are trying >> >>to solve or >> >>fabricate. My control network is IP based and IP has >> >>proven resiliency >> >>(Internet *does* work), why would I like to take >> >>control plan resiliency >> >>problem at a layer *above-IP* and complicate my >> >>life. Did I miss >> >>something? >> >> >> >>Thanks >> >> >> >>Regards... Zafar >> >> >> >> >> >>________________________________ >> >> >> >> From: owner-ccamp@ops.ietf.org >> >>[mailto:owner-ccamp@ops.ietf.org] >> >>On Behalf Of Kim Young Hwa >> >> Sent: Friday, October 28, 2005 6:04 AM >> >> To: ccamp@ops.ietf.org >> >> Subject: Two Drafts for Resilience of Control Plane >> >> >> >> >> >> Dear all, >> >> >> >> I posted two drafts for the resilience of control >> >>plane. >> >> One is for requirements of the resilience of >> >>control plane, the >> >>other is for a protocol specification as a solution >> >>of that . >> >> These are now available at: >> >> >> >> >> > >> > http://www.ietf.org/internet-drafts/draft-kim-ccamp-cpr-reqts-01.txt >> > >> >> >> >> >> > >> > > http://www.ietf.org/internet-drafts/draft-kim-ccamp-accp-protocol-00.tx= t >> > >> >> >> >> I want your comments. >> >> >> >> Regards >> >> >> >> Young. >> >> >> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D> >> Young-Hwa Kim >> >> Principal Member / Ph.D >> >> BcN Research Division, ETRI >> >> Tel: +82-42-860-5819 >> >> Fax: +82-42-860-5440 >> >> e-mail: yhwkim@etri.re.kr >> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D> >> >> >> >> > >> > > > > >> > > g&name=3Dccamp%40ops.ietf.org&fromemail=3Dyhwkim@etri.re.kr&messageid=3D= %3C863 >> > >> >>0a6db-0c31-49ab-a798-13b0dda04553@etri.re.kr%3E> >> >> >> >> >> > >> > >> > >> > >> > >> > >> > __________________________________ >> > Yahoo! Mail - PC Magazine Editors' Choice 2005 >> > http://mail.yahoo.com >> > >> > >> > . >> > > > > From owner-ccamp@ops.ietf.org Fri Oct 28 14:52:33 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVZL6-0007fO-Gl for ccamp-archive@megatron.ietf.org; Fri, 28 Oct 2005 14:52:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02988 for ; Fri, 28 Oct 2005 14:52:14 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVZYe-0006LT-SB for ccamp-archive@ietf.org; Fri, 28 Oct 2005 15:06:37 -0400 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EVZHI-000NIE-SP for ccamp-data@psg.com; Fri, 28 Oct 2005 18:48:36 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [130.76.64.48] (helo=slb-smtpout-01.boeing.com) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EVZHH-000NHx-RP; Fri, 28 Oct 2005 18:48:35 +0000 Received: from slb-av-01.boeing.com ([129.172.13.4]) by slb-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id LAA04333; Fri, 28 Oct 2005 11:48:20 -0700 (PDT) Received: from XCH-SWBH-04.sw.nos.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id j9SImJd07052; Fri, 28 Oct 2005 11:48:19 -0700 (PDT) Received: from XCH-SW-42.sw.nos.boeing.com ([192.79.11.43]) by XCH-SWBH-04.sw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 28 Oct 2005 11:48:19 -0700 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: Two Drafts for Resilience of Control Plane Date: Fri, 28 Oct 2005 11:48:19 -0700 Message-ID: <626FC7C6A97381468FB872072AB5DDC83696FE@XCH-SW-42.sw.nos.boeing.com> Thread-Topic: Two Drafts for Resilience of Control Plane Thread-Index: AcXb7zdjVlvAUlhGQAOKUI2nmgJ52QAAKYjQ From: "Drake, John E" To: Cc: , , "Igor Bryskin" , "Zafar Ali" , "Kim Young Hwa" , X-OriginalArrivalTime: 28 Oct 2005 18:48:19.0440 (UTC) FILETIME=[2A123F00:01C5DBF0] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 926f893f9bbbfa169f045f85f0cdb955 Content-Transfer-Encoding: quoted-printable What part of your problem, as stated below, is not handled by RSVP graceful restart? > -----Original Message----- > From: ibryskin@movaz.com [mailto:ibryskin@movaz.com] > Sent: Friday, October 28, 2005 11:41 AM > To: Drake, John E > Cc: dpapadimitriou@psg.com; dimitri.papadimitriou@alcatel.be; Igor > Bryskin; Zafar Ali; Kim Young Hwa; ccamp@ops.ietf.org > Subject: RE: Two Drafts for Resilience of Control Plane >=20 > Hi, >=20 > Here is one of the problems that I've been thinking for a while - control > plane partitioned LSPs. Suppose one or more signaling controllers managing > some LSP went out of service leaving the LSP's data plane intact. As far > as the user is concerned such LSP is perfectly healthy and operational. > Such situation could last for a considerable period of time. Do we need to > manage such LSP via control plane? Sure, we must be capable to tear down > such LSP, perform mb4b rerouting, distribute alarms between operational > controllers, signal data plane faults and perform recovery switchover, > modify LSP status, etc. Can we do this today? No, but with some > (signaling) extensions the problem I believe is solvable. Is this some > artificial, "fabricated" problem? No, I think it is real. Does it fall > under the control plane resilience problem space? I believe it does. >=20 > Igor >=20 > > I agree with Zafar and Dimitri. If someone wanted to document the GMPLS > > control plane resiliency features, as was done for GMPLS addressing, > > that might be a useful activity. > > > >> -----Original Message----- > >> From: dimitri papadimitriou [mailto:dpapadimitriou@psg.com] > >> Sent: Friday, October 28, 2005 9:56 AM > >> To: Igor Bryskin > >> Cc: Zafar Ali (zali); Kim Young Hwa; ccamp@ops.ietf.org > >> Subject: Re: Two Drafts for Resilience of Control Plane > >> > >> igor - > >> > >> over time CCAMP came with a set of mechanims to improve control plane > >> resilience (RSVP and LMP GR upon channel/node failure) other WG > > protocol > >> work are also usable used here OSPF GR, etc. ... on the other side, > >> mechanism such as link bundling have built-in resilience capabilities > >> and most GMPLS control plane capabilities have been designed such as > > to > >> be independent of the control plane realisation (in-band, out-of-band, > >> etc.) > >> > >> so indeed i share the concern of Zafar what could we do more here than > >> document these tools and provide our experience in using them; > >> > >> now, before stating there are (potential) problems(s) arising - would > >> you please be more specific on what are these potential issue(s) > > and/or > >> problems ? (not related to policy/config. - note: all the issues you > >> have pointed here below are simply policy/config specific but none of > >> them highlights a missing IP control plane resiliency feature) > >> > >> thanks, > >> - dimitri. > >> > >> > >> Igor Bryskin wrote: > >> > >> > Zafar, > >> > > >> > The problem arises when the control plane is decoupled > >> > from the data plane. The question is do we need such > >> > decoupling in IP networks? Consider, for example, the > >> > situation when several parallel PSC data links bundled > >> > together and controlled by a single control channel. > >> > Does it mean in this case that when the control > >> > channel fails all associated data links also fail? Do > >> > we need to reroute in this case LSPs that use the data > >> > links? Can we rely in this case on control plane > >> > indications to decide whether an associated data link > >> > is healthy or not (in other words, can we rely on RSVP > >> > Hellos or should we use, for example, BTD)? Should we > >> > be capable to recover control channels without > >> > disturbing data plane? I think control plane > >> > resilience is important for all layers. You are right, > >> > Internet does work, however, we do need for some > >> > reason TE and (fast) recovery in IP as much as in > >> > other layers,don't we? > >> > > >> > Cheers, > >> > Igor > >> > > >> > --- "Zafar Ali (zali)" wrote: > >> > > >> > > >> >>Hi All, > >> >> > >> >>I am unable to understand the problem we are trying > >> >>to solve or > >> >>fabricate. My control network is IP based and IP has > >> >>proven resiliency > >> >>(Internet *does* work), why would I like to take > >> >>control plan resiliency > >> >>problem at a layer *above-IP* and complicate my > >> >>life. Did I miss > >> >>something? > >> >> > >> >>Thanks > >> >> > >> >>Regards... Zafar > >> >> > >> >> > >> >>________________________________ > >> >> > >> >> From: owner-ccamp@ops.ietf.org > >> >>[mailto:owner-ccamp@ops.ietf.org] > >> >>On Behalf Of Kim Young Hwa > >> >> Sent: Friday, October 28, 2005 6:04 AM > >> >> To: ccamp@ops.ietf.org > >> >> Subject: Two Drafts for Resilience of Control Plane > >> >> > >> >> > >> >> Dear all, > >> >> > >> >> I posted two drafts for the resilience of control > >> >>plane. > >> >> One is for requirements of the resilience of > >> >>control plane, the > >> >>other is for a protocol specification as a solution > >> >>of that . > >> >> These are now available at: > >> >> > >> >> > >> > > >> > http://www.ietf.org/internet-drafts/draft-kim-ccamp-cpr-reqts-01.txt > >> > > >> >> > >> >> > >> > > >> > > > http://www.ietf.org/internet-drafts/draft-kim-ccamp-accp-protocol-00.txt > >> > > >> >> > >> >> I want your comments. > >> >> > >> >> Regards > >> >> > >> >> Young. > >> >> > >> >> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D> >> Young-Hwa Kim > >> >> Principal Member / Ph.D > >> >> BcN Research Division, ETRI > >> >> Tel: +82-42-860-5819 > >> >> Fax: +82-42-860-5440 > >> >> e-mail: yhwkim@etri.re.kr > >> >> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D> >> > >> >> > >> > > >> > > > >> > > >> > > > g&name=3Dccamp%40ops.ietf.org&fromemail=3Dyhwkim@etri.re.kr&messageid=3D%= 3C863 > >> > > >> >>0a6db-0c31-49ab-a798-13b0dda04553@etri.re.kr%3E> > >> >> > >> >> > >> > > >> > > >> > > >> > > >> > > >> > > >> > __________________________________ > >> > Yahoo! Mail - PC Magazine Editors' Choice 2005 > >> > http://mail.yahoo.com > >> > > >> > > >> > . > >> > > > > > > > From owner-ccamp@ops.ietf.org Fri Oct 28 15:00:40 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVZSw-0003D3-OU for ccamp-archive@megatron.ietf.org; Fri, 28 Oct 2005 15:00:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03269 for ; Fri, 28 Oct 2005 15:00:21 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVZgY-0006Vi-A7 for ccamp-archive@ietf.org; Fri, 28 Oct 2005 15:14:43 -0400 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EVZLN-000NZj-9w for ccamp-data@psg.com; Fri, 28 Oct 2005 18:52:49 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [64.102.122.149] (helo=rtp-iport-2.cisco.com) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EVZLM-000NZW-6Q for ccamp@ops.ietf.org; Fri, 28 Oct 2005 18:52:48 +0000 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 28 Oct 2005 14:52:47 -0400 X-IronPort-AV: i="3.97,263,1125892800"; d="scan'208"; a="74646345:sNHT27445620" Received: from [10.83.15.50] (rtp-tnadeau-vpn1.cisco.com [10.83.15.50]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with SMTP id j9SIqjEj005122 for ; Fri, 28 Oct 2005 14:52:46 -0400 (EDT) In-Reply-To: <4618.68.100.80.11.1130524889.squirrel@webmail.movaz.com> References: <626FC7C6A97381468FB872072AB5DDC83696FA@XCH-SW-42.sw.nos.boeing.com> <4618.68.100.80.11.1130524889.squirrel@webmail.movaz.com> Mime-Version: 1.0 (Apple Message framework v734) X-Priority: 3 Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed Message-Id: <9CD44DF1-E80A-4722-9191-BB90D5292111@cisco.com> Content-Transfer-Encoding: quoted-printable From: "Thomas D. Nadeau" Subject: Re: Two Drafts for Resilience of Control Plane Date: Fri, 28 Oct 2005 14:52:47 -0400 To: ccamp@ops.ietf.org X-Mailer: Apple Mail (2.734) Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 1e467ff145ef391eb7b594ef62b8301f Content-Transfer-Encoding: quoted-printable Just like with 'classic' MPLS, with GMPLS I think you have a situation where the data and control planes could be out of sync., or at least out of contact with each other for a period of time. This is certainly not a fabricated problem, but a matter of 'how often' and 'how bad' when it happens (i.e.: is the IP control plane sufficiently resilient) As Zafar said earlier, there are already some mechanisms in place to handle this. Some folks (vendors only) have said they are sufficient. To me, this should be a question that operator types should be answering. --Tom > Hi, > > Here is one of the problems that I=92ve been thinking for a while =96 =20= > control > plane partitioned LSPs. Suppose one or more signaling controllers =20 > managing > some LSP went out of service leaving the LSP=92s data plane intact. =20= > As far > as the user is concerned such LSP is perfectly healthy and =20 > operational. > Such situation could last for a considerable period of time. Do we =20 > need to > manage such LSP via control plane? Sure, we must be capable to tear =20= > down > such LSP, perform mb4b rerouting, distribute alarms between =20 > operational > controllers, signal data plane faults and perform recovery switchover, > modify LSP status, etc. Can we do this today? No, but with some > (signaling) extensions the problem I believe is solvable. Is this some > artificial, =93fabricated=94 problem? No, I think it is real. Does it = fall > under the control plane resilience problem space? I believe it does. > > Igor > > >> I agree with Zafar and Dimitri. If someone wanted to document the =20= >> GMPLS >> control plane resiliency features, as was done for GMPLS addressing, >> that might be a useful activity. >> >> >>> -----Original Message----- >>> From: dimitri papadimitriou [mailto:dpapadimitriou@psg.com] >>> Sent: Friday, October 28, 2005 9:56 AM >>> To: Igor Bryskin >>> Cc: Zafar Ali (zali); Kim Young Hwa; ccamp@ops.ietf.org >>> Subject: Re: Two Drafts for Resilience of Control Plane >>> >>> igor - >>> >>> over time CCAMP came with a set of mechanims to improve control =20 >>> plane >>> resilience (RSVP and LMP GR upon channel/node failure) other WG >>> >> protocol >> >>> work are also usable used here OSPF GR, etc. ... on the other side, >>> mechanism such as link bundling have built-in resilience =20 >>> capabilities >>> and most GMPLS control plane capabilities have been designed such as >>> >> to >> >>> be independent of the control plane realisation (in-band, out-of-=20 >>> band, >>> etc.) >>> >>> so indeed i share the concern of Zafar what could we do more here =20= >>> than >>> document these tools and provide our experience in using them; >>> >>> now, before stating there are (potential) problems(s) arising - =20 >>> would >>> you please be more specific on what are these potential issue(s) >>> >> and/or >> >>> problems ? (not related to policy/config. - note: all the issues you >>> have pointed here below are simply policy/config specific but =20 >>> none of >>> them highlights a missing IP control plane resiliency feature) >>> >>> thanks, >>> - dimitri. >>> >>> >>> Igor Bryskin wrote: >>> >>> >>>> Zafar, >>>> >>>> The problem arises when the control plane is decoupled >>>> from the data plane. The question is do we need such >>>> decoupling in IP networks? Consider, for example, the >>>> situation when several parallel PSC data links bundled >>>> together and controlled by a single control channel. >>>> Does it mean in this case that when the control >>>> channel fails all associated data links also fail? Do >>>> we need to reroute in this case LSPs that use the data >>>> links? Can we rely in this case on control plane >>>> indications to decide whether an associated data link >>>> is healthy or not (in other words, can we rely on RSVP >>>> Hellos or should we use, for example, BTD)? Should we >>>> be capable to recover control channels without >>>> disturbing data plane? I think control plane >>>> resilience is important for all layers. You are right, >>>> Internet does work, however, we do need for some >>>> reason TE and (fast) recovery in IP as much as in >>>> other layers,don't we? >>>> >>>> Cheers, >>>> Igor >>>> >>>> --- "Zafar Ali (zali)" wrote: >>>> >>>> >>>> >>>>> Hi All, >>>>> >>>>> I am unable to understand the problem we are trying >>>>> to solve or >>>>> fabricate. My control network is IP based and IP has >>>>> proven resiliency >>>>> (Internet *does* work), why would I like to take >>>>> control plan resiliency >>>>> problem at a layer *above-IP* and complicate my >>>>> life. Did I miss >>>>> something? >>>>> >>>>> Thanks >>>>> >>>>> Regards... Zafar >>>>> >>>>> >>>>> ________________________________ >>>>> >>>>> From: owner-ccamp@ops.ietf.org >>>>> [mailto:owner-ccamp@ops.ietf.org] >>>>> On Behalf Of Kim Young Hwa >>>>> Sent: Friday, October 28, 2005 6:04 AM >>>>> To: ccamp@ops.ietf.org >>>>> Subject: Two Drafts for Resilience of Control Plane >>>>> >>>>> >>>>> Dear all, >>>>> >>>>> I posted two drafts for the resilience of control >>>>> plane. >>>>> One is for requirements of the resilience of >>>>> control plane, the >>>>> other is for a protocol specification as a solution >>>>> of that . >>>>> These are now available at: >>>>> >>>>> >>>>> >>>> >>>> http://www.ietf.org/internet-drafts/draft-kim-ccamp-cpr-=20 >>>> reqts-01.txt >>>> >>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >> http://www.ietf.org/internet-drafts/draft-kim-ccamp-accp-=20 >> protocol-00.txt >> >>>> >>>> >>>>> >>>>> I want your comments. >>>>> >>>>> Regards >>>>> >>>>> Young. >>>>> >>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D> >> Young-Hwa Kim >>>>> Principal Member / Ph.D >>>>> BcN Research Division, ETRI >>>>> Tel: +82-42-860-5819 >>>>> Fax: +82-42-860-5440 >>>>> e-mail: yhwkim@etri.re.kr >>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D> >> >>>>> >>>>> >>>> >>>> >>>> >> > email=3Dccamp@ops.ietf.or >> >>>> >>>> >>>> >> g&name=3Dccamp%40ops.ietf.org&fromemail=3Dyhwkim@etri.re.kr&messageid=3D= %=20 >> 3C863 >> >>>> >>>> >>>>> 0a6db-0c31-49ab-a798-13b0dda04553@etri.re.kr%3E> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> __________________________________ >>>> Yahoo! Mail - PC Magazine Editors' Choice 2005 >>>> http://mail.yahoo.com >>>> >>>> >>>> . >>>> >>>> >> >> >> > From owner-ccamp@ops.ietf.org Fri Oct 28 15:08:16 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVZaK-0005Sf-Gy for ccamp-archive@megatron.ietf.org; Fri, 28 Oct 2005 15:08:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03547 for ; Fri, 28 Oct 2005 15:07:58 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVZnw-0006fy-SQ for ccamp-archive@ietf.org; Fri, 28 Oct 2005 15:22:21 -0400 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EVZVy-000OBp-WD for ccamp-data@psg.com; Fri, 28 Oct 2005 19:03:47 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-4.9 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from localhost ([127.0.0.1]) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EVZVx-000OBV-JU; Fri, 28 Oct 2005 19:03:45 +0000 Message-ID: <436275E3.9040504@psg.com> Date: Fri, 28 Oct 2005 21:02:59 +0200 From: dimitri papadimitriou Reply-To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.11) Gecko/20050728 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ibryskin@movaz.com CC: "Drake, John E" , dimitri.papadimitriou@alcatel.be, Igor Bryskin , Zafar Ali , Kim Young Hwa , ccamp@ops.ietf.org Subject: Re: Two Drafts for Resilience of Control Plane References: <626FC7C6A97381468FB872072AB5DDC83696FA@XCH-SW-42.sw.nos.boeing.com> <4618.68.100.80.11.1130524889.squirrel@webmail.movaz.com> In-Reply-To: <4618.68.100.80.11.1130524889.squirrel@webmail.movaz.com> Content-Type: text/plain; charset=windows-1252; format=flowed Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: d9238570526f12788af3d33c67f37625 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id PAA03547 igor - you are already going beyond the specific discussion context 1. what is a control plane partitioned LSP ? 2. when you state "Suppose one or more signaling controllers managing some LSP went out of service leaving the LSP=92s data plane intact." what does it mean "one or more controllers" ? what if you support RSVP GR ? why are you not able to recover the states ? etc. hence, i still miss the exact problem wrt to the control plane protocol=20 resilience but i think there is another issue (which is even more important) - the=20 resilience mechanisms of the control plane that we have today have been=20 provided based on experience from the common use of the control plane=20 and for being resilient wrt common failures - but not for ALL use of the=20 control plane in ANY condition and for ALL possible failures - indeed=20 what you are asking here is like what shall i do when the CP is=20 completely down and the DP still up; it would surprise me that the CP=20 would be of any help in this specific condition thanks, - dimitri. ibryskin@movaz.com wrote: > Hi, >=20 > Here is one of the problems that I=92ve been thinking for a while =96 c= ontrol > plane partitioned LSPs. Suppose one or more signaling controllers manag= ing > some LSP went out of service leaving the LSP=92s data plane intact. As = far > as the user is concerned such LSP is perfectly healthy and operational. > Such situation could last for a considerable period of time. Do we need= to > manage such LSP via control plane? Sure, we must be capable to tear dow= n > such LSP, perform mb4b rerouting, distribute alarms between operational > controllers, signal data plane faults and perform recovery switchover, > modify LSP status, etc. Can we do this today? No, but with some > (signaling) extensions the problem I believe is solvable. Is this some > artificial, =93fabricated=94 problem? No, I think it is real. Does it f= all > under the control plane resilience problem space? I believe it does. >=20 > Igor >=20 >=20 >>I agree with Zafar and Dimitri. If someone wanted to document the GMPL= S >>control plane resiliency features, as was done for GMPLS addressing, >>that might be a useful activity. >> >> >>>-----Original Message----- >>>From: dimitri papadimitriou [mailto:dpapadimitriou@psg.com] >>>Sent: Friday, October 28, 2005 9:56 AM >>>To: Igor Bryskin >>>Cc: Zafar Ali (zali); Kim Young Hwa; ccamp@ops.ietf.org >>>Subject: Re: Two Drafts for Resilience of Control Plane >>> >>>igor - >>> >>>over time CCAMP came with a set of mechanims to improve control plane >>>resilience (RSVP and LMP GR upon channel/node failure) other WG >> >>protocol >> >>>work are also usable used here OSPF GR, etc. ... on the other side, >>>mechanism such as link bundling have built-in resilience capabilities >>>and most GMPLS control plane capabilities have been designed such as >> >>to >> >>>be independent of the control plane realisation (in-band, out-of-band, >>>etc.) >>> >>>so indeed i share the concern of Zafar what could we do more here than >>>document these tools and provide our experience in using them; >>> >>>now, before stating there are (potential) problems(s) arising - would >>>you please be more specific on what are these potential issue(s) >> >>and/or >> >>>problems ? (not related to policy/config. - note: all the issues you >>>have pointed here below are simply policy/config specific but none of >>>them highlights a missing IP control plane resiliency feature) >>> >>>thanks, >>>- dimitri. >>> >>> >>>Igor Bryskin wrote: >>> >>> >>>>Zafar, >>>> >>>>The problem arises when the control plane is decoupled >>>>from the data plane. The question is do we need such >>>>decoupling in IP networks? Consider, for example, the >>>>situation when several parallel PSC data links bundled >>>>together and controlled by a single control channel. >>>>Does it mean in this case that when the control >>>>channel fails all associated data links also fail? Do >>>>we need to reroute in this case LSPs that use the data >>>>links? Can we rely in this case on control plane >>>>indications to decide whether an associated data link >>>>is healthy or not (in other words, can we rely on RSVP >>>>Hellos or should we use, for example, BTD)? Should we >>>>be capable to recover control channels without >>>>disturbing data plane? I think control plane >>>>resilience is important for all layers. You are right, >>>>Internet does work, however, we do need for some >>>>reason TE and (fast) recovery in IP as much as in >>>>other layers,don't we? >>>> >>>>Cheers, >>>>Igor >>>> >>>>--- "Zafar Ali (zali)" wrote: >>>> >>>> >>>> >>>>>Hi All, >>>>> >>>>>I am unable to understand the problem we are trying >>>>>to solve or >>>>>fabricate. My control network is IP based and IP has >>>>>proven resiliency >>>>>(Internet *does* work), why would I like to take >>>>>control plan resiliency >>>>>problem at a layer *above-IP* and complicate my >>>>>life. Did I miss >>>>>something? >>>>> >>>>>Thanks >>>>> >>>>>Regards... Zafar >>>>> >>>>> >>>>>________________________________ >>>>> >>>>> From: owner-ccamp@ops.ietf.org >>>>>[mailto:owner-ccamp@ops.ietf.org] >>>>>On Behalf Of Kim Young Hwa >>>>> Sent: Friday, October 28, 2005 6:04 AM >>>>> To: ccamp@ops.ietf.org >>>>> Subject: Two Drafts for Resilience of Control Plane >>>>> >>>>> >>>>> Dear all, >>>>> >>>>> I posted two drafts for the resilience of control >>>>>plane. >>>>> One is for requirements of the resilience of >>>>>control plane, the >>>>>other is for a protocol specification as a solution >>>>>of that . >>>>> These are now available at: >>>>> >>>>> >>>> >>>>http://www.ietf.org/internet-drafts/draft-kim-ccamp-cpr-reqts-01.txt >>>> >>>> >>>>> >>>> >>http://www.ietf.org/internet-drafts/draft-kim-ccamp-accp-protocol-00.tx= t >> >>>>> I want your comments. >>>>> >>>>> Regards >>>>> >>>>> Young. >>>>> >>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D> >> Young-Hwa Kim >>>>> Principal Member / Ph.D >>>>> BcN Research Division, ETRI >>>>> Tel: +82-42-860-5819 >>>>> Fax: +82-42-860-5440 >>>>> e-mail: yhwkim@etri.re.kr >>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D> >> >>>>> >>>> >>> >>>> >>g&name=3Dccamp%40ops.ietf.org&fromemail=3Dyhwkim@etri.re.kr&messageid=3D= %3C863 >> >>>>>0a6db-0c31-49ab-a798-13b0dda04553@etri.re.kr%3E> >>>>> >>>>> >>>> >>>> >>>> >>>> >>>> >>>>__________________________________ >>>>Yahoo! Mail - PC Magazine Editors' Choice 2005 >>>>http://mail.yahoo.com >>>> >>>> >>>>. >>>> >> >> >> >=20 >=20 >=20 > . >=20 From owner-ccamp@ops.ietf.org Fri Oct 28 16:06:48 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVaUv-0004AR-5l for ccamp-archive@megatron.ietf.org; Fri, 28 Oct 2005 16:06:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08749 for ; Fri, 28 Oct 2005 16:06:23 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVaiU-0000mV-GU for ccamp-archive@ietf.org; Fri, 28 Oct 2005 16:20:47 -0400 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EVaOi-0001SX-Uh for ccamp-data@psg.com; Fri, 28 Oct 2005 20:00:20 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=3.1.0 Received: from [70.158.43.219] (helo=jera.movaz.com) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EVaOf-0001SJ-UY for ccamp@ops.ietf.org; Fri, 28 Oct 2005 20:00:18 +0000 Received: by jera.movaz.com (Postfix, from userid 30) id 7D6B5382E1; Fri, 28 Oct 2005 16:00:16 -0400 (EDT) Received: from 68.100.80.11 (SquirrelMail authenticated user ibryskin) by webmail.movaz.com with HTTP; Fri, 28 Oct 2005 16:00:16 -0400 (EDT) Message-ID: <4650.68.100.80.11.1130529616.squirrel@webmail.movaz.com> In-Reply-To: <626FC7C6A97381468FB872072AB5DDC83696FE@XCH-SW-42.sw.nos.boeing.com> References: <626FC7C6A97381468FB872072AB5DDC83696FE@XCH-SW-42.sw.nos.boeing.com> Date: Fri, 28 Oct 2005 16:00:16 -0400 (EDT) Subject: RE: Two Drafts for Resilience of Control Plane From: ibryskin@movaz.com To: "Drake, John E" Cc: ibryskin@movaz.com, dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be, "Igor Bryskin" , "Zafar Ali" , "Kim Young Hwa" , ccamp@ops.ietf.org User-Agent: SquirrelMail/1.4.1 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 Importance: Normal Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 1.2 (+) X-Scan-Signature: 17e5edc4dfd335965c1d21372171c01c Content-Transfer-Encoding: 8bit John, I think you missed my point here. "Dead" controllers in my example *do not* come back for a considerable period of time. So there are no restarts here (graceful or not graceful) :=) Igor > What part of your problem, as stated below, is not handled by RSVP > graceful restart? > >> -----Original Message----- >> From: ibryskin@movaz.com [mailto:ibryskin@movaz.com] >> Sent: Friday, October 28, 2005 11:41 AM >> To: Drake, John E >> Cc: dpapadimitriou@psg.com; dimitri.papadimitriou@alcatel.be; Igor >> Bryskin; Zafar Ali; Kim Young Hwa; ccamp@ops.ietf.org >> Subject: RE: Two Drafts for Resilience of Control Plane >> >> Hi, >> >> Here is one of the problems that I've been thinking for a while - > control >> plane partitioned LSPs. Suppose one or more signaling controllers > managing >> some LSP went out of service leaving the LSP's data plane intact. As > far >> as the user is concerned such LSP is perfectly healthy and > operational. >> Such situation could last for a considerable period of time. Do we > need to >> manage such LSP via control plane? Sure, we must be capable to tear > down >> such LSP, perform mb4b rerouting, distribute alarms between > operational >> controllers, signal data plane faults and perform recovery switchover, >> modify LSP status, etc. Can we do this today? No, but with some >> (signaling) extensions the problem I believe is solvable. Is this some >> artificial, "fabricated" problem? No, I think it is real. Does it fall >> under the control plane resilience problem space? I believe it does. >> >> Igor >> >> > I agree with Zafar and Dimitri. If someone wanted to document the > GMPLS >> > control plane resiliency features, as was done for GMPLS addressing, >> > that might be a useful activity. >> > >> >> -----Original Message----- >> >> From: dimitri papadimitriou [mailto:dpapadimitriou@psg.com] >> >> Sent: Friday, October 28, 2005 9:56 AM >> >> To: Igor Bryskin >> >> Cc: Zafar Ali (zali); Kim Young Hwa; ccamp@ops.ietf.org >> >> Subject: Re: Two Drafts for Resilience of Control Plane >> >> >> >> igor - >> >> >> >> over time CCAMP came with a set of mechanims to improve control > plane >> >> resilience (RSVP and LMP GR upon channel/node failure) other WG >> > protocol >> >> work are also usable used here OSPF GR, etc. ... on the other side, >> >> mechanism such as link bundling have built-in resilience > capabilities >> >> and most GMPLS control plane capabilities have been designed such > as >> > to >> >> be independent of the control plane realisation (in-band, > out-of-band, >> >> etc.) >> >> >> >> so indeed i share the concern of Zafar what could we do more here > than >> >> document these tools and provide our experience in using them; >> >> >> >> now, before stating there are (potential) problems(s) arising - > would >> >> you please be more specific on what are these potential issue(s) >> > and/or >> >> problems ? (not related to policy/config. - note: all the issues > you >> >> have pointed here below are simply policy/config specific but none > of >> >> them highlights a missing IP control plane resiliency feature) >> >> >> >> thanks, >> >> - dimitri. >> >> >> >> >> >> Igor Bryskin wrote: >> >> >> >> > Zafar, >> >> > >> >> > The problem arises when the control plane is decoupled >> >> > from the data plane. The question is do we need such >> >> > decoupling in IP networks? Consider, for example, the >> >> > situation when several parallel PSC data links bundled >> >> > together and controlled by a single control channel. >> >> > Does it mean in this case that when the control >> >> > channel fails all associated data links also fail? Do >> >> > we need to reroute in this case LSPs that use the data >> >> > links? Can we rely in this case on control plane >> >> > indications to decide whether an associated data link >> >> > is healthy or not (in other words, can we rely on RSVP >> >> > Hellos or should we use, for example, BTD)? Should we >> >> > be capable to recover control channels without >> >> > disturbing data plane? I think control plane >> >> > resilience is important for all layers. You are right, >> >> > Internet does work, however, we do need for some >> >> > reason TE and (fast) recovery in IP as much as in >> >> > other layers,don't we? >> >> > >> >> > Cheers, >> >> > Igor >> >> > >> >> > --- "Zafar Ali (zali)" wrote: >> >> > >> >> > >> >> >>Hi All, >> >> >> >> >> >>I am unable to understand the problem we are trying >> >> >>to solve or >> >> >>fabricate. My control network is IP based and IP has >> >> >>proven resiliency >> >> >>(Internet *does* work), why would I like to take >> >> >>control plan resiliency >> >> >>problem at a layer *above-IP* and complicate my >> >> >>life. Did I miss >> >> >>something? >> >> >> >> >> >>Thanks >> >> >> >> >> >>Regards... Zafar >> >> >> >> >> >> >> >> >>________________________________ >> >> >> >> >> >> From: owner-ccamp@ops.ietf.org >> >> >>[mailto:owner-ccamp@ops.ietf.org] >> >> >>On Behalf Of Kim Young Hwa >> >> >> Sent: Friday, October 28, 2005 6:04 AM >> >> >> To: ccamp@ops.ietf.org >> >> >> Subject: Two Drafts for Resilience of Control Plane >> >> >> >> >> >> >> >> >> Dear all, >> >> >> >> >> >> I posted two drafts for the resilience of control >> >> >>plane. >> >> >> One is for requirements of the resilience of >> >> >>control plane, the >> >> >>other is for a protocol specification as a solution >> >> >>of that . >> >> >> These are now available at: >> >> >> >> >> >> >> >> > >> >> > > http://www.ietf.org/internet-drafts/draft-kim-ccamp-cpr-reqts-01.txt >> >> > >> >> >> >> >> >> >> >> > >> >> > >> > > http://www.ietf.org/internet-drafts/draft-kim-ccamp-accp-protocol-00.txt >> >> > >> >> >> >> >> >> I want your comments. >> >> >> >> >> >> Regards >> >> >> >> >> >> Young. >> >> >> >> >> >> ===================================> >> Young-Hwa Kim >> >> >> Principal Member / Ph.D >> >> >> BcN Research Division, ETRI >> >> >> Tel: +82-42-860-5819 >> >> >> Fax: +82-42-860-5440 >> >> >> e-mail: yhwkim@etri.re.kr >> >> >> ===================================> >> >> >> >> >> >> > >> >> > >> > > > >> > >> >> > >> > > g&name=ccamp%40ops.ietf.org&fromemail=yhwkim@etri.re.kr&messageid=%3C863 >> >> > >> >> >>0a6db-0c31-49ab-a798-13b0dda04553@etri.re.kr%3E> >> >> >> >> >> >> >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > __________________________________ >> >> > Yahoo! Mail - PC Magazine Editors' Choice 2005 >> >> > http://mail.yahoo.com >> >> > >> >> > >> >> > . >> >> > >> > >> > >> > > > From owner-ccamp@ops.ietf.org Fri Oct 28 16:12:27 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVaaQ-00088X-Nr for ccamp-archive@megatron.ietf.org; Fri, 28 Oct 2005 16:12:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11301 for ; Fri, 28 Oct 2005 16:12:07 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVao2-0001jt-0K for ccamp-archive@ietf.org; Fri, 28 Oct 2005 16:26:30 -0400 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EVaWV-0001x2-S5 for ccamp-data@psg.com; Fri, 28 Oct 2005 20:08:23 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=3.1.0 Received: from [70.158.43.219] (helo=jera.movaz.com) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EVaWS-0001vp-GL for ccamp@ops.ietf.org; Fri, 28 Oct 2005 20:08:21 +0000 Received: by jera.movaz.com (Postfix, from userid 30) id D2A0065CD6; Fri, 28 Oct 2005 16:08:18 -0400 (EDT) Received: from 68.100.80.11 (SquirrelMail authenticated user ibryskin) by webmail.movaz.com with HTTP; Fri, 28 Oct 2005 16:08:18 -0400 (EDT) Message-ID: <4658.68.100.80.11.1130530098.squirrel@webmail.movaz.com> In-Reply-To: <436275E3.9040504@psg.com> References: <626FC7C6A97381468FB872072AB5DDC83696FA@XCH-SW-42.sw.nos.boeing.com> <4618.68.100.80.11.1130524889.squirrel@webmail.movaz.com> <436275E3.9040504@psg.com> Date: Fri, 28 Oct 2005 16:08:18 -0400 (EDT) Subject: Re: Two Drafts for Resilience of Control Plane From: ibryskin@movaz.com To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be Cc: ibryskin@movaz.com, Drake@movaz.com, "John E" , dimitri.papadimitriou@alcatel.be, "Igor Bryskin" , "Zafar Ali" , "Kim Young Hwa" , ccamp@ops.ietf.org User-Agent: SquirrelMail/1.4.1 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 Importance: Normal Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 1.2 (+) X-Scan-Signature: 325b777e1a3a618c889460b612a65510 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id QAA11301 Dimitri, See in-line. > igor - > > you are already going beyond the specific discussion context > > 1. what is a control plane partitioned LSP ? LSPs with one or more controllers down, so there is/are partitions in hop-by-hop signaling > > 2. when you state "Suppose one or more signaling controllers managing > some LSP went out of service leaving the LSP=92s data plane intact.= " > > what does it mean "one or more controllers" ? what if you support > RSVP GR ? why are you not able to recover the states ? etc. See my response to John. There are no restarts in my example > > hence, i still miss the exact problem wrt to the control plane protocol > resilience > > but i think there is another issue (which is even more important) - the > resilience mechanisms of the control plane that we have today have been > provided based on experience from the common use of the control plane > and for being resilient wrt common failures - but not for ALL use of th= e > control plane in ANY condition and for ALL possible failures - indeed > what you are asking here is like what shall i do when the CP is > completely down and the DP still up; it would surprise me that the CP > would be of any help in this specific condition Believe me, CP could be still of a great help in such conditions. You nee= d some signaling extensions - which is why I think CP resilience is an important topic within CCAMP - and then you can manage LSPs with control plane gaps at least to the extend I described. Igor > > thanks, > - dimitri. > > ibryskin@movaz.com wrote: > >> Hi, >> >> Here is one of the problems that I=92ve been thinking for a while =96 >> control >> plane partitioned LSPs. Suppose one or more signaling controllers >> managing >> some LSP went out of service leaving the LSP=92s data plane intact. As= far >> as the user is concerned such LSP is perfectly healthy and operational. >> Such situation could last for a considerable period of time. Do we nee= d >> to >> manage such LSP via control plane? Sure, we must be capable to tear do= wn >> such LSP, perform mb4b rerouting, distribute alarms between operationa= l >> controllers, signal data plane faults and perform recovery switchover, >> modify LSP status, etc. Can we do this today? No, but with some >> (signaling) extensions the problem I believe is solvable. Is this some >> artificial, =93fabricated=94 problem? No, I think it is real. Does it = fall >> under the control plane resilience problem space? I believe it does. >> >> Igor >> >> >>>I agree with Zafar and Dimitri. If someone wanted to document the GMP= LS >>>control plane resiliency features, as was done for GMPLS addressing, >>>that might be a useful activity. >>> >>> >>>>-----Original Message----- >>>>From: dimitri papadimitriou [mailto:dpapadimitriou@psg.com] >>>>Sent: Friday, October 28, 2005 9:56 AM >>>>To: Igor Bryskin >>>>Cc: Zafar Ali (zali); Kim Young Hwa; ccamp@ops.ietf.org >>>>Subject: Re: Two Drafts for Resilience of Control Plane >>>> >>>>igor - >>>> >>>>over time CCAMP came with a set of mechanims to improve control plane >>>>resilience (RSVP and LMP GR upon channel/node failure) other WG >>> >>>protocol >>> >>>>work are also usable used here OSPF GR, etc. ... on the other side, >>>>mechanism such as link bundling have built-in resilience capabilities >>>>and most GMPLS control plane capabilities have been designed such as >>> >>>to >>> >>>>be independent of the control plane realisation (in-band, out-of-band= , >>>>etc.) >>>> >>>>so indeed i share the concern of Zafar what could we do more here tha= n >>>>document these tools and provide our experience in using them; >>>> >>>>now, before stating there are (potential) problems(s) arising - would >>>>you please be more specific on what are these potential issue(s) >>> >>>and/or >>> >>>>problems ? (not related to policy/config. - note: all the issues you >>>>have pointed here below are simply policy/config specific but none of >>>>them highlights a missing IP control plane resiliency feature) >>>> >>>>thanks, >>>>- dimitri. >>>> >>>> >>>>Igor Bryskin wrote: >>>> >>>> >>>>>Zafar, >>>>> >>>>>The problem arises when the control plane is decoupled >>>>>from the data plane. The question is do we need such >>>>>decoupling in IP networks? Consider, for example, the >>>>>situation when several parallel PSC data links bundled >>>>>together and controlled by a single control channel. >>>>>Does it mean in this case that when the control >>>>>channel fails all associated data links also fail? Do >>>>>we need to reroute in this case LSPs that use the data >>>>>links? Can we rely in this case on control plane >>>>>indications to decide whether an associated data link >>>>>is healthy or not (in other words, can we rely on RSVP >>>>>Hellos or should we use, for example, BTD)? Should we >>>>>be capable to recover control channels without >>>>>disturbing data plane? I think control plane >>>>>resilience is important for all layers. You are right, >>>>>Internet does work, however, we do need for some >>>>>reason TE and (fast) recovery in IP as much as in >>>>>other layers,don't we? >>>>> >>>>>Cheers, >>>>>Igor >>>>> >>>>>--- "Zafar Ali (zali)" wrote: >>>>> >>>>> >>>>> >>>>>>Hi All, >>>>>> >>>>>>I am unable to understand the problem we are trying >>>>>>to solve or >>>>>>fabricate. My control network is IP based and IP has >>>>>>proven resiliency >>>>>>(Internet *does* work), why would I like to take >>>>>>control plan resiliency >>>>>>problem at a layer *above-IP* and complicate my >>>>>>life. Did I miss >>>>>>something? >>>>>> >>>>>>Thanks >>>>>> >>>>>>Regards... Zafar >>>>>> >>>>>> >>>>>>________________________________ >>>>>> >>>>>> From: owner-ccamp@ops.ietf.org >>>>>>[mailto:owner-ccamp@ops.ietf.org] >>>>>>On Behalf Of Kim Young Hwa >>>>>> Sent: Friday, October 28, 2005 6:04 AM >>>>>> To: ccamp@ops.ietf.org >>>>>> Subject: Two Drafts for Resilience of Control Plane >>>>>> >>>>>> >>>>>> Dear all, >>>>>> >>>>>> I posted two drafts for the resilience of control >>>>>>plane. >>>>>> One is for requirements of the resilience of >>>>>>control plane, the >>>>>>other is for a protocol specification as a solution >>>>>>of that . >>>>>> These are now available at: >>>>>> >>>>>> >>>>> >>>>>http://www.ietf.org/internet-drafts/draft-kim-ccamp-cpr-reqts-01.txt >>>>> >>>>> >>>>>> >>>>> >>>http://www.ietf.org/internet-drafts/draft-kim-ccamp-accp-protocol-00.t= xt >>> >>>>>> I want your comments. >>>>>> >>>>>> Regards >>>>>> >>>>>> Young. >>>>>> >>>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D> >> Young-Hwa Kim >>>>>> Principal Member / Ph.D >>>>>> BcN Research Division, ETRI >>>>>> Tel: +82-42-860-5819 >>>>>> Fax: +82-42-860-5440 >>>>>> e-mail: yhwkim@etri.re.kr >>>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D> >> >>>>>> >>>>> >>>>> >>>>> >>>g&name=3Dccamp%40ops.ietf.org&fromemail=3Dyhwkim@etri.re.kr&messageid=3D= %3C863 >>> >>>>>>0a6db-0c31-49ab-a798-13b0dda04553@etri.re.kr%3E> >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>__________________________________ >>>>>Yahoo! Mail - PC Magazine Editors' Choice 2005 >>>>>http://mail.yahoo.com >>>>> >>>>> >>>>>. >>>>> >>> >>> >>> >> >> >> >> . >> > From owner-ccamp@ops.ietf.org Fri Oct 28 16:18:08 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVafw-0003v0-3B for ccamp-archive@megatron.ietf.org; Fri, 28 Oct 2005 16:18:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13889 for ; Fri, 28 Oct 2005 16:17:49 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVatO-0002hB-Ih for ccamp-archive@ietf.org; Fri, 28 Oct 2005 16:32:10 -0400 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EVaaZ-0002D5-0Y for ccamp-data@psg.com; Fri, 28 Oct 2005 20:12:35 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [130.76.32.69] (helo=blv-smtpout-01.boeing.com) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EVaaY-0002Cq-0q; Fri, 28 Oct 2005 20:12:34 +0000 Received: from stl-av-01.boeing.com ([192.76.190.6]) by blv-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id NAA10198; Fri, 28 Oct 2005 13:12:13 -0700 (PDT) Received: from XCH-SWBH-04.sw.nos.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id j9SKCCY01694; Fri, 28 Oct 2005 15:12:12 -0500 (CDT) Received: from XCH-SW-42.sw.nos.boeing.com ([192.79.11.43]) by XCH-SWBH-04.sw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 28 Oct 2005 13:12:04 -0700 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: Two Drafts for Resilience of Control Plane Date: Fri, 28 Oct 2005 13:12:03 -0700 Message-ID: <626FC7C6A97381468FB872072AB5DDC8369701@XCH-SW-42.sw.nos.boeing.com> Thread-Topic: Two Drafts for Resilience of Control Plane Thread-Index: AcXb+jnJdj0+wNOWTniYJbc2ZmRFkAAAGuoA From: "Drake, John E" To: Cc: , , "Igor Bryskin" , "Zafar Ali" , "Kim Young Hwa" , X-OriginalArrivalTime: 28 Oct 2005 20:12:04.0512 (UTC) FILETIME=[DD3F6200:01C5DBFB] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 249cd1efd3d5e0d09114abe826a41235 Content-Transfer-Encoding: quoted-printable Igor, What you wrote was: "Suppose one or more signaling controllers managing some LSP went out of service leaving the LSP's data plane intact. As far as the user is concerned such LSP is perfectly healthy and operational. Such situation could last for a considerable period of time." What part of this is *not* handled by RSVP graceful restart? In your subsequent e-mail, you then changed the problem statement to: ""Dead" controllers in my example *do not* come back for a considerable period of time. So there are no restarts here (graceful or not graceful)" If "Considerable period of time" is not equal to infinity, then there will be an RSVP graceful restart. If a controller is really and truly dead, then presumably the operator will either replace it or re-assign its data-plane resources to another signaling controller. In either case, there will then be an RSVP graceful restart. Thanks, John > -----Original Message----- > From: ibryskin@movaz.com [mailto:ibryskin@movaz.com] > Sent: Friday, October 28, 2005 1:00 PM > To: Drake, John E > Cc: ibryskin@movaz.com; dpapadimitriou@psg.com; > dimitri.papadimitriou@alcatel.be; Igor Bryskin; Zafar Ali; Kim Young Hwa; > ccamp@ops.ietf.org > Subject: RE: Two Drafts for Resilience of Control Plane >=20 > John, >=20 > I think you missed my point here. "Dead" controllers in my example *do > not* come back for a considerable period of time. So there are no restarts > here (graceful or not graceful) :=3D) >=20 > Igor >=20 > > What part of your problem, as stated below, is not handled by RSVP > > graceful restart? > > > >> -----Original Message----- > >> From: ibryskin@movaz.com [mailto:ibryskin@movaz.com] > >> Sent: Friday, October 28, 2005 11:41 AM > >> To: Drake, John E > >> Cc: dpapadimitriou@psg.com; dimitri.papadimitriou@alcatel.be; Igor > >> Bryskin; Zafar Ali; Kim Young Hwa; ccamp@ops.ietf.org > >> Subject: RE: Two Drafts for Resilience of Control Plane > >> > >> Hi, > >> > >> Here is one of the problems that I've been thinking for a while - > > control > >> plane partitioned LSPs. Suppose one or more signaling controllers > > managing > >> some LSP went out of service leaving the LSP's data plane intact. As > > far > >> as the user is concerned such LSP is perfectly healthy and > > operational. > >> Such situation could last for a considerable period of time. Do we > > need to > >> manage such LSP via control plane? Sure, we must be capable to tear > > down > >> such LSP, perform mb4b rerouting, distribute alarms between > > operational > >> controllers, signal data plane faults and perform recovery switchover, > >> modify LSP status, etc. Can we do this today? No, but with some > >> (signaling) extensions the problem I believe is solvable. Is this some > >> artificial, "fabricated" problem? No, I think it is real. Does it fall > >> under the control plane resilience problem space? I believe it does. > >> > >> Igor > >> > >> > I agree with Zafar and Dimitri. If someone wanted to document the > > GMPLS > >> > control plane resiliency features, as was done for GMPLS addressing, > >> > that might be a useful activity. > >> > > >> >> -----Original Message----- > >> >> From: dimitri papadimitriou [mailto:dpapadimitriou@psg.com] > >> >> Sent: Friday, October 28, 2005 9:56 AM > >> >> To: Igor Bryskin > >> >> Cc: Zafar Ali (zali); Kim Young Hwa; ccamp@ops.ietf.org > >> >> Subject: Re: Two Drafts for Resilience of Control Plane > >> >> > >> >> igor - > >> >> > >> >> over time CCAMP came with a set of mechanims to improve control > > plane > >> >> resilience (RSVP and LMP GR upon channel/node failure) other WG > >> > protocol > >> >> work are also usable used here OSPF GR, etc. ... on the other side, > >> >> mechanism such as link bundling have built-in resilience > > capabilities > >> >> and most GMPLS control plane capabilities have been designed such > > as > >> > to > >> >> be independent of the control plane realisation (in-band, > > out-of-band, > >> >> etc.) > >> >> > >> >> so indeed i share the concern of Zafar what could we do more here > > than > >> >> document these tools and provide our experience in using them; > >> >> > >> >> now, before stating there are (potential) problems(s) arising - > > would > >> >> you please be more specific on what are these potential issue(s) > >> > and/or > >> >> problems ? (not related to policy/config. - note: all the issues > > you > >> >> have pointed here below are simply policy/config specific but none > > of > >> >> them highlights a missing IP control plane resiliency feature) > >> >> > >> >> thanks, > >> >> - dimitri. > >> >> > >> >> > >> >> Igor Bryskin wrote: > >> >> > >> >> > Zafar, > >> >> > > >> >> > The problem arises when the control plane is decoupled > >> >> > from the data plane. The question is do we need such > >> >> > decoupling in IP networks? Consider, for example, the > >> >> > situation when several parallel PSC data links bundled > >> >> > together and controlled by a single control channel. > >> >> > Does it mean in this case that when the control > >> >> > channel fails all associated data links also fail? Do > >> >> > we need to reroute in this case LSPs that use the data > >> >> > links? Can we rely in this case on control plane > >> >> > indications to decide whether an associated data link > >> >> > is healthy or not (in other words, can we rely on RSVP > >> >> > Hellos or should we use, for example, BTD)? Should we > >> >> > be capable to recover control channels without > >> >> > disturbing data plane? I think control plane > >> >> > resilience is important for all layers. You are right, > >> >> > Internet does work, however, we do need for some > >> >> > reason TE and (fast) recovery in IP as much as in > >> >> > other layers,don't we? > >> >> > > >> >> > Cheers, > >> >> > Igor > >> >> > > >> >> > --- "Zafar Ali (zali)" wrote: > >> >> > > >> >> > > >> >> >>Hi All, > >> >> >> > >> >> >>I am unable to understand the problem we are trying > >> >> >>to solve or > >> >> >>fabricate. My control network is IP based and IP has > >> >> >>proven resiliency > >> >> >>(Internet *does* work), why would I like to take > >> >> >>control plan resiliency > >> >> >>problem at a layer *above-IP* and complicate my > >> >> >>life. Did I miss > >> >> >>something? > >> >> >> > >> >> >>Thanks > >> >> >> > >> >> >>Regards... Zafar > >> >> >> > >> >> >> > >> >> >>________________________________ > >> >> >> > >> >> >> From: owner-ccamp@ops.ietf.org > >> >> >>[mailto:owner-ccamp@ops.ietf.org] > >> >> >>On Behalf Of Kim Young Hwa > >> >> >> Sent: Friday, October 28, 2005 6:04 AM > >> >> >> To: ccamp@ops.ietf.org > >> >> >> Subject: Two Drafts for Resilience of Control Plane > >> >> >> > >> >> >> > >> >> >> Dear all, > >> >> >> > >> >> >> I posted two drafts for the resilience of control > >> >> >>plane. > >> >> >> One is for requirements of the resilience of > >> >> >>control plane, the > >> >> >>other is for a protocol specification as a solution > >> >> >>of that . > >> >> >> These are now available at: > >> >> >> > >> >> >> > >> >> > > >> >> > > > http://www.ietf.org/internet-drafts/draft-kim-ccamp-cpr-reqts-01.txt > >> >> > > >> >> >> > >> >> >> > >> >> > > >> >> > > >> > > > http://www.ietf.org/internet-drafts/draft-kim-ccamp-accp-protocol-00.txt > >> >> > > >> >> >> > >> >> >> I want your comments. > >> >> >> > >> >> >> Regards > >> >> >> > >> >> >> Young. > >> >> >> > >> >> >> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D> >> Young-Hwa Kim > >> >> >> Principal Member / Ph.D > >> >> >> BcN Research Division, ETRI > >> >> >> Tel: +82-42-860-5819 > >> >> >> Fax: +82-42-860-5440 > >> >> >> e-mail: yhwkim@etri.re.kr > >> >> >> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D> >> > >> >> >> > >> >> > > >> >> > > >> > > > >> >> > > >> >> > > >> > > > g&name=3Dccamp%40ops.ietf.org&fromemail=3Dyhwkim@etri.re.kr&messageid=3D%= 3C863 > >> >> > > >> >> >>0a6db-0c31-49ab-a798-13b0dda04553@etri.re.kr%3E> > >> >> >> > >> >> >> > >> >> > > >> >> > > >> >> > > >> >> > > >> >> > > >> >> > > >> >> > __________________________________ > >> >> > Yahoo! Mail - PC Magazine Editors' Choice 2005 > >> >> > http://mail.yahoo.com > >> >> > > >> >> > > >> >> > . > >> >> > > >> > > >> > > >> > > > > > From owner-ccamp@ops.ietf.org Fri Oct 28 16:33:57 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVavE-0007qf-RX for ccamp-archive@megatron.ietf.org; Fri, 28 Oct 2005 16:33:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16990 for ; Fri, 28 Oct 2005 16:33:40 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVb8Y-0003w0-6a for ccamp-archive@ietf.org; Fri, 28 Oct 2005 16:48:02 -0400 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EVaps-0003XY-FU for ccamp-data@psg.com; Fri, 28 Oct 2005 20:28:24 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [63.118.39.27] (helo=mdmxm02.ciena.com) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EVapr-0003Wn-9l for ccamp@ops.ietf.org; Fri, 28 Oct 2005 20:28:23 +0000 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: Two Drafts for Resilience of Control Plane Date: Fri, 28 Oct 2005 16:28:20 -0400 Message-ID: <0901D1988E815341A0103206A834DA07902956@mdmxm02.ciena.com> Thread-Topic: Two Drafts for Resilience of Control Plane Thread-Index: AcXb+5sI7DBursUUSnCMr5SUjjw6QQAAZ19A From: "Ong, Lyndon" To: , , Cc: , "John E" , , "Igor Bryskin" , "Zafar Ali" , "Kim Young Hwa" , Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 578c2c9d0cb01ffe6e1ca36540edd070 Content-Transfer-Encoding: quoted-printable Hi Igor, Are you referring to controlling the LSP while one of the controllers is still down? That would mean that no restart has yet taken place. The draft seems to be focused on providing standby control channels, what you're suggesting sounds more like a standby signaling controller. Cheers, Lyndon -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of ibryskin@movaz.com Sent: Friday, October 28, 2005 1:08 PM To: dpapadimitriou@psg.com; dimitri.papadimitriou@alcatel.be Cc: ibryskin@movaz.com; Drake@movaz.com; John E; dimitri.papadimitriou@alcatel.be; Igor Bryskin; Zafar Ali; Kim Young Hwa; ccamp@ops.ietf.org Subject: Re: Two Drafts for Resilience of Control Plane Dimitri, See in-line. > igor - > > you are already going beyond the specific discussion context > > 1. what is a control plane partitioned LSP ? LSPs with one or more controllers down, so there is/are partitions in hop-by-hop signaling > > 2. when you state "Suppose one or more signaling controllers managing > some LSP went out of service leaving the LSP's data plane intact." > > what does it mean "one or more controllers" ? what if you support > RSVP GR ? why are you not able to recover the states ? etc. See my response to John. There are no restarts in my example > > hence, i still miss the exact problem wrt to the control plane=20 > protocol resilience > > but i think there is another issue (which is even more important) -=20 > the resilience mechanisms of the control plane that we have today have > been provided based on experience from the common use of the control=20 > plane and for being resilient wrt common failures - but not for ALL=20 > use of the control plane in ANY condition and for ALL possible=20 > failures - indeed what you are asking here is like what shall i do=20 > when the CP is completely down and the DP still up; it would surprise=20 > me that the CP would be of any help in this specific condition Believe me, CP could be still of a great help in such conditions. You need some signaling extensions - which is why I think CP resilience is an important topic within CCAMP - and then you can manage LSPs with control plane gaps at least to the extend I described. Igor > > thanks, > - dimitri. > > ibryskin@movaz.com wrote: > >> Hi, >> >> Here is one of the problems that I've been thinking for a while -=20 >> control plane partitioned LSPs. Suppose one or more signaling=20 >> controllers managing some LSP went out of service leaving the LSP's=20 >> data plane intact. As far as the user is concerned such LSP is=20 >> perfectly healthy and operational. >> Such situation could last for a considerable period of time. Do we=20 >> need to manage such LSP via control plane? Sure, we must be capable=20 >> to tear down such LSP, perform mb4b rerouting, distribute alarms=20 >> between operational controllers, signal data plane faults and perform >> recovery switchover, modify LSP status, etc. Can we do this today?=20 >> No, but with some >> (signaling) extensions the problem I believe is solvable. Is this=20 >> some artificial, "fabricated" problem? No, I think it is real. Does=20 >> it fall under the control plane resilience problem space? I believe it does. >> >> Igor >> >> >>>I agree with Zafar and Dimitri. If someone wanted to document the=20 >>>GMPLS control plane resiliency features, as was done for GMPLS=20 >>>addressing, that might be a useful activity. >>> >>> >>>>-----Original Message----- >>>>From: dimitri papadimitriou [mailto:dpapadimitriou@psg.com] >>>>Sent: Friday, October 28, 2005 9:56 AM >>>>To: Igor Bryskin >>>>Cc: Zafar Ali (zali); Kim Young Hwa; ccamp@ops.ietf.org >>>>Subject: Re: Two Drafts for Resilience of Control Plane >>>> >>>>igor - >>>> >>>>over time CCAMP came with a set of mechanims to improve control=20 >>>>plane resilience (RSVP and LMP GR upon channel/node failure) other=20 >>>>WG >>> >>>protocol >>> >>>>work are also usable used here OSPF GR, etc. ... on the other side,=20 >>>>mechanism such as link bundling have built-in resilience=20 >>>>capabilities and most GMPLS control plane capabilities have been=20 >>>>designed such as >>> >>>to >>> >>>>be independent of the control plane realisation (in-band,=20 >>>>out-of-band, >>>>etc.) >>>> >>>>so indeed i share the concern of Zafar what could we do more here=20 >>>>than document these tools and provide our experience in using them; >>>> >>>>now, before stating there are (potential) problems(s) arising -=20 >>>>would you please be more specific on what are these potential=20 >>>>issue(s) >>> >>>and/or >>> >>>>problems ? (not related to policy/config. - note: all the issues you >>>>have pointed here below are simply policy/config specific but none=20 >>>>of them highlights a missing IP control plane resiliency feature) >>>> >>>>thanks, >>>>- dimitri. >>>> >>>> >>>>Igor Bryskin wrote: >>>> >>>> >>>>>Zafar, >>>>> >>>>>The problem arises when the control plane is decoupled from the=20 >>>>>data plane. The question is do we need such decoupling in IP=20 >>>>>networks? Consider, for example, the situation when several=20 >>>>>parallel PSC data links bundled together and controlled by a single >>>>>control channel. >>>>>Does it mean in this case that when the control channel fails all=20 >>>>>associated data links also fail? Do we need to reroute in this case >>>>>LSPs that use the data links? Can we rely in this case on control=20 >>>>>plane indications to decide whether an associated data link is=20 >>>>>healthy or not (in other words, can we rely on RSVP Hellos or=20 >>>>>should we use, for example, BTD)? Should we be capable to recover=20 >>>>>control channels without disturbing data plane? I think control=20 >>>>>plane resilience is important for all layers. You are right,=20 >>>>>Internet does work, however, we do need for some reason TE and=20 >>>>>(fast) recovery in IP as much as in other layers,don't we? >>>>> >>>>>Cheers, >>>>>Igor >>>>> >>>>>--- "Zafar Ali (zali)" wrote: >>>>> >>>>> >>>>> >>>>>>Hi All, >>>>>> >>>>>>I am unable to understand the problem we are trying to solve or=20 >>>>>>fabricate. My control network is IP based and IP has proven=20 >>>>>>resiliency (Internet *does* work), why would I like to take=20 >>>>>>control plan resiliency problem at a layer *above-IP* and=20 >>>>>>complicate my life. Did I miss something? >>>>>> >>>>>>Thanks >>>>>> >>>>>>Regards... Zafar >>>>>> >>>>>> >>>>>>________________________________ >>>>>> >>>>>> From: owner-ccamp@ops.ietf.org >>>>>>[mailto:owner-ccamp@ops.ietf.org] >>>>>>On Behalf Of Kim Young Hwa >>>>>> Sent: Friday, October 28, 2005 6:04 AM >>>>>> To: ccamp@ops.ietf.org >>>>>> Subject: Two Drafts for Resilience of Control Plane >>>>>> >>>>>> >>>>>> Dear all, >>>>>> >>>>>> I posted two drafts for the resilience of control plane. >>>>>> One is for requirements of the resilience of control plane, the=20 >>>>>>other is for a protocol specification as a solution of that . >>>>>> These are now available at: >>>>>> >>>>>> >>>>> >>>>>http://www.ietf.org/internet-drafts/draft-kim-ccamp-cpr-reqts-01.tx >>>>>t >>>>> >>>>> >>>>>> >>>>> >>>http://www.ietf.org/internet-drafts/draft-kim-ccamp-accp-protocol-00. >>>txt >>> >>>>>> I want your comments. >>>>>> >>>>>> Regards >>>>>> >>>>>> Young. >>>>>> >>>>>> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D> >> Young-Hwa Kim >>>>>> Principal Member / Ph.D >>>>>> BcN Research Division, ETRI >>>>>> Tel: +82-42-860-5819 >>>>>> Fax: +82-42-860-5440 >>>>>> e-mail: yhwkim@etri.re.kr >>>>>> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D> >> >>>>>> >>>>> >>>>>.or >>> >>>>> >>>g&name=3Dccamp%40ops.ietf.org&fromemail=3Dyhwkim@etri.re.kr&messageid=3D= %3C >>>863 >>> >>>>>>0a6db-0c31-49ab-a798-13b0dda04553@etri.re.kr%3E> >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>__________________________________ >>>>>Yahoo! Mail - PC Magazine Editors' Choice 2005=20 >>>>>http://mail.yahoo.com >>>>> >>>>> >>>>>. >>>>> >>> >>> >>> >> >> >> >> . >> > From owner-ccamp@ops.ietf.org Fri Oct 28 16:56:45 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVbHH-000446-WA for ccamp-archive@megatron.ietf.org; Fri, 28 Oct 2005 16:56:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19091 for ; Fri, 28 Oct 2005 16:56:27 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVbUt-0004rg-6w for ccamp-archive@ietf.org; Fri, 28 Oct 2005 17:10:50 -0400 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EVbCU-0004oQ-Jp for ccamp-data@psg.com; Fri, 28 Oct 2005 20:51:46 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [130.76.96.56] (helo=stl-smtpout-01.boeing.com) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EVbCT-0004o9-Dm; Fri, 28 Oct 2005 20:51:45 +0000 Received: from slb-av-01.boeing.com ([129.172.13.4]) by stl-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id PAA29215; Fri, 28 Oct 2005 15:51:38 -0500 (CDT) Received: from XCH-SWBH-04.sw.nos.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id j9SKpbd00224; Fri, 28 Oct 2005 13:51:37 -0700 (PDT) Received: from XCH-SW-42.sw.nos.boeing.com ([192.79.11.43]) by XCH-SWBH-04.sw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 28 Oct 2005 13:51:36 -0700 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: Two Drafts for Resilience of Control Plane Date: Fri, 28 Oct 2005 13:51:36 -0700 Message-ID: <626FC7C6A97381468FB872072AB5DDC8369704@XCH-SW-42.sw.nos.boeing.com> Thread-Topic: Two Drafts for Resilience of Control Plane Thread-Index: AcXb+5sI7DBursUUSnCMr5SUjjw6QQAAZ19AAADmq6A= From: "Drake, John E" To: "Ong, Lyndon" , , , Cc: , , "Igor Bryskin" , "Zafar Ali" , "Kim Young Hwa" , X-OriginalArrivalTime: 28 Oct 2005 20:51:36.0905 (UTC) FILETIME=[634DD390:01C5DC01] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: f1405b5eaa25d745f8c52e3273d3af78 Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: Ong, Lyndon [mailto:Lyong@Ciena.com] > Sent: Friday, October 28, 2005 1:28 PM > To: ibryskin@movaz.com; dpapadimitriou@psg.com; > dimitri.papadimitriou@alcatel.be > Cc: Drake@movaz.com; Drake, John E; dimitri.papadimitriou@alcatel.be; Igor > Bryskin; Zafar Ali; Kim Young Hwa; ccamp@ops.ietf.org > Subject: RE: Two Drafts for Resilience of Control Plane >=20 > Hi Igor, >=20 > Are you referring to controlling the LSP while one of the controllers is > still down? That would mean that no restart has yet taken place. >=20 > The draft seems to be focused on providing standby control channels, [JD]=20 What is the utility of having standby control channels, as opposed to just having multiple *active* control channels? > what > you're suggesting sounds more like a standby signaling controller. [JD]=20 A standby signaling controller is an implementation option that shouldn't affect the existing GMPLS protocols >=20 > Cheers, >=20 > Lyndon >=20 > -----Original Message----- > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On > Behalf Of ibryskin@movaz.com > Sent: Friday, October 28, 2005 1:08 PM > To: dpapadimitriou@psg.com; dimitri.papadimitriou@alcatel.be > Cc: ibryskin@movaz.com; Drake@movaz.com; John E; > dimitri.papadimitriou@alcatel.be; Igor Bryskin; Zafar Ali; Kim Young > Hwa; ccamp@ops.ietf.org > Subject: Re: Two Drafts for Resilience of Control Plane >=20 > Dimitri, > See in-line. > > igor - > > > > you are already going beyond the specific discussion context > > > > 1. what is a control plane partitioned LSP ? >=20 > LSPs with one or more controllers down, so there is/are partitions in > hop-by-hop signaling > > > > 2. when you state "Suppose one or more signaling controllers managing > > some LSP went out of service leaving the LSP's data plane intact." > > > > what does it mean "one or more controllers" ? what if you support > > RSVP GR ? why are you not able to recover the states ? etc. >=20 > See my response to John. There are no restarts in my example >=20 > > > > hence, i still miss the exact problem wrt to the control plane > > protocol resilience > > > > but i think there is another issue (which is even more important) - > > the resilience mechanisms of the control plane that we have today have >=20 > > been provided based on experience from the common use of the control > > plane and for being resilient wrt common failures - but not for ALL > > use of the control plane in ANY condition and for ALL possible > > failures - indeed what you are asking here is like what shall i do > > when the CP is completely down and the DP still up; it would surprise > > me that the CP would be of any help in this specific condition >=20 > Believe me, CP could be still of a great help in such conditions. You > need some signaling extensions - which is why I think CP resilience is > an important topic within CCAMP - and then you can manage LSPs with > control plane gaps at least to the extend I described. >=20 > Igor >=20 > > > > thanks, > > - dimitri. > > > > ibryskin@movaz.com wrote: > > > >> Hi, > >> > >> Here is one of the problems that I've been thinking for a while - > >> control plane partitioned LSPs. Suppose one or more signaling > >> controllers managing some LSP went out of service leaving the LSP's > >> data plane intact. As far as the user is concerned such LSP is > >> perfectly healthy and operational. > >> Such situation could last for a considerable period of time. Do we > >> need to manage such LSP via control plane? Sure, we must be capable > >> to tear down such LSP, perform mb4b rerouting, distribute alarms > >> between operational controllers, signal data plane faults and perform >=20 > >> recovery switchover, modify LSP status, etc. Can we do this today? > >> No, but with some > >> (signaling) extensions the problem I believe is solvable. Is this > >> some artificial, "fabricated" problem? No, I think it is real. Does > >> it fall under the control plane resilience problem space? I believe > it does. > >> > >> Igor > >> > >> > >>>I agree with Zafar and Dimitri. If someone wanted to document the > >>>GMPLS control plane resiliency features, as was done for GMPLS > >>>addressing, that might be a useful activity. > >>> > >>> > >>>>-----Original Message----- > >>>>From: dimitri papadimitriou [mailto:dpapadimitriou@psg.com] > >>>>Sent: Friday, October 28, 2005 9:56 AM > >>>>To: Igor Bryskin > >>>>Cc: Zafar Ali (zali); Kim Young Hwa; ccamp@ops.ietf.org > >>>>Subject: Re: Two Drafts for Resilience of Control Plane > >>>> > >>>>igor - > >>>> > >>>>over time CCAMP came with a set of mechanims to improve control > >>>>plane resilience (RSVP and LMP GR upon channel/node failure) other > >>>>WG > >>> > >>>protocol > >>> > >>>>work are also usable used here OSPF GR, etc. ... on the other side, > >>>>mechanism such as link bundling have built-in resilience > >>>>capabilities and most GMPLS control plane capabilities have been > >>>>designed such as > >>> > >>>to > >>> > >>>>be independent of the control plane realisation (in-band, > >>>>out-of-band, > >>>>etc.) > >>>> > >>>>so indeed i share the concern of Zafar what could we do more here > >>>>than document these tools and provide our experience in using them; > >>>> > >>>>now, before stating there are (potential) problems(s) arising - > >>>>would you please be more specific on what are these potential > >>>>issue(s) > >>> > >>>and/or > >>> > >>>>problems ? (not related to policy/config. - note: all the issues you >=20 > >>>>have pointed here below are simply policy/config specific but none > >>>>of them highlights a missing IP control plane resiliency feature) > >>>> > >>>>thanks, > >>>>- dimitri. > >>>> > >>>> > >>>>Igor Bryskin wrote: > >>>> > >>>> > >>>>>Zafar, > >>>>> > >>>>>The problem arises when the control plane is decoupled from the > >>>>>data plane. The question is do we need such decoupling in IP > >>>>>networks? Consider, for example, the situation when several > >>>>>parallel PSC data links bundled together and controlled by a single >=20 > >>>>>control channel. > >>>>>Does it mean in this case that when the control channel fails all > >>>>>associated data links also fail? Do we need to reroute in this case >=20 > >>>>>LSPs that use the data links? Can we rely in this case on control > >>>>>plane indications to decide whether an associated data link is > >>>>>healthy or not (in other words, can we rely on RSVP Hellos or > >>>>>should we use, for example, BTD)? Should we be capable to recover > >>>>>control channels without disturbing data plane? I think control > >>>>>plane resilience is important for all layers. You are right, > >>>>>Internet does work, however, we do need for some reason TE and > >>>>>(fast) recovery in IP as much as in other layers,don't we? > >>>>> > >>>>>Cheers, > >>>>>Igor > >>>>> > >>>>>--- "Zafar Ali (zali)" wrote: > >>>>> > >>>>> > >>>>> > >>>>>>Hi All, > >>>>>> > >>>>>>I am unable to understand the problem we are trying to solve or > >>>>>>fabricate. My control network is IP based and IP has proven > >>>>>>resiliency (Internet *does* work), why would I like to take > >>>>>>control plan resiliency problem at a layer *above-IP* and > >>>>>>complicate my life. Did I miss something? > >>>>>> > >>>>>>Thanks > >>>>>> > >>>>>>Regards... Zafar > >>>>>> > >>>>>> > >>>>>>________________________________ > >>>>>> > >>>>>> From: owner-ccamp@ops.ietf.org > >>>>>>[mailto:owner-ccamp@ops.ietf.org] > >>>>>>On Behalf Of Kim Young Hwa > >>>>>> Sent: Friday, October 28, 2005 6:04 AM > >>>>>> To: ccamp@ops.ietf.org > >>>>>> Subject: Two Drafts for Resilience of Control Plane > >>>>>> > >>>>>> > >>>>>> Dear all, > >>>>>> > >>>>>> I posted two drafts for the resilience of control plane. > >>>>>> One is for requirements of the resilience of control plane, > the > >>>>>>other is for a protocol specification as a solution of that . > >>>>>> These are now available at: > >>>>>> > >>>>>> > >>>>> > >>>>>http://www.ietf.org/internet-drafts/draft-kim-ccamp-cpr-reqts-01.tx > >>>>>t > >>>>> > >>>>> > >>>>>> > >>>>> > >>>http://www.ietf.org/internet-drafts/draft-kim-ccamp-accp-protocol-00. > >>>txt > >>> > >>>>>> I want your comments. > >>>>>> > >>>>>> Regards > >>>>>> > >>>>>> Young. > >>>>>> > >>>>>> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D> >> Young-Hwa Kim > >>>>>> Principal Member / Ph.D > >>>>>> BcN Research Division, ETRI > >>>>>> Tel: +82-42-860-5819 > >>>>>> Fax: +82-42-860-5440 > >>>>>> e-mail: yhwkim@etri.re.kr > >>>>>> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D> >> > >>>>>> > >>>>> > >>> >>>.or > >>> > >>>>> > >>>g&name=3Dccamp%40ops.ietf.org&fromemail=3Dyhwkim@etri.re.kr&messageid=3D= %3C > >>>863 > >>> > >>>>>>0a6db-0c31-49ab-a798-13b0dda04553@etri.re.kr%3E> > >>>>>> > >>>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>__________________________________ > >>>>>Yahoo! Mail - PC Magazine Editors' Choice 2005 > >>>>>http://mail.yahoo.com > >>>>> > >>>>> > >>>>>. > >>>>> > >>> > >>> > >>> > >> > >> > >> > >> . > >> > > >=20 From owner-ccamp@ops.ietf.org Fri Oct 28 18:42:05 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVcvE-0002n6-3L for ccamp-archive@megatron.ietf.org; Fri, 28 Oct 2005 18:42:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24486 for ; Fri, 28 Oct 2005 18:41:46 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVd8q-0007iF-3K for ccamp-archive@ietf.org; Fri, 28 Oct 2005 18:56:11 -0400 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EVcmw-000AK5-Kd for ccamp-data@psg.com; Fri, 28 Oct 2005 22:33:30 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [130.76.96.56] (helo=stl-smtpout-01.boeing.com) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EVcmv-000AJp-Bo; Fri, 28 Oct 2005 22:33:29 +0000 Received: from blv-av-01.boeing.com ([192.42.227.216]) by stl-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id RAA25052; Fri, 28 Oct 2005 17:33:28 -0500 (CDT) Received: from XCH-SWBH-04.sw.nos.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id j9SMXRH16167; Fri, 28 Oct 2005 15:33:27 -0700 (PDT) Received: from XCH-SW-42.sw.nos.boeing.com ([192.79.11.43]) by XCH-SWBH-04.sw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 28 Oct 2005 15:33:26 -0700 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: comments on draft-shiba-ccamp-gmpls-lambda-labels-00.txt Date: Fri, 28 Oct 2005 15:33:26 -0700 Message-ID: <626FC7C6A97381468FB872072AB5DDC8369708@XCH-SW-42.sw.nos.boeing.com> Thread-Topic: comments on draft-shiba-ccamp-gmpls-lambda-labels-00.txt Thread-Index: AcXbIzcAFoI5B5TzS9O/zBGY1cMJbwA6iz0A From: "Drake, John E" To: , "Shiba, Sidney" Cc: "Adrian Farrel" , , X-OriginalArrivalTime: 28 Oct 2005 22:33:26.0884 (UTC) FILETIME=[9D22A240:01C5DC0F] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 343d06d914165ffd9d590a64755216ca Content-Transfer-Encoding: quoted-printable Hi, Below is the text of an e-mail is sent to the Ethernet/GMPLS mailing list. Upon reflection I am not sure using a real wavelength value makes much sense. Between a pair of adjacent nodes, there may be multiple pairs of switch ports in the same TE link that support a given frequency. If a real wavelength value is used, how do the two nodes agree on which pair of switch ports to use? Furthermore, the amount of configuration is the same - you still need to configure the wavelength of each switch port. Thanks, John =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D Adrian, In the transparent photonic lambda switch case, the labels also have only local significance. When an LSP is established, the input ports, as identified with local labels, are cross-connected to the output ports, as identified with local labels. There is just extra configuration to identify, using strictly local identifiers, the wavelength associated with the all of the switch's ports, and an additional CAC requirement that the wavelengths of the input and output ports are the same. Thanks, John =20 > -----Original Message----- > From: dimitri papadimitriou [mailto:dpapadimitriou@psg.com] > Sent: Thursday, October 27, 2005 10:03 AM > To: Shiba, Sidney > Cc: dimitri.papadimitriou@alcatel.be; Adrian Farrel; > richard.rabbat@us.fujitsu.com; ccamp@ops.ietf.org > Subject: Re: comments on draft-shiba-ccamp-gmpls-lambda-labels-00.txt >=20 > shiba - see inline for some additional hints: >=20 > >>Shiba, Sidney wrote: > >> > >>>Adrian, Dimitri, > >>> > >>>Thanks for reviewing these I-D. > >>> > >>>Wavelength continuity constraint does require the use of semanticful > >>>label whether it is spectral or index. > >> > >>=3D> see my reply to adrian on this specific point > >> > >>>I agree with Dimitri that the > >>>wavelength indexing requires document updating each time a new > >>>spectrum is introduced. > >> > >>=3D> indeed and in addition it requires updating the already > >>signaled path > >> > >>>The use of spectral label provides self maintainance, i.e., > >>>no need to update any document and the use of the nominal value > >>>provides a common semantic ground. > >> > >>=3D> what do you mean by self-maintenance - would you provide a > >>bit more detail > > > > [Sidney]What I've meant here was that it was not necessary to > > update any document when new wavelengths are inventoried. In the > > case of indexing approach, it would require the wavelength indexing > > document to be updated with implementation impacts. > > > > In the case, the nominal value is used, there is no need for > > documentation update. >=20 > ok - what you mean here is that you are going to make use of the already > defined C-Type 2 - what about the specific encoding of the value space ? >=20 > >>=3D> now i have a more specific question before being light-up > >>how do you know the frequency that you can support ? > > > > [Sidney] Some new technologies integrate optical switch and mux/demux > > capabilities, which allows the equipment to know the spectrum it > supports. >=20 > indeed - but the question is what does happen if the "detected" values > (during initialization) do not match the nominal values ? you don't > initialize then ? >=20 > >>if these differ from the nominal values how are you going to deal with > these > >>discrepancies ? > > > > [Sidney] These new technologies uses the nominal value as reference. We > can say > > that a lightpath wavelength is identified by its nominal value. If the > equipment > > is drifting from this nominal value, it is considered as a failure. >=20 > ok - but if the deviation is such you have overlap - how the control > plane is going to be able to detect such failure ? >=20 > >>this said i am not necessarily sure that having to maintain the data > plane > >>specifics as part of the control plane is really helping > >>operations (is this method not just duplicating complexity ?) > > > > [Sidney] The wavelength is WDM specific as much as the SUKLM label > encoding > > is for SONET. The wavelegth/frequency nominal value is used to identify > the > > facilities to cross-connect. >=20 > there is an equivalence but there is also a major difference, the > structure is invariant independently of the state of the network, with > spectral value space you may have labels that become unavailable due to > non-local usage of wavelength in the network >=20 > hence, there is also no real coupling to the data plane more than > knowing the type of interface and some generic capabilities >=20 > >>>I'm not sure if the draft needs to be updated before the > >>>face-to-face meeting or after all comments are collected. Please > advise. > >> > >>=3D> suggest to keep discussion on - document update can be > >>performed at a later stage >=20 > thanks, > - dimitri. >=20 > >>>>-----Original Message----- > >>>>From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On > >>>>Behalf Of Adrian Farrel > >>>>Sent: Thursday, October 27, 2005 4:45 AM > >>>>To: dpapadimitriou@psg.com; dimitri.papadimitriou@alcatel.be; > >>>>ccamp@ops.ietf.org > >>>>Subject: Re: comments on > >> > >>draft-shiba-ccamp-gmpls-lambda-labels-00.txt > >> > >>>> > >>>>Dimitri, > >>>> > >>>>Thanks for your work reviewing these recent I-Ds. It is > >>>>really valuable > >>>>and I'd welcome other people doing similar reviews. > >>>> > >>>> > >>>> > >>>>>there is a specific point to be clarified in this document: > >>>>> > >>>>>semanticless vs semanticful label (even here there is a distinction > >>>>>between spectral vs indexes i.e. using the wavelength index) > >>>>> > >>>>>domain-wide vs link local significant label > >>>> > >>>>Without being too picky, I think all labels are semanticful > >>>>otherwise, we > >>>>would not know what resource they refered to. > >>>> > >>>>So the point reduces to whether the scope of the semantics > >>>>are link-local > >>>>or wider. > >>>> > >>>> > >>>> > >>>>>so, the comparison from this perspective with TDM labels is > >>>> > >>>>difficult to > >>>> > >>>> > >>>>>parse, the latter is semanticful but link local > >>>>> > >>>>>now, i don't specifically see what has changed the late 90's, early > >>>>>y2k's, to have a change in the wavelength label definition; > >>>> > >>>>This is the question I would like to get to the bottom of. In > >>>>other words: > >>>>do we need this function? > >>>> > >>>>It seems to me that the question being asked is this: > >>>> > >>>> If I want to compute a path that has some form of wavelength > >>>> constraints, what information do I need access to? > >>>> > >>>>Another question might be: > >>>> > >>>> If I want to signal a path with wavelength constraints what > >>>> information do I need to include in the signaling message? > >>>> > >>>> > >>>>I'd suggest that when we started on GMPLS, we were > >> > >>enthusiastic about > >> > >>>>transparent optical networks, but we were not properly > >>>>focusing wavelength > >>>>constraints because lambda-switching PXCs didn't take off. > >>>>Therefore we > >>>>didn't examine the requirements for wavelength constraints in > >>>>routing and > >>>>signaling. The authors of this I-D are claiming new hardware > >>>>requirements > >>>>for the same function. > >>>> > >>>> > >>>> > >>>>>there are > >>>>>several solution possible > >>>>> > >>>>>- absolute values: the freq. of the wavelength: difficult to adopt > >>>>>because referenced values are nominal and knowing all interactions > >>>>>between wavelengths this knowledge is at the end of little > >> > >>practical > >> > >>>>>usage; (introduces implicit ordering) > >>>>> > >>>>>- indexed values: the # of the wavelength: it does not > >> > >>provide for a > >> > >>>>>future proof label space for inst. in case new frequencies > >>>> > >>>>are inserted > >>>> > >>>> > >>>>>in the grid (introduces explicit ordering) > >>>>> > >>>>>- diff. values e.g. freq spacing starting from a reference > >>>> > >>>>value: pauses > >>>> > >>>> > >>>>>the question of the reference value and does suffer from the former > >>>>>issue (introduces implicit ordering) > >>>>> > >>>>>- the solution available today - cumbersome in some control plane > >>>>>operations (e.g. label set translation) and not easy to > >>>> > >>>>troubleshoot but > >>>> > >>>> > >>>>>independent of any physical consideration (spectral), scale to any > >>>>>number of wavelength per fiber, does not introduce any > >> > >>ordering, the > >> > >>>>>most flexible (since allowing each system to maintain its specific > >>>>>control operations) and the less constraining since maintaining the > >>>>>control plane operations independent of any data plane specifics > >>>>> > >>>>> > >>>> > >>>> >>> > >>>ambda-labels > >>>-00.txt> > >>> > >>>. > >>> > >> > > > > . > > From owner-ccamp@ops.ietf.org Fri Oct 28 19:32:44 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVdiE-0000Bg-GX for ccamp-archive@megatron.ietf.org; Fri, 28 Oct 2005 19:32:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26587 for ; Fri, 28 Oct 2005 19:32:25 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVdvt-0000Uv-BX for ccamp-archive@ietf.org; Fri, 28 Oct 2005 19:46:49 -0400 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EVdcf-000CqW-NQ for ccamp-data@psg.com; Fri, 28 Oct 2005 23:26:57 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-4.9 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from localhost ([127.0.0.1]) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EVdcc-000CpL-45; Fri, 28 Oct 2005 23:26:54 +0000 Message-ID: <4362B390.1090609@psg.com> Date: Sat, 29 Oct 2005 01:26:08 +0200 From: dimitri papadimitriou Reply-To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.11) Gecko/20050728 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ibryskin@movaz.com CC: dimitri.papadimitriou@alcatel.be, Drake@movaz.com, John E , Igor Bryskin , Zafar Ali , Kim Young Hwa , ccamp@ops.ietf.org Subject: Re: Two Drafts for Resilience of Control Plane References: <626FC7C6A97381468FB872072AB5DDC83696FA@XCH-SW-42.sw.nos.boeing.com> <4618.68.100.80.11.1130524889.squirrel@webmail.movaz.com> <436275E3.9040504@psg.com> <4658.68.100.80.11.1130530098.squirrel@webmail.movaz.com> In-Reply-To: <4658.68.100.80.11.1130530098.squirrel@webmail.movaz.com> Content-Type: text/plain; charset=windows-1252; format=flowed Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 5fb88b8381f3896aeacc5a021513237b Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id TAA26587 igor - see in-line ibryskin@movaz.com wrote: > Dimitri, > See in-line. >=20 >>igor - >> >>you are already going beyond the specific discussion context >> >>1. what is a control plane partitioned LSP ? > =20 > LSPs with one or more controllers down, so there is/are partitions in > hop-by-hop signaling >=20 >>2. when you state "Suppose one or more signaling controllers managing >> some LSP went out of service leaving the LSP=92s data plane intact.= " >> >> what does it mean "one or more controllers" ? what if you support >> RSVP GR ? why are you not able to recover the states ? etc. >=20 > See my response to John. There are no restarts in my example you stated "I think you missed my point here. "Dead" controllers in my example *do not* come back for a considerable period of time. So there are no=20 restarts here (graceful or not graceful) :=3D)" but this is exactly issue i am pointing here below - if a controller is=20 really DEAD (and i included here any redundant controller pair) - beside=20 *replacing* the damaged controller and restart i don't know which kind=20 of additional extension you are asking for in the present context ...=20 and this is logical we are discussing control plane availability/MTBF=20 issues rather than resiliency issues >>hence, i still miss the exact problem wrt to the control plane protocol >>resilience >> >>but i think there is another issue (which is even more important) - the >>resilience mechanisms of the control plane that we have today have been >>provided based on experience from the common use of the control plane >>and for being resilient wrt common failures - but not for ALL use of th= e >>control plane in ANY condition and for ALL possible failures - indeed >>what you are asking here is like what shall i do when the CP is >>completely down and the DP still up; it would surprise me that the CP >>would be of any help in this specific condition >=20 > Believe me, CP could be still of a great help in such conditions. You n= eed > some signaling extensions - which is why I think CP resilience is an > important topic within CCAMP - and then you can manage LSPs with contro= l > plane gaps at least to the extend I described. > Igor >=20 >=20 >>thanks, >>- dimitri. >> >>ibryskin@movaz.com wrote: >> >> >>>Hi, >>> >>>Here is one of the problems that I=92ve been thinking for a while =96 >>>control >>>plane partitioned LSPs. Suppose one or more signaling controllers >>>managing >>>some LSP went out of service leaving the LSP=92s data plane intact. As= far >>>as the user is concerned such LSP is perfectly healthy and operational. >>>Such situation could last for a considerable period of time. Do we nee= d >>>to >>>manage such LSP via control plane? Sure, we must be capable to tear do= wn >>>such LSP, perform mb4b rerouting, distribute alarms between operationa= l >>>controllers, signal data plane faults and perform recovery switchover, >>>modify LSP status, etc. Can we do this today? No, but with some >>>(signaling) extensions the problem I believe is solvable. Is this some >>>artificial, =93fabricated=94 problem? No, I think it is real. Does it = fall >>>under the control plane resilience problem space? I believe it does. >>> >>>Igor >>> >>> >>> >>>>I agree with Zafar and Dimitri. If someone wanted to document the GM= PLS >>>>control plane resiliency features, as was done for GMPLS addressing, >>>>that might be a useful activity. >>>> >>>> >>>> >>>>>-----Original Message----- >>>>>From: dimitri papadimitriou [mailto:dpapadimitriou@psg.com] >>>>>Sent: Friday, October 28, 2005 9:56 AM >>>>>To: Igor Bryskin >>>>>Cc: Zafar Ali (zali); Kim Young Hwa; ccamp@ops.ietf.org >>>>>Subject: Re: Two Drafts for Resilience of Control Plane >>>>> >>>>>igor - >>>>> >>>>>over time CCAMP came with a set of mechanims to improve control plan= e >>>>>resilience (RSVP and LMP GR upon channel/node failure) other WG >>>> >>>>protocol >>>> >>>> >>>>>work are also usable used here OSPF GR, etc. ... on the other side, >>>>>mechanism such as link bundling have built-in resilience capabilitie= s >>>>>and most GMPLS control plane capabilities have been designed such as >>>> >>>>to >>>> >>>> >>>>>be independent of the control plane realisation (in-band, out-of-ban= d, >>>>>etc.) >>>>> >>>>>so indeed i share the concern of Zafar what could we do more here th= an >>>>>document these tools and provide our experience in using them; >>>>> >>>>>now, before stating there are (potential) problems(s) arising - woul= d >>>>>you please be more specific on what are these potential issue(s) >>>> >>>>and/or >>>> >>>> >>>>>problems ? (not related to policy/config. - note: all the issues you >>>>>have pointed here below are simply policy/config specific but none o= f >>>>>them highlights a missing IP control plane resiliency feature) >>>>> >>>>>thanks, >>>>>- dimitri. >>>>> >>>>> >>>>>Igor Bryskin wrote: >>>>> >>>>> >>>>> >>>>>>Zafar, >>>>>> >>>>>>The problem arises when the control plane is decoupled >>>>> >>>>>>from the data plane. The question is do we need such >>>>> >>>>>>decoupling in IP networks? Consider, for example, the >>>>>>situation when several parallel PSC data links bundled >>>>>>together and controlled by a single control channel. >>>>>>Does it mean in this case that when the control >>>>>>channel fails all associated data links also fail? Do >>>>>>we need to reroute in this case LSPs that use the data >>>>>>links? Can we rely in this case on control plane >>>>>>indications to decide whether an associated data link >>>>>>is healthy or not (in other words, can we rely on RSVP >>>>>>Hellos or should we use, for example, BTD)? Should we >>>>>>be capable to recover control channels without >>>>>>disturbing data plane? I think control plane >>>>>>resilience is important for all layers. You are right, >>>>>>Internet does work, however, we do need for some >>>>>>reason TE and (fast) recovery in IP as much as in >>>>>>other layers,don't we? >>>>>> >>>>>>Cheers, >>>>>>Igor >>>>>> >>>>>>--- "Zafar Ali (zali)" wrote: >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>Hi All, >>>>>>> >>>>>>>I am unable to understand the problem we are trying >>>>>>>to solve or >>>>>>>fabricate. My control network is IP based and IP has >>>>>>>proven resiliency >>>>>>>(Internet *does* work), why would I like to take >>>>>>>control plan resiliency >>>>>>>problem at a layer *above-IP* and complicate my >>>>>>>life. Did I miss >>>>>>>something? >>>>>>> >>>>>>>Thanks >>>>>>> >>>>>>>Regards... Zafar >>>>>>> >>>>>>> >>>>>>>________________________________ >>>>>>> >>>>>>> From: owner-ccamp@ops.ietf.org >>>>>>>[mailto:owner-ccamp@ops.ietf.org] >>>>>>>On Behalf Of Kim Young Hwa >>>>>>> Sent: Friday, October 28, 2005 6:04 AM >>>>>>> To: ccamp@ops.ietf.org >>>>>>> Subject: Two Drafts for Resilience of Control Plane >>>>>>> >>>>>>> >>>>>>> Dear all, >>>>>>> >>>>>>> I posted two drafts for the resilience of control >>>>>>>plane. >>>>>>> One is for requirements of the resilience of >>>>>>>control plane, the >>>>>>>other is for a protocol specification as a solution >>>>>>>of that . >>>>>>> These are now available at: >>>>>>> >>>>>>> >>>>>> >>>>>>http://www.ietf.org/internet-drafts/draft-kim-ccamp-cpr-reqts-01.tx= t >>>>>> >>>>>> >>>>>> >>>>http://www.ietf.org/internet-drafts/draft-kim-ccamp-accp-protocol-00.= txt >>>> >>>> >>>>>>> I want your comments. >>>>>>> >>>>>>> Regards >>>>>>> >>>>>>> Young. >>>>>>> >>>>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D> >> Young-Hwa Kim >>>>>>> Principal Member / Ph.D >>>>>>> BcN Research Division, ETRI >>>>>>> Tel: +82-42-860-5819 >>>>>>> Fax: +82-42-860-5440 >>>>>>> e-mail: yhwkim@etri.re.kr >>>>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D> >> >>>>>>> >>>>>>> >>>> >>>>g&name=3Dccamp%40ops.ietf.org&fromemail=3Dyhwkim@etri.re.kr&messageid= =3D%3C863 >>>> >>>> >>>>>>>0a6db-0c31-49ab-a798-13b0dda04553@etri.re.kr%3E> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>__________________________________ >>>>>>Yahoo! Mail - PC Magazine Editors' Choice 2005 >>>>>>http://mail.yahoo.com >>>>>> >>>>>> >>>>>>. >>>>>> >>>> >>>> >>>> >>> >>> >>>. >>> >> >=20 >=20 > . >=20 From owner-ccamp@ops.ietf.org Fri Oct 28 19:36:43 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVdm6-0000wz-Oy for ccamp-archive@megatron.ietf.org; Fri, 28 Oct 2005 19:36:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26856 for ; Fri, 28 Oct 2005 19:36:25 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVdzl-0000dL-Bw for ccamp-archive@ietf.org; Fri, 28 Oct 2005 19:50:49 -0400 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EVdiJ-000DBw-JH for ccamp-data@psg.com; Fri, 28 Oct 2005 23:32:47 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-4.8 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from localhost ([127.0.0.1]) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EVdiI-000DBU-61; Fri, 28 Oct 2005 23:32:46 +0000 Message-ID: <4362B4F0.4050801@psg.com> Date: Sat, 29 Oct 2005 01:32:00 +0200 From: dimitri papadimitriou Reply-To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.11) Gecko/20050728 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Drake, John E" CC: "Ong, Lyndon" , ibryskin@movaz.com, dimitri.papadimitriou@alcatel.be, Drake@movaz.com, Igor Bryskin , Zafar Ali , Kim Young Hwa , ccamp@ops.ietf.org Subject: Re: Two Drafts for Resilience of Control Plane References: <626FC7C6A97381468FB872072AB5DDC8369704@XCH-SW-42.sw.nos.boeing.com> In-Reply-To: <626FC7C6A97381468FB872072AB5DDC8369704@XCH-SW-42.sw.nos.boeing.com> 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: e654cfa5e44bd623be3eb2c720858b05 Content-Transfer-Encoding: 7bit Drake, John E wrote: > >>-----Original Message----- >>From: Ong, Lyndon [mailto:Lyong@Ciena.com] >>Sent: Friday, October 28, 2005 1:28 PM >>To: ibryskin@movaz.com; dpapadimitriou@psg.com; >>dimitri.papadimitriou@alcatel.be >>Cc: Drake@movaz.com; Drake, John E; dimitri.papadimitriou@alcatel.be; > > Igor > >>Bryskin; Zafar Ali; Kim Young Hwa; ccamp@ops.ietf.org >>Subject: RE: Two Drafts for Resilience of Control Plane >> >>Hi Igor, >> >>Are you referring to controlling the LSP while one of the controllers > > is > >>still down? That would mean that no restart has yet taken place. >> >>The draft seems to be focused on providing standby control channels, > > [JD] > > What is the utility of having standby control channels, as opposed to > just having multiple *active* control channels? none - (except if the hardware is limited and does not allow load spreading among multiple channels but this is not a "feature") >>what >>you're suggesting sounds more like a standby signaling controller. > > [JD] > > A standby signaling controller is an implementation option that > shouldn't affect the existing GMPLS protocols it would surprise that hot swappable control plane instance would require any external coordination (i would say the objective is quite the opposite i.e. to disturb as less as possible neighbors) >>Cheers, >> >>Lyndon >> >>-----Original Message----- >>From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On >>Behalf Of ibryskin@movaz.com >>Sent: Friday, October 28, 2005 1:08 PM >>To: dpapadimitriou@psg.com; dimitri.papadimitriou@alcatel.be >>Cc: ibryskin@movaz.com; Drake@movaz.com; John E; >>dimitri.papadimitriou@alcatel.be; Igor Bryskin; Zafar Ali; Kim Young >>Hwa; ccamp@ops.ietf.org >>Subject: Re: Two Drafts for Resilience of Control Plane >> >>Dimitri, >>See in-line. >> >>>igor - >>> >>>you are already going beyond the specific discussion context >>> >>>1. what is a control plane partitioned LSP ? >> >>LSPs with one or more controllers down, so there is/are partitions in >>hop-by-hop signaling >> >>>2. when you state "Suppose one or more signaling controllers > > managing > >>> some LSP went out of service leaving the LSP's data plane > > intact." > >>> what does it mean "one or more controllers" ? what if you > > support > >>> RSVP GR ? why are you not able to recover the states ? etc. >> >>See my response to John. There are no restarts in my example >> >> >>>hence, i still miss the exact problem wrt to the control plane >>>protocol resilience >>> >>>but i think there is another issue (which is even more important) - >>>the resilience mechanisms of the control plane that we have today > > have > >>>been provided based on experience from the common use of the control >>>plane and for being resilient wrt common failures - but not for ALL >>>use of the control plane in ANY condition and for ALL possible >>>failures - indeed what you are asking here is like what shall i do >>>when the CP is completely down and the DP still up; it would > > surprise > >>>me that the CP would be of any help in this specific condition >> >>Believe me, CP could be still of a great help in such conditions. You >>need some signaling extensions - which is why I think CP resilience is >>an important topic within CCAMP - and then you can manage LSPs with >>control plane gaps at least to the extend I described. >> >>Igor >> >> >>>thanks, >>>- dimitri. >>> >>>ibryskin@movaz.com wrote: >>> >>> >>>>Hi, >>>> >>>>Here is one of the problems that I've been thinking for a while - >>>>control plane partitioned LSPs. Suppose one or more signaling >>>>controllers managing some LSP went out of service leaving the LSP's >>>>data plane intact. As far as the user is concerned such LSP is >>>>perfectly healthy and operational. >>>>Such situation could last for a considerable period of time. Do we >>>>need to manage such LSP via control plane? Sure, we must be capable >>>>to tear down such LSP, perform mb4b rerouting, distribute alarms >>>>between operational controllers, signal data plane faults and > > perform > >>>>recovery switchover, modify LSP status, etc. Can we do this today? >>>>No, but with some >>>>(signaling) extensions the problem I believe is solvable. Is this >>>>some artificial, "fabricated" problem? No, I think it is real. Does >>>>it fall under the control plane resilience problem space? I believe >> >>it does. >> >>>>Igor >>>> >>>> >>>> >>>>>I agree with Zafar and Dimitri. If someone wanted to document the >>>>>GMPLS control plane resiliency features, as was done for GMPLS >>>>>addressing, that might be a useful activity. >>>>> >>>>> >>>>> >>>>>>-----Original Message----- >>>>>>From: dimitri papadimitriou [mailto:dpapadimitriou@psg.com] >>>>>>Sent: Friday, October 28, 2005 9:56 AM >>>>>>To: Igor Bryskin >>>>>>Cc: Zafar Ali (zali); Kim Young Hwa; ccamp@ops.ietf.org >>>>>>Subject: Re: Two Drafts for Resilience of Control Plane >>>>>> >>>>>>igor - >>>>>> >>>>>>over time CCAMP came with a set of mechanims to improve control >>>>>>plane resilience (RSVP and LMP GR upon channel/node failure) other >>>>>>WG >>>>> >>>>>protocol >>>>> >>>>> >>>>>>work are also usable used here OSPF GR, etc. ... on the other > > side, > >>>>>>mechanism such as link bundling have built-in resilience >>>>>>capabilities and most GMPLS control plane capabilities have been >>>>>>designed such as >>>>> >>>>>to >>>>> >>>>> >>>>>>be independent of the control plane realisation (in-band, >>>>>>out-of-band, >>>>>>etc.) >>>>>> >>>>>>so indeed i share the concern of Zafar what could we do more here >>>>>>than document these tools and provide our experience in using > > them; > >>>>>>now, before stating there are (potential) problems(s) arising - >>>>>>would you please be more specific on what are these potential >>>>>>issue(s) >>>>> >>>>>and/or >>>>> >>>>> >>>>>>problems ? (not related to policy/config. - note: all the issues > > you > >>>>>>have pointed here below are simply policy/config specific but none >>>>>>of them highlights a missing IP control plane resiliency feature) >>>>>> >>>>>>thanks, >>>>>>- dimitri. >>>>>> >>>>>> >>>>>>Igor Bryskin wrote: >>>>>> >>>>>> >>>>>> >>>>>>>Zafar, >>>>>>> >>>>>>>The problem arises when the control plane is decoupled from the >>>>>>>data plane. The question is do we need such decoupling in IP >>>>>>>networks? Consider, for example, the situation when several >>>>>>>parallel PSC data links bundled together and controlled by a > > single > >>>>>>>control channel. >>>>>>>Does it mean in this case that when the control channel fails all >>>>>>>associated data links also fail? Do we need to reroute in this > > case > >>>>>>>LSPs that use the data links? Can we rely in this case on control >>>>>>>plane indications to decide whether an associated data link is >>>>>>>healthy or not (in other words, can we rely on RSVP Hellos or >>>>>>>should we use, for example, BTD)? Should we be capable to recover >>>>>>>control channels without disturbing data plane? I think control >>>>>>>plane resilience is important for all layers. You are right, >>>>>>>Internet does work, however, we do need for some reason TE and >>>>>>>(fast) recovery in IP as much as in other layers,don't we? >>>>>>> >>>>>>>Cheers, >>>>>>>Igor >>>>>>> >>>>>>>--- "Zafar Ali (zali)" wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>>Hi All, >>>>>>>> >>>>>>>>I am unable to understand the problem we are trying to solve or >>>>>>>>fabricate. My control network is IP based and IP has proven >>>>>>>>resiliency (Internet *does* work), why would I like to take >>>>>>>>control plan resiliency problem at a layer *above-IP* and >>>>>>>>complicate my life. Did I miss something? >>>>>>>> >>>>>>>>Thanks >>>>>>>> >>>>>>>>Regards... Zafar >>>>>>>> >>>>>>>> >>>>>>>>________________________________ >>>>>>>> >>>>>>>> From: owner-ccamp@ops.ietf.org >>>>>>>>[mailto:owner-ccamp@ops.ietf.org] >>>>>>>>On Behalf Of Kim Young Hwa >>>>>>>> Sent: Friday, October 28, 2005 6:04 AM >>>>>>>> To: ccamp@ops.ietf.org >>>>>>>> Subject: Two Drafts for Resilience of Control Plane >>>>>>>> >>>>>>>> >>>>>>>> Dear all, >>>>>>>> >>>>>>>> I posted two drafts for the resilience of control plane. >>>>>>>> One is for requirements of the resilience of control > > plane, > >>the >> >>>>>>>>other is for a protocol specification as a solution of that . >>>>>>>> These are now available at: >>>>>>>> >>>>>>>> >>>>>>> >>>>>>http://www.ietf.org/internet-drafts/draft-kim-ccamp-cpr-reqts-01.tx >>>>>> >>>>>>>t >>>>>>> >>>>>>> >>>>>>> >>>>http://www.ietf.org/internet-drafts/draft-kim-ccamp-accp-protocol-00. >>>> >>>>>txt >>>>> >>>>> >>>>>>>> I want your comments. >>>>>>>> >>>>>>>> Regards >>>>>>>> >>>>>>>> Young. >>>>>>>> >>>>>>>> ===================================> >> Young-Hwa Kim >>>>>>>> Principal Member / Ph.D >>>>>>>> BcN Research Division, ETRI >>>>>>>> Tel: +82-42-860-5819 >>>>>>>> Fax: +82-42-860-5440 >>>>>>>> e-mail: yhwkim@etri.re.kr >>>>>>>> ===================================> >> >>>>>>>> >>>>>>> >>>>>.or >>>>> >>>>> >>>>g&name=ccamp%40ops.ietf.org&fromemail=yhwkim@etri.re.kr&messageid=%3C >>>> >>>>>863 >>>>> >>>>> >>>>>>>>0a6db-0c31-49ab-a798-13b0dda04553@etri.re.kr%3E> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>__________________________________ >>>>>>>Yahoo! Mail - PC Magazine Editors' Choice 2005 >>>>>>>http://mail.yahoo.com >>>>>>> >>>>>>> >>>>>>>. >>>>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>>. >>>> >>> > > > > . > From owner-ccamp@ops.ietf.org Fri Oct 28 19:57:30 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVe6E-00032g-HC for ccamp-archive@megatron.ietf.org; Fri, 28 Oct 2005 19:57:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27921 for ; Fri, 28 Oct 2005 19:57:12 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVeJs-0001BA-BD for ccamp-archive@ietf.org; Fri, 28 Oct 2005 20:11:37 -0400 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EVe0t-000EDa-PJ for ccamp-data@psg.com; Fri, 28 Oct 2005 23:51:59 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [64.102.122.149] (helo=rtp-iport-2.cisco.com) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EVe0q-000ED9-DF for ccamp@ops.ietf.org; Fri, 28 Oct 2005 23:51:56 +0000 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 28 Oct 2005 19:51:46 -0400 X-IronPort-AV: i="3.97,265,1125892800"; d="scan'208"; a="74670701:sNHT28906936" Received: from [10.83.15.50] (rtp-tnadeau-vpn1.cisco.com [10.83.15.50]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with SMTP id j9SNpf24017770; Fri, 28 Oct 2005 19:51:42 -0400 (EDT) In-Reply-To: <4618.68.100.80.11.1130524889.squirrel@webmail.movaz.com> References: <626FC7C6A97381468FB872072AB5DDC83696FA@XCH-SW-42.sw.nos.boeing.com> <4618.68.100.80.11.1130524889.squirrel@webmail.movaz.com> Mime-Version: 1.0 (Apple Message framework v734) X-Priority: 3 Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed Message-Id: <3164AFEA-F073-48EB-852C-E256C211BF47@cisco.com> Cc: Drake@movaz.com, John E , "Dimitri.Papadimitriou" , Igor Bryskin , Zafar Ali , Kim Young Hwa , ccamp@ops.ietf.org Content-Transfer-Encoding: quoted-printable From: "Thomas D. Nadeau" Subject: Re: Two Drafts for Resilience of Control Plane Date: Fri, 28 Oct 2005 19:51:40 -0400 To: dpapadimitriou@psg.com, "Dimitri.Papadimitriou" X-Mailer: Apple Mail (2.734) Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 83e9494d829b08cc3f644ef6ac1b9bd4 Content-Transfer-Encoding: quoted-printable Just like with 'classic' MPLS, with GMPLS I think you have a situation where the data and control planes could be out of sync., or at least out of contact with each other for a period of time. This is certainly not a fabricated problem, but a matter of 'how often' and 'how bad' when it happens (i.e.: is the IP control plane sufficiently resilient) As Zafar said earlier, there are already some mechanisms in place to handle this. Some folks (vendors only) have said they are sufficient. To me, this should be a question that operator types should be answering. --Tom > Hi, > > Here is one of the problems that I=92ve been thinking for a while =96 =20= > control > plane partitioned LSPs. Suppose one or more signaling controllers =20 > managing > some LSP went out of service leaving the LSP=92s data plane intact. =20= > As far > as the user is concerned such LSP is perfectly healthy and =20 > operational. > Such situation could last for a considerable period of time. Do we =20 > need to > manage such LSP via control plane? Sure, we must be capable to tear =20= > down > such LSP, perform mb4b rerouting, distribute alarms between =20 > operational > controllers, signal data plane faults and perform recovery switchover, > modify LSP status, etc. Can we do this today? No, but with some > (signaling) extensions the problem I believe is solvable. Is this some > artificial, =93fabricated=94 problem? No, I think it is real. Does it = fall > under the control plane resilience problem space? I believe it does. > > Igor > > > >> I agree with Zafar and Dimitri. If someone wanted to document the =20= >> GMPLS >> control plane resiliency features, as was done for GMPLS addressing, >> that might be a useful activity. >> >> >> >>> -----Original Message----- >>> From: dimitri papadimitriou [mailto:dpapadimitriou@psg.com] >>> Sent: Friday, October 28, 2005 9:56 AM >>> To: Igor Bryskin >>> Cc: Zafar Ali (zali); Kim Young Hwa; ccamp@ops.ietf.org >>> Subject: Re: Two Drafts for Resilience of Control Plane >>> >>> igor - >>> >>> over time CCAMP came with a set of mechanims to improve control =20 >>> plane >>> resilience (RSVP and LMP GR upon channel/node failure) other WG >>> >>> >> protocol >> >> >>> work are also usable used here OSPF GR, etc. ... on the other side, >>> mechanism such as link bundling have built-in resilience =20 >>> capabilities >>> and most GMPLS control plane capabilities have been designed such as >>> >>> >> to >> >> >>> be independent of the control plane realisation (in-band, out-of-=20 >>> band, >>> etc.) >>> >>> so indeed i share the concern of Zafar what could we do more here =20= >>> than >>> document these tools and provide our experience in using them; >>> >>> now, before stating there are (potential) problems(s) arising - =20 >>> would >>> you please be more specific on what are these potential issue(s) >>> >>> >> and/or >> >> >>> problems ? (not related to policy/config. - note: all the issues you >>> have pointed here below are simply policy/config specific but =20 >>> none of >>> them highlights a missing IP control plane resiliency feature) >>> >>> thanks, >>> - dimitri. >>> >>> >>> Igor Bryskin wrote: >>> >>> >>> >>>> Zafar, >>>> >>>> The problem arises when the control plane is decoupled >>>> from the data plane. The question is do we need such >>>> decoupling in IP networks? Consider, for example, the >>>> situation when several parallel PSC data links bundled >>>> together and controlled by a single control channel. >>>> Does it mean in this case that when the control >>>> channel fails all associated data links also fail? Do >>>> we need to reroute in this case LSPs that use the data >>>> links? Can we rely in this case on control plane >>>> indications to decide whether an associated data link >>>> is healthy or not (in other words, can we rely on RSVP >>>> Hellos or should we use, for example, BTD)? Should we >>>> be capable to recover control channels without >>>> disturbing data plane? I think control plane >>>> resilience is important for all layers. You are right, >>>> Internet does work, however, we do need for some >>>> reason TE and (fast) recovery in IP as much as in >>>> other layers,don't we? >>>> >>>> Cheers, >>>> Igor >>>> >>>> --- "Zafar Ali (zali)" wrote: >>>> >>>> >>>> >>>> >>>>> Hi All, >>>>> >>>>> I am unable to understand the problem we are trying >>>>> to solve or >>>>> fabricate. My control network is IP based and IP has >>>>> proven resiliency >>>>> (Internet *does* work), why would I like to take >>>>> control plan resiliency >>>>> problem at a layer *above-IP* and complicate my >>>>> life. Did I miss >>>>> something? >>>>> >>>>> Thanks >>>>> >>>>> Regards... Zafar >>>>> >>>>> >>>>> ________________________________ >>>>> >>>>> From: owner-ccamp@ops.ietf.org >>>>> [mailto:owner-ccamp@ops.ietf.org] >>>>> On Behalf Of Kim Young Hwa >>>>> Sent: Friday, October 28, 2005 6:04 AM >>>>> To: ccamp@ops.ietf.org >>>>> Subject: Two Drafts for Resilience of Control Plane >>>>> >>>>> >>>>> Dear all, >>>>> >>>>> I posted two drafts for the resilience of control >>>>> plane. >>>>> One is for requirements of the resilience of >>>>> control plane, the >>>>> other is for a protocol specification as a solution >>>>> of that . >>>>> These are now available at: >>>>> >>>>> >>>>> >>>>> >>>> >>>> http://www.ietf.org/internet-drafts/draft-kim-ccamp-cpr-=20 >>>> reqts-01.txt >>>> >>>> >>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>>> >> http://www.ietf.org/internet-drafts/draft-kim-ccamp-accp-=20 >> protocol-00.txt >> >> >>>> >>>> >>>> >>>>> >>>>> I want your comments. >>>>> >>>>> Regards >>>>> >>>>> Young. >>>>> >>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D> >> Young-Hwa Kim >>>>> Principal Member / Ph.D >>>>> BcN Research Division, ETRI >>>>> Tel: +82-42-860-5819 >>>>> Fax: +82-42-860-5440 >>>>> e-mail: yhwkim@etri.re.kr >>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D> >> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>>> >> > email=3Dccamp@ops.ietf.or >> >> >>>> >>>> >>>> >>>> >> g&name=3Dccamp%40ops.ietf.org&fromemail=3Dyhwkim@etri.re.kr&messageid=3D= %=20 >> 3C863 >> >> >>>> >>>> >>>> >>>>> 0a6db-0c31-49ab-a798-13b0dda04553@etri.re.kr%3E> >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> __________________________________ >>>> Yahoo! Mail - PC Magazine Editors' Choice 2005 >>>> http://mail.yahoo.com >>>> >>>> >>>> . >>>> >>>> >>>> >> >> >> >> > > From owner-ccamp@ops.ietf.org Fri Oct 28 20:12:48 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVeL2-0001v4-1q for ccamp-archive@megatron.ietf.org; Fri, 28 Oct 2005 20:12:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28498 for ; Fri, 28 Oct 2005 20:12:30 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVeYh-0001Wc-5r for ccamp-archive@ietf.org; Fri, 28 Oct 2005 20:26:55 -0400 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EVeGa-000FfM-4E for ccamp-data@psg.com; Sat, 29 Oct 2005 00:08:12 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [171.68.10.87] (helo=sj-iport-5.cisco.com) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EVeGY-000Ff9-8e for ccamp@ops.ietf.org; Sat, 29 Oct 2005 00:08:10 +0000 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 28 Oct 2005 17:08:03 -0700 X-IronPort-AV: i="3.97,265,1125903600"; d="scan'208"; a="225121530:sNHT30648360" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j9T07vUw025563; Fri, 28 Oct 2005 17:07:57 -0700 (PDT) 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); Fri, 28 Oct 2005 20:07:57 -0400 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: Two Drafts for Resilience of Control Plane Date: Fri, 28 Oct 2005 20:07:55 -0400 Message-ID: Thread-Topic: Two Drafts for Resilience of Control Plane Thread-Index: AcXb+5sI7DBursUUSnCMr5SUjjw6QQAAZ19AAADmq6AABtIYwA== From: "Zafar Ali \(zali\)" To: "Drake, John E" , "Ong, Lyndon" , , , Cc: , , "Igor Bryskin" , "Kim Young Hwa" , X-OriginalArrivalTime: 29 Oct 2005 00:07:57.0174 (UTC) FILETIME=[D0E43960:01C5DC1C] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a2f5df4c6f30e0d5df43748fb095119 Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: Drake, John E [mailto:John.E.Drake2@boeing.com]=20 > Sent: Friday, October 28, 2005 4:52 PM > To: Ong, Lyndon; ibryskin@movaz.com; dpapadimitriou@psg.com;=20 > dimitri.papadimitriou@alcatel.be > Cc: Drake@movaz.com; dimitri.papadimitriou@alcatel.be; Igor=20 > Bryskin; Zafar Ali (zali); Kim Young Hwa; ccamp@ops.ietf.org > Subject: RE: Two Drafts for Resilience of Control Plane >=20 >=20 >=20 > > -----Original Message----- > > From: Ong, Lyndon [mailto:Lyong@Ciena.com] > > Sent: Friday, October 28, 2005 1:28 PM > > To: ibryskin@movaz.com; dpapadimitriou@psg.com;=20 > > dimitri.papadimitriou@alcatel.be > > Cc: Drake@movaz.com; Drake, John E;=20 > dimitri.papadimitriou@alcatel.be; > Igor > > Bryskin; Zafar Ali; Kim Young Hwa; ccamp@ops.ietf.org > > Subject: RE: Two Drafts for Resilience of Control Plane > >=20 > > Hi Igor, > >=20 > > Are you referring to controlling the LSP while one of the=20 > controllers > is > > still down? That would mean that no restart has yet taken place. > >=20 > > The draft seems to be focused on providing standby control channels, > [JD]=20 >=20 > What is the utility of having standby control channels, as=20 > opposed to just having multiple *active* control channels? >=20 There is no advantage, but there are numerous disadvantages. Having multiple *active* control channels is what I was referring to as let IP layer provide the resilience for Control Plane. In fact there are disadvantages of having active and standby control channel and some other entity have to manage them. Now you have to worry about signaling and control channels to be in-sync, fast switchover, etc.=20 My motivation is to keep is simple, but yet superior.=20 Thanks Regards... Zafar=20 > > what > > you're suggesting sounds more like a standby signaling controller. > [JD]=20 >=20 > A standby signaling controller is an implementation option=20 > that shouldn't affect the existing GMPLS protocols >=20 > >=20 > > Cheers, > >=20 > > Lyndon > >=20 > > -----Original Message----- > > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On=20 > > Behalf Of ibryskin@movaz.com > > Sent: Friday, October 28, 2005 1:08 PM > > To: dpapadimitriou@psg.com; dimitri.papadimitriou@alcatel.be > > Cc: ibryskin@movaz.com; Drake@movaz.com; John E;=20 > > dimitri.papadimitriou@alcatel.be; Igor Bryskin; Zafar Ali;=20 > Kim Young=20 > > Hwa; ccamp@ops.ietf.org > > Subject: Re: Two Drafts for Resilience of Control Plane > >=20 > > Dimitri, > > See in-line. > > > igor - > > > > > > you are already going beyond the specific discussion context > > > > > > 1. what is a control plane partitioned LSP ? > >=20 > > LSPs with one or more controllers down, so there is/are=20 > partitions in=20 > > hop-by-hop signaling > > > > > > 2. when you state "Suppose one or more signaling controllers > managing > > > some LSP went out of service leaving the LSP's data plane > intact." > > > > > > what does it mean "one or more controllers" ? what if you > support > > > RSVP GR ? why are you not able to recover the states ? etc. > >=20 > > See my response to John. There are no restarts in my example > >=20 > > > > > > hence, i still miss the exact problem wrt to the control plane=20 > > > protocol resilience > > > > > > but i think there is another issue (which is even more=20 > important) -=20 > > > the resilience mechanisms of the control plane that we have today > have > >=20 > > > been provided based on experience from the common use of=20 > the control=20 > > > plane and for being resilient wrt common failures - but=20 > not for ALL=20 > > > use of the control plane in ANY condition and for ALL possible=20 > > > failures - indeed what you are asking here is like what=20 > shall i do=20 > > > when the CP is completely down and the DP still up; it would > surprise > > > me that the CP would be of any help in this specific condition > >=20 > > Believe me, CP could be still of a great help in such=20 > conditions. You=20 > > need some signaling extensions - which is why I think CP=20 > resilience is=20 > > an important topic within CCAMP - and then you can manage LSPs with=20 > > control plane gaps at least to the extend I described. > >=20 > > Igor > >=20 > > > > > > thanks, > > > - dimitri. > > > > > > ibryskin@movaz.com wrote: > > > > > >> Hi, > > >> > > >> Here is one of the problems that I've been thinking for=20 > a while -=20 > > >> control plane partitioned LSPs. Suppose one or more signaling=20 > > >> controllers managing some LSP went out of service=20 > leaving the LSP's=20 > > >> data plane intact. As far as the user is concerned such LSP is=20 > > >> perfectly healthy and operational. > > >> Such situation could last for a considerable period of=20 > time. Do we=20 > > >> need to manage such LSP via control plane? Sure, we must=20 > be capable=20 > > >> to tear down such LSP, perform mb4b rerouting, distribute alarms=20 > > >> between operational controllers, signal data plane faults and > perform > >=20 > > >> recovery switchover, modify LSP status, etc. Can we do=20 > this today? > > >> No, but with some > > >> (signaling) extensions the problem I believe is=20 > solvable. Is this=20 > > >> some artificial, "fabricated" problem? No, I think it is=20 > real. Does=20 > > >> it fall under the control plane resilience problem=20 > space? I believe > > it does. > > >> > > >> Igor > > >> > > >> > > >>>I agree with Zafar and Dimitri. If someone wanted to=20 > document the=20 > > >>>GMPLS control plane resiliency features, as was done for GMPLS=20 > > >>>addressing, that might be a useful activity. > > >>> > > >>> > > >>>>-----Original Message----- > > >>>>From: dimitri papadimitriou [mailto:dpapadimitriou@psg.com] > > >>>>Sent: Friday, October 28, 2005 9:56 AM > > >>>>To: Igor Bryskin > > >>>>Cc: Zafar Ali (zali); Kim Young Hwa; ccamp@ops.ietf.org > > >>>>Subject: Re: Two Drafts for Resilience of Control Plane > > >>>> > > >>>>igor - > > >>>> > > >>>>over time CCAMP came with a set of mechanims to improve control=20 > > >>>>plane resilience (RSVP and LMP GR upon channel/node=20 > failure) other=20 > > >>>>WG > > >>> > > >>>protocol > > >>> > > >>>>work are also usable used here OSPF GR, etc. ... on the other > side, > > >>>>mechanism such as link bundling have built-in resilience=20 > > >>>>capabilities and most GMPLS control plane capabilities=20 > have been=20 > > >>>>designed such as > > >>> > > >>>to > > >>> > > >>>>be independent of the control plane realisation (in-band,=20 > > >>>>out-of-band, > > >>>>etc.) > > >>>> > > >>>>so indeed i share the concern of Zafar what could we do=20 > more here=20 > > >>>>than document these tools and provide our experience in using > them; > > >>>> > > >>>>now, before stating there are (potential) problems(s) arising -=20 > > >>>>would you please be more specific on what are these potential > > >>>>issue(s) > > >>> > > >>>and/or > > >>> > > >>>>problems ? (not related to policy/config. - note: all the issues > you > >=20 > > >>>>have pointed here below are simply policy/config=20 > specific but none=20 > > >>>>of them highlights a missing IP control plane=20 > resiliency feature) > > >>>> > > >>>>thanks, > > >>>>- dimitri. > > >>>> > > >>>> > > >>>>Igor Bryskin wrote: > > >>>> > > >>>> > > >>>>>Zafar, > > >>>>> > > >>>>>The problem arises when the control plane is decoupled=20 > from the=20 > > >>>>>data plane. The question is do we need such decoupling in IP=20 > > >>>>>networks? Consider, for example, the situation when several=20 > > >>>>>parallel PSC data links bundled together and controlled by a > single > >=20 > > >>>>>control channel. > > >>>>>Does it mean in this case that when the control=20 > channel fails all=20 > > >>>>>associated data links also fail? Do we need to reroute in this > case > >=20 > > >>>>>LSPs that use the data links? Can we rely in this case=20 > on control=20 > > >>>>>plane indications to decide whether an associated data link is=20 > > >>>>>healthy or not (in other words, can we rely on RSVP Hellos or=20 > > >>>>>should we use, for example, BTD)? Should we be capable=20 > to recover=20 > > >>>>>control channels without disturbing data plane? I=20 > think control=20 > > >>>>>plane resilience is important for all layers. You are right,=20 > > >>>>>Internet does work, however, we do need for some reason TE and > > >>>>>(fast) recovery in IP as much as in other layers,don't we? > > >>>>> > > >>>>>Cheers, > > >>>>>Igor > > >>>>> > > >>>>>--- "Zafar Ali (zali)" wrote: > > >>>>> > > >>>>> > > >>>>> > > >>>>>>Hi All, > > >>>>>> > > >>>>>>I am unable to understand the problem we are trying=20 > to solve or=20 > > >>>>>>fabricate. My control network is IP based and IP has proven=20 > > >>>>>>resiliency (Internet *does* work), why would I like to take=20 > > >>>>>>control plan resiliency problem at a layer *above-IP* and=20 > > >>>>>>complicate my life. Did I miss something? > > >>>>>> > > >>>>>>Thanks > > >>>>>> > > >>>>>>Regards... Zafar > > >>>>>> > > >>>>>> > > >>>>>>________________________________ > > >>>>>> > > >>>>>> From: owner-ccamp@ops.ietf.org > > >>>>>>[mailto:owner-ccamp@ops.ietf.org] > > >>>>>>On Behalf Of Kim Young Hwa > > >>>>>> Sent: Friday, October 28, 2005 6:04 AM > > >>>>>> To: ccamp@ops.ietf.org > > >>>>>> Subject: Two Drafts for Resilience of Control Plane > > >>>>>> > > >>>>>> > > >>>>>> Dear all, > > >>>>>> > > >>>>>> I posted two drafts for the resilience of control plane. > > >>>>>> One is for requirements of the resilience of control > plane, > > the > > >>>>>>other is for a protocol specification as a solution of that . > > >>>>>> These are now available at: > > >>>>>> > > >>>>>> > > >>>>> > > > >>>>>http://www.ietf.org/internet-drafts/draft-kim-ccamp-cpr-r > eqts-01.tx > > >>>>>t > > >>>>> > > >>>>> > > >>>>>> > > >>>>> > > > >>>http://www.ietf.org/internet-drafts/draft-kim-ccamp-accp-pr > otocol-00. > > >>>txt > > >>> > > >>>>>> I want your comments. > > >>>>>> > > >>>>>> Regards > > >>>>>> > > >>>>>> Young. > > >>>>>> > > >>>>>> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D> >> Young-Hwa Kim > > >>>>>> Principal Member / Ph.D > > >>>>>> BcN Research Division, ETRI > > >>>>>> Tel: +82-42-860-5819 > > >>>>>> Fax: +82-42-860-5440 > > >>>>>> e-mail: yhwkim@etri.re.kr > > >>>>>> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D> >> > > >>>>>> > > >>>>> > > > >>> p@ops.ietf > > >>>.or > > >>> > > >>>>> > > > >>>g&name=3Dccamp%40ops.ietf.org&fromemail=3Dyhwkim@etri.re.kr&mes > sageid=3D%3C > > >>>863 > > >>> > > >>>>>>0a6db-0c31-49ab-a798-13b0dda04553@etri.re.kr%3E> > > >>>>>> > > >>>>>> > > >>>>> > > >>>>> > > >>>>> > > >>>>> > > >>>>> > > >>>>>__________________________________ > > >>>>>Yahoo! Mail - PC Magazine Editors' Choice 2005=20 > > >>>>>http://mail.yahoo.com > > >>>>> > > >>>>> > > >>>>>. > > >>>>> > > >>> > > >>> > > >>> > > >> > > >> > > >> > > >> . > > >> > > > > >=20 >=20 From owner-ccamp@ops.ietf.org Fri Oct 28 20:15:29 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVeNd-0003HI-7D for ccamp-archive@megatron.ietf.org; Fri, 28 Oct 2005 20:15:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28576 for ; Fri, 28 Oct 2005 20:15:11 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVebB-0001ZE-SK for ccamp-archive@ietf.org; Fri, 28 Oct 2005 20:29:37 -0400 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EVeJo-000Fs1-Dj for ccamp-data@psg.com; Sat, 29 Oct 2005 00:11:32 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [130.76.64.48] (helo=slb-smtpout-01.boeing.com) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EVeJl-000Frc-L5; Sat, 29 Oct 2005 00:11:29 +0000 Received: from slb-av-01.boeing.com ([129.172.13.4]) by slb-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id RAA09143; Fri, 28 Oct 2005 17:11:23 -0700 (PDT) Received: from XCH-SWBH-04.sw.nos.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id j9T0BNd08915; Fri, 28 Oct 2005 17:11:23 -0700 (PDT) Received: from XCH-SW-42.sw.nos.boeing.com ([192.79.11.43]) by XCH-SWBH-04.sw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 28 Oct 2005 17:11:23 -0700 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: Two Drafts for Resilience of Control Plane Date: Fri, 28 Oct 2005 17:11:22 -0700 Message-ID: <626FC7C6A97381468FB872072AB5DDC836970A@XCH-SW-42.sw.nos.boeing.com> Thread-Topic: Two Drafts for Resilience of Control Plane Thread-Index: AcXb+5sI7DBursUUSnCMr5SUjjw6QQAAZ19AAADmq6AABtIYwAAANgdA From: "Drake, John E" To: "Zafar Ali \(zali\)" , "Ong, Lyndon" , , , Cc: , , "Igor Bryskin" , "Kim Young Hwa" , X-OriginalArrivalTime: 29 Oct 2005 00:11:23.0121 (UTC) FILETIME=[4BA53E10:01C5DC1D] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: e9d8c60d9288f2c774f26bab15869505 Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: Zafar Ali (zali) [mailto:zali@cisco.com] > Sent: Friday, October 28, 2005 5:08 PM > To: Drake, John E; Ong, Lyndon; ibryskin@movaz.com; > dpapadimitriou@psg.com; dimitri.papadimitriou@alcatel.be > Cc: Drake@movaz.com; dimitri.papadimitriou@alcatel.be; Igor Bryskin; Kim > Young Hwa; ccamp@ops.ietf.org > Subject: RE: Two Drafts for Resilience of Control Plane >=20 > > -----Original Message----- > > From: Drake, John E [mailto:John.E.Drake2@boeing.com] > > Sent: Friday, October 28, 2005 4:52 PM > > To: Ong, Lyndon; ibryskin@movaz.com; dpapadimitriou@psg.com; > > dimitri.papadimitriou@alcatel.be > > Cc: Drake@movaz.com; dimitri.papadimitriou@alcatel.be; Igor > > Bryskin; Zafar Ali (zali); Kim Young Hwa; ccamp@ops.ietf.org > > Subject: RE: Two Drafts for Resilience of Control Plane > > > > > > > > > -----Original Message----- > > > From: Ong, Lyndon [mailto:Lyong@Ciena.com] > > > Sent: Friday, October 28, 2005 1:28 PM > > > To: ibryskin@movaz.com; dpapadimitriou@psg.com; > > > dimitri.papadimitriou@alcatel.be > > > Cc: Drake@movaz.com; Drake, John E; > > dimitri.papadimitriou@alcatel.be; > > Igor > > > Bryskin; Zafar Ali; Kim Young Hwa; ccamp@ops.ietf.org > > > Subject: RE: Two Drafts for Resilience of Control Plane > > > > > > Hi Igor, > > > > > > Are you referring to controlling the LSP while one of the > > controllers > > is > > > still down? That would mean that no restart has yet taken place. > > > > > > The draft seems to be focused on providing standby control channels, > > [JD] > > > > What is the utility of having standby control channels, as > > opposed to just having multiple *active* control channels? > > >=20 > There is no advantage, but there are numerous disadvantages. Having > multiple *active* control channels is what I was referring to as let IP > layer provide the resilience for Control Plane. In fact there are > disadvantages of having active and standby control channel and some > other entity have to manage them. Now you have to worry about signaling > and control channels to be in-sync, fast switchover, etc. >=20 > My motivation is to keep is simple, but yet superior. [JD]=20 Years ago, when we first started on LMP, we had the notion of active and standby control channels and it was George Swallow that pointed out that this was a really *BadIdea*tm. Thanks, John >=20 > Thanks >=20 > Regards... Zafar >=20 >=20 > > > what > > > you're suggesting sounds more like a standby signaling controller. > > [JD] > > > > A standby signaling controller is an implementation option > > that shouldn't affect the existing GMPLS protocols > > > > > > > > Cheers, > > > > > > Lyndon > > > > > > -----Original Message----- > > > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On > > > Behalf Of ibryskin@movaz.com > > > Sent: Friday, October 28, 2005 1:08 PM > > > To: dpapadimitriou@psg.com; dimitri.papadimitriou@alcatel.be > > > Cc: ibryskin@movaz.com; Drake@movaz.com; John E; > > > dimitri.papadimitriou@alcatel.be; Igor Bryskin; Zafar Ali; > > Kim Young > > > Hwa; ccamp@ops.ietf.org > > > Subject: Re: Two Drafts for Resilience of Control Plane > > > > > > Dimitri, > > > See in-line. > > > > igor - > > > > > > > > you are already going beyond the specific discussion context > > > > > > > > 1. what is a control plane partitioned LSP ? > > > > > > LSPs with one or more controllers down, so there is/are > > partitions in > > > hop-by-hop signaling > > > > > > > > 2. when you state "Suppose one or more signaling controllers > > managing > > > > some LSP went out of service leaving the LSP's data plane > > intact." > > > > > > > > what does it mean "one or more controllers" ? what if you > > support > > > > RSVP GR ? why are you not able to recover the states ? etc. > > > > > > See my response to John. There are no restarts in my example > > > > > > > > > > > hence, i still miss the exact problem wrt to the control plane > > > > protocol resilience > > > > > > > > but i think there is another issue (which is even more > > important) - > > > > the resilience mechanisms of the control plane that we have today > > have > > > > > > > been provided based on experience from the common use of > > the control > > > > plane and for being resilient wrt common failures - but > > not for ALL > > > > use of the control plane in ANY condition and for ALL possible > > > > failures - indeed what you are asking here is like what > > shall i do > > > > when the CP is completely down and the DP still up; it would > > surprise > > > > me that the CP would be of any help in this specific condition > > > > > > Believe me, CP could be still of a great help in such > > conditions. You > > > need some signaling extensions - which is why I think CP > > resilience is > > > an important topic within CCAMP - and then you can manage LSPs with > > > control plane gaps at least to the extend I described. > > > > > > Igor > > > > > > > > > > > thanks, > > > > - dimitri. > > > > > > > > ibryskin@movaz.com wrote: > > > > > > > >> Hi, > > > >> > > > >> Here is one of the problems that I've been thinking for > > a while - > > > >> control plane partitioned LSPs. Suppose one or more signaling > > > >> controllers managing some LSP went out of service > > leaving the LSP's > > > >> data plane intact. As far as the user is concerned such LSP is > > > >> perfectly healthy and operational. > > > >> Such situation could last for a considerable period of > > time. Do we > > > >> need to manage such LSP via control plane? Sure, we must > > be capable > > > >> to tear down such LSP, perform mb4b rerouting, distribute alarms > > > >> between operational controllers, signal data plane faults and > > perform > > > > > > >> recovery switchover, modify LSP status, etc. Can we do > > this today? > > > >> No, but with some > > > >> (signaling) extensions the problem I believe is > > solvable. Is this > > > >> some artificial, "fabricated" problem? No, I think it is > > real. Does > > > >> it fall under the control plane resilience problem > > space? I believe > > > it does. > > > >> > > > >> Igor > > > >> > > > >> > > > >>>I agree with Zafar and Dimitri. If someone wanted to > > document the > > > >>>GMPLS control plane resiliency features, as was done for GMPLS > > > >>>addressing, that might be a useful activity. > > > >>> > > > >>> > > > >>>>-----Original Message----- > > > >>>>From: dimitri papadimitriou [mailto:dpapadimitriou@psg.com] > > > >>>>Sent: Friday, October 28, 2005 9:56 AM > > > >>>>To: Igor Bryskin > > > >>>>Cc: Zafar Ali (zali); Kim Young Hwa; ccamp@ops.ietf.org > > > >>>>Subject: Re: Two Drafts for Resilience of Control Plane > > > >>>> > > > >>>>igor - > > > >>>> > > > >>>>over time CCAMP came with a set of mechanims to improve control > > > >>>>plane resilience (RSVP and LMP GR upon channel/node > > failure) other > > > >>>>WG > > > >>> > > > >>>protocol > > > >>> > > > >>>>work are also usable used here OSPF GR, etc. ... on the other > > side, > > > >>>>mechanism such as link bundling have built-in resilience > > > >>>>capabilities and most GMPLS control plane capabilities > > have been > > > >>>>designed such as > > > >>> > > > >>>to > > > >>> > > > >>>>be independent of the control plane realisation (in-band, > > > >>>>out-of-band, > > > >>>>etc.) > > > >>>> > > > >>>>so indeed i share the concern of Zafar what could we do > > more here > > > >>>>than document these tools and provide our experience in using > > them; > > > >>>> > > > >>>>now, before stating there are (potential) problems(s) arising - > > > >>>>would you please be more specific on what are these potential > > > >>>>issue(s) > > > >>> > > > >>>and/or > > > >>> > > > >>>>problems ? (not related to policy/config. - note: all the issues > > you > > > > > > >>>>have pointed here below are simply policy/config > > specific but none > > > >>>>of them highlights a missing IP control plane > > resiliency feature) > > > >>>> > > > >>>>thanks, > > > >>>>- dimitri. > > > >>>> > > > >>>> > > > >>>>Igor Bryskin wrote: > > > >>>> > > > >>>> > > > >>>>>Zafar, > > > >>>>> > > > >>>>>The problem arises when the control plane is decoupled > > from the > > > >>>>>data plane. The question is do we need such decoupling in IP > > > >>>>>networks? Consider, for example, the situation when several > > > >>>>>parallel PSC data links bundled together and controlled by a > > single > > > > > > >>>>>control channel. > > > >>>>>Does it mean in this case that when the control > > channel fails all > > > >>>>>associated data links also fail? Do we need to reroute in this > > case > > > > > > >>>>>LSPs that use the data links? Can we rely in this case > > on control > > > >>>>>plane indications to decide whether an associated data link is > > > >>>>>healthy or not (in other words, can we rely on RSVP Hellos or > > > >>>>>should we use, for example, BTD)? Should we be capable > > to recover > > > >>>>>control channels without disturbing data plane? I > > think control > > > >>>>>plane resilience is important for all layers. You are right, > > > >>>>>Internet does work, however, we do need for some reason TE and > > > >>>>>(fast) recovery in IP as much as in other layers,don't we? > > > >>>>> > > > >>>>>Cheers, > > > >>>>>Igor > > > >>>>> > > > >>>>>--- "Zafar Ali (zali)" wrote: > > > >>>>> > > > >>>>> > > > >>>>> > > > >>>>>>Hi All, > > > >>>>>> > > > >>>>>>I am unable to understand the problem we are trying > > to solve or > > > >>>>>>fabricate. My control network is IP based and IP has proven > > > >>>>>>resiliency (Internet *does* work), why would I like to take > > > >>>>>>control plan resiliency problem at a layer *above-IP* and > > > >>>>>>complicate my life. Did I miss something? > > > >>>>>> > > > >>>>>>Thanks > > > >>>>>> > > > >>>>>>Regards... Zafar > > > >>>>>> > > > >>>>>> > > > >>>>>>________________________________ > > > >>>>>> > > > >>>>>> From: owner-ccamp@ops.ietf.org > > > >>>>>>[mailto:owner-ccamp@ops.ietf.org] > > > >>>>>>On Behalf Of Kim Young Hwa > > > >>>>>> Sent: Friday, October 28, 2005 6:04 AM > > > >>>>>> To: ccamp@ops.ietf.org > > > >>>>>> Subject: Two Drafts for Resilience of Control Plane > > > >>>>>> > > > >>>>>> > > > >>>>>> Dear all, > > > >>>>>> > > > >>>>>> I posted two drafts for the resilience of control plane. > > > >>>>>> One is for requirements of the resilience of control > > plane, > > > the > > > >>>>>>other is for a protocol specification as a solution of that . > > > >>>>>> These are now available at: > > > >>>>>> > > > >>>>>> > > > >>>>> > > > > > >>>>>http://www.ietf.org/internet-drafts/draft-kim-ccamp-cpr-r > > eqts-01.tx > > > >>>>>t > > > >>>>> > > > >>>>> > > > >>>>>> > > > >>>>> > > > > > >>>http://www.ietf.org/internet-drafts/draft-kim-ccamp-accp-pr > > otocol-00. > > > >>>txt > > > >>> > > > >>>>>> I want your comments. > > > >>>>>> > > > >>>>>> Regards > > > >>>>>> > > > >>>>>> Young. > > > >>>>>> > > > >>>>>> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D> >> Young-Hwa Kim > > > >>>>>> Principal Member / Ph.D > > > >>>>>> BcN Research Division, ETRI > > > >>>>>> Tel: +82-42-860-5819 > > > >>>>>> Fax: +82-42-860-5440 > > > >>>>>> e-mail: yhwkim@etri.re.kr > > > >>>>>> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D> >> > > > >>>>>> > > > >>>>> > > > > > >>> > p@ops.ietf > > > >>>.or > > > >>> > > > >>>>> > > > > > >>>g&name=3Dccamp%40ops.ietf.org&fromemail=3Dyhwkim@etri.re.kr&mes > > sageid=3D%3C > > > >>>863 > > > >>> > > > >>>>>>0a6db-0c31-49ab-a798-13b0dda04553@etri.re.kr%3E> > > > >>>>>> > > > >>>>>> > > > >>>>> > > > >>>>> > > > >>>>> > > > >>>>> > > > >>>>> > > > >>>>>__________________________________ > > > >>>>>Yahoo! Mail - PC Magazine Editors' Choice 2005 > > > >>>>>http://mail.yahoo.com > > > >>>>> > > > >>>>> > > > >>>>>. > > > >>>>> > > > >>> > > > >>> > > > >>> > > > >> > > > >> > > > >> > > > >> . > > > >> > > > > > > > > > From owner-ccamp@ops.ietf.org Sat Oct 29 07:57:15 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVpKl-0008CT-Hy for ccamp-archive@megatron.ietf.org; Sat, 29 Oct 2005 07:57:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26839 for ; Sat, 29 Oct 2005 07:56:57 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVpYW-00017T-Do for ccamp-archive@ietf.org; Sat, 29 Oct 2005 08:11:29 -0400 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EVpC0-000Ps8-Sp for ccamp-data@psg.com; Sat, 29 Oct 2005 11:48:12 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [171.71.176.71] (helo=sj-iport-2.cisco.com) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EVpBz-000Prw-4Q for ccamp@ops.ietf.org; Sat, 29 Oct 2005 11:48:11 +0000 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-2.cisco.com with ESMTP; 29 Oct 2005 04:48:05 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j9TBlu7G009533; Sat, 29 Oct 2005 04:47:56 -0700 (PDT) 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); Sat, 29 Oct 2005 07:47:55 -0400 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: Two Drafts for Resilience of Control Plane Date: Sat, 29 Oct 2005 07:47:54 -0400 Message-ID: Thread-Topic: Two Drafts for Resilience of Control Plane Thread-Index: AcXb+5sI7DBursUUSnCMr5SUjjw6QQAAZ19AAADmq6AABtIYwAAANgdAABf9eCA= From: "Zafar Ali \(zali\)" To: "Drake, John E" , "Ong, Lyndon" , , , Cc: , , "Igor Bryskin" , "Kim Young Hwa" , X-OriginalArrivalTime: 29 Oct 2005 11:47:55.0891 (UTC) FILETIME=[9A13DC30:01C5DC7E] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e8a3b85ef670172081194f0b0f68e6f Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: Drake, John E [mailto:John.E.Drake2@boeing.com]=20 > Sent: Friday, October 28, 2005 8:11 PM > To: Zafar Ali (zali); Ong, Lyndon; ibryskin@movaz.com;=20 > dpapadimitriou@psg.com; dimitri.papadimitriou@alcatel.be > Cc: Drake@movaz.com; dimitri.papadimitriou@alcatel.be; Igor=20 > Bryskin; Kim Young Hwa; ccamp@ops.ietf.org > Subject: RE: Two Drafts for Resilience of Control Plane >=20 >=20 >=20 > > -----Original Message----- > > From: Zafar Ali (zali) [mailto:zali@cisco.com] > > Sent: Friday, October 28, 2005 5:08 PM > > To: Drake, John E; Ong, Lyndon; ibryskin@movaz.com;=20 > > dpapadimitriou@psg.com; dimitri.papadimitriou@alcatel.be > > Cc: Drake@movaz.com; dimitri.papadimitriou@alcatel.be; Igor Bryskin; > Kim > > Young Hwa; ccamp@ops.ietf.org > > Subject: RE: Two Drafts for Resilience of Control Plane > >=20 > > > -----Original Message----- > > > From: Drake, John E [mailto:John.E.Drake2@boeing.com] > > > Sent: Friday, October 28, 2005 4:52 PM > > > To: Ong, Lyndon; ibryskin@movaz.com; dpapadimitriou@psg.com;=20 > > > dimitri.papadimitriou@alcatel.be > > > Cc: Drake@movaz.com; dimitri.papadimitriou@alcatel.be;=20 > Igor Bryskin;=20 > > > Zafar Ali (zali); Kim Young Hwa; ccamp@ops.ietf.org > > > Subject: RE: Two Drafts for Resilience of Control Plane > > > > > > > > > > > > > -----Original Message----- > > > > From: Ong, Lyndon [mailto:Lyong@Ciena.com] > > > > Sent: Friday, October 28, 2005 1:28 PM > > > > To: ibryskin@movaz.com; dpapadimitriou@psg.com;=20 > > > > dimitri.papadimitriou@alcatel.be > > > > Cc: Drake@movaz.com; Drake, John E; > > > dimitri.papadimitriou@alcatel.be; > > > Igor > > > > Bryskin; Zafar Ali; Kim Young Hwa; ccamp@ops.ietf.org > > > > Subject: RE: Two Drafts for Resilience of Control Plane > > > > > > > > Hi Igor, > > > > > > > > Are you referring to controlling the LSP while one of the > > > controllers > > > is > > > > still down? That would mean that no restart has yet=20 > taken place. > > > > > > > > The draft seems to be focused on providing standby control > channels, > > > [JD] > > > > > > What is the utility of having standby control channels,=20 > as opposed=20 > > > to just having multiple *active* control channels? > > > > >=20 > > There is no advantage, but there are numerous disadvantages. Having=20 > > multiple *active* control channels is what I was referring to as let > IP > > layer provide the resilience for Control Plane. In fact there are=20 > > disadvantages of having active and standby control channel and some=20 > > other entity have to manage them. Now you have to worry about > signaling > > and control channels to be in-sync, fast switchover, etc. > >=20 > > My motivation is to keep is simple, but yet superior. > [JD]=20 >=20 > Years ago, when we first started on LMP, we had the notion of=20 > active and standby control channels and it was George Swallow=20 > that pointed out that this was a really *BadIdea*tm. >=20 Good news is that "we" are consistent :-) The bad news is that LMP newly born RFC still have this notion [no one listened to George :-( ]. Here are some reasons why "we" think this way:=20 - Redundancy/ HA via IP Layer.=20 - Taken a CC OOS is simple as putting an IF to the control network OOS, and other operational simplicities.=20 - OOS IF can be repair without impacting other links or LMP CC FSM.=20 - One LMP CC FSM per "N" Egress links to control network.=20 - LMP CC FSM is up as long as we have connectivity to the neighbor.=20 - No need to make special arrangements to make signaling and control channel consistent. I.e., both LMP and RSVP Hellos fail only when there is no IP connectivity to the neighbor.=20 - Etc.=20 Thanks Regards... Zafar=20 > Thanks, >=20 > John > >=20 > > Thanks > >=20 > > Regards... Zafar > >=20 > >=20 > > > > what > > > > you're suggesting sounds more like a standby signaling=20 > controller. > > > [JD] > > > > > > A standby signaling controller is an implementation option that=20 > > > shouldn't affect the existing GMPLS protocols > > > > > > > > > > > Cheers, > > > > > > > > Lyndon > > > > > > > > -----Original Message----- > > > > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] > On > > > > Behalf Of ibryskin@movaz.com > > > > Sent: Friday, October 28, 2005 1:08 PM > > > > To: dpapadimitriou@psg.com; dimitri.papadimitriou@alcatel.be > > > > Cc: ibryskin@movaz.com; Drake@movaz.com; John E;=20 > > > > dimitri.papadimitriou@alcatel.be; Igor Bryskin; Zafar Ali; > > > Kim Young > > > > Hwa; ccamp@ops.ietf.org > > > > Subject: Re: Two Drafts for Resilience of Control Plane > > > > > > > > Dimitri, > > > > See in-line. > > > > > igor - > > > > > > > > > > you are already going beyond the specific discussion context > > > > > > > > > > 1. what is a control plane partitioned LSP ? > > > > > > > > LSPs with one or more controllers down, so there is/are > > > partitions in > > > > hop-by-hop signaling > > > > > > > > > > 2. when you state "Suppose one or more signaling controllers > > > managing > > > > > some LSP went out of service leaving the LSP's data plane > > > intact." > > > > > > > > > > what does it mean "one or more controllers" ? what if you > > > support > > > > > RSVP GR ? why are you not able to recover the=20 > states ? etc. > > > > > > > > See my response to John. There are no restarts in my example > > > > > > > > > > > > > > hence, i still miss the exact problem wrt to the=20 > control plane=20 > > > > > protocol resilience > > > > > > > > > > but i think there is another issue (which is even more > > > important) - > > > > > the resilience mechanisms of the control plane that we have > today > > > have > > > > > > > > > been provided based on experience from the common use of > > > the control > > > > > plane and for being resilient wrt common failures - but > > > not for ALL > > > > > use of the control plane in ANY condition and for ALL=20 > possible=20 > > > > > failures - indeed what you are asking here is like what > > > shall i do > > > > > when the CP is completely down and the DP still up; it would > > > surprise > > > > > me that the CP would be of any help in this specific condition > > > > > > > > Believe me, CP could be still of a great help in such > > > conditions. You > > > > need some signaling extensions - which is why I think CP > > > resilience is > > > > an important topic within CCAMP - and then you can manage LSPs > with > > > > control plane gaps at least to the extend I described. > > > > > > > > Igor > > > > > > > > > > > > > > thanks, > > > > > - dimitri. > > > > > > > > > > ibryskin@movaz.com wrote: > > > > > > > > > >> Hi, > > > > >> > > > > >> Here is one of the problems that I've been thinking for > > > a while - > > > > >> control plane partitioned LSPs. Suppose one or more=20 > signaling=20 > > > > >> controllers managing some LSP went out of service > > > leaving the LSP's > > > > >> data plane intact. As far as the user is concerned=20 > such LSP is=20 > > > > >> perfectly healthy and operational. > > > > >> Such situation could last for a considerable period of > > > time. Do we > > > > >> need to manage such LSP via control plane? Sure, we must > > > be capable > > > > >> to tear down such LSP, perform mb4b rerouting, distribute > alarms > > > > >> between operational controllers, signal data plane faults and > > > perform > > > > > > > > >> recovery switchover, modify LSP status, etc. Can we do > > > this today? > > > > >> No, but with some > > > > >> (signaling) extensions the problem I believe is > > > solvable. Is this > > > > >> some artificial, "fabricated" problem? No, I think it is > > > real. Does > > > > >> it fall under the control plane resilience problem > > > space? I believe > > > > it does. > > > > >> > > > > >> Igor > > > > >> > > > > >> > > > > >>>I agree with Zafar and Dimitri. If someone wanted to > > > document the > > > > >>>GMPLS control plane resiliency features, as was done=20 > for GMPLS=20 > > > > >>>addressing, that might be a useful activity. > > > > >>> > > > > >>> > > > > >>>>-----Original Message----- > > > > >>>>From: dimitri papadimitriou [mailto:dpapadimitriou@psg.com] > > > > >>>>Sent: Friday, October 28, 2005 9:56 AM > > > > >>>>To: Igor Bryskin > > > > >>>>Cc: Zafar Ali (zali); Kim Young Hwa; ccamp@ops.ietf.org > > > > >>>>Subject: Re: Two Drafts for Resilience of Control Plane > > > > >>>> > > > > >>>>igor - > > > > >>>> > > > > >>>>over time CCAMP came with a set of mechanims to improve > control > > > > >>>>plane resilience (RSVP and LMP GR upon channel/node > > > failure) other > > > > >>>>WG > > > > >>> > > > > >>>protocol > > > > >>> > > > > >>>>work are also usable used here OSPF GR, etc. ... on=20 > the other > > > side, > > > > >>>>mechanism such as link bundling have built-in resilience=20 > > > > >>>>capabilities and most GMPLS control plane capabilities > > > have been > > > > >>>>designed such as > > > > >>> > > > > >>>to > > > > >>> > > > > >>>>be independent of the control plane realisation (in-band,=20 > > > > >>>>out-of-band, > > > > >>>>etc.) > > > > >>>> > > > > >>>>so indeed i share the concern of Zafar what could we do > > > more here > > > > >>>>than document these tools and provide our=20 > experience in using > > > them; > > > > >>>> > > > > >>>>now, before stating there are (potential)=20 > problems(s) arising > - > > > > >>>>would you please be more specific on what are these=20 > potential > > > > >>>>issue(s) > > > > >>> > > > > >>>and/or > > > > >>> > > > > >>>>problems ? (not related to policy/config. - note: all the > issues > > > you > > > > > > > > >>>>have pointed here below are simply policy/config > > > specific but none > > > > >>>>of them highlights a missing IP control plane > > > resiliency feature) > > > > >>>> > > > > >>>>thanks, > > > > >>>>- dimitri. > > > > >>>> > > > > >>>> > > > > >>>>Igor Bryskin wrote: > > > > >>>> > > > > >>>> > > > > >>>>>Zafar, > > > > >>>>> > > > > >>>>>The problem arises when the control plane is decoupled > > > from the > > > > >>>>>data plane. The question is do we need such=20 > decoupling in IP=20 > > > > >>>>>networks? Consider, for example, the situation=20 > when several=20 > > > > >>>>>parallel PSC data links bundled together and=20 > controlled by a > > > single > > > > > > > > >>>>>control channel. > > > > >>>>>Does it mean in this case that when the control > > > channel fails all > > > > >>>>>associated data links also fail? Do we need to reroute in > this > > > case > > > > > > > > >>>>>LSPs that use the data links? Can we rely in this case > > > on control > > > > >>>>>plane indications to decide whether an associated data link > is > > > > >>>>>healthy or not (in other words, can we rely on=20 > RSVP Hellos or=20 > > > > >>>>>should we use, for example, BTD)? Should we be capable > > > to recover > > > > >>>>>control channels without disturbing data plane? I > > > think control > > > > >>>>>plane resilience is important for all layers. You=20 > are right,=20 > > > > >>>>>Internet does work, however, we do need for some reason TE > and > > > > >>>>>(fast) recovery in IP as much as in other layers,don't we? > > > > >>>>> > > > > >>>>>Cheers, > > > > >>>>>Igor > > > > >>>>> > > > > >>>>>--- "Zafar Ali (zali)" wrote: > > > > >>>>> > > > > >>>>> > > > > >>>>> > > > > >>>>>>Hi All, > > > > >>>>>> > > > > >>>>>>I am unable to understand the problem we are trying > > > to solve or > > > > >>>>>>fabricate. My control network is IP based and IP=20 > has proven=20 > > > > >>>>>>resiliency (Internet *does* work), why would I=20 > like to take=20 > > > > >>>>>>control plan resiliency problem at a layer *above-IP* and=20 > > > > >>>>>>complicate my life. Did I miss something? > > > > >>>>>> > > > > >>>>>>Thanks > > > > >>>>>> > > > > >>>>>>Regards... Zafar > > > > >>>>>> > > > > >>>>>> > > > > >>>>>>________________________________ > > > > >>>>>> > > > > >>>>>> From: owner-ccamp@ops.ietf.org=20 > > > > >>>>>>[mailto:owner-ccamp@ops.ietf.org] > > > > >>>>>>On Behalf Of Kim Young Hwa > > > > >>>>>> Sent: Friday, October 28, 2005 6:04 AM > > > > >>>>>> To: ccamp@ops.ietf.org > > > > >>>>>> Subject: Two Drafts for Resilience of Control Plane > > > > >>>>>> > > > > >>>>>> > > > > >>>>>> Dear all, > > > > >>>>>> > > > > >>>>>> I posted two drafts for the resilience of control plane. > > > > >>>>>> One is for requirements of the resilience of control > > > plane, > > > > the > > > > >>>>>>other is for a protocol specification as a=20 > solution of that > . > > > > >>>>>> These are now available at: > > > > >>>>>> > > > > >>>>>> > > > > >>>>> > > > > > > > >>>>>http://www.ietf.org/internet-drafts/draft-kim-ccamp-cpr-r > > > eqts-01.tx > > > > >>>>>t > > > > >>>>> > > > > >>>>> > > > > >>>>>> > > > > >>>>> > > > > > > > >>>http://www.ietf.org/internet-drafts/draft-kim-ccamp-accp-pr > > > otocol-00. > > > > >>>txt > > > > >>> > > > > >>>>>> I want your comments. > > > > >>>>>> > > > > >>>>>> Regards > > > > >>>>>> > > > > >>>>>> Young. > > > > >>>>>> > > > > >>>>>> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D> >> Young-Hwa Kim > > > > >>>>>> Principal Member / Ph.D > > > > >>>>>> BcN Research Division, ETRI > > > > >>>>>> Tel: +82-42-860-5819 > > > > >>>>>> Fax: +82-42-860-5440 > > > > >>>>>> e-mail: yhwkim@etri.re.kr > > > > >>>>>> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D> >> > > > > >>>>>> > > > > >>>>> > > > > > > > >>> > > p@ops.ietf > > > > >>>.or > > > > >>> > > > > >>>>> > > > > > > > >>>g&name=3Dccamp%40ops.ietf.org&fromemail=3Dyhwkim@etri.re.kr&mes > > > sageid=3D%3C > > > > >>>863 > > > > >>> > > > > >>>>>>0a6db-0c31-49ab-a798-13b0dda04553@etri.re.kr%3E> > > > > >>>>>> > > > > >>>>>> > > > > >>>>> > > > > >>>>> > > > > >>>>> > > > > >>>>> > > > > >>>>> > > > > >>>>>__________________________________ > > > > >>>>>Yahoo! Mail - PC Magazine Editors' Choice 2005=20 > > > > >>>>>http://mail.yahoo.com > > > > >>>>> > > > > >>>>> > > > > >>>>>. > > > > >>>>> > > > > >>> > > > > >>> > > > > >>> > > > > >> > > > > >> > > > > >> > > > > >> . > > > > >> > > > > > > > > > > > > >=20 From owner-ccamp@ops.ietf.org Sat Oct 29 09:43:54 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVqzx-0007nl-Hw for ccamp-archive@megatron.ietf.org; Sat, 29 Oct 2005 09:43:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01325 for ; Sat, 29 Oct 2005 09:43:35 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVrDh-0003dn-Rb for ccamp-archive@ietf.org; Sat, 29 Oct 2005 09:58:08 -0400 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EVquG-0005GD-Pm for ccamp-data@psg.com; Sat, 29 Oct 2005 13:38:00 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=3.1.0 Received: from [70.158.43.219] (helo=jera.movaz.com) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EVquF-0005G2-IC for ccamp@ops.ietf.org; Sat, 29 Oct 2005 13:37:59 +0000 Received: by jera.movaz.com (Postfix, from userid 30) id 35B7268CC0; Sat, 29 Oct 2005 09:37:55 -0400 (EDT) Received: from 68.100.80.11 (SquirrelMail authenticated user ibryskin) by webmail.movaz.com with HTTP; Sat, 29 Oct 2005 09:37:55 -0400 (EDT) Message-ID: <3336.68.100.80.11.1130593075.squirrel@webmail.movaz.com> In-Reply-To: <626FC7C6A97381468FB872072AB5DDC8369701@XCH-SW-42.sw.nos.boeing.com> References: <626FC7C6A97381468FB872072AB5DDC8369701@XCH-SW-42.sw.nos.boeing.com> Date: Sat, 29 Oct 2005 09:37:55 -0400 (EDT) Subject: RE: Two Drafts for Resilience of Control Plane From: ibryskin@movaz.com To: "Drake, John E" Cc: ibryskin@movaz.com, dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be, "Igor Bryskin" , "Zafar Ali" , "Kim Young Hwa" , ccamp@ops.ietf.org User-Agent: SquirrelMail/1.4.1 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 Importance: Normal Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 1.2 (+) X-Scan-Signature: fcb459c204557d9509ce9c1b55d771f1 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id JAA01325 John, See in line. Igor > Igor, > > What you wrote was: > > "Suppose one or more signaling controllers managing some LSP went out o= f > service leaving the LSP's data plane intact. As far as the user is > concerned such LSP is perfectly healthy and operational. Such situatio= n > could last for a considerable period of time." > > What part of this is *not* handled by RSVP graceful restart? > > In your subsequent e-mail, you then changed the problem statement to: > > ""Dead" controllers in my example *do not* come back for a considerable > period of time. So there are no restarts here (graceful or not > graceful)" Sorry, I don=92t see how I have changed the problem statement. I was and = am saying that while controllers are out of service for a considerable time (day? two days? week?) the question is what to do with active LSPs associated with them? Let=92s consider an example: A----B------C-----D } | E-----F-----H-----K Suppose we have an LSP A-B-C-D carrying user traffic and a controller managing node B went out of service. The question is what to do with this LSP until the controller comes back? The operator may decide: a) simply not wait and delete the LSP. Normal LSP teardown =96 PathTear originated on the ingress controller- won=92t work because PathTear won=92= t make it to controllers managing nodes C and D, leaving (very expensive in the optical layer) resources associated with the LSP allocated and not available for other LSPs; b) reroute via mb4b the LSP onto alternative path A-E-H-K-D =96won=92t wo= rk for the same reason as in a) c) leave LSP as it is and wait for the dead controller to be replaced or repaired. This would mean the need to perform normal operations like, for example, monitoring of data plane alarms, changing LSP admin status (for example, disabling alarms on all nodes), perform power monitoring and equalization, perform recovery operation in case of a fatal data plane failure. All what depends on hop-by-hop signaling won=92t work today. Don=92t tell me that these problems are fabricated; they are real because they are raised by the customers. Dimitri seems to understand the problem but he is saying that the CP in this case is hardly of any use. This IMO is a dangerous statement for the future of CP in non-packet environments. The Management plane aficionados will jump on it and say that management plane does not have such a problem =96 NMS has a direct access to any NE = on the network, so it can do all necessary cleanup no matter what happened. Customers will say: =93Well, if there are situations when CP suddenly becomes useless and we have to use management plane anyway, why would we use the CP in the first place?=92 Fortunately, I believe that the problems could be solved entirely via CP by making it more resilient. Hence, CP resilience is a good direction to work on within CCAMP WG Igor > If "Considerable period of time" is not equal to infinity, then there > will be an RSVP graceful restart. If a controller is really and truly > dead, then presumably the operator will either replace it or re-assign > its data-plane resources to another signaling controller. In either > case, there will then be an RSVP graceful restart. > > Thanks, > > John > > > >> -----Original Message----- >> From: ibryskin@movaz.com [mailto:ibryskin@movaz.com] >> Sent: Friday, October 28, 2005 1:00 PM >> To: Drake, John E >> Cc: ibryskin@movaz.com; dpapadimitriou@psg.com; >> dimitri.papadimitriou@alcatel.be; Igor Bryskin; Zafar Ali; Kim Young > Hwa; >> ccamp@ops.ietf.org >> Subject: RE: Two Drafts for Resilience of Control Plane >> >> John, >> >> I think you missed my point here. "Dead" controllers in my example *do >> not* come back for a considerable period of time. So there are no > restarts >> here (graceful or not graceful) :=3D) >> >> Igor >> >> > What part of your problem, as stated below, is not handled by RSVP >> > graceful restart? >> > >> >> -----Original Message----- >> >> From: ibryskin@movaz.com [mailto:ibryskin@movaz.com] >> >> Sent: Friday, October 28, 2005 11:41 AM >> >> To: Drake, John E >> >> Cc: dpapadimitriou@psg.com; dimitri.papadimitriou@alcatel.be; Igor >> >> Bryskin; Zafar Ali; Kim Young Hwa; ccamp@ops.ietf.org >> >> Subject: RE: Two Drafts for Resilience of Control Plane >> >> >> >> Hi, >> >> >> >> Here is one of the problems that I've been thinking for a while - >> > control >> >> plane partitioned LSPs. Suppose one or more signaling controllers >> > managing >> >> some LSP went out of service leaving the LSP's data plane intact. > As >> > far >> >> as the user is concerned such LSP is perfectly healthy and >> > operational. >> >> Such situation could last for a considerable period of time. Do we >> > need to >> >> manage such LSP via control plane? Sure, we must be capable to tear >> > down >> >> such LSP, perform mb4b rerouting, distribute alarms between >> > operational >> >> controllers, signal data plane faults and perform recovery > switchover, >> >> modify LSP status, etc. Can we do this today? No, but with some >> >> (signaling) extensions the problem I believe is solvable. Is this > some >> >> artificial, "fabricated" problem? No, I think it is real. Does it > fall >> >> under the control plane resilience problem space? I believe it > does. >> >> >> >> Igor >> >> >> >> > I agree with Zafar and Dimitri. If someone wanted to document > the >> > GMPLS >> >> > control plane resiliency features, as was done for GMPLS > addressing, >> >> > that might be a useful activity. >> >> > >> >> >> -----Original Message----- >> >> >> From: dimitri papadimitriou [mailto:dpapadimitriou@psg.com] >> >> >> Sent: Friday, October 28, 2005 9:56 AM >> >> >> To: Igor Bryskin >> >> >> Cc: Zafar Ali (zali); Kim Young Hwa; ccamp@ops.ietf.org >> >> >> Subject: Re: Two Drafts for Resilience of Control Plane >> >> >> >> >> >> igor - >> >> >> >> >> >> over time CCAMP came with a set of mechanims to improve control >> > plane >> >> >> resilience (RSVP and LMP GR upon channel/node failure) other WG >> >> > protocol >> >> >> work are also usable used here OSPF GR, etc. ... on the other > side, >> >> >> mechanism such as link bundling have built-in resilience >> > capabilities >> >> >> and most GMPLS control plane capabilities have been designed > such >> > as >> >> > to >> >> >> be independent of the control plane realisation (in-band, >> > out-of-band, >> >> >> etc.) >> >> >> >> >> >> so indeed i share the concern of Zafar what could we do more > here >> > than >> >> >> document these tools and provide our experience in using them; >> >> >> >> >> >> now, before stating there are (potential) problems(s) arising - >> > would >> >> >> you please be more specific on what are these potential issue(s) >> >> > and/or >> >> >> problems ? (not related to policy/config. - note: all the issues >> > you >> >> >> have pointed here below are simply policy/config specific but > none >> > of >> >> >> them highlights a missing IP control plane resiliency feature) >> >> >> >> >> >> thanks, >> >> >> - dimitri. >> >> >> >> >> >> >> >> >> Igor Bryskin wrote: >> >> >> >> >> >> > Zafar, >> >> >> > >> >> >> > The problem arises when the control plane is decoupled >> >> >> > from the data plane. The question is do we need such >> >> >> > decoupling in IP networks? Consider, for example, the >> >> >> > situation when several parallel PSC data links bundled >> >> >> > together and controlled by a single control channel. >> >> >> > Does it mean in this case that when the control >> >> >> > channel fails all associated data links also fail? Do >> >> >> > we need to reroute in this case LSPs that use the data >> >> >> > links? Can we rely in this case on control plane >> >> >> > indications to decide whether an associated data link >> >> >> > is healthy or not (in other words, can we rely on RSVP >> >> >> > Hellos or should we use, for example, BTD)? Should we >> >> >> > be capable to recover control channels without >> >> >> > disturbing data plane? I think control plane >> >> >> > resilience is important for all layers. You are right, >> >> >> > Internet does work, however, we do need for some >> >> >> > reason TE and (fast) recovery in IP as much as in >> >> >> > other layers,don't we? >> >> >> > >> >> >> > Cheers, >> >> >> > Igor >> >> >> > >> >> >> > --- "Zafar Ali (zali)" wrote: >> >> >> > >> >> >> > >> >> >> >>Hi All, >> >> >> >> >> >> >> >>I am unable to understand the problem we are trying >> >> >> >>to solve or >> >> >> >>fabricate. My control network is IP based and IP has >> >> >> >>proven resiliency >> >> >> >>(Internet *does* work), why would I like to take >> >> >> >>control plan resiliency >> >> >> >>problem at a layer *above-IP* and complicate my >> >> >> >>life. Did I miss >> >> >> >>something? >> >> >> >> >> >> >> >>Thanks >> >> >> >> >> >> >> >>Regards... Zafar >> >> >> >> >> >> >> >> >> >> >> >>________________________________ >> >> >> >> >> >> >> >> From: owner-ccamp@ops.ietf.org >> >> >> >>[mailto:owner-ccamp@ops.ietf.org] >> >> >> >>On Behalf Of Kim Young Hwa >> >> >> >> Sent: Friday, October 28, 2005 6:04 AM >> >> >> >> To: ccamp@ops.ietf.org >> >> >> >> Subject: Two Drafts for Resilience of Control Plane >> >> >> >> >> >> >> >> >> >> >> >> Dear all, >> >> >> >> >> >> >> >> I posted two drafts for the resilience of control >> >> >> >>plane. >> >> >> >> One is for requirements of the resilience of >> >> >> >>control plane, the >> >> >> >>other is for a protocol specification as a solution >> >> >> >>of that . >> >> >> >> These are now available at: >> >> >> >> >> >> >> >> >> >> >> > >> >> >> > >> > http://www.ietf.org/internet-drafts/draft-kim-ccamp-cpr-reqts-01.txt >> >> >> > >> >> >> >> >> >> >> >> >> >> >> > >> >> >> > >> >> > >> > > http://www.ietf.org/internet-drafts/draft-kim-ccamp-accp-protocol-00.tx= t >> >> >> > >> >> >> >> >> >> >> >> I want your comments. >> >> >> >> >> >> >> >> Regards >> >> >> >> >> >> >> >> Young. >> >> >> >> >> >> >> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D> >> Young-Hwa Kim >> >> >> >> Principal Member / Ph.D >> >> >> >> BcN Research Division, ETRI >> >> >> >> Tel: +82-42-860-5819 >> >> >> >> Fax: +82-42-860-5440 >> >> >> >> e-mail: yhwkim@etri.re.kr >> >> >> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D> >> >> >> >> >> >> >> >> > >> >> >> > >> >> > >> > > > >> >> > >> >> >> > >> >> > >> > > g&name=3Dccamp%40ops.ietf.org&fromemail=3Dyhwkim@etri.re.kr&messageid=3D= %3C863 >> >> >> > >> >> >> >>0a6db-0c31-49ab-a798-13b0dda04553@etri.re.kr%3E> >> >> >> >> >> >> >> >> >> >> >> > >> >> >> > >> >> >> > >> >> >> > >> >> >> > >> >> >> > >> >> >> > __________________________________ >> >> >> > Yahoo! Mail - PC Magazine Editors' Choice 2005 >> >> >> > http://mail.yahoo.com >> >> >> > >> >> >> > >> >> >> > . >> >> >> > >> >> > >> >> > >> >> > >> > >> > > > From owner-ccamp@ops.ietf.org Sat Oct 29 10:00:06 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVrFd-0005uR-49 for ccamp-archive@megatron.ietf.org; Sat, 29 Oct 2005 10:00:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01986 for ; Sat, 29 Oct 2005 09:59:46 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVrTP-00041l-8g for ccamp-archive@ietf.org; Sat, 29 Oct 2005 10:14:20 -0400 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EVr9s-0005xc-4t for ccamp-data@psg.com; Sat, 29 Oct 2005 13:54:08 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [64.102.122.149] (helo=rtp-iport-2.cisco.com) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EVr9n-0005xN-Sk for ccamp@ops.ietf.org; Sat, 29 Oct 2005 13:54:06 +0000 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 29 Oct 2005 09:54:03 -0400 X-IronPort-AV: i="3.97,265,1125892800"; d="scan'208"; a="74704552:sNHT30839756" 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 j9TDrw23011816; Sat, 29 Oct 2005 09:53:59 -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); Sat, 29 Oct 2005 09:53:58 -0400 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: Two Drafts for Resilience of Control Plane Date: Sat, 29 Oct 2005 09:53:57 -0400 Message-ID: Thread-Topic: Two Drafts for Resilience of Control Plane Thread-Index: AcXcjf5z9+Ny5FLLSyKDj5WcLr/jtQAARsJA From: "Zafar Ali \(zali\)" To: , "Drake, John E" Cc: , , "Igor Bryskin" , "Kim Young Hwa" , X-OriginalArrivalTime: 29 Oct 2005 13:53:58.0730 (UTC) FILETIME=[35E182A0:01C5DC90] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 715d0e6950aaebd45af78ef9318d0186 Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: ibryskin@movaz.com [mailto:ibryskin@movaz.com]=20 > Sent: Saturday, October 29, 2005 9:38 AM > To: Drake, John E > Cc: ibryskin@movaz.com; dpapadimitriou@psg.com;=20 > dimitri.papadimitriou@alcatel.be; Igor Bryskin; Zafar Ali=20 > (zali); Kim Young Hwa; ccamp@ops.ietf.org > Subject: RE: Two Drafts for Resilience of Control Plane >=20 > John, >=20 > See in line. >=20 > Igor >=20 > > Igor, > > > > What you wrote was: > > > > "Suppose one or more signaling controllers managing some=20 > LSP went out=20 > > of service leaving the LSP's data plane intact. As far as=20 > the user is=20 > > concerned such LSP is perfectly healthy and operational. Such=20 > > situation could last for a considerable period of time." > > > > What part of this is *not* handled by RSVP graceful restart? > > > > In your subsequent e-mail, you then changed the problem=20 > statement to: > > > > ""Dead" controllers in my example *do not* come back for a=20 > > considerable period of time. So there are no restarts here=20 > (graceful=20 > > or not graceful)" >=20 > Sorry, I don't see how I have changed the problem statement.=20 > I was and am saying that while controllers are out of service=20 > for a considerable time (day? two days? week?) the question=20 > is what to do with active LSPs associated with them? Let's=20 > consider an example: >=20 >=20 > A----B------C-----D > } | > E-----F-----H-----K >=20 > Suppose we have an LSP A-B-C-D carrying user traffic and a=20 > controller managing node B went out of service. The question=20 > is what to do with this LSP until the controller comes back?=20 > The operator may decide: > a) simply not wait and delete the LSP. Normal LSP teardown=20 > - PathTear > originated on the ingress controller- won't work because=20 > PathTear won't make it to controllers managing nodes C and D,=20 > leaving (very expensive in the optical layer) resources=20 > associated with the LSP allocated and not available for other LSPs; > b) reroute via mb4b the LSP onto alternative path=20 > A-E-H-K-D -won't work > for the same reason as in a) > c) leave LSP as it is and wait for the dead controller to=20 > be replaced or > repaired. This would mean the need to perform normal=20 > operations like, for example, monitoring of data plane=20 > alarms, changing LSP admin status (for example, disabling=20 > alarms on all nodes), perform power monitoring and=20 > equalization, perform recovery operation in case of a fatal=20 > data plane failure. All what depends on hop-by-hop signaling=20 > won't work today. > Don't tell me that these problems are fabricated; they are=20 > real because they are raised by the customers. Dimitri seems=20 > to understand the problem but he is saying that the CP in=20 > this case is hardly of any use. This IMO is a dangerous=20 > statement for the future of CP in non-packet environments. > The Management plane aficionados will jump on it and say that=20 > management plane does not have such a problem - NMS has a=20 > direct access to any NE on the network, so it can do all=20 > necessary cleanup no matter what happened. > Customers will say: "Well, if there are situations when CP=20 > suddenly becomes useless and we have to use management plane=20 > anyway, why would we use the CP in the first place?' >=20 > Fortunately, I believe that the problems could be solved=20 > entirely via CP by making it more resilient. Hence, CP=20 > resilience is a good direction to work on within CCAMP WG Igor,=20 W.r.t. option C, please note that traffic CANNOT be forwarded in a "head-less mode" for a very long time . If you control network melts or a peering controller goes down, either RSVP GR or refreshes will take care of the clean-up of the affected RSVP states. Similarly LMP CC SM will go down (after states are cleared, i.e., degraded-to-down), eventually removing the TE links from topology. =20 Thanks Regards... Zafar=20 >=20 > Igor >=20 > > If "Considerable period of time" is not equal to infinity,=20 > then there=20 > > will be an RSVP graceful restart. If a controller is=20 > really and truly=20 > > dead, then presumably the operator will either replace it=20 > or re-assign=20 > > its data-plane resources to another signaling controller. =20 > In either=20 > > case, there will then be an RSVP graceful restart. > > > > Thanks, > > > > John > > > > > > > >> -----Original Message----- > >> From: ibryskin@movaz.com [mailto:ibryskin@movaz.com] > >> Sent: Friday, October 28, 2005 1:00 PM > >> To: Drake, John E > >> Cc: ibryskin@movaz.com; dpapadimitriou@psg.com;=20 > >> dimitri.papadimitriou@alcatel.be; Igor Bryskin; Zafar Ali;=20 > Kim Young > > Hwa; > >> ccamp@ops.ietf.org > >> Subject: RE: Two Drafts for Resilience of Control Plane > >> > >> John, > >> > >> I think you missed my point here. "Dead" controllers in my example=20 > >> *do > >> not* come back for a considerable period of time. So there are no > > restarts > >> here (graceful or not graceful) :=3D) > >> > >> Igor > >> > >> > What part of your problem, as stated below, is not=20 > handled by RSVP=20 > >> > graceful restart? > >> > > >> >> -----Original Message----- > >> >> From: ibryskin@movaz.com [mailto:ibryskin@movaz.com] > >> >> Sent: Friday, October 28, 2005 11:41 AM > >> >> To: Drake, John E > >> >> Cc: dpapadimitriou@psg.com;=20 > dimitri.papadimitriou@alcatel.be; Igor=20 > >> >> Bryskin; Zafar Ali; Kim Young Hwa; ccamp@ops.ietf.org > >> >> Subject: RE: Two Drafts for Resilience of Control Plane > >> >> > >> >> Hi, > >> >> > >> >> Here is one of the problems that I've been thinking for=20 > a while - > >> > control > >> >> plane partitioned LSPs. Suppose one or more signaling=20 > controllers > >> > managing > >> >> some LSP went out of service leaving the LSP's data=20 > plane intact. > > As > >> > far > >> >> as the user is concerned such LSP is perfectly healthy and > >> > operational. > >> >> Such situation could last for a considerable period of=20 > time. Do we > >> > need to > >> >> manage such LSP via control plane? Sure, we must be capable to=20 > >> >> tear > >> > down > >> >> such LSP, perform mb4b rerouting, distribute alarms between > >> > operational > >> >> controllers, signal data plane faults and perform recovery > > switchover, > >> >> modify LSP status, etc. Can we do this today? No, but with some > >> >> (signaling) extensions the problem I believe is=20 > solvable. Is this > > some > >> >> artificial, "fabricated" problem? No, I think it is=20 > real. Does it > > fall > >> >> under the control plane resilience problem space? I believe it > > does. > >> >> > >> >> Igor > >> >> > >> >> > I agree with Zafar and Dimitri. If someone wanted to document > > the > >> > GMPLS > >> >> > control plane resiliency features, as was done for GMPLS > > addressing, > >> >> > that might be a useful activity. > >> >> > > >> >> >> -----Original Message----- > >> >> >> From: dimitri papadimitriou [mailto:dpapadimitriou@psg.com] > >> >> >> Sent: Friday, October 28, 2005 9:56 AM > >> >> >> To: Igor Bryskin > >> >> >> Cc: Zafar Ali (zali); Kim Young Hwa; ccamp@ops.ietf.org > >> >> >> Subject: Re: Two Drafts for Resilience of Control Plane > >> >> >> > >> >> >> igor - > >> >> >> > >> >> >> over time CCAMP came with a set of mechanims to=20 > improve control > >> > plane > >> >> >> resilience (RSVP and LMP GR upon channel/node=20 > failure) other WG > >> >> > protocol > >> >> >> work are also usable used here OSPF GR, etc. ... on the other > > side, > >> >> >> mechanism such as link bundling have built-in resilience > >> > capabilities > >> >> >> and most GMPLS control plane capabilities have been designed > > such > >> > as > >> >> > to > >> >> >> be independent of the control plane realisation (in-band, > >> > out-of-band, > >> >> >> etc.) > >> >> >> > >> >> >> so indeed i share the concern of Zafar what could we do more > > here > >> > than > >> >> >> document these tools and provide our experience in=20 > using them; > >> >> >> > >> >> >> now, before stating there are (potential)=20 > problems(s) arising - > >> > would > >> >> >> you please be more specific on what are these potential=20 > >> >> >> issue(s) > >> >> > and/or > >> >> >> problems ? (not related to policy/config. - note: all the=20 > >> >> >> issues > >> > you > >> >> >> have pointed here below are simply policy/config specific but > > none > >> > of > >> >> >> them highlights a missing IP control plane=20 > resiliency feature) > >> >> >> > >> >> >> thanks, > >> >> >> - dimitri. > >> >> >> > >> >> >> > >> >> >> Igor Bryskin wrote: > >> >> >> > >> >> >> > Zafar, > >> >> >> > > >> >> >> > The problem arises when the control plane is=20 > decoupled from=20 > >> >> >> > the data plane. The question is do we need such=20 > decoupling in=20 > >> >> >> > IP networks? Consider, for example, the situation when=20 > >> >> >> > several parallel PSC data links bundled together and=20 > >> >> >> > controlled by a single control channel. > >> >> >> > Does it mean in this case that when the control=20 > channel fails=20 > >> >> >> > all associated data links also fail? Do we need to=20 > reroute in=20 > >> >> >> > this case LSPs that use the data links? Can we=20 > rely in this=20 > >> >> >> > case on control plane indications to decide whether an=20 > >> >> >> > associated data link is healthy or not (in other=20 > words, can=20 > >> >> >> > we rely on RSVP Hellos or should we use, for=20 > example, BTD)?=20 > >> >> >> > Should we be capable to recover control channels without=20 > >> >> >> > disturbing data plane? I think control plane resilience is=20 > >> >> >> > important for all layers. You are right, Internet=20 > does work,=20 > >> >> >> > however, we do need for some reason TE and (fast)=20 > recovery in=20 > >> >> >> > IP as much as in other layers,don't we? > >> >> >> > > >> >> >> > Cheers, > >> >> >> > Igor > >> >> >> > > >> >> >> > --- "Zafar Ali (zali)" wrote: > >> >> >> > > >> >> >> > > >> >> >> >>Hi All, > >> >> >> >> > >> >> >> >>I am unable to understand the problem we are=20 > trying to solve=20 > >> >> >> >>or fabricate. My control network is IP based and IP has=20 > >> >> >> >>proven resiliency (Internet *does* work), why=20 > would I like to=20 > >> >> >> >>take control plan resiliency problem at a layer *above-IP*=20 > >> >> >> >>and complicate my life. Did I miss something? > >> >> >> >> > >> >> >> >>Thanks > >> >> >> >> > >> >> >> >>Regards... Zafar > >> >> >> >> > >> >> >> >> > >> >> >> >>________________________________ > >> >> >> >> > >> >> >> >> From: owner-ccamp@ops.ietf.org=20 > >> >> >> >>[mailto:owner-ccamp@ops.ietf.org] > >> >> >> >>On Behalf Of Kim Young Hwa > >> >> >> >> Sent: Friday, October 28, 2005 6:04 AM > >> >> >> >> To: ccamp@ops.ietf.org > >> >> >> >> Subject: Two Drafts for Resilience of Control Plane > >> >> >> >> > >> >> >> >> > >> >> >> >> Dear all, > >> >> >> >> > >> >> >> >> I posted two drafts for the resilience of control plane. > >> >> >> >> One is for requirements of the resilience of=20 > control plane,=20 > >> >> >> >>the other is for a protocol specification as a solution of=20 > >> >> >> >>that . > >> >> >> >> These are now available at: > >> >> >> >> > >> >> >> >> > >> >> >> > > >> >> >> > > >> >=20 > http://www.ietf.org/internet-drafts/draft-kim-ccamp-cpr-reqts-01.tx > >> > t > >> >> >> > > >> >> >> >> > >> >> >> >> > >> >> >> > > >> >> >> > > >> >> > > >> > > >=20 > http://www.ietf.org/internet-drafts/draft-kim-ccamp-accp-protocol-00.t > > xt > >> >> >> > > >> >> >> >> > >> >> >> >> I want your comments. > >> >> >> >> > >> >> >> >> Regards > >> >> >> >> > >> >> >> >> Young. > >> >> >> >> > >> >> >> >> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D> >> Young-Hwa Kim > >> >> >> >> Principal Member / Ph.D > >> >> >> >> BcN Research Division, ETRI > >> >> >> >> Tel: +82-42-860-5819 > >> >> >> >> Fax: +82-42-860-5440 > >> >> >> >> e-mail: yhwkim@etri.re.kr > >> >> >> >> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D> >> > >> >> >> >> > >> >> >> > > >> >> >> > > >> >> > > >> > > >=20 > = > or > >> >> >> > > >> >> >> > > >> >> > > >> > > >=20 > = g&name=3Dccamp%40ops.ietf.org&fromemail=3Dyhwkim@etri.re.kr&messageid=3D%= 3C8 > > 63 > >> >> >> > > >> >> >> >>0a6db-0c31-49ab-a798-13b0dda04553@etri.re.kr%3E> > >> >> >> >> > >> >> >> >> > >> >> >> > > >> >> >> > > >> >> >> > > >> >> >> > > >> >> >> > > >> >> >> > > >> >> >> > __________________________________ > >> >> >> > Yahoo! Mail - PC Magazine Editors' Choice 2005=20 > >> >> >> > http://mail.yahoo.com > >> >> >> > > >> >> >> > > >> >> >> > . > >> >> >> > > >> >> > > >> >> > > >> >> > > >> > > >> > > > > > >=20 From owner-ccamp@ops.ietf.org Sat Oct 29 10:08:26 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVrNg-0000lV-G4 for ccamp-archive@megatron.ietf.org; Sat, 29 Oct 2005 10:08:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02358 for ; Sat, 29 Oct 2005 10:08:06 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVrbK-0004EO-JQ for ccamp-archive@ietf.org; Sat, 29 Oct 2005 10:22:39 -0400 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EVrJ9-0006Qe-7G for ccamp-data@psg.com; Sat, 29 Oct 2005 14:03:43 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [130.76.64.48] (helo=slb-smtpout-01.boeing.com) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EVrJ7-0006QJ-NR; Sat, 29 Oct 2005 14:03:41 +0000 Received: from stl-av-01.boeing.com ([192.76.190.6]) by slb-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id HAA15765; Sat, 29 Oct 2005 07:03:29 -0700 (PDT) Received: from XCH-SWBH-04.sw.nos.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id j9TE3SY17544; Sat, 29 Oct 2005 09:03:28 -0500 (CDT) Received: from XCH-SW-42.sw.nos.boeing.com ([192.79.11.43]) by XCH-SWBH-04.sw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 29 Oct 2005 07:03:28 -0700 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: Two Drafts for Resilience of Control Plane Date: Sat, 29 Oct 2005 07:03:27 -0700 Message-ID: <626FC7C6A97381468FB872072AB5DDC8369711@XCH-SW-42.sw.nos.boeing.com> Thread-Topic: Two Drafts for Resilience of Control Plane Thread-Index: AcXcjfnSQmJlztSNT1CH6Ck+YB2EbwAAqmTQ From: "Drake, John E" To: Cc: , , "Igor Bryskin" , "Zafar Ali" , "Kim Young Hwa" , X-OriginalArrivalTime: 29 Oct 2005 14:03:28.0208 (UTC) FILETIME=[8950F500:01C5DC91] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 2fe944273194be3112d13b31c91e6941 Content-Transfer-Encoding: quoted-printable Igor, You haven't convinced me that there is a real problem here that is not addressed by the combination of the existing GMPLS resilience mechanisms and a robust implementation of those mechanisms. As I said yesterday, an I-D that enumerated all of the resilience mechanisms might be a useful thing, specifically as a primer. Thanks, John > -----Original Message----- > From: ibryskin@movaz.com [mailto:ibryskin@movaz.com] > Sent: Saturday, October 29, 2005 6:38 AM > To: Drake, John E > Cc: ibryskin@movaz.com; dpapadimitriou@psg.com; > dimitri.papadimitriou@alcatel.be; Igor Bryskin; Zafar Ali; Kim Young Hwa; > ccamp@ops.ietf.org > Subject: RE: Two Drafts for Resilience of Control Plane >=20 > John, >=20 > See in line. >=20 > Igor >=20 > > Igor, > > > > What you wrote was: > > > > "Suppose one or more signaling controllers managing some LSP went out of > > service leaving the LSP's data plane intact. As far as the user is > > concerned such LSP is perfectly healthy and operational. Such situation > > could last for a considerable period of time." > > > > What part of this is *not* handled by RSVP graceful restart? > > > > In your subsequent e-mail, you then changed the problem statement to: > > > > ""Dead" controllers in my example *do not* come back for a considerable > > period of time. So there are no restarts here (graceful or not > > graceful)" >=20 > Sorry, I don't see how I have changed the problem statement. I was and am > saying that while controllers are out of service for a considerable time > (day? two days? week?) the question is what to do with active LSPs > associated with them? Let's consider an example: >=20 >=20 > A----B------C-----D > } | > E-----F-----H-----K >=20 > Suppose we have an LSP A-B-C-D carrying user traffic and a controller > managing node B went out of service. The question is what to do with this > LSP until the controller comes back? The operator may decide: > a) simply not wait and delete the LSP. Normal LSP teardown - PathTear > originated on the ingress controller- won't work because PathTear won't > make it to controllers managing nodes C and D, leaving (very expensive in > the optical layer) resources associated with the LSP allocated and not > available for other LSPs; > b) reroute via mb4b the LSP onto alternative path A-E-H-K-D -won't work > for the same reason as in a) > c) leave LSP as it is and wait for the dead controller to be replaced > or > repaired. This would mean the need to perform normal operations like, for > example, monitoring of data plane alarms, changing LSP admin status (for > example, disabling alarms on all nodes), perform power monitoring and > equalization, perform recovery operation in case of a fatal data plane > failure. All what depends on hop-by-hop signaling won't work today. > Don't tell me that these problems are fabricated; they are real because > they are raised by the customers. Dimitri seems to understand the problem > but he is saying that the CP in this case is hardly of any use. This IMO > is a dangerous statement for the future of CP in non-packet environments. > The Management plane aficionados will jump on it and say that management > plane does not have such a problem - NMS has a direct access to any NE on > the network, so it can do all necessary cleanup no matter what happened. > Customers will say: "Well, if there are situations when CP suddenly > becomes useless and we have to use management plane anyway, why would we > use the CP in the first place?' >=20 > Fortunately, I believe that the problems could be solved entirely via CP > by making it more resilient. Hence, CP resilience is a good direction to > work on within CCAMP WG >=20 > Igor >=20 > > If "Considerable period of time" is not equal to infinity, then there > > will be an RSVP graceful restart. If a controller is really and truly > > dead, then presumably the operator will either replace it or re-assign > > its data-plane resources to another signaling controller. In either > > case, there will then be an RSVP graceful restart. > > > > Thanks, > > > > John > > > > > > > >> -----Original Message----- > >> From: ibryskin@movaz.com [mailto:ibryskin@movaz.com] > >> Sent: Friday, October 28, 2005 1:00 PM > >> To: Drake, John E > >> Cc: ibryskin@movaz.com; dpapadimitriou@psg.com; > >> dimitri.papadimitriou@alcatel.be; Igor Bryskin; Zafar Ali; Kim Young > > Hwa; > >> ccamp@ops.ietf.org > >> Subject: RE: Two Drafts for Resilience of Control Plane > >> > >> John, > >> > >> I think you missed my point here. "Dead" controllers in my example *do > >> not* come back for a considerable period of time. So there are no > > restarts > >> here (graceful or not graceful) :=3D) > >> > >> Igor > >> > >> > What part of your problem, as stated below, is not handled by RSVP > >> > graceful restart? > >> > > >> >> -----Original Message----- > >> >> From: ibryskin@movaz.com [mailto:ibryskin@movaz.com] > >> >> Sent: Friday, October 28, 2005 11:41 AM > >> >> To: Drake, John E > >> >> Cc: dpapadimitriou@psg.com; dimitri.papadimitriou@alcatel.be; Igor > >> >> Bryskin; Zafar Ali; Kim Young Hwa; ccamp@ops.ietf.org > >> >> Subject: RE: Two Drafts for Resilience of Control Plane > >> >> > >> >> Hi, > >> >> > >> >> Here is one of the problems that I've been thinking for a while - > >> > control > >> >> plane partitioned LSPs. Suppose one or more signaling controllers > >> > managing > >> >> some LSP went out of service leaving the LSP's data plane intact. > > As > >> > far > >> >> as the user is concerned such LSP is perfectly healthy and > >> > operational. > >> >> Such situation could last for a considerable period of time. Do we > >> > need to > >> >> manage such LSP via control plane? Sure, we must be capable to tear > >> > down > >> >> such LSP, perform mb4b rerouting, distribute alarms between > >> > operational > >> >> controllers, signal data plane faults and perform recovery > > switchover, > >> >> modify LSP status, etc. Can we do this today? No, but with some > >> >> (signaling) extensions the problem I believe is solvable. Is this > > some > >> >> artificial, "fabricated" problem? No, I think it is real. Does it > > fall > >> >> under the control plane resilience problem space? I believe it > > does. > >> >> > >> >> Igor > >> >> > >> >> > I agree with Zafar and Dimitri. If someone wanted to document > > the > >> > GMPLS > >> >> > control plane resiliency features, as was done for GMPLS > > addressing, > >> >> > that might be a useful activity. > >> >> > > >> >> >> -----Original Message----- > >> >> >> From: dimitri papadimitriou [mailto:dpapadimitriou@psg.com] > >> >> >> Sent: Friday, October 28, 2005 9:56 AM > >> >> >> To: Igor Bryskin > >> >> >> Cc: Zafar Ali (zali); Kim Young Hwa; ccamp@ops.ietf.org > >> >> >> Subject: Re: Two Drafts for Resilience of Control Plane > >> >> >> > >> >> >> igor - > >> >> >> > >> >> >> over time CCAMP came with a set of mechanims to improve control > >> > plane > >> >> >> resilience (RSVP and LMP GR upon channel/node failure) other WG > >> >> > protocol > >> >> >> work are also usable used here OSPF GR, etc. ... on the other > > side, > >> >> >> mechanism such as link bundling have built-in resilience > >> > capabilities > >> >> >> and most GMPLS control plane capabilities have been designed > > such > >> > as > >> >> > to > >> >> >> be independent of the control plane realisation (in-band, > >> > out-of-band, > >> >> >> etc.) > >> >> >> > >> >> >> so indeed i share the concern of Zafar what could we do more > > here > >> > than > >> >> >> document these tools and provide our experience in using them; > >> >> >> > >> >> >> now, before stating there are (potential) problems(s) arising - > >> > would > >> >> >> you please be more specific on what are these potential issue(s) > >> >> > and/or > >> >> >> problems ? (not related to policy/config. - note: all the issues > >> > you > >> >> >> have pointed here below are simply policy/config specific but > > none > >> > of > >> >> >> them highlights a missing IP control plane resiliency feature) > >> >> >> > >> >> >> thanks, > >> >> >> - dimitri. > >> >> >> > >> >> >> > >> >> >> Igor Bryskin wrote: > >> >> >> > >> >> >> > Zafar, > >> >> >> > > >> >> >> > The problem arises when the control plane is decoupled > >> >> >> > from the data plane. The question is do we need such > >> >> >> > decoupling in IP networks? Consider, for example, the > >> >> >> > situation when several parallel PSC data links bundled > >> >> >> > together and controlled by a single control channel. > >> >> >> > Does it mean in this case that when the control > >> >> >> > channel fails all associated data links also fail? Do > >> >> >> > we need to reroute in this case LSPs that use the data > >> >> >> > links? Can we rely in this case on control plane > >> >> >> > indications to decide whether an associated data link > >> >> >> > is healthy or not (in other words, can we rely on RSVP > >> >> >> > Hellos or should we use, for example, BTD)? Should we > >> >> >> > be capable to recover control channels without > >> >> >> > disturbing data plane? I think control plane > >> >> >> > resilience is important for all layers. You are right, > >> >> >> > Internet does work, however, we do need for some > >> >> >> > reason TE and (fast) recovery in IP as much as in > >> >> >> > other layers,don't we? > >> >> >> > > >> >> >> > Cheers, > >> >> >> > Igor > >> >> >> > > >> >> >> > --- "Zafar Ali (zali)" wrote: > >> >> >> > > >> >> >> > > >> >> >> >>Hi All, > >> >> >> >> > >> >> >> >>I am unable to understand the problem we are trying > >> >> >> >>to solve or > >> >> >> >>fabricate. My control network is IP based and IP has > >> >> >> >>proven resiliency > >> >> >> >>(Internet *does* work), why would I like to take > >> >> >> >>control plan resiliency > >> >> >> >>problem at a layer *above-IP* and complicate my > >> >> >> >>life. Did I miss > >> >> >> >>something? > >> >> >> >> > >> >> >> >>Thanks > >> >> >> >> > >> >> >> >>Regards... Zafar > >> >> >> >> > >> >> >> >> > >> >> >> >>________________________________ > >> >> >> >> > >> >> >> >> From: owner-ccamp@ops.ietf.org > >> >> >> >>[mailto:owner-ccamp@ops.ietf.org] > >> >> >> >>On Behalf Of Kim Young Hwa > >> >> >> >> Sent: Friday, October 28, 2005 6:04 AM > >> >> >> >> To: ccamp@ops.ietf.org > >> >> >> >> Subject: Two Drafts for Resilience of Control Plane > >> >> >> >> > >> >> >> >> > >> >> >> >> Dear all, > >> >> >> >> > >> >> >> >> I posted two drafts for the resilience of control > >> >> >> >>plane. > >> >> >> >> One is for requirements of the resilience of > >> >> >> >>control plane, the > >> >> >> >>other is for a protocol specification as a solution > >> >> >> >>of that . > >> >> >> >> These are now available at: > >> >> >> >> > >> >> >> >> > >> >> >> > > >> >> >> > > >> > http://www.ietf.org/internet-drafts/draft-kim-ccamp-cpr-reqts-01.txt > >> >> >> > > >> >> >> >> > >> >> >> >> > >> >> >> > > >> >> >> > > >> >> > > >> > > > http://www.ietf.org/internet-drafts/draft-kim-ccamp-accp-protocol-00.txt > >> >> >> > > >> >> >> >> > >> >> >> >> I want your comments. > >> >> >> >> > >> >> >> >> Regards > >> >> >> >> > >> >> >> >> Young. > >> >> >> >> > >> >> >> >> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D> >> Young-Hwa Kim > >> >> >> >> Principal Member / Ph.D > >> >> >> >> BcN Research Division, ETRI > >> >> >> >> Tel: +82-42-860-5819 > >> >> >> >> Fax: +82-42-860-5440 > >> >> >> >> e-mail: yhwkim@etri.re.kr > >> >> >> >> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D> >> > >> >> >> >> > >> >> >> > > >> >> >> > > >> >> > > >> > > > >> >> >> > > >> >> >> > > >> >> > > >> > > > g&name=3Dccamp%40ops.ietf.org&fromemail=3Dyhwkim@etri.re.kr&messageid=3D%= 3C863 > >> >> >> > > >> >> >> >>0a6db-0c31-49ab-a798-13b0dda04553@etri.re.kr%3E> > >> >> >> >> > >> >> >> >> > >> >> >> > > >> >> >> > > >> >> >> > > >> >> >> > > >> >> >> > > >> >> >> > > >> >> >> > __________________________________ > >> >> >> > Yahoo! Mail - PC Magazine Editors' Choice 2005 > >> >> >> > http://mail.yahoo.com > >> >> >> > > >> >> >> > > >> >> >> > . > >> >> >> > > >> >> > > >> >> > > >> >> > > >> > > >> > > > > > From owner-ccamp@ops.ietf.org Sat Oct 29 10:15:50 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVrUr-00039L-1g for ccamp-archive@megatron.ietf.org; Sat, 29 Oct 2005 10:15:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02770 for ; Sat, 29 Oct 2005 10:15:30 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVrid-0004Qw-Hp for ccamp-archive@ietf.org; Sat, 29 Oct 2005 10:30:04 -0400 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EVrPg-0006xS-7B for ccamp-data@psg.com; Sat, 29 Oct 2005 14:10:28 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=3.1.0 Received: from [70.158.43.219] (helo=jera.movaz.com) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EVrPe-0006xF-V2 for ccamp@ops.ietf.org; Sat, 29 Oct 2005 14:10:27 +0000 Received: by jera.movaz.com (Postfix, from userid 30) id C65BA68C75; Sat, 29 Oct 2005 10:10:25 -0400 (EDT) Received: from 68.100.80.11 (SquirrelMail authenticated user ibryskin) by webmail.movaz.com with HTTP; Sat, 29 Oct 2005 10:10:25 -0400 (EDT) Message-ID: <3445.68.100.80.11.1130595025.squirrel@webmail.movaz.com> In-Reply-To: References: Date: Sat, 29 Oct 2005 10:10:25 -0400 (EDT) Subject: RE: Two Drafts for Resilience of Control Plane From: ibryskin@movaz.com To: "Zafar Ali (zali)" Cc: ibryskin@movaz.com, Drake@movaz.com, "John E" , dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be, "Igor Bryskin" , "Kim Young Hwa" , ccamp@ops.ietf.org User-Agent: SquirrelMail/1.4.1 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 Importance: Normal Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 1.2 (+) X-Scan-Signature: 10dcc25e55b9b5f7d6ded516404bdc4c Content-Transfer-Encoding: 8bit Zafar, >> c) leave LSP as it is and wait for the dead controller to >> be replaced or >> repaired. This would mean the need to perform normal >> operations like, for example, monitoring of data plane >> alarms, changing LSP admin status (for example, disabling >> alarms on all nodes), perform power monitoring and >> equalization, perform recovery operation in case of a fatal >> data plane failure. All what depends on hop-by-hop signaling >> won't work today. >> Don't tell me that these problems are fabricated; they are >> real because they are raised by the customers. Dimitri seems >> to understand the problem but he is saying that the CP in >> this case is hardly of any use. This IMO is a dangerous >> statement for the future of CP in non-packet environments. >> The Management plane aficionados will jump on it and say that >> management plane does not have such a problem - NMS has a >> direct access to any NE on the network, so it can do all >> necessary cleanup no matter what happened. >> Customers will say: "Well, if there are situations when CP >> suddenly becomes useless and we have to use management plane >> anyway, why would we use the CP in the first place?' >> >> Fortunately, I believe that the problems could be solved >> entirely via CP by making it more resilient. Hence, CP >> resilience is a good direction to work on within CCAMP WG > > Igor, > > W.r.t. option C, please note that traffic CANNOT be forwarded in a > "head-less mode" for a very long time . If you control network melts or > a peering controller goes down, either RSVP GR or refreshes will take > care of the clean-up of the affected RSVP states. Similarly LMP CC SM > will go down (after states are cleared, i.e., degraded-to-down), > eventually removing the TE links from topology. > Sticking to the example I described: a) absence of RSVP refreshes does not affect data plane in any way; b) use of LMP is not mandatory and, becides, I don't see now it helps. True, the TE link could be withdrawn, however, the LSP will still be operational Igor > Thanks > > Regards... Zafar > >> >> Igor >> >> > If "Considerable period of time" is not equal to infinity, >> then there >> > will be an RSVP graceful restart. If a controller is >> really and truly >> > dead, then presumably the operator will either replace it >> or re-assign >> > its data-plane resources to another signaling controller. >> In either >> > case, there will then be an RSVP graceful restart. >> > >> > Thanks, >> > >> > John >> > >> > >> > >> >> -----Original Message----- >> >> From: ibryskin@movaz.com [mailto:ibryskin@movaz.com] >> >> Sent: Friday, October 28, 2005 1:00 PM >> >> To: Drake, John E >> >> Cc: ibryskin@movaz.com; dpapadimitriou@psg.com; >> >> dimitri.papadimitriou@alcatel.be; Igor Bryskin; Zafar Ali; >> Kim Young >> > Hwa; >> >> ccamp@ops.ietf.org >> >> Subject: RE: Two Drafts for Resilience of Control Plane >> >> >> >> John, >> >> >> >> I think you missed my point here. "Dead" controllers in my example >> >> *do >> >> not* come back for a considerable period of time. So there are no >> > restarts >> >> here (graceful or not graceful) :=) >> >> >> >> Igor >> >> >> >> > What part of your problem, as stated below, is not >> handled by RSVP >> >> > graceful restart? >> >> > >> >> >> -----Original Message----- >> >> >> From: ibryskin@movaz.com [mailto:ibryskin@movaz.com] >> >> >> Sent: Friday, October 28, 2005 11:41 AM >> >> >> To: Drake, John E >> >> >> Cc: dpapadimitriou@psg.com; >> dimitri.papadimitriou@alcatel.be; Igor >> >> >> Bryskin; Zafar Ali; Kim Young Hwa; ccamp@ops.ietf.org >> >> >> Subject: RE: Two Drafts for Resilience of Control Plane >> >> >> >> >> >> Hi, >> >> >> >> >> >> Here is one of the problems that I've been thinking for >> a while - >> >> > control >> >> >> plane partitioned LSPs. Suppose one or more signaling >> controllers >> >> > managing >> >> >> some LSP went out of service leaving the LSP's data >> plane intact. >> > As >> >> > far >> >> >> as the user is concerned such LSP is perfectly healthy and >> >> > operational. >> >> >> Such situation could last for a considerable period of >> time. Do we >> >> > need to >> >> >> manage such LSP via control plane? Sure, we must be capable to >> >> >> tear >> >> > down >> >> >> such LSP, perform mb4b rerouting, distribute alarms between >> >> > operational >> >> >> controllers, signal data plane faults and perform recovery >> > switchover, >> >> >> modify LSP status, etc. Can we do this today? No, but with some >> >> >> (signaling) extensions the problem I believe is >> solvable. Is this >> > some >> >> >> artificial, "fabricated" problem? No, I think it is >> real. Does it >> > fall >> >> >> under the control plane resilience problem space? I believe it >> > does. >> >> >> >> >> >> Igor >> >> >> >> >> >> > I agree with Zafar and Dimitri. If someone wanted to document >> > the >> >> > GMPLS >> >> >> > control plane resiliency features, as was done for GMPLS >> > addressing, >> >> >> > that might be a useful activity. >> >> >> > >> >> >> >> -----Original Message----- >> >> >> >> From: dimitri papadimitriou [mailto:dpapadimitriou@psg.com] >> >> >> >> Sent: Friday, October 28, 2005 9:56 AM >> >> >> >> To: Igor Bryskin >> >> >> >> Cc: Zafar Ali (zali); Kim Young Hwa; ccamp@ops.ietf.org >> >> >> >> Subject: Re: Two Drafts for Resilience of Control Plane >> >> >> >> >> >> >> >> igor - >> >> >> >> >> >> >> >> over time CCAMP came with a set of mechanims to >> improve control >> >> > plane >> >> >> >> resilience (RSVP and LMP GR upon channel/node >> failure) other WG >> >> >> > protocol >> >> >> >> work are also usable used here OSPF GR, etc. ... on the other >> > side, >> >> >> >> mechanism such as link bundling have built-in resilience >> >> > capabilities >> >> >> >> and most GMPLS control plane capabilities have been designed >> > such >> >> > as >> >> >> > to >> >> >> >> be independent of the control plane realisation (in-band, >> >> > out-of-band, >> >> >> >> etc.) >> >> >> >> >> >> >> >> so indeed i share the concern of Zafar what could we do more >> > here >> >> > than >> >> >> >> document these tools and provide our experience in >> using them; >> >> >> >> >> >> >> >> now, before stating there are (potential) >> problems(s) arising - >> >> > would >> >> >> >> you please be more specific on what are these potential >> >> >> >> issue(s) >> >> >> > and/or >> >> >> >> problems ? (not related to policy/config. - note: all the >> >> >> >> issues >> >> > you >> >> >> >> have pointed here below are simply policy/config specific but >> > none >> >> > of >> >> >> >> them highlights a missing IP control plane >> resiliency feature) >> >> >> >> >> >> >> >> thanks, >> >> >> >> - dimitri. >> >> >> >> >> >> >> >> >> >> >> >> Igor Bryskin wrote: >> >> >> >> >> >> >> >> > Zafar, >> >> >> >> > >> >> >> >> > The problem arises when the control plane is >> decoupled from >> >> >> >> > the data plane. The question is do we need such >> decoupling in >> >> >> >> > IP networks? Consider, for example, the situation when >> >> >> >> > several parallel PSC data links bundled together and >> >> >> >> > controlled by a single control channel. >> >> >> >> > Does it mean in this case that when the control >> channel fails >> >> >> >> > all associated data links also fail? Do we need to >> reroute in >> >> >> >> > this case LSPs that use the data links? Can we >> rely in this >> >> >> >> > case on control plane indications to decide whether an >> >> >> >> > associated data link is healthy or not (in other >> words, can >> >> >> >> > we rely on RSVP Hellos or should we use, for >> example, BTD)? >> >> >> >> > Should we be capable to recover control channels without >> >> >> >> > disturbing data plane? I think control plane resilience is >> >> >> >> > important for all layers. You are right, Internet >> does work, >> >> >> >> > however, we do need for some reason TE and (fast) >> recovery in >> >> >> >> > IP as much as in other layers,don't we? >> >> >> >> > >> >> >> >> > Cheers, >> >> >> >> > Igor >> >> >> >> > >> >> >> >> > --- "Zafar Ali (zali)" wrote: >> >> >> >> > >> >> >> >> > >> >> >> >> >>Hi All, >> >> >> >> >> >> >> >> >> >>I am unable to understand the problem we are >> trying to solve >> >> >> >> >>or fabricate. My control network is IP based and IP has >> >> >> >> >>proven resiliency (Internet *does* work), why >> would I like to >> >> >> >> >>take control plan resiliency problem at a layer *above-IP* >> >> >> >> >>and complicate my life. Did I miss something? >> >> >> >> >> >> >> >> >> >>Thanks >> >> >> >> >> >> >> >> >> >>Regards... Zafar >> >> >> >> >> >> >> >> >> >> >> >> >> >> >>________________________________ >> >> >> >> >> >> >> >> >> >> From: owner-ccamp@ops.ietf.org >> >> >> >> >>[mailto:owner-ccamp@ops.ietf.org] >> >> >> >> >>On Behalf Of Kim Young Hwa >> >> >> >> >> Sent: Friday, October 28, 2005 6:04 AM >> >> >> >> >> To: ccamp@ops.ietf.org >> >> >> >> >> Subject: Two Drafts for Resilience of Control Plane >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> Dear all, >> >> >> >> >> >> >> >> >> >> I posted two drafts for the resilience of control plane. >> >> >> >> >> One is for requirements of the resilience of >> control plane, >> >> >> >> >>the other is for a protocol specification as a solution of >> >> >> >> >>that . >> >> >> >> >> These are now available at: >> >> >> >> >> >> >> >> >> >> >> >> >> >> > >> >> >> >> > >> >> > >> http://www.ietf.org/internet-drafts/draft-kim-ccamp-cpr-reqts-01.tx >> >> > t >> >> >> >> > >> >> >> >> >> >> >> >> >> >> >> >> >> >> > >> >> >> >> > >> >> >> > >> >> > >> > >> http://www.ietf.org/internet-drafts/draft-kim-ccamp-accp-protocol-00.t >> > xt >> >> >> >> > >> >> >> >> >> >> >> >> >> >> I want your comments. >> >> >> >> >> >> >> >> >> >> Regards >> >> >> >> >> >> >> >> >> >> Young. >> >> >> >> >> >> >> >> >> >> ===================================> >> Young-Hwa Kim >> >> >> >> >> Principal Member / Ph.D >> >> >> >> >> BcN Research Division, ETRI >> >> >> >> >> Tel: +82-42-860-5819 >> >> >> >> >> Fax: +82-42-860-5440 >> >> >> >> >> e-mail: yhwkim@etri.re.kr >> >> >> >> >> ===================================> >> >> >> >> >> >> >> >> >> >> > >> >> >> >> > >> >> >> > >> >> > >> > >> > > or >> >> >> >> > >> >> >> >> > >> >> >> > >> >> > >> > >> g&name=ccamp%40ops.ietf.org&fromemail=yhwkim@etri.re.kr&messageid=%3C8 >> > 63 >> >> >> >> > >> >> >> >> >>0a6db-0c31-49ab-a798-13b0dda04553@etri.re.kr%3E> >> >> >> >> >> >> >> >> >> >> >> >> >> >> > >> >> >> >> > >> >> >> >> > >> >> >> >> > >> >> >> >> > >> >> >> >> > >> >> >> >> > __________________________________ >> >> >> >> > Yahoo! Mail - PC Magazine Editors' Choice 2005 >> >> >> >> > http://mail.yahoo.com >> >> >> >> > >> >> >> >> > >> >> >> >> > . >> >> >> >> > >> >> >> > >> >> >> > >> >> >> > >> >> > >> >> > >> > >> > >> > From owner-ccamp@ops.ietf.org Sat Oct 29 10:24:37 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVrdL-0006uk-I1 for ccamp-archive@megatron.ietf.org; Sat, 29 Oct 2005 10:24:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03086 for ; Sat, 29 Oct 2005 10:24:17 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVrr8-0004dT-7d for ccamp-archive@ietf.org; Sat, 29 Oct 2005 10:38:50 -0400 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EVrYK-0007jm-JR for ccamp-data@psg.com; Sat, 29 Oct 2005 14:19:24 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=3.1.0 Received: from [70.158.43.219] (helo=jera.movaz.com) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EVrYJ-0007ja-7X for ccamp@ops.ietf.org; Sat, 29 Oct 2005 14:19:23 +0000 Received: by jera.movaz.com (Postfix, from userid 30) id 031D766DAA; Sat, 29 Oct 2005 10:19:22 -0400 (EDT) Received: from 68.100.80.11 (SquirrelMail authenticated user ibryskin) by webmail.movaz.com with HTTP; Sat, 29 Oct 2005 10:19:21 -0400 (EDT) Message-ID: <3450.68.100.80.11.1130595561.squirrel@webmail.movaz.com> In-Reply-To: <626FC7C6A97381468FB872072AB5DDC8369711@XCH-SW-42.sw.nos.boeing.com> References: <626FC7C6A97381468FB872072AB5DDC8369711@XCH-SW-42.sw.nos.boeing.com> Date: Sat, 29 Oct 2005 10:19:21 -0400 (EDT) Subject: RE: Two Drafts for Resilience of Control Plane From: ibryskin@movaz.com To: "Drake, John E" Cc: ibryskin@movaz.com, dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be, "Igor Bryskin" , "Zafar Ali" , "Kim Young Hwa" , ccamp@ops.ietf.org User-Agent: SquirrelMail/1.4.1 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 Importance: Normal Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 1.2 (+) X-Scan-Signature: cd3d702b63698072ba67a75ce9e0fc9e Content-Transfer-Encoding: 8bit John, > Igor, > > You haven't convinced me that there is a real problem here that is not > addressed by the combination of the existing GMPLS resilience mechanisms > and a robust implementation of those mechanisms. What exactly I failed to convince you: a) the example is not real problem -- I am telling you that this is the problem raised by the customers, how more real it could be? b) the problem cannot ne solved by existing machinery --- so I described in details the problem, please, tell me how I can solve it. Have a great weekend. Igor > > As I said yesterday, an I-D that enumerated all of the resilience > mechanisms might be a useful thing, specifically as a primer. > > Thanks, > > John > >> -----Original Message----- >> From: ibryskin@movaz.com [mailto:ibryskin@movaz.com] >> Sent: Saturday, October 29, 2005 6:38 AM >> To: Drake, John E >> Cc: ibryskin@movaz.com; dpapadimitriou@psg.com; >> dimitri.papadimitriou@alcatel.be; Igor Bryskin; Zafar Ali; Kim Young > Hwa; >> ccamp@ops.ietf.org >> Subject: RE: Two Drafts for Resilience of Control Plane >> >> John, >> >> See in line. >> >> Igor >> >> > Igor, >> > >> > What you wrote was: >> > >> > "Suppose one or more signaling controllers managing some LSP went > out of >> > service leaving the LSP's data plane intact. As far as the user is >> > concerned such LSP is perfectly healthy and operational. Such > situation >> > could last for a considerable period of time." >> > >> > What part of this is *not* handled by RSVP graceful restart? >> > >> > In your subsequent e-mail, you then changed the problem statement > to: >> > >> > ""Dead" controllers in my example *do not* come back for a > considerable >> > period of time. So there are no restarts here (graceful or not >> > graceful)" >> >> Sorry, I don't see how I have changed the problem statement. I was and > am >> saying that while controllers are out of service for a considerable > time >> (day? two days? week?) the question is what to do with active LSPs >> associated with them? Let's consider an example: >> >> >> A----B------C-----D >> } | >> E-----F-----H-----K >> >> Suppose we have an LSP A-B-C-D carrying user traffic and a controller >> managing node B went out of service. The question is what to do with > this >> LSP until the controller comes back? The operator may decide: >> a) simply not wait and delete the LSP. Normal LSP teardown - > PathTear >> originated on the ingress controller- won't work because PathTear > won't >> make it to controllers managing nodes C and D, leaving (very expensive > in >> the optical layer) resources associated with the LSP allocated and not >> available for other LSPs; >> b) reroute via mb4b the LSP onto alternative path A-E-H-K-D -won't > work >> for the same reason as in a) >> c) leave LSP as it is and wait for the dead controller to be > replaced >> or >> repaired. This would mean the need to perform normal operations like, > for >> example, monitoring of data plane alarms, changing LSP admin status > (for >> example, disabling alarms on all nodes), perform power monitoring and >> equalization, perform recovery operation in case of a fatal data plane >> failure. All what depends on hop-by-hop signaling won't work today. >> Don't tell me that these problems are fabricated; they are real > because >> they are raised by the customers. Dimitri seems to understand the > problem >> but he is saying that the CP in this case is hardly of any use. This > IMO >> is a dangerous statement for the future of CP in non-packet > environments. >> The Management plane aficionados will jump on it and say that > management >> plane does not have such a problem - NMS has a direct access to any NE > on >> the network, so it can do all necessary cleanup no matter what > happened. >> Customers will say: "Well, if there are situations when CP suddenly >> becomes useless and we have to use management plane anyway, why would > we >> use the CP in the first place?' >> >> Fortunately, I believe that the problems could be solved entirely via > CP >> by making it more resilient. Hence, CP resilience is a good direction > to >> work on within CCAMP WG >> >> Igor >> >> > If "Considerable period of time" is not equal to infinity, then > there >> > will be an RSVP graceful restart. If a controller is really and > truly >> > dead, then presumably the operator will either replace it or > re-assign >> > its data-plane resources to another signaling controller. In either >> > case, there will then be an RSVP graceful restart. >> > >> > Thanks, >> > >> > John >> > >> > >> > >> >> -----Original Message----- >> >> From: ibryskin@movaz.com [mailto:ibryskin@movaz.com] >> >> Sent: Friday, October 28, 2005 1:00 PM >> >> To: Drake, John E >> >> Cc: ibryskin@movaz.com; dpapadimitriou@psg.com; >> >> dimitri.papadimitriou@alcatel.be; Igor Bryskin; Zafar Ali; Kim > Young >> > Hwa; >> >> ccamp@ops.ietf.org >> >> Subject: RE: Two Drafts for Resilience of Control Plane >> >> >> >> John, >> >> >> >> I think you missed my point here. "Dead" controllers in my example > *do >> >> not* come back for a considerable period of time. So there are no >> > restarts >> >> here (graceful or not graceful) :=) >> >> >> >> Igor >> >> >> >> > What part of your problem, as stated below, is not handled by > RSVP >> >> > graceful restart? >> >> > >> >> >> -----Original Message----- >> >> >> From: ibryskin@movaz.com [mailto:ibryskin@movaz.com] >> >> >> Sent: Friday, October 28, 2005 11:41 AM >> >> >> To: Drake, John E >> >> >> Cc: dpapadimitriou@psg.com; dimitri.papadimitriou@alcatel.be; > Igor >> >> >> Bryskin; Zafar Ali; Kim Young Hwa; ccamp@ops.ietf.org >> >> >> Subject: RE: Two Drafts for Resilience of Control Plane >> >> >> >> >> >> Hi, >> >> >> >> >> >> Here is one of the problems that I've been thinking for a while > - >> >> > control >> >> >> plane partitioned LSPs. Suppose one or more signaling > controllers >> >> > managing >> >> >> some LSP went out of service leaving the LSP's data plane > intact. >> > As >> >> > far >> >> >> as the user is concerned such LSP is perfectly healthy and >> >> > operational. >> >> >> Such situation could last for a considerable period of time. Do > we >> >> > need to >> >> >> manage such LSP via control plane? Sure, we must be capable to > tear >> >> > down >> >> >> such LSP, perform mb4b rerouting, distribute alarms between >> >> > operational >> >> >> controllers, signal data plane faults and perform recovery >> > switchover, >> >> >> modify LSP status, etc. Can we do this today? No, but with some >> >> >> (signaling) extensions the problem I believe is solvable. Is > this >> > some >> >> >> artificial, "fabricated" problem? No, I think it is real. Does > it >> > fall >> >> >> under the control plane resilience problem space? I believe it >> > does. >> >> >> >> >> >> Igor >> >> >> >> >> >> > I agree with Zafar and Dimitri. If someone wanted to document >> > the >> >> > GMPLS >> >> >> > control plane resiliency features, as was done for GMPLS >> > addressing, >> >> >> > that might be a useful activity. >> >> >> > >> >> >> >> -----Original Message----- >> >> >> >> From: dimitri papadimitriou [mailto:dpapadimitriou@psg.com] >> >> >> >> Sent: Friday, October 28, 2005 9:56 AM >> >> >> >> To: Igor Bryskin >> >> >> >> Cc: Zafar Ali (zali); Kim Young Hwa; ccamp@ops.ietf.org >> >> >> >> Subject: Re: Two Drafts for Resilience of Control Plane >> >> >> >> >> >> >> >> igor - >> >> >> >> >> >> >> >> over time CCAMP came with a set of mechanims to improve > control >> >> > plane >> >> >> >> resilience (RSVP and LMP GR upon channel/node failure) other > WG >> >> >> > protocol >> >> >> >> work are also usable used here OSPF GR, etc. ... on the other >> > side, >> >> >> >> mechanism such as link bundling have built-in resilience >> >> > capabilities >> >> >> >> and most GMPLS control plane capabilities have been designed >> > such >> >> > as >> >> >> > to >> >> >> >> be independent of the control plane realisation (in-band, >> >> > out-of-band, >> >> >> >> etc.) >> >> >> >> >> >> >> >> so indeed i share the concern of Zafar what could we do more >> > here >> >> > than >> >> >> >> document these tools and provide our experience in using > them; >> >> >> >> >> >> >> >> now, before stating there are (potential) problems(s) arising > - >> >> > would >> >> >> >> you please be more specific on what are these potential > issue(s) >> >> >> > and/or >> >> >> >> problems ? (not related to policy/config. - note: all the > issues >> >> > you >> >> >> >> have pointed here below are simply policy/config specific but >> > none >> >> > of >> >> >> >> them highlights a missing IP control plane resiliency > feature) >> >> >> >> >> >> >> >> thanks, >> >> >> >> - dimitri. >> >> >> >> >> >> >> >> >> >> >> >> Igor Bryskin wrote: >> >> >> >> >> >> >> >> > Zafar, >> >> >> >> > >> >> >> >> > The problem arises when the control plane is decoupled >> >> >> >> > from the data plane. The question is do we need such >> >> >> >> > decoupling in IP networks? Consider, for example, the >> >> >> >> > situation when several parallel PSC data links bundled >> >> >> >> > together and controlled by a single control channel. >> >> >> >> > Does it mean in this case that when the control >> >> >> >> > channel fails all associated data links also fail? Do >> >> >> >> > we need to reroute in this case LSPs that use the data >> >> >> >> > links? Can we rely in this case on control plane >> >> >> >> > indications to decide whether an associated data link >> >> >> >> > is healthy or not (in other words, can we rely on RSVP >> >> >> >> > Hellos or should we use, for example, BTD)? Should we >> >> >> >> > be capable to recover control channels without >> >> >> >> > disturbing data plane? I think control plane >> >> >> >> > resilience is important for all layers. You are right, >> >> >> >> > Internet does work, however, we do need for some >> >> >> >> > reason TE and (fast) recovery in IP as much as in >> >> >> >> > other layers,don't we? >> >> >> >> > >> >> >> >> > Cheers, >> >> >> >> > Igor >> >> >> >> > >> >> >> >> > --- "Zafar Ali (zali)" wrote: >> >> >> >> > >> >> >> >> > >> >> >> >> >>Hi All, >> >> >> >> >> >> >> >> >> >>I am unable to understand the problem we are trying >> >> >> >> >>to solve or >> >> >> >> >>fabricate. My control network is IP based and IP has >> >> >> >> >>proven resiliency >> >> >> >> >>(Internet *does* work), why would I like to take >> >> >> >> >>control plan resiliency >> >> >> >> >>problem at a layer *above-IP* and complicate my >> >> >> >> >>life. Did I miss >> >> >> >> >>something? >> >> >> >> >> >> >> >> >> >>Thanks >> >> >> >> >> >> >> >> >> >>Regards... Zafar >> >> >> >> >> >> >> >> >> >> >> >> >> >> >>________________________________ >> >> >> >> >> >> >> >> >> >> From: owner-ccamp@ops.ietf.org >> >> >> >> >>[mailto:owner-ccamp@ops.ietf.org] >> >> >> >> >>On Behalf Of Kim Young Hwa >> >> >> >> >> Sent: Friday, October 28, 2005 6:04 AM >> >> >> >> >> To: ccamp@ops.ietf.org >> >> >> >> >> Subject: Two Drafts for Resilience of Control Plane >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> Dear all, >> >> >> >> >> >> >> >> >> >> I posted two drafts for the resilience of control >> >> >> >> >>plane. >> >> >> >> >> One is for requirements of the resilience of >> >> >> >> >>control plane, the >> >> >> >> >>other is for a protocol specification as a solution >> >> >> >> >>of that . >> >> >> >> >> These are now available at: >> >> >> >> >> >> >> >> >> >> >> >> >> >> > >> >> >> >> > >> >> > > http://www.ietf.org/internet-drafts/draft-kim-ccamp-cpr-reqts-01.txt >> >> >> >> > >> >> >> >> >> >> >> >> >> >> >> >> >> >> > >> >> >> >> > >> >> >> > >> >> > >> > > http://www.ietf.org/internet-drafts/draft-kim-ccamp-accp-protocol-00.txt >> >> >> >> > >> >> >> >> >> >> >> >> >> >> I want your comments. >> >> >> >> >> >> >> >> >> >> Regards >> >> >> >> >> >> >> >> >> >> Young. >> >> >> >> >> >> >> >> >> >> ===================================> >> Young-Hwa Kim >> >> >> >> >> Principal Member / Ph.D >> >> >> >> >> BcN Research Division, ETRI >> >> >> >> >> Tel: +82-42-860-5819 >> >> >> >> >> Fax: +82-42-860-5440 >> >> >> >> >> e-mail: yhwkim@etri.re.kr >> >> >> >> >> ===================================> >> >> >> >> >> >> >> >> >> >> > >> >> >> >> > >> >> >> > >> >> > >> > > > >> >> >> > >> >> >> >> > >> >> >> > >> >> > >> > > g&name=ccamp%40ops.ietf.org&fromemail=yhwkim@etri.re.kr&messageid=%3C863 >> >> >> >> > >> >> >> >> >>0a6db-0c31-49ab-a798-13b0dda04553@etri.re.kr%3E> >> >> >> >> >> >> >> >> >> >> >> >> >> >> > >> >> >> >> > >> >> >> >> > >> >> >> >> > >> >> >> >> > >> >> >> >> > >> >> >> >> > __________________________________ >> >> >> >> > Yahoo! Mail - PC Magazine Editors' Choice 2005 >> >> >> >> > http://mail.yahoo.com >> >> >> >> > >> >> >> >> > >> >> >> >> > . >> >> >> >> > >> >> >> > >> >> >> > >> >> >> > >> >> > >> >> > >> > >> > > > From owner-ccamp@ops.ietf.org Sat Oct 29 10:27:24 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVrg4-0007zA-8b for ccamp-archive@megatron.ietf.org; Sat, 29 Oct 2005 10:27:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03209 for ; Sat, 29 Oct 2005 10:27:05 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVrto-0004hD-99 for ccamp-archive@ietf.org; Sat, 29 Oct 2005 10:41:39 -0400 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EVraJ-0007u5-Ko for ccamp-data@psg.com; Sat, 29 Oct 2005 14:21:27 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [130.76.64.48] (helo=slb-smtpout-01.boeing.com) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EVraJ-0007tp-3T; Sat, 29 Oct 2005 14:21:27 +0000 Received: from blv-av-01.boeing.com ([192.42.227.216]) by slb-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id HAA20879; Sat, 29 Oct 2005 07:21:21 -0700 (PDT) Received: from XCH-SWBH-04.sw.nos.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id j9TELLH15018; Sat, 29 Oct 2005 07:21:21 -0700 (PDT) Received: from XCH-SW-42.sw.nos.boeing.com ([192.79.11.43]) by XCH-SWBH-04.sw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 29 Oct 2005 07:21:20 -0700 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: Two Drafts for Resilience of Control Plane Date: Sat, 29 Oct 2005 07:21:20 -0700 Message-ID: <626FC7C6A97381468FB872072AB5DDC8369712@XCH-SW-42.sw.nos.boeing.com> Thread-Topic: Two Drafts for Resilience of Control Plane Thread-Index: AcXckoR17u8i/c1wQ3K2pzKwCgkbiQAAJz1w From: "Drake, John E" To: , "Zafar Ali \(zali\)" Cc: , , , "Igor Bryskin" , "Kim Young Hwa" , X-OriginalArrivalTime: 29 Oct 2005 14:21:20.0675 (UTC) FILETIME=[088E6F30:01C5DC94] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: quoted-printable > Sticking to the example I described: > a) absence of RSVP refreshes does not affect data plane in any way; > b) use of LMP is not mandatory and, becides, I don't see now it helps. > True, the TE link could be withdrawn, however, the LSP will still be > operational [JD]=20 In your example, PathTear downstream and PathErr w/ state removed upstream would work quite nicely. As a matter of local policy, a node always has the option of tearing down LSPs through adjacent nodes with which control plane connectivity has been lost, after a configured interval has elapsed. From owner-ccamp@ops.ietf.org Sat Oct 29 10:49:09 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVs17-0007bk-GA for ccamp-archive@megatron.ietf.org; Sat, 29 Oct 2005 10:49:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05132 for ; Sat, 29 Oct 2005 10:48:50 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVsEs-0005Ne-ME for ccamp-archive@ietf.org; Sat, 29 Oct 2005 11:03:24 -0400 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EVrsK-0000kp-RE for ccamp-data@psg.com; Sat, 29 Oct 2005 14:40:04 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=3.1.0 Received: from [70.158.43.219] (helo=jera.movaz.com) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EVrsK-0000kU-0A for ccamp@ops.ietf.org; Sat, 29 Oct 2005 14:40:04 +0000 Received: by jera.movaz.com (Postfix, from userid 30) id E396468EA7; Sat, 29 Oct 2005 10:40:01 -0400 (EDT) Received: from 68.100.80.11 (SquirrelMail authenticated user ibryskin) by webmail.movaz.com with HTTP; Sat, 29 Oct 2005 10:40:01 -0400 (EDT) Message-ID: <3505.68.100.80.11.1130596801.squirrel@webmail.movaz.com> In-Reply-To: <626FC7C6A97381468FB872072AB5DDC8369712@XCH-SW-42.sw.nos.boeing.com> References: <626FC7C6A97381468FB872072AB5DDC8369712@XCH-SW-42.sw.nos.boeing.com> Date: Sat, 29 Oct 2005 10:40:01 -0400 (EDT) Subject: RE: Two Drafts for Resilience of Control Plane From: ibryskin@movaz.com To: "Drake, John E" Cc: ibryskin@movaz.com, "Zafar Ali" , drake@movaz.com, dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be, "Igor Bryskin" , "Kim Young Hwa" , ccamp@ops.ietf.org User-Agent: SquirrelMail/1.4.1 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 Importance: Normal Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 1.2 (+) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 8bit > >> Sticking to the example I described: >> a) absence of RSVP refreshes does not affect data plane in any way; >> b) use of LMP is not mandatory and, becides, I don't see now it helps. >> True, the TE link could be withdrawn, however, the LSP will still be >> operational > [JD] > > In your example, PathTear downstream and PathErr w/ state removed > upstream would work quite nicely. True, but it means that operator needs to issue two management requests from two controllers. But this is not how control plane is supposed to work, isn't it? - it should be able to manage an LSP from a single (usually, ingress)controller. The way you described it the operator needs to figure out where to go and issue these requests. And what if this LSP is not an S-PVC, rather, SVC created via UNI or ENNI request? As a matter of local policy, a node > always has the option of tearing down LSPs through adjacent nodes with > which control plane connectivity has been lost, after a configured > interval has elapsed. Sorry, for envirionments where control and data planes are not congruent what you just said is an explicit NO-OPTION, i.e. must not be done - you cannot destroy data plane just because you lost connectivity in the control plane. Igor From owner-ccamp@ops.ietf.org Sat Oct 29 11:39:52 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVsoB-00011n-SO for ccamp-archive@megatron.ietf.org; Sat, 29 Oct 2005 11:39:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07129 for ; Sat, 29 Oct 2005 11:39:34 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVt1t-0006ZQ-7r for ccamp-archive@ietf.org; Sat, 29 Oct 2005 11:54:07 -0400 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EVskZ-00041p-AG for ccamp-data@psg.com; Sat, 29 Oct 2005 15:36:07 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [130.76.96.56] (helo=stl-smtpout-01.boeing.com) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EVskY-00041Z-9f; Sat, 29 Oct 2005 15:36:06 +0000 Received: from blv-av-01.boeing.com ([192.42.227.216]) by stl-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id KAA18752; Sat, 29 Oct 2005 10:35:55 -0500 (CDT) Received: from XCH-SWBH-04.sw.nos.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id j9TFZsH22021; Sat, 29 Oct 2005 08:35:54 -0700 (PDT) Received: from XCH-SW-42.sw.nos.boeing.com ([192.79.11.43]) by XCH-SWBH-04.sw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 29 Oct 2005 08:35:53 -0700 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: Two Drafts for Resilience of Control Plane Date: Sat, 29 Oct 2005 08:35:53 -0700 Message-ID: <626FC7C6A97381468FB872072AB5DDC8369713@XCH-SW-42.sw.nos.boeing.com> Thread-Topic: Two Drafts for Resilience of Control Plane Thread-Index: AcXclqb/BJdCG3rVRGauipftnzFUJwABGQIQ From: "Drake, John E" To: Cc: "Zafar Ali" , , , , "Igor Bryskin" , "Kim Young Hwa" , X-OriginalArrivalTime: 29 Oct 2005 15:35:53.0662 (UTC) FILETIME=[72AA15E0:01C5DC9E] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Content-Transfer-Encoding: quoted-printable Igor, If a node looses control plane connectivity to its adjacent nodes, then in the interval until that connectivity is restored, the nodes adjacent to that node will take it and its links out of the TE link state database so that no new LSPs will be routed through that node. Existing LSPS can be maintained. The endpoints of each LSP will be informed of the control plane failure, so that they can tear the LSP down if configured to do so, after a configured interval. If connectivity to multiple nodes along the path of an LSP are lost, there may be hung resources. To reclaim those resources, any node that loses CP connectivity to an adjacent node can be configured to tear down LSPs through that node after a configured interval. I am dubious the NM connectivity would exist if CP connectivity would exist, so one can't resort to NM to save the day. I think we are done. Thanks, John=20 > -----Original Message----- > From: ibryskin@movaz.com [mailto:ibryskin@movaz.com] > Sent: Saturday, October 29, 2005 7:40 AM > To: Drake, John E > Cc: ibryskin@movaz.com; Zafar Ali; drake@movaz.com; > dpapadimitriou@psg.com; dimitri.papadimitriou@alcatel.be; Igor Bryskin; > Kim Young Hwa; ccamp@ops.ietf.org > Subject: RE: Two Drafts for Resilience of Control Plane >=20 > > > >> Sticking to the example I described: > >> a) absence of RSVP refreshes does not affect data plane in any way; > >> b) use of LMP is not mandatory and, becides, I don't see now it helps. > >> True, the TE link could be withdrawn, however, the LSP will still be > >> operational > > [JD] > > > > In your example, PathTear downstream and PathErr w/ state removed > > upstream would work quite nicely. >=20 > True, but it means that operator needs to issue two management requests > from two controllers. But this is not how control plane is supposed to > work, isn't it? - it should be able to manage an LSP from a single > (usually, ingress)controller. The way you described it the operator needs > to figure out where to go and issue these requests. And what if this LSP > is not an S-PVC, rather, SVC created via UNI or ENNI request? >=20 > As a matter of local policy, a node > > always has the option of tearing down LSPs through adjacent nodes with > > which control plane connectivity has been lost, after a configured > > interval has elapsed. >=20 > Sorry, for envirionments where control and data planes are not congruent > what you just said is an explicit NO-OPTION, i.e. must not be done - you > cannot destroy data plane just because you lost connectivity in the > control plane. >=20 > Igor From owner-ccamp@ops.ietf.org Sat Oct 29 11:43:19 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVsrX-00028O-9b for ccamp-archive@megatron.ietf.org; Sat, 29 Oct 2005 11:43:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07242 for ; Sat, 29 Oct 2005 11:43:02 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVt5K-0006eV-Lz for ccamp-archive@ietf.org; Sat, 29 Oct 2005 11:57:35 -0400 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EVsne-0004F5-5C for ccamp-data@psg.com; Sat, 29 Oct 2005 15:39:18 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-4.8 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from localhost ([127.0.0.1]) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EVsnb-0004Dg-A0; Sat, 29 Oct 2005 15:39:16 +0000 Message-ID: <43639774.3000201@psg.com> Date: Sat, 29 Oct 2005 17:38:28 +0200 From: dimitri papadimitriou Reply-To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.11) Gecko/20050728 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ibryskin@movaz.com CC: "Drake, John E" , dimitri.papadimitriou@alcatel.be, Igor Bryskin , Zafar Ali , Kim Young Hwa , ccamp@ops.ietf.org Subject: Re: Two Drafts for Resilience of Control Plane References: <626FC7C6A97381468FB872072AB5DDC8369701@XCH-SW-42.sw.nos.boeing.com> <3336.68.100.80.11.1130593075.squirrel@webmail.movaz.com> In-Reply-To: <3336.68.100.80.11.1130593075.squirrel@webmail.movaz.com> Content-Type: text/plain; charset=windows-1252; format=flowed Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 4ec58ef3f343ebf5ac40a04538f9a6fc Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id LAA07242 igor - see in-line >>Igor, >> >>What you wrote was: >> >>"Suppose one or more signaling controllers managing some LSP went out o= f >>service leaving the LSP's data plane intact. As far as the user is >>concerned such LSP is perfectly healthy and operational. Such situatio= n >>could last for a considerable period of time." >> >>What part of this is *not* handled by RSVP graceful restart? >> >>In your subsequent e-mail, you then changed the problem statement to: >> >>""Dead" controllers in my example *do not* come back for a considerable >>period of time. So there are no restarts here (graceful or not >>graceful)" >=20 >=20 > Sorry, I don=92t see how I have changed the problem statement. I was an= d am > saying that while controllers are out of service for a considerable tim= e > (day? two days? week?) the question is what to do with active LSPs > associated with them?=20 you should take this as the initial problem - is there something wrong=20 with that situation as transient ? and is the objective leave B dead for=20 an non-finite period of time because in *any case* you will have to=20 replace B to be able to provision new LSPs crossing this node ? > Let=92s consider an example: >=20 >=20 > A----B------C-----D > } | > E-----F-----H-----K >=20 > Suppose we have an LSP A-B-C-D carrying user traffic and a controller > managing node B went out of service. The question is what to do with th= is > LSP until the controller comes back? The operator may decide: > a) simply not wait and delete the LSP. Normal LSP teardown =96 PathTear > originated on the ingress controller- won=92t work because PathTear won= =92t > make it to controllers managing nodes C and D, leaving (very expensive = in > the optical layer) resources associated with the LSP allocated and not > available for other LSPs; > b) reroute via mb4b the LSP onto alternative path A-E-H-K-D =96won=92t = work > for the same reason as in a) what does not work ? the release of the unused resource so once notified=20 of the failed controller and re-routing achieved trigger a PathErr with=20 PSR flag and you are done (so its a policy configuration) > c) leave LSP as it is and wait for the dead controller to be replaced o= r > repaired. This would mean the need to perform normal operations like, f= or > example, monitoring of data plane alarms, changing LSP admin status (fo= r > example, disabling alarms on all nodes), perform power monitoring and > equalization, perform recovery operation in case of a fatal data plane > failure. All what depends on hop-by-hop signaling won=92t work today. > Don=92t tell me that these problems are fabricated; they are real becau= se > they are raised by the customers. Dimitri seems to understand the probl= em > but he is saying that the CP in this case is hardly of any use.=20 just to clarify what i am saying here is that you can not expect a=20 collaboration in the resiliency process from a controller that is down=20 over a longer period than the repairing phase - now in any case the dead=20 CP will need to be replaced at some point in time; hence, whatever the=20 resiliency mechanism you are going to define it is certainly not going=20 to resurrect your dead CP and make possible the re-use of the node's=20 resources hence, you should first correctly position the problem instead of trying=20 to find unadapted workarounds or missing functionality; moreover here,=20 as the problem can be solved what can be additionally expected from the=20 CP ? > This IMO > is a dangerous statement for the future of CP in non-packet environment= s. what's more dangerous is to continuously claim that the GMPLS CP is not=20 resilient because of incomplete policy configuration (and that more work=20 is still needed) > The Management plane aficionados will jump on it and say that managemen= t > plane does not have such a problem =96 NMS has a direct access to any N= E on > the network, so it can do all necessary cleanup no matter what happened. > Customers will say: =93Well, if there are situations when CP suddenly > becomes useless and we have to use management plane anyway, why would w= e > use the CP in the first place?=92 you should ask the question is the other way around - why do you=20 consider a CP like a distributed MP ? > Fortunately, I believe that the problems could be solved entirely via C= P > by making it more resilient. Hence, CP resilience is a good direction t= o > work on within CCAMP WG indeed, document the resiliency mechanisms that the CCAMP WG and others=20 have defined over time and a GMPLS CP can make use to address such=20 problems may be advisable; but except if GMPLS is showing real gaps in=20 terms of resiliency there is no need to initiate new protocol work thanks, - dimitri. > Igor >=20 >=20 >>If "Considerable period of time" is not equal to infinity, then there >>will be an RSVP graceful restart. If a controller is really and truly >>dead, then presumably the operator will either replace it or re-assign >>its data-plane resources to another signaling controller. In either >>case, there will then be an RSVP graceful restart. >> >>Thanks, >> >>John >> >> >> >> >>>-----Original Message----- >>>From: ibryskin@movaz.com [mailto:ibryskin@movaz.com] >>>Sent: Friday, October 28, 2005 1:00 PM >>>To: Drake, John E >>>Cc: ibryskin@movaz.com; dpapadimitriou@psg.com; >>>dimitri.papadimitriou@alcatel.be; Igor Bryskin; Zafar Ali; Kim Young >> >>Hwa; >> >>>ccamp@ops.ietf.org >>>Subject: RE: Two Drafts for Resilience of Control Plane >>> >>>John, >>> >>>I think you missed my point here. "Dead" controllers in my example *do >>>not* come back for a considerable period of time. So there are no >> >>restarts >> >>>here (graceful or not graceful) :=3D) >>> >>>Igor >>> >>> >>>>What part of your problem, as stated below, is not handled by RSVP >>>>graceful restart? >>>> >>>> >>>>>-----Original Message----- >>>>>From: ibryskin@movaz.com [mailto:ibryskin@movaz.com] >>>>>Sent: Friday, October 28, 2005 11:41 AM >>>>>To: Drake, John E >>>>>Cc: dpapadimitriou@psg.com; dimitri.papadimitriou@alcatel.be; Igor >>>>>Bryskin; Zafar Ali; Kim Young Hwa; ccamp@ops.ietf.org >>>>>Subject: RE: Two Drafts for Resilience of Control Plane >>>>> >>>>>Hi, >>>>> >>>>>Here is one of the problems that I've been thinking for a while - >>>> >>>>control >>>> >>>>>plane partitioned LSPs. Suppose one or more signaling controllers >>>> >>>>managing >>>> >>>>>some LSP went out of service leaving the LSP's data plane intact. >> >>As >> >>>>far >>>> >>>>>as the user is concerned such LSP is perfectly healthy and >>>> >>>>operational. >>>> >>>>>Such situation could last for a considerable period of time. Do we >>>> >>>>need to >>>> >>>>>manage such LSP via control plane? Sure, we must be capable to tear >>>> >>>>down >>>> >>>>>such LSP, perform mb4b rerouting, distribute alarms between >>>> >>>>operational >>>> >>>>>controllers, signal data plane faults and perform recovery >> >>switchover, >> >>>>>modify LSP status, etc. Can we do this today? No, but with some >>>>>(signaling) extensions the problem I believe is solvable. Is this >> >>some >> >>>>>artificial, "fabricated" problem? No, I think it is real. Does it >> >>fall >> >>>>>under the control plane resilience problem space? I believe it >> >>does. >> >>>>>Igor >>>>> >>>>> >>>>>>I agree with Zafar and Dimitri. If someone wanted to document >> >>the >> >>>>GMPLS >>>> >>>>>>control plane resiliency features, as was done for GMPLS >> >>addressing, >> >>>>>>that might be a useful activity. >>>>>> >>>>>> >>>>>>>-----Original Message----- >>>>>>>From: dimitri papadimitriou [mailto:dpapadimitriou@psg.com] >>>>>>>Sent: Friday, October 28, 2005 9:56 AM >>>>>>>To: Igor Bryskin >>>>>>>Cc: Zafar Ali (zali); Kim Young Hwa; ccamp@ops.ietf.org >>>>>>>Subject: Re: Two Drafts for Resilience of Control Plane >>>>>>> >>>>>>>igor - >>>>>>> >>>>>>>over time CCAMP came with a set of mechanims to improve control >>>> >>>>plane >>>> >>>>>>>resilience (RSVP and LMP GR upon channel/node failure) other WG >>>>>> >>>>>>protocol >>>>>> >>>>>>>work are also usable used here OSPF GR, etc. ... on the other >> >>side, >> >>>>>>>mechanism such as link bundling have built-in resilience >>>> >>>>capabilities >>>> >>>>>>>and most GMPLS control plane capabilities have been designed >> >>such >> >>>>as >>>> >>>>>>to >>>>>> >>>>>>>be independent of the control plane realisation (in-band, >>>> >>>>out-of-band, >>>> >>>>>>>etc.) >>>>>>> >>>>>>>so indeed i share the concern of Zafar what could we do more >> >>here >> >>>>than >>>> >>>>>>>document these tools and provide our experience in using them; >>>>>>> >>>>>>>now, before stating there are (potential) problems(s) arising - >>>> >>>>would >>>> >>>>>>>you please be more specific on what are these potential issue(s) >>>>>> >>>>>>and/or >>>>>> >>>>>>>problems ? (not related to policy/config. - note: all the issues >>>> >>>>you >>>> >>>>>>>have pointed here below are simply policy/config specific but >> >>none >> >>>>of >>>> >>>>>>>them highlights a missing IP control plane resiliency feature) >>>>>>> >>>>>>>thanks, >>>>>>>- dimitri. >>>>>>> >>>>>>> >>>>>>>Igor Bryskin wrote: >>>>>>> >>>>>>> >>>>>>>>Zafar, >>>>>>>> >>>>>>>>The problem arises when the control plane is decoupled >>>>>>>>from the data plane. The question is do we need such >>>>>>>>decoupling in IP networks? Consider, for example, the >>>>>>>>situation when several parallel PSC data links bundled >>>>>>>>together and controlled by a single control channel. >>>>>>>>Does it mean in this case that when the control >>>>>>>>channel fails all associated data links also fail? Do >>>>>>>>we need to reroute in this case LSPs that use the data >>>>>>>>links? Can we rely in this case on control plane >>>>>>>>indications to decide whether an associated data link >>>>>>>>is healthy or not (in other words, can we rely on RSVP >>>>>>>>Hellos or should we use, for example, BTD)? Should we >>>>>>>>be capable to recover control channels without >>>>>>>>disturbing data plane? I think control plane >>>>>>>>resilience is important for all layers. You are right, >>>>>>>>Internet does work, however, we do need for some >>>>>>>>reason TE and (fast) recovery in IP as much as in >>>>>>>>other layers,don't we? >>>>>>>> >>>>>>>>Cheers, >>>>>>>>Igor >>>>>>>> >>>>>>>>--- "Zafar Ali (zali)" wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>Hi All, >>>>>>>>> >>>>>>>>>I am unable to understand the problem we are trying >>>>>>>>>to solve or >>>>>>>>>fabricate. My control network is IP based and IP has >>>>>>>>>proven resiliency >>>>>>>>>(Internet *does* work), why would I like to take >>>>>>>>>control plan resiliency >>>>>>>>>problem at a layer *above-IP* and complicate my >>>>>>>>>life. Did I miss >>>>>>>>>something? >>>>>>>>> >>>>>>>>>Thanks >>>>>>>>> >>>>>>>>>Regards... Zafar >>>>>>>>> >>>>>>>>> >>>>>>>>>________________________________ >>>>>>>>> >>>>>>>>> From: owner-ccamp@ops.ietf.org >>>>>>>>>[mailto:owner-ccamp@ops.ietf.org] >>>>>>>>>On Behalf Of Kim Young Hwa >>>>>>>>> Sent: Friday, October 28, 2005 6:04 AM >>>>>>>>> To: ccamp@ops.ietf.org >>>>>>>>> Subject: Two Drafts for Resilience of Control Plane >>>>>>>>> >>>>>>>>> >>>>>>>>> Dear all, >>>>>>>>> >>>>>>>>> I posted two drafts for the resilience of control >>>>>>>>>plane. >>>>>>>>> One is for requirements of the resilience of >>>>>>>>>control plane, the >>>>>>>>>other is for a protocol specification as a solution >>>>>>>>>of that . >>>>>>>>> These are now available at: >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>http://www.ietf.org/internet-drafts/draft-kim-ccamp-cpr-reqts-01.txt >>>> >>>>>>>>> >>>>>>>> >>http://www.ietf.org/internet-drafts/draft-kim-ccamp-accp-protocol-00.tx= t >> >>>>>>>>> I want your comments. >>>>>>>>> >>>>>>>>> Regards >>>>>>>>> >>>>>>>>> Young. >>>>>>>>> >>>>>>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D> >> Young-Hwa Kim >>>>>>>>> Principal Member / Ph.D >>>>>>>>> BcN Research Division, ETRI >>>>>>>>> Tel: +82-42-860-5819 >>>>>>>>> Fax: +82-42-860-5440 >>>>>>>>> e-mail: yhwkim@etri.re.kr >>>>>>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D> >> >>>>>>>>> >>>>>>>> >>> >>>>>>>> >>g&name=3Dccamp%40ops.ietf.org&fromemail=3Dyhwkim@etri.re.kr&messageid=3D= %3C863 >> >>>>>>>>>0a6db-0c31-49ab-a798-13b0dda04553@etri.re.kr%3E> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>__________________________________ >>>>>>>>Yahoo! Mail - PC Magazine Editors' Choice 2005 >>>>>>>>http://mail.yahoo.com >>>>>>>> >>>>>>>> >>>>>>>>. >>>>>>>> >>>>>> >>>>>> >>>>>> >>>> >> >=20 >=20 > . >=20 From owner-ccamp@ops.ietf.org Sat Oct 29 12:23:51 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVtUl-0001Do-Lg for ccamp-archive@megatron.ietf.org; Sat, 29 Oct 2005 12:23:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09242 for ; Sat, 29 Oct 2005 12:23:34 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVtiZ-0007iZ-Az for ccamp-archive@ietf.org; Sat, 29 Oct 2005 12:38:08 -0400 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EVtNR-0006DN-CN for ccamp-data@psg.com; Sat, 29 Oct 2005 16:16:17 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [64.102.122.149] (helo=rtp-iport-2.cisco.com) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EVtNP-0006C5-Ch for ccamp@ops.ietf.org; Sat, 29 Oct 2005 16:16:15 +0000 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 29 Oct 2005 12:16:06 -0400 X-IronPort-AV: i="3.97,266,1125892800"; d="scan'208"; a="74707354:sNHT31902894" 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 j9TGG1Ei018553; Sat, 29 Oct 2005 12:16:01 -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); Sat, 29 Oct 2005 12:16:01 -0400 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: Two Drafts for Resilience of Control Plane Date: Sat, 29 Oct 2005 12:16:00 -0400 Message-ID: Thread-Topic: Two Drafts for Resilience of Control Plane Thread-Index: AcXckpMNqIqx8cGPSn+y34NSOd+/cQAEQtAA From: "Zafar Ali \(zali\)" To: Cc: , "John E" , , , "Igor Bryskin" , "Kim Young Hwa" , X-OriginalArrivalTime: 29 Oct 2005 16:16:01.0331 (UTC) FILETIME=[0DBF3830:01C5DCA4] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 9178bae9f85419fdc08e9f2c86e345d0 Content-Transfer-Encoding: quoted-printable =20 > -----Original Message----- > From: ibryskin@movaz.com [mailto:ibryskin@movaz.com]=20 > Sent: Saturday, October 29, 2005 10:10 AM > To: Zafar Ali (zali) > Cc: ibryskin@movaz.com; Drake@movaz.com; John E;=20 > dpapadimitriou@psg.com; dimitri.papadimitriou@alcatel.be;=20 > Igor Bryskin; Kim Young Hwa; ccamp@ops.ietf.org > Subject: RE: Two Drafts for Resilience of Control Plane >=20 > Zafar, > >> c) leave LSP as it is and wait for the dead controller to > >> be replaced or > >> repaired. This would mean the need to perform normal=20 > operations like,=20 > >> for example, monitoring of data plane alarms, changing LSP admin=20 > >> status (for example, disabling alarms on all nodes), perform power=20 > >> monitoring and equalization, perform recovery operation in=20 > case of a=20 > >> fatal data plane failure. All what depends on hop-by-hop signaling=20 > >> won't work today. > >> Don't tell me that these problems are fabricated; they are real=20 > >> because they are raised by the customers. Dimitri seems to=20 > understand=20 > >> the problem but he is saying that the CP in this case is hardly of=20 > >> any use. This IMO is a dangerous statement for the future of CP in=20 > >> non-packet environments. > >> The Management plane aficionados will jump on it and say that=20 > >> management plane does not have such a problem - NMS has a direct=20 > >> access to any NE on the network, so it can do all=20 > necessary cleanup=20 > >> no matter what happened. > >> Customers will say: "Well, if there are situations when CP=20 > suddenly=20 > >> becomes useless and we have to use management plane=20 > anyway, why would=20 > >> we use the CP in the first place?' > >> > >> Fortunately, I believe that the problems could be solved=20 > entirely via=20 > >> CP by making it more resilient. Hence, CP resilience is a good=20 > >> direction to work on within CCAMP WG > > > > Igor, > > > > W.r.t. option C, please note that traffic CANNOT be forwarded in a=20 > > "head-less mode" for a very long time . If you control=20 > network melts=20 > > or a peering controller goes down, either RSVP GR or refreshes will=20 > > take care of the clean-up of the affected RSVP states.=20 > Similarly LMP=20 > > CC SM will go down (after states are cleared, i.e.,=20 > degraded-to-down),=20 > > eventually removing the TE links from topology. > > >=20 > Sticking to the example I described: > a) absence of RSVP refreshes does not affect data plane in any way; > b) use of LMP is not mandatory and, becides, I don't see now it helps. > True, the TE link could be withdrawn, however, the LSP will=20 > still be operational Isn't the problem is at "B" only and control plane at the other node (or controller for other nodes) still working fine? If yes, local controllers will withdraw RSVP states; hence correct the data plane.=20 Thanks Regards... Zafar=20 >=20 > Igor >=20 >=20 > > Thanks > > > > Regards... Zafar > > > >> > >> Igor > >> > >> > If "Considerable period of time" is not equal to infinity, > >> then there > >> > will be an RSVP graceful restart. If a controller is > >> really and truly > >> > dead, then presumably the operator will either replace it > >> or re-assign > >> > its data-plane resources to another signaling controller. > >> In either > >> > case, there will then be an RSVP graceful restart. > >> > > >> > Thanks, > >> > > >> > John > >> > > >> > > >> > > >> >> -----Original Message----- > >> >> From: ibryskin@movaz.com [mailto:ibryskin@movaz.com] > >> >> Sent: Friday, October 28, 2005 1:00 PM > >> >> To: Drake, John E > >> >> Cc: ibryskin@movaz.com; dpapadimitriou@psg.com;=20 > >> >> dimitri.papadimitriou@alcatel.be; Igor Bryskin; Zafar Ali; > >> Kim Young > >> > Hwa; > >> >> ccamp@ops.ietf.org > >> >> Subject: RE: Two Drafts for Resilience of Control Plane > >> >> > >> >> John, > >> >> > >> >> I think you missed my point here. "Dead" controllers in=20 > my example=20 > >> >> *do > >> >> not* come back for a considerable period of time. So=20 > there are no > >> > restarts > >> >> here (graceful or not graceful) :=3D) > >> >> > >> >> Igor > >> >> > >> >> > What part of your problem, as stated below, is not > >> handled by RSVP > >> >> > graceful restart? > >> >> > > >> >> >> -----Original Message----- > >> >> >> From: ibryskin@movaz.com [mailto:ibryskin@movaz.com] > >> >> >> Sent: Friday, October 28, 2005 11:41 AM > >> >> >> To: Drake, John E > >> >> >> Cc: dpapadimitriou@psg.com; > >> dimitri.papadimitriou@alcatel.be; Igor > >> >> >> Bryskin; Zafar Ali; Kim Young Hwa; ccamp@ops.ietf.org > >> >> >> Subject: RE: Two Drafts for Resilience of Control Plane > >> >> >> > >> >> >> Hi, > >> >> >> > >> >> >> Here is one of the problems that I've been thinking for > >> a while - > >> >> > control > >> >> >> plane partitioned LSPs. Suppose one or more signaling > >> controllers > >> >> > managing > >> >> >> some LSP went out of service leaving the LSP's data > >> plane intact. > >> > As > >> >> > far > >> >> >> as the user is concerned such LSP is perfectly healthy and > >> >> > operational. > >> >> >> Such situation could last for a considerable period of > >> time. Do we > >> >> > need to > >> >> >> manage such LSP via control plane? Sure, we must be=20 > capable to=20 > >> >> >> tear > >> >> > down > >> >> >> such LSP, perform mb4b rerouting, distribute alarms between > >> >> > operational > >> >> >> controllers, signal data plane faults and perform recovery > >> > switchover, > >> >> >> modify LSP status, etc. Can we do this today? No,=20 > but with some > >> >> >> (signaling) extensions the problem I believe is > >> solvable. Is this > >> > some > >> >> >> artificial, "fabricated" problem? No, I think it is > >> real. Does it > >> > fall > >> >> >> under the control plane resilience problem space? I=20 > believe it > >> > does. > >> >> >> > >> >> >> Igor > >> >> >> > >> >> >> > I agree with Zafar and Dimitri. If someone wanted to=20 > >> >> >> > document > >> > the > >> >> > GMPLS > >> >> >> > control plane resiliency features, as was done for GMPLS > >> > addressing, > >> >> >> > that might be a useful activity. > >> >> >> > > >> >> >> >> -----Original Message----- > >> >> >> >> From: dimitri papadimitriou=20 > [mailto:dpapadimitriou@psg.com] > >> >> >> >> Sent: Friday, October 28, 2005 9:56 AM > >> >> >> >> To: Igor Bryskin > >> >> >> >> Cc: Zafar Ali (zali); Kim Young Hwa; ccamp@ops.ietf.org > >> >> >> >> Subject: Re: Two Drafts for Resilience of Control Plane > >> >> >> >> > >> >> >> >> igor - > >> >> >> >> > >> >> >> >> over time CCAMP came with a set of mechanims to > >> improve control > >> >> > plane > >> >> >> >> resilience (RSVP and LMP GR upon channel/node > >> failure) other WG > >> >> >> > protocol > >> >> >> >> work are also usable used here OSPF GR, etc. ... on the=20 > >> >> >> >> other > >> > side, > >> >> >> >> mechanism such as link bundling have built-in resilience > >> >> > capabilities > >> >> >> >> and most GMPLS control plane capabilities have=20 > been designed > >> > such > >> >> > as > >> >> >> > to > >> >> >> >> be independent of the control plane realisation (in-band, > >> >> > out-of-band, > >> >> >> >> etc.) > >> >> >> >> > >> >> >> >> so indeed i share the concern of Zafar what could=20 > we do more > >> > here > >> >> > than > >> >> >> >> document these tools and provide our experience in > >> using them; > >> >> >> >> > >> >> >> >> now, before stating there are (potential) > >> problems(s) arising - > >> >> > would > >> >> >> >> you please be more specific on what are these potential > >> >> >> >> issue(s) > >> >> >> > and/or > >> >> >> >> problems ? (not related to policy/config. - note: all the=20 > >> >> >> >> issues > >> >> > you > >> >> >> >> have pointed here below are simply policy/config specific=20 > >> >> >> >> but > >> > none > >> >> > of > >> >> >> >> them highlights a missing IP control plane > >> resiliency feature) > >> >> >> >> > >> >> >> >> thanks, > >> >> >> >> - dimitri. > >> >> >> >> > >> >> >> >> > >> >> >> >> Igor Bryskin wrote: > >> >> >> >> > >> >> >> >> > Zafar, > >> >> >> >> > > >> >> >> >> > The problem arises when the control plane is > >> decoupled from > >> >> >> >> > the data plane. The question is do we need such > >> decoupling in > >> >> >> >> > IP networks? Consider, for example, the situation when=20 > >> >> >> >> > several parallel PSC data links bundled together and=20 > >> >> >> >> > controlled by a single control channel. > >> >> >> >> > Does it mean in this case that when the control > >> channel fails > >> >> >> >> > all associated data links also fail? Do we need to > >> reroute in > >> >> >> >> > this case LSPs that use the data links? Can we > >> rely in this > >> >> >> >> > case on control plane indications to decide whether an=20 > >> >> >> >> > associated data link is healthy or not (in other > >> words, can > >> >> >> >> > we rely on RSVP Hellos or should we use, for > >> example, BTD)? > >> >> >> >> > Should we be capable to recover control=20 > channels without=20 > >> >> >> >> > disturbing data plane? I think control plane=20 > resilience is=20 > >> >> >> >> > important for all layers. You are right, Internet > >> does work, > >> >> >> >> > however, we do need for some reason TE and (fast) > >> recovery in > >> >> >> >> > IP as much as in other layers,don't we? > >> >> >> >> > > >> >> >> >> > Cheers, > >> >> >> >> > Igor > >> >> >> >> > > >> >> >> >> > --- "Zafar Ali (zali)" wrote: > >> >> >> >> > > >> >> >> >> > > >> >> >> >> >>Hi All, > >> >> >> >> >> > >> >> >> >> >>I am unable to understand the problem we are > >> trying to solve > >> >> >> >> >>or fabricate. My control network is IP based and IP has=20 > >> >> >> >> >>proven resiliency (Internet *does* work), why > >> would I like to > >> >> >> >> >>take control plan resiliency problem at a layer=20 > *above-IP*=20 > >> >> >> >> >>and complicate my life. Did I miss something? > >> >> >> >> >> > >> >> >> >> >>Thanks > >> >> >> >> >> > >> >> >> >> >>Regards... Zafar > >> >> >> >> >> > >> >> >> >> >> > >> >> >> >> >>________________________________ > >> >> >> >> >> > >> >> >> >> >> From: owner-ccamp@ops.ietf.org=20 > >> >> >> >> >>[mailto:owner-ccamp@ops.ietf.org] > >> >> >> >> >>On Behalf Of Kim Young Hwa > >> >> >> >> >> Sent: Friday, October 28, 2005 6:04 AM > >> >> >> >> >> To: ccamp@ops.ietf.org > >> >> >> >> >> Subject: Two Drafts for Resilience of=20 > Control Plane > >> >> >> >> >> > >> >> >> >> >> > >> >> >> >> >> Dear all, > >> >> >> >> >> > >> >> >> >> >> I posted two drafts for the resilience=20 > of control plane. > >> >> >> >> >> One is for requirements of the resilience of > >> control plane, > >> >> >> >> >>the other is for a protocol specification as a=20 > solution of=20 > >> >> >> >> >>that . > >> >> >> >> >> These are now available at: > >> >> >> >> >> > >> >> >> >> >> > >> >> >> >> > > >> >> >> >> > > >> >> > > >> http://www.ietf.org/internet-drafts/draft-kim-ccamp-cpr-reqts-01.tx > >> >> > t > >> >> >> >> > > >> >> >> >> >> > >> >> >> >> >> > >> >> >> >> > > >> >> >> >> > > >> >> >> > > >> >> > > >> > > >>=20 > http://www.ietf.org/internet-drafts/draft-kim-ccamp-accp-protocol-00. > >> t > >> > xt > >> >> >> >> > > >> >> >> >> >> > >> >> >> >> >> I want your comments. > >> >> >> >> >> > >> >> >> >> >> Regards > >> >> >> >> >> > >> >> >> >> >> Young. > >> >> >> >> >> > >> >> >> >> >> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D> >>=09 > Young-Hwa Kim > >> >> >> >> >> Principal Member / Ph.D > >> >> >> >> >> BcN Research Division, ETRI > >> >> >> >> >> Tel: +82-42-860-5819 > >> >> >> >> >> Fax: +82-42-860-5440 > >> >> >> >> >> e-mail: yhwkim@etri.re.kr > >> >> >> >> >> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D> >> > >> >> >> >> >> > >> >> >> >> > > >> >> >> >> > > >> >> >> > > >> >> > > >> > > >>=20 > = >> > or > >> >> >> >> > > >> >> >> >> > > >> >> >> > > >> >> > > >> > > >>=20 > = g&name=3Dccamp%40ops.ietf.org&fromemail=3Dyhwkim@etri.re.kr&messageid=3D%= 3C > >> 8 > >> > 63 > >> >> >> >> > > >> >> >> >> >>0a6db-0c31-49ab-a798-13b0dda04553@etri.re.kr%3E> > >> >> >> >> >> > >> >> >> >> >> > >> >> >> >> > > >> >> >> >> > > >> >> >> >> > > >> >> >> >> > > >> >> >> >> > > >> >> >> >> > > >> >> >> >> > __________________________________ > >> >> >> >> > Yahoo! Mail - PC Magazine Editors' Choice 2005=20 > >> >> >> >> > http://mail.yahoo.com > >> >> >> >> > > >> >> >> >> > > >> >> >> >> > . > >> >> >> >> > > >> >> >> > > >> >> >> > > >> >> >> > > >> >> > > >> >> > > >> > > >> > > >> > > >=20 From owner-ccamp@ops.ietf.org Sat Oct 29 13:36:12 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVucm-00035z-2k for ccamp-archive@megatron.ietf.org; Sat, 29 Oct 2005 13:36:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12267 for ; Sat, 29 Oct 2005 13:35:54 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVuqR-00011C-Gt for ccamp-archive@ietf.org; Sat, 29 Oct 2005 13:50:29 -0400 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EVuY6-000AVS-R2 for ccamp-data@psg.com; Sat, 29 Oct 2005 17:31:22 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=3.1.0 Received: from [70.158.43.219] (helo=jera.movaz.com) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EVuY6-000AV0-5Q for ccamp@ops.ietf.org; Sat, 29 Oct 2005 17:31:22 +0000 Received: by jera.movaz.com (Postfix, from userid 30) id F26C22DFB5; Sat, 29 Oct 2005 13:31:20 -0400 (EDT) Received: from 68.100.80.11 (SquirrelMail authenticated user ibryskin) by webmail.movaz.com with HTTP; Sat, 29 Oct 2005 13:31:20 -0400 (EDT) Message-ID: <3038.68.100.80.11.1130607080.squirrel@webmail.movaz.com> In-Reply-To: <626FC7C6A97381468FB872072AB5DDC8369713@XCH-SW-42.sw.nos.boeing.com> References: <626FC7C6A97381468FB872072AB5DDC8369713@XCH-SW-42.sw.nos.boeing.com> Date: Sat, 29 Oct 2005 13:31:20 -0400 (EDT) Subject: RE: Two Drafts for Resilience of Control Plane From: ibryskin@movaz.com To: "Drake, John E" Cc: ibryskin@movaz.com, "Zafar Ali" , drake@movaz.com, dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be, "Igor Bryskin" , "Kim Young Hwa" , ccamp@ops.ietf.org User-Agent: SquirrelMail/1.4.1 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 Importance: Normal Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 1.2 (+) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id NAA12267 > Igor, > > If a node looses control plane connectivity to its adjacent nodes, then > in the interval until that connectivity is restored, the nodes adjacent > to that node will take it and its links out of the TE link state > database so that no new LSPs will be routed through that node. I never said that the problem is about new LSPs > Existing LSPS can be maintained. The endpoints of each LSP will be > informed of the control plane failure, so that they can tear the LSP down if configured to do so, after a configured interval. Here is the problem. The CP comes into play when some entity (for example= , TL1 agent) issues a provisioning request on the service ingress to setup one or more LSPs. All subsequent management is provided via this ingress node. One cannot pre-configure what to do, say, on LSP egress node becaus= e all actions are service specific real-time decisions based on numerous policies (time of day, network state, identity of the service user, SLAs and many other things). In other words all operations should be controlle= d via ingress node. > connectivity to multiple nodes along the path of an LSP are lost, there > may be hung resources. To reclaim those resources, any node that loses > CP connectivity to an adjacent node can be configured to tear down LSPs > through that node after a configured interval. > > I am dubious the NM connectivity would exist if CP connectivity would =D8 exist, so one can't resort to NM to save the day. I was talking about NMS connectivity with =93live=94 NEs via management = network > > I think we are done. > I think too. > Thanks, > > John > >> -----Original Message----- >> From: ibryskin@movaz.com [mailto:ibryskin@movaz.com] >> Sent: Saturday, October 29, 2005 7:40 AM >> To: Drake, John E >> Cc: ibryskin@movaz.com; Zafar Ali; drake@movaz.com; >> dpapadimitriou@psg.com; dimitri.papadimitriou@alcatel.be; Igor > Bryskin; >> Kim Young Hwa; ccamp@ops.ietf.org >> Subject: RE: Two Drafts for Resilience of Control Plane >> >> > >> >> Sticking to the example I described: >> >> a) absence of RSVP refreshes does not affect data plane in any way; >> >> b) use of LMP is not mandatory and, becides, I don't see now it > helps. >> >> True, the TE link could be withdrawn, however, the LSP will still > be >> >> operational >> > [JD] >> > >> > In your example, PathTear downstream and PathErr w/ state removed >> > upstream would work quite nicely. >> >> True, but it means that operator needs to issue two management > requests >> from two controllers. But this is not how control plane is supposed to >> work, isn't it? - it should be able to manage an LSP from a single >> (usually, ingress)controller. The way you described it the operator > needs >> to figure out where to go and issue these requests. And what if this > LSP >> is not an S-PVC, rather, SVC created via UNI or ENNI request? >> >> As a matter of local policy, a node >> > always has the option of tearing down LSPs through adjacent nodes > with >> > which control plane connectivity has been lost, after a configured >> > interval has elapsed. >> >> Sorry, for envirionments where control and data planes are not > congruent >> what you just said is an explicit NO-OPTION, i.e. must not be done - > you >> cannot destroy data plane just because you lost connectivity in the >> control plane. >> >> Igor > > From owner-ccamp@ops.ietf.org Sat Oct 29 13:41:29 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVuht-0004yZ-2h for ccamp-archive@megatron.ietf.org; Sat, 29 Oct 2005 13:41:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12463 for ; Sat, 29 Oct 2005 13:41:11 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVuvh-00019S-GN for ccamp-archive@ietf.org; Sat, 29 Oct 2005 13:55:46 -0400 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EVue8-000FmP-1U for ccamp-data@psg.com; Sat, 29 Oct 2005 17:37:36 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=3.1.0 Received: from [70.158.43.219] (helo=jera.movaz.com) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EVue6-000FmC-QM for ccamp@ops.ietf.org; Sat, 29 Oct 2005 17:37:35 +0000 Received: by jera.movaz.com (Postfix, from userid 30) id 8FD112E789; Sat, 29 Oct 2005 13:37:33 -0400 (EDT) Received: from 68.100.80.11 (SquirrelMail authenticated user ibryskin) by webmail.movaz.com with HTTP; Sat, 29 Oct 2005 13:37:33 -0400 (EDT) Message-ID: <3041.68.100.80.11.1130607453.squirrel@webmail.movaz.com> In-Reply-To: References: Date: Sat, 29 Oct 2005 13:37:33 -0400 (EDT) Subject: RE: Two Drafts for Resilience of Control Plane From: ibryskin@movaz.com To: "Zafar Ali (zali)" Cc: ibryskin@movaz.com, drake@movaz.com, "John E" , dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be, "Igor Bryskin" , "Kim Young Hwa" , ccamp@ops.ietf.org User-Agent: SquirrelMail/1.4.1 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 Importance: Normal Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 1.2 (+) X-Scan-Signature: 21f6736b171db90b7af90d77f0c0e285 Content-Transfer-Encoding: 8bit > > >> -----Original Message----- >> From: ibryskin@movaz.com [mailto:ibryskin@movaz.com] >> Sent: Saturday, October 29, 2005 10:10 AM >> To: Zafar Ali (zali) >> Cc: ibryskin@movaz.com; Drake@movaz.com; John E; >> dpapadimitriou@psg.com; dimitri.papadimitriou@alcatel.be; >> Igor Bryskin; Kim Young Hwa; ccamp@ops.ietf.org >> Subject: RE: Two Drafts for Resilience of Control Plane >> >> Zafar, >> >> c) leave LSP as it is and wait for the dead controller to >> >> be replaced or >> >> repaired. This would mean the need to perform normal >> operations like, >> >> for example, monitoring of data plane alarms, changing LSP admin >> >> status (for example, disabling alarms on all nodes), perform power >> >> monitoring and equalization, perform recovery operation in >> case of a >> >> fatal data plane failure. All what depends on hop-by-hop signaling >> >> won't work today. >> >> Don't tell me that these problems are fabricated; they are real >> >> because they are raised by the customers. Dimitri seems to >> understand >> >> the problem but he is saying that the CP in this case is hardly of >> >> any use. This IMO is a dangerous statement for the future of CP in >> >> non-packet environments. >> >> The Management plane aficionados will jump on it and say that >> >> management plane does not have such a problem - NMS has a direct >> >> access to any NE on the network, so it can do all >> necessary cleanup >> >> no matter what happened. >> >> Customers will say: "Well, if there are situations when CP >> suddenly >> >> becomes useless and we have to use management plane >> anyway, why would >> >> we use the CP in the first place?' >> >> >> >> Fortunately, I believe that the problems could be solved >> entirely via >> >> CP by making it more resilient. Hence, CP resilience is a good >> >> direction to work on within CCAMP WG >> > >> > Igor, >> > >> > W.r.t. option C, please note that traffic CANNOT be forwarded in a >> > "head-less mode" for a very long time . If you control >> network melts >> > or a peering controller goes down, either RSVP GR or refreshes will >> > take care of the clean-up of the affected RSVP states. >> Similarly LMP >> > CC SM will go down (after states are cleared, i.e., >> degraded-to-down), >> > eventually removing the TE links from topology. >> > >> >> Sticking to the example I described: >> a) absence of RSVP refreshes does not affect data plane in any way; >> b) use of LMP is not mandatory and, becides, I don't see now it helps. >> True, the TE link could be withdrawn, however, the LSP will >> still be operational > > Isn't the problem is at "B" only and control plane at the other node (or > controller for other nodes) still working fine? If yes, local > controllers will withdraw RSVP states; hence correct the data plane. > Again, GMPLS controller cannot remove control state and destroy data plane just because it does not get refreshes from adjacent controllers. Remember, CP and DP could be completely independent networks Igor > Thanks > > Regards... Zafar > >> >> Igor >> >> >> > Thanks >> > >> > Regards... Zafar >> > >> >> >> >> Igor >> >> >> >> > If "Considerable period of time" is not equal to infinity, >> >> then there >> >> > will be an RSVP graceful restart. If a controller is >> >> really and truly >> >> > dead, then presumably the operator will either replace it >> >> or re-assign >> >> > its data-plane resources to another signaling controller. >> >> In either >> >> > case, there will then be an RSVP graceful restart. >> >> > >> >> > Thanks, >> >> > >> >> > John >> >> > >> >> > >> >> > >> >> >> -----Original Message----- >> >> >> From: ibryskin@movaz.com [mailto:ibryskin@movaz.com] >> >> >> Sent: Friday, October 28, 2005 1:00 PM >> >> >> To: Drake, John E >> >> >> Cc: ibryskin@movaz.com; dpapadimitriou@psg.com; >> >> >> dimitri.papadimitriou@alcatel.be; Igor Bryskin; Zafar Ali; >> >> Kim Young >> >> > Hwa; >> >> >> ccamp@ops.ietf.org >> >> >> Subject: RE: Two Drafts for Resilience of Control Plane >> >> >> >> >> >> John, >> >> >> >> >> >> I think you missed my point here. "Dead" controllers in >> my example >> >> >> *do >> >> >> not* come back for a considerable period of time. So >> there are no >> >> > restarts >> >> >> here (graceful or not graceful) :=) >> >> >> >> >> >> Igor >> >> >> >> >> >> > What part of your problem, as stated below, is not >> >> handled by RSVP >> >> >> > graceful restart? >> >> >> > >> >> >> >> -----Original Message----- >> >> >> >> From: ibryskin@movaz.com [mailto:ibryskin@movaz.com] >> >> >> >> Sent: Friday, October 28, 2005 11:41 AM >> >> >> >> To: Drake, John E >> >> >> >> Cc: dpapadimitriou@psg.com; >> >> dimitri.papadimitriou@alcatel.be; Igor >> >> >> >> Bryskin; Zafar Ali; Kim Young Hwa; ccamp@ops.ietf.org >> >> >> >> Subject: RE: Two Drafts for Resilience of Control Plane >> >> >> >> >> >> >> >> Hi, >> >> >> >> >> >> >> >> Here is one of the problems that I've been thinking for >> >> a while - >> >> >> > control >> >> >> >> plane partitioned LSPs. Suppose one or more signaling >> >> controllers >> >> >> > managing >> >> >> >> some LSP went out of service leaving the LSP's data >> >> plane intact. >> >> > As >> >> >> > far >> >> >> >> as the user is concerned such LSP is perfectly healthy and >> >> >> > operational. >> >> >> >> Such situation could last for a considerable period of >> >> time. Do we >> >> >> > need to >> >> >> >> manage such LSP via control plane? Sure, we must be >> capable to >> >> >> >> tear >> >> >> > down >> >> >> >> such LSP, perform mb4b rerouting, distribute alarms between >> >> >> > operational >> >> >> >> controllers, signal data plane faults and perform recovery >> >> > switchover, >> >> >> >> modify LSP status, etc. Can we do this today? No, >> but with some >> >> >> >> (signaling) extensions the problem I believe is >> >> solvable. Is this >> >> > some >> >> >> >> artificial, "fabricated" problem? No, I think it is >> >> real. Does it >> >> > fall >> >> >> >> under the control plane resilience problem space? I >> believe it >> >> > does. >> >> >> >> >> >> >> >> Igor >> >> >> >> >> >> >> >> > I agree with Zafar and Dimitri. If someone wanted to >> >> >> >> > document >> >> > the >> >> >> > GMPLS >> >> >> >> > control plane resiliency features, as was done for GMPLS >> >> > addressing, >> >> >> >> > that might be a useful activity. >> >> >> >> > >> >> >> >> >> -----Original Message----- >> >> >> >> >> From: dimitri papadimitriou >> [mailto:dpapadimitriou@psg.com] >> >> >> >> >> Sent: Friday, October 28, 2005 9:56 AM >> >> >> >> >> To: Igor Bryskin >> >> >> >> >> Cc: Zafar Ali (zali); Kim Young Hwa; ccamp@ops.ietf.org >> >> >> >> >> Subject: Re: Two Drafts for Resilience of Control Plane >> >> >> >> >> >> >> >> >> >> igor - >> >> >> >> >> >> >> >> >> >> over time CCAMP came with a set of mechanims to >> >> improve control >> >> >> > plane >> >> >> >> >> resilience (RSVP and LMP GR upon channel/node >> >> failure) other WG >> >> >> >> > protocol >> >> >> >> >> work are also usable used here OSPF GR, etc. ... on the >> >> >> >> >> other >> >> > side, >> >> >> >> >> mechanism such as link bundling have built-in resilience >> >> >> > capabilities >> >> >> >> >> and most GMPLS control plane capabilities have >> been designed >> >> > such >> >> >> > as >> >> >> >> > to >> >> >> >> >> be independent of the control plane realisation (in-band, >> >> >> > out-of-band, >> >> >> >> >> etc.) >> >> >> >> >> >> >> >> >> >> so indeed i share the concern of Zafar what could >> we do more >> >> > here >> >> >> > than >> >> >> >> >> document these tools and provide our experience in >> >> using them; >> >> >> >> >> >> >> >> >> >> now, before stating there are (potential) >> >> problems(s) arising - >> >> >> > would >> >> >> >> >> you please be more specific on what are these potential >> >> >> >> >> issue(s) >> >> >> >> > and/or >> >> >> >> >> problems ? (not related to policy/config. - note: all the >> >> >> >> >> issues >> >> >> > you >> >> >> >> >> have pointed here below are simply policy/config specific >> >> >> >> >> but >> >> > none >> >> >> > of >> >> >> >> >> them highlights a missing IP control plane >> >> resiliency feature) >> >> >> >> >> >> >> >> >> >> thanks, >> >> >> >> >> - dimitri. >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> Igor Bryskin wrote: >> >> >> >> >> >> >> >> >> >> > Zafar, >> >> >> >> >> > >> >> >> >> >> > The problem arises when the control plane is >> >> decoupled from >> >> >> >> >> > the data plane. The question is do we need such >> >> decoupling in >> >> >> >> >> > IP networks? Consider, for example, the situation when >> >> >> >> >> > several parallel PSC data links bundled together and >> >> >> >> >> > controlled by a single control channel. >> >> >> >> >> > Does it mean in this case that when the control >> >> channel fails >> >> >> >> >> > all associated data links also fail? Do we need to >> >> reroute in >> >> >> >> >> > this case LSPs that use the data links? Can we >> >> rely in this >> >> >> >> >> > case on control plane indications to decide whether an >> >> >> >> >> > associated data link is healthy or not (in other >> >> words, can >> >> >> >> >> > we rely on RSVP Hellos or should we use, for >> >> example, BTD)? >> >> >> >> >> > Should we be capable to recover control >> channels without >> >> >> >> >> > disturbing data plane? I think control plane >> resilience is >> >> >> >> >> > important for all layers. You are right, Internet >> >> does work, >> >> >> >> >> > however, we do need for some reason TE and (fast) >> >> recovery in >> >> >> >> >> > IP as much as in other layers,don't we? >> >> >> >> >> > >> >> >> >> >> > Cheers, >> >> >> >> >> > Igor >> >> >> >> >> > >> >> >> >> >> > --- "Zafar Ali (zali)" wrote: >> >> >> >> >> > >> >> >> >> >> > >> >> >> >> >> >>Hi All, >> >> >> >> >> >> >> >> >> >> >> >>I am unable to understand the problem we are >> >> trying to solve >> >> >> >> >> >>or fabricate. My control network is IP based and IP has >> >> >> >> >> >>proven resiliency (Internet *does* work), why >> >> would I like to >> >> >> >> >> >>take control plan resiliency problem at a layer >> *above-IP* >> >> >> >> >> >>and complicate my life. Did I miss something? >> >> >> >> >> >> >> >> >> >> >> >>Thanks >> >> >> >> >> >> >> >> >> >> >> >>Regards... Zafar >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >>________________________________ >> >> >> >> >> >> >> >> >> >> >> >> From: owner-ccamp@ops.ietf.org >> >> >> >> >> >>[mailto:owner-ccamp@ops.ietf.org] >> >> >> >> >> >>On Behalf Of Kim Young Hwa >> >> >> >> >> >> Sent: Friday, October 28, 2005 6:04 AM >> >> >> >> >> >> To: ccamp@ops.ietf.org >> >> >> >> >> >> Subject: Two Drafts for Resilience of >> Control Plane >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> Dear all, >> >> >> >> >> >> >> >> >> >> >> >> I posted two drafts for the resilience >> of control plane. >> >> >> >> >> >> One is for requirements of the resilience of >> >> control plane, >> >> >> >> >> >>the other is for a protocol specification as a >> solution of >> >> >> >> >> >>that . >> >> >> >> >> >> These are now available at: >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> > >> >> >> >> >> > >> >> >> > >> >> http://www.ietf.org/internet-drafts/draft-kim-ccamp-cpr-reqts-01.tx >> >> >> > t >> >> >> >> >> > >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> > >> >> >> >> >> > >> >> >> >> > >> >> >> > >> >> > >> >> >> http://www.ietf.org/internet-drafts/draft-kim-ccamp-accp-protocol-00. >> >> t >> >> > xt >> >> >> >> >> > >> >> >> >> >> >> >> >> >> >> >> >> I want your comments. >> >> >> >> >> >> >> >> >> >> >> >> Regards >> >> >> >> >> >> >> >> >> >> >> >> Young. >> >> >> >> >> >> >> >> >> >> >> >> ===================================> >> >> Young-Hwa Kim >> >> >> >> >> >> Principal Member / Ph.D >> >> >> >> >> >> BcN Research Division, ETRI >> >> >> >> >> >> Tel: +82-42-860-5819 >> >> >> >> >> >> Fax: +82-42-860-5440 >> >> >> >> >> >> e-mail: yhwkim@etri.re.kr >> >> >> >> >> >> ===================================> >> >> >> >> >> >> >> >> >> >> >> >> > >> >> >> >> >> > >> >> >> >> > >> >> >> > >> >> > >> >> >> > >> > or >> >> >> >> >> > >> >> >> >> >> > >> >> >> >> > >> >> >> > >> >> > >> >> >> g&name=ccamp%40ops.ietf.org&fromemail=yhwkim@etri.re.kr&messageid=%3C >> >> 8 >> >> > 63 >> >> >> >> >> > >> >> >> >> >> >>0a6db-0c31-49ab-a798-13b0dda04553@etri.re.kr%3E> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> > >> >> >> >> >> > >> >> >> >> >> > >> >> >> >> >> > >> >> >> >> >> > >> >> >> >> >> > >> >> >> >> >> > __________________________________ >> >> >> >> >> > Yahoo! Mail - PC Magazine Editors' Choice 2005 >> >> >> >> >> > http://mail.yahoo.com >> >> >> >> >> > >> >> >> >> >> > >> >> >> >> >> > . >> >> >> >> >> > >> >> >> >> > >> >> >> >> > >> >> >> >> > >> >> >> > >> >> >> > >> >> > >> >> > >> >> >> > >> > From owner-ccamp@ops.ietf.org Sat Oct 29 13:45:27 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVuli-0006OJ-SW for ccamp-archive@megatron.ietf.org; Sat, 29 Oct 2005 13:45:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12664 for ; Sat, 29 Oct 2005 13:45:09 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVuzV-0001Gd-La for ccamp-archive@ietf.org; Sat, 29 Oct 2005 13:59:44 -0400 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EVui6-000G4E-5q for ccamp-data@psg.com; Sat, 29 Oct 2005 17:41:42 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [171.71.176.72] (helo=sj-iport-3.cisco.com) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EVui0-000G3k-KA for ccamp@ops.ietf.org; Sat, 29 Oct 2005 17:41:36 +0000 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-3.cisco.com with ESMTP; 29 Oct 2005 10:41:30 -0700 X-IronPort-AV: i="3.97,266,1125903600"; d="scan'208"; a="358427507:sNHT26858836" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j9THfQ94024715; Sat, 29 Oct 2005 10:41:27 -0700 (PDT) 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); Sat, 29 Oct 2005 13:41:26 -0400 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: Two Drafts for Resilience of Control Plane Date: Sat, 29 Oct 2005 13:41:25 -0400 Message-ID: Thread-Topic: Two Drafts for Resilience of Control Plane Thread-Index: AcXcr3hb4yh8Q8iVSk2gZUt7/xg56AAAEXFg From: "Zafar Ali \(zali\)" To: Cc: , "John E" , , , "Igor Bryskin" , "Kim Young Hwa" , X-OriginalArrivalTime: 29 Oct 2005 17:41:26.0491 (UTC) FILETIME=[FC9492B0:01C5DCAF] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: quoted-printable > >> > > >> > Igor, > >> > > >> > W.r.t. option C, please note that traffic CANNOT be=20 > forwarded in a=20 > >> > "head-less mode" for a very long time . If you control > >> network melts > >> > or a peering controller goes down, either RSVP GR or=20 > refreshes will=20 > >> > take care of the clean-up of the affected RSVP states. > >> Similarly LMP > >> > CC SM will go down (after states are cleared, i.e., > >> degraded-to-down), > >> > eventually removing the TE links from topology. > >> > > >> > >> Sticking to the example I described: > >> a) absence of RSVP refreshes does not affect data plane in any way; > >> b) use of LMP is not mandatory and, becides, I don't see=20 > now it helps. > >> True, the TE link could be withdrawn, however, the LSP=20 > will still be=20 > >> operational > > > > Isn't the problem is at "B" only and control plane at the=20 > other node=20 > > (or controller for other nodes) still working fine? If yes, local=20 > > controllers will withdraw RSVP states; hence correct the data plane. > > >=20 > Again, GMPLS controller cannot remove control state and=20 > destroy data plane just because it does not get refreshes=20 > from adjacent controllers. Then how states get ever destoryed, even in normal case, e.g., if head end sends a ptear and all controllers are up?=20 Thanks Regards... Zafar=20 From owner-ccamp@ops.ietf.org Sun Oct 30 14:34:28 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWIvd-0001UC-FB for ccamp-archive@megatron.ietf.org; Sun, 30 Oct 2005 14:33:17 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06638 for ; Sun, 30 Oct 2005 14:21:06 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EWGUG-0004fK-B1 for ccamp-archive@ietf.org; Sun, 30 Oct 2005 11:56:54 -0500 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EWG6d-00087I-IT for ccamp-data@psg.com; Sun, 30 Oct 2005 16:32:27 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [64.102.122.148] (helo=rtp-iport-1.cisco.com) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EWG6c-000874-NT for ccamp@ops.ietf.org; Sun, 30 Oct 2005 16:32:26 +0000 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 30 Oct 2005 08:32:26 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.97,267,1125903600"; d="scan'208"; a="14195595:sNHT24094020" 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 j9UGVv2L003493; Sun, 30 Oct 2005 11:32:21 -0500 (EST) 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); Sun, 30 Oct 2005 11:32:19 -0500 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: Two Drafts for Resilience of Control Plane Date: Sun, 30 Oct 2005 11:32:18 -0500 Message-ID: Thread-Topic: Two Drafts for Resilience of Control Plane Thread-Index: AcXdZkYp8+2roqIaTpWMcrN6jVo3zgACKc9A From: "Zafar Ali \(zali\)" To: "Igor Bryskin" , Cc: , "John E" , , , "Kim Young Hwa" , X-OriginalArrivalTime: 30 Oct 2005 16:32:19.0619 (UTC) FILETIME=[7F43DF30:01C5DD6F] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Content-Transfer-Encoding: quoted-printable Igor,=20 > -----Original Message----- > From: Igor Bryskin [mailto:i_bryskin@yahoo.com]=20 > Sent: Sunday, October 30, 2005 10:26 AM > To: Zafar Ali (zali); ibryskin@movaz.com > Cc: drake@movaz.com; John E; dpapadimitriou@psg.com;=20 > dimitri.papadimitriou@alcatel.be; Igor Bryskin; Kim Young=20 > Hwa; ccamp@ops.ietf.org > Subject: RE: Two Drafts for Resilience of Control Plane >=20 > Zafar, >=20 >=20 > --- "Zafar Ali (zali)" wrote: >=20 > > > > > >> > > > > >> > Igor, > > > >> > > > > >> > W.r.t. option C, please note that traffic > > CANNOT be > > > forwarded in a > > > >> > "head-less mode" for a very long time . If > > you control > > > >> network melts > > > >> > or a peering controller goes down, either > > RSVP GR or > > > refreshes will > > > >> > take care of the clean-up of the affected > > RSVP states. > > > >> Similarly LMP > > > >> > CC SM will go down (after states are cleared, > > i.e., > > > >> degraded-to-down), > > > >> > eventually removing the TE links from > > topology. > > > >> > > > > >> > > > >> Sticking to the example I described: > > > >> a) absence of RSVP refreshes does not affect > > data plane in any way; > > > >> b) use of LMP is not mandatory and, becides, I > > don't see > > > now it helps. > > > >> True, the TE link could be withdrawn, however, > > the LSP > > > will still be > > > >> operational > > > > > > > > Isn't the problem is at "B" only and control > > plane at the > > > other node > > > > (or controller for other nodes) still working > > fine? If yes, local > > > > controllers will withdraw RSVP states; hence > > correct the data plane. > > > > > > >=20 > > > Again, GMPLS controller cannot remove control > > state and > > > destroy data plane just because it does not get > > refreshes > > > from adjacent controllers. > >=20 > > Then how states get ever destoryed, even in normal case,=20 > e.g., if head=20 > > end sends a ptear and all controllers are up? > >=20 >=20 > States are supposed to be destroyed on explicit signalling=20 > message (e.g. PathTear or PathErr with the state removal=20 > flag), but not because of the absence of refreshes. >=20 I see this as an implementation deficency and not a protocol deficiency. Just remove the states that are not refreshed and your problem is solved.=20 Thanks Regards... Zafar > Igor >=20 >=20 > > Thanks > >=20 > > Regards... Zafar > >=20 > > > >=20 >=20 >=20 >=20 > =09 > __________________________________ > Yahoo! FareChase: Search multiple travel sites in one click. > http://farechase.yahoo.com >=20 From owner-ccamp@ops.ietf.org Sun Oct 30 18:17:06 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWMQE-0003FE-AZ for ccamp-archive@megatron.ietf.org; Sun, 30 Oct 2005 18:17:06 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24482 for ; Sun, 30 Oct 2005 18:16:48 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EWMeA-000544-BS for ccamp-archive@ietf.org; Sun, 30 Oct 2005 18:31:39 -0500 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EWMJJ-00043G-OO for ccamp-data@psg.com; Sun, 30 Oct 2005 23:09:57 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [130.76.32.69] (helo=blv-smtpout-01.boeing.com) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EWMJJ-000431-2n; Sun, 30 Oct 2005 23:09:57 +0000 Received: from stl-av-01.boeing.com ([192.76.190.6]) by blv-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id PAA21450; Sun, 30 Oct 2005 15:09:35 -0800 (PST) Received: from XCH-SWBH-04.sw.nos.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id j9UN9YY23295; Sun, 30 Oct 2005 17:09:34 -0600 (CST) Received: from XCH-SW-42.sw.nos.boeing.com ([192.79.11.43]) by XCH-SWBH-04.sw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 30 Oct 2005 15:09:33 -0800 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: Two Drafts for Resilience of Control Plane Date: Sun, 30 Oct 2005 15:09:33 -0800 Message-ID: <626FC7C6A97381468FB872072AB5DDC8369714@XCH-SW-42.sw.nos.boeing.com> Thread-Topic: Two Drafts for Resilience of Control Plane Thread-Index: AcXdZkYp8+2roqIaTpWMcrN6jVo3zgACKc9AAA3sOmA= From: "Drake, John E" To: "Zafar Ali \(zali\)" , "Igor Bryskin" , Cc: , , , "Kim Young Hwa" , X-OriginalArrivalTime: 30 Oct 2005 23:09:33.0951 (UTC) FILETIME=[FDA250F0:01C5DDA6] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: quoted-printable Snipped > > > > > > > States are supposed to be destroyed on explicit signalling > > message (e.g. PathTear or PathErr with the state removal > > flag), but not because of the absence of refreshes. > > [JD]=20 Igor, Just to be clear, we are talking about RSVP here, and RSVP *is* a soft state protocol. Can you point to any RFC that supports your statements above? Thanks, John From owner-ccamp@ops.ietf.org Mon Oct 31 03:04:31 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWUeb-0007Qz-OT for ccamp-archive@megatron.ietf.org; Mon, 31 Oct 2005 03:04:31 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18763 for ; Mon, 31 Oct 2005 03:04:10 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EWUsc-00054W-Vl for ccamp-archive@ietf.org; Mon, 31 Oct 2005 03:19:07 -0500 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EWUX6-0008Nk-VE for ccamp-data@psg.com; Mon, 31 Oct 2005 07:56:44 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00, UNPARSEABLE_RELAY autolearn=ham version=3.1.0 Received: from [192.51.44.35] (helo=fgwmail5.fujitsu.co.jp) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EWUX5-0008Mf-Iy for ccamp@ops.ietf.org; Mon, 31 Oct 2005 07:56:43 +0000 Received: from m5.gw.fujitsu.co.jp ([10.0.50.75]) by fgwmail5.fujitsu.co.jp (Fujitsu Gateway) id j9V7ugew001275 for ; Mon, 31 Oct 2005 16:56:42 +0900 (envelope-from nagata.akira@jp.fujitsu.com) Received: from s11.gw.fujitsu.co.jp by m5.gw.fujitsu.co.jp (8.12.10/Fujitsu Domain Master) id j9V7uekg026054 for ; Mon, 31 Oct 2005 16:56:40 +0900 (envelope-from nagata.akira@jp.fujitsu.com) Received: from s11.gw.fujitsu.co.jp (s11 [127.0.0.1]) by s11.gw.fujitsu.co.jp (Postfix) with ESMTP id D14B0DC06E for ; Mon, 31 Oct 2005 16:56:40 +0900 (JST) Received: from flabmail.flab.fujitsu.co.jp (flabmail.flab.fujitsu.co.jp [10.25.192.4]) by s11.gw.fujitsu.co.jp (Postfix) with ESMTP id 8734FDC06F for ; Mon, 31 Oct 2005 16:56:40 +0900 (JST) Received: from flabmail.flab.fujitsu.co.jp by flabmail.flab.fujitsu.co.jp (8.9.3p2/3.7W-030703-Fujitsu Labs. Domain Mail Master (NAVGW)) id QAA07730; Mon, 31 Oct 2005 16:56:40 +0900 (JST) Received: from goofy.dream.flab.fujitsu.co.jp ([10.25.144.14]) by flabmail.flab.fujitsu.co.jp (NAVGW 2.5.2.9) with SMTP id M2005103116563920833 ; Mon, 31 Oct 2005 16:56:39 +0900 Received: from [127.0.0.1] (mark [10.25.144.221]) by goofy.dream.flab.fujitsu.co.jp (8.9.3+3.2W/3.7W) with ESMTP id QAA04326; Mon, 31 Oct 2005 16:56:42 +0900 Date: Mon, 31 Oct 2005 16:56:18 +0900 From: Akira NAGATA To: "Zafar Ali (zali)" , "Adrian Farrel" Subject: Re: Question on Administratively down bit Cc: In-Reply-To: References: Message-Id: <20051031164940.9692.NAGATA.AKIRA@jp.fujitsu.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.20 [ja] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: a92270ba83d7ead10c5001bb42ec3221 Content-Transfer-Encoding: 7bit Hi Zafar, Thank you for your comments. I'll consider more about this point, based on your comments. Please let me discuss again at a later date. best regards, Akira On Fri, 21 Oct 2005 07:10:40 -0400 "Zafar Ali (zali)" san wrote: > Hi Akira, > > The sequence you mentioned is correct. Also this is my understanding > that when an LSP is in "Admin.A = 1", an optical node may be performing > some power monitoring and adjustment related to the commissioning > process (again, this is a local action by an optical node). From a > router's prospective, I do see a need for router NOT to send any data > traffic on the LSP that is in "Admin.A=1", in addition of suppressing > alarm on the interface in question. I.e., an LSP can ONLY carrying data > traffic when it is back to "Admin.A=0". > > Comments/ additions? > > Thanks > > Regards... Zafar > > > -----Original Message----- > > From: owner-ccamp@ops.ietf.org > > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Akira NAGATA > > Sent: Friday, October 21, 2005 1:52 AM > > To: Adrian Farrel > > Cc: Akira_NAGATA; ccamp@ops.ietf.org > > Subject: Re: Question on Administratively down bit > > > > Hi Adrian, > > > > Thank you for your discussing this issue. > > > > I understand that a hardware behavior triggered by > > AdminStatus bit will differ from one vendor to another. > > > > Alarm inhibition is just an example of application by A-bit, > > RFC3471 or 3473 can not achieve interoperability on the > > hardware behavior itself triggered by A-bit in multi-vendor > > network. Is it right? > > In a fact, I think it cannot be helped. > > > > I believe, however, RFC3471 or 3473 shall achieve > > interoperability on AdminStatus bit including A-bit from the > > perspective of message handling, at least. > > > > RFC3473 has no explicit clarification of handling A-bit or > > T-bit, where it has an explicit description of handling the > > pair of D and R-bit (in Section 7.2). > > In order to achieve interoperability at message level, more > > explicit description will be needed for A-bit or T-bit like > > the case of D+R-bit. > > > > How do you think about this point? > > > > According to my understanding using examples from D+R-bit in > > Sec 7.2.1, Path/Resv sequence for alarm report inhibition by > > A-bit (i.e. > > degradation > > of established LSP) can be shown as following: > > > > Path (A=1, R=1) > > ingress -------------------> egress > > node Resv (A=1, R=0) node > > <------------------ > > > > Similarly, Path/Resv sequence for enabling alarm report by > > A-bit (i.e. activation of degradated LSP) can be shown as following: > > > > Path (A=0, R=1) > > ingress -------------------> egress > > node Resv (A=0, R=0) node > > <------------------ > > > > Would you mind letting me know if something wrong? > > > > best regards, > > Akira > > > > On Wed, 19 Oct 2005 14:57:35 +0100 > > "Adrian Farrel" san wrote: > > > > > Hi Akira, > > > > > > I have been thinking about your question and discussing it > > with a few > > > people. > > > > > > The general consensus is that it is important to have well-defined > > > mechanisms for the signaling exchange of the Admin Status bits, but > > > that the actions to take on receipt of some the bits may be > > dependent > > > on local policy or on data plane technology. > > > > > > Thus an implementation may decide that certain alarms should be > > > suppressed during LSP establishment because it knows them to be > > > "false" alarms triggered by the process of establishing the LSP. On > > > the other hand, an implementation may decide that other alarms that > > > are first raised during LSP establishment represent a > > different set of > > > circumstances and should be raised. I would be worried if > > we tried to > > > list and categorise all such alarms within the CCAMP working group. > > > > > > It might be useful to consider whether the behavior of switch under > > > alarm suppression conditions should be configurable to allow the > > > operator to select consistent behavior, or whether this is > > adding too much complexity. > > > > > > Cheers, > > > Adrian > > > > > > ----- Original Message ----- > > > From: "Akira NAGATA" > > > To: > > > Cc: "Akira_NAGATA" > > > Sent: Friday, August 19, 2005 12:13 PM > > > Subject: Question on Administratively down bit > > > > > > > > > > Mr. Lou Berger and editors of RFC3471 and RFC3473, > > > > > > > > This is my first time to send e-mail to ccamp. > > > > Thanks in advance. > > > > > > > > I'd like to ask one question about the handling of > > Administratively > > > > down > > > bit > > > > in GMPLS RSVP-TE's Admin_Status object. > > > > > > > > RFC3471 introduces "inhibiting alarm reporting" as an example > > > application > > > > of local action to "down" state (that is, A-bit=1) in Section 8. > > > > But I can't find any other explicit descriptions about this > > > > procedure in RFC3471 or 3473. > > > > > > > > I understand that actions to be taken by each node receiving > > > Admin_Status > > > > object shall be based on local policy. > > > > > > > > With regard to inhibition of alarm reporting, however, in order to > > > achieve it > > > > through end-to-end, I believe that we had better take a unified > > > > action as a response to A-bit ("down" or "up"). > > > > Operator will expect this feature. > > > > > > > > (Here I mean alarm report is not reporting via RSVP messages as > > > described > > > > in ID-alarm-spec, but one from NE to external system such > > as network > > > > management system.) > > > > > > > > Are there any considerations, drafts or RFCs to define it? > > > > > > > > Thanks, > > > > --- > > > > Akira NAGATA > > > > > > > > > > > > > > > > > > > > > > > --- > > Akira NAGATA Photonic Node > > Laboratory, Photonics Networking Laboratories, Fujitsu > > Laboratories Ltd. > > TEL: +81-44-754-2765 FAX: +81-44-754-2741 > > > > --- Akira NAGATA Photonic Node Laboratory, Photonics Networking Laboratories, Fujitsu Laboratories Ltd. TEL: +81-44-754-2765 FAX: +81-44-754-2741 From owner-ccamp@ops.ietf.org Mon Oct 31 06:06:34 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWXUo-0002fa-LI for ccamp-archive@megatron.ietf.org; Mon, 31 Oct 2005 06:06:34 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29212 for ; Mon, 31 Oct 2005 06:06:14 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EWXil-0002Gt-1f for ccamp-archive@ietf.org; Mon, 31 Oct 2005 06:21:13 -0500 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EWXOz-000IMY-I5 for ccamp-data@psg.com; Mon, 31 Oct 2005 11:00:33 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [129.60.39.102] (helo=tama5.ecl.ntt.co.jp) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EWXOx-000IMN-VM for ccamp@ops.ietf.org; Mon, 31 Oct 2005 11:00:32 +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.12.11/8.12.11) with ESMTP id j9VB0ULc027246 for ; Mon, 31 Oct 2005 20:00:30 +0900 (JST) Received: from vcs3.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by vcs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j9VB0TXN019766 for ; Mon, 31 Oct 2005 20:00:29 +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 j9VB0Tgh019761 for ; Mon, 31 Oct 2005 20:00:29 +0900 (JST) Received: from mfs3.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by mfs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j9VB0S46011162 for ; Mon, 31 Oct 2005 20:00:28 +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 j9VB0SXB011158 for ; Mon, 31 Oct 2005 20:00:28 +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 j9VB0SU7004771 for ; Mon, 31 Oct 2005 20:00:28 +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 j9VB0Rxa001032 for ; Mon, 31 Oct 2005 20:00:27 +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 j9VB0Ran001027 for ; Mon, 31 Oct 2005 20:00:27 +0900 (JST) Received: from TAKEDA_PANA.lab.ntt.co.jp ([129.60.80.223]) by imf.m.ecl.ntt.co.jp (8.13.4/8.13.4) with ESMTP id j9VB0QxA021834 for ; Mon, 31 Oct 2005 20:00:27 +0900 (JST) Message-Id: <5.1.1.9.2.20051031192340.06cb3ec0@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, 31 Oct 2005 20:00:42 +0900 To: ccamp@ops.ietf.org From: Tomonori TAKEDA Subject: Question on draft-ietf-ccamp-inter-domain-pd-path-comp-01.txt 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: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit Hi JP, Arthi, Raymond I have a small question on draft-ietf-ccamp-inter-domain-pd-path-comp-01.txt. http://www.ietf.org/internet-drafts/draft-ietf-ccamp-inter-domain-pd-path-comp-01.txt In section 4, it says: In terms of computation of an inter-AS TE LSP path, an interesting optimization technique consists of allowing the ASBRs to flood the TE information related to the inter-ASBR link(s) although no IGP TE is enabled over those links (and so there is no IGP adjacency over the inter-ASBR links). It sounds like passive interface in IP. Is it applicable (or is there a defined way) in (G)MPLS TE? Note I think: - This technique is as useful when PCE is used, assuming (each) PCE participates routing in each domain (in this case, AS) - This technique may be as useful in GMPLS overlay network Thanks, Tomonori From info@mail.hclj.com Mon Oct 31 07:53:58 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWZAj-0000eh-Ic for ccamp-archive@megatron.ietf.org; Mon, 31 Oct 2005 07:53:58 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05191 for ; Mon, 31 Oct 2005 07:53:38 -0500 (EST) Received: from [125.57.107.122] (helo=mail.hclj.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EWZOu-0000nm-0E for ccamp-archive@ietf.org; Mon, 31 Oct 2005 08:08:36 -0500 Received: (qmail 32560 invoked by uid 510); 31 Oct 2005 12:29:57 +0900 Date: 31 Oct 2005 12:29:57 +0900 Message-ID: <20051031032957.32559.qmail@mail.hclj.com> From: info@hclj.com To: ccamp-archive@ietf.org Subject: $B$*6bM_$7$/$"$j$^$;$s$+!)$D$$$KJ}#G#E#T$7$^$;$s$+!)(B $B2q$($FEv$?$jA0!*!*!*$*6bLc$($FEv$jA0!*!*!*(B $B:#$O$=$s$J;~Be$G$9!#$=$NHkL)$O!&!&!&!&(B http://www.gyakuten5.net/?enjyo $B"-!Z$3$N%5%$%H$NHkL)!&!&!&![(B $B"#=w@-2q0wMM$OJ@l9g$O(B gyakuten_angel@yahoo.com.au $B!a!a!a!a!a!a!a!a!a!a!a!a!a!a!a!a!a!a!a(B From owner-ccamp@ops.ietf.org Mon Oct 31 08:47:49 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWa0q-0002d6-Rc for ccamp-archive@megatron.ietf.org; Mon, 31 Oct 2005 08:47:49 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08907 for ; Mon, 31 Oct 2005 08:47:29 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EWaEy-0004Zu-Cz for ccamp-archive@ietf.org; Mon, 31 Oct 2005 09:02:28 -0500 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EWZrR-00007K-8J for ccamp-data@psg.com; Mon, 31 Oct 2005 13:38:05 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [70.158.43.219] (helo=jera.movaz.com) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EWZrQ-00006l-4y for ccamp@ops.ietf.org; Mon, 31 Oct 2005 13:38:04 +0000 Received: from ib (unknown [172.16.24.122]) by jera.movaz.com (Postfix) with SMTP id 6DDE82DFB5; Mon, 31 Oct 2005 08:37:58 -0500 (EST) Message-ID: <009a01c5de20$4e7ecde0$7a1810ac@movaz.com> From: "Igor Bryskin" To: "Zafar Ali (zali)" , "Igor Bryskin" Cc: , "John E" , , , "Kim Young Hwa" , References: Subject: Re: Two Drafts for Resilience of Control Plane Date: Mon, 31 Oct 2005 08:37:58 -0500 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: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit Zafar, [Snipped] > > Then how states get ever destoryed, even in normal case, > e.g., if head > > end sends a ptear and all controllers are up? > > > > States are supposed to be destroyed on explicit signalling > message (e.g. PathTear or PathErr with the state removal > flag), but not because of the absence of refreshes. > I see this as an implementation deficency and not a protocol deficiency. Just remove the states that are not refreshed and your problem is solved. IB>> Well, you cannot remove control plane state without releasing associated resources. Let me give you two reasons why: a) Once you do this, the associated resources become orphans: there will be no entity remembering them and, thus, there will be no way to return them to the pool of unreserved resources and reuse in other LSPs b) If/when the "dead" controller does come back to life, it will not be capable to synchronize the control plane states because its neighbors will not have ones. Igor From owner-ccamp@ops.ietf.org Mon Oct 31 09:14:46 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWaQv-00086z-Ow for ccamp-archive@megatron.ietf.org; Mon, 31 Oct 2005 09:14:46 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10197 for ; Mon, 31 Oct 2005 09:14:26 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EWaf8-0007Lg-2C for ccamp-archive@ietf.org; Mon, 31 Oct 2005 09:29:26 -0500 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EWaMF-0001nD-Rq for ccamp-data@psg.com; Mon, 31 Oct 2005 14:09:55 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [70.158.43.219] (helo=jera.movaz.com) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EWaME-0001mq-B5 for ccamp@ops.ietf.org; Mon, 31 Oct 2005 14:09:55 +0000 Received: from ib (unknown [172.16.24.122]) by jera.movaz.com (Postfix) with SMTP id 731E718809; Mon, 31 Oct 2005 09:09:50 -0500 (EST) Message-ID: <00b201c5de24$c20fc710$7a1810ac@movaz.com> From: "Igor Bryskin" To: "Drake, John E" , "Zafar Ali (zali)" , "Igor Bryskin" Cc: , , , "Kim Young Hwa" , References: <626FC7C6A97381468FB872072AB5DDC8369714@XCH-SW-42.sw.nos.boeing.com> Subject: Re: Two Drafts for Resilience of Control Plane Date: Mon, 31 Oct 2005 09:09:50 -0500 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: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: 7bit John, > > > > > > > States are supposed to be destroyed on explicit signalling > > message (e.g. PathTear or PathErr with the state removal > > flag), but not because of the absence of refreshes. > > [JD] Igor, Just to be clear, we are talking about RSVP here, and RSVP *is* a soft state protocol. Can you point to any RFC that supports your statements above? IB>> Oh, come on, John. You sound like you've been yourself in a dormant state for a while :=). We've gone a long way since RFC2205. In RFC3471, for example, there is a discussion why GMPLS is needed and how is it different from MPLS. One of the differences is the fact that soft state protocols do not work well for non-packet environments. Here is from the RDC3471: 9.2. Fault Handling There are two new faults that must be handled when the control channel is independent of the data channel. In the first, there is a link or other type of failure that limits the ability of neighboring nodes to pass control messages. In this situation, neighboring nodes are unable to exchange control messages for a period of time. Once communication is restored the underlying signaling protocol must indicate that the nodes have maintained their state through the failure.. What is more important is the reality of life: The customers simply say that you cannot destroy a user service (or even force any traffic hits) just because you have a problem in the control plane. If this does not fit your soft-state paradigm, than "harden" your protocols or flash them down the toilet and come with something else if you want our business. After all, if we provision the services via NMS, we do not have to destroy the services if we have problems in the management network. It is that simple. Igor From owner-ccamp@ops.ietf.org Mon Oct 31 09:37:51 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWanH-0004Y9-8w for ccamp-archive@megatron.ietf.org; Mon, 31 Oct 2005 09:37:51 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11406 for ; Mon, 31 Oct 2005 09:37:31 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EWb1K-0001iC-Ci for ccamp-archive@ietf.org; Mon, 31 Oct 2005 09:52:32 -0500 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EWai2-00033e-Vp for ccamp-data@psg.com; Mon, 31 Oct 2005 14:32:26 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=3.1.0 Received: from [217.32.164.150] (helo=smtp2.smtp.bt.com) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EWai0-00033O-Fa for ccamp@ops.ietf.org; Mon, 31 Oct 2005 14:32:24 +0000 Received: from i2km97-ukbr.domain1.systemhost.net ([193.113.197.30]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 31 Oct 2005 14:32:20 +0000 Received: from i2km07-ukbr.domain1.systemhost.net ([193.113.197.26]) by i2km97-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Mon, 31 Oct 2005 14:31:42 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.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: Two Drafts for Resilience of Control Plane Date: Mon, 31 Oct 2005 14:31:42 -0000 Message-ID: <0536FC9B908BEC4597EE721BE6A3538912275564@i2km07-ukbr.domain1.systemhost.net> Thread-Topic: Two Drafts for Resilience of Control Plane Thread-Index: AcXeJODvtSLGpyjCSiesm+zs4e0vcQAAljWg From: To: , , , Cc: , , , , X-OriginalArrivalTime: 31 Oct 2005 14:31:42.0681 (UTC) FILETIME=[D0208490:01C5DE27] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.3 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Content-Transfer-Encoding: quoted-printable Igor....if it's any comfort to you, folks here in BT agree with you. And I don't care what anyone says about the NMS and the futile attempts to obsolete it....we will always need this for a whole raft of functions/reasons....and the closer one gets to the duct the more important it becomes and the less important a control-plane becomes (at least dynamic routing aspects). =20 regards, Neil=20 > -----Original Message----- > From: owner-ccamp@ops.ietf.org > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Igor Bryskin > Sent: 31 October 2005 14:10 > To: Drake, John E; Zafar Ali (zali); Igor Bryskin > Cc: drake@movaz.com; dpapadimitriou@psg.com;=20 > dimitri.papadimitriou@alcatel.be; Kim Young Hwa; ccamp@ops.ietf.org > Subject: Re: Two Drafts for Resilience of Control Plane >=20 >=20 > John, >=20 >=20 > > > > > > > > > > States are supposed to be destroyed on explicit > signalling message > > > (e.g. PathTear or PathErr with the state removal flag), but not > > > because of the absence of refreshes. > > > > [JD] >=20 > Igor, >=20 > Just to be clear, we are talking about RSVP here, and RSVP > *is* a soft state protocol. Can you point to any RFC that=20 > supports your statements above? >=20 > IB>> Oh, come on, John. You sound like you've been yourself > in a dormant > state for a while :=3D). We've gone a long way since RFC2205. > In RFC3471, for example, there is a discussion why GMPLS is=20 > needed and how is it different from MPLS. One of the=20 > differences is the fact that soft state protocols do not work=20 > well for non-packet environments. Here is from the RDC3471: >=20 >=20 >=20 > 9.2. Fault Handling There are two new faults that must be=20 > handled when > the control channel is independent of the data channel. In=20 > the first, > there is a link or other type of failure that limits the ability of > neighboring nodes to pass control messages. In this situation, > neighboring nodes are unable to exchange control messages=20 > for a period of > time. Once communication is restored the underlying=20 > signaling protocol > must indicate that the nodes have maintained their state through the > failure.. >=20 > What is more important is the reality of life: The customers > simply say that you cannot destroy a user service (or even=20 > force any traffic hits) just because you have a problem in=20 > the control plane. If this does not fit your soft-state=20 > paradigm, than "harden" your protocols or flash them down the=20 > toilet and come with something else if you want our business.=20 > After all, if we provision the services via NMS, we do not=20 > have to destroy the services if we have problems in the=20 > management network. It is that simple. >=20 >=20 >=20 > Igor >=20 >=20 >=20 >=20 >=20 >=20 >=20 From owner-ccamp@ops.ietf.org Mon Oct 31 09:48:44 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWaxn-0006jZ-R7 for ccamp-archive@megatron.ietf.org; Mon, 31 Oct 2005 09:48:44 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11891 for ; Mon, 31 Oct 2005 09:48:24 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EWbBr-0002uE-UN for ccamp-archive@ietf.org; Mon, 31 Oct 2005 10:03:24 -0500 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EWaqE-0003jn-QB for ccamp-data@psg.com; Mon, 31 Oct 2005 14:40:54 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [130.76.64.48] (helo=slb-smtpout-01.boeing.com) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EWaqC-0003jW-R3; Mon, 31 Oct 2005 14:40:52 +0000 Received: from blv-av-01.boeing.com ([192.42.227.216]) by slb-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id GAA15211; Mon, 31 Oct 2005 06:40:29 -0800 (PST) Received: from XCH-SWBH-04.sw.nos.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id j9VEeSH12499; Mon, 31 Oct 2005 06:40:28 -0800 (PST) Received: from XCH-SW-42.sw.nos.boeing.com ([192.79.11.43]) by XCH-SWBH-04.sw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 31 Oct 2005 06:40:25 -0800 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: Two Drafts for Resilience of Control Plane Date: Mon, 31 Oct 2005 06:40:24 -0800 Message-ID: <626FC7C6A97381468FB872072AB5DDC8369717@XCH-SW-42.sw.nos.boeing.com> Thread-Topic: Two Drafts for Resilience of Control Plane Thread-Index: AcXeJODvtSLGpyjCSiesm+zs4e0vcQAAljWgAAA4G0A= From: "Drake, John E" To: , , , Cc: , , , , X-OriginalArrivalTime: 31 Oct 2005 14:40:25.0326 (UTC) FILETIME=[07A5D0E0:01C5DE29] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Content-Transfer-Encoding: quoted-printable Neil, I don't think the discussion, at least from my perspective, has anything to do with the NMS, other than this strange assertion that the NMS will always be able to reach every node in the network even if there is a control plane failure. =20 I have always considered the control plane to be a component in a larger system that also includes the NMS, etc. Thanks, John=20 > -----Original Message----- > From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com] > Sent: Monday, October 31, 2005 6:32 AM > To: ibryskin@movaz.com; Drake, John E; zali@cisco.com; i_bryskin@yahoo.com > Cc: drake@movaz.com; dpapadimitriou@psg.com; > dimitri.papadimitriou@alcatel.be; yhwkim@etri.re.kr; ccamp@ops.ietf.org > Subject: RE: Two Drafts for Resilience of Control Plane >=20 > Igor....if it's any comfort to you, folks here in BT agree with you. > And I don't care what anyone says about the NMS and the futile attempts > to obsolete it....we will always need this for a whole raft of > functions/reasons....and the closer one gets to the duct the more > important it becomes and the less important a control-plane becomes (at > least dynamic routing aspects). >=20 > regards, Neil >=20 > > -----Original Message----- > > From: owner-ccamp@ops.ietf.org > > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Igor Bryskin > > Sent: 31 October 2005 14:10 > > To: Drake, John E; Zafar Ali (zali); Igor Bryskin > > Cc: drake@movaz.com; dpapadimitriou@psg.com; > > dimitri.papadimitriou@alcatel.be; Kim Young Hwa; ccamp@ops.ietf.org > > Subject: Re: Two Drafts for Resilience of Control Plane > > > > > > John, > > > > > > > > > > > > > > > > > States are supposed to be destroyed on explicit > > signalling message > > > > (e.g. PathTear or PathErr with the state removal flag), but not > > > > because of the absence of refreshes. > > > > > > [JD] > > > > Igor, > > > > Just to be clear, we are talking about RSVP here, and RSVP > > *is* a soft state protocol. Can you point to any RFC that > > supports your statements above? > > > > IB>> Oh, come on, John. You sound like you've been yourself > > in a dormant > > state for a while :=3D). We've gone a long way since RFC2205. > > In RFC3471, for example, there is a discussion why GMPLS is > > needed and how is it different from MPLS. One of the > > differences is the fact that soft state protocols do not work > > well for non-packet environments. Here is from the RDC3471: > > > > > > > > 9.2. Fault Handling There are two new faults that must be > > handled when > > the control channel is independent of the data channel. In > > the first, > > there is a link or other type of failure that limits the ability of > > neighboring nodes to pass control messages. In this situation, > > neighboring nodes are unable to exchange control messages > > for a period of > > time. Once communication is restored the underlying > > signaling protocol > > must indicate that the nodes have maintained their state through the > > failure.. > > > > What is more important is the reality of life: The customers > > simply say that you cannot destroy a user service (or even > > force any traffic hits) just because you have a problem in > > the control plane. If this does not fit your soft-state > > paradigm, than "harden" your protocols or flash them down the > > toilet and come with something else if you want our business. > > After all, if we provision the services via NMS, we do not > > have to destroy the services if we have problems in the > > management network. It is that simple. > > > > > > > > Igor > > > > > > > > > > > > > > From owner-ccamp@ops.ietf.org Mon Oct 31 10:26:55 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWbYk-0006cL-Ss for ccamp-archive@megatron.ietf.org; Mon, 31 Oct 2005 10:26:55 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14072 for ; Mon, 31 Oct 2005 10:26:35 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EWbmw-0006L2-IZ for ccamp-archive@ietf.org; Mon, 31 Oct 2005 10:41:36 -0500 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EWbR0-0005aK-LS for ccamp-data@psg.com; Mon, 31 Oct 2005 15:18:54 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [70.158.43.219] (helo=jera.movaz.com) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EWbQy-0005a3-1Z for ccamp@ops.ietf.org; Mon, 31 Oct 2005 15:18:53 +0000 Received: from ib (unknown [172.16.24.122]) by jera.movaz.com (Postfix) with SMTP id 7BC1E14EC2; Mon, 31 Oct 2005 10:18:50 -0500 (EST) Message-ID: <00fa01c5de2e$65e8e1b0$7a1810ac@movaz.com> From: "Igor Bryskin" To: "Drake, John E" , , , Cc: , , , , References: <626FC7C6A97381468FB872072AB5DDC8369717@XCH-SW-42.sw.nos.boeing.com> Subject: Re: Two Drafts for Resilience of Control Plane Date: Mon, 31 Oct 2005 10:18:50 -0500 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: 93e7fb8fef2e780414389440f367c879 Content-Transfer-Encoding: 7bit John, This discussion is about resilience of control plane and whether some standardized solutions (and hence additional work in CCAMP) is needed. So I disagree with you when you say that the discussion has nothing to do with NMS, because one can evaluate the resilience only compared with one of some alternative way of service provisioning and management. I personally do not see any technical reason why managing services via control plane should be less resilient than doing so via management plane. However, to achieve this some additional work is required. Igor ----- Original Message ----- From: "Drake, John E" To: ; ; ; Cc: ; ; ; ; Sent: Monday, October 31, 2005 9:40 AM Subject: RE: Two Drafts for Resilience of Control Plane Neil, I don't think the discussion, at least from my perspective, has anything to do with the NMS, other than this strange assertion that the NMS will always be able to reach every node in the network even if there is a control plane failure. I have always considered the control plane to be a component in a larger system that also includes the NMS, etc. Thanks, John > -----Original Message----- > From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com] > Sent: Monday, October 31, 2005 6:32 AM > To: ibryskin@movaz.com; Drake, John E; zali@cisco.com; i_bryskin@yahoo.com > Cc: drake@movaz.com; dpapadimitriou@psg.com; > dimitri.papadimitriou@alcatel.be; yhwkim@etri.re.kr; ccamp@ops.ietf.org > Subject: RE: Two Drafts for Resilience of Control Plane > > Igor....if it's any comfort to you, folks here in BT agree with you. > And I don't care what anyone says about the NMS and the futile attempts > to obsolete it....we will always need this for a whole raft of > functions/reasons....and the closer one gets to the duct the more > important it becomes and the less important a control-plane becomes (at > least dynamic routing aspects). > > regards, Neil > > > -----Original Message----- > > From: owner-ccamp@ops.ietf.org > > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Igor Bryskin > > Sent: 31 October 2005 14:10 > > To: Drake, John E; Zafar Ali (zali); Igor Bryskin > > Cc: drake@movaz.com; dpapadimitriou@psg.com; > > dimitri.papadimitriou@alcatel.be; Kim Young Hwa; ccamp@ops.ietf.org > > Subject: Re: Two Drafts for Resilience of Control Plane > > > > > > John, > > > > > > > > > > > > > > > > > States are supposed to be destroyed on explicit > > signalling message > > > > (e.g. PathTear or PathErr with the state removal flag), but not > > > > because of the absence of refreshes. > > > > > > [JD] > > > > Igor, > > > > Just to be clear, we are talking about RSVP here, and RSVP > > *is* a soft state protocol. Can you point to any RFC that > > supports your statements above? > > > > IB>> Oh, come on, John. You sound like you've been yourself > > in a dormant > > state for a while :=). We've gone a long way since RFC2205. > > In RFC3471, for example, there is a discussion why GMPLS is > > needed and how is it different from MPLS. One of the > > differences is the fact that soft state protocols do not work > > well for non-packet environments. Here is from the RDC3471: > > > > > > > > 9.2. Fault Handling There are two new faults that must be > > handled when > > the control channel is independent of the data channel. In > > the first, > > there is a link or other type of failure that limits the ability of > > neighboring nodes to pass control messages. In this situation, > > neighboring nodes are unable to exchange control messages > > for a period of > > time. Once communication is restored the underlying > > signaling protocol > > must indicate that the nodes have maintained their state through the > > failure.. > > > > What is more important is the reality of life: The customers > > simply say that you cannot destroy a user service (or even > > force any traffic hits) just because you have a problem in > > the control plane. If this does not fit your soft-state > > paradigm, than "harden" your protocols or flash them down the > > toilet and come with something else if you want our business. > > After all, if we provision the services via NMS, we do not > > have to destroy the services if we have problems in the > > management network. It is that simple. > > > > > > > > Igor > > > > > > > > > > > > > > From owner-ccamp@ops.ietf.org Mon Oct 31 10:30:12 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWbbv-0007Jp-IL for ccamp-archive@megatron.ietf.org; Mon, 31 Oct 2005 10:30:12 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14233 for ; Mon, 31 Oct 2005 10:29:51 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EWbpv-0006eQ-0h for ccamp-archive@ietf.org; Mon, 31 Oct 2005 10:44:52 -0500 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EWbXC-0005wk-7P for ccamp-data@psg.com; Mon, 31 Oct 2005 15:25:18 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [168.127.0.57] (helo=fncnmp04.fnc.fujitsu.com) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EWbXA-0005wW-QH for ccamp@ops.ietf.org; Mon, 31 Oct 2005 15:25:16 +0000 Received: from rchemx01.fnc.net.local (167.254.101.101) by fncnmp04.fnc.fujitsu.com with ESMTP; 31 Oct 2005 09:25:16 -0600 X-IronPort-AV: i="3.97,270,1125896400"; d="scan'208"; a="10643544:sNHT17819560" 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: comments on draft-shiba-ccamp-gmpls-lambda-labels-00.txt Date: Mon, 31 Oct 2005 09:25:15 -0600 Message-ID: <7CA873794E52904EAA980A074B076779B17C5F@rchemx01.fnc.net.local> Thread-Topic: comments on draft-shiba-ccamp-gmpls-lambda-labels-00.txt Thread-Index: AcXbIzcAFoI5B5TzS9O/zBGY1cMJbwA6iz0AAIdyNZA= From: "Shiba, Sidney" To: "Drake, John E" , Cc: "Adrian Farrel" , , Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: c119f9923e40f08a1d7f390ce651ea92 Content-Transfer-Encoding: quoted-printable Hi John, Optical switches based on Wavelength Selective Switch (WSS) technology requires the wavelength information for switching. This technology is = NOT=20 wavelength agnostic. | | | wdm | wdm |2 |2 --------- --------- wdm 1| optical |3 wdm 1| optical |3 wdm --------| switch |------------| switch |--------- | (WSS) | | (WSS) | --------- --------- |4 |4 | wdm | wdm | |=20 Note that the figure above shows an example of two optical switches = interconnect by a single WDM fiber. In this example, each optical switch can be = connect to 4=20 other optical switches.=20 As you can see, the optical ports information do not provide enough = information for wavelength switching. Hope that clarifies the application requirement. Thanks, Sidney > -----Original Message----- > From: Drake, John E [mailto:John.E.Drake2@boeing.com] > Sent: Friday, October 28, 2005 5:33 PM > To: dpapadimitriou@psg.com; Shiba, Sidney > Cc: Adrian Farrel; richard.rabbat@us.fujitsu.com; ccamp@ops.ietf.org > Subject: RE: comments on draft-shiba-ccamp-gmpls-lambda-labels-00.txt >=20 >=20 > Hi, >=20 > Below is the text of an e-mail is sent to the Ethernet/GMPLS mailing > list. >=20 > Upon reflection I am not sure using a real wavelength value makes much > sense. Between a pair of adjacent nodes, there may be=20 > multiple pairs of > switch ports in the same TE link that support a given frequency. If a > real wavelength value is used, how do the two nodes agree on=20 > which pair > of switch ports to use? >=20 > Furthermore, the amount of configuration is the same - you=20 > still need to > configure the wavelength of each switch port. >=20 > Thanks, >=20 > John > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > =3D=3D=3D=3D > Adrian, >=20 > In the transparent photonic lambda switch case, the labels also have > only local significance. When an LSP is established, the input ports, > as identified with local labels, are cross-connected to the output > ports, as identified with local labels. >=20 > There is just extra configuration to identify, using strictly local > identifiers, the wavelength associated with the all of the switch's > ports, and an additional CAC requirement that the wavelengths of the > input and output ports are the same. >=20 > Thanks, >=20 > John =20 >=20 >=20 > > -----Original Message----- > > From: dimitri papadimitriou [mailto:dpapadimitriou@psg.com] > > Sent: Thursday, October 27, 2005 10:03 AM > > To: Shiba, Sidney > > Cc: dimitri.papadimitriou@alcatel.be; Adrian Farrel; > > richard.rabbat@us.fujitsu.com; ccamp@ops.ietf.org > > Subject: Re: comments on=20 > draft-shiba-ccamp-gmpls-lambda-labels-00.txt > >=20 > > shiba - see inline for some additional hints: > >=20 > > >>Shiba, Sidney wrote: > > >> > > >>>Adrian, Dimitri, > > >>> > > >>>Thanks for reviewing these I-D. > > >>> > > >>>Wavelength continuity constraint does require the use of > semanticful > > >>>label whether it is spectral or index. > > >> > > >>=3D> see my reply to adrian on this specific point > > >> > > >>>I agree with Dimitri that the > > >>>wavelength indexing requires document updating each time a new > > >>>spectrum is introduced. > > >> > > >>=3D> indeed and in addition it requires updating the already > > >>signaled path > > >> > > >>>The use of spectral label provides self maintainance, i.e., > > >>>no need to update any document and the use of the nominal value > > >>>provides a common semantic ground. > > >> > > >>=3D> what do you mean by self-maintenance - would you provide a > > >>bit more detail > > > > > > [Sidney]What I've meant here was that it was not necessary to > > > update any document when new wavelengths are inventoried. In the > > > case of indexing approach, it would require the=20 > wavelength indexing > > > document to be updated with implementation impacts. > > > > > > In the case, the nominal value is used, there is no need for > > > documentation update. > >=20 > > ok - what you mean here is that you are going to make use of the > already > > defined C-Type 2 - what about the specific encoding of the=20 > value space > ? > >=20 > > >>=3D> now i have a more specific question before being light-up > > >>how do you know the frequency that you can support ? > > > > > > [Sidney] Some new technologies integrate optical switch and > mux/demux > > > capabilities, which allows the equipment to know the spectrum it > > supports. > >=20 > > indeed - but the question is what does happen if the=20 > "detected" values > > (during initialization) do not match the nominal values ? you don't > > initialize then ? > >=20 > > >>if these differ from the nominal values how are you going to deal > with > > these > > >>discrepancies ? > > > > > > [Sidney] These new technologies uses the nominal value as=20 > reference. > We > > can say > > > that a lightpath wavelength is identified by its nominal value. If > the > > equipment > > > is drifting from this nominal value, it is considered as=20 > a failure. > >=20 > > ok - but if the deviation is such you have overlap - how the control > > plane is going to be able to detect such failure ? > >=20 > > >>this said i am not necessarily sure that having to=20 > maintain the data > > plane > > >>specifics as part of the control plane is really helping > > >>operations (is this method not just duplicating complexity ?) > > > > > > [Sidney] The wavelength is WDM specific as much as the SUKLM label > > encoding > > > is for SONET. The wavelegth/frequency nominal value is used to > identify > > the > > > facilities to cross-connect. > >=20 > > there is an equivalence but there is also a major difference, the > > structure is invariant independently of the state of the=20 > network, with > > spectral value space you may have labels that become unavailable due > to > > non-local usage of wavelength in the network > >=20 > > hence, there is also no real coupling to the data plane more than > > knowing the type of interface and some generic capabilities > >=20 > > >>>I'm not sure if the draft needs to be updated before the > > >>>face-to-face meeting or after all comments are collected. Please > > advise. > > >> > > >>=3D> suggest to keep discussion on - document update can be > > >>performed at a later stage > >=20 > > thanks, > > - dimitri. > >=20 > > >>>>-----Original Message----- > > >>>>From: owner-ccamp@ops.ietf.org=20 > [mailto:owner-ccamp@ops.ietf.org]On > > >>>>Behalf Of Adrian Farrel > > >>>>Sent: Thursday, October 27, 2005 4:45 AM > > >>>>To: dpapadimitriou@psg.com; dimitri.papadimitriou@alcatel.be; > > >>>>ccamp@ops.ietf.org > > >>>>Subject: Re: comments on > > >> > > >>draft-shiba-ccamp-gmpls-lambda-labels-00.txt > > >> > > >>>> > > >>>>Dimitri, > > >>>> > > >>>>Thanks for your work reviewing these recent I-Ds. It is > > >>>>really valuable > > >>>>and I'd welcome other people doing similar reviews. > > >>>> > > >>>> > > >>>> > > >>>>>there is a specific point to be clarified in this document: > > >>>>> > > >>>>>semanticless vs semanticful label (even here there is a > distinction > > >>>>>between spectral vs indexes i.e. using the wavelength index) > > >>>>> > > >>>>>domain-wide vs link local significant label > > >>>> > > >>>>Without being too picky, I think all labels are semanticful > > >>>>otherwise, we > > >>>>would not know what resource they refered to. > > >>>> > > >>>>So the point reduces to whether the scope of the semantics > > >>>>are link-local > > >>>>or wider. > > >>>> > > >>>> > > >>>> > > >>>>>so, the comparison from this perspective with TDM labels is > > >>>> > > >>>>difficult to > > >>>> > > >>>> > > >>>>>parse, the latter is semanticful but link local > > >>>>> > > >>>>>now, i don't specifically see what has changed the late 90's, > early > > >>>>>y2k's, to have a change in the wavelength label definition; > > >>>> > > >>>>This is the question I would like to get to the bottom of. In > > >>>>other words: > > >>>>do we need this function? > > >>>> > > >>>>It seems to me that the question being asked is this: > > >>>> > > >>>> If I want to compute a path that has some form of wavelength > > >>>> constraints, what information do I need access to? > > >>>> > > >>>>Another question might be: > > >>>> > > >>>> If I want to signal a path with wavelength constraints what > > >>>> information do I need to include in the signaling message? > > >>>> > > >>>> > > >>>>I'd suggest that when we started on GMPLS, we were > > >> > > >>enthusiastic about > > >> > > >>>>transparent optical networks, but we were not properly > > >>>>focusing wavelength > > >>>>constraints because lambda-switching PXCs didn't take off. > > >>>>Therefore we > > >>>>didn't examine the requirements for wavelength constraints in > > >>>>routing and > > >>>>signaling. The authors of this I-D are claiming new hardware > > >>>>requirements > > >>>>for the same function. > > >>>> > > >>>> > > >>>> > > >>>>>there are > > >>>>>several solution possible > > >>>>> > > >>>>>- absolute values: the freq. of the wavelength: difficult to > adopt > > >>>>>because referenced values are nominal and knowing all > interactions > > >>>>>between wavelengths this knowledge is at the end of little > > >> > > >>practical > > >> > > >>>>>usage; (introduces implicit ordering) > > >>>>> > > >>>>>- indexed values: the # of the wavelength: it does not > > >> > > >>provide for a > > >> > > >>>>>future proof label space for inst. in case new frequencies > > >>>> > > >>>>are inserted > > >>>> > > >>>> > > >>>>>in the grid (introduces explicit ordering) > > >>>>> > > >>>>>- diff. values e.g. freq spacing starting from a reference > > >>>> > > >>>>value: pauses > > >>>> > > >>>> > > >>>>>the question of the reference value and does suffer from the > former > > >>>>>issue (introduces implicit ordering) > > >>>>> > > >>>>>- the solution available today - cumbersome in some=20 > control plane > > >>>>>operations (e.g. label set translation) and not easy to > > >>>> > > >>>>troubleshoot but > > >>>> > > >>>> > > >>>>>independent of any physical consideration (spectral), scale to > any > > >>>>>number of wavelength per fiber, does not introduce any > > >> > > >>ordering, the > > >> > > >>>>>most flexible (since allowing each system to maintain its > specific > > >>>>>control operations) and the less constraining since maintaining > the > > >>>>>control plane operations independent of any data plane=20 > specifics > > >>>>> > > >>>>> > > >>>> > > >>>> > >>> > > >>>ambda-labels > > >>>-00.txt> > > >>> > > >>>. > > >>> > > >> > > > > > > . > > > >=20 From owner-ccamp@ops.ietf.org Mon Oct 31 10:31:37 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWbdJ-0007bk-E9 for ccamp-archive@megatron.ietf.org; Mon, 31 Oct 2005 10:31:37 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14323 for ; Mon, 31 Oct 2005 10:31:17 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EWbrW-0006yt-2s for ccamp-archive@ietf.org; Mon, 31 Oct 2005 10:46:18 -0500 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EWbZ5-000666-G2 for ccamp-data@psg.com; Mon, 31 Oct 2005 15:27:15 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [130.76.96.56] (helo=stl-smtpout-01.boeing.com) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EWbZ2-00065c-Rv; Mon, 31 Oct 2005 15:27:12 +0000 Received: from blv-av-01.boeing.com ([192.42.227.216]) by stl-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id JAA22849; Mon, 31 Oct 2005 09:27:03 -0600 (CST) Received: from XCH-SWBH-04.sw.nos.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id j9VFR2H16238; Mon, 31 Oct 2005 07:27:02 -0800 (PST) Received: from XCH-SW-42.sw.nos.boeing.com ([192.79.11.43]) by XCH-SWBH-04.sw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 31 Oct 2005 07:26:07 -0800 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: Two Drafts for Resilience of Control Plane Date: Mon, 31 Oct 2005 07:26:06 -0800 Message-ID: <626FC7C6A97381468FB872072AB5DDC8369719@XCH-SW-42.sw.nos.boeing.com> Thread-Topic: Two Drafts for Resilience of Control Plane Thread-Index: AcXeLmdrIZ1O83J1RPiWLi4DL8kinwAAHLKg From: "Drake, John E" To: "Igor Bryskin" , , , Cc: , , , , X-OriginalArrivalTime: 31 Oct 2005 15:26:07.0187 (UTC) FILETIME=[69EC9A30:01C5DE2F] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 2a76bcd37b1c8a21336eb0a1ea6bbf48 Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: Igor Bryskin [mailto:ibryskin@movaz.com] > Sent: Monday, October 31, 2005 7:19 AM > To: Drake, John E; neil.2.harrison@bt.com; zali@cisco.com; > i_bryskin@yahoo.com > Cc: drake@movaz.com; dpapadimitriou@psg.com; > dimitri.papadimitriou@alcatel.be; yhwkim@etri.re.kr; ccamp@ops.ietf.org > Subject: Re: Two Drafts for Resilience of Control Plane >=20 > John, >=20 >=20 >=20 > This discussion is about resilience of control plane and whether some > standardized solutions (and hence additional work in CCAMP) is needed. [JD]=20 We're still waiting for you to describe what you think is needed. All you do is continue to assert that additional work is needed. > So > I > disagree with you when you say that the discussion has nothing to do with > NMS, because one can evaluate the resilience only compared with one of > some > alternative way of service provisioning and management. I personally do > not > see any technical reason why managing services via control plane should be > less resilient than doing so via management plane. [JD]=20 As I said in my note, I don't consider the two to be competing. > However, to achieve > this > some additional work is required. [JD]=20 Argument by emphatic repetition? >=20 >=20 >=20 > Igor >=20 > ----- Original Message ----- > From: "Drake, John E" > To: ; ; ; > > Cc: ; ; > ; ; > > Sent: Monday, October 31, 2005 9:40 AM > Subject: RE: Two Drafts for Resilience of Control Plane >=20 >=20 > Neil, >=20 > I don't think the discussion, at least from my perspective, has anything > to do with the NMS, other than this strange assertion that the NMS will > always be able to reach every node in the network even if there is a > control plane failure. >=20 > I have always considered the control plane to be a component in a larger > system that also includes the NMS, etc. >=20 > Thanks, >=20 > John >=20 > > -----Original Message----- > > From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com] > > Sent: Monday, October 31, 2005 6:32 AM > > To: ibryskin@movaz.com; Drake, John E; zali@cisco.com; > i_bryskin@yahoo.com > > Cc: drake@movaz.com; dpapadimitriou@psg.com; > > dimitri.papadimitriou@alcatel.be; yhwkim@etri.re.kr; > ccamp@ops.ietf.org > > Subject: RE: Two Drafts for Resilience of Control Plane > > > > Igor....if it's any comfort to you, folks here in BT agree with you. > > And I don't care what anyone says about the NMS and the futile > attempts > > to obsolete it....we will always need this for a whole raft of > > functions/reasons....and the closer one gets to the duct the more > > important it becomes and the less important a control-plane becomes > (at > > least dynamic routing aspects). > > > > regards, Neil > > > > > -----Original Message----- > > > From: owner-ccamp@ops.ietf.org > > > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Igor Bryskin > > > Sent: 31 October 2005 14:10 > > > To: Drake, John E; Zafar Ali (zali); Igor Bryskin > > > Cc: drake@movaz.com; dpapadimitriou@psg.com; > > > dimitri.papadimitriou@alcatel.be; Kim Young Hwa; ccamp@ops.ietf.org > > > Subject: Re: Two Drafts for Resilience of Control Plane > > > > > > > > > John, > > > > > > > > > > > > > > > > > > > > > > States are supposed to be destroyed on explicit > > > signalling message > > > > > (e.g. PathTear or PathErr with the state removal flag), but not > > > > > because of the absence of refreshes. > > > > > > > > [JD] > > > > > > Igor, > > > > > > Just to be clear, we are talking about RSVP here, and RSVP > > > *is* a soft state protocol. Can you point to any RFC that > > > supports your statements above? > > > > > > IB>> Oh, come on, John. You sound like you've been yourself > > > in a dormant > > > state for a while :=3D). We've gone a long way since RFC2205. > > > In RFC3471, for example, there is a discussion why GMPLS is > > > needed and how is it different from MPLS. One of the > > > differences is the fact that soft state protocols do not work > > > well for non-packet environments. Here is from the RDC3471: > > > > > > > > > > > > 9.2. Fault Handling There are two new faults that must be > > > handled when > > > the control channel is independent of the data channel. In > > > the first, > > > there is a link or other type of failure that limits the ability > of > > > neighboring nodes to pass control messages. In this situation, > > > neighboring nodes are unable to exchange control messages > > > for a period of > > > time. Once communication is restored the underlying > > > signaling protocol > > > must indicate that the nodes have maintained their state through > the > > > failure.. > > > > > > What is more important is the reality of life: The customers > > > simply say that you cannot destroy a user service (or even > > > force any traffic hits) just because you have a problem in > > > the control plane. If this does not fit your soft-state > > > paradigm, than "harden" your protocols or flash them down the > > > toilet and come with something else if you want our business. > > > After all, if we provision the services via NMS, we do not > > > have to destroy the services if we have problems in the > > > management network. It is that simple. > > > > > > > > > > > > Igor > > > > > > > > > > > > > > > > > > > > > From owner-ccamp@ops.ietf.org Mon Oct 31 10:40:55 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWbmI-00012Z-6m for ccamp-archive@megatron.ietf.org; Mon, 31 Oct 2005 10:40:55 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14743 for ; Mon, 31 Oct 2005 10:40:34 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EWc0U-00087o-B3 for ccamp-archive@ietf.org; Mon, 31 Oct 2005 10:55:35 -0500 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EWbhW-0006iZ-N7 for ccamp-data@psg.com; Mon, 31 Oct 2005 15:35:58 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [130.76.32.69] (helo=blv-smtpout-01.boeing.com) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EWbhV-0006iJ-Ea; Mon, 31 Oct 2005 15:35:57 +0000 Received: from blv-av-01.boeing.com ([192.42.227.216]) by blv-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id HAA18476; Mon, 31 Oct 2005 07:35:56 -0800 (PST) Received: from XCH-SWBH-04.sw.nos.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id j9VFZuH29548; Mon, 31 Oct 2005 07:35:56 -0800 (PST) Received: from XCH-SW-42.sw.nos.boeing.com ([192.79.11.43]) by XCH-SWBH-04.sw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 31 Oct 2005 07:35:55 -0800 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: comments on draft-shiba-ccamp-gmpls-lambda-labels-00.txt Date: Mon, 31 Oct 2005 07:35:55 -0800 Message-ID: <626FC7C6A97381468FB872072AB5DDC836971A@XCH-SW-42.sw.nos.boeing.com> Thread-Topic: comments on draft-shiba-ccamp-gmpls-lambda-labels-00.txt Thread-Index: AcXbIzcAFoI5B5TzS9O/zBGY1cMJbwA6iz0AAIdyNZAAAR14UA== From: "Drake, John E" To: "Shiba, Sidney" , Cc: "Adrian Farrel" , , X-OriginalArrivalTime: 31 Oct 2005 15:35:55.0489 (UTC) FILETIME=[C8945D10:01C5DE30] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 89ebdf268eceaeaf784b3acb625dc20e Content-Transfer-Encoding: quoted-printable Sidney, But there's nothing in your picture that requires an absolute end-end global wavelength. The existing GMPLS solution with relative wavelengths of local significance should work just fine. As I said in my previous note, your method precludes combining two or more parallel WDM links into a single TE link. Thanks, John > -----Original Message----- > From: Shiba, Sidney [mailto:sidney.shiba@us.fujitsu.com] > Sent: Monday, October 31, 2005 7:25 AM > To: Drake, John E; dpapadimitriou@psg.com > Cc: Adrian Farrel; richard.rabbat@us.fujitsu.com; ccamp@ops.ietf.org > Subject: RE: comments on draft-shiba-ccamp-gmpls-lambda-labels-00.txt >=20 > Hi John, >=20 > Optical switches based on Wavelength Selective Switch (WSS) technology > requires the wavelength information for switching. This technology is NOT > wavelength agnostic. >=20 > | | > | wdm | wdm > |2 |2 > --------- --------- > wdm 1| optical |3 wdm 1| optical |3 wdm > --------| switch |------------| switch |--------- > | (WSS) | | (WSS) | > --------- --------- > |4 |4 > | wdm | wdm > | | >=20 > Note that the figure above shows an example of two optical switches > interconnect > by a single WDM fiber. In this example, each optical switch can be connect > to 4 > other optical switches. >=20 > As you can see, the optical ports information do not provide enough > information > for wavelength switching. >=20 > Hope that clarifies the application requirement. >=20 > Thanks, >=20 > Sidney >=20 > > -----Original Message----- > > From: Drake, John E [mailto:John.E.Drake2@boeing.com] > > Sent: Friday, October 28, 2005 5:33 PM > > To: dpapadimitriou@psg.com; Shiba, Sidney > > Cc: Adrian Farrel; richard.rabbat@us.fujitsu.com; ccamp@ops.ietf.org > > Subject: RE: comments on draft-shiba-ccamp-gmpls-lambda-labels-00.txt > > > > > > Hi, > > > > Below is the text of an e-mail is sent to the Ethernet/GMPLS mailing > > list. > > > > Upon reflection I am not sure using a real wavelength value makes much > > sense. Between a pair of adjacent nodes, there may be > > multiple pairs of > > switch ports in the same TE link that support a given frequency. If a > > real wavelength value is used, how do the two nodes agree on > > which pair > > of switch ports to use? > > > > Furthermore, the amount of configuration is the same - you > > still need to > > configure the wavelength of each switch port. > > > > Thanks, > > > > John > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > =3D=3D=3D=3D > > Adrian, > > > > In the transparent photonic lambda switch case, the labels also have > > only local significance. When an LSP is established, the input ports, > > as identified with local labels, are cross-connected to the output > > ports, as identified with local labels. > > > > There is just extra configuration to identify, using strictly local > > identifiers, the wavelength associated with the all of the switch's > > ports, and an additional CAC requirement that the wavelengths of the > > input and output ports are the same. > > > > Thanks, > > > > John > > > > > > > -----Original Message----- > > > From: dimitri papadimitriou [mailto:dpapadimitriou@psg.com] > > > Sent: Thursday, October 27, 2005 10:03 AM > > > To: Shiba, Sidney > > > Cc: dimitri.papadimitriou@alcatel.be; Adrian Farrel; > > > richard.rabbat@us.fujitsu.com; ccamp@ops.ietf.org > > > Subject: Re: comments on > > draft-shiba-ccamp-gmpls-lambda-labels-00.txt > > > > > > shiba - see inline for some additional hints: > > > > > > >>Shiba, Sidney wrote: > > > >> > > > >>>Adrian, Dimitri, > > > >>> > > > >>>Thanks for reviewing these I-D. > > > >>> > > > >>>Wavelength continuity constraint does require the use of > > semanticful > > > >>>label whether it is spectral or index. > > > >> > > > >>=3D> see my reply to adrian on this specific point > > > >> > > > >>>I agree with Dimitri that the > > > >>>wavelength indexing requires document updating each time a new > > > >>>spectrum is introduced. > > > >> > > > >>=3D> indeed and in addition it requires updating the already > > > >>signaled path > > > >> > > > >>>The use of spectral label provides self maintainance, i.e., > > > >>>no need to update any document and the use of the nominal value > > > >>>provides a common semantic ground. > > > >> > > > >>=3D> what do you mean by self-maintenance - would you provide a > > > >>bit more detail > > > > > > > > [Sidney]What I've meant here was that it was not necessary to > > > > update any document when new wavelengths are inventoried. In the > > > > case of indexing approach, it would require the > > wavelength indexing > > > > document to be updated with implementation impacts. > > > > > > > > In the case, the nominal value is used, there is no need for > > > > documentation update. > > > > > > ok - what you mean here is that you are going to make use of the > > already > > > defined C-Type 2 - what about the specific encoding of the > > value space > > ? > > > > > > >>=3D> now i have a more specific question before being light-up > > > >>how do you know the frequency that you can support ? > > > > > > > > [Sidney] Some new technologies integrate optical switch and > > mux/demux > > > > capabilities, which allows the equipment to know the spectrum it > > > supports. > > > > > > indeed - but the question is what does happen if the > > "detected" values > > > (during initialization) do not match the nominal values ? you don't > > > initialize then ? > > > > > > >>if these differ from the nominal values how are you going to deal > > with > > > these > > > >>discrepancies ? > > > > > > > > [Sidney] These new technologies uses the nominal value as > > reference. > > We > > > can say > > > > that a lightpath wavelength is identified by its nominal value. If > > the > > > equipment > > > > is drifting from this nominal value, it is considered as > > a failure. > > > > > > ok - but if the deviation is such you have overlap - how the control > > > plane is going to be able to detect such failure ? > > > > > > >>this said i am not necessarily sure that having to > > maintain the data > > > plane > > > >>specifics as part of the control plane is really helping > > > >>operations (is this method not just duplicating complexity ?) > > > > > > > > [Sidney] The wavelength is WDM specific as much as the SUKLM label > > > encoding > > > > is for SONET. The wavelegth/frequency nominal value is used to > > identify > > > the > > > > facilities to cross-connect. > > > > > > there is an equivalence but there is also a major difference, the > > > structure is invariant independently of the state of the > > network, with > > > spectral value space you may have labels that become unavailable due > > to > > > non-local usage of wavelength in the network > > > > > > hence, there is also no real coupling to the data plane more than > > > knowing the type of interface and some generic capabilities > > > > > > >>>I'm not sure if the draft needs to be updated before the > > > >>>face-to-face meeting or after all comments are collected. Please > > > advise. > > > >> > > > >>=3D> suggest to keep discussion on - document update can be > > > >>performed at a later stage > > > > > > thanks, > > > - dimitri. > > > > > > >>>>-----Original Message----- > > > >>>>From: owner-ccamp@ops.ietf.org > > [mailto:owner-ccamp@ops.ietf.org]On > > > >>>>Behalf Of Adrian Farrel > > > >>>>Sent: Thursday, October 27, 2005 4:45 AM > > > >>>>To: dpapadimitriou@psg.com; dimitri.papadimitriou@alcatel.be; > > > >>>>ccamp@ops.ietf.org > > > >>>>Subject: Re: comments on > > > >> > > > >>draft-shiba-ccamp-gmpls-lambda-labels-00.txt > > > >> > > > >>>> > > > >>>>Dimitri, > > > >>>> > > > >>>>Thanks for your work reviewing these recent I-Ds. It is > > > >>>>really valuable > > > >>>>and I'd welcome other people doing similar reviews. > > > >>>> > > > >>>> > > > >>>> > > > >>>>>there is a specific point to be clarified in this document: > > > >>>>> > > > >>>>>semanticless vs semanticful label (even here there is a > > distinction > > > >>>>>between spectral vs indexes i.e. using the wavelength index) > > > >>>>> > > > >>>>>domain-wide vs link local significant label > > > >>>> > > > >>>>Without being too picky, I think all labels are semanticful > > > >>>>otherwise, we > > > >>>>would not know what resource they refered to. > > > >>>> > > > >>>>So the point reduces to whether the scope of the semantics > > > >>>>are link-local > > > >>>>or wider. > > > >>>> > > > >>>> > > > >>>> > > > >>>>>so, the comparison from this perspective with TDM labels is > > > >>>> > > > >>>>difficult to > > > >>>> > > > >>>> > > > >>>>>parse, the latter is semanticful but link local > > > >>>>> > > > >>>>>now, i don't specifically see what has changed the late 90's, > > early > > > >>>>>y2k's, to have a change in the wavelength label definition; > > > >>>> > > > >>>>This is the question I would like to get to the bottom of. In > > > >>>>other words: > > > >>>>do we need this function? > > > >>>> > > > >>>>It seems to me that the question being asked is this: > > > >>>> > > > >>>> If I want to compute a path that has some form of wavelength > > > >>>> constraints, what information do I need access to? > > > >>>> > > > >>>>Another question might be: > > > >>>> > > > >>>> If I want to signal a path with wavelength constraints what > > > >>>> information do I need to include in the signaling message? > > > >>>> > > > >>>> > > > >>>>I'd suggest that when we started on GMPLS, we were > > > >> > > > >>enthusiastic about > > > >> > > > >>>>transparent optical networks, but we were not properly > > > >>>>focusing wavelength > > > >>>>constraints because lambda-switching PXCs didn't take off. > > > >>>>Therefore we > > > >>>>didn't examine the requirements for wavelength constraints in > > > >>>>routing and > > > >>>>signaling. The authors of this I-D are claiming new hardware > > > >>>>requirements > > > >>>>for the same function. > > > >>>> > > > >>>> > > > >>>> > > > >>>>>there are > > > >>>>>several solution possible > > > >>>>> > > > >>>>>- absolute values: the freq. of the wavelength: difficult to > > adopt > > > >>>>>because referenced values are nominal and knowing all > > interactions > > > >>>>>between wavelengths this knowledge is at the end of little > > > >> > > > >>practical > > > >> > > > >>>>>usage; (introduces implicit ordering) > > > >>>>> > > > >>>>>- indexed values: the # of the wavelength: it does not > > > >> > > > >>provide for a > > > >> > > > >>>>>future proof label space for inst. in case new frequencies > > > >>>> > > > >>>>are inserted > > > >>>> > > > >>>> > > > >>>>>in the grid (introduces explicit ordering) > > > >>>>> > > > >>>>>- diff. values e.g. freq spacing starting from a reference > > > >>>> > > > >>>>value: pauses > > > >>>> > > > >>>> > > > >>>>>the question of the reference value and does suffer from the > > former > > > >>>>>issue (introduces implicit ordering) > > > >>>>> > > > >>>>>- the solution available today - cumbersome in some > > control plane > > > >>>>>operations (e.g. label set translation) and not easy to > > > >>>> > > > >>>>troubleshoot but > > > >>>> > > > >>>> > > > >>>>>independent of any physical consideration (spectral), scale to > > any > > > >>>>>number of wavelength per fiber, does not introduce any > > > >> > > > >>ordering, the > > > >> > > > >>>>>most flexible (since allowing each system to maintain its > > specific > > > >>>>>control operations) and the less constraining since maintaining > > the > > > >>>>>control plane operations independent of any data plane > > specifics > > > >>>>> > > > >>>>> > > > >>>> > > > >>>> > > >>> > > > >>>ambda-labels > > > >>>-00.txt> > > > >>> > > > >>>. > > > >>> > > > >> > > > > > > > > . > > > > > > From owner-ccamp@ops.ietf.org Mon Oct 31 10:41:21 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWbmh-0001Av-QT for ccamp-archive@megatron.ietf.org; Mon, 31 Oct 2005 10:41:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14758 for ; Mon, 31 Oct 2005 10:40:59 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EWc0u-00088O-JC for ccamp-archive@ietf.org; Mon, 31 Oct 2005 10:56:01 -0500 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EWbgz-0006fP-2z for ccamp-data@psg.com; Mon, 31 Oct 2005 15:35:25 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-4.8 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from localhost ([127.0.0.1]) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EWbgy-0006em-7t; Mon, 31 Oct 2005 15:35:24 +0000 Message-ID: <436639BA.6040405@psg.com> Date: Mon, 31 Oct 2005 16:35:22 +0100 From: dimitri papadimitriou Reply-To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.11) Gecko/20050728 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Igor Bryskin CC: "Drake, John E" , "Zafar Ali (zali)" , Igor Bryskin , drake@movaz.com, dimitri.papadimitriou@alcatel.be, Kim Young Hwa , ccamp@ops.ietf.org Subject: Re: Two Drafts for Resilience of Control Plane References: <626FC7C6A97381468FB872072AB5DDC8369714@XCH-SW-42.sw.nos.boeing.com> <00b201c5de24$c20fc710$7a1810ac@movaz.com> In-Reply-To: <00b201c5de24$c20fc710$7a1810ac@movaz.com> 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: 00e94c813bef7832af255170dca19e36 Content-Transfer-Encoding: 7bit igor - my two cents RSVP over time has progressively borrowed mechanisms from "hard-state" protocols, explicit deletion using PathTear is most noticeable and initial example of this evolution ! but in any case, RSVP still relies is on idem-potent soft-states that are flushed when not refreshed after certain time interval (or self- maintained if previously negotiated) this prevents orphans in the network (so unused resources) and provides for resilience - hence there is by no means a need to introduce an additional protocol mechanism to trigger or not such event via the "control plane" - btw, the paragraph you mention in RFC3471 does not say "soft state protocols do not work well for non-packet environments" this is your interpretation; ps: you are still free to make use of RFC3472 in case (as you were apparently looking for something else ;-) Igor Bryskin wrote: > John, > > > >>>States are supposed to be destroyed on explicit signalling >>>message (e.g. PathTear or PathErr with the state removal >>>flag), but not because of the absence of refreshes. >>> > > [JD] > > Igor, > > Just to be clear, we are talking about RSVP here, and RSVP *is* a soft > state protocol. Can you point to any RFC that supports your statements > above? > > IB>> Oh, come on, John. You sound like you've been yourself in a dormant > state for a while :=). We've gone a long way since RFC2205. In RFC3471, for > example, there is a discussion why GMPLS is needed and how is it different > from MPLS. One of the differences is the fact that soft state protocols do > not work well for non-packet environments. Here is from the RDC3471: > > > > 9.2. Fault Handling There are two new faults that must be handled when > the control channel is independent of the data channel. In the first, > there is a link or other type of failure that limits the ability of > neighboring nodes to pass control messages. In this situation, > neighboring nodes are unable to exchange control messages for a period of > time. Once communication is restored the underlying signaling protocol > must indicate that the nodes have maintained their state through the > failure.. > > What is more important is the reality of life: The customers simply say that > you cannot destroy a user service (or even force any traffic hits) just > because you have a problem in the control plane. If this does not fit your > soft-state paradigm, than "harden" your protocols or flash them down the > toilet and come with something else if you want our business. After all, if > we provision the services via NMS, we do not have to destroy the services if > we have problems in the management network. It is that simple. > > > > Igor > > > > > > > > . > From owner-ccamp@ops.ietf.org Mon Oct 31 10:50:23 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWbvS-0003UL-RZ for ccamp-archive@megatron.ietf.org; Mon, 31 Oct 2005 10:50:23 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15342 for ; Mon, 31 Oct 2005 10:50:02 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EWc9f-0000iF-OM for ccamp-archive@ietf.org; Mon, 31 Oct 2005 11:05:04 -0500 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EWbnz-0007BO-Uf for ccamp-data@psg.com; Mon, 31 Oct 2005 15:42:39 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [70.158.43.219] (helo=jera.movaz.com) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EWbny-0007B3-FF for ccamp@ops.ietf.org; Mon, 31 Oct 2005 15:42:38 +0000 Received: from ib (unknown [172.16.24.122]) by jera.movaz.com (Postfix) with SMTP id F06511477A; Mon, 31 Oct 2005 10:42:36 -0500 (EST) Message-ID: <010f01c5de31$b81c18a0$7a1810ac@movaz.com> From: "Igor Bryskin" To: "Drake, John E" , , , Cc: , , , , References: <626FC7C6A97381468FB872072AB5DDC8369719@XCH-SW-42.sw.nos.boeing.com> Subject: Re: Two Drafts for Resilience of Control Plane Date: Mon, 31 Oct 2005 10:42:36 -0500 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: 9af087f15dbdd4c64ae6bbcdbc5b1d44 Content-Transfer-Encoding: 7bit John, > This discussion is about resilience of control plane and whether some > standardized solutions (and hence additional work in CCAMP) is needed. [JD] We're still waiting for you to describe what you think is needed. All you do is continue to assert that additional work is needed. No John, This is not true, I gave you a very specific problem - provide mechanisms to manage LSPs with impaired control plane (when one or more controllers are out of service). You said that this is not a problem, because RSVP is a soft state protocol and once there are no refreshes the control data plane states must be destroyed and hence there is nothing to manage. And I tried very hard to explain you why this is not acceptable and hence must be addressed. I have a solution and am planning to write a draft. I'd like this work to live in CCAMP. Igor > So > I > disagree with you when you say that the discussion has nothing to do with > NMS, because one can evaluate the resilience only compared with one of > some > alternative way of service provisioning and management. I personally do > not > see any technical reason why managing services via control plane should be > less resilient than doing so via management plane. [JD] As I said in my note, I don't consider the two to be competing. > However, to achieve > this > some additional work is required. [JD] Argument by emphatic repetition? > > > > Igor > > ----- Original Message ----- > From: "Drake, John E" > To: ; ; ; > > Cc: ; ; > ; ; > > Sent: Monday, October 31, 2005 9:40 AM > Subject: RE: Two Drafts for Resilience of Control Plane > > > Neil, > > I don't think the discussion, at least from my perspective, has anything > to do with the NMS, other than this strange assertion that the NMS will > always be able to reach every node in the network even if there is a > control plane failure. > > I have always considered the control plane to be a component in a larger > system that also includes the NMS, etc. > > Thanks, > > John > > > -----Original Message----- > > From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com] > > Sent: Monday, October 31, 2005 6:32 AM > > To: ibryskin@movaz.com; Drake, John E; zali@cisco.com; > i_bryskin@yahoo.com > > Cc: drake@movaz.com; dpapadimitriou@psg.com; > > dimitri.papadimitriou@alcatel.be; yhwkim@etri.re.kr; > ccamp@ops.ietf.org > > Subject: RE: Two Drafts for Resilience of Control Plane > > > > Igor....if it's any comfort to you, folks here in BT agree with you. > > And I don't care what anyone says about the NMS and the futile > attempts > > to obsolete it....we will always need this for a whole raft of > > functions/reasons....and the closer one gets to the duct the more > > important it becomes and the less important a control-plane becomes > (at > > least dynamic routing aspects). > > > > regards, Neil > > > > > -----Original Message----- > > > From: owner-ccamp@ops.ietf.org > > > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Igor Bryskin > > > Sent: 31 October 2005 14:10 > > > To: Drake, John E; Zafar Ali (zali); Igor Bryskin > > > Cc: drake@movaz.com; dpapadimitriou@psg.com; > > > dimitri.papadimitriou@alcatel.be; Kim Young Hwa; ccamp@ops.ietf.org > > > Subject: Re: Two Drafts for Resilience of Control Plane > > > > > > > > > John, > > > > > > > > > > > > > > > > > > > > > > States are supposed to be destroyed on explicit > > > signalling message > > > > > (e.g. PathTear or PathErr with the state removal flag), but not > > > > > because of the absence of refreshes. > > > > > > > > [JD] > > > > > > Igor, > > > > > > Just to be clear, we are talking about RSVP here, and RSVP > > > *is* a soft state protocol. Can you point to any RFC that > > > supports your statements above? > > > > > > IB>> Oh, come on, John. You sound like you've been yourself > > > in a dormant > > > state for a while :=). We've gone a long way since RFC2205. > > > In RFC3471, for example, there is a discussion why GMPLS is > > > needed and how is it different from MPLS. One of the > > > differences is the fact that soft state protocols do not work > > > well for non-packet environments. Here is from the RDC3471: > > > > > > > > > > > > 9.2. Fault Handling There are two new faults that must be > > > handled when > > > the control channel is independent of the data channel. In > > > the first, > > > there is a link or other type of failure that limits the ability > of > > > neighboring nodes to pass control messages. In this situation, > > > neighboring nodes are unable to exchange control messages > > > for a period of > > > time. Once communication is restored the underlying > > > signaling protocol > > > must indicate that the nodes have maintained their state through > the > > > failure.. > > > > > > What is more important is the reality of life: The customers > > > simply say that you cannot destroy a user service (or even > > > force any traffic hits) just because you have a problem in > > > the control plane. If this does not fit your soft-state > > > paradigm, than "harden" your protocols or flash them down the > > > toilet and come with something else if you want our business. > > > After all, if we provision the services via NMS, we do not > > > have to destroy the services if we have problems in the > > > management network. It is that simple. > > > > > > > > > > > > Igor > > > > > > > > > > > > > > > > > > > > > From owner-ccamp@ops.ietf.org Mon Oct 31 10:55:29 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWc0P-0004fV-5C for ccamp-archive@megatron.ietf.org; Mon, 31 Oct 2005 10:55:29 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15584 for ; Mon, 31 Oct 2005 10:55:09 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EWcEV-0001Zf-G7 for ccamp-archive@ietf.org; Mon, 31 Oct 2005 11:10:10 -0500 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EWbw0-0007lA-2s for ccamp-data@psg.com; Mon, 31 Oct 2005 15:50:56 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [130.76.96.56] (helo=stl-smtpout-01.boeing.com) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EWbvy-0007kw-5y; Mon, 31 Oct 2005 15:50:54 +0000 Received: from stl-av-01.boeing.com ([192.76.190.6]) by stl-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id JAA23085; Mon, 31 Oct 2005 09:50:53 -0600 (CST) Received: from XCH-SWBH-04.sw.nos.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id j9VFoqY26929; Mon, 31 Oct 2005 09:50:52 -0600 (CST) Received: from XCH-SW-42.sw.nos.boeing.com ([192.79.11.43]) by XCH-SWBH-04.sw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 31 Oct 2005 07:50:51 -0800 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: comments on draft-shiba-ccamp-gmpls-lambda-labels-00.txt Date: Mon, 31 Oct 2005 07:50:51 -0800 Message-ID: <626FC7C6A97381468FB872072AB5DDC836971B@XCH-SW-42.sw.nos.boeing.com> Thread-Topic: comments on draft-shiba-ccamp-gmpls-lambda-labels-00.txt Thread-Index: AcXbIzcAFoI5B5TzS9O/zBGY1cMJbwA6iz0AAIdyNZAAAR14UAAAnn6w From: "Drake, John E" To: "Drake, John E" , "Shiba, Sidney" , Cc: "Adrian Farrel" , , X-OriginalArrivalTime: 31 Oct 2005 15:50:51.0589 (UTC) FILETIME=[DEB25F50:01C5DE32] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 75ac86d24bd0a3cd8a26e327ae61143e Content-Transfer-Encoding: quoted-printable Sidney, There's another issue as well. Having absolute end-end global wavelengths is probably insufficient to ensure that an end-end LSP can be established successfully, as having a common wavelength does not mean that equipment from different vendors will interoperate correctly in the data-plane. Thanks, John > -----Original Message----- > From: Drake, John E > Sent: Monday, October 31, 2005 7:36 AM > To: Shiba, Sidney; dpapadimitriou@psg.com > Cc: Adrian Farrel; richard.rabbat@us.fujitsu.com; ccamp@ops.ietf.org > Subject: RE: comments on draft-shiba-ccamp-gmpls-lambda-labels-00.txt >=20 > Sidney, >=20 > But there's nothing in your picture that requires an absolute end-end > global wavelength. The existing GMPLS solution with relative > wavelengths of local significance should work just fine. As I said in > my previous note, your method precludes combining two or more parallel > WDM links into a single TE link. >=20 > Thanks, >=20 > John >=20 > > -----Original Message----- > > From: Shiba, Sidney [mailto:sidney.shiba@us.fujitsu.com] > > Sent: Monday, October 31, 2005 7:25 AM > > To: Drake, John E; dpapadimitriou@psg.com > > Cc: Adrian Farrel; richard.rabbat@us.fujitsu.com; ccamp@ops.ietf.org > > Subject: RE: comments on draft-shiba-ccamp-gmpls-lambda-labels-00.txt > > > > Hi John, > > > > Optical switches based on Wavelength Selective Switch (WSS) technology > > requires the wavelength information for switching. This technology is > NOT > > wavelength agnostic. > > > > | | > > | wdm | wdm > > |2 |2 > > --------- --------- > > wdm 1| optical |3 wdm 1| optical |3 wdm > > --------| switch |------------| switch |--------- > > | (WSS) | | (WSS) | > > --------- --------- > > |4 |4 > > | wdm | wdm > > | | > > > > Note that the figure above shows an example of two optical switches > > interconnect > > by a single WDM fiber. In this example, each optical switch can be > connect > > to 4 > > other optical switches. > > > > As you can see, the optical ports information do not provide enough > > information > > for wavelength switching. > > > > Hope that clarifies the application requirement. > > > > Thanks, > > > > Sidney > > > > > -----Original Message----- > > > From: Drake, John E [mailto:John.E.Drake2@boeing.com] > > > Sent: Friday, October 28, 2005 5:33 PM > > > To: dpapadimitriou@psg.com; Shiba, Sidney > > > Cc: Adrian Farrel; richard.rabbat@us.fujitsu.com; ccamp@ops.ietf.org > > > Subject: RE: comments on > draft-shiba-ccamp-gmpls-lambda-labels-00.txt > > > > > > > > > Hi, > > > > > > Below is the text of an e-mail is sent to the Ethernet/GMPLS mailing > > > list. > > > > > > Upon reflection I am not sure using a real wavelength value makes > much > > > sense. Between a pair of adjacent nodes, there may be > > > multiple pairs of > > > switch ports in the same TE link that support a given frequency. If > a > > > real wavelength value is used, how do the two nodes agree on > > > which pair > > > of switch ports to use? > > > > > > Furthermore, the amount of configuration is the same - you > > > still need to > > > configure the wavelength of each switch port. > > > > > > Thanks, > > > > > > John > > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > =3D=3D=3D=3D > > > Adrian, > > > > > > In the transparent photonic lambda switch case, the labels also have > > > only local significance. When an LSP is established, the input > ports, > > > as identified with local labels, are cross-connected to the output > > > ports, as identified with local labels. > > > > > > There is just extra configuration to identify, using strictly local > > > identifiers, the wavelength associated with the all of the switch's > > > ports, and an additional CAC requirement that the wavelengths of the > > > input and output ports are the same. > > > > > > Thanks, > > > > > > John > > > > > > > > > > -----Original Message----- > > > > From: dimitri papadimitriou [mailto:dpapadimitriou@psg.com] > > > > Sent: Thursday, October 27, 2005 10:03 AM > > > > To: Shiba, Sidney > > > > Cc: dimitri.papadimitriou@alcatel.be; Adrian Farrel; > > > > richard.rabbat@us.fujitsu.com; ccamp@ops.ietf.org > > > > Subject: Re: comments on > > > draft-shiba-ccamp-gmpls-lambda-labels-00.txt > > > > > > > > shiba - see inline for some additional hints: > > > > > > > > >>Shiba, Sidney wrote: > > > > >> > > > > >>>Adrian, Dimitri, > > > > >>> > > > > >>>Thanks for reviewing these I-D. > > > > >>> > > > > >>>Wavelength continuity constraint does require the use of > > > semanticful > > > > >>>label whether it is spectral or index. > > > > >> > > > > >>=3D> see my reply to adrian on this specific point > > > > >> > > > > >>>I agree with Dimitri that the > > > > >>>wavelength indexing requires document updating each time a new > > > > >>>spectrum is introduced. > > > > >> > > > > >>=3D> indeed and in addition it requires updating the already > > > > >>signaled path > > > > >> > > > > >>>The use of spectral label provides self maintainance, i.e., > > > > >>>no need to update any document and the use of the nominal value > > > > >>>provides a common semantic ground. > > > > >> > > > > >>=3D> what do you mean by self-maintenance - would you provide = a > > > > >>bit more detail > > > > > > > > > > [Sidney]What I've meant here was that it was not necessary to > > > > > update any document when new wavelengths are inventoried. In the > > > > > case of indexing approach, it would require the > > > wavelength indexing > > > > > document to be updated with implementation impacts. > > > > > > > > > > In the case, the nominal value is used, there is no need for > > > > > documentation update. > > > > > > > > ok - what you mean here is that you are going to make use of the > > > already > > > > defined C-Type 2 - what about the specific encoding of the > > > value space > > > ? > > > > > > > > >>=3D> now i have a more specific question before being light-up > > > > >>how do you know the frequency that you can support ? > > > > > > > > > > [Sidney] Some new technologies integrate optical switch and > > > mux/demux > > > > > capabilities, which allows the equipment to know the spectrum it > > > > supports. > > > > > > > > indeed - but the question is what does happen if the > > > "detected" values > > > > (during initialization) do not match the nominal values ? you > don't > > > > initialize then ? > > > > > > > > >>if these differ from the nominal values how are you going to > deal > > > with > > > > these > > > > >>discrepancies ? > > > > > > > > > > [Sidney] These new technologies uses the nominal value as > > > reference. > > > We > > > > can say > > > > > that a lightpath wavelength is identified by its nominal value. > If > > > the > > > > equipment > > > > > is drifting from this nominal value, it is considered as > > > a failure. > > > > > > > > ok - but if the deviation is such you have overlap - how the > control > > > > plane is going to be able to detect such failure ? > > > > > > > > >>this said i am not necessarily sure that having to > > > maintain the data > > > > plane > > > > >>specifics as part of the control plane is really helping > > > > >>operations (is this method not just duplicating complexity ?) > > > > > > > > > > [Sidney] The wavelength is WDM specific as much as the SUKLM > label > > > > encoding > > > > > is for SONET. The wavelegth/frequency nominal value is used to > > > identify > > > > the > > > > > facilities to cross-connect. > > > > > > > > there is an equivalence but there is also a major difference, the > > > > structure is invariant independently of the state of the > > > network, with > > > > spectral value space you may have labels that become unavailable > due > > > to > > > > non-local usage of wavelength in the network > > > > > > > > hence, there is also no real coupling to the data plane more than > > > > knowing the type of interface and some generic capabilities > > > > > > > > >>>I'm not sure if the draft needs to be updated before the > > > > >>>face-to-face meeting or after all comments are collected. > Please > > > > advise. > > > > >> > > > > >>=3D> suggest to keep discussion on - document update can be > > > > >>performed at a later stage > > > > > > > > thanks, > > > > - dimitri. > > > > > > > > >>>>-----Original Message----- > > > > >>>>From: owner-ccamp@ops.ietf.org > > > [mailto:owner-ccamp@ops.ietf.org]On > > > > >>>>Behalf Of Adrian Farrel > > > > >>>>Sent: Thursday, October 27, 2005 4:45 AM > > > > >>>>To: dpapadimitriou@psg.com; dimitri.papadimitriou@alcatel.be; > > > > >>>>ccamp@ops.ietf.org > > > > >>>>Subject: Re: comments on > > > > >> > > > > >>draft-shiba-ccamp-gmpls-lambda-labels-00.txt > > > > >> > > > > >>>> > > > > >>>>Dimitri, > > > > >>>> > > > > >>>>Thanks for your work reviewing these recent I-Ds. It is > > > > >>>>really valuable > > > > >>>>and I'd welcome other people doing similar reviews. > > > > >>>> > > > > >>>> > > > > >>>> > > > > >>>>>there is a specific point to be clarified in this document: > > > > >>>>> > > > > >>>>>semanticless vs semanticful label (even here there is a > > > distinction > > > > >>>>>between spectral vs indexes i.e. using the wavelength index) > > > > >>>>> > > > > >>>>>domain-wide vs link local significant label > > > > >>>> > > > > >>>>Without being too picky, I think all labels are semanticful > > > > >>>>otherwise, we > > > > >>>>would not know what resource they refered to. > > > > >>>> > > > > >>>>So the point reduces to whether the scope of the semantics > > > > >>>>are link-local > > > > >>>>or wider. > > > > >>>> > > > > >>>> > > > > >>>> > > > > >>>>>so, the comparison from this perspective with TDM labels is > > > > >>>> > > > > >>>>difficult to > > > > >>>> > > > > >>>> > > > > >>>>>parse, the latter is semanticful but link local > > > > >>>>> > > > > >>>>>now, i don't specifically see what has changed the late 90's, > > > early > > > > >>>>>y2k's, to have a change in the wavelength label definition; > > > > >>>> > > > > >>>>This is the question I would like to get to the bottom of. In > > > > >>>>other words: > > > > >>>>do we need this function? > > > > >>>> > > > > >>>>It seems to me that the question being asked is this: > > > > >>>> > > > > >>>> If I want to compute a path that has some form of wavelength > > > > >>>> constraints, what information do I need access to? > > > > >>>> > > > > >>>>Another question might be: > > > > >>>> > > > > >>>> If I want to signal a path with wavelength constraints what > > > > >>>> information do I need to include in the signaling message? > > > > >>>> > > > > >>>> > > > > >>>>I'd suggest that when we started on GMPLS, we were > > > > >> > > > > >>enthusiastic about > > > > >> > > > > >>>>transparent optical networks, but we were not properly > > > > >>>>focusing wavelength > > > > >>>>constraints because lambda-switching PXCs didn't take off. > > > > >>>>Therefore we > > > > >>>>didn't examine the requirements for wavelength constraints in > > > > >>>>routing and > > > > >>>>signaling. The authors of this I-D are claiming new hardware > > > > >>>>requirements > > > > >>>>for the same function. > > > > >>>> > > > > >>>> > > > > >>>> > > > > >>>>>there are > > > > >>>>>several solution possible > > > > >>>>> > > > > >>>>>- absolute values: the freq. of the wavelength: difficult to > > > adopt > > > > >>>>>because referenced values are nominal and knowing all > > > interactions > > > > >>>>>between wavelengths this knowledge is at the end of little > > > > >> > > > > >>practical > > > > >> > > > > >>>>>usage; (introduces implicit ordering) > > > > >>>>> > > > > >>>>>- indexed values: the # of the wavelength: it does not > > > > >> > > > > >>provide for a > > > > >> > > > > >>>>>future proof label space for inst. in case new frequencies > > > > >>>> > > > > >>>>are inserted > > > > >>>> > > > > >>>> > > > > >>>>>in the grid (introduces explicit ordering) > > > > >>>>> > > > > >>>>>- diff. values e.g. freq spacing starting from a reference > > > > >>>> > > > > >>>>value: pauses > > > > >>>> > > > > >>>> > > > > >>>>>the question of the reference value and does suffer from the > > > former > > > > >>>>>issue (introduces implicit ordering) > > > > >>>>> > > > > >>>>>- the solution available today - cumbersome in some > > > control plane > > > > >>>>>operations (e.g. label set translation) and not easy to > > > > >>>> > > > > >>>>troubleshoot but > > > > >>>> > > > > >>>> > > > > >>>>>independent of any physical consideration (spectral), scale > to > > > any > > > > >>>>>number of wavelength per fiber, does not introduce any > > > > >> > > > > >>ordering, the > > > > >> > > > > >>>>>most flexible (since allowing each system to maintain its > > > specific > > > > >>>>>control operations) and the less constraining since > maintaining > > > the > > > > >>>>>control plane operations independent of any data plane > > > specifics > > > > >>>>> > > > > >>>>> > > > > >>>> > > > > >>>> > > > >>> > > > > >>>ambda-labels > > > > >>>-00.txt> > > > > >>> > > > > >>>. > > > > >>> > > > > >> > > > > > > > > > > . > > > > > > > > From owner-ccamp@ops.ietf.org Mon Oct 31 10:58:23 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWc3D-0005FV-1c for ccamp-archive@megatron.ietf.org; Mon, 31 Oct 2005 10:58:23 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15729 for ; Mon, 31 Oct 2005 10:58:03 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EWcHQ-0001hZ-2e for ccamp-archive@ietf.org; Mon, 31 Oct 2005 11:13:04 -0500 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EWbz2-0007uH-45 for ccamp-data@psg.com; Mon, 31 Oct 2005 15:54:04 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [70.158.43.219] (helo=jera.movaz.com) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EWbz0-0007u3-3r for ccamp@ops.ietf.org; Mon, 31 Oct 2005 15:54:02 +0000 Received: from ib (unknown [172.16.24.122]) by jera.movaz.com (Postfix) with SMTP id D7C4A45E30; Mon, 31 Oct 2005 10:54:00 -0500 (EST) Message-ID: <011a01c5de33$4fc053f0$7a1810ac@movaz.com> From: "Igor Bryskin" To: , Cc: "Drake, John E" , "Zafar Ali (zali)" , "Igor Bryskin" , , , "Kim Young Hwa" , References: <626FC7C6A97381468FB872072AB5DDC8369714@XCH-SW-42.sw.nos.boeing.com> <00b201c5de24$c20fc710$7a1810ac@movaz.com> <436639BA.6040405@psg.com> Subject: Re: Two Drafts for Resilience of Control Plane Date: Mon, 31 Oct 2005 10:54:00 -0500 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: e1b0e72ff1bbd457ceef31828f216a86 Content-Transfer-Encoding: 7bit Dimitri, > igor - my two cents > > RSVP over time has progressively borrowed mechanisms from "hard-state" > protocols, explicit deletion using PathTear is most noticeable and > initial example of this evolution ! > > but in any case, RSVP still relies is on idem-potent soft-states that > are flushed when not refreshed after certain time interval (or self- > maintained if previously negotiated) this prevents orphans in the > network (so unused resources) and provides for resilience - hence there > is by no means a need to introduce an additional protocol mechanism to > trigger or not such event via the "control plane" - Refreshes are useful mechanism but only between neighbors that maintain Hello communication. In this case the absence of Path refreshes is as good indication that data plane must be destroyed as received PathTear message. However, when a controller does not receive Path refreshes from a neighbor it does not have any control plane communication with, it can assume neither a problem in the data plane nor intention to destroy it. Hence, as it was specified in RFC3471, it *must* maintain both control and data plane states throughout the failure. Igor > > btw, the paragraph you mention in RFC3471 does not say "soft state > protocols do not work well for non-packet environments" this is your > interpretation; > > ps: you are still free to make use of RFC3472 in case (as you were > apparently looking for something else ;-) > > Igor Bryskin wrote: > > John, > > > > > > > >>>States are supposed to be destroyed on explicit signalling > >>>message (e.g. PathTear or PathErr with the state removal > >>>flag), but not because of the absence of refreshes. > >>> > > > > [JD] > > > > Igor, > > > > Just to be clear, we are talking about RSVP here, and RSVP *is* a soft > > state protocol. Can you point to any RFC that supports your statements > > above? > > > > IB>> Oh, come on, John. You sound like you've been yourself in a dormant > > state for a while :=). We've gone a long way since RFC2205. In RFC3471, for > > example, there is a discussion why GMPLS is needed and how is it different > > from MPLS. One of the differences is the fact that soft state protocols do > > not work well for non-packet environments. Here is from the RDC3471: > > > > > > > > 9.2. Fault Handling There are two new faults that must be handled when > > the control channel is independent of the data channel. In the first, > > there is a link or other type of failure that limits the ability of > > neighboring nodes to pass control messages. In this situation, > > neighboring nodes are unable to exchange control messages for a period of > > time. Once communication is restored the underlying signaling protocol > > must indicate that the nodes have maintained their state through the > > failure.. > > > > What is more important is the reality of life: The customers simply say that > > you cannot destroy a user service (or even force any traffic hits) just > > because you have a problem in the control plane. If this does not fit your > > soft-state paradigm, than "harden" your protocols or flash them down the > > toilet and come with something else if you want our business. After all, if > > we provision the services via NMS, we do not have to destroy the services if > > we have problems in the management network. It is that simple. > > > > > > > > Igor > > > > > > > > > > > > > > > > . > > From owner-ccamp@ops.ietf.org Mon Oct 31 11:00:15 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWc51-0005k7-1t for ccamp-archive@megatron.ietf.org; Mon, 31 Oct 2005 11:00:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15921 for ; Mon, 31 Oct 2005 10:59:54 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EWcJD-0001uN-IR for ccamp-archive@ietf.org; Mon, 31 Oct 2005 11:14:56 -0500 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EWc0t-00085f-8P for ccamp-data@psg.com; Mon, 31 Oct 2005 15:55:59 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [168.127.0.56] (helo=fncnmp03.fnc.fujitsu.com) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EWc0r-00085O-IQ for ccamp@ops.ietf.org; Mon, 31 Oct 2005 15:55:57 +0000 Received: from rchemx01.fnc.net.local (167.254.101.101) by fncnmp03.fnc.fujitsu.com with ESMTP; 31 Oct 2005 09:55:57 -0600 X-IronPort-AV: i="3.97,270,1125896400"; d="scan'208"; a="15936926:sNHT18714820" 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: comments on draft-shiba-ccamp-gmpls-lambda-labels-00.txt Date: Mon, 31 Oct 2005 09:55:56 -0600 Message-ID: <7CA873794E52904EAA980A074B076779B17C61@rchemx01.fnc.net.local> Thread-Topic: comments on draft-shiba-ccamp-gmpls-lambda-labels-00.txt Thread-Index: AcXbIzcAFoI5B5TzS9O/zBGY1cMJbwA6iz0AAIdyNZAAAR14UAAAqdxA From: "Shiba, Sidney" To: "Drake, John E" , Cc: "Adrian Farrel" , , Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 28dc73ba51024f450a593b05aa945739 Content-Transfer-Encoding: quoted-printable John, Comments inline: > -----Original Message----- > From: Drake, John E [mailto:John.E.Drake2@boeing.com] > Sent: Monday, October 31, 2005 9:36 AM > To: Shiba, Sidney; dpapadimitriou@psg.com > Cc: Adrian Farrel; richard.rabbat@us.fujitsu.com; ccamp@ops.ietf.org > Subject: RE: comments on draft-shiba-ccamp-gmpls-lambda-labels-00.txt >=20 >=20 > Sidney, >=20 > But there's nothing in your picture that requires an absolute end-end > global wavelength. The existing GMPLS solution with relative > wavelengths of local significance should work just fine. [Sidney] Sorry for the missing info. The optical switch is an all = optical switch (i.e., no OEO is necessary). The wavelength continuity constraint indicates which wavelength (nominal value) all the optical switches=20 traversed by the lightpath needs to cross-connect. > As I said in my previous note, your method precludes combining two or=20 > more parallel WDM links into a single TE link. [Sidney] Note the Label is complemented by the interface id of the link. I think this is the same approach used for parallel SONET OCn datalinks where the label identifies a time-slot and interface id identifies the datalink chosen for the connection. >=20 > Thanks, >=20 > John >=20 > > -----Original Message----- > > From: Shiba, Sidney [mailto:sidney.shiba@us.fujitsu.com] > > Sent: Monday, October 31, 2005 7:25 AM > > To: Drake, John E; dpapadimitriou@psg.com > > Cc: Adrian Farrel; richard.rabbat@us.fujitsu.com; ccamp@ops.ietf.org > > Subject: RE: comments on=20 > draft-shiba-ccamp-gmpls-lambda-labels-00.txt > >=20 > > Hi John, > >=20 > > Optical switches based on Wavelength Selective Switch (WSS)=20 > technology > > requires the wavelength information for switching. This=20 > technology is > NOT > > wavelength agnostic. > >=20 > > | | > > | wdm | wdm > > |2 |2 > > --------- --------- > > wdm 1| optical |3 wdm 1| optical |3 wdm > > --------| switch |------------| switch |--------- > > | (WSS) | | (WSS) | > > --------- --------- > > |4 |4 > > | wdm | wdm > > | | > >=20 > > Note that the figure above shows an example of two optical switches > > interconnect > > by a single WDM fiber. In this example, each optical switch can be > connect > > to 4 > > other optical switches. > >=20 > > As you can see, the optical ports information do not provide enough > > information > > for wavelength switching. > >=20 > > Hope that clarifies the application requirement. > >=20 > > Thanks, > >=20 > > Sidney > >=20 > > > -----Original Message----- > > > From: Drake, John E [mailto:John.E.Drake2@boeing.com] > > > Sent: Friday, October 28, 2005 5:33 PM > > > To: dpapadimitriou@psg.com; Shiba, Sidney > > > Cc: Adrian Farrel; richard.rabbat@us.fujitsu.com;=20 > ccamp@ops.ietf.org > > > Subject: RE: comments on > draft-shiba-ccamp-gmpls-lambda-labels-00.txt > > > > > > > > > Hi, > > > > > > Below is the text of an e-mail is sent to the=20 > Ethernet/GMPLS mailing > > > list. > > > > > > Upon reflection I am not sure using a real wavelength value makes > much > > > sense. Between a pair of adjacent nodes, there may be > > > multiple pairs of > > > switch ports in the same TE link that support a given=20 > frequency. If > a > > > real wavelength value is used, how do the two nodes agree on > > > which pair > > > of switch ports to use? > > > > > > Furthermore, the amount of configuration is the same - you > > > still need to > > > configure the wavelength of each switch port. > > > > > > Thanks, > > > > > > John > > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > =3D=3D=3D=3D > > > Adrian, > > > > > > In the transparent photonic lambda switch case, the=20 > labels also have > > > only local significance. When an LSP is established, the input > ports, > > > as identified with local labels, are cross-connected to the output > > > ports, as identified with local labels. > > > > > > There is just extra configuration to identify, using=20 > strictly local > > > identifiers, the wavelength associated with the all of=20 > the switch's > > > ports, and an additional CAC requirement that the=20 > wavelengths of the > > > input and output ports are the same. > > > > > > Thanks, > > > > > > John > > > > > > > > > > -----Original Message----- > > > > From: dimitri papadimitriou [mailto:dpapadimitriou@psg.com] > > > > Sent: Thursday, October 27, 2005 10:03 AM > > > > To: Shiba, Sidney > > > > Cc: dimitri.papadimitriou@alcatel.be; Adrian Farrel; > > > > richard.rabbat@us.fujitsu.com; ccamp@ops.ietf.org > > > > Subject: Re: comments on > > > draft-shiba-ccamp-gmpls-lambda-labels-00.txt > > > > > > > > shiba - see inline for some additional hints: > > > > > > > > >>Shiba, Sidney wrote: > > > > >> > > > > >>>Adrian, Dimitri, > > > > >>> > > > > >>>Thanks for reviewing these I-D. > > > > >>> > > > > >>>Wavelength continuity constraint does require the use of > > > semanticful > > > > >>>label whether it is spectral or index. > > > > >> > > > > >>=3D> see my reply to adrian on this specific point > > > > >> > > > > >>>I agree with Dimitri that the > > > > >>>wavelength indexing requires document updating each=20 > time a new > > > > >>>spectrum is introduced. > > > > >> > > > > >>=3D> indeed and in addition it requires updating the already > > > > >>signaled path > > > > >> > > > > >>>The use of spectral label provides self maintainance, i.e., > > > > >>>no need to update any document and the use of the=20 > nominal value > > > > >>>provides a common semantic ground. > > > > >> > > > > >>=3D> what do you mean by self-maintenance - would you provide = a > > > > >>bit more detail > > > > > > > > > > [Sidney]What I've meant here was that it was not necessary to > > > > > update any document when new wavelengths are=20 > inventoried. In the > > > > > case of indexing approach, it would require the > > > wavelength indexing > > > > > document to be updated with implementation impacts. > > > > > > > > > > In the case, the nominal value is used, there is no need for > > > > > documentation update. > > > > > > > > ok - what you mean here is that you are going to make use of the > > > already > > > > defined C-Type 2 - what about the specific encoding of the > > > value space > > > ? > > > > > > > > >>=3D> now i have a more specific question before being light-up > > > > >>how do you know the frequency that you can support ? > > > > > > > > > > [Sidney] Some new technologies integrate optical switch and > > > mux/demux > > > > > capabilities, which allows the equipment to know the=20 > spectrum it > > > > supports. > > > > > > > > indeed - but the question is what does happen if the > > > "detected" values > > > > (during initialization) do not match the nominal values ? you > don't > > > > initialize then ? > > > > > > > > >>if these differ from the nominal values how are you going to > deal > > > with > > > > these > > > > >>discrepancies ? > > > > > > > > > > [Sidney] These new technologies uses the nominal value as > > > reference. > > > We > > > > can say > > > > > that a lightpath wavelength is identified by its=20 > nominal value. > If > > > the > > > > equipment > > > > > is drifting from this nominal value, it is considered as > > > a failure. > > > > > > > > ok - but if the deviation is such you have overlap - how the > control > > > > plane is going to be able to detect such failure ? > > > > > > > > >>this said i am not necessarily sure that having to > > > maintain the data > > > > plane > > > > >>specifics as part of the control plane is really helping > > > > >>operations (is this method not just duplicating complexity ?) > > > > > > > > > > [Sidney] The wavelength is WDM specific as much as the SUKLM > label > > > > encoding > > > > > is for SONET. The wavelegth/frequency nominal value is used to > > > identify > > > > the > > > > > facilities to cross-connect. > > > > > > > > there is an equivalence but there is also a major=20 > difference, the > > > > structure is invariant independently of the state of the > > > network, with > > > > spectral value space you may have labels that become unavailable > due > > > to > > > > non-local usage of wavelength in the network > > > > > > > > hence, there is also no real coupling to the data plane=20 > more than > > > > knowing the type of interface and some generic capabilities > > > > > > > > >>>I'm not sure if the draft needs to be updated before the > > > > >>>face-to-face meeting or after all comments are collected. > Please > > > > advise. > > > > >> > > > > >>=3D> suggest to keep discussion on - document update can be > > > > >>performed at a later stage > > > > > > > > thanks, > > > > - dimitri. > > > > > > > > >>>>-----Original Message----- > > > > >>>>From: owner-ccamp@ops.ietf.org > > > [mailto:owner-ccamp@ops.ietf.org]On > > > > >>>>Behalf Of Adrian Farrel > > > > >>>>Sent: Thursday, October 27, 2005 4:45 AM > > > > >>>>To: dpapadimitriou@psg.com;=20 > dimitri.papadimitriou@alcatel.be; > > > > >>>>ccamp@ops.ietf.org > > > > >>>>Subject: Re: comments on > > > > >> > > > > >>draft-shiba-ccamp-gmpls-lambda-labels-00.txt > > > > >> > > > > >>>> > > > > >>>>Dimitri, > > > > >>>> > > > > >>>>Thanks for your work reviewing these recent I-Ds. It is > > > > >>>>really valuable > > > > >>>>and I'd welcome other people doing similar reviews. > > > > >>>> > > > > >>>> > > > > >>>> > > > > >>>>>there is a specific point to be clarified in this document: > > > > >>>>> > > > > >>>>>semanticless vs semanticful label (even here there is a > > > distinction > > > > >>>>>between spectral vs indexes i.e. using the=20 > wavelength index) > > > > >>>>> > > > > >>>>>domain-wide vs link local significant label > > > > >>>> > > > > >>>>Without being too picky, I think all labels are semanticful > > > > >>>>otherwise, we > > > > >>>>would not know what resource they refered to. > > > > >>>> > > > > >>>>So the point reduces to whether the scope of the semantics > > > > >>>>are link-local > > > > >>>>or wider. > > > > >>>> > > > > >>>> > > > > >>>> > > > > >>>>>so, the comparison from this perspective with TDM labels is > > > > >>>> > > > > >>>>difficult to > > > > >>>> > > > > >>>> > > > > >>>>>parse, the latter is semanticful but link local > > > > >>>>> > > > > >>>>>now, i don't specifically see what has changed the=20 > late 90's, > > > early > > > > >>>>>y2k's, to have a change in the wavelength label definition; > > > > >>>> > > > > >>>>This is the question I would like to get to the=20 > bottom of. In > > > > >>>>other words: > > > > >>>>do we need this function? > > > > >>>> > > > > >>>>It seems to me that the question being asked is this: > > > > >>>> > > > > >>>> If I want to compute a path that has some form of=20 > wavelength > > > > >>>> constraints, what information do I need access to? > > > > >>>> > > > > >>>>Another question might be: > > > > >>>> > > > > >>>> If I want to signal a path with wavelength=20 > constraints what > > > > >>>> information do I need to include in the signaling message? > > > > >>>> > > > > >>>> > > > > >>>>I'd suggest that when we started on GMPLS, we were > > > > >> > > > > >>enthusiastic about > > > > >> > > > > >>>>transparent optical networks, but we were not properly > > > > >>>>focusing wavelength > > > > >>>>constraints because lambda-switching PXCs didn't take off. > > > > >>>>Therefore we > > > > >>>>didn't examine the requirements for wavelength=20 > constraints in > > > > >>>>routing and > > > > >>>>signaling. The authors of this I-D are claiming new hardware > > > > >>>>requirements > > > > >>>>for the same function. > > > > >>>> > > > > >>>> > > > > >>>> > > > > >>>>>there are > > > > >>>>>several solution possible > > > > >>>>> > > > > >>>>>- absolute values: the freq. of the wavelength:=20 > difficult to > > > adopt > > > > >>>>>because referenced values are nominal and knowing all > > > interactions > > > > >>>>>between wavelengths this knowledge is at the end of little > > > > >> > > > > >>practical > > > > >> > > > > >>>>>usage; (introduces implicit ordering) > > > > >>>>> > > > > >>>>>- indexed values: the # of the wavelength: it does not > > > > >> > > > > >>provide for a > > > > >> > > > > >>>>>future proof label space for inst. in case new frequencies > > > > >>>> > > > > >>>>are inserted > > > > >>>> > > > > >>>> > > > > >>>>>in the grid (introduces explicit ordering) > > > > >>>>> > > > > >>>>>- diff. values e.g. freq spacing starting from a reference > > > > >>>> > > > > >>>>value: pauses > > > > >>>> > > > > >>>> > > > > >>>>>the question of the reference value and does=20 > suffer from the > > > former > > > > >>>>>issue (introduces implicit ordering) > > > > >>>>> > > > > >>>>>- the solution available today - cumbersome in some > > > control plane > > > > >>>>>operations (e.g. label set translation) and not easy to > > > > >>>> > > > > >>>>troubleshoot but > > > > >>>> > > > > >>>> > > > > >>>>>independent of any physical consideration (spectral), scale > to > > > any > > > > >>>>>number of wavelength per fiber, does not introduce any > > > > >> > > > > >>ordering, the > > > > >> > > > > >>>>>most flexible (since allowing each system to maintain its > > > specific > > > > >>>>>control operations) and the less constraining since > maintaining > > > the > > > > >>>>>control plane operations independent of any data plane > > > specifics > > > > >>>>> > > > > >>>>> > > > > >>>> > > > >=20 > >>>> > > > >>> > > > > >>>ambda-labels > > > > >>>-00.txt> > > > > >>> > > > > >>>. > > > > >>> > > > > >> > > > > > > > > > > . > > > > > > > > >=20 From owner-ccamp@ops.ietf.org Mon Oct 31 11:01:18 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWc62-0006He-BZ for ccamp-archive@megatron.ietf.org; Mon, 31 Oct 2005 11:01:18 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16206 for ; Mon, 31 Oct 2005 11:00:58 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EWcKD-00026V-Ge for ccamp-archive@ietf.org; Mon, 31 Oct 2005 11:15:59 -0500 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EWc2E-0008BV-94 for ccamp-data@psg.com; Mon, 31 Oct 2005 15:57:22 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [132.151.6.50] (helo=newodin.ietf.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1EWc2D-0008BD-3i for ccamp@ops.ietf.org; Mon, 31 Oct 2005 15:57:21 +0000 Received: from apache by newodin.ietf.org with local (Exim 4.43) id 1EWc2B-0006ri-Fr; Mon, 31 Oct 2005 10:57:19 -0500 X-test-idtracker: no To: IETF-Announce From: The IESG Subject: Last Call: 'Reoptimization of Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) loosely routed Label Switch Path (LSP)' to Informational RFC Reply-to: iesg@ietf.org CC: Message-Id: Date: Mon, 31 Oct 2005 10:57:19 -0500 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c The IESG has received a request from the Common Control and Measurement Plane WG to consider the following document: - 'Reoptimization of Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) loosely routed Label Switch Path (LSP) ' as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2005-11-25. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-ccamp-loose-path-reopt-01.txt From owner-ccamp@ops.ietf.org Mon Oct 31 11:05:55 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWcAV-00085J-1f for ccamp-archive@megatron.ietf.org; Mon, 31 Oct 2005 11:05:55 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17205 for ; Mon, 31 Oct 2005 11:05:34 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EWcOh-00038D-Jo for ccamp-archive@ietf.org; Mon, 31 Oct 2005 11:20:36 -0500 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EWc5F-0008UD-VS for ccamp-data@psg.com; Mon, 31 Oct 2005 16:00:29 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [168.127.0.57] (helo=fncnmp04.fnc.fujitsu.com) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EWc5E-0008Ts-5u for ccamp@ops.ietf.org; Mon, 31 Oct 2005 16:00:28 +0000 Received: from rchemx01.fnc.net.local (167.254.101.101) by fncnmp04.fnc.fujitsu.com with ESMTP; 31 Oct 2005 10:00:16 -0600 X-IronPort-AV: i="3.97,270,1125896400"; d="scan'208"; a="10646474:sNHT3597341922" 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: comments on draft-shiba-ccamp-gmpls-lambda-labels-00.txt Date: Mon, 31 Oct 2005 10:00:16 -0600 Message-ID: <7CA873794E52904EAA980A074B076779B17C62@rchemx01.fnc.net.local> Thread-Topic: comments on draft-shiba-ccamp-gmpls-lambda-labels-00.txt Thread-Index: AcXbIzcAFoI5B5TzS9O/zBGY1cMJbwA6iz0AAIdyNZAAAR14UAAAnn6wAABj8oA= From: "Shiba, Sidney" To: "Drake, John E" , Cc: "Adrian Farrel" , , Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: d2bb8c7db26f2d12109e0cd8e454db52 Content-Transfer-Encoding: quoted-printable John, Most of vendor support a standardized wavelength grid (e.g., ITU-T DWDM wavelength grid given in nominal value). If a wavelength chosen for a lightpath setup is not available in an optical switch, it rejects the operation for resource not being available. Regards, Sidney > -----Original Message----- > From: Drake, John E [mailto:John.E.Drake2@boeing.com] > Sent: Monday, October 31, 2005 9:51 AM > To: Drake, John E; Shiba, Sidney; dpapadimitriou@psg.com > Cc: Adrian Farrel; richard.rabbat@us.fujitsu.com; ccamp@ops.ietf.org > Subject: RE: comments on draft-shiba-ccamp-gmpls-lambda-labels-00.txt >=20 >=20 > Sidney, >=20 > There's another issue as well. Having absolute end-end global > wavelengths is probably insufficient to ensure that an end-end LSP can > be established successfully, as having a common wavelength=20 > does not mean > that equipment from different vendors will interoperate=20 > correctly in the > data-plane. >=20 > Thanks, >=20 > John >=20 > > -----Original Message----- > > From: Drake, John E > > Sent: Monday, October 31, 2005 7:36 AM > > To: Shiba, Sidney; dpapadimitriou@psg.com > > Cc: Adrian Farrel; richard.rabbat@us.fujitsu.com; ccamp@ops.ietf.org > > Subject: RE: comments on=20 > draft-shiba-ccamp-gmpls-lambda-labels-00.txt > >=20 > > Sidney, > >=20 > > But there's nothing in your picture that requires an=20 > absolute end-end > > global wavelength. The existing GMPLS solution with relative > > wavelengths of local significance should work just fine. =20 > As I said in > > my previous note, your method precludes combining two or=20 > more parallel > > WDM links into a single TE link. > >=20 > > Thanks, > >=20 > > John > >=20 > > > -----Original Message----- > > > From: Shiba, Sidney [mailto:sidney.shiba@us.fujitsu.com] > > > Sent: Monday, October 31, 2005 7:25 AM > > > To: Drake, John E; dpapadimitriou@psg.com > > > Cc: Adrian Farrel; richard.rabbat@us.fujitsu.com;=20 > ccamp@ops.ietf.org > > > Subject: RE: comments on > draft-shiba-ccamp-gmpls-lambda-labels-00.txt > > > > > > Hi John, > > > > > > Optical switches based on Wavelength Selective Switch (WSS) > technology > > > requires the wavelength information for switching. This technology > is > > NOT > > > wavelength agnostic. > > > > > > | | > > > | wdm | wdm > > > |2 |2 > > > --------- --------- > > > wdm 1| optical |3 wdm 1| optical |3 wdm > > > --------| switch |------------| switch |--------- > > > | (WSS) | | (WSS) | > > > --------- --------- > > > |4 |4 > > > | wdm | wdm > > > | | > > > > > > Note that the figure above shows an example of two=20 > optical switches > > > interconnect > > > by a single WDM fiber. In this example, each optical switch can be > > connect > > > to 4 > > > other optical switches. > > > > > > As you can see, the optical ports information do not=20 > provide enough > > > information > > > for wavelength switching. > > > > > > Hope that clarifies the application requirement. > > > > > > Thanks, > > > > > > Sidney > > > > > > > -----Original Message----- > > > > From: Drake, John E [mailto:John.E.Drake2@boeing.com] > > > > Sent: Friday, October 28, 2005 5:33 PM > > > > To: dpapadimitriou@psg.com; Shiba, Sidney > > > > Cc: Adrian Farrel; richard.rabbat@us.fujitsu.com; > ccamp@ops.ietf.org > > > > Subject: RE: comments on > > draft-shiba-ccamp-gmpls-lambda-labels-00.txt > > > > > > > > > > > > Hi, > > > > > > > > Below is the text of an e-mail is sent to the Ethernet/GMPLS > mailing > > > > list. > > > > > > > > Upon reflection I am not sure using a real wavelength=20 > value makes > > much > > > > sense. Between a pair of adjacent nodes, there may be > > > > multiple pairs of > > > > switch ports in the same TE link that support a given frequency. > If > > a > > > > real wavelength value is used, how do the two nodes agree on > > > > which pair > > > > of switch ports to use? > > > > > > > > Furthermore, the amount of configuration is the same - you > > > > still need to > > > > configure the wavelength of each switch port. > > > > > > > > Thanks, > > > > > > > > John > > > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > =3D=3D=3D=3D > > > > Adrian, > > > > > > > > In the transparent photonic lambda switch case, the labels also > have > > > > only local significance. When an LSP is established, the input > > ports, > > > > as identified with local labels, are cross-connected to=20 > the output > > > > ports, as identified with local labels. > > > > > > > > There is just extra configuration to identify, using strictly > local > > > > identifiers, the wavelength associated with the all of the > switch's > > > > ports, and an additional CAC requirement that the wavelengths of > the > > > > input and output ports are the same. > > > > > > > > Thanks, > > > > > > > > John > > > > > > > > > > > > > -----Original Message----- > > > > > From: dimitri papadimitriou [mailto:dpapadimitriou@psg.com] > > > > > Sent: Thursday, October 27, 2005 10:03 AM > > > > > To: Shiba, Sidney > > > > > Cc: dimitri.papadimitriou@alcatel.be; Adrian Farrel; > > > > > richard.rabbat@us.fujitsu.com; ccamp@ops.ietf.org > > > > > Subject: Re: comments on > > > > draft-shiba-ccamp-gmpls-lambda-labels-00.txt > > > > > > > > > > shiba - see inline for some additional hints: > > > > > > > > > > >>Shiba, Sidney wrote: > > > > > >> > > > > > >>>Adrian, Dimitri, > > > > > >>> > > > > > >>>Thanks for reviewing these I-D. > > > > > >>> > > > > > >>>Wavelength continuity constraint does require the use of > > > > semanticful > > > > > >>>label whether it is spectral or index. > > > > > >> > > > > > >>=3D> see my reply to adrian on this specific point > > > > > >> > > > > > >>>I agree with Dimitri that the > > > > > >>>wavelength indexing requires document updating each time a > new > > > > > >>>spectrum is introduced. > > > > > >> > > > > > >>=3D> indeed and in addition it requires updating the already > > > > > >>signaled path > > > > > >> > > > > > >>>The use of spectral label provides self maintainance, i.e., > > > > > >>>no need to update any document and the use of the nominal > value > > > > > >>>provides a common semantic ground. > > > > > >> > > > > > >>=3D> what do you mean by self-maintenance - would you=20 > provide a > > > > > >>bit more detail > > > > > > > > > > > > [Sidney]What I've meant here was that it was not=20 > necessary to > > > > > > update any document when new wavelengths are inventoried. In > the > > > > > > case of indexing approach, it would require the > > > > wavelength indexing > > > > > > document to be updated with implementation impacts. > > > > > > > > > > > > In the case, the nominal value is used, there is no need for > > > > > > documentation update. > > > > > > > > > > ok - what you mean here is that you are going to make=20 > use of the > > > > already > > > > > defined C-Type 2 - what about the specific encoding of the > > > > value space > > > > ? > > > > > > > > > > >>=3D> now i have a more specific question before being = light-up > > > > > >>how do you know the frequency that you can support ? > > > > > > > > > > > > [Sidney] Some new technologies integrate optical switch and > > > > mux/demux > > > > > > capabilities, which allows the equipment to know=20 > the spectrum > it > > > > > supports. > > > > > > > > > > indeed - but the question is what does happen if the > > > > "detected" values > > > > > (during initialization) do not match the nominal values ? you > > don't > > > > > initialize then ? > > > > > > > > > > >>if these differ from the nominal values how are you going to > > deal > > > > with > > > > > these > > > > > >>discrepancies ? > > > > > > > > > > > > [Sidney] These new technologies uses the nominal value as > > > > reference. > > > > We > > > > > can say > > > > > > that a lightpath wavelength is identified by its nominal > value. > > If > > > > the > > > > > equipment > > > > > > is drifting from this nominal value, it is considered as > > > > a failure. > > > > > > > > > > ok - but if the deviation is such you have overlap - how the > > control > > > > > plane is going to be able to detect such failure ? > > > > > > > > > > >>this said i am not necessarily sure that having to > > > > maintain the data > > > > > plane > > > > > >>specifics as part of the control plane is really helping > > > > > >>operations (is this method not just duplicating=20 > complexity ?) > > > > > > > > > > > > [Sidney] The wavelength is WDM specific as much as the SUKLM > > label > > > > > encoding > > > > > > is for SONET. The wavelegth/frequency nominal value=20 > is used to > > > > identify > > > > > the > > > > > > facilities to cross-connect. > > > > > > > > > > there is an equivalence but there is also a major difference, > the > > > > > structure is invariant independently of the state of the > > > > network, with > > > > > spectral value space you may have labels that become=20 > unavailable > > due > > > > to > > > > > non-local usage of wavelength in the network > > > > > > > > > > hence, there is also no real coupling to the data plane more > than > > > > > knowing the type of interface and some generic capabilities > > > > > > > > > > >>>I'm not sure if the draft needs to be updated before the > > > > > >>>face-to-face meeting or after all comments are collected. > > Please > > > > > advise. > > > > > >> > > > > > >>=3D> suggest to keep discussion on - document update can be > > > > > >>performed at a later stage > > > > > > > > > > thanks, > > > > > - dimitri. > > > > > > > > > > >>>>-----Original Message----- > > > > > >>>>From: owner-ccamp@ops.ietf.org > > > > [mailto:owner-ccamp@ops.ietf.org]On > > > > > >>>>Behalf Of Adrian Farrel > > > > > >>>>Sent: Thursday, October 27, 2005 4:45 AM > > > > > >>>>To: dpapadimitriou@psg.com; > dimitri.papadimitriou@alcatel.be; > > > > > >>>>ccamp@ops.ietf.org > > > > > >>>>Subject: Re: comments on > > > > > >> > > > > > >>draft-shiba-ccamp-gmpls-lambda-labels-00.txt > > > > > >> > > > > > >>>> > > > > > >>>>Dimitri, > > > > > >>>> > > > > > >>>>Thanks for your work reviewing these recent I-Ds. It is > > > > > >>>>really valuable > > > > > >>>>and I'd welcome other people doing similar reviews. > > > > > >>>> > > > > > >>>> > > > > > >>>> > > > > > >>>>>there is a specific point to be clarified in=20 > this document: > > > > > >>>>> > > > > > >>>>>semanticless vs semanticful label (even here there is a > > > > distinction > > > > > >>>>>between spectral vs indexes i.e. using the wavelength > index) > > > > > >>>>> > > > > > >>>>>domain-wide vs link local significant label > > > > > >>>> > > > > > >>>>Without being too picky, I think all labels are=20 > semanticful > > > > > >>>>otherwise, we > > > > > >>>>would not know what resource they refered to. > > > > > >>>> > > > > > >>>>So the point reduces to whether the scope of the semantics > > > > > >>>>are link-local > > > > > >>>>or wider. > > > > > >>>> > > > > > >>>> > > > > > >>>> > > > > > >>>>>so, the comparison from this perspective with=20 > TDM labels is > > > > > >>>> > > > > > >>>>difficult to > > > > > >>>> > > > > > >>>> > > > > > >>>>>parse, the latter is semanticful but link local > > > > > >>>>> > > > > > >>>>>now, i don't specifically see what has changed the late > 90's, > > > > early > > > > > >>>>>y2k's, to have a change in the wavelength label=20 > definition; > > > > > >>>> > > > > > >>>>This is the question I would like to get to the bottom of. > In > > > > > >>>>other words: > > > > > >>>>do we need this function? > > > > > >>>> > > > > > >>>>It seems to me that the question being asked is this: > > > > > >>>> > > > > > >>>> If I want to compute a path that has some form of > wavelength > > > > > >>>> constraints, what information do I need access to? > > > > > >>>> > > > > > >>>>Another question might be: > > > > > >>>> > > > > > >>>> If I want to signal a path with wavelength constraints > what > > > > > >>>> information do I need to include in the=20 > signaling message? > > > > > >>>> > > > > > >>>> > > > > > >>>>I'd suggest that when we started on GMPLS, we were > > > > > >> > > > > > >>enthusiastic about > > > > > >> > > > > > >>>>transparent optical networks, but we were not properly > > > > > >>>>focusing wavelength > > > > > >>>>constraints because lambda-switching PXCs didn't take off. > > > > > >>>>Therefore we > > > > > >>>>didn't examine the requirements for wavelength constraints > in > > > > > >>>>routing and > > > > > >>>>signaling. The authors of this I-D are claiming=20 > new hardware > > > > > >>>>requirements > > > > > >>>>for the same function. > > > > > >>>> > > > > > >>>> > > > > > >>>> > > > > > >>>>>there are > > > > > >>>>>several solution possible > > > > > >>>>> > > > > > >>>>>- absolute values: the freq. of the wavelength: difficult > to > > > > adopt > > > > > >>>>>because referenced values are nominal and knowing all > > > > interactions > > > > > >>>>>between wavelengths this knowledge is at the end=20 > of little > > > > > >> > > > > > >>practical > > > > > >> > > > > > >>>>>usage; (introduces implicit ordering) > > > > > >>>>> > > > > > >>>>>- indexed values: the # of the wavelength: it does not > > > > > >> > > > > > >>provide for a > > > > > >> > > > > > >>>>>future proof label space for inst. in case new=20 > frequencies > > > > > >>>> > > > > > >>>>are inserted > > > > > >>>> > > > > > >>>> > > > > > >>>>>in the grid (introduces explicit ordering) > > > > > >>>>> > > > > > >>>>>- diff. values e.g. freq spacing starting from a=20 > reference > > > > > >>>> > > > > > >>>>value: pauses > > > > > >>>> > > > > > >>>> > > > > > >>>>>the question of the reference value and does suffer from > the > > > > former > > > > > >>>>>issue (introduces implicit ordering) > > > > > >>>>> > > > > > >>>>>- the solution available today - cumbersome in some > > > > control plane > > > > > >>>>>operations (e.g. label set translation) and not easy to > > > > > >>>> > > > > > >>>>troubleshoot but > > > > > >>>> > > > > > >>>> > > > > > >>>>>independent of any physical consideration=20 > (spectral), scale > > to > > > > any > > > > > >>>>>number of wavelength per fiber, does not introduce any > > > > > >> > > > > > >>ordering, the > > > > > >> > > > > > >>>>>most flexible (since allowing each system to maintain its > > > > specific > > > > > >>>>>control operations) and the less constraining since > > maintaining > > > > the > > > > > >>>>>control plane operations independent of any data plane > > > > specifics > > > > > >>>>> > > > > > >>>>> > > > > > >>>> > > > > > > >>>> > > > > >>> > > > > > >>>ambda-labels > > > > > >>>-00.txt> > > > > > >>> > > > > > >>>. > > > > > >>> > > > > > >> > > > > > > > > > > > > . > > > > > > > > > > >=20 From owner-ccamp@ops.ietf.org Mon Oct 31 11:18:26 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWcMc-0003e1-Jj for ccamp-archive@megatron.ietf.org; Mon, 31 Oct 2005 11:18:26 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18099 for ; Mon, 31 Oct 2005 11:18:06 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EWcak-0004oh-FA for ccamp-archive@ietf.org; Mon, 31 Oct 2005 11:33:07 -0500 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EWcH3-0009JH-4S for ccamp-data@psg.com; Mon, 31 Oct 2005 16:12:41 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [12.47.115.93] (helo=mailsrv01.vasw) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1EWcH0-0009Ip-TR; Mon, 31 Oct 2005 16:12:39 +0000 Received: from NETPTORAB (net-torab.vasw [192.168.254.48]) by mailsrv01.vasw (8.13.1/8.13.1) with SMTP id j9VG96kh030600; Mon, 31 Oct 2005 11:09:06 -0500 From: "Payam Torab" To: "'Drake, John E'" , "'Shiba, Sidney'" , Cc: "'Adrian Farrel'" , , Subject: RE: comments on draft-shiba-ccamp-gmpls-lambda-labels-00.txt Date: Mon, 31 Oct 2005 11:11:46 -0500 Message-ID: <00f201c5de35$cb12b140$30fea8c0@NETPTORAB> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_00F3_01C5DE0B.E23CA940" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.6604 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 In-Reply-To: <626FC7C6A97381468FB872072AB5DDC836971A@XCH-SW-42.sw.nos.boeing.com> X-MS-TNEF-Correlator: 00000000DF91DC056F78C244BF1B5659AD723CE664652400 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 9724479da43a8325ad975c1a9b841870 This is a multi-part message in MIME format. ------=_NextPart_000_00F3_01C5DE0B.E23CA940 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit John- Obviously the benefits or harms of giving a global meaning to a lambda label requires study, but your particular example is not a good one: If one really wants to have a preference for a specific wavelength channel among multiple parallel channels of the same wavelength, bundling should not be exercised in the first place. Thanks, Payam -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On Behalf Of Drake, John E Sent: Monday, October 31, 2005 10:36 AM To: Shiba, Sidney; dpapadimitriou@psg.com Cc: Adrian Farrel; richard.rabbat@us.fujitsu.com; ccamp@ops.ietf.org Subject: RE: comments on draft-shiba-ccamp-gmpls-lambda-labels-00.txt Sidney, But there's nothing in your picture that requires an absolute end-end global wavelength. The existing GMPLS solution with relative wavelengths of local significance should work just fine. As I said in my previous note, your method precludes combining two or more parallel WDM links into a single TE link. Thanks, John > -----Original Message----- > From: Shiba, Sidney [mailto:sidney.shiba@us.fujitsu.com] > Sent: Monday, October 31, 2005 7:25 AM > To: Drake, John E; dpapadimitriou@psg.com > Cc: Adrian Farrel; richard.rabbat@us.fujitsu.com; ccamp@ops.ietf.org > Subject: RE: comments on draft-shiba-ccamp-gmpls-lambda-labels-00.txt > > Hi John, > > Optical switches based on Wavelength Selective Switch (WSS) technology > requires the wavelength information for switching. This technology is NOT > wavelength agnostic. > > | | > | wdm | wdm > |2 |2 > --------- --------- > wdm 1| optical |3 wdm 1| optical |3 wdm > --------| switch |------------| switch |--------- > | (WSS) | | (WSS) | > --------- --------- > |4 |4 > | wdm | wdm > | | > > Note that the figure above shows an example of two optical switches > interconnect > by a single WDM fiber. In this example, each optical switch can be connect > to 4 > other optical switches. > > As you can see, the optical ports information do not provide enough > information > for wavelength switching. > > Hope that clarifies the application requirement. > > Thanks, > > Sidney > > > -----Original Message----- > > From: Drake, John E [mailto:John.E.Drake2@boeing.com] > > Sent: Friday, October 28, 2005 5:33 PM > > To: dpapadimitriou@psg.com; Shiba, Sidney > > Cc: Adrian Farrel; richard.rabbat@us.fujitsu.com; ccamp@ops.ietf.org > > Subject: RE: comments on draft-shiba-ccamp-gmpls-lambda-labels-00.txt > > > > > > Hi, > > > > Below is the text of an e-mail is sent to the Ethernet/GMPLS mailing > > list. > > > > Upon reflection I am not sure using a real wavelength value makes much > > sense. Between a pair of adjacent nodes, there may be > > multiple pairs of > > switch ports in the same TE link that support a given frequency. If a > > real wavelength value is used, how do the two nodes agree on > > which pair > > of switch ports to use? > > > > Furthermore, the amount of configuration is the same - you > > still need to > > configure the wavelength of each switch port. > > > > Thanks, > > > > John > > ============================================================== > > ========== > > ==== > > Adrian, > > > > In the transparent photonic lambda switch case, the labels also have > > only local significance. When an LSP is established, the input ports, > > as identified with local labels, are cross-connected to the output > > ports, as identified with local labels. > > > > There is just extra configuration to identify, using strictly local > > identifiers, the wavelength associated with the all of the switch's > > ports, and an additional CAC requirement that the wavelengths of the > > input and output ports are the same. > > > > Thanks, > > > > John > > > > > > > -----Original Message----- > > > From: dimitri papadimitriou [mailto:dpapadimitriou@psg.com] > > > Sent: Thursday, October 27, 2005 10:03 AM > > > To: Shiba, Sidney > > > Cc: dimitri.papadimitriou@alcatel.be; Adrian Farrel; > > > richard.rabbat@us.fujitsu.com; ccamp@ops.ietf.org > > > Subject: Re: comments on > > draft-shiba-ccamp-gmpls-lambda-labels-00.txt > > > > > > shiba - see inline for some additional hints: > > > > > > >>Shiba, Sidney wrote: > > > >> > > > >>>Adrian, Dimitri, > > > >>> > > > >>>Thanks for reviewing these I-D. > > > >>> > > > >>>Wavelength continuity constraint does require the use of > > semanticful > > > >>>label whether it is spectral or index. > > > >> > > > >>=> see my reply to adrian on this specific point > > > >> > > > >>>I agree with Dimitri that the > > > >>>wavelength indexing requires document updating each time a new > > > >>>spectrum is introduced. > > > >> > > > >>=> indeed and in addition it requires updating the already > > > >>signaled path > > > >> > > > >>>The use of spectral label provides self maintainance, i.e., > > > >>>no need to update any document and the use of the nominal value > > > >>>provides a common semantic ground. > > > >> > > > >>=> what do you mean by self-maintenance - would you provide a > > > >>bit more detail > > > > > > > > [Sidney]What I've meant here was that it was not necessary to > > > > update any document when new wavelengths are inventoried. In the > > > > case of indexing approach, it would require the > > wavelength indexing > > > > document to be updated with implementation impacts. > > > > > > > > In the case, the nominal value is used, there is no need for > > > > documentation update. > > > > > > ok - what you mean here is that you are going to make use of the > > already > > > defined C-Type 2 - what about the specific encoding of the > > value space > > ? > > > > > > >>=> now i have a more specific question before being light-up > > > >>how do you know the frequency that you can support ? > > > > > > > > [Sidney] Some new technologies integrate optical switch and > > mux/demux > > > > capabilities, which allows the equipment to know the spectrum it > > > supports. > > > > > > indeed - but the question is what does happen if the > > "detected" values > > > (during initialization) do not match the nominal values ? you don't > > > initialize then ? > > > > > > >>if these differ from the nominal values how are you going to deal > > with > > > these > > > >>discrepancies ? > > > > > > > > [Sidney] These new technologies uses the nominal value as > > reference. > > We > > > can say > > > > that a lightpath wavelength is identified by its nominal value. If > > the > > > equipment > > > > is drifting from this nominal value, it is considered as > > a failure. > > > > > > ok - but if the deviation is such you have overlap - how the control > > > plane is going to be able to detect such failure ? > > > > > > >>this said i am not necessarily sure that having to > > maintain the data > > > plane > > > >>specifics as part of the control plane is really helping > > > >>operations (is this method not just duplicating complexity ?) > > > > > > > > [Sidney] The wavelength is WDM specific as much as the SUKLM label > > > encoding > > > > is for SONET. The wavelegth/frequency nominal value is used to > > identify > > > the > > > > facilities to cross-connect. > > > > > > there is an equivalence but there is also a major difference, the > > > structure is invariant independently of the state of the > > network, with > > > spectral value space you may have labels that become unavailable due > > to > > > non-local usage of wavelength in the network > > > > > > hence, there is also no real coupling to the data plane more than > > > knowing the type of interface and some generic capabilities > > > > > > >>>I'm not sure if the draft needs to be updated before the > > > >>>face-to-face meeting or after all comments are collected. Please > > > advise. > > > >> > > > >>=> suggest to keep discussion on - document update can be > > > >>performed at a later stage > > > > > > thanks, > > > - dimitri. > > > > > > >>>>-----Original Message----- > > > >>>>From: owner-ccamp@ops.ietf.org > > [mailto:owner-ccamp@ops.ietf.org]On > > > >>>>Behalf Of Adrian Farrel > > > >>>>Sent: Thursday, October 27, 2005 4:45 AM > > > >>>>To: dpapadimitriou@psg.com; dimitri.papadimitriou@alcatel.be; > > > >>>>ccamp@ops.ietf.org > > > >>>>Subject: Re: comments on > > > >> > > > >>draft-shiba-ccamp-gmpls-lambda-labels-00.txt > > > >> > > > >>>> > > > >>>>Dimitri, > > > >>>> > > > >>>>Thanks for your work reviewing these recent I-Ds. It is > > > >>>>really valuable > > > >>>>and I'd welcome other people doing similar reviews. > > > >>>> > > > >>>> > > > >>>> > > > >>>>>there is a specific point to be clarified in this document: > > > >>>>> > > > >>>>>semanticless vs semanticful label (even here there is a > > distinction > > > >>>>>between spectral vs indexes i.e. using the wavelength index) > > > >>>>> > > > >>>>>domain-wide vs link local significant label > > > >>>> > > > >>>>Without being too picky, I think all labels are semanticful > > > >>>>otherwise, we > > > >>>>would not know what resource they refered to. > > > >>>> > > > >>>>So the point reduces to whether the scope of the semantics > > > >>>>are link-local > > > >>>>or wider. > > > >>>> > > > >>>> > > > >>>> > > > >>>>>so, the comparison from this perspective with TDM labels is > > > >>>> > > > >>>>difficult to > > > >>>> > > > >>>> > > > >>>>>parse, the latter is semanticful but link local > > > >>>>> > > > >>>>>now, i don't specifically see what has changed the late 90's, > > early > > > >>>>>y2k's, to have a change in the wavelength label definition; > > > >>>> > > > >>>>This is the question I would like to get to the bottom of. In > > > >>>>other words: > > > >>>>do we need this function? > > > >>>> > > > >>>>It seems to me that the question being asked is this: > > > >>>> > > > >>>> If I want to compute a path that has some form of wavelength > > > >>>> constraints, what information do I need access to? > > > >>>> > > > >>>>Another question might be: > > > >>>> > > > >>>> If I want to signal a path with wavelength constraints what > > > >>>> information do I need to include in the signaling message? > > > >>>> > > > >>>> > > > >>>>I'd suggest that when we started on GMPLS, we were > > > >> > > > >>enthusiastic about > > > >> > > > >>>>transparent optical networks, but we were not properly > > > >>>>focusing wavelength > > > >>>>constraints because lambda-switching PXCs didn't take off. > > > >>>>Therefore we > > > >>>>didn't examine the requirements for wavelength constraints in > > > >>>>routing and > > > >>>>signaling. The authors of this I-D are claiming new hardware > > > >>>>requirements > > > >>>>for the same function. > > > >>>> > > > >>>> > > > >>>> > > > >>>>>there are > > > >>>>>several solution possible > > > >>>>> > > > >>>>>- absolute values: the freq. of the wavelength: difficult to > > adopt > > > >>>>>because referenced values are nominal and knowing all > > interactions > > > >>>>>between wavelengths this knowledge is at the end of little > > > >> > > > >>practical > > > >> > > > >>>>>usage; (introduces implicit ordering) > > > >>>>> > > > >>>>>- indexed values: the # of the wavelength: it does not > > > >> > > > >>provide for a > > > >> > > > >>>>>future proof label space for inst. in case new frequencies > > > >>>> > > > >>>>are inserted > > > >>>> > > > >>>> > > > >>>>>in the grid (introduces explicit ordering) > > > >>>>> > > > >>>>>- diff. values e.g. freq spacing starting from a reference > > > >>>> > > > >>>>value: pauses > > > >>>> > > > >>>> > > > >>>>>the question of the reference value and does suffer from the > > former > > > >>>>>issue (introduces implicit ordering) > > > >>>>> > > > >>>>>- the solution available today - cumbersome in some > > control plane > > > >>>>>operations (e.g. label set translation) and not easy to > > > >>>> > > > >>>>troubleshoot but > > > >>>> > > > >>>> > > > >>>>>independent of any physical consideration (spectral), scale to > > any > > > >>>>>number of wavelength per fiber, does not introduce any > > > >> > > > >>ordering, the > > > >> > > > >>>>>most flexible (since allowing each system to maintain its > > specific > > > >>>>>control operations) and the less constraining since maintaining > > the > > > >>>>>control plane operations independent of any data plane > > specifics > > > >>>>> > > > >>>>> > > > >>>> > > > >>>> > > >>> > > > >>>ambda-labels > > > >>>-00.txt> > > > >>> > > > >>>. > > > >>> > > > >> > > > > > > > > . > > > > > > ------=_NextPart_000_00F3_01C5DE0B.E23CA940 Content-Type: application/ms-tnef; name="winmail.dat" Content-Disposition: attachment; filename="winmail.dat" Content-Transfer-Encoding: base64 eJ8+Ii8QAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEGgAMADgAAANUHCgAfAAsACwAAAAEAHAEB A5AGABQcAAAlAAAACwACAAEAAAALACMAAAAAAAMAJgAAAAAACwApAAAAAAADAC4AAAAAAAMANgAA AAAAHgBwAAEAAAA5AAAAY29tbWVudHMgb24gZHJhZnQtc2hpYmEtY2NhbXAtZ21wbHMtbGFtYmRh LWxhYmVscy0wMC50eHQAAAAAAgFxAAEAAAAWAAAAAcXeNcpyWStaVYm1SxaXOoXTA/t1xQAAAgEd DAEAAAAXAAAAU01UUDpQVE9SQUJATE9QU1lTLkNPTQAACwABDgAAAABAAAYOAEL3rjXexQECAQoO AQAAABgAAAAAAAAA35HcBW94wkS/G1ZZrXI85sKAAAADABQOAQAAAAsAHw4BAAAAAgEJEAEAAAC8 FwAAuBcAAJM6AABMWkZ1tGSTmAMACgByY3BnMTI14jIDQ3RleAVBAQMB9/8KgAKkA+QHEwKAD/MA UARWPwhVB7IRJQ5RAwECAGNo4QrAc2V0MgYABsMRJfYzBEYTtzASLBEzCO8J97Y7GB8OMDURIgxg YwBQMwsJAWQzNhZQC6YgSnBvaG4tCqIKhAqATwhidmkIYHNseSBgdGhlIGIJ8AEQaS50BCAFsRPh bR9RZiCEZ2keIG5nIGEgIHUXsGIHQCAHgABwIGJ07m8gkQtgBtBkIeIe4AMgMRggcXVpGCAEIHN0 UHVkeSwe0HUFQHnVCGEgCrF0DeB1C2AFwB8OwCIQC1AewAQAIG5vOwVAIKFvBHAfYB8AOiC+SSAQ JnEiwQdAHnF3AHC3H0EhsRPgdh7AIKBwGCD2ZgSQCfBjHsACEAXAIKD8c3AFkAaQDeAnkShQJWDr IHAeoCAT0W4fAAMgIhD7AiAggG0kwCSQJVIKsSdR7yKhKvUf4x6icyIQHsAqSJEjsm5kbCBic2gI YP5sJlAlwh7gJQEEkCngFBD/JlALgB6THyAUAAVAC1EpIIouHUpUKwFrcywdRFhQYXkiEB1KLTTi T2sFECAwbiEBTQeQLfBnNmU04x1ERgNhJqBvdyEfAHItY2MlMUBv2HBzLgiQADAuBbAggG5bAMAD ECGwOjdPOFVdpk8LkB1TQmUT4GwgEMpPIBBELIBrZSOwHPK8IEUdRAZgAjAmoE0CIHMiQCOhT2Mh sB7gBcAzBjEjsAHQMDUgMTB2OhwgEMBNMqU5MAYAaEZpIPAjsFNpZB8Aedg7IGQKsAqwZAdwHzDL BRAIYEA4EGcuBaA0FWRDYyagQWQHIQOgRj8KwBggAnAiwA3gE+FkLiUsgGIg8HRAHlAuZnR1ah8x dUJSQRA5v2cxPNV1YmoFkD1hUkX/JqBCYQeAJ8ICIEEgLIABgE4tL5BAYTmkLWclQXO+LSIESpEi kUqAPuAuDND+dB1KPNVAwzNlOwUj4R6h/RggJyWjQFAgcTERJBQN4H8jcBggHpFE4CLIA5EBoHPv BvAj4DBRLyAtUhEdRCDF8SpILiAgMwAwUgQAJJDhIHFHTVBMBfBRox4wvwOgA/AqwUPRROAgQGUd RL8qSB/jF7BGIAMgAJBnAwAvKgEAcCkhL5V3BbBrIL5qHlAFQB8gHwBT8UEEIN5JLeFAwDEBHURt HoAoof8eIyWyPEEkEweAHqAmQSih3mMKQAEABCBCYWILgCFzP1mgH2IEYFBBLGYdRFdE/k0h8AuA M0AxASGzAJAgcPklYVRFYMMyPzNHHUQc8vkdSj4gNO81/WWANuRAS7c4xwCQQNIuSYNFDV1lJvM9 Pz5MNzoOMD93ZYBAAv88C0EfQitlgEL/RA9FH0Yvf2tHR69Iv0nPSt9lJmUmSO5pHOMzZXsoTwUw WMFYQb9V4RPQB5Eg8DDSd9FXKlg/BmAlYD4gVoEGAH3TICjwV1NTKR6QBZAdEBeh/Gd5ZSYi1x6i KkkLgClR/wDAVZMpUn3EIGFT8DMAJZHHgQglgR1ETk9UZSYqSXc2ACXAVJFjYoV7KIm9fI+JvopV iU+KVndkbYsf/42UjD+KVRRAkP+Qo49vVAC/ZaNlopFMk5eSao3DMYqw8zgAfWR8M5Ymlo+PO5OW /4qwfcSKkZOXmi+VP4pIgKR/iqyeKZ0Pk3+g/6BPilU0/5E/pKSjf41Ppy+mf4pfi2/dewpOXKFQ ZDFEZ1AyAaD2byhRL5F3UTMlFi2CXwL/fV1lJmExMJECIB8APiBlJn5iHoBhh2CSHyA+UVPwSf8x IiWRJRUjsCFAgHGwzCrg/wORHuAdRLKdIbGmZ08BEoH/sM6Iv1qxJBG3MxQQPEEeot2W1nAXwWES g8hkIcAlwp8ooK8AQMBR8ghgZ2ixyP+Dx2UmKVIqSYSoes84AFBV/13gCsAp8YKFb/ALUFjBVZP/ ItV3csOPMwt7KEC0w55ljz9mn8tCNuQ8CzjHHPIuRdIuPAMyQAbgZYUCawpPa6Y24EDAbGoyOD61 Nfs/QJdgUG4XboRv30JDb7D/QEvK6HG/cs9z33Tv0Rl2j/93lB1EeA95H3ovy1Dhb3ui/8j34nk7 YBewB+CFch6xDrP7IAGvoi044iWCFBACMCGizR6iRU5yHwB0L1T0OOK/IGHK6C9AI2DHh+J5Vb3g /cayZn+zd9Fa4CIQJbPagN9QQR5QIGQnMio6dgdAClD/6EE8MIZlK9AT0Mro5qEUEP9T8TtgXvAJ 4ShyC3C58eWx/GRqMgHmwSXAXhG9A1BB/wDAHoC3hstCK9kxkR/x75n/gES95i2oYhVQZNqAxiAX wf8gklaBhEEi0ikBadBUACbA/R1EYcro7U/uUyWRHlAJgP8jsK9RvvLlE18B8mOIIQnR+94Xy0J3 QFD2IvFhyuggAff16yGx/ME/6b9noQhwTnL/X2K9BCtxLxDlg7KRrnOEBP/k5S3zofC8Ue+ZJJAn YCWw/wngJlAhsMroBSZQUoLbIAH/tgP16emv1ILIrOJ5ZIjLQv49D68QvxHPEngPDxNfyuj/2CQN j8tRtPNQUSyA8FAsYf3msnAvoCGwIWAqICIFttd/8GC9BOCU+LAtUCgUADlu9x5xWA9acldUMPER 8RBVIPZQJYL+QHTZoOlhVDD88fuuMltQcCPgNIS94xao+LD/YRH+MPIwxXJZgVXyHRTglP+14Bix KuC/gMyA31CypAgz/70UIJAgh8tCIRQiDyMdC+//DPPy8uZxWfPlYV/QBR1hUd8nddJh7MQxsNkR dBzmyuj/J3cxoL0Eh4rMgB0g2FAlIv9V48XTB+GwUvbym/NOwCY/d1FQXZBRUmTVQFWSvbFD/EFD xsqt2FcdrjEuqSBy/zRzJdS91SQi9uYpPwz/Dg//PO/K6MtvzH8/xGfE1UVfoX/VKWj31P/Qvmum Y1ADgHOF0kw30zUxMDowl2C/bgjUdtZ/P6bX4kUVLkTc9zJAxmHY0C7S0G+w2Cw/at/ZH9ov2z9G WdzXZd1/yyT/3q/fv+DPP9I/alZjBrG80f/2oeiBrlGEcl5grsE1CITxTQGgOljPP8Q+Pmgsd9+/ gOVQXPpeYV28PhZFzhD/1VQhaWFTYL3IlIRT/pC/oD5lm/Ds8a4x8GD58C1EvzsoYz9hYn7pspEn sG6CUP50s5CykS3B8WDyMb8A/kH/giWuI/zB9RzHMDTAfWFRMP8umWFTGyP/gVKwudJRYOZj/8Sw 3RAYYDJhbtE0kK/QZm39Xbw98BLugbOQ/pCwELOQ/yyRRQDYQyxihWJvUh2yC5H/XLFwf2Dq6+H+ gzGzYiWt1z9gvYL7cDHs4oInvwBjdf82U/hQGeBpMe0AtgMnsFvC/QgBd2C9b1R7wOZiXLG/gP5k 72AlMHBvcX1wEiUxNIJ/9rE09m7iewd8JzIE+zFk/0tLfnEdgTJAJTEYoIgAgA+/Y8xrVm9IbhS/ deaCbADg/+Yh8jBqER3yteBMsPBwYp7vvzAIBnwUrsFus5B7lzSC/2s4riO/MEMAQMLuQ2C9iof/ K5LdsOuxbHb40L+ABLB/7/9xbv+Q+BG/AbxS90C3UrOQ/4sS5hKyUYvTWoH94PRAJUDvvFK/dvqJ XlJibvED4tTgv1Kw5jFdu127zvDW5F0eYPn4EUknrxGXMvig8uMwUH/FsvgRbvGfYr8yssFBEnL/ cxKcvI4/8jFucfEQfXE3K/8kIkCw+QEskMVgf9EX1Zy8/xqCAMJ6d8YRv4C2EYwhoAH/mPNquf75 ed9TG1Xhe6Yskf/S0KI1KAXVULARx0IFpbWg//IAAaBmbJy8F+UaiJCr/Ij/8tTmcY2GwgGr73vD BaSiRPtmaj9qb/fQmMHE8pb3Kob3xOO8UiQiZ3TxZbFzQO6if4/pIXmFD5txdKDnsCVAQ+gtVHnE sTK5JlCgOZH/9tR0ZvmR/iDs4jf+7kQYkf8eEMroAjhdnnIx7DDkwRvT//ixmzN0V/lxB7HrsdLQ tTHPW0DS0Ozi6IBnaFZA+FD3Xbz9JZbya8YyICL5R7qo/x3h+DfEapyfnaXRoFuyo9L/5VBQMOww 5KBAoP5BmCL+gH+iclJgbMEdQhokNIHzmnj+L/4w0+GmThigmvDogCewv/KS/5QyQeSwBhR7EnCt Bv/LV36YdSv4Ra/bP2qB9VqQ/mLAhcfn5nGWdf5BloD4YLfxAR2wOBwim4ElAyLuNPszaUAAKH+g QIDs8UCwNSHpMkBpegWjKf1S7DLmIDcaQrJ//lA/Btj9YG4n/3Ur4kc6g/EQxG9eB970ZgH5RRBm ZkhB+UBbsOQP3lL/y3EkIpbyu4bllftB/vkxwe8/amXTXbxFEHMkYHLgHfH/0ULN387vz/EqcWYB 0H/8wX8GFLK8J0D6muph+ZG3elf/eMvNE0ew8pyfo1pwyUOG0r+qqydbl4FRYbKsZmVJa8n/eK3X R/KcHyFOgVYwp/Lqpf+0g7LZqLMfIWmymcF3QDSh+zNpWnBmm7EJgdqfuJrcov/e9JtxkpCvFXQx f7AjIJby78aTmaAvwBsgcFqByqI4J/9pApJwbRuuoDTAs3O7h62B/x+BOoFzQOAECnQGxef/Xfj/ dASbsIKBkuB/AKBqm8CXkf8Q0p+jG+HtCtOji3UJZFDQ/5oLDgOFbcEFG3EbcO1xwDB/kDUM1Q34 vcEyUGmQIDBsenCrvj5SYC/ALDOksCj/uoMOYX0gMNDBsKBTKwN/oH+uoNJRfGNRsa6hp+BpgT8e KfHP8t/z4/wdV0RNH3RIJ0HT4NLi1uRTVUt+TEl1V/MAW8GVAa9k8lNwT05FVKXAI+gwwS//y+iy v7PCoTv9Bforph8GwO/xYNW0jfLxAG9BIFawyED9oKF0Bz/vOLRUl1F7EsMRv/fy3JY0FVgwc0EW YWpbcf/qNPfytANZe37RVDAQ0n8j/8MQTpJvAXAh3rH9EhRxkDUvyBDR48It9GB0qQBya//WEe69 b1fDGZbkR7DGhFf0/3hEWBBRsa2RXGDDEJvAD1Lv7WWRWqFMxjBuV3B7oNJx/1EAdyCJQ6q79bQ8 5DJ/4WT/o5E3hTXZjYEcElShICK7tP8XBg31mzOfoVVZ37DLUoR272mAv5Gnc1+gcjCxjoLcYP9b o0VA9GAUUHTA1VpHP3Z4/icThBSjCUZWEo2jMUOtiavIdXivPk8CLdfgLU8D/30gbpDB02UQVCHq cdaRkwO/AXGktEFg1qDgM2ZlUIaQf7Ih4QpzYJKQ79CUf3F+df5nRUAf4dfid1ALwPDSRRD/BWDI QchBv+B7nLHyyFJcvP8d4bUxfSCCQftDonEqMDtx50VAUS/6t25r1gDhCmCBp3fkMm92aD4taXJP FFB70TD2Qk0UEkVAaXNofkb16rE6C1B3UAEx4NJgr4COQNIgr9ClkHRmLrVA1avZWxZxbNfgOmx/ bYXMXU9Mq2kyQmWWgIsx2k+QQEECsZdRRrtAd0B7m9x20VMBcWxQiOAQ0HPVS3B5jCBP4EBvDyAq MAQyN4wgMjAwNSBoNDo0diBBJwVo2FS/bvACoPvQ+9BnRbsQQG1A9GcuQWE7Zzd4DNaQIGH1J6Au DyA7aH5vfxztdBGYdWJq4DFsUFJlbFCfWVfIQFy/8CpUEi1z1kDkYmFvZC1nrpEx0EIQXG1iS3CD UUCiLXYALtx0eAGcaG9ofkRnVIyO/4Z/KsBmEioDlvEqMD0CqVF/kpDQgE216gH3oPgQrSFJ/C1E r9CeUATiaH4cFcMS/0IoaNhPUlLArhEnoEFjoHD7tDEN8GXSIA9xyuCn8gVg/2dgQhAqMItUr92I 35R/lY+/EqE0BsdI2kAWkQ7lY5LR7/1UFtMCgqMFOpafm1/v0H8WcP0xmaAUEfZwCmGdhWb/qSBA dOGwCcDewbQzNajhCP/w0SCB4EAeMZxvDyA88NxA380xPnc5YqfB0VIuXJCzsX9Ntqq+IZycL2ky yuAWci1/rjAP0J4ySrEIwES0BWBnv+JQx6E54id/p99SkVfusZ/Acsjk1+APABywY2t1Af5JA4Kq MVkSQIW7Qp55aH7/kWM9YO/Q1hGPXz0AnwAfZP/LU8AD96BPkBDQTyH1wUAQ//ekLYKTj32vSxSY 5AWhJhD/MTTAAB8h6nHAs0FgTlTAs/+dhY1vsJKqEkSksY+K4QVy77cfwD/BT5yObzejIMMUQf9P kGHAA0gd4T5jNNAq4e6x/yqwJRFAhY1fwy/qMtZQnwD/XwLH/8rPlr3tcbLy9cJj0f9Y0gpSnokJ AqoYzL/Qv9gh/wSxYJHmEZhHHDPv0CrhFQQ/BRFMgUVALYHORE/AOTA+J2ZKSjALkPosaTJ5Mv5r 1nEO4kAzBqDVREZGJCn/nzQP0KsQ4lLFQHt/iQ8Dov8ek0/AK9GhocVBr2C0VFDA319QDuJFQF8D 9cJiUxBLAP/q0DsAjQGiL5FkPQFUkJtP/2CgkNFUUwOEnvCh1PG83S/3UqEQIVRwbTFDT7H7E97b f65UJdBfUBMxHqTj32h+IP+MsDsQ36E54jFiIOEJENly//vTFPUKYU+iYxJFbOzPBSP/PqEWkdjh 1LMW0GMSCfTk4X+vYOVDMMAUAkOB5m9ofkH/UwGRgt8XZ2D7oVWR67/xr//t3KrCaiHvNcbTJCny ydSj//qP89/lNQ8AocEs4KmxFtX//HQgkk+wanP13wQf546Qsf9ep9TCuqFhwOURO3EaYC1xwcVB R01QTFOzEpDR/3MAhK8KaYyBdKD8cCXQz2H/D0GuEQo/aKvzAR5QQnGMgv8d0M9haiE81djhz9IJ xVLz/nAbQB3h139XIJrRpWPxD3d7+P5pQUFhLVFAcYODc8c9YdmwIJJQWEOaoSNx/9NxZEDgQTsA fVDdX5/yVcP/sz/J4RhDISCDcEZQoCOLQf80sXMAWYQqEv2v/rRGUI1//64R6qNPYGh+AvcqpBZw rfH/dMA69JgBjMFZ1EIQZ1EDYf9UYLUg1MDjoNqQCh6OUh04/xJfKiE7M4Nw8GHl9RkfKk//K1+W v6ACJf+dQ0XAPrJPkP8/EPijuZBf8Y8/LR9pQgyx/zBzqcE/AuuguUPFcB0gpTD/OwXamHfRyg9c BA+xMp8WRv+2dEjBkIA0VFnTSfAcgfyy/09hTXbUIWZoTrNPEPiiJ9/fozfamOtUtOOSAGTZ8kmB 3+mURfAJATWAUMF0MW5iDb89k9CPPh8WgGqReVAoTrH/xYC6FGdQSqGYgA+R46BQEX8DYKb/Re8z kaSEOnY0tCP/NW82cUiR9KCk0bSxRR9D2/5vi3CpsSjioNlPfxMTz+D/dLC5ccWAQjKfQw8xV9Eo 4v8CgAxwpTACgUTgjCElYjUS/98g5gCaAD4PvM+X0g8goADfCOFW/1nPLW0ChWd6gJCA/0d6pLBI X0lvSn82k6UwOpX/pSAi4TUSVHOSUwiyA1LFc//vMDnnWr//bTqTbFAPQBaB/1bvZ/8tX97qTPU5 5zqEO7P/TlMHUDbAzrHFdWUZ8IKgAP9p/5gAB1ACYEd/Xp9frzLd/7sjMIamACTwnzGSAbpwg6D/ tlBLcJrhmXAjoJEiAoHwMv//WP5RXbGqoIMgkGBlH7+Q/8YR9EMWIJ+QYoJUJeCyDwK7znHfYSk7 s7SyjoBztlD3yp90H12xdXaBgkCuwK4x/wz+fz+CT1yxpsC7kKaxD4LHTQCQYLZQcGh5/HCqgtf+ Ur/i9EQoo8YpxGC7YN/UIHnFN0uFYINfbndT8Mz/xgId0DFAoADEYE5WPUJdxL+JL4NNcobEY43f MsxtMRD1+TBmdpB4MUKG8QIB2XH/1DA8JNdA2bC7UIWw1iDFof/pEf6yqVFOEWfpmFaRT3kG/3ro fUTVw54C/ldjU5NS/1T/lSYDUf9YkD+X6XmDmImmk/+ErRcAGJB5fpaGZ++RP6PPBf9ePPkgdHA6 Ly9qd6dgLlbAdOHQVPBnpi89UxAxLWQV0GYWEO4vqMMXIK+QYhcQ9VAW0OhwLWdyAXO+QP9d/10H FtSwJP9dLTAwLnT8eHSl3v9dKj6Qb/q4/1suICo8/1f/VH22IB4AQhABAAAARQAAADw2MjZGQzdD NkE5NzM4MTQ2OEZCODcyMDcyQUI1RERDODM2OTcxQUBYQ0gtU1ctNDIuc3cubm9zLmJvZWluZy5j b20+AAAAAAMACVkBAAAACwAAgAggBgAAAAAAwAAAAAAAAEYAAAAAA4UAAAAAAAADAAKACCAGAAAA AADAAAAAAAAARgAAAAAQhQAAAAAAAAMAD4AIIAYAAAAAAMAAAAAAAABGAAAAAFKFAABzeQEAHgAQ gAggBgAAAAAAwAAAAAAAAEYAAAAAVIUAAAEAAAAEAAAAOS4wAAsAEYAIIAYAAAAAAMAAAAAAAABG AAAAAAaFAAAAAAAAAwASgAggBgAAAAAAwAAAAAAAAEYAAAAAAYUAAAAAAAALABuACCAGAAAAAADA AAAAAAAARgAAAAAOhQAAAAAAAAMAHIAIIAYAAAAAAMAAAAAAAABGAAAAABGFAAAAAAAAAwAegAgg BgAAAAAAwAAAAAAAAEYAAAAAGIUAAAAAAAACAfgPAQAAABAAAADfkdwFb3jCRL8bVlmtcjzmAgH6 DwEAAAAQAAAA35HcBW94wkS/G1ZZrXI85gIB+w8BAAAAlAAAAAAAAAA4obsQBeUQGqG7CAArKlbC AABtc3BzdC5kbGwAAAAAAE5JVEH5v7gBAKoAN9luAAAAQzpcRG9jdW1lbnRzIGFuZCBTZXR0aW5n c1xwdG9yYWJcTG9jYWwgU2V0dGluZ3NcQXBwbGljYXRpb24gRGF0YVxNaWNyb3NvZnRcT3V0bG9v a1xtYWlsYm94LnBzdAADAP4PBQAAAAMADTT9NwAAAgF/AAEAAAAxAAAAMDAwMDAwMDBERjkxREMw NTZGNzhDMjQ0QkYxQjU2NTlBRDcyM0NFNjY0NjUyNDAwAAAAAAMABhDo79l/AwAHEDsgAAADABAQ AAAAAAMAERAoAAAAHgAIEAEAAABlAAAASk9ITi1PQlZJT1VTTFlUSEVCRU5FRklUU09SSEFSTVNP RkdJVklOR0FHTE9CQUxNRUFOSU5HVE9BTEFNQkRBTEFCRUxSRVFVSVJFU1NUVURZLEJVVFlPVVJQ QVJUSUNVTEFSRQAAAADQww== ------=_NextPart_000_00F3_01C5DE0B.E23CA940-- From owner-ccamp@ops.ietf.org Mon Oct 31 11:31:11 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWcYx-0007iL-Cz for ccamp-archive@megatron.ietf.org; Mon, 31 Oct 2005 11:31:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18826 for ; Mon, 31 Oct 2005 11:30:51 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EWcn7-0005om-In for ccamp-archive@ietf.org; Mon, 31 Oct 2005 11:45:53 -0500 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EWcTw-000A35-NI for ccamp-data@psg.com; Mon, 31 Oct 2005 16:26:00 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [68.142.201.254] (helo=web30811.mail.mud.yahoo.com) by psg.com with smtp (Exim 4.52 (FreeBSD)) id 1EWcTv-000A2f-Ae for ccamp@ops.ietf.org; Mon, 31 Oct 2005 16:25:59 +0000 Received: (qmail 71820 invoked by uid 60001); 30 Oct 2005 15:25:58 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=k7LyDCxXCrVt+S0cG0U5+emGpqRpYH0KtV5BGT3u6edqhfuRUYA53r56V/d41CxM00Y4wNPwDiCcFs+qesCjimDrtCbPYZ1qOH4k6eSWuj6lVJWJbr0AXJZQeRKEudN6T5P0AovbpoGsHiuTBkCDx9G9b84vwvqlbKeIrLJDtpw= ; Message-ID: <20051030152558.71818.qmail@web30811.mail.mud.yahoo.com> Received: from [68.100.80.11] by web30811.mail.mud.yahoo.com via HTTP; Sun, 30 Oct 2005 07:25:58 PST Date: Sun, 30 Oct 2005 07:25:58 -0800 (PST) From: Igor Bryskin Subject: RE: Two Drafts for Resilience of Control Plane To: "Zafar Ali \(zali\)" , ibryskin@movaz.com Cc: drake@movaz.com, John E , dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be, Igor Bryskin , Kim Young Hwa , ccamp@ops.ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.6 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Content-Transfer-Encoding: 8bit Zafar, --- "Zafar Ali (zali)" wrote: > > > >> > > > >> > Igor, > > >> > > > >> > W.r.t. option C, please note that traffic > CANNOT be > > forwarded in a > > >> > "head-less mode" for a very long time . If > you control > > >> network melts > > >> > or a peering controller goes down, either > RSVP GR or > > refreshes will > > >> > take care of the clean-up of the affected > RSVP states. > > >> Similarly LMP > > >> > CC SM will go down (after states are cleared, > i.e., > > >> degraded-to-down), > > >> > eventually removing the TE links from > topology. > > >> > > > >> > > >> Sticking to the example I described: > > >> a) absence of RSVP refreshes does not affect > data plane in any way; > > >> b) use of LMP is not mandatory and, becides, I > don't see > > now it helps. > > >> True, the TE link could be withdrawn, however, > the LSP > > will still be > > >> operational > > > > > > Isn't the problem is at "B" only and control > plane at the > > other node > > > (or controller for other nodes) still working > fine? If yes, local > > > controllers will withdraw RSVP states; hence > correct the data plane. > > > > > > > Again, GMPLS controller cannot remove control > state and > > destroy data plane just because it does not get > refreshes > > from adjacent controllers. > > Then how states get ever destoryed, even in normal > case, e.g., if head > end sends a ptear and all controllers are up? > States are supposed to be destroyed on explicit signalling message (e.g. PathTear or PathErr with the state removal flag), but not because of the absence of refreshes. Igor > Thanks > > Regards... Zafar > > > __________________________________ Yahoo! FareChase: Search multiple travel sites in one click. http://farechase.yahoo.com From owner-ccamp@ops.ietf.org Mon Oct 31 11:48:23 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWcpb-0003jN-1t for ccamp-archive@megatron.ietf.org; Mon, 31 Oct 2005 11:48:23 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19712 for ; Mon, 31 Oct 2005 11:48:02 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EWd3j-0007Sa-6b for ccamp-archive@ietf.org; Mon, 31 Oct 2005 12:03:04 -0500 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EWckq-000B1R-IQ for ccamp-data@psg.com; Mon, 31 Oct 2005 16:43:28 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [130.76.64.48] (helo=slb-smtpout-01.boeing.com) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EWckp-000B1D-Qo; Mon, 31 Oct 2005 16:43:27 +0000 Received: from slb-av-01.boeing.com ([129.172.13.4]) by slb-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id IAA19537; Mon, 31 Oct 2005 08:43:20 -0800 (PST) Received: from XCH-SWBH-04.sw.nos.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id j9VGhKd23624; Mon, 31 Oct 2005 08:43:20 -0800 (PST) Received: from XCH-SW-42.sw.nos.boeing.com ([192.79.11.43]) by XCH-SWBH-04.sw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 31 Oct 2005 08:43:20 -0800 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: Two Drafts for Resilience of Control Plane Date: Mon, 31 Oct 2005 08:43:19 -0800 Message-ID: <626FC7C6A97381468FB872072AB5DDC836971D@XCH-SW-42.sw.nos.boeing.com> Thread-Topic: Two Drafts for Resilience of Control Plane Thread-Index: AcXeMlogEzfcQWXxTaabrq+w3EYCBAAAaCwg From: "Drake, John E" To: "Igor Bryskin" , , , Cc: , , , , X-OriginalArrivalTime: 31 Oct 2005 16:43:20.0198 (UTC) FILETIME=[3369FA60:01C5DE3A] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: quoted-printable . >=20 > No John, >=20 > This is not true, I gave you a very specific problem - provide mechanisms > to > manage LSPs with impaired control plane (when one or more controllers are > out of service). > You said that this is not a problem, because RSVP is a soft state protocol > and once there are no refreshes the control data plane states must be > destroyed and hence there is nothing to manage. > And I tried very hard to explain you why this is not acceptable and hence > must be addressed. [JD]=20 Actually, I didn't say that. What I said was that in your example, PathTear and PathError with state removed should work just fine. Due to 'CP degraded' notification, nodes C and D will know that B failed. In option a), local policy, configured via the NMS, at D will tell it whether to send a PathErr with state removed and if so, how long to wait. As stated in another e-mail, multiple CP failures are handled by configuration, via the NMS, at intermediate nodes that tell them under what circumstances and after what duration to send PathTear and /or PathErr with state removed, or whether simply to wait until the resources time-out and how long to wait before timing them out. In option b) A creates an MBB LSP on the path A, E, F, H, K, D. Subsequently, A sends a PathTear to B, and D sends a PathErr with state removed to C. The MBB LSP was created under policy control, via the NMS, at the ingress node, A. Here's your initial example: A----B------C-----D | | E-----F-----H-----K > I have a solution and am planning to write a draft. I'd like this work to > live in CCAMP. [JD]=20 You can't get pre-approval of an I-D. >=20 > Igor From owner-ccamp@ops.ietf.org Mon Oct 31 11:49:00 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWcqB-0003rR-Va for ccamp-archive@megatron.ietf.org; Mon, 31 Oct 2005 11:49:00 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19743 for ; Mon, 31 Oct 2005 11:48:39 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EWd4O-0007VD-EH for ccamp-archive@ietf.org; Mon, 31 Oct 2005 12:03:41 -0500 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EWckT-000B0L-Oc for ccamp-data@psg.com; Mon, 31 Oct 2005 16:43:05 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [130.76.96.56] (helo=stl-smtpout-01.boeing.com) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EWckR-000B02-Ha; Mon, 31 Oct 2005 16:43:03 +0000 Received: from stl-av-01.boeing.com ([192.76.190.6]) by stl-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id KAA02986; Mon, 31 Oct 2005 10:43:02 -0600 (CST) Received: from XCH-SWBH-04.sw.nos.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id j9VGh1Y20928; Mon, 31 Oct 2005 10:43:02 -0600 (CST) Received: from XCH-SW-42.sw.nos.boeing.com ([192.79.11.43]) by XCH-SWBH-04.sw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 31 Oct 2005 08:43:01 -0800 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: comments on draft-shiba-ccamp-gmpls-lambda-labels-00.txt Date: Mon, 31 Oct 2005 08:43:01 -0800 Message-ID: <626FC7C6A97381468FB872072AB5DDC836971C@XCH-SW-42.sw.nos.boeing.com> Thread-Topic: comments on draft-shiba-ccamp-gmpls-lambda-labels-00.txt Thread-Index: AcXbIzcAFoI5B5TzS9O/zBGY1cMJbwA6iz0AAIdyNZAAAR14UAAAqdxAAAGnFZA= From: "Drake, John E" To: "Shiba, Sidney" , Cc: "Adrian Farrel" , , X-OriginalArrivalTime: 31 Oct 2005 16:43:01.0387 (UTC) FILETIME=[2833A5B0:01C5DE3A] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 680445c3afe8c9e96925f2dfef141924 Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: Shiba, Sidney [mailto:sidney.shiba@us.fujitsu.com] > Sent: Monday, October 31, 2005 7:56 AM > To: Drake, John E; dpapadimitriou@psg.com > Cc: Adrian Farrel; richard.rabbat@us.fujitsu.com; ccamp@ops.ietf.org > Subject: RE: comments on draft-shiba-ccamp-gmpls-lambda-labels-00.txt >=20 > John, >=20 > Comments inline: >=20 > > -----Original Message----- > > From: Drake, John E [mailto:John.E.Drake2@boeing.com] > > Sent: Monday, October 31, 2005 9:36 AM > > To: Shiba, Sidney; dpapadimitriou@psg.com > > Cc: Adrian Farrel; richard.rabbat@us.fujitsu.com; ccamp@ops.ietf.org > > Subject: RE: comments on draft-shiba-ccamp-gmpls-lambda-labels-00.txt > > > > > > Sidney, > > > > But there's nothing in your picture that requires an absolute end-end > > global wavelength. The existing GMPLS solution with relative > > wavelengths of local significance should work just fine. >=20 > [Sidney] Sorry for the missing info. The optical switch is an all optical > switch (i.e., no OEO is necessary). The wavelength continuity constraint > indicates which wavelength (nominal value) all the optical switches > traversed by the lightpath needs to cross-connect. [JD]=20 I understand all that, but my comment still stands. >=20 > > As I said in my previous note, your method precludes combining two or > > more parallel WDM links into a single TE link. >=20 > [Sidney] Note the Label is complemented by the interface id of the link. >=20 > I think this is the same approach used for parallel SONET OCn datalinks > where the label identifies a time-slot and interface id identifies the > datalink chosen for the connection. [JD]=20 That's probably true, but wavelength LSPs don't have that restriction under the current GMPLS procedures. >=20 > > > > Thanks, > > > > John > > > > > -----Original Message----- > > > From: Shiba, Sidney [mailto:sidney.shiba@us.fujitsu.com] > > > Sent: Monday, October 31, 2005 7:25 AM > > > To: Drake, John E; dpapadimitriou@psg.com > > > Cc: Adrian Farrel; richard.rabbat@us.fujitsu.com; ccamp@ops.ietf.org > > > Subject: RE: comments on > > draft-shiba-ccamp-gmpls-lambda-labels-00.txt > > > > > > Hi John, > > > > > > Optical switches based on Wavelength Selective Switch (WSS) > > technology > > > requires the wavelength information for switching. This > > technology is > > NOT > > > wavelength agnostic. > > > > > > | | > > > | wdm | wdm > > > |2 |2 > > > --------- --------- > > > wdm 1| optical |3 wdm 1| optical |3 wdm > > > --------| switch |------------| switch |--------- > > > | (WSS) | | (WSS) | > > > --------- --------- > > > |4 |4 > > > | wdm | wdm > > > | | > > > > > > Note that the figure above shows an example of two optical switches > > > interconnect > > > by a single WDM fiber. In this example, each optical switch can be > > connect > > > to 4 > > > other optical switches. > > > > > > As you can see, the optical ports information do not provide enough > > > information > > > for wavelength switching. > > > > > > Hope that clarifies the application requirement. > > > > > > Thanks, > > > > > > Sidney > > > > > > > -----Original Message----- > > > > From: Drake, John E [mailto:John.E.Drake2@boeing.com] > > > > Sent: Friday, October 28, 2005 5:33 PM > > > > To: dpapadimitriou@psg.com; Shiba, Sidney > > > > Cc: Adrian Farrel; richard.rabbat@us.fujitsu.com; > > ccamp@ops.ietf.org > > > > Subject: RE: comments on > > draft-shiba-ccamp-gmpls-lambda-labels-00.txt > > > > > > > > > > > > Hi, > > > > > > > > Below is the text of an e-mail is sent to the > > Ethernet/GMPLS mailing > > > > list. > > > > > > > > Upon reflection I am not sure using a real wavelength value makes > > much > > > > sense. Between a pair of adjacent nodes, there may be > > > > multiple pairs of > > > > switch ports in the same TE link that support a given > > frequency. If > > a > > > > real wavelength value is used, how do the two nodes agree on > > > > which pair > > > > of switch ports to use? > > > > > > > > Furthermore, the amount of configuration is the same - you > > > > still need to > > > > configure the wavelength of each switch port. > > > > > > > > Thanks, > > > > > > > > John > > > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > =3D=3D=3D=3D > > > > Adrian, > > > > > > > > In the transparent photonic lambda switch case, the > > labels also have > > > > only local significance. When an LSP is established, the input > > ports, > > > > as identified with local labels, are cross-connected to the output > > > > ports, as identified with local labels. > > > > > > > > There is just extra configuration to identify, using > > strictly local > > > > identifiers, the wavelength associated with the all of > > the switch's > > > > ports, and an additional CAC requirement that the > > wavelengths of the > > > > input and output ports are the same. > > > > > > > > Thanks, > > > > > > > > John > > > > > > > > > > > > > -----Original Message----- > > > > > From: dimitri papadimitriou [mailto:dpapadimitriou@psg.com] > > > > > Sent: Thursday, October 27, 2005 10:03 AM > > > > > To: Shiba, Sidney > > > > > Cc: dimitri.papadimitriou@alcatel.be; Adrian Farrel; > > > > > richard.rabbat@us.fujitsu.com; ccamp@ops.ietf.org > > > > > Subject: Re: comments on > > > > draft-shiba-ccamp-gmpls-lambda-labels-00.txt > > > > > > > > > > shiba - see inline for some additional hints: > > > > > > > > > > >>Shiba, Sidney wrote: > > > > > >> > > > > > >>>Adrian, Dimitri, > > > > > >>> > > > > > >>>Thanks for reviewing these I-D. > > > > > >>> > > > > > >>>Wavelength continuity constraint does require the use of > > > > semanticful > > > > > >>>label whether it is spectral or index. > > > > > >> > > > > > >>=3D> see my reply to adrian on this specific point > > > > > >> > > > > > >>>I agree with Dimitri that the > > > > > >>>wavelength indexing requires document updating each > > time a new > > > > > >>>spectrum is introduced. > > > > > >> > > > > > >>=3D> indeed and in addition it requires updating the already > > > > > >>signaled path > > > > > >> > > > > > >>>The use of spectral label provides self maintainance, i.e., > > > > > >>>no need to update any document and the use of the > > nominal value > > > > > >>>provides a common semantic ground. > > > > > >> > > > > > >>=3D> what do you mean by self-maintenance - would you = provide a > > > > > >>bit more detail > > > > > > > > > > > > [Sidney]What I've meant here was that it was not necessary to > > > > > > update any document when new wavelengths are > > inventoried. In the > > > > > > case of indexing approach, it would require the > > > > wavelength indexing > > > > > > document to be updated with implementation impacts. > > > > > > > > > > > > In the case, the nominal value is used, there is no need for > > > > > > documentation update. > > > > > > > > > > ok - what you mean here is that you are going to make use of the > > > > already > > > > > defined C-Type 2 - what about the specific encoding of the > > > > value space > > > > ? > > > > > > > > > > >>=3D> now i have a more specific question before being = light-up > > > > > >>how do you know the frequency that you can support ? > > > > > > > > > > > > [Sidney] Some new technologies integrate optical switch and > > > > mux/demux > > > > > > capabilities, which allows the equipment to know the > > spectrum it > > > > > supports. > > > > > > > > > > indeed - but the question is what does happen if the > > > > "detected" values > > > > > (during initialization) do not match the nominal values ? you > > don't > > > > > initialize then ? > > > > > > > > > > >>if these differ from the nominal values how are you going to > > deal > > > > with > > > > > these > > > > > >>discrepancies ? > > > > > > > > > > > > [Sidney] These new technologies uses the nominal value as > > > > reference. > > > > We > > > > > can say > > > > > > that a lightpath wavelength is identified by its > > nominal value. > > If > > > > the > > > > > equipment > > > > > > is drifting from this nominal value, it is considered as > > > > a failure. > > > > > > > > > > ok - but if the deviation is such you have overlap - how the > > control > > > > > plane is going to be able to detect such failure ? > > > > > > > > > > >>this said i am not necessarily sure that having to > > > > maintain the data > > > > > plane > > > > > >>specifics as part of the control plane is really helping > > > > > >>operations (is this method not just duplicating complexity ?) > > > > > > > > > > > > [Sidney] The wavelength is WDM specific as much as the SUKLM > > label > > > > > encoding > > > > > > is for SONET. The wavelegth/frequency nominal value is used to > > > > identify > > > > > the > > > > > > facilities to cross-connect. > > > > > > > > > > there is an equivalence but there is also a major > > difference, the > > > > > structure is invariant independently of the state of the > > > > network, with > > > > > spectral value space you may have labels that become unavailable > > due > > > > to > > > > > non-local usage of wavelength in the network > > > > > > > > > > hence, there is also no real coupling to the data plane > > more than > > > > > knowing the type of interface and some generic capabilities > > > > > > > > > > >>>I'm not sure if the draft needs to be updated before the > > > > > >>>face-to-face meeting or after all comments are collected. > > Please > > > > > advise. > > > > > >> > > > > > >>=3D> suggest to keep discussion on - document update can be > > > > > >>performed at a later stage > > > > > > > > > > thanks, > > > > > - dimitri. > > > > > > > > > > >>>>-----Original Message----- > > > > > >>>>From: owner-ccamp@ops.ietf.org > > > > [mailto:owner-ccamp@ops.ietf.org]On > > > > > >>>>Behalf Of Adrian Farrel > > > > > >>>>Sent: Thursday, October 27, 2005 4:45 AM > > > > > >>>>To: dpapadimitriou@psg.com; > > dimitri.papadimitriou@alcatel.be; > > > > > >>>>ccamp@ops.ietf.org > > > > > >>>>Subject: Re: comments on > > > > > >> > > > > > >>draft-shiba-ccamp-gmpls-lambda-labels-00.txt > > > > > >> > > > > > >>>> > > > > > >>>>Dimitri, > > > > > >>>> > > > > > >>>>Thanks for your work reviewing these recent I-Ds. It is > > > > > >>>>really valuable > > > > > >>>>and I'd welcome other people doing similar reviews. > > > > > >>>> > > > > > >>>> > > > > > >>>> > > > > > >>>>>there is a specific point to be clarified in this document: > > > > > >>>>> > > > > > >>>>>semanticless vs semanticful label (even here there is a > > > > distinction > > > > > >>>>>between spectral vs indexes i.e. using the > > wavelength index) > > > > > >>>>> > > > > > >>>>>domain-wide vs link local significant label > > > > > >>>> > > > > > >>>>Without being too picky, I think all labels are semanticful > > > > > >>>>otherwise, we > > > > > >>>>would not know what resource they refered to. > > > > > >>>> > > > > > >>>>So the point reduces to whether the scope of the semantics > > > > > >>>>are link-local > > > > > >>>>or wider. > > > > > >>>> > > > > > >>>> > > > > > >>>> > > > > > >>>>>so, the comparison from this perspective with TDM labels is > > > > > >>>> > > > > > >>>>difficult to > > > > > >>>> > > > > > >>>> > > > > > >>>>>parse, the latter is semanticful but link local > > > > > >>>>> > > > > > >>>>>now, i don't specifically see what has changed the > > late 90's, > > > > early > > > > > >>>>>y2k's, to have a change in the wavelength label definition; > > > > > >>>> > > > > > >>>>This is the question I would like to get to the > > bottom of. In > > > > > >>>>other words: > > > > > >>>>do we need this function? > > > > > >>>> > > > > > >>>>It seems to me that the question being asked is this: > > > > > >>>> > > > > > >>>> If I want to compute a path that has some form of > > wavelength > > > > > >>>> constraints, what information do I need access to? > > > > > >>>> > > > > > >>>>Another question might be: > > > > > >>>> > > > > > >>>> If I want to signal a path with wavelength > > constraints what > > > > > >>>> information do I need to include in the signaling message? > > > > > >>>> > > > > > >>>> > > > > > >>>>I'd suggest that when we started on GMPLS, we were > > > > > >> > > > > > >>enthusiastic about > > > > > >> > > > > > >>>>transparent optical networks, but we were not properly > > > > > >>>>focusing wavelength > > > > > >>>>constraints because lambda-switching PXCs didn't take off. > > > > > >>>>Therefore we > > > > > >>>>didn't examine the requirements for wavelength > > constraints in > > > > > >>>>routing and > > > > > >>>>signaling. The authors of this I-D are claiming new hardware > > > > > >>>>requirements > > > > > >>>>for the same function. > > > > > >>>> > > > > > >>>> > > > > > >>>> > > > > > >>>>>there are > > > > > >>>>>several solution possible > > > > > >>>>> > > > > > >>>>>- absolute values: the freq. of the wavelength: > > difficult to > > > > adopt > > > > > >>>>>because referenced values are nominal and knowing all > > > > interactions > > > > > >>>>>between wavelengths this knowledge is at the end of little > > > > > >> > > > > > >>practical > > > > > >> > > > > > >>>>>usage; (introduces implicit ordering) > > > > > >>>>> > > > > > >>>>>- indexed values: the # of the wavelength: it does not > > > > > >> > > > > > >>provide for a > > > > > >> > > > > > >>>>>future proof label space for inst. in case new frequencies > > > > > >>>> > > > > > >>>>are inserted > > > > > >>>> > > > > > >>>> > > > > > >>>>>in the grid (introduces explicit ordering) > > > > > >>>>> > > > > > >>>>>- diff. values e.g. freq spacing starting from a reference > > > > > >>>> > > > > > >>>>value: pauses > > > > > >>>> > > > > > >>>> > > > > > >>>>>the question of the reference value and does > > suffer from the > > > > former > > > > > >>>>>issue (introduces implicit ordering) > > > > > >>>>> > > > > > >>>>>- the solution available today - cumbersome in some > > > > control plane > > > > > >>>>>operations (e.g. label set translation) and not easy to > > > > > >>>> > > > > > >>>>troubleshoot but > > > > > >>>> > > > > > >>>> > > > > > >>>>>independent of any physical consideration (spectral), scale > > to > > > > any > > > > > >>>>>number of wavelength per fiber, does not introduce any > > > > > >> > > > > > >>ordering, the > > > > > >> > > > > > >>>>>most flexible (since allowing each system to maintain its > > > > specific > > > > > >>>>>control operations) and the less constraining since > > maintaining > > > > the > > > > > >>>>>control plane operations independent of any data plane > > > > specifics > > > > > >>>>> > > > > > >>>>> > > > > > >>>> > > > > > > > >>>> > > > > >>> > > > > > >>>ambda-labels > > > > > >>>-00.txt> > > > > > >>> > > > > > >>>. > > > > > >>> > > > > > >> > > > > > > > > > > > > . > > > > > > > > > > > > From owner-ccamp@ops.ietf.org Mon Oct 31 11:58:53 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWczk-0006Bu-L7 for ccamp-archive@megatron.ietf.org; Mon, 31 Oct 2005 11:58:52 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20201 for ; Mon, 31 Oct 2005 11:58:32 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EWdDy-0008BB-4W for ccamp-archive@ietf.org; Mon, 31 Oct 2005 12:13:34 -0500 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EWctQ-000Bcg-9w for ccamp-data@psg.com; Mon, 31 Oct 2005 16:52:20 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-4.8 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from localhost ([127.0.0.1]) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EWctO-000BcN-JQ; Mon, 31 Oct 2005 16:52:18 +0000 Message-ID: <43664BBF.8030704@psg.com> Date: Mon, 31 Oct 2005 17:52:15 +0100 From: dimitri papadimitriou Reply-To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.11) Gecko/20050728 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Igor Bryskin CC: dimitri.papadimitriou@alcatel.be, "Drake, John E" , "Zafar Ali (zali)" , Igor Bryskin , drake@movaz.com, Kim Young Hwa , ccamp@ops.ietf.org Subject: Re: Two Drafts for Resilience of Control Plane References: <626FC7C6A97381468FB872072AB5DDC8369714@XCH-SW-42.sw.nos.boeing.com> <00b201c5de24$c20fc710$7a1810ac@movaz.com> <436639BA.6040405@psg.com> <011a01c5de33$4fc053f0$7a1810ac@movaz.com> In-Reply-To: <011a01c5de33$4fc053f0$7a1810ac@movaz.com> 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: d16ce744298aacf98517bc7c108bd198 Content-Transfer-Encoding: 7bit igor - Igor Bryskin wrote: > Dimitri, > >>igor - my two cents >> >>RSVP over time has progressively borrowed mechanisms from "hard-state" >>protocols, explicit deletion using PathTear is most noticeable and >>initial example of this evolution ! >> >>but in any case, RSVP still relies is on idem-potent soft-states that >>are flushed when not refreshed after certain time interval (or self- >>maintained if previously negotiated) this prevents orphans in the >>network (so unused resources) and provides for resilience - hence there >>is by no means a need to introduce an additional protocol mechanism to >>trigger or not such event via the "control plane" - > > > Refreshes are useful mechanism but only between neighbors that maintain > Hello communication. In this case the absence of Path refreshes is as good > indication that data plane must be destroyed as received PathTear message. the base function of state refresh and usefulness is independent of hello adjacency maintenance (or any other control channel maintenance) > However, when a controller does not receive Path refreshes from a neighbor > it does not have any control plane communication with, it can assume neither > a problem in the data plane nor intention to destroy it. as the node did not negotiate any channel/node fault recovery (due in part. to the absence of Hello adjacency with its neighbor) and if no other independent control channel failure is provided (this is an add-on of RFC3471/3), the simple absence of refresh is simply intepreted as "implicit deletion" you are mis-interpreting the following sentence of RFC3471 " Note that these cases only apply when there are mechanisms to detect data channel failures independent of control channel failures." there is no retro-fit on the use of Refreshes in absence of control channel failure detection mechanism > Hence, as it was > specified in RFC3471, it *must* maintain both control and data plane states > throughout the failure. - d. > Igor > > >>btw, the paragraph you mention in RFC3471 does not say "soft state >>protocols do not work well for non-packet environments" this is your >>interpretation; >> >>ps: you are still free to make use of RFC3472 in case (as you were >>apparently looking for something else ;-) >> >>Igor Bryskin wrote: >> >>>John, >>> >>> >>> >>> >>>>>States are supposed to be destroyed on explicit signalling >>>>>message (e.g. PathTear or PathErr with the state removal >>>>>flag), but not because of the absence of refreshes. >>>>> >>> >>>[JD] >>> >>>Igor, >>> >>>Just to be clear, we are talking about RSVP here, and RSVP *is* a soft >>>state protocol. Can you point to any RFC that supports your statements >>>above? >>> >>>IB>> Oh, come on, John. You sound like you've been yourself in a dormant >>>state for a while :=). We've gone a long way since RFC2205. In RFC3471, > > for > >>>example, there is a discussion why GMPLS is needed and how is it > > different > >>>from MPLS. One of the differences is the fact that soft state protocols > > do > >>>not work well for non-packet environments. Here is from the RDC3471: >>> >>> >>> >>>9.2. Fault Handling There are two new faults that must be handled > > when > >>>the control channel is independent of the data channel. In the first, >>>there is a link or other type of failure that limits the ability of >>>neighboring nodes to pass control messages. In this situation, >>>neighboring nodes are unable to exchange control messages for a period > > of > >>>time. Once communication is restored the underlying signaling > > protocol > >>>must indicate that the nodes have maintained their state through the >>>failure.. >>> >>>What is more important is the reality of life: The customers simply say > > that > >>>you cannot destroy a user service (or even force any traffic hits) just >>>because you have a problem in the control plane. If this does not fit > > your > >>>soft-state paradigm, than "harden" your protocols or flash them down the >>>toilet and come with something else if you want our business. After all, > > if > >>>we provision the services via NMS, we do not have to destroy the > > services if > >>>we have problems in the management network. It is that simple. >>> >>> >>> >>>Igor >>> >>> >>> >>> >>> >>> >>> >>>. >>> > > > > > . > From owner-ccamp@ops.ietf.org Mon Oct 31 11:59:02 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWczu-0006ED-Ol for ccamp-archive@megatron.ietf.org; Mon, 31 Oct 2005 11:59:02 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20217 for ; Mon, 31 Oct 2005 11:58:42 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EWdE3-0008Ba-FZ for ccamp-archive@ietf.org; Mon, 31 Oct 2005 12:13:44 -0500 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EWctg-000Bdm-0C for ccamp-data@psg.com; Mon, 31 Oct 2005 16:52:36 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [168.127.0.57] (helo=fncnmp04.fnc.fujitsu.com) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EWcte-000BdV-2U for ccamp@ops.ietf.org; Mon, 31 Oct 2005 16:52:34 +0000 Received: from rchemx01.fnc.net.local (167.254.101.101) by fncnmp04.fnc.fujitsu.com with ESMTP; 31 Oct 2005 10:52:24 -0600 X-IronPort-AV: i="3.97,270,1125896400"; d="scan'208"; a="10649120:sNHT18815876" 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: comments on draft-shiba-ccamp-gmpls-lambda-labels-00.txt Date: Mon, 31 Oct 2005 10:52:23 -0600 Message-ID: <7CA873794E52904EAA980A074B076779B17C63@rchemx01.fnc.net.local> Thread-Topic: comments on draft-shiba-ccamp-gmpls-lambda-labels-00.txt Thread-Index: AcXbIzcAFoI5B5TzS9O/zBGY1cMJbwA6iz0AAIdyNZAAAR14UAAAqdxAAAGnFZAAAGLHsA== From: "Shiba, Sidney" To: "Drake, John E" , Cc: "Adrian Farrel" , , Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: a7c7a0f28a102b9cb6317697abf1cf76 Content-Transfer-Encoding: quoted-printable John, Comments inline: > -----Original Message----- > From: Drake, John E [mailto:John.E.Drake2@boeing.com] > Sent: Monday, October 31, 2005 10:43 AM > To: Shiba, Sidney; dpapadimitriou@psg.com > Cc: Adrian Farrel; richard.rabbat@us.fujitsu.com; ccamp@ops.ietf.org > Subject: RE: comments on draft-shiba-ccamp-gmpls-lambda-labels-00.txt >=20 >=20 >=20 >=20 > > -----Original Message----- > > From: Shiba, Sidney [mailto:sidney.shiba@us.fujitsu.com] > > Sent: Monday, October 31, 2005 7:56 AM > > To: Drake, John E; dpapadimitriou@psg.com > > Cc: Adrian Farrel; richard.rabbat@us.fujitsu.com; ccamp@ops.ietf.org > > Subject: RE: comments on=20 > draft-shiba-ccamp-gmpls-lambda-labels-00.txt > >=20 > > John, > >=20 > > Comments inline: > >=20 > > > -----Original Message----- > > > From: Drake, John E [mailto:John.E.Drake2@boeing.com] > > > Sent: Monday, October 31, 2005 9:36 AM > > > To: Shiba, Sidney; dpapadimitriou@psg.com > > > Cc: Adrian Farrel; richard.rabbat@us.fujitsu.com;=20 > ccamp@ops.ietf.org > > > Subject: RE: comments on > draft-shiba-ccamp-gmpls-lambda-labels-00.txt > > > > > > > > > Sidney, > > > > > > But there's nothing in your picture that requires an absolute > end-end > > > global wavelength. The existing GMPLS solution with relative > > > wavelengths of local significance should work just fine. > >=20 > > [Sidney] Sorry for the missing info. The optical switch is an all > optical > > switch (i.e., no OEO is necessary). The wavelength continuity > constraint > > indicates which wavelength (nominal value) all the optical switches > > traversed by the lightpath needs to cross-connect. > [JD]=20 >=20 > I understand all that, but my comment still stands. >=20 [Sidney] May be I'm missing something but for example, can you explain=20 me how can we use Label Set with labels that only have local = significance? > >=20 > > > As I said in my previous note, your method precludes combining two > or > > > more parallel WDM links into a single TE link. > >=20 > > [Sidney] Note the Label is complemented by the interface id of the > link. > >=20 > > I think this is the same approach used for parallel SONET OCn > datalinks > > where the label identifies a time-slot and interface id=20 > identifies the > > datalink chosen for the connection. > [JD]=20 >=20 > That's probably true, but wavelength LSPs don't have that restriction > under the current GMPLS procedures. >=20 [Sidney] I understand that current wavelength LSPs don't have that = restriction. What the draft is proposing are procedures for optical switches using = WSS=20 technology. > >=20 > > > > > > Thanks, > > > > > > John > > > > > > > -----Original Message----- > > > > From: Shiba, Sidney [mailto:sidney.shiba@us.fujitsu.com] > > > > Sent: Monday, October 31, 2005 7:25 AM > > > > To: Drake, John E; dpapadimitriou@psg.com > > > > Cc: Adrian Farrel; richard.rabbat@us.fujitsu.com; > ccamp@ops.ietf.org > > > > Subject: RE: comments on > > > draft-shiba-ccamp-gmpls-lambda-labels-00.txt > > > > > > > > Hi John, > > > > > > > > Optical switches based on Wavelength Selective Switch (WSS) > > > technology > > > > requires the wavelength information for switching. This > > > technology is > > > NOT > > > > wavelength agnostic. > > > > > > > > | | > > > > | wdm | wdm > > > > |2 |2 > > > > --------- --------- > > > > wdm 1| optical |3 wdm 1| optical |3 wdm > > > > --------| switch |------------| switch |--------- > > > > | (WSS) | | (WSS) | > > > > --------- --------- > > > > |4 |4 > > > > | wdm | wdm > > > > | | > > > > > > > > Note that the figure above shows an example of two optical > switches > > > > interconnect > > > > by a single WDM fiber. In this example, each optical=20 > switch can be > > > connect > > > > to 4 > > > > other optical switches. > > > > > > > > As you can see, the optical ports information do not provide > enough > > > > information > > > > for wavelength switching. > > > > > > > > Hope that clarifies the application requirement. > > > > > > > > Thanks, > > > > > > > > Sidney > > > > > > > > > -----Original Message----- > > > > > From: Drake, John E [mailto:John.E.Drake2@boeing.com] > > > > > Sent: Friday, October 28, 2005 5:33 PM > > > > > To: dpapadimitriou@psg.com; Shiba, Sidney > > > > > Cc: Adrian Farrel; richard.rabbat@us.fujitsu.com; > > > ccamp@ops.ietf.org > > > > > Subject: RE: comments on > > > draft-shiba-ccamp-gmpls-lambda-labels-00.txt > > > > > > > > > > > > > > > Hi, > > > > > > > > > > Below is the text of an e-mail is sent to the > > > Ethernet/GMPLS mailing > > > > > list. > > > > > > > > > > Upon reflection I am not sure using a real wavelength value > makes > > > much > > > > > sense. Between a pair of adjacent nodes, there may be > > > > > multiple pairs of > > > > > switch ports in the same TE link that support a given > > > frequency. If > > > a > > > > > real wavelength value is used, how do the two nodes agree on > > > > > which pair > > > > > of switch ports to use? > > > > > > > > > > Furthermore, the amount of configuration is the same - you > > > > > still need to > > > > > configure the wavelength of each switch port. > > > > > > > > > > Thanks, > > > > > > > > > > John > > > > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > > =3D=3D=3D=3D > > > > > Adrian, > > > > > > > > > > In the transparent photonic lambda switch case, the > > > labels also have > > > > > only local significance. When an LSP is established,=20 > the input > > > ports, > > > > > as identified with local labels, are cross-connected to the > output > > > > > ports, as identified with local labels. > > > > > > > > > > There is just extra configuration to identify, using > > > strictly local > > > > > identifiers, the wavelength associated with the all of > > > the switch's > > > > > ports, and an additional CAC requirement that the > > > wavelengths of the > > > > > input and output ports are the same. > > > > > > > > > > Thanks, > > > > > > > > > > John > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: dimitri papadimitriou [mailto:dpapadimitriou@psg.com] > > > > > > Sent: Thursday, October 27, 2005 10:03 AM > > > > > > To: Shiba, Sidney > > > > > > Cc: dimitri.papadimitriou@alcatel.be; Adrian Farrel; > > > > > > richard.rabbat@us.fujitsu.com; ccamp@ops.ietf.org > > > > > > Subject: Re: comments on > > > > > draft-shiba-ccamp-gmpls-lambda-labels-00.txt > > > > > > > > > > > > shiba - see inline for some additional hints: > > > > > > > > > > > > >>Shiba, Sidney wrote: > > > > > > >> > > > > > > >>>Adrian, Dimitri, > > > > > > >>> > > > > > > >>>Thanks for reviewing these I-D. > > > > > > >>> > > > > > > >>>Wavelength continuity constraint does require the use of > > > > > semanticful > > > > > > >>>label whether it is spectral or index. > > > > > > >> > > > > > > >>=3D> see my reply to adrian on this specific point > > > > > > >> > > > > > > >>>I agree with Dimitri that the > > > > > > >>>wavelength indexing requires document updating each > > > time a new > > > > > > >>>spectrum is introduced. > > > > > > >> > > > > > > >>=3D> indeed and in addition it requires updating the = already > > > > > > >>signaled path > > > > > > >> > > > > > > >>>The use of spectral label provides self=20 > maintainance, i.e., > > > > > > >>>no need to update any document and the use of the > > > nominal value > > > > > > >>>provides a common semantic ground. > > > > > > >> > > > > > > >>=3D> what do you mean by self-maintenance - would=20 > you provide > a > > > > > > >>bit more detail > > > > > > > > > > > > > > [Sidney]What I've meant here was that it was not necessary > to > > > > > > > update any document when new wavelengths are > > > inventoried. In the > > > > > > > case of indexing approach, it would require the > > > > > wavelength indexing > > > > > > > document to be updated with implementation impacts. > > > > > > > > > > > > > > In the case, the nominal value is used, there is=20 > no need for > > > > > > > documentation update. > > > > > > > > > > > > ok - what you mean here is that you are going to make use of > the > > > > > already > > > > > > defined C-Type 2 - what about the specific encoding of the > > > > > value space > > > > > ? > > > > > > > > > > > > >>=3D> now i have a more specific question before=20 > being light-up > > > > > > >>how do you know the frequency that you can support ? > > > > > > > > > > > > > > [Sidney] Some new technologies integrate optical=20 > switch and > > > > > mux/demux > > > > > > > capabilities, which allows the equipment to know the > > > spectrum it > > > > > > supports. > > > > > > > > > > > > indeed - but the question is what does happen if the > > > > > "detected" values > > > > > > (during initialization) do not match the nominal=20 > values ? you > > > don't > > > > > > initialize then ? > > > > > > > > > > > > >>if these differ from the nominal values how are=20 > you going to > > > deal > > > > > with > > > > > > these > > > > > > >>discrepancies ? > > > > > > > > > > > > > > [Sidney] These new technologies uses the nominal value as > > > > > reference. > > > > > We > > > > > > can say > > > > > > > that a lightpath wavelength is identified by its > > > nominal value. > > > If > > > > > the > > > > > > equipment > > > > > > > is drifting from this nominal value, it is considered as > > > > > a failure. > > > > > > > > > > > > ok - but if the deviation is such you have overlap - how the > > > control > > > > > > plane is going to be able to detect such failure ? > > > > > > > > > > > > >>this said i am not necessarily sure that having to > > > > > maintain the data > > > > > > plane > > > > > > >>specifics as part of the control plane is really helping > > > > > > >>operations (is this method not just duplicating complexity > ?) > > > > > > > > > > > > > > [Sidney] The wavelength is WDM specific as much=20 > as the SUKLM > > > label > > > > > > encoding > > > > > > > is for SONET. The wavelegth/frequency nominal=20 > value is used > to > > > > > identify > > > > > > the > > > > > > > facilities to cross-connect. > > > > > > > > > > > > there is an equivalence but there is also a major > > > difference, the > > > > > > structure is invariant independently of the state of the > > > > > network, with > > > > > > spectral value space you may have labels that become > unavailable > > > due > > > > > to > > > > > > non-local usage of wavelength in the network > > > > > > > > > > > > hence, there is also no real coupling to the data plane > > > more than > > > > > > knowing the type of interface and some generic capabilities > > > > > > > > > > > > >>>I'm not sure if the draft needs to be updated before the > > > > > > >>>face-to-face meeting or after all comments are collected. > > > Please > > > > > > advise. > > > > > > >> > > > > > > >>=3D> suggest to keep discussion on - document update can = be > > > > > > >>performed at a later stage > > > > > > > > > > > > thanks, > > > > > > - dimitri. > > > > > > > > > > > > >>>>-----Original Message----- > > > > > > >>>>From: owner-ccamp@ops.ietf.org > > > > > [mailto:owner-ccamp@ops.ietf.org]On > > > > > > >>>>Behalf Of Adrian Farrel > > > > > > >>>>Sent: Thursday, October 27, 2005 4:45 AM > > > > > > >>>>To: dpapadimitriou@psg.com; > > > dimitri.papadimitriou@alcatel.be; > > > > > > >>>>ccamp@ops.ietf.org > > > > > > >>>>Subject: Re: comments on > > > > > > >> > > > > > > >>draft-shiba-ccamp-gmpls-lambda-labels-00.txt > > > > > > >> > > > > > > >>>> > > > > > > >>>>Dimitri, > > > > > > >>>> > > > > > > >>>>Thanks for your work reviewing these recent I-Ds. It is > > > > > > >>>>really valuable > > > > > > >>>>and I'd welcome other people doing similar reviews. > > > > > > >>>> > > > > > > >>>> > > > > > > >>>> > > > > > > >>>>>there is a specific point to be clarified in this > document: > > > > > > >>>>> > > > > > > >>>>>semanticless vs semanticful label (even here there is a > > > > > distinction > > > > > > >>>>>between spectral vs indexes i.e. using the > > > wavelength index) > > > > > > >>>>> > > > > > > >>>>>domain-wide vs link local significant label > > > > > > >>>> > > > > > > >>>>Without being too picky, I think all labels are > semanticful > > > > > > >>>>otherwise, we > > > > > > >>>>would not know what resource they refered to. > > > > > > >>>> > > > > > > >>>>So the point reduces to whether the scope of=20 > the semantics > > > > > > >>>>are link-local > > > > > > >>>>or wider. > > > > > > >>>> > > > > > > >>>> > > > > > > >>>> > > > > > > >>>>>so, the comparison from this perspective with=20 > TDM labels > is > > > > > > >>>> > > > > > > >>>>difficult to > > > > > > >>>> > > > > > > >>>> > > > > > > >>>>>parse, the latter is semanticful but link local > > > > > > >>>>> > > > > > > >>>>>now, i don't specifically see what has changed the > > > late 90's, > > > > > early > > > > > > >>>>>y2k's, to have a change in the wavelength label > definition; > > > > > > >>>> > > > > > > >>>>This is the question I would like to get to the > > > bottom of. In > > > > > > >>>>other words: > > > > > > >>>>do we need this function? > > > > > > >>>> > > > > > > >>>>It seems to me that the question being asked is this: > > > > > > >>>> > > > > > > >>>> If I want to compute a path that has some form of > > > wavelength > > > > > > >>>> constraints, what information do I need access to? > > > > > > >>>> > > > > > > >>>>Another question might be: > > > > > > >>>> > > > > > > >>>> If I want to signal a path with wavelength > > > constraints what > > > > > > >>>> information do I need to include in the signaling > message? > > > > > > >>>> > > > > > > >>>> > > > > > > >>>>I'd suggest that when we started on GMPLS, we were > > > > > > >> > > > > > > >>enthusiastic about > > > > > > >> > > > > > > >>>>transparent optical networks, but we were not properly > > > > > > >>>>focusing wavelength > > > > > > >>>>constraints because lambda-switching PXCs=20 > didn't take off. > > > > > > >>>>Therefore we > > > > > > >>>>didn't examine the requirements for wavelength > > > constraints in > > > > > > >>>>routing and > > > > > > >>>>signaling. The authors of this I-D are claiming new > hardware > > > > > > >>>>requirements > > > > > > >>>>for the same function. > > > > > > >>>> > > > > > > >>>> > > > > > > >>>> > > > > > > >>>>>there are > > > > > > >>>>>several solution possible > > > > > > >>>>> > > > > > > >>>>>- absolute values: the freq. of the wavelength: > > > difficult to > > > > > adopt > > > > > > >>>>>because referenced values are nominal and knowing all > > > > > interactions > > > > > > >>>>>between wavelengths this knowledge is at the end of > little > > > > > > >> > > > > > > >>practical > > > > > > >> > > > > > > >>>>>usage; (introduces implicit ordering) > > > > > > >>>>> > > > > > > >>>>>- indexed values: the # of the wavelength: it does not > > > > > > >> > > > > > > >>provide for a > > > > > > >> > > > > > > >>>>>future proof label space for inst. in case new > frequencies > > > > > > >>>> > > > > > > >>>>are inserted > > > > > > >>>> > > > > > > >>>> > > > > > > >>>>>in the grid (introduces explicit ordering) > > > > > > >>>>> > > > > > > >>>>>- diff. values e.g. freq spacing starting from a > reference > > > > > > >>>> > > > > > > >>>>value: pauses > > > > > > >>>> > > > > > > >>>> > > > > > > >>>>>the question of the reference value and does > > > suffer from the > > > > > former > > > > > > >>>>>issue (introduces implicit ordering) > > > > > > >>>>> > > > > > > >>>>>- the solution available today - cumbersome in some > > > > > control plane > > > > > > >>>>>operations (e.g. label set translation) and not easy to > > > > > > >>>> > > > > > > >>>>troubleshoot but > > > > > > >>>> > > > > > > >>>> > > > > > > >>>>>independent of any physical consideration (spectral), > scale > > > to > > > > > any > > > > > > >>>>>number of wavelength per fiber, does not introduce any > > > > > > >> > > > > > > >>ordering, the > > > > > > >> > > > > > > >>>>>most flexible (since allowing each system to=20 > maintain its > > > > > specific > > > > > > >>>>>control operations) and the less constraining since > > > maintaining > > > > > the > > > > > > >>>>>control plane operations independent of any data plane > > > > > specifics > > > > > > >>>>> > > > > > > >>>>> > > > > > > >>>> > > > > > > > > > >>>> > > > > > >>> > > > > > > >>>ambda-labels > > > > > > >>>-00.txt> > > > > > > >>> > > > > > > >>>. > > > > > > >>> > > > > > > >> > > > > > > > > > > > > > > . > > > > > > > > > > > > > > > >=20 From owner-ccamp@ops.ietf.org Mon Oct 31 12:04:25 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWd57-0007aZ-DW for ccamp-archive@megatron.ietf.org; Mon, 31 Oct 2005 12:04:25 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20646 for ; Mon, 31 Oct 2005 12:04:05 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EWdJG-00005j-Dc for ccamp-archive@ietf.org; Mon, 31 Oct 2005 12:19:07 -0500 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EWcz7-000C3y-1Z for ccamp-data@psg.com; Mon, 31 Oct 2005 16:58:13 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [130.76.64.48] (helo=slb-smtpout-01.boeing.com) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EWcz5-000C3g-Mt; Mon, 31 Oct 2005 16:58:11 +0000 Received: from slb-av-01.boeing.com ([129.172.13.4]) by slb-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id IAA10226; Mon, 31 Oct 2005 08:58:11 -0800 (PST) Received: from XCH-SWBH-04.sw.nos.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id j9VGwAd11098; Mon, 31 Oct 2005 08:58:10 -0800 (PST) Received: from XCH-SW-42.sw.nos.boeing.com ([192.79.11.43]) by XCH-SWBH-04.sw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 31 Oct 2005 08:58:10 -0800 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: comments on draft-shiba-ccamp-gmpls-lambda-labels-00.txt Date: Mon, 31 Oct 2005 08:58:10 -0800 Message-ID: <626FC7C6A97381468FB872072AB5DDC836971E@XCH-SW-42.sw.nos.boeing.com> Thread-Topic: comments on draft-shiba-ccamp-gmpls-lambda-labels-00.txt Thread-Index: AcXeNcpyWStaVYm1SxaXOoXTA/t1xQABG17A From: "Drake, John E" To: "Payam Torab" , "Shiba, Sidney" , Cc: "Adrian Farrel" , , X-OriginalArrivalTime: 31 Oct 2005 16:58:10.0393 (UTC) FILETIME=[4602F490:01C5DE3C] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de8c36679aaa17b008853e74231c885 Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: Payam Torab [mailto:ptorab@lopsys.com] > Sent: Monday, October 31, 2005 8:12 AM > To: Drake, John E; 'Shiba, Sidney'; dpapadimitriou@psg.com > Cc: 'Adrian Farrel'; richard.rabbat@us.fujitsu.com; ccamp@ops.ietf.org > Subject: RE: comments on draft-shiba-ccamp-gmpls-lambda-labels-00.txt >=20 > John- >=20 > Obviously the benefits or harms of giving a global meaning to a lambda > label requires study, but your particular example is not a good one: If > one really wants to have a preference for a specific wavelength channel > among multiple parallel channels of the same wavelength, bundling should > not be exercised in the first place. [JD]=20 It isn't bundling. LMP allows one to configure two or more parallel WDM systems into a single TE link. One reason for doing this is to improve the scalability of the TE LSB. Another is to reduce crankback (see below). If this done, you would have multiple instances of each of the wavelengths supported by the WDM systems. You asserted that this is a BadIdea(tm), but it reduces crankback in the network. If you make each parallel WDM system a separate TE link, then you have bound the LSP to the selected TE link. If the selected wavelength is blocked, you have to crankback. If you combine the parallel WDM systems into a single TE link, then the LSP can be progressed on *any* WDM system on which the selected wavelength is available.=20 >=20 > Thanks, > Payam >=20 > -----Original Message----- > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On > Behalf Of Drake, John E > Sent: Monday, October 31, 2005 10:36 AM > To: Shiba, Sidney; dpapadimitriou@psg.com > Cc: Adrian Farrel; richard.rabbat@us.fujitsu.com; ccamp@ops.ietf.org > Subject: RE: comments on draft-shiba-ccamp-gmpls-lambda-labels-00.txt >=20 >=20 > Sidney, >=20 > But there's nothing in your picture that requires an absolute end-end > global wavelength. The existing GMPLS solution with relative > wavelengths of local significance should work just fine. As I said in > my previous note, your method precludes combining two or more parallel > WDM links into a single TE link. >=20 > Thanks, >=20 > John >=20 > > -----Original Message----- > > From: Shiba, Sidney [mailto:sidney.shiba@us.fujitsu.com] > > Sent: Monday, October 31, 2005 7:25 AM > > To: Drake, John E; dpapadimitriou@psg.com > > Cc: Adrian Farrel; richard.rabbat@us.fujitsu.com; ccamp@ops.ietf.org > > Subject: RE: comments on draft-shiba-ccamp-gmpls-lambda-labels-00.txt > > > > Hi John, > > > > Optical switches based on Wavelength Selective Switch (WSS) technology > > requires the wavelength information for switching. This technology is > NOT > > wavelength agnostic. > > > > | | > > | wdm | wdm > > |2 |2 > > --------- --------- > > wdm 1| optical |3 wdm 1| optical |3 wdm > > --------| switch |------------| switch |--------- > > | (WSS) | | (WSS) | > > --------- --------- > > |4 |4 > > | wdm | wdm > > | | > > > > Note that the figure above shows an example of two optical switches > > interconnect > > by a single WDM fiber. In this example, each optical switch can be > connect > > to 4 > > other optical switches. > > > > As you can see, the optical ports information do not provide enough > > information > > for wavelength switching. > > > > Hope that clarifies the application requirement. > > > > Thanks, > > > > Sidney > > > > > -----Original Message----- > > > From: Drake, John E [mailto:John.E.Drake2@boeing.com] > > > Sent: Friday, October 28, 2005 5:33 PM > > > To: dpapadimitriou@psg.com; Shiba, Sidney > > > Cc: Adrian Farrel; richard.rabbat@us.fujitsu.com; ccamp@ops.ietf.org > > > Subject: RE: comments on > draft-shiba-ccamp-gmpls-lambda-labels-00.txt > > > > > > > > > Hi, > > > > > > Below is the text of an e-mail is sent to the Ethernet/GMPLS mailing > > > list. > > > > > > Upon reflection I am not sure using a real wavelength value makes > much > > > sense. Between a pair of adjacent nodes, there may be > > > multiple pairs of > > > switch ports in the same TE link that support a given frequency. If > a > > > real wavelength value is used, how do the two nodes agree on > > > which pair > > > of switch ports to use? > > > > > > Furthermore, the amount of configuration is the same - you > > > still need to > > > configure the wavelength of each switch port. > > > > > > Thanks, > > > > > > John > > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > =3D=3D=3D=3D > > > Adrian, > > > > > > In the transparent photonic lambda switch case, the labels also have > > > only local significance. When an LSP is established, the input > ports, > > > as identified with local labels, are cross-connected to the output > > > ports, as identified with local labels. > > > > > > There is just extra configuration to identify, using strictly local > > > identifiers, the wavelength associated with the all of the switch's > > > ports, and an additional CAC requirement that the wavelengths of the > > > input and output ports are the same. > > > > > > Thanks, > > > > > > John > > > > > > > > > > -----Original Message----- > > > > From: dimitri papadimitriou [mailto:dpapadimitriou@psg.com] > > > > Sent: Thursday, October 27, 2005 10:03 AM > > > > To: Shiba, Sidney > > > > Cc: dimitri.papadimitriou@alcatel.be; Adrian Farrel; > > > > richard.rabbat@us.fujitsu.com; ccamp@ops.ietf.org > > > > Subject: Re: comments on > > > draft-shiba-ccamp-gmpls-lambda-labels-00.txt > > > > > > > > shiba - see inline for some additional hints: > > > > > > > > >>Shiba, Sidney wrote: > > > > >> > > > > >>>Adrian, Dimitri, > > > > >>> > > > > >>>Thanks for reviewing these I-D. > > > > >>> > > > > >>>Wavelength continuity constraint does require the use of > > > semanticful > > > > >>>label whether it is spectral or index. > > > > >> > > > > >>=3D> see my reply to adrian on this specific point > > > > >> > > > > >>>I agree with Dimitri that the > > > > >>>wavelength indexing requires document updating each time a new > > > > >>>spectrum is introduced. > > > > >> > > > > >>=3D> indeed and in addition it requires updating the already > > > > >>signaled path > > > > >> > > > > >>>The use of spectral label provides self maintainance, i.e., > > > > >>>no need to update any document and the use of the nominal value > > > > >>>provides a common semantic ground. > > > > >> > > > > >>=3D> what do you mean by self-maintenance - would you provide = a > > > > >>bit more detail > > > > > > > > > > [Sidney]What I've meant here was that it was not necessary to > > > > > update any document when new wavelengths are inventoried. In the > > > > > case of indexing approach, it would require the > > > wavelength indexing > > > > > document to be updated with implementation impacts. > > > > > > > > > > In the case, the nominal value is used, there is no need for > > > > > documentation update. > > > > > > > > ok - what you mean here is that you are going to make use of the > > > already > > > > defined C-Type 2 - what about the specific encoding of the > > > value space > > > ? > > > > > > > > >>=3D> now i have a more specific question before being light-up > > > > >>how do you know the frequency that you can support ? > > > > > > > > > > [Sidney] Some new technologies integrate optical switch and > > > mux/demux > > > > > capabilities, which allows the equipment to know the spectrum it > > > > supports. > > > > > > > > indeed - but the question is what does happen if the > > > "detected" values > > > > (during initialization) do not match the nominal values ? you > don't > > > > initialize then ? > > > > > > > > >>if these differ from the nominal values how are you going to > deal > > > with > > > > these > > > > >>discrepancies ? > > > > > > > > > > [Sidney] These new technologies uses the nominal value as > > > reference. > > > We > > > > can say > > > > > that a lightpath wavelength is identified by its nominal value. > If > > > the > > > > equipment > > > > > is drifting from this nominal value, it is considered as > > > a failure. > > > > > > > > ok - but if the deviation is such you have overlap - how the > control > > > > plane is going to be able to detect such failure ? > > > > > > > > >>this said i am not necessarily sure that having to > > > maintain the data > > > > plane > > > > >>specifics as part of the control plane is really helping > > > > >>operations (is this method not just duplicating complexity ?) > > > > > > > > > > [Sidney] The wavelength is WDM specific as much as the SUKLM > label > > > > encoding > > > > > is for SONET. The wavelegth/frequency nominal value is used to > > > identify > > > > the > > > > > facilities to cross-connect. > > > > > > > > there is an equivalence but there is also a major difference, the > > > > structure is invariant independently of the state of the > > > network, with > > > > spectral value space you may have labels that become unavailable > due > > > to > > > > non-local usage of wavelength in the network > > > > > > > > hence, there is also no real coupling to the data plane more than > > > > knowing the type of interface and some generic capabilities > > > > > > > > >>>I'm not sure if the draft needs to be updated before the > > > > >>>face-to-face meeting or after all comments are collected. > Please > > > > advise. > > > > >> > > > > >>=3D> suggest to keep discussion on - document update can be > > > > >>performed at a later stage > > > > > > > > thanks, > > > > - dimitri. > > > > > > > > >>>>-----Original Message----- > > > > >>>>From: owner-ccamp@ops.ietf.org > > > [mailto:owner-ccamp@ops.ietf.org]On > > > > >>>>Behalf Of Adrian Farrel > > > > >>>>Sent: Thursday, October 27, 2005 4:45 AM > > > > >>>>To: dpapadimitriou@psg.com; dimitri.papadimitriou@alcatel.be; > > > > >>>>ccamp@ops.ietf.org > > > > >>>>Subject: Re: comments on > > > > >> > > > > >>draft-shiba-ccamp-gmpls-lambda-labels-00.txt > > > > >> > > > > >>>> > > > > >>>>Dimitri, > > > > >>>> > > > > >>>>Thanks for your work reviewing these recent I-Ds. It is > > > > >>>>really valuable > > > > >>>>and I'd welcome other people doing similar reviews. > > > > >>>> > > > > >>>> > > > > >>>> > > > > >>>>>there is a specific point to be clarified in this document: > > > > >>>>> > > > > >>>>>semanticless vs semanticful label (even here there is a > > > distinction > > > > >>>>>between spectral vs indexes i.e. using the wavelength index) > > > > >>>>> > > > > >>>>>domain-wide vs link local significant label > > > > >>>> > > > > >>>>Without being too picky, I think all labels are semanticful > > > > >>>>otherwise, we > > > > >>>>would not know what resource they refered to. > > > > >>>> > > > > >>>>So the point reduces to whether the scope of the semantics > > > > >>>>are link-local > > > > >>>>or wider. > > > > >>>> > > > > >>>> > > > > >>>> > > > > >>>>>so, the comparison from this perspective with TDM labels is > > > > >>>> > > > > >>>>difficult to > > > > >>>> > > > > >>>> > > > > >>>>>parse, the latter is semanticful but link local > > > > >>>>> > > > > >>>>>now, i don't specifically see what has changed the late 90's, > > > early > > > > >>>>>y2k's, to have a change in the wavelength label definition; > > > > >>>> > > > > >>>>This is the question I would like to get to the bottom of. In > > > > >>>>other words: > > > > >>>>do we need this function? > > > > >>>> > > > > >>>>It seems to me that the question being asked is this: > > > > >>>> > > > > >>>> If I want to compute a path that has some form of wavelength > > > > >>>> constraints, what information do I need access to? > > > > >>>> > > > > >>>>Another question might be: > > > > >>>> > > > > >>>> If I want to signal a path with wavelength constraints what > > > > >>>> information do I need to include in the signaling message? > > > > >>>> > > > > >>>> > > > > >>>>I'd suggest that when we started on GMPLS, we were > > > > >> > > > > >>enthusiastic about > > > > >> > > > > >>>>transparent optical networks, but we were not properly > > > > >>>>focusing wavelength > > > > >>>>constraints because lambda-switching PXCs didn't take off. > > > > >>>>Therefore we > > > > >>>>didn't examine the requirements for wavelength constraints in > > > > >>>>routing and > > > > >>>>signaling. The authors of this I-D are claiming new hardware > > > > >>>>requirements > > > > >>>>for the same function. > > > > >>>> > > > > >>>> > > > > >>>> > > > > >>>>>there are > > > > >>>>>several solution possible > > > > >>>>> > > > > >>>>>- absolute values: the freq. of the wavelength: difficult to > > > adopt > > > > >>>>>because referenced values are nominal and knowing all > > > interactions > > > > >>>>>between wavelengths this knowledge is at the end of little > > > > >> > > > > >>practical > > > > >> > > > > >>>>>usage; (introduces implicit ordering) > > > > >>>>> > > > > >>>>>- indexed values: the # of the wavelength: it does not > > > > >> > > > > >>provide for a > > > > >> > > > > >>>>>future proof label space for inst. in case new frequencies > > > > >>>> > > > > >>>>are inserted > > > > >>>> > > > > >>>> > > > > >>>>>in the grid (introduces explicit ordering) > > > > >>>>> > > > > >>>>>- diff. values e.g. freq spacing starting from a reference > > > > >>>> > > > > >>>>value: pauses > > > > >>>> > > > > >>>> > > > > >>>>>the question of the reference value and does suffer from the > > > former > > > > >>>>>issue (introduces implicit ordering) > > > > >>>>> > > > > >>>>>- the solution available today - cumbersome in some > > > control plane > > > > >>>>>operations (e.g. label set translation) and not easy to > > > > >>>> > > > > >>>>troubleshoot but > > > > >>>> > > > > >>>> > > > > >>>>>independent of any physical consideration (spectral), scale > to > > > any > > > > >>>>>number of wavelength per fiber, does not introduce any > > > > >> > > > > >>ordering, the > > > > >> > > > > >>>>>most flexible (since allowing each system to maintain its > > > specific > > > > >>>>>control operations) and the less constraining since > maintaining > > > the > > > > >>>>>control plane operations independent of any data plane > > > specifics > > > > >>>>> > > > > >>>>> > > > > >>>> > > > > >>>> > > > >>> > > > > >>>ambda-labels > > > > >>>-00.txt> > > > > >>> > > > > >>>. > > > > >>> > > > > >> > > > > > > > > > > . > > > > > > > > From owner-ccamp@ops.ietf.org Mon Oct 31 12:21:57 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWdM5-0004dP-Dh for ccamp-archive@megatron.ietf.org; Mon, 31 Oct 2005 12:21:57 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21836 for ; Mon, 31 Oct 2005 12:21:36 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EWdaJ-0002MK-2r for ccamp-archive@ietf.org; Mon, 31 Oct 2005 12:36:39 -0500 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EWdHd-000DLF-6q for ccamp-data@psg.com; Mon, 31 Oct 2005 17:17:21 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [70.158.43.219] (helo=jera.movaz.com) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EWdHb-000DL2-SV for ccamp@ops.ietf.org; Mon, 31 Oct 2005 17:17:20 +0000 Received: from ib (unknown [172.16.24.122]) by jera.movaz.com (Postfix) with SMTP id 93CDE14EC2; Mon, 31 Oct 2005 12:17:18 -0500 (EST) Message-ID: <015b01c5de3e$f2a2a090$7a1810ac@movaz.com> From: "Igor Bryskin" To: , Cc: , "Drake, John E" , "Zafar Ali (zali)" , "Igor Bryskin" , , "Kim Young Hwa" , References: <626FC7C6A97381468FB872072AB5DDC8369714@XCH-SW-42.sw.nos.boeing.com> <00b201c5de24$c20fc710$7a1810ac@movaz.com> <436639BA.6040405@psg.com> <011a01c5de33$4fc053f0$7a1810ac@movaz.com> <43664BBF.8030704@psg.com> Subject: Re: Two Drafts for Resilience of Control Plane Date: Mon, 31 Oct 2005 12:17:18 -0500 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: 31b28e25e9d13a22020d8b7aedc9832c Content-Transfer-Encoding: 7bit Dimitri, Suppose you have LSP going through -A-B-C- and a controller managing node B fails, while the data plane is intact, that is, no data plane alarms are detected. According to your logic such situation can exist only for 90c, because once controller managing node C detects the absence of 3 Path refreshes it will delete the control plane and destroy the service. My question is why do you need the RSVP graceful restart procedures then if they can happen only within 90c time interval - after that there will be nothing to synchronize. What we see and hear in the field, though, that a controller may stay days out of service and then come back and should be capable to synchronize the control state of all LSPs it used to manage before the crash/reboot. And, of course, you MUST maintain data service up and running. Igor ----- Original Message ----- From: "dimitri papadimitriou" To: "Igor Bryskin" Cc: ; "Drake, John E" ; "Zafar Ali (zali)" ; "Igor Bryskin" ; ; "Kim Young Hwa" ; Sent: Monday, October 31, 2005 11:52 AM Subject: Re: Two Drafts for Resilience of Control Plane > igor - > > Igor Bryskin wrote: > > Dimitri, > > > >>igor - my two cents > >> > >>RSVP over time has progressively borrowed mechanisms from "hard-state" > >>protocols, explicit deletion using PathTear is most noticeable and > >>initial example of this evolution ! > >> > >>but in any case, RSVP still relies is on idem-potent soft-states that > >>are flushed when not refreshed after certain time interval (or self- > >>maintained if previously negotiated) this prevents orphans in the > >>network (so unused resources) and provides for resilience - hence there > >>is by no means a need to introduce an additional protocol mechanism to > >>trigger or not such event via the "control plane" - > > > > > > Refreshes are useful mechanism but only between neighbors that maintain > > Hello communication. In this case the absence of Path refreshes is as good > > indication that data plane must be destroyed as received PathTear message. > > the base function of state refresh and usefulness is independent of > hello adjacency maintenance (or any other control channel maintenance) > > > However, when a controller does not receive Path refreshes from a neighbor > > it does not have any control plane communication with, it can assume neither > > a problem in the data plane nor intention to destroy it. > > as the node did not negotiate any channel/node fault recovery (due in > part. to the absence of Hello adjacency with its neighbor) and if no > other independent control channel failure is provided (this is an add-on > of RFC3471/3), the simple absence of refresh is simply intepreted as > "implicit deletion" > > you are mis-interpreting the following sentence of RFC3471 > > " Note that these cases only apply when there are mechanisms to detect > data channel failures independent of control channel failures." > > there is no retro-fit on the use of Refreshes in absence of control > channel failure detection mechanism > > > Hence, as it was > > specified in RFC3471, it *must* maintain both control and data plane states > > throughout the failure. > > - d. > > Igor > > > > > >>btw, the paragraph you mention in RFC3471 does not say "soft state > >>protocols do not work well for non-packet environments" this is your > >>interpretation; > >> > >>ps: you are still free to make use of RFC3472 in case (as you were > >>apparently looking for something else ;-) > >> > >>Igor Bryskin wrote: > >> > >>>John, > >>> > >>> > >>> > >>> > >>>>>States are supposed to be destroyed on explicit signalling > >>>>>message (e.g. PathTear or PathErr with the state removal > >>>>>flag), but not because of the absence of refreshes. > >>>>> > >>> > >>>[JD] > >>> > >>>Igor, > >>> > >>>Just to be clear, we are talking about RSVP here, and RSVP *is* a soft > >>>state protocol. Can you point to any RFC that supports your statements > >>>above? > >>> > >>>IB>> Oh, come on, John. You sound like you've been yourself in a dormant > >>>state for a while :=). We've gone a long way since RFC2205. In RFC3471, > > > > for > > > >>>example, there is a discussion why GMPLS is needed and how is it > > > > different > > > >>>from MPLS. One of the differences is the fact that soft state protocols > > > > do > > > >>>not work well for non-packet environments. Here is from the RDC3471: > >>> > >>> > >>> > >>>9.2. Fault Handling There are two new faults that must be handled > > > > when > > > >>>the control channel is independent of the data channel. In the first, > >>>there is a link or other type of failure that limits the ability of > >>>neighboring nodes to pass control messages. In this situation, > >>>neighboring nodes are unable to exchange control messages for a period > > > > of > > > >>>time. Once communication is restored the underlying signaling > > > > protocol > > > >>>must indicate that the nodes have maintained their state through the > >>>failure.. > >>> > >>>What is more important is the reality of life: The customers simply say > > > > that > > > >>>you cannot destroy a user service (or even force any traffic hits) just > >>>because you have a problem in the control plane. If this does not fit > > > > your > > > >>>soft-state paradigm, than "harden" your protocols or flash them down the > >>>toilet and come with something else if you want our business. After all, > > > > if > > > >>>we provision the services via NMS, we do not have to destroy the > > > > services if > > > >>>we have problems in the management network. It is that simple. > >>> > >>> > >>> > >>>Igor > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>>. > >>> > > > > > > > > > > . > > From owner-ccamp@ops.ietf.org Mon Oct 31 12:18:53 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWdJ7-0003Et-KX for ccamp-archive@megatron.ietf.org; Mon, 31 Oct 2005 12:18:53 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21664 for ; Mon, 31 Oct 2005 12:18:33 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EWdXK-0002Az-Pu for ccamp-archive@ietf.org; Mon, 31 Oct 2005 12:33:35 -0500 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EWdCk-000D2B-QH for ccamp-data@psg.com; Mon, 31 Oct 2005 17:12:18 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [130.76.32.69] (helo=blv-smtpout-01.boeing.com) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EWdCi-000D1e-Ji; Mon, 31 Oct 2005 17:12:16 +0000 Received: from blv-av-01.boeing.com ([192.42.227.216]) by blv-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id JAA26447; Mon, 31 Oct 2005 09:12:16 -0800 (PST) Received: from XCH-SWBH-04.sw.nos.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id j9VHCFH00497; Mon, 31 Oct 2005 09:12:15 -0800 (PST) Received: from XCH-SW-42.sw.nos.boeing.com ([192.79.11.43]) by XCH-SWBH-04.sw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 31 Oct 2005 09:12:15 -0800 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: comments on draft-shiba-ccamp-gmpls-lambda-labels-00.txt Date: Mon, 31 Oct 2005 09:12:14 -0800 Message-ID: <626FC7C6A97381468FB872072AB5DDC836971F@XCH-SW-42.sw.nos.boeing.com> Thread-Topic: comments on draft-shiba-ccamp-gmpls-lambda-labels-00.txt Thread-Index: AcXbIzcAFoI5B5TzS9O/zBGY1cMJbwA6iz0AAIdyNZAAAR14UAAAnn6wAABj8oAAAozZ0A== From: "Drake, John E" To: "Shiba, Sidney" , Cc: "Adrian Farrel" , , X-OriginalArrivalTime: 31 Oct 2005 17:12:15.0324 (UTC) FILETIME=[3DA131C0:01C5DE3E] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 93ea548d5fde6eb89af31f1faab96344 Content-Transfer-Encoding: quoted-printable Sidney 'm not sure you are addressing my concern, unless you are telling me that an LSP can be instantiated along a path that contains WDM systems from *different* vendors. I had been told that, in general, this was not the case. Thanks, John > -----Original Message----- > From: Shiba, Sidney [mailto:sidney.shiba@us.fujitsu.com] > Sent: Monday, October 31, 2005 8:00 AM > To: Drake, John E; dpapadimitriou@psg.com > Cc: Adrian Farrel; richard.rabbat@us.fujitsu.com; ccamp@ops.ietf.org > Subject: RE: comments on draft-shiba-ccamp-gmpls-lambda-labels-00.txt >=20 > John, >=20 > Most of vendor support a standardized wavelength grid > (e.g., ITU-T DWDM wavelength grid given in nominal value). >=20 > If a wavelength chosen for a lightpath setup is not available > in an optical switch, it rejects the operation for resource > not being available. >=20 > Regards, >=20 > Sidney >=20 > > -----Original Message----- > > From: Drake, John E [mailto:John.E.Drake2@boeing.com] > > Sent: Monday, October 31, 2005 9:51 AM > > To: Drake, John E; Shiba, Sidney; dpapadimitriou@psg.com > > Cc: Adrian Farrel; richard.rabbat@us.fujitsu.com; ccamp@ops.ietf.org > > Subject: RE: comments on draft-shiba-ccamp-gmpls-lambda-labels-00.txt > > > > > > Sidney, > > > > There's another issue as well. Having absolute end-end global > > wavelengths is probably insufficient to ensure that an end-end LSP can > > be established successfully, as having a common wavelength > > does not mean > > that equipment from different vendors will interoperate > > correctly in the > > data-plane. > > > > Thanks, > > > > John > > > > > -----Original Message----- > > > From: Drake, John E > > > Sent: Monday, October 31, 2005 7:36 AM > > > To: Shiba, Sidney; dpapadimitriou@psg.com > > > Cc: Adrian Farrel; richard.rabbat@us.fujitsu.com; ccamp@ops.ietf.org > > > Subject: RE: comments on > > draft-shiba-ccamp-gmpls-lambda-labels-00.txt > > > > > > Sidney, > > > > > > But there's nothing in your picture that requires an > > absolute end-end > > > global wavelength. The existing GMPLS solution with relative > > > wavelengths of local significance should work just fine. > > As I said in > > > my previous note, your method precludes combining two or > > more parallel > > > WDM links into a single TE link. > > > > > > Thanks, > > > > > > John > > > > > > > -----Original Message----- > > > > From: Shiba, Sidney [mailto:sidney.shiba@us.fujitsu.com] > > > > Sent: Monday, October 31, 2005 7:25 AM > > > > To: Drake, John E; dpapadimitriou@psg.com > > > > Cc: Adrian Farrel; richard.rabbat@us.fujitsu.com; > > ccamp@ops.ietf.org > > > > Subject: RE: comments on > > draft-shiba-ccamp-gmpls-lambda-labels-00.txt > > > > > > > > Hi John, > > > > > > > > Optical switches based on Wavelength Selective Switch (WSS) > > technology > > > > requires the wavelength information for switching. This technology > > is > > > NOT > > > > wavelength agnostic. > > > > > > > > | | > > > > | wdm | wdm > > > > |2 |2 > > > > --------- --------- > > > > wdm 1| optical |3 wdm 1| optical |3 wdm > > > > --------| switch |------------| switch |--------- > > > > | (WSS) | | (WSS) | > > > > --------- --------- > > > > |4 |4 > > > > | wdm | wdm > > > > | | > > > > > > > > Note that the figure above shows an example of two > > optical switches > > > > interconnect > > > > by a single WDM fiber. In this example, each optical switch can be > > > connect > > > > to 4 > > > > other optical switches. > > > > > > > > As you can see, the optical ports information do not > > provide enough > > > > information > > > > for wavelength switching. > > > > > > > > Hope that clarifies the application requirement. > > > > > > > > Thanks, > > > > > > > > Sidney > > > > > > > > > -----Original Message----- > > > > > From: Drake, John E [mailto:John.E.Drake2@boeing.com] > > > > > Sent: Friday, October 28, 2005 5:33 PM > > > > > To: dpapadimitriou@psg.com; Shiba, Sidney > > > > > Cc: Adrian Farrel; richard.rabbat@us.fujitsu.com; > > ccamp@ops.ietf.org > > > > > Subject: RE: comments on > > > draft-shiba-ccamp-gmpls-lambda-labels-00.txt > > > > > > > > > > > > > > > Hi, > > > > > > > > > > Below is the text of an e-mail is sent to the Ethernet/GMPLS > > mailing > > > > > list. > > > > > > > > > > Upon reflection I am not sure using a real wavelength > > value makes > > > much > > > > > sense. Between a pair of adjacent nodes, there may be > > > > > multiple pairs of > > > > > switch ports in the same TE link that support a given frequency. > > If > > > a > > > > > real wavelength value is used, how do the two nodes agree on > > > > > which pair > > > > > of switch ports to use? > > > > > > > > > > Furthermore, the amount of configuration is the same - you > > > > > still need to > > > > > configure the wavelength of each switch port. > > > > > > > > > > Thanks, > > > > > > > > > > John > > > > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > > =3D=3D=3D=3D > > > > > Adrian, > > > > > > > > > > In the transparent photonic lambda switch case, the labels also > > have > > > > > only local significance. When an LSP is established, the input > > > ports, > > > > > as identified with local labels, are cross-connected to > > the output > > > > > ports, as identified with local labels. > > > > > > > > > > There is just extra configuration to identify, using strictly > > local > > > > > identifiers, the wavelength associated with the all of the > > switch's > > > > > ports, and an additional CAC requirement that the wavelengths of > > the > > > > > input and output ports are the same. > > > > > > > > > > Thanks, > > > > > > > > > > John > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: dimitri papadimitriou [mailto:dpapadimitriou@psg.com] > > > > > > Sent: Thursday, October 27, 2005 10:03 AM > > > > > > To: Shiba, Sidney > > > > > > Cc: dimitri.papadimitriou@alcatel.be; Adrian Farrel; > > > > > > richard.rabbat@us.fujitsu.com; ccamp@ops.ietf.org > > > > > > Subject: Re: comments on > > > > > draft-shiba-ccamp-gmpls-lambda-labels-00.txt > > > > > > > > > > > > shiba - see inline for some additional hints: > > > > > > > > > > > > >>Shiba, Sidney wrote: > > > > > > >> > > > > > > >>>Adrian, Dimitri, > > > > > > >>> > > > > > > >>>Thanks for reviewing these I-D. > > > > > > >>> > > > > > > >>>Wavelength continuity constraint does require the use of > > > > > semanticful > > > > > > >>>label whether it is spectral or index. > > > > > > >> > > > > > > >>=3D> see my reply to adrian on this specific point > > > > > > >> > > > > > > >>>I agree with Dimitri that the > > > > > > >>>wavelength indexing requires document updating each time a > > new > > > > > > >>>spectrum is introduced. > > > > > > >> > > > > > > >>=3D> indeed and in addition it requires updating the = already > > > > > > >>signaled path > > > > > > >> > > > > > > >>>The use of spectral label provides self maintainance, i.e., > > > > > > >>>no need to update any document and the use of the nominal > > value > > > > > > >>>provides a common semantic ground. > > > > > > >> > > > > > > >>=3D> what do you mean by self-maintenance - would you > > provide a > > > > > > >>bit more detail > > > > > > > > > > > > > > [Sidney]What I've meant here was that it was not > > necessary to > > > > > > > update any document when new wavelengths are inventoried. In > > the > > > > > > > case of indexing approach, it would require the > > > > > wavelength indexing > > > > > > > document to be updated with implementation impacts. > > > > > > > > > > > > > > In the case, the nominal value is used, there is no need for > > > > > > > documentation update. > > > > > > > > > > > > ok - what you mean here is that you are going to make > > use of the > > > > > already > > > > > > defined C-Type 2 - what about the specific encoding of the > > > > > value space > > > > > ? > > > > > > > > > > > > >>=3D> now i have a more specific question before being light-up > > > > > > >>how do you know the frequency that you can support ? > > > > > > > > > > > > > > [Sidney] Some new technologies integrate optical switch and > > > > > mux/demux > > > > > > > capabilities, which allows the equipment to know > > the spectrum > > it > > > > > > supports. > > > > > > > > > > > > indeed - but the question is what does happen if the > > > > > "detected" values > > > > > > (during initialization) do not match the nominal values ? you > > > don't > > > > > > initialize then ? > > > > > > > > > > > > >>if these differ from the nominal values how are you going to > > > deal > > > > > with > > > > > > these > > > > > > >>discrepancies ? > > > > > > > > > > > > > > [Sidney] These new technologies uses the nominal value as > > > > > reference. > > > > > We > > > > > > can say > > > > > > > that a lightpath wavelength is identified by its nominal > > value. > > > If > > > > > the > > > > > > equipment > > > > > > > is drifting from this nominal value, it is considered as > > > > > a failure. > > > > > > > > > > > > ok - but if the deviation is such you have overlap - how the > > > control > > > > > > plane is going to be able to detect such failure ? > > > > > > > > > > > > >>this said i am not necessarily sure that having to > > > > > maintain the data > > > > > > plane > > > > > > >>specifics as part of the control plane is really helping > > > > > > >>operations (is this method not just duplicating > > complexity ?) > > > > > > > > > > > > > > [Sidney] The wavelength is WDM specific as much as the SUKLM > > > label > > > > > > encoding > > > > > > > is for SONET. The wavelegth/frequency nominal value > > is used to > > > > > identify > > > > > > the > > > > > > > facilities to cross-connect. > > > > > > > > > > > > there is an equivalence but there is also a major difference, > > the > > > > > > structure is invariant independently of the state of the > > > > > network, with > > > > > > spectral value space you may have labels that become > > unavailable > > > due > > > > > to > > > > > > non-local usage of wavelength in the network > > > > > > > > > > > > hence, there is also no real coupling to the data plane more > > than > > > > > > knowing the type of interface and some generic capabilities > > > > > > > > > > > > >>>I'm not sure if the draft needs to be updated before the > > > > > > >>>face-to-face meeting or after all comments are collected. > > > Please > > > > > > advise. > > > > > > >> > > > > > > >>=3D> suggest to keep discussion on - document update can = be > > > > > > >>performed at a later stage > > > > > > > > > > > > thanks, > > > > > > - dimitri. > > > > > > > > > > > > >>>>-----Original Message----- > > > > > > >>>>From: owner-ccamp@ops.ietf.org > > > > > [mailto:owner-ccamp@ops.ietf.org]On > > > > > > >>>>Behalf Of Adrian Farrel > > > > > > >>>>Sent: Thursday, October 27, 2005 4:45 AM > > > > > > >>>>To: dpapadimitriou@psg.com; > > dimitri.papadimitriou@alcatel.be; > > > > > > >>>>ccamp@ops.ietf.org > > > > > > >>>>Subject: Re: comments on > > > > > > >> > > > > > > >>draft-shiba-ccamp-gmpls-lambda-labels-00.txt > > > > > > >> > > > > > > >>>> > > > > > > >>>>Dimitri, > > > > > > >>>> > > > > > > >>>>Thanks for your work reviewing these recent I-Ds. It is > > > > > > >>>>really valuable > > > > > > >>>>and I'd welcome other people doing similar reviews. > > > > > > >>>> > > > > > > >>>> > > > > > > >>>> > > > > > > >>>>>there is a specific point to be clarified in > > this document: > > > > > > >>>>> > > > > > > >>>>>semanticless vs semanticful label (even here there is a > > > > > distinction > > > > > > >>>>>between spectral vs indexes i.e. using the wavelength > > index) > > > > > > >>>>> > > > > > > >>>>>domain-wide vs link local significant label > > > > > > >>>> > > > > > > >>>>Without being too picky, I think all labels are > > semanticful > > > > > > >>>>otherwise, we > > > > > > >>>>would not know what resource they refered to. > > > > > > >>>> > > > > > > >>>>So the point reduces to whether the scope of the semantics > > > > > > >>>>are link-local > > > > > > >>>>or wider. > > > > > > >>>> > > > > > > >>>> > > > > > > >>>> > > > > > > >>>>>so, the comparison from this perspective with > > TDM labels is > > > > > > >>>> > > > > > > >>>>difficult to > > > > > > >>>> > > > > > > >>>> > > > > > > >>>>>parse, the latter is semanticful but link local > > > > > > >>>>> > > > > > > >>>>>now, i don't specifically see what has changed the late > > 90's, > > > > > early > > > > > > >>>>>y2k's, to have a change in the wavelength label > > definition; > > > > > > >>>> > > > > > > >>>>This is the question I would like to get to the bottom of. > > In > > > > > > >>>>other words: > > > > > > >>>>do we need this function? > > > > > > >>>> > > > > > > >>>>It seems to me that the question being asked is this: > > > > > > >>>> > > > > > > >>>> If I want to compute a path that has some form of > > wavelength > > > > > > >>>> constraints, what information do I need access to? > > > > > > >>>> > > > > > > >>>>Another question might be: > > > > > > >>>> > > > > > > >>>> If I want to signal a path with wavelength constraints > > what > > > > > > >>>> information do I need to include in the > > signaling message? > > > > > > >>>> > > > > > > >>>> > > > > > > >>>>I'd suggest that when we started on GMPLS, we were > > > > > > >> > > > > > > >>enthusiastic about > > > > > > >> > > > > > > >>>>transparent optical networks, but we were not properly > > > > > > >>>>focusing wavelength > > > > > > >>>>constraints because lambda-switching PXCs didn't take off. > > > > > > >>>>Therefore we > > > > > > >>>>didn't examine the requirements for wavelength constraints > > in > > > > > > >>>>routing and > > > > > > >>>>signaling. The authors of this I-D are claiming > > new hardware > > > > > > >>>>requirements > > > > > > >>>>for the same function. > > > > > > >>>> > > > > > > >>>> > > > > > > >>>> > > > > > > >>>>>there are > > > > > > >>>>>several solution possible > > > > > > >>>>> > > > > > > >>>>>- absolute values: the freq. of the wavelength: difficult > > to > > > > > adopt > > > > > > >>>>>because referenced values are nominal and knowing all > > > > > interactions > > > > > > >>>>>between wavelengths this knowledge is at the end > > of little > > > > > > >> > > > > > > >>practical > > > > > > >> > > > > > > >>>>>usage; (introduces implicit ordering) > > > > > > >>>>> > > > > > > >>>>>- indexed values: the # of the wavelength: it does not > > > > > > >> > > > > > > >>provide for a > > > > > > >> > > > > > > >>>>>future proof label space for inst. in case new > > frequencies > > > > > > >>>> > > > > > > >>>>are inserted > > > > > > >>>> > > > > > > >>>> > > > > > > >>>>>in the grid (introduces explicit ordering) > > > > > > >>>>> > > > > > > >>>>>- diff. values e.g. freq spacing starting from a > > reference > > > > > > >>>> > > > > > > >>>>value: pauses > > > > > > >>>> > > > > > > >>>> > > > > > > >>>>>the question of the reference value and does suffer from > > the > > > > > former > > > > > > >>>>>issue (introduces implicit ordering) > > > > > > >>>>> > > > > > > >>>>>- the solution available today - cumbersome in some > > > > > control plane > > > > > > >>>>>operations (e.g. label set translation) and not easy to > > > > > > >>>> > > > > > > >>>>troubleshoot but > > > > > > >>>> > > > > > > >>>> > > > > > > >>>>>independent of any physical consideration > > (spectral), scale > > > to > > > > > any > > > > > > >>>>>number of wavelength per fiber, does not introduce any > > > > > > >> > > > > > > >>ordering, the > > > > > > >> > > > > > > >>>>>most flexible (since allowing each system to maintain its > > > > > specific > > > > > > >>>>>control operations) and the less constraining since > > > maintaining > > > > > the > > > > > > >>>>>control plane operations independent of any data plane > > > > > specifics > > > > > > >>>>> > > > > > > >>>>> > > > > > > >>>> > > > > > > > > >>>> > > > > > >>> > > > > > > >>>ambda-labels > > > > > > >>>-00.txt> > > > > > > >>> > > > > > > >>>. > > > > > > >>> > > > > > > >> > > > > > > > > > > > > > > . > > > > > > > > > > > > > > From owner-ccamp@ops.ietf.org Mon Oct 31 12:24:52 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWdOs-0005KB-Q5 for ccamp-archive@megatron.ietf.org; Mon, 31 Oct 2005 12:24:52 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22021 for ; Mon, 31 Oct 2005 12:24:30 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EWdd6-0002YC-6t for ccamp-archive@ietf.org; Mon, 31 Oct 2005 12:39:32 -0500 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EWdHu-000DMl-Bz for ccamp-data@psg.com; Mon, 31 Oct 2005 17:17:38 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-4.8 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from localhost ([127.0.0.1]) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EWdHs-000DMI-F0; Mon, 31 Oct 2005 17:17:37 +0000 Message-ID: <436651AE.8010701@psg.com> Date: Mon, 31 Oct 2005 18:17:34 +0100 From: dimitri papadimitriou Reply-To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.11) Gecko/20050728 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Shiba, Sidney" CC: "Drake, John E" , Adrian Farrel , richard.rabbat@us.fujitsu.com, ccamp@ops.ietf.org Subject: Re: comments on draft-shiba-ccamp-gmpls-lambda-labels-00.txt References: <7CA873794E52904EAA980A074B076779B17C61@rchemx01.fnc.net.local> In-Reply-To: <7CA873794E52904EAA980A074B076779B17C61@rchemx01.fnc.net.local> 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: b4be0d55bab88df9d21005ced9551e26 Content-Transfer-Encoding: 7bit sidney - short note to clarify the comparison with SONET/SDH Shiba, Sidney wrote: > John, > > Comments inline: > > >>-----Original Message----- >>From: Drake, John E [mailto:John.E.Drake2@boeing.com] >>Sent: Monday, October 31, 2005 9:36 AM >>To: Shiba, Sidney; dpapadimitriou@psg.com >>Cc: Adrian Farrel; richard.rabbat@us.fujitsu.com; ccamp@ops.ietf.org >>Subject: RE: comments on draft-shiba-ccamp-gmpls-lambda-labels-00.txt >> >> >>Sidney, >> >>But there's nothing in your picture that requires an absolute end-end >>global wavelength. The existing GMPLS solution with relative >>wavelengths of local significance should work just fine. > > > [Sidney] Sorry for the missing info. The optical switch is an all optical > switch (i.e., no OEO is necessary). The wavelength continuity constraint > indicates which wavelength (nominal value) all the optical switches > traversed by the lightpath needs to cross-connect. > > >>As I said in my previous note, your method precludes combining two or >>more parallel WDM links into a single TE link. > > [Sidney] Note the Label is complemented by the interface id of the link. > > I think this is the same approach used for parallel SONET OCn datalinks > where the label identifies a time-slot and interface id identifies the > datalink chosen for the connection. in RFC3946 the label does not include the interface id; the latter is part of the IF_ID RSVP_HOP TLV if you introduce a spectral wavelength label you will not be able anymore to correlate into the same (unbundled) link two data links having the same nominal wavelength; note: introducing "spectral label" would introduce a similar issue present in SDH/SONET where you can not correlate two or more "data links" in the same (unbundled) TE link with a resulting overlapping set of timeslots; however, the major difference compared with wavelength switching is that in SONET/SDH you need to construct very particular configurations for reaching this kind of restriction; also there is no real operational issue since so far with this simply because each timeslot in a given section is spatially equivalent and has identical TE properties; the situation is completely different in a wavelength switched environment >>Thanks, >> >>John >> >> >>>-----Original Message----- >>>From: Shiba, Sidney [mailto:sidney.shiba@us.fujitsu.com] >>>Sent: Monday, October 31, 2005 7:25 AM >>>To: Drake, John E; dpapadimitriou@psg.com >>>Cc: Adrian Farrel; richard.rabbat@us.fujitsu.com; ccamp@ops.ietf.org >>>Subject: RE: comments on >> >>draft-shiba-ccamp-gmpls-lambda-labels-00.txt >> >>>Hi John, >>> >>>Optical switches based on Wavelength Selective Switch (WSS) >> >>technology >> >>>requires the wavelength information for switching. This >> >>technology is >>NOT >> >>>wavelength agnostic. >>> >>> | | >>> | wdm | wdm >>> |2 |2 >>> --------- --------- >>> wdm 1| optical |3 wdm 1| optical |3 wdm >>> --------| switch |------------| switch |--------- >>> | (WSS) | | (WSS) | >>> --------- --------- >>> |4 |4 >>> | wdm | wdm >>> | | >>> >>>Note that the figure above shows an example of two optical switches >>>interconnect >>>by a single WDM fiber. In this example, each optical switch can be >> >>connect >> >>>to 4 >>>other optical switches. >>> >>>As you can see, the optical ports information do not provide enough >>>information >>>for wavelength switching. >>> >>>Hope that clarifies the application requirement. >>> >>>Thanks, >>> >>>Sidney >>> >>> >>>>-----Original Message----- >>>>From: Drake, John E [mailto:John.E.Drake2@boeing.com] >>>>Sent: Friday, October 28, 2005 5:33 PM >>>>To: dpapadimitriou@psg.com; Shiba, Sidney >>>>Cc: Adrian Farrel; richard.rabbat@us.fujitsu.com; >> >>ccamp@ops.ietf.org >> >>>>Subject: RE: comments on >> >>draft-shiba-ccamp-gmpls-lambda-labels-00.txt >> >>>> >>>>Hi, >>>> >>>>Below is the text of an e-mail is sent to the >> >>Ethernet/GMPLS mailing >> >>>>list. >>>> >>>>Upon reflection I am not sure using a real wavelength value makes >> >>much >> >>>>sense. Between a pair of adjacent nodes, there may be >>>>multiple pairs of >>>>switch ports in the same TE link that support a given >> >>frequency. If >>a >> >>>>real wavelength value is used, how do the two nodes agree on >>>>which pair >>>>of switch ports to use? >>>> >>>>Furthermore, the amount of configuration is the same - you >>>>still need to >>>>configure the wavelength of each switch port. >>>> >>>>Thanks, >>>> >>>>John >>>>============================================================== >>>>========== >>>>==== >>>>Adrian, >>>> >>>>In the transparent photonic lambda switch case, the >> >>labels also have >> >>>>only local significance. When an LSP is established, the input >> >>ports, >> >>>>as identified with local labels, are cross-connected to the output >>>>ports, as identified with local labels. >>>> >>>>There is just extra configuration to identify, using >> >>strictly local >> >>>>identifiers, the wavelength associated with the all of >> >>the switch's >> >>>>ports, and an additional CAC requirement that the >> >>wavelengths of the >> >>>>input and output ports are the same. >>>> >>>>Thanks, >>>> >>>>John >>>> >>>> >>>> >>>>>-----Original Message----- >>>>>From: dimitri papadimitriou [mailto:dpapadimitriou@psg.com] >>>>>Sent: Thursday, October 27, 2005 10:03 AM >>>>>To: Shiba, Sidney >>>>>Cc: dimitri.papadimitriou@alcatel.be; Adrian Farrel; >>>>>richard.rabbat@us.fujitsu.com; ccamp@ops.ietf.org >>>>>Subject: Re: comments on >>>> >>>>draft-shiba-ccamp-gmpls-lambda-labels-00.txt >>>> >>>>>shiba - see inline for some additional hints: >>>>> >>>>> >>>>>>>Shiba, Sidney wrote: >>>>>>> >>>>>>> >>>>>>>>Adrian, Dimitri, >>>>>>>> >>>>>>>>Thanks for reviewing these I-D. >>>>>>>> >>>>>>>>Wavelength continuity constraint does require the use of >>>> >>>>semanticful >>>> >>>>>>>>label whether it is spectral or index. >>>>>>> >>>>>>>=> see my reply to adrian on this specific point >>>>>>> >>>>>>> >>>>>>>>I agree with Dimitri that the >>>>>>>>wavelength indexing requires document updating each >> >>time a new >> >>>>>>>>spectrum is introduced. >>>>>>> >>>>>>>=> indeed and in addition it requires updating the already >>>>>>>signaled path >>>>>>> >>>>>>> >>>>>>>>The use of spectral label provides self maintainance, i.e., >>>>>>>>no need to update any document and the use of the >> >>nominal value >> >>>>>>>>provides a common semantic ground. >>>>>>> >>>>>>>=> what do you mean by self-maintenance - would you provide a >>>>>>>bit more detail >>>>>> >>>>>>[Sidney]What I've meant here was that it was not necessary to >>>>>>update any document when new wavelengths are >> >>inventoried. In the >> >>>>>>case of indexing approach, it would require the >>>> >>>>wavelength indexing >>>> >>>>>>document to be updated with implementation impacts. >>>>>> >>>>>>In the case, the nominal value is used, there is no need for >>>>>>documentation update. >>>>> >>>>>ok - what you mean here is that you are going to make use of the >>>> >>>>already >>>> >>>>>defined C-Type 2 - what about the specific encoding of the >>>> >>>>value space >>>>? >>>> >>>>>>>=> now i have a more specific question before being light-up >>>>>>>how do you know the frequency that you can support ? >>>>>> >>>>>>[Sidney] Some new technologies integrate optical switch and >>>> >>>>mux/demux >>>> >>>>>>capabilities, which allows the equipment to know the >> >>spectrum it >> >>>>>supports. >>>>> >>>>>indeed - but the question is what does happen if the >>>> >>>>"detected" values >>>> >>>>>(during initialization) do not match the nominal values ? you >> >>don't >> >>>>>initialize then ? >>>>> >>>>> >>>>>>>if these differ from the nominal values how are you going to >> >>deal >> >>>>with >>>> >>>>>these >>>>> >>>>>>>discrepancies ? >>>>>> >>>>>>[Sidney] These new technologies uses the nominal value as >>>> >>>>reference. >>>>We >>>> >>>>>can say >>>>> >>>>>>that a lightpath wavelength is identified by its >> >>nominal value. >>If >> >>>>the >>>> >>>>>equipment >>>>> >>>>>>is drifting from this nominal value, it is considered as >>>> >>>>a failure. >>>> >>>>>ok - but if the deviation is such you have overlap - how the >> >>control >> >>>>>plane is going to be able to detect such failure ? >>>>> >>>>> >>>>>>>this said i am not necessarily sure that having to >>>> >>>>maintain the data >>>> >>>>>plane >>>>> >>>>>>>specifics as part of the control plane is really helping >>>>>>>operations (is this method not just duplicating complexity ?) >>>>>> >>>>>>[Sidney] The wavelength is WDM specific as much as the SUKLM >> >>label >> >>>>>encoding >>>>> >>>>>>is for SONET. The wavelegth/frequency nominal value is used to >>>> >>>>identify >>>> >>>>>the >>>>> >>>>>>facilities to cross-connect. >>>>> >>>>>there is an equivalence but there is also a major >> >>difference, the >> >>>>>structure is invariant independently of the state of the >>>> >>>>network, with >>>> >>>>>spectral value space you may have labels that become unavailable >> >>due >> >>>>to >>>> >>>>>non-local usage of wavelength in the network >>>>> >>>>>hence, there is also no real coupling to the data plane >> >>more than >> >>>>>knowing the type of interface and some generic capabilities >>>>> >>>>> >>>>>>>>I'm not sure if the draft needs to be updated before the >>>>>>>>face-to-face meeting or after all comments are collected. >> >>Please >> >>>>>advise. >>>>> >>>>>>>=> suggest to keep discussion on - document update can be >>>>>>>performed at a later stage >>>>> >>>>>thanks, >>>>>- dimitri. >>>>> >>>>> >>>>>>>>>-----Original Message----- >>>>>>>>>From: owner-ccamp@ops.ietf.org >>>> >>>>[mailto:owner-ccamp@ops.ietf.org]On >>>> >>>>>>>>>Behalf Of Adrian Farrel >>>>>>>>>Sent: Thursday, October 27, 2005 4:45 AM >>>>>>>>>To: dpapadimitriou@psg.com; >> >>dimitri.papadimitriou@alcatel.be; >> >>>>>>>>>ccamp@ops.ietf.org >>>>>>>>>Subject: Re: comments on >>>>>>> >>>>>>>draft-shiba-ccamp-gmpls-lambda-labels-00.txt >>>>>>> >>>>>>> >>>>>>>>>Dimitri, >>>>>>>>> >>>>>>>>>Thanks for your work reviewing these recent I-Ds. It is >>>>>>>>>really valuable >>>>>>>>>and I'd welcome other people doing similar reviews. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>there is a specific point to be clarified in this document: >>>>>>>>>> >>>>>>>>>>semanticless vs semanticful label (even here there is a >>>> >>>>distinction >>>> >>>>>>>>>>between spectral vs indexes i.e. using the >> >>wavelength index) >> >>>>>>>>>>domain-wide vs link local significant label >>>>>>>>> >>>>>>>>>Without being too picky, I think all labels are semanticful >>>>>>>>>otherwise, we >>>>>>>>>would not know what resource they refered to. >>>>>>>>> >>>>>>>>>So the point reduces to whether the scope of the semantics >>>>>>>>>are link-local >>>>>>>>>or wider. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>so, the comparison from this perspective with TDM labels is >>>>>>>>> >>>>>>>>>difficult to >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>parse, the latter is semanticful but link local >>>>>>>>>> >>>>>>>>>>now, i don't specifically see what has changed the >> >>late 90's, >> >>>>early >>>> >>>>>>>>>>y2k's, to have a change in the wavelength label definition; >>>>>>>>> >>>>>>>>>This is the question I would like to get to the >> >>bottom of. In >> >>>>>>>>>other words: >>>>>>>>>do we need this function? >>>>>>>>> >>>>>>>>>It seems to me that the question being asked is this: >>>>>>>>> >>>>>>>>> If I want to compute a path that has some form of >> >>wavelength >> >>>>>>>>> constraints, what information do I need access to? >>>>>>>>> >>>>>>>>>Another question might be: >>>>>>>>> >>>>>>>>> If I want to signal a path with wavelength >> >>constraints what >> >>>>>>>>> information do I need to include in the signaling message? >>>>>>>>> >>>>>>>>> >>>>>>>>>I'd suggest that when we started on GMPLS, we were >>>>>>> >>>>>>>enthusiastic about >>>>>>> >>>>>>> >>>>>>>>>transparent optical networks, but we were not properly >>>>>>>>>focusing wavelength >>>>>>>>>constraints because lambda-switching PXCs didn't take off. >>>>>>>>>Therefore we >>>>>>>>>didn't examine the requirements for wavelength >> >>constraints in >> >>>>>>>>>routing and >>>>>>>>>signaling. The authors of this I-D are claiming new hardware >>>>>>>>>requirements >>>>>>>>>for the same function. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>there are >>>>>>>>>>several solution possible >>>>>>>>>> >>>>>>>>>>- absolute values: the freq. of the wavelength: >> >>difficult to >> >>>>adopt >>>> >>>>>>>>>>because referenced values are nominal and knowing all >>>> >>>>interactions >>>> >>>>>>>>>>between wavelengths this knowledge is at the end of little >>>>>>> >>>>>>>practical >>>>>>> >>>>>>> >>>>>>>>>>usage; (introduces implicit ordering) >>>>>>>>>> >>>>>>>>>>- indexed values: the # of the wavelength: it does not >>>>>>> >>>>>>>provide for a >>>>>>> >>>>>>> >>>>>>>>>>future proof label space for inst. in case new frequencies >>>>>>>>> >>>>>>>>>are inserted >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>in the grid (introduces explicit ordering) >>>>>>>>>> >>>>>>>>>>- diff. values e.g. freq spacing starting from a reference >>>>>>>>> >>>>>>>>>value: pauses >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>the question of the reference value and does >> >>suffer from the >> >>>>former >>>> >>>>>>>>>>issue (introduces implicit ordering) >>>>>>>>>> >>>>>>>>>>- the solution available today - cumbersome in some >>>> >>>>control plane >>>> >>>>>>>>>>operations (e.g. label set translation) and not easy to >>>>>>>>> >>>>>>>>>troubleshoot but >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>independent of any physical consideration (spectral), scale >> >>to >> >>>>any >>>> >>>>>>>>>>number of wavelength per fiber, does not introduce any >>>>>>> >>>>>>>ordering, the >>>>>>> >>>>>>> >>>>>>>>>>most flexible (since allowing each system to maintain its >>>> >>>>specific >>>> >>>>>>>>>>control operations) and the less constraining since >> >>maintaining >> >>>>the >>>> >>>>>>>>>>control plane operations independent of any data plane >>>> >>>>specifics >>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>ambda-labels >>>>>>>>-00.txt> >>>>>>>> >>>>>>>>. >>>>>>>> >>>>>>> >>>>>>. >>>>>> >>>> > > > . > From owner-ccamp@ops.ietf.org Mon Oct 31 12:38:07 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWdbi-0007va-6P for ccamp-archive@megatron.ietf.org; Mon, 31 Oct 2005 12:38:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22956 for ; Mon, 31 Oct 2005 12:37:45 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EWdpv-0003KY-Ab for ccamp-archive@ietf.org; Mon, 31 Oct 2005 12:52:48 -0500 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EWdSm-000E8p-2f for ccamp-data@psg.com; Mon, 31 Oct 2005 17:28:52 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=3.1.0 Received: from [217.32.164.151] (helo=smtp4.smtp.bt.com) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EWdSj-000E7y-9L for ccamp@ops.ietf.org; Mon, 31 Oct 2005 17:28:49 +0000 Received: from i2km98-ukbr.domain1.systemhost.net ([193.113.197.85]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 31 Oct 2005 17:28:42 +0000 Received: from i2km07-ukbr.domain1.systemhost.net ([193.113.197.26]) by i2km98-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Mon, 31 Oct 2005 17:28:42 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.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: comments on draft-shiba-ccamp-gmpls-lambda-labels-00.txt Date: Mon, 31 Oct 2005 17:28:41 -0000 Message-ID: <0536FC9B908BEC4597EE721BE6A3538912275969@i2km07-ukbr.domain1.systemhost.net> Thread-Topic: comments on draft-shiba-ccamp-gmpls-lambda-labels-00.txt Thread-Index: AcXeNcpyWStaVYm1SxaXOoXTA/t1xQACpj7g From: To: , , , Cc: , , X-OriginalArrivalTime: 31 Oct 2005 17:28:42.0459 (UTC) FILETIME=[8A020AB0:01C5DE40] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.3 (/) X-Scan-Signature: 6e8a3b85ef670172081194f0b0f68e6f Content-Transfer-Encoding: quoted-printable Absolutely right.....'space' is always a consideration for 1 dimension of the labelling of resource partitions in the co-cs mode....once space has been labelled then we need to know whether we are dealing with a 'freq' or 'time' label next (there is actually a 3rd possibility wrt 'amplitutde' labelling....code division muxing). And to be of practical use, these has to be an implicit assumed binding of known bit rate to this. regards, neil > -----Original Message----- > From: owner-ccamp@ops.ietf.org=20 > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Payam Torab > Sent: 31 October 2005 16:12 > To: 'Drake, John E'; 'Shiba, Sidney'; dpapadimitriou@psg.com > Cc: 'Adrian Farrel'; richard.rabbat@us.fujitsu.com; ccamp@ops.ietf.org > Subject: RE: comments on draft-shiba-ccamp-gmpls-lambda-labels-00.txt >=20 >=20 > John- >=20 > Obviously the benefits or harms of giving a global meaning to=20 > a lambda label requires study, but your particular example is=20 > not a good one: If one really wants to have a preference for=20 > a specific wavelength channel among multiple parallel=20 > channels of the same wavelength, bundling should not be=20 > exercised in the first place. >=20 > Thanks, > Payam >=20 > -----Original Message----- > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On > Behalf Of Drake, John E > Sent: Monday, October 31, 2005 10:36 AM > To: Shiba, Sidney; dpapadimitriou@psg.com > Cc: Adrian Farrel; richard.rabbat@us.fujitsu.com; ccamp@ops.ietf.org > Subject: RE: comments on draft-shiba-ccamp-gmpls-lambda-labels-00.txt >=20 >=20 > Sidney, >=20 > But there's nothing in your picture that requires an absolute=20 > end-end global wavelength. The existing GMPLS solution with=20 > relative wavelengths of local significance should work just=20 > fine. As I said in my previous note, your method precludes=20 > combining two or more parallel WDM links into a single TE link. >=20 > Thanks, >=20 > John >=20 > > -----Original Message----- > > From: Shiba, Sidney [mailto:sidney.shiba@us.fujitsu.com] > > Sent: Monday, October 31, 2005 7:25 AM > > To: Drake, John E; dpapadimitriou@psg.com > > Cc: Adrian Farrel; richard.rabbat@us.fujitsu.com; ccamp@ops.ietf.org > > Subject: RE: comments on=20 > draft-shiba-ccamp-gmpls-lambda-labels-00.txt > >=20 > > Hi John, > >=20 > > Optical switches based on Wavelength Selective Switch (WSS)=20 > technology=20 > > requires the wavelength information for switching. This=20 > technology is > NOT > > wavelength agnostic. > >=20 > > | | > > | wdm | wdm > > |2 |2 > > --------- --------- > > wdm 1| optical |3 wdm 1| optical |3 wdm > > --------| switch |------------| switch |--------- > > | (WSS) | | (WSS) | > > --------- --------- > > |4 |4 > > | wdm | wdm > > | | > >=20 > > Note that the figure above shows an example of two optical switches=20 > > interconnect by a single WDM fiber. In this example, each optical=20 > > switch can be > connect > > to 4 > > other optical switches. > >=20 > > As you can see, the optical ports information do not provide enough=20 > > information for wavelength switching. > >=20 > > Hope that clarifies the application requirement. > >=20 > > Thanks, > >=20 > > Sidney > >=20 > > > -----Original Message----- > > > From: Drake, John E [mailto:John.E.Drake2@boeing.com] > > > Sent: Friday, October 28, 2005 5:33 PM > > > To: dpapadimitriou@psg.com; Shiba, Sidney > > > Cc: Adrian Farrel; richard.rabbat@us.fujitsu.com;=20 > ccamp@ops.ietf.org > > > Subject: RE: comments on > draft-shiba-ccamp-gmpls-lambda-labels-00.txt > > > > > > > > > Hi, > > > > > > Below is the text of an e-mail is sent to the=20 > Ethernet/GMPLS mailing=20 > > > list. > > > > > > Upon reflection I am not sure using a real wavelength value makes > much > > > sense. Between a pair of adjacent nodes, there may be multiple=20 > > > pairs of switch ports in the same TE link that support a given=20 > > > frequency. If > a > > > real wavelength value is used, how do the two nodes agree=20 > on which=20 > > > pair of switch ports to use? > > > > > > Furthermore, the amount of configuration is the same - you still=20 > > > need to configure the wavelength of each switch port. > > > > > > Thanks, > > > > > > John=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=3D=3D=3D=3D=3D=3D=3D=3D > > > =3D=3D=3D=3D > > > Adrian, > > > > > > In the transparent photonic lambda switch case, the=20 > labels also have=20 > > > only local significance. When an LSP is established, the input > ports, > > > as identified with local labels, are cross-connected to=20 > the output=20 > > > ports, as identified with local labels. > > > > > > There is just extra configuration to identify, using=20 > strictly local=20 > > > identifiers, the wavelength associated with the all of=20 > the switch's=20 > > > ports, and an additional CAC requirement that the=20 > wavelengths of the=20 > > > input and output ports are the same. > > > > > > Thanks, > > > > > > John > > > > > > > > > > -----Original Message----- > > > > From: dimitri papadimitriou [mailto:dpapadimitriou@psg.com] > > > > Sent: Thursday, October 27, 2005 10:03 AM > > > > To: Shiba, Sidney > > > > Cc: dimitri.papadimitriou@alcatel.be; Adrian Farrel;=20 > > > > richard.rabbat@us.fujitsu.com; ccamp@ops.ietf.org > > > > Subject: Re: comments on > > > draft-shiba-ccamp-gmpls-lambda-labels-00.txt > > > > > > > > shiba - see inline for some additional hints: > > > > > > > > >>Shiba, Sidney wrote: > > > > >> > > > > >>>Adrian, Dimitri, > > > > >>> > > > > >>>Thanks for reviewing these I-D. > > > > >>> > > > > >>>Wavelength continuity constraint does require the use of > > > semanticful > > > > >>>label whether it is spectral or index. > > > > >> > > > > >>=3D> see my reply to adrian on this specific point > > > > >> > > > > >>>I agree with Dimitri that the > > > > >>>wavelength indexing requires document updating each=20 > time a new=20 > > > > >>>spectrum is introduced. > > > > >> > > > > >>=3D> indeed and in addition it requires updating the already=20 > > > > >>signaled path > > > > >> > > > > >>>The use of spectral label provides self=20 > maintainance, i.e., no=20 > > > > >>>need to update any document and the use of the nominal value=20 > > > > >>>provides a common semantic ground. > > > > >> > > > > >>=3D> what do you mean by self-maintenance - would you provide = a=20 > > > > >>bit more detail > > > > > > > > > > [Sidney]What I've meant here was that it was not necessary to=20 > > > > > update any document when new wavelengths are=20 > inventoried. In the=20 > > > > > case of indexing approach, it would require the > > > wavelength indexing > > > > > document to be updated with implementation impacts. > > > > > > > > > > In the case, the nominal value is used, there is no need for=20 > > > > > documentation update. > > > > > > > > ok - what you mean here is that you are going to make use of the > > > already > > > > defined C-Type 2 - what about the specific encoding of the > > > value space > > > ? > > > > > > > > >>=3D> now i have a more specific question before being=20 > light-up how=20 > > > > >>do you know the frequency that you can support ? > > > > > > > > > > [Sidney] Some new technologies integrate optical switch and > > > mux/demux > > > > > capabilities, which allows the equipment to know the=20 > spectrum it > > > > supports. > > > > > > > > indeed - but the question is what does happen if the > > > "detected" values > > > > (during initialization) do not match the nominal values ? you > don't > > > > initialize then ? > > > > > > > > >>if these differ from the nominal values how are you going to > deal > > > with > > > > these > > > > >>discrepancies ? > > > > > > > > > > [Sidney] These new technologies uses the nominal value as > > > reference. > > > We > > > > can say > > > > > that a lightpath wavelength is identified by its=20 > nominal value. > If > > > the > > > > equipment > > > > > is drifting from this nominal value, it is considered as > > > a failure. > > > > > > > > ok - but if the deviation is such you have overlap - how the > control > > > > plane is going to be able to detect such failure ? > > > > > > > > >>this said i am not necessarily sure that having to > > > maintain the data > > > > plane > > > > >>specifics as part of the control plane is really helping=20 > > > > >>operations (is this method not just duplicating complexity ?) > > > > > > > > > > [Sidney] The wavelength is WDM specific as much as the SUKLM > label > > > > encoding > > > > > is for SONET. The wavelegth/frequency nominal value is used to > > > identify > > > > the > > > > > facilities to cross-connect. > > > > > > > > there is an equivalence but there is also a major=20 > difference, the=20 > > > > structure is invariant independently of the state of the > > > network, with > > > > spectral value space you may have labels that become unavailable > due > > > to > > > > non-local usage of wavelength in the network > > > > > > > > hence, there is also no real coupling to the data plane=20 > more than=20 > > > > knowing the type of interface and some generic capabilities > > > > > > > > >>>I'm not sure if the draft needs to be updated before the=20 > > > > >>>face-to-face meeting or after all comments are collected. > Please > > > > advise. > > > > >> > > > > >>=3D> suggest to keep discussion on - document update can be=20 > > > > >>performed at a later stage > > > > > > > > thanks, > > > > - dimitri. > > > > > > > > >>>>-----Original Message----- > > > > >>>>From: owner-ccamp@ops.ietf.org > > > [mailto:owner-ccamp@ops.ietf.org]On > > > > >>>>Behalf Of Adrian Farrel > > > > >>>>Sent: Thursday, October 27, 2005 4:45 AM > > > > >>>>To: dpapadimitriou@psg.com;=20 > dimitri.papadimitriou@alcatel.be;=20 > > > > >>>>ccamp@ops.ietf.org > > > > >>>>Subject: Re: comments on > > > > >> > > > > >>draft-shiba-ccamp-gmpls-lambda-labels-00.txt > > > > >> > > > > >>>> > > > > >>>>Dimitri, > > > > >>>> > > > > >>>>Thanks for your work reviewing these recent I-Ds.=20 > It is really=20 > > > > >>>>valuable and I'd welcome other people doing similar reviews. > > > > >>>> > > > > >>>> > > > > >>>> > > > > >>>>>there is a specific point to be clarified in this document: > > > > >>>>> > > > > >>>>>semanticless vs semanticful label (even here there is a > > > distinction > > > > >>>>>between spectral vs indexes i.e. using the=20 > wavelength index) > > > > >>>>> > > > > >>>>>domain-wide vs link local significant label > > > > >>>> > > > > >>>>Without being too picky, I think all labels are semanticful=20 > > > > >>>>otherwise, we would not know what resource they refered to. > > > > >>>> > > > > >>>>So the point reduces to whether the scope of the=20 > semantics are=20 > > > > >>>>link-local or wider. > > > > >>>> > > > > >>>> > > > > >>>> > > > > >>>>>so, the comparison from this perspective with TDM labels is > > > > >>>> > > > > >>>>difficult to > > > > >>>> > > > > >>>> > > > > >>>>>parse, the latter is semanticful but link local > > > > >>>>> > > > > >>>>>now, i don't specifically see what has changed the=20 > late 90's, > > > early > > > > >>>>>y2k's, to have a change in the wavelength label definition; > > > > >>>> > > > > >>>>This is the question I would like to get to the=20 > bottom of. In=20 > > > > >>>>other words: do we need this function? > > > > >>>> > > > > >>>>It seems to me that the question being asked is this: > > > > >>>> > > > > >>>> If I want to compute a path that has some form of=20 > wavelength =20 > > > > >>>> constraints, what information do I need access to? > > > > >>>> > > > > >>>>Another question might be: > > > > >>>> > > > > >>>> If I want to signal a path with wavelength=20 > constraints what =20 > > > > >>>> information do I need to include in the signaling message? > > > > >>>> > > > > >>>> > > > > >>>>I'd suggest that when we started on GMPLS, we were > > > > >> > > > > >>enthusiastic about > > > > >> > > > > >>>>transparent optical networks, but we were not properly=20 > > > > >>>>focusing wavelength constraints because=20 > lambda-switching PXCs=20 > > > > >>>>didn't take off. Therefore we > > > > >>>>didn't examine the requirements for wavelength=20 > constraints in > > > > >>>>routing and > > > > >>>>signaling. The authors of this I-D are claiming new hardware > > > > >>>>requirements > > > > >>>>for the same function. > > > > >>>> > > > > >>>> > > > > >>>> > > > > >>>>>there are > > > > >>>>>several solution possible > > > > >>>>> > > > > >>>>>- absolute values: the freq. of the wavelength:=20 > difficult to > > > adopt > > > > >>>>>because referenced values are nominal and knowing all > > > interactions > > > > >>>>>between wavelengths this knowledge is at the end of little > > > > >> > > > > >>practical > > > > >> > > > > >>>>>usage; (introduces implicit ordering) > > > > >>>>> > > > > >>>>>- indexed values: the # of the wavelength: it does not > > > > >> > > > > >>provide for a > > > > >> > > > > >>>>>future proof label space for inst. in case new frequencies > > > > >>>> > > > > >>>>are inserted > > > > >>>> > > > > >>>> > > > > >>>>>in the grid (introduces explicit ordering) > > > > >>>>> > > > > >>>>>- diff. values e.g. freq spacing starting from a reference > > > > >>>> > > > > >>>>value: pauses > > > > >>>> > > > > >>>> > > > > >>>>>the question of the reference value and does=20 > suffer from the > > > former > > > > >>>>>issue (introduces implicit ordering) > > > > >>>>> > > > > >>>>>- the solution available today - cumbersome in some > > > control plane > > > > >>>>>operations (e.g. label set translation) and not easy to > > > > >>>> > > > > >>>>troubleshoot but > > > > >>>> > > > > >>>> > > > > >>>>>independent of any physical consideration (spectral), scale > to > > > any > > > > >>>>>number of wavelength per fiber, does not introduce any > > > > >> > > > > >>ordering, the > > > > >> > > > > >>>>>most flexible (since allowing each system to maintain its > > > specific > > > > >>>>>control operations) and the less constraining since > maintaining > > > the > > > > >>>>>control plane operations independent of any data plane > > > specifics > > > > >>>>> > > > > >>>>> > > > > >>>> > > > >=20 > >>>> > > >>> > > > >>>ambda-labels > > > >>>-00.txt> > > > >>> > > > >>>. > > > >>> > > > >> > > > > > > > > . > > > > > > From owner-ccamp@ops.ietf.org Mon Oct 31 12:45:21 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWdii-00010o-IU for ccamp-archive@megatron.ietf.org; Mon, 31 Oct 2005 12:45:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23306 for ; Mon, 31 Oct 2005 12:44:59 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EWdwv-0003zf-BF for ccamp-archive@ietf.org; Mon, 31 Oct 2005 13:00:02 -0500 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EWdby-000Ek3-42 for ccamp-data@psg.com; Mon, 31 Oct 2005 17:38:22 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [168.127.0.56] (helo=fncnmp03.fnc.fujitsu.com) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EWdbw-000Ejq-7k for ccamp@ops.ietf.org; Mon, 31 Oct 2005 17:38:20 +0000 Received: from rchemx01.fnc.net.local (167.254.101.101) by fncnmp03.fnc.fujitsu.com with ESMTP; 31 Oct 2005 11:38:11 -0600 X-IronPort-AV: i="3.97,270,1125896400"; d="scan'208"; a="15944143:sNHT30899124" 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: comments on draft-shiba-ccamp-gmpls-lambda-labels-00.txt Date: Mon, 31 Oct 2005 11:38:10 -0600 Message-ID: <7CA873794E52904EAA980A074B076779B17C65@rchemx01.fnc.net.local> Thread-Topic: comments on draft-shiba-ccamp-gmpls-lambda-labels-00.txt Thread-Index: AcXbIzcAFoI5B5TzS9O/zBGY1cMJbwA6iz0AAIdyNZAAAR14UAAAnn6wAABj8oAAAozZ0AAAuniQ From: "Shiba, Sidney" To: "Drake, John E" , Cc: "Adrian Farrel" , , Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: c3d1fcc6feccbcc611b6c309986f05f7 Content-Transfer-Encoding: quoted-printable John, When multi-vendor configuration is involved, regenerators (e.g, G.709 OEO conversion) are usually used to interface two systems. In this case, tunable laser regenerators need to be tuned to the desired wavelength. Hope that helps to identify the interoperability requirement. BTW, the draft provides some "requirements" related to Label Set. I'm=20 curious to know how this is addressed with local significance labels. Thanks, Sidney > -----Original Message----- > From: Drake, John E [mailto:John.E.Drake2@boeing.com] > Sent: Monday, October 31, 2005 11:12 AM > To: Shiba, Sidney; dpapadimitriou@psg.com > Cc: Adrian Farrel; richard.rabbat@us.fujitsu.com; ccamp@ops.ietf.org > Subject: RE: comments on draft-shiba-ccamp-gmpls-lambda-labels-00.txt >=20 >=20 > Sidney >=20 > 'm not sure you are addressing my concern, unless you are telling me > that an LSP can be instantiated along a path that contains WDM systems > from *different* vendors. I had been told that, in general, this was > not the case. >=20 > Thanks, >=20 > John >=20 > > -----Original Message----- > > From: Shiba, Sidney [mailto:sidney.shiba@us.fujitsu.com] > > Sent: Monday, October 31, 2005 8:00 AM > > To: Drake, John E; dpapadimitriou@psg.com > > Cc: Adrian Farrel; richard.rabbat@us.fujitsu.com; ccamp@ops.ietf.org > > Subject: RE: comments on=20 > draft-shiba-ccamp-gmpls-lambda-labels-00.txt > >=20 > > John, > >=20 > > Most of vendor support a standardized wavelength grid > > (e.g., ITU-T DWDM wavelength grid given in nominal value). > >=20 > > If a wavelength chosen for a lightpath setup is not available > > in an optical switch, it rejects the operation for resource > > not being available. > >=20 > > Regards, > >=20 > > Sidney > >=20 > > > -----Original Message----- > > > From: Drake, John E [mailto:John.E.Drake2@boeing.com] > > > Sent: Monday, October 31, 2005 9:51 AM > > > To: Drake, John E; Shiba, Sidney; dpapadimitriou@psg.com > > > Cc: Adrian Farrel; richard.rabbat@us.fujitsu.com;=20 > ccamp@ops.ietf.org > > > Subject: RE: comments on > draft-shiba-ccamp-gmpls-lambda-labels-00.txt > > > > > > > > > Sidney, > > > > > > There's another issue as well. Having absolute end-end global > > > wavelengths is probably insufficient to ensure that an end-end LSP > can > > > be established successfully, as having a common wavelength > > > does not mean > > > that equipment from different vendors will interoperate > > > correctly in the > > > data-plane. > > > > > > Thanks, > > > > > > John > > > > > > > -----Original Message----- > > > > From: Drake, John E > > > > Sent: Monday, October 31, 2005 7:36 AM > > > > To: Shiba, Sidney; dpapadimitriou@psg.com > > > > Cc: Adrian Farrel; richard.rabbat@us.fujitsu.com; > ccamp@ops.ietf.org > > > > Subject: RE: comments on > > > draft-shiba-ccamp-gmpls-lambda-labels-00.txt > > > > > > > > Sidney, > > > > > > > > But there's nothing in your picture that requires an > > > absolute end-end > > > > global wavelength. The existing GMPLS solution with relative > > > > wavelengths of local significance should work just fine. > > > As I said in > > > > my previous note, your method precludes combining two or > > > more parallel > > > > WDM links into a single TE link. > > > > > > > > Thanks, > > > > > > > > John > > > > > > > > > -----Original Message----- > > > > > From: Shiba, Sidney [mailto:sidney.shiba@us.fujitsu.com] > > > > > Sent: Monday, October 31, 2005 7:25 AM > > > > > To: Drake, John E; dpapadimitriou@psg.com > > > > > Cc: Adrian Farrel; richard.rabbat@us.fujitsu.com; > > > ccamp@ops.ietf.org > > > > > Subject: RE: comments on > > > draft-shiba-ccamp-gmpls-lambda-labels-00.txt > > > > > > > > > > Hi John, > > > > > > > > > > Optical switches based on Wavelength Selective Switch (WSS) > > > technology > > > > > requires the wavelength information for switching. This > technology > > > is > > > > NOT > > > > > wavelength agnostic. > > > > > > > > > > | | > > > > > | wdm | wdm > > > > > |2 |2 > > > > > --------- --------- > > > > > wdm 1| optical |3 wdm 1| optical |3 wdm > > > > > --------| switch |------------| switch |--------- > > > > > | (WSS) | | (WSS) | > > > > > --------- --------- > > > > > |4 |4 > > > > > | wdm | wdm > > > > > | | > > > > > > > > > > Note that the figure above shows an example of two > > > optical switches > > > > > interconnect > > > > > by a single WDM fiber. In this example, each optical=20 > switch can > be > > > > connect > > > > > to 4 > > > > > other optical switches. > > > > > > > > > > As you can see, the optical ports information do not > > > provide enough > > > > > information > > > > > for wavelength switching. > > > > > > > > > > Hope that clarifies the application requirement. > > > > > > > > > > Thanks, > > > > > > > > > > Sidney > > > > > > > > > > > -----Original Message----- > > > > > > From: Drake, John E [mailto:John.E.Drake2@boeing.com] > > > > > > Sent: Friday, October 28, 2005 5:33 PM > > > > > > To: dpapadimitriou@psg.com; Shiba, Sidney > > > > > > Cc: Adrian Farrel; richard.rabbat@us.fujitsu.com; > > > ccamp@ops.ietf.org > > > > > > Subject: RE: comments on > > > > draft-shiba-ccamp-gmpls-lambda-labels-00.txt > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > Below is the text of an e-mail is sent to the Ethernet/GMPLS > > > mailing > > > > > > list. > > > > > > > > > > > > Upon reflection I am not sure using a real wavelength > > > value makes > > > > much > > > > > > sense. Between a pair of adjacent nodes, there may be > > > > > > multiple pairs of > > > > > > switch ports in the same TE link that support a given > frequency. > > > If > > > > a > > > > > > real wavelength value is used, how do the two nodes agree on > > > > > > which pair > > > > > > of switch ports to use? > > > > > > > > > > > > Furthermore, the amount of configuration is the same - you > > > > > > still need to > > > > > > configure the wavelength of each switch port. > > > > > > > > > > > > Thanks, > > > > > > > > > > > > John > > > > > >=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=3D=3D=3D=3D=3D=3D=3D=3D > > > > > > =3D=3D=3D=3D > > > > > > Adrian, > > > > > > > > > > > > In the transparent photonic lambda switch case, the labels > also > > > have > > > > > > only local significance. When an LSP is established, the > input > > > > ports, > > > > > > as identified with local labels, are cross-connected to > > > the output > > > > > > ports, as identified with local labels. > > > > > > > > > > > > There is just extra configuration to identify,=20 > using strictly > > > local > > > > > > identifiers, the wavelength associated with the all of the > > > switch's > > > > > > ports, and an additional CAC requirement that the=20 > wavelengths > of > > > the > > > > > > input and output ports are the same. > > > > > > > > > > > > Thanks, > > > > > > > > > > > > John > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: dimitri papadimitriou=20 > [mailto:dpapadimitriou@psg.com] > > > > > > > Sent: Thursday, October 27, 2005 10:03 AM > > > > > > > To: Shiba, Sidney > > > > > > > Cc: dimitri.papadimitriou@alcatel.be; Adrian Farrel; > > > > > > > richard.rabbat@us.fujitsu.com; ccamp@ops.ietf.org > > > > > > > Subject: Re: comments on > > > > > > draft-shiba-ccamp-gmpls-lambda-labels-00.txt > > > > > > > > > > > > > > shiba - see inline for some additional hints: > > > > > > > > > > > > > > >>Shiba, Sidney wrote: > > > > > > > >> > > > > > > > >>>Adrian, Dimitri, > > > > > > > >>> > > > > > > > >>>Thanks for reviewing these I-D. > > > > > > > >>> > > > > > > > >>>Wavelength continuity constraint does require=20 > the use of > > > > > > semanticful > > > > > > > >>>label whether it is spectral or index. > > > > > > > >> > > > > > > > >>=3D> see my reply to adrian on this specific point > > > > > > > >> > > > > > > > >>>I agree with Dimitri that the > > > > > > > >>>wavelength indexing requires document updating=20 > each time > a > > > new > > > > > > > >>>spectrum is introduced. > > > > > > > >> > > > > > > > >>=3D> indeed and in addition it requires updating=20 > the already > > > > > > > >>signaled path > > > > > > > >> > > > > > > > >>>The use of spectral label provides self maintainance, > i.e., > > > > > > > >>>no need to update any document and the use of=20 > the nominal > > > value > > > > > > > >>>provides a common semantic ground. > > > > > > > >> > > > > > > > >>=3D> what do you mean by self-maintenance - would you > > > provide a > > > > > > > >>bit more detail > > > > > > > > > > > > > > > > [Sidney]What I've meant here was that it was not > > > necessary to > > > > > > > > update any document when new wavelengths are=20 > inventoried. > In > > > the > > > > > > > > case of indexing approach, it would require the > > > > > > wavelength indexing > > > > > > > > document to be updated with implementation impacts. > > > > > > > > > > > > > > > > In the case, the nominal value is used, there is no need > for > > > > > > > > documentation update. > > > > > > > > > > > > > > ok - what you mean here is that you are going to make > > > use of the > > > > > > already > > > > > > > defined C-Type 2 - what about the specific encoding of the > > > > > > value space > > > > > > ? > > > > > > > > > > > > > > >>=3D> now i have a more specific question before being > light-up > > > > > > > >>how do you know the frequency that you can support ? > > > > > > > > > > > > > > > > [Sidney] Some new technologies integrate optical switch > and > > > > > > mux/demux > > > > > > > > capabilities, which allows the equipment to know > > > the spectrum > > > it > > > > > > > supports. > > > > > > > > > > > > > > indeed - but the question is what does happen if the > > > > > > "detected" values > > > > > > > (during initialization) do not match the nominal values ? > you > > > > don't > > > > > > > initialize then ? > > > > > > > > > > > > > > >>if these differ from the nominal values how are=20 > you going > to > > > > deal > > > > > > with > > > > > > > these > > > > > > > >>discrepancies ? > > > > > > > > > > > > > > > > [Sidney] These new technologies uses the=20 > nominal value as > > > > > > reference. > > > > > > We > > > > > > > can say > > > > > > > > that a lightpath wavelength is identified by its nominal > > > value. > > > > If > > > > > > the > > > > > > > equipment > > > > > > > > is drifting from this nominal value, it is considered as > > > > > > a failure. > > > > > > > > > > > > > > ok - but if the deviation is such you have=20 > overlap - how the > > > > control > > > > > > > plane is going to be able to detect such failure ? > > > > > > > > > > > > > > >>this said i am not necessarily sure that having to > > > > > > maintain the data > > > > > > > plane > > > > > > > >>specifics as part of the control plane is really helping > > > > > > > >>operations (is this method not just duplicating > > > complexity ?) > > > > > > > > > > > > > > > > [Sidney] The wavelength is WDM specific as much as the > SUKLM > > > > label > > > > > > > encoding > > > > > > > > is for SONET. The wavelegth/frequency nominal value > > > is used to > > > > > > identify > > > > > > > the > > > > > > > > facilities to cross-connect. > > > > > > > > > > > > > > there is an equivalence but there is also a major > difference, > > > the > > > > > > > structure is invariant independently of the state of the > > > > > > network, with > > > > > > > spectral value space you may have labels that become > > > unavailable > > > > due > > > > > > to > > > > > > > non-local usage of wavelength in the network > > > > > > > > > > > > > > hence, there is also no real coupling to the data=20 > plane more > > > than > > > > > > > knowing the type of interface and some generic=20 > capabilities > > > > > > > > > > > > > > >>>I'm not sure if the draft needs to be updated=20 > before the > > > > > > > >>>face-to-face meeting or after all comments are=20 > collected. > > > > Please > > > > > > > advise. > > > > > > > >> > > > > > > > >>=3D> suggest to keep discussion on - document=20 > update can be > > > > > > > >>performed at a later stage > > > > > > > > > > > > > > thanks, > > > > > > > - dimitri. > > > > > > > > > > > > > > >>>>-----Original Message----- > > > > > > > >>>>From: owner-ccamp@ops.ietf.org > > > > > > [mailto:owner-ccamp@ops.ietf.org]On > > > > > > > >>>>Behalf Of Adrian Farrel > > > > > > > >>>>Sent: Thursday, October 27, 2005 4:45 AM > > > > > > > >>>>To: dpapadimitriou@psg.com; > > > dimitri.papadimitriou@alcatel.be; > > > > > > > >>>>ccamp@ops.ietf.org > > > > > > > >>>>Subject: Re: comments on > > > > > > > >> > > > > > > > >>draft-shiba-ccamp-gmpls-lambda-labels-00.txt > > > > > > > >> > > > > > > > >>>> > > > > > > > >>>>Dimitri, > > > > > > > >>>> > > > > > > > >>>>Thanks for your work reviewing these recent=20 > I-Ds. It is > > > > > > > >>>>really valuable > > > > > > > >>>>and I'd welcome other people doing similar reviews. > > > > > > > >>>> > > > > > > > >>>> > > > > > > > >>>> > > > > > > > >>>>>there is a specific point to be clarified in > > > this document: > > > > > > > >>>>> > > > > > > > >>>>>semanticless vs semanticful label (even here=20 > there is a > > > > > > distinction > > > > > > > >>>>>between spectral vs indexes i.e. using the wavelength > > > index) > > > > > > > >>>>> > > > > > > > >>>>>domain-wide vs link local significant label > > > > > > > >>>> > > > > > > > >>>>Without being too picky, I think all labels are > > > semanticful > > > > > > > >>>>otherwise, we > > > > > > > >>>>would not know what resource they refered to. > > > > > > > >>>> > > > > > > > >>>>So the point reduces to whether the scope of the > semantics > > > > > > > >>>>are link-local > > > > > > > >>>>or wider. > > > > > > > >>>> > > > > > > > >>>> > > > > > > > >>>> > > > > > > > >>>>>so, the comparison from this perspective with > > > TDM labels is > > > > > > > >>>> > > > > > > > >>>>difficult to > > > > > > > >>>> > > > > > > > >>>> > > > > > > > >>>>>parse, the latter is semanticful but link local > > > > > > > >>>>> > > > > > > > >>>>>now, i don't specifically see what has=20 > changed the late > > > 90's, > > > > > > early > > > > > > > >>>>>y2k's, to have a change in the wavelength label > > > definition; > > > > > > > >>>> > > > > > > > >>>>This is the question I would like to get to the bottom > of. > > > In > > > > > > > >>>>other words: > > > > > > > >>>>do we need this function? > > > > > > > >>>> > > > > > > > >>>>It seems to me that the question being asked is this: > > > > > > > >>>> > > > > > > > >>>> If I want to compute a path that has some form of > > > wavelength > > > > > > > >>>> constraints, what information do I need access to? > > > > > > > >>>> > > > > > > > >>>>Another question might be: > > > > > > > >>>> > > > > > > > >>>> If I want to signal a path with wavelength=20 > constraints > > > what > > > > > > > >>>> information do I need to include in the > > > signaling message? > > > > > > > >>>> > > > > > > > >>>> > > > > > > > >>>>I'd suggest that when we started on GMPLS, we were > > > > > > > >> > > > > > > > >>enthusiastic about > > > > > > > >> > > > > > > > >>>>transparent optical networks, but we were not properly > > > > > > > >>>>focusing wavelength > > > > > > > >>>>constraints because lambda-switching PXCs didn't take > off. > > > > > > > >>>>Therefore we > > > > > > > >>>>didn't examine the requirements for wavelength > constraints > > > in > > > > > > > >>>>routing and > > > > > > > >>>>signaling. The authors of this I-D are claiming > > > new hardware > > > > > > > >>>>requirements > > > > > > > >>>>for the same function. > > > > > > > >>>> > > > > > > > >>>> > > > > > > > >>>> > > > > > > > >>>>>there are > > > > > > > >>>>>several solution possible > > > > > > > >>>>> > > > > > > > >>>>>- absolute values: the freq. of the wavelength: > difficult > > > to > > > > > > adopt > > > > > > > >>>>>because referenced values are nominal and knowing all > > > > > > interactions > > > > > > > >>>>>between wavelengths this knowledge is at the end > > > of little > > > > > > > >> > > > > > > > >>practical > > > > > > > >> > > > > > > > >>>>>usage; (introduces implicit ordering) > > > > > > > >>>>> > > > > > > > >>>>>- indexed values: the # of the wavelength:=20 > it does not > > > > > > > >> > > > > > > > >>provide for a > > > > > > > >> > > > > > > > >>>>>future proof label space for inst. in case new > > > frequencies > > > > > > > >>>> > > > > > > > >>>>are inserted > > > > > > > >>>> > > > > > > > >>>> > > > > > > > >>>>>in the grid (introduces explicit ordering) > > > > > > > >>>>> > > > > > > > >>>>>- diff. values e.g. freq spacing starting from a > > > reference > > > > > > > >>>> > > > > > > > >>>>value: pauses > > > > > > > >>>> > > > > > > > >>>> > > > > > > > >>>>>the question of the reference value and does suffer > from > > > the > > > > > > former > > > > > > > >>>>>issue (introduces implicit ordering) > > > > > > > >>>>> > > > > > > > >>>>>- the solution available today - cumbersome in some > > > > > > control plane > > > > > > > >>>>>operations (e.g. label set translation) and=20 > not easy to > > > > > > > >>>> > > > > > > > >>>>troubleshoot but > > > > > > > >>>> > > > > > > > >>>> > > > > > > > >>>>>independent of any physical consideration > > > (spectral), scale > > > > to > > > > > > any > > > > > > > >>>>>number of wavelength per fiber, does not=20 > introduce any > > > > > > > >> > > > > > > > >>ordering, the > > > > > > > >> > > > > > > > >>>>>most flexible (since allowing each system to maintain > its > > > > > > specific > > > > > > > >>>>>control operations) and the less constraining since > > > > maintaining > > > > > > the > > > > > > > >>>>>control plane operations independent of any=20 > data plane > > > > > > specifics > > > > > > > >>>>> > > > > > > > >>>>> > > > > > > > >>>> > > > > > > > > > > >>>> > > > > > > >>> > > > > > > > >>>ambda-labels > > > > > > > >>>-00.txt> > > > > > > > >>> > > > > > > > >>>. > > > > > > > >>> > > > > > > > >> > > > > > > > > > > > > > > > > . > > > > > > > > > > > > > > > > > >=20 From owner-ccamp@ops.ietf.org Mon Oct 31 12:46:30 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWdjq-0001OI-55 for ccamp-archive@megatron.ietf.org; Mon, 31 Oct 2005 12:46:30 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23420 for ; Mon, 31 Oct 2005 12:46:06 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EWdy1-00042u-7A for ccamp-archive@ietf.org; Mon, 31 Oct 2005 13:01:09 -0500 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EWdeW-000ExS-Nf for ccamp-data@psg.com; Mon, 31 Oct 2005 17:41:00 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-4.8 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from localhost ([127.0.0.1]) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EWdeU-000Ex5-Tu; Mon, 31 Oct 2005 17:40:59 +0000 Message-ID: <43665728.6030003@psg.com> Date: Mon, 31 Oct 2005 18:40:56 +0100 From: dimitri papadimitriou Reply-To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.11) Gecko/20050728 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Igor Bryskin CC: dimitri.papadimitriou@alcatel.be, "Drake, John E" , "Zafar Ali (zali)" , Igor Bryskin , drake@movaz.com, Kim Young Hwa , ccamp@ops.ietf.org Subject: Re: Two Drafts for Resilience of Control Plane References: <626FC7C6A97381468FB872072AB5DDC8369714@XCH-SW-42.sw.nos.boeing.com> <00b201c5de24$c20fc710$7a1810ac@movaz.com> <436639BA.6040405@psg.com> <011a01c5de33$4fc053f0$7a1810ac@movaz.com> <43664BBF.8030704@psg.com> <015b01c5de3e$f2a2a090$7a1810ac@movaz.com> In-Reply-To: <015b01c5de3e$f2a2a090$7a1810ac@movaz.com> 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: 2b2ad76aced9b1d558e34a970a85c027 Content-Transfer-Encoding: 7bit igor > Suppose you have LSP going through -A-B-C- and a controller managing node B > fails, while the data plane is intact, that is, no data plane alarms are > detected. > > According to your logic such situation can exist only for 90c, because once > controller managing node C detects the absence of 3 Path refreshes it will > delete the control plane and destroy the service. My question is why do you > need the RSVP graceful restart procedures then if they can happen only > within 90c time interval - after that there will be nothing to synchronize. > > What we see and hear in the field, though, that a controller may stay days > out of service and then come back and should be capable to synchronize the > control state of all LSPs it used to manage before the crash/reboot. And, of > course, you MUST maintain data service up and running. i have never said the contrary, if you run an (independent) cp failure detection mechanism and prior negotiated cp recovery: in case of failure in CP => GR (see RFC 3471/3) ... you are the one trying to find protocol deficiencies while it is still totally unclear to me (but i am not the only one apparently) where they these limitations (potentially) are ? on one side, you ask how to free costly resources and on the other you ask how to maintain the connection service ... at the end, you should decide what you want to do - i am not sure that you have understood that you can have both at the same time > Igor > > ----- Original Message ----- > From: "dimitri papadimitriou" > To: "Igor Bryskin" > Cc: ; "Drake, John E" > ; "Zafar Ali (zali)" ; "Igor > Bryskin" ; ; "Kim Young Hwa" > ; > Sent: Monday, October 31, 2005 11:52 AM > Subject: Re: Two Drafts for Resilience of Control Plane > > > >>igor - >> >>Igor Bryskin wrote: >> >>>Dimitri, >>> >>> >>>>igor - my two cents >>>> >>>>RSVP over time has progressively borrowed mechanisms from "hard-state" >>>>protocols, explicit deletion using PathTear is most noticeable and >>>>initial example of this evolution ! >>>> >>>>but in any case, RSVP still relies is on idem-potent soft-states that >>>>are flushed when not refreshed after certain time interval (or self- >>>>maintained if previously negotiated) this prevents orphans in the >>>>network (so unused resources) and provides for resilience - hence there >>>>is by no means a need to introduce an additional protocol mechanism to >>>>trigger or not such event via the "control plane" - >>> >>> >>>Refreshes are useful mechanism but only between neighbors that maintain >>>Hello communication. In this case the absence of Path refreshes is as > > good > >>>indication that data plane must be destroyed as received PathTear > > message. > >>the base function of state refresh and usefulness is independent of >>hello adjacency maintenance (or any other control channel maintenance) >> >> >>>However, when a controller does not receive Path refreshes from a > > neighbor > >>>it does not have any control plane communication with, it can assume > > neither > >>>a problem in the data plane nor intention to destroy it. >> >>as the node did not negotiate any channel/node fault recovery (due in >>part. to the absence of Hello adjacency with its neighbor) and if no >>other independent control channel failure is provided (this is an add-on >>of RFC3471/3), the simple absence of refresh is simply intepreted as >>"implicit deletion" >> >>you are mis-interpreting the following sentence of RFC3471 >> >>" Note that these cases only apply when there are mechanisms to detect >> data channel failures independent of control channel failures." >> >>there is no retro-fit on the use of Refreshes in absence of control >>channel failure detection mechanism >> >> >>>Hence, as it was >>>specified in RFC3471, it *must* maintain both control and data plane > > states > >>>throughout the failure. >> >>- d. >> >>>Igor >>> >>> >>> >>>>btw, the paragraph you mention in RFC3471 does not say "soft state >>>>protocols do not work well for non-packet environments" this is your >>>>interpretation; >>>> >>>>ps: you are still free to make use of RFC3472 in case (as you were >>>>apparently looking for something else ;-) >>>> >>>>Igor Bryskin wrote: >>>> >>>> >>>>>John, >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>>>States are supposed to be destroyed on explicit signalling >>>>>>>message (e.g. PathTear or PathErr with the state removal >>>>>>>flag), but not because of the absence of refreshes. >>>>>>> >>>>> >>>>>[JD] >>>>> >>>>>Igor, >>>>> >>>>>Just to be clear, we are talking about RSVP here, and RSVP *is* a soft >>>>>state protocol. Can you point to any RFC that supports your statements >>>>>above? >>>>> >>>>>IB>> Oh, come on, John. You sound like you've been yourself in a > > dormant > >>>>>state for a while :=). We've gone a long way since RFC2205. In RFC3471, >>> >>>for >>> >>> >>>>>example, there is a discussion why GMPLS is needed and how is it >>> >>>different >>> >>> >>>>>from MPLS. One of the differences is the fact that soft state protocols >>> >>>do >>> >>> >>>>>not work well for non-packet environments. Here is from the RDC3471: >>>>> >>>>> >>>>> >>>>>9.2. Fault Handling There are two new faults that must be handled >>> >>>when >>> >>> >>>>>the control channel is independent of the data channel. In the > > first, > >>>>>there is a link or other type of failure that limits the ability of >>>>>neighboring nodes to pass control messages. In this situation, >>>>>neighboring nodes are unable to exchange control messages for a > > period > >>>of >>> >>> >>>>>time. Once communication is restored the underlying signaling >>> >>>protocol >>> >>> >>>>>must indicate that the nodes have maintained their state through the >>>>>failure.. >>>>> >>>>>What is more important is the reality of life: The customers simply say >>> >>>that >>> >>> >>>>>you cannot destroy a user service (or even force any traffic hits) just >>>>>because you have a problem in the control plane. If this does not fit >>> >>>your >>> >>> >>>>>soft-state paradigm, than "harden" your protocols or flash them down > > the > >>>>>toilet and come with something else if you want our business. After > > all, > >>>if >>> >>> >>>>>we provision the services via NMS, we do not have to destroy the >>> >>>services if >>> >>> >>>>>we have problems in the management network. It is that simple. >>>>> >>>>> >>>>> >>>>>Igor >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>. >>>>> >>> >>> >>> >>> >>>. >>> > > > > > . > From owner-ccamp@ops.ietf.org Mon Oct 31 13:21:01 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWeHF-00006L-1q for ccamp-archive@megatron.ietf.org; Mon, 31 Oct 2005 13:21:01 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25443 for ; Mon, 31 Oct 2005 13:20:42 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EWeVN-0005LM-3P for ccamp-archive@ietf.org; Mon, 31 Oct 2005 13:35:43 -0500 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EWe6s-000Gio-Tf for ccamp-data@psg.com; Mon, 31 Oct 2005 18:10:18 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [130.76.96.56] (helo=stl-smtpout-01.boeing.com) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EWe6r-000GiW-Nm; Mon, 31 Oct 2005 18:10:17 +0000 Received: from stl-av-01.boeing.com ([192.76.190.6]) by stl-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id MAA28345; Mon, 31 Oct 2005 12:10:17 -0600 (CST) Received: from XCH-SWBH-04.sw.nos.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id j9VIAGY22500; Mon, 31 Oct 2005 12:10:16 -0600 (CST) Received: from XCH-SW-42.sw.nos.boeing.com ([192.79.11.43]) by XCH-SWBH-04.sw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 31 Oct 2005 10:10:15 -0800 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: comments on draft-shiba-ccamp-gmpls-lambda-labels-00.txt Date: Mon, 31 Oct 2005 10:10:14 -0800 Message-ID: <626FC7C6A97381468FB872072AB5DDC8369721@XCH-SW-42.sw.nos.boeing.com> Thread-Topic: comments on draft-shiba-ccamp-gmpls-lambda-labels-00.txt Thread-Index: AcXbIzcAFoI5B5TzS9O/zBGY1cMJbwA6iz0AAIdyNZAAAR14UAAAqdxAAAGnFZAAAGLHsAAC5pxQ From: "Drake, John E" To: "Shiba, Sidney" , Cc: "Adrian Farrel" , , X-OriginalArrivalTime: 31 Oct 2005 18:10:15.0465 (UTC) FILETIME=[57F49190:01C5DE46] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: quoted-printable Snipped... > > [Sidney] May be I'm missing something but for example, can you explain > me how can we use Label Set with labels that only have local significance? >=20 [JD]=20 From RFC 3471: "The receiver of a Label Set must restrict its choice of labels to one which is in the Label Set. Much like a label, a Label Set may be present across multiple hops. In this case each node generates its own outgoing Label Set, possibly based on the incoming Label Set and the node's hardware capabilities. This case is expected to be the norm for nodes with conversion incapable (CI-incapable) interfaces." From owner-ccamp@ops.ietf.org Mon Oct 31 13:22:15 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWeIR-0000MI-Nd for ccamp-archive@megatron.ietf.org; Mon, 31 Oct 2005 13:22:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25505 for ; Mon, 31 Oct 2005 13:21:56 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EWeWb-0005O7-93 for ccamp-archive@ietf.org; Mon, 31 Oct 2005 13:36:58 -0500 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EWeBb-000H4w-Bd for ccamp-data@psg.com; Mon, 31 Oct 2005 18:15:11 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [130.76.64.48] (helo=slb-smtpout-01.boeing.com) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EWeBZ-000H4S-Dp; Mon, 31 Oct 2005 18:15:09 +0000 Received: from blv-av-01.boeing.com ([192.42.227.216]) by slb-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id KAA22266; Mon, 31 Oct 2005 10:15:08 -0800 (PST) Received: from XCH-SWBH-04.sw.nos.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id j9VIF7H10856; Mon, 31 Oct 2005 10:15:07 -0800 (PST) Received: from XCH-SW-42.sw.nos.boeing.com ([192.79.11.43]) by XCH-SWBH-04.sw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 31 Oct 2005 10:15:04 -0800 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: comments on draft-shiba-ccamp-gmpls-lambda-labels-00.txt Date: Mon, 31 Oct 2005 10:15:03 -0800 Message-ID: <626FC7C6A97381468FB872072AB5DDC8369722@XCH-SW-42.sw.nos.boeing.com> Thread-Topic: comments on draft-shiba-ccamp-gmpls-lambda-labels-00.txt Thread-Index: AcXbIzcAFoI5B5TzS9O/zBGY1cMJbwA6iz0AAIdyNZAAAR14UAAAnn6wAABj8oAAAozZ0AAAuniQAAFlmFA= From: "Drake, John E" To: "Shiba, Sidney" , Cc: "Adrian Farrel" , , X-OriginalArrivalTime: 31 Oct 2005 18:15:04.0327 (UTC) FILETIME=[04216970:01C5DE47] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 34a12386bc31e4adf7d931eae58f5833 Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: Shiba, Sidney [mailto:sidney.shiba@us.fujitsu.com] > Sent: Monday, October 31, 2005 9:38 AM > To: Drake, John E; dpapadimitriou@psg.com > Cc: Adrian Farrel; richard.rabbat@us.fujitsu.com; ccamp@ops.ietf.org > Subject: RE: comments on draft-shiba-ccamp-gmpls-lambda-labels-00.txt >=20 > John, >=20 > When multi-vendor configuration is involved, regenerators (e.g, G.709 > OEO conversion) are usually used to interface two systems. In this case, > tunable laser regenerators need to be tuned to the desired wavelength. >=20 > Hope that helps to identify the interoperability requirement. [JD]=20 So, you can only have an end-end absolute global label across a set of WDM systems from a single vendor? So what exactly is the marginal utility compared to the existing GMPLS solution? =20 >=20 > BTW, the draft provides some "requirements" related to Label Set. I'm > curious to know how this is addressed with local significance labels. [JD]=20 See my other e-mail. =20 >=20 > Thanks, >=20 > Sidney >=20 > > -----Original Message----- > > From: Drake, John E [mailto:John.E.Drake2@boeing.com] > > Sent: Monday, October 31, 2005 11:12 AM > > To: Shiba, Sidney; dpapadimitriou@psg.com > > Cc: Adrian Farrel; richard.rabbat@us.fujitsu.com; ccamp@ops.ietf.org > > Subject: RE: comments on draft-shiba-ccamp-gmpls-lambda-labels-00.txt > > > > > > Sidney > > > > 'm not sure you are addressing my concern, unless you are telling me > > that an LSP can be instantiated along a path that contains WDM systems > > from *different* vendors. I had been told that, in general, this was > > not the case. > > > > Thanks, > > > > John > > > > > -----Original Message----- > > > From: Shiba, Sidney [mailto:sidney.shiba@us.fujitsu.com] > > > Sent: Monday, October 31, 2005 8:00 AM > > > To: Drake, John E; dpapadimitriou@psg.com > > > Cc: Adrian Farrel; richard.rabbat@us.fujitsu.com; ccamp@ops.ietf.org > > > Subject: RE: comments on > > draft-shiba-ccamp-gmpls-lambda-labels-00.txt > > > > > > John, > > > > > > Most of vendor support a standardized wavelength grid > > > (e.g., ITU-T DWDM wavelength grid given in nominal value). > > > > > > If a wavelength chosen for a lightpath setup is not available > > > in an optical switch, it rejects the operation for resource > > > not being available. > > > > > > Regards, > > > > > > Sidney > > > > > > > -----Original Message----- > > > > From: Drake, John E [mailto:John.E.Drake2@boeing.com] > > > > Sent: Monday, October 31, 2005 9:51 AM > > > > To: Drake, John E; Shiba, Sidney; dpapadimitriou@psg.com > > > > Cc: Adrian Farrel; richard.rabbat@us.fujitsu.com; > > ccamp@ops.ietf.org > > > > Subject: RE: comments on > > draft-shiba-ccamp-gmpls-lambda-labels-00.txt > > > > > > > > > > > > Sidney, > > > > > > > > There's another issue as well. Having absolute end-end global > > > > wavelengths is probably insufficient to ensure that an end-end LSP > > can > > > > be established successfully, as having a common wavelength > > > > does not mean > > > > that equipment from different vendors will interoperate > > > > correctly in the > > > > data-plane. > > > > > > > > Thanks, > > > > > > > > John > > > > > > > > > -----Original Message----- > > > > > From: Drake, John E > > > > > Sent: Monday, October 31, 2005 7:36 AM > > > > > To: Shiba, Sidney; dpapadimitriou@psg.com > > > > > Cc: Adrian Farrel; richard.rabbat@us.fujitsu.com; > > ccamp@ops.ietf.org > > > > > Subject: RE: comments on > > > > draft-shiba-ccamp-gmpls-lambda-labels-00.txt > > > > > > > > > > Sidney, > > > > > > > > > > But there's nothing in your picture that requires an > > > > absolute end-end > > > > > global wavelength. The existing GMPLS solution with relative > > > > > wavelengths of local significance should work just fine. > > > > As I said in > > > > > my previous note, your method precludes combining two or > > > > more parallel > > > > > WDM links into a single TE link. > > > > > > > > > > Thanks, > > > > > > > > > > John > > > > > > > > > > > -----Original Message----- > > > > > > From: Shiba, Sidney [mailto:sidney.shiba@us.fujitsu.com] > > > > > > Sent: Monday, October 31, 2005 7:25 AM > > > > > > To: Drake, John E; dpapadimitriou@psg.com > > > > > > Cc: Adrian Farrel; richard.rabbat@us.fujitsu.com; > > > > ccamp@ops.ietf.org > > > > > > Subject: RE: comments on > > > > draft-shiba-ccamp-gmpls-lambda-labels-00.txt > > > > > > > > > > > > Hi John, > > > > > > > > > > > > Optical switches based on Wavelength Selective Switch (WSS) > > > > technology > > > > > > requires the wavelength information for switching. This > > technology > > > > is > > > > > NOT > > > > > > wavelength agnostic. > > > > > > > > > > > > | | > > > > > > | wdm | wdm > > > > > > |2 |2 > > > > > > --------- --------- > > > > > > wdm 1| optical |3 wdm 1| optical |3 wdm > > > > > > --------| switch |------------| switch |--------- > > > > > > | (WSS) | | (WSS) | > > > > > > --------- --------- > > > > > > |4 |4 > > > > > > | wdm | wdm > > > > > > | | > > > > > > > > > > > > Note that the figure above shows an example of two > > > > optical switches > > > > > > interconnect > > > > > > by a single WDM fiber. In this example, each optical > > switch can > > be > > > > > connect > > > > > > to 4 > > > > > > other optical switches. > > > > > > > > > > > > As you can see, the optical ports information do not > > > > provide enough > > > > > > information > > > > > > for wavelength switching. > > > > > > > > > > > > Hope that clarifies the application requirement. > > > > > > > > > > > > Thanks, > > > > > > > > > > > > Sidney > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Drake, John E [mailto:John.E.Drake2@boeing.com] > > > > > > > Sent: Friday, October 28, 2005 5:33 PM > > > > > > > To: dpapadimitriou@psg.com; Shiba, Sidney > > > > > > > Cc: Adrian Farrel; richard.rabbat@us.fujitsu.com; > > > > ccamp@ops.ietf.org > > > > > > > Subject: RE: comments on > > > > > draft-shiba-ccamp-gmpls-lambda-labels-00.txt > > > > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > Below is the text of an e-mail is sent to the Ethernet/GMPLS > > > > mailing > > > > > > > list. > > > > > > > > > > > > > > Upon reflection I am not sure using a real wavelength > > > > value makes > > > > > much > > > > > > > sense. Between a pair of adjacent nodes, there may be > > > > > > > multiple pairs of > > > > > > > switch ports in the same TE link that support a given > > frequency. > > > > If > > > > > a > > > > > > > real wavelength value is used, how do the two nodes agree on > > > > > > > which pair > > > > > > > of switch ports to use? > > > > > > > > > > > > > > Furthermore, the amount of configuration is the same - you > > > > > > > still need to > > > > > > > configure the wavelength of each switch port. > > > > > > > > > > > > > > Thanks, > > > > > > > > > > > > > > John > > > > > > > > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > > > > =3D=3D=3D=3D > > > > > > > Adrian, > > > > > > > > > > > > > > In the transparent photonic lambda switch case, the labels > > also > > > > have > > > > > > > only local significance. When an LSP is established, the > > input > > > > > ports, > > > > > > > as identified with local labels, are cross-connected to > > > > the output > > > > > > > ports, as identified with local labels. > > > > > > > > > > > > > > There is just extra configuration to identify, > > using strictly > > > > local > > > > > > > identifiers, the wavelength associated with the all of the > > > > switch's > > > > > > > ports, and an additional CAC requirement that the > > wavelengths > > of > > > > the > > > > > > > input and output ports are the same. > > > > > > > > > > > > > > Thanks, > > > > > > > > > > > > > > John > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: dimitri papadimitriou > > [mailto:dpapadimitriou@psg.com] > > > > > > > > Sent: Thursday, October 27, 2005 10:03 AM > > > > > > > > To: Shiba, Sidney > > > > > > > > Cc: dimitri.papadimitriou@alcatel.be; Adrian Farrel; > > > > > > > > richard.rabbat@us.fujitsu.com; ccamp@ops.ietf.org > > > > > > > > Subject: Re: comments on > > > > > > > draft-shiba-ccamp-gmpls-lambda-labels-00.txt > > > > > > > > > > > > > > > > shiba - see inline for some additional hints: > > > > > > > > > > > > > > > > >>Shiba, Sidney wrote: > > > > > > > > >> > > > > > > > > >>>Adrian, Dimitri, > > > > > > > > >>> > > > > > > > > >>>Thanks for reviewing these I-D. > > > > > > > > >>> > > > > > > > > >>>Wavelength continuity constraint does require > > the use of > > > > > > > semanticful > > > > > > > > >>>label whether it is spectral or index. > > > > > > > > >> > > > > > > > > >>=3D> see my reply to adrian on this specific point > > > > > > > > >> > > > > > > > > >>>I agree with Dimitri that the > > > > > > > > >>>wavelength indexing requires document updating > > each time > > a > > > > new > > > > > > > > >>>spectrum is introduced. > > > > > > > > >> > > > > > > > > >>=3D> indeed and in addition it requires updating > > the already > > > > > > > > >>signaled path > > > > > > > > >> > > > > > > > > >>>The use of spectral label provides self maintainance, > > i.e., > > > > > > > > >>>no need to update any document and the use of > > the nominal > > > > value > > > > > > > > >>>provides a common semantic ground. > > > > > > > > >> > > > > > > > > >>=3D> what do you mean by self-maintenance - would you > > > > provide a > > > > > > > > >>bit more detail > > > > > > > > > > > > > > > > > > [Sidney]What I've meant here was that it was not > > > > necessary to > > > > > > > > > update any document when new wavelengths are > > inventoried. > > In > > > > the > > > > > > > > > case of indexing approach, it would require the > > > > > > > wavelength indexing > > > > > > > > > document to be updated with implementation impacts. > > > > > > > > > > > > > > > > > > In the case, the nominal value is used, there is no need > > for > > > > > > > > > documentation update. > > > > > > > > > > > > > > > > ok - what you mean here is that you are going to make > > > > use of the > > > > > > > already > > > > > > > > defined C-Type 2 - what about the specific encoding of the > > > > > > > value space > > > > > > > ? > > > > > > > > > > > > > > > > >>=3D> now i have a more specific question before being > > light-up > > > > > > > > >>how do you know the frequency that you can support ? > > > > > > > > > > > > > > > > > > [Sidney] Some new technologies integrate optical switch > > and > > > > > > > mux/demux > > > > > > > > > capabilities, which allows the equipment to know > > > > the spectrum > > > > it > > > > > > > > supports. > > > > > > > > > > > > > > > > indeed - but the question is what does happen if the > > > > > > > "detected" values > > > > > > > > (during initialization) do not match the nominal values ? > > you > > > > > don't > > > > > > > > initialize then ? > > > > > > > > > > > > > > > > >>if these differ from the nominal values how are > > you going > > to > > > > > deal > > > > > > > with > > > > > > > > these > > > > > > > > >>discrepancies ? > > > > > > > > > > > > > > > > > > [Sidney] These new technologies uses the > > nominal value as > > > > > > > reference. > > > > > > > We > > > > > > > > can say > > > > > > > > > that a lightpath wavelength is identified by its nominal > > > > value. > > > > > If > > > > > > > the > > > > > > > > equipment > > > > > > > > > is drifting from this nominal value, it is considered as > > > > > > > a failure. > > > > > > > > > > > > > > > > ok - but if the deviation is such you have > > overlap - how the > > > > > control > > > > > > > > plane is going to be able to detect such failure ? > > > > > > > > > > > > > > > > >>this said i am not necessarily sure that having to > > > > > > > maintain the data > > > > > > > > plane > > > > > > > > >>specifics as part of the control plane is really helping > > > > > > > > >>operations (is this method not just duplicating > > > > complexity ?) > > > > > > > > > > > > > > > > > > [Sidney] The wavelength is WDM specific as much as the > > SUKLM > > > > > label > > > > > > > > encoding > > > > > > > > > is for SONET. The wavelegth/frequency nominal value > > > > is used to > > > > > > > identify > > > > > > > > the > > > > > > > > > facilities to cross-connect. > > > > > > > > > > > > > > > > there is an equivalence but there is also a major > > difference, > > > > the > > > > > > > > structure is invariant independently of the state of the > > > > > > > network, with > > > > > > > > spectral value space you may have labels that become > > > > unavailable > > > > > due > > > > > > > to > > > > > > > > non-local usage of wavelength in the network > > > > > > > > > > > > > > > > hence, there is also no real coupling to the data > > plane more > > > > than > > > > > > > > knowing the type of interface and some generic > > capabilities > > > > > > > > > > > > > > > > >>>I'm not sure if the draft needs to be updated > > before the > > > > > > > > >>>face-to-face meeting or after all comments are > > collected. > > > > > Please > > > > > > > > advise. > > > > > > > > >> > > > > > > > > >>=3D> suggest to keep discussion on - document > > update can be > > > > > > > > >>performed at a later stage > > > > > > > > > > > > > > > > thanks, > > > > > > > > - dimitri. > > > > > > > > > > > > > > > > >>>>-----Original Message----- > > > > > > > > >>>>From: owner-ccamp@ops.ietf.org > > > > > > > [mailto:owner-ccamp@ops.ietf.org]On > > > > > > > > >>>>Behalf Of Adrian Farrel > > > > > > > > >>>>Sent: Thursday, October 27, 2005 4:45 AM > > > > > > > > >>>>To: dpapadimitriou@psg.com; > > > > dimitri.papadimitriou@alcatel.be; > > > > > > > > >>>>ccamp@ops.ietf.org > > > > > > > > >>>>Subject: Re: comments on > > > > > > > > >> > > > > > > > > >>draft-shiba-ccamp-gmpls-lambda-labels-00.txt > > > > > > > > >> > > > > > > > > >>>> > > > > > > > > >>>>Dimitri, > > > > > > > > >>>> > > > > > > > > >>>>Thanks for your work reviewing these recent > > I-Ds. It is > > > > > > > > >>>>really valuable > > > > > > > > >>>>and I'd welcome other people doing similar reviews. > > > > > > > > >>>> > > > > > > > > >>>> > > > > > > > > >>>> > > > > > > > > >>>>>there is a specific point to be clarified in > > > > this document: > > > > > > > > >>>>> > > > > > > > > >>>>>semanticless vs semanticful label (even here > > there is a > > > > > > > distinction > > > > > > > > >>>>>between spectral vs indexes i.e. using the wavelength > > > > index) > > > > > > > > >>>>> > > > > > > > > >>>>>domain-wide vs link local significant label > > > > > > > > >>>> > > > > > > > > >>>>Without being too picky, I think all labels are > > > > semanticful > > > > > > > > >>>>otherwise, we > > > > > > > > >>>>would not know what resource they refered to. > > > > > > > > >>>> > > > > > > > > >>>>So the point reduces to whether the scope of the > > semantics > > > > > > > > >>>>are link-local > > > > > > > > >>>>or wider. > > > > > > > > >>>> > > > > > > > > >>>> > > > > > > > > >>>> > > > > > > > > >>>>>so, the comparison from this perspective with > > > > TDM labels is > > > > > > > > >>>> > > > > > > > > >>>>difficult to > > > > > > > > >>>> > > > > > > > > >>>> > > > > > > > > >>>>>parse, the latter is semanticful but link local > > > > > > > > >>>>> > > > > > > > > >>>>>now, i don't specifically see what has > > changed the late > > > > 90's, > > > > > > > early > > > > > > > > >>>>>y2k's, to have a change in the wavelength label > > > > definition; > > > > > > > > >>>> > > > > > > > > >>>>This is the question I would like to get to the bottom > > of. > > > > In > > > > > > > > >>>>other words: > > > > > > > > >>>>do we need this function? > > > > > > > > >>>> > > > > > > > > >>>>It seems to me that the question being asked is this: > > > > > > > > >>>> > > > > > > > > >>>> If I want to compute a path that has some form of > > > > wavelength > > > > > > > > >>>> constraints, what information do I need access to? > > > > > > > > >>>> > > > > > > > > >>>>Another question might be: > > > > > > > > >>>> > > > > > > > > >>>> If I want to signal a path with wavelength > > constraints > > > > what > > > > > > > > >>>> information do I need to include in the > > > > signaling message? > > > > > > > > >>>> > > > > > > > > >>>> > > > > > > > > >>>>I'd suggest that when we started on GMPLS, we were > > > > > > > > >> > > > > > > > > >>enthusiastic about > > > > > > > > >> > > > > > > > > >>>>transparent optical networks, but we were not properly > > > > > > > > >>>>focusing wavelength > > > > > > > > >>>>constraints because lambda-switching PXCs didn't take > > off. > > > > > > > > >>>>Therefore we > > > > > > > > >>>>didn't examine the requirements for wavelength > > constraints > > > > in > > > > > > > > >>>>routing and > > > > > > > > >>>>signaling. The authors of this I-D are claiming > > > > new hardware > > > > > > > > >>>>requirements > > > > > > > > >>>>for the same function. > > > > > > > > >>>> > > > > > > > > >>>> > > > > > > > > >>>> > > > > > > > > >>>>>there are > > > > > > > > >>>>>several solution possible > > > > > > > > >>>>> > > > > > > > > >>>>>- absolute values: the freq. of the wavelength: > > difficult > > > > to > > > > > > > adopt > > > > > > > > >>>>>because referenced values are nominal and knowing all > > > > > > > interactions > > > > > > > > >>>>>between wavelengths this knowledge is at the end > > > > of little > > > > > > > > >> > > > > > > > > >>practical > > > > > > > > >> > > > > > > > > >>>>>usage; (introduces implicit ordering) > > > > > > > > >>>>> > > > > > > > > >>>>>- indexed values: the # of the wavelength: > > it does not > > > > > > > > >> > > > > > > > > >>provide for a > > > > > > > > >> > > > > > > > > >>>>>future proof label space for inst. in case new > > > > frequencies > > > > > > > > >>>> > > > > > > > > >>>>are inserted > > > > > > > > >>>> > > > > > > > > >>>> > > > > > > > > >>>>>in the grid (introduces explicit ordering) > > > > > > > > >>>>> > > > > > > > > >>>>>- diff. values e.g. freq spacing starting from a > > > > reference > > > > > > > > >>>> > > > > > > > > >>>>value: pauses > > > > > > > > >>>> > > > > > > > > >>>> > > > > > > > > >>>>>the question of the reference value and does suffer > > from > > > > the > > > > > > > former > > > > > > > > >>>>>issue (introduces implicit ordering) > > > > > > > > >>>>> > > > > > > > > >>>>>- the solution available today - cumbersome in some > > > > > > > control plane > > > > > > > > >>>>>operations (e.g. label set translation) and > > not easy to > > > > > > > > >>>> > > > > > > > > >>>>troubleshoot but > > > > > > > > >>>> > > > > > > > > >>>> > > > > > > > > >>>>>independent of any physical consideration > > > > (spectral), scale > > > > > to > > > > > > > any > > > > > > > > >>>>>number of wavelength per fiber, does not > > introduce any > > > > > > > > >> > > > > > > > > >>ordering, the > > > > > > > > >> > > > > > > > > >>>>>most flexible (since allowing each system to maintain > > its > > > > > > > specific > > > > > > > > >>>>>control operations) and the less constraining since > > > > > maintaining > > > > > > > the > > > > > > > > >>>>>control plane operations independent of any > > data plane > > > > > > > specifics > > > > > > > > >>>>> > > > > > > > > >>>>> > > > > > > > > >>>> > > > > > > > > > > > > >>>> > > > > > > > >>> > > > > > > > > >>>ambda-labels > > > > > > > > >>>-00.txt> > > > > > > > > >>> > > > > > > > > >>>. > > > > > > > > >>> > > > > > > > > >> > > > > > > > > > > > > > > > > > > . > > > > > > > > > > > > > > > > > > > > > > From owner-ccamp@ops.ietf.org Mon Oct 31 14:09:50 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWf2T-0005Kj-UU for ccamp-archive@megatron.ietf.org; Mon, 31 Oct 2005 14:09:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00246 for ; Mon, 31 Oct 2005 14:09:30 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EWfGi-0008Mx-E8 for ccamp-archive@ietf.org; Mon, 31 Oct 2005 14:24:33 -0500 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EWeww-000JQ4-R8 for ccamp-data@psg.com; Mon, 31 Oct 2005 19:04:06 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [70.158.43.219] (helo=jera.movaz.com) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EWews-000JPi-6j for ccamp@ops.ietf.org; Mon, 31 Oct 2005 19:04:05 +0000 Received: from ib (unknown [172.16.24.122]) by jera.movaz.com (Postfix) with SMTP id 17285ABA8; Mon, 31 Oct 2005 14:03:57 -0500 (EST) Message-ID: <018101c5de4d$d86d3190$7a1810ac@movaz.com> From: "Igor Bryskin" To: , Cc: , "Drake, John E" , "Zafar Ali (zali)" , "Igor Bryskin" , , "Kim Young Hwa" , References: <626FC7C6A97381468FB872072AB5DDC8369714@XCH-SW-42.sw.nos.boeing.com> <00b201c5de24$c20fc710$7a1810ac@movaz.com> <436639BA.6040405@psg.com> <011a01c5de33$4fc053f0$7a1810ac@movaz.com> <43664BBF.8030704@psg.com> <015b01c5de3e$f2a2a090$7a1810ac@movaz.com> <43665728.6030003@psg.com> Subject: Re: Two Drafts for Resilience of Control Plane Date: Mon, 31 Oct 2005 14:03:57 -0500 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: 9cc83ac38bbbabacbf00f656311dd8d8 Content-Transfer-Encoding: 7bit Dimitri, Let me try once more. > igor > > > Suppose you have LSP going through -A-B-C- and a controller managing node B > > fails, while the data plane is intact, that is, no data plane alarms are > > detected. > > > > According to your logic such situation can exist only for 90c, because once > > controller managing node C detects the absence of 3 Path refreshes it will > > delete the control plane and destroy the service. My question is why do you > > need the RSVP graceful restart procedures then if they can happen only > > within 90c time interval - after that there will be nothing to synchronize. > > > > What we see and hear in the field, though, that a controller may stay days > > out of service and then come back and should be capable to synchronize the > > control state of all LSPs it used to manage before the crash/reboot. And, of > > course, you MUST maintain data service up and running. > > i have never said the contrary, if you run an (independent) cp failure > detection mechanism and prior negotiated cp recovery: in case of failure > in CP => GR (see RFC 3471/3) ... you are the one trying to find protocol > deficiencies while it is still totally unclear to me (but i am not the > only one apparently) where they these limitations (potentially) are ? > > on one side, you ask how to free costly resources and on the other you > ask how to maintain the connection service ... IB>>Do you believe the two requirements contradict each other? I don't think so > on one side, you ask how to free costly resources ==>only if the user decides to do so > and on the other you > ask how to maintain the connection service ... ==>only if the user decides to do so at the end, you should > decide what you want to do - i am not sure that you have understood that > you can have both at the same time IB>> 1. Yes, I do have an independent dp (not cp as you say) failure detection mechanism 2. Yes, I do negotiate with my neighbors not to drop state in case of cp failure 3. Yes, I want to control my LSP in such state from a *single* (LSP ingress) point, because when an LSP is created by a user (via say UNI or management plane) it is totally up to user to decide what to do with the LSP when CP fails. The only way the user can control this is by sending another request(s) to the LSP ingress controller (not to egress or any transit controller because the user may not even know their IDs). In particular, the user may decide to continue using the service (after all it is still carrying its traffic), but in this case the user would want to maintain control of the LSP (for example, he may want to get notifications about data plane alarms detected on the nodes beyond point of CP failure, likewise, he may want to modify the LSP's admin status, setup/holding priorities, etc.) Alternatively, he may decide to delete or reroute it. Still in any case the user wants to control/convey its decision only to the LSP ingress controller. 4. No. I can not do this today because of the deficiency of RSVP - messages on a contiguous LSP are sent on a hop-by-hop basis, meaning that any hop can block the message 5. Yes, I do have a simple and totally backward compatible solution how to overcome these deficiencies. Igor > > > Igor > > > > ----- Original Message ----- > > From: "dimitri papadimitriou" > > To: "Igor Bryskin" > > Cc: ; "Drake, John E" > > ; "Zafar Ali (zali)" ; "Igor > > Bryskin" ; ; "Kim Young Hwa" > > ; > > Sent: Monday, October 31, 2005 11:52 AM > > Subject: Re: Two Drafts for Resilience of Control Plane > > > > > > > >>igor - > >> > >>Igor Bryskin wrote: > >> > >>>Dimitri, > >>> > >>> > >>>>igor - my two cents > >>>> > >>>>RSVP over time has progressively borrowed mechanisms from "hard-state" > >>>>protocols, explicit deletion using PathTear is most noticeable and > >>>>initial example of this evolution ! > >>>> > >>>>but in any case, RSVP still relies is on idem-potent soft-states that > >>>>are flushed when not refreshed after certain time interval (or self- > >>>>maintained if previously negotiated) this prevents orphans in the > >>>>network (so unused resources) and provides for resilience - hence there > >>>>is by no means a need to introduce an additional protocol mechanism to > >>>>trigger or not such event via the "control plane" - > >>> > >>> > >>>Refreshes are useful mechanism but only between neighbors that maintain > >>>Hello communication. In this case the absence of Path refreshes is as > > > > good > > > >>>indication that data plane must be destroyed as received PathTear > > > > message. > > > >>the base function of state refresh and usefulness is independent of > >>hello adjacency maintenance (or any other control channel maintenance) > >> > >> > >>>However, when a controller does not receive Path refreshes from a > > > > neighbor > > > >>>it does not have any control plane communication with, it can assume > > > > neither > > > >>>a problem in the data plane nor intention to destroy it. > >> > >>as the node did not negotiate any channel/node fault recovery (due in > >>part. to the absence of Hello adjacency with its neighbor) and if no > >>other independent control channel failure is provided (this is an add-on > >>of RFC3471/3), the simple absence of refresh is simply intepreted as > >>"implicit deletion" > >> > >>you are mis-interpreting the following sentence of RFC3471 > >> > >>" Note that these cases only apply when there are mechanisms to detect > >> data channel failures independent of control channel failures." > >> > >>there is no retro-fit on the use of Refreshes in absence of control > >>channel failure detection mechanism > >> > >> > >>>Hence, as it was > >>>specified in RFC3471, it *must* maintain both control and data plane > > > > states > > > >>>throughout the failure. > >> > >>- d. > >> > >>>Igor > >>> > >>> > >>> > >>>>btw, the paragraph you mention in RFC3471 does not say "soft state > >>>>protocols do not work well for non-packet environments" this is your > >>>>interpretation; > >>>> > >>>>ps: you are still free to make use of RFC3472 in case (as you were > >>>>apparently looking for something else ;-) > >>>> > >>>>Igor Bryskin wrote: > >>>> > >>>> > >>>>>John, > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>>>States are supposed to be destroyed on explicit signalling > >>>>>>>message (e.g. PathTear or PathErr with the state removal > >>>>>>>flag), but not because of the absence of refreshes. > >>>>>>> > >>>>> > >>>>>[JD] > >>>>> > >>>>>Igor, > >>>>> > >>>>>Just to be clear, we are talking about RSVP here, and RSVP *is* a soft > >>>>>state protocol. Can you point to any RFC that supports your statements > >>>>>above? > >>>>> > >>>>>IB>> Oh, come on, John. You sound like you've been yourself in a > > > > dormant > > > >>>>>state for a while :=). We've gone a long way since RFC2205. In RFC3471, > >>> > >>>for > >>> > >>> > >>>>>example, there is a discussion why GMPLS is needed and how is it > >>> > >>>different > >>> > >>> > >>>>>from MPLS. One of the differences is the fact that soft state protocols > >>> > >>>do > >>> > >>> > >>>>>not work well for non-packet environments. Here is from the RDC3471: > >>>>> > >>>>> > >>>>> > >>>>>9.2. Fault Handling There are two new faults that must be handled > >>> > >>>when > >>> > >>> > >>>>>the control channel is independent of the data channel. In the > > > > first, > > > >>>>>there is a link or other type of failure that limits the ability of > >>>>>neighboring nodes to pass control messages. In this situation, > >>>>>neighboring nodes are unable to exchange control messages for a > > > > period > > > >>>of > >>> > >>> > >>>>>time. Once communication is restored the underlying signaling > >>> > >>>protocol > >>> > >>> > >>>>>must indicate that the nodes have maintained their state through the > >>>>>failure.. > >>>>> > >>>>>What is more important is the reality of life: The customers simply say > >>> > >>>that > >>> > >>> > >>>>>you cannot destroy a user service (or even force any traffic hits) just > >>>>>because you have a problem in the control plane. If this does not fit > >>> > >>>your > >>> > >>> > >>>>>soft-state paradigm, than "harden" your protocols or flash them down > > > > the > > > >>>>>toilet and come with something else if you want our business. After > > > > all, > > > >>>if > >>> > >>> > >>>>>we provision the services via NMS, we do not have to destroy the > >>> > >>>services if > >>> > >>> > >>>>>we have problems in the management network. It is that simple. > >>>>> > >>>>> > >>>>> > >>>>>Igor > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>. > >>>>> > >>> > >>> > >>> > >>> > >>>. > >>> > > > > > > > > > > . > > From owner-ccamp@ops.ietf.org Mon Oct 31 14:26:03 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWfI9-00017m-Fc for ccamp-archive@megatron.ietf.org; Mon, 31 Oct 2005 14:26:03 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01282 for ; Mon, 31 Oct 2005 14:25:42 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EWfWN-0000vp-DD for ccamp-archive@ietf.org; Mon, 31 Oct 2005 14:40:44 -0500 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EWfD0-000KKI-DC for ccamp-data@psg.com; Mon, 31 Oct 2005 19:20:42 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [70.158.43.219] (helo=jera.movaz.com) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EWfCy-000KJn-TY for ccamp@ops.ietf.org; Mon, 31 Oct 2005 19:20:41 +0000 Received: from ib (unknown [172.16.24.122]) by jera.movaz.com (Postfix) with SMTP id AA8D7286A4; Mon, 31 Oct 2005 14:20:39 -0500 (EST) Message-ID: <019c01c5de50$2e0d7130$7a1810ac@movaz.com> From: "Igor Bryskin" To: "Drake, John E" , , , Cc: , , , , References: <626FC7C6A97381468FB872072AB5DDC836971D@XCH-SW-42.sw.nos.boeing.com> Subject: Re: Two Drafts for Resilience of Control Plane Date: Mon, 31 Oct 2005 14:20:39 -0500 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: 41c17b4b16d1eedaa8395c26e9a251c4 Content-Transfer-Encoding: 7bit John, > > No John, > > This is not true, I gave you a very specific problem - provide mechanisms > to > manage LSPs with impaired control plane (when one or more controllers are > out of service). > You said that this is not a problem, because RSVP is a soft state protocol > and once there are no refreshes the control data plane states must be > destroyed and hence there is nothing to manage. > And I tried very hard to explain you why this is not acceptable and hence > must be addressed. [JD] Actually, I didn't say that. What I said was that in your example, PathTear and PathError with state removed should work just fine. IB>> This would require node D, for example, to know exactly what to do with the service when it gets notified about the CP failure. Policies do not work here. It's totally upto user to decide what to do with this service. The only way it can convey this decision is by sending more requests to the LSP ingress controller. For instance, the user may decide to keep using the service for a while and then delete or reroute it before the controller B comes back. Neither of your options below therefore works. See also my response to Dimitri. Igor Due to 'CP degraded' notification, nodes C and D will know that B failed. In option a), local policy, configured via the NMS, at D will tell it whether to send a PathErr with state removed and if so, how long to wait. As stated in another e-mail, multiple CP failures are handled by configuration, via the NMS, at intermediate nodes that tell them under what circumstances and after what duration to send PathTear and /or PathErr with state removed, or whether simply to wait until the resources time-out and how long to wait before timing them out. In option b) A creates an MBB LSP on the path A, E, F, H, K, D. Subsequently, A sends a PathTear to B, and D sends a PathErr with state removed to C. The MBB LSP was created under policy control, via the NMS, at the ingress node, A. Here's your initial example: A----B------C-----D | | E-----F-----H-----K > I have a solution and am planning to write a draft. I'd like this work to > live in CCAMP. [JD] You can't get pre-approval of an I-D. > > Igor From owner-ccamp@ops.ietf.org Mon Oct 31 14:45:18 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWfan-0006Ak-Rb for ccamp-archive@megatron.ietf.org; Mon, 31 Oct 2005 14:45:18 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03226 for ; Mon, 31 Oct 2005 14:44:58 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EWfp2-00027z-Dl for ccamp-archive@ietf.org; Mon, 31 Oct 2005 15:00:01 -0500 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EWfVa-000LCW-V2 for ccamp-data@psg.com; Mon, 31 Oct 2005 19:39:54 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-4.8 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from localhost ([127.0.0.1]) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EWfVZ-000LC9-L2; Mon, 31 Oct 2005 19:39:54 +0000 Message-ID: <43667307.1000808@psg.com> Date: Mon, 31 Oct 2005 20:39:51 +0100 From: dimitri papadimitriou Reply-To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.11) Gecko/20050728 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Igor Bryskin CC: dimitri.papadimitriou@alcatel.be, "Drake, John E" , "Zafar Ali (zali)" , Igor Bryskin , drake@movaz.com, Kim Young Hwa , ccamp@ops.ietf.org Subject: Re: Two Drafts for Resilience of Control Plane References: <626FC7C6A97381468FB872072AB5DDC8369714@XCH-SW-42.sw.nos.boeing.com> <00b201c5de24$c20fc710$7a1810ac@movaz.com> <436639BA.6040405@psg.com> <011a01c5de33$4fc053f0$7a1810ac@movaz.com> <43664BBF.8030704@psg.com> <015b01c5de3e$f2a2a090$7a1810ac@movaz.com> <43665728.6030003@psg.com> <018101c5de4d$d86d3190$7a1810ac@movaz.com> In-Reply-To: <018101c5de4d$d86d3190$7a1810ac@movaz.com> 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: 32a65c0bf5eb4ec26489239c7cdd0636 Content-Transfer-Encoding: 7bit Igor [snip] > 1. Yes, I do have an independent dp (not cp as you say) failure detection > mechanism not sure what's so specific here from a base SONET/SDH GMPLS control > 2. Yes, I do negotiate with my neighbors not to drop state in case of cp > failure ok > 3. Yes, I want to control my LSP in such state from a *single* (LSP ingress) > point, because when an LSP is created by a user (via say UNI or management > plane) it is totally up to user to decide what to do with the LSP when CP > fails. The only way the user can control this is by sending another > request(s) to the LSP ingress controller (not to egress or any transit > controller because the user may not even know their IDs). In particular, the > user may decide to continue using the service (after all it is still > carrying its traffic), but in this case the user would want to maintain > control of the LSP (for example, he may want to get notifications about data > plane alarms detected on the nodes beyond point of CP failure, likewise, he > may want to modify the LSP's admin status, setup/holding priorities, etc.) > Alternatively, he may decide to delete or reroute it. Still in any case the > user wants to control/convey its decision only to the LSP ingress > controller. you have many specific requirements but i really don't see here what's so specific here in terms of resiliency of existing cp mechanisms; you should probably try to find another name for this kind of feature here as using 'resiliency' is rather confusing btw, if your data plane is up i am not sure which kind of alarms you may want to receive and/or if there is something preventing you as of today to receive these alarms at the sender side ? > 4. No. I can not do this today because of the deficiency of RSVP - messages > on a contiguous LSP are sent on a hop-by-hop basis, meaning that any hop can > block the message just a simple comment are you sure that in such a degraded state the user is willing to make so many/various operations on its LSPs - i mean beside service availability and base maintenance operations ? would be nice to have a bit more feedback on this specific aspect > 5. Yes, I do have a simple and totally backward compatible solution how to > overcome these deficiencies. ok ... i think right time for you to write a draft about it note: don't forget to provide a complete motivation section, as well as why RSVP mechanisms/others would not be sufficient as this may seriously help assessing the value of your proposal > Igor > > > > > >>>Igor >>> >>>----- Original Message ----- >>>From: "dimitri papadimitriou" >>>To: "Igor Bryskin" >>>Cc: ; "Drake, John E" >>>; "Zafar Ali (zali)" ; "Igor >>>Bryskin" ; ; "Kim Young Hwa" >>>; >>>Sent: Monday, October 31, 2005 11:52 AM >>>Subject: Re: Two Drafts for Resilience of Control Plane >>> >>> >>> >>> >>>>igor - >>>> >>>>Igor Bryskin wrote: >>>> >>>> >>>>>Dimitri, >>>>> >>>>> >>>>> >>>>>>igor - my two cents >>>>>> >>>>>>RSVP over time has progressively borrowed mechanisms from "hard-state" >>>>>>protocols, explicit deletion using PathTear is most noticeable and >>>>>>initial example of this evolution ! >>>>>> >>>>>>but in any case, RSVP still relies is on idem-potent soft-states that >>>>>>are flushed when not refreshed after certain time interval (or self- >>>>>>maintained if previously negotiated) this prevents orphans in the >>>>>>network (so unused resources) and provides for resilience - hence > > there > >>>>>>is by no means a need to introduce an additional protocol mechanism to >>>>>>trigger or not such event via the "control plane" - >>>>> >>>>> >>>>>Refreshes are useful mechanism but only between neighbors that maintain >>>>>Hello communication. In this case the absence of Path refreshes is as >>> >>>good >>> >>> >>>>>indication that data plane must be destroyed as received PathTear >>> >>>message. >>> >>> >>>>the base function of state refresh and usefulness is independent of >>>>hello adjacency maintenance (or any other control channel maintenance) >>>> >>>> >>>> >>>>>However, when a controller does not receive Path refreshes from a >>> >>>neighbor >>> >>> >>>>>it does not have any control plane communication with, it can assume >>> >>>neither >>> >>> >>>>>a problem in the data plane nor intention to destroy it. >>>> >>>>as the node did not negotiate any channel/node fault recovery (due in >>>>part. to the absence of Hello adjacency with its neighbor) and if no >>>>other independent control channel failure is provided (this is an add-on >>>>of RFC3471/3), the simple absence of refresh is simply intepreted as >>>>"implicit deletion" >>>> >>>>you are mis-interpreting the following sentence of RFC3471 >>>> >>>>" Note that these cases only apply when there are mechanisms to detect >>>> data channel failures independent of control channel failures." >>>> >>>>there is no retro-fit on the use of Refreshes in absence of control >>>>channel failure detection mechanism >>>> >>>> >>>> >>>>>Hence, as it was >>>>>specified in RFC3471, it *must* maintain both control and data plane >>> >>>states >>> >>> >>>>>throughout the failure. >>>> >>>>- d. >>>> >>>> >>>>>Igor >>>>> >>>>> >>>>> >>>>> >>>>>>btw, the paragraph you mention in RFC3471 does not say "soft state >>>>>>protocols do not work well for non-packet environments" this is your >>>>>>interpretation; >>>>>> >>>>>>ps: you are still free to make use of RFC3472 in case (as you were >>>>>>apparently looking for something else ;-) >>>>>> >>>>>>Igor Bryskin wrote: >>>>>> >>>>>> >>>>>> >>>>>>>John, >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>>>States are supposed to be destroyed on explicit signalling >>>>>>>>>message (e.g. PathTear or PathErr with the state removal >>>>>>>>>flag), but not because of the absence of refreshes. >>>>>>>>> >>>>>>> >>>>>>>[JD] >>>>>>> >>>>>>>Igor, >>>>>>> >>>>>>>Just to be clear, we are talking about RSVP here, and RSVP *is* a > > soft > >>>>>>>state protocol. Can you point to any RFC that supports your > > statements > >>>>>>>above? >>>>>>> >>>>>>>IB>> Oh, come on, John. You sound like you've been yourself in a >>> >>>dormant >>> >>> >>>>>>>state for a while :=). We've gone a long way since RFC2205. In > > RFC3471, > >>>>>for >>>>> >>>>> >>>>> >>>>>>>example, there is a discussion why GMPLS is needed and how is it >>>>> >>>>>different >>>>> >>>>> >>>>> >>>>>>>from MPLS. One of the differences is the fact that soft state > > protocols > >>>>>do >>>>> >>>>> >>>>> >>>>>>>not work well for non-packet environments. Here is from the RDC3471: >>>>>>> >>>>>>> >>>>>>> >>>>>>>9.2. Fault Handling There are two new faults that must be handled >>>>> >>>>>when >>>>> >>>>> >>>>> >>>>>>>the control channel is independent of the data channel. In the >>> >>>first, >>> >>> >>>>>>>there is a link or other type of failure that limits the ability of >>>>>>>neighboring nodes to pass control messages. In this situation, >>>>>>>neighboring nodes are unable to exchange control messages for a >>> >>>period >>> >>> >>>>>of >>>>> >>>>> >>>>> >>>>>>>time. Once communication is restored the underlying signaling >>>>> >>>>>protocol >>>>> >>>>> >>>>> >>>>>>>must indicate that the nodes have maintained their state through > > the > >>>>>>>failure.. >>>>>>> >>>>>>>What is more important is the reality of life: The customers simply > > say > >>>>>that >>>>> >>>>> >>>>> >>>>>>>you cannot destroy a user service (or even force any traffic hits) > > just > >>>>>>>because you have a problem in the control plane. If this does not fit >>>>> >>>>>your >>>>> >>>>> >>>>> >>>>>>>soft-state paradigm, than "harden" your protocols or flash them down >>> >>>the >>> >>> >>>>>>>toilet and come with something else if you want our business. After >>> >>>all, >>> >>> >>>>>if >>>>> >>>>> >>>>> >>>>>>>we provision the services via NMS, we do not have to destroy the >>>>> >>>>>services if >>>>> >>>>> >>>>> >>>>>>>we have problems in the management network. It is that simple. >>>>>>> >>>>>>> >>>>>>> >>>>>>>Igor >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>. >>>>>>> >>>>> >>>>> >>>>> >>>>> >>>>>. >>>>> >>> >>> >>> >>> >>>. >>> > > > > > . > From owner-ccamp@ops.ietf.org Mon Oct 31 15:29:39 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWgHi-0007q8-Ue for ccamp-archive@megatron.ietf.org; Mon, 31 Oct 2005 15:29:39 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05881 for ; Mon, 31 Oct 2005 15:29:19 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EWgVt-0007MG-1g for ccamp-archive@ietf.org; Mon, 31 Oct 2005 15:44:22 -0500 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EWgBN-000N9w-63 for ccamp-data@psg.com; Mon, 31 Oct 2005 20:23:05 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [12.47.115.93] (helo=mailsrv01.vasw) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1EWgBK-000N9e-Nc; Mon, 31 Oct 2005 20:23:03 +0000 Received: from NETPTORAB (net-torab.vasw [192.168.254.48]) by mailsrv01.vasw (8.13.1/8.13.1) with SMTP id j9VKJRBG006887; Mon, 31 Oct 2005 15:19:27 -0500 From: "Payam Torab" To: "'Drake, John E'" , "'Shiba, Sidney'" , Cc: "'Adrian Farrel'" , , Subject: RE: comments on draft-shiba-ccamp-gmpls-lambda-labels-00.txt Date: Mon, 31 Oct 2005 15:22:07 -0500 Message-ID: <011001c5de58$c4c09190$30fea8c0@NETPTORAB> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0111_01C5DE2E.DBEA8990" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.6604 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 In-Reply-To: <626FC7C6A97381468FB872072AB5DDC836971E@XCH-SW-42.sw.nos.boeing.com> X-MS-TNEF-Correlator: 00000000DF91DC056F78C244BF1B5659AD723CE6046A2400 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: f9c0d585568a86447c98453afdf94aa0 This is a multi-part message in MIME format. ------=_NextPart_000_0111_01C5DE2E.DBEA8990 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit John- So, with bundling out of the picture, we have closure: - If there is no real difference between multiple parallel channels of the same wavelength, we may want to combine these channels into a single TE link for scalability and crankback benefits. In this case, there will be a clash in the lambda label space if the label is going to have a purely spectral meaning. - If these parallel channels have different properties to the extent that one wants to bind an LSP to a particular channel, then combining (and obviously bundling) is not an option anyway. Thanks, Payam -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On Behalf Of Drake, John E Sent: Monday, October 31, 2005 11:58 AM To: Payam Torab; Shiba, Sidney; dpapadimitriou@psg.com Cc: Adrian Farrel; richard.rabbat@us.fujitsu.com; ccamp@ops.ietf.org Subject: RE: comments on draft-shiba-ccamp-gmpls-lambda-labels-00.txt > -----Original Message----- > From: Payam Torab [mailto:ptorab@lopsys.com] > Sent: Monday, October 31, 2005 8:12 AM > To: Drake, John E; 'Shiba, Sidney'; dpapadimitriou@psg.com > Cc: 'Adrian Farrel'; richard.rabbat@us.fujitsu.com; ccamp@ops.ietf.org > Subject: RE: comments on draft-shiba-ccamp-gmpls-lambda-labels-00.txt > > John- > > Obviously the benefits or harms of giving a global meaning to a lambda > label requires study, but your particular example is not a good one: If > one really wants to have a preference for a specific wavelength channel > among multiple parallel channels of the same wavelength, bundling should > not be exercised in the first place. [JD] It isn't bundling. LMP allows one to configure two or more parallel WDM systems into a single TE link. One reason for doing this is to improve the scalability of the TE LSB. Another is to reduce crankback (see below). If this done, you would have multiple instances of each of the wavelengths supported by the WDM systems. You asserted that this is a BadIdea(tm), but it reduces crankback in the network. If you make each parallel WDM system a separate TE link, then you have bound the LSP to the selected TE link. If the selected wavelength is blocked, you have to crankback. If you combine the parallel WDM systems into a single TE link, then the LSP can be progressed on *any* WDM system on which the selected wavelength is available. > > Thanks, > Payam > > -----Original Message----- > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On > Behalf Of Drake, John E > Sent: Monday, October 31, 2005 10:36 AM > To: Shiba, Sidney; dpapadimitriou@psg.com > Cc: Adrian Farrel; richard.rabbat@us.fujitsu.com; ccamp@ops.ietf.org > Subject: RE: comments on draft-shiba-ccamp-gmpls-lambda-labels-00.txt > > > Sidney, > > But there's nothing in your picture that requires an absolute end-end > global wavelength. The existing GMPLS solution with relative > wavelengths of local significance should work just fine. As I said in > my previous note, your method precludes combining two or more parallel > WDM links into a single TE link. > > Thanks, > > John > > > -----Original Message----- > > From: Shiba, Sidney [mailto:sidney.shiba@us.fujitsu.com] > > Sent: Monday, October 31, 2005 7:25 AM > > To: Drake, John E; dpapadimitriou@psg.com > > Cc: Adrian Farrel; richard.rabbat@us.fujitsu.com; ccamp@ops.ietf.org > > Subject: RE: comments on draft-shiba-ccamp-gmpls-lambda-labels-00.txt > > > > Hi John, > > > > Optical switches based on Wavelength Selective Switch (WSS) technology > > requires the wavelength information for switching. This technology is > NOT > > wavelength agnostic. > > > > | | > > | wdm | wdm > > |2 |2 > > --------- --------- > > wdm 1| optical |3 wdm 1| optical |3 wdm > > --------| switch |------------| switch |--------- > > | (WSS) | | (WSS) | > > --------- --------- > > |4 |4 > > | wdm | wdm > > | | > > > > Note that the figure above shows an example of two optical switches > > interconnect > > by a single WDM fiber. In this example, each optical switch can be > connect > > to 4 > > other optical switches. > > > > As you can see, the optical ports information do not provide enough > > information > > for wavelength switching. > > > > Hope that clarifies the application requirement. > > > > Thanks, > > > > Sidney > > > > > -----Original Message----- > > > From: Drake, John E [mailto:John.E.Drake2@boeing.com] > > > Sent: Friday, October 28, 2005 5:33 PM > > > To: dpapadimitriou@psg.com; Shiba, Sidney > > > Cc: Adrian Farrel; richard.rabbat@us.fujitsu.com; ccamp@ops.ietf.org > > > Subject: RE: comments on > draft-shiba-ccamp-gmpls-lambda-labels-00.txt > > > > > > > > > Hi, > > > > > > Below is the text of an e-mail is sent to the Ethernet/GMPLS mailing > > > list. > > > > > > Upon reflection I am not sure using a real wavelength value makes > much > > > sense. Between a pair of adjacent nodes, there may be > > > multiple pairs of > > > switch ports in the same TE link that support a given frequency. If > a > > > real wavelength value is used, how do the two nodes agree on > > > which pair > > > of switch ports to use? > > > > > > Furthermore, the amount of configuration is the same - you > > > still need to > > > configure the wavelength of each switch port. > > > > > > Thanks, > > > > > > John > > > ============================================================== > > > ========== > > > ==== > > > Adrian, > > > > > > In the transparent photonic lambda switch case, the labels also have > > > only local significance. When an LSP is established, the input > ports, > > > as identified with local labels, are cross-connected to the output > > > ports, as identified with local labels. > > > > > > There is just extra configuration to identify, using strictly local > > > identifiers, the wavelength associated with the all of the switch's > > > ports, and an additional CAC requirement that the wavelengths of the > > > input and output ports are the same. > > > > > > Thanks, > > > > > > John > > > > > > > > > > -----Original Message----- > > > > From: dimitri papadimitriou [mailto:dpapadimitriou@psg.com] > > > > Sent: Thursday, October 27, 2005 10:03 AM > > > > To: Shiba, Sidney > > > > Cc: dimitri.papadimitriou@alcatel.be; Adrian Farrel; > > > > richard.rabbat@us.fujitsu.com; ccamp@ops.ietf.org > > > > Subject: Re: comments on > > > draft-shiba-ccamp-gmpls-lambda-labels-00.txt > > > > > > > > shiba - see inline for some additional hints: > > > > > > > > >>Shiba, Sidney wrote: > > > > >> > > > > >>>Adrian, Dimitri, > > > > >>> > > > > >>>Thanks for reviewing these I-D. > > > > >>> > > > > >>>Wavelength continuity constraint does require the use of > > > semanticful > > > > >>>label whether it is spectral or index. > > > > >> > > > > >>=> see my reply to adrian on this specific point > > > > >> > > > > >>>I agree with Dimitri that the > > > > >>>wavelength indexing requires document updating each time a new > > > > >>>spectrum is introduced. > > > > >> > > > > >>=> indeed and in addition it requires updating the already > > > > >>signaled path > > > > >> > > > > >>>The use of spectral label provides self maintainance, i.e., > > > > >>>no need to update any document and the use of the nominal value > > > > >>>provides a common semantic ground. > > > > >> > > > > >>=> what do you mean by self-maintenance - would you provide a > > > > >>bit more detail > > > > > > > > > > [Sidney]What I've meant here was that it was not necessary to > > > > > update any document when new wavelengths are inventoried. In the > > > > > case of indexing approach, it would require the > > > wavelength indexing > > > > > document to be updated with implementation impacts. > > > > > > > > > > In the case, the nominal value is used, there is no need for > > > > > documentation update. > > > > > > > > ok - what you mean here is that you are going to make use of the > > > already > > > > defined C-Type 2 - what about the specific encoding of the > > > value space > > > ? > > > > > > > > >>=> now i have a more specific question before being light-up > > > > >>how do you know the frequency that you can support ? > > > > > > > > > > [Sidney] Some new technologies integrate optical switch and > > > mux/demux > > > > > capabilities, which allows the equipment to know the spectrum it > > > > supports. > > > > > > > > indeed - but the question is what does happen if the > > > "detected" values > > > > (during initialization) do not match the nominal values ? you > don't > > > > initialize then ? > > > > > > > > >>if these differ from the nominal values how are you going to > deal > > > with > > > > these > > > > >>discrepancies ? > > > > > > > > > > [Sidney] These new technologies uses the nominal value as > > > reference. > > > We > > > > can say > > > > > that a lightpath wavelength is identified by its nominal value. > If > > > the > > > > equipment > > > > > is drifting from this nominal value, it is considered as > > > a failure. > > > > > > > > ok - but if the deviation is such you have overlap - how the > control > > > > plane is going to be able to detect such failure ? > > > > > > > > >>this said i am not necessarily sure that having to > > > maintain the data > > > > plane > > > > >>specifics as part of the control plane is really helping > > > > >>operations (is this method not just duplicating complexity ?) > > > > > > > > > > [Sidney] The wavelength is WDM specific as much as the SUKLM > label > > > > encoding > > > > > is for SONET. The wavelegth/frequency nominal value is used to > > > identify > > > > the > > > > > facilities to cross-connect. > > > > > > > > there is an equivalence but there is also a major difference, the > > > > structure is invariant independently of the state of the > > > network, with > > > > spectral value space you may have labels that become unavailable > due > > > to > > > > non-local usage of wavelength in the network > > > > > > > > hence, there is also no real coupling to the data plane more than > > > > knowing the type of interface and some generic capabilities > > > > > > > > >>>I'm not sure if the draft needs to be updated before the > > > > >>>face-to-face meeting or after all comments are collected. > Please > > > > advise. > > > > >> > > > > >>=> suggest to keep discussion on - document update can be > > > > >>performed at a later stage > > > > > > > > thanks, > > > > - dimitri. > > > > > > > > >>>>-----Original Message----- > > > > >>>>From: owner-ccamp@ops.ietf.org > > > [mailto:owner-ccamp@ops.ietf.org]On > > > > >>>>Behalf Of Adrian Farrel > > > > >>>>Sent: Thursday, October 27, 2005 4:45 AM > > > > >>>>To: dpapadimitriou@psg.com; dimitri.papadimitriou@alcatel.be; > > > > >>>>ccamp@ops.ietf.org > > > > >>>>Subject: Re: comments on > > > > >> > > > > >>draft-shiba-ccamp-gmpls-lambda-labels-00.txt > > > > >> > > > > >>>> > > > > >>>>Dimitri, > > > > >>>> > > > > >>>>Thanks for your work reviewing these recent I-Ds. It is > > > > >>>>really valuable > > > > >>>>and I'd welcome other people doing similar reviews. > > > > >>>> > > > > >>>> > > > > >>>> > > > > >>>>>there is a specific point to be clarified in this document: > > > > >>>>> > > > > >>>>>semanticless vs semanticful label (even here there is a > > > distinction > > > > >>>>>between spectral vs indexes i.e. using the wavelength index) > > > > >>>>> > > > > >>>>>domain-wide vs link local significant label > > > > >>>> > > > > >>>>Without being too picky, I think all labels are semanticful > > > > >>>>otherwise, we > > > > >>>>would not know what resource they refered to. > > > > >>>> > > > > >>>>So the point reduces to whether the scope of the semantics > > > > >>>>are link-local > > > > >>>>or wider. > > > > >>>> > > > > >>>> > > > > >>>> > > > > >>>>>so, the comparison from this perspective with TDM labels is > > > > >>>> > > > > >>>>difficult to > > > > >>>> > > > > >>>> > > > > >>>>>parse, the latter is semanticful but link local > > > > >>>>> > > > > >>>>>now, i don't specifically see what has changed the late 90's, > > > early > > > > >>>>>y2k's, to have a change in the wavelength label definition; > > > > >>>> > > > > >>>>This is the question I would like to get to the bottom of. In > > > > >>>>other words: > > > > >>>>do we need this function? > > > > >>>> > > > > >>>>It seems to me that the question being asked is this: > > > > >>>> > > > > >>>> If I want to compute a path that has some form of wavelength > > > > >>>> constraints, what information do I need access to? > > > > >>>> > > > > >>>>Another question might be: > > > > >>>> > > > > >>>> If I want to signal a path with wavelength constraints what > > > > >>>> information do I need to include in the signaling message? > > > > >>>> > > > > >>>> > > > > >>>>I'd suggest that when we started on GMPLS, we were > > > > >> > > > > >>enthusiastic about > > > > >> > > > > >>>>transparent optical networks, but we were not properly > > > > >>>>focusing wavelength > > > > >>>>constraints because lambda-switching PXCs didn't take off. > > > > >>>>Therefore we > > > > >>>>didn't examine the requirements for wavelength constraints in > > > > >>>>routing and > > > > >>>>signaling. The authors of this I-D are claiming new hardware > > > > >>>>requirements > > > > >>>>for the same function. > > > > >>>> > > > > >>>> > > > > >>>> > > > > >>>>>there are > > > > >>>>>several solution possible > > > > >>>>> > > > > >>>>>- absolute values: the freq. of the wavelength: difficult to > > > adopt > > > > >>>>>because referenced values are nominal and knowing all > > > interactions > > > > >>>>>between wavelengths this knowledge is at the end of little > > > > >> > > > > >>practical > > > > >> > > > > >>>>>usage; (introduces implicit ordering) > > > > >>>>> > > > > >>>>>- indexed values: the # of the wavelength: it does not > > > > >> > > > > >>provide for a > > > > >> > > > > >>>>>future proof label space for inst. in case new frequencies > > > > >>>> > > > > >>>>are inserted > > > > >>>> > > > > >>>> > > > > >>>>>in the grid (introduces explicit ordering) > > > > >>>>> > > > > >>>>>- diff. values e.g. freq spacing starting from a reference > > > > >>>> > > > > >>>>value: pauses > > > > >>>> > > > > >>>> > > > > >>>>>the question of the reference value and does suffer from the > > > former > > > > >>>>>issue (introduces implicit ordering) > > > > >>>>> > > > > >>>>>- the solution available today - cumbersome in some > > > control plane > > > > >>>>>operations (e.g. label set translation) and not easy to > > > > >>>> > > > > >>>>troubleshoot but > > > > >>>> > > > > >>>> > > > > >>>>>independent of any physical consideration (spectral), scale > to > > > any > > > > >>>>>number of wavelength per fiber, does not introduce any > > > > >> > > > > >>ordering, the > > > > >> > > > > >>>>>most flexible (since allowing each system to maintain its > > > specific > > > > >>>>>control operations) and the less constraining since > maintaining > > > the > > > > >>>>>control plane operations independent of any data plane > > > specifics > > > > >>>>> > > > > >>>>> > > > > >>>> > > > > >>>> > > > >>> > > > > >>>ambda-labels > > > > >>>-00.txt> > > > > >>> > > > > >>>. > > > > >>> > > > > >> > > > > > > > > > > . > > > > > > > > ------=_NextPart_000_0111_01C5DE2E.DBEA8990 Content-Type: application/ms-tnef; name="winmail.dat" Content-Disposition: attachment; filename="winmail.dat" Content-Transfer-Encoding: base64 eJ8+IggUAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEGgAMADgAAANUHCgAfAA8AFgAAAAEAKwEB A5AGAPwfAAAlAAAACwACAAEAAAALACMAAAAAAAMAJgAAAAAACwApAAAAAAADAC4AAAAAAAMANgAA AAAAHgBwAAEAAAA5AAAAY29tbWVudHMgb24gZHJhZnQtc2hpYmEtY2NhbXAtZ21wbHMtbGFtYmRh LWxhYmVscy0wMC50eHQAAAAAAgFxAAEAAAAWAAAAAcXeWMPW5nlVR+kNRfaIVY8Or2+BdgAAAgEd DAEAAAAXAAAAU01UUDpQVE9SQUJATE9QU1lTLkNPTQAACwABDgAAAABAAAYOAORsv1jexQECAQoO AQAAABgAAAAAAAAA35HcBW94wkS/G1ZZrXI85sKAAAADABQOAQAAAAsAHw4BAAAAAgEJEAEAAACk GwAAoBsAAPxGAABMWkZ1OHC/fAMACgByY3BnMTI14jIDQ3RleAVBAQMB9/8KgAKkA+QHEwKAD/MA UARWPwhVB7IRJQ5RAwECAGNo4QrAc2V0MgYABsMRJfYzBEYTtzASLBEzCO8J97Y7GB8OMDURIgxg YwBQMwsJAWQzNhZQC6YgShBvaG4tBgBvLCABA/B0aCBidW5kMmwLgGcgCGAFQG9moiAdsGUgcA3g dAhwrmUdcR8AE+B2HwBjF7B6cx9hOgqiCoQKgB0wSQsewxggIAQAIG5vIFMYIAdAIGQGkGYh4W46 Yx8AYhQgH7AJ8CBt6HVsdAUgbB8BCsAHQOckYAMgE9FubiTwBCAetfxzYQeAHYAf8SRgHkAdsPsf kwDAeSZhAjAe0CJgBaD/BtALgB8AHuEUECUYC4An8Y5hJhAeMSRhVEUgHiH8ayACEAXABPAHQAGg AxB3HaAngABwZCAgJLAqwGIvANAq0COAJWBmHaBzLv8hgAOgHbAiIStAFBAdcCHE/wPwJNAjcSnR IDAuAB3AC4B3HtMLYAbQZCngK2Ek8XM/CrAjUQaQL9UwsiIhZ2+vHjIn8R/jKeBwH2FsJ4D7MPAF kHQksSPwIpADAB5Afi4gvyikJJ8f1CLWBUBw/wNgM9AAIAiQBCAn8R7iDsH7OBIdsGEekShxJ6I4 4yhR4ywQA5FMU1An4jMxCsD9JDBjJBAKwSUlLjMDoCgkhR4yKCvyb2J2aQhg9nMzkR3mKSIUBUAD kThwVyQwAiAr4XkmcHk0y1TRJTFrcyw01FAncCYw1zTaIRVEUk8FEGcLgCKhZk0HkCYgZ2VEUzTU RhUDYToeYHclYHItY/ErQG1wQDhwLUAIkAAwdi4FsB5QWwDAAxAn8DozRr9HxV1PC5A040JlVRPg bB7ATx7ARCSwa/MfgRzyIEU01AZgAjBGkNZNAiAwYHkdcE8fQD6QGRKBMzEdcAHQMDUgoDExOjU4 EMBNQbW9SKAgQuMqYAWwAaA7BgBHLbAsgB1wU2lkJWB53VBgZAqwCrAi0G0doAUQPQhgQEeANLAo ITTUQ2PZRpBBZAchA6BGCsAzcWdQYAUQE9JkLlAxLIB0QkA+4C5mdWotIXUXUpJQYEkvZ0xFdWJq 8zPhRpBSRUaQKCEHgDqS60CxU4BhAYAtL4BQoUkU7C1nR0AlgC0wJFrRMLErWsBOUC4M0HQ02j4g /0RfRW1c4EZUT7lINwUwUCK2QBewR4B5LUAoIV1chvNMr028ODoOIE7nXOBPcutLe1BgJ1CLJ1Ff Umtc4P1TMidTe2dRVG9Vf1aPYgX/V+9Y/1oPWx9chlyGHPNynn5PPqce4izWHmAFwBPhbf8lk12A PrAeQSngKjA+kDQoHzu0MCRchjCUGCBxdWnrGCAEIHMfUGRjER3gBUD+eQhhPAoOwEcxJGE/1jJB /wRwOiJGkCGQXIY6MiKCM5H/Oncy5hggIwYq8inhM9EGkP8N4CZpJRZchiYwAiAeUCQP3yUfJi8d 5y+ACGBsCzFcpP9AAi8BDsAEkIGgFBAsEC+1Py0QFAA4MQtgI1A0xVtKbERdcwU01EkFQAQAbt4n iMEd9S1QO3BNO6CEwa9IwG+CKIEoAm4tEGcfYX0e0HciYAWxBGAh8YSXV/5ETwVhYQ6wdrEpnyqi jWHbSlB+03NAsSryZDJkLbL/IiEn8QdwOFEgADTUheMrSdcetSpxO4BCjWFBQAEh0d+UxRghGtAg ESxHKBQQlZX7MLFIwCk0yyGTIiGUIIVg/x1we2EdgIfiH9SEBwuAerD/AHAjUIWTIpAT0B6lNNQm eLF6kXVwcBfBiYFidWTvkKGGEJFEjWFZnLEuABQQr6ETOeOUhnk1QmfASQEA4GEodG0pewQdoJjV 3y3RLEcvtYVgj1FykvCbDX+cogDAS6Ce5JAaogWR8mX/hJIOsCpmPTWcoh/imjUIYP8sAR7iO4WF 4yahH0CJgZKY/yGUrtiCCQQAmjUXsCygCYD/nIQf4yfyLEaoD5yxKCmp3/+Rb6u+n3c7gitAA6Av AThRpwnBowF9oiAqQOEqqmp9QLF3LbCfEa6qn66kE3b/SGEBoIRgLVBcLGTHQipc4P9C6XL4XQ9e H0ZfR29If0mPn8LkSt9L6mJPTZ8wOhwg/2SdUI9nr2i9U39q32vvbP//bg9vH3AvcT9yT3Laz5TB Z/fJhx6BIcMnP+MtsB5BL7H/e2QfNDnUeicDkQGgk6AKQPOroQnwZC3h0cLGd6UmeL+NYUIQOVIE AIQwHkFHjaD/O4CGEOFyQKIdkzNxOgB3IH+VlcMgoAoesbJRIqEAkGc/AwCBwZ5ih7Wc0afgIGq/ PuAFQC0QhWCX0gQgSYYR98+gt2HCxm0ngIBhPrM/8v+cdI+hFCCH0CwQgGEgMHrQ/6ZSPbePX4Th wsah0iqit1//kqXAD8Eccxr0TsMvxD/2Yt/FZM8rx0cAkM+yLtij1A3nYdfL38zuNzoOMGSZZS// ZjLQH9Er0d/S79P/1Q/WGP/Wn9enIRTYT9lf2m/2cPYI3EhpHOPBZw05T0CB6CPfHZET0ODh+XC6 5VeCGP0AH68C5mH88BAjPjBXU1OeKZWlCFAdEBehZ3n2CP96Jx7isRqO0IEgx2BAkyrzfxAjjTNC EJTSE72xxvaATnxPVPYIgglFcCJQ5HFj9/LHDTkdPXwdPh3VHK8duPx3ZE/wIZ8hQx+/HbdkgP8k vyRjIw8lAvaj9qIlDCd3OyYsIWMxHjBAcugifDP/KiYqjyLdJ3YeMBAUHhEnd/8uTykfHaoS8x4d MmkxLyc/9zU/MQ8dmTQk/zkkN98gz/87ryLvHZ8+3xwfGeHswaN2/4oCjwNQQJVxh7KOEeERfGb/ hbLvIg+t9gjxcYkxuyCFYP8IYPYIoWG3x6HSgcDNERfw/kmJwnzhfGWysJ70D6u59f/CxkevjoE6 6ZgkRb4cD/Zx/+qxtSPhEZoBuMMqx6Dy8VJ/FoiUIH0DlVLPoOGy7HBn/mhGuhaH9giBEoIJF2hQ v/8NwcaA4BXuAHwwgbEVRQFQ/53g6MHlc3ol17JZj//SwRz/DTnPlF9v9m/3f2HGxWTKqyPHR3OS LkUuyqMyQP2tkGWNMvws/ObFYM+g/aq0Mjj+hTXOACtgUP9Z///kAT8CQwYwzythigM/BE//BV3C xAZfB2kH/wkNYiAJ//8LDwwfYfJ5P2HkDeBfWGFs/8oAmrGUw4XxtyAMkIWiRJK+LcdilMKJcP0g rmZF3jL9p5Ev5NPCxMdih4Fhiodwt4pQXbhhbFWg8FziZhID/7sh6uB3UIiTBdCP4eyAh4L3t8CT ceMaIL8A4YCdcalR/xl3nZAQUGGKfxG64I1hygA/7xCaEOEh78HgwH4DZGr/nwB/IhPg7jG4w4/h x2D6AP9MuGICnZeKsueyiNsSlFOm/66Ud1C4N+AkoMWrEWLAnWD3FwFdAuHQY/rwm2bCxqRV/2Hk hm+Hcxgx7ICykkRBVLL/fYPvIYvDG3GmAEUhV1nm8X+8o4qyYYqewY+Ls2GW4T//gp9kRd+A3jLv glLEd1Ctof99801RQ2MWxH1VkMM2ULUh/4jbEjDwEKeBr0GzYGGKn8b/tcQa2efRSzOPiYKPa2Zf DfdhbPVKYgI9qy+sP61Prfj/qm+uv7Aub2Sor2HVSiOX0e/v8ImwtiF/InBEQH9g7sD+Y7hweANL +LrgUsR4ZPGwn3igozXgQOZ4TwNubPoAe+gP6nJXvQDhIeEggJBQ+5aimGB0v0HkYH2QlxF9gv3r UHDeAMLGj/OyivGw8VH/7jCLkFui6YHl0rmkeGTs8P+00e5gVUBjQHcgR7Si81LU/94AvRliAr3E vt+/7abPp9f/jFIYMenzfdHv8J+9f2HEZe9pYYXkgmBwUXS5cD5EuaP/YYrEZ45wUsQa2mNAubBv kP/B8uXDnuOioUVCfZA+RBAU396Aww/A0eHg4QNkbGDlcvFTcUNBQ1z6QsjnHBNF/9BmzIW9AtKD wqRTlcDykIb/xi+n39nvqf9532HVYi9jP//fBvjkbGWKoWxJ+hdsH2efV/zXx6DtMHNpTDf+hTH4 MDowK2D/Sv/GbZ/e6HtvIuSVLuRc8ABckXAQLv/+IAYwb2zerHBfBX9yz+Xb/XSHZXUvYcZ2f3eP eJ/fFP/erPajoVFSkZBBgUFDQRcy3/TgQ7HTGBex8XA6+Q/e6Pw+PupLz0BVQEdw/Xz/If3+Xj6y JWTw5KS+GwJTA6/vXvQXE5iwVWBlz1CGEX2B8xDAShAtRNmqBF8CRBE5601REjBuFRB0SMBNUcrx /4rAi5FUwJhhXQV9c5xhjp7/XWDS0BvR8TDMGwJTt0OZwf/ysE9iLrB+01rgdMC0gNAB3xCR0qBE wAev/l49iXKHof9IwJiwRQBIwH9h5IBvg8mS/0piERK6QlORR1ESPwGuhQH/mKPPUwMlQscYP835 EdOGAuddBZhwVMBjddRjkfC2AH8KsYYgSzOEsPxCPkRH0He/Gx8RFB4glqJHUVVAZIig/8IAEi8T P0cyi+DCAdKSkFG/0wYQoh1nHofPpJVRZOsN/yFBuhG3sMIBtMC/4CLfBM/fDMcRCA/UVTV+8mxF UH6Rf4uQC5G6gowQ7JCJ0AOfPu9U8KLGHnRDsW5IwB330pL/DLh9c1Tw4oDgIT5EllMwD/8t98jC 9PCE0Q4WknBVQJ9Q/yK/Kz8UMZnQkbFUwVISXXD/TIJIwC6CfoJHYS9DoVFFgL+NwNfwUhJVNpSL /xJiELH/noJsAPKwgSH+Xf5dZdDqtOZduvCRsUknuHA7Y5JA/4xDzfBb4pGxELFEAlTyR9H94HJy FRJBPjHPi5EQMdLg/yAh1TvA8uAQkqF/YN/gIqH/s/HWL98GtqKbIhzXXEFVQP+l0S+RRKE9Mww5 mRscP/Md//YhHgZ/YYzQRvXE9eSgjgH/XXKgRfIwpdDxcDh+QT60Bf+2qDQ1lk6MNKChMRb74VE/ 3x4FoERHBDh83qxvkXA9Ab+Rojs3x7ZEQzsywPJnFvH/BvEVQIfCM3m+Kygf9hKEYMP7odfwQy1U eRZg6AD/XzbwoNgRkHQWZpMxmECGAv9iv4dVtLG6oK8KnJpWPxQi/4VQfTGXMM4BklE/kxZXkxH/ onGE0YzQ++Gg8IzQhgKBQHxnaPaAkfD+XpdFOzJr/20CfYKS52C4unGR12r8a7//QifmgPwySJJ9 wPAwhVDAEP/gAJhhPGKYoEcy8mAOYbnS57ZE0pGM/Hgvi+B7MUtf/+RhP1CBQISwi/KZ1M/hcmD7 oLQdcnBSdnJHIWavBLZQv/ndkfRVTd6sJQX7EGJm1f9ut6ChOrWYYZGgkgCKYbpA7RreIj/hwdMi aXTRW99gfigicN/gTTHgENMxt7Bp+nqgQymXckUCN6C2YlgvzZhwP6F6l4BuJxctiqd/2QPS4Gr/ /ouHFAdB5JBm/mbn4XLQ9OCMb4ZycmHA8v87MmGWjfelwMwbz1LerAcT+/5e5JBzwTAU4LqBeHJ0 z/9133blx6EHQXevWXGgtFhsv86grwoZgJNBZ9FdTFeZLf90A+dQnB5EQ/rwcBMqAk/7v8RLO8Hx YTQvWRA4d0kNS/9LL363nB67se5h9nBNIpOF/1ozWIlN47uxCzI+ARmA0rH70Vv68Gbj4clAXU9e X4TC/4cUP9E2kFSFFjEigL/wOzLvbWM2gMfAwHBw+wFxktaJ/wqCNnAOvVQQ0tBZI2GXUvH/vBHZ ARVAiES1xLHVkJ/+fP8WBOPgJZFtoCHQRQp9EDvR/7xiRENtYZXsevMu5bS01ND/Pk25kyh/FmVJ cUlwgKFmgH8zxbhFuYhj8c/wCxAsYGx+cFEP/zDyYFnwXJNJcCi/YJO58VRAz3BoAETzavEA/zrh cHB9IO2xTSLxsVQRHRB5CwE/KZsvnD+dR6Y9V3xETRZIRNF7MHoSflRT+FVLTOkX+DOrDWflrH/B BhRTT05FVEqA0Hj9CkEvcthYb1lyRd2nJaQtf6rf32C8IJrAfSQxgppgb+/ggPbwbxBFQXSyT5g8 WgT/O5F+sljhobKEtuGl+HAVQf3CUWoRoZMUobIv9dzfC2H9IoB0vGIh81jg7nIQwRHh/4bRpzIV ATPFbuB5E4cvZWDydD0gcmt9gZffERdpif87JKQQbVT4NBqEb0DxsVMB//zgWOB9ELrijfc1PEXu bQD+bvewMoD88SyQGWAss1AL/59U6wTfz4mISFEvcuM8WmH/yEI3AcxyYcTC9rmFP5LlRv87kIlM ckInhs2gZeFMowBg/nLeATISKeDj4B+B8+BlYN/AIBbAfMr13xh8J79UwHP/tJZ5AK3QMTPek1L5 b0Xlr+sZEf5SLRUwLf5TH4AQUP9oIxGwA7GTUX4BNwMywUl07++gfhCIczh3UCnAV9GJTL8VYDaQ WYA4f2vfgdJn8+D/zDF/UhmQtxCaMiyQsFBvEf9vEbQwHfxXom8iDK7KMVrh/x+AJVGlY0cx1yDp cfPgAH/7mEo7kGt9cIlMELEaJN+/6QF8Pi0aYk/AIHhg2XKeTb/i8+AaYxlPPkaTkXo6s/B3/1Hf MHmQVPBAx3lQVUBKUHRmLj+g1ctqW8JhbLqAOh2PHpVdZk/73RoiQmVg0C6hT+1MsEGtoTuRRmFQ oWBAPr0CIVMywR1gLFC8YHPDMGp5fYBPiIBvurDXIDICN32AMjAwNSA0tDo0J5BB05cZyFQgIF+t kKXwpfAX9WEgQB5QZ/ou76E7iUQX9imcoDDMsf0kYC66sCrlGaogr8kfJYGYdWJqiHEdYFJlHWCf CQdvEAyvmU4Doi1zfbDkYmEglC1nVAHfIPBQXG1iwzA1se7iLSdwLrx0eKxuMz837wIhRBgE/xbt OO8o9BaT1vONwdcg6yL/ToHBMHew/QWS4aFgodBSkXhJLURVQELwr9I77z7/yEVY4vBqGcj+ogJQ U4EkYO/vowKgWeHGYGV5ULsBi6D/TSKwUBgQ8FDXID5UVU87v/9Hv0jPGgS+ceGWbhiCIMKBfbp1 Y0YRp3TCw61yUkU6/0o/Sh8aIlmAjBCnUU1gv+HnoBC+sVGFZnXHkNQjihD/tRCG4Vnj4XiJSpox zNGIgP9vAVBPKSC6sOsQhGB0Iey36+diu2B4eIIuDICfAf0G/9C4gJVY0s3uUA9LBIugwmL+LeuA u2BSMvmRPjDzVLBQfmeKsG5x5+LUL0nfGfVXP+uRZsJvtLqAupDI4GNr/SZxSa5yXwEIwu7FlUJS ef9hz8oQ4XLrgFJwfYFCfykg/+sgUwDLtHJDhgOhYOPgvGD//nGHQe5QoWTackbPYa8lcv/59Eyk sJHSoN6EhgDLcZNR/3/T76D9pH/TUYVAb0OBBXH/XuLzRHJfyhA94bBibG9tf/d2/3gPURVv99PN E8AR4+D/4hCuOMox7KPiYNfR65HXoP/Roe7FQF95P12zkyHSMFMA/w8yf29/X4JPGiL7UWgi0xL/ FCEIgrWiUom0Ul7og4+Db/8aImpRr6GOZEwHyGNScNfRf8DUsAH7sfPg2nGFNNz1OXwwJxbc+RC2 4KQuGiJ5/DJrjfG6cu5zsbCMdPTm/9C5UzS7YF/gX8C1Ui1fiL//PNPnUtL02MFVwbVxZHBppL8A EA+AunLz4A8z0xJiAqDvuoC/UOkAdfVJVk9nlT3y/wQgTw9d0kQRA+OudFLwVfTfvKyU7xoEQCGL oW3ek/8B/6UzlttjZAsgD4C/Acr0nE/7oA8CISCp4ZeS5+Less0x/7RgkTL7UPTBwMW+sURiE2L/ /cEW9Fo+phywIuzhwoGQof9qk8LAE2K1RJ1xZHCd094Q37/SunGe/6WfAiFBApFEwvOXFxgQZ2jv YqSPsG+mr/9fg/OBqEV9I9C5rEmqBe9B/7RvpsGtb53UTRBV4dnQXoH/wsW2dMzi/wAbY69ftE+/ f/+hA0PxDtfvQnAx4hCdoelxB8aQ2mGygUdNUExT/2hCRBH7JjdvxXcRISYQX5D/CyCGUUvgmVCG 0MUPwN/s4f+sYPtRESJFIIZR84Hq9ZCh94bCxJUCg3De8BMxjx8Gsr8Q4Vmjqm8t2qxY73Jh2kE7 YEE143PrgZFwvcJQWP5DTmHbcIqS6YCYQekAmdb/PExUAQVTaG+AU9PTWPA10P/08AWD+PHiQSRQ CTQ9crev/7i59PDWn0GAYyGjc/6w29//UWC9dllw1dFL4IbQYxAmMP/o9OdRP8EJhPBQGAG90QPw /2pw7nCcEJJQxO9BY9kI4o//zrFwlTXQqXGehdSvyQ/n3//o70sK4l9RJfRgWFL4oEIg/7JjbyAQ IUJfiI9K9RfQYGD/7bNekUIRWRAdYJkSe8DY8P9ZcHFVklgpYYCW+0WBOywA/8sB7/9XYtH0a8Se kBOh8dT/CYNqANhRtrL+sfzGi1EW+v/+A/5gsmLkX1dZklikJGoz/dowZJGyCXGiZJKgw9EDMP/f EIWA7q/v780g+9KHfwH/9xoix0AbgTtTgNGB3PBvpP8YADWATHBi8BBwnBBUAL3Bv1uP78/w1VjE +IbyNCPy73/z8QdhriBZEWoBA68CL29/PnBegT1yVNsOr0sEhoB0/yYgbwHc8ACCU0PKgWtBPXL/ vPDCcFlwvPEDcD8h4cLykv+XIJ6QTcD8PxGfc0UUsVQAv8OxF68XnxqP8NK89WcsYP/CAAZKWPAH LxvfG7/w84CC/1lw+KVZYN9B8pIUA0WTw4L/vcJ7w6hA9/cgzyC/tWDx0/8LgPTA0hEWfyafKZ9L FpcI/3FV9/fxxPnDDWPCIICghaH/e8L0td+AKuqpklQAKu8c0f9SEC4hBk8ezx/fNN8KgHCz/+3G kmDhUFMxRUFNANKQa6D/CoBOoU0w4ABEYrzxqUI16v+sQR3hX3BFMEOgJY9ngnxh/63DjFBTkCLy E7WYsspShWHdsnEp+cNqAkGgc2uggS/vNb/KBJfQ7pFzYxBqEYbB/0GfQY9Evxy0W1BxIFtBytLH cWAuUGugcGh5X5BfUtesQnWyrcQoWAYperBw8P9YYDvH9R1IIEX/ieE5M3FC/5JZPRGpgO6AVAB6 sA1m+3L/MxRMLxGPdVI0RHqzUP9Mf6w+be5QY0Bm2jB47oL/SbG8ceuxZQD6NI7gkXDl8P9IcPGg e/Gh4ayiXiENISib/4rWVM/Q8zszPQg/ZIUjrvL/rEcjw1byWsZYxr3BWspTn/9bqzuDXGkKk0dt 0pDUIDt//4rHKJ9Fz2gPRZ+00GmFoRECPLLgdHA6Ly93NWyQLhZQdJnQ5ZBnL1P7g8uBLWTRYGbR oC93bfPSsOBwYtKgrtDSYHD0LWczoXNz8GmPb//SZAN9tHEPLTAwLnR49nRw/3RfPubfdW92nXad LiB2jnaZdpR9fLAeAEIQAQAAAEUAAAA8NjI2RkM3QzZBOTczODE0NjhGQjg3MjA3MkFCNUREQzgz Njk3MUVAWENILVNXLTQyLnN3Lm5vcy5ib2VpbmcuY29tPgAAAAADAAlZAQAAAAsAAIAIIAYAAAAA AMAAAAAAAABGAAAAAAOFAAAAAAAAAwACgAggBgAAAAAAwAAAAAAAAEYAAAAAEIUAAAAAAAADAA+A CCAGAAAAAADAAAAAAAAARgAAAABShQAAc3kBAB4AEIAIIAYAAAAAAMAAAAAAAABGAAAAAFSFAAAB AAAABAAAADkuMAALABGACCAGAAAAAADAAAAAAAAARgAAAAAGhQAAAAAAAAMAEoAIIAYAAAAAAMAA AAAAAABGAAAAAAGFAAAAAAAACwAbgAggBgAAAAAAwAAAAAAAAEYAAAAADoUAAAAAAAADAByACCAG AAAAAADAAAAAAAAARgAAAAARhQAAAAAAAAMAHoAIIAYAAAAAAMAAAAAAAABGAAAAABiFAAAAAAAA AgH4DwEAAAAQAAAA35HcBW94wkS/G1ZZrXI85gIB+g8BAAAAEAAAAN+R3AVveMJEvxtWWa1yPOYC AfsPAQAAAJQAAAAAAAAAOKG7EAXlEBqhuwgAKypWwgAAbXNwc3QuZGxsAAAAAABOSVRB+b+4AQCq ADfZbgAAAEM6XERvY3VtZW50cyBhbmQgU2V0dGluZ3NccHRvcmFiXExvY2FsIFNldHRpbmdzXEFw cGxpY2F0aW9uIERhdGFcTWljcm9zb2Z0XE91dGxvb2tcbWFpbGJveC5wc3QAAwD+DwUAAAADAA00 /TcAAAIBfwABAAAAMQAAADAwMDAwMDAwREY5MURDMDU2Rjc4QzI0NEJGMUI1NjU5QUQ3MjNDRTYw NDZBMjQwMAAAAAADAAYQ8bdF9AMABxCkJgAAAwAQEAAAAAADABEQMAAAAB4ACBABAAAAZQAAAEpP SE4tU08sV0lUSEJVTkRMSU5HT1VUT0ZUSEVQSUNUVVJFLFdFSEFWRUNMT1NVUkU6LUlGVEhFUkVJ U05PUkVBTERJRkZFUkVOQ0VCRVRXRUVOTVVMVElQTEVQQVJBTExFTEMAAAAAoN4= ------=_NextPart_000_0111_01C5DE2E.DBEA8990-- From owner-ccamp@ops.ietf.org Mon Oct 31 15:46:57 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWgYT-0004Jw-3A for ccamp-archive@megatron.ietf.org; Mon, 31 Oct 2005 15:46:57 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07586 for ; Mon, 31 Oct 2005 15:46:37 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EWgmb-0001Fd-Rn for ccamp-archive@ietf.org; Mon, 31 Oct 2005 16:01:40 -0500 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EWgTn-000O6a-De for ccamp-data@psg.com; Mon, 31 Oct 2005 20:42:07 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [130.76.32.69] (helo=blv-smtpout-01.boeing.com) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EWgTm-000O6J-Ax; Mon, 31 Oct 2005 20:42:06 +0000 Received: from stl-av-01.boeing.com ([192.76.190.6]) by blv-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id MAA24511; Mon, 31 Oct 2005 12:41:58 -0800 (PST) Received: from XCH-SWBH-04.sw.nos.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id j9VKfvY03693; Mon, 31 Oct 2005 14:41:57 -0600 (CST) Received: from XCH-SW-42.sw.nos.boeing.com ([192.79.11.43]) by XCH-SWBH-04.sw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 31 Oct 2005 12:41:37 -0800 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: Two Drafts for Resilience of Control Plane Date: Mon, 31 Oct 2005 12:41:37 -0800 Message-ID: <626FC7C6A97381468FB872072AB5DDC836972C@XCH-SW-42.sw.nos.boeing.com> Thread-Topic: Two Drafts for Resilience of Control Plane Thread-Index: AcXeUC/DxWtRHzn7RY+EkY53MLTb5QACbl6w From: "Drake, John E" To: "Igor Bryskin" , , , Cc: , , , , X-OriginalArrivalTime: 31 Oct 2005 20:41:37.0652 (UTC) FILETIME=[7D5C5340:01C5DE5B] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Content-Transfer-Encoding: quoted-printable >=20 > [JD] > IB>> This would require node D, for example, to know exactly what to do > with > the service when it gets notified about the CP failure. > Policies do not work here. It's totally upto user to decide what to do > with > this service. [JD]=20 I don't buy that. That's what Service Level Agreements are for. > The only way it can convey this decision is by sending more > requests to the LSP ingress controller. For instance, the user may decide > to > keep using the service for a while and then delete or reroute it before > the > controller B comes back. [JD]=20 Why would the user be involved any decision other than hanging up? The user shouldn't be aware that node B failed. You are asserting a particular mode of operation for a service provider network which seems to require that every instance of every service have its own individualized recovery plan. > Neither of your options below therefore works. See also my response to > Dimitri. >=20 > Igor >=20 >=20 > Due to 'CP degraded' notification, nodes C and D will know that B > failed. >=20 > In option a), local policy, configured via the NMS, at D will tell it > whether to send a PathErr with state removed and if so, how long to > wait. As stated in another e-mail, multiple CP failures are handled by > configuration, via the NMS, at intermediate nodes that tell them under > what circumstances and after what duration to send PathTear and /or > PathErr with state removed, or whether simply to wait until the > resources time-out and how long to wait before timing them out. >=20 > In option b) A creates an MBB LSP on the path A, E, F, H, K, D. > Subsequently, A sends a PathTear to B, and D sends a PathErr with state > removed to C. The MBB LSP was created under policy control, via the > NMS, at the ingress node, A. >=20 > Here's your initial example: >=20 > A----B------C-----D > | | > E-----F-----H-----K >=20 > > I have a solution and am planning to write a draft. I'd like this work > to > > live in CCAMP. > [JD] >=20 > You can't get pre-approval of an I-D. >=20 > > > > Igor From owner-ccamp@ops.ietf.org Mon Oct 31 15:49:28 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWgat-0004lN-V1 for ccamp-archive@megatron.ietf.org; Mon, 31 Oct 2005 15:49:28 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07772 for ; Mon, 31 Oct 2005 15:49:08 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EWgp7-0001fA-MA for ccamp-archive@ietf.org; Mon, 31 Oct 2005 16:04:10 -0500 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EWgWa-000OFY-UM for ccamp-data@psg.com; Mon, 31 Oct 2005 20:45:00 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [130.76.64.48] (helo=slb-smtpout-01.boeing.com) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EWgWY-000OF0-F9; Mon, 31 Oct 2005 20:44:58 +0000 Received: from blv-av-01.boeing.com ([192.42.227.216]) by slb-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id MAA05122; Mon, 31 Oct 2005 12:44:57 -0800 (PST) Received: from XCH-SWBH-04.sw.nos.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id j9VKitH29027; Mon, 31 Oct 2005 12:44:55 -0800 (PST) Received: from XCH-SW-42.sw.nos.boeing.com ([192.79.11.43]) by XCH-SWBH-04.sw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 31 Oct 2005 12:44:55 -0800 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: comments on draft-shiba-ccamp-gmpls-lambda-labels-00.txt Date: Mon, 31 Oct 2005 12:44:54 -0800 Message-ID: <626FC7C6A97381468FB872072AB5DDC836972D@XCH-SW-42.sw.nos.boeing.com> Thread-Topic: comments on draft-shiba-ccamp-gmpls-lambda-labels-00.txt Thread-Index: AcXeWMPW5nlVR+kNRfaIVY8Or2+BdgAAtuLg From: "Drake, John E" To: "Payam Torab" , "Shiba, Sidney" , Cc: "Adrian Farrel" , , X-OriginalArrivalTime: 31 Oct 2005 20:44:55.0065 (UTC) FILETIME=[F3072890:01C5DE5B] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf > Of Payam Torab > Sent: Monday, October 31, 2005 12:22 PM > To: Drake, John E; 'Shiba, Sidney'; dpapadimitriou@psg.com > Cc: 'Adrian Farrel'; richard.rabbat@us.fujitsu.com; ccamp@ops.ietf.org > Subject: RE: comments on draft-shiba-ccamp-gmpls-lambda-labels-00.txt >=20 > John- So, with bundling out of the picture, we have closure: >=20 > - If there is no real difference between multiple parallel channels of the > same wavelength, we may want to combine these channels into a single TE > link for scalability and crankback benefits. In this case, there will be a > clash in the lambda label space if the label is going to have a purely > spectral meaning. >=20 > - If these parallel channels have different properties to the extent that > one wants to bind an LSP to a particular channel, then combining (and > obviously bundling) is not an option anyway. [JD]=20 Correct. My other point was that wavelength alone probably isn't sufficient to characterize a WDM line system for purposes of interoperability. >=20 > Thanks, > Payam >=20 From owner-ccamp@ops.ietf.org Mon Oct 31 17:43:53 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWiNd-0007Wf-NH for ccamp-archive@megatron.ietf.org; Mon, 31 Oct 2005 17:43:53 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16923 for ; Mon, 31 Oct 2005 17:43:33 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EWibt-0007nq-5m for ccamp-archive@ietf.org; Mon, 31 Oct 2005 17:58:38 -0500 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EWiGd-00035s-Lr for ccamp-data@psg.com; Mon, 31 Oct 2005 22:36:39 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.0 Received: from [62.241.162.32] (helo=ranger.systems.pipex.net) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EWiGY-00035h-LB for ccamp@ops.ietf.org; Mon, 31 Oct 2005 22:36:34 +0000 Received: from dnni.com (81-178-2-190.dsl.pipex.com [81.178.2.190]) by ranger.systems.pipex.net (Postfix) with ESMTP id A8A28E000197 for ; Mon, 31 Oct 2005 22:36:27 +0000 (GMT) Received: from Puppy ([217.158.132.17] RDNS failed) by dnni.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 31 Oct 2005 22:35:46 +0000 Message-ID: <0aef01c5de6b$d0a61760$de849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Control plane resiliency Date: Mon, 31 Oct 2005 22:37:34 -0000 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: 31 Oct 2005 22:35:48.0095 (UTC) FILETIME=[708AF8F0:01C5DE6B] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Content-Transfer-Encoding: 7bit Hi, It is nice to see some traffic on the CCAMP list. Some observations based on your discussions (in no particular order). 1. There is a distinction to be made between control channel resiliency and controller resiliency. Since the control channel uses IP, it will heal so long as there is IP connectivity (failing that you're dead anyway); the issue is the speed of convergence. Other solutions exist to provide control channel redundancy, but I believe that these are either implementation specific or are hardware specific. In either case, they are out of scope and (as Zafar says) the IP connectivity would remain. Controller resiliency is actually a debate about how to manage the data plane in the absence of a controller. Note that it is perfectly possible to lose your signaling controller without losing your routing controller, etc. 2. There is no need to make a distinction between data plane technologies. That is, for GMPLS this applies equally to PSC and non-PSC. 3. Dimitri's observation that it may be worthwhile documenting the concerns and explaining why they are not issues (i.e. how they solve themselves) may be very valuable. It should suit all people because if the concerns are real then the attempt at documentation will expose them, while if the concerns are not real we will have an advisory document for all time. 4. *The* controller resiliency issue appears to be: How to manage and teardown an LSP downstream of a broken controller. I do not understand why the answer is not one of: a. Wait for the controller to be repaired b. Use the management plane It seems that in-place modification of GMPLS LSPs is not a common operational feature for an active LSP. This leaves us with teardown. For teardown, option a does not seem to be very painful, but if it does cause problems (and alarms *will* be raised) option b is available. 5. The ability to manage the data plane resources at the node where the control plane has failed, may still exist in the management plane (in which case use it!) or may also be gone (in which case, who cares that you can't free up the resources for another user since another user cannot make use of the resources). You *might* manage to claim that there is a safety issue here - anyone know what OSMINE says about loss of management plane connectivity to a device with lasers? 6. There may be a *separate* issue (as raised by Tom) about how to synch the control plane with the data plane. This might be particularly important after controller recovery. Such OAM features should be part of a separate effort (such as a GMPLS OAM requirements draft). 7. Lyndon points out that there is scope for a "standby signaling controller". This could mean two things. a. An implementation option (as John points out) including, but not limited to: i. multiple instances of the software component ii. multiple instances of a controller CPU iii. control-plane message replication to distinct devices b. A protocol option where two entirely different "routers" manage the same data plane switch. This is pretty much outside our architecture (although we could handle a "replacement signaling controller" if it turned up with the same addresses). *If* someone wants to work on this idea, I suggest they need to develop the requirements and convince the community that what we have already doesn't provide everything we need anyway. (Not saying that the standby model is wrong, but am suggesting that we might not have a need for it at the moment.) 8. In a transport network, we must accept an operator's right to entirely eliminate soft state timeouts. That is, the failure of the control plane for any length of time, must not impact the traffic (note that even though RSVP is a soft state protocol, the refresh period may be set so high (32 bitsworth of milliseconds) as to be practically infinite. Note specifically that the failure of Hellos is used in RFC3473 to temporarily "turn off" the soft state nature of RSVP-TE. In summary: A. We have decided that observation 3 might be useful. Is anyone planning to work on this? B. We have not heard from Young since the start of this debate. I hope the hot words have not driven him away. C. Igor appears to be out on a limb here. While I appreciate him pushing a point that he believes in strongly, such determination in the face of WG consensus approaches a DOS attack (unintentional, I'm sure) on the IETF process. Please be careful. Thanks, Adrian From rogert@yahoo.com Mon Oct 31 18:58:42 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWjY2-0006od-6B for ccamp-archive@megatron.ietf.org; Mon, 31 Oct 2005 18:58:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21676 for ; Mon, 31 Oct 2005 18:58:21 -0500 (EST) Received: from e178118060.adsl.alicedsl.de ([85.178.118.60] helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EWjmJ-0007Lq-Cu for ccamp-archive@ietf.org; Mon, 31 Oct 2005 19:13:27 -0500 Date: Di, 01 Nov 2005 01:05:34 +0100 From: "Fink" To: Subject: Welcome to International Legal RX! Message-ID: <001001c5dd93$bc191aa0$0200a8c0@noop> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000D_01C5DD50.AC7AD360" 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: 1.2 (+) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 This is a multi-part message in MIME format. ------=_NextPart_000_000D_01C5DD50.AC7AD360 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable Suffering from pain, depression or heartburn? We'll help you! Great choice of wonderful meds to give you long-awaited relief!=20 Vlaggra as low as $3.84=20 ClaIis as low as $5.67=20 Xanaks as low as $2.47=20 VaIium as low as $3.41=20 Traumaddol as low as $3.30 UItram as low as $3.33=20 Soomma as low as $0.88=20 Meridida as low as $2.48=20 Our phartmacy is LICENSED, verified by BBB and approved by VISA!=20 ------=_NextPart_000_000D_01C5DD50.AC7AD360 Content-Type: text/html; charset="koi8-r" Content-Transfer-Encoding: quoted-printable
Suffering=20 from pain, depression or heartburn? We'll help=20 you!
Great=20 choice of wonderful meds to give you long-awaited relief!=20
 
Vlaggra=20 as low as $3.84 =
ClaIis=20 as low as $5.67 =
Xanaks=20 as low as $2.47 =
VaIium=20 as low as $3.41 =
Traumaddol=20 as low as=20 $3.30    
UItram=20 as low as $3.33 =
Soomma=20 as low as $0.88 =
Meridida=20 as low as $2.48 =
 
Our = phartmacy is=20 LICENSED, verified by BBB and approved by VISA!
 
------=_NextPart_000_000D_01C5DD50.AC7AD360-- From owner-ccamp@ops.ietf.org Mon Oct 31 19:56:25 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWkRt-0002u6-DL for ccamp-archive@megatron.ietf.org; Mon, 31 Oct 2005 19:56:25 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26093 for ; Mon, 31 Oct 2005 19:56:06 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EWkgA-0003dL-5K for ccamp-archive@ietf.org; Mon, 31 Oct 2005 20:11:11 -0500 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EWkKV-0008mI-K9 for ccamp-data@psg.com; Tue, 01 Nov 2005 00:48:47 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=3.1.0 Received: from [128.9.160.161] (helo=boreas.isi.edu) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EWkKU-0008m7-NX for ccamp@ops.ietf.org; Tue, 01 Nov 2005 00:48:46 +0000 Received: from ISI.EDU (adma.isi.edu [128.9.160.239]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jA10mIL15236; Mon, 31 Oct 2005 16:48:18 -0800 (PST) Message-Id: <200511010048.jA10mIL15236@boreas.isi.edu> To: ietf-announce@ietf.org Subject: RFC 4209 on Link Management Protocol (LMP) for Dense Wavelength Division Multiplexing (DWDM) Optical Line Systems Cc: rfc-editor@rfc-editor.org, ccamp@ops.ietf.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Mon, 31 Oct 2005 16:48:18 -0800 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: rfc-ed@isi.edu Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.4 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 --NextPart A new Request for Comments is now available in online RFC libraries. RFC 4209 Title: Link Management Protocol (LMP) for Dense Wavelength Division Multiplexing (DWDM) Optical Line Systems Author(s): A. Fredette, Ed., J. Lang, Ed. Status: Standards Track Date: October 2005 Mailbox: Afredette@HatterasNetworks.com, jplang@ieee.org Pages: 16 Characters: 33906 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-ccamp-lmp-wdm-03.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc4209.txt The Link Management Protocol (LMP) is defined to manage traffic engineering (TE) links. In its present form, LMP focuses on peer nodes, i.e., nodes that peer in signaling and/or routing. This document proposes extensions to LMP to allow it to be used between a peer node and an adjacent optical line system (OLS). These extensions are intended to satisfy the "Optical Link Interface Requirements" described in a companion document. This document is a product of the Common Control and Measurement Plane Working Group of the IETF. This is now a Proposed Standard Protocol. 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 ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <051031164719.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc4209 --OtherAccess Content-Type: Message/External-body; name="rfc4209.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <051031164719.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- From owner-ccamp@ops.ietf.org Mon Oct 31 23:11:15 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWnUR-0001C3-EB for ccamp-archive@megatron.ietf.org; Mon, 31 Oct 2005 23:11:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA07909 for ; Mon, 31 Oct 2005 23:10:55 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EWnij-0006U2-BK for ccamp-archive@ietf.org; Mon, 31 Oct 2005 23:26:03 -0500 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EWnLO-000GPk-Ih for ccamp-data@psg.com; Tue, 01 Nov 2005 04:01:54 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: ** X-Spam-Status: No, score=2.6 required=5.0 tests=AWL,BAYES_00,HTML_50_60, HTML_MESSAGE,MIME_BASE64_NO_NAME,MIME_BASE64_TEXT,MIME_HTML_MOSTLY, RCVD_IN_WHOIS_INVALID autolearn=no version=3.1.0 Received: from [129.254.16.131] (helo=email1.etri.info) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EWnLN-000GPY-6r for ccamp@ops.ietf.org; Tue, 01 Nov 2005 04:01:53 +0000 Received: from mail pickup service by email1.etri.info with Microsoft SMTPSVC; Tue, 1 Nov 2005 13:03:46 +0900 X-ReadCheckMessageID: <93997059-cba1-4edb-b3e5-3eb85aa82bb7@etri.re.kr> Thread-Topic: Two Drafts for Resilience of Control Plane thread-index: AcXemUHhH9P6Cx1AT1qsB+vhGsbi8g== X-ReadCheckName: ccamp%40ops.ietf.org Content-Transfer-Encoding: 7bit Reply-To: "Kim Young Hwa" From: "Kim Young Hwa" To: Subject: RE: Two Drafts for Resilience of Control Plane Date: Tue, 1 Nov 2005 13:03:46 +0900 Comment: GQ19@|@ZEk=E?,18?x, OAM1b MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_5274_01C5DEE4.B1CB07F0" X-Mailer: Microsoft CDO for Exchange 2000 Content-Class: urn:content-classes:message Importance: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.181 X-OriginalArrivalTime: 01 Nov 2005 04:03:46.0875 (UTC) FILETIME=[420280B0:01C5DE99] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 3.7 (+++) X-Scan-Signature: a92270ba83d7ead10c5001bb42ec3221 This is a multi-part message in MIME format. ------=_NextPart_000_5274_01C5DEE4.B1CB07F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: base64 ------=_NextPart_000_5274_01C5DEE4.B1CB07F0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: base64 PERJViBpZD1tc2dib2R5IHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBTeXN0 ZW0iPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsPkhpLDwvRk9OVD48L0RJVj4NCjxESVY+Jm5ic3A7 PC9ESVY+DQo8RElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsPkZpcnN0IG9mIGFsbCwgSSdkIGxp a2UgdG8gYXBwcmVjaWF0ZSB5b3VyIHNlbmRpbmcgYW5kIHJlY2VpdmluZyBjb21tdW5pY2F0aW9u IGJyb2FkbHkgYXMgYW4gaW5pdGlhdG9yIG9mIHRoaXMgaXNzdWUuPC9GT05UPjwvRElWPg0KPERJ Vj48Rk9OVCBmYWNlPUFyaWFsPjwvRk9OVD4mbmJzcDs8L0RJVj48L0RJVj4NCjxESVY+PEZPTlQg ZmFjZT1BcmlhbD5BcyBtb3N0IG9mIHBlb3BsZSBrbm93IGFib3V0IGNvbnRyb2wgcGxhbmUsPC9G T05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsPml0IGNvbnNpc3RzIG9mIGNvbnRyb2wg bm9kZXMsIGNvbnRyb2wgZW50aXRpZXMsIGFuZCBjb250cm9sIGNoYW5uZWxzLiA8L0ZPTlQ+PC9E SVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWw+SGVyZSwgdGhlIHJlc2lsaWVuY2UgYXNwZWN0IG9m IGNvbnRyb2wgbm9kZXMmbmJzcDtjb3VsZCBiZSZuYnNwO2FkZHJlc3NlZCZuYnNwO2luIHRoZSBJ Z29yJ3MgZXhhbXBsZSA8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWw+b3IgaW4g dGhlIGR1cGxpY2F0aW9uIG9mIHByb2Nlc3NvciBjYXJkcyB3aXRoaW4gYSBjb21tZXJjaWFsIHBy b2R1Y3QuIDwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbD5UaGUgcmVzaWxpZW5j ZSBhc3BlY3Qgb2YgY29udHJvbCBlbnRpdGllcyBjb3VsZCBiZSBhZGRyZXNzZWQgaW4gYSBwcm90 b2NvbCBpdHNlbGYgd2l0aCBHUiAoZ3JhY2VmdWwgcmVzdGFydCkgY2FwYWJpbGl0eS4gPC9GT05U PjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsPkFuZCwgdGhlIHJlc2lsaWVuY2UgYXNwZWN0 IG9mIGNvbnRyb2wgY2hhbm5lbHMgY291bGQgYmUgaWRlbnRpZmllZCBhIGxpbmsgb3IgY29uY2F0 ZW5hdGlvbiBvZiBsaW5rcyBjYXJyeWluZyBjb250cm9sIHBhY2tldHMuPC9GT05UPjwvRElWPg0K PERJVj48Rk9OVCBmYWNlPUFyaWFsPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFj ZT1BcmlhbD5IZXJlLCBJIGJlbGlldmUgdGhhdCB0aGUgcmVzaWxpZW5jZSBvZiBjb250cm9sIG5v ZGVzLCBjYWxsZWQgY29udHJvbGxlciByZXNpbGllbmN5LCA8L0ZPTlQ+PC9ESVY+DQo8RElWPjxG T05UIGZhY2U9QXJpYWw+YmVsb25nIHRvIGltcGxlbWVudGF0aW9uIGlzc3VlIChvciBIL1cgc3Bl Y2lmaWMgaXNzdWUpLCBub3QgcHJvdG9jb2wgaXNzdWUuIDwvRk9OVD48L0RJVj4NCjxESVY+PEZP TlQgZmFjZT1BcmlhbD5BbmQsIHRoZSByZXNpbGllbmNlIG9mIGNvbnRyb2wgZW50aXRpZXMgYmVs b25nIHRvIHByb3RvY29sIGlzc3VlLiA8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJp YWw+SG93ZXZlciwgdGhlIHNjb3BlIG9mIHJlc2lsaWVuY2UgaW4gY29udHJvbCBlbnRpdGllcyBl eGlzdHMgYmV0d2VlbiBwZWVyIGNvbnRyb2wgZW50aXRpZXMsIG5vdCBiZXR3ZWVuIHBoeXNpY2Fs bHkgYWRqYWNlbnQgbm9kZXMuIDwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbD5O b3RlIHRoYXQgdGhlIHJlc2lsaWVuY2Ugb2YgY29udHJvbCBlbnRpdGllcyBiZWxvbmcgdG8gb25s eSB0aGUgcHJvdG9jb2wgYmVjYXVzZSBhIGNvbnRyb2wgZW50aXR5Jm5ic3A7bWVhbnMgYSBwcm90 b2NvbCB0aGF0IHJ1bnMgYSBzcGVjaWZpYyBmdW5jdGlvbi4gPC9GT05UPjwvRElWPg0KPERJVj48 Rk9OVCBmYWNlPUFyaWFsPlNvbWUgcHJvdG9jb2xzIGNvdWxkIGJlIHJ1biB3aXRoIHNvZnQtc3Rh dGUgbmF0dXJlLCBvdGhlcnMgY291bGQgYmUgcnVuIHdpdGggaGFyZC1zdGF0ZSBuYXR1cmUuPC9G T05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsPlRoZSBkZWNpc2lvbiBvbiBzb2Z0LXN0 YXRlIGFuZCBoYXJkLXN0YXRlIGlzIGRpZmZlcmVudCBmcm9tIGV2ZXJ5IHByb3RvY29sIHRvIGJl IGFwcGxpZWQuPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsPjwvRk9OVD4mbmJz cDs8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbD5OZXh0IGlzIHRoZSByZXNpbGllbmNlIG9m IGNvbnRyb2wgY2hhbm5lbHMuIDwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbD5J dCBzZWVtcyB0aGF0IHRoaXMgY291bGQgYmVsb25nIHRvIGltcGxlbWVudGF0aW9uIGlzc3VlIGFz IGFkZHJlc3NlZCBieSBBZHJpYW4uPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFs Pkhvd2V2ZXIsIGlmIHlvdSBzZWUgdGhlIHJlc2lsaWVuY2Ugb2YgY29udHJvbCBjaGFubmVscyBh cyBpbXBsZW1lbnRhdGlvbiBpc3N1ZSw8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJp YWw+SSB0aGluayB0aGF0IHdlIGRvbid0IG5lZWQgdG8gY29uc2lkZXIgbW9yZSB0aGUgcmVzaWxp ZW5jZSBvZiBjb250cm9sIGNoYW5uZWxzIGluIGEgcHJvdG9jb2wgYXBwcm9hY2guIEJ1dCw8L0ZP TlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWw+ZGlmZmVyZW50bHkgZnJvbSBkYXRhIHBs YW5lLCBjb250cm9sIHBsYW5lIGhhcyB2YXJpb3VzIHByb3RvY29scyB0byBrZWVwIHRoZWlyIGNv bnRyb2wgcmVsYXRpb24uPC9GT05UPjwvRElWPg0KPERJVj4NCjxESVY+PEZPTlQgZmFjZT1Bcmlh bD5Db250cm9sIGNoYW5uZWxzIGFkZHJlc3NlZCBoZXJlIGFyZSBjb25jZXJuZWQgd2l0aCBwaHlz aWNhbGx5IGFkamFjZW50IG5vZGVzIHZpYSBkaXJlY3QgYW5kIGluZGlyZWN0IGNvbm5lY3Rpb25z PC9GT05UPjxGT05UIGZhY2U9QXJpYWw+LjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1B cmlhbD5BbmQsIHRoZXJlJm5ic3A7Y291bGQgYmUmbmJzcDtvbmUgb3IgbW9yZSBhbHRlcm5hdGl2 ZSByb3V0ZXMgdG8gdHJhbnNmZXIgY29udHJvbCBwYWNrZXRzIGJldHdlZW4gcGh5c2ljYWxseSBh ZGphY2VudCBub2Rlcy48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWw+TGV0J3Mg bG9vayBhdCBhbiBleGFtcGxlIG5ldHdvcmsuPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNl PSJDb3VyaWVyIE5ldyI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPSJDb3Vy aWVyIE5ldyI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPSJDb3VyaWVyIE5l dyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7fn5+fn5+fn5+fn5+fn5+fn5+fjwvRk9OVD48L0RJVj4NCjxESVY+ PEZPTlQgZmFjZT0iQ291cmllciBOZXciPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IHw8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9IkNvdXJp ZXIgTmV3Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDt8Jm5ic3A7Jm5ic3A7SW50cmEvZXh0cmEmbmJzcDsmbmJz cDsmbmJzcDsgfDwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0iQ291cmllciBOZXciPnwt LS0tLS0tLS0tLXwmbmJzcDsmbmJzcDtuZXR3b3JrIGZvciZuYnNwOyZuYnNwOyZuYnNwOyB8PC9G T05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyI+fCZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3wmbmJz cDtjb250cm9sIHBsYW5lJm5ic3A7Jm5ic3A7IHw8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZh Y2U9IkNvdXJpZXIgTmV3Ij58Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgfDwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0iQ291cmllciBOZXciPnwmbmJz cDs1Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 fn5+fn5+fn5+fn5+fn5+fn5+fjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0iQ291cmll ciBOZXciPnwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgfDwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0iQ291cmllciBOZXciPnwmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCA2PC9GT05UPjwv RElWPg0KPERJVj48Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyI+fCZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzEmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyA0PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPSJDb3Vy aWVyIE5ldyI+QS0tLS0tLS0tLS0tLS0tLS0tLS1CLS0tLS0tLS0tLS0tLS0tLS0tQzwvRk9OVD48 L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0iQ291cmllciBOZXciPnwmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDt8Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHw8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZh Y2U9IkNvdXJpZXIgTmV3Ij58Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7MiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHw8 L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3Ij58LS0tLS0tLS0tLS0t LS0tLS0tLS0mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfDwv Rk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0iQ291cmllciBOZXciPnwmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfDwvRk9OVD48L0RJVj4NCjxE SVY+PEZPTlQgZmFjZT0iQ291cmllciBOZXciPnwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDszJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IHw8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9IkNvdXJp ZXIgTmV3Ij58LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS18PC9GT05UPjwv RElWPjwvRElWPg0KPERJVj4NCjxESVY+PEZPTlQgZmFjZT0iQ291cmllciBOZXciPjwvRk9OVD4m bmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0iQ291cmllciBOZXciPjwvRk9OVD4mbmJzcDs8 L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbD5BYm92ZSB0aGUgZXhhbXBsZSwgd2UgYXNzdW1l IHRoYXQgMSwgMiwgMywgYW5kJm5ic3A7NCBjb250cm9sIGNoYW5uZWxzIHNoYXJlIHRoZSBmYXRl IHdpdGggZGF0YSBjaGFubmVscywgYW5kJm5ic3A7NSBhbmQmbmJzcDs2IGNvbnRyb2wgY2hhbm5l bHMgYXJlIHVzZWQgdG8gdHJhbnNmZXIgb25seSBjb250cm9sIHBhY2tldHMuIEFuZCwgdGhlIG5l dHdvcmsgZm9yIGNvbnRyb2wgcGxhbmUgY291bGQgaGF2ZSBkaWZmZXJlbnQgY2FwYWNpdHkgaW4g cmVhbCBpbXBsZW1lbnRhdGlvbnMuPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFs PkhlcmUsIHdlIGNhbiBzZWUgc2V2ZXJhbCBhbHRlcm5hdGl2ZXMgcm91dGVzIGluIGNvbnZleWlu ZyBjb250cm9sIHBhY2tldHMgYmV0d2VlbiBwaHlzaWNhbGx5IGFkamFjZW50IG5vZGVzLjwvRk9O VD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbD5CZXR3ZWVuIEEgYW5kIEIgbm9kZXMgaGF2 ZSB0aGUgZm9sbG93aW5nIHJvdXRlcy48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJp YWw+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyBSb3V0ZS0xIDogMTwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1B cmlhbD4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgUm91dGUtMiA6IDI8L0ZPTlQ+PC9ESVY+DQo8 RElWPjxGT05UIGZhY2U9QXJpYWw+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFJvdXRlLTMgOiAz LTQ8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWw+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IFJvdXRlLTQgOiA1LTY8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWw+ PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbD5JIHRoaW5r IHRoYXQgdGhlIHJlc2lsaWVuY2UgYXNwZWN0IG9mIGNvbnRyb2wgY2hhbm5lbCBzaG91bGQgaGFu ZGxlIHJlbGlhYmxlIChhbmQgZmFzdCkgdHJhbnNmZXIgb2YgY29udHJvbCBwYWNrZXRzIGJldHdl ZW4gc3BlY2lmaWMgbm9kZXMuPC9GT05UPjwvRElWPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFy aWFsPkluIHRoZSBleGFtcGxlIGJldHdlZW4gQSBhbmQgQiBub2RlcywgdGhlc2Ugbm9kZXMgc2hv dWxkIG5lZ290aWF0ZSBhY3RpdmUgYW5kIHN0YW5kYnkgY29udHJvbCBjaGFubmVscywgcHJvdG9j b2xzIHRvIGJlIGNhcnJpZWQgb24mbmJzcDthIGNvbnRyb2wgY2hhbm5lbCwgYW5kIGV0Yy4gSW4g dGhpcyBzZW5zZSwmbmJzcDtJIGJlbGlldmUgdGhhdCB0aGUgcmVzaWxpZW5jZSBvZiBjb250cm9s IGNoYW5uZWwgY291bGQgYmVsb25nIHRvIHByb3RvY29sIGlzc3VlLjwvRk9OVD48L0RJVj4NCjxE SVY+PEZPTlQgZmFjZT1BcmlhbD48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9 QXJpYWw+T25lIG9mIHR3byBkcmFmdCB0aGF0IEkgcHJvcG9zZWQgaXMgYSBzb2x1dGlvbiBmb3Ig dGhlIHJlc2lsaWVuY2Ugb2YgY29udHJvbCBjaGFubmVsLCB3aGljaCBpcyBiYXNlZCBvbiBhIGNv bmNlcHQgb2YgdGhlIGNvbnRyb2wgbmV0d29yaywgY2FsbGVkIGNvbW1vbiBjaGFubmVsIHNpZ25h bGluZyBzeXN0ZW0gdXNlZCBpbiB0aGUgdHJhZGl0aW9uYWwgUFNUTiBhbmQgSVNETi48L0ZPTlQ+ PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWw+T2YgY291cnNlLCB0aGVyZSBjb3VsZCBiZSBv dGhlciBzb2x1dGlvbnMgdG8gc29sdmUgdGhlIHJlc2lsaWVuY2Ugb2YgY29udHJvbCBjaGFubmVs LjwvRk9OVD48L0RJVj4NCjxESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWw+SSBkb24ndCB0aGlu ayB0aGF0IHRoZSBJUCBjb25uZWN0aXZpdHkgcHJvdmlkZXMgYSBtZWFucyB0byBiZSBjYXBhYmxl IG9mIHVzaW5nIHRoZXNlIHZhcmlvdXMgcm91dGVzLjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQg ZmFjZT1BcmlhbD5Gb3IgdGhlIHJlc2lsaWVuY2Ugb2YgY29udHJvbCBwbGFuZSwgdGhlIElQIGNv bm5lY3Rpdml0eSBpcyBhIGJhc2ljLCBhbmQgYWRkaXRpb25hbCB3b3JrcyBzaG91bGQgYmUgY29u c2lkZXJlZC48L0ZPTlQ+PC9ESVY+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWw+PC9GT05U PiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsPlRoZSBvdGhlciBkcmFmdCB0aGF0 IEkgcHJvcG9zZWQgaXMgYSByZXF1aXJlbWVudCBkb2N1bWVudCBmb3IgdGhlIHJlc2lsaWVuY2Ug b2YgY29udHJvbCBwbGFuZSwgbm90IHRoZSBvbmUgb2YgY29udHJvbCBjaGFubmVscy48L0ZPTlQ+ PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWw+SW4gdGhlIHJlcXVpcmVtZW50IGRvY3VtZW50 LCBhcyBhIGluaXRpYWwgY29tbWVudCBmcm9tIERpbWl0cmksIEkgdGhpbmsgdGhhdCB0aGUgZHJh ZnQgc2hvdWxkIGNvdmVyIHByb3RvY29sLW5ldXRyYWwgYXBwcm9hY2hlcywgbm90IHByb3RvY29s IHNwZWNpZmljIG9uZXMuIEZvciBleGFtcGxlcywgdGhlIHZhcmlvdXMgcmVzaWxpZW5jZSBhc3Bl Y3RzIG9mIGNvbnRyb2wgbm9kZXMsIGNvbnRyb2wgZW50aXRpZXMsIGNvbnRyb2wgY2hhbm5lbHMs IGFuZCBldGMgc2hvdWxkIGJlIGNvdmVyZWQuPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNl PUFyaWFsPkhvd2V2ZXIsIHRoZSBjdXJyZW50IGRyYWZ0IGRvZXMgbm90IHN1ZmZpY2llbnRseSBj b3ZlciB0aGUgZ2VuZXJhbCBhc3BlY3QgZm9yIHRoZSByZXNpbGllbmNlIG9mIGNvbnRyb2wgcGxh bmUuPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsPkkgdGhpbmsgdGhhdCB0aGVz ZSBwYXJ0cyBpbiB0aGUgcmVxdWlyZW1lbnQgZG9jdW1lbnQgY291bGQgYmUgaGFuZGxlZCBpbiBm dXJ0aGVyIHZlcnNpb24gd2l0aCBoZWxwIG9mIGNjYW1wZXJzIHdobyBhcmUgaW50ZXJlc3RlZCBp biB0aGUgcmVzaWxpZW5jZSBvZiBjb250cm9sIHBsYW5lLjwvRk9OVD48L0RJVj4NCjxESVY+PEZP TlQgZmFjZT1BcmlhbD48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWw+ PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsPlJlZ2FyZHM8L0ZPTlQ+ PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWw+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48 Rk9OVCBmYWNlPUFyaWFsPllvdW5nLjwvRk9OVD48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+PC9E SVY+PC9ESVY+PGltZyBzdHlsZT0iZGlzcGxheTpub25lIiB3aWR0aD0wIGhlaWdodD0wIHNyYz0i aHR0cDovL3VtYWlsLmV0cmkucmUua3IvRXh0ZXJuYWxfUmVhZENoZWNrLmFzcHg/ZW1haWw9Y2Nh bXBAb3BzLmlldGYub3JnJm5hbWU9Y2NhbXAlNDBvcHMuaWV0Zi5vcmcmZnJvbWVtYWlsPXlod2tp bUBldHJpLnJlLmtyJm1lc3NhZ2VpZD0lM0M5Mzk5NzA1OS1jYmExLTRlZGItYjNlNS0zZWI4NWFh ODJiYjdAZXRyaS5yZS5rciUzRSI+ ------=_NextPart_000_5274_01C5DEE4.B1CB07F0-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 31 Oct 2005 22:37:51 +0000 Message-ID: <0aef01c5de6b$d0a61760$de849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Control plane resiliency Date: Mon, 31 Oct 2005 22:37:34 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi, It is nice to see some traffic on the CCAMP list. Some observations based on your discussions (in no particular order). 1. There is a distinction to be made between control channel resiliency and controller resiliency. Since the control channel uses IP, it will heal so long as there is IP connectivity (failing that you're dead anyway); the issue is the speed of convergence. Other solutions exist to provide control channel redundancy, but I believe that these are either implementation specific or are hardware specific. In either case, they are out of scope and (as Zafar says) the IP connectivity would remain. Controller resiliency is actually a debate about how to manage the data plane in the absence of a controller. Note that it is perfectly possible to lose your signaling controller without losing your routing controller, etc. 2. There is no need to make a distinction between data plane technologies. That is, for GMPLS this applies equally to PSC and non-PSC. 3. Dimitri's observation that it may be worthwhile documenting the concerns and explaining why they are not issues (i.e. how they solve themselves) may be very valuable. It should suit all people because if the concerns are real then the attempt at documentation will expose them, while if the concerns are not real we will have an advisory document for all time. 4. *The* controller resiliency issue appears to be: How to manage and teardown an LSP downstream of a broken controller. I do not understand why the answer is not one of: a. Wait for the controller to be repaired b. Use the management plane It seems that in-place modification of GMPLS LSPs is not a common operational feature for an active LSP. This leaves us with teardown. For teardown, option a does not seem to be very painful, but if it does cause problems (and alarms *will* be raised) option b is available. 5. The ability to manage the data plane resources at the node where the control plane has failed, may still exist in the management plane (in which case use it!) or may also be gone (in which case, who cares that you can't free up the resources for another user since another user cannot make use of the resources). You *might* manage to claim that there is a safety issue here - anyone know what OSMINE says about loss of management plane connectivity to a device with lasers? 6. There may be a *separate* issue (as raised by Tom) about how to synch the control plane with the data plane. This might be particularly important after controller recovery. Such OAM features should be part of a separate effort (such as a GMPLS OAM requirements draft). 7. Lyndon points out that there is scope for a "standby signaling controller". This could mean two things. a. An implementation option (as John points out) including, but not limited to: i. multiple instances of the software component ii. multiple instances of a controller CPU iii. control-plane message replication to distinct devices b. A protocol option where two entirely different "routers" manage the same data plane switch. This is pretty much outside our architecture (although we could handle a "replacement signaling controller" if it turned up with the same addresses). *If* someone wants to work on this idea, I suggest they need to develop the requirements and convince the community that what we have already doesn't provide everything we need anyway. (Not saying that the standby model is wrong, but am suggesting that we might not have a need for it at the moment.) 8. In a transport network, we must accept an operator's right to entirely eliminate soft state timeouts. That is, the failure of the control plane for any length of time, must not impact the traffic (note that even though RSVP is a soft state protocol, the refresh period may be set so high (32 bitsworth of milliseconds) as to be practically infinite. Note specifically that the failure of Hellos is used in RFC3473 to temporarily "turn off" the soft state nature of RSVP-TE. In summary: A. We have decided that observation 3 might be useful. Is anyone planning to work on this? B. We have not heard from Young since the start of this debate. I hope the hot words have not driven him away. C. Igor appears to be out on a limb here. While I appreciate him pushing a point that he believes in strongly, such determination in the face of WG consensus approaches a DOS attack (unintentional, I'm sure) on the IETF process. Please be careful. Thanks, Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 31 Oct 2005 20:45:08 +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: comments on draft-shiba-ccamp-gmpls-lambda-labels-00.txt Date: Mon, 31 Oct 2005 12:44:54 -0800 Message-ID: <626FC7C6A97381468FB872072AB5DDC836972D@XCH-SW-42.sw.nos.boeing.com> Thread-Topic: comments on draft-shiba-ccamp-gmpls-lambda-labels-00.txt Thread-Index: AcXeWMPW5nlVR+kNRfaIVY8Or2+BdgAAtuLg From: "Drake, John E" To: "Payam Torab" , "Shiba, Sidney" , Cc: "Adrian Farrel" , , > -----Original Message----- > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf > Of Payam Torab > Sent: Monday, October 31, 2005 12:22 PM > To: Drake, John E; 'Shiba, Sidney'; dpapadimitriou@psg.com > Cc: 'Adrian Farrel'; richard.rabbat@us.fujitsu.com; ccamp@ops.ietf.org > Subject: RE: comments on draft-shiba-ccamp-gmpls-lambda-labels-00.txt >=20 > John- So, with bundling out of the picture, we have closure: >=20 > - If there is no real difference between multiple parallel channels of the > same wavelength, we may want to combine these channels into a single TE > link for scalability and crankback benefits. In this case, there will be a > clash in the lambda label space if the label is going to have a purely > spectral meaning. >=20 > - If these parallel channels have different properties to the extent that > one wants to bind an LSP to a particular channel, then combining (and > obviously bundling) is not an option anyway. [JD]=20 Correct. My other point was that wavelength alone probably isn't sufficient to characterize a WDM line system for purposes of interoperability. >=20 > Thanks, > Payam >=20 Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 31 Oct 2005 20:42:36 +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: Two Drafts for Resilience of Control Plane Date: Mon, 31 Oct 2005 12:41:37 -0800 Message-ID: <626FC7C6A97381468FB872072AB5DDC836972C@XCH-SW-42.sw.nos.boeing.com> Thread-Topic: Two Drafts for Resilience of Control Plane Thread-Index: AcXeUC/DxWtRHzn7RY+EkY53MLTb5QACbl6w From: "Drake, John E" To: "Igor Bryskin" , , , Cc: , , , , >=20 > [JD] > IB>> This would require node D, for example, to know exactly what to do > with > the service when it gets notified about the CP failure. > Policies do not work here. It's totally upto user to decide what to do > with > this service. [JD]=20 I don't buy that. That's what Service Level Agreements are for. > The only way it can convey this decision is by sending more > requests to the LSP ingress controller. For instance, the user may decide > to > keep using the service for a while and then delete or reroute it before > the > controller B comes back. [JD]=20 Why would the user be involved any decision other than hanging up? The user shouldn't be aware that node B failed. You are asserting a particular mode of operation for a service provider network which seems to require that every instance of every service have its own individualized recovery plan. > Neither of your options below therefore works. See also my response to > Dimitri. >=20 > Igor >=20 >=20 > Due to 'CP degraded' notification, nodes C and D will know that B > failed. >=20 > In option a), local policy, configured via the NMS, at D will tell it > whether to send a PathErr with state removed and if so, how long to > wait. As stated in another e-mail, multiple CP failures are handled by > configuration, via the NMS, at intermediate nodes that tell them under > what circumstances and after what duration to send PathTear and /or > PathErr with state removed, or whether simply to wait until the > resources time-out and how long to wait before timing them out. >=20 > In option b) A creates an MBB LSP on the path A, E, F, H, K, D. > Subsequently, A sends a PathTear to B, and D sends a PathErr with state > removed to C. The MBB LSP was created under policy control, via the > NMS, at the ingress node, A. >=20 > Here's your initial example: >=20 > A----B------C-----D > | | > E-----F-----H-----K >=20 > > I have a solution and am planning to write a draft. I'd like this work > to > > live in CCAMP. > [JD] >=20 > You can't get pre-approval of an I-D. >=20 > > > > Igor Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 31 Oct 2005 20:24:09 +0000 From: "Payam Torab" To: "'Drake, John E'" , "'Shiba, Sidney'" , Cc: "'Adrian Farrel'" , , Subject: RE: comments on draft-shiba-ccamp-gmpls-lambda-labels-00.txt Date: Mon, 31 Oct 2005 15:22:07 -0500 Message-ID: <011001c5de58$c4c09190$30fea8c0@NETPTORAB> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0111_01C5DE2E.DBEA8990" This is a multi-part message in MIME format. ------=_NextPart_000_0111_01C5DE2E.DBEA8990 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit John- So, with bundling out of the picture, we have closure: - If there is no real difference between multiple parallel channels of the same wavelength, we may want to combine these channels into a single TE link for scalability and crankback benefits. In this case, there will be a clash in the lambda label space if the label is going to have a purely spectral meaning. - If these parallel channels have different properties to the extent that one wants to bind an LSP to a particular channel, then combining (and obviously bundling) is not an option anyway. Thanks, Payam -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On Behalf Of Drake, John E Sent: Monday, October 31, 2005 11:58 AM To: Payam Torab; Shiba, Sidney; dpapadimitriou@psg.com Cc: Adrian Farrel; richard.rabbat@us.fujitsu.com; ccamp@ops.ietf.org Subject: RE: comments on draft-shiba-ccamp-gmpls-lambda-labels-00.txt > -----Original Message----- > From: Payam Torab [mailto:ptorab@lopsys.com] > Sent: Monday, October 31, 2005 8:12 AM > To: Drake, John E; 'Shiba, Sidney'; dpapadimitriou@psg.com > Cc: 'Adrian Farrel'; richard.rabbat@us.fujitsu.com; ccamp@ops.ietf.org > Subject: RE: comments on draft-shiba-ccamp-gmpls-lambda-labels-00.txt > > John- > > Obviously the benefits or harms of giving a global meaning to a lambda > label requires study, but your particular example is not a good one: If > one really wants to have a preference for a specific wavelength channel > among multiple parallel channels of the same wavelength, bundling should > not be exercised in the first place. [JD] It isn't bundling. LMP allows one to configure two or more parallel WDM systems into a single TE link. One reason for doing this is to improve the scalability of the TE LSB. Another is to reduce crankback (see below). If this done, you would have multiple instances of each of the wavelengths supported by the WDM systems. You asserted that this is a BadIdea(tm), but it reduces crankback in the network. If you make each parallel WDM system a separate TE link, then you have bound the LSP to the selected TE link. If the selected wavelength is blocked, you have to crankback. If you combine the parallel WDM systems into a single TE link, then the LSP can be progressed on *any* WDM system on which the selected wavelength is available. > > Thanks, > Payam > > -----Original Message----- > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On > Behalf Of Drake, John E > Sent: Monday, October 31, 2005 10:36 AM > To: Shiba, Sidney; dpapadimitriou@psg.com > Cc: Adrian Farrel; richard.rabbat@us.fujitsu.com; ccamp@ops.ietf.org > Subject: RE: comments on draft-shiba-ccamp-gmpls-lambda-labels-00.txt > > > Sidney, > > But there's nothing in your picture that requires an absolute end-end > global wavelength. The existing GMPLS solution with relative > wavelengths of local significance should work just fine. As I said in > my previous note, your method precludes combining two or more parallel > WDM links into a single TE link. > > Thanks, > > John > > > -----Original Message----- > > From: Shiba, Sidney [mailto:sidney.shiba@us.fujitsu.com] > > Sent: Monday, October 31, 2005 7:25 AM > > To: Drake, John E; dpapadimitriou@psg.com > > Cc: Adrian Farrel; richard.rabbat@us.fujitsu.com; ccamp@ops.ietf.org > > Subject: RE: comments on draft-shiba-ccamp-gmpls-lambda-labels-00.txt > > > > Hi John, > > > > Optical switches based on Wavelength Selective Switch (WSS) technology > > requires the wavelength information for switching. This technology is > NOT > > wavelength agnostic. > > > > | | > > | wdm | wdm > > |2 |2 > > --------- --------- > > wdm 1| optical |3 wdm 1| optical |3 wdm > > --------| switch |------------| switch |--------- > > | (WSS) | | (WSS) | > > --------- --------- > > |4 |4 > > | wdm | wdm > > | | > > > > Note that the figure above shows an example of two optical switches > > interconnect > > by a single WDM fiber. In this example, each optical switch can be > connect > > to 4 > > other optical switches. > > > > As you can see, the optical ports information do not provide enough > > information > > for wavelength switching. > > > > Hope that clarifies the application requirement. > > > > Thanks, > > > > Sidney > > > > > -----Original Message----- > > > From: Drake, John E [mailto:John.E.Drake2@boeing.com] > > > Sent: Friday, October 28, 2005 5:33 PM > > > To: dpapadimitriou@psg.com; Shiba, Sidney > > > Cc: Adrian Farrel; richard.rabbat@us.fujitsu.com; ccamp@ops.ietf.org > > > Subject: RE: comments on > draft-shiba-ccamp-gmpls-lambda-labels-00.txt > > > > > > > > > Hi, > > > > > > Below is the text of an e-mail is sent to the Ethernet/GMPLS mailing > > > list. > > > > > > Upon reflection I am not sure using a real wavelength value makes > much > > > sense. Between a pair of adjacent nodes, there may be > > > multiple pairs of > > > switch ports in the same TE link that support a given frequency. If > a > > > real wavelength value is used, how do the two nodes agree on > > > which pair > > > of switch ports to use? > > > > > > Furthermore, the amount of configuration is the same - you > > > still need to > > > configure the wavelength of each switch port. > > > > > > Thanks, > > > > > > John > > > ============================================================== > > > ========== > > > ==== > > > Adrian, > > > > > > In the transparent photonic lambda switch case, the labels also have > > > only local significance. When an LSP is established, the input > ports, > > > as identified with local labels, are cross-connected to the output > > > ports, as identified with local labels. > > > > > > There is just extra configuration to identify, using strictly local > > > identifiers, the wavelength associated with the all of the switch's > > > ports, and an additional CAC requirement that the wavelengths of the > > > input and output ports are the same. > > > > > > Thanks, > > > > > > John > > > > > > > > > > -----Original Message----- > > > > From: dimitri papadimitriou [mailto:dpapadimitriou@psg.com] > > > > Sent: Thursday, October 27, 2005 10:03 AM > > > > To: Shiba, Sidney > > > > Cc: dimitri.papadimitriou@alcatel.be; Adrian Farrel; > > > > richard.rabbat@us.fujitsu.com; ccamp@ops.ietf.org > > > > Subject: Re: comments on > > > draft-shiba-ccamp-gmpls-lambda-labels-00.txt > > > > > > > > shiba - see inline for some additional hints: > > > > > > > > >>Shiba, Sidney wrote: > > > > >> > > > > >>>Adrian, Dimitri, > > > > >>> > > > > >>>Thanks for reviewing these I-D. > > > > >>> > > > > >>>Wavelength continuity constraint does require the use of > > > semanticful > > > > >>>label whether it is spectral or index. > > > > >> > > > > >>=> see my reply to adrian on this specific point > > > > >> > > > > >>>I agree with Dimitri that the > > > > >>>wavelength indexing requires document updating each time a new > > > > >>>spectrum is introduced. > > > > >> > > > > >>=> indeed and in addition it requires updating the already > > > > >>signaled path > > > > >> > > > > >>>The use of spectral label provides self maintainance, i.e., > > > > >>>no need to update any document and the use of the nominal value > > > > >>>provides a common semantic ground. > > > > >> > > > > >>=> what do you mean by self-maintenance - would you provide a > > > > >>bit more detail > > > > > > > > > > [Sidney]What I've meant here was that it was not necessary to > > > > > update any document when new wavelengths are inventoried. In the > > > > > case of indexing approach, it would require the > > > wavelength indexing > > > > > document to be updated with implementation impacts. > > > > > > > > > > In the case, the nominal value is used, there is no need for > > > > > documentation update. > > > > > > > > ok - what you mean here is that you are going to make use of the > > > already > > > > defined C-Type 2 - what about the specific encoding of the > > > value space > > > ? > > > > > > > > >>=> now i have a more specific question before being light-up > > > > >>how do you know the frequency that you can support ? > > > > > > > > > > [Sidney] Some new technologies integrate optical switch and > > > mux/demux > > > > > capabilities, which allows the equipment to know the spectrum it > > > > supports. > > > > > > > > indeed - but the question is what does happen if the > > > "detected" values > > > > (during initialization) do not match the nominal values ? you > don't > > > > initialize then ? > > > > > > > > >>if these differ from the nominal values how are you going to > deal > > > with > > > > these > > > > >>discrepancies ? > > > > > > > > > > [Sidney] These new technologies uses the nominal value as > > > reference. > > > We > > > > can say > > > > > that a lightpath wavelength is identified by its nominal value. > If > > > the > > > > equipment > > > > > is drifting from this nominal value, it is considered as > > > a failure. > > > > > > > > ok - but if the deviation is such you have overlap - how the > control > > > > plane is going to be able to detect such failure ? > > > > > > > > >>this said i am not necessarily sure that having to > > > maintain the data > > > > plane > > > > >>specifics as part of the control plane is really helping > > > > >>operations (is this method not just duplicating complexity ?) > > > > > > > > > > [Sidney] The wavelength is WDM specific as much as the SUKLM > label > > > > encoding > > > > > is for SONET. The wavelegth/frequency nominal value is used to > > > identify > > > > the > > > > > facilities to cross-connect. > > > > > > > > there is an equivalence but there is also a major difference, the > > > > structure is invariant independently of the state of the > > > network, with > > > > spectral value space you may have labels that become unavailable > due > > > to > > > > non-local usage of wavelength in the network > > > > > > > > hence, there is also no real coupling to the data plane more than > > > > knowing the type of interface and some generic capabilities > > > > > > > > >>>I'm not sure if the draft needs to be updated before the > > > > >>>face-to-face meeting or after all comments are collected. > Please > > > > advise. > > > > >> > > > > >>=> suggest to keep discussion on - document update can be > > > > >>performed at a later stage > > > > > > > > thanks, > > > > - dimitri. > > > > > > > > >>>>-----Original Message----- > > > > >>>>From: owner-ccamp@ops.ietf.org > > > [mailto:owner-ccamp@ops.ietf.org]On > > > > >>>>Behalf Of Adrian Farrel > > > > >>>>Sent: Thursday, October 27, 2005 4:45 AM > > > > >>>>To: dpapadimitriou@psg.com; dimitri.papadimitriou@alcatel.be; > > > > >>>>ccamp@ops.ietf.org > > > > >>>>Subject: Re: comments on > > > > >> > > > > >>draft-shiba-ccamp-gmpls-lambda-labels-00.txt > > > > >> > > > > >>>> > > > > >>>>Dimitri, > > > > >>>> > > > > >>>>Thanks for your work reviewing these recent I-Ds. It is > > > > >>>>really valuable > > > > >>>>and I'd welcome other people doing similar reviews. > > > > >>>> > > > > >>>> > > > > >>>> > > > > >>>>>there is a specific point to be clarified in this document: > > > > >>>>> > > > > >>>>>semanticless vs semanticful label (even here there is a > > > distinction > > > > >>>>>between spectral vs indexes i.e. using the wavelength index) > > > > >>>>> > > > > >>>>>domain-wide vs link local significant label > > > > >>>> > > > > >>>>Without being too picky, I think all labels are semanticful > > > > >>>>otherwise, we > > > > >>>>would not know what resource they refered to. > > > > >>>> > > > > >>>>So the point reduces to whether the scope of the semantics > > > > >>>>are link-local > > > > >>>>or wider. > > > > >>>> > > > > >>>> > > > > >>>> > > > > >>>>>so, the comparison from this perspective with TDM labels is > > > > >>>> > > > > >>>>difficult to > > > > >>>> > > > > >>>> > > > > >>>>>parse, the latter is semanticful but link local > > > > >>>>> > > > > >>>>>now, i don't specifically see what has changed the late 90's, > > > early > > > > >>>>>y2k's, to have a change in the wavelength label definition; > > > > >>>> > > > > >>>>This is the question I would like to get to the bottom of. In > > > > >>>>other words: > > > > >>>>do we need this function? > > > > >>>> > > > > >>>>It seems to me that the question being asked is this: > > > > >>>> > > > > >>>> If I want to compute a path that has some form of wavelength > > > > >>>> constraints, what information do I need access to? > > > > >>>> > > > > >>>>Another question might be: > > > > >>>> > > > > >>>> If I want to signal a path with wavelength constraints what > > > > >>>> information do I need to include in the signaling message? > > > > >>>> > > > > >>>> > > > > >>>>I'd suggest that when we started on GMPLS, we were > > > > >> > > > > >>enthusiastic about > > > > >> > > > > >>>>transparent optical networks, but we were not properly > > > > >>>>focusing wavelength > > > > >>>>constraints because lambda-switching PXCs didn't take off. > > > > >>>>Therefore we > > > > >>>>didn't examine the requirements for wavelength constraints in > > > > >>>>routing and > > > > >>>>signaling. The authors of this I-D are claiming new hardware > > > > >>>>requirements > > > > >>>>for the same function. > > > > >>>> > > > > >>>> > > > > >>>> > > > > >>>>>there are > > > > >>>>>several solution possible > > > > >>>>> > > > > >>>>>- absolute values: the freq. of the wavelength: difficult to > > > adopt > > > > >>>>>because referenced values are nominal and knowing all > > > interactions > > > > >>>>>between wavelengths this knowledge is at the end of little > > > > >> > > > > >>practical > > > > >> > > > > >>>>>usage; (introduces implicit ordering) > > > > >>>>> > > > > >>>>>- indexed values: the # of the wavelength: it does not > > > > >> > > > > >>provide for a > > > > >> > > > > >>>>>future proof label space for inst. in case new frequencies > > > > >>>> > > > > >>>>are inserted > > > > >>>> > > > > >>>> > > > > >>>>>in the grid (introduces explicit ordering) > > > > >>>>> > > > > >>>>>- diff. values e.g. freq spacing starting from a reference > > > > >>>> > > > > >>>>value: pauses > > > > >>>> > > > > >>>> > > > > >>>>>the question of the reference value and does suffer from the > > > former > > > > >>>>>issue (introduces implicit ordering) > > > > >>>>> > > > > >>>>>- the solution available today - cumbersome in some > > > control plane > > > > >>>>>operations (e.g. label set translation) and not easy to > > > > >>>> > > > > >>>>troubleshoot but > > > > >>>> > > > > >>>> > > > > >>>>>independent of any physical consideration (spectral), scale > to > > > any > > > > >>>>>number of wavelength per fiber, does not introduce any > > > > >> > > > > >>ordering, the > > > > >> > > > > >>>>>most flexible (since allowing each system to maintain its > > > specific > > > > >>>>>control operations) and the less constraining since > maintaining > > > the > > > > >>>>>control plane operations independent of any data plane > > > specifics > > > > >>>>> > > > > >>>>> > > > > >>>> > > > > >>>> > > > >>> > > > > >>>ambda-labels > > > > >>>-00.txt> > > > > >>> > > > > >>>. > > > > >>> > > > > >> > > > > > > > > > > . > > > > > > > > ------=_NextPart_000_0111_01C5DE2E.DBEA8990 Content-Type: application/ms-tnef; name="winmail.dat" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="winmail.dat" eJ8+IggUAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEGgAMADgAAANUHCgAfAA8AFgAAAAEAKwEB A5AGAPwfAAAlAAAACwACAAEAAAALACMAAAAAAAMAJgAAAAAACwApAAAAAAADAC4AAAAAAAMANgAA AAAAHgBwAAEAAAA5AAAAY29tbWVudHMgb24gZHJhZnQtc2hpYmEtY2NhbXAtZ21wbHMtbGFtYmRh LWxhYmVscy0wMC50eHQAAAAAAgFxAAEAAAAWAAAAAcXeWMPW5nlVR+kNRfaIVY8Or2+BdgAAAgEd DAEAAAAXAAAAU01UUDpQVE9SQUJATE9QU1lTLkNPTQAACwABDgAAAABAAAYOAORsv1jexQECAQoO AQAAABgAAAAAAAAA35HcBW94wkS/G1ZZrXI85sKAAAADABQOAQAAAAsAHw4BAAAAAgEJEAEAAACk GwAAoBsAAPxGAABMWkZ1OHC/fAMACgByY3BnMTI14jIDQ3RleAVBAQMB9/8KgAKkA+QHEwKAD/MA UARWPwhVB7IRJQ5RAwECAGNo4QrAc2V0MgYABsMRJfYzBEYTtzASLBEzCO8J97Y7GB8OMDURIgxg YwBQMwsJAWQzNhZQC6YgShBvaG4tBgBvLCABA/B0aCBidW5kMmwLgGcgCGAFQG9moiAdsGUgcA3g dAhwrmUdcR8AE+B2HwBjF7B6cx9hOgqiCoQKgB0wSQsewxggIAQAIG5vIFMYIAdAIGQGkGYh4W46 Yx8AYhQgH7AJ8CBt6HVsdAUgbB8BCsAHQOckYAMgE9FubiTwBCAetfxzYQeAHYAf8SRgHkAdsPsf kwDAeSZhAjAe0CJgBaD/BtALgB8AHuEUECUYC4An8Y5hJhAeMSRhVEUgHiH8ayACEAXABPAHQAGg AxB3HaAngABwZCAgJLAqwGIvANAq0COAJWBmHaBzLv8hgAOgHbAiIStAFBAdcCHE/wPwJNAjcSnR IDAuAB3AC4B3HtMLYAbQZCngK2Ek8XM/CrAjUQaQL9UwsiIhZ2+vHjIn8R/jKeBwH2FsJ4D7MPAF kHQksSPwIpADAB5Afi4gvyikJJ8f1CLWBUBw/wNgM9AAIAiQBCAn8R7iDsH7OBIdsGEekShxJ6I4 4yhR4ywQA5FMU1An4jMxCsD9JDBjJBAKwSUlLjMDoCgkhR4yKCvyb2J2aQhg9nMzkR3mKSIUBUAD kThwVyQwAiAr4XkmcHk0y1TRJTFrcyw01FAncCYw1zTaIRVEUk8FEGcLgCKhZk0HkCYgZ2VEUzTU RhUDYToeYHclYHItY/ErQG1wQDhwLUAIkAAwdi4FsB5QWwDAAxAn8DozRr9HxV1PC5A040JlVRPg bB7ATx7ARCSwa/MfgRzyIEU01AZgAjBGkNZNAiAwYHkdcE8fQD6QGRKBMzEdcAHQMDUgoDExOjU4 EMBNQbW9SKAgQuMqYAWwAaA7BgBHLbAsgB1wU2lkJWB53VBgZAqwCrAi0G0doAUQPQhgQEeANLAo ITTUQ2PZRpBBZAchA6BGCsAzcWdQYAUQE9JkLlAxLIB0QkA+4C5mdWotIXUXUpJQYEkvZ0xFdWJq 8zPhRpBSRUaQKCEHgDqS60CxU4BhAYAtL4BQoUkU7C1nR0AlgC0wJFrRMLErWsBOUC4M0HQ02j4g /0RfRW1c4EZUT7lINwUwUCK2QBewR4B5LUAoIV1chvNMr028ODoOIE7nXOBPcutLe1BgJ1CLJ1Ff Umtc4P1TMidTe2dRVG9Vf1aPYgX/V+9Y/1oPWx9chlyGHPNynn5PPqce4izWHmAFwBPhbf8lk12A PrAeQSngKjA+kDQoHzu0MCRchjCUGCBxdWnrGCAEIHMfUGRjER3gBUD+eQhhPAoOwEcxJGE/1jJB /wRwOiJGkCGQXIY6MiKCM5H/Oncy5hggIwYq8inhM9EGkP8N4CZpJRZchiYwAiAeUCQP3yUfJi8d 5y+ACGBsCzFcpP9AAi8BDsAEkIGgFBAsEC+1Py0QFAA4MQtgI1A0xVtKbERdcwU01EkFQAQAbt4n iMEd9S1QO3BNO6CEwa9IwG+CKIEoAm4tEGcfYX0e0HciYAWxBGAh8YSXV/5ETwVhYQ6wdrEpnyqi jWHbSlB+03NAsSryZDJkLbL/IiEn8QdwOFEgADTUheMrSdcetSpxO4BCjWFBQAEh0d+UxRghGtAg ESxHKBQQlZX7MLFIwCk0yyGTIiGUIIVg/x1we2EdgIfiH9SEBwuAerD/AHAjUIWTIpAT0B6lNNQm eLF6kXVwcBfBiYFidWTvkKGGEJFEjWFZnLEuABQQr6ETOeOUhnk1QmfASQEA4GEodG0pewQdoJjV 3y3RLEcvtYVgj1FykvCbDX+cogDAS6Ce5JAaogWR8mX/hJIOsCpmPTWcoh/imjUIYP8sAR7iO4WF 4yahH0CJgZKY/yGUrtiCCQQAmjUXsCygCYD/nIQf4yfyLEaoD5yxKCmp3/+Rb6u+n3c7gitAA6Av AThRpwnBowF9oiAqQOEqqmp9QLF3LbCfEa6qn66kE3b/SGEBoIRgLVBcLGTHQipc4P9C6XL4XQ9e H0ZfR29If0mPn8LkSt9L6mJPTZ8wOhwg/2SdUI9nr2i9U39q32vvbP//bg9vH3AvcT9yT3Laz5TB Z/fJhx6BIcMnP+MtsB5BL7H/e2QfNDnUeicDkQGgk6AKQPOroQnwZC3h0cLGd6UmeL+NYUIQOVIE AIQwHkFHjaD/O4CGEOFyQKIdkzNxOgB3IH+VlcMgoAoesbJRIqEAkGc/AwCBwZ5ih7Wc0afgIGq/ PuAFQC0QhWCX0gQgSYYR98+gt2HCxm0ngIBhPrM/8v+cdI+hFCCH0CwQgGEgMHrQ/6ZSPbePX4Th wsah0iqit1//kqXAD8Eccxr0TsMvxD/2Yt/FZM8rx0cAkM+yLtij1A3nYdfL38zuNzoOMGSZZS// ZjLQH9Er0d/S79P/1Q/WGP/Wn9enIRTYT9lf2m/2cPYI3EhpHOPBZw05T0CB6CPfHZET0ODh+XC6 5VeCGP0AH68C5mH88BAjPjBXU1OeKZWlCFAdEBehZ3n2CP96Jx7isRqO0IEgx2BAkyrzfxAjjTNC EJTSE72xxvaATnxPVPYIgglFcCJQ5HFj9/LHDTkdPXwdPh3VHK8duPx3ZE/wIZ8hQx+/HbdkgP8k vyRjIw8lAvaj9qIlDCd3OyYsIWMxHjBAcugifDP/KiYqjyLdJ3YeMBAUHhEnd/8uTykfHaoS8x4d MmkxLyc/9zU/MQ8dmTQk/zkkN98gz/87ryLvHZ8+3xwfGeHswaN2/4oCjwNQQJVxh7KOEeERfGb/ hbLvIg+t9gjxcYkxuyCFYP8IYPYIoWG3x6HSgcDNERfw/kmJwnzhfGWysJ70D6u59f/CxkevjoE6 6ZgkRb4cD/Zx/+qxtSPhEZoBuMMqx6Dy8VJ/FoiUIH0DlVLPoOGy7HBn/mhGuhaH9giBEoIJF2hQ v/8NwcaA4BXuAHwwgbEVRQFQ/53g6MHlc3ol17JZj//SwRz/DTnPlF9v9m/3f2HGxWTKqyPHR3OS LkUuyqMyQP2tkGWNMvws/ObFYM+g/aq0Mjj+hTXOACtgUP9Z///kAT8CQwYwzythigM/BE//BV3C xAZfB2kH/wkNYiAJ//8LDwwfYfJ5P2HkDeBfWGFs/8oAmrGUw4XxtyAMkIWiRJK+LcdilMKJcP0g rmZF3jL9p5Ev5NPCxMdih4Fhiodwt4pQXbhhbFWg8FziZhID/7sh6uB3UIiTBdCP4eyAh4L3t8CT ceMaIL8A4YCdcalR/xl3nZAQUGGKfxG64I1hygA/7xCaEOEh78HgwH4DZGr/nwB/IhPg7jG4w4/h x2D6AP9MuGICnZeKsueyiNsSlFOm/66Ud1C4N+AkoMWrEWLAnWD3FwFdAuHQY/rwm2bCxqRV/2Hk hm+Hcxgx7ICykkRBVLL/fYPvIYvDG3GmAEUhV1nm8X+8o4qyYYqewY+Ls2GW4T//gp9kRd+A3jLv glLEd1Ctof99801RQ2MWxH1VkMM2ULUh/4jbEjDwEKeBr0GzYGGKn8b/tcQa2efRSzOPiYKPa2Zf DfdhbPVKYgI9qy+sP61Prfj/qm+uv7Aub2Sor2HVSiOX0e/v8ImwtiF/InBEQH9g7sD+Y7hweANL +LrgUsR4ZPGwn3igozXgQOZ4TwNubPoAe+gP6nJXvQDhIeEggJBQ+5aimGB0v0HkYH2QlxF9gv3r UHDeAMLGj/OyivGw8VH/7jCLkFui6YHl0rmkeGTs8P+00e5gVUBjQHcgR7Si81LU/94AvRliAr3E vt+/7abPp9f/jFIYMenzfdHv8J+9f2HEZe9pYYXkgmBwUXS5cD5EuaP/YYrEZ45wUsQa2mNAubBv kP/B8uXDnuOioUVCfZA+RBAU396Aww/A0eHg4QNkbGDlcvFTcUNBQ1z6QsjnHBNF/9BmzIW9AtKD wqRTlcDykIb/xi+n39nvqf9532HVYi9jP//fBvjkbGWKoWxJ+hdsH2efV/zXx6DtMHNpTDf+hTH4 MDowK2D/Sv/GbZ/e6HtvIuSVLuRc8ABckXAQLv/+IAYwb2zerHBfBX9yz+Xb/XSHZXUvYcZ2f3eP eJ/fFP/erPajoVFSkZBBgUFDQRcy3/TgQ7HTGBex8XA6+Q/e6Pw+PupLz0BVQEdw/Xz/If3+Xj6y JWTw5KS+GwJTA6/vXvQXE5iwVWBlz1CGEX2B8xDAShAtRNmqBF8CRBE5601REjBuFRB0SMBNUcrx /4rAi5FUwJhhXQV9c5xhjp7/XWDS0BvR8TDMGwJTt0OZwf/ysE9iLrB+01rgdMC0gNAB3xCR0qBE wAev/l49iXKHof9IwJiwRQBIwH9h5IBvg8mS/0piERK6QlORR1ESPwGuhQH/mKPPUwMlQscYP835 EdOGAuddBZhwVMBjddRjkfC2AH8KsYYgSzOEsPxCPkRH0He/Gx8RFB4glqJHUVVAZIig/8IAEi8T P0cyi+DCAdKSkFG/0wYQoh1nHofPpJVRZOsN/yFBuhG3sMIBtMC/4CLfBM/fDMcRCA/UVTV+8mxF UH6Rf4uQC5G6gowQ7JCJ0AOfPu9U8KLGHnRDsW5IwB330pL/DLh9c1Tw4oDgIT5EllMwD/8t98jC 9PCE0Q4WknBVQJ9Q/yK/Kz8UMZnQkbFUwVISXXD/TIJIwC6CfoJHYS9DoVFFgL+NwNfwUhJVNpSL /xJiELH/noJsAPKwgSH+Xf5dZdDqtOZduvCRsUknuHA7Y5JA/4xDzfBb4pGxELFEAlTyR9H94HJy FRJBPjHPi5EQMdLg/yAh1TvA8uAQkqF/YN/gIqH/s/HWL98GtqKbIhzXXEFVQP+l0S+RRKE9Mww5 mRscP/Md//YhHgZ/YYzQRvXE9eSgjgH/XXKgRfIwpdDxcDh+QT60Bf+2qDQ1lk6MNKChMRb74VE/ 3x4FoERHBDh83qxvkXA9Ab+Rojs3x7ZEQzsywPJnFvH/BvEVQIfCM3m+Kygf9hKEYMP7odfwQy1U eRZg6AD/XzbwoNgRkHQWZpMxmECGAv9iv4dVtLG6oK8KnJpWPxQi/4VQfTGXMM4BklE/kxZXkxH/ onGE0YzQ++Gg8IzQhgKBQHxnaPaAkfD+XpdFOzJr/20CfYKS52C4unGR12r8a7//QifmgPwySJJ9 wPAwhVDAEP/gAJhhPGKYoEcy8mAOYbnS57ZE0pGM/Hgvi+B7MUtf/+RhP1CBQISwi/KZ1M/hcmD7 oLQdcnBSdnJHIWavBLZQv/ndkfRVTd6sJQX7EGJm1f9ut6ChOrWYYZGgkgCKYbpA7RreIj/hwdMi aXTRW99gfigicN/gTTHgENMxt7Bp+nqgQymXckUCN6C2YlgvzZhwP6F6l4BuJxctiqd/2QPS4Gr/ /ouHFAdB5JBm/mbn4XLQ9OCMb4ZycmHA8v87MmGWjfelwMwbz1LerAcT+/5e5JBzwTAU4LqBeHJ0 z/9133blx6EHQXevWXGgtFhsv86grwoZgJNBZ9FdTFeZLf90A+dQnB5EQ/rwcBMqAk/7v8RLO8Hx YTQvWRA4d0kNS/9LL363nB67se5h9nBNIpOF/1ozWIlN47uxCzI+ARmA0rH70Vv68Gbj4clAXU9e X4TC/4cUP9E2kFSFFjEigL/wOzLvbWM2gMfAwHBw+wFxktaJ/wqCNnAOvVQQ0tBZI2GXUvH/vBHZ ARVAiES1xLHVkJ/+fP8WBOPgJZFtoCHQRQp9EDvR/7xiRENtYZXsevMu5bS01ND/Pk25kyh/FmVJ cUlwgKFmgH8zxbhFuYhj8c/wCxAsYGx+cFEP/zDyYFnwXJNJcCi/YJO58VRAz3BoAETzavEA/zrh cHB9IO2xTSLxsVQRHRB5CwE/KZsvnD+dR6Y9V3xETRZIRNF7MHoSflRT+FVLTOkX+DOrDWflrH/B BhRTT05FVEqA0Hj9CkEvcthYb1lyRd2nJaQtf6rf32C8IJrAfSQxgppgb+/ggPbwbxBFQXSyT5g8 WgT/O5F+sljhobKEtuGl+HAVQf3CUWoRoZMUobIv9dzfC2H9IoB0vGIh81jg7nIQwRHh/4bRpzIV ATPFbuB5E4cvZWDydD0gcmt9gZffERdpif87JKQQbVT4NBqEb0DxsVMB//zgWOB9ELrijfc1PEXu bQD+bvewMoD88SyQGWAss1AL/59U6wTfz4mISFEvcuM8WmH/yEI3AcxyYcTC9rmFP5LlRv87kIlM ckInhs2gZeFMowBg/nLeATISKeDj4B+B8+BlYN/AIBbAfMr13xh8J79UwHP/tJZ5AK3QMTPek1L5 b0Xlr+sZEf5SLRUwLf5TH4AQUP9oIxGwA7GTUX4BNwMywUl07++gfhCIczh3UCnAV9GJTL8VYDaQ WYA4f2vfgdJn8+D/zDF/UhmQtxCaMiyQsFBvEf9vEbQwHfxXom8iDK7KMVrh/x+AJVGlY0cx1yDp cfPgAH/7mEo7kGt9cIlMELEaJN+/6QF8Pi0aYk/AIHhg2XKeTb/i8+AaYxlPPkaTkXo6s/B3/1Hf MHmQVPBAx3lQVUBKUHRmLj+g1ctqW8JhbLqAOh2PHpVdZk/73RoiQmVg0C6hT+1MsEGtoTuRRmFQ oWBAPr0CIVMywR1gLFC8YHPDMGp5fYBPiIBvurDXIDICN32AMjAwNSA0tDo0J5BB05cZyFQgIF+t kKXwpfAX9WEgQB5QZ/ou76E7iUQX9imcoDDMsf0kYC66sCrlGaogr8kfJYGYdWJqiHEdYFJlHWCf CQdvEAyvmU4Doi1zfbDkYmEglC1nVAHfIPBQXG1iwzA1se7iLSdwLrx0eKxuMz837wIhRBgE/xbt OO8o9BaT1vONwdcg6yL/ToHBMHew/QWS4aFgodBSkXhJLURVQELwr9I77z7/yEVY4vBqGcj+ogJQ U4EkYO/vowKgWeHGYGV5ULsBi6D/TSKwUBgQ8FDXID5UVU87v/9Hv0jPGgS+ceGWbhiCIMKBfbp1 Y0YRp3TCw61yUkU6/0o/Sh8aIlmAjBCnUU1gv+HnoBC+sVGFZnXHkNQjihD/tRCG4Vnj4XiJSpox zNGIgP9vAVBPKSC6sOsQhGB0Iey36+diu2B4eIIuDICfAf0G/9C4gJVY0s3uUA9LBIugwmL+LeuA u2BSMvmRPjDzVLBQfmeKsG5x5+LUL0nfGfVXP+uRZsJvtLqAupDI4GNr/SZxSa5yXwEIwu7FlUJS ef9hz8oQ4XLrgFJwfYFCfykg/+sgUwDLtHJDhgOhYOPgvGD//nGHQe5QoWTackbPYa8lcv/59Eyk sJHSoN6EhgDLcZNR/3/T76D9pH/TUYVAb0OBBXH/XuLzRHJfyhA94bBibG9tf/d2/3gPURVv99PN E8AR4+D/4hCuOMox7KPiYNfR65HXoP/Roe7FQF95P12zkyHSMFMA/w8yf29/X4JPGiL7UWgi0xL/ FCEIgrWiUom0Ul7og4+Db/8aImpRr6GOZEwHyGNScNfRf8DUsAH7sfPg2nGFNNz1OXwwJxbc+RC2 4KQuGiJ5/DJrjfG6cu5zsbCMdPTm/9C5UzS7YF/gX8C1Ui1fiL//PNPnUtL02MFVwbVxZHBppL8A EA+AunLz4A8z0xJiAqDvuoC/UOkAdfVJVk9nlT3y/wQgTw9d0kQRA+OudFLwVfTfvKyU7xoEQCGL oW3ek/8B/6UzlttjZAsgD4C/Acr0nE/7oA8CISCp4ZeS5+Less0x/7RgkTL7UPTBwMW+sURiE2L/ /cEW9Fo+phywIuzhwoGQof9qk8LAE2K1RJ1xZHCd094Q37/SunGe/6WfAiFBApFEwvOXFxgQZ2jv YqSPsG+mr/9fg/OBqEV9I9C5rEmqBe9B/7RvpsGtb53UTRBV4dnQXoH/wsW2dMzi/wAbY69ftE+/ f/+hA0PxDtfvQnAx4hCdoelxB8aQ2mGygUdNUExT/2hCRBH7JjdvxXcRISYQX5D/CyCGUUvgmVCG 0MUPwN/s4f+sYPtRESJFIIZR84Hq9ZCh94bCxJUCg3De8BMxjx8Gsr8Q4Vmjqm8t2qxY73Jh2kE7 YEE143PrgZFwvcJQWP5DTmHbcIqS6YCYQekAmdb/PExUAQVTaG+AU9PTWPA10P/08AWD+PHiQSRQ CTQ9crev/7i59PDWn0GAYyGjc/6w29//UWC9dllw1dFL4IbQYxAmMP/o9OdRP8EJhPBQGAG90QPw /2pw7nCcEJJQxO9BY9kI4o//zrFwlTXQqXGehdSvyQ/n3//o70sK4l9RJfRgWFL4oEIg/7JjbyAQ IUJfiI9K9RfQYGD/7bNekUIRWRAdYJkSe8DY8P9ZcHFVklgpYYCW+0WBOywA/8sB7/9XYtH0a8Se kBOh8dT/CYNqANhRtrL+sfzGi1EW+v/+A/5gsmLkX1dZklikJGoz/dowZJGyCXGiZJKgw9EDMP/f EIWA7q/v780g+9KHfwH/9xoix0AbgTtTgNGB3PBvpP8YADWATHBi8BBwnBBUAL3Bv1uP78/w1VjE +IbyNCPy73/z8QdhriBZEWoBA68CL29/PnBegT1yVNsOr0sEhoB0/yYgbwHc8ACCU0PKgWtBPXL/ vPDCcFlwvPEDcD8h4cLykv+XIJ6QTcD8PxGfc0UUsVQAv8OxF68XnxqP8NK89WcsYP/CAAZKWPAH LxvfG7/w84CC/1lw+KVZYN9B8pIUA0WTw4L/vcJ7w6hA9/cgzyC/tWDx0/8LgPTA0hEWfyafKZ9L FpcI/3FV9/fxxPnDDWPCIICghaH/e8L0td+AKuqpklQAKu8c0f9SEC4hBk8ezx/fNN8KgHCz/+3G kmDhUFMxRUFNANKQa6D/CoBOoU0w4ABEYrzxqUI16v+sQR3hX3BFMEOgJY9ngnxh/63DjFBTkCLy E7WYsspShWHdsnEp+cNqAkGgc2uggS/vNb/KBJfQ7pFzYxBqEYbB/0GfQY9Evxy0W1BxIFtBytLH cWAuUGugcGh5X5BfUtesQnWyrcQoWAYperBw8P9YYDvH9R1IIEX/ieE5M3FC/5JZPRGpgO6AVAB6 sA1m+3L/MxRMLxGPdVI0RHqzUP9Mf6w+be5QY0Bm2jB47oL/SbG8ceuxZQD6NI7gkXDl8P9IcPGg e/Gh4ayiXiENISib/4rWVM/Q8zszPQg/ZIUjrvL/rEcjw1byWsZYxr3BWspTn/9bqzuDXGkKk0dt 0pDUIDt//4rHKJ9Fz2gPRZ+00GmFoRECPLLgdHA6Ly93NWyQLhZQdJnQ5ZBnL1P7g8uBLWTRYGbR oC93bfPSsOBwYtKgrtDSYHD0LWczoXNz8GmPb//SZAN9tHEPLTAwLnR49nRw/3RfPubfdW92nXad LiB2jnaZdpR9fLAeAEIQAQAAAEUAAAA8NjI2RkM3QzZBOTczODE0NjhGQjg3MjA3MkFCNUREQzgz Njk3MUVAWENILVNXLTQyLnN3Lm5vcy5ib2VpbmcuY29tPgAAAAADAAlZAQAAAAsAAIAIIAYAAAAA AMAAAAAAAABGAAAAAAOFAAAAAAAAAwACgAggBgAAAAAAwAAAAAAAAEYAAAAAEIUAAAAAAAADAA+A CCAGAAAAAADAAAAAAAAARgAAAABShQAAc3kBAB4AEIAIIAYAAAAAAMAAAAAAAABGAAAAAFSFAAAB AAAABAAAADkuMAALABGACCAGAAAAAADAAAAAAAAARgAAAAAGhQAAAAAAAAMAEoAIIAYAAAAAAMAA AAAAAABGAAAAAAGFAAAAAAAACwAbgAggBgAAAAAAwAAAAAAAAEYAAAAADoUAAAAAAAADAByACCAG AAAAAADAAAAAAAAARgAAAAARhQAAAAAAAAMAHoAIIAYAAAAAAMAAAAAAAABGAAAAABiFAAAAAAAA AgH4DwEAAAAQAAAA35HcBW94wkS/G1ZZrXI85gIB+g8BAAAAEAAAAN+R3AVveMJEvxtWWa1yPOYC AfsPAQAAAJQAAAAAAAAAOKG7EAXlEBqhuwgAKypWwgAAbXNwc3QuZGxsAAAAAABOSVRB+b+4AQCq ADfZbgAAAEM6XERvY3VtZW50cyBhbmQgU2V0dGluZ3NccHRvcmFiXExvY2FsIFNldHRpbmdzXEFw cGxpY2F0aW9uIERhdGFcTWljcm9zb2Z0XE91dGxvb2tcbWFpbGJveC5wc3QAAwD+DwUAAAADAA00 /TcAAAIBfwABAAAAMQAAADAwMDAwMDAwREY5MURDMDU2Rjc4QzI0NEJGMUI1NjU5QUQ3MjNDRTYw NDZBMjQwMAAAAAADAAYQ8bdF9AMABxCkJgAAAwAQEAAAAAADABEQMAAAAB4ACBABAAAAZQAAAEpP SE4tU08sV0lUSEJVTkRMSU5HT1VUT0ZUSEVQSUNUVVJFLFdFSEFWRUNMT1NVUkU6LUlGVEhFUkVJ U05PUkVBTERJRkZFUkVOQ0VCRVRXRUVOTVVMVElQTEVQQVJBTExFTEMAAAAAoN4= ------=_NextPart_000_0111_01C5DE2E.DBEA8990-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 31 Oct 2005 19:40:24 +0000 Message-ID: <43667307.1000808@psg.com> Date: Mon, 31 Oct 2005 20:39:51 +0100 From: dimitri papadimitriou Reply-To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.11) Gecko/20050728 MIME-Version: 1.0 To: Igor Bryskin CC: dimitri.papadimitriou@alcatel.be, "Drake, John E" , "Zafar Ali (zali)" , Igor Bryskin , drake@movaz.com, Kim Young Hwa , ccamp@ops.ietf.org Subject: Re: Two Drafts for Resilience of Control Plane Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Igor [snip] > 1. Yes, I do have an independent dp (not cp as you say) failure detection > mechanism not sure what's so specific here from a base SONET/SDH GMPLS control > 2. Yes, I do negotiate with my neighbors not to drop state in case of cp > failure ok > 3. Yes, I want to control my LSP in such state from a *single* (LSP ingress) > point, because when an LSP is created by a user (via say UNI or management > plane) it is totally up to user to decide what to do with the LSP when CP > fails. The only way the user can control this is by sending another > request(s) to the LSP ingress controller (not to egress or any transit > controller because the user may not even know their IDs). In particular, the > user may decide to continue using the service (after all it is still > carrying its traffic), but in this case the user would want to maintain > control of the LSP (for example, he may want to get notifications about data > plane alarms detected on the nodes beyond point of CP failure, likewise, he > may want to modify the LSP's admin status, setup/holding priorities, etc.) > Alternatively, he may decide to delete or reroute it. Still in any case the > user wants to control/convey its decision only to the LSP ingress > controller. you have many specific requirements but i really don't see here what's so specific here in terms of resiliency of existing cp mechanisms; you should probably try to find another name for this kind of feature here as using 'resiliency' is rather confusing btw, if your data plane is up i am not sure which kind of alarms you may want to receive and/or if there is something preventing you as of today to receive these alarms at the sender side ? > 4. No. I can not do this today because of the deficiency of RSVP - messages > on a contiguous LSP are sent on a hop-by-hop basis, meaning that any hop can > block the message just a simple comment are you sure that in such a degraded state the user is willing to make so many/various operations on its LSPs - i mean beside service availability and base maintenance operations ? would be nice to have a bit more feedback on this specific aspect > 5. Yes, I do have a simple and totally backward compatible solution how to > overcome these deficiencies. ok ... i think right time for you to write a draft about it note: don't forget to provide a complete motivation section, as well as why RSVP mechanisms/others would not be sufficient as this may seriously help assessing the value of your proposal > Igor > > > > > >>>Igor >>> >>>----- Original Message ----- >>>From: "dimitri papadimitriou" >>>To: "Igor Bryskin" >>>Cc: ; "Drake, John E" >>>; "Zafar Ali (zali)" ; "Igor >>>Bryskin" ; ; "Kim Young Hwa" >>>; >>>Sent: Monday, October 31, 2005 11:52 AM >>>Subject: Re: Two Drafts for Resilience of Control Plane >>> >>> >>> >>> >>>>igor - >>>> >>>>Igor Bryskin wrote: >>>> >>>> >>>>>Dimitri, >>>>> >>>>> >>>>> >>>>>>igor - my two cents >>>>>> >>>>>>RSVP over time has progressively borrowed mechanisms from "hard-state" >>>>>>protocols, explicit deletion using PathTear is most noticeable and >>>>>>initial example of this evolution ! >>>>>> >>>>>>but in any case, RSVP still relies is on idem-potent soft-states that >>>>>>are flushed when not refreshed after certain time interval (or self- >>>>>>maintained if previously negotiated) this prevents orphans in the >>>>>>network (so unused resources) and provides for resilience - hence > > there > >>>>>>is by no means a need to introduce an additional protocol mechanism to >>>>>>trigger or not such event via the "control plane" - >>>>> >>>>> >>>>>Refreshes are useful mechanism but only between neighbors that maintain >>>>>Hello communication. In this case the absence of Path refreshes is as >>> >>>good >>> >>> >>>>>indication that data plane must be destroyed as received PathTear >>> >>>message. >>> >>> >>>>the base function of state refresh and usefulness is independent of >>>>hello adjacency maintenance (or any other control channel maintenance) >>>> >>>> >>>> >>>>>However, when a controller does not receive Path refreshes from a >>> >>>neighbor >>> >>> >>>>>it does not have any control plane communication with, it can assume >>> >>>neither >>> >>> >>>>>a problem in the data plane nor intention to destroy it. >>>> >>>>as the node did not negotiate any channel/node fault recovery (due in >>>>part. to the absence of Hello adjacency with its neighbor) and if no >>>>other independent control channel failure is provided (this is an add-on >>>>of RFC3471/3), the simple absence of refresh is simply intepreted as >>>>"implicit deletion" >>>> >>>>you are mis-interpreting the following sentence of RFC3471 >>>> >>>>" Note that these cases only apply when there are mechanisms to detect >>>> data channel failures independent of control channel failures." >>>> >>>>there is no retro-fit on the use of Refreshes in absence of control >>>>channel failure detection mechanism >>>> >>>> >>>> >>>>>Hence, as it was >>>>>specified in RFC3471, it *must* maintain both control and data plane >>> >>>states >>> >>> >>>>>throughout the failure. >>>> >>>>- d. >>>> >>>> >>>>>Igor >>>>> >>>>> >>>>> >>>>> >>>>>>btw, the paragraph you mention in RFC3471 does not say "soft state >>>>>>protocols do not work well for non-packet environments" this is your >>>>>>interpretation; >>>>>> >>>>>>ps: you are still free to make use of RFC3472 in case (as you were >>>>>>apparently looking for something else ;-) >>>>>> >>>>>>Igor Bryskin wrote: >>>>>> >>>>>> >>>>>> >>>>>>>John, >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>>>States are supposed to be destroyed on explicit signalling >>>>>>>>>message (e.g. PathTear or PathErr with the state removal >>>>>>>>>flag), but not because of the absence of refreshes. >>>>>>>>> >>>>>>> >>>>>>>[JD] >>>>>>> >>>>>>>Igor, >>>>>>> >>>>>>>Just to be clear, we are talking about RSVP here, and RSVP *is* a > > soft > >>>>>>>state protocol. Can you point to any RFC that supports your > > statements > >>>>>>>above? >>>>>>> >>>>>>>IB>> Oh, come on, John. You sound like you've been yourself in a >>> >>>dormant >>> >>> >>>>>>>state for a while :=). We've gone a long way since RFC2205. In > > RFC3471, > >>>>>for >>>>> >>>>> >>>>> >>>>>>>example, there is a discussion why GMPLS is needed and how is it >>>>> >>>>>different >>>>> >>>>> >>>>> >>>>>>>from MPLS. One of the differences is the fact that soft state > > protocols > >>>>>do >>>>> >>>>> >>>>> >>>>>>>not work well for non-packet environments. Here is from the RDC3471: >>>>>>> >>>>>>> >>>>>>> >>>>>>>9.2. Fault Handling There are two new faults that must be handled >>>>> >>>>>when >>>>> >>>>> >>>>> >>>>>>>the control channel is independent of the data channel. In the >>> >>>first, >>> >>> >>>>>>>there is a link or other type of failure that limits the ability of >>>>>>>neighboring nodes to pass control messages. In this situation, >>>>>>>neighboring nodes are unable to exchange control messages for a >>> >>>period >>> >>> >>>>>of >>>>> >>>>> >>>>> >>>>>>>time. Once communication is restored the underlying signaling >>>>> >>>>>protocol >>>>> >>>>> >>>>> >>>>>>>must indicate that the nodes have maintained their state through > > the > >>>>>>>failure.. >>>>>>> >>>>>>>What is more important is the reality of life: The customers simply > > say > >>>>>that >>>>> >>>>> >>>>> >>>>>>>you cannot destroy a user service (or even force any traffic hits) > > just > >>>>>>>because you have a problem in the control plane. If this does not fit >>>>> >>>>>your >>>>> >>>>> >>>>> >>>>>>>soft-state paradigm, than "harden" your protocols or flash them down >>> >>>the >>> >>> >>>>>>>toilet and come with something else if you want our business. After >>> >>>all, >>> >>> >>>>>if >>>>> >>>>> >>>>> >>>>>>>we provision the services via NMS, we do not have to destroy the >>>>> >>>>>services if >>>>> >>>>> >>>>> >>>>>>>we have problems in the management network. It is that simple. >>>>>>> >>>>>>> >>>>>>> >>>>>>>Igor >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>. >>>>>>> >>>>> >>>>> >>>>> >>>>> >>>>>. >>>>> >>> >>> >>> >>> >>>. >>> > > > > > . > Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 31 Oct 2005 19:21:31 +0000 Message-ID: <019c01c5de50$2e0d7130$7a1810ac@movaz.com> From: "Igor Bryskin" To: "Drake, John E" , , , Cc: , , , , Subject: Re: Two Drafts for Resilience of Control Plane Date: Mon, 31 Oct 2005 14:20:39 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit John, > > No John, > > This is not true, I gave you a very specific problem - provide mechanisms > to > manage LSPs with impaired control plane (when one or more controllers are > out of service). > You said that this is not a problem, because RSVP is a soft state protocol > and once there are no refreshes the control data plane states must be > destroyed and hence there is nothing to manage. > And I tried very hard to explain you why this is not acceptable and hence > must be addressed. [JD] Actually, I didn't say that. What I said was that in your example, PathTear and PathError with state removed should work just fine. IB>> This would require node D, for example, to know exactly what to do with the service when it gets notified about the CP failure. Policies do not work here. It's totally upto user to decide what to do with this service. The only way it can convey this decision is by sending more requests to the LSP ingress controller. For instance, the user may decide to keep using the service for a while and then delete or reroute it before the controller B comes back. Neither of your options below therefore works. See also my response to Dimitri. Igor Due to 'CP degraded' notification, nodes C and D will know that B failed. In option a), local policy, configured via the NMS, at D will tell it whether to send a PathErr with state removed and if so, how long to wait. As stated in another e-mail, multiple CP failures are handled by configuration, via the NMS, at intermediate nodes that tell them under what circumstances and after what duration to send PathTear and /or PathErr with state removed, or whether simply to wait until the resources time-out and how long to wait before timing them out. In option b) A creates an MBB LSP on the path A, E, F, H, K, D. Subsequently, A sends a PathTear to B, and D sends a PathErr with state removed to C. The MBB LSP was created under policy control, via the NMS, at the ingress node, A. Here's your initial example: A----B------C-----D | | E-----F-----H-----K > I have a solution and am planning to write a draft. I'd like this work to > live in CCAMP. [JD] You can't get pre-approval of an I-D. > > Igor Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 31 Oct 2005 19:04:54 +0000 Message-ID: <018101c5de4d$d86d3190$7a1810ac@movaz.com> From: "Igor Bryskin" To: , Cc: , "Drake, John E" , "Zafar Ali (zali)" , "Igor Bryskin" , , "Kim Young Hwa" , Subject: Re: Two Drafts for Resilience of Control Plane Date: Mon, 31 Oct 2005 14:03:57 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Dimitri, Let me try once more. > igor > > > Suppose you have LSP going through -A-B-C- and a controller managing node B > > fails, while the data plane is intact, that is, no data plane alarms are > > detected. > > > > According to your logic such situation can exist only for 90c, because once > > controller managing node C detects the absence of 3 Path refreshes it will > > delete the control plane and destroy the service. My question is why do you > > need the RSVP graceful restart procedures then if they can happen only > > within 90c time interval - after that there will be nothing to synchronize. > > > > What we see and hear in the field, though, that a controller may stay days > > out of service and then come back and should be capable to synchronize the > > control state of all LSPs it used to manage before the crash/reboot. And, of > > course, you MUST maintain data service up and running. > > i have never said the contrary, if you run an (independent) cp failure > detection mechanism and prior negotiated cp recovery: in case of failure > in CP => GR (see RFC 3471/3) ... you are the one trying to find protocol > deficiencies while it is still totally unclear to me (but i am not the > only one apparently) where they these limitations (potentially) are ? > > on one side, you ask how to free costly resources and on the other you > ask how to maintain the connection service ... IB>>Do you believe the two requirements contradict each other? I don't think so > on one side, you ask how to free costly resources ==>only if the user decides to do so > and on the other you > ask how to maintain the connection service ... ==>only if the user decides to do so at the end, you should > decide what you want to do - i am not sure that you have understood that > you can have both at the same time IB>> 1. Yes, I do have an independent dp (not cp as you say) failure detection mechanism 2. Yes, I do negotiate with my neighbors not to drop state in case of cp failure 3. Yes, I want to control my LSP in such state from a *single* (LSP ingress) point, because when an LSP is created by a user (via say UNI or management plane) it is totally up to user to decide what to do with the LSP when CP fails. The only way the user can control this is by sending another request(s) to the LSP ingress controller (not to egress or any transit controller because the user may not even know their IDs). In particular, the user may decide to continue using the service (after all it is still carrying its traffic), but in this case the user would want to maintain control of the LSP (for example, he may want to get notifications about data plane alarms detected on the nodes beyond point of CP failure, likewise, he may want to modify the LSP's admin status, setup/holding priorities, etc.) Alternatively, he may decide to delete or reroute it. Still in any case the user wants to control/convey its decision only to the LSP ingress controller. 4. No. I can not do this today because of the deficiency of RSVP - messages on a contiguous LSP are sent on a hop-by-hop basis, meaning that any hop can block the message 5. Yes, I do have a simple and totally backward compatible solution how to overcome these deficiencies. Igor > > > Igor > > > > ----- Original Message ----- > > From: "dimitri papadimitriou" > > To: "Igor Bryskin" > > Cc: ; "Drake, John E" > > ; "Zafar Ali (zali)" ; "Igor > > Bryskin" ; ; "Kim Young Hwa" > > ; > > Sent: Monday, October 31, 2005 11:52 AM > > Subject: Re: Two Drafts for Resilience of Control Plane > > > > > > > >>igor - > >> > >>Igor Bryskin wrote: > >> > >>>Dimitri, > >>> > >>> > >>>>igor - my two cents > >>>> > >>>>RSVP over time has progressively borrowed mechanisms from "hard-state" > >>>>protocols, explicit deletion using PathTear is most noticeable and > >>>>initial example of this evolution ! > >>>> > >>>>but in any case, RSVP still relies is on idem-potent soft-states that > >>>>are flushed when not refreshed after certain time interval (or self- > >>>>maintained if previously negotiated) this prevents orphans in the > >>>>network (so unused resources) and provides for resilience - hence there > >>>>is by no means a need to introduce an additional protocol mechanism to > >>>>trigger or not such event via the "control plane" - > >>> > >>> > >>>Refreshes are useful mechanism but only between neighbors that maintain > >>>Hello communication. In this case the absence of Path refreshes is as > > > > good > > > >>>indication that data plane must be destroyed as received PathTear > > > > message. > > > >>the base function of state refresh and usefulness is independent of > >>hello adjacency maintenance (or any other control channel maintenance) > >> > >> > >>>However, when a controller does not receive Path refreshes from a > > > > neighbor > > > >>>it does not have any control plane communication with, it can assume > > > > neither > > > >>>a problem in the data plane nor intention to destroy it. > >> > >>as the node did not negotiate any channel/node fault recovery (due in > >>part. to the absence of Hello adjacency with its neighbor) and if no > >>other independent control channel failure is provided (this is an add-on > >>of RFC3471/3), the simple absence of refresh is simply intepreted as > >>"implicit deletion" > >> > >>you are mis-interpreting the following sentence of RFC3471 > >> > >>" Note that these cases only apply when there are mechanisms to detect > >> data channel failures independent of control channel failures." > >> > >>there is no retro-fit on the use of Refreshes in absence of control > >>channel failure detection mechanism > >> > >> > >>>Hence, as it was > >>>specified in RFC3471, it *must* maintain both control and data plane > > > > states > > > >>>throughout the failure. > >> > >>- d. > >> > >>>Igor > >>> > >>> > >>> > >>>>btw, the paragraph you mention in RFC3471 does not say "soft state > >>>>protocols do not work well for non-packet environments" this is your > >>>>interpretation; > >>>> > >>>>ps: you are still free to make use of RFC3472 in case (as you were > >>>>apparently looking for something else ;-) > >>>> > >>>>Igor Bryskin wrote: > >>>> > >>>> > >>>>>John, > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>>>States are supposed to be destroyed on explicit signalling > >>>>>>>message (e.g. PathTear or PathErr with the state removal > >>>>>>>flag), but not because of the absence of refreshes. > >>>>>>> > >>>>> > >>>>>[JD] > >>>>> > >>>>>Igor, > >>>>> > >>>>>Just to be clear, we are talking about RSVP here, and RSVP *is* a soft > >>>>>state protocol. Can you point to any RFC that supports your statements > >>>>>above? > >>>>> > >>>>>IB>> Oh, come on, John. You sound like you've been yourself in a > > > > dormant > > > >>>>>state for a while :=). We've gone a long way since RFC2205. In RFC3471, > >>> > >>>for > >>> > >>> > >>>>>example, there is a discussion why GMPLS is needed and how is it > >>> > >>>different > >>> > >>> > >>>>>from MPLS. One of the differences is the fact that soft state protocols > >>> > >>>do > >>> > >>> > >>>>>not work well for non-packet environments. Here is from the RDC3471: > >>>>> > >>>>> > >>>>> > >>>>>9.2. Fault Handling There are two new faults that must be handled > >>> > >>>when > >>> > >>> > >>>>>the control channel is independent of the data channel. In the > > > > first, > > > >>>>>there is a link or other type of failure that limits the ability of > >>>>>neighboring nodes to pass control messages. In this situation, > >>>>>neighboring nodes are unable to exchange control messages for a > > > > period > > > >>>of > >>> > >>> > >>>>>time. Once communication is restored the underlying signaling > >>> > >>>protocol > >>> > >>> > >>>>>must indicate that the nodes have maintained their state through the > >>>>>failure.. > >>>>> > >>>>>What is more important is the reality of life: The customers simply say > >>> > >>>that > >>> > >>> > >>>>>you cannot destroy a user service (or even force any traffic hits) just > >>>>>because you have a problem in the control plane. If this does not fit > >>> > >>>your > >>> > >>> > >>>>>soft-state paradigm, than "harden" your protocols or flash them down > > > > the > > > >>>>>toilet and come with something else if you want our business. After > > > > all, > > > >>>if > >>> > >>> > >>>>>we provision the services via NMS, we do not have to destroy the > >>> > >>>services if > >>> > >>> > >>>>>we have problems in the management network. It is that simple. > >>>>> > >>>>> > >>>>> > >>>>>Igor > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>. > >>>>> > >>> > >>> > >>> > >>> > >>>. > >>> > > > > > > > > > > . > > Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 31 Oct 2005 18:15:20 +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: comments on draft-shiba-ccamp-gmpls-lambda-labels-00.txt Date: Mon, 31 Oct 2005 10:15:03 -0800 Message-ID: <626FC7C6A97381468FB872072AB5DDC8369722@XCH-SW-42.sw.nos.boeing.com> Thread-Topic: comments on draft-shiba-ccamp-gmpls-lambda-labels-00.txt Thread-Index: AcXbIzcAFoI5B5TzS9O/zBGY1cMJbwA6iz0AAIdyNZAAAR14UAAAnn6wAABj8oAAAozZ0AAAuniQAAFlmFA= From: "Drake, John E" To: "Shiba, Sidney" , Cc: "Adrian Farrel" , , > -----Original Message----- > From: Shiba, Sidney [mailto:sidney.shiba@us.fujitsu.com] > Sent: Monday, October 31, 2005 9:38 AM > To: Drake, John E; dpapadimitriou@psg.com > Cc: Adrian Farrel; richard.rabbat@us.fujitsu.com; ccamp@ops.ietf.org > Subject: RE: comments on draft-shiba-ccamp-gmpls-lambda-labels-00.txt >=20 > John, >=20 > When multi-vendor configuration is involved, regenerators (e.g, G.709 > OEO conversion) are usually used to interface two systems. In this case, > tunable laser regenerators need to be tuned to the desired wavelength. >=20 > Hope that helps to identify the interoperability requirement. [JD]=20 So, you can only have an end-end absolute global label across a set of WDM systems from a single vendor? So what exactly is the marginal utility compared to the existing GMPLS solution? =20 >=20 > BTW, the draft provides some "requirements" related to Label Set. I'm > curious to know how this is addressed with local significance labels. [JD]=20 See my other e-mail. =20 >=20 > Thanks, >=20 > Sidney >=20 > > -----Original Message----- > > From: Drake, John E [mailto:John.E.Drake2@boeing.com] > > Sent: Monday, October 31, 2005 11:12 AM > > To: Shiba, Sidney; dpapadimitriou@psg.com > > Cc: Adrian Farrel; richard.rabbat@us.fujitsu.com; ccamp@ops.ietf.org > > Subject: RE: comments on draft-shiba-ccamp-gmpls-lambda-labels-00.txt > > > > > > Sidney > > > > 'm not sure you are addressing my concern, unless you are telling me > > that an LSP can be instantiated along a path that contains WDM systems > > from *different* vendors. I had been told that, in general, this was > > not the case. > > > > Thanks, > > > > John > > > > > -----Original Message----- > > > From: Shiba, Sidney [mailto:sidney.shiba@us.fujitsu.com] > > > Sent: Monday, October 31, 2005 8:00 AM > > > To: Drake, John E; dpapadimitriou@psg.com > > > Cc: Adrian Farrel; richard.rabbat@us.fujitsu.com; ccamp@ops.ietf.org > > > Subject: RE: comments on > > draft-shiba-ccamp-gmpls-lambda-labels-00.txt > > > > > > John, > > > > > > Most of vendor support a standardized wavelength grid > > > (e.g., ITU-T DWDM wavelength grid given in nominal value). > > > > > > If a wavelength chosen for a lightpath setup is not available > > > in an optical switch, it rejects the operation for resource > > > not being available. > > > > > > Regards, > > > > > > Sidney > > > > > > > -----Original Message----- > > > > From: Drake, John E [mailto:John.E.Drake2@boeing.com] > > > > Sent: Monday, October 31, 2005 9:51 AM > > > > To: Drake, John E; Shiba, Sidney; dpapadimitriou@psg.com > > > > Cc: Adrian Farrel; richard.rabbat@us.fujitsu.com; > > ccamp@ops.ietf.org > > > > Subject: RE: comments on > > draft-shiba-ccamp-gmpls-lambda-labels-00.txt > > > > > > > > > > > > Sidney, > > > > > > > > There's another issue as well. Having absolute end-end global > > > > wavelengths is probably insufficient to ensure that an end-end LSP > > can > > > > be established successfully, as having a common wavelength > > > > does not mean > > > > that equipment from different vendors will interoperate > > > > correctly in the > > > > data-plane. > > > > > > > > Thanks, > > > > > > > > John > > > > > > > > > -----Original Message----- > > > > > From: Drake, John E > > > > > Sent: Monday, October 31, 2005 7:36 AM > > > > > To: Shiba, Sidney; dpapadimitriou@psg.com > > > > > Cc: Adrian Farrel; richard.rabbat@us.fujitsu.com; > > ccamp@ops.ietf.org > > > > > Subject: RE: comments on > > > > draft-shiba-ccamp-gmpls-lambda-labels-00.txt > > > > > > > > > > Sidney, > > > > > > > > > > But there's nothing in your picture that requires an > > > > absolute end-end > > > > > global wavelength. The existing GMPLS solution with relative > > > > > wavelengths of local significance should work just fine. > > > > As I said in > > > > > my previous note, your method precludes combining two or > > > > more parallel > > > > > WDM links into a single TE link. > > > > > > > > > > Thanks, > > > > > > > > > > John > > > > > > > > > > > -----Original Message----- > > > > > > From: Shiba, Sidney [mailto:sidney.shiba@us.fujitsu.com] > > > > > > Sent: Monday, October 31, 2005 7:25 AM > > > > > > To: Drake, John E; dpapadimitriou@psg.com > > > > > > Cc: Adrian Farrel; richard.rabbat@us.fujitsu.com; > > > > ccamp@ops.ietf.org > > > > > > Subject: RE: comments on > > > > draft-shiba-ccamp-gmpls-lambda-labels-00.txt > > > > > > > > > > > > Hi John, > > > > > > > > > > > > Optical switches based on Wavelength Selective Switch (WSS) > > > > technology > > > > > > requires the wavelength information for switching. This > > technology > > > > is > > > > > NOT > > > > > > wavelength agnostic. > > > > > > > > > > > > | | > > > > > > | wdm | wdm > > > > > > |2 |2 > > > > > > --------- --------- > > > > > > wdm 1| optical |3 wdm 1| optical |3 wdm > > > > > > --------| switch |------------| switch |--------- > > > > > > | (WSS) | | (WSS) | > > > > > > --------- --------- > > > > > > |4 |4 > > > > > > | wdm | wdm > > > > > > | | > > > > > > > > > > > > Note that the figure above shows an example of two > > > > optical switches > > > > > > interconnect > > > > > > by a single WDM fiber. In this example, each optical > > switch can > > be > > > > > connect > > > > > > to 4 > > > > > > other optical switches. > > > > > > > > > > > > As you can see, the optical ports information do not > > > > provide enough > > > > > > information > > > > > > for wavelength switching. > > > > > > > > > > > > Hope that clarifies the application requirement. > > > > > > > > > > > > Thanks, > > > > > > > > > > > > Sidney > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Drake, John E [mailto:John.E.Drake2@boeing.com] > > > > > > > Sent: Friday, October 28, 2005 5:33 PM > > > > > > > To: dpapadimitriou@psg.com; Shiba, Sidney > > > > > > > Cc: Adrian Farrel; richard.rabbat@us.fujitsu.com; > > > > ccamp@ops.ietf.org > > > > > > > Subject: RE: comments on > > > > > draft-shiba-ccamp-gmpls-lambda-labels-00.txt > > > > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > Below is the text of an e-mail is sent to the Ethernet/GMPLS > > > > mailing > > > > > > > list. > > > > > > > > > > > > > > Upon reflection I am not sure using a real wavelength > > > > value makes > > > > > much > > > > > > > sense. Between a pair of adjacent nodes, there may be > > > > > > > multiple pairs of > > > > > > > switch ports in the same TE link that support a given > > frequency. > > > > If > > > > > a > > > > > > > real wavelength value is used, how do the two nodes agree on > > > > > > > which pair > > > > > > > of switch ports to use? > > > > > > > > > > > > > > Furthermore, the amount of configuration is the same - you > > > > > > > still need to > > > > > > > configure the wavelength of each switch port. > > > > > > > > > > > > > > Thanks, > > > > > > > > > > > > > > John > > > > > > > > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > > > > =3D=3D=3D=3D > > > > > > > Adrian, > > > > > > > > > > > > > > In the transparent photonic lambda switch case, the labels > > also > > > > have > > > > > > > only local significance. When an LSP is established, the > > input > > > > > ports, > > > > > > > as identified with local labels, are cross-connected to > > > > the output > > > > > > > ports, as identified with local labels. > > > > > > > > > > > > > > There is just extra configuration to identify, > > using strictly > > > > local > > > > > > > identifiers, the wavelength associated with the all of the > > > > switch's > > > > > > > ports, and an additional CAC requirement that the > > wavelengths > > of > > > > the > > > > > > > input and output ports are the same. > > > > > > > > > > > > > > Thanks, > > > > > > > > > > > > > > John > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: dimitri papadimitriou > > [mailto:dpapadimitriou@psg.com] > > > > > > > > Sent: Thursday, October 27, 2005 10:03 AM > > > > > > > > To: Shiba, Sidney > > > > > > > > Cc: dimitri.papadimitriou@alcatel.be; Adrian Farrel; > > > > > > > > richard.rabbat@us.fujitsu.com; ccamp@ops.ietf.org > > > > > > > > Subject: Re: comments on > > > > > > > draft-shiba-ccamp-gmpls-lambda-labels-00.txt > > > > > > > > > > > > > > > > shiba - see inline for some additional hints: > > > > > > > > > > > > > > > > >>Shiba, Sidney wrote: > > > > > > > > >> > > > > > > > > >>>Adrian, Dimitri, > > > > > > > > >>> > > > > > > > > >>>Thanks for reviewing these I-D. > > > > > > > > >>> > > > > > > > > >>>Wavelength continuity constraint does require > > the use of > > > > > > > semanticful > > > > > > > > >>>label whether it is spectral or index. > > > > > > > > >> > > > > > > > > >>=3D> see my reply to adrian on this specific point > > > > > > > > >> > > > > > > > > >>>I agree with Dimitri that the > > > > > > > > >>>wavelength indexing requires document updating > > each time > > a > > > > new > > > > > > > > >>>spectrum is introduced. > > > > > > > > >> > > > > > > > > >>=3D> indeed and in addition it requires updating > > the already > > > > > > > > >>signaled path > > > > > > > > >> > > > > > > > > >>>The use of spectral label provides self maintainance, > > i.e., > > > > > > > > >>>no need to update any document and the use of > > the nominal > > > > value > > > > > > > > >>>provides a common semantic ground. > > > > > > > > >> > > > > > > > > >>=3D> what do you mean by self-maintenance - would you > > > > provide a > > > > > > > > >>bit more detail > > > > > > > > > > > > > > > > > > [Sidney]What I've meant here was that it was not > > > > necessary to > > > > > > > > > update any document when new wavelengths are > > inventoried. > > In > > > > the > > > > > > > > > case of indexing approach, it would require the > > > > > > > wavelength indexing > > > > > > > > > document to be updated with implementation impacts. > > > > > > > > > > > > > > > > > > In the case, the nominal value is used, there is no need > > for > > > > > > > > > documentation update. > > > > > > > > > > > > > > > > ok - what you mean here is that you are going to make > > > > use of the > > > > > > > already > > > > > > > > defined C-Type 2 - what about the specific encoding of the > > > > > > > value space > > > > > > > ? > > > > > > > > > > > > > > > > >>=3D> now i have a more specific question before being > > light-up > > > > > > > > >>how do you know the frequency that you can support ? > > > > > > > > > > > > > > > > > > [Sidney] Some new technologies integrate optical switch > > and > > > > > > > mux/demux > > > > > > > > > capabilities, which allows the equipment to know > > > > the spectrum > > > > it > > > > > > > > supports. > > > > > > > > > > > > > > > > indeed - but the question is what does happen if the > > > > > > > "detected" values > > > > > > > > (during initialization) do not match the nominal values ? > > you > > > > > don't > > > > > > > > initialize then ? > > > > > > > > > > > > > > > > >>if these differ from the nominal values how are > > you going > > to > > > > > deal > > > > > > > with > > > > > > > > these > > > > > > > > >>discrepancies ? > > > > > > > > > > > > > > > > > > [Sidney] These new technologies uses the > > nominal value as > > > > > > > reference. > > > > > > > We > > > > > > > > can say > > > > > > > > > that a lightpath wavelength is identified by its nominal > > > > value. > > > > > If > > > > > > > the > > > > > > > > equipment > > > > > > > > > is drifting from this nominal value, it is considered as > > > > > > > a failure. > > > > > > > > > > > > > > > > ok - but if the deviation is such you have > > overlap - how the > > > > > control > > > > > > > > plane is going to be able to detect such failure ? > > > > > > > > > > > > > > > > >>this said i am not necessarily sure that having to > > > > > > > maintain the data > > > > > > > > plane > > > > > > > > >>specifics as part of the control plane is really helping > > > > > > > > >>operations (is this method not just duplicating > > > > complexity ?) > > > > > > > > > > > > > > > > > > [Sidney] The wavelength is WDM specific as much as the > > SUKLM > > > > > label > > > > > > > > encoding > > > > > > > > > is for SONET. The wavelegth/frequency nominal value > > > > is used to > > > > > > > identify > > > > > > > > the > > > > > > > > > facilities to cross-connect. > > > > > > > > > > > > > > > > there is an equivalence but there is also a major > > difference, > > > > the > > > > > > > > structure is invariant independently of the state of the > > > > > > > network, with > > > > > > > > spectral value space you may have labels that become > > > > unavailable > > > > > due > > > > > > > to > > > > > > > > non-local usage of wavelength in the network > > > > > > > > > > > > > > > > hence, there is also no real coupling to the data > > plane more > > > > than > > > > > > > > knowing the type of interface and some generic > > capabilities > > > > > > > > > > > > > > > > >>>I'm not sure if the draft needs to be updated > > before the > > > > > > > > >>>face-to-face meeting or after all comments are > > collected. > > > > > Please > > > > > > > > advise. > > > > > > > > >> > > > > > > > > >>=3D> suggest to keep discussion on - document > > update can be > > > > > > > > >>performed at a later stage > > > > > > > > > > > > > > > > thanks, > > > > > > > > - dimitri. > > > > > > > > > > > > > > > > >>>>-----Original Message----- > > > > > > > > >>>>From: owner-ccamp@ops.ietf.org > > > > > > > [mailto:owner-ccamp@ops.ietf.org]On > > > > > > > > >>>>Behalf Of Adrian Farrel > > > > > > > > >>>>Sent: Thursday, October 27, 2005 4:45 AM > > > > > > > > >>>>To: dpapadimitriou@psg.com; > > > > dimitri.papadimitriou@alcatel.be; > > > > > > > > >>>>ccamp@ops.ietf.org > > > > > > > > >>>>Subject: Re: comments on > > > > > > > > >> > > > > > > > > >>draft-shiba-ccamp-gmpls-lambda-labels-00.txt > > > > > > > > >> > > > > > > > > >>>> > > > > > > > > >>>>Dimitri, > > > > > > > > >>>> > > > > > > > > >>>>Thanks for your work reviewing these recent > > I-Ds. It is > > > > > > > > >>>>really valuable > > > > > > > > >>>>and I'd welcome other people doing similar reviews. > > > > > > > > >>>> > > > > > > > > >>>> > > > > > > > > >>>> > > > > > > > > >>>>>there is a specific point to be clarified in > > > > this document: > > > > > > > > >>>>> > > > > > > > > >>>>>semanticless vs semanticful label (even here > > there is a > > > > > > > distinction > > > > > > > > >>>>>between spectral vs indexes i.e. using the wavelength > > > > index) > > > > > > > > >>>>> > > > > > > > > >>>>>domain-wide vs link local significant label > > > > > > > > >>>> > > > > > > > > >>>>Without being too picky, I think all labels are > > > > semanticful > > > > > > > > >>>>otherwise, we > > > > > > > > >>>>would not know what resource they refered to. > > > > > > > > >>>> > > > > > > > > >>>>So the point reduces to whether the scope of the > > semantics > > > > > > > > >>>>are link-local > > > > > > > > >>>>or wider. > > > > > > > > >>>> > > > > > > > > >>>> > > > > > > > > >>>> > > > > > > > > >>>>>so, the comparison from this perspective with > > > > TDM labels is > > > > > > > > >>>> > > > > > > > > >>>>difficult to > > > > > > > > >>>> > > > > > > > > >>>> > > > > > > > > >>>>>parse, the latter is semanticful but link local > > > > > > > > >>>>> > > > > > > > > >>>>>now, i don't specifically see what has > > changed the late > > > > 90's, > > > > > > > early > > > > > > > > >>>>>y2k's, to have a change in the wavelength label > > > > definition; > > > > > > > > >>>> > > > > > > > > >>>>This is the question I would like to get to the bottom > > of. > > > > In > > > > > > > > >>>>other words: > > > > > > > > >>>>do we need this function? > > > > > > > > >>>> > > > > > > > > >>>>It seems to me that the question being asked is this: > > > > > > > > >>>> > > > > > > > > >>>> If I want to compute a path that has some form of > > > > wavelength > > > > > > > > >>>> constraints, what information do I need access to? > > > > > > > > >>>> > > > > > > > > >>>>Another question might be: > > > > > > > > >>>> > > > > > > > > >>>> If I want to signal a path with wavelength > > constraints > > > > what > > > > > > > > >>>> information do I need to include in the > > > > signaling message? > > > > > > > > >>>> > > > > > > > > >>>> > > > > > > > > >>>>I'd suggest that when we started on GMPLS, we were > > > > > > > > >> > > > > > > > > >>enthusiastic about > > > > > > > > >> > > > > > > > > >>>>transparent optical networks, but we were not properly > > > > > > > > >>>>focusing wavelength > > > > > > > > >>>>constraints because lambda-switching PXCs didn't take > > off. > > > > > > > > >>>>Therefore we > > > > > > > > >>>>didn't examine the requirements for wavelength > > constraints > > > > in > > > > > > > > >>>>routing and > > > > > > > > >>>>signaling. The authors of this I-D are claiming > > > > new hardware > > > > > > > > >>>>requirements > > > > > > > > >>>>for the same function. > > > > > > > > >>>> > > > > > > > > >>>> > > > > > > > > >>>> > > > > > > > > >>>>>there are > > > > > > > > >>>>>several solution possible > > > > > > > > >>>>> > > > > > > > > >>>>>- absolute values: the freq. of the wavelength: > > difficult > > > > to > > > > > > > adopt > > > > > > > > >>>>>because referenced values are nominal and knowing all > > > > > > > interactions > > > > > > > > >>>>>between wavelengths this knowledge is at the end > > > > of little > > > > > > > > >> > > > > > > > > >>practical > > > > > > > > >> > > > > > > > > >>>>>usage; (introduces implicit ordering) > > > > > > > > >>>>> > > > > > > > > >>>>>- indexed values: the # of the wavelength: > > it does not > > > > > > > > >> > > > > > > > > >>provide for a > > > > > > > > >> > > > > > > > > >>>>>future proof label space for inst. in case new > > > > frequencies > > > > > > > > >>>> > > > > > > > > >>>>are inserted > > > > > > > > >>>> > > > > > > > > >>>> > > > > > > > > >>>>>in the grid (introduces explicit ordering) > > > > > > > > >>>>> > > > > > > > > >>>>>- diff. values e.g. freq spacing starting from a > > > > reference > > > > > > > > >>>> > > > > > > > > >>>>value: pauses > > > > > > > > >>>> > > > > > > > > >>>> > > > > > > > > >>>>>the question of the reference value and does suffer > > from > > > > the > > > > > > > former > > > > > > > > >>>>>issue (introduces implicit ordering) > > > > > > > > >>>>> > > > > > > > > >>>>>- the solution available today - cumbersome in some > > > > > > > control plane > > > > > > > > >>>>>operations (e.g. label set translation) and > > not easy to > > > > > > > > >>>> > > > > > > > > >>>>troubleshoot but > > > > > > > > >>>> > > > > > > > > >>>> > > > > > > > > >>>>>independent of any physical consideration > > > > (spectral), scale > > > > > to > > > > > > > any > > > > > > > > >>>>>number of wavelength per fiber, does not > > introduce any > > > > > > > > >> > > > > > > > > >>ordering, the > > > > > > > > >> > > > > > > > > >>>>>most flexible (since allowing each system to maintain > > its > > > > > > > specific > > > > > > > > >>>>>control operations) and the less constraining since > > > > > maintaining > > > > > > > the > > > > > > > > >>>>>control plane operations independent of any > > data plane > > > > > > > specifics > > > > > > > > >>>>> > > > > > > > > >>>>> > > > > > > > > >>>> > > > > > > > > > > > > >>>> > > > > > > > >>> > > > > > > > > >>>ambda-labels > > > > > > > > >>>-00.txt> > > > > > > > > >>> > > > > > > > > >>>. > > > > > > > > >>> > > > > > > > > >> > > > > > > > > > > > > > > > > > > . > > > > > > > > > > > > > > > > > > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 31 Oct 2005 18:11:18 +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: comments on draft-shiba-ccamp-gmpls-lambda-labels-00.txt Date: Mon, 31 Oct 2005 10:10:14 -0800 Message-ID: <626FC7C6A97381468FB872072AB5DDC8369721@XCH-SW-42.sw.nos.boeing.com> Thread-Topic: comments on draft-shiba-ccamp-gmpls-lambda-labels-00.txt Thread-Index: AcXbIzcAFoI5B5TzS9O/zBGY1cMJbwA6iz0AAIdyNZAAAR14UAAAqdxAAAGnFZAAAGLHsAAC5pxQ From: "Drake, John E" To: "Shiba, Sidney" , Cc: "Adrian Farrel" , , Snipped... > > [Sidney] May be I'm missing something but for example, can you explain > me how can we use Label Set with labels that only have local significance? >=20 [JD]=20 >From RFC 3471: "The receiver of a Label Set must restrict its choice of labels to one which is in the Label Set. Much like a label, a Label Set may be present across multiple hops. In this case each node generates its own outgoing Label Set, possibly based on the incoming Label Set and the node's hardware capabilities. This case is expected to be the norm for nodes with conversion incapable (CI-incapable) interfaces." Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 31 Oct 2005 17:41:19 +0000 Message-ID: <43665728.6030003@psg.com> Date: Mon, 31 Oct 2005 18:40:56 +0100 From: dimitri papadimitriou Reply-To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.11) Gecko/20050728 MIME-Version: 1.0 To: Igor Bryskin CC: dimitri.papadimitriou@alcatel.be, "Drake, John E" , "Zafar Ali (zali)" , Igor Bryskin , drake@movaz.com, Kim Young Hwa , ccamp@ops.ietf.org Subject: Re: Two Drafts for Resilience of Control Plane Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit igor > Suppose you have LSP going through -A-B-C- and a controller managing node B > fails, while the data plane is intact, that is, no data plane alarms are > detected. > > According to your logic such situation can exist only for 90c, because once > controller managing node C detects the absence of 3 Path refreshes it will > delete the control plane and destroy the service. My question is why do you > need the RSVP graceful restart procedures then if they can happen only > within 90c time interval - after that there will be nothing to synchronize. > > What we see and hear in the field, though, that a controller may stay days > out of service and then come back and should be capable to synchronize the > control state of all LSPs it used to manage before the crash/reboot. And, of > course, you MUST maintain data service up and running. i have never said the contrary, if you run an (independent) cp failure detection mechanism and prior negotiated cp recovery: in case of failure in CP => GR (see RFC 3471/3) ... you are the one trying to find protocol deficiencies while it is still totally unclear to me (but i am not the only one apparently) where they these limitations (potentially) are ? on one side, you ask how to free costly resources and on the other you ask how to maintain the connection service ... at the end, you should decide what you want to do - i am not sure that you have understood that you can have both at the same time > Igor > > ----- Original Message ----- > From: "dimitri papadimitriou" > To: "Igor Bryskin" > Cc: ; "Drake, John E" > ; "Zafar Ali (zali)" ; "Igor > Bryskin" ; ; "Kim Young Hwa" > ; > Sent: Monday, October 31, 2005 11:52 AM > Subject: Re: Two Drafts for Resilience of Control Plane > > > >>igor - >> >>Igor Bryskin wrote: >> >>>Dimitri, >>> >>> >>>>igor - my two cents >>>> >>>>RSVP over time has progressively borrowed mechanisms from "hard-state" >>>>protocols, explicit deletion using PathTear is most noticeable and >>>>initial example of this evolution ! >>>> >>>>but in any case, RSVP still relies is on idem-potent soft-states that >>>>are flushed when not refreshed after certain time interval (or self- >>>>maintained if previously negotiated) this prevents orphans in the >>>>network (so unused resources) and provides for resilience - hence there >>>>is by no means a need to introduce an additional protocol mechanism to >>>>trigger or not such event via the "control plane" - >>> >>> >>>Refreshes are useful mechanism but only between neighbors that maintain >>>Hello communication. In this case the absence of Path refreshes is as > > good > >>>indication that data plane must be destroyed as received PathTear > > message. > >>the base function of state refresh and usefulness is independent of >>hello adjacency maintenance (or any other control channel maintenance) >> >> >>>However, when a controller does not receive Path refreshes from a > > neighbor > >>>it does not have any control plane communication with, it can assume > > neither > >>>a problem in the data plane nor intention to destroy it. >> >>as the node did not negotiate any channel/node fault recovery (due in >>part. to the absence of Hello adjacency with its neighbor) and if no >>other independent control channel failure is provided (this is an add-on >>of RFC3471/3), the simple absence of refresh is simply intepreted as >>"implicit deletion" >> >>you are mis-interpreting the following sentence of RFC3471 >> >>" Note that these cases only apply when there are mechanisms to detect >> data channel failures independent of control channel failures." >> >>there is no retro-fit on the use of Refreshes in absence of control >>channel failure detection mechanism >> >> >>>Hence, as it was >>>specified in RFC3471, it *must* maintain both control and data plane > > states > >>>throughout the failure. >> >>- d. >> >>>Igor >>> >>> >>> >>>>btw, the paragraph you mention in RFC3471 does not say "soft state >>>>protocols do not work well for non-packet environments" this is your >>>>interpretation; >>>> >>>>ps: you are still free to make use of RFC3472 in case (as you were >>>>apparently looking for something else ;-) >>>> >>>>Igor Bryskin wrote: >>>> >>>> >>>>>John, >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>>>States are supposed to be destroyed on explicit signalling >>>>>>>message (e.g. PathTear or PathErr with the state removal >>>>>>>flag), but not because of the absence of refreshes. >>>>>>> >>>>> >>>>>[JD] >>>>> >>>>>Igor, >>>>> >>>>>Just to be clear, we are talking about RSVP here, and RSVP *is* a soft >>>>>state protocol. Can you point to any RFC that supports your statements >>>>>above? >>>>> >>>>>IB>> Oh, come on, John. You sound like you've been yourself in a > > dormant > >>>>>state for a while :=). We've gone a long way since RFC2205. In RFC3471, >>> >>>for >>> >>> >>>>>example, there is a discussion why GMPLS is needed and how is it >>> >>>different >>> >>> >>>>>from MPLS. One of the differences is the fact that soft state protocols >>> >>>do >>> >>> >>>>>not work well for non-packet environments. Here is from the RDC3471: >>>>> >>>>> >>>>> >>>>>9.2. Fault Handling There are two new faults that must be handled >>> >>>when >>> >>> >>>>>the control channel is independent of the data channel. In the > > first, > >>>>>there is a link or other type of failure that limits the ability of >>>>>neighboring nodes to pass control messages. In this situation, >>>>>neighboring nodes are unable to exchange control messages for a > > period > >>>of >>> >>> >>>>>time. Once communication is restored the underlying signaling >>> >>>protocol >>> >>> >>>>>must indicate that the nodes have maintained their state through the >>>>>failure.. >>>>> >>>>>What is more important is the reality of life: The customers simply say >>> >>>that >>> >>> >>>>>you cannot destroy a user service (or even force any traffic hits) just >>>>>because you have a problem in the control plane. If this does not fit >>> >>>your >>> >>> >>>>>soft-state paradigm, than "harden" your protocols or flash them down > > the > >>>>>toilet and come with something else if you want our business. After > > all, > >>>if >>> >>> >>>>>we provision the services via NMS, we do not have to destroy the >>> >>>services if >>> >>> >>>>>we have problems in the management network. It is that simple. >>>>> >>>>> >>>>> >>>>>Igor >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>. >>>>> >>> >>> >>> >>> >>>. >>> > > > > > . > Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 31 Oct 2005 17:38:34 +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: comments on draft-shiba-ccamp-gmpls-lambda-labels-00.txt Date: Mon, 31 Oct 2005 11:38:10 -0600 Message-ID: <7CA873794E52904EAA980A074B076779B17C65@rchemx01.fnc.net.local> Thread-Topic: comments on draft-shiba-ccamp-gmpls-lambda-labels-00.txt Thread-Index: AcXbIzcAFoI5B5TzS9O/zBGY1cMJbwA6iz0AAIdyNZAAAR14UAAAnn6wAABj8oAAAozZ0AAAuniQ From: "Shiba, Sidney" To: "Drake, John E" , Cc: "Adrian Farrel" , , John, When multi-vendor configuration is involved, regenerators (e.g, G.709 OEO conversion) are usually used to interface two systems. In this case, tunable laser regenerators need to be tuned to the desired wavelength. Hope that helps to identify the interoperability requirement. BTW, the draft provides some "requirements" related to Label Set. I'm=20 curious to know how this is addressed with local significance labels. Thanks, Sidney > -----Original Message----- > From: Drake, John E [mailto:John.E.Drake2@boeing.com] > Sent: Monday, October 31, 2005 11:12 AM > To: Shiba, Sidney; dpapadimitriou@psg.com > Cc: Adrian Farrel; richard.rabbat@us.fujitsu.com; ccamp@ops.ietf.org > Subject: RE: comments on draft-shiba-ccamp-gmpls-lambda-labels-00.txt >=20 >=20 > Sidney >=20 > 'm not sure you are addressing my concern, unless you are telling me > that an LSP can be instantiated along a path that contains WDM systems > from *different* vendors. I had been told that, in general, this was > not the case. >=20 > Thanks, >=20 > John >=20 > > -----Original Message----- > > From: Shiba, Sidney [mailto:sidney.shiba@us.fujitsu.com] > > Sent: Monday, October 31, 2005 8:00 AM > > To: Drake, John E; dpapadimitriou@psg.com > > Cc: Adrian Farrel; richard.rabbat@us.fujitsu.com; ccamp@ops.ietf.org > > Subject: RE: comments on=20 > draft-shiba-ccamp-gmpls-lambda-labels-00.txt > >=20 > > John, > >=20 > > Most of vendor support a standardized wavelength grid > > (e.g., ITU-T DWDM wavelength grid given in nominal value). > >=20 > > If a wavelength chosen for a lightpath setup is not available > > in an optical switch, it rejects the operation for resource > > not being available. > >=20 > > Regards, > >=20 > > Sidney > >=20 > > > -----Original Message----- > > > From: Drake, John E [mailto:John.E.Drake2@boeing.com] > > > Sent: Monday, October 31, 2005 9:51 AM > > > To: Drake, John E; Shiba, Sidney; dpapadimitriou@psg.com > > > Cc: Adrian Farrel; richard.rabbat@us.fujitsu.com;=20 > ccamp@ops.ietf.org > > > Subject: RE: comments on > draft-shiba-ccamp-gmpls-lambda-labels-00.txt > > > > > > > > > Sidney, > > > > > > There's another issue as well. Having absolute end-end global > > > wavelengths is probably insufficient to ensure that an end-end LSP > can > > > be established successfully, as having a common wavelength > > > does not mean > > > that equipment from different vendors will interoperate > > > correctly in the > > > data-plane. > > > > > > Thanks, > > > > > > John > > > > > > > -----Original Message----- > > > > From: Drake, John E > > > > Sent: Monday, October 31, 2005 7:36 AM > > > > To: Shiba, Sidney; dpapadimitriou@psg.com > > > > Cc: Adrian Farrel; richard.rabbat@us.fujitsu.com; > ccamp@ops.ietf.org > > > > Subject: RE: comments on > > > draft-shiba-ccamp-gmpls-lambda-labels-00.txt > > > > > > > > Sidney, > > > > > > > > But there's nothing in your picture that requires an > > > absolute end-end > > > > global wavelength. The existing GMPLS solution with relative > > > > wavelengths of local significance should work just fine. > > > As I said in > > > > my previous note, your method precludes combining two or > > > more parallel > > > > WDM links into a single TE link. > > > > > > > > Thanks, > > > > > > > > John > > > > > > > > > -----Original Message----- > > > > > From: Shiba, Sidney [mailto:sidney.shiba@us.fujitsu.com] > > > > > Sent: Monday, October 31, 2005 7:25 AM > > > > > To: Drake, John E; dpapadimitriou@psg.com > > > > > Cc: Adrian Farrel; richard.rabbat@us.fujitsu.com; > > > ccamp@ops.ietf.org > > > > > Subject: RE: comments on > > > draft-shiba-ccamp-gmpls-lambda-labels-00.txt > > > > > > > > > > Hi John, > > > > > > > > > > Optical switches based on Wavelength Selective Switch (WSS) > > > technology > > > > > requires the wavelength information for switching. This > technology > > > is > > > > NOT > > > > > wavelength agnostic. > > > > > > > > > > | | > > > > > | wdm | wdm > > > > > |2 |2 > > > > > --------- --------- > > > > > wdm 1| optical |3 wdm 1| optical |3 wdm > > > > > --------| switch |------------| switch |--------- > > > > > | (WSS) | | (WSS) | > > > > > --------- --------- > > > > > |4 |4 > > > > > | wdm | wdm > > > > > | | > > > > > > > > > > Note that the figure above shows an example of two > > > optical switches > > > > > interconnect > > > > > by a single WDM fiber. In this example, each optical=20 > switch can > be > > > > connect > > > > > to 4 > > > > > other optical switches. > > > > > > > > > > As you can see, the optical ports information do not > > > provide enough > > > > > information > > > > > for wavelength switching. > > > > > > > > > > Hope that clarifies the application requirement. > > > > > > > > > > Thanks, > > > > > > > > > > Sidney > > > > > > > > > > > -----Original Message----- > > > > > > From: Drake, John E [mailto:John.E.Drake2@boeing.com] > > > > > > Sent: Friday, October 28, 2005 5:33 PM > > > > > > To: dpapadimitriou@psg.com; Shiba, Sidney > > > > > > Cc: Adrian Farrel; richard.rabbat@us.fujitsu.com; > > > ccamp@ops.ietf.org > > > > > > Subject: RE: comments on > > > > draft-shiba-ccamp-gmpls-lambda-labels-00.txt > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > Below is the text of an e-mail is sent to the Ethernet/GMPLS > > > mailing > > > > > > list. > > > > > > > > > > > > Upon reflection I am not sure using a real wavelength > > > value makes > > > > much > > > > > > sense. Between a pair of adjacent nodes, there may be > > > > > > multiple pairs of > > > > > > switch ports in the same TE link that support a given > frequency. > > > If > > > > a > > > > > > real wavelength value is used, how do the two nodes agree on > > > > > > which pair > > > > > > of switch ports to use? > > > > > > > > > > > > Furthermore, the amount of configuration is the same - you > > > > > > still need to > > > > > > configure the wavelength of each switch port. > > > > > > > > > > > > Thanks, > > > > > > > > > > > > John > > > > > >=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=3D=3D=3D=3D=3D=3D=3D=3D > > > > > > =3D=3D=3D=3D > > > > > > Adrian, > > > > > > > > > > > > In the transparent photonic lambda switch case, the labels > also > > > have > > > > > > only local significance. When an LSP is established, the > input > > > > ports, > > > > > > as identified with local labels, are cross-connected to > > > the output > > > > > > ports, as identified with local labels. > > > > > > > > > > > > There is just extra configuration to identify,=20 > using strictly > > > local > > > > > > identifiers, the wavelength associated with the all of the > > > switch's > > > > > > ports, and an additional CAC requirement that the=20 > wavelengths > of > > > the > > > > > > input and output ports are the same. > > > > > > > > > > > > Thanks, > > > > > > > > > > > > John > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: dimitri papadimitriou=20 > [mailto:dpapadimitriou@psg.com] > > > > > > > Sent: Thursday, October 27, 2005 10:03 AM > > > > > > > To: Shiba, Sidney > > > > > > > Cc: dimitri.papadimitriou@alcatel.be; Adrian Farrel; > > > > > > > richard.rabbat@us.fujitsu.com; ccamp@ops.ietf.org > > > > > > > Subject: Re: comments on > > > > > > draft-shiba-ccamp-gmpls-lambda-labels-00.txt > > > > > > > > > > > > > > shiba - see inline for some additional hints: > > > > > > > > > > > > > > >>Shiba, Sidney wrote: > > > > > > > >> > > > > > > > >>>Adrian, Dimitri, > > > > > > > >>> > > > > > > > >>>Thanks for reviewing these I-D. > > > > > > > >>> > > > > > > > >>>Wavelength continuity constraint does require=20 > the use of > > > > > > semanticful > > > > > > > >>>label whether it is spectral or index. > > > > > > > >> > > > > > > > >>=3D> see my reply to adrian on this specific point > > > > > > > >> > > > > > > > >>>I agree with Dimitri that the > > > > > > > >>>wavelength indexing requires document updating=20 > each time > a > > > new > > > > > > > >>>spectrum is introduced. > > > > > > > >> > > > > > > > >>=3D> indeed and in addition it requires updating=20 > the already > > > > > > > >>signaled path > > > > > > > >> > > > > > > > >>>The use of spectral label provides self maintainance, > i.e., > > > > > > > >>>no need to update any document and the use of=20 > the nominal > > > value > > > > > > > >>>provides a common semantic ground. > > > > > > > >> > > > > > > > >>=3D> what do you mean by self-maintenance - would you > > > provide a > > > > > > > >>bit more detail > > > > > > > > > > > > > > > > [Sidney]What I've meant here was that it was not > > > necessary to > > > > > > > > update any document when new wavelengths are=20 > inventoried. > In > > > the > > > > > > > > case of indexing approach, it would require the > > > > > > wavelength indexing > > > > > > > > document to be updated with implementation impacts. > > > > > > > > > > > > > > > > In the case, the nominal value is used, there is no need > for > > > > > > > > documentation update. > > > > > > > > > > > > > > ok - what you mean here is that you are going to make > > > use of the > > > > > > already > > > > > > > defined C-Type 2 - what about the specific encoding of the > > > > > > value space > > > > > > ? > > > > > > > > > > > > > > >>=3D> now i have a more specific question before being > light-up > > > > > > > >>how do you know the frequency that you can support ? > > > > > > > > > > > > > > > > [Sidney] Some new technologies integrate optical switch > and > > > > > > mux/demux > > > > > > > > capabilities, which allows the equipment to know > > > the spectrum > > > it > > > > > > > supports. > > > > > > > > > > > > > > indeed - but the question is what does happen if the > > > > > > "detected" values > > > > > > > (during initialization) do not match the nominal values ? > you > > > > don't > > > > > > > initialize then ? > > > > > > > > > > > > > > >>if these differ from the nominal values how are=20 > you going > to > > > > deal > > > > > > with > > > > > > > these > > > > > > > >>discrepancies ? > > > > > > > > > > > > > > > > [Sidney] These new technologies uses the=20 > nominal value as > > > > > > reference. > > > > > > We > > > > > > > can say > > > > > > > > that a lightpath wavelength is identified by its nominal > > > value. > > > > If > > > > > > the > > > > > > > equipment > > > > > > > > is drifting from this nominal value, it is considered as > > > > > > a failure. > > > > > > > > > > > > > > ok - but if the deviation is such you have=20 > overlap - how the > > > > control > > > > > > > plane is going to be able to detect such failure ? > > > > > > > > > > > > > > >>this said i am not necessarily sure that having to > > > > > > maintain the data > > > > > > > plane > > > > > > > >>specifics as part of the control plane is really helping > > > > > > > >>operations (is this method not just duplicating > > > complexity ?) > > > > > > > > > > > > > > > > [Sidney] The wavelength is WDM specific as much as the > SUKLM > > > > label > > > > > > > encoding > > > > > > > > is for SONET. The wavelegth/frequency nominal value > > > is used to > > > > > > identify > > > > > > > the > > > > > > > > facilities to cross-connect. > > > > > > > > > > > > > > there is an equivalence but there is also a major > difference, > > > the > > > > > > > structure is invariant independently of the state of the > > > > > > network, with > > > > > > > spectral value space you may have labels that become > > > unavailable > > > > due > > > > > > to > > > > > > > non-local usage of wavelength in the network > > > > > > > > > > > > > > hence, there is also no real coupling to the data=20 > plane more > > > than > > > > > > > knowing the type of interface and some generic=20 > capabilities > > > > > > > > > > > > > > >>>I'm not sure if the draft needs to be updated=20 > before the > > > > > > > >>>face-to-face meeting or after all comments are=20 > collected. > > > > Please > > > > > > > advise. > > > > > > > >> > > > > > > > >>=3D> suggest to keep discussion on - document=20 > update can be > > > > > > > >>performed at a later stage > > > > > > > > > > > > > > thanks, > > > > > > > - dimitri. > > > > > > > > > > > > > > >>>>-----Original Message----- > > > > > > > >>>>From: owner-ccamp@ops.ietf.org > > > > > > [mailto:owner-ccamp@ops.ietf.org]On > > > > > > > >>>>Behalf Of Adrian Farrel > > > > > > > >>>>Sent: Thursday, October 27, 2005 4:45 AM > > > > > > > >>>>To: dpapadimitriou@psg.com; > > > dimitri.papadimitriou@alcatel.be; > > > > > > > >>>>ccamp@ops.ietf.org > > > > > > > >>>>Subject: Re: comments on > > > > > > > >> > > > > > > > >>draft-shiba-ccamp-gmpls-lambda-labels-00.txt > > > > > > > >> > > > > > > > >>>> > > > > > > > >>>>Dimitri, > > > > > > > >>>> > > > > > > > >>>>Thanks for your work reviewing these recent=20 > I-Ds. It is > > > > > > > >>>>really valuable > > > > > > > >>>>and I'd welcome other people doing similar reviews. > > > > > > > >>>> > > > > > > > >>>> > > > > > > > >>>> > > > > > > > >>>>>there is a specific point to be clarified in > > > this document: > > > > > > > >>>>> > > > > > > > >>>>>semanticless vs semanticful label (even here=20 > there is a > > > > > > distinction > > > > > > > >>>>>between spectral vs indexes i.e. using the wavelength > > > index) > > > > > > > >>>>> > > > > > > > >>>>>domain-wide vs link local significant label > > > > > > > >>>> > > > > > > > >>>>Without being too picky, I think all labels are > > > semanticful > > > > > > > >>>>otherwise, we > > > > > > > >>>>would not know what resource they refered to. > > > > > > > >>>> > > > > > > > >>>>So the point reduces to whether the scope of the > semantics > > > > > > > >>>>are link-local > > > > > > > >>>>or wider. > > > > > > > >>>> > > > > > > > >>>> > > > > > > > >>>> > > > > > > > >>>>>so, the comparison from this perspective with > > > TDM labels is > > > > > > > >>>> > > > > > > > >>>>difficult to > > > > > > > >>>> > > > > > > > >>>> > > > > > > > >>>>>parse, the latter is semanticful but link local > > > > > > > >>>>> > > > > > > > >>>>>now, i don't specifically see what has=20 > changed the late > > > 90's, > > > > > > early > > > > > > > >>>>>y2k's, to have a change in the wavelength label > > > definition; > > > > > > > >>>> > > > > > > > >>>>This is the question I would like to get to the bottom > of. > > > In > > > > > > > >>>>other words: > > > > > > > >>>>do we need this function? > > > > > > > >>>> > > > > > > > >>>>It seems to me that the question being asked is this: > > > > > > > >>>> > > > > > > > >>>> If I want to compute a path that has some form of > > > wavelength > > > > > > > >>>> constraints, what information do I need access to? > > > > > > > >>>> > > > > > > > >>>>Another question might be: > > > > > > > >>>> > > > > > > > >>>> If I want to signal a path with wavelength=20 > constraints > > > what > > > > > > > >>>> information do I need to include in the > > > signaling message? > > > > > > > >>>> > > > > > > > >>>> > > > > > > > >>>>I'd suggest that when we started on GMPLS, we were > > > > > > > >> > > > > > > > >>enthusiastic about > > > > > > > >> > > > > > > > >>>>transparent optical networks, but we were not properly > > > > > > > >>>>focusing wavelength > > > > > > > >>>>constraints because lambda-switching PXCs didn't take > off. > > > > > > > >>>>Therefore we > > > > > > > >>>>didn't examine the requirements for wavelength > constraints > > > in > > > > > > > >>>>routing and > > > > > > > >>>>signaling. The authors of this I-D are claiming > > > new hardware > > > > > > > >>>>requirements > > > > > > > >>>>for the same function. > > > > > > > >>>> > > > > > > > >>>> > > > > > > > >>>> > > > > > > > >>>>>there are > > > > > > > >>>>>several solution possible > > > > > > > >>>>> > > > > > > > >>>>>- absolute values: the freq. of the wavelength: > difficult > > > to > > > > > > adopt > > > > > > > >>>>>because referenced values are nominal and knowing all > > > > > > interactions > > > > > > > >>>>>between wavelengths this knowledge is at the end > > > of little > > > > > > > >> > > > > > > > >>practical > > > > > > > >> > > > > > > > >>>>>usage; (introduces implicit ordering) > > > > > > > >>>>> > > > > > > > >>>>>- indexed values: the # of the wavelength:=20 > it does not > > > > > > > >> > > > > > > > >>provide for a > > > > > > > >> > > > > > > > >>>>>future proof label space for inst. in case new > > > frequencies > > > > > > > >>>> > > > > > > > >>>>are inserted > > > > > > > >>>> > > > > > > > >>>> > > > > > > > >>>>>in the grid (introduces explicit ordering) > > > > > > > >>>>> > > > > > > > >>>>>- diff. values e.g. freq spacing starting from a > > > reference > > > > > > > >>>> > > > > > > > >>>>value: pauses > > > > > > > >>>> > > > > > > > >>>> > > > > > > > >>>>>the question of the reference value and does suffer > from > > > the > > > > > > former > > > > > > > >>>>>issue (introduces implicit ordering) > > > > > > > >>>>> > > > > > > > >>>>>- the solution available today - cumbersome in some > > > > > > control plane > > > > > > > >>>>>operations (e.g. label set translation) and=20 > not easy to > > > > > > > >>>> > > > > > > > >>>>troubleshoot but > > > > > > > >>>> > > > > > > > >>>> > > > > > > > >>>>>independent of any physical consideration > > > (spectral), scale > > > > to > > > > > > any > > > > > > > >>>>>number of wavelength per fiber, does not=20 > introduce any > > > > > > > >> > > > > > > > >>ordering, the > > > > > > > >> > > > > > > > >>>>>most flexible (since allowing each system to maintain > its > > > > > > specific > > > > > > > >>>>>control operations) and the less constraining since > > > > maintaining > > > > > > the > > > > > > > >>>>>control plane operations independent of any=20 > data plane > > > > > > specifics > > > > > > > >>>>> > > > > > > > >>>>> > > > > > > > >>>> > > > > > > > > > > >>>> > > > > > > >>> > > > > > > > >>>ambda-labels > > > > > > > >>>-00.txt> > > > > > > > >>> > > > > > > > >>>. > > > > > > > >>> > > > > > > > >> > > > > > > > > > > > > > > > > . > > > > > > > > > > > > > > > > > >=20 Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 31 Oct 2005 17:29:19 +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: comments on draft-shiba-ccamp-gmpls-lambda-labels-00.txt Date: Mon, 31 Oct 2005 17:28:41 -0000 Message-ID: <0536FC9B908BEC4597EE721BE6A3538912275969@i2km07-ukbr.domain1.systemhost.net> Thread-Topic: comments on draft-shiba-ccamp-gmpls-lambda-labels-00.txt Thread-Index: AcXeNcpyWStaVYm1SxaXOoXTA/t1xQACpj7g From: To: , , , Cc: , , Absolutely right.....'space' is always a consideration for 1 dimension of the labelling of resource partitions in the co-cs mode....once space has been labelled then we need to know whether we are dealing with a 'freq' or 'time' label next (there is actually a 3rd possibility wrt 'amplitutde' labelling....code division muxing). And to be of practical use, these has to be an implicit assumed binding of known bit rate to this. regards, neil > -----Original Message----- > From: owner-ccamp@ops.ietf.org=20 > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Payam Torab > Sent: 31 October 2005 16:12 > To: 'Drake, John E'; 'Shiba, Sidney'; dpapadimitriou@psg.com > Cc: 'Adrian Farrel'; richard.rabbat@us.fujitsu.com; ccamp@ops.ietf.org > Subject: RE: comments on draft-shiba-ccamp-gmpls-lambda-labels-00.txt >=20 >=20 > John- >=20 > Obviously the benefits or harms of giving a global meaning to=20 > a lambda label requires study, but your particular example is=20 > not a good one: If one really wants to have a preference for=20 > a specific wavelength channel among multiple parallel=20 > channels of the same wavelength, bundling should not be=20 > exercised in the first place. >=20 > Thanks, > Payam >=20 > -----Original Message----- > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On > Behalf Of Drake, John E > Sent: Monday, October 31, 2005 10:36 AM > To: Shiba, Sidney; dpapadimitriou@psg.com > Cc: Adrian Farrel; richard.rabbat@us.fujitsu.com; ccamp@ops.ietf.org > Subject: RE: comments on draft-shiba-ccamp-gmpls-lambda-labels-00.txt >=20 >=20 > Sidney, >=20 > But there's nothing in your picture that requires an absolute=20 > end-end global wavelength. The existing GMPLS solution with=20 > relative wavelengths of local significance should work just=20 > fine. As I said in my previous note, your method precludes=20 > combining two or more parallel WDM links into a single TE link. >=20 > Thanks, >=20 > John >=20 > > -----Original Message----- > > From: Shiba, Sidney [mailto:sidney.shiba@us.fujitsu.com] > > Sent: Monday, October 31, 2005 7:25 AM > > To: Drake, John E; dpapadimitriou@psg.com > > Cc: Adrian Farrel; richard.rabbat@us.fujitsu.com; ccamp@ops.ietf.org > > Subject: RE: comments on=20 > draft-shiba-ccamp-gmpls-lambda-labels-00.txt > >=20 > > Hi John, > >=20 > > Optical switches based on Wavelength Selective Switch (WSS)=20 > technology=20 > > requires the wavelength information for switching. This=20 > technology is > NOT > > wavelength agnostic. > >=20 > > | | > > | wdm | wdm > > |2 |2 > > --------- --------- > > wdm 1| optical |3 wdm 1| optical |3 wdm > > --------| switch |------------| switch |--------- > > | (WSS) | | (WSS) | > > --------- --------- > > |4 |4 > > | wdm | wdm > > | | > >=20 > > Note that the figure above shows an example of two optical switches=20 > > interconnect by a single WDM fiber. In this example, each optical=20 > > switch can be > connect > > to 4 > > other optical switches. > >=20 > > As you can see, the optical ports information do not provide enough=20 > > information for wavelength switching. > >=20 > > Hope that clarifies the application requirement. > >=20 > > Thanks, > >=20 > > Sidney > >=20 > > > -----Original Message----- > > > From: Drake, John E [mailto:John.E.Drake2@boeing.com] > > > Sent: Friday, October 28, 2005 5:33 PM > > > To: dpapadimitriou@psg.com; Shiba, Sidney > > > Cc: Adrian Farrel; richard.rabbat@us.fujitsu.com;=20 > ccamp@ops.ietf.org > > > Subject: RE: comments on > draft-shiba-ccamp-gmpls-lambda-labels-00.txt > > > > > > > > > Hi, > > > > > > Below is the text of an e-mail is sent to the=20 > Ethernet/GMPLS mailing=20 > > > list. > > > > > > Upon reflection I am not sure using a real wavelength value makes > much > > > sense. Between a pair of adjacent nodes, there may be multiple=20 > > > pairs of switch ports in the same TE link that support a given=20 > > > frequency. If > a > > > real wavelength value is used, how do the two nodes agree=20 > on which=20 > > > pair of switch ports to use? > > > > > > Furthermore, the amount of configuration is the same - you still=20 > > > need to configure the wavelength of each switch port. > > > > > > Thanks, > > > > > > John=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=3D=3D=3D=3D=3D=3D=3D=3D > > > =3D=3D=3D=3D > > > Adrian, > > > > > > In the transparent photonic lambda switch case, the=20 > labels also have=20 > > > only local significance. When an LSP is established, the input > ports, > > > as identified with local labels, are cross-connected to=20 > the output=20 > > > ports, as identified with local labels. > > > > > > There is just extra configuration to identify, using=20 > strictly local=20 > > > identifiers, the wavelength associated with the all of=20 > the switch's=20 > > > ports, and an additional CAC requirement that the=20 > wavelengths of the=20 > > > input and output ports are the same. > > > > > > Thanks, > > > > > > John > > > > > > > > > > -----Original Message----- > > > > From: dimitri papadimitriou [mailto:dpapadimitriou@psg.com] > > > > Sent: Thursday, October 27, 2005 10:03 AM > > > > To: Shiba, Sidney > > > > Cc: dimitri.papadimitriou@alcatel.be; Adrian Farrel;=20 > > > > richard.rabbat@us.fujitsu.com; ccamp@ops.ietf.org > > > > Subject: Re: comments on > > > draft-shiba-ccamp-gmpls-lambda-labels-00.txt > > > > > > > > shiba - see inline for some additional hints: > > > > > > > > >>Shiba, Sidney wrote: > > > > >> > > > > >>>Adrian, Dimitri, > > > > >>> > > > > >>>Thanks for reviewing these I-D. > > > > >>> > > > > >>>Wavelength continuity constraint does require the use of > > > semanticful > > > > >>>label whether it is spectral or index. > > > > >> > > > > >>=3D> see my reply to adrian on this specific point > > > > >> > > > > >>>I agree with Dimitri that the > > > > >>>wavelength indexing requires document updating each=20 > time a new=20 > > > > >>>spectrum is introduced. > > > > >> > > > > >>=3D> indeed and in addition it requires updating the already=20 > > > > >>signaled path > > > > >> > > > > >>>The use of spectral label provides self=20 > maintainance, i.e., no=20 > > > > >>>need to update any document and the use of the nominal value=20 > > > > >>>provides a common semantic ground. > > > > >> > > > > >>=3D> what do you mean by self-maintenance - would you provide = a=20 > > > > >>bit more detail > > > > > > > > > > [Sidney]What I've meant here was that it was not necessary to=20 > > > > > update any document when new wavelengths are=20 > inventoried. In the=20 > > > > > case of indexing approach, it would require the > > > wavelength indexing > > > > > document to be updated with implementation impacts. > > > > > > > > > > In the case, the nominal value is used, there is no need for=20 > > > > > documentation update. > > > > > > > > ok - what you mean here is that you are going to make use of the > > > already > > > > defined C-Type 2 - what about the specific encoding of the > > > value space > > > ? > > > > > > > > >>=3D> now i have a more specific question before being=20 > light-up how=20 > > > > >>do you know the frequency that you can support ? > > > > > > > > > > [Sidney] Some new technologies integrate optical switch and > > > mux/demux > > > > > capabilities, which allows the equipment to know the=20 > spectrum it > > > > supports. > > > > > > > > indeed - but the question is what does happen if the > > > "detected" values > > > > (during initialization) do not match the nominal values ? you > don't > > > > initialize then ? > > > > > > > > >>if these differ from the nominal values how are you going to > deal > > > with > > > > these > > > > >>discrepancies ? > > > > > > > > > > [Sidney] These new technologies uses the nominal value as > > > reference. > > > We > > > > can say > > > > > that a lightpath wavelength is identified by its=20 > nominal value. > If > > > the > > > > equipment > > > > > is drifting from this nominal value, it is considered as > > > a failure. > > > > > > > > ok - but if the deviation is such you have overlap - how the > control > > > > plane is going to be able to detect such failure ? > > > > > > > > >>this said i am not necessarily sure that having to > > > maintain the data > > > > plane > > > > >>specifics as part of the control plane is really helping=20 > > > > >>operations (is this method not just duplicating complexity ?) > > > > > > > > > > [Sidney] The wavelength is WDM specific as much as the SUKLM > label > > > > encoding > > > > > is for SONET. The wavelegth/frequency nominal value is used to > > > identify > > > > the > > > > > facilities to cross-connect. > > > > > > > > there is an equivalence but there is also a major=20 > difference, the=20 > > > > structure is invariant independently of the state of the > > > network, with > > > > spectral value space you may have labels that become unavailable > due > > > to > > > > non-local usage of wavelength in the network > > > > > > > > hence, there is also no real coupling to the data plane=20 > more than=20 > > > > knowing the type of interface and some generic capabilities > > > > > > > > >>>I'm not sure if the draft needs to be updated before the=20 > > > > >>>face-to-face meeting or after all comments are collected. > Please > > > > advise. > > > > >> > > > > >>=3D> suggest to keep discussion on - document update can be=20 > > > > >>performed at a later stage > > > > > > > > thanks, > > > > - dimitri. > > > > > > > > >>>>-----Original Message----- > > > > >>>>From: owner-ccamp@ops.ietf.org > > > [mailto:owner-ccamp@ops.ietf.org]On > > > > >>>>Behalf Of Adrian Farrel > > > > >>>>Sent: Thursday, October 27, 2005 4:45 AM > > > > >>>>To: dpapadimitriou@psg.com;=20 > dimitri.papadimitriou@alcatel.be;=20 > > > > >>>>ccamp@ops.ietf.org > > > > >>>>Subject: Re: comments on > > > > >> > > > > >>draft-shiba-ccamp-gmpls-lambda-labels-00.txt > > > > >> > > > > >>>> > > > > >>>>Dimitri, > > > > >>>> > > > > >>>>Thanks for your work reviewing these recent I-Ds.=20 > It is really=20 > > > > >>>>valuable and I'd welcome other people doing similar reviews. > > > > >>>> > > > > >>>> > > > > >>>> > > > > >>>>>there is a specific point to be clarified in this document: > > > > >>>>> > > > > >>>>>semanticless vs semanticful label (even here there is a > > > distinction > > > > >>>>>between spectral vs indexes i.e. using the=20 > wavelength index) > > > > >>>>> > > > > >>>>>domain-wide vs link local significant label > > > > >>>> > > > > >>>>Without being too picky, I think all labels are semanticful=20 > > > > >>>>otherwise, we would not know what resource they refered to. > > > > >>>> > > > > >>>>So the point reduces to whether the scope of the=20 > semantics are=20 > > > > >>>>link-local or wider. > > > > >>>> > > > > >>>> > > > > >>>> > > > > >>>>>so, the comparison from this perspective with TDM labels is > > > > >>>> > > > > >>>>difficult to > > > > >>>> > > > > >>>> > > > > >>>>>parse, the latter is semanticful but link local > > > > >>>>> > > > > >>>>>now, i don't specifically see what has changed the=20 > late 90's, > > > early > > > > >>>>>y2k's, to have a change in the wavelength label definition; > > > > >>>> > > > > >>>>This is the question I would like to get to the=20 > bottom of. In=20 > > > > >>>>other words: do we need this function? > > > > >>>> > > > > >>>>It seems to me that the question being asked is this: > > > > >>>> > > > > >>>> If I want to compute a path that has some form of=20 > wavelength =20 > > > > >>>> constraints, what information do I need access to? > > > > >>>> > > > > >>>>Another question might be: > > > > >>>> > > > > >>>> If I want to signal a path with wavelength=20 > constraints what =20 > > > > >>>> information do I need to include in the signaling message? > > > > >>>> > > > > >>>> > > > > >>>>I'd suggest that when we started on GMPLS, we were > > > > >> > > > > >>enthusiastic about > > > > >> > > > > >>>>transparent optical networks, but we were not properly=20 > > > > >>>>focusing wavelength constraints because=20 > lambda-switching PXCs=20 > > > > >>>>didn't take off. Therefore we > > > > >>>>didn't examine the requirements for wavelength=20 > constraints in > > > > >>>>routing and > > > > >>>>signaling. The authors of this I-D are claiming new hardware > > > > >>>>requirements > > > > >>>>for the same function. > > > > >>>> > > > > >>>> > > > > >>>> > > > > >>>>>there are > > > > >>>>>several solution possible > > > > >>>>> > > > > >>>>>- absolute values: the freq. of the wavelength:=20 > difficult to > > > adopt > > > > >>>>>because referenced values are nominal and knowing all > > > interactions > > > > >>>>>between wavelengths this knowledge is at the end of little > > > > >> > > > > >>practical > > > > >> > > > > >>>>>usage; (introduces implicit ordering) > > > > >>>>> > > > > >>>>>- indexed values: the # of the wavelength: it does not > > > > >> > > > > >>provide for a > > > > >> > > > > >>>>>future proof label space for inst. in case new frequencies > > > > >>>> > > > > >>>>are inserted > > > > >>>> > > > > >>>> > > > > >>>>>in the grid (introduces explicit ordering) > > > > >>>>> > > > > >>>>>- diff. values e.g. freq spacing starting from a reference > > > > >>>> > > > > >>>>value: pauses > > > > >>>> > > > > >>>> > > > > >>>>>the question of the reference value and does=20 > suffer from the > > > former > > > > >>>>>issue (introduces implicit ordering) > > > > >>>>> > > > > >>>>>- the solution available today - cumbersome in some > > > control plane > > > > >>>>>operations (e.g. label set translation) and not easy to > > > > >>>> > > > > >>>>troubleshoot but > > > > >>>> > > > > >>>> > > > > >>>>>independent of any physical consideration (spectral), scale > to > > > any > > > > >>>>>number of wavelength per fiber, does not introduce any > > > > >> > > > > >>ordering, the > > > > >> > > > > >>>>>most flexible (since allowing each system to maintain its > > > specific > > > > >>>>>control operations) and the less constraining since > maintaining > > > the > > > > >>>>>control plane operations independent of any data plane > > > specifics > > > > >>>>> > > > > >>>>> > > > > >>>> > > > >=20 > >>>> > > >>> > > > >>>ambda-labels > > > >>>-00.txt> > > > >>> > > > >>>. > > > >>> > > > >> > > > > > > > > . > > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 31 Oct 2005 17:17:51 +0000 Message-ID: <436651AE.8010701@psg.com> Date: Mon, 31 Oct 2005 18:17:34 +0100 From: dimitri papadimitriou Reply-To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.11) Gecko/20050728 MIME-Version: 1.0 To: "Shiba, Sidney" CC: "Drake, John E" , Adrian Farrel , richard.rabbat@us.fujitsu.com, ccamp@ops.ietf.org Subject: Re: comments on draft-shiba-ccamp-gmpls-lambda-labels-00.txt Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit sidney - short note to clarify the comparison with SONET/SDH Shiba, Sidney wrote: > John, > > Comments inline: > > >>-----Original Message----- >>From: Drake, John E [mailto:John.E.Drake2@boeing.com] >>Sent: Monday, October 31, 2005 9:36 AM >>To: Shiba, Sidney; dpapadimitriou@psg.com >>Cc: Adrian Farrel; richard.rabbat@us.fujitsu.com; ccamp@ops.ietf.org >>Subject: RE: comments on draft-shiba-ccamp-gmpls-lambda-labels-00.txt >> >> >>Sidney, >> >>But there's nothing in your picture that requires an absolute end-end >>global wavelength. The existing GMPLS solution with relative >>wavelengths of local significance should work just fine. > > > [Sidney] Sorry for the missing info. The optical switch is an all optical > switch (i.e., no OEO is necessary). The wavelength continuity constraint > indicates which wavelength (nominal value) all the optical switches > traversed by the lightpath needs to cross-connect. > > >>As I said in my previous note, your method precludes combining two or >>more parallel WDM links into a single TE link. > > [Sidney] Note the Label is complemented by the interface id of the link. > > I think this is the same approach used for parallel SONET OCn datalinks > where the label identifies a time-slot and interface id identifies the > datalink chosen for the connection. in RFC3946 the label does not include the interface id; the latter is part of the IF_ID RSVP_HOP TLV if you introduce a spectral wavelength label you will not be able anymore to correlate into the same (unbundled) link two data links having the same nominal wavelength; note: introducing "spectral label" would introduce a similar issue present in SDH/SONET where you can not correlate two or more "data links" in the same (unbundled) TE link with a resulting overlapping set of timeslots; however, the major difference compared with wavelength switching is that in SONET/SDH you need to construct very particular configurations for reaching this kind of restriction; also there is no real operational issue since so far with this simply because each timeslot in a given section is spatially equivalent and has identical TE properties; the situation is completely different in a wavelength switched environment >>Thanks, >> >>John >> >> >>>-----Original Message----- >>>From: Shiba, Sidney [mailto:sidney.shiba@us.fujitsu.com] >>>Sent: Monday, October 31, 2005 7:25 AM >>>To: Drake, John E; dpapadimitriou@psg.com >>>Cc: Adrian Farrel; richard.rabbat@us.fujitsu.com; ccamp@ops.ietf.org >>>Subject: RE: comments on >> >>draft-shiba-ccamp-gmpls-lambda-labels-00.txt >> >>>Hi John, >>> >>>Optical switches based on Wavelength Selective Switch (WSS) >> >>technology >> >>>requires the wavelength information for switching. This >> >>technology is >>NOT >> >>>wavelength agnostic. >>> >>> | | >>> | wdm | wdm >>> |2 |2 >>> --------- --------- >>> wdm 1| optical |3 wdm 1| optical |3 wdm >>> --------| switch |------------| switch |--------- >>> | (WSS) | | (WSS) | >>> --------- --------- >>> |4 |4 >>> | wdm | wdm >>> | | >>> >>>Note that the figure above shows an example of two optical switches >>>interconnect >>>by a single WDM fiber. In this example, each optical switch can be >> >>connect >> >>>to 4 >>>other optical switches. >>> >>>As you can see, the optical ports information do not provide enough >>>information >>>for wavelength switching. >>> >>>Hope that clarifies the application requirement. >>> >>>Thanks, >>> >>>Sidney >>> >>> >>>>-----Original Message----- >>>>From: Drake, John E [mailto:John.E.Drake2@boeing.com] >>>>Sent: Friday, October 28, 2005 5:33 PM >>>>To: dpapadimitriou@psg.com; Shiba, Sidney >>>>Cc: Adrian Farrel; richard.rabbat@us.fujitsu.com; >> >>ccamp@ops.ietf.org >> >>>>Subject: RE: comments on >> >>draft-shiba-ccamp-gmpls-lambda-labels-00.txt >> >>>> >>>>Hi, >>>> >>>>Below is the text of an e-mail is sent to the >> >>Ethernet/GMPLS mailing >> >>>>list. >>>> >>>>Upon reflection I am not sure using a real wavelength value makes >> >>much >> >>>>sense. Between a pair of adjacent nodes, there may be >>>>multiple pairs of >>>>switch ports in the same TE link that support a given >> >>frequency. If >>a >> >>>>real wavelength value is used, how do the two nodes agree on >>>>which pair >>>>of switch ports to use? >>>> >>>>Furthermore, the amount of configuration is the same - you >>>>still need to >>>>configure the wavelength of each switch port. >>>> >>>>Thanks, >>>> >>>>John >>>>============================================================== >>>>========== >>>>==== >>>>Adrian, >>>> >>>>In the transparent photonic lambda switch case, the >> >>labels also have >> >>>>only local significance. When an LSP is established, the input >> >>ports, >> >>>>as identified with local labels, are cross-connected to the output >>>>ports, as identified with local labels. >>>> >>>>There is just extra configuration to identify, using >> >>strictly local >> >>>>identifiers, the wavelength associated with the all of >> >>the switch's >> >>>>ports, and an additional CAC requirement that the >> >>wavelengths of the >> >>>>input and output ports are the same. >>>> >>>>Thanks, >>>> >>>>John >>>> >>>> >>>> >>>>>-----Original Message----- >>>>>From: dimitri papadimitriou [mailto:dpapadimitriou@psg.com] >>>>>Sent: Thursday, October 27, 2005 10:03 AM >>>>>To: Shiba, Sidney >>>>>Cc: dimitri.papadimitriou@alcatel.be; Adrian Farrel; >>>>>richard.rabbat@us.fujitsu.com; ccamp@ops.ietf.org >>>>>Subject: Re: comments on >>>> >>>>draft-shiba-ccamp-gmpls-lambda-labels-00.txt >>>> >>>>>shiba - see inline for some additional hints: >>>>> >>>>> >>>>>>>Shiba, Sidney wrote: >>>>>>> >>>>>>> >>>>>>>>Adrian, Dimitri, >>>>>>>> >>>>>>>>Thanks for reviewing these I-D. >>>>>>>> >>>>>>>>Wavelength continuity constraint does require the use of >>>> >>>>semanticful >>>> >>>>>>>>label whether it is spectral or index. >>>>>>> >>>>>>>=> see my reply to adrian on this specific point >>>>>>> >>>>>>> >>>>>>>>I agree with Dimitri that the >>>>>>>>wavelength indexing requires document updating each >> >>time a new >> >>>>>>>>spectrum is introduced. >>>>>>> >>>>>>>=> indeed and in addition it requires updating the already >>>>>>>signaled path >>>>>>> >>>>>>> >>>>>>>>The use of spectral label provides self maintainance, i.e., >>>>>>>>no need to update any document and the use of the >> >>nominal value >> >>>>>>>>provides a common semantic ground. >>>>>>> >>>>>>>=> what do you mean by self-maintenance - would you provide a >>>>>>>bit more detail >>>>>> >>>>>>[Sidney]What I've meant here was that it was not necessary to >>>>>>update any document when new wavelengths are >> >>inventoried. In the >> >>>>>>case of indexing approach, it would require the >>>> >>>>wavelength indexing >>>> >>>>>>document to be updated with implementation impacts. >>>>>> >>>>>>In the case, the nominal value is used, there is no need for >>>>>>documentation update. >>>>> >>>>>ok - what you mean here is that you are going to make use of the >>>> >>>>already >>>> >>>>>defined C-Type 2 - what about the specific encoding of the >>>> >>>>value space >>>>? >>>> >>>>>>>=> now i have a more specific question before being light-up >>>>>>>how do you know the frequency that you can support ? >>>>>> >>>>>>[Sidney] Some new technologies integrate optical switch and >>>> >>>>mux/demux >>>> >>>>>>capabilities, which allows the equipment to know the >> >>spectrum it >> >>>>>supports. >>>>> >>>>>indeed - but the question is what does happen if the >>>> >>>>"detected" values >>>> >>>>>(during initialization) do not match the nominal values ? you >> >>don't >> >>>>>initialize then ? >>>>> >>>>> >>>>>>>if these differ from the nominal values how are you going to >> >>deal >> >>>>with >>>> >>>>>these >>>>> >>>>>>>discrepancies ? >>>>>> >>>>>>[Sidney] These new technologies uses the nominal value as >>>> >>>>reference. >>>>We >>>> >>>>>can say >>>>> >>>>>>that a lightpath wavelength is identified by its >> >>nominal value. >>If >> >>>>the >>>> >>>>>equipment >>>>> >>>>>>is drifting from this nominal value, it is considered as >>>> >>>>a failure. >>>> >>>>>ok - but if the deviation is such you have overlap - how the >> >>control >> >>>>>plane is going to be able to detect such failure ? >>>>> >>>>> >>>>>>>this said i am not necessarily sure that having to >>>> >>>>maintain the data >>>> >>>>>plane >>>>> >>>>>>>specifics as part of the control plane is really helping >>>>>>>operations (is this method not just duplicating complexity ?) >>>>>> >>>>>>[Sidney] The wavelength is WDM specific as much as the SUKLM >> >>label >> >>>>>encoding >>>>> >>>>>>is for SONET. The wavelegth/frequency nominal value is used to >>>> >>>>identify >>>> >>>>>the >>>>> >>>>>>facilities to cross-connect. >>>>> >>>>>there is an equivalence but there is also a major >> >>difference, the >> >>>>>structure is invariant independently of the state of the >>>> >>>>network, with >>>> >>>>>spectral value space you may have labels that become unavailable >> >>due >> >>>>to >>>> >>>>>non-local usage of wavelength in the network >>>>> >>>>>hence, there is also no real coupling to the data plane >> >>more than >> >>>>>knowing the type of interface and some generic capabilities >>>>> >>>>> >>>>>>>>I'm not sure if the draft needs to be updated before the >>>>>>>>face-to-face meeting or after all comments are collected. >> >>Please >> >>>>>advise. >>>>> >>>>>>>=> suggest to keep discussion on - document update can be >>>>>>>performed at a later stage >>>>> >>>>>thanks, >>>>>- dimitri. >>>>> >>>>> >>>>>>>>>-----Original Message----- >>>>>>>>>From: owner-ccamp@ops.ietf.org >>>> >>>>[mailto:owner-ccamp@ops.ietf.org]On >>>> >>>>>>>>>Behalf Of Adrian Farrel >>>>>>>>>Sent: Thursday, October 27, 2005 4:45 AM >>>>>>>>>To: dpapadimitriou@psg.com; >> >>dimitri.papadimitriou@alcatel.be; >> >>>>>>>>>ccamp@ops.ietf.org >>>>>>>>>Subject: Re: comments on >>>>>>> >>>>>>>draft-shiba-ccamp-gmpls-lambda-labels-00.txt >>>>>>> >>>>>>> >>>>>>>>>Dimitri, >>>>>>>>> >>>>>>>>>Thanks for your work reviewing these recent I-Ds. It is >>>>>>>>>really valuable >>>>>>>>>and I'd welcome other people doing similar reviews. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>there is a specific point to be clarified in this document: >>>>>>>>>> >>>>>>>>>>semanticless vs semanticful label (even here there is a >>>> >>>>distinction >>>> >>>>>>>>>>between spectral vs indexes i.e. using the >> >>wavelength index) >> >>>>>>>>>>domain-wide vs link local significant label >>>>>>>>> >>>>>>>>>Without being too picky, I think all labels are semanticful >>>>>>>>>otherwise, we >>>>>>>>>would not know what resource they refered to. >>>>>>>>> >>>>>>>>>So the point reduces to whether the scope of the semantics >>>>>>>>>are link-local >>>>>>>>>or wider. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>so, the comparison from this perspective with TDM labels is >>>>>>>>> >>>>>>>>>difficult to >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>parse, the latter is semanticful but link local >>>>>>>>>> >>>>>>>>>>now, i don't specifically see what has changed the >> >>late 90's, >> >>>>early >>>> >>>>>>>>>>y2k's, to have a change in the wavelength label definition; >>>>>>>>> >>>>>>>>>This is the question I would like to get to the >> >>bottom of. In >> >>>>>>>>>other words: >>>>>>>>>do we need this function? >>>>>>>>> >>>>>>>>>It seems to me that the question being asked is this: >>>>>>>>> >>>>>>>>> If I want to compute a path that has some form of >> >>wavelength >> >>>>>>>>> constraints, what information do I need access to? >>>>>>>>> >>>>>>>>>Another question might be: >>>>>>>>> >>>>>>>>> If I want to signal a path with wavelength >> >>constraints what >> >>>>>>>>> information do I need to include in the signaling message? >>>>>>>>> >>>>>>>>> >>>>>>>>>I'd suggest that when we started on GMPLS, we were >>>>>>> >>>>>>>enthusiastic about >>>>>>> >>>>>>> >>>>>>>>>transparent optical networks, but we were not properly >>>>>>>>>focusing wavelength >>>>>>>>>constraints because lambda-switching PXCs didn't take off. >>>>>>>>>Therefore we >>>>>>>>>didn't examine the requirements for wavelength >> >>constraints in >> >>>>>>>>>routing and >>>>>>>>>signaling. The authors of this I-D are claiming new hardware >>>>>>>>>requirements >>>>>>>>>for the same function. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>there are >>>>>>>>>>several solution possible >>>>>>>>>> >>>>>>>>>>- absolute values: the freq. of the wavelength: >> >>difficult to >> >>>>adopt >>>> >>>>>>>>>>because referenced values are nominal and knowing all >>>> >>>>interactions >>>> >>>>>>>>>>between wavelengths this knowledge is at the end of little >>>>>>> >>>>>>>practical >>>>>>> >>>>>>> >>>>>>>>>>usage; (introduces implicit ordering) >>>>>>>>>> >>>>>>>>>>- indexed values: the # of the wavelength: it does not >>>>>>> >>>>>>>provide for a >>>>>>> >>>>>>> >>>>>>>>>>future proof label space for inst. in case new frequencies >>>>>>>>> >>>>>>>>>are inserted >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>in the grid (introduces explicit ordering) >>>>>>>>>> >>>>>>>>>>- diff. values e.g. freq spacing starting from a reference >>>>>>>>> >>>>>>>>>value: pauses >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>the question of the reference value and does >> >>suffer from the >> >>>>former >>>> >>>>>>>>>>issue (introduces implicit ordering) >>>>>>>>>> >>>>>>>>>>- the solution available today - cumbersome in some >>>> >>>>control plane >>>> >>>>>>>>>>operations (e.g. label set translation) and not easy to >>>>>>>>> >>>>>>>>>troubleshoot but >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>independent of any physical consideration (spectral), scale >> >>to >> >>>>any >>>> >>>>>>>>>>number of wavelength per fiber, does not introduce any >>>>>>> >>>>>>>ordering, the >>>>>>> >>>>>>> >>>>>>>>>>most flexible (since allowing each system to maintain its >>>> >>>>specific >>>> >>>>>>>>>>control operations) and the less constraining since >> >>maintaining >> >>>>the >>>> >>>>>>>>>>control plane operations independent of any data plane >>>> >>>>specifics >>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>ambda-labels >>>>>>>>-00.txt> >>>>>>>> >>>>>>>>. >>>>>>>> >>>>>>> >>>>>>. >>>>>> >>>> > > > . > Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 31 Oct 2005 17:17:30 +0000 Message-ID: <015b01c5de3e$f2a2a090$7a1810ac@movaz.com> From: "Igor Bryskin" To: , Cc: , "Drake, John E" , "Zafar Ali (zali)" , "Igor Bryskin" , , "Kim Young Hwa" , Subject: Re: Two Drafts for Resilience of Control Plane Date: Mon, 31 Oct 2005 12:17:18 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Dimitri, Suppose you have LSP going through -A-B-C- and a controller managing node B fails, while the data plane is intact, that is, no data plane alarms are detected. According to your logic such situation can exist only for 90c, because once controller managing node C detects the absence of 3 Path refreshes it will delete the control plane and destroy the service. My question is why do you need the RSVP graceful restart procedures then if they can happen only within 90c time interval - after that there will be nothing to synchronize. What we see and hear in the field, though, that a controller may stay days out of service and then come back and should be capable to synchronize the control state of all LSPs it used to manage before the crash/reboot. And, of course, you MUST maintain data service up and running. Igor ----- Original Message ----- From: "dimitri papadimitriou" To: "Igor Bryskin" Cc: ; "Drake, John E" ; "Zafar Ali (zali)" ; "Igor Bryskin" ; ; "Kim Young Hwa" ; Sent: Monday, October 31, 2005 11:52 AM Subject: Re: Two Drafts for Resilience of Control Plane > igor - > > Igor Bryskin wrote: > > Dimitri, > > > >>igor - my two cents > >> > >>RSVP over time has progressively borrowed mechanisms from "hard-state" > >>protocols, explicit deletion using PathTear is most noticeable and > >>initial example of this evolution ! > >> > >>but in any case, RSVP still relies is on idem-potent soft-states that > >>are flushed when not refreshed after certain time interval (or self- > >>maintained if previously negotiated) this prevents orphans in the > >>network (so unused resources) and provides for resilience - hence there > >>is by no means a need to introduce an additional protocol mechanism to > >>trigger or not such event via the "control plane" - > > > > > > Refreshes are useful mechanism but only between neighbors that maintain > > Hello communication. In this case the absence of Path refreshes is as good > > indication that data plane must be destroyed as received PathTear message. > > the base function of state refresh and usefulness is independent of > hello adjacency maintenance (or any other control channel maintenance) > > > However, when a controller does not receive Path refreshes from a neighbor > > it does not have any control plane communication with, it can assume neither > > a problem in the data plane nor intention to destroy it. > > as the node did not negotiate any channel/node fault recovery (due in > part. to the absence of Hello adjacency with its neighbor) and if no > other independent control channel failure is provided (this is an add-on > of RFC3471/3), the simple absence of refresh is simply intepreted as > "implicit deletion" > > you are mis-interpreting the following sentence of RFC3471 > > " Note that these cases only apply when there are mechanisms to detect > data channel failures independent of control channel failures." > > there is no retro-fit on the use of Refreshes in absence of control > channel failure detection mechanism > > > Hence, as it was > > specified in RFC3471, it *must* maintain both control and data plane states > > throughout the failure. > > - d. > > Igor > > > > > >>btw, the paragraph you mention in RFC3471 does not say "soft state > >>protocols do not work well for non-packet environments" this is your > >>interpretation; > >> > >>ps: you are still free to make use of RFC3472 in case (as you were > >>apparently looking for something else ;-) > >> > >>Igor Bryskin wrote: > >> > >>>John, > >>> > >>> > >>> > >>> > >>>>>States are supposed to be destroyed on explicit signalling > >>>>>message (e.g. PathTear or PathErr with the state removal > >>>>>flag), but not because of the absence of refreshes. > >>>>> > >>> > >>>[JD] > >>> > >>>Igor, > >>> > >>>Just to be clear, we are talking about RSVP here, and RSVP *is* a soft > >>>state protocol. Can you point to any RFC that supports your statements > >>>above? > >>> > >>>IB>> Oh, come on, John. You sound like you've been yourself in a dormant > >>>state for a while :=). We've gone a long way since RFC2205. In RFC3471, > > > > for > > > >>>example, there is a discussion why GMPLS is needed and how is it > > > > different > > > >>>from MPLS. One of the differences is the fact that soft state protocols > > > > do > > > >>>not work well for non-packet environments. Here is from the RDC3471: > >>> > >>> > >>> > >>>9.2. Fault Handling There are two new faults that must be handled > > > > when > > > >>>the control channel is independent of the data channel. In the first, > >>>there is a link or other type of failure that limits the ability of > >>>neighboring nodes to pass control messages. In this situation, > >>>neighboring nodes are unable to exchange control messages for a period > > > > of > > > >>>time. Once communication is restored the underlying signaling > > > > protocol > > > >>>must indicate that the nodes have maintained their state through the > >>>failure.. > >>> > >>>What is more important is the reality of life: The customers simply say > > > > that > > > >>>you cannot destroy a user service (or even force any traffic hits) just > >>>because you have a problem in the control plane. If this does not fit > > > > your > > > >>>soft-state paradigm, than "harden" your protocols or flash them down the > >>>toilet and come with something else if you want our business. After all, > > > > if > > > >>>we provision the services via NMS, we do not have to destroy the > > > > services if > > > >>>we have problems in the management network. It is that simple. > >>> > >>> > >>> > >>>Igor > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>>. > >>> > > > > > > > > > > . > > Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 31 Oct 2005 17:12:50 +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: comments on draft-shiba-ccamp-gmpls-lambda-labels-00.txt Date: Mon, 31 Oct 2005 09:12:14 -0800 Message-ID: <626FC7C6A97381468FB872072AB5DDC836971F@XCH-SW-42.sw.nos.boeing.com> Thread-Topic: comments on draft-shiba-ccamp-gmpls-lambda-labels-00.txt Thread-Index: AcXbIzcAFoI5B5TzS9O/zBGY1cMJbwA6iz0AAIdyNZAAAR14UAAAnn6wAABj8oAAAozZ0A== From: "Drake, John E" To: "Shiba, Sidney" , Cc: "Adrian Farrel" , , Sidney 'm not sure you are addressing my concern, unless you are telling me that an LSP can be instantiated along a path that contains WDM systems from *different* vendors. I had been told that, in general, this was not the case. Thanks, John > -----Original Message----- > From: Shiba, Sidney [mailto:sidney.shiba@us.fujitsu.com] > Sent: Monday, October 31, 2005 8:00 AM > To: Drake, John E; dpapadimitriou@psg.com > Cc: Adrian Farrel; richard.rabbat@us.fujitsu.com; ccamp@ops.ietf.org > Subject: RE: comments on draft-shiba-ccamp-gmpls-lambda-labels-00.txt >=20 > John, >=20 > Most of vendor support a standardized wavelength grid > (e.g., ITU-T DWDM wavelength grid given in nominal value). >=20 > If a wavelength chosen for a lightpath setup is not available > in an optical switch, it rejects the operation for resource > not being available. >=20 > Regards, >=20 > Sidney >=20 > > -----Original Message----- > > From: Drake, John E [mailto:John.E.Drake2@boeing.com] > > Sent: Monday, October 31, 2005 9:51 AM > > To: Drake, John E; Shiba, Sidney; dpapadimitriou@psg.com > > Cc: Adrian Farrel; richard.rabbat@us.fujitsu.com; ccamp@ops.ietf.org > > Subject: RE: comments on draft-shiba-ccamp-gmpls-lambda-labels-00.txt > > > > > > Sidney, > > > > There's another issue as well. Having absolute end-end global > > wavelengths is probably insufficient to ensure that an end-end LSP can > > be established successfully, as having a common wavelength > > does not mean > > that equipment from different vendors will interoperate > > correctly in the > > data-plane. > > > > Thanks, > > > > John > > > > > -----Original Message----- > > > From: Drake, John E > > > Sent: Monday, October 31, 2005 7:36 AM > > > To: Shiba, Sidney; dpapadimitriou@psg.com > > > Cc: Adrian Farrel; richard.rabbat@us.fujitsu.com; ccamp@ops.ietf.org > > > Subject: RE: comments on > > draft-shiba-ccamp-gmpls-lambda-labels-00.txt > > > > > > Sidney, > > > > > > But there's nothing in your picture that requires an > > absolute end-end > > > global wavelength. The existing GMPLS solution with relative > > > wavelengths of local significance should work just fine. > > As I said in > > > my previous note, your method precludes combining two or > > more parallel > > > WDM links into a single TE link. > > > > > > Thanks, > > > > > > John > > > > > > > -----Original Message----- > > > > From: Shiba, Sidney [mailto:sidney.shiba@us.fujitsu.com] > > > > Sent: Monday, October 31, 2005 7:25 AM > > > > To: Drake, John E; dpapadimitriou@psg.com > > > > Cc: Adrian Farrel; richard.rabbat@us.fujitsu.com; > > ccamp@ops.ietf.org > > > > Subject: RE: comments on > > draft-shiba-ccamp-gmpls-lambda-labels-00.txt > > > > > > > > Hi John, > > > > > > > > Optical switches based on Wavelength Selective Switch (WSS) > > technology > > > > requires the wavelength information for switching. This technology > > is > > > NOT > > > > wavelength agnostic. > > > > > > > > | | > > > > | wdm | wdm > > > > |2 |2 > > > > --------- --------- > > > > wdm 1| optical |3 wdm 1| optical |3 wdm > > > > --------| switch |------------| switch |--------- > > > > | (WSS) | | (WSS) | > > > > --------- --------- > > > > |4 |4 > > > > | wdm | wdm > > > > | | > > > > > > > > Note that the figure above shows an example of two > > optical switches > > > > interconnect > > > > by a single WDM fiber. In this example, each optical switch can be > > > connect > > > > to 4 > > > > other optical switches. > > > > > > > > As you can see, the optical ports information do not > > provide enough > > > > information > > > > for wavelength switching. > > > > > > > > Hope that clarifies the application requirement. > > > > > > > > Thanks, > > > > > > > > Sidney > > > > > > > > > -----Original Message----- > > > > > From: Drake, John E [mailto:John.E.Drake2@boeing.com] > > > > > Sent: Friday, October 28, 2005 5:33 PM > > > > > To: dpapadimitriou@psg.com; Shiba, Sidney > > > > > Cc: Adrian Farrel; richard.rabbat@us.fujitsu.com; > > ccamp@ops.ietf.org > > > > > Subject: RE: comments on > > > draft-shiba-ccamp-gmpls-lambda-labels-00.txt > > > > > > > > > > > > > > > Hi, > > > > > > > > > > Below is the text of an e-mail is sent to the Ethernet/GMPLS > > mailing > > > > > list. > > > > > > > > > > Upon reflection I am not sure using a real wavelength > > value makes > > > much > > > > > sense. Between a pair of adjacent nodes, there may be > > > > > multiple pairs of > > > > > switch ports in the same TE link that support a given frequency. > > If > > > a > > > > > real wavelength value is used, how do the two nodes agree on > > > > > which pair > > > > > of switch ports to use? > > > > > > > > > > Furthermore, the amount of configuration is the same - you > > > > > still need to > > > > > configure the wavelength of each switch port. > > > > > > > > > > Thanks, > > > > > > > > > > John > > > > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > > =3D=3D=3D=3D > > > > > Adrian, > > > > > > > > > > In the transparent photonic lambda switch case, the labels also > > have > > > > > only local significance. When an LSP is established, the input > > > ports, > > > > > as identified with local labels, are cross-connected to > > the output > > > > > ports, as identified with local labels. > > > > > > > > > > There is just extra configuration to identify, using strictly > > local > > > > > identifiers, the wavelength associated with the all of the > > switch's > > > > > ports, and an additional CAC requirement that the wavelengths of > > the > > > > > input and output ports are the same. > > > > > > > > > > Thanks, > > > > > > > > > > John > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: dimitri papadimitriou [mailto:dpapadimitriou@psg.com] > > > > > > Sent: Thursday, October 27, 2005 10:03 AM > > > > > > To: Shiba, Sidney > > > > > > Cc: dimitri.papadimitriou@alcatel.be; Adrian Farrel; > > > > > > richard.rabbat@us.fujitsu.com; ccamp@ops.ietf.org > > > > > > Subject: Re: comments on > > > > > draft-shiba-ccamp-gmpls-lambda-labels-00.txt > > > > > > > > > > > > shiba - see inline for some additional hints: > > > > > > > > > > > > >>Shiba, Sidney wrote: > > > > > > >> > > > > > > >>>Adrian, Dimitri, > > > > > > >>> > > > > > > >>>Thanks for reviewing these I-D. > > > > > > >>> > > > > > > >>>Wavelength continuity constraint does require the use of > > > > > semanticful > > > > > > >>>label whether it is spectral or index. > > > > > > >> > > > > > > >>=3D> see my reply to adrian on this specific point > > > > > > >> > > > > > > >>>I agree with Dimitri that the > > > > > > >>>wavelength indexing requires document updating each time a > > new > > > > > > >>>spectrum is introduced. > > > > > > >> > > > > > > >>=3D> indeed and in addition it requires updating the = already > > > > > > >>signaled path > > > > > > >> > > > > > > >>>The use of spectral label provides self maintainance, i.e., > > > > > > >>>no need to update any document and the use of the nominal > > value > > > > > > >>>provides a common semantic ground. > > > > > > >> > > > > > > >>=3D> what do you mean by self-maintenance - would you > > provide a > > > > > > >>bit more detail > > > > > > > > > > > > > > [Sidney]What I've meant here was that it was not > > necessary to > > > > > > > update any document when new wavelengths are inventoried. In > > the > > > > > > > case of indexing approach, it would require the > > > > > wavelength indexing > > > > > > > document to be updated with implementation impacts. > > > > > > > > > > > > > > In the case, the nominal value is used, there is no need for > > > > > > > documentation update. > > > > > > > > > > > > ok - what you mean here is that you are going to make > > use of the > > > > > already > > > > > > defined C-Type 2 - what about the specific encoding of the > > > > > value space > > > > > ? > > > > > > > > > > > > >>=3D> now i have a more specific question before being light-up > > > > > > >>how do you know the frequency that you can support ? > > > > > > > > > > > > > > [Sidney] Some new technologies integrate optical switch and > > > > > mux/demux > > > > > > > capabilities, which allows the equipment to know > > the spectrum > > it > > > > > > supports. > > > > > > > > > > > > indeed - but the question is what does happen if the > > > > > "detected" values > > > > > > (during initialization) do not match the nominal values ? you > > > don't > > > > > > initialize then ? > > > > > > > > > > > > >>if these differ from the nominal values how are you going to > > > deal > > > > > with > > > > > > these > > > > > > >>discrepancies ? > > > > > > > > > > > > > > [Sidney] These new technologies uses the nominal value as > > > > > reference. > > > > > We > > > > > > can say > > > > > > > that a lightpath wavelength is identified by its nominal > > value. > > > If > > > > > the > > > > > > equipment > > > > > > > is drifting from this nominal value, it is considered as > > > > > a failure. > > > > > > > > > > > > ok - but if the deviation is such you have overlap - how the > > > control > > > > > > plane is going to be able to detect such failure ? > > > > > > > > > > > > >>this said i am not necessarily sure that having to > > > > > maintain the data > > > > > > plane > > > > > > >>specifics as part of the control plane is really helping > > > > > > >>operations (is this method not just duplicating > > complexity ?) > > > > > > > > > > > > > > [Sidney] The wavelength is WDM specific as much as the SUKLM > > > label > > > > > > encoding > > > > > > > is for SONET. The wavelegth/frequency nominal value > > is used to > > > > > identify > > > > > > the > > > > > > > facilities to cross-connect. > > > > > > > > > > > > there is an equivalence but there is also a major difference, > > the > > > > > > structure is invariant independently of the state of the > > > > > network, with > > > > > > spectral value space you may have labels that become > > unavailable > > > due > > > > > to > > > > > > non-local usage of wavelength in the network > > > > > > > > > > > > hence, there is also no real coupling to the data plane more > > than > > > > > > knowing the type of interface and some generic capabilities > > > > > > > > > > > > >>>I'm not sure if the draft needs to be updated before the > > > > > > >>>face-to-face meeting or after all comments are collected. > > > Please > > > > > > advise. > > > > > > >> > > > > > > >>=3D> suggest to keep discussion on - document update can = be > > > > > > >>performed at a later stage > > > > > > > > > > > > thanks, > > > > > > - dimitri. > > > > > > > > > > > > >>>>-----Original Message----- > > > > > > >>>>From: owner-ccamp@ops.ietf.org > > > > > [mailto:owner-ccamp@ops.ietf.org]On > > > > > > >>>>Behalf Of Adrian Farrel > > > > > > >>>>Sent: Thursday, October 27, 2005 4:45 AM > > > > > > >>>>To: dpapadimitriou@psg.com; > > dimitri.papadimitriou@alcatel.be; > > > > > > >>>>ccamp@ops.ietf.org > > > > > > >>>>Subject: Re: comments on > > > > > > >> > > > > > > >>draft-shiba-ccamp-gmpls-lambda-labels-00.txt > > > > > > >> > > > > > > >>>> > > > > > > >>>>Dimitri, > > > > > > >>>> > > > > > > >>>>Thanks for your work reviewing these recent I-Ds. It is > > > > > > >>>>really valuable > > > > > > >>>>and I'd welcome other people doing similar reviews. > > > > > > >>>> > > > > > > >>>> > > > > > > >>>> > > > > > > >>>>>there is a specific point to be clarified in > > this document: > > > > > > >>>>> > > > > > > >>>>>semanticless vs semanticful label (even here there is a > > > > > distinction > > > > > > >>>>>between spectral vs indexes i.e. using the wavelength > > index) > > > > > > >>>>> > > > > > > >>>>>domain-wide vs link local significant label > > > > > > >>>> > > > > > > >>>>Without being too picky, I think all labels are > > semanticful > > > > > > >>>>otherwise, we > > > > > > >>>>would not know what resource they refered to. > > > > > > >>>> > > > > > > >>>>So the point reduces to whether the scope of the semantics > > > > > > >>>>are link-local > > > > > > >>>>or wider. > > > > > > >>>> > > > > > > >>>> > > > > > > >>>> > > > > > > >>>>>so, the comparison from this perspective with > > TDM labels is > > > > > > >>>> > > > > > > >>>>difficult to > > > > > > >>>> > > > > > > >>>> > > > > > > >>>>>parse, the latter is semanticful but link local > > > > > > >>>>> > > > > > > >>>>>now, i don't specifically see what has changed the late > > 90's, > > > > > early > > > > > > >>>>>y2k's, to have a change in the wavelength label > > definition; > > > > > > >>>> > > > > > > >>>>This is the question I would like to get to the bottom of. > > In > > > > > > >>>>other words: > > > > > > >>>>do we need this function? > > > > > > >>>> > > > > > > >>>>It seems to me that the question being asked is this: > > > > > > >>>> > > > > > > >>>> If I want to compute a path that has some form of > > wavelength > > > > > > >>>> constraints, what information do I need access to? > > > > > > >>>> > > > > > > >>>>Another question might be: > > > > > > >>>> > > > > > > >>>> If I want to signal a path with wavelength constraints > > what > > > > > > >>>> information do I need to include in the > > signaling message? > > > > > > >>>> > > > > > > >>>> > > > > > > >>>>I'd suggest that when we started on GMPLS, we were > > > > > > >> > > > > > > >>enthusiastic about > > > > > > >> > > > > > > >>>>transparent optical networks, but we were not properly > > > > > > >>>>focusing wavelength > > > > > > >>>>constraints because lambda-switching PXCs didn't take off. > > > > > > >>>>Therefore we > > > > > > >>>>didn't examine the requirements for wavelength constraints > > in > > > > > > >>>>routing and > > > > > > >>>>signaling. The authors of this I-D are claiming > > new hardware > > > > > > >>>>requirements > > > > > > >>>>for the same function. > > > > > > >>>> > > > > > > >>>> > > > > > > >>>> > > > > > > >>>>>there are > > > > > > >>>>>several solution possible > > > > > > >>>>> > > > > > > >>>>>- absolute values: the freq. of the wavelength: difficult > > to > > > > > adopt > > > > > > >>>>>because referenced values are nominal and knowing all > > > > > interactions > > > > > > >>>>>between wavelengths this knowledge is at the end > > of little > > > > > > >> > > > > > > >>practical > > > > > > >> > > > > > > >>>>>usage; (introduces implicit ordering) > > > > > > >>>>> > > > > > > >>>>>- indexed values: the # of the wavelength: it does not > > > > > > >> > > > > > > >>provide for a > > > > > > >> > > > > > > >>>>>future proof label space for inst. in case new > > frequencies > > > > > > >>>> > > > > > > >>>>are inserted > > > > > > >>>> > > > > > > >>>> > > > > > > >>>>>in the grid (introduces explicit ordering) > > > > > > >>>>> > > > > > > >>>>>- diff. values e.g. freq spacing starting from a > > reference > > > > > > >>>> > > > > > > >>>>value: pauses > > > > > > >>>> > > > > > > >>>> > > > > > > >>>>>the question of the reference value and does suffer from > > the > > > > > former > > > > > > >>>>>issue (introduces implicit ordering) > > > > > > >>>>> > > > > > > >>>>>- the solution available today - cumbersome in some > > > > > control plane > > > > > > >>>>>operations (e.g. label set translation) and not easy to > > > > > > >>>> > > > > > > >>>>troubleshoot but > > > > > > >>>> > > > > > > >>>> > > > > > > >>>>>independent of any physical consideration > > (spectral), scale > > > to > > > > > any > > > > > > >>>>>number of wavelength per fiber, does not introduce any > > > > > > >> > > > > > > >>ordering, the > > > > > > >> > > > > > > >>>>>most flexible (since allowing each system to maintain its > > > > > specific > > > > > > >>>>>control operations) and the less constraining since > > > maintaining > > > > > the > > > > > > >>>>>control plane operations independent of any data plane > > > > > specifics > > > > > > >>>>> > > > > > > >>>>> > > > > > > >>>> > > > > > > > > >>>> > > > > > >>> > > > > > > >>>ambda-labels > > > > > > >>>-00.txt> > > > > > > >>> > > > > > > >>>. > > > > > > >>> > > > > > > >> > > > > > > > > > > > > > > . > > > > > > > > > > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 31 Oct 2005 16:58:27 +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: comments on draft-shiba-ccamp-gmpls-lambda-labels-00.txt Date: Mon, 31 Oct 2005 08:58:10 -0800 Message-ID: <626FC7C6A97381468FB872072AB5DDC836971E@XCH-SW-42.sw.nos.boeing.com> Thread-Topic: comments on draft-shiba-ccamp-gmpls-lambda-labels-00.txt Thread-Index: AcXeNcpyWStaVYm1SxaXOoXTA/t1xQABG17A From: "Drake, John E" To: "Payam Torab" , "Shiba, Sidney" , Cc: "Adrian Farrel" , , > -----Original Message----- > From: Payam Torab [mailto:ptorab@lopsys.com] > Sent: Monday, October 31, 2005 8:12 AM > To: Drake, John E; 'Shiba, Sidney'; dpapadimitriou@psg.com > Cc: 'Adrian Farrel'; richard.rabbat@us.fujitsu.com; ccamp@ops.ietf.org > Subject: RE: comments on draft-shiba-ccamp-gmpls-lambda-labels-00.txt >=20 > John- >=20 > Obviously the benefits or harms of giving a global meaning to a lambda > label requires study, but your particular example is not a good one: If > one really wants to have a preference for a specific wavelength channel > among multiple parallel channels of the same wavelength, bundling should > not be exercised in the first place. [JD]=20 It isn't bundling. LMP allows one to configure two or more parallel WDM systems into a single TE link. One reason for doing this is to improve the scalability of the TE LSB. Another is to reduce crankback (see below). If this done, you would have multiple instances of each of the wavelengths supported by the WDM systems. You asserted that this is a BadIdea(tm), but it reduces crankback in the network. If you make each parallel WDM system a separate TE link, then you have bound the LSP to the selected TE link. If the selected wavelength is blocked, you have to crankback. If you combine the parallel WDM systems into a single TE link, then the LSP can be progressed on *any* WDM system on which the selected wavelength is available.=20 >=20 > Thanks, > Payam >=20 > -----Original Message----- > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On > Behalf Of Drake, John E > Sent: Monday, October 31, 2005 10:36 AM > To: Shiba, Sidney; dpapadimitriou@psg.com > Cc: Adrian Farrel; richard.rabbat@us.fujitsu.com; ccamp@ops.ietf.org > Subject: RE: comments on draft-shiba-ccamp-gmpls-lambda-labels-00.txt >=20 >=20 > Sidney, >=20 > But there's nothing in your picture that requires an absolute end-end > global wavelength. The existing GMPLS solution with relative > wavelengths of local significance should work just fine. As I said in > my previous note, your method precludes combining two or more parallel > WDM links into a single TE link. >=20 > Thanks, >=20 > John >=20 > > -----Original Message----- > > From: Shiba, Sidney [mailto:sidney.shiba@us.fujitsu.com] > > Sent: Monday, October 31, 2005 7:25 AM > > To: Drake, John E; dpapadimitriou@psg.com > > Cc: Adrian Farrel; richard.rabbat@us.fujitsu.com; ccamp@ops.ietf.org > > Subject: RE: comments on draft-shiba-ccamp-gmpls-lambda-labels-00.txt > > > > Hi John, > > > > Optical switches based on Wavelength Selective Switch (WSS) technology > > requires the wavelength information for switching. This technology is > NOT > > wavelength agnostic. > > > > | | > > | wdm | wdm > > |2 |2 > > --------- --------- > > wdm 1| optical |3 wdm 1| optical |3 wdm > > --------| switch |------------| switch |--------- > > | (WSS) | | (WSS) | > > --------- --------- > > |4 |4 > > | wdm | wdm > > | | > > > > Note that the figure above shows an example of two optical switches > > interconnect > > by a single WDM fiber. In this example, each optical switch can be > connect > > to 4 > > other optical switches. > > > > As you can see, the optical ports information do not provide enough > > information > > for wavelength switching. > > > > Hope that clarifies the application requirement. > > > > Thanks, > > > > Sidney > > > > > -----Original Message----- > > > From: Drake, John E [mailto:John.E.Drake2@boeing.com] > > > Sent: Friday, October 28, 2005 5:33 PM > > > To: dpapadimitriou@psg.com; Shiba, Sidney > > > Cc: Adrian Farrel; richard.rabbat@us.fujitsu.com; ccamp@ops.ietf.org > > > Subject: RE: comments on > draft-shiba-ccamp-gmpls-lambda-labels-00.txt > > > > > > > > > Hi, > > > > > > Below is the text of an e-mail is sent to the Ethernet/GMPLS mailing > > > list. > > > > > > Upon reflection I am not sure using a real wavelength value makes > much > > > sense. Between a pair of adjacent nodes, there may be > > > multiple pairs of > > > switch ports in the same TE link that support a given frequency. If > a > > > real wavelength value is used, how do the two nodes agree on > > > which pair > > > of switch ports to use? > > > > > > Furthermore, the amount of configuration is the same - you > > > still need to > > > configure the wavelength of each switch port. > > > > > > Thanks, > > > > > > John > > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > =3D=3D=3D=3D > > > Adrian, > > > > > > In the transparent photonic lambda switch case, the labels also have > > > only local significance. When an LSP is established, the input > ports, > > > as identified with local labels, are cross-connected to the output > > > ports, as identified with local labels. > > > > > > There is just extra configuration to identify, using strictly local > > > identifiers, the wavelength associated with the all of the switch's > > > ports, and an additional CAC requirement that the wavelengths of the > > > input and output ports are the same. > > > > > > Thanks, > > > > > > John > > > > > > > > > > -----Original Message----- > > > > From: dimitri papadimitriou [mailto:dpapadimitriou@psg.com] > > > > Sent: Thursday, October 27, 2005 10:03 AM > > > > To: Shiba, Sidney > > > > Cc: dimitri.papadimitriou@alcatel.be; Adrian Farrel; > > > > richard.rabbat@us.fujitsu.com; ccamp@ops.ietf.org > > > > Subject: Re: comments on > > > draft-shiba-ccamp-gmpls-lambda-labels-00.txt > > > > > > > > shiba - see inline for some additional hints: > > > > > > > > >>Shiba, Sidney wrote: > > > > >> > > > > >>>Adrian, Dimitri, > > > > >>> > > > > >>>Thanks for reviewing these I-D. > > > > >>> > > > > >>>Wavelength continuity constraint does require the use of > > > semanticful > > > > >>>label whether it is spectral or index. > > > > >> > > > > >>=3D> see my reply to adrian on this specific point > > > > >> > > > > >>>I agree with Dimitri that the > > > > >>>wavelength indexing requires document updating each time a new > > > > >>>spectrum is introduced. > > > > >> > > > > >>=3D> indeed and in addition it requires updating the already > > > > >>signaled path > > > > >> > > > > >>>The use of spectral label provides self maintainance, i.e., > > > > >>>no need to update any document and the use of the nominal value > > > > >>>provides a common semantic ground. > > > > >> > > > > >>=3D> what do you mean by self-maintenance - would you provide = a > > > > >>bit more detail > > > > > > > > > > [Sidney]What I've meant here was that it was not necessary to > > > > > update any document when new wavelengths are inventoried. In the > > > > > case of indexing approach, it would require the > > > wavelength indexing > > > > > document to be updated with implementation impacts. > > > > > > > > > > In the case, the nominal value is used, there is no need for > > > > > documentation update. > > > > > > > > ok - what you mean here is that you are going to make use of the > > > already > > > > defined C-Type 2 - what about the specific encoding of the > > > value space > > > ? > > > > > > > > >>=3D> now i have a more specific question before being light-up > > > > >>how do you know the frequency that you can support ? > > > > > > > > > > [Sidney] Some new technologies integrate optical switch and > > > mux/demux > > > > > capabilities, which allows the equipment to know the spectrum it > > > > supports. > > > > > > > > indeed - but the question is what does happen if the > > > "detected" values > > > > (during initialization) do not match the nominal values ? you > don't > > > > initialize then ? > > > > > > > > >>if these differ from the nominal values how are you going to > deal > > > with > > > > these > > > > >>discrepancies ? > > > > > > > > > > [Sidney] These new technologies uses the nominal value as > > > reference. > > > We > > > > can say > > > > > that a lightpath wavelength is identified by its nominal value. > If > > > the > > > > equipment > > > > > is drifting from this nominal value, it is considered as > > > a failure. > > > > > > > > ok - but if the deviation is such you have overlap - how the > control > > > > plane is going to be able to detect such failure ? > > > > > > > > >>this said i am not necessarily sure that having to > > > maintain the data > > > > plane > > > > >>specifics as part of the control plane is really helping > > > > >>operations (is this method not just duplicating complexity ?) > > > > > > > > > > [Sidney] The wavelength is WDM specific as much as the SUKLM > label > > > > encoding > > > > > is for SONET. The wavelegth/frequency nominal value is used to > > > identify > > > > the > > > > > facilities to cross-connect. > > > > > > > > there is an equivalence but there is also a major difference, the > > > > structure is invariant independently of the state of the > > > network, with > > > > spectral value space you may have labels that become unavailable > due > > > to > > > > non-local usage of wavelength in the network > > > > > > > > hence, there is also no real coupling to the data plane more than > > > > knowing the type of interface and some generic capabilities > > > > > > > > >>>I'm not sure if the draft needs to be updated before the > > > > >>>face-to-face meeting or after all comments are collected. > Please > > > > advise. > > > > >> > > > > >>=3D> suggest to keep discussion on - document update can be > > > > >>performed at a later stage > > > > > > > > thanks, > > > > - dimitri. > > > > > > > > >>>>-----Original Message----- > > > > >>>>From: owner-ccamp@ops.ietf.org > > > [mailto:owner-ccamp@ops.ietf.org]On > > > > >>>>Behalf Of Adrian Farrel > > > > >>>>Sent: Thursday, October 27, 2005 4:45 AM > > > > >>>>To: dpapadimitriou@psg.com; dimitri.papadimitriou@alcatel.be; > > > > >>>>ccamp@ops.ietf.org > > > > >>>>Subject: Re: comments on > > > > >> > > > > >>draft-shiba-ccamp-gmpls-lambda-labels-00.txt > > > > >> > > > > >>>> > > > > >>>>Dimitri, > > > > >>>> > > > > >>>>Thanks for your work reviewing these recent I-Ds. It is > > > > >>>>really valuable > > > > >>>>and I'd welcome other people doing similar reviews. > > > > >>>> > > > > >>>> > > > > >>>> > > > > >>>>>there is a specific point to be clarified in this document: > > > > >>>>> > > > > >>>>>semanticless vs semanticful label (even here there is a > > > distinction > > > > >>>>>between spectral vs indexes i.e. using the wavelength index) > > > > >>>>> > > > > >>>>>domain-wide vs link local significant label > > > > >>>> > > > > >>>>Without being too picky, I think all labels are semanticful > > > > >>>>otherwise, we > > > > >>>>would not know what resource they refered to. > > > > >>>> > > > > >>>>So the point reduces to whether the scope of the semantics > > > > >>>>are link-local > > > > >>>>or wider. > > > > >>>> > > > > >>>> > > > > >>>> > > > > >>>>>so, the comparison from this perspective with TDM labels is > > > > >>>> > > > > >>>>difficult to > > > > >>>> > > > > >>>> > > > > >>>>>parse, the latter is semanticful but link local > > > > >>>>> > > > > >>>>>now, i don't specifically see what has changed the late 90's, > > > early > > > > >>>>>y2k's, to have a change in the wavelength label definition; > > > > >>>> > > > > >>>>This is the question I would like to get to the bottom of. In > > > > >>>>other words: > > > > >>>>do we need this function? > > > > >>>> > > > > >>>>It seems to me that the question being asked is this: > > > > >>>> > > > > >>>> If I want to compute a path that has some form of wavelength > > > > >>>> constraints, what information do I need access to? > > > > >>>> > > > > >>>>Another question might be: > > > > >>>> > > > > >>>> If I want to signal a path with wavelength constraints what > > > > >>>> information do I need to include in the signaling message? > > > > >>>> > > > > >>>> > > > > >>>>I'd suggest that when we started on GMPLS, we were > > > > >> > > > > >>enthusiastic about > > > > >> > > > > >>>>transparent optical networks, but we were not properly > > > > >>>>focusing wavelength > > > > >>>>constraints because lambda-switching PXCs didn't take off. > > > > >>>>Therefore we > > > > >>>>didn't examine the requirements for wavelength constraints in > > > > >>>>routing and > > > > >>>>signaling. The authors of this I-D are claiming new hardware > > > > >>>>requirements > > > > >>>>for the same function. > > > > >>>> > > > > >>>> > > > > >>>> > > > > >>>>>there are > > > > >>>>>several solution possible > > > > >>>>> > > > > >>>>>- absolute values: the freq. of the wavelength: difficult to > > > adopt > > > > >>>>>because referenced values are nominal and knowing all > > > interactions > > > > >>>>>between wavelengths this knowledge is at the end of little > > > > >> > > > > >>practical > > > > >> > > > > >>>>>usage; (introduces implicit ordering) > > > > >>>>> > > > > >>>>>- indexed values: the # of the wavelength: it does not > > > > >> > > > > >>provide for a > > > > >> > > > > >>>>>future proof label space for inst. in case new frequencies > > > > >>>> > > > > >>>>are inserted > > > > >>>> > > > > >>>> > > > > >>>>>in the grid (introduces explicit ordering) > > > > >>>>> > > > > >>>>>- diff. values e.g. freq spacing starting from a reference > > > > >>>> > > > > >>>>value: pauses > > > > >>>> > > > > >>>> > > > > >>>>>the question of the reference value and does suffer from the > > > former > > > > >>>>>issue (introduces implicit ordering) > > > > >>>>> > > > > >>>>>- the solution available today - cumbersome in some > > > control plane > > > > >>>>>operations (e.g. label set translation) and not easy to > > > > >>>> > > > > >>>>troubleshoot but > > > > >>>> > > > > >>>> > > > > >>>>>independent of any physical consideration (spectral), scale > to > > > any > > > > >>>>>number of wavelength per fiber, does not introduce any > > > > >> > > > > >>ordering, the > > > > >> > > > > >>>>>most flexible (since allowing each system to maintain its > > > specific > > > > >>>>>control operations) and the less constraining since > maintaining > > > the > > > > >>>>>control plane operations independent of any data plane > > > specifics > > > > >>>>> > > > > >>>>> > > > > >>>> > > > > >>>> > > > >>> > > > > >>>ambda-labels > > > > >>>-00.txt> > > > > >>> > > > > >>>. > > > > >>> > > > > >> > > > > > > > > > > . > > > > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 31 Oct 2005 16:52:40 +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: comments on draft-shiba-ccamp-gmpls-lambda-labels-00.txt Date: Mon, 31 Oct 2005 10:52:23 -0600 Message-ID: <7CA873794E52904EAA980A074B076779B17C63@rchemx01.fnc.net.local> Thread-Topic: comments on draft-shiba-ccamp-gmpls-lambda-labels-00.txt Thread-Index: AcXbIzcAFoI5B5TzS9O/zBGY1cMJbwA6iz0AAIdyNZAAAR14UAAAqdxAAAGnFZAAAGLHsA== From: "Shiba, Sidney" To: "Drake, John E" , Cc: "Adrian Farrel" , , John, Comments inline: > -----Original Message----- > From: Drake, John E [mailto:John.E.Drake2@boeing.com] > Sent: Monday, October 31, 2005 10:43 AM > To: Shiba, Sidney; dpapadimitriou@psg.com > Cc: Adrian Farrel; richard.rabbat@us.fujitsu.com; ccamp@ops.ietf.org > Subject: RE: comments on draft-shiba-ccamp-gmpls-lambda-labels-00.txt >=20 >=20 >=20 >=20 > > -----Original Message----- > > From: Shiba, Sidney [mailto:sidney.shiba@us.fujitsu.com] > > Sent: Monday, October 31, 2005 7:56 AM > > To: Drake, John E; dpapadimitriou@psg.com > > Cc: Adrian Farrel; richard.rabbat@us.fujitsu.com; ccamp@ops.ietf.org > > Subject: RE: comments on=20 > draft-shiba-ccamp-gmpls-lambda-labels-00.txt > >=20 > > John, > >=20 > > Comments inline: > >=20 > > > -----Original Message----- > > > From: Drake, John E [mailto:John.E.Drake2@boeing.com] > > > Sent: Monday, October 31, 2005 9:36 AM > > > To: Shiba, Sidney; dpapadimitriou@psg.com > > > Cc: Adrian Farrel; richard.rabbat@us.fujitsu.com;=20 > ccamp@ops.ietf.org > > > Subject: RE: comments on > draft-shiba-ccamp-gmpls-lambda-labels-00.txt > > > > > > > > > Sidney, > > > > > > But there's nothing in your picture that requires an absolute > end-end > > > global wavelength. The existing GMPLS solution with relative > > > wavelengths of local significance should work just fine. > >=20 > > [Sidney] Sorry for the missing info. The optical switch is an all > optical > > switch (i.e., no OEO is necessary). The wavelength continuity > constraint > > indicates which wavelength (nominal value) all the optical switches > > traversed by the lightpath needs to cross-connect. > [JD]=20 >=20 > I understand all that, but my comment still stands. >=20 [Sidney] May be I'm missing something but for example, can you explain=20 me how can we use Label Set with labels that only have local = significance? > >=20 > > > As I said in my previous note, your method precludes combining two > or > > > more parallel WDM links into a single TE link. > >=20 > > [Sidney] Note the Label is complemented by the interface id of the > link. > >=20 > > I think this is the same approach used for parallel SONET OCn > datalinks > > where the label identifies a time-slot and interface id=20 > identifies the > > datalink chosen for the connection. > [JD]=20 >=20 > That's probably true, but wavelength LSPs don't have that restriction > under the current GMPLS procedures. >=20 [Sidney] I understand that current wavelength LSPs don't have that = restriction. What the draft is proposing are procedures for optical switches using = WSS=20 technology. > >=20 > > > > > > Thanks, > > > > > > John > > > > > > > -----Original Message----- > > > > From: Shiba, Sidney [mailto:sidney.shiba@us.fujitsu.com] > > > > Sent: Monday, October 31, 2005 7:25 AM > > > > To: Drake, John E; dpapadimitriou@psg.com > > > > Cc: Adrian Farrel; richard.rabbat@us.fujitsu.com; > ccamp@ops.ietf.org > > > > Subject: RE: comments on > > > draft-shiba-ccamp-gmpls-lambda-labels-00.txt > > > > > > > > Hi John, > > > > > > > > Optical switches based on Wavelength Selective Switch (WSS) > > > technology > > > > requires the wavelength information for switching. This > > > technology is > > > NOT > > > > wavelength agnostic. > > > > > > > > | | > > > > | wdm | wdm > > > > |2 |2 > > > > --------- --------- > > > > wdm 1| optical |3 wdm 1| optical |3 wdm > > > > --------| switch |------------| switch |--------- > > > > | (WSS) | | (WSS) | > > > > --------- --------- > > > > |4 |4 > > > > | wdm | wdm > > > > | | > > > > > > > > Note that the figure above shows an example of two optical > switches > > > > interconnect > > > > by a single WDM fiber. In this example, each optical=20 > switch can be > > > connect > > > > to 4 > > > > other optical switches. > > > > > > > > As you can see, the optical ports information do not provide > enough > > > > information > > > > for wavelength switching. > > > > > > > > Hope that clarifies the application requirement. > > > > > > > > Thanks, > > > > > > > > Sidney > > > > > > > > > -----Original Message----- > > > > > From: Drake, John E [mailto:John.E.Drake2@boeing.com] > > > > > Sent: Friday, October 28, 2005 5:33 PM > > > > > To: dpapadimitriou@psg.com; Shiba, Sidney > > > > > Cc: Adrian Farrel; richard.rabbat@us.fujitsu.com; > > > ccamp@ops.ietf.org > > > > > Subject: RE: comments on > > > draft-shiba-ccamp-gmpls-lambda-labels-00.txt > > > > > > > > > > > > > > > Hi, > > > > > > > > > > Below is the text of an e-mail is sent to the > > > Ethernet/GMPLS mailing > > > > > list. > > > > > > > > > > Upon reflection I am not sure using a real wavelength value > makes > > > much > > > > > sense. Between a pair of adjacent nodes, there may be > > > > > multiple pairs of > > > > > switch ports in the same TE link that support a given > > > frequency. If > > > a > > > > > real wavelength value is used, how do the two nodes agree on > > > > > which pair > > > > > of switch ports to use? > > > > > > > > > > Furthermore, the amount of configuration is the same - you > > > > > still need to > > > > > configure the wavelength of each switch port. > > > > > > > > > > Thanks, > > > > > > > > > > John > > > > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > > =3D=3D=3D=3D > > > > > Adrian, > > > > > > > > > > In the transparent photonic lambda switch case, the > > > labels also have > > > > > only local significance. When an LSP is established,=20 > the input > > > ports, > > > > > as identified with local labels, are cross-connected to the > output > > > > > ports, as identified with local labels. > > > > > > > > > > There is just extra configuration to identify, using > > > strictly local > > > > > identifiers, the wavelength associated with the all of > > > the switch's > > > > > ports, and an additional CAC requirement that the > > > wavelengths of the > > > > > input and output ports are the same. > > > > > > > > > > Thanks, > > > > > > > > > > John > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: dimitri papadimitriou [mailto:dpapadimitriou@psg.com] > > > > > > Sent: Thursday, October 27, 2005 10:03 AM > > > > > > To: Shiba, Sidney > > > > > > Cc: dimitri.papadimitriou@alcatel.be; Adrian Farrel; > > > > > > richard.rabbat@us.fujitsu.com; ccamp@ops.ietf.org > > > > > > Subject: Re: comments on > > > > > draft-shiba-ccamp-gmpls-lambda-labels-00.txt > > > > > > > > > > > > shiba - see inline for some additional hints: > > > > > > > > > > > > >>Shiba, Sidney wrote: > > > > > > >> > > > > > > >>>Adrian, Dimitri, > > > > > > >>> > > > > > > >>>Thanks for reviewing these I-D. > > > > > > >>> > > > > > > >>>Wavelength continuity constraint does require the use of > > > > > semanticful > > > > > > >>>label whether it is spectral or index. > > > > > > >> > > > > > > >>=3D> see my reply to adrian on this specific point > > > > > > >> > > > > > > >>>I agree with Dimitri that the > > > > > > >>>wavelength indexing requires document updating each > > > time a new > > > > > > >>>spectrum is introduced. > > > > > > >> > > > > > > >>=3D> indeed and in addition it requires updating the = already > > > > > > >>signaled path > > > > > > >> > > > > > > >>>The use of spectral label provides self=20 > maintainance, i.e., > > > > > > >>>no need to update any document and the use of the > > > nominal value > > > > > > >>>provides a common semantic ground. > > > > > > >> > > > > > > >>=3D> what do you mean by self-maintenance - would=20 > you provide > a > > > > > > >>bit more detail > > > > > > > > > > > > > > [Sidney]What I've meant here was that it was not necessary > to > > > > > > > update any document when new wavelengths are > > > inventoried. In the > > > > > > > case of indexing approach, it would require the > > > > > wavelength indexing > > > > > > > document to be updated with implementation impacts. > > > > > > > > > > > > > > In the case, the nominal value is used, there is=20 > no need for > > > > > > > documentation update. > > > > > > > > > > > > ok - what you mean here is that you are going to make use of > the > > > > > already > > > > > > defined C-Type 2 - what about the specific encoding of the > > > > > value space > > > > > ? > > > > > > > > > > > > >>=3D> now i have a more specific question before=20 > being light-up > > > > > > >>how do you know the frequency that you can support ? > > > > > > > > > > > > > > [Sidney] Some new technologies integrate optical=20 > switch and > > > > > mux/demux > > > > > > > capabilities, which allows the equipment to know the > > > spectrum it > > > > > > supports. > > > > > > > > > > > > indeed - but the question is what does happen if the > > > > > "detected" values > > > > > > (during initialization) do not match the nominal=20 > values ? you > > > don't > > > > > > initialize then ? > > > > > > > > > > > > >>if these differ from the nominal values how are=20 > you going to > > > deal > > > > > with > > > > > > these > > > > > > >>discrepancies ? > > > > > > > > > > > > > > [Sidney] These new technologies uses the nominal value as > > > > > reference. > > > > > We > > > > > > can say > > > > > > > that a lightpath wavelength is identified by its > > > nominal value. > > > If > > > > > the > > > > > > equipment > > > > > > > is drifting from this nominal value, it is considered as > > > > > a failure. > > > > > > > > > > > > ok - but if the deviation is such you have overlap - how the > > > control > > > > > > plane is going to be able to detect such failure ? > > > > > > > > > > > > >>this said i am not necessarily sure that having to > > > > > maintain the data > > > > > > plane > > > > > > >>specifics as part of the control plane is really helping > > > > > > >>operations (is this method not just duplicating complexity > ?) > > > > > > > > > > > > > > [Sidney] The wavelength is WDM specific as much=20 > as the SUKLM > > > label > > > > > > encoding > > > > > > > is for SONET. The wavelegth/frequency nominal=20 > value is used > to > > > > > identify > > > > > > the > > > > > > > facilities to cross-connect. > > > > > > > > > > > > there is an equivalence but there is also a major > > > difference, the > > > > > > structure is invariant independently of the state of the > > > > > network, with > > > > > > spectral value space you may have labels that become > unavailable > > > due > > > > > to > > > > > > non-local usage of wavelength in the network > > > > > > > > > > > > hence, there is also no real coupling to the data plane > > > more than > > > > > > knowing the type of interface and some generic capabilities > > > > > > > > > > > > >>>I'm not sure if the draft needs to be updated before the > > > > > > >>>face-to-face meeting or after all comments are collected. > > > Please > > > > > > advise. > > > > > > >> > > > > > > >>=3D> suggest to keep discussion on - document update can = be > > > > > > >>performed at a later stage > > > > > > > > > > > > thanks, > > > > > > - dimitri. > > > > > > > > > > > > >>>>-----Original Message----- > > > > > > >>>>From: owner-ccamp@ops.ietf.org > > > > > [mailto:owner-ccamp@ops.ietf.org]On > > > > > > >>>>Behalf Of Adrian Farrel > > > > > > >>>>Sent: Thursday, October 27, 2005 4:45 AM > > > > > > >>>>To: dpapadimitriou@psg.com; > > > dimitri.papadimitriou@alcatel.be; > > > > > > >>>>ccamp@ops.ietf.org > > > > > > >>>>Subject: Re: comments on > > > > > > >> > > > > > > >>draft-shiba-ccamp-gmpls-lambda-labels-00.txt > > > > > > >> > > > > > > >>>> > > > > > > >>>>Dimitri, > > > > > > >>>> > > > > > > >>>>Thanks for your work reviewing these recent I-Ds. It is > > > > > > >>>>really valuable > > > > > > >>>>and I'd welcome other people doing similar reviews. > > > > > > >>>> > > > > > > >>>> > > > > > > >>>> > > > > > > >>>>>there is a specific point to be clarified in this > document: > > > > > > >>>>> > > > > > > >>>>>semanticless vs semanticful label (even here there is a > > > > > distinction > > > > > > >>>>>between spectral vs indexes i.e. using the > > > wavelength index) > > > > > > >>>>> > > > > > > >>>>>domain-wide vs link local significant label > > > > > > >>>> > > > > > > >>>>Without being too picky, I think all labels are > semanticful > > > > > > >>>>otherwise, we > > > > > > >>>>would not know what resource they refered to. > > > > > > >>>> > > > > > > >>>>So the point reduces to whether the scope of=20 > the semantics > > > > > > >>>>are link-local > > > > > > >>>>or wider. > > > > > > >>>> > > > > > > >>>> > > > > > > >>>> > > > > > > >>>>>so, the comparison from this perspective with=20 > TDM labels > is > > > > > > >>>> > > > > > > >>>>difficult to > > > > > > >>>> > > > > > > >>>> > > > > > > >>>>>parse, the latter is semanticful but link local > > > > > > >>>>> > > > > > > >>>>>now, i don't specifically see what has changed the > > > late 90's, > > > > > early > > > > > > >>>>>y2k's, to have a change in the wavelength label > definition; > > > > > > >>>> > > > > > > >>>>This is the question I would like to get to the > > > bottom of. In > > > > > > >>>>other words: > > > > > > >>>>do we need this function? > > > > > > >>>> > > > > > > >>>>It seems to me that the question being asked is this: > > > > > > >>>> > > > > > > >>>> If I want to compute a path that has some form of > > > wavelength > > > > > > >>>> constraints, what information do I need access to? > > > > > > >>>> > > > > > > >>>>Another question might be: > > > > > > >>>> > > > > > > >>>> If I want to signal a path with wavelength > > > constraints what > > > > > > >>>> information do I need to include in the signaling > message? > > > > > > >>>> > > > > > > >>>> > > > > > > >>>>I'd suggest that when we started on GMPLS, we were > > > > > > >> > > > > > > >>enthusiastic about > > > > > > >> > > > > > > >>>>transparent optical networks, but we were not properly > > > > > > >>>>focusing wavelength > > > > > > >>>>constraints because lambda-switching PXCs=20 > didn't take off. > > > > > > >>>>Therefore we > > > > > > >>>>didn't examine the requirements for wavelength > > > constraints in > > > > > > >>>>routing and > > > > > > >>>>signaling. The authors of this I-D are claiming new > hardware > > > > > > >>>>requirements > > > > > > >>>>for the same function. > > > > > > >>>> > > > > > > >>>> > > > > > > >>>> > > > > > > >>>>>there are > > > > > > >>>>>several solution possible > > > > > > >>>>> > > > > > > >>>>>- absolute values: the freq. of the wavelength: > > > difficult to > > > > > adopt > > > > > > >>>>>because referenced values are nominal and knowing all > > > > > interactions > > > > > > >>>>>between wavelengths this knowledge is at the end of > little > > > > > > >> > > > > > > >>practical > > > > > > >> > > > > > > >>>>>usage; (introduces implicit ordering) > > > > > > >>>>> > > > > > > >>>>>- indexed values: the # of the wavelength: it does not > > > > > > >> > > > > > > >>provide for a > > > > > > >> > > > > > > >>>>>future proof label space for inst. in case new > frequencies > > > > > > >>>> > > > > > > >>>>are inserted > > > > > > >>>> > > > > > > >>>> > > > > > > >>>>>in the grid (introduces explicit ordering) > > > > > > >>>>> > > > > > > >>>>>- diff. values e.g. freq spacing starting from a > reference > > > > > > >>>> > > > > > > >>>>value: pauses > > > > > > >>>> > > > > > > >>>> > > > > > > >>>>>the question of the reference value and does > > > suffer from the > > > > > former > > > > > > >>>>>issue (introduces implicit ordering) > > > > > > >>>>> > > > > > > >>>>>- the solution available today - cumbersome in some > > > > > control plane > > > > > > >>>>>operations (e.g. label set translation) and not easy to > > > > > > >>>> > > > > > > >>>>troubleshoot but > > > > > > >>>> > > > > > > >>>> > > > > > > >>>>>independent of any physical consideration (spectral), > scale > > > to > > > > > any > > > > > > >>>>>number of wavelength per fiber, does not introduce any > > > > > > >> > > > > > > >>ordering, the > > > > > > >> > > > > > > >>>>>most flexible (since allowing each system to=20 > maintain its > > > > > specific > > > > > > >>>>>control operations) and the less constraining since > > > maintaining > > > > > the > > > > > > >>>>>control plane operations independent of any data plane > > > > > specifics > > > > > > >>>>> > > > > > > >>>>> > > > > > > >>>> > > > > > > > > > >>>> > > > > > >>> > > > > > > >>>ambda-labels > > > > > > >>>-00.txt> > > > > > > >>> > > > > > > >>>. > > > > > > >>> > > > > > > >> > > > > > > > > > > > > > > . > > > > > > > > > > > > > > > >=20 Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 31 Oct 2005 16:52:34 +0000 Message-ID: <43664BBF.8030704@psg.com> Date: Mon, 31 Oct 2005 17:52:15 +0100 From: dimitri papadimitriou Reply-To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.11) Gecko/20050728 MIME-Version: 1.0 To: Igor Bryskin CC: dimitri.papadimitriou@alcatel.be, "Drake, John E" , "Zafar Ali (zali)" , Igor Bryskin , drake@movaz.com, Kim Young Hwa , ccamp@ops.ietf.org Subject: Re: Two Drafts for Resilience of Control Plane Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit igor - Igor Bryskin wrote: > Dimitri, > >>igor - my two cents >> >>RSVP over time has progressively borrowed mechanisms from "hard-state" >>protocols, explicit deletion using PathTear is most noticeable and >>initial example of this evolution ! >> >>but in any case, RSVP still relies is on idem-potent soft-states that >>are flushed when not refreshed after certain time interval (or self- >>maintained if previously negotiated) this prevents orphans in the >>network (so unused resources) and provides for resilience - hence there >>is by no means a need to introduce an additional protocol mechanism to >>trigger or not such event via the "control plane" - > > > Refreshes are useful mechanism but only between neighbors that maintain > Hello communication. In this case the absence of Path refreshes is as good > indication that data plane must be destroyed as received PathTear message. the base function of state refresh and usefulness is independent of hello adjacency maintenance (or any other control channel maintenance) > However, when a controller does not receive Path refreshes from a neighbor > it does not have any control plane communication with, it can assume neither > a problem in the data plane nor intention to destroy it. as the node did not negotiate any channel/node fault recovery (due in part. to the absence of Hello adjacency with its neighbor) and if no other independent control channel failure is provided (this is an add-on of RFC3471/3), the simple absence of refresh is simply intepreted as "implicit deletion" you are mis-interpreting the following sentence of RFC3471 " Note that these cases only apply when there are mechanisms to detect data channel failures independent of control channel failures." there is no retro-fit on the use of Refreshes in absence of control channel failure detection mechanism > Hence, as it was > specified in RFC3471, it *must* maintain both control and data plane states > throughout the failure. - d. > Igor > > >>btw, the paragraph you mention in RFC3471 does not say "soft state >>protocols do not work well for non-packet environments" this is your >>interpretation; >> >>ps: you are still free to make use of RFC3472 in case (as you were >>apparently looking for something else ;-) >> >>Igor Bryskin wrote: >> >>>John, >>> >>> >>> >>> >>>>>States are supposed to be destroyed on explicit signalling >>>>>message (e.g. PathTear or PathErr with the state removal >>>>>flag), but not because of the absence of refreshes. >>>>> >>> >>>[JD] >>> >>>Igor, >>> >>>Just to be clear, we are talking about RSVP here, and RSVP *is* a soft >>>state protocol. Can you point to any RFC that supports your statements >>>above? >>> >>>IB>> Oh, come on, John. You sound like you've been yourself in a dormant >>>state for a while :=). We've gone a long way since RFC2205. In RFC3471, > > for > >>>example, there is a discussion why GMPLS is needed and how is it > > different > >>>from MPLS. One of the differences is the fact that soft state protocols > > do > >>>not work well for non-packet environments. Here is from the RDC3471: >>> >>> >>> >>>9.2. Fault Handling There are two new faults that must be handled > > when > >>>the control channel is independent of the data channel. In the first, >>>there is a link or other type of failure that limits the ability of >>>neighboring nodes to pass control messages. In this situation, >>>neighboring nodes are unable to exchange control messages for a period > > of > >>>time. Once communication is restored the underlying signaling > > protocol > >>>must indicate that the nodes have maintained their state through the >>>failure.. >>> >>>What is more important is the reality of life: The customers simply say > > that > >>>you cannot destroy a user service (or even force any traffic hits) just >>>because you have a problem in the control plane. If this does not fit > > your > >>>soft-state paradigm, than "harden" your protocols or flash them down the >>>toilet and come with something else if you want our business. After all, > > if > >>>we provision the services via NMS, we do not have to destroy the > > services if > >>>we have problems in the management network. It is that simple. >>> >>> >>> >>>Igor >>> >>> >>> >>> >>> >>> >>> >>>. >>> > > > > > . > Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 31 Oct 2005 16:44:34 +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: comments on draft-shiba-ccamp-gmpls-lambda-labels-00.txt Date: Mon, 31 Oct 2005 08:43:01 -0800 Message-ID: <626FC7C6A97381468FB872072AB5DDC836971C@XCH-SW-42.sw.nos.boeing.com> Thread-Topic: comments on draft-shiba-ccamp-gmpls-lambda-labels-00.txt Thread-Index: AcXbIzcAFoI5B5TzS9O/zBGY1cMJbwA6iz0AAIdyNZAAAR14UAAAqdxAAAGnFZA= From: "Drake, John E" To: "Shiba, Sidney" , Cc: "Adrian Farrel" , , > -----Original Message----- > From: Shiba, Sidney [mailto:sidney.shiba@us.fujitsu.com] > Sent: Monday, October 31, 2005 7:56 AM > To: Drake, John E; dpapadimitriou@psg.com > Cc: Adrian Farrel; richard.rabbat@us.fujitsu.com; ccamp@ops.ietf.org > Subject: RE: comments on draft-shiba-ccamp-gmpls-lambda-labels-00.txt >=20 > John, >=20 > Comments inline: >=20 > > -----Original Message----- > > From: Drake, John E [mailto:John.E.Drake2@boeing.com] > > Sent: Monday, October 31, 2005 9:36 AM > > To: Shiba, Sidney; dpapadimitriou@psg.com > > Cc: Adrian Farrel; richard.rabbat@us.fujitsu.com; ccamp@ops.ietf.org > > Subject: RE: comments on draft-shiba-ccamp-gmpls-lambda-labels-00.txt > > > > > > Sidney, > > > > But there's nothing in your picture that requires an absolute end-end > > global wavelength. The existing GMPLS solution with relative > > wavelengths of local significance should work just fine. >=20 > [Sidney] Sorry for the missing info. The optical switch is an all optical > switch (i.e., no OEO is necessary). The wavelength continuity constraint > indicates which wavelength (nominal value) all the optical switches > traversed by the lightpath needs to cross-connect. [JD]=20 I understand all that, but my comment still stands. >=20 > > As I said in my previous note, your method precludes combining two or > > more parallel WDM links into a single TE link. >=20 > [Sidney] Note the Label is complemented by the interface id of the link. >=20 > I think this is the same approach used for parallel SONET OCn datalinks > where the label identifies a time-slot and interface id identifies the > datalink chosen for the connection. [JD]=20 That's probably true, but wavelength LSPs don't have that restriction under the current GMPLS procedures. >=20 > > > > Thanks, > > > > John > > > > > -----Original Message----- > > > From: Shiba, Sidney [mailto:sidney.shiba@us.fujitsu.com] > > > Sent: Monday, October 31, 2005 7:25 AM > > > To: Drake, John E; dpapadimitriou@psg.com > > > Cc: Adrian Farrel; richard.rabbat@us.fujitsu.com; ccamp@ops.ietf.org > > > Subject: RE: comments on > > draft-shiba-ccamp-gmpls-lambda-labels-00.txt > > > > > > Hi John, > > > > > > Optical switches based on Wavelength Selective Switch (WSS) > > technology > > > requires the wavelength information for switching. This > > technology is > > NOT > > > wavelength agnostic. > > > > > > | | > > > | wdm | wdm > > > |2 |2 > > > --------- --------- > > > wdm 1| optical |3 wdm 1| optical |3 wdm > > > --------| switch |------------| switch |--------- > > > | (WSS) | | (WSS) | > > > --------- --------- > > > |4 |4 > > > | wdm | wdm > > > | | > > > > > > Note that the figure above shows an example of two optical switches > > > interconnect > > > by a single WDM fiber. In this example, each optical switch can be > > connect > > > to 4 > > > other optical switches. > > > > > > As you can see, the optical ports information do not provide enough > > > information > > > for wavelength switching. > > > > > > Hope that clarifies the application requirement. > > > > > > Thanks, > > > > > > Sidney > > > > > > > -----Original Message----- > > > > From: Drake, John E [mailto:John.E.Drake2@boeing.com] > > > > Sent: Friday, October 28, 2005 5:33 PM > > > > To: dpapadimitriou@psg.com; Shiba, Sidney > > > > Cc: Adrian Farrel; richard.rabbat@us.fujitsu.com; > > ccamp@ops.ietf.org > > > > Subject: RE: comments on > > draft-shiba-ccamp-gmpls-lambda-labels-00.txt > > > > > > > > > > > > Hi, > > > > > > > > Below is the text of an e-mail is sent to the > > Ethernet/GMPLS mailing > > > > list. > > > > > > > > Upon reflection I am not sure using a real wavelength value makes > > much > > > > sense. Between a pair of adjacent nodes, there may be > > > > multiple pairs of > > > > switch ports in the same TE link that support a given > > frequency. If > > a > > > > real wavelength value is used, how do the two nodes agree on > > > > which pair > > > > of switch ports to use? > > > > > > > > Furthermore, the amount of configuration is the same - you > > > > still need to > > > > configure the wavelength of each switch port. > > > > > > > > Thanks, > > > > > > > > John > > > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > =3D=3D=3D=3D > > > > Adrian, > > > > > > > > In the transparent photonic lambda switch case, the > > labels also have > > > > only local significance. When an LSP is established, the input > > ports, > > > > as identified with local labels, are cross-connected to the output > > > > ports, as identified with local labels. > > > > > > > > There is just extra configuration to identify, using > > strictly local > > > > identifiers, the wavelength associated with the all of > > the switch's > > > > ports, and an additional CAC requirement that the > > wavelengths of the > > > > input and output ports are the same. > > > > > > > > Thanks, > > > > > > > > John > > > > > > > > > > > > > -----Original Message----- > > > > > From: dimitri papadimitriou [mailto:dpapadimitriou@psg.com] > > > > > Sent: Thursday, October 27, 2005 10:03 AM > > > > > To: Shiba, Sidney > > > > > Cc: dimitri.papadimitriou@alcatel.be; Adrian Farrel; > > > > > richard.rabbat@us.fujitsu.com; ccamp@ops.ietf.org > > > > > Subject: Re: comments on > > > > draft-shiba-ccamp-gmpls-lambda-labels-00.txt > > > > > > > > > > shiba - see inline for some additional hints: > > > > > > > > > > >>Shiba, Sidney wrote: > > > > > >> > > > > > >>>Adrian, Dimitri, > > > > > >>> > > > > > >>>Thanks for reviewing these I-D. > > > > > >>> > > > > > >>>Wavelength continuity constraint does require the use of > > > > semanticful > > > > > >>>label whether it is spectral or index. > > > > > >> > > > > > >>=3D> see my reply to adrian on this specific point > > > > > >> > > > > > >>>I agree with Dimitri that the > > > > > >>>wavelength indexing requires document updating each > > time a new > > > > > >>>spectrum is introduced. > > > > > >> > > > > > >>=3D> indeed and in addition it requires updating the already > > > > > >>signaled path > > > > > >> > > > > > >>>The use of spectral label provides self maintainance, i.e., > > > > > >>>no need to update any document and the use of the > > nominal value > > > > > >>>provides a common semantic ground. > > > > > >> > > > > > >>=3D> what do you mean by self-maintenance - would you = provide a > > > > > >>bit more detail > > > > > > > > > > > > [Sidney]What I've meant here was that it was not necessary to > > > > > > update any document when new wavelengths are > > inventoried. In the > > > > > > case of indexing approach, it would require the > > > > wavelength indexing > > > > > > document to be updated with implementation impacts. > > > > > > > > > > > > In the case, the nominal value is used, there is no need for > > > > > > documentation update. > > > > > > > > > > ok - what you mean here is that you are going to make use of the > > > > already > > > > > defined C-Type 2 - what about the specific encoding of the > > > > value space > > > > ? > > > > > > > > > > >>=3D> now i have a more specific question before being = light-up > > > > > >>how do you know the frequency that you can support ? > > > > > > > > > > > > [Sidney] Some new technologies integrate optical switch and > > > > mux/demux > > > > > > capabilities, which allows the equipment to know the > > spectrum it > > > > > supports. > > > > > > > > > > indeed - but the question is what does happen if the > > > > "detected" values > > > > > (during initialization) do not match the nominal values ? you > > don't > > > > > initialize then ? > > > > > > > > > > >>if these differ from the nominal values how are you going to > > deal > > > > with > > > > > these > > > > > >>discrepancies ? > > > > > > > > > > > > [Sidney] These new technologies uses the nominal value as > > > > reference. > > > > We > > > > > can say > > > > > > that a lightpath wavelength is identified by its > > nominal value. > > If > > > > the > > > > > equipment > > > > > > is drifting from this nominal value, it is considered as > > > > a failure. > > > > > > > > > > ok - but if the deviation is such you have overlap - how the > > control > > > > > plane is going to be able to detect such failure ? > > > > > > > > > > >>this said i am not necessarily sure that having to > > > > maintain the data > > > > > plane > > > > > >>specifics as part of the control plane is really helping > > > > > >>operations (is this method not just duplicating complexity ?) > > > > > > > > > > > > [Sidney] The wavelength is WDM specific as much as the SUKLM > > label > > > > > encoding > > > > > > is for SONET. The wavelegth/frequency nominal value is used to > > > > identify > > > > > the > > > > > > facilities to cross-connect. > > > > > > > > > > there is an equivalence but there is also a major > > difference, the > > > > > structure is invariant independently of the state of the > > > > network, with > > > > > spectral value space you may have labels that become unavailable > > due > > > > to > > > > > non-local usage of wavelength in the network > > > > > > > > > > hence, there is also no real coupling to the data plane > > more than > > > > > knowing the type of interface and some generic capabilities > > > > > > > > > > >>>I'm not sure if the draft needs to be updated before the > > > > > >>>face-to-face meeting or after all comments are collected. > > Please > > > > > advise. > > > > > >> > > > > > >>=3D> suggest to keep discussion on - document update can be > > > > > >>performed at a later stage > > > > > > > > > > thanks, > > > > > - dimitri. > > > > > > > > > > >>>>-----Original Message----- > > > > > >>>>From: owner-ccamp@ops.ietf.org > > > > [mailto:owner-ccamp@ops.ietf.org]On > > > > > >>>>Behalf Of Adrian Farrel > > > > > >>>>Sent: Thursday, October 27, 2005 4:45 AM > > > > > >>>>To: dpapadimitriou@psg.com; > > dimitri.papadimitriou@alcatel.be; > > > > > >>>>ccamp@ops.ietf.org > > > > > >>>>Subject: Re: comments on > > > > > >> > > > > > >>draft-shiba-ccamp-gmpls-lambda-labels-00.txt > > > > > >> > > > > > >>>> > > > > > >>>>Dimitri, > > > > > >>>> > > > > > >>>>Thanks for your work reviewing these recent I-Ds. It is > > > > > >>>>really valuable > > > > > >>>>and I'd welcome other people doing similar reviews. > > > > > >>>> > > > > > >>>> > > > > > >>>> > > > > > >>>>>there is a specific point to be clarified in this document: > > > > > >>>>> > > > > > >>>>>semanticless vs semanticful label (even here there is a > > > > distinction > > > > > >>>>>between spectral vs indexes i.e. using the > > wavelength index) > > > > > >>>>> > > > > > >>>>>domain-wide vs link local significant label > > > > > >>>> > > > > > >>>>Without being too picky, I think all labels are semanticful > > > > > >>>>otherwise, we > > > > > >>>>would not know what resource they refered to. > > > > > >>>> > > > > > >>>>So the point reduces to whether the scope of the semantics > > > > > >>>>are link-local > > > > > >>>>or wider. > > > > > >>>> > > > > > >>>> > > > > > >>>> > > > > > >>>>>so, the comparison from this perspective with TDM labels is > > > > > >>>> > > > > > >>>>difficult to > > > > > >>>> > > > > > >>>> > > > > > >>>>>parse, the latter is semanticful but link local > > > > > >>>>> > > > > > >>>>>now, i don't specifically see what has changed the > > late 90's, > > > > early > > > > > >>>>>y2k's, to have a change in the wavelength label definition; > > > > > >>>> > > > > > >>>>This is the question I would like to get to the > > bottom of. In > > > > > >>>>other words: > > > > > >>>>do we need this function? > > > > > >>>> > > > > > >>>>It seems to me that the question being asked is this: > > > > > >>>> > > > > > >>>> If I want to compute a path that has some form of > > wavelength > > > > > >>>> constraints, what information do I need access to? > > > > > >>>> > > > > > >>>>Another question might be: > > > > > >>>> > > > > > >>>> If I want to signal a path with wavelength > > constraints what > > > > > >>>> information do I need to include in the signaling message? > > > > > >>>> > > > > > >>>> > > > > > >>>>I'd suggest that when we started on GMPLS, we were > > > > > >> > > > > > >>enthusiastic about > > > > > >> > > > > > >>>>transparent optical networks, but we were not properly > > > > > >>>>focusing wavelength > > > > > >>>>constraints because lambda-switching PXCs didn't take off. > > > > > >>>>Therefore we > > > > > >>>>didn't examine the requirements for wavelength > > constraints in > > > > > >>>>routing and > > > > > >>>>signaling. The authors of this I-D are claiming new hardware > > > > > >>>>requirements > > > > > >>>>for the same function. > > > > > >>>> > > > > > >>>> > > > > > >>>> > > > > > >>>>>there are > > > > > >>>>>several solution possible > > > > > >>>>> > > > > > >>>>>- absolute values: the freq. of the wavelength: > > difficult to > > > > adopt > > > > > >>>>>because referenced values are nominal and knowing all > > > > interactions > > > > > >>>>>between wavelengths this knowledge is at the end of little > > > > > >> > > > > > >>practical > > > > > >> > > > > > >>>>>usage; (introduces implicit ordering) > > > > > >>>>> > > > > > >>>>>- indexed values: the # of the wavelength: it does not > > > > > >> > > > > > >>provide for a > > > > > >> > > > > > >>>>>future proof label space for inst. in case new frequencies > > > > > >>>> > > > > > >>>>are inserted > > > > > >>>> > > > > > >>>> > > > > > >>>>>in the grid (introduces explicit ordering) > > > > > >>>>> > > > > > >>>>>- diff. values e.g. freq spacing starting from a reference > > > > > >>>> > > > > > >>>>value: pauses > > > > > >>>> > > > > > >>>> > > > > > >>>>>the question of the reference value and does > > suffer from the > > > > former > > > > > >>>>>issue (introduces implicit ordering) > > > > > >>>>> > > > > > >>>>>- the solution available today - cumbersome in some > > > > control plane > > > > > >>>>>operations (e.g. label set translation) and not easy to > > > > > >>>> > > > > > >>>>troubleshoot but > > > > > >>>> > > > > > >>>> > > > > > >>>>>independent of any physical consideration (spectral), scale > > to > > > > any > > > > > >>>>>number of wavelength per fiber, does not introduce any > > > > > >> > > > > > >>ordering, the > > > > > >> > > > > > >>>>>most flexible (since allowing each system to maintain its > > > > specific > > > > > >>>>>control operations) and the less constraining since > > maintaining > > > > the > > > > > >>>>>control plane operations independent of any data plane > > > > specifics > > > > > >>>>> > > > > > >>>>> > > > > > >>>> > > > > > > > >>>> > > > > >>> > > > > > >>>ambda-labels > > > > > >>>-00.txt> > > > > > >>> > > > > > >>>. > > > > > >>> > > > > > >> > > > > > > > > > > > > . > > > > > > > > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 31 Oct 2005 16:44: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: Two Drafts for Resilience of Control Plane Date: Mon, 31 Oct 2005 08:43:19 -0800 Message-ID: <626FC7C6A97381468FB872072AB5DDC836971D@XCH-SW-42.sw.nos.boeing.com> Thread-Topic: Two Drafts for Resilience of Control Plane Thread-Index: AcXeMlogEzfcQWXxTaabrq+w3EYCBAAAaCwg From: "Drake, John E" To: "Igor Bryskin" , , , Cc: , , , , . >=20 > No John, >=20 > This is not true, I gave you a very specific problem - provide mechanisms > to > manage LSPs with impaired control plane (when one or more controllers are > out of service). > You said that this is not a problem, because RSVP is a soft state protocol > and once there are no refreshes the control data plane states must be > destroyed and hence there is nothing to manage. > And I tried very hard to explain you why this is not acceptable and hence > must be addressed. [JD]=20 Actually, I didn't say that. What I said was that in your example, PathTear and PathError with state removed should work just fine. Due to 'CP degraded' notification, nodes C and D will know that B failed. In option a), local policy, configured via the NMS, at D will tell it whether to send a PathErr with state removed and if so, how long to wait. As stated in another e-mail, multiple CP failures are handled by configuration, via the NMS, at intermediate nodes that tell them under what circumstances and after what duration to send PathTear and /or PathErr with state removed, or whether simply to wait until the resources time-out and how long to wait before timing them out. In option b) A creates an MBB LSP on the path A, E, F, H, K, D. Subsequently, A sends a PathTear to B, and D sends a PathErr with state removed to C. The MBB LSP was created under policy control, via the NMS, at the ingress node, A. Here's your initial example: A----B------C-----D | | E-----F-----H-----K > I have a solution and am planning to write a draft. I'd like this work to > live in CCAMP. [JD]=20 You can't get pre-approval of an I-D. >=20 > Igor Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 31 Oct 2005 16:26:23 +0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=k7LyDCxXCrVt+S0cG0U5+emGpqRpYH0KtV5BGT3u6edqhfuRUYA53r56V/d41CxM00Y4wNPwDiCcFs+qesCjimDrtCbPYZ1qOH4k6eSWuj6lVJWJbr0AXJZQeRKEudN6T5P0AovbpoGsHiuTBkCDx9G9b84vwvqlbKeIrLJDtpw= ; Message-ID: <20051030152558.71818.qmail@web30811.mail.mud.yahoo.com> Date: Sun, 30 Oct 2005 07:25:58 -0800 (PST) From: Igor Bryskin Subject: RE: Two Drafts for Resilience of Control Plane To: "Zafar Ali \(zali\)" , ibryskin@movaz.com Cc: drake@movaz.com, John E , dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be, Igor Bryskin , Kim Young Hwa , ccamp@ops.ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Zafar, --- "Zafar Ali (zali)" wrote: > > > >> > > > >> > Igor, > > >> > > > >> > W.r.t. option C, please note that traffic > CANNOT be > > forwarded in a > > >> > "head-less mode" for a very long time . If > you control > > >> network melts > > >> > or a peering controller goes down, either > RSVP GR or > > refreshes will > > >> > take care of the clean-up of the affected > RSVP states. > > >> Similarly LMP > > >> > CC SM will go down (after states are cleared, > i.e., > > >> degraded-to-down), > > >> > eventually removing the TE links from > topology. > > >> > > > >> > > >> Sticking to the example I described: > > >> a) absence of RSVP refreshes does not affect > data plane in any way; > > >> b) use of LMP is not mandatory and, becides, I > don't see > > now it helps. > > >> True, the TE link could be withdrawn, however, > the LSP > > will still be > > >> operational > > > > > > Isn't the problem is at "B" only and control > plane at the > > other node > > > (or controller for other nodes) still working > fine? If yes, local > > > controllers will withdraw RSVP states; hence > correct the data plane. > > > > > > > Again, GMPLS controller cannot remove control > state and > > destroy data plane just because it does not get > refreshes > > from adjacent controllers. > > Then how states get ever destoryed, even in normal > case, e.g., if head > end sends a ptear and all controllers are up? > States are supposed to be destroyed on explicit signalling message (e.g. PathTear or PathErr with the state removal flag), but not because of the absence of refreshes. Igor > Thanks > > Regards... Zafar > > > __________________________________ Yahoo! FareChase: Search multiple travel sites in one click. http://farechase.yahoo.com Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 31 Oct 2005 16:13:07 +0000 From: "Payam Torab" To: "'Drake, John E'" , "'Shiba, Sidney'" , Cc: "'Adrian Farrel'" , , Subject: RE: comments on draft-shiba-ccamp-gmpls-lambda-labels-00.txt Date: Mon, 31 Oct 2005 11:11:46 -0500 Message-ID: <00f201c5de35$cb12b140$30fea8c0@NETPTORAB> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_00F3_01C5DE0B.E23CA940" This is a multi-part message in MIME format. ------=_NextPart_000_00F3_01C5DE0B.E23CA940 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit John- Obviously the benefits or harms of giving a global meaning to a lambda label requires study, but your particular example is not a good one: If one really wants to have a preference for a specific wavelength channel among multiple parallel channels of the same wavelength, bundling should not be exercised in the first place. Thanks, Payam -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On Behalf Of Drake, John E Sent: Monday, October 31, 2005 10:36 AM To: Shiba, Sidney; dpapadimitriou@psg.com Cc: Adrian Farrel; richard.rabbat@us.fujitsu.com; ccamp@ops.ietf.org Subject: RE: comments on draft-shiba-ccamp-gmpls-lambda-labels-00.txt Sidney, But there's nothing in your picture that requires an absolute end-end global wavelength. The existing GMPLS solution with relative wavelengths of local significance should work just fine. As I said in my previous note, your method precludes combining two or more parallel WDM links into a single TE link. Thanks, John > -----Original Message----- > From: Shiba, Sidney [mailto:sidney.shiba@us.fujitsu.com] > Sent: Monday, October 31, 2005 7:25 AM > To: Drake, John E; dpapadimitriou@psg.com > Cc: Adrian Farrel; richard.rabbat@us.fujitsu.com; ccamp@ops.ietf.org > Subject: RE: comments on draft-shiba-ccamp-gmpls-lambda-labels-00.txt > > Hi John, > > Optical switches based on Wavelength Selective Switch (WSS) technology > requires the wavelength information for switching. This technology is NOT > wavelength agnostic. > > | | > | wdm | wdm > |2 |2 > --------- --------- > wdm 1| optical |3 wdm 1| optical |3 wdm > --------| switch |------------| switch |--------- > | (WSS) | | (WSS) | > --------- --------- > |4 |4 > | wdm | wdm > | | > > Note that the figure above shows an example of two optical switches > interconnect > by a single WDM fiber. In this example, each optical switch can be connect > to 4 > other optical switches. > > As you can see, the optical ports information do not provide enough > information > for wavelength switching. > > Hope that clarifies the application requirement. > > Thanks, > > Sidney > > > -----Original Message----- > > From: Drake, John E [mailto:John.E.Drake2@boeing.com] > > Sent: Friday, October 28, 2005 5:33 PM > > To: dpapadimitriou@psg.com; Shiba, Sidney > > Cc: Adrian Farrel; richard.rabbat@us.fujitsu.com; ccamp@ops.ietf.org > > Subject: RE: comments on draft-shiba-ccamp-gmpls-lambda-labels-00.txt > > > > > > Hi, > > > > Below is the text of an e-mail is sent to the Ethernet/GMPLS mailing > > list. > > > > Upon reflection I am not sure using a real wavelength value makes much > > sense. Between a pair of adjacent nodes, there may be > > multiple pairs of > > switch ports in the same TE link that support a given frequency. If a > > real wavelength value is used, how do the two nodes agree on > > which pair > > of switch ports to use? > > > > Furthermore, the amount of configuration is the same - you > > still need to > > configure the wavelength of each switch port. > > > > Thanks, > > > > John > > ============================================================== > > ========== > > ==== > > Adrian, > > > > In the transparent photonic lambda switch case, the labels also have > > only local significance. When an LSP is established, the input ports, > > as identified with local labels, are cross-connected to the output > > ports, as identified with local labels. > > > > There is just extra configuration to identify, using strictly local > > identifiers, the wavelength associated with the all of the switch's > > ports, and an additional CAC requirement that the wavelengths of the > > input and output ports are the same. > > > > Thanks, > > > > John > > > > > > > -----Original Message----- > > > From: dimitri papadimitriou [mailto:dpapadimitriou@psg.com] > > > Sent: Thursday, October 27, 2005 10:03 AM > > > To: Shiba, Sidney > > > Cc: dimitri.papadimitriou@alcatel.be; Adrian Farrel; > > > richard.rabbat@us.fujitsu.com; ccamp@ops.ietf.org > > > Subject: Re: comments on > > draft-shiba-ccamp-gmpls-lambda-labels-00.txt > > > > > > shiba - see inline for some additional hints: > > > > > > >>Shiba, Sidney wrote: > > > >> > > > >>>Adrian, Dimitri, > > > >>> > > > >>>Thanks for reviewing these I-D. > > > >>> > > > >>>Wavelength continuity constraint does require the use of > > semanticful > > > >>>label whether it is spectral or index. > > > >> > > > >>=> see my reply to adrian on this specific point > > > >> > > > >>>I agree with Dimitri that the > > > >>>wavelength indexing requires document updating each time a new > > > >>>spectrum is introduced. > > > >> > > > >>=> indeed and in addition it requires updating the already > > > >>signaled path > > > >> > > > >>>The use of spectral label provides self maintainance, i.e., > > > >>>no need to update any document and the use of the nominal value > > > >>>provides a common semantic ground. > > > >> > > > >>=> what do you mean by self-maintenance - would you provide a > > > >>bit more detail > > > > > > > > [Sidney]What I've meant here was that it was not necessary to > > > > update any document when new wavelengths are inventoried. In the > > > > case of indexing approach, it would require the > > wavelength indexing > > > > document to be updated with implementation impacts. > > > > > > > > In the case, the nominal value is used, there is no need for > > > > documentation update. > > > > > > ok - what you mean here is that you are going to make use of the > > already > > > defined C-Type 2 - what about the specific encoding of the > > value space > > ? > > > > > > >>=> now i have a more specific question before being light-up > > > >>how do you know the frequency that you can support ? > > > > > > > > [Sidney] Some new technologies integrate optical switch and > > mux/demux > > > > capabilities, which allows the equipment to know the spectrum it > > > supports. > > > > > > indeed - but the question is what does happen if the > > "detected" values > > > (during initialization) do not match the nominal values ? you don't > > > initialize then ? > > > > > > >>if these differ from the nominal values how are you going to deal > > with > > > these > > > >>discrepancies ? > > > > > > > > [Sidney] These new technologies uses the nominal value as > > reference. > > We > > > can say > > > > that a lightpath wavelength is identified by its nominal value. If > > the > > > equipment > > > > is drifting from this nominal value, it is considered as > > a failure. > > > > > > ok - but if the deviation is such you have overlap - how the control > > > plane is going to be able to detect such failure ? > > > > > > >>this said i am not necessarily sure that having to > > maintain the data > > > plane > > > >>specifics as part of the control plane is really helping > > > >>operations (is this method not just duplicating complexity ?) > > > > > > > > [Sidney] The wavelength is WDM specific as much as the SUKLM label > > > encoding > > > > is for SONET. The wavelegth/frequency nominal value is used to > > identify > > > the > > > > facilities to cross-connect. > > > > > > there is an equivalence but there is also a major difference, the > > > structure is invariant independently of the state of the > > network, with > > > spectral value space you may have labels that become unavailable due > > to > > > non-local usage of wavelength in the network > > > > > > hence, there is also no real coupling to the data plane more than > > > knowing the type of interface and some generic capabilities > > > > > > >>>I'm not sure if the draft needs to be updated before the > > > >>>face-to-face meeting or after all comments are collected. Please > > > advise. > > > >> > > > >>=> suggest to keep discussion on - document update can be > > > >>performed at a later stage > > > > > > thanks, > > > - dimitri. > > > > > > >>>>-----Original Message----- > > > >>>>From: owner-ccamp@ops.ietf.org > > [mailto:owner-ccamp@ops.ietf.org]On > > > >>>>Behalf Of Adrian Farrel > > > >>>>Sent: Thursday, October 27, 2005 4:45 AM > > > >>>>To: dpapadimitriou@psg.com; dimitri.papadimitriou@alcatel.be; > > > >>>>ccamp@ops.ietf.org > > > >>>>Subject: Re: comments on > > > >> > > > >>draft-shiba-ccamp-gmpls-lambda-labels-00.txt > > > >> > > > >>>> > > > >>>>Dimitri, > > > >>>> > > > >>>>Thanks for your work reviewing these recent I-Ds. It is > > > >>>>really valuable > > > >>>>and I'd welcome other people doing similar reviews. > > > >>>> > > > >>>> > > > >>>> > > > >>>>>there is a specific point to be clarified in this document: > > > >>>>> > > > >>>>>semanticless vs semanticful label (even here there is a > > distinction > > > >>>>>between spectral vs indexes i.e. using the wavelength index) > > > >>>>> > > > >>>>>domain-wide vs link local significant label > > > >>>> > > > >>>>Without being too picky, I think all labels are semanticful > > > >>>>otherwise, we > > > >>>>would not know what resource they refered to. > > > >>>> > > > >>>>So the point reduces to whether the scope of the semantics > > > >>>>are link-local > > > >>>>or wider. > > > >>>> > > > >>>> > > > >>>> > > > >>>>>so, the comparison from this perspective with TDM labels is > > > >>>> > > > >>>>difficult to > > > >>>> > > > >>>> > > > >>>>>parse, the latter is semanticful but link local > > > >>>>> > > > >>>>>now, i don't specifically see what has changed the late 90's, > > early > > > >>>>>y2k's, to have a change in the wavelength label definition; > > > >>>> > > > >>>>This is the question I would like to get to the bottom of. In > > > >>>>other words: > > > >>>>do we need this function? > > > >>>> > > > >>>>It seems to me that the question being asked is this: > > > >>>> > > > >>>> If I want to compute a path that has some form of wavelength > > > >>>> constraints, what information do I need access to? > > > >>>> > > > >>>>Another question might be: > > > >>>> > > > >>>> If I want to signal a path with wavelength constraints what > > > >>>> information do I need to include in the signaling message? > > > >>>> > > > >>>> > > > >>>>I'd suggest that when we started on GMPLS, we were > > > >> > > > >>enthusiastic about > > > >> > > > >>>>transparent optical networks, but we were not properly > > > >>>>focusing wavelength > > > >>>>constraints because lambda-switching PXCs didn't take off. > > > >>>>Therefore we > > > >>>>didn't examine the requirements for wavelength constraints in > > > >>>>routing and > > > >>>>signaling. The authors of this I-D are claiming new hardware > > > >>>>requirements > > > >>>>for the same function. > > > >>>> > > > >>>> > > > >>>> > > > >>>>>there are > > > >>>>>several solution possible > > > >>>>> > > > >>>>>- absolute values: the freq. of the wavelength: difficult to > > adopt > > > >>>>>because referenced values are nominal and knowing all > > interactions > > > >>>>>between wavelengths this knowledge is at the end of little > > > >> > > > >>practical > > > >> > > > >>>>>usage; (introduces implicit ordering) > > > >>>>> > > > >>>>>- indexed values: the # of the wavelength: it does not > > > >> > > > >>provide for a > > > >> > > > >>>>>future proof label space for inst. in case new frequencies > > > >>>> > > > >>>>are inserted > > > >>>> > > > >>>> > > > >>>>>in the grid (introduces explicit ordering) > > > >>>>> > > > >>>>>- diff. values e.g. freq spacing starting from a reference > > > >>>> > > > >>>>value: pauses > > > >>>> > > > >>>> > > > >>>>>the question of the reference value and does suffer from the > > former > > > >>>>>issue (introduces implicit ordering) > > > >>>>> > > > >>>>>- the solution available today - cumbersome in some > > control plane > > > >>>>>operations (e.g. label set translation) and not easy to > > > >>>> > > > >>>>troubleshoot but > > > >>>> > > > >>>> > > > >>>>>independent of any physical consideration (spectral), scale to > > any > > > >>>>>number of wavelength per fiber, does not introduce any > > > >> > > > >>ordering, the > > > >> > > > >>>>>most flexible (since allowing each system to maintain its > > specific > > > >>>>>control operations) and the less constraining since maintaining > > the > > > >>>>>control plane operations independent of any data plane > > specifics > > > >>>>> > > > >>>>> > > > >>>> > > > >>>> > > >>> > > > >>>ambda-labels > > > >>>-00.txt> > > > >>> > > > >>>. > > > >>> > > > >> > > > > > > > > . > > > > > > ------=_NextPart_000_00F3_01C5DE0B.E23CA940 Content-Type: application/ms-tnef; name="winmail.dat" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="winmail.dat" eJ8+Ii8QAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEGgAMADgAAANUHCgAfAAsACwAAAAEAHAEB A5AGABQcAAAlAAAACwACAAEAAAALACMAAAAAAAMAJgAAAAAACwApAAAAAAADAC4AAAAAAAMANgAA AAAAHgBwAAEAAAA5AAAAY29tbWVudHMgb24gZHJhZnQtc2hpYmEtY2NhbXAtZ21wbHMtbGFtYmRh LWxhYmVscy0wMC50eHQAAAAAAgFxAAEAAAAWAAAAAcXeNcpyWStaVYm1SxaXOoXTA/t1xQAAAgEd DAEAAAAXAAAAU01UUDpQVE9SQUJATE9QU1lTLkNPTQAACwABDgAAAABAAAYOAEL3rjXexQECAQoO AQAAABgAAAAAAAAA35HcBW94wkS/G1ZZrXI85sKAAAADABQOAQAAAAsAHw4BAAAAAgEJEAEAAAC8 FwAAuBcAAJM6AABMWkZ1tGSTmAMACgByY3BnMTI14jIDQ3RleAVBAQMB9/8KgAKkA+QHEwKAD/MA UARWPwhVB7IRJQ5RAwECAGNo4QrAc2V0MgYABsMRJfYzBEYTtzASLBEzCO8J97Y7GB8OMDURIgxg YwBQMwsJAWQzNhZQC6YgSnBvaG4tCqIKhAqATwhidmkIYHNseSBgdGhlIGIJ8AEQaS50BCAFsRPh bR9RZiCEZ2keIG5nIGEgIHUXsGIHQCAHgABwIGJ07m8gkQtgBtBkIeIe4AMgMRggcXVpGCAEIHN0 UHVkeSwe0HUFQHnVCGEgCrF0DeB1C2AFwB8OwCIQC1AewAQAIG5vOwVAIKFvBHAfYB8AOiC+SSAQ JnEiwQdAHnF3AHC3H0EhsRPgdh7AIKBwGCD2ZgSQCfBjHsACEAXAIKD8c3AFkAaQDeAnkShQJWDr IHAeoCAT0W4fAAMgIhD7AiAggG0kwCSQJVIKsSdR7yKhKvUf4x6icyIQHsAqSJEjsm5kbCBic2gI YP5sJlAlwh7gJQEEkCngFBD/JlALgB6THyAUAAVAC1EpIIouHUpUKwFrcywdRFhQYXkiEB1KLTTi T2sFECAwbiEBTQeQLfBnNmU04x1ERgNhJqBvdyEfAHItY2MlMUBv2HBzLgiQADAuBbAggG5bAMAD ECGwOjdPOFVdpk8LkB1TQmUT4GwgEMpPIBBELIBrZSOwHPK8IEUdRAZgAjAmoE0CIHMiQCOhT2Mh sB7gBcAzBjEjsAHQMDUgMTB2OhwgEMBNMqU5MAYAaEZpIPAjsFNpZB8Aedg7IGQKsAqwZAdwHzDL BRAIYEA4EGcuBaA0FWRDYyagQWQHIQOgRj8KwBggAnAiwA3gE+FkLiUsgGIg8HRAHlAuZnR1ah8x dUJSQRA5v2cxPNV1YmoFkD1hUkX/JqBCYQeAJ8ICIEEgLIABgE4tL5BAYTmkLWclQXO+LSIESpEi kUqAPuAuDND+dB1KPNVAwzNlOwUj4R6h/RggJyWjQFAgcTERJBQN4H8jcBggHpFE4CLIA5EBoHPv BvAj4DBRLyAtUhEdRCDF8SpILiAgMwAwUgQAJJDhIHFHTVBMBfBRox4wvwOgA/AqwUPRROAgQGUd RL8qSB/jF7BGIAMgAJBnAwAvKgEAcCkhL5V3BbBrIL5qHlAFQB8gHwBT8UEEIN5JLeFAwDEBHURt HoAoof8eIyWyPEEkEweAHqAmQSih3mMKQAEABCBCYWILgCFzP1mgH2IEYFBBLGYdRFdE/k0h8AuA M0AxASGzAJAgcPklYVRFYMMyPzNHHUQc8vkdSj4gNO81/WWANuRAS7c4xwCQQNIuSYNFDV1lJvM9 Pz5MNzoOMD93ZYBAAv88C0EfQitlgEL/RA9FH0Yvf2tHR69Iv0nPSt9lJmUmSO5pHOMzZXsoTwUw WMFYQb9V4RPQB5Eg8DDSd9FXKlg/BmAlYD4gVoEGAH3TICjwV1NTKR6QBZAdEBeh/Gd5ZSYi1x6i KkkLgClR/wDAVZMpUn3EIGFT8DMAJZHHgQglgR1ETk9UZSYqSXc2ACXAVJFjYoV7KIm9fI+JvopV iU+KVndkbYsf/42UjD+KVRRAkP+Qo49vVAC/ZaNlopFMk5eSao3DMYqw8zgAfWR8M5Ymlo+PO5OW /4qwfcSKkZOXmi+VP4pIgKR/iqyeKZ0Pk3+g/6BPilU0/5E/pKSjf41Ppy+mf4pfi2/dewpOXKFQ ZDFEZ1AyAaD2byhRL5F3UTMlFi2CXwL/fV1lJmExMJECIB8APiBlJn5iHoBhh2CSHyA+UVPwSf8x IiWRJRUjsCFAgHGwzCrg/wORHuAdRLKdIbGmZ08BEoH/sM6Iv1qxJBG3MxQQPEEeot2W1nAXwWES g8hkIcAlwp8ooK8AQMBR8ghgZ2ixyP+Dx2UmKVIqSYSoes84AFBV/13gCsAp8YKFb/ALUFjBVZP/ ItV3csOPMwt7KEC0w55ljz9mn8tCNuQ8CzjHHPIuRdIuPAMyQAbgZYUCawpPa6Y24EDAbGoyOD61 Nfs/QJdgUG4XboRv30JDb7D/QEvK6HG/cs9z33Tv0Rl2j/93lB1EeA95H3ovy1Dhb3ui/8j34nk7 YBewB+CFch6xDrP7IAGvoi044iWCFBACMCGizR6iRU5yHwB0L1T0OOK/IGHK6C9AI2DHh+J5Vb3g /cayZn+zd9Fa4CIQJbPagN9QQR5QIGQnMio6dgdAClD/6EE8MIZlK9AT0Mro5qEUEP9T8TtgXvAJ 4ShyC3C58eWx/GRqMgHmwSXAXhG9A1BB/wDAHoC3hstCK9kxkR/x75n/gES95i2oYhVQZNqAxiAX wf8gklaBhEEi0ikBadBUACbA/R1EYcro7U/uUyWRHlAJgP8jsK9RvvLlE18B8mOIIQnR+94Xy0J3 QFD2IvFhyuggAff16yGx/ME/6b9noQhwTnL/X2K9BCtxLxDlg7KRrnOEBP/k5S3zofC8Ue+ZJJAn YCWw/wngJlAhsMroBSZQUoLbIAH/tgP16emv1ILIrOJ5ZIjLQv49D68QvxHPEngPDxNfyuj/2CQN j8tRtPNQUSyA8FAsYf3msnAvoCGwIWAqICIFttd/8GC9BOCU+LAtUCgUADlu9x5xWA9acldUMPER 8RBVIPZQJYL+QHTZoOlhVDD88fuuMltQcCPgNIS94xao+LD/YRH+MPIwxXJZgVXyHRTglP+14Bix KuC/gMyA31CypAgz/70UIJAgh8tCIRQiDyMdC+//DPPy8uZxWfPlYV/QBR1hUd8nddJh7MQxsNkR dBzmyuj/J3cxoL0Eh4rMgB0g2FAlIv9V48XTB+GwUvbym/NOwCY/d1FQXZBRUmTVQFWSvbFD/EFD xsqt2FcdrjEuqSBy/zRzJdS91SQi9uYpPwz/Dg//PO/K6MtvzH8/xGfE1UVfoX/VKWj31P/Qvmum Y1ADgHOF0kw30zUxMDowl2C/bgjUdtZ/P6bX4kUVLkTc9zJAxmHY0C7S0G+w2Cw/at/ZH9ov2z9G WdzXZd1/yyT/3q/fv+DPP9I/alZjBrG80f/2oeiBrlGEcl5grsE1CITxTQGgOljPP8Q+Pmgsd9+/ gOVQXPpeYV28PhZFzhD/1VQhaWFTYL3IlIRT/pC/oD5lm/Ds8a4x8GD58C1EvzsoYz9hYn7pspEn sG6CUP50s5CykS3B8WDyMb8A/kH/giWuI/zB9RzHMDTAfWFRMP8umWFTGyP/gVKwudJRYOZj/8Sw 3RAYYDJhbtE0kK/QZm39Xbw98BLugbOQ/pCwELOQ/yyRRQDYQyxihWJvUh2yC5H/XLFwf2Dq6+H+ gzGzYiWt1z9gvYL7cDHs4oInvwBjdf82U/hQGeBpMe0AtgMnsFvC/QgBd2C9b1R7wOZiXLG/gP5k 72AlMHBvcX1wEiUxNIJ/9rE09m7iewd8JzIE+zFk/0tLfnEdgTJAJTEYoIgAgA+/Y8xrVm9IbhS/ deaCbADg/+Yh8jBqER3yteBMsPBwYp7vvzAIBnwUrsFus5B7lzSC/2s4riO/MEMAQMLuQ2C9iof/ K5LdsOuxbHb40L+ABLB/7/9xbv+Q+BG/AbxS90C3UrOQ/4sS5hKyUYvTWoH94PRAJUDvvFK/dvqJ XlJibvED4tTgv1Kw5jFdu127zvDW5F0eYPn4EUknrxGXMvig8uMwUH/FsvgRbvGfYr8yssFBEnL/ cxKcvI4/8jFucfEQfXE3K/8kIkCw+QEskMVgf9EX1Zy8/xqCAMJ6d8YRv4C2EYwhoAH/mPNquf75 ed9TG1Xhe6Yskf/S0KI1KAXVULARx0IFpbWg//IAAaBmbJy8F+UaiJCr/Ij/8tTmcY2GwgGr73vD BaSiRPtmaj9qb/fQmMHE8pb3Kob3xOO8UiQiZ3TxZbFzQO6if4/pIXmFD5txdKDnsCVAQ+gtVHnE sTK5JlCgOZH/9tR0ZvmR/iDs4jf+7kQYkf8eEMroAjhdnnIx7DDkwRvT//ixmzN0V/lxB7HrsdLQ tTHPW0DS0Ozi6IBnaFZA+FD3Xbz9JZbya8YyICL5R7qo/x3h+DfEapyfnaXRoFuyo9L/5VBQMOww 5KBAoP5BmCL+gH+iclJgbMEdQhokNIHzmnj+L/4w0+GmThigmvDogCewv/KS/5QyQeSwBhR7EnCt Bv/LV36YdSv4Ra/bP2qB9VqQ/mLAhcfn5nGWdf5BloD4YLfxAR2wOBwim4ElAyLuNPszaUAAKH+g QIDs8UCwNSHpMkBpegWjKf1S7DLmIDcaQrJ//lA/Btj9YG4n/3Ur4kc6g/EQxG9eB970ZgH5RRBm ZkhB+UBbsOQP3lL/y3EkIpbyu4bllftB/vkxwe8/amXTXbxFEHMkYHLgHfH/0ULN387vz/EqcWYB 0H/8wX8GFLK8J0D6muph+ZG3elf/eMvNE0ew8pyfo1pwyUOG0r+qqydbl4FRYbKsZmVJa8n/eK3X R/KcHyFOgVYwp/Lqpf+0g7LZqLMfIWmymcF3QDSh+zNpWnBmm7EJgdqfuJrcov/e9JtxkpCvFXQx f7AjIJby78aTmaAvwBsgcFqByqI4J/9pApJwbRuuoDTAs3O7h62B/x+BOoFzQOAECnQGxef/Xfj/ dASbsIKBkuB/AKBqm8CXkf8Q0p+jG+HtCtOji3UJZFDQ/5oLDgOFbcEFG3EbcO1xwDB/kDUM1Q34 vcEyUGmQIDBsenCrvj5SYC/ALDOksCj/uoMOYX0gMNDBsKBTKwN/oH+uoNJRfGNRsa6hp+BpgT8e KfHP8t/z4/wdV0RNH3RIJ0HT4NLi1uRTVUt+TEl1V/MAW8GVAa9k8lNwT05FVKXAI+gwwS//y+iy v7PCoTv9Bforph8GwO/xYNW0jfLxAG9BIFawyED9oKF0Bz/vOLRUl1F7EsMRv/fy3JY0FVgwc0EW YWpbcf/qNPfytANZe37RVDAQ0n8j/8MQTpJvAXAh3rH9EhRxkDUvyBDR48It9GB0qQBya//WEe69 b1fDGZbkR7DGhFf0/3hEWBBRsa2RXGDDEJvAD1Lv7WWRWqFMxjBuV3B7oNJx/1EAdyCJQ6q79bQ8 5DJ/4WT/o5E3hTXZjYEcElShICK7tP8XBg31mzOfoVVZ37DLUoR272mAv5Gnc1+gcjCxjoLcYP9b o0VA9GAUUHTA1VpHP3Z4/icThBSjCUZWEo2jMUOtiavIdXivPk8CLdfgLU8D/30gbpDB02UQVCHq cdaRkwO/AXGktEFg1qDgM2ZlUIaQf7Ih4QpzYJKQ79CUf3F+df5nRUAf4dfid1ALwPDSRRD/BWDI QchBv+B7nLHyyFJcvP8d4bUxfSCCQftDonEqMDtx50VAUS/6t25r1gDhCmCBp3fkMm92aD4taXJP FFB70TD2Qk0UEkVAaXNofkb16rE6C1B3UAEx4NJgr4COQNIgr9ClkHRmLrVA1avZWxZxbNfgOmx/ bYXMXU9Mq2kyQmWWgIsx2k+QQEECsZdRRrtAd0B7m9x20VMBcWxQiOAQ0HPVS3B5jCBP4EBvDyAq MAQyN4wgMjAwNSBoNDo0diBBJwVo2FS/bvACoPvQ+9BnRbsQQG1A9GcuQWE7Zzd4DNaQIGH1J6Au DyA7aH5vfxztdBGYdWJq4DFsUFJlbFCfWVfIQFy/8CpUEi1z1kDkYmFvZC1nrpEx0EIQXG1iS3CD UUCiLXYALtx0eAGcaG9ofkRnVIyO/4Z/KsBmEioDlvEqMD0CqVF/kpDQgE216gH3oPgQrSFJ/C1E r9CeUATiaH4cFcMS/0IoaNhPUlLArhEnoEFjoHD7tDEN8GXSIA9xyuCn8gVg/2dgQhAqMItUr92I 35R/lY+/EqE0BsdI2kAWkQ7lY5LR7/1UFtMCgqMFOpafm1/v0H8WcP0xmaAUEfZwCmGdhWb/qSBA dOGwCcDewbQzNajhCP/w0SCB4EAeMZxvDyA88NxA380xPnc5YqfB0VIuXJCzsX9Ntqq+IZycL2ky yuAWci1/rjAP0J4ySrEIwES0BWBnv+JQx6E54id/p99SkVfusZ/Acsjk1+APABywY2t1Af5JA4Kq MVkSQIW7Qp55aH7/kWM9YO/Q1hGPXz0AnwAfZP/LU8AD96BPkBDQTyH1wUAQ//ekLYKTj32vSxSY 5AWhJhD/MTTAAB8h6nHAs0FgTlTAs/+dhY1vsJKqEkSksY+K4QVy77cfwD/BT5yObzejIMMUQf9P kGHAA0gd4T5jNNAq4e6x/yqwJRFAhY1fwy/qMtZQnwD/XwLH/8rPlr3tcbLy9cJj0f9Y0gpSnokJ AqoYzL/Qv9gh/wSxYJHmEZhHHDPv0CrhFQQ/BRFMgUVALYHORE/AOTA+J2ZKSjALkPosaTJ5Mv5r 1nEO4kAzBqDVREZGJCn/nzQP0KsQ4lLFQHt/iQ8Dov8ek0/AK9GhocVBr2C0VFDA319QDuJFQF8D 9cJiUxBLAP/q0DsAjQGiL5FkPQFUkJtP/2CgkNFUUwOEnvCh1PG83S/3UqEQIVRwbTFDT7H7E97b f65UJdBfUBMxHqTj32h+IP+MsDsQ36E54jFiIOEJENly//vTFPUKYU+iYxJFbOzPBSP/PqEWkdjh 1LMW0GMSCfTk4X+vYOVDMMAUAkOB5m9ofkH/UwGRgt8XZ2D7oVWR67/xr//t3KrCaiHvNcbTJCny ydSj//qP89/lNQ8AocEs4KmxFtX//HQgkk+wanP13wQf546Qsf9ep9TCuqFhwOURO3EaYC1xwcVB R01QTFOzEpDR/3MAhK8KaYyBdKD8cCXQz2H/D0GuEQo/aKvzAR5QQnGMgv8d0M9haiE81djhz9IJ xVLz/nAbQB3h139XIJrRpWPxD3d7+P5pQUFhLVFAcYODc8c9YdmwIJJQWEOaoSNx/9NxZEDgQTsA fVDdX5/yVcP/sz/J4RhDISCDcEZQoCOLQf80sXMAWYQqEv2v/rRGUI1//64R6qNPYGh+AvcqpBZw rfH/dMA69JgBjMFZ1EIQZ1EDYf9UYLUg1MDjoNqQCh6OUh04/xJfKiE7M4Nw8GHl9RkfKk//K1+W v6ACJf+dQ0XAPrJPkP8/EPijuZBf8Y8/LR9pQgyx/zBzqcE/AuuguUPFcB0gpTD/OwXamHfRyg9c BA+xMp8WRv+2dEjBkIA0VFnTSfAcgfyy/09hTXbUIWZoTrNPEPiiJ9/fozfamOtUtOOSAGTZ8kmB 3+mURfAJATWAUMF0MW5iDb89k9CPPh8WgGqReVAoTrH/xYC6FGdQSqGYgA+R46BQEX8DYKb/Re8z kaSEOnY0tCP/NW82cUiR9KCk0bSxRR9D2/5vi3CpsSjioNlPfxMTz+D/dLC5ccWAQjKfQw8xV9Eo 4v8CgAxwpTACgUTgjCElYjUS/98g5gCaAD4PvM+X0g8goADfCOFW/1nPLW0ChWd6gJCA/0d6pLBI X0lvSn82k6UwOpX/pSAi4TUSVHOSUwiyA1LFc//vMDnnWr//bTqTbFAPQBaB/1bvZ/8tX97qTPU5 5zqEO7P/TlMHUDbAzrHFdWUZ8IKgAP9p/5gAB1ACYEd/Xp9frzLd/7sjMIamACTwnzGSAbpwg6D/ tlBLcJrhmXAjoJEiAoHwMv//WP5RXbGqoIMgkGBlH7+Q/8YR9EMWIJ+QYoJUJeCyDwK7znHfYSk7 s7SyjoBztlD3yp90H12xdXaBgkCuwK4x/wz+fz+CT1yxpsC7kKaxD4LHTQCQYLZQcGh5/HCqgtf+ Ur/i9EQoo8YpxGC7YN/UIHnFN0uFYINfbndT8Mz/xgId0DFAoADEYE5WPUJdxL+JL4NNcobEY43f MsxtMRD1+TBmdpB4MUKG8QIB2XH/1DA8JNdA2bC7UIWw1iDFof/pEf6yqVFOEWfpmFaRT3kG/3ro fUTVw54C/ldjU5NS/1T/lSYDUf9YkD+X6XmDmImmk/+ErRcAGJB5fpaGZ++RP6PPBf9ePPkgdHA6 Ly9qd6dgLlbAdOHQVPBnpi89UxAxLWQV0GYWEO4vqMMXIK+QYhcQ9VAW0OhwLWdyAXO+QP9d/10H FtSwJP9dLTAwLnT8eHSl3v9dKj6Qb/q4/1suICo8/1f/VH22IB4AQhABAAAARQAAADw2MjZGQzdD NkE5NzM4MTQ2OEZCODcyMDcyQUI1RERDODM2OTcxQUBYQ0gtU1ctNDIuc3cubm9zLmJvZWluZy5j b20+AAAAAAMACVkBAAAACwAAgAggBgAAAAAAwAAAAAAAAEYAAAAAA4UAAAAAAAADAAKACCAGAAAA AADAAAAAAAAARgAAAAAQhQAAAAAAAAMAD4AIIAYAAAAAAMAAAAAAAABGAAAAAFKFAABzeQEAHgAQ gAggBgAAAAAAwAAAAAAAAEYAAAAAVIUAAAEAAAAEAAAAOS4wAAsAEYAIIAYAAAAAAMAAAAAAAABG AAAAAAaFAAAAAAAAAwASgAggBgAAAAAAwAAAAAAAAEYAAAAAAYUAAAAAAAALABuACCAGAAAAAADA AAAAAAAARgAAAAAOhQAAAAAAAAMAHIAIIAYAAAAAAMAAAAAAAABGAAAAABGFAAAAAAAAAwAegAgg BgAAAAAAwAAAAAAAAEYAAAAAGIUAAAAAAAACAfgPAQAAABAAAADfkdwFb3jCRL8bVlmtcjzmAgH6 DwEAAAAQAAAA35HcBW94wkS/G1ZZrXI85gIB+w8BAAAAlAAAAAAAAAA4obsQBeUQGqG7CAArKlbC AABtc3BzdC5kbGwAAAAAAE5JVEH5v7gBAKoAN9luAAAAQzpcRG9jdW1lbnRzIGFuZCBTZXR0aW5n c1xwdG9yYWJcTG9jYWwgU2V0dGluZ3NcQXBwbGljYXRpb24gRGF0YVxNaWNyb3NvZnRcT3V0bG9v a1xtYWlsYm94LnBzdAADAP4PBQAAAAMADTT9NwAAAgF/AAEAAAAxAAAAMDAwMDAwMDBERjkxREMw NTZGNzhDMjQ0QkYxQjU2NTlBRDcyM0NFNjY0NjUyNDAwAAAAAAMABhDo79l/AwAHEDsgAAADABAQ AAAAAAMAERAoAAAAHgAIEAEAAABlAAAASk9ITi1PQlZJT1VTTFlUSEVCRU5FRklUU09SSEFSTVNP RkdJVklOR0FHTE9CQUxNRUFOSU5HVE9BTEFNQkRBTEFCRUxSRVFVSVJFU1NUVURZLEJVVFlPVVJQ QVJUSUNVTEFSRQAAAADQww== ------=_NextPart_000_00F3_01C5DE0B.E23CA940-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 31 Oct 2005 16:00:38 +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: comments on draft-shiba-ccamp-gmpls-lambda-labels-00.txt Date: Mon, 31 Oct 2005 10:00:16 -0600 Message-ID: <7CA873794E52904EAA980A074B076779B17C62@rchemx01.fnc.net.local> Thread-Topic: comments on draft-shiba-ccamp-gmpls-lambda-labels-00.txt Thread-Index: AcXbIzcAFoI5B5TzS9O/zBGY1cMJbwA6iz0AAIdyNZAAAR14UAAAnn6wAABj8oA= From: "Shiba, Sidney" To: "Drake, John E" , Cc: "Adrian Farrel" , , John, Most of vendor support a standardized wavelength grid (e.g., ITU-T DWDM wavelength grid given in nominal value). If a wavelength chosen for a lightpath setup is not available in an optical switch, it rejects the operation for resource not being available. Regards, Sidney > -----Original Message----- > From: Drake, John E [mailto:John.E.Drake2@boeing.com] > Sent: Monday, October 31, 2005 9:51 AM > To: Drake, John E; Shiba, Sidney; dpapadimitriou@psg.com > Cc: Adrian Farrel; richard.rabbat@us.fujitsu.com; ccamp@ops.ietf.org > Subject: RE: comments on draft-shiba-ccamp-gmpls-lambda-labels-00.txt >=20 >=20 > Sidney, >=20 > There's another issue as well. Having absolute end-end global > wavelengths is probably insufficient to ensure that an end-end LSP can > be established successfully, as having a common wavelength=20 > does not mean > that equipment from different vendors will interoperate=20 > correctly in the > data-plane. >=20 > Thanks, >=20 > John >=20 > > -----Original Message----- > > From: Drake, John E > > Sent: Monday, October 31, 2005 7:36 AM > > To: Shiba, Sidney; dpapadimitriou@psg.com > > Cc: Adrian Farrel; richard.rabbat@us.fujitsu.com; ccamp@ops.ietf.org > > Subject: RE: comments on=20 > draft-shiba-ccamp-gmpls-lambda-labels-00.txt > >=20 > > Sidney, > >=20 > > But there's nothing in your picture that requires an=20 > absolute end-end > > global wavelength. The existing GMPLS solution with relative > > wavelengths of local significance should work just fine. =20 > As I said in > > my previous note, your method precludes combining two or=20 > more parallel > > WDM links into a single TE link. > >=20 > > Thanks, > >=20 > > John > >=20 > > > -----Original Message----- > > > From: Shiba, Sidney [mailto:sidney.shiba@us.fujitsu.com] > > > Sent: Monday, October 31, 2005 7:25 AM > > > To: Drake, John E; dpapadimitriou@psg.com > > > Cc: Adrian Farrel; richard.rabbat@us.fujitsu.com;=20 > ccamp@ops.ietf.org > > > Subject: RE: comments on > draft-shiba-ccamp-gmpls-lambda-labels-00.txt > > > > > > Hi John, > > > > > > Optical switches based on Wavelength Selective Switch (WSS) > technology > > > requires the wavelength information for switching. This technology > is > > NOT > > > wavelength agnostic. > > > > > > | | > > > | wdm | wdm > > > |2 |2 > > > --------- --------- > > > wdm 1| optical |3 wdm 1| optical |3 wdm > > > --------| switch |------------| switch |--------- > > > | (WSS) | | (WSS) | > > > --------- --------- > > > |4 |4 > > > | wdm | wdm > > > | | > > > > > > Note that the figure above shows an example of two=20 > optical switches > > > interconnect > > > by a single WDM fiber. In this example, each optical switch can be > > connect > > > to 4 > > > other optical switches. > > > > > > As you can see, the optical ports information do not=20 > provide enough > > > information > > > for wavelength switching. > > > > > > Hope that clarifies the application requirement. > > > > > > Thanks, > > > > > > Sidney > > > > > > > -----Original Message----- > > > > From: Drake, John E [mailto:John.E.Drake2@boeing.com] > > > > Sent: Friday, October 28, 2005 5:33 PM > > > > To: dpapadimitriou@psg.com; Shiba, Sidney > > > > Cc: Adrian Farrel; richard.rabbat@us.fujitsu.com; > ccamp@ops.ietf.org > > > > Subject: RE: comments on > > draft-shiba-ccamp-gmpls-lambda-labels-00.txt > > > > > > > > > > > > Hi, > > > > > > > > Below is the text of an e-mail is sent to the Ethernet/GMPLS > mailing > > > > list. > > > > > > > > Upon reflection I am not sure using a real wavelength=20 > value makes > > much > > > > sense. Between a pair of adjacent nodes, there may be > > > > multiple pairs of > > > > switch ports in the same TE link that support a given frequency. > If > > a > > > > real wavelength value is used, how do the two nodes agree on > > > > which pair > > > > of switch ports to use? > > > > > > > > Furthermore, the amount of configuration is the same - you > > > > still need to > > > > configure the wavelength of each switch port. > > > > > > > > Thanks, > > > > > > > > John > > > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > =3D=3D=3D=3D > > > > Adrian, > > > > > > > > In the transparent photonic lambda switch case, the labels also > have > > > > only local significance. When an LSP is established, the input > > ports, > > > > as identified with local labels, are cross-connected to=20 > the output > > > > ports, as identified with local labels. > > > > > > > > There is just extra configuration to identify, using strictly > local > > > > identifiers, the wavelength associated with the all of the > switch's > > > > ports, and an additional CAC requirement that the wavelengths of > the > > > > input and output ports are the same. > > > > > > > > Thanks, > > > > > > > > John > > > > > > > > > > > > > -----Original Message----- > > > > > From: dimitri papadimitriou [mailto:dpapadimitriou@psg.com] > > > > > Sent: Thursday, October 27, 2005 10:03 AM > > > > > To: Shiba, Sidney > > > > > Cc: dimitri.papadimitriou@alcatel.be; Adrian Farrel; > > > > > richard.rabbat@us.fujitsu.com; ccamp@ops.ietf.org > > > > > Subject: Re: comments on > > > > draft-shiba-ccamp-gmpls-lambda-labels-00.txt > > > > > > > > > > shiba - see inline for some additional hints: > > > > > > > > > > >>Shiba, Sidney wrote: > > > > > >> > > > > > >>>Adrian, Dimitri, > > > > > >>> > > > > > >>>Thanks for reviewing these I-D. > > > > > >>> > > > > > >>>Wavelength continuity constraint does require the use of > > > > semanticful > > > > > >>>label whether it is spectral or index. > > > > > >> > > > > > >>=3D> see my reply to adrian on this specific point > > > > > >> > > > > > >>>I agree with Dimitri that the > > > > > >>>wavelength indexing requires document updating each time a > new > > > > > >>>spectrum is introduced. > > > > > >> > > > > > >>=3D> indeed and in addition it requires updating the already > > > > > >>signaled path > > > > > >> > > > > > >>>The use of spectral label provides self maintainance, i.e., > > > > > >>>no need to update any document and the use of the nominal > value > > > > > >>>provides a common semantic ground. > > > > > >> > > > > > >>=3D> what do you mean by self-maintenance - would you=20 > provide a > > > > > >>bit more detail > > > > > > > > > > > > [Sidney]What I've meant here was that it was not=20 > necessary to > > > > > > update any document when new wavelengths are inventoried. In > the > > > > > > case of indexing approach, it would require the > > > > wavelength indexing > > > > > > document to be updated with implementation impacts. > > > > > > > > > > > > In the case, the nominal value is used, there is no need for > > > > > > documentation update. > > > > > > > > > > ok - what you mean here is that you are going to make=20 > use of the > > > > already > > > > > defined C-Type 2 - what about the specific encoding of the > > > > value space > > > > ? > > > > > > > > > > >>=3D> now i have a more specific question before being = light-up > > > > > >>how do you know the frequency that you can support ? > > > > > > > > > > > > [Sidney] Some new technologies integrate optical switch and > > > > mux/demux > > > > > > capabilities, which allows the equipment to know=20 > the spectrum > it > > > > > supports. > > > > > > > > > > indeed - but the question is what does happen if the > > > > "detected" values > > > > > (during initialization) do not match the nominal values ? you > > don't > > > > > initialize then ? > > > > > > > > > > >>if these differ from the nominal values how are you going to > > deal > > > > with > > > > > these > > > > > >>discrepancies ? > > > > > > > > > > > > [Sidney] These new technologies uses the nominal value as > > > > reference. > > > > We > > > > > can say > > > > > > that a lightpath wavelength is identified by its nominal > value. > > If > > > > the > > > > > equipment > > > > > > is drifting from this nominal value, it is considered as > > > > a failure. > > > > > > > > > > ok - but if the deviation is such you have overlap - how the > > control > > > > > plane is going to be able to detect such failure ? > > > > > > > > > > >>this said i am not necessarily sure that having to > > > > maintain the data > > > > > plane > > > > > >>specifics as part of the control plane is really helping > > > > > >>operations (is this method not just duplicating=20 > complexity ?) > > > > > > > > > > > > [Sidney] The wavelength is WDM specific as much as the SUKLM > > label > > > > > encoding > > > > > > is for SONET. The wavelegth/frequency nominal value=20 > is used to > > > > identify > > > > > the > > > > > > facilities to cross-connect. > > > > > > > > > > there is an equivalence but there is also a major difference, > the > > > > > structure is invariant independently of the state of the > > > > network, with > > > > > spectral value space you may have labels that become=20 > unavailable > > due > > > > to > > > > > non-local usage of wavelength in the network > > > > > > > > > > hence, there is also no real coupling to the data plane more > than > > > > > knowing the type of interface and some generic capabilities > > > > > > > > > > >>>I'm not sure if the draft needs to be updated before the > > > > > >>>face-to-face meeting or after all comments are collected. > > Please > > > > > advise. > > > > > >> > > > > > >>=3D> suggest to keep discussion on - document update can be > > > > > >>performed at a later stage > > > > > > > > > > thanks, > > > > > - dimitri. > > > > > > > > > > >>>>-----Original Message----- > > > > > >>>>From: owner-ccamp@ops.ietf.org > > > > [mailto:owner-ccamp@ops.ietf.org]On > > > > > >>>>Behalf Of Adrian Farrel > > > > > >>>>Sent: Thursday, October 27, 2005 4:45 AM > > > > > >>>>To: dpapadimitriou@psg.com; > dimitri.papadimitriou@alcatel.be; > > > > > >>>>ccamp@ops.ietf.org > > > > > >>>>Subject: Re: comments on > > > > > >> > > > > > >>draft-shiba-ccamp-gmpls-lambda-labels-00.txt > > > > > >> > > > > > >>>> > > > > > >>>>Dimitri, > > > > > >>>> > > > > > >>>>Thanks for your work reviewing these recent I-Ds. It is > > > > > >>>>really valuable > > > > > >>>>and I'd welcome other people doing similar reviews. > > > > > >>>> > > > > > >>>> > > > > > >>>> > > > > > >>>>>there is a specific point to be clarified in=20 > this document: > > > > > >>>>> > > > > > >>>>>semanticless vs semanticful label (even here there is a > > > > distinction > > > > > >>>>>between spectral vs indexes i.e. using the wavelength > index) > > > > > >>>>> > > > > > >>>>>domain-wide vs link local significant label > > > > > >>>> > > > > > >>>>Without being too picky, I think all labels are=20 > semanticful > > > > > >>>>otherwise, we > > > > > >>>>would not know what resource they refered to. > > > > > >>>> > > > > > >>>>So the point reduces to whether the scope of the semantics > > > > > >>>>are link-local > > > > > >>>>or wider. > > > > > >>>> > > > > > >>>> > > > > > >>>> > > > > > >>>>>so, the comparison from this perspective with=20 > TDM labels is > > > > > >>>> > > > > > >>>>difficult to > > > > > >>>> > > > > > >>>> > > > > > >>>>>parse, the latter is semanticful but link local > > > > > >>>>> > > > > > >>>>>now, i don't specifically see what has changed the late > 90's, > > > > early > > > > > >>>>>y2k's, to have a change in the wavelength label=20 > definition; > > > > > >>>> > > > > > >>>>This is the question I would like to get to the bottom of. > In > > > > > >>>>other words: > > > > > >>>>do we need this function? > > > > > >>>> > > > > > >>>>It seems to me that the question being asked is this: > > > > > >>>> > > > > > >>>> If I want to compute a path that has some form of > wavelength > > > > > >>>> constraints, what information do I need access to? > > > > > >>>> > > > > > >>>>Another question might be: > > > > > >>>> > > > > > >>>> If I want to signal a path with wavelength constraints > what > > > > > >>>> information do I need to include in the=20 > signaling message? > > > > > >>>> > > > > > >>>> > > > > > >>>>I'd suggest that when we started on GMPLS, we were > > > > > >> > > > > > >>enthusiastic about > > > > > >> > > > > > >>>>transparent optical networks, but we were not properly > > > > > >>>>focusing wavelength > > > > > >>>>constraints because lambda-switching PXCs didn't take off. > > > > > >>>>Therefore we > > > > > >>>>didn't examine the requirements for wavelength constraints > in > > > > > >>>>routing and > > > > > >>>>signaling. The authors of this I-D are claiming=20 > new hardware > > > > > >>>>requirements > > > > > >>>>for the same function. > > > > > >>>> > > > > > >>>> > > > > > >>>> > > > > > >>>>>there are > > > > > >>>>>several solution possible > > > > > >>>>> > > > > > >>>>>- absolute values: the freq. of the wavelength: difficult > to > > > > adopt > > > > > >>>>>because referenced values are nominal and knowing all > > > > interactions > > > > > >>>>>between wavelengths this knowledge is at the end=20 > of little > > > > > >> > > > > > >>practical > > > > > >> > > > > > >>>>>usage; (introduces implicit ordering) > > > > > >>>>> > > > > > >>>>>- indexed values: the # of the wavelength: it does not > > > > > >> > > > > > >>provide for a > > > > > >> > > > > > >>>>>future proof label space for inst. in case new=20 > frequencies > > > > > >>>> > > > > > >>>>are inserted > > > > > >>>> > > > > > >>>> > > > > > >>>>>in the grid (introduces explicit ordering) > > > > > >>>>> > > > > > >>>>>- diff. values e.g. freq spacing starting from a=20 > reference > > > > > >>>> > > > > > >>>>value: pauses > > > > > >>>> > > > > > >>>> > > > > > >>>>>the question of the reference value and does suffer from > the > > > > former > > > > > >>>>>issue (introduces implicit ordering) > > > > > >>>>> > > > > > >>>>>- the solution available today - cumbersome in some > > > > control plane > > > > > >>>>>operations (e.g. label set translation) and not easy to > > > > > >>>> > > > > > >>>>troubleshoot but > > > > > >>>> > > > > > >>>> > > > > > >>>>>independent of any physical consideration=20 > (spectral), scale > > to > > > > any > > > > > >>>>>number of wavelength per fiber, does not introduce any > > > > > >> > > > > > >>ordering, the > > > > > >> > > > > > >>>>>most flexible (since allowing each system to maintain its > > > > specific > > > > > >>>>>control operations) and the less constraining since > > maintaining > > > > the > > > > > >>>>>control plane operations independent of any data plane > > > > specifics > > > > > >>>>> > > > > > >>>>> > > > > > >>>> > > > > > > >>>> > > > > >>> > > > > > >>>ambda-labels > > > > > >>>-00.txt> > > > > > >>> > > > > > >>>. > > > > > >>> > > > > > >> > > > > > > > > > > > > . > > > > > > > > > > >=20 Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 31 Oct 2005 15:57:32 +0000 To: IETF-Announce From: The IESG Subject: Last Call: 'Reoptimization of Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) loosely routed Label Switch Path (LSP)' to Informational RFC Reply-to: iesg@ietf.org CC: Message-Id: Date: Mon, 31 Oct 2005 10:57:19 -0500 The IESG has received a request from the Common Control and Measurement Plane WG to consider the following document: - 'Reoptimization of Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) loosely routed Label Switch Path (LSP) ' as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2005-11-25. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-ccamp-loose-path-reopt-01.txt Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 31 Oct 2005 15:56:08 +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: comments on draft-shiba-ccamp-gmpls-lambda-labels-00.txt Date: Mon, 31 Oct 2005 09:55:56 -0600 Message-ID: <7CA873794E52904EAA980A074B076779B17C61@rchemx01.fnc.net.local> Thread-Topic: comments on draft-shiba-ccamp-gmpls-lambda-labels-00.txt Thread-Index: AcXbIzcAFoI5B5TzS9O/zBGY1cMJbwA6iz0AAIdyNZAAAR14UAAAqdxA From: "Shiba, Sidney" To: "Drake, John E" , Cc: "Adrian Farrel" , , John, Comments inline: > -----Original Message----- > From: Drake, John E [mailto:John.E.Drake2@boeing.com] > Sent: Monday, October 31, 2005 9:36 AM > To: Shiba, Sidney; dpapadimitriou@psg.com > Cc: Adrian Farrel; richard.rabbat@us.fujitsu.com; ccamp@ops.ietf.org > Subject: RE: comments on draft-shiba-ccamp-gmpls-lambda-labels-00.txt >=20 >=20 > Sidney, >=20 > But there's nothing in your picture that requires an absolute end-end > global wavelength. The existing GMPLS solution with relative > wavelengths of local significance should work just fine. [Sidney] Sorry for the missing info. The optical switch is an all = optical switch (i.e., no OEO is necessary). The wavelength continuity constraint indicates which wavelength (nominal value) all the optical switches=20 traversed by the lightpath needs to cross-connect. > As I said in my previous note, your method precludes combining two or=20 > more parallel WDM links into a single TE link. [Sidney] Note the Label is complemented by the interface id of the link. I think this is the same approach used for parallel SONET OCn datalinks where the label identifies a time-slot and interface id identifies the datalink chosen for the connection. >=20 > Thanks, >=20 > John >=20 > > -----Original Message----- > > From: Shiba, Sidney [mailto:sidney.shiba@us.fujitsu.com] > > Sent: Monday, October 31, 2005 7:25 AM > > To: Drake, John E; dpapadimitriou@psg.com > > Cc: Adrian Farrel; richard.rabbat@us.fujitsu.com; ccamp@ops.ietf.org > > Subject: RE: comments on=20 > draft-shiba-ccamp-gmpls-lambda-labels-00.txt > >=20 > > Hi John, > >=20 > > Optical switches based on Wavelength Selective Switch (WSS)=20 > technology > > requires the wavelength information for switching. This=20 > technology is > NOT > > wavelength agnostic. > >=20 > > | | > > | wdm | wdm > > |2 |2 > > --------- --------- > > wdm 1| optical |3 wdm 1| optical |3 wdm > > --------| switch |------------| switch |--------- > > | (WSS) | | (WSS) | > > --------- --------- > > |4 |4 > > | wdm | wdm > > | | > >=20 > > Note that the figure above shows an example of two optical switches > > interconnect > > by a single WDM fiber. In this example, each optical switch can be > connect > > to 4 > > other optical switches. > >=20 > > As you can see, the optical ports information do not provide enough > > information > > for wavelength switching. > >=20 > > Hope that clarifies the application requirement. > >=20 > > Thanks, > >=20 > > Sidney > >=20 > > > -----Original Message----- > > > From: Drake, John E [mailto:John.E.Drake2@boeing.com] > > > Sent: Friday, October 28, 2005 5:33 PM > > > To: dpapadimitriou@psg.com; Shiba, Sidney > > > Cc: Adrian Farrel; richard.rabbat@us.fujitsu.com;=20 > ccamp@ops.ietf.org > > > Subject: RE: comments on > draft-shiba-ccamp-gmpls-lambda-labels-00.txt > > > > > > > > > Hi, > > > > > > Below is the text of an e-mail is sent to the=20 > Ethernet/GMPLS mailing > > > list. > > > > > > Upon reflection I am not sure using a real wavelength value makes > much > > > sense. Between a pair of adjacent nodes, there may be > > > multiple pairs of > > > switch ports in the same TE link that support a given=20 > frequency. If > a > > > real wavelength value is used, how do the two nodes agree on > > > which pair > > > of switch ports to use? > > > > > > Furthermore, the amount of configuration is the same - you > > > still need to > > > configure the wavelength of each switch port. > > > > > > Thanks, > > > > > > John > > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > =3D=3D=3D=3D > > > Adrian, > > > > > > In the transparent photonic lambda switch case, the=20 > labels also have > > > only local significance. When an LSP is established, the input > ports, > > > as identified with local labels, are cross-connected to the output > > > ports, as identified with local labels. > > > > > > There is just extra configuration to identify, using=20 > strictly local > > > identifiers, the wavelength associated with the all of=20 > the switch's > > > ports, and an additional CAC requirement that the=20 > wavelengths of the > > > input and output ports are the same. > > > > > > Thanks, > > > > > > John > > > > > > > > > > -----Original Message----- > > > > From: dimitri papadimitriou [mailto:dpapadimitriou@psg.com] > > > > Sent: Thursday, October 27, 2005 10:03 AM > > > > To: Shiba, Sidney > > > > Cc: dimitri.papadimitriou@alcatel.be; Adrian Farrel; > > > > richard.rabbat@us.fujitsu.com; ccamp@ops.ietf.org > > > > Subject: Re: comments on > > > draft-shiba-ccamp-gmpls-lambda-labels-00.txt > > > > > > > > shiba - see inline for some additional hints: > > > > > > > > >>Shiba, Sidney wrote: > > > > >> > > > > >>>Adrian, Dimitri, > > > > >>> > > > > >>>Thanks for reviewing these I-D. > > > > >>> > > > > >>>Wavelength continuity constraint does require the use of > > > semanticful > > > > >>>label whether it is spectral or index. > > > > >> > > > > >>=3D> see my reply to adrian on this specific point > > > > >> > > > > >>>I agree with Dimitri that the > > > > >>>wavelength indexing requires document updating each=20 > time a new > > > > >>>spectrum is introduced. > > > > >> > > > > >>=3D> indeed and in addition it requires updating the already > > > > >>signaled path > > > > >> > > > > >>>The use of spectral label provides self maintainance, i.e., > > > > >>>no need to update any document and the use of the=20 > nominal value > > > > >>>provides a common semantic ground. > > > > >> > > > > >>=3D> what do you mean by self-maintenance - would you provide = a > > > > >>bit more detail > > > > > > > > > > [Sidney]What I've meant here was that it was not necessary to > > > > > update any document when new wavelengths are=20 > inventoried. In the > > > > > case of indexing approach, it would require the > > > wavelength indexing > > > > > document to be updated with implementation impacts. > > > > > > > > > > In the case, the nominal value is used, there is no need for > > > > > documentation update. > > > > > > > > ok - what you mean here is that you are going to make use of the > > > already > > > > defined C-Type 2 - what about the specific encoding of the > > > value space > > > ? > > > > > > > > >>=3D> now i have a more specific question before being light-up > > > > >>how do you know the frequency that you can support ? > > > > > > > > > > [Sidney] Some new technologies integrate optical switch and > > > mux/demux > > > > > capabilities, which allows the equipment to know the=20 > spectrum it > > > > supports. > > > > > > > > indeed - but the question is what does happen if the > > > "detected" values > > > > (during initialization) do not match the nominal values ? you > don't > > > > initialize then ? > > > > > > > > >>if these differ from the nominal values how are you going to > deal > > > with > > > > these > > > > >>discrepancies ? > > > > > > > > > > [Sidney] These new technologies uses the nominal value as > > > reference. > > > We > > > > can say > > > > > that a lightpath wavelength is identified by its=20 > nominal value. > If > > > the > > > > equipment > > > > > is drifting from this nominal value, it is considered as > > > a failure. > > > > > > > > ok - but if the deviation is such you have overlap - how the > control > > > > plane is going to be able to detect such failure ? > > > > > > > > >>this said i am not necessarily sure that having to > > > maintain the data > > > > plane > > > > >>specifics as part of the control plane is really helping > > > > >>operations (is this method not just duplicating complexity ?) > > > > > > > > > > [Sidney] The wavelength is WDM specific as much as the SUKLM > label > > > > encoding > > > > > is for SONET. The wavelegth/frequency nominal value is used to > > > identify > > > > the > > > > > facilities to cross-connect. > > > > > > > > there is an equivalence but there is also a major=20 > difference, the > > > > structure is invariant independently of the state of the > > > network, with > > > > spectral value space you may have labels that become unavailable > due > > > to > > > > non-local usage of wavelength in the network > > > > > > > > hence, there is also no real coupling to the data plane=20 > more than > > > > knowing the type of interface and some generic capabilities > > > > > > > > >>>I'm not sure if the draft needs to be updated before the > > > > >>>face-to-face meeting or after all comments are collected. > Please > > > > advise. > > > > >> > > > > >>=3D> suggest to keep discussion on - document update can be > > > > >>performed at a later stage > > > > > > > > thanks, > > > > - dimitri. > > > > > > > > >>>>-----Original Message----- > > > > >>>>From: owner-ccamp@ops.ietf.org > > > [mailto:owner-ccamp@ops.ietf.org]On > > > > >>>>Behalf Of Adrian Farrel > > > > >>>>Sent: Thursday, October 27, 2005 4:45 AM > > > > >>>>To: dpapadimitriou@psg.com;=20 > dimitri.papadimitriou@alcatel.be; > > > > >>>>ccamp@ops.ietf.org > > > > >>>>Subject: Re: comments on > > > > >> > > > > >>draft-shiba-ccamp-gmpls-lambda-labels-00.txt > > > > >> > > > > >>>> > > > > >>>>Dimitri, > > > > >>>> > > > > >>>>Thanks for your work reviewing these recent I-Ds. It is > > > > >>>>really valuable > > > > >>>>and I'd welcome other people doing similar reviews. > > > > >>>> > > > > >>>> > > > > >>>> > > > > >>>>>there is a specific point to be clarified in this document: > > > > >>>>> > > > > >>>>>semanticless vs semanticful label (even here there is a > > > distinction > > > > >>>>>between spectral vs indexes i.e. using the=20 > wavelength index) > > > > >>>>> > > > > >>>>>domain-wide vs link local significant label > > > > >>>> > > > > >>>>Without being too picky, I think all labels are semanticful > > > > >>>>otherwise, we > > > > >>>>would not know what resource they refered to. > > > > >>>> > > > > >>>>So the point reduces to whether the scope of the semantics > > > > >>>>are link-local > > > > >>>>or wider. > > > > >>>> > > > > >>>> > > > > >>>> > > > > >>>>>so, the comparison from this perspective with TDM labels is > > > > >>>> > > > > >>>>difficult to > > > > >>>> > > > > >>>> > > > > >>>>>parse, the latter is semanticful but link local > > > > >>>>> > > > > >>>>>now, i don't specifically see what has changed the=20 > late 90's, > > > early > > > > >>>>>y2k's, to have a change in the wavelength label definition; > > > > >>>> > > > > >>>>This is the question I would like to get to the=20 > bottom of. In > > > > >>>>other words: > > > > >>>>do we need this function? > > > > >>>> > > > > >>>>It seems to me that the question being asked is this: > > > > >>>> > > > > >>>> If I want to compute a path that has some form of=20 > wavelength > > > > >>>> constraints, what information do I need access to? > > > > >>>> > > > > >>>>Another question might be: > > > > >>>> > > > > >>>> If I want to signal a path with wavelength=20 > constraints what > > > > >>>> information do I need to include in the signaling message? > > > > >>>> > > > > >>>> > > > > >>>>I'd suggest that when we started on GMPLS, we were > > > > >> > > > > >>enthusiastic about > > > > >> > > > > >>>>transparent optical networks, but we were not properly > > > > >>>>focusing wavelength > > > > >>>>constraints because lambda-switching PXCs didn't take off. > > > > >>>>Therefore we > > > > >>>>didn't examine the requirements for wavelength=20 > constraints in > > > > >>>>routing and > > > > >>>>signaling. The authors of this I-D are claiming new hardware > > > > >>>>requirements > > > > >>>>for the same function. > > > > >>>> > > > > >>>> > > > > >>>> > > > > >>>>>there are > > > > >>>>>several solution possible > > > > >>>>> > > > > >>>>>- absolute values: the freq. of the wavelength:=20 > difficult to > > > adopt > > > > >>>>>because referenced values are nominal and knowing all > > > interactions > > > > >>>>>between wavelengths this knowledge is at the end of little > > > > >> > > > > >>practical > > > > >> > > > > >>>>>usage; (introduces implicit ordering) > > > > >>>>> > > > > >>>>>- indexed values: the # of the wavelength: it does not > > > > >> > > > > >>provide for a > > > > >> > > > > >>>>>future proof label space for inst. in case new frequencies > > > > >>>> > > > > >>>>are inserted > > > > >>>> > > > > >>>> > > > > >>>>>in the grid (introduces explicit ordering) > > > > >>>>> > > > > >>>>>- diff. values e.g. freq spacing starting from a reference > > > > >>>> > > > > >>>>value: pauses > > > > >>>> > > > > >>>> > > > > >>>>>the question of the reference value and does=20 > suffer from the > > > former > > > > >>>>>issue (introduces implicit ordering) > > > > >>>>> > > > > >>>>>- the solution available today - cumbersome in some > > > control plane > > > > >>>>>operations (e.g. label set translation) and not easy to > > > > >>>> > > > > >>>>troubleshoot but > > > > >>>> > > > > >>>> > > > > >>>>>independent of any physical consideration (spectral), scale > to > > > any > > > > >>>>>number of wavelength per fiber, does not introduce any > > > > >> > > > > >>ordering, the > > > > >> > > > > >>>>>most flexible (since allowing each system to maintain its > > > specific > > > > >>>>>control operations) and the less constraining since > maintaining > > > the > > > > >>>>>control plane operations independent of any data plane > > > specifics > > > > >>>>> > > > > >>>>> > > > > >>>> > > > >=20 > >>>> > > > >>> > > > > >>>ambda-labels > > > > >>>-00.txt> > > > > >>> > > > > >>>. > > > > >>> > > > > >> > > > > > > > > > > . > > > > > > > > >=20 Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 31 Oct 2005 15:54:14 +0000 Message-ID: <011a01c5de33$4fc053f0$7a1810ac@movaz.com> From: "Igor Bryskin" To: , Cc: "Drake, John E" , "Zafar Ali (zali)" , "Igor Bryskin" , , , "Kim Young Hwa" , Subject: Re: Two Drafts for Resilience of Control Plane Date: Mon, 31 Oct 2005 10:54:00 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Dimitri, > igor - my two cents > > RSVP over time has progressively borrowed mechanisms from "hard-state" > protocols, explicit deletion using PathTear is most noticeable and > initial example of this evolution ! > > but in any case, RSVP still relies is on idem-potent soft-states that > are flushed when not refreshed after certain time interval (or self- > maintained if previously negotiated) this prevents orphans in the > network (so unused resources) and provides for resilience - hence there > is by no means a need to introduce an additional protocol mechanism to > trigger or not such event via the "control plane" - Refreshes are useful mechanism but only between neighbors that maintain Hello communication. In this case the absence of Path refreshes is as good indication that data plane must be destroyed as received PathTear message. However, when a controller does not receive Path refreshes from a neighbor it does not have any control plane communication with, it can assume neither a problem in the data plane nor intention to destroy it. Hence, as it was specified in RFC3471, it *must* maintain both control and data plane states throughout the failure. Igor > > btw, the paragraph you mention in RFC3471 does not say "soft state > protocols do not work well for non-packet environments" this is your > interpretation; > > ps: you are still free to make use of RFC3472 in case (as you were > apparently looking for something else ;-) > > Igor Bryskin wrote: > > John, > > > > > > > >>>States are supposed to be destroyed on explicit signalling > >>>message (e.g. PathTear or PathErr with the state removal > >>>flag), but not because of the absence of refreshes. > >>> > > > > [JD] > > > > Igor, > > > > Just to be clear, we are talking about RSVP here, and RSVP *is* a soft > > state protocol. Can you point to any RFC that supports your statements > > above? > > > > IB>> Oh, come on, John. You sound like you've been yourself in a dormant > > state for a while :=). We've gone a long way since RFC2205. In RFC3471, for > > example, there is a discussion why GMPLS is needed and how is it different > > from MPLS. One of the differences is the fact that soft state protocols do > > not work well for non-packet environments. Here is from the RDC3471: > > > > > > > > 9.2. Fault Handling There are two new faults that must be handled when > > the control channel is independent of the data channel. In the first, > > there is a link or other type of failure that limits the ability of > > neighboring nodes to pass control messages. In this situation, > > neighboring nodes are unable to exchange control messages for a period of > > time. Once communication is restored the underlying signaling protocol > > must indicate that the nodes have maintained their state through the > > failure.. > > > > What is more important is the reality of life: The customers simply say that > > you cannot destroy a user service (or even force any traffic hits) just > > because you have a problem in the control plane. If this does not fit your > > soft-state paradigm, than "harden" your protocols or flash them down the > > toilet and come with something else if you want our business. After all, if > > we provision the services via NMS, we do not have to destroy the services if > > we have problems in the management network. It is that simple. > > > > > > > > Igor > > > > > > > > > > > > > > > > . > > Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 31 Oct 2005 15:51:17 +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: comments on draft-shiba-ccamp-gmpls-lambda-labels-00.txt Date: Mon, 31 Oct 2005 07:50:51 -0800 Message-ID: <626FC7C6A97381468FB872072AB5DDC836971B@XCH-SW-42.sw.nos.boeing.com> Thread-Topic: comments on draft-shiba-ccamp-gmpls-lambda-labels-00.txt Thread-Index: AcXbIzcAFoI5B5TzS9O/zBGY1cMJbwA6iz0AAIdyNZAAAR14UAAAnn6w From: "Drake, John E" To: "Drake, John E" , "Shiba, Sidney" , Cc: "Adrian Farrel" , , Sidney, There's another issue as well. Having absolute end-end global wavelengths is probably insufficient to ensure that an end-end LSP can be established successfully, as having a common wavelength does not mean that equipment from different vendors will interoperate correctly in the data-plane. Thanks, John > -----Original Message----- > From: Drake, John E > Sent: Monday, October 31, 2005 7:36 AM > To: Shiba, Sidney; dpapadimitriou@psg.com > Cc: Adrian Farrel; richard.rabbat@us.fujitsu.com; ccamp@ops.ietf.org > Subject: RE: comments on draft-shiba-ccamp-gmpls-lambda-labels-00.txt >=20 > Sidney, >=20 > But there's nothing in your picture that requires an absolute end-end > global wavelength. The existing GMPLS solution with relative > wavelengths of local significance should work just fine. As I said in > my previous note, your method precludes combining two or more parallel > WDM links into a single TE link. >=20 > Thanks, >=20 > John >=20 > > -----Original Message----- > > From: Shiba, Sidney [mailto:sidney.shiba@us.fujitsu.com] > > Sent: Monday, October 31, 2005 7:25 AM > > To: Drake, John E; dpapadimitriou@psg.com > > Cc: Adrian Farrel; richard.rabbat@us.fujitsu.com; ccamp@ops.ietf.org > > Subject: RE: comments on draft-shiba-ccamp-gmpls-lambda-labels-00.txt > > > > Hi John, > > > > Optical switches based on Wavelength Selective Switch (WSS) technology > > requires the wavelength information for switching. This technology is > NOT > > wavelength agnostic. > > > > | | > > | wdm | wdm > > |2 |2 > > --------- --------- > > wdm 1| optical |3 wdm 1| optical |3 wdm > > --------| switch |------------| switch |--------- > > | (WSS) | | (WSS) | > > --------- --------- > > |4 |4 > > | wdm | wdm > > | | > > > > Note that the figure above shows an example of two optical switches > > interconnect > > by a single WDM fiber. In this example, each optical switch can be > connect > > to 4 > > other optical switches. > > > > As you can see, the optical ports information do not provide enough > > information > > for wavelength switching. > > > > Hope that clarifies the application requirement. > > > > Thanks, > > > > Sidney > > > > > -----Original Message----- > > > From: Drake, John E [mailto:John.E.Drake2@boeing.com] > > > Sent: Friday, October 28, 2005 5:33 PM > > > To: dpapadimitriou@psg.com; Shiba, Sidney > > > Cc: Adrian Farrel; richard.rabbat@us.fujitsu.com; ccamp@ops.ietf.org > > > Subject: RE: comments on > draft-shiba-ccamp-gmpls-lambda-labels-00.txt > > > > > > > > > Hi, > > > > > > Below is the text of an e-mail is sent to the Ethernet/GMPLS mailing > > > list. > > > > > > Upon reflection I am not sure using a real wavelength value makes > much > > > sense. Between a pair of adjacent nodes, there may be > > > multiple pairs of > > > switch ports in the same TE link that support a given frequency. If > a > > > real wavelength value is used, how do the two nodes agree on > > > which pair > > > of switch ports to use? > > > > > > Furthermore, the amount of configuration is the same - you > > > still need to > > > configure the wavelength of each switch port. > > > > > > Thanks, > > > > > > John > > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > =3D=3D=3D=3D > > > Adrian, > > > > > > In the transparent photonic lambda switch case, the labels also have > > > only local significance. When an LSP is established, the input > ports, > > > as identified with local labels, are cross-connected to the output > > > ports, as identified with local labels. > > > > > > There is just extra configuration to identify, using strictly local > > > identifiers, the wavelength associated with the all of the switch's > > > ports, and an additional CAC requirement that the wavelengths of the > > > input and output ports are the same. > > > > > > Thanks, > > > > > > John > > > > > > > > > > -----Original Message----- > > > > From: dimitri papadimitriou [mailto:dpapadimitriou@psg.com] > > > > Sent: Thursday, October 27, 2005 10:03 AM > > > > To: Shiba, Sidney > > > > Cc: dimitri.papadimitriou@alcatel.be; Adrian Farrel; > > > > richard.rabbat@us.fujitsu.com; ccamp@ops.ietf.org > > > > Subject: Re: comments on > > > draft-shiba-ccamp-gmpls-lambda-labels-00.txt > > > > > > > > shiba - see inline for some additional hints: > > > > > > > > >>Shiba, Sidney wrote: > > > > >> > > > > >>>Adrian, Dimitri, > > > > >>> > > > > >>>Thanks for reviewing these I-D. > > > > >>> > > > > >>>Wavelength continuity constraint does require the use of > > > semanticful > > > > >>>label whether it is spectral or index. > > > > >> > > > > >>=3D> see my reply to adrian on this specific point > > > > >> > > > > >>>I agree with Dimitri that the > > > > >>>wavelength indexing requires document updating each time a new > > > > >>>spectrum is introduced. > > > > >> > > > > >>=3D> indeed and in addition it requires updating the already > > > > >>signaled path > > > > >> > > > > >>>The use of spectral label provides self maintainance, i.e., > > > > >>>no need to update any document and the use of the nominal value > > > > >>>provides a common semantic ground. > > > > >> > > > > >>=3D> what do you mean by self-maintenance - would you provide = a > > > > >>bit more detail > > > > > > > > > > [Sidney]What I've meant here was that it was not necessary to > > > > > update any document when new wavelengths are inventoried. In the > > > > > case of indexing approach, it would require the > > > wavelength indexing > > > > > document to be updated with implementation impacts. > > > > > > > > > > In the case, the nominal value is used, there is no need for > > > > > documentation update. > > > > > > > > ok - what you mean here is that you are going to make use of the > > > already > > > > defined C-Type 2 - what about the specific encoding of the > > > value space > > > ? > > > > > > > > >>=3D> now i have a more specific question before being light-up > > > > >>how do you know the frequency that you can support ? > > > > > > > > > > [Sidney] Some new technologies integrate optical switch and > > > mux/demux > > > > > capabilities, which allows the equipment to know the spectrum it > > > > supports. > > > > > > > > indeed - but the question is what does happen if the > > > "detected" values > > > > (during initialization) do not match the nominal values ? you > don't > > > > initialize then ? > > > > > > > > >>if these differ from the nominal values how are you going to > deal > > > with > > > > these > > > > >>discrepancies ? > > > > > > > > > > [Sidney] These new technologies uses the nominal value as > > > reference. > > > We > > > > can say > > > > > that a lightpath wavelength is identified by its nominal value. > If > > > the > > > > equipment > > > > > is drifting from this nominal value, it is considered as > > > a failure. > > > > > > > > ok - but if the deviation is such you have overlap - how the > control > > > > plane is going to be able to detect such failure ? > > > > > > > > >>this said i am not necessarily sure that having to > > > maintain the data > > > > plane > > > > >>specifics as part of the control plane is really helping > > > > >>operations (is this method not just duplicating complexity ?) > > > > > > > > > > [Sidney] The wavelength is WDM specific as much as the SUKLM > label > > > > encoding > > > > > is for SONET. The wavelegth/frequency nominal value is used to > > > identify > > > > the > > > > > facilities to cross-connect. > > > > > > > > there is an equivalence but there is also a major difference, the > > > > structure is invariant independently of the state of the > > > network, with > > > > spectral value space you may have labels that become unavailable > due > > > to > > > > non-local usage of wavelength in the network > > > > > > > > hence, there is also no real coupling to the data plane more than > > > > knowing the type of interface and some generic capabilities > > > > > > > > >>>I'm not sure if the draft needs to be updated before the > > > > >>>face-to-face meeting or after all comments are collected. > Please > > > > advise. > > > > >> > > > > >>=3D> suggest to keep discussion on - document update can be > > > > >>performed at a later stage > > > > > > > > thanks, > > > > - dimitri. > > > > > > > > >>>>-----Original Message----- > > > > >>>>From: owner-ccamp@ops.ietf.org > > > [mailto:owner-ccamp@ops.ietf.org]On > > > > >>>>Behalf Of Adrian Farrel > > > > >>>>Sent: Thursday, October 27, 2005 4:45 AM > > > > >>>>To: dpapadimitriou@psg.com; dimitri.papadimitriou@alcatel.be; > > > > >>>>ccamp@ops.ietf.org > > > > >>>>Subject: Re: comments on > > > > >> > > > > >>draft-shiba-ccamp-gmpls-lambda-labels-00.txt > > > > >> > > > > >>>> > > > > >>>>Dimitri, > > > > >>>> > > > > >>>>Thanks for your work reviewing these recent I-Ds. It is > > > > >>>>really valuable > > > > >>>>and I'd welcome other people doing similar reviews. > > > > >>>> > > > > >>>> > > > > >>>> > > > > >>>>>there is a specific point to be clarified in this document: > > > > >>>>> > > > > >>>>>semanticless vs semanticful label (even here there is a > > > distinction > > > > >>>>>between spectral vs indexes i.e. using the wavelength index) > > > > >>>>> > > > > >>>>>domain-wide vs link local significant label > > > > >>>> > > > > >>>>Without being too picky, I think all labels are semanticful > > > > >>>>otherwise, we > > > > >>>>would not know what resource they refered to. > > > > >>>> > > > > >>>>So the point reduces to whether the scope of the semantics > > > > >>>>are link-local > > > > >>>>or wider. > > > > >>>> > > > > >>>> > > > > >>>> > > > > >>>>>so, the comparison from this perspective with TDM labels is > > > > >>>> > > > > >>>>difficult to > > > > >>>> > > > > >>>> > > > > >>>>>parse, the latter is semanticful but link local > > > > >>>>> > > > > >>>>>now, i don't specifically see what has changed the late 90's, > > > early > > > > >>>>>y2k's, to have a change in the wavelength label definition; > > > > >>>> > > > > >>>>This is the question I would like to get to the bottom of. In > > > > >>>>other words: > > > > >>>>do we need this function? > > > > >>>> > > > > >>>>It seems to me that the question being asked is this: > > > > >>>> > > > > >>>> If I want to compute a path that has some form of wavelength > > > > >>>> constraints, what information do I need access to? > > > > >>>> > > > > >>>>Another question might be: > > > > >>>> > > > > >>>> If I want to signal a path with wavelength constraints what > > > > >>>> information do I need to include in the signaling message? > > > > >>>> > > > > >>>> > > > > >>>>I'd suggest that when we started on GMPLS, we were > > > > >> > > > > >>enthusiastic about > > > > >> > > > > >>>>transparent optical networks, but we were not properly > > > > >>>>focusing wavelength > > > > >>>>constraints because lambda-switching PXCs didn't take off. > > > > >>>>Therefore we > > > > >>>>didn't examine the requirements for wavelength constraints in > > > > >>>>routing and > > > > >>>>signaling. The authors of this I-D are claiming new hardware > > > > >>>>requirements > > > > >>>>for the same function. > > > > >>>> > > > > >>>> > > > > >>>> > > > > >>>>>there are > > > > >>>>>several solution possible > > > > >>>>> > > > > >>>>>- absolute values: the freq. of the wavelength: difficult to > > > adopt > > > > >>>>>because referenced values are nominal and knowing all > > > interactions > > > > >>>>>between wavelengths this knowledge is at the end of little > > > > >> > > > > >>practical > > > > >> > > > > >>>>>usage; (introduces implicit ordering) > > > > >>>>> > > > > >>>>>- indexed values: the # of the wavelength: it does not > > > > >> > > > > >>provide for a > > > > >> > > > > >>>>>future proof label space for inst. in case new frequencies > > > > >>>> > > > > >>>>are inserted > > > > >>>> > > > > >>>> > > > > >>>>>in the grid (introduces explicit ordering) > > > > >>>>> > > > > >>>>>- diff. values e.g. freq spacing starting from a reference > > > > >>>> > > > > >>>>value: pauses > > > > >>>> > > > > >>>> > > > > >>>>>the question of the reference value and does suffer from the > > > former > > > > >>>>>issue (introduces implicit ordering) > > > > >>>>> > > > > >>>>>- the solution available today - cumbersome in some > > > control plane > > > > >>>>>operations (e.g. label set translation) and not easy to > > > > >>>> > > > > >>>>troubleshoot but > > > > >>>> > > > > >>>> > > > > >>>>>independent of any physical consideration (spectral), scale > to > > > any > > > > >>>>>number of wavelength per fiber, does not introduce any > > > > >> > > > > >>ordering, the > > > > >> > > > > >>>>>most flexible (since allowing each system to maintain its > > > specific > > > > >>>>>control operations) and the less constraining since > maintaining > > > the > > > > >>>>>control plane operations independent of any data plane > > > specifics > > > > >>>>> > > > > >>>>> > > > > >>>> > > > > >>>> > > > >>> > > > > >>>ambda-labels > > > > >>>-00.txt> > > > > >>> > > > > >>>. > > > > >>> > > > > >> > > > > > > > > > > . > > > > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 31 Oct 2005 15:43:26 +0000 Message-ID: <010f01c5de31$b81c18a0$7a1810ac@movaz.com> From: "Igor Bryskin" To: "Drake, John E" , , , Cc: , , , , Subject: Re: Two Drafts for Resilience of Control Plane Date: Mon, 31 Oct 2005 10:42:36 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit John, > This discussion is about resilience of control plane and whether some > standardized solutions (and hence additional work in CCAMP) is needed. [JD] We're still waiting for you to describe what you think is needed. All you do is continue to assert that additional work is needed. No John, This is not true, I gave you a very specific problem - provide mechanisms to manage LSPs with impaired control plane (when one or more controllers are out of service). You said that this is not a problem, because RSVP is a soft state protocol and once there are no refreshes the control data plane states must be destroyed and hence there is nothing to manage. And I tried very hard to explain you why this is not acceptable and hence must be addressed. I have a solution and am planning to write a draft. I'd like this work to live in CCAMP. Igor > So > I > disagree with you when you say that the discussion has nothing to do with > NMS, because one can evaluate the resilience only compared with one of > some > alternative way of service provisioning and management. I personally do > not > see any technical reason why managing services via control plane should be > less resilient than doing so via management plane. [JD] As I said in my note, I don't consider the two to be competing. > However, to achieve > this > some additional work is required. [JD] Argument by emphatic repetition? > > > > Igor > > ----- Original Message ----- > From: "Drake, John E" > To: ; ; ; > > Cc: ; ; > ; ; > > Sent: Monday, October 31, 2005 9:40 AM > Subject: RE: Two Drafts for Resilience of Control Plane > > > Neil, > > I don't think the discussion, at least from my perspective, has anything > to do with the NMS, other than this strange assertion that the NMS will > always be able to reach every node in the network even if there is a > control plane failure. > > I have always considered the control plane to be a component in a larger > system that also includes the NMS, etc. > > Thanks, > > John > > > -----Original Message----- > > From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com] > > Sent: Monday, October 31, 2005 6:32 AM > > To: ibryskin@movaz.com; Drake, John E; zali@cisco.com; > i_bryskin@yahoo.com > > Cc: drake@movaz.com; dpapadimitriou@psg.com; > > dimitri.papadimitriou@alcatel.be; yhwkim@etri.re.kr; > ccamp@ops.ietf.org > > Subject: RE: Two Drafts for Resilience of Control Plane > > > > Igor....if it's any comfort to you, folks here in BT agree with you. > > And I don't care what anyone says about the NMS and the futile > attempts > > to obsolete it....we will always need this for a whole raft of > > functions/reasons....and the closer one gets to the duct the more > > important it becomes and the less important a control-plane becomes > (at > > least dynamic routing aspects). > > > > regards, Neil > > > > > -----Original Message----- > > > From: owner-ccamp@ops.ietf.org > > > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Igor Bryskin > > > Sent: 31 October 2005 14:10 > > > To: Drake, John E; Zafar Ali (zali); Igor Bryskin > > > Cc: drake@movaz.com; dpapadimitriou@psg.com; > > > dimitri.papadimitriou@alcatel.be; Kim Young Hwa; ccamp@ops.ietf.org > > > Subject: Re: Two Drafts for Resilience of Control Plane > > > > > > > > > John, > > > > > > > > > > > > > > > > > > > > > > States are supposed to be destroyed on explicit > > > signalling message > > > > > (e.g. PathTear or PathErr with the state removal flag), but not > > > > > because of the absence of refreshes. > > > > > > > > [JD] > > > > > > Igor, > > > > > > Just to be clear, we are talking about RSVP here, and RSVP > > > *is* a soft state protocol. Can you point to any RFC that > > > supports your statements above? > > > > > > IB>> Oh, come on, John. You sound like you've been yourself > > > in a dormant > > > state for a while :=). We've gone a long way since RFC2205. > > > In RFC3471, for example, there is a discussion why GMPLS is > > > needed and how is it different from MPLS. One of the > > > differences is the fact that soft state protocols do not work > > > well for non-packet environments. Here is from the RDC3471: > > > > > > > > > > > > 9.2. Fault Handling There are two new faults that must be > > > handled when > > > the control channel is independent of the data channel. In > > > the first, > > > there is a link or other type of failure that limits the ability > of > > > neighboring nodes to pass control messages. In this situation, > > > neighboring nodes are unable to exchange control messages > > > for a period of > > > time. Once communication is restored the underlying > > > signaling protocol > > > must indicate that the nodes have maintained their state through > the > > > failure.. > > > > > > What is more important is the reality of life: The customers > > > simply say that you cannot destroy a user service (or even > > > force any traffic hits) just because you have a problem in > > > the control plane. If this does not fit your soft-state > > > paradigm, than "harden" your protocols or flash them down the > > > toilet and come with something else if you want our business. > > > After all, if we provision the services via NMS, we do not > > > have to destroy the services if we have problems in the > > > management network. It is that simple. > > > > > > > > > > > > Igor > > > > > > > > > > > > > > > > > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 31 Oct 2005 15:36:03 +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: comments on draft-shiba-ccamp-gmpls-lambda-labels-00.txt Date: Mon, 31 Oct 2005 07:35:55 -0800 Message-ID: <626FC7C6A97381468FB872072AB5DDC836971A@XCH-SW-42.sw.nos.boeing.com> Thread-Topic: comments on draft-shiba-ccamp-gmpls-lambda-labels-00.txt Thread-Index: AcXbIzcAFoI5B5TzS9O/zBGY1cMJbwA6iz0AAIdyNZAAAR14UA== From: "Drake, John E" To: "Shiba, Sidney" , Cc: "Adrian Farrel" , , Sidney, But there's nothing in your picture that requires an absolute end-end global wavelength. The existing GMPLS solution with relative wavelengths of local significance should work just fine. As I said in my previous note, your method precludes combining two or more parallel WDM links into a single TE link. Thanks, John > -----Original Message----- > From: Shiba, Sidney [mailto:sidney.shiba@us.fujitsu.com] > Sent: Monday, October 31, 2005 7:25 AM > To: Drake, John E; dpapadimitriou@psg.com > Cc: Adrian Farrel; richard.rabbat@us.fujitsu.com; ccamp@ops.ietf.org > Subject: RE: comments on draft-shiba-ccamp-gmpls-lambda-labels-00.txt >=20 > Hi John, >=20 > Optical switches based on Wavelength Selective Switch (WSS) technology > requires the wavelength information for switching. This technology is NOT > wavelength agnostic. >=20 > | | > | wdm | wdm > |2 |2 > --------- --------- > wdm 1| optical |3 wdm 1| optical |3 wdm > --------| switch |------------| switch |--------- > | (WSS) | | (WSS) | > --------- --------- > |4 |4 > | wdm | wdm > | | >=20 > Note that the figure above shows an example of two optical switches > interconnect > by a single WDM fiber. In this example, each optical switch can be connect > to 4 > other optical switches. >=20 > As you can see, the optical ports information do not provide enough > information > for wavelength switching. >=20 > Hope that clarifies the application requirement. >=20 > Thanks, >=20 > Sidney >=20 > > -----Original Message----- > > From: Drake, John E [mailto:John.E.Drake2@boeing.com] > > Sent: Friday, October 28, 2005 5:33 PM > > To: dpapadimitriou@psg.com; Shiba, Sidney > > Cc: Adrian Farrel; richard.rabbat@us.fujitsu.com; ccamp@ops.ietf.org > > Subject: RE: comments on draft-shiba-ccamp-gmpls-lambda-labels-00.txt > > > > > > Hi, > > > > Below is the text of an e-mail is sent to the Ethernet/GMPLS mailing > > list. > > > > Upon reflection I am not sure using a real wavelength value makes much > > sense. Between a pair of adjacent nodes, there may be > > multiple pairs of > > switch ports in the same TE link that support a given frequency. If a > > real wavelength value is used, how do the two nodes agree on > > which pair > > of switch ports to use? > > > > Furthermore, the amount of configuration is the same - you > > still need to > > configure the wavelength of each switch port. > > > > Thanks, > > > > John > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > =3D=3D=3D=3D > > Adrian, > > > > In the transparent photonic lambda switch case, the labels also have > > only local significance. When an LSP is established, the input ports, > > as identified with local labels, are cross-connected to the output > > ports, as identified with local labels. > > > > There is just extra configuration to identify, using strictly local > > identifiers, the wavelength associated with the all of the switch's > > ports, and an additional CAC requirement that the wavelengths of the > > input and output ports are the same. > > > > Thanks, > > > > John > > > > > > > -----Original Message----- > > > From: dimitri papadimitriou [mailto:dpapadimitriou@psg.com] > > > Sent: Thursday, October 27, 2005 10:03 AM > > > To: Shiba, Sidney > > > Cc: dimitri.papadimitriou@alcatel.be; Adrian Farrel; > > > richard.rabbat@us.fujitsu.com; ccamp@ops.ietf.org > > > Subject: Re: comments on > > draft-shiba-ccamp-gmpls-lambda-labels-00.txt > > > > > > shiba - see inline for some additional hints: > > > > > > >>Shiba, Sidney wrote: > > > >> > > > >>>Adrian, Dimitri, > > > >>> > > > >>>Thanks for reviewing these I-D. > > > >>> > > > >>>Wavelength continuity constraint does require the use of > > semanticful > > > >>>label whether it is spectral or index. > > > >> > > > >>=3D> see my reply to adrian on this specific point > > > >> > > > >>>I agree with Dimitri that the > > > >>>wavelength indexing requires document updating each time a new > > > >>>spectrum is introduced. > > > >> > > > >>=3D> indeed and in addition it requires updating the already > > > >>signaled path > > > >> > > > >>>The use of spectral label provides self maintainance, i.e., > > > >>>no need to update any document and the use of the nominal value > > > >>>provides a common semantic ground. > > > >> > > > >>=3D> what do you mean by self-maintenance - would you provide a > > > >>bit more detail > > > > > > > > [Sidney]What I've meant here was that it was not necessary to > > > > update any document when new wavelengths are inventoried. In the > > > > case of indexing approach, it would require the > > wavelength indexing > > > > document to be updated with implementation impacts. > > > > > > > > In the case, the nominal value is used, there is no need for > > > > documentation update. > > > > > > ok - what you mean here is that you are going to make use of the > > already > > > defined C-Type 2 - what about the specific encoding of the > > value space > > ? > > > > > > >>=3D> now i have a more specific question before being light-up > > > >>how do you know the frequency that you can support ? > > > > > > > > [Sidney] Some new technologies integrate optical switch and > > mux/demux > > > > capabilities, which allows the equipment to know the spectrum it > > > supports. > > > > > > indeed - but the question is what does happen if the > > "detected" values > > > (during initialization) do not match the nominal values ? you don't > > > initialize then ? > > > > > > >>if these differ from the nominal values how are you going to deal > > with > > > these > > > >>discrepancies ? > > > > > > > > [Sidney] These new technologies uses the nominal value as > > reference. > > We > > > can say > > > > that a lightpath wavelength is identified by its nominal value. If > > the > > > equipment > > > > is drifting from this nominal value, it is considered as > > a failure. > > > > > > ok - but if the deviation is such you have overlap - how the control > > > plane is going to be able to detect such failure ? > > > > > > >>this said i am not necessarily sure that having to > > maintain the data > > > plane > > > >>specifics as part of the control plane is really helping > > > >>operations (is this method not just duplicating complexity ?) > > > > > > > > [Sidney] The wavelength is WDM specific as much as the SUKLM label > > > encoding > > > > is for SONET. The wavelegth/frequency nominal value is used to > > identify > > > the > > > > facilities to cross-connect. > > > > > > there is an equivalence but there is also a major difference, the > > > structure is invariant independently of the state of the > > network, with > > > spectral value space you may have labels that become unavailable due > > to > > > non-local usage of wavelength in the network > > > > > > hence, there is also no real coupling to the data plane more than > > > knowing the type of interface and some generic capabilities > > > > > > >>>I'm not sure if the draft needs to be updated before the > > > >>>face-to-face meeting or after all comments are collected. Please > > > advise. > > > >> > > > >>=3D> suggest to keep discussion on - document update can be > > > >>performed at a later stage > > > > > > thanks, > > > - dimitri. > > > > > > >>>>-----Original Message----- > > > >>>>From: owner-ccamp@ops.ietf.org > > [mailto:owner-ccamp@ops.ietf.org]On > > > >>>>Behalf Of Adrian Farrel > > > >>>>Sent: Thursday, October 27, 2005 4:45 AM > > > >>>>To: dpapadimitriou@psg.com; dimitri.papadimitriou@alcatel.be; > > > >>>>ccamp@ops.ietf.org > > > >>>>Subject: Re: comments on > > > >> > > > >>draft-shiba-ccamp-gmpls-lambda-labels-00.txt > > > >> > > > >>>> > > > >>>>Dimitri, > > > >>>> > > > >>>>Thanks for your work reviewing these recent I-Ds. It is > > > >>>>really valuable > > > >>>>and I'd welcome other people doing similar reviews. > > > >>>> > > > >>>> > > > >>>> > > > >>>>>there is a specific point to be clarified in this document: > > > >>>>> > > > >>>>>semanticless vs semanticful label (even here there is a > > distinction > > > >>>>>between spectral vs indexes i.e. using the wavelength index) > > > >>>>> > > > >>>>>domain-wide vs link local significant label > > > >>>> > > > >>>>Without being too picky, I think all labels are semanticful > > > >>>>otherwise, we > > > >>>>would not know what resource they refered to. > > > >>>> > > > >>>>So the point reduces to whether the scope of the semantics > > > >>>>are link-local > > > >>>>or wider. > > > >>>> > > > >>>> > > > >>>> > > > >>>>>so, the comparison from this perspective with TDM labels is > > > >>>> > > > >>>>difficult to > > > >>>> > > > >>>> > > > >>>>>parse, the latter is semanticful but link local > > > >>>>> > > > >>>>>now, i don't specifically see what has changed the late 90's, > > early > > > >>>>>y2k's, to have a change in the wavelength label definition; > > > >>>> > > > >>>>This is the question I would like to get to the bottom of. In > > > >>>>other words: > > > >>>>do we need this function? > > > >>>> > > > >>>>It seems to me that the question being asked is this: > > > >>>> > > > >>>> If I want to compute a path that has some form of wavelength > > > >>>> constraints, what information do I need access to? > > > >>>> > > > >>>>Another question might be: > > > >>>> > > > >>>> If I want to signal a path with wavelength constraints what > > > >>>> information do I need to include in the signaling message? > > > >>>> > > > >>>> > > > >>>>I'd suggest that when we started on GMPLS, we were > > > >> > > > >>enthusiastic about > > > >> > > > >>>>transparent optical networks, but we were not properly > > > >>>>focusing wavelength > > > >>>>constraints because lambda-switching PXCs didn't take off. > > > >>>>Therefore we > > > >>>>didn't examine the requirements for wavelength constraints in > > > >>>>routing and > > > >>>>signaling. The authors of this I-D are claiming new hardware > > > >>>>requirements > > > >>>>for the same function. > > > >>>> > > > >>>> > > > >>>> > > > >>>>>there are > > > >>>>>several solution possible > > > >>>>> > > > >>>>>- absolute values: the freq. of the wavelength: difficult to > > adopt > > > >>>>>because referenced values are nominal and knowing all > > interactions > > > >>>>>between wavelengths this knowledge is at the end of little > > > >> > > > >>practical > > > >> > > > >>>>>usage; (introduces implicit ordering) > > > >>>>> > > > >>>>>- indexed values: the # of the wavelength: it does not > > > >> > > > >>provide for a > > > >> > > > >>>>>future proof label space for inst. in case new frequencies > > > >>>> > > > >>>>are inserted > > > >>>> > > > >>>> > > > >>>>>in the grid (introduces explicit ordering) > > > >>>>> > > > >>>>>- diff. values e.g. freq spacing starting from a reference > > > >>>> > > > >>>>value: pauses > > > >>>> > > > >>>> > > > >>>>>the question of the reference value and does suffer from the > > former > > > >>>>>issue (introduces implicit ordering) > > > >>>>> > > > >>>>>- the solution available today - cumbersome in some > > control plane > > > >>>>>operations (e.g. label set translation) and not easy to > > > >>>> > > > >>>>troubleshoot but > > > >>>> > > > >>>> > > > >>>>>independent of any physical consideration (spectral), scale to > > any > > > >>>>>number of wavelength per fiber, does not introduce any > > > >> > > > >>ordering, the > > > >> > > > >>>>>most flexible (since allowing each system to maintain its > > specific > > > >>>>>control operations) and the less constraining since maintaining > > the > > > >>>>>control plane operations independent of any data plane > > specifics > > > >>>>> > > > >>>>> > > > >>>> > > > >>>> > > >>> > > > >>>ambda-labels > > > >>>-00.txt> > > > >>> > > > >>>. > > > >>> > > > >> > > > > > > > > . > > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 31 Oct 2005 15:35:41 +0000 Message-ID: <436639BA.6040405@psg.com> Date: Mon, 31 Oct 2005 16:35:22 +0100 From: dimitri papadimitriou Reply-To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.11) Gecko/20050728 MIME-Version: 1.0 To: Igor Bryskin CC: "Drake, John E" , "Zafar Ali (zali)" , Igor Bryskin , drake@movaz.com, dimitri.papadimitriou@alcatel.be, Kim Young Hwa , ccamp@ops.ietf.org Subject: Re: Two Drafts for Resilience of Control Plane Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit igor - my two cents RSVP over time has progressively borrowed mechanisms from "hard-state" protocols, explicit deletion using PathTear is most noticeable and initial example of this evolution ! but in any case, RSVP still relies is on idem-potent soft-states that are flushed when not refreshed after certain time interval (or self- maintained if previously negotiated) this prevents orphans in the network (so unused resources) and provides for resilience - hence there is by no means a need to introduce an additional protocol mechanism to trigger or not such event via the "control plane" - btw, the paragraph you mention in RFC3471 does not say "soft state protocols do not work well for non-packet environments" this is your interpretation; ps: you are still free to make use of RFC3472 in case (as you were apparently looking for something else ;-) Igor Bryskin wrote: > John, > > > >>>States are supposed to be destroyed on explicit signalling >>>message (e.g. PathTear or PathErr with the state removal >>>flag), but not because of the absence of refreshes. >>> > > [JD] > > Igor, > > Just to be clear, we are talking about RSVP here, and RSVP *is* a soft > state protocol. Can you point to any RFC that supports your statements > above? > > IB>> Oh, come on, John. You sound like you've been yourself in a dormant > state for a while :=). We've gone a long way since RFC2205. In RFC3471, for > example, there is a discussion why GMPLS is needed and how is it different > from MPLS. One of the differences is the fact that soft state protocols do > not work well for non-packet environments. Here is from the RDC3471: > > > > 9.2. Fault Handling There are two new faults that must be handled when > the control channel is independent of the data channel. In the first, > there is a link or other type of failure that limits the ability of > neighboring nodes to pass control messages. In this situation, > neighboring nodes are unable to exchange control messages for a period of > time. Once communication is restored the underlying signaling protocol > must indicate that the nodes have maintained their state through the > failure.. > > What is more important is the reality of life: The customers simply say that > you cannot destroy a user service (or even force any traffic hits) just > because you have a problem in the control plane. If this does not fit your > soft-state paradigm, than "harden" your protocols or flash them down the > toilet and come with something else if you want our business. After all, if > we provision the services via NMS, we do not have to destroy the services if > we have problems in the management network. It is that simple. > > > > Igor > > > > > > > > . > Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 31 Oct 2005 15:27:21 +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: Two Drafts for Resilience of Control Plane Date: Mon, 31 Oct 2005 07:26:06 -0800 Message-ID: <626FC7C6A97381468FB872072AB5DDC8369719@XCH-SW-42.sw.nos.boeing.com> Thread-Topic: Two Drafts for Resilience of Control Plane Thread-Index: AcXeLmdrIZ1O83J1RPiWLi4DL8kinwAAHLKg From: "Drake, John E" To: "Igor Bryskin" , , , Cc: , , , , > -----Original Message----- > From: Igor Bryskin [mailto:ibryskin@movaz.com] > Sent: Monday, October 31, 2005 7:19 AM > To: Drake, John E; neil.2.harrison@bt.com; zali@cisco.com; > i_bryskin@yahoo.com > Cc: drake@movaz.com; dpapadimitriou@psg.com; > dimitri.papadimitriou@alcatel.be; yhwkim@etri.re.kr; ccamp@ops.ietf.org > Subject: Re: Two Drafts for Resilience of Control Plane >=20 > John, >=20 >=20 >=20 > This discussion is about resilience of control plane and whether some > standardized solutions (and hence additional work in CCAMP) is needed. [JD]=20 We're still waiting for you to describe what you think is needed. All you do is continue to assert that additional work is needed. > So > I > disagree with you when you say that the discussion has nothing to do with > NMS, because one can evaluate the resilience only compared with one of > some > alternative way of service provisioning and management. I personally do > not > see any technical reason why managing services via control plane should be > less resilient than doing so via management plane. [JD]=20 As I said in my note, I don't consider the two to be competing. > However, to achieve > this > some additional work is required. [JD]=20 Argument by emphatic repetition? >=20 >=20 >=20 > Igor >=20 > ----- Original Message ----- > From: "Drake, John E" > To: ; ; ; > > Cc: ; ; > ; ; > > Sent: Monday, October 31, 2005 9:40 AM > Subject: RE: Two Drafts for Resilience of Control Plane >=20 >=20 > Neil, >=20 > I don't think the discussion, at least from my perspective, has anything > to do with the NMS, other than this strange assertion that the NMS will > always be able to reach every node in the network even if there is a > control plane failure. >=20 > I have always considered the control plane to be a component in a larger > system that also includes the NMS, etc. >=20 > Thanks, >=20 > John >=20 > > -----Original Message----- > > From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com] > > Sent: Monday, October 31, 2005 6:32 AM > > To: ibryskin@movaz.com; Drake, John E; zali@cisco.com; > i_bryskin@yahoo.com > > Cc: drake@movaz.com; dpapadimitriou@psg.com; > > dimitri.papadimitriou@alcatel.be; yhwkim@etri.re.kr; > ccamp@ops.ietf.org > > Subject: RE: Two Drafts for Resilience of Control Plane > > > > Igor....if it's any comfort to you, folks here in BT agree with you. > > And I don't care what anyone says about the NMS and the futile > attempts > > to obsolete it....we will always need this for a whole raft of > > functions/reasons....and the closer one gets to the duct the more > > important it becomes and the less important a control-plane becomes > (at > > least dynamic routing aspects). > > > > regards, Neil > > > > > -----Original Message----- > > > From: owner-ccamp@ops.ietf.org > > > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Igor Bryskin > > > Sent: 31 October 2005 14:10 > > > To: Drake, John E; Zafar Ali (zali); Igor Bryskin > > > Cc: drake@movaz.com; dpapadimitriou@psg.com; > > > dimitri.papadimitriou@alcatel.be; Kim Young Hwa; ccamp@ops.ietf.org > > > Subject: Re: Two Drafts for Resilience of Control Plane > > > > > > > > > John, > > > > > > > > > > > > > > > > > > > > > > States are supposed to be destroyed on explicit > > > signalling message > > > > > (e.g. PathTear or PathErr with the state removal flag), but not > > > > > because of the absence of refreshes. > > > > > > > > [JD] > > > > > > Igor, > > > > > > Just to be clear, we are talking about RSVP here, and RSVP > > > *is* a soft state protocol. Can you point to any RFC that > > > supports your statements above? > > > > > > IB>> Oh, come on, John. You sound like you've been yourself > > > in a dormant > > > state for a while :=3D). We've gone a long way since RFC2205. > > > In RFC3471, for example, there is a discussion why GMPLS is > > > needed and how is it different from MPLS. One of the > > > differences is the fact that soft state protocols do not work > > > well for non-packet environments. Here is from the RDC3471: > > > > > > > > > > > > 9.2. Fault Handling There are two new faults that must be > > > handled when > > > the control channel is independent of the data channel. In > > > the first, > > > there is a link or other type of failure that limits the ability > of > > > neighboring nodes to pass control messages. In this situation, > > > neighboring nodes are unable to exchange control messages > > > for a period of > > > time. Once communication is restored the underlying > > > signaling protocol > > > must indicate that the nodes have maintained their state through > the > > > failure.. > > > > > > What is more important is the reality of life: The customers > > > simply say that you cannot destroy a user service (or even > > > force any traffic hits) just because you have a problem in > > > the control plane. If this does not fit your soft-state > > > paradigm, than "harden" your protocols or flash them down the > > > toilet and come with something else if you want our business. > > > After all, if we provision the services via NMS, we do not > > > have to destroy the services if we have problems in the > > > management network. It is that simple. > > > > > > > > > > > > Igor > > > > > > > > > > > > > > > > > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 31 Oct 2005 15:25:29 +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: comments on draft-shiba-ccamp-gmpls-lambda-labels-00.txt Date: Mon, 31 Oct 2005 09:25:15 -0600 Message-ID: <7CA873794E52904EAA980A074B076779B17C5F@rchemx01.fnc.net.local> Thread-Topic: comments on draft-shiba-ccamp-gmpls-lambda-labels-00.txt Thread-Index: AcXbIzcAFoI5B5TzS9O/zBGY1cMJbwA6iz0AAIdyNZA= From: "Shiba, Sidney" To: "Drake, John E" , Cc: "Adrian Farrel" , , Hi John, Optical switches based on Wavelength Selective Switch (WSS) technology requires the wavelength information for switching. This technology is = NOT=20 wavelength agnostic. | | | wdm | wdm |2 |2 --------- --------- wdm 1| optical |3 wdm 1| optical |3 wdm --------| switch |------------| switch |--------- | (WSS) | | (WSS) | --------- --------- |4 |4 | wdm | wdm | |=20 Note that the figure above shows an example of two optical switches = interconnect by a single WDM fiber. In this example, each optical switch can be = connect to 4=20 other optical switches.=20 As you can see, the optical ports information do not provide enough = information for wavelength switching. Hope that clarifies the application requirement. Thanks, Sidney > -----Original Message----- > From: Drake, John E [mailto:John.E.Drake2@boeing.com] > Sent: Friday, October 28, 2005 5:33 PM > To: dpapadimitriou@psg.com; Shiba, Sidney > Cc: Adrian Farrel; richard.rabbat@us.fujitsu.com; ccamp@ops.ietf.org > Subject: RE: comments on draft-shiba-ccamp-gmpls-lambda-labels-00.txt >=20 >=20 > Hi, >=20 > Below is the text of an e-mail is sent to the Ethernet/GMPLS mailing > list. >=20 > Upon reflection I am not sure using a real wavelength value makes much > sense. Between a pair of adjacent nodes, there may be=20 > multiple pairs of > switch ports in the same TE link that support a given frequency. If a > real wavelength value is used, how do the two nodes agree on=20 > which pair > of switch ports to use? >=20 > Furthermore, the amount of configuration is the same - you=20 > still need to > configure the wavelength of each switch port. >=20 > Thanks, >=20 > John > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > =3D=3D=3D=3D > Adrian, >=20 > In the transparent photonic lambda switch case, the labels also have > only local significance. When an LSP is established, the input ports, > as identified with local labels, are cross-connected to the output > ports, as identified with local labels. >=20 > There is just extra configuration to identify, using strictly local > identifiers, the wavelength associated with the all of the switch's > ports, and an additional CAC requirement that the wavelengths of the > input and output ports are the same. >=20 > Thanks, >=20 > John =20 >=20 >=20 > > -----Original Message----- > > From: dimitri papadimitriou [mailto:dpapadimitriou@psg.com] > > Sent: Thursday, October 27, 2005 10:03 AM > > To: Shiba, Sidney > > Cc: dimitri.papadimitriou@alcatel.be; Adrian Farrel; > > richard.rabbat@us.fujitsu.com; ccamp@ops.ietf.org > > Subject: Re: comments on=20 > draft-shiba-ccamp-gmpls-lambda-labels-00.txt > >=20 > > shiba - see inline for some additional hints: > >=20 > > >>Shiba, Sidney wrote: > > >> > > >>>Adrian, Dimitri, > > >>> > > >>>Thanks for reviewing these I-D. > > >>> > > >>>Wavelength continuity constraint does require the use of > semanticful > > >>>label whether it is spectral or index. > > >> > > >>=3D> see my reply to adrian on this specific point > > >> > > >>>I agree with Dimitri that the > > >>>wavelength indexing requires document updating each time a new > > >>>spectrum is introduced. > > >> > > >>=3D> indeed and in addition it requires updating the already > > >>signaled path > > >> > > >>>The use of spectral label provides self maintainance, i.e., > > >>>no need to update any document and the use of the nominal value > > >>>provides a common semantic ground. > > >> > > >>=3D> what do you mean by self-maintenance - would you provide a > > >>bit more detail > > > > > > [Sidney]What I've meant here was that it was not necessary to > > > update any document when new wavelengths are inventoried. In the > > > case of indexing approach, it would require the=20 > wavelength indexing > > > document to be updated with implementation impacts. > > > > > > In the case, the nominal value is used, there is no need for > > > documentation update. > >=20 > > ok - what you mean here is that you are going to make use of the > already > > defined C-Type 2 - what about the specific encoding of the=20 > value space > ? > >=20 > > >>=3D> now i have a more specific question before being light-up > > >>how do you know the frequency that you can support ? > > > > > > [Sidney] Some new technologies integrate optical switch and > mux/demux > > > capabilities, which allows the equipment to know the spectrum it > > supports. > >=20 > > indeed - but the question is what does happen if the=20 > "detected" values > > (during initialization) do not match the nominal values ? you don't > > initialize then ? > >=20 > > >>if these differ from the nominal values how are you going to deal > with > > these > > >>discrepancies ? > > > > > > [Sidney] These new technologies uses the nominal value as=20 > reference. > We > > can say > > > that a lightpath wavelength is identified by its nominal value. If > the > > equipment > > > is drifting from this nominal value, it is considered as=20 > a failure. > >=20 > > ok - but if the deviation is such you have overlap - how the control > > plane is going to be able to detect such failure ? > >=20 > > >>this said i am not necessarily sure that having to=20 > maintain the data > > plane > > >>specifics as part of the control plane is really helping > > >>operations (is this method not just duplicating complexity ?) > > > > > > [Sidney] The wavelength is WDM specific as much as the SUKLM label > > encoding > > > is for SONET. The wavelegth/frequency nominal value is used to > identify > > the > > > facilities to cross-connect. > >=20 > > there is an equivalence but there is also a major difference, the > > structure is invariant independently of the state of the=20 > network, with > > spectral value space you may have labels that become unavailable due > to > > non-local usage of wavelength in the network > >=20 > > hence, there is also no real coupling to the data plane more than > > knowing the type of interface and some generic capabilities > >=20 > > >>>I'm not sure if the draft needs to be updated before the > > >>>face-to-face meeting or after all comments are collected. Please > > advise. > > >> > > >>=3D> suggest to keep discussion on - document update can be > > >>performed at a later stage > >=20 > > thanks, > > - dimitri. > >=20 > > >>>>-----Original Message----- > > >>>>From: owner-ccamp@ops.ietf.org=20 > [mailto:owner-ccamp@ops.ietf.org]On > > >>>>Behalf Of Adrian Farrel > > >>>>Sent: Thursday, October 27, 2005 4:45 AM > > >>>>To: dpapadimitriou@psg.com; dimitri.papadimitriou@alcatel.be; > > >>>>ccamp@ops.ietf.org > > >>>>Subject: Re: comments on > > >> > > >>draft-shiba-ccamp-gmpls-lambda-labels-00.txt > > >> > > >>>> > > >>>>Dimitri, > > >>>> > > >>>>Thanks for your work reviewing these recent I-Ds. It is > > >>>>really valuable > > >>>>and I'd welcome other people doing similar reviews. > > >>>> > > >>>> > > >>>> > > >>>>>there is a specific point to be clarified in this document: > > >>>>> > > >>>>>semanticless vs semanticful label (even here there is a > distinction > > >>>>>between spectral vs indexes i.e. using the wavelength index) > > >>>>> > > >>>>>domain-wide vs link local significant label > > >>>> > > >>>>Without being too picky, I think all labels are semanticful > > >>>>otherwise, we > > >>>>would not know what resource they refered to. > > >>>> > > >>>>So the point reduces to whether the scope of the semantics > > >>>>are link-local > > >>>>or wider. > > >>>> > > >>>> > > >>>> > > >>>>>so, the comparison from this perspective with TDM labels is > > >>>> > > >>>>difficult to > > >>>> > > >>>> > > >>>>>parse, the latter is semanticful but link local > > >>>>> > > >>>>>now, i don't specifically see what has changed the late 90's, > early > > >>>>>y2k's, to have a change in the wavelength label definition; > > >>>> > > >>>>This is the question I would like to get to the bottom of. In > > >>>>other words: > > >>>>do we need this function? > > >>>> > > >>>>It seems to me that the question being asked is this: > > >>>> > > >>>> If I want to compute a path that has some form of wavelength > > >>>> constraints, what information do I need access to? > > >>>> > > >>>>Another question might be: > > >>>> > > >>>> If I want to signal a path with wavelength constraints what > > >>>> information do I need to include in the signaling message? > > >>>> > > >>>> > > >>>>I'd suggest that when we started on GMPLS, we were > > >> > > >>enthusiastic about > > >> > > >>>>transparent optical networks, but we were not properly > > >>>>focusing wavelength > > >>>>constraints because lambda-switching PXCs didn't take off. > > >>>>Therefore we > > >>>>didn't examine the requirements for wavelength constraints in > > >>>>routing and > > >>>>signaling. The authors of this I-D are claiming new hardware > > >>>>requirements > > >>>>for the same function. > > >>>> > > >>>> > > >>>> > > >>>>>there are > > >>>>>several solution possible > > >>>>> > > >>>>>- absolute values: the freq. of the wavelength: difficult to > adopt > > >>>>>because referenced values are nominal and knowing all > interactions > > >>>>>between wavelengths this knowledge is at the end of little > > >> > > >>practical > > >> > > >>>>>usage; (introduces implicit ordering) > > >>>>> > > >>>>>- indexed values: the # of the wavelength: it does not > > >> > > >>provide for a > > >> > > >>>>>future proof label space for inst. in case new frequencies > > >>>> > > >>>>are inserted > > >>>> > > >>>> > > >>>>>in the grid (introduces explicit ordering) > > >>>>> > > >>>>>- diff. values e.g. freq spacing starting from a reference > > >>>> > > >>>>value: pauses > > >>>> > > >>>> > > >>>>>the question of the reference value and does suffer from the > former > > >>>>>issue (introduces implicit ordering) > > >>>>> > > >>>>>- the solution available today - cumbersome in some=20 > control plane > > >>>>>operations (e.g. label set translation) and not easy to > > >>>> > > >>>>troubleshoot but > > >>>> > > >>>> > > >>>>>independent of any physical consideration (spectral), scale to > any > > >>>>>number of wavelength per fiber, does not introduce any > > >> > > >>ordering, the > > >> > > >>>>>most flexible (since allowing each system to maintain its > specific > > >>>>>control operations) and the less constraining since maintaining > the > > >>>>>control plane operations independent of any data plane=20 > specifics > > >>>>> > > >>>>> > > >>>> > > >>>> > >>> > > >>>ambda-labels > > >>>-00.txt> > > >>> > > >>>. > > >>> > > >> > > > > > > . > > > >=20 Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 31 Oct 2005 15:19:24 +0000 Message-ID: <00fa01c5de2e$65e8e1b0$7a1810ac@movaz.com> From: "Igor Bryskin" To: "Drake, John E" , , , Cc: , , , , Subject: Re: Two Drafts for Resilience of Control Plane Date: Mon, 31 Oct 2005 10:18:50 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit John, This discussion is about resilience of control plane and whether some standardized solutions (and hence additional work in CCAMP) is needed. So I disagree with you when you say that the discussion has nothing to do with NMS, because one can evaluate the resilience only compared with one of some alternative way of service provisioning and management. I personally do not see any technical reason why managing services via control plane should be less resilient than doing so via management plane. However, to achieve this some additional work is required. Igor ----- Original Message ----- From: "Drake, John E" To: ; ; ; Cc: ; ; ; ; Sent: Monday, October 31, 2005 9:40 AM Subject: RE: Two Drafts for Resilience of Control Plane Neil, I don't think the discussion, at least from my perspective, has anything to do with the NMS, other than this strange assertion that the NMS will always be able to reach every node in the network even if there is a control plane failure. I have always considered the control plane to be a component in a larger system that also includes the NMS, etc. Thanks, John > -----Original Message----- > From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com] > Sent: Monday, October 31, 2005 6:32 AM > To: ibryskin@movaz.com; Drake, John E; zali@cisco.com; i_bryskin@yahoo.com > Cc: drake@movaz.com; dpapadimitriou@psg.com; > dimitri.papadimitriou@alcatel.be; yhwkim@etri.re.kr; ccamp@ops.ietf.org > Subject: RE: Two Drafts for Resilience of Control Plane > > Igor....if it's any comfort to you, folks here in BT agree with you. > And I don't care what anyone says about the NMS and the futile attempts > to obsolete it....we will always need this for a whole raft of > functions/reasons....and the closer one gets to the duct the more > important it becomes and the less important a control-plane becomes (at > least dynamic routing aspects). > > regards, Neil > > > -----Original Message----- > > From: owner-ccamp@ops.ietf.org > > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Igor Bryskin > > Sent: 31 October 2005 14:10 > > To: Drake, John E; Zafar Ali (zali); Igor Bryskin > > Cc: drake@movaz.com; dpapadimitriou@psg.com; > > dimitri.papadimitriou@alcatel.be; Kim Young Hwa; ccamp@ops.ietf.org > > Subject: Re: Two Drafts for Resilience of Control Plane > > > > > > John, > > > > > > > > > > > > > > > > > States are supposed to be destroyed on explicit > > signalling message > > > > (e.g. PathTear or PathErr with the state removal flag), but not > > > > because of the absence of refreshes. > > > > > > [JD] > > > > Igor, > > > > Just to be clear, we are talking about RSVP here, and RSVP > > *is* a soft state protocol. Can you point to any RFC that > > supports your statements above? > > > > IB>> Oh, come on, John. You sound like you've been yourself > > in a dormant > > state for a while :=). We've gone a long way since RFC2205. > > In RFC3471, for example, there is a discussion why GMPLS is > > needed and how is it different from MPLS. One of the > > differences is the fact that soft state protocols do not work > > well for non-packet environments. Here is from the RDC3471: > > > > > > > > 9.2. Fault Handling There are two new faults that must be > > handled when > > the control channel is independent of the data channel. In > > the first, > > there is a link or other type of failure that limits the ability of > > neighboring nodes to pass control messages. In this situation, > > neighboring nodes are unable to exchange control messages > > for a period of > > time. Once communication is restored the underlying > > signaling protocol > > must indicate that the nodes have maintained their state through the > > failure.. > > > > What is more important is the reality of life: The customers > > simply say that you cannot destroy a user service (or even > > force any traffic hits) just because you have a problem in > > the control plane. If this does not fit your soft-state > > paradigm, than "harden" your protocols or flash them down the > > toilet and come with something else if you want our business. > > After all, if we provision the services via NMS, we do not > > have to destroy the services if we have problems in the > > management network. It is that simple. > > > > > > > > Igor > > > > > > > > > > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 31 Oct 2005 14:41:34 +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: Two Drafts for Resilience of Control Plane Date: Mon, 31 Oct 2005 06:40:24 -0800 Message-ID: <626FC7C6A97381468FB872072AB5DDC8369717@XCH-SW-42.sw.nos.boeing.com> Thread-Topic: Two Drafts for Resilience of Control Plane Thread-Index: AcXeJODvtSLGpyjCSiesm+zs4e0vcQAAljWgAAA4G0A= From: "Drake, John E" To: , , , Cc: , , , , Neil, I don't think the discussion, at least from my perspective, has anything to do with the NMS, other than this strange assertion that the NMS will always be able to reach every node in the network even if there is a control plane failure. =20 I have always considered the control plane to be a component in a larger system that also includes the NMS, etc. Thanks, John=20 > -----Original Message----- > From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com] > Sent: Monday, October 31, 2005 6:32 AM > To: ibryskin@movaz.com; Drake, John E; zali@cisco.com; i_bryskin@yahoo.com > Cc: drake@movaz.com; dpapadimitriou@psg.com; > dimitri.papadimitriou@alcatel.be; yhwkim@etri.re.kr; ccamp@ops.ietf.org > Subject: RE: Two Drafts for Resilience of Control Plane >=20 > Igor....if it's any comfort to you, folks here in BT agree with you. > And I don't care what anyone says about the NMS and the futile attempts > to obsolete it....we will always need this for a whole raft of > functions/reasons....and the closer one gets to the duct the more > important it becomes and the less important a control-plane becomes (at > least dynamic routing aspects). >=20 > regards, Neil >=20 > > -----Original Message----- > > From: owner-ccamp@ops.ietf.org > > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Igor Bryskin > > Sent: 31 October 2005 14:10 > > To: Drake, John E; Zafar Ali (zali); Igor Bryskin > > Cc: drake@movaz.com; dpapadimitriou@psg.com; > > dimitri.papadimitriou@alcatel.be; Kim Young Hwa; ccamp@ops.ietf.org > > Subject: Re: Two Drafts for Resilience of Control Plane > > > > > > John, > > > > > > > > > > > > > > > > > States are supposed to be destroyed on explicit > > signalling message > > > > (e.g. PathTear or PathErr with the state removal flag), but not > > > > because of the absence of refreshes. > > > > > > [JD] > > > > Igor, > > > > Just to be clear, we are talking about RSVP here, and RSVP > > *is* a soft state protocol. Can you point to any RFC that > > supports your statements above? > > > > IB>> Oh, come on, John. You sound like you've been yourself > > in a dormant > > state for a while :=3D). We've gone a long way since RFC2205. > > In RFC3471, for example, there is a discussion why GMPLS is > > needed and how is it different from MPLS. One of the > > differences is the fact that soft state protocols do not work > > well for non-packet environments. Here is from the RDC3471: > > > > > > > > 9.2. Fault Handling There are two new faults that must be > > handled when > > the control channel is independent of the data channel. In > > the first, > > there is a link or other type of failure that limits the ability of > > neighboring nodes to pass control messages. In this situation, > > neighboring nodes are unable to exchange control messages > > for a period of > > time. Once communication is restored the underlying > > signaling protocol > > must indicate that the nodes have maintained their state through the > > failure.. > > > > What is more important is the reality of life: The customers > > simply say that you cannot destroy a user service (or even > > force any traffic hits) just because you have a problem in > > the control plane. If this does not fit your soft-state > > paradigm, than "harden" your protocols or flash them down the > > toilet and come with something else if you want our business. > > After all, if we provision the services via NMS, we do not > > have to destroy the services if we have problems in the > > management network. It is that simple. > > > > > > > > Igor > > > > > > > > > > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 31 Oct 2005 14:32:39 +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: Two Drafts for Resilience of Control Plane Date: Mon, 31 Oct 2005 14:31:42 -0000 Message-ID: <0536FC9B908BEC4597EE721BE6A3538912275564@i2km07-ukbr.domain1.systemhost.net> Thread-Topic: Two Drafts for Resilience of Control Plane Thread-Index: AcXeJODvtSLGpyjCSiesm+zs4e0vcQAAljWg From: To: , , , Cc: , , , , Igor....if it's any comfort to you, folks here in BT agree with you. And I don't care what anyone says about the NMS and the futile attempts to obsolete it....we will always need this for a whole raft of functions/reasons....and the closer one gets to the duct the more important it becomes and the less important a control-plane becomes (at least dynamic routing aspects). =20 regards, Neil=20 > -----Original Message----- > From: owner-ccamp@ops.ietf.org > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Igor Bryskin > Sent: 31 October 2005 14:10 > To: Drake, John E; Zafar Ali (zali); Igor Bryskin > Cc: drake@movaz.com; dpapadimitriou@psg.com;=20 > dimitri.papadimitriou@alcatel.be; Kim Young Hwa; ccamp@ops.ietf.org > Subject: Re: Two Drafts for Resilience of Control Plane >=20 >=20 > John, >=20 >=20 > > > > > > > > > > States are supposed to be destroyed on explicit > signalling message > > > (e.g. PathTear or PathErr with the state removal flag), but not > > > because of the absence of refreshes. > > > > [JD] >=20 > Igor, >=20 > Just to be clear, we are talking about RSVP here, and RSVP > *is* a soft state protocol. Can you point to any RFC that=20 > supports your statements above? >=20 > IB>> Oh, come on, John. You sound like you've been yourself > in a dormant > state for a while :=3D). We've gone a long way since RFC2205. > In RFC3471, for example, there is a discussion why GMPLS is=20 > needed and how is it different from MPLS. One of the=20 > differences is the fact that soft state protocols do not work=20 > well for non-packet environments. Here is from the RDC3471: >=20 >=20 >=20 > 9.2. Fault Handling There are two new faults that must be=20 > handled when > the control channel is independent of the data channel. In=20 > the first, > there is a link or other type of failure that limits the ability of > neighboring nodes to pass control messages. In this situation, > neighboring nodes are unable to exchange control messages=20 > for a period of > time. Once communication is restored the underlying=20 > signaling protocol > must indicate that the nodes have maintained their state through the > failure.. >=20 > What is more important is the reality of life: The customers > simply say that you cannot destroy a user service (or even=20 > force any traffic hits) just because you have a problem in=20 > the control plane. If this does not fit your soft-state=20 > paradigm, than "harden" your protocols or flash them down the=20 > toilet and come with something else if you want our business.=20 > After all, if we provision the services via NMS, we do not=20 > have to destroy the services if we have problems in the=20 > management network. It is that simple. >=20 >=20 >=20 > Igor >=20 >=20 >=20 >=20 >=20 >=20 >=20 Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 31 Oct 2005 14:10:22 +0000 Message-ID: <00b201c5de24$c20fc710$7a1810ac@movaz.com> From: "Igor Bryskin" To: "Drake, John E" , "Zafar Ali (zali)" , "Igor Bryskin" Cc: , , , "Kim Young Hwa" , Subject: Re: Two Drafts for Resilience of Control Plane Date: Mon, 31 Oct 2005 09:09:50 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit John, > > > > > > > States are supposed to be destroyed on explicit signalling > > message (e.g. PathTear or PathErr with the state removal > > flag), but not because of the absence of refreshes. > > [JD] Igor, Just to be clear, we are talking about RSVP here, and RSVP *is* a soft state protocol. Can you point to any RFC that supports your statements above? IB>> Oh, come on, John. You sound like you've been yourself in a dormant state for a while :=). We've gone a long way since RFC2205. In RFC3471, for example, there is a discussion why GMPLS is needed and how is it different from MPLS. One of the differences is the fact that soft state protocols do not work well for non-packet environments. Here is from the RDC3471: 9.2. Fault Handling There are two new faults that must be handled when the control channel is independent of the data channel. In the first, there is a link or other type of failure that limits the ability of neighboring nodes to pass control messages. In this situation, neighboring nodes are unable to exchange control messages for a period of time. Once communication is restored the underlying signaling protocol must indicate that the nodes have maintained their state through the failure.. What is more important is the reality of life: The customers simply say that you cannot destroy a user service (or even force any traffic hits) just because you have a problem in the control plane. If this does not fit your soft-state paradigm, than "harden" your protocols or flash them down the toilet and come with something else if you want our business. After all, if we provision the services via NMS, we do not have to destroy the services if we have problems in the management network. It is that simple. Igor Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 31 Oct 2005 13:39:09 +0000 Message-ID: <009a01c5de20$4e7ecde0$7a1810ac@movaz.com> From: "Igor Bryskin" To: "Zafar Ali (zali)" , "Igor Bryskin" Cc: , "John E" , , , "Kim Young Hwa" , Subject: Re: Two Drafts for Resilience of Control Plane Date: Mon, 31 Oct 2005 08:37:58 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Zafar, [Snipped] > > Then how states get ever destoryed, even in normal case, > e.g., if head > > end sends a ptear and all controllers are up? > > > > States are supposed to be destroyed on explicit signalling > message (e.g. PathTear or PathErr with the state removal > flag), but not because of the absence of refreshes. > I see this as an implementation deficency and not a protocol deficiency. Just remove the states that are not refreshed and your problem is solved. IB>> Well, you cannot remove control plane state without releasing associated resources. Let me give you two reasons why: a) Once you do this, the associated resources become orphans: there will be no entity remembering them and, thus, there will be no way to return them to the pool of unreserved resources and reuse in other LSPs b) If/when the "dead" controller does come back to life, it will not be capable to synchronize the control plane states because its neighbors will not have ones. Igor Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 31 Oct 2005 11:01:27 +0000 Message-Id: <5.1.1.9.2.20051031192340.06cb3ec0@imf.m.ecl.ntt.co.jp> Date: Mon, 31 Oct 2005 20:00:42 +0900 To: ccamp@ops.ietf.org From: Tomonori TAKEDA Subject: Question on draft-ietf-ccamp-inter-domain-pd-path-comp-01.txt Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP"; format=flowed Content-Transfer-Encoding: 7bit Hi JP, Arthi, Raymond I have a small question on draft-ietf-ccamp-inter-domain-pd-path-comp-01.txt. http://www.ietf.org/internet-drafts/draft-ietf-ccamp-inter-domain-pd-path-comp-01.txt In section 4, it says: In terms of computation of an inter-AS TE LSP path, an interesting optimization technique consists of allowing the ASBRs to flood the TE information related to the inter-ASBR link(s) although no IGP TE is enabled over those links (and so there is no IGP adjacency over the inter-ASBR links). It sounds like passive interface in IP. Is it applicable (or is there a defined way) in (G)MPLS TE? Note I think: - This technique is as useful when PCE is used, assuming (each) PCE participates routing in each domain (in this case, AS) - This technique may be as useful in GMPLS overlay network Thanks, Tomonori Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 31 Oct 2005 07:57:59 +0000 Date: Mon, 31 Oct 2005 16:56:18 +0900 From: Akira NAGATA To: "Zafar Ali (zali)" , "Adrian Farrel" Subject: Re: Question on Administratively down bit Cc: Message-Id: <20051031164940.9692.NAGATA.AKIRA@jp.fujitsu.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Hi Zafar, Thank you for your comments. I'll consider more about this point, based on your comments. Please let me discuss again at a later date. best regards, Akira On Fri, 21 Oct 2005 07:10:40 -0400 "Zafar Ali (zali)" san wrote: > Hi Akira, > > The sequence you mentioned is correct. Also this is my understanding > that when an LSP is in "Admin.A = 1", an optical node may be performing > some power monitoring and adjustment related to the commissioning > process (again, this is a local action by an optical node). From a > router's prospective, I do see a need for router NOT to send any data > traffic on the LSP that is in "Admin.A=1", in addition of suppressing > alarm on the interface in question. I.e., an LSP can ONLY carrying data > traffic when it is back to "Admin.A=0". > > Comments/ additions? > > Thanks > > Regards... Zafar > > > -----Original Message----- > > From: owner-ccamp@ops.ietf.org > > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Akira NAGATA > > Sent: Friday, October 21, 2005 1:52 AM > > To: Adrian Farrel > > Cc: Akira_NAGATA; ccamp@ops.ietf.org > > Subject: Re: Question on Administratively down bit > > > > Hi Adrian, > > > > Thank you for your discussing this issue. > > > > I understand that a hardware behavior triggered by > > AdminStatus bit will differ from one vendor to another. > > > > Alarm inhibition is just an example of application by A-bit, > > RFC3471 or 3473 can not achieve interoperability on the > > hardware behavior itself triggered by A-bit in multi-vendor > > network. Is it right? > > In a fact, I think it cannot be helped. > > > > I believe, however, RFC3471 or 3473 shall achieve > > interoperability on AdminStatus bit including A-bit from the > > perspective of message handling, at least. > > > > RFC3473 has no explicit clarification of handling A-bit or > > T-bit, where it has an explicit description of handling the > > pair of D and R-bit (in Section 7.2). > > In order to achieve interoperability at message level, more > > explicit description will be needed for A-bit or T-bit like > > the case of D+R-bit. > > > > How do you think about this point? > > > > According to my understanding using examples from D+R-bit in > > Sec 7.2.1, Path/Resv sequence for alarm report inhibition by > > A-bit (i.e. > > degradation > > of established LSP) can be shown as following: > > > > Path (A=1, R=1) > > ingress -------------------> egress > > node Resv (A=1, R=0) node > > <------------------ > > > > Similarly, Path/Resv sequence for enabling alarm report by > > A-bit (i.e. activation of degradated LSP) can be shown as following: > > > > Path (A=0, R=1) > > ingress -------------------> egress > > node Resv (A=0, R=0) node > > <------------------ > > > > Would you mind letting me know if something wrong? > > > > best regards, > > Akira > > > > On Wed, 19 Oct 2005 14:57:35 +0100 > > "Adrian Farrel" san wrote: > > > > > Hi Akira, > > > > > > I have been thinking about your question and discussing it > > with a few > > > people. > > > > > > The general consensus is that it is important to have well-defined > > > mechanisms for the signaling exchange of the Admin Status bits, but > > > that the actions to take on receipt of some the bits may be > > dependent > > > on local policy or on data plane technology. > > > > > > Thus an implementation may decide that certain alarms should be > > > suppressed during LSP establishment because it knows them to be > > > "false" alarms triggered by the process of establishing the LSP. On > > > the other hand, an implementation may decide that other alarms that > > > are first raised during LSP establishment represent a > > different set of > > > circumstances and should be raised. I would be worried if > > we tried to > > > list and categorise all such alarms within the CCAMP working group. > > > > > > It might be useful to consider whether the behavior of switch under > > > alarm suppression conditions should be configurable to allow the > > > operator to select consistent behavior, or whether this is > > adding too much complexity. > > > > > > Cheers, > > > Adrian > > > > > > ----- Original Message ----- > > > From: "Akira NAGATA" > > > To: > > > Cc: "Akira_NAGATA" > > > Sent: Friday, August 19, 2005 12:13 PM > > > Subject: Question on Administratively down bit > > > > > > > > > > Mr. Lou Berger and editors of RFC3471 and RFC3473, > > > > > > > > This is my first time to send e-mail to ccamp. > > > > Thanks in advance. > > > > > > > > I'd like to ask one question about the handling of > > Administratively > > > > down > > > bit > > > > in GMPLS RSVP-TE's Admin_Status object. > > > > > > > > RFC3471 introduces "inhibiting alarm reporting" as an example > > > application > > > > of local action to "down" state (that is, A-bit=1) in Section 8. > > > > But I can't find any other explicit descriptions about this > > > > procedure in RFC3471 or 3473. > > > > > > > > I understand that actions to be taken by each node receiving > > > Admin_Status > > > > object shall be based on local policy. > > > > > > > > With regard to inhibition of alarm reporting, however, in order to > > > achieve it > > > > through end-to-end, I believe that we had better take a unified > > > > action as a response to A-bit ("down" or "up"). > > > > Operator will expect this feature. > > > > > > > > (Here I mean alarm report is not reporting via RSVP messages as > > > described > > > > in ID-alarm-spec, but one from NE to external system such > > as network > > > > management system.) > > > > > > > > Are there any considerations, drafts or RFCs to define it? > > > > > > > > Thanks, > > > > --- > > > > Akira NAGATA > > > > > > > > > > > > > > > > > > > > > > > --- > > Akira NAGATA Photonic Node > > Laboratory, Photonics Networking Laboratories, Fujitsu > > Laboratories Ltd. > > TEL: +81-44-754-2765 FAX: +81-44-754-2741 > > > > --- Akira NAGATA Photonic Node Laboratory, Photonics Networking Laboratories, Fujitsu Laboratories Ltd. TEL: +81-44-754-2765 FAX: +81-44-754-2741 Envelope-to: ccamp-data@psg.com Delivery-date: Sun, 30 Oct 2005 23:11:23 +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: Two Drafts for Resilience of Control Plane Date: Sun, 30 Oct 2005 15:09:33 -0800 Message-ID: <626FC7C6A97381468FB872072AB5DDC8369714@XCH-SW-42.sw.nos.boeing.com> Thread-Topic: Two Drafts for Resilience of Control Plane Thread-Index: AcXdZkYp8+2roqIaTpWMcrN6jVo3zgACKc9AAA3sOmA= From: "Drake, John E" To: "Zafar Ali \(zali\)" , "Igor Bryskin" , Cc: , , , "Kim Young Hwa" , Snipped > > > > > > > States are supposed to be destroyed on explicit signalling > > message (e.g. PathTear or PathErr with the state removal > > flag), but not because of the absence of refreshes. > > [JD]=20 Igor, Just to be clear, we are talking about RSVP here, and RSVP *is* a soft state protocol. Can you point to any RFC that supports your statements above? Thanks, John Envelope-to: ccamp-data@psg.com Delivery-date: Sun, 30 Oct 2005 16:34:35 +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: Two Drafts for Resilience of Control Plane Date: Sun, 30 Oct 2005 11:32:18 -0500 Message-ID: Thread-Topic: Two Drafts for Resilience of Control Plane Thread-Index: AcXdZkYp8+2roqIaTpWMcrN6jVo3zgACKc9A From: "Zafar Ali \(zali\)" To: "Igor Bryskin" , Cc: , "John E" , , , "Kim Young Hwa" , Igor,=20 > -----Original Message----- > From: Igor Bryskin [mailto:i_bryskin@yahoo.com]=20 > Sent: Sunday, October 30, 2005 10:26 AM > To: Zafar Ali (zali); ibryskin@movaz.com > Cc: drake@movaz.com; John E; dpapadimitriou@psg.com;=20 > dimitri.papadimitriou@alcatel.be; Igor Bryskin; Kim Young=20 > Hwa; ccamp@ops.ietf.org > Subject: RE: Two Drafts for Resilience of Control Plane >=20 > Zafar, >=20 >=20 > --- "Zafar Ali (zali)" wrote: >=20 > > > > > >> > > > > >> > Igor, > > > >> > > > > >> > W.r.t. option C, please note that traffic > > CANNOT be > > > forwarded in a > > > >> > "head-less mode" for a very long time . If > > you control > > > >> network melts > > > >> > or a peering controller goes down, either > > RSVP GR or > > > refreshes will > > > >> > take care of the clean-up of the affected > > RSVP states. > > > >> Similarly LMP > > > >> > CC SM will go down (after states are cleared, > > i.e., > > > >> degraded-to-down), > > > >> > eventually removing the TE links from > > topology. > > > >> > > > > >> > > > >> Sticking to the example I described: > > > >> a) absence of RSVP refreshes does not affect > > data plane in any way; > > > >> b) use of LMP is not mandatory and, becides, I > > don't see > > > now it helps. > > > >> True, the TE link could be withdrawn, however, > > the LSP > > > will still be > > > >> operational > > > > > > > > Isn't the problem is at "B" only and control > > plane at the > > > other node > > > > (or controller for other nodes) still working > > fine? If yes, local > > > > controllers will withdraw RSVP states; hence > > correct the data plane. > > > > > > >=20 > > > Again, GMPLS controller cannot remove control > > state and > > > destroy data plane just because it does not get > > refreshes > > > from adjacent controllers. > >=20 > > Then how states get ever destoryed, even in normal case,=20 > e.g., if head=20 > > end sends a ptear and all controllers are up? > >=20 >=20 > States are supposed to be destroyed on explicit signalling=20 > message (e.g. PathTear or PathErr with the state removal=20 > flag), but not because of the absence of refreshes. >=20 I see this as an implementation deficency and not a protocol deficiency. Just remove the states that are not refreshed and your problem is solved.=20 Thanks Regards... Zafar > Igor >=20 >=20 > > Thanks > >=20 > > Regards... Zafar > >=20 > > > >=20 >=20 >=20 >=20 > =09 > __________________________________ > Yahoo! FareChase: Search multiple travel sites in one click. > http://farechase.yahoo.com >=20 Envelope-to: ccamp-data@psg.com Delivery-date: Sat, 29 Oct 2005 17:41:56 +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: Two Drafts for Resilience of Control Plane Date: Sat, 29 Oct 2005 13:41:25 -0400 Message-ID: Thread-Topic: Two Drafts for Resilience of Control Plane Thread-Index: AcXcr3hb4yh8Q8iVSk2gZUt7/xg56AAAEXFg From: "Zafar Ali \(zali\)" To: Cc: , "John E" , , , "Igor Bryskin" , "Kim Young Hwa" , > >> > > >> > Igor, > >> > > >> > W.r.t. option C, please note that traffic CANNOT be=20 > forwarded in a=20 > >> > "head-less mode" for a very long time . If you control > >> network melts > >> > or a peering controller goes down, either RSVP GR or=20 > refreshes will=20 > >> > take care of the clean-up of the affected RSVP states. > >> Similarly LMP > >> > CC SM will go down (after states are cleared, i.e., > >> degraded-to-down), > >> > eventually removing the TE links from topology. > >> > > >> > >> Sticking to the example I described: > >> a) absence of RSVP refreshes does not affect data plane in any way; > >> b) use of LMP is not mandatory and, becides, I don't see=20 > now it helps. > >> True, the TE link could be withdrawn, however, the LSP=20 > will still be=20 > >> operational > > > > Isn't the problem is at "B" only and control plane at the=20 > other node=20 > > (or controller for other nodes) still working fine? If yes, local=20 > > controllers will withdraw RSVP states; hence correct the data plane. > > >=20 > Again, GMPLS controller cannot remove control state and=20 > destroy data plane just because it does not get refreshes=20 > from adjacent controllers. Then how states get ever destoryed, even in normal case, e.g., if head end sends a ptear and all controllers are up?=20 Thanks Regards... Zafar=20 Envelope-to: ccamp-data@psg.com Delivery-date: Sat, 29 Oct 2005 17:37:44 +0000 Message-ID: <3041.68.100.80.11.1130607453.squirrel@webmail.movaz.com> Date: Sat, 29 Oct 2005 13:37:33 -0400 (EDT) Subject: RE: Two Drafts for Resilience of Control Plane From: ibryskin@movaz.com To: "Zafar Ali (zali)" Cc: ibryskin@movaz.com, drake@movaz.com, "John E" , dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be, "Igor Bryskin" , "Kim Young Hwa" , ccamp@ops.ietf.org User-Agent: SquirrelMail/1.4.1 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit > > >> -----Original Message----- >> From: ibryskin@movaz.com [mailto:ibryskin@movaz.com] >> Sent: Saturday, October 29, 2005 10:10 AM >> To: Zafar Ali (zali) >> Cc: ibryskin@movaz.com; Drake@movaz.com; John E; >> dpapadimitriou@psg.com; dimitri.papadimitriou@alcatel.be; >> Igor Bryskin; Kim Young Hwa; ccamp@ops.ietf.org >> Subject: RE: Two Drafts for Resilience of Control Plane >> >> Zafar, >> >> c) leave LSP as it is and wait for the dead controller to >> >> be replaced or >> >> repaired. This would mean the need to perform normal >> operations like, >> >> for example, monitoring of data plane alarms, changing LSP admin >> >> status (for example, disabling alarms on all nodes), perform power >> >> monitoring and equalization, perform recovery operation in >> case of a >> >> fatal data plane failure. All what depends on hop-by-hop signaling >> >> won't work today. >> >> Don't tell me that these problems are fabricated; they are real >> >> because they are raised by the customers. Dimitri seems to >> understand >> >> the problem but he is saying that the CP in this case is hardly of >> >> any use. This IMO is a dangerous statement for the future of CP in >> >> non-packet environments. >> >> The Management plane aficionados will jump on it and say that >> >> management plane does not have such a problem - NMS has a direct >> >> access to any NE on the network, so it can do all >> necessary cleanup >> >> no matter what happened. >> >> Customers will say: "Well, if there are situations when CP >> suddenly >> >> becomes useless and we have to use management plane >> anyway, why would >> >> we use the CP in the first place?' >> >> >> >> Fortunately, I believe that the problems could be solved >> entirely via >> >> CP by making it more resilient. Hence, CP resilience is a good >> >> direction to work on within CCAMP WG >> > >> > Igor, >> > >> > W.r.t. option C, please note that traffic CANNOT be forwarded in a >> > "head-less mode" for a very long time . If you control >> network melts >> > or a peering controller goes down, either RSVP GR or refreshes will >> > take care of the clean-up of the affected RSVP states. >> Similarly LMP >> > CC SM will go down (after states are cleared, i.e., >> degraded-to-down), >> > eventually removing the TE links from topology. >> > >> >> Sticking to the example I described: >> a) absence of RSVP refreshes does not affect data plane in any way; >> b) use of LMP is not mandatory and, becides, I don't see now it helps. >> True, the TE link could be withdrawn, however, the LSP will >> still be operational > > Isn't the problem is at "B" only and control plane at the other node (or > controller for other nodes) still working fine? If yes, local > controllers will withdraw RSVP states; hence correct the data plane. > Again, GMPLS controller cannot remove control state and destroy data plane just because it does not get refreshes from adjacent controllers. Remember, CP and DP could be completely independent networks Igor > Thanks > > Regards... Zafar > >> >> Igor >> >> >> > Thanks >> > >> > Regards... Zafar >> > >> >> >> >> Igor >> >> >> >> > If "Considerable period of time" is not equal to infinity, >> >> then there >> >> > will be an RSVP graceful restart. If a controller is >> >> really and truly >> >> > dead, then presumably the operator will either replace it >> >> or re-assign >> >> > its data-plane resources to another signaling controller. >> >> In either >> >> > case, there will then be an RSVP graceful restart. >> >> > >> >> > Thanks, >> >> > >> >> > John >> >> > >> >> > >> >> > >> >> >> -----Original Message----- >> >> >> From: ibryskin@movaz.com [mailto:ibryskin@movaz.com] >> >> >> Sent: Friday, October 28, 2005 1:00 PM >> >> >> To: Drake, John E >> >> >> Cc: ibryskin@movaz.com; dpapadimitriou@psg.com; >> >> >> dimitri.papadimitriou@alcatel.be; Igor Bryskin; Zafar Ali; >> >> Kim Young >> >> > Hwa; >> >> >> ccamp@ops.ietf.org >> >> >> Subject: RE: Two Drafts for Resilience of Control Plane >> >> >> >> >> >> John, >> >> >> >> >> >> I think you missed my point here. "Dead" controllers in >> my example >> >> >> *do >> >> >> not* come back for a considerable period of time. So >> there are no >> >> > restarts >> >> >> here (graceful or not graceful) :=) >> >> >> >> >> >> Igor >> >> >> >> >> >> > What part of your problem, as stated below, is not >> >> handled by RSVP >> >> >> > graceful restart? >> >> >> > >> >> >> >> -----Original Message----- >> >> >> >> From: ibryskin@movaz.com [mailto:ibryskin@movaz.com] >> >> >> >> Sent: Friday, October 28, 2005 11:41 AM >> >> >> >> To: Drake, John E >> >> >> >> Cc: dpapadimitriou@psg.com; >> >> dimitri.papadimitriou@alcatel.be; Igor >> >> >> >> Bryskin; Zafar Ali; Kim Young Hwa; ccamp@ops.ietf.org >> >> >> >> Subject: RE: Two Drafts for Resilience of Control Plane >> >> >> >> >> >> >> >> Hi, >> >> >> >> >> >> >> >> Here is one of the problems that I've been thinking for >> >> a while - >> >> >> > control >> >> >> >> plane partitioned LSPs. Suppose one or more signaling >> >> controllers >> >> >> > managing >> >> >> >> some LSP went out of service leaving the LSP's data >> >> plane intact. >> >> > As >> >> >> > far >> >> >> >> as the user is concerned such LSP is perfectly healthy and >> >> >> > operational. >> >> >> >> Such situation could last for a considerable period of >> >> time. Do we >> >> >> > need to >> >> >> >> manage such LSP via control plane? Sure, we must be >> capable to >> >> >> >> tear >> >> >> > down >> >> >> >> such LSP, perform mb4b rerouting, distribute alarms between >> >> >> > operational >> >> >> >> controllers, signal data plane faults and perform recovery >> >> > switchover, >> >> >> >> modify LSP status, etc. Can we do this today? No, >> but with some >> >> >> >> (signaling) extensions the problem I believe is >> >> solvable. Is this >> >> > some >> >> >> >> artificial, "fabricated" problem? No, I think it is >> >> real. Does it >> >> > fall >> >> >> >> under the control plane resilience problem space? I >> believe it >> >> > does. >> >> >> >> >> >> >> >> Igor >> >> >> >> >> >> >> >> > I agree with Zafar and Dimitri. If someone wanted to >> >> >> >> > document >> >> > the >> >> >> > GMPLS >> >> >> >> > control plane resiliency features, as was done for GMPLS >> >> > addressing, >> >> >> >> > that might be a useful activity. >> >> >> >> > >> >> >> >> >> -----Original Message----- >> >> >> >> >> From: dimitri papadimitriou >> [mailto:dpapadimitriou@psg.com] >> >> >> >> >> Sent: Friday, October 28, 2005 9:56 AM >> >> >> >> >> To: Igor Bryskin >> >> >> >> >> Cc: Zafar Ali (zali); Kim Young Hwa; ccamp@ops.ietf.org >> >> >> >> >> Subject: Re: Two Drafts for Resilience of Control Plane >> >> >> >> >> >> >> >> >> >> igor - >> >> >> >> >> >> >> >> >> >> over time CCAMP came with a set of mechanims to >> >> improve control >> >> >> > plane >> >> >> >> >> resilience (RSVP and LMP GR upon channel/node >> >> failure) other WG >> >> >> >> > protocol >> >> >> >> >> work are also usable used here OSPF GR, etc. ... on the >> >> >> >> >> other >> >> > side, >> >> >> >> >> mechanism such as link bundling have built-in resilience >> >> >> > capabilities >> >> >> >> >> and most GMPLS control plane capabilities have >> been designed >> >> > such >> >> >> > as >> >> >> >> > to >> >> >> >> >> be independent of the control plane realisation (in-band, >> >> >> > out-of-band, >> >> >> >> >> etc.) >> >> >> >> >> >> >> >> >> >> so indeed i share the concern of Zafar what could >> we do more >> >> > here >> >> >> > than >> >> >> >> >> document these tools and provide our experience in >> >> using them; >> >> >> >> >> >> >> >> >> >> now, before stating there are (potential) >> >> problems(s) arising - >> >> >> > would >> >> >> >> >> you please be more specific on what are these potential >> >> >> >> >> issue(s) >> >> >> >> > and/or >> >> >> >> >> problems ? (not related to policy/config. - note: all the >> >> >> >> >> issues >> >> >> > you >> >> >> >> >> have pointed here below are simply policy/config specific >> >> >> >> >> but >> >> > none >> >> >> > of >> >> >> >> >> them highlights a missing IP control plane >> >> resiliency feature) >> >> >> >> >> >> >> >> >> >> thanks, >> >> >> >> >> - dimitri. >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> Igor Bryskin wrote: >> >> >> >> >> >> >> >> >> >> > Zafar, >> >> >> >> >> > >> >> >> >> >> > The problem arises when the control plane is >> >> decoupled from >> >> >> >> >> > the data plane. The question is do we need such >> >> decoupling in >> >> >> >> >> > IP networks? Consider, for example, the situation when >> >> >> >> >> > several parallel PSC data links bundled together and >> >> >> >> >> > controlled by a single control channel. >> >> >> >> >> > Does it mean in this case that when the control >> >> channel fails >> >> >> >> >> > all associated data links also fail? Do we need to >> >> reroute in >> >> >> >> >> > this case LSPs that use the data links? Can we >> >> rely in this >> >> >> >> >> > case on control plane indications to decide whether an >> >> >> >> >> > associated data link is healthy or not (in other >> >> words, can >> >> >> >> >> > we rely on RSVP Hellos or should we use, for >> >> example, BTD)? >> >> >> >> >> > Should we be capable to recover control >> channels without >> >> >> >> >> > disturbing data plane? I think control plane >> resilience is >> >> >> >> >> > important for all layers. You are right, Internet >> >> does work, >> >> >> >> >> > however, we do need for some reason TE and (fast) >> >> recovery in >> >> >> >> >> > IP as much as in other layers,don't we? >> >> >> >> >> > >> >> >> >> >> > Cheers, >> >> >> >> >> > Igor >> >> >> >> >> > >> >> >> >> >> > --- "Zafar Ali (zali)" wrote: >> >> >> >> >> > >> >> >> >> >> > >> >> >> >> >> >>Hi All, >> >> >> >> >> >> >> >> >> >> >> >>I am unable to understand the problem we are >> >> trying to solve >> >> >> >> >> >>or fabricate. My control network is IP based and IP has >> >> >> >> >> >>proven resiliency (Internet *does* work), why >> >> would I like to >> >> >> >> >> >>take control plan resiliency problem at a layer >> *above-IP* >> >> >> >> >> >>and complicate my life. Did I miss something? >> >> >> >> >> >> >> >> >> >> >> >>Thanks >> >> >> >> >> >> >> >> >> >> >> >>Regards... Zafar >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >>________________________________ >> >> >> >> >> >> >> >> >> >> >> >> From: owner-ccamp@ops.ietf.org >> >> >> >> >> >>[mailto:owner-ccamp@ops.ietf.org] >> >> >> >> >> >>On Behalf Of Kim Young Hwa >> >> >> >> >> >> Sent: Friday, October 28, 2005 6:04 AM >> >> >> >> >> >> To: ccamp@ops.ietf.org >> >> >> >> >> >> Subject: Two Drafts for Resilience of >> Control Plane >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> Dear all, >> >> >> >> >> >> >> >> >> >> >> >> I posted two drafts for the resilience >> of control plane. >> >> >> >> >> >> One is for requirements of the resilience of >> >> control plane, >> >> >> >> >> >>the other is for a protocol specification as a >> solution of >> >> >> >> >> >>that . >> >> >> >> >> >> These are now available at: >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> > >> >> >> >> >> > >> >> >> > >> >> http://www.ietf.org/internet-drafts/draft-kim-ccamp-cpr-reqts-01.tx >> >> >> > t >> >> >> >> >> > >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> > >> >> >> >> >> > >> >> >> >> > >> >> >> > >> >> > >> >> >> http://www.ietf.org/internet-drafts/draft-kim-ccamp-accp-protocol-00. >> >> t >> >> > xt >> >> >> >> >> > >> >> >> >> >> >> >> >> >> >> >> >> I want your comments. >> >> >> >> >> >> >> >> >> >> >> >> Regards >> >> >> >> >> >> >> >> >> >> >> >> Young. >> >> >> >> >> >> >> >> >> >> >> >> ===================================> >> >> Young-Hwa Kim >> >> >> >> >> >> Principal Member / Ph.D >> >> >> >> >> >> BcN Research Division, ETRI >> >> >> >> >> >> Tel: +82-42-860-5819 >> >> >> >> >> >> Fax: +82-42-860-5440 >> >> >> >> >> >> e-mail: yhwkim@etri.re.kr >> >> >> >> >> >> ===================================> >> >> >> >> >> >> >> >> >> >> >> >> > >> >> >> >> >> > >> >> >> >> > >> >> >> > >> >> > >> >> >> > >> > or >> >> >> >> >> > >> >> >> >> >> > >> >> >> >> > >> >> >> > >> >> > >> >> >> g&name=ccamp%40ops.ietf.org&fromemail=yhwkim@etri.re.kr&messageid=%3C >> >> 8 >> >> > 63 >> >> >> >> >> > >> >> >> >> >> >>0a6db-0c31-49ab-a798-13b0dda04553@etri.re.kr%3E> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> > >> >> >> >> >> > >> >> >> >> >> > >> >> >> >> >> > >> >> >> >> >> > >> >> >> >> >> > >> >> >> >> >> > __________________________________ >> >> >> >> >> > Yahoo! Mail - PC Magazine Editors' Choice 2005 >> >> >> >> >> > http://mail.yahoo.com >> >> >> >> >> > >> >> >> >> >> > >> >> >> >> >> > . >> >> >> >> >> > >> >> >> >> > >> >> >> >> > >> >> >> >> > >> >> >> > >> >> >> > >> >> > >> >> > >> >> >> > >> > Envelope-to: ccamp-data@psg.com Delivery-date: Sat, 29 Oct 2005 17:32:31 +0000 Message-ID: <3038.68.100.80.11.1130607080.squirrel@webmail.movaz.com> Date: Sat, 29 Oct 2005 13:31:20 -0400 (EDT) Subject: RE: Two Drafts for Resilience of Control Plane From: ibryskin@movaz.com To: "Drake, John E" Cc: ibryskin@movaz.com, "Zafar Ali" , drake@movaz.com, dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be, "Igor Bryskin" , "Kim Young Hwa" , ccamp@ops.ietf.org User-Agent: SquirrelMail/1.4.1 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit > Igor, > > If a node looses control plane connectivity to its adjacent nodes, then > in the interval until that connectivity is restored, the nodes adjacent > to that node will take it and its links out of the TE link state > database so that no new LSPs will be routed through that node. I never said that the problem is about new LSPs > Existing LSPS can be maintained. The endpoints of each LSP will be > informed of the control plane failure, so that they can tear the LSP down if configured to do so, after a configured interval. Here is the problem. The CP comes into play when some entity (for example, TL1 agent) issues a provisioning request on the service ingress to setup one or more LSPs. All subsequent management is provided via this ingress node. One cannot pre-configure what to do, say, on LSP egress node because all actions are service specific real-time decisions based on numerous policies (time of day, network state, identity of the service user, SLAs and many other things). In other words all operations should be controlled via ingress node. > connectivity to multiple nodes along the path of an LSP are lost, there > may be hung resources. To reclaim those resources, any node that loses > CP connectivity to an adjacent node can be configured to tear down LSPs > through that node after a configured interval. > > I am dubious the NM connectivity would exist if CP connectivity would Ø exist, so one can't resort to NM to save the day. I was talking about NMS connectivity with “live” NEs via management network > > I think we are done. > I think too. > Thanks, > > John > >> -----Original Message----- >> From: ibryskin@movaz.com [mailto:ibryskin@movaz.com] >> Sent: Saturday, October 29, 2005 7:40 AM >> To: Drake, John E >> Cc: ibryskin@movaz.com; Zafar Ali; drake@movaz.com; >> dpapadimitriou@psg.com; dimitri.papadimitriou@alcatel.be; Igor > Bryskin; >> Kim Young Hwa; ccamp@ops.ietf.org >> Subject: RE: Two Drafts for Resilience of Control Plane >> >> > >> >> Sticking to the example I described: >> >> a) absence of RSVP refreshes does not affect data plane in any way; >> >> b) use of LMP is not mandatory and, becides, I don't see now it > helps. >> >> True, the TE link could be withdrawn, however, the LSP will still > be >> >> operational >> > [JD] >> > >> > In your example, PathTear downstream and PathErr w/ state removed >> > upstream would work quite nicely. >> >> True, but it means that operator needs to issue two management > requests >> from two controllers. But this is not how control plane is supposed to >> work, isn't it? - it should be able to manage an LSP from a single >> (usually, ingress)controller. The way you described it the operator > needs >> to figure out where to go and issue these requests. And what if this > LSP >> is not an S-PVC, rather, SVC created via UNI or ENNI request? >> >> As a matter of local policy, a node >> > always has the option of tearing down LSPs through adjacent nodes > with >> > which control plane connectivity has been lost, after a configured >> > interval has elapsed. >> >> Sorry, for envirionments where control and data planes are not > congruent >> what you just said is an explicit NO-OPTION, i.e. must not be done - > you >> cannot destroy data plane just because you lost connectivity in the >> control plane. >> >> Igor > > Envelope-to: ccamp-data@psg.com Delivery-date: Sat, 29 Oct 2005 16:17:07 +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: Two Drafts for Resilience of Control Plane Date: Sat, 29 Oct 2005 12:16:00 -0400 Message-ID: Thread-Topic: Two Drafts for Resilience of Control Plane Thread-Index: AcXckpMNqIqx8cGPSn+y34NSOd+/cQAEQtAA From: "Zafar Ali \(zali\)" To: Cc: , "John E" , , , "Igor Bryskin" , "Kim Young Hwa" , =20 > -----Original Message----- > From: ibryskin@movaz.com [mailto:ibryskin@movaz.com]=20 > Sent: Saturday, October 29, 2005 10:10 AM > To: Zafar Ali (zali) > Cc: ibryskin@movaz.com; Drake@movaz.com; John E;=20 > dpapadimitriou@psg.com; dimitri.papadimitriou@alcatel.be;=20 > Igor Bryskin; Kim Young Hwa; ccamp@ops.ietf.org > Subject: RE: Two Drafts for Resilience of Control Plane >=20 > Zafar, > >> c) leave LSP as it is and wait for the dead controller to > >> be replaced or > >> repaired. This would mean the need to perform normal=20 > operations like,=20 > >> for example, monitoring of data plane alarms, changing LSP admin=20 > >> status (for example, disabling alarms on all nodes), perform power=20 > >> monitoring and equalization, perform recovery operation in=20 > case of a=20 > >> fatal data plane failure. All what depends on hop-by-hop signaling=20 > >> won't work today. > >> Don't tell me that these problems are fabricated; they are real=20 > >> because they are raised by the customers. Dimitri seems to=20 > understand=20 > >> the problem but he is saying that the CP in this case is hardly of=20 > >> any use. This IMO is a dangerous statement for the future of CP in=20 > >> non-packet environments. > >> The Management plane aficionados will jump on it and say that=20 > >> management plane does not have such a problem - NMS has a direct=20 > >> access to any NE on the network, so it can do all=20 > necessary cleanup=20 > >> no matter what happened. > >> Customers will say: "Well, if there are situations when CP=20 > suddenly=20 > >> becomes useless and we have to use management plane=20 > anyway, why would=20 > >> we use the CP in the first place?' > >> > >> Fortunately, I believe that the problems could be solved=20 > entirely via=20 > >> CP by making it more resilient. Hence, CP resilience is a good=20 > >> direction to work on within CCAMP WG > > > > Igor, > > > > W.r.t. option C, please note that traffic CANNOT be forwarded in a=20 > > "head-less mode" for a very long time . If you control=20 > network melts=20 > > or a peering controller goes down, either RSVP GR or refreshes will=20 > > take care of the clean-up of the affected RSVP states.=20 > Similarly LMP=20 > > CC SM will go down (after states are cleared, i.e.,=20 > degraded-to-down),=20 > > eventually removing the TE links from topology. > > >=20 > Sticking to the example I described: > a) absence of RSVP refreshes does not affect data plane in any way; > b) use of LMP is not mandatory and, becides, I don't see now it helps. > True, the TE link could be withdrawn, however, the LSP will=20 > still be operational Isn't the problem is at "B" only and control plane at the other node (or controller for other nodes) still working fine? If yes, local controllers will withdraw RSVP states; hence correct the data plane.=20 Thanks Regards... Zafar=20 >=20 > Igor >=20 >=20 > > Thanks > > > > Regards... Zafar > > > >> > >> Igor > >> > >> > If "Considerable period of time" is not equal to infinity, > >> then there > >> > will be an RSVP graceful restart. If a controller is > >> really and truly > >> > dead, then presumably the operator will either replace it > >> or re-assign > >> > its data-plane resources to another signaling controller. > >> In either > >> > case, there will then be an RSVP graceful restart. > >> > > >> > Thanks, > >> > > >> > John > >> > > >> > > >> > > >> >> -----Original Message----- > >> >> From: ibryskin@movaz.com [mailto:ibryskin@movaz.com] > >> >> Sent: Friday, October 28, 2005 1:00 PM > >> >> To: Drake, John E > >> >> Cc: ibryskin@movaz.com; dpapadimitriou@psg.com;=20 > >> >> dimitri.papadimitriou@alcatel.be; Igor Bryskin; Zafar Ali; > >> Kim Young > >> > Hwa; > >> >> ccamp@ops.ietf.org > >> >> Subject: RE: Two Drafts for Resilience of Control Plane > >> >> > >> >> John, > >> >> > >> >> I think you missed my point here. "Dead" controllers in=20 > my example=20 > >> >> *do > >> >> not* come back for a considerable period of time. So=20 > there are no > >> > restarts > >> >> here (graceful or not graceful) :=3D) > >> >> > >> >> Igor > >> >> > >> >> > What part of your problem, as stated below, is not > >> handled by RSVP > >> >> > graceful restart? > >> >> > > >> >> >> -----Original Message----- > >> >> >> From: ibryskin@movaz.com [mailto:ibryskin@movaz.com] > >> >> >> Sent: Friday, October 28, 2005 11:41 AM > >> >> >> To: Drake, John E > >> >> >> Cc: dpapadimitriou@psg.com; > >> dimitri.papadimitriou@alcatel.be; Igor > >> >> >> Bryskin; Zafar Ali; Kim Young Hwa; ccamp@ops.ietf.org > >> >> >> Subject: RE: Two Drafts for Resilience of Control Plane > >> >> >> > >> >> >> Hi, > >> >> >> > >> >> >> Here is one of the problems that I've been thinking for > >> a while - > >> >> > control > >> >> >> plane partitioned LSPs. Suppose one or more signaling > >> controllers > >> >> > managing > >> >> >> some LSP went out of service leaving the LSP's data > >> plane intact. > >> > As > >> >> > far > >> >> >> as the user is concerned such LSP is perfectly healthy and > >> >> > operational. > >> >> >> Such situation could last for a considerable period of > >> time. Do we > >> >> > need to > >> >> >> manage such LSP via control plane? Sure, we must be=20 > capable to=20 > >> >> >> tear > >> >> > down > >> >> >> such LSP, perform mb4b rerouting, distribute alarms between > >> >> > operational > >> >> >> controllers, signal data plane faults and perform recovery > >> > switchover, > >> >> >> modify LSP status, etc. Can we do this today? No,=20 > but with some > >> >> >> (signaling) extensions the problem I believe is > >> solvable. Is this > >> > some > >> >> >> artificial, "fabricated" problem? No, I think it is > >> real. Does it > >> > fall > >> >> >> under the control plane resilience problem space? I=20 > believe it > >> > does. > >> >> >> > >> >> >> Igor > >> >> >> > >> >> >> > I agree with Zafar and Dimitri. If someone wanted to=20 > >> >> >> > document > >> > the > >> >> > GMPLS > >> >> >> > control plane resiliency features, as was done for GMPLS > >> > addressing, > >> >> >> > that might be a useful activity. > >> >> >> > > >> >> >> >> -----Original Message----- > >> >> >> >> From: dimitri papadimitriou=20 > [mailto:dpapadimitriou@psg.com] > >> >> >> >> Sent: Friday, October 28, 2005 9:56 AM > >> >> >> >> To: Igor Bryskin > >> >> >> >> Cc: Zafar Ali (zali); Kim Young Hwa; ccamp@ops.ietf.org > >> >> >> >> Subject: Re: Two Drafts for Resilience of Control Plane > >> >> >> >> > >> >> >> >> igor - > >> >> >> >> > >> >> >> >> over time CCAMP came with a set of mechanims to > >> improve control > >> >> > plane > >> >> >> >> resilience (RSVP and LMP GR upon channel/node > >> failure) other WG > >> >> >> > protocol > >> >> >> >> work are also usable used here OSPF GR, etc. ... on the=20 > >> >> >> >> other > >> > side, > >> >> >> >> mechanism such as link bundling have built-in resilience > >> >> > capabilities > >> >> >> >> and most GMPLS control plane capabilities have=20 > been designed > >> > such > >> >> > as > >> >> >> > to > >> >> >> >> be independent of the control plane realisation (in-band, > >> >> > out-of-band, > >> >> >> >> etc.) > >> >> >> >> > >> >> >> >> so indeed i share the concern of Zafar what could=20 > we do more > >> > here > >> >> > than > >> >> >> >> document these tools and provide our experience in > >> using them; > >> >> >> >> > >> >> >> >> now, before stating there are (potential) > >> problems(s) arising - > >> >> > would > >> >> >> >> you please be more specific on what are these potential > >> >> >> >> issue(s) > >> >> >> > and/or > >> >> >> >> problems ? (not related to policy/config. - note: all the=20 > >> >> >> >> issues > >> >> > you > >> >> >> >> have pointed here below are simply policy/config specific=20 > >> >> >> >> but > >> > none > >> >> > of > >> >> >> >> them highlights a missing IP control plane > >> resiliency feature) > >> >> >> >> > >> >> >> >> thanks, > >> >> >> >> - dimitri. > >> >> >> >> > >> >> >> >> > >> >> >> >> Igor Bryskin wrote: > >> >> >> >> > >> >> >> >> > Zafar, > >> >> >> >> > > >> >> >> >> > The problem arises when the control plane is > >> decoupled from > >> >> >> >> > the data plane. The question is do we need such > >> decoupling in > >> >> >> >> > IP networks? Consider, for example, the situation when=20 > >> >> >> >> > several parallel PSC data links bundled together and=20 > >> >> >> >> > controlled by a single control channel. > >> >> >> >> > Does it mean in this case that when the control > >> channel fails > >> >> >> >> > all associated data links also fail? Do we need to > >> reroute in > >> >> >> >> > this case LSPs that use the data links? Can we > >> rely in this > >> >> >> >> > case on control plane indications to decide whether an=20 > >> >> >> >> > associated data link is healthy or not (in other > >> words, can > >> >> >> >> > we rely on RSVP Hellos or should we use, for > >> example, BTD)? > >> >> >> >> > Should we be capable to recover control=20 > channels without=20 > >> >> >> >> > disturbing data plane? I think control plane=20 > resilience is=20 > >> >> >> >> > important for all layers. You are right, Internet > >> does work, > >> >> >> >> > however, we do need for some reason TE and (fast) > >> recovery in > >> >> >> >> > IP as much as in other layers,don't we? > >> >> >> >> > > >> >> >> >> > Cheers, > >> >> >> >> > Igor > >> >> >> >> > > >> >> >> >> > --- "Zafar Ali (zali)" wrote: > >> >> >> >> > > >> >> >> >> > > >> >> >> >> >>Hi All, > >> >> >> >> >> > >> >> >> >> >>I am unable to understand the problem we are > >> trying to solve > >> >> >> >> >>or fabricate. My control network is IP based and IP has=20 > >> >> >> >> >>proven resiliency (Internet *does* work), why > >> would I like to > >> >> >> >> >>take control plan resiliency problem at a layer=20 > *above-IP*=20 > >> >> >> >> >>and complicate my life. Did I miss something? > >> >> >> >> >> > >> >> >> >> >>Thanks > >> >> >> >> >> > >> >> >> >> >>Regards... Zafar > >> >> >> >> >> > >> >> >> >> >> > >> >> >> >> >>________________________________ > >> >> >> >> >> > >> >> >> >> >> From: owner-ccamp@ops.ietf.org=20 > >> >> >> >> >>[mailto:owner-ccamp@ops.ietf.org] > >> >> >> >> >>On Behalf Of Kim Young Hwa > >> >> >> >> >> Sent: Friday, October 28, 2005 6:04 AM > >> >> >> >> >> To: ccamp@ops.ietf.org > >> >> >> >> >> Subject: Two Drafts for Resilience of=20 > Control Plane > >> >> >> >> >> > >> >> >> >> >> > >> >> >> >> >> Dear all, > >> >> >> >> >> > >> >> >> >> >> I posted two drafts for the resilience=20 > of control plane. > >> >> >> >> >> One is for requirements of the resilience of > >> control plane, > >> >> >> >> >>the other is for a protocol specification as a=20 > solution of=20 > >> >> >> >> >>that . > >> >> >> >> >> These are now available at: > >> >> >> >> >> > >> >> >> >> >> > >> >> >> >> > > >> >> >> >> > > >> >> > > >> http://www.ietf.org/internet-drafts/draft-kim-ccamp-cpr-reqts-01.tx > >> >> > t > >> >> >> >> > > >> >> >> >> >> > >> >> >> >> >> > >> >> >> >> > > >> >> >> >> > > >> >> >> > > >> >> > > >> > > >>=20 > http://www.ietf.org/internet-drafts/draft-kim-ccamp-accp-protocol-00. > >> t > >> > xt > >> >> >> >> > > >> >> >> >> >> > >> >> >> >> >> I want your comments. > >> >> >> >> >> > >> >> >> >> >> Regards > >> >> >> >> >> > >> >> >> >> >> Young. > >> >> >> >> >> > >> >> >> >> >> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D> >>=09 > Young-Hwa Kim > >> >> >> >> >> Principal Member / Ph.D > >> >> >> >> >> BcN Research Division, ETRI > >> >> >> >> >> Tel: +82-42-860-5819 > >> >> >> >> >> Fax: +82-42-860-5440 > >> >> >> >> >> e-mail: yhwkim@etri.re.kr > >> >> >> >> >> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D> >> > >> >> >> >> >> > >> >> >> >> > > >> >> >> >> > > >> >> >> > > >> >> > > >> > > >>=20 > = >> > or > >> >> >> >> > > >> >> >> >> > > >> >> >> > > >> >> > > >> > > >>=20 > = g&name=3Dccamp%40ops.ietf.org&fromemail=3Dyhwkim@etri.re.kr&messageid=3D%= 3C > >> 8 > >> > 63 > >> >> >> >> > > >> >> >> >> >>0a6db-0c31-49ab-a798-13b0dda04553@etri.re.kr%3E> > >> >> >> >> >> > >> >> >> >> >> > >> >> >> >> > > >> >> >> >> > > >> >> >> >> > > >> >> >> >> > > >> >> >> >> > > >> >> >> >> > > >> >> >> >> > __________________________________ > >> >> >> >> > Yahoo! Mail - PC Magazine Editors' Choice 2005=20 > >> >> >> >> > http://mail.yahoo.com > >> >> >> >> > > >> >> >> >> > > >> >> >> >> > . > >> >> >> >> > > >> >> >> > > >> >> >> > > >> >> >> > > >> >> > > >> >> > > >> > > >> > > >> > > >=20 Envelope-to: ccamp-data@psg.com Delivery-date: Sat, 29 Oct 2005 15:39:25 +0000 Message-ID: <43639774.3000201@psg.com> Date: Sat, 29 Oct 2005 17:38:28 +0200 From: dimitri papadimitriou Reply-To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.11) Gecko/20050728 MIME-Version: 1.0 To: ibryskin@movaz.com CC: "Drake, John E" , dimitri.papadimitriou@alcatel.be, Igor Bryskin , Zafar Ali , Kim Young Hwa , ccamp@ops.ietf.org Subject: Re: Two Drafts for Resilience of Control Plane Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit igor - see in-line >>Igor, >> >>What you wrote was: >> >>"Suppose one or more signaling controllers managing some LSP went out of >>service leaving the LSP's data plane intact. As far as the user is >>concerned such LSP is perfectly healthy and operational. Such situation >>could last for a considerable period of time." >> >>What part of this is *not* handled by RSVP graceful restart? >> >>In your subsequent e-mail, you then changed the problem statement to: >> >>""Dead" controllers in my example *do not* come back for a considerable >>period of time. So there are no restarts here (graceful or not >>graceful)" > > > Sorry, I don’t see how I have changed the problem statement. I was and am > saying that while controllers are out of service for a considerable time > (day? two days? week?) the question is what to do with active LSPs > associated with them? you should take this as the initial problem - is there something wrong with that situation as transient ? and is the objective leave B dead for an non-finite period of time because in *any case* you will have to replace B to be able to provision new LSPs crossing this node ? > Let’s consider an example: > > > A----B------C-----D > } | > E-----F-----H-----K > > Suppose we have an LSP A-B-C-D carrying user traffic and a controller > managing node B went out of service. The question is what to do with this > LSP until the controller comes back? The operator may decide: > a) simply not wait and delete the LSP. Normal LSP teardown – PathTear > originated on the ingress controller- won’t work because PathTear won’t > make it to controllers managing nodes C and D, leaving (very expensive in > the optical layer) resources associated with the LSP allocated and not > available for other LSPs; > b) reroute via mb4b the LSP onto alternative path A-E-H-K-D –won’t work > for the same reason as in a) what does not work ? the release of the unused resource so once notified of the failed controller and re-routing achieved trigger a PathErr with PSR flag and you are done (so its a policy configuration) > c) leave LSP as it is and wait for the dead controller to be replaced or > repaired. This would mean the need to perform normal operations like, for > example, monitoring of data plane alarms, changing LSP admin status (for > example, disabling alarms on all nodes), perform power monitoring and > equalization, perform recovery operation in case of a fatal data plane > failure. All what depends on hop-by-hop signaling won’t work today. > Don’t tell me that these problems are fabricated; they are real because > they are raised by the customers. Dimitri seems to understand the problem > but he is saying that the CP in this case is hardly of any use. just to clarify what i am saying here is that you can not expect a collaboration in the resiliency process from a controller that is down over a longer period than the repairing phase - now in any case the dead CP will need to be replaced at some point in time; hence, whatever the resiliency mechanism you are going to define it is certainly not going to resurrect your dead CP and make possible the re-use of the node's resources hence, you should first correctly position the problem instead of trying to find unadapted workarounds or missing functionality; moreover here, as the problem can be solved what can be additionally expected from the CP ? > This IMO > is a dangerous statement for the future of CP in non-packet environments. what's more dangerous is to continuously claim that the GMPLS CP is not resilient because of incomplete policy configuration (and that more work is still needed) > The Management plane aficionados will jump on it and say that management > plane does not have such a problem – NMS has a direct access to any NE on > the network, so it can do all necessary cleanup no matter what happened. > Customers will say: “Well, if there are situations when CP suddenly > becomes useless and we have to use management plane anyway, why would we > use the CP in the first place?’ you should ask the question is the other way around - why do you consider a CP like a distributed MP ? > Fortunately, I believe that the problems could be solved entirely via CP > by making it more resilient. Hence, CP resilience is a good direction to > work on within CCAMP WG indeed, document the resiliency mechanisms that the CCAMP WG and others have defined over time and a GMPLS CP can make use to address such problems may be advisable; but except if GMPLS is showing real gaps in terms of resiliency there is no need to initiate new protocol work thanks, - dimitri. > Igor > > >>If "Considerable period of time" is not equal to infinity, then there >>will be an RSVP graceful restart. If a controller is really and truly >>dead, then presumably the operator will either replace it or re-assign >>its data-plane resources to another signaling controller. In either >>case, there will then be an RSVP graceful restart. >> >>Thanks, >> >>John >> >> >> >> >>>-----Original Message----- >>>From: ibryskin@movaz.com [mailto:ibryskin@movaz.com] >>>Sent: Friday, October 28, 2005 1:00 PM >>>To: Drake, John E >>>Cc: ibryskin@movaz.com; dpapadimitriou@psg.com; >>>dimitri.papadimitriou@alcatel.be; Igor Bryskin; Zafar Ali; Kim Young >> >>Hwa; >> >>>ccamp@ops.ietf.org >>>Subject: RE: Two Drafts for Resilience of Control Plane >>> >>>John, >>> >>>I think you missed my point here. "Dead" controllers in my example *do >>>not* come back for a considerable period of time. So there are no >> >>restarts >> >>>here (graceful or not graceful) :=) >>> >>>Igor >>> >>> >>>>What part of your problem, as stated below, is not handled by RSVP >>>>graceful restart? >>>> >>>> >>>>>-----Original Message----- >>>>>From: ibryskin@movaz.com [mailto:ibryskin@movaz.com] >>>>>Sent: Friday, October 28, 2005 11:41 AM >>>>>To: Drake, John E >>>>>Cc: dpapadimitriou@psg.com; dimitri.papadimitriou@alcatel.be; Igor >>>>>Bryskin; Zafar Ali; Kim Young Hwa; ccamp@ops.ietf.org >>>>>Subject: RE: Two Drafts for Resilience of Control Plane >>>>> >>>>>Hi, >>>>> >>>>>Here is one of the problems that I've been thinking for a while - >>>> >>>>control >>>> >>>>>plane partitioned LSPs. Suppose one or more signaling controllers >>>> >>>>managing >>>> >>>>>some LSP went out of service leaving the LSP's data plane intact. >> >>As >> >>>>far >>>> >>>>>as the user is concerned such LSP is perfectly healthy and >>>> >>>>operational. >>>> >>>>>Such situation could last for a considerable period of time. Do we >>>> >>>>need to >>>> >>>>>manage such LSP via control plane? Sure, we must be capable to tear >>>> >>>>down >>>> >>>>>such LSP, perform mb4b rerouting, distribute alarms between >>>> >>>>operational >>>> >>>>>controllers, signal data plane faults and perform recovery >> >>switchover, >> >>>>>modify LSP status, etc. Can we do this today? No, but with some >>>>>(signaling) extensions the problem I believe is solvable. Is this >> >>some >> >>>>>artificial, "fabricated" problem? No, I think it is real. Does it >> >>fall >> >>>>>under the control plane resilience problem space? I believe it >> >>does. >> >>>>>Igor >>>>> >>>>> >>>>>>I agree with Zafar and Dimitri. If someone wanted to document >> >>the >> >>>>GMPLS >>>> >>>>>>control plane resiliency features, as was done for GMPLS >> >>addressing, >> >>>>>>that might be a useful activity. >>>>>> >>>>>> >>>>>>>-----Original Message----- >>>>>>>From: dimitri papadimitriou [mailto:dpapadimitriou@psg.com] >>>>>>>Sent: Friday, October 28, 2005 9:56 AM >>>>>>>To: Igor Bryskin >>>>>>>Cc: Zafar Ali (zali); Kim Young Hwa; ccamp@ops.ietf.org >>>>>>>Subject: Re: Two Drafts for Resilience of Control Plane >>>>>>> >>>>>>>igor - >>>>>>> >>>>>>>over time CCAMP came with a set of mechanims to improve control >>>> >>>>plane >>>> >>>>>>>resilience (RSVP and LMP GR upon channel/node failure) other WG >>>>>> >>>>>>protocol >>>>>> >>>>>>>work are also usable used here OSPF GR, etc. ... on the other >> >>side, >> >>>>>>>mechanism such as link bundling have built-in resilience >>>> >>>>capabilities >>>> >>>>>>>and most GMPLS control plane capabilities have been designed >> >>such >> >>>>as >>>> >>>>>>to >>>>>> >>>>>>>be independent of the control plane realisation (in-band, >>>> >>>>out-of-band, >>>> >>>>>>>etc.) >>>>>>> >>>>>>>so indeed i share the concern of Zafar what could we do more >> >>here >> >>>>than >>>> >>>>>>>document these tools and provide our experience in using them; >>>>>>> >>>>>>>now, before stating there are (potential) problems(s) arising - >>>> >>>>would >>>> >>>>>>>you please be more specific on what are these potential issue(s) >>>>>> >>>>>>and/or >>>>>> >>>>>>>problems ? (not related to policy/config. - note: all the issues >>>> >>>>you >>>> >>>>>>>have pointed here below are simply policy/config specific but >> >>none >> >>>>of >>>> >>>>>>>them highlights a missing IP control plane resiliency feature) >>>>>>> >>>>>>>thanks, >>>>>>>- dimitri. >>>>>>> >>>>>>> >>>>>>>Igor Bryskin wrote: >>>>>>> >>>>>>> >>>>>>>>Zafar, >>>>>>>> >>>>>>>>The problem arises when the control plane is decoupled >>>>>>>>from the data plane. The question is do we need such >>>>>>>>decoupling in IP networks? Consider, for example, the >>>>>>>>situation when several parallel PSC data links bundled >>>>>>>>together and controlled by a single control channel. >>>>>>>>Does it mean in this case that when the control >>>>>>>>channel fails all associated data links also fail? Do >>>>>>>>we need to reroute in this case LSPs that use the data >>>>>>>>links? Can we rely in this case on control plane >>>>>>>>indications to decide whether an associated data link >>>>>>>>is healthy or not (in other words, can we rely on RSVP >>>>>>>>Hellos or should we use, for example, BTD)? Should we >>>>>>>>be capable to recover control channels without >>>>>>>>disturbing data plane? I think control plane >>>>>>>>resilience is important for all layers. You are right, >>>>>>>>Internet does work, however, we do need for some >>>>>>>>reason TE and (fast) recovery in IP as much as in >>>>>>>>other layers,don't we? >>>>>>>> >>>>>>>>Cheers, >>>>>>>>Igor >>>>>>>> >>>>>>>>--- "Zafar Ali (zali)" wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>Hi All, >>>>>>>>> >>>>>>>>>I am unable to understand the problem we are trying >>>>>>>>>to solve or >>>>>>>>>fabricate. My control network is IP based and IP has >>>>>>>>>proven resiliency >>>>>>>>>(Internet *does* work), why would I like to take >>>>>>>>>control plan resiliency >>>>>>>>>problem at a layer *above-IP* and complicate my >>>>>>>>>life. Did I miss >>>>>>>>>something? >>>>>>>>> >>>>>>>>>Thanks >>>>>>>>> >>>>>>>>>Regards... Zafar >>>>>>>>> >>>>>>>>> >>>>>>>>>________________________________ >>>>>>>>> >>>>>>>>> From: owner-ccamp@ops.ietf.org >>>>>>>>>[mailto:owner-ccamp@ops.ietf.org] >>>>>>>>>On Behalf Of Kim Young Hwa >>>>>>>>> Sent: Friday, October 28, 2005 6:04 AM >>>>>>>>> To: ccamp@ops.ietf.org >>>>>>>>> Subject: Two Drafts for Resilience of Control Plane >>>>>>>>> >>>>>>>>> >>>>>>>>> Dear all, >>>>>>>>> >>>>>>>>> I posted two drafts for the resilience of control >>>>>>>>>plane. >>>>>>>>> One is for requirements of the resilience of >>>>>>>>>control plane, the >>>>>>>>>other is for a protocol specification as a solution >>>>>>>>>of that . >>>>>>>>> These are now available at: >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>http://www.ietf.org/internet-drafts/draft-kim-ccamp-cpr-reqts-01.txt >>>> >>>>>>>>> >>>>>>>> >>http://www.ietf.org/internet-drafts/draft-kim-ccamp-accp-protocol-00.txt >> >>>>>>>>> I want your comments. >>>>>>>>> >>>>>>>>> Regards >>>>>>>>> >>>>>>>>> Young. >>>>>>>>> >>>>>>>>> ===================================> >> Young-Hwa Kim >>>>>>>>> Principal Member / Ph.D >>>>>>>>> BcN Research Division, ETRI >>>>>>>>> Tel: +82-42-860-5819 >>>>>>>>> Fax: +82-42-860-5440 >>>>>>>>> e-mail: yhwkim@etri.re.kr >>>>>>>>> ===================================> >> >>>>>>>>> >>>>>>>> >>> >>>>>>>> >>g&name=ccamp%40ops.ietf.org&fromemail=yhwkim@etri.re.kr&messageid=%3C863 >> >>>>>>>>>0a6db-0c31-49ab-a798-13b0dda04553@etri.re.kr%3E> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>__________________________________ >>>>>>>>Yahoo! Mail - PC Magazine Editors' Choice 2005 >>>>>>>>http://mail.yahoo.com >>>>>>>> >>>>>>>> >>>>>>>>. >>>>>>>> >>>>>> >>>>>> >>>>>> >>>> >> > > > . > Envelope-to: ccamp-data@psg.com Delivery-date: Sat, 29 Oct 2005 15:36:28 +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: Two Drafts for Resilience of Control Plane Date: Sat, 29 Oct 2005 08:35:53 -0700 Message-ID: <626FC7C6A97381468FB872072AB5DDC8369713@XCH-SW-42.sw.nos.boeing.com> Thread-Topic: Two Drafts for Resilience of Control Plane Thread-Index: AcXclqb/BJdCG3rVRGauipftnzFUJwABGQIQ From: "Drake, John E" To: Cc: "Zafar Ali" , , , , "Igor Bryskin" , "Kim Young Hwa" , Igor, If a node looses control plane connectivity to its adjacent nodes, then in the interval until that connectivity is restored, the nodes adjacent to that node will take it and its links out of the TE link state database so that no new LSPs will be routed through that node. Existing LSPS can be maintained. The endpoints of each LSP will be informed of the control plane failure, so that they can tear the LSP down if configured to do so, after a configured interval. If connectivity to multiple nodes along the path of an LSP are lost, there may be hung resources. To reclaim those resources, any node that loses CP connectivity to an adjacent node can be configured to tear down LSPs through that node after a configured interval. I am dubious the NM connectivity would exist if CP connectivity would exist, so one can't resort to NM to save the day. I think we are done. Thanks, John=20 > -----Original Message----- > From: ibryskin@movaz.com [mailto:ibryskin@movaz.com] > Sent: Saturday, October 29, 2005 7:40 AM > To: Drake, John E > Cc: ibryskin@movaz.com; Zafar Ali; drake@movaz.com; > dpapadimitriou@psg.com; dimitri.papadimitriou@alcatel.be; Igor Bryskin; > Kim Young Hwa; ccamp@ops.ietf.org > Subject: RE: Two Drafts for Resilience of Control Plane >=20 > > > >> Sticking to the example I described: > >> a) absence of RSVP refreshes does not affect data plane in any way; > >> b) use of LMP is not mandatory and, becides, I don't see now it helps. > >> True, the TE link could be withdrawn, however, the LSP will still be > >> operational > > [JD] > > > > In your example, PathTear downstream and PathErr w/ state removed > > upstream would work quite nicely. >=20 > True, but it means that operator needs to issue two management requests > from two controllers. But this is not how control plane is supposed to > work, isn't it? - it should be able to manage an LSP from a single > (usually, ingress)controller. The way you described it the operator needs > to figure out where to go and issue these requests. And what if this LSP > is not an S-PVC, rather, SVC created via UNI or ENNI request? >=20 > As a matter of local policy, a node > > always has the option of tearing down LSPs through adjacent nodes with > > which control plane connectivity has been lost, after a configured > > interval has elapsed. >=20 > Sorry, for envirionments where control and data planes are not congruent > what you just said is an explicit NO-OPTION, i.e. must not be done - you > cannot destroy data plane just because you lost connectivity in the > control plane. >=20 > Igor Envelope-to: ccamp-data@psg.com Delivery-date: Sat, 29 Oct 2005 14:42:42 +0000 Message-ID: <3505.68.100.80.11.1130596801.squirrel@webmail.movaz.com> Date: Sat, 29 Oct 2005 10:40:01 -0400 (EDT) Subject: RE: Two Drafts for Resilience of Control Plane From: ibryskin@movaz.com To: "Drake, John E" Cc: ibryskin@movaz.com, "Zafar Ali" , drake@movaz.com, dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be, "Igor Bryskin" , "Kim Young Hwa" , ccamp@ops.ietf.org User-Agent: SquirrelMail/1.4.1 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit > >> Sticking to the example I described: >> a) absence of RSVP refreshes does not affect data plane in any way; >> b) use of LMP is not mandatory and, becides, I don't see now it helps. >> True, the TE link could be withdrawn, however, the LSP will still be >> operational > [JD] > > In your example, PathTear downstream and PathErr w/ state removed > upstream would work quite nicely. True, but it means that operator needs to issue two management requests from two controllers. But this is not how control plane is supposed to work, isn't it? - it should be able to manage an LSP from a single (usually, ingress)controller. The way you described it the operator needs to figure out where to go and issue these requests. And what if this LSP is not an S-PVC, rather, SVC created via UNI or ENNI request? As a matter of local policy, a node > always has the option of tearing down LSPs through adjacent nodes with > which control plane connectivity has been lost, after a configured > interval has elapsed. Sorry, for envirionments where control and data planes are not congruent what you just said is an explicit NO-OPTION, i.e. must not be done - you cannot destroy data plane just because you lost connectivity in the control plane. Igor Envelope-to: ccamp-data@psg.com Delivery-date: Sat, 29 Oct 2005 14:21:38 +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: Two Drafts for Resilience of Control Plane Date: Sat, 29 Oct 2005 07:21:20 -0700 Message-ID: <626FC7C6A97381468FB872072AB5DDC8369712@XCH-SW-42.sw.nos.boeing.com> Thread-Topic: Two Drafts for Resilience of Control Plane Thread-Index: AcXckoR17u8i/c1wQ3K2pzKwCgkbiQAAJz1w From: "Drake, John E" To: , "Zafar Ali \(zali\)" Cc: , , , "Igor Bryskin" , "Kim Young Hwa" , > Sticking to the example I described: > a) absence of RSVP refreshes does not affect data plane in any way; > b) use of LMP is not mandatory and, becides, I don't see now it helps. > True, the TE link could be withdrawn, however, the LSP will still be > operational [JD]=20 In your example, PathTear downstream and PathErr w/ state removed upstream would work quite nicely. As a matter of local policy, a node always has the option of tearing down LSPs through adjacent nodes with which control plane connectivity has been lost, after a configured interval has elapsed. Envelope-to: ccamp-data@psg.com Delivery-date: Sat, 29 Oct 2005 14:19:32 +0000 Message-ID: <3450.68.100.80.11.1130595561.squirrel@webmail.movaz.com> Date: Sat, 29 Oct 2005 10:19:21 -0400 (EDT) Subject: RE: Two Drafts for Resilience of Control Plane From: ibryskin@movaz.com To: "Drake, John E" Cc: ibryskin@movaz.com, dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be, "Igor Bryskin" , "Zafar Ali" , "Kim Young Hwa" , ccamp@ops.ietf.org User-Agent: SquirrelMail/1.4.1 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit John, > Igor, > > You haven't convinced me that there is a real problem here that is not > addressed by the combination of the existing GMPLS resilience mechanisms > and a robust implementation of those mechanisms. What exactly I failed to convince you: a) the example is not real problem -- I am telling you that this is the problem raised by the customers, how more real it could be? b) the problem cannot ne solved by existing machinery --- so I described in details the problem, please, tell me how I can solve it. Have a great weekend. Igor > > As I said yesterday, an I-D that enumerated all of the resilience > mechanisms might be a useful thing, specifically as a primer. > > Thanks, > > John > >> -----Original Message----- >> From: ibryskin@movaz.com [mailto:ibryskin@movaz.com] >> Sent: Saturday, October 29, 2005 6:38 AM >> To: Drake, John E >> Cc: ibryskin@movaz.com; dpapadimitriou@psg.com; >> dimitri.papadimitriou@alcatel.be; Igor Bryskin; Zafar Ali; Kim Young > Hwa; >> ccamp@ops.ietf.org >> Subject: RE: Two Drafts for Resilience of Control Plane >> >> John, >> >> See in line. >> >> Igor >> >> > Igor, >> > >> > What you wrote was: >> > >> > "Suppose one or more signaling controllers managing some LSP went > out of >> > service leaving the LSP's data plane intact. As far as the user is >> > concerned such LSP is perfectly healthy and operational. Such > situation >> > could last for a considerable period of time." >> > >> > What part of this is *not* handled by RSVP graceful restart? >> > >> > In your subsequent e-mail, you then changed the problem statement > to: >> > >> > ""Dead" controllers in my example *do not* come back for a > considerable >> > period of time. So there are no restarts here (graceful or not >> > graceful)" >> >> Sorry, I don't see how I have changed the problem statement. I was and > am >> saying that while controllers are out of service for a considerable > time >> (day? two days? week?) the question is what to do with active LSPs >> associated with them? Let's consider an example: >> >> >> A----B------C-----D >> } | >> E-----F-----H-----K >> >> Suppose we have an LSP A-B-C-D carrying user traffic and a controller >> managing node B went out of service. The question is what to do with > this >> LSP until the controller comes back? The operator may decide: >> a) simply not wait and delete the LSP. Normal LSP teardown - > PathTear >> originated on the ingress controller- won't work because PathTear > won't >> make it to controllers managing nodes C and D, leaving (very expensive > in >> the optical layer) resources associated with the LSP allocated and not >> available for other LSPs; >> b) reroute via mb4b the LSP onto alternative path A-E-H-K-D -won't > work >> for the same reason as in a) >> c) leave LSP as it is and wait for the dead controller to be > replaced >> or >> repaired. This would mean the need to perform normal operations like, > for >> example, monitoring of data plane alarms, changing LSP admin status > (for >> example, disabling alarms on all nodes), perform power monitoring and >> equalization, perform recovery operation in case of a fatal data plane >> failure. All what depends on hop-by-hop signaling won't work today. >> Don't tell me that these problems are fabricated; they are real > because >> they are raised by the customers. Dimitri seems to understand the > problem >> but he is saying that the CP in this case is hardly of any use. This > IMO >> is a dangerous statement for the future of CP in non-packet > environments. >> The Management plane aficionados will jump on it and say that > management >> plane does not have such a problem - NMS has a direct access to any NE > on >> the network, so it can do all necessary cleanup no matter what > happened. >> Customers will say: "Well, if there are situations when CP suddenly >> becomes useless and we have to use management plane anyway, why would > we >> use the CP in the first place?' >> >> Fortunately, I believe that the problems could be solved entirely via > CP >> by making it more resilient. Hence, CP resilience is a good direction > to >> work on within CCAMP WG >> >> Igor >> >> > If "Considerable period of time" is not equal to infinity, then > there >> > will be an RSVP graceful restart. If a controller is really and > truly >> > dead, then presumably the operator will either replace it or > re-assign >> > its data-plane resources to another signaling controller. In either >> > case, there will then be an RSVP graceful restart. >> > >> > Thanks, >> > >> > John >> > >> > >> > >> >> -----Original Message----- >> >> From: ibryskin@movaz.com [mailto:ibryskin@movaz.com] >> >> Sent: Friday, October 28, 2005 1:00 PM >> >> To: Drake, John E >> >> Cc: ibryskin@movaz.com; dpapadimitriou@psg.com; >> >> dimitri.papadimitriou@alcatel.be; Igor Bryskin; Zafar Ali; Kim > Young >> > Hwa; >> >> ccamp@ops.ietf.org >> >> Subject: RE: Two Drafts for Resilience of Control Plane >> >> >> >> John, >> >> >> >> I think you missed my point here. "Dead" controllers in my example > *do >> >> not* come back for a considerable period of time. So there are no >> > restarts >> >> here (graceful or not graceful) :=) >> >> >> >> Igor >> >> >> >> > What part of your problem, as stated below, is not handled by > RSVP >> >> > graceful restart? >> >> > >> >> >> -----Original Message----- >> >> >> From: ibryskin@movaz.com [mailto:ibryskin@movaz.com] >> >> >> Sent: Friday, October 28, 2005 11:41 AM >> >> >> To: Drake, John E >> >> >> Cc: dpapadimitriou@psg.com; dimitri.papadimitriou@alcatel.be; > Igor >> >> >> Bryskin; Zafar Ali; Kim Young Hwa; ccamp@ops.ietf.org >> >> >> Subject: RE: Two Drafts for Resilience of Control Plane >> >> >> >> >> >> Hi, >> >> >> >> >> >> Here is one of the problems that I've been thinking for a while > - >> >> > control >> >> >> plane partitioned LSPs. Suppose one or more signaling > controllers >> >> > managing >> >> >> some LSP went out of service leaving the LSP's data plane > intact. >> > As >> >> > far >> >> >> as the user is concerned such LSP is perfectly healthy and >> >> > operational. >> >> >> Such situation could last for a considerable period of time. Do > we >> >> > need to >> >> >> manage such LSP via control plane? Sure, we must be capable to > tear >> >> > down >> >> >> such LSP, perform mb4b rerouting, distribute alarms between >> >> > operational >> >> >> controllers, signal data plane faults and perform recovery >> > switchover, >> >> >> modify LSP status, etc. Can we do this today? No, but with some >> >> >> (signaling) extensions the problem I believe is solvable. Is > this >> > some >> >> >> artificial, "fabricated" problem? No, I think it is real. Does > it >> > fall >> >> >> under the control plane resilience problem space? I believe it >> > does. >> >> >> >> >> >> Igor >> >> >> >> >> >> > I agree with Zafar and Dimitri. If someone wanted to document >> > the >> >> > GMPLS >> >> >> > control plane resiliency features, as was done for GMPLS >> > addressing, >> >> >> > that might be a useful activity. >> >> >> > >> >> >> >> -----Original Message----- >> >> >> >> From: dimitri papadimitriou [mailto:dpapadimitriou@psg.com] >> >> >> >> Sent: Friday, October 28, 2005 9:56 AM >> >> >> >> To: Igor Bryskin >> >> >> >> Cc: Zafar Ali (zali); Kim Young Hwa; ccamp@ops.ietf.org >> >> >> >> Subject: Re: Two Drafts for Resilience of Control Plane >> >> >> >> >> >> >> >> igor - >> >> >> >> >> >> >> >> over time CCAMP came with a set of mechanims to improve > control >> >> > plane >> >> >> >> resilience (RSVP and LMP GR upon channel/node failure) other > WG >> >> >> > protocol >> >> >> >> work are also usable used here OSPF GR, etc. ... on the other >> > side, >> >> >> >> mechanism such as link bundling have built-in resilience >> >> > capabilities >> >> >> >> and most GMPLS control plane capabilities have been designed >> > such >> >> > as >> >> >> > to >> >> >> >> be independent of the control plane realisation (in-band, >> >> > out-of-band, >> >> >> >> etc.) >> >> >> >> >> >> >> >> so indeed i share the concern of Zafar what could we do more >> > here >> >> > than >> >> >> >> document these tools and provide our experience in using > them; >> >> >> >> >> >> >> >> now, before stating there are (potential) problems(s) arising > - >> >> > would >> >> >> >> you please be more specific on what are these potential > issue(s) >> >> >> > and/or >> >> >> >> problems ? (not related to policy/config. - note: all the > issues >> >> > you >> >> >> >> have pointed here below are simply policy/config specific but >> > none >> >> > of >> >> >> >> them highlights a missing IP control plane resiliency > feature) >> >> >> >> >> >> >> >> thanks, >> >> >> >> - dimitri. >> >> >> >> >> >> >> >> >> >> >> >> Igor Bryskin wrote: >> >> >> >> >> >> >> >> > Zafar, >> >> >> >> > >> >> >> >> > The problem arises when the control plane is decoupled >> >> >> >> > from the data plane. The question is do we need such >> >> >> >> > decoupling in IP networks? Consider, for example, the >> >> >> >> > situation when several parallel PSC data links bundled >> >> >> >> > together and controlled by a single control channel. >> >> >> >> > Does it mean in this case that when the control >> >> >> >> > channel fails all associated data links also fail? Do >> >> >> >> > we need to reroute in this case LSPs that use the data >> >> >> >> > links? Can we rely in this case on control plane >> >> >> >> > indications to decide whether an associated data link >> >> >> >> > is healthy or not (in other words, can we rely on RSVP >> >> >> >> > Hellos or should we use, for example, BTD)? Should we >> >> >> >> > be capable to recover control channels without >> >> >> >> > disturbing data plane? I think control plane >> >> >> >> > resilience is important for all layers. You are right, >> >> >> >> > Internet does work, however, we do need for some >> >> >> >> > reason TE and (fast) recovery in IP as much as in >> >> >> >> > other layers,don't we? >> >> >> >> > >> >> >> >> > Cheers, >> >> >> >> > Igor >> >> >> >> > >> >> >> >> > --- "Zafar Ali (zali)" wrote: >> >> >> >> > >> >> >> >> > >> >> >> >> >>Hi All, >> >> >> >> >> >> >> >> >> >>I am unable to understand the problem we are trying >> >> >> >> >>to solve or >> >> >> >> >>fabricate. My control network is IP based and IP has >> >> >> >> >>proven resiliency >> >> >> >> >>(Internet *does* work), why would I like to take >> >> >> >> >>control plan resiliency >> >> >> >> >>problem at a layer *above-IP* and complicate my >> >> >> >> >>life. Did I miss >> >> >> >> >>something? >> >> >> >> >> >> >> >> >> >>Thanks >> >> >> >> >> >> >> >> >> >>Regards... Zafar >> >> >> >> >> >> >> >> >> >> >> >> >> >> >>________________________________ >> >> >> >> >> >> >> >> >> >> From: owner-ccamp@ops.ietf.org >> >> >> >> >>[mailto:owner-ccamp@ops.ietf.org] >> >> >> >> >>On Behalf Of Kim Young Hwa >> >> >> >> >> Sent: Friday, October 28, 2005 6:04 AM >> >> >> >> >> To: ccamp@ops.ietf.org >> >> >> >> >> Subject: Two Drafts for Resilience of Control Plane >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> Dear all, >> >> >> >> >> >> >> >> >> >> I posted two drafts for the resilience of control >> >> >> >> >>plane. >> >> >> >> >> One is for requirements of the resilience of >> >> >> >> >>control plane, the >> >> >> >> >>other is for a protocol specification as a solution >> >> >> >> >>of that . >> >> >> >> >> These are now available at: >> >> >> >> >> >> >> >> >> >> >> >> >> >> > >> >> >> >> > >> >> > > http://www.ietf.org/internet-drafts/draft-kim-ccamp-cpr-reqts-01.txt >> >> >> >> > >> >> >> >> >> >> >> >> >> >> >> >> >> >> > >> >> >> >> > >> >> >> > >> >> > >> > > http://www.ietf.org/internet-drafts/draft-kim-ccamp-accp-protocol-00.txt >> >> >> >> > >> >> >> >> >> >> >> >> >> >> I want your comments. >> >> >> >> >> >> >> >> >> >> Regards >> >> >> >> >> >> >> >> >> >> Young. >> >> >> >> >> >> >> >> >> >> ===================================> >> Young-Hwa Kim >> >> >> >> >> Principal Member / Ph.D >> >> >> >> >> BcN Research Division, ETRI >> >> >> >> >> Tel: +82-42-860-5819 >> >> >> >> >> Fax: +82-42-860-5440 >> >> >> >> >> e-mail: yhwkim@etri.re.kr >> >> >> >> >> ===================================> >> >> >> >> >> >> >> >> >> >> > >> >> >> >> > >> >> >> > >> >> > >> > > > >> >> >> > >> >> >> >> > >> >> >> > >> >> > >> > > g&name=ccamp%40ops.ietf.org&fromemail=yhwkim@etri.re.kr&messageid=%3C863 >> >> >> >> > >> >> >> >> >>0a6db-0c31-49ab-a798-13b0dda04553@etri.re.kr%3E> >> >> >> >> >> >> >> >> >> >> >> >> >> >> > >> >> >> >> > >> >> >> >> > >> >> >> >> > >> >> >> >> > >> >> >> >> > >> >> >> >> > __________________________________ >> >> >> >> > Yahoo! Mail - PC Magazine Editors' Choice 2005 >> >> >> >> > http://mail.yahoo.com >> >> >> >> > >> >> >> >> > >> >> >> >> > . >> >> >> >> > >> >> >> > >> >> >> > >> >> >> > >> >> > >> >> > >> > >> > > > Envelope-to: ccamp-data@psg.com Delivery-date: Sat, 29 Oct 2005 14:10:53 +0000 Message-ID: <3445.68.100.80.11.1130595025.squirrel@webmail.movaz.com> Date: Sat, 29 Oct 2005 10:10:25 -0400 (EDT) Subject: RE: Two Drafts for Resilience of Control Plane From: ibryskin@movaz.com To: "Zafar Ali (zali)" Cc: ibryskin@movaz.com, Drake@movaz.com, "John E" , dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be, "Igor Bryskin" , "Kim Young Hwa" , ccamp@ops.ietf.org User-Agent: SquirrelMail/1.4.1 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit Zafar, >> c) leave LSP as it is and wait for the dead controller to >> be replaced or >> repaired. This would mean the need to perform normal >> operations like, for example, monitoring of data plane >> alarms, changing LSP admin status (for example, disabling >> alarms on all nodes), perform power monitoring and >> equalization, perform recovery operation in case of a fatal >> data plane failure. All what depends on hop-by-hop signaling >> won't work today. >> Don't tell me that these problems are fabricated; they are >> real because they are raised by the customers. Dimitri seems >> to understand the problem but he is saying that the CP in >> this case is hardly of any use. This IMO is a dangerous >> statement for the future of CP in non-packet environments. >> The Management plane aficionados will jump on it and say that >> management plane does not have such a problem - NMS has a >> direct access to any NE on the network, so it can do all >> necessary cleanup no matter what happened. >> Customers will say: "Well, if there are situations when CP >> suddenly becomes useless and we have to use management plane >> anyway, why would we use the CP in the first place?' >> >> Fortunately, I believe that the problems could be solved >> entirely via CP by making it more resilient. Hence, CP >> resilience is a good direction to work on within CCAMP WG > > Igor, > > W.r.t. option C, please note that traffic CANNOT be forwarded in a > "head-less mode" for a very long time . If you control network melts or > a peering controller goes down, either RSVP GR or refreshes will take > care of the clean-up of the affected RSVP states. Similarly LMP CC SM > will go down (after states are cleared, i.e., degraded-to-down), > eventually removing the TE links from topology. > Sticking to the example I described: a) absence of RSVP refreshes does not affect data plane in any way; b) use of LMP is not mandatory and, becides, I don't see now it helps. True, the TE link could be withdrawn, however, the LSP will still be operational Igor > Thanks > > Regards... Zafar > >> >> Igor >> >> > If "Considerable period of time" is not equal to infinity, >> then there >> > will be an RSVP graceful restart. If a controller is >> really and truly >> > dead, then presumably the operator will either replace it >> or re-assign >> > its data-plane resources to another signaling controller. >> In either >> > case, there will then be an RSVP graceful restart. >> > >> > Thanks, >> > >> > John >> > >> > >> > >> >> -----Original Message----- >> >> From: ibryskin@movaz.com [mailto:ibryskin@movaz.com] >> >> Sent: Friday, October 28, 2005 1:00 PM >> >> To: Drake, John E >> >> Cc: ibryskin@movaz.com; dpapadimitriou@psg.com; >> >> dimitri.papadimitriou@alcatel.be; Igor Bryskin; Zafar Ali; >> Kim Young >> > Hwa; >> >> ccamp@ops.ietf.org >> >> Subject: RE: Two Drafts for Resilience of Control Plane >> >> >> >> John, >> >> >> >> I think you missed my point here. "Dead" controllers in my example >> >> *do >> >> not* come back for a considerable period of time. So there are no >> > restarts >> >> here (graceful or not graceful) :=) >> >> >> >> Igor >> >> >> >> > What part of your problem, as stated below, is not >> handled by RSVP >> >> > graceful restart? >> >> > >> >> >> -----Original Message----- >> >> >> From: ibryskin@movaz.com [mailto:ibryskin@movaz.com] >> >> >> Sent: Friday, October 28, 2005 11:41 AM >> >> >> To: Drake, John E >> >> >> Cc: dpapadimitriou@psg.com; >> dimitri.papadimitriou@alcatel.be; Igor >> >> >> Bryskin; Zafar Ali; Kim Young Hwa; ccamp@ops.ietf.org >> >> >> Subject: RE: Two Drafts for Resilience of Control Plane >> >> >> >> >> >> Hi, >> >> >> >> >> >> Here is one of the problems that I've been thinking for >> a while - >> >> > control >> >> >> plane partitioned LSPs. Suppose one or more signaling >> controllers >> >> > managing >> >> >> some LSP went out of service leaving the LSP's data >> plane intact. >> > As >> >> > far >> >> >> as the user is concerned such LSP is perfectly healthy and >> >> > operational. >> >> >> Such situation could last for a considerable period of >> time. Do we >> >> > need to >> >> >> manage such LSP via control plane? Sure, we must be capable to >> >> >> tear >> >> > down >> >> >> such LSP, perform mb4b rerouting, distribute alarms between >> >> > operational >> >> >> controllers, signal data plane faults and perform recovery >> > switchover, >> >> >> modify LSP status, etc. Can we do this today? No, but with some >> >> >> (signaling) extensions the problem I believe is >> solvable. Is this >> > some >> >> >> artificial, "fabricated" problem? No, I think it is >> real. Does it >> > fall >> >> >> under the control plane resilience problem space? I believe it >> > does. >> >> >> >> >> >> Igor >> >> >> >> >> >> > I agree with Zafar and Dimitri. If someone wanted to document >> > the >> >> > GMPLS >> >> >> > control plane resiliency features, as was done for GMPLS >> > addressing, >> >> >> > that might be a useful activity. >> >> >> > >> >> >> >> -----Original Message----- >> >> >> >> From: dimitri papadimitriou [mailto:dpapadimitriou@psg.com] >> >> >> >> Sent: Friday, October 28, 2005 9:56 AM >> >> >> >> To: Igor Bryskin >> >> >> >> Cc: Zafar Ali (zali); Kim Young Hwa; ccamp@ops.ietf.org >> >> >> >> Subject: Re: Two Drafts for Resilience of Control Plane >> >> >> >> >> >> >> >> igor - >> >> >> >> >> >> >> >> over time CCAMP came with a set of mechanims to >> improve control >> >> > plane >> >> >> >> resilience (RSVP and LMP GR upon channel/node >> failure) other WG >> >> >> > protocol >> >> >> >> work are also usable used here OSPF GR, etc. ... on the other >> > side, >> >> >> >> mechanism such as link bundling have built-in resilience >> >> > capabilities >> >> >> >> and most GMPLS control plane capabilities have been designed >> > such >> >> > as >> >> >> > to >> >> >> >> be independent of the control plane realisation (in-band, >> >> > out-of-band, >> >> >> >> etc.) >> >> >> >> >> >> >> >> so indeed i share the concern of Zafar what could we do more >> > here >> >> > than >> >> >> >> document these tools and provide our experience in >> using them; >> >> >> >> >> >> >> >> now, before stating there are (potential) >> problems(s) arising - >> >> > would >> >> >> >> you please be more specific on what are these potential >> >> >> >> issue(s) >> >> >> > and/or >> >> >> >> problems ? (not related to policy/config. - note: all the >> >> >> >> issues >> >> > you >> >> >> >> have pointed here below are simply policy/config specific but >> > none >> >> > of >> >> >> >> them highlights a missing IP control plane >> resiliency feature) >> >> >> >> >> >> >> >> thanks, >> >> >> >> - dimitri. >> >> >> >> >> >> >> >> >> >> >> >> Igor Bryskin wrote: >> >> >> >> >> >> >> >> > Zafar, >> >> >> >> > >> >> >> >> > The problem arises when the control plane is >> decoupled from >> >> >> >> > the data plane. The question is do we need such >> decoupling in >> >> >> >> > IP networks? Consider, for example, the situation when >> >> >> >> > several parallel PSC data links bundled together and >> >> >> >> > controlled by a single control channel. >> >> >> >> > Does it mean in this case that when the control >> channel fails >> >> >> >> > all associated data links also fail? Do we need to >> reroute in >> >> >> >> > this case LSPs that use the data links? Can we >> rely in this >> >> >> >> > case on control plane indications to decide whether an >> >> >> >> > associated data link is healthy or not (in other >> words, can >> >> >> >> > we rely on RSVP Hellos or should we use, for >> example, BTD)? >> >> >> >> > Should we be capable to recover control channels without >> >> >> >> > disturbing data plane? I think control plane resilience is >> >> >> >> > important for all layers. You are right, Internet >> does work, >> >> >> >> > however, we do need for some reason TE and (fast) >> recovery in >> >> >> >> > IP as much as in other layers,don't we? >> >> >> >> > >> >> >> >> > Cheers, >> >> >> >> > Igor >> >> >> >> > >> >> >> >> > --- "Zafar Ali (zali)" wrote: >> >> >> >> > >> >> >> >> > >> >> >> >> >>Hi All, >> >> >> >> >> >> >> >> >> >>I am unable to understand the problem we are >> trying to solve >> >> >> >> >>or fabricate. My control network is IP based and IP has >> >> >> >> >>proven resiliency (Internet *does* work), why >> would I like to >> >> >> >> >>take control plan resiliency problem at a layer *above-IP* >> >> >> >> >>and complicate my life. Did I miss something? >> >> >> >> >> >> >> >> >> >>Thanks >> >> >> >> >> >> >> >> >> >>Regards... Zafar >> >> >> >> >> >> >> >> >> >> >> >> >> >> >>________________________________ >> >> >> >> >> >> >> >> >> >> From: owner-ccamp@ops.ietf.org >> >> >> >> >>[mailto:owner-ccamp@ops.ietf.org] >> >> >> >> >>On Behalf Of Kim Young Hwa >> >> >> >> >> Sent: Friday, October 28, 2005 6:04 AM >> >> >> >> >> To: ccamp@ops.ietf.org >> >> >> >> >> Subject: Two Drafts for Resilience of Control Plane >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> Dear all, >> >> >> >> >> >> >> >> >> >> I posted two drafts for the resilience of control plane. >> >> >> >> >> One is for requirements of the resilience of >> control plane, >> >> >> >> >>the other is for a protocol specification as a solution of >> >> >> >> >>that . >> >> >> >> >> These are now available at: >> >> >> >> >> >> >> >> >> >> >> >> >> >> > >> >> >> >> > >> >> > >> http://www.ietf.org/internet-drafts/draft-kim-ccamp-cpr-reqts-01.tx >> >> > t >> >> >> >> > >> >> >> >> >> >> >> >> >> >> >> >> >> >> > >> >> >> >> > >> >> >> > >> >> > >> > >> http://www.ietf.org/internet-drafts/draft-kim-ccamp-accp-protocol-00.t >> > xt >> >> >> >> > >> >> >> >> >> >> >> >> >> >> I want your comments. >> >> >> >> >> >> >> >> >> >> Regards >> >> >> >> >> >> >> >> >> >> Young. >> >> >> >> >> >> >> >> >> >> ===================================> >> Young-Hwa Kim >> >> >> >> >> Principal Member / Ph.D >> >> >> >> >> BcN Research Division, ETRI >> >> >> >> >> Tel: +82-42-860-5819 >> >> >> >> >> Fax: +82-42-860-5440 >> >> >> >> >> e-mail: yhwkim@etri.re.kr >> >> >> >> >> ===================================> >> >> >> >> >> >> >> >> >> >> > >> >> >> >> > >> >> >> > >> >> > >> > >> > > or >> >> >> >> > >> >> >> >> > >> >> >> > >> >> > >> > >> g&name=ccamp%40ops.ietf.org&fromemail=yhwkim@etri.re.kr&messageid=%3C8 >> > 63 >> >> >> >> > >> >> >> >> >>0a6db-0c31-49ab-a798-13b0dda04553@etri.re.kr%3E> >> >> >> >> >> >> >> >> >> >> >> >> >> >> > >> >> >> >> > >> >> >> >> > >> >> >> >> > >> >> >> >> > >> >> >> >> > >> >> >> >> > __________________________________ >> >> >> >> > Yahoo! Mail - PC Magazine Editors' Choice 2005 >> >> >> >> > http://mail.yahoo.com >> >> >> >> > >> >> >> >> > >> >> >> >> > . >> >> >> >> > >> >> >> > >> >> >> > >> >> >> > >> >> > >> >> > >> > >> > >> > Envelope-to: ccamp-data@psg.com Delivery-date: Sat, 29 Oct 2005 14:03: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: Two Drafts for Resilience of Control Plane Date: Sat, 29 Oct 2005 07:03:27 -0700 Message-ID: <626FC7C6A97381468FB872072AB5DDC8369711@XCH-SW-42.sw.nos.boeing.com> Thread-Topic: Two Drafts for Resilience of Control Plane Thread-Index: AcXcjfnSQmJlztSNT1CH6Ck+YB2EbwAAqmTQ From: "Drake, John E" To: Cc: , , "Igor Bryskin" , "Zafar Ali" , "Kim Young Hwa" , Igor, You haven't convinced me that there is a real problem here that is not addressed by the combination of the existing GMPLS resilience mechanisms and a robust implementation of those mechanisms. As I said yesterday, an I-D that enumerated all of the resilience mechanisms might be a useful thing, specifically as a primer. Thanks, John > -----Original Message----- > From: ibryskin@movaz.com [mailto:ibryskin@movaz.com] > Sent: Saturday, October 29, 2005 6:38 AM > To: Drake, John E > Cc: ibryskin@movaz.com; dpapadimitriou@psg.com; > dimitri.papadimitriou@alcatel.be; Igor Bryskin; Zafar Ali; Kim Young Hwa; > ccamp@ops.ietf.org > Subject: RE: Two Drafts for Resilience of Control Plane >=20 > John, >=20 > See in line. >=20 > Igor >=20 > > Igor, > > > > What you wrote was: > > > > "Suppose one or more signaling controllers managing some LSP went out of > > service leaving the LSP's data plane intact. As far as the user is > > concerned such LSP is perfectly healthy and operational. Such situation > > could last for a considerable period of time." > > > > What part of this is *not* handled by RSVP graceful restart? > > > > In your subsequent e-mail, you then changed the problem statement to: > > > > ""Dead" controllers in my example *do not* come back for a considerable > > period of time. So there are no restarts here (graceful or not > > graceful)" >=20 > Sorry, I don't see how I have changed the problem statement. I was and am > saying that while controllers are out of service for a considerable time > (day? two days? week?) the question is what to do with active LSPs > associated with them? Let's consider an example: >=20 >=20 > A----B------C-----D > } | > E-----F-----H-----K >=20 > Suppose we have an LSP A-B-C-D carrying user traffic and a controller > managing node B went out of service. The question is what to do with this > LSP until the controller comes back? The operator may decide: > a) simply not wait and delete the LSP. Normal LSP teardown - PathTear > originated on the ingress controller- won't work because PathTear won't > make it to controllers managing nodes C and D, leaving (very expensive in > the optical layer) resources associated with the LSP allocated and not > available for other LSPs; > b) reroute via mb4b the LSP onto alternative path A-E-H-K-D -won't work > for the same reason as in a) > c) leave LSP as it is and wait for the dead controller to be replaced > or > repaired. This would mean the need to perform normal operations like, for > example, monitoring of data plane alarms, changing LSP admin status (for > example, disabling alarms on all nodes), perform power monitoring and > equalization, perform recovery operation in case of a fatal data plane > failure. All what depends on hop-by-hop signaling won't work today. > Don't tell me that these problems are fabricated; they are real because > they are raised by the customers. Dimitri seems to understand the problem > but he is saying that the CP in this case is hardly of any use. This IMO > is a dangerous statement for the future of CP in non-packet environments. > The Management plane aficionados will jump on it and say that management > plane does not have such a problem - NMS has a direct access to any NE on > the network, so it can do all necessary cleanup no matter what happened. > Customers will say: "Well, if there are situations when CP suddenly > becomes useless and we have to use management plane anyway, why would we > use the CP in the first place?' >=20 > Fortunately, I believe that the problems could be solved entirely via CP > by making it more resilient. Hence, CP resilience is a good direction to > work on within CCAMP WG >=20 > Igor >=20 > > If "Considerable period of time" is not equal to infinity, then there > > will be an RSVP graceful restart. If a controller is really and truly > > dead, then presumably the operator will either replace it or re-assign > > its data-plane resources to another signaling controller. In either > > case, there will then be an RSVP graceful restart. > > > > Thanks, > > > > John > > > > > > > >> -----Original Message----- > >> From: ibryskin@movaz.com [mailto:ibryskin@movaz.com] > >> Sent: Friday, October 28, 2005 1:00 PM > >> To: Drake, John E > >> Cc: ibryskin@movaz.com; dpapadimitriou@psg.com; > >> dimitri.papadimitriou@alcatel.be; Igor Bryskin; Zafar Ali; Kim Young > > Hwa; > >> ccamp@ops.ietf.org > >> Subject: RE: Two Drafts for Resilience of Control Plane > >> > >> John, > >> > >> I think you missed my point here. "Dead" controllers in my example *do > >> not* come back for a considerable period of time. So there are no > > restarts > >> here (graceful or not graceful) :=3D) > >> > >> Igor > >> > >> > What part of your problem, as stated below, is not handled by RSVP > >> > graceful restart? > >> > > >> >> -----Original Message----- > >> >> From: ibryskin@movaz.com [mailto:ibryskin@movaz.com] > >> >> Sent: Friday, October 28, 2005 11:41 AM > >> >> To: Drake, John E > >> >> Cc: dpapadimitriou@psg.com; dimitri.papadimitriou@alcatel.be; Igor > >> >> Bryskin; Zafar Ali; Kim Young Hwa; ccamp@ops.ietf.org > >> >> Subject: RE: Two Drafts for Resilience of Control Plane > >> >> > >> >> Hi, > >> >> > >> >> Here is one of the problems that I've been thinking for a while - > >> > control > >> >> plane partitioned LSPs. Suppose one or more signaling controllers > >> > managing > >> >> some LSP went out of service leaving the LSP's data plane intact. > > As > >> > far > >> >> as the user is concerned such LSP is perfectly healthy and > >> > operational. > >> >> Such situation could last for a considerable period of time. Do we > >> > need to > >> >> manage such LSP via control plane? Sure, we must be capable to tear > >> > down > >> >> such LSP, perform mb4b rerouting, distribute alarms between > >> > operational > >> >> controllers, signal data plane faults and perform recovery > > switchover, > >> >> modify LSP status, etc. Can we do this today? No, but with some > >> >> (signaling) extensions the problem I believe is solvable. Is this > > some > >> >> artificial, "fabricated" problem? No, I think it is real. Does it > > fall > >> >> under the control plane resilience problem space? I believe it > > does. > >> >> > >> >> Igor > >> >> > >> >> > I agree with Zafar and Dimitri. If someone wanted to document > > the > >> > GMPLS > >> >> > control plane resiliency features, as was done for GMPLS > > addressing, > >> >> > that might be a useful activity. > >> >> > > >> >> >> -----Original Message----- > >> >> >> From: dimitri papadimitriou [mailto:dpapadimitriou@psg.com] > >> >> >> Sent: Friday, October 28, 2005 9:56 AM > >> >> >> To: Igor Bryskin > >> >> >> Cc: Zafar Ali (zali); Kim Young Hwa; ccamp@ops.ietf.org > >> >> >> Subject: Re: Two Drafts for Resilience of Control Plane > >> >> >> > >> >> >> igor - > >> >> >> > >> >> >> over time CCAMP came with a set of mechanims to improve control > >> > plane > >> >> >> resilience (RSVP and LMP GR upon channel/node failure) other WG > >> >> > protocol > >> >> >> work are also usable used here OSPF GR, etc. ... on the other > > side, > >> >> >> mechanism such as link bundling have built-in resilience > >> > capabilities > >> >> >> and most GMPLS control plane capabilities have been designed > > such > >> > as > >> >> > to > >> >> >> be independent of the control plane realisation (in-band, > >> > out-of-band, > >> >> >> etc.) > >> >> >> > >> >> >> so indeed i share the concern of Zafar what could we do more > > here > >> > than > >> >> >> document these tools and provide our experience in using them; > >> >> >> > >> >> >> now, before stating there are (potential) problems(s) arising - > >> > would > >> >> >> you please be more specific on what are these potential issue(s) > >> >> > and/or > >> >> >> problems ? (not related to policy/config. - note: all the issues > >> > you > >> >> >> have pointed here below are simply policy/config specific but > > none > >> > of > >> >> >> them highlights a missing IP control plane resiliency feature) > >> >> >> > >> >> >> thanks, > >> >> >> - dimitri. > >> >> >> > >> >> >> > >> >> >> Igor Bryskin wrote: > >> >> >> > >> >> >> > Zafar, > >> >> >> > > >> >> >> > The problem arises when the control plane is decoupled > >> >> >> > from the data plane. The question is do we need such > >> >> >> > decoupling in IP networks? Consider, for example, the > >> >> >> > situation when several parallel PSC data links bundled > >> >> >> > together and controlled by a single control channel. > >> >> >> > Does it mean in this case that when the control > >> >> >> > channel fails all associated data links also fail? Do > >> >> >> > we need to reroute in this case LSPs that use the data > >> >> >> > links? Can we rely in this case on control plane > >> >> >> > indications to decide whether an associated data link > >> >> >> > is healthy or not (in other words, can we rely on RSVP > >> >> >> > Hellos or should we use, for example, BTD)? Should we > >> >> >> > be capable to recover control channels without > >> >> >> > disturbing data plane? I think control plane > >> >> >> > resilience is important for all layers. You are right, > >> >> >> > Internet does work, however, we do need for some > >> >> >> > reason TE and (fast) recovery in IP as much as in > >> >> >> > other layers,don't we? > >> >> >> > > >> >> >> > Cheers, > >> >> >> > Igor > >> >> >> > > >> >> >> > --- "Zafar Ali (zali)" wrote: > >> >> >> > > >> >> >> > > >> >> >> >>Hi All, > >> >> >> >> > >> >> >> >>I am unable to understand the problem we are trying > >> >> >> >>to solve or > >> >> >> >>fabricate. My control network is IP based and IP has > >> >> >> >>proven resiliency > >> >> >> >>(Internet *does* work), why would I like to take > >> >> >> >>control plan resiliency > >> >> >> >>problem at a layer *above-IP* and complicate my > >> >> >> >>life. Did I miss > >> >> >> >>something? > >> >> >> >> > >> >> >> >>Thanks > >> >> >> >> > >> >> >> >>Regards... Zafar > >> >> >> >> > >> >> >> >> > >> >> >> >>________________________________ > >> >> >> >> > >> >> >> >> From: owner-ccamp@ops.ietf.org > >> >> >> >>[mailto:owner-ccamp@ops.ietf.org] > >> >> >> >>On Behalf Of Kim Young Hwa > >> >> >> >> Sent: Friday, October 28, 2005 6:04 AM > >> >> >> >> To: ccamp@ops.ietf.org > >> >> >> >> Subject: Two Drafts for Resilience of Control Plane > >> >> >> >> > >> >> >> >> > >> >> >> >> Dear all, > >> >> >> >> > >> >> >> >> I posted two drafts for the resilience of control > >> >> >> >>plane. > >> >> >> >> One is for requirements of the resilience of > >> >> >> >>control plane, the > >> >> >> >>other is for a protocol specification as a solution > >> >> >> >>of that . > >> >> >> >> These are now available at: > >> >> >> >> > >> >> >> >> > >> >> >> > > >> >> >> > > >> > http://www.ietf.org/internet-drafts/draft-kim-ccamp-cpr-reqts-01.txt > >> >> >> > > >> >> >> >> > >> >> >> >> > >> >> >> > > >> >> >> > > >> >> > > >> > > > http://www.ietf.org/internet-drafts/draft-kim-ccamp-accp-protocol-00.txt > >> >> >> > > >> >> >> >> > >> >> >> >> I want your comments. > >> >> >> >> > >> >> >> >> Regards > >> >> >> >> > >> >> >> >> Young. > >> >> >> >> > >> >> >> >> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D> >> Young-Hwa Kim > >> >> >> >> Principal Member / Ph.D > >> >> >> >> BcN Research Division, ETRI > >> >> >> >> Tel: +82-42-860-5819 > >> >> >> >> Fax: +82-42-860-5440 > >> >> >> >> e-mail: yhwkim@etri.re.kr > >> >> >> >> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D> >> > >> >> >> >> > >> >> >> > > >> >> >> > > >> >> > > >> > > > >> >> >> > > >> >> >> > > >> >> > > >> > > > g&name=3Dccamp%40ops.ietf.org&fromemail=3Dyhwkim@etri.re.kr&messageid=3D%= 3C863 > >> >> >> > > >> >> >> >>0a6db-0c31-49ab-a798-13b0dda04553@etri.re.kr%3E> > >> >> >> >> > >> >> >> >> > >> >> >> > > >> >> >> > > >> >> >> > > >> >> >> > > >> >> >> > > >> >> >> > > >> >> >> > __________________________________ > >> >> >> > Yahoo! Mail - PC Magazine Editors' Choice 2005 > >> >> >> > http://mail.yahoo.com > >> >> >> > > >> >> >> > > >> >> >> > . > >> >> >> > > >> >> > > >> >> > > >> >> > > >> > > >> > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Sat, 29 Oct 2005 13:54: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: Two Drafts for Resilience of Control Plane Date: Sat, 29 Oct 2005 09:53:57 -0400 Message-ID: Thread-Topic: Two Drafts for Resilience of Control Plane Thread-Index: AcXcjf5z9+Ny5FLLSyKDj5WcLr/jtQAARsJA From: "Zafar Ali \(zali\)" To: , "Drake, John E" Cc: , , "Igor Bryskin" , "Kim Young Hwa" , > -----Original Message----- > From: ibryskin@movaz.com [mailto:ibryskin@movaz.com]=20 > Sent: Saturday, October 29, 2005 9:38 AM > To: Drake, John E > Cc: ibryskin@movaz.com; dpapadimitriou@psg.com;=20 > dimitri.papadimitriou@alcatel.be; Igor Bryskin; Zafar Ali=20 > (zali); Kim Young Hwa; ccamp@ops.ietf.org > Subject: RE: Two Drafts for Resilience of Control Plane >=20 > John, >=20 > See in line. >=20 > Igor >=20 > > Igor, > > > > What you wrote was: > > > > "Suppose one or more signaling controllers managing some=20 > LSP went out=20 > > of service leaving the LSP's data plane intact. As far as=20 > the user is=20 > > concerned such LSP is perfectly healthy and operational. Such=20 > > situation could last for a considerable period of time." > > > > What part of this is *not* handled by RSVP graceful restart? > > > > In your subsequent e-mail, you then changed the problem=20 > statement to: > > > > ""Dead" controllers in my example *do not* come back for a=20 > > considerable period of time. So there are no restarts here=20 > (graceful=20 > > or not graceful)" >=20 > Sorry, I don't see how I have changed the problem statement.=20 > I was and am saying that while controllers are out of service=20 > for a considerable time (day? two days? week?) the question=20 > is what to do with active LSPs associated with them? Let's=20 > consider an example: >=20 >=20 > A----B------C-----D > } | > E-----F-----H-----K >=20 > Suppose we have an LSP A-B-C-D carrying user traffic and a=20 > controller managing node B went out of service. The question=20 > is what to do with this LSP until the controller comes back?=20 > The operator may decide: > a) simply not wait and delete the LSP. Normal LSP teardown=20 > - PathTear > originated on the ingress controller- won't work because=20 > PathTear won't make it to controllers managing nodes C and D,=20 > leaving (very expensive in the optical layer) resources=20 > associated with the LSP allocated and not available for other LSPs; > b) reroute via mb4b the LSP onto alternative path=20 > A-E-H-K-D -won't work > for the same reason as in a) > c) leave LSP as it is and wait for the dead controller to=20 > be replaced or > repaired. This would mean the need to perform normal=20 > operations like, for example, monitoring of data plane=20 > alarms, changing LSP admin status (for example, disabling=20 > alarms on all nodes), perform power monitoring and=20 > equalization, perform recovery operation in case of a fatal=20 > data plane failure. All what depends on hop-by-hop signaling=20 > won't work today. > Don't tell me that these problems are fabricated; they are=20 > real because they are raised by the customers. Dimitri seems=20 > to understand the problem but he is saying that the CP in=20 > this case is hardly of any use. This IMO is a dangerous=20 > statement for the future of CP in non-packet environments. > The Management plane aficionados will jump on it and say that=20 > management plane does not have such a problem - NMS has a=20 > direct access to any NE on the network, so it can do all=20 > necessary cleanup no matter what happened. > Customers will say: "Well, if there are situations when CP=20 > suddenly becomes useless and we have to use management plane=20 > anyway, why would we use the CP in the first place?' >=20 > Fortunately, I believe that the problems could be solved=20 > entirely via CP by making it more resilient. Hence, CP=20 > resilience is a good direction to work on within CCAMP WG Igor,=20 W.r.t. option C, please note that traffic CANNOT be forwarded in a "head-less mode" for a very long time . If you control network melts or a peering controller goes down, either RSVP GR or refreshes will take care of the clean-up of the affected RSVP states. Similarly LMP CC SM will go down (after states are cleared, i.e., degraded-to-down), eventually removing the TE links from topology. =20 Thanks Regards... Zafar=20 >=20 > Igor >=20 > > If "Considerable period of time" is not equal to infinity,=20 > then there=20 > > will be an RSVP graceful restart. If a controller is=20 > really and truly=20 > > dead, then presumably the operator will either replace it=20 > or re-assign=20 > > its data-plane resources to another signaling controller. =20 > In either=20 > > case, there will then be an RSVP graceful restart. > > > > Thanks, > > > > John > > > > > > > >> -----Original Message----- > >> From: ibryskin@movaz.com [mailto:ibryskin@movaz.com] > >> Sent: Friday, October 28, 2005 1:00 PM > >> To: Drake, John E > >> Cc: ibryskin@movaz.com; dpapadimitriou@psg.com;=20 > >> dimitri.papadimitriou@alcatel.be; Igor Bryskin; Zafar Ali;=20 > Kim Young > > Hwa; > >> ccamp@ops.ietf.org > >> Subject: RE: Two Drafts for Resilience of Control Plane > >> > >> John, > >> > >> I think you missed my point here. "Dead" controllers in my example=20 > >> *do > >> not* come back for a considerable period of time. So there are no > > restarts > >> here (graceful or not graceful) :=3D) > >> > >> Igor > >> > >> > What part of your problem, as stated below, is not=20 > handled by RSVP=20 > >> > graceful restart? > >> > > >> >> -----Original Message----- > >> >> From: ibryskin@movaz.com [mailto:ibryskin@movaz.com] > >> >> Sent: Friday, October 28, 2005 11:41 AM > >> >> To: Drake, John E > >> >> Cc: dpapadimitriou@psg.com;=20 > dimitri.papadimitriou@alcatel.be; Igor=20 > >> >> Bryskin; Zafar Ali; Kim Young Hwa; ccamp@ops.ietf.org > >> >> Subject: RE: Two Drafts for Resilience of Control Plane > >> >> > >> >> Hi, > >> >> > >> >> Here is one of the problems that I've been thinking for=20 > a while - > >> > control > >> >> plane partitioned LSPs. Suppose one or more signaling=20 > controllers > >> > managing > >> >> some LSP went out of service leaving the LSP's data=20 > plane intact. > > As > >> > far > >> >> as the user is concerned such LSP is perfectly healthy and > >> > operational. > >> >> Such situation could last for a considerable period of=20 > time. Do we > >> > need to > >> >> manage such LSP via control plane? Sure, we must be capable to=20 > >> >> tear > >> > down > >> >> such LSP, perform mb4b rerouting, distribute alarms between > >> > operational > >> >> controllers, signal data plane faults and perform recovery > > switchover, > >> >> modify LSP status, etc. Can we do this today? No, but with some > >> >> (signaling) extensions the problem I believe is=20 > solvable. Is this > > some > >> >> artificial, "fabricated" problem? No, I think it is=20 > real. Does it > > fall > >> >> under the control plane resilience problem space? I believe it > > does. > >> >> > >> >> Igor > >> >> > >> >> > I agree with Zafar and Dimitri. If someone wanted to document > > the > >> > GMPLS > >> >> > control plane resiliency features, as was done for GMPLS > > addressing, > >> >> > that might be a useful activity. > >> >> > > >> >> >> -----Original Message----- > >> >> >> From: dimitri papadimitriou [mailto:dpapadimitriou@psg.com] > >> >> >> Sent: Friday, October 28, 2005 9:56 AM > >> >> >> To: Igor Bryskin > >> >> >> Cc: Zafar Ali (zali); Kim Young Hwa; ccamp@ops.ietf.org > >> >> >> Subject: Re: Two Drafts for Resilience of Control Plane > >> >> >> > >> >> >> igor - > >> >> >> > >> >> >> over time CCAMP came with a set of mechanims to=20 > improve control > >> > plane > >> >> >> resilience (RSVP and LMP GR upon channel/node=20 > failure) other WG > >> >> > protocol > >> >> >> work are also usable used here OSPF GR, etc. ... on the other > > side, > >> >> >> mechanism such as link bundling have built-in resilience > >> > capabilities > >> >> >> and most GMPLS control plane capabilities have been designed > > such > >> > as > >> >> > to > >> >> >> be independent of the control plane realisation (in-band, > >> > out-of-band, > >> >> >> etc.) > >> >> >> > >> >> >> so indeed i share the concern of Zafar what could we do more > > here > >> > than > >> >> >> document these tools and provide our experience in=20 > using them; > >> >> >> > >> >> >> now, before stating there are (potential)=20 > problems(s) arising - > >> > would > >> >> >> you please be more specific on what are these potential=20 > >> >> >> issue(s) > >> >> > and/or > >> >> >> problems ? (not related to policy/config. - note: all the=20 > >> >> >> issues > >> > you > >> >> >> have pointed here below are simply policy/config specific but > > none > >> > of > >> >> >> them highlights a missing IP control plane=20 > resiliency feature) > >> >> >> > >> >> >> thanks, > >> >> >> - dimitri. > >> >> >> > >> >> >> > >> >> >> Igor Bryskin wrote: > >> >> >> > >> >> >> > Zafar, > >> >> >> > > >> >> >> > The problem arises when the control plane is=20 > decoupled from=20 > >> >> >> > the data plane. The question is do we need such=20 > decoupling in=20 > >> >> >> > IP networks? Consider, for example, the situation when=20 > >> >> >> > several parallel PSC data links bundled together and=20 > >> >> >> > controlled by a single control channel. > >> >> >> > Does it mean in this case that when the control=20 > channel fails=20 > >> >> >> > all associated data links also fail? Do we need to=20 > reroute in=20 > >> >> >> > this case LSPs that use the data links? Can we=20 > rely in this=20 > >> >> >> > case on control plane indications to decide whether an=20 > >> >> >> > associated data link is healthy or not (in other=20 > words, can=20 > >> >> >> > we rely on RSVP Hellos or should we use, for=20 > example, BTD)?=20 > >> >> >> > Should we be capable to recover control channels without=20 > >> >> >> > disturbing data plane? I think control plane resilience is=20 > >> >> >> > important for all layers. You are right, Internet=20 > does work,=20 > >> >> >> > however, we do need for some reason TE and (fast)=20 > recovery in=20 > >> >> >> > IP as much as in other layers,don't we? > >> >> >> > > >> >> >> > Cheers, > >> >> >> > Igor > >> >> >> > > >> >> >> > --- "Zafar Ali (zali)" wrote: > >> >> >> > > >> >> >> > > >> >> >> >>Hi All, > >> >> >> >> > >> >> >> >>I am unable to understand the problem we are=20 > trying to solve=20 > >> >> >> >>or fabricate. My control network is IP based and IP has=20 > >> >> >> >>proven resiliency (Internet *does* work), why=20 > would I like to=20 > >> >> >> >>take control plan resiliency problem at a layer *above-IP*=20 > >> >> >> >>and complicate my life. Did I miss something? > >> >> >> >> > >> >> >> >>Thanks > >> >> >> >> > >> >> >> >>Regards... Zafar > >> >> >> >> > >> >> >> >> > >> >> >> >>________________________________ > >> >> >> >> > >> >> >> >> From: owner-ccamp@ops.ietf.org=20 > >> >> >> >>[mailto:owner-ccamp@ops.ietf.org] > >> >> >> >>On Behalf Of Kim Young Hwa > >> >> >> >> Sent: Friday, October 28, 2005 6:04 AM > >> >> >> >> To: ccamp@ops.ietf.org > >> >> >> >> Subject: Two Drafts for Resilience of Control Plane > >> >> >> >> > >> >> >> >> > >> >> >> >> Dear all, > >> >> >> >> > >> >> >> >> I posted two drafts for the resilience of control plane. > >> >> >> >> One is for requirements of the resilience of=20 > control plane,=20 > >> >> >> >>the other is for a protocol specification as a solution of=20 > >> >> >> >>that . > >> >> >> >> These are now available at: > >> >> >> >> > >> >> >> >> > >> >> >> > > >> >> >> > > >> >=20 > http://www.ietf.org/internet-drafts/draft-kim-ccamp-cpr-reqts-01.tx > >> > t > >> >> >> > > >> >> >> >> > >> >> >> >> > >> >> >> > > >> >> >> > > >> >> > > >> > > >=20 > http://www.ietf.org/internet-drafts/draft-kim-ccamp-accp-protocol-00.t > > xt > >> >> >> > > >> >> >> >> > >> >> >> >> I want your comments. > >> >> >> >> > >> >> >> >> Regards > >> >> >> >> > >> >> >> >> Young. > >> >> >> >> > >> >> >> >> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D> >> Young-Hwa Kim > >> >> >> >> Principal Member / Ph.D > >> >> >> >> BcN Research Division, ETRI > >> >> >> >> Tel: +82-42-860-5819 > >> >> >> >> Fax: +82-42-860-5440 > >> >> >> >> e-mail: yhwkim@etri.re.kr > >> >> >> >> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D> >> > >> >> >> >> > >> >> >> > > >> >> >> > > >> >> > > >> > > >=20 > = > or > >> >> >> > > >> >> >> > > >> >> > > >> > > >=20 > = g&name=3Dccamp%40ops.ietf.org&fromemail=3Dyhwkim@etri.re.kr&messageid=3D%= 3C8 > > 63 > >> >> >> > > >> >> >> >>0a6db-0c31-49ab-a798-13b0dda04553@etri.re.kr%3E> > >> >> >> >> > >> >> >> >> > >> >> >> > > >> >> >> > > >> >> >> > > >> >> >> > > >> >> >> > > >> >> >> > > >> >> >> > __________________________________ > >> >> >> > Yahoo! Mail - PC Magazine Editors' Choice 2005=20 > >> >> >> > http://mail.yahoo.com > >> >> >> > > >> >> >> > > >> >> >> > . > >> >> >> > > >> >> > > >> >> > > >> >> > > >> > > >> > > > > > >=20 Envelope-to: ccamp-data@psg.com Delivery-date: Sat, 29 Oct 2005 13:38:54 +0000 Message-ID: <3336.68.100.80.11.1130593075.squirrel@webmail.movaz.com> Date: Sat, 29 Oct 2005 09:37:55 -0400 (EDT) Subject: RE: Two Drafts for Resilience of Control Plane From: ibryskin@movaz.com To: "Drake, John E" Cc: ibryskin@movaz.com, dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be, "Igor Bryskin" , "Zafar Ali" , "Kim Young Hwa" , ccamp@ops.ietf.org User-Agent: SquirrelMail/1.4.1 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit John, See in line. Igor > Igor, > > What you wrote was: > > "Suppose one or more signaling controllers managing some LSP went out of > service leaving the LSP's data plane intact. As far as the user is > concerned such LSP is perfectly healthy and operational. Such situation > could last for a considerable period of time." > > What part of this is *not* handled by RSVP graceful restart? > > In your subsequent e-mail, you then changed the problem statement to: > > ""Dead" controllers in my example *do not* come back for a considerable > period of time. So there are no restarts here (graceful or not > graceful)" Sorry, I don’t see how I have changed the problem statement. I was and am saying that while controllers are out of service for a considerable time (day? two days? week?) the question is what to do with active LSPs associated with them? Let’s consider an example: A----B------C-----D } | E-----F-----H-----K Suppose we have an LSP A-B-C-D carrying user traffic and a controller managing node B went out of service. The question is what to do with this LSP until the controller comes back? The operator may decide: a) simply not wait and delete the LSP. Normal LSP teardown – PathTear originated on the ingress controller- won’t work because PathTear won’t make it to controllers managing nodes C and D, leaving (very expensive in the optical layer) resources associated with the LSP allocated and not available for other LSPs; b) reroute via mb4b the LSP onto alternative path A-E-H-K-D –won’t work for the same reason as in a) c) leave LSP as it is and wait for the dead controller to be replaced or repaired. This would mean the need to perform normal operations like, for example, monitoring of data plane alarms, changing LSP admin status (for example, disabling alarms on all nodes), perform power monitoring and equalization, perform recovery operation in case of a fatal data plane failure. All what depends on hop-by-hop signaling won’t work today. Don’t tell me that these problems are fabricated; they are real because they are raised by the customers. Dimitri seems to understand the problem but he is saying that the CP in this case is hardly of any use. This IMO is a dangerous statement for the future of CP in non-packet environments. The Management plane aficionados will jump on it and say that management plane does not have such a problem – NMS has a direct access to any NE on the network, so it can do all necessary cleanup no matter what happened. Customers will say: “Well, if there are situations when CP suddenly becomes useless and we have to use management plane anyway, why would we use the CP in the first place?’ Fortunately, I believe that the problems could be solved entirely via CP by making it more resilient. Hence, CP resilience is a good direction to work on within CCAMP WG Igor > If "Considerable period of time" is not equal to infinity, then there > will be an RSVP graceful restart. If a controller is really and truly > dead, then presumably the operator will either replace it or re-assign > its data-plane resources to another signaling controller. In either > case, there will then be an RSVP graceful restart. > > Thanks, > > John > > > >> -----Original Message----- >> From: ibryskin@movaz.com [mailto:ibryskin@movaz.com] >> Sent: Friday, October 28, 2005 1:00 PM >> To: Drake, John E >> Cc: ibryskin@movaz.com; dpapadimitriou@psg.com; >> dimitri.papadimitriou@alcatel.be; Igor Bryskin; Zafar Ali; Kim Young > Hwa; >> ccamp@ops.ietf.org >> Subject: RE: Two Drafts for Resilience of Control Plane >> >> John, >> >> I think you missed my point here. "Dead" controllers in my example *do >> not* come back for a considerable period of time. So there are no > restarts >> here (graceful or not graceful) :=) >> >> Igor >> >> > What part of your problem, as stated below, is not handled by RSVP >> > graceful restart? >> > >> >> -----Original Message----- >> >> From: ibryskin@movaz.com [mailto:ibryskin@movaz.com] >> >> Sent: Friday, October 28, 2005 11:41 AM >> >> To: Drake, John E >> >> Cc: dpapadimitriou@psg.com; dimitri.papadimitriou@alcatel.be; Igor >> >> Bryskin; Zafar Ali; Kim Young Hwa; ccamp@ops.ietf.org >> >> Subject: RE: Two Drafts for Resilience of Control Plane >> >> >> >> Hi, >> >> >> >> Here is one of the problems that I've been thinking for a while - >> > control >> >> plane partitioned LSPs. Suppose one or more signaling controllers >> > managing >> >> some LSP went out of service leaving the LSP's data plane intact. > As >> > far >> >> as the user is concerned such LSP is perfectly healthy and >> > operational. >> >> Such situation could last for a considerable period of time. Do we >> > need to >> >> manage such LSP via control plane? Sure, we must be capable to tear >> > down >> >> such LSP, perform mb4b rerouting, distribute alarms between >> > operational >> >> controllers, signal data plane faults and perform recovery > switchover, >> >> modify LSP status, etc. Can we do this today? No, but with some >> >> (signaling) extensions the problem I believe is solvable. Is this > some >> >> artificial, "fabricated" problem? No, I think it is real. Does it > fall >> >> under the control plane resilience problem space? I believe it > does. >> >> >> >> Igor >> >> >> >> > I agree with Zafar and Dimitri. If someone wanted to document > the >> > GMPLS >> >> > control plane resiliency features, as was done for GMPLS > addressing, >> >> > that might be a useful activity. >> >> > >> >> >> -----Original Message----- >> >> >> From: dimitri papadimitriou [mailto:dpapadimitriou@psg.com] >> >> >> Sent: Friday, October 28, 2005 9:56 AM >> >> >> To: Igor Bryskin >> >> >> Cc: Zafar Ali (zali); Kim Young Hwa; ccamp@ops.ietf.org >> >> >> Subject: Re: Two Drafts for Resilience of Control Plane >> >> >> >> >> >> igor - >> >> >> >> >> >> over time CCAMP came with a set of mechanims to improve control >> > plane >> >> >> resilience (RSVP and LMP GR upon channel/node failure) other WG >> >> > protocol >> >> >> work are also usable used here OSPF GR, etc. ... on the other > side, >> >> >> mechanism such as link bundling have built-in resilience >> > capabilities >> >> >> and most GMPLS control plane capabilities have been designed > such >> > as >> >> > to >> >> >> be independent of the control plane realisation (in-band, >> > out-of-band, >> >> >> etc.) >> >> >> >> >> >> so indeed i share the concern of Zafar what could we do more > here >> > than >> >> >> document these tools and provide our experience in using them; >> >> >> >> >> >> now, before stating there are (potential) problems(s) arising - >> > would >> >> >> you please be more specific on what are these potential issue(s) >> >> > and/or >> >> >> problems ? (not related to policy/config. - note: all the issues >> > you >> >> >> have pointed here below are simply policy/config specific but > none >> > of >> >> >> them highlights a missing IP control plane resiliency feature) >> >> >> >> >> >> thanks, >> >> >> - dimitri. >> >> >> >> >> >> >> >> >> Igor Bryskin wrote: >> >> >> >> >> >> > Zafar, >> >> >> > >> >> >> > The problem arises when the control plane is decoupled >> >> >> > from the data plane. The question is do we need such >> >> >> > decoupling in IP networks? Consider, for example, the >> >> >> > situation when several parallel PSC data links bundled >> >> >> > together and controlled by a single control channel. >> >> >> > Does it mean in this case that when the control >> >> >> > channel fails all associated data links also fail? Do >> >> >> > we need to reroute in this case LSPs that use the data >> >> >> > links? Can we rely in this case on control plane >> >> >> > indications to decide whether an associated data link >> >> >> > is healthy or not (in other words, can we rely on RSVP >> >> >> > Hellos or should we use, for example, BTD)? Should we >> >> >> > be capable to recover control channels without >> >> >> > disturbing data plane? I think control plane >> >> >> > resilience is important for all layers. You are right, >> >> >> > Internet does work, however, we do need for some >> >> >> > reason TE and (fast) recovery in IP as much as in >> >> >> > other layers,don't we? >> >> >> > >> >> >> > Cheers, >> >> >> > Igor >> >> >> > >> >> >> > --- "Zafar Ali (zali)" wrote: >> >> >> > >> >> >> > >> >> >> >>Hi All, >> >> >> >> >> >> >> >>I am unable to understand the problem we are trying >> >> >> >>to solve or >> >> >> >>fabricate. My control network is IP based and IP has >> >> >> >>proven resiliency >> >> >> >>(Internet *does* work), why would I like to take >> >> >> >>control plan resiliency >> >> >> >>problem at a layer *above-IP* and complicate my >> >> >> >>life. Did I miss >> >> >> >>something? >> >> >> >> >> >> >> >>Thanks >> >> >> >> >> >> >> >>Regards... Zafar >> >> >> >> >> >> >> >> >> >> >> >>________________________________ >> >> >> >> >> >> >> >> From: owner-ccamp@ops.ietf.org >> >> >> >>[mailto:owner-ccamp@ops.ietf.org] >> >> >> >>On Behalf Of Kim Young Hwa >> >> >> >> Sent: Friday, October 28, 2005 6:04 AM >> >> >> >> To: ccamp@ops.ietf.org >> >> >> >> Subject: Two Drafts for Resilience of Control Plane >> >> >> >> >> >> >> >> >> >> >> >> Dear all, >> >> >> >> >> >> >> >> I posted two drafts for the resilience of control >> >> >> >>plane. >> >> >> >> One is for requirements of the resilience of >> >> >> >>control plane, the >> >> >> >>other is for a protocol specification as a solution >> >> >> >>of that . >> >> >> >> These are now available at: >> >> >> >> >> >> >> >> >> >> >> > >> >> >> > >> > http://www.ietf.org/internet-drafts/draft-kim-ccamp-cpr-reqts-01.txt >> >> >> > >> >> >> >> >> >> >> >> >> >> >> > >> >> >> > >> >> > >> > > http://www.ietf.org/internet-drafts/draft-kim-ccamp-accp-protocol-00.txt >> >> >> > >> >> >> >> >> >> >> >> I want your comments. >> >> >> >> >> >> >> >> Regards >> >> >> >> >> >> >> >> Young. >> >> >> >> >> >> >> >> ===================================> >> Young-Hwa Kim >> >> >> >> Principal Member / Ph.D >> >> >> >> BcN Research Division, ETRI >> >> >> >> Tel: +82-42-860-5819 >> >> >> >> Fax: +82-42-860-5440 >> >> >> >> e-mail: yhwkim@etri.re.kr >> >> >> >> ===================================> >> >> >> >> >> >> >> >> > >> >> >> > >> >> > >> > > > >> >> > >> >> >> > >> >> > >> > > g&name=ccamp%40ops.ietf.org&fromemail=yhwkim@etri.re.kr&messageid=%3C863 >> >> >> > >> >> >> >>0a6db-0c31-49ab-a798-13b0dda04553@etri.re.kr%3E> >> >> >> >> >> >> >> >> >> >> >> > >> >> >> > >> >> >> > >> >> >> > >> >> >> > >> >> >> > >> >> >> > __________________________________ >> >> >> > Yahoo! Mail - PC Magazine Editors' Choice 2005 >> >> >> > http://mail.yahoo.com >> >> >> > >> >> >> > >> >> >> > . >> >> >> > >> >> > >> >> > >> >> > >> > >> > > > Envelope-to: ccamp-data@psg.com Delivery-date: Sat, 29 Oct 2005 11:49:57 +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: Two Drafts for Resilience of Control Plane Date: Sat, 29 Oct 2005 07:47:54 -0400 Message-ID: Thread-Topic: Two Drafts for Resilience of Control Plane Thread-Index: AcXb+5sI7DBursUUSnCMr5SUjjw6QQAAZ19AAADmq6AABtIYwAAANgdAABf9eCA= From: "Zafar Ali \(zali\)" To: "Drake, John E" , "Ong, Lyndon" , , , Cc: , , "Igor Bryskin" , "Kim Young Hwa" , > -----Original Message----- > From: Drake, John E [mailto:John.E.Drake2@boeing.com]=20 > Sent: Friday, October 28, 2005 8:11 PM > To: Zafar Ali (zali); Ong, Lyndon; ibryskin@movaz.com;=20 > dpapadimitriou@psg.com; dimitri.papadimitriou@alcatel.be > Cc: Drake@movaz.com; dimitri.papadimitriou@alcatel.be; Igor=20 > Bryskin; Kim Young Hwa; ccamp@ops.ietf.org > Subject: RE: Two Drafts for Resilience of Control Plane >=20 >=20 >=20 > > -----Original Message----- > > From: Zafar Ali (zali) [mailto:zali@cisco.com] > > Sent: Friday, October 28, 2005 5:08 PM > > To: Drake, John E; Ong, Lyndon; ibryskin@movaz.com;=20 > > dpapadimitriou@psg.com; dimitri.papadimitriou@alcatel.be > > Cc: Drake@movaz.com; dimitri.papadimitriou@alcatel.be; Igor Bryskin; > Kim > > Young Hwa; ccamp@ops.ietf.org > > Subject: RE: Two Drafts for Resilience of Control Plane > >=20 > > > -----Original Message----- > > > From: Drake, John E [mailto:John.E.Drake2@boeing.com] > > > Sent: Friday, October 28, 2005 4:52 PM > > > To: Ong, Lyndon; ibryskin@movaz.com; dpapadimitriou@psg.com;=20 > > > dimitri.papadimitriou@alcatel.be > > > Cc: Drake@movaz.com; dimitri.papadimitriou@alcatel.be;=20 > Igor Bryskin;=20 > > > Zafar Ali (zali); Kim Young Hwa; ccamp@ops.ietf.org > > > Subject: RE: Two Drafts for Resilience of Control Plane > > > > > > > > > > > > > -----Original Message----- > > > > From: Ong, Lyndon [mailto:Lyong@Ciena.com] > > > > Sent: Friday, October 28, 2005 1:28 PM > > > > To: ibryskin@movaz.com; dpapadimitriou@psg.com;=20 > > > > dimitri.papadimitriou@alcatel.be > > > > Cc: Drake@movaz.com; Drake, John E; > > > dimitri.papadimitriou@alcatel.be; > > > Igor > > > > Bryskin; Zafar Ali; Kim Young Hwa; ccamp@ops.ietf.org > > > > Subject: RE: Two Drafts for Resilience of Control Plane > > > > > > > > Hi Igor, > > > > > > > > Are you referring to controlling the LSP while one of the > > > controllers > > > is > > > > still down? That would mean that no restart has yet=20 > taken place. > > > > > > > > The draft seems to be focused on providing standby control > channels, > > > [JD] > > > > > > What is the utility of having standby control channels,=20 > as opposed=20 > > > to just having multiple *active* control channels? > > > > >=20 > > There is no advantage, but there are numerous disadvantages. Having=20 > > multiple *active* control channels is what I was referring to as let > IP > > layer provide the resilience for Control Plane. In fact there are=20 > > disadvantages of having active and standby control channel and some=20 > > other entity have to manage them. Now you have to worry about > signaling > > and control channels to be in-sync, fast switchover, etc. > >=20 > > My motivation is to keep is simple, but yet superior. > [JD]=20 >=20 > Years ago, when we first started on LMP, we had the notion of=20 > active and standby control channels and it was George Swallow=20 > that pointed out that this was a really *BadIdea*tm. >=20 Good news is that "we" are consistent :-) The bad news is that LMP newly born RFC still have this notion [no one listened to George :-( ]. Here are some reasons why "we" think this way:=20 - Redundancy/ HA via IP Layer.=20 - Taken a CC OOS is simple as putting an IF to the control network OOS, and other operational simplicities.=20 - OOS IF can be repair without impacting other links or LMP CC FSM.=20 - One LMP CC FSM per "N" Egress links to control network.=20 - LMP CC FSM is up as long as we have connectivity to the neighbor.=20 - No need to make special arrangements to make signaling and control channel consistent. I.e., both LMP and RSVP Hellos fail only when there is no IP connectivity to the neighbor.=20 - Etc.=20 Thanks Regards... Zafar=20 > Thanks, >=20 > John > >=20 > > Thanks > >=20 > > Regards... Zafar > >=20 > >=20 > > > > what > > > > you're suggesting sounds more like a standby signaling=20 > controller. > > > [JD] > > > > > > A standby signaling controller is an implementation option that=20 > > > shouldn't affect the existing GMPLS protocols > > > > > > > > > > > Cheers, > > > > > > > > Lyndon > > > > > > > > -----Original Message----- > > > > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] > On > > > > Behalf Of ibryskin@movaz.com > > > > Sent: Friday, October 28, 2005 1:08 PM > > > > To: dpapadimitriou@psg.com; dimitri.papadimitriou@alcatel.be > > > > Cc: ibryskin@movaz.com; Drake@movaz.com; John E;=20 > > > > dimitri.papadimitriou@alcatel.be; Igor Bryskin; Zafar Ali; > > > Kim Young > > > > Hwa; ccamp@ops.ietf.org > > > > Subject: Re: Two Drafts for Resilience of Control Plane > > > > > > > > Dimitri, > > > > See in-line. > > > > > igor - > > > > > > > > > > you are already going beyond the specific discussion context > > > > > > > > > > 1. what is a control plane partitioned LSP ? > > > > > > > > LSPs with one or more controllers down, so there is/are > > > partitions in > > > > hop-by-hop signaling > > > > > > > > > > 2. when you state "Suppose one or more signaling controllers > > > managing > > > > > some LSP went out of service leaving the LSP's data plane > > > intact." > > > > > > > > > > what does it mean "one or more controllers" ? what if you > > > support > > > > > RSVP GR ? why are you not able to recover the=20 > states ? etc. > > > > > > > > See my response to John. There are no restarts in my example > > > > > > > > > > > > > > hence, i still miss the exact problem wrt to the=20 > control plane=20 > > > > > protocol resilience > > > > > > > > > > but i think there is another issue (which is even more > > > important) - > > > > > the resilience mechanisms of the control plane that we have > today > > > have > > > > > > > > > been provided based on experience from the common use of > > > the control > > > > > plane and for being resilient wrt common failures - but > > > not for ALL > > > > > use of the control plane in ANY condition and for ALL=20 > possible=20 > > > > > failures - indeed what you are asking here is like what > > > shall i do > > > > > when the CP is completely down and the DP still up; it would > > > surprise > > > > > me that the CP would be of any help in this specific condition > > > > > > > > Believe me, CP could be still of a great help in such > > > conditions. You > > > > need some signaling extensions - which is why I think CP > > > resilience is > > > > an important topic within CCAMP - and then you can manage LSPs > with > > > > control plane gaps at least to the extend I described. > > > > > > > > Igor > > > > > > > > > > > > > > thanks, > > > > > - dimitri. > > > > > > > > > > ibryskin@movaz.com wrote: > > > > > > > > > >> Hi, > > > > >> > > > > >> Here is one of the problems that I've been thinking for > > > a while - > > > > >> control plane partitioned LSPs. Suppose one or more=20 > signaling=20 > > > > >> controllers managing some LSP went out of service > > > leaving the LSP's > > > > >> data plane intact. As far as the user is concerned=20 > such LSP is=20 > > > > >> perfectly healthy and operational. > > > > >> Such situation could last for a considerable period of > > > time. Do we > > > > >> need to manage such LSP via control plane? Sure, we must > > > be capable > > > > >> to tear down such LSP, perform mb4b rerouting, distribute > alarms > > > > >> between operational controllers, signal data plane faults and > > > perform > > > > > > > > >> recovery switchover, modify LSP status, etc. Can we do > > > this today? > > > > >> No, but with some > > > > >> (signaling) extensions the problem I believe is > > > solvable. Is this > > > > >> some artificial, "fabricated" problem? No, I think it is > > > real. Does > > > > >> it fall under the control plane resilience problem > > > space? I believe > > > > it does. > > > > >> > > > > >> Igor > > > > >> > > > > >> > > > > >>>I agree with Zafar and Dimitri. If someone wanted to > > > document the > > > > >>>GMPLS control plane resiliency features, as was done=20 > for GMPLS=20 > > > > >>>addressing, that might be a useful activity. > > > > >>> > > > > >>> > > > > >>>>-----Original Message----- > > > > >>>>From: dimitri papadimitriou [mailto:dpapadimitriou@psg.com] > > > > >>>>Sent: Friday, October 28, 2005 9:56 AM > > > > >>>>To: Igor Bryskin > > > > >>>>Cc: Zafar Ali (zali); Kim Young Hwa; ccamp@ops.ietf.org > > > > >>>>Subject: Re: Two Drafts for Resilience of Control Plane > > > > >>>> > > > > >>>>igor - > > > > >>>> > > > > >>>>over time CCAMP came with a set of mechanims to improve > control > > > > >>>>plane resilience (RSVP and LMP GR upon channel/node > > > failure) other > > > > >>>>WG > > > > >>> > > > > >>>protocol > > > > >>> > > > > >>>>work are also usable used here OSPF GR, etc. ... on=20 > the other > > > side, > > > > >>>>mechanism such as link bundling have built-in resilience=20 > > > > >>>>capabilities and most GMPLS control plane capabilities > > > have been > > > > >>>>designed such as > > > > >>> > > > > >>>to > > > > >>> > > > > >>>>be independent of the control plane realisation (in-band,=20 > > > > >>>>out-of-band, > > > > >>>>etc.) > > > > >>>> > > > > >>>>so indeed i share the concern of Zafar what could we do > > > more here > > > > >>>>than document these tools and provide our=20 > experience in using > > > them; > > > > >>>> > > > > >>>>now, before stating there are (potential)=20 > problems(s) arising > - > > > > >>>>would you please be more specific on what are these=20 > potential > > > > >>>>issue(s) > > > > >>> > > > > >>>and/or > > > > >>> > > > > >>>>problems ? (not related to policy/config. - note: all the > issues > > > you > > > > > > > > >>>>have pointed here below are simply policy/config > > > specific but none > > > > >>>>of them highlights a missing IP control plane > > > resiliency feature) > > > > >>>> > > > > >>>>thanks, > > > > >>>>- dimitri. > > > > >>>> > > > > >>>> > > > > >>>>Igor Bryskin wrote: > > > > >>>> > > > > >>>> > > > > >>>>>Zafar, > > > > >>>>> > > > > >>>>>The problem arises when the control plane is decoupled > > > from the > > > > >>>>>data plane. The question is do we need such=20 > decoupling in IP=20 > > > > >>>>>networks? Consider, for example, the situation=20 > when several=20 > > > > >>>>>parallel PSC data links bundled together and=20 > controlled by a > > > single > > > > > > > > >>>>>control channel. > > > > >>>>>Does it mean in this case that when the control > > > channel fails all > > > > >>>>>associated data links also fail? Do we need to reroute in > this > > > case > > > > > > > > >>>>>LSPs that use the data links? Can we rely in this case > > > on control > > > > >>>>>plane indications to decide whether an associated data link > is > > > > >>>>>healthy or not (in other words, can we rely on=20 > RSVP Hellos or=20 > > > > >>>>>should we use, for example, BTD)? Should we be capable > > > to recover > > > > >>>>>control channels without disturbing data plane? I > > > think control > > > > >>>>>plane resilience is important for all layers. You=20 > are right,=20 > > > > >>>>>Internet does work, however, we do need for some reason TE > and > > > > >>>>>(fast) recovery in IP as much as in other layers,don't we? > > > > >>>>> > > > > >>>>>Cheers, > > > > >>>>>Igor > > > > >>>>> > > > > >>>>>--- "Zafar Ali (zali)" wrote: > > > > >>>>> > > > > >>>>> > > > > >>>>> > > > > >>>>>>Hi All, > > > > >>>>>> > > > > >>>>>>I am unable to understand the problem we are trying > > > to solve or > > > > >>>>>>fabricate. My control network is IP based and IP=20 > has proven=20 > > > > >>>>>>resiliency (Internet *does* work), why would I=20 > like to take=20 > > > > >>>>>>control plan resiliency problem at a layer *above-IP* and=20 > > > > >>>>>>complicate my life. Did I miss something? > > > > >>>>>> > > > > >>>>>>Thanks > > > > >>>>>> > > > > >>>>>>Regards... Zafar > > > > >>>>>> > > > > >>>>>> > > > > >>>>>>________________________________ > > > > >>>>>> > > > > >>>>>> From: owner-ccamp@ops.ietf.org=20 > > > > >>>>>>[mailto:owner-ccamp@ops.ietf.org] > > > > >>>>>>On Behalf Of Kim Young Hwa > > > > >>>>>> Sent: Friday, October 28, 2005 6:04 AM > > > > >>>>>> To: ccamp@ops.ietf.org > > > > >>>>>> Subject: Two Drafts for Resilience of Control Plane > > > > >>>>>> > > > > >>>>>> > > > > >>>>>> Dear all, > > > > >>>>>> > > > > >>>>>> I posted two drafts for the resilience of control plane. > > > > >>>>>> One is for requirements of the resilience of control > > > plane, > > > > the > > > > >>>>>>other is for a protocol specification as a=20 > solution of that > . > > > > >>>>>> These are now available at: > > > > >>>>>> > > > > >>>>>> > > > > >>>>> > > > > > > > >>>>>http://www.ietf.org/internet-drafts/draft-kim-ccamp-cpr-r > > > eqts-01.tx > > > > >>>>>t > > > > >>>>> > > > > >>>>> > > > > >>>>>> > > > > >>>>> > > > > > > > >>>http://www.ietf.org/internet-drafts/draft-kim-ccamp-accp-pr > > > otocol-00. > > > > >>>txt > > > > >>> > > > > >>>>>> I want your comments. > > > > >>>>>> > > > > >>>>>> Regards > > > > >>>>>> > > > > >>>>>> Young. > > > > >>>>>> > > > > >>>>>> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D> >> Young-Hwa Kim > > > > >>>>>> Principal Member / Ph.D > > > > >>>>>> BcN Research Division, ETRI > > > > >>>>>> Tel: +82-42-860-5819 > > > > >>>>>> Fax: +82-42-860-5440 > > > > >>>>>> e-mail: yhwkim@etri.re.kr > > > > >>>>>> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D> >> > > > > >>>>>> > > > > >>>>> > > > > > > > >>> > > p@ops.ietf > > > > >>>.or > > > > >>> > > > > >>>>> > > > > > > > >>>g&name=3Dccamp%40ops.ietf.org&fromemail=3Dyhwkim@etri.re.kr&mes > > > sageid=3D%3C > > > > >>>863 > > > > >>> > > > > >>>>>>0a6db-0c31-49ab-a798-13b0dda04553@etri.re.kr%3E> > > > > >>>>>> > > > > >>>>>> > > > > >>>>> > > > > >>>>> > > > > >>>>> > > > > >>>>> > > > > >>>>> > > > > >>>>>__________________________________ > > > > >>>>>Yahoo! Mail - PC Magazine Editors' Choice 2005=20 > > > > >>>>>http://mail.yahoo.com > > > > >>>>> > > > > >>>>> > > > > >>>>>. > > > > >>>>> > > > > >>> > > > > >>> > > > > >>> > > > > >> > > > > >> > > > > >> > > > > >> . > > > > >> > > > > > > > > > > > > >=20 Envelope-to: ccamp-data@psg.com Delivery-date: Sat, 29 Oct 2005 00:11:37 +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: Two Drafts for Resilience of Control Plane Date: Fri, 28 Oct 2005 17:11:22 -0700 Message-ID: <626FC7C6A97381468FB872072AB5DDC836970A@XCH-SW-42.sw.nos.boeing.com> Thread-Topic: Two Drafts for Resilience of Control Plane Thread-Index: AcXb+5sI7DBursUUSnCMr5SUjjw6QQAAZ19AAADmq6AABtIYwAAANgdA From: "Drake, John E" To: "Zafar Ali \(zali\)" , "Ong, Lyndon" , , , Cc: , , "Igor Bryskin" , "Kim Young Hwa" , > -----Original Message----- > From: Zafar Ali (zali) [mailto:zali@cisco.com] > Sent: Friday, October 28, 2005 5:08 PM > To: Drake, John E; Ong, Lyndon; ibryskin@movaz.com; > dpapadimitriou@psg.com; dimitri.papadimitriou@alcatel.be > Cc: Drake@movaz.com; dimitri.papadimitriou@alcatel.be; Igor Bryskin; Kim > Young Hwa; ccamp@ops.ietf.org > Subject: RE: Two Drafts for Resilience of Control Plane >=20 > > -----Original Message----- > > From: Drake, John E [mailto:John.E.Drake2@boeing.com] > > Sent: Friday, October 28, 2005 4:52 PM > > To: Ong, Lyndon; ibryskin@movaz.com; dpapadimitriou@psg.com; > > dimitri.papadimitriou@alcatel.be > > Cc: Drake@movaz.com; dimitri.papadimitriou@alcatel.be; Igor > > Bryskin; Zafar Ali (zali); Kim Young Hwa; ccamp@ops.ietf.org > > Subject: RE: Two Drafts for Resilience of Control Plane > > > > > > > > > -----Original Message----- > > > From: Ong, Lyndon [mailto:Lyong@Ciena.com] > > > Sent: Friday, October 28, 2005 1:28 PM > > > To: ibryskin@movaz.com; dpapadimitriou@psg.com; > > > dimitri.papadimitriou@alcatel.be > > > Cc: Drake@movaz.com; Drake, John E; > > dimitri.papadimitriou@alcatel.be; > > Igor > > > Bryskin; Zafar Ali; Kim Young Hwa; ccamp@ops.ietf.org > > > Subject: RE: Two Drafts for Resilience of Control Plane > > > > > > Hi Igor, > > > > > > Are you referring to controlling the LSP while one of the > > controllers > > is > > > still down? That would mean that no restart has yet taken place. > > > > > > The draft seems to be focused on providing standby control channels, > > [JD] > > > > What is the utility of having standby control channels, as > > opposed to just having multiple *active* control channels? > > >=20 > There is no advantage, but there are numerous disadvantages. Having > multiple *active* control channels is what I was referring to as let IP > layer provide the resilience for Control Plane. In fact there are > disadvantages of having active and standby control channel and some > other entity have to manage them. Now you have to worry about signaling > and control channels to be in-sync, fast switchover, etc. >=20 > My motivation is to keep is simple, but yet superior. [JD]=20 Years ago, when we first started on LMP, we had the notion of active and standby control channels and it was George Swallow that pointed out that this was a really *BadIdea*tm. Thanks, John >=20 > Thanks >=20 > Regards... Zafar >=20 >=20 > > > what > > > you're suggesting sounds more like a standby signaling controller. > > [JD] > > > > A standby signaling controller is an implementation option > > that shouldn't affect the existing GMPLS protocols > > > > > > > > Cheers, > > > > > > Lyndon > > > > > > -----Original Message----- > > > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On > > > Behalf Of ibryskin@movaz.com > > > Sent: Friday, October 28, 2005 1:08 PM > > > To: dpapadimitriou@psg.com; dimitri.papadimitriou@alcatel.be > > > Cc: ibryskin@movaz.com; Drake@movaz.com; John E; > > > dimitri.papadimitriou@alcatel.be; Igor Bryskin; Zafar Ali; > > Kim Young > > > Hwa; ccamp@ops.ietf.org > > > Subject: Re: Two Drafts for Resilience of Control Plane > > > > > > Dimitri, > > > See in-line. > > > > igor - > > > > > > > > you are already going beyond the specific discussion context > > > > > > > > 1. what is a control plane partitioned LSP ? > > > > > > LSPs with one or more controllers down, so there is/are > > partitions in > > > hop-by-hop signaling > > > > > > > > 2. when you state "Suppose one or more signaling controllers > > managing > > > > some LSP went out of service leaving the LSP's data plane > > intact." > > > > > > > > what does it mean "one or more controllers" ? what if you > > support > > > > RSVP GR ? why are you not able to recover the states ? etc. > > > > > > See my response to John. There are no restarts in my example > > > > > > > > > > > hence, i still miss the exact problem wrt to the control plane > > > > protocol resilience > > > > > > > > but i think there is another issue (which is even more > > important) - > > > > the resilience mechanisms of the control plane that we have today > > have > > > > > > > been provided based on experience from the common use of > > the control > > > > plane and for being resilient wrt common failures - but > > not for ALL > > > > use of the control plane in ANY condition and for ALL possible > > > > failures - indeed what you are asking here is like what > > shall i do > > > > when the CP is completely down and the DP still up; it would > > surprise > > > > me that the CP would be of any help in this specific condition > > > > > > Believe me, CP could be still of a great help in such > > conditions. You > > > need some signaling extensions - which is why I think CP > > resilience is > > > an important topic within CCAMP - and then you can manage LSPs with > > > control plane gaps at least to the extend I described. > > > > > > Igor > > > > > > > > > > > thanks, > > > > - dimitri. > > > > > > > > ibryskin@movaz.com wrote: > > > > > > > >> Hi, > > > >> > > > >> Here is one of the problems that I've been thinking for > > a while - > > > >> control plane partitioned LSPs. Suppose one or more signaling > > > >> controllers managing some LSP went out of service > > leaving the LSP's > > > >> data plane intact. As far as the user is concerned such LSP is > > > >> perfectly healthy and operational. > > > >> Such situation could last for a considerable period of > > time. Do we > > > >> need to manage such LSP via control plane? Sure, we must > > be capable > > > >> to tear down such LSP, perform mb4b rerouting, distribute alarms > > > >> between operational controllers, signal data plane faults and > > perform > > > > > > >> recovery switchover, modify LSP status, etc. Can we do > > this today? > > > >> No, but with some > > > >> (signaling) extensions the problem I believe is > > solvable. Is this > > > >> some artificial, "fabricated" problem? No, I think it is > > real. Does > > > >> it fall under the control plane resilience problem > > space? I believe > > > it does. > > > >> > > > >> Igor > > > >> > > > >> > > > >>>I agree with Zafar and Dimitri. If someone wanted to > > document the > > > >>>GMPLS control plane resiliency features, as was done for GMPLS > > > >>>addressing, that might be a useful activity. > > > >>> > > > >>> > > > >>>>-----Original Message----- > > > >>>>From: dimitri papadimitriou [mailto:dpapadimitriou@psg.com] > > > >>>>Sent: Friday, October 28, 2005 9:56 AM > > > >>>>To: Igor Bryskin > > > >>>>Cc: Zafar Ali (zali); Kim Young Hwa; ccamp@ops.ietf.org > > > >>>>Subject: Re: Two Drafts for Resilience of Control Plane > > > >>>> > > > >>>>igor - > > > >>>> > > > >>>>over time CCAMP came with a set of mechanims to improve control > > > >>>>plane resilience (RSVP and LMP GR upon channel/node > > failure) other > > > >>>>WG > > > >>> > > > >>>protocol > > > >>> > > > >>>>work are also usable used here OSPF GR, etc. ... on the other > > side, > > > >>>>mechanism such as link bundling have built-in resilience > > > >>>>capabilities and most GMPLS control plane capabilities > > have been > > > >>>>designed such as > > > >>> > > > >>>to > > > >>> > > > >>>>be independent of the control plane realisation (in-band, > > > >>>>out-of-band, > > > >>>>etc.) > > > >>>> > > > >>>>so indeed i share the concern of Zafar what could we do > > more here > > > >>>>than document these tools and provide our experience in using > > them; > > > >>>> > > > >>>>now, before stating there are (potential) problems(s) arising - > > > >>>>would you please be more specific on what are these potential > > > >>>>issue(s) > > > >>> > > > >>>and/or > > > >>> > > > >>>>problems ? (not related to policy/config. - note: all the issues > > you > > > > > > >>>>have pointed here below are simply policy/config > > specific but none > > > >>>>of them highlights a missing IP control plane > > resiliency feature) > > > >>>> > > > >>>>thanks, > > > >>>>- dimitri. > > > >>>> > > > >>>> > > > >>>>Igor Bryskin wrote: > > > >>>> > > > >>>> > > > >>>>>Zafar, > > > >>>>> > > > >>>>>The problem arises when the control plane is decoupled > > from the > > > >>>>>data plane. The question is do we need such decoupling in IP > > > >>>>>networks? Consider, for example, the situation when several > > > >>>>>parallel PSC data links bundled together and controlled by a > > single > > > > > > >>>>>control channel. > > > >>>>>Does it mean in this case that when the control > > channel fails all > > > >>>>>associated data links also fail? Do we need to reroute in this > > case > > > > > > >>>>>LSPs that use the data links? Can we rely in this case > > on control > > > >>>>>plane indications to decide whether an associated data link is > > > >>>>>healthy or not (in other words, can we rely on RSVP Hellos or > > > >>>>>should we use, for example, BTD)? Should we be capable > > to recover > > > >>>>>control channels without disturbing data plane? I > > think control > > > >>>>>plane resilience is important for all layers. You are right, > > > >>>>>Internet does work, however, we do need for some reason TE and > > > >>>>>(fast) recovery in IP as much as in other layers,don't we? > > > >>>>> > > > >>>>>Cheers, > > > >>>>>Igor > > > >>>>> > > > >>>>>--- "Zafar Ali (zali)" wrote: > > > >>>>> > > > >>>>> > > > >>>>> > > > >>>>>>Hi All, > > > >>>>>> > > > >>>>>>I am unable to understand the problem we are trying > > to solve or > > > >>>>>>fabricate. My control network is IP based and IP has proven > > > >>>>>>resiliency (Internet *does* work), why would I like to take > > > >>>>>>control plan resiliency problem at a layer *above-IP* and > > > >>>>>>complicate my life. Did I miss something? > > > >>>>>> > > > >>>>>>Thanks > > > >>>>>> > > > >>>>>>Regards... Zafar > > > >>>>>> > > > >>>>>> > > > >>>>>>________________________________ > > > >>>>>> > > > >>>>>> From: owner-ccamp@ops.ietf.org > > > >>>>>>[mailto:owner-ccamp@ops.ietf.org] > > > >>>>>>On Behalf Of Kim Young Hwa > > > >>>>>> Sent: Friday, October 28, 2005 6:04 AM > > > >>>>>> To: ccamp@ops.ietf.org > > > >>>>>> Subject: Two Drafts for Resilience of Control Plane > > > >>>>>> > > > >>>>>> > > > >>>>>> Dear all, > > > >>>>>> > > > >>>>>> I posted two drafts for the resilience of control plane. > > > >>>>>> One is for requirements of the resilience of control > > plane, > > > the > > > >>>>>>other is for a protocol specification as a solution of that . > > > >>>>>> These are now available at: > > > >>>>>> > > > >>>>>> > > > >>>>> > > > > > >>>>>http://www.ietf.org/internet-drafts/draft-kim-ccamp-cpr-r > > eqts-01.tx > > > >>>>>t > > > >>>>> > > > >>>>> > > > >>>>>> > > > >>>>> > > > > > >>>http://www.ietf.org/internet-drafts/draft-kim-ccamp-accp-pr > > otocol-00. > > > >>>txt > > > >>> > > > >>>>>> I want your comments. > > > >>>>>> > > > >>>>>> Regards > > > >>>>>> > > > >>>>>> Young. > > > >>>>>> > > > >>>>>> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D> >> Young-Hwa Kim > > > >>>>>> Principal Member / Ph.D > > > >>>>>> BcN Research Division, ETRI > > > >>>>>> Tel: +82-42-860-5819 > > > >>>>>> Fax: +82-42-860-5440 > > > >>>>>> e-mail: yhwkim@etri.re.kr > > > >>>>>> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D> >> > > > >>>>>> > > > >>>>> > > > > > >>> > p@ops.ietf > > > >>>.or > > > >>> > > > >>>>> > > > > > >>>g&name=3Dccamp%40ops.ietf.org&fromemail=3Dyhwkim@etri.re.kr&mes > > sageid=3D%3C > > > >>>863 > > > >>> > > > >>>>>>0a6db-0c31-49ab-a798-13b0dda04553@etri.re.kr%3E> > > > >>>>>> > > > >>>>>> > > > >>>>> > > > >>>>> > > > >>>>> > > > >>>>> > > > >>>>> > > > >>>>>__________________________________ > > > >>>>>Yahoo! Mail - PC Magazine Editors' Choice 2005 > > > >>>>>http://mail.yahoo.com > > > >>>>> > > > >>>>> > > > >>>>>. > > > >>>>> > > > >>> > > > >>> > > > >>> > > > >> > > > >> > > > >> > > > >> . > > > >> > > > > > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Sat, 29 Oct 2005 00:08:35 +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: Two Drafts for Resilience of Control Plane Date: Fri, 28 Oct 2005 20:07:55 -0400 Message-ID: Thread-Topic: Two Drafts for Resilience of Control Plane Thread-Index: AcXb+5sI7DBursUUSnCMr5SUjjw6QQAAZ19AAADmq6AABtIYwA== From: "Zafar Ali \(zali\)" To: "Drake, John E" , "Ong, Lyndon" , , , Cc: , , "Igor Bryskin" , "Kim Young Hwa" , > -----Original Message----- > From: Drake, John E [mailto:John.E.Drake2@boeing.com]=20 > Sent: Friday, October 28, 2005 4:52 PM > To: Ong, Lyndon; ibryskin@movaz.com; dpapadimitriou@psg.com;=20 > dimitri.papadimitriou@alcatel.be > Cc: Drake@movaz.com; dimitri.papadimitriou@alcatel.be; Igor=20 > Bryskin; Zafar Ali (zali); Kim Young Hwa; ccamp@ops.ietf.org > Subject: RE: Two Drafts for Resilience of Control Plane >=20 >=20 >=20 > > -----Original Message----- > > From: Ong, Lyndon [mailto:Lyong@Ciena.com] > > Sent: Friday, October 28, 2005 1:28 PM > > To: ibryskin@movaz.com; dpapadimitriou@psg.com;=20 > > dimitri.papadimitriou@alcatel.be > > Cc: Drake@movaz.com; Drake, John E;=20 > dimitri.papadimitriou@alcatel.be; > Igor > > Bryskin; Zafar Ali; Kim Young Hwa; ccamp@ops.ietf.org > > Subject: RE: Two Drafts for Resilience of Control Plane > >=20 > > Hi Igor, > >=20 > > Are you referring to controlling the LSP while one of the=20 > controllers > is > > still down? That would mean that no restart has yet taken place. > >=20 > > The draft seems to be focused on providing standby control channels, > [JD]=20 >=20 > What is the utility of having standby control channels, as=20 > opposed to just having multiple *active* control channels? >=20 There is no advantage, but there are numerous disadvantages. Having multiple *active* control channels is what I was referring to as let IP layer provide the resilience for Control Plane. In fact there are disadvantages of having active and standby control channel and some other entity have to manage them. Now you have to worry about signaling and control channels to be in-sync, fast switchover, etc.=20 My motivation is to keep is simple, but yet superior.=20 Thanks Regards... Zafar=20 > > what > > you're suggesting sounds more like a standby signaling controller. > [JD]=20 >=20 > A standby signaling controller is an implementation option=20 > that shouldn't affect the existing GMPLS protocols >=20 > >=20 > > Cheers, > >=20 > > Lyndon > >=20 > > -----Original Message----- > > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On=20 > > Behalf Of ibryskin@movaz.com > > Sent: Friday, October 28, 2005 1:08 PM > > To: dpapadimitriou@psg.com; dimitri.papadimitriou@alcatel.be > > Cc: ibryskin@movaz.com; Drake@movaz.com; John E;=20 > > dimitri.papadimitriou@alcatel.be; Igor Bryskin; Zafar Ali;=20 > Kim Young=20 > > Hwa; ccamp@ops.ietf.org > > Subject: Re: Two Drafts for Resilience of Control Plane > >=20 > > Dimitri, > > See in-line. > > > igor - > > > > > > you are already going beyond the specific discussion context > > > > > > 1. what is a control plane partitioned LSP ? > >=20 > > LSPs with one or more controllers down, so there is/are=20 > partitions in=20 > > hop-by-hop signaling > > > > > > 2. when you state "Suppose one or more signaling controllers > managing > > > some LSP went out of service leaving the LSP's data plane > intact." > > > > > > what does it mean "one or more controllers" ? what if you > support > > > RSVP GR ? why are you not able to recover the states ? etc. > >=20 > > See my response to John. There are no restarts in my example > >=20 > > > > > > hence, i still miss the exact problem wrt to the control plane=20 > > > protocol resilience > > > > > > but i think there is another issue (which is even more=20 > important) -=20 > > > the resilience mechanisms of the control plane that we have today > have > >=20 > > > been provided based on experience from the common use of=20 > the control=20 > > > plane and for being resilient wrt common failures - but=20 > not for ALL=20 > > > use of the control plane in ANY condition and for ALL possible=20 > > > failures - indeed what you are asking here is like what=20 > shall i do=20 > > > when the CP is completely down and the DP still up; it would > surprise > > > me that the CP would be of any help in this specific condition > >=20 > > Believe me, CP could be still of a great help in such=20 > conditions. You=20 > > need some signaling extensions - which is why I think CP=20 > resilience is=20 > > an important topic within CCAMP - and then you can manage LSPs with=20 > > control plane gaps at least to the extend I described. > >=20 > > Igor > >=20 > > > > > > thanks, > > > - dimitri. > > > > > > ibryskin@movaz.com wrote: > > > > > >> Hi, > > >> > > >> Here is one of the problems that I've been thinking for=20 > a while -=20 > > >> control plane partitioned LSPs. Suppose one or more signaling=20 > > >> controllers managing some LSP went out of service=20 > leaving the LSP's=20 > > >> data plane intact. As far as the user is concerned such LSP is=20 > > >> perfectly healthy and operational. > > >> Such situation could last for a considerable period of=20 > time. Do we=20 > > >> need to manage such LSP via control plane? Sure, we must=20 > be capable=20 > > >> to tear down such LSP, perform mb4b rerouting, distribute alarms=20 > > >> between operational controllers, signal data plane faults and > perform > >=20 > > >> recovery switchover, modify LSP status, etc. Can we do=20 > this today? > > >> No, but with some > > >> (signaling) extensions the problem I believe is=20 > solvable. Is this=20 > > >> some artificial, "fabricated" problem? No, I think it is=20 > real. Does=20 > > >> it fall under the control plane resilience problem=20 > space? I believe > > it does. > > >> > > >> Igor > > >> > > >> > > >>>I agree with Zafar and Dimitri. If someone wanted to=20 > document the=20 > > >>>GMPLS control plane resiliency features, as was done for GMPLS=20 > > >>>addressing, that might be a useful activity. > > >>> > > >>> > > >>>>-----Original Message----- > > >>>>From: dimitri papadimitriou [mailto:dpapadimitriou@psg.com] > > >>>>Sent: Friday, October 28, 2005 9:56 AM > > >>>>To: Igor Bryskin > > >>>>Cc: Zafar Ali (zali); Kim Young Hwa; ccamp@ops.ietf.org > > >>>>Subject: Re: Two Drafts for Resilience of Control Plane > > >>>> > > >>>>igor - > > >>>> > > >>>>over time CCAMP came with a set of mechanims to improve control=20 > > >>>>plane resilience (RSVP and LMP GR upon channel/node=20 > failure) other=20 > > >>>>WG > > >>> > > >>>protocol > > >>> > > >>>>work are also usable used here OSPF GR, etc. ... on the other > side, > > >>>>mechanism such as link bundling have built-in resilience=20 > > >>>>capabilities and most GMPLS control plane capabilities=20 > have been=20 > > >>>>designed such as > > >>> > > >>>to > > >>> > > >>>>be independent of the control plane realisation (in-band,=20 > > >>>>out-of-band, > > >>>>etc.) > > >>>> > > >>>>so indeed i share the concern of Zafar what could we do=20 > more here=20 > > >>>>than document these tools and provide our experience in using > them; > > >>>> > > >>>>now, before stating there are (potential) problems(s) arising -=20 > > >>>>would you please be more specific on what are these potential > > >>>>issue(s) > > >>> > > >>>and/or > > >>> > > >>>>problems ? (not related to policy/config. - note: all the issues > you > >=20 > > >>>>have pointed here below are simply policy/config=20 > specific but none=20 > > >>>>of them highlights a missing IP control plane=20 > resiliency feature) > > >>>> > > >>>>thanks, > > >>>>- dimitri. > > >>>> > > >>>> > > >>>>Igor Bryskin wrote: > > >>>> > > >>>> > > >>>>>Zafar, > > >>>>> > > >>>>>The problem arises when the control plane is decoupled=20 > from the=20 > > >>>>>data plane. The question is do we need such decoupling in IP=20 > > >>>>>networks? Consider, for example, the situation when several=20 > > >>>>>parallel PSC data links bundled together and controlled by a > single > >=20 > > >>>>>control channel. > > >>>>>Does it mean in this case that when the control=20 > channel fails all=20 > > >>>>>associated data links also fail? Do we need to reroute in this > case > >=20 > > >>>>>LSPs that use the data links? Can we rely in this case=20 > on control=20 > > >>>>>plane indications to decide whether an associated data link is=20 > > >>>>>healthy or not (in other words, can we rely on RSVP Hellos or=20 > > >>>>>should we use, for example, BTD)? Should we be capable=20 > to recover=20 > > >>>>>control channels without disturbing data plane? I=20 > think control=20 > > >>>>>plane resilience is important for all layers. You are right,=20 > > >>>>>Internet does work, however, we do need for some reason TE and > > >>>>>(fast) recovery in IP as much as in other layers,don't we? > > >>>>> > > >>>>>Cheers, > > >>>>>Igor > > >>>>> > > >>>>>--- "Zafar Ali (zali)" wrote: > > >>>>> > > >>>>> > > >>>>> > > >>>>>>Hi All, > > >>>>>> > > >>>>>>I am unable to understand the problem we are trying=20 > to solve or=20 > > >>>>>>fabricate. My control network is IP based and IP has proven=20 > > >>>>>>resiliency (Internet *does* work), why would I like to take=20 > > >>>>>>control plan resiliency problem at a layer *above-IP* and=20 > > >>>>>>complicate my life. Did I miss something? > > >>>>>> > > >>>>>>Thanks > > >>>>>> > > >>>>>>Regards... Zafar > > >>>>>> > > >>>>>> > > >>>>>>________________________________ > > >>>>>> > > >>>>>> From: owner-ccamp@ops.ietf.org > > >>>>>>[mailto:owner-ccamp@ops.ietf.org] > > >>>>>>On Behalf Of Kim Young Hwa > > >>>>>> Sent: Friday, October 28, 2005 6:04 AM > > >>>>>> To: ccamp@ops.ietf.org > > >>>>>> Subject: Two Drafts for Resilience of Control Plane > > >>>>>> > > >>>>>> > > >>>>>> Dear all, > > >>>>>> > > >>>>>> I posted two drafts for the resilience of control plane. > > >>>>>> One is for requirements of the resilience of control > plane, > > the > > >>>>>>other is for a protocol specification as a solution of that . > > >>>>>> These are now available at: > > >>>>>> > > >>>>>> > > >>>>> > > > >>>>>http://www.ietf.org/internet-drafts/draft-kim-ccamp-cpr-r > eqts-01.tx > > >>>>>t > > >>>>> > > >>>>> > > >>>>>> > > >>>>> > > > >>>http://www.ietf.org/internet-drafts/draft-kim-ccamp-accp-pr > otocol-00. > > >>>txt > > >>> > > >>>>>> I want your comments. > > >>>>>> > > >>>>>> Regards > > >>>>>> > > >>>>>> Young. > > >>>>>> > > >>>>>> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D> >> Young-Hwa Kim > > >>>>>> Principal Member / Ph.D > > >>>>>> BcN Research Division, ETRI > > >>>>>> Tel: +82-42-860-5819 > > >>>>>> Fax: +82-42-860-5440 > > >>>>>> e-mail: yhwkim@etri.re.kr > > >>>>>> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D> >> > > >>>>>> > > >>>>> > > > >>> p@ops.ietf > > >>>.or > > >>> > > >>>>> > > > >>>g&name=3Dccamp%40ops.ietf.org&fromemail=3Dyhwkim@etri.re.kr&mes > sageid=3D%3C > > >>>863 > > >>> > > >>>>>>0a6db-0c31-49ab-a798-13b0dda04553@etri.re.kr%3E> > > >>>>>> > > >>>>>> > > >>>>> > > >>>>> > > >>>>> > > >>>>> > > >>>>> > > >>>>>__________________________________ > > >>>>>Yahoo! Mail - PC Magazine Editors' Choice 2005=20 > > >>>>>http://mail.yahoo.com > > >>>>> > > >>>>> > > >>>>>. > > >>>>> > > >>> > > >>> > > >>> > > >> > > >> > > >> > > >> . > > >> > > > > >=20 >=20 Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 28 Oct 2005 23:53:07 +0000 Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed Message-Id: <3164AFEA-F073-48EB-852C-E256C211BF47@cisco.com> Cc: Drake@movaz.com, John E , "Dimitri.Papadimitriou" , Igor Bryskin , Zafar Ali , Kim Young Hwa , ccamp@ops.ietf.org Content-Transfer-Encoding: quoted-printable From: "Thomas D. Nadeau" Subject: Re: Two Drafts for Resilience of Control Plane Date: Fri, 28 Oct 2005 19:51:40 -0400 To: dpapadimitriou@psg.com, "Dimitri.Papadimitriou" Just like with 'classic' MPLS, with GMPLS I think you have a situation where the data and control planes could be out of sync., or at least out of contact with each other for a period of time. This is certainly not a fabricated problem, but a matter of 'how often' and 'how bad' when it happens (i.e.: is the IP control plane sufficiently resilient) As Zafar said earlier, there are already some mechanisms in place to handle this. Some folks (vendors only) have said they are sufficient. To me, this should be a question that operator types should be answering. --Tom > Hi, > > Here is one of the problems that I=92ve been thinking for a while =96 =20= > control > plane partitioned LSPs. Suppose one or more signaling controllers =20 > managing > some LSP went out of service leaving the LSP=92s data plane intact. =20= > As far > as the user is concerned such LSP is perfectly healthy and =20 > operational. > Such situation could last for a considerable period of time. Do we =20 > need to > manage such LSP via control plane? Sure, we must be capable to tear =20= > down > such LSP, perform mb4b rerouting, distribute alarms between =20 > operational > controllers, signal data plane faults and perform recovery switchover, > modify LSP status, etc. Can we do this today? No, but with some > (signaling) extensions the problem I believe is solvable. Is this some > artificial, =93fabricated=94 problem? No, I think it is real. Does it = fall > under the control plane resilience problem space? I believe it does. > > Igor > > > >> I agree with Zafar and Dimitri. If someone wanted to document the =20= >> GMPLS >> control plane resiliency features, as was done for GMPLS addressing, >> that might be a useful activity. >> >> >> >>> -----Original Message----- >>> From: dimitri papadimitriou [mailto:dpapadimitriou@psg.com] >>> Sent: Friday, October 28, 2005 9:56 AM >>> To: Igor Bryskin >>> Cc: Zafar Ali (zali); Kim Young Hwa; ccamp@ops.ietf.org >>> Subject: Re: Two Drafts for Resilience of Control Plane >>> >>> igor - >>> >>> over time CCAMP came with a set of mechanims to improve control =20 >>> plane >>> resilience (RSVP and LMP GR upon channel/node failure) other WG >>> >>> >> protocol >> >> >>> work are also usable used here OSPF GR, etc. ... on the other side, >>> mechanism such as link bundling have built-in resilience =20 >>> capabilities >>> and most GMPLS control plane capabilities have been designed such as >>> >>> >> to >> >> >>> be independent of the control plane realisation (in-band, out-of-=20 >>> band, >>> etc.) >>> >>> so indeed i share the concern of Zafar what could we do more here =20= >>> than >>> document these tools and provide our experience in using them; >>> >>> now, before stating there are (potential) problems(s) arising - =20 >>> would >>> you please be more specific on what are these potential issue(s) >>> >>> >> and/or >> >> >>> problems ? (not related to policy/config. - note: all the issues you >>> have pointed here below are simply policy/config specific but =20 >>> none of >>> them highlights a missing IP control plane resiliency feature) >>> >>> thanks, >>> - dimitri. >>> >>> >>> Igor Bryskin wrote: >>> >>> >>> >>>> Zafar, >>>> >>>> The problem arises when the control plane is decoupled >>>> from the data plane. The question is do we need such >>>> decoupling in IP networks? Consider, for example, the >>>> situation when several parallel PSC data links bundled >>>> together and controlled by a single control channel. >>>> Does it mean in this case that when the control >>>> channel fails all associated data links also fail? Do >>>> we need to reroute in this case LSPs that use the data >>>> links? Can we rely in this case on control plane >>>> indications to decide whether an associated data link >>>> is healthy or not (in other words, can we rely on RSVP >>>> Hellos or should we use, for example, BTD)? Should we >>>> be capable to recover control channels without >>>> disturbing data plane? I think control plane >>>> resilience is important for all layers. You are right, >>>> Internet does work, however, we do need for some >>>> reason TE and (fast) recovery in IP as much as in >>>> other layers,don't we? >>>> >>>> Cheers, >>>> Igor >>>> >>>> --- "Zafar Ali (zali)" wrote: >>>> >>>> >>>> >>>> >>>>> Hi All, >>>>> >>>>> I am unable to understand the problem we are trying >>>>> to solve or >>>>> fabricate. My control network is IP based and IP has >>>>> proven resiliency >>>>> (Internet *does* work), why would I like to take >>>>> control plan resiliency >>>>> problem at a layer *above-IP* and complicate my >>>>> life. Did I miss >>>>> something? >>>>> >>>>> Thanks >>>>> >>>>> Regards... Zafar >>>>> >>>>> >>>>> ________________________________ >>>>> >>>>> From: owner-ccamp@ops.ietf.org >>>>> [mailto:owner-ccamp@ops.ietf.org] >>>>> On Behalf Of Kim Young Hwa >>>>> Sent: Friday, October 28, 2005 6:04 AM >>>>> To: ccamp@ops.ietf.org >>>>> Subject: Two Drafts for Resilience of Control Plane >>>>> >>>>> >>>>> Dear all, >>>>> >>>>> I posted two drafts for the resilience of control >>>>> plane. >>>>> One is for requirements of the resilience of >>>>> control plane, the >>>>> other is for a protocol specification as a solution >>>>> of that . >>>>> These are now available at: >>>>> >>>>> >>>>> >>>>> >>>> >>>> http://www.ietf.org/internet-drafts/draft-kim-ccamp-cpr-=20 >>>> reqts-01.txt >>>> >>>> >>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>>> >> http://www.ietf.org/internet-drafts/draft-kim-ccamp-accp-=20 >> protocol-00.txt >> >> >>>> >>>> >>>> >>>>> >>>>> I want your comments. >>>>> >>>>> Regards >>>>> >>>>> Young. >>>>> >>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D> >> Young-Hwa Kim >>>>> Principal Member / Ph.D >>>>> BcN Research Division, ETRI >>>>> Tel: +82-42-860-5819 >>>>> Fax: +82-42-860-5440 >>>>> e-mail: yhwkim@etri.re.kr >>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D> >> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>>> >> > email=3Dccamp@ops.ietf.or >> >> >>>> >>>> >>>> >>>> >> g&name=3Dccamp%40ops.ietf.org&fromemail=3Dyhwkim@etri.re.kr&messageid=3D= %=20 >> 3C863 >> >> >>>> >>>> >>>> >>>>> 0a6db-0c31-49ab-a798-13b0dda04553@etri.re.kr%3E> >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> __________________________________ >>>> Yahoo! Mail - PC Magazine Editors' Choice 2005 >>>> http://mail.yahoo.com >>>> >>>> >>>> . >>>> >>>> >>>> >> >> >> >> > > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 28 Oct 2005 23:32:55 +0000 Message-ID: <4362B4F0.4050801@psg.com> Date: Sat, 29 Oct 2005 01:32:00 +0200 From: dimitri papadimitriou Reply-To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.11) Gecko/20050728 MIME-Version: 1.0 To: "Drake, John E" CC: "Ong, Lyndon" , ibryskin@movaz.com, dimitri.papadimitriou@alcatel.be, Drake@movaz.com, Igor Bryskin , Zafar Ali , Kim Young Hwa , ccamp@ops.ietf.org Subject: Re: Two Drafts for Resilience of Control Plane Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Drake, John E wrote: > >>-----Original Message----- >>From: Ong, Lyndon [mailto:Lyong@Ciena.com] >>Sent: Friday, October 28, 2005 1:28 PM >>To: ibryskin@movaz.com; dpapadimitriou@psg.com; >>dimitri.papadimitriou@alcatel.be >>Cc: Drake@movaz.com; Drake, John E; dimitri.papadimitriou@alcatel.be; > > Igor > >>Bryskin; Zafar Ali; Kim Young Hwa; ccamp@ops.ietf.org >>Subject: RE: Two Drafts for Resilience of Control Plane >> >>Hi Igor, >> >>Are you referring to controlling the LSP while one of the controllers > > is > >>still down? That would mean that no restart has yet taken place. >> >>The draft seems to be focused on providing standby control channels, > > [JD] > > What is the utility of having standby control channels, as opposed to > just having multiple *active* control channels? none - (except if the hardware is limited and does not allow load spreading among multiple channels but this is not a "feature") >>what >>you're suggesting sounds more like a standby signaling controller. > > [JD] > > A standby signaling controller is an implementation option that > shouldn't affect the existing GMPLS protocols it would surprise that hot swappable control plane instance would require any external coordination (i would say the objective is quite the opposite i.e. to disturb as less as possible neighbors) >>Cheers, >> >>Lyndon >> >>-----Original Message----- >>From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On >>Behalf Of ibryskin@movaz.com >>Sent: Friday, October 28, 2005 1:08 PM >>To: dpapadimitriou@psg.com; dimitri.papadimitriou@alcatel.be >>Cc: ibryskin@movaz.com; Drake@movaz.com; John E; >>dimitri.papadimitriou@alcatel.be; Igor Bryskin; Zafar Ali; Kim Young >>Hwa; ccamp@ops.ietf.org >>Subject: Re: Two Drafts for Resilience of Control Plane >> >>Dimitri, >>See in-line. >> >>>igor - >>> >>>you are already going beyond the specific discussion context >>> >>>1. what is a control plane partitioned LSP ? >> >>LSPs with one or more controllers down, so there is/are partitions in >>hop-by-hop signaling >> >>>2. when you state "Suppose one or more signaling controllers > > managing > >>> some LSP went out of service leaving the LSP's data plane > > intact." > >>> what does it mean "one or more controllers" ? what if you > > support > >>> RSVP GR ? why are you not able to recover the states ? etc. >> >>See my response to John. There are no restarts in my example >> >> >>>hence, i still miss the exact problem wrt to the control plane >>>protocol resilience >>> >>>but i think there is another issue (which is even more important) - >>>the resilience mechanisms of the control plane that we have today > > have > >>>been provided based on experience from the common use of the control >>>plane and for being resilient wrt common failures - but not for ALL >>>use of the control plane in ANY condition and for ALL possible >>>failures - indeed what you are asking here is like what shall i do >>>when the CP is completely down and the DP still up; it would > > surprise > >>>me that the CP would be of any help in this specific condition >> >>Believe me, CP could be still of a great help in such conditions. You >>need some signaling extensions - which is why I think CP resilience is >>an important topic within CCAMP - and then you can manage LSPs with >>control plane gaps at least to the extend I described. >> >>Igor >> >> >>>thanks, >>>- dimitri. >>> >>>ibryskin@movaz.com wrote: >>> >>> >>>>Hi, >>>> >>>>Here is one of the problems that I've been thinking for a while - >>>>control plane partitioned LSPs. Suppose one or more signaling >>>>controllers managing some LSP went out of service leaving the LSP's >>>>data plane intact. As far as the user is concerned such LSP is >>>>perfectly healthy and operational. >>>>Such situation could last for a considerable period of time. Do we >>>>need to manage such LSP via control plane? Sure, we must be capable >>>>to tear down such LSP, perform mb4b rerouting, distribute alarms >>>>between operational controllers, signal data plane faults and > > perform > >>>>recovery switchover, modify LSP status, etc. Can we do this today? >>>>No, but with some >>>>(signaling) extensions the problem I believe is solvable. Is this >>>>some artificial, "fabricated" problem? No, I think it is real. Does >>>>it fall under the control plane resilience problem space? I believe >> >>it does. >> >>>>Igor >>>> >>>> >>>> >>>>>I agree with Zafar and Dimitri. If someone wanted to document the >>>>>GMPLS control plane resiliency features, as was done for GMPLS >>>>>addressing, that might be a useful activity. >>>>> >>>>> >>>>> >>>>>>-----Original Message----- >>>>>>From: dimitri papadimitriou [mailto:dpapadimitriou@psg.com] >>>>>>Sent: Friday, October 28, 2005 9:56 AM >>>>>>To: Igor Bryskin >>>>>>Cc: Zafar Ali (zali); Kim Young Hwa; ccamp@ops.ietf.org >>>>>>Subject: Re: Two Drafts for Resilience of Control Plane >>>>>> >>>>>>igor - >>>>>> >>>>>>over time CCAMP came with a set of mechanims to improve control >>>>>>plane resilience (RSVP and LMP GR upon channel/node failure) other >>>>>>WG >>>>> >>>>>protocol >>>>> >>>>> >>>>>>work are also usable used here OSPF GR, etc. ... on the other > > side, > >>>>>>mechanism such as link bundling have built-in resilience >>>>>>capabilities and most GMPLS control plane capabilities have been >>>>>>designed such as >>>>> >>>>>to >>>>> >>>>> >>>>>>be independent of the control plane realisation (in-band, >>>>>>out-of-band, >>>>>>etc.) >>>>>> >>>>>>so indeed i share the concern of Zafar what could we do more here >>>>>>than document these tools and provide our experience in using > > them; > >>>>>>now, before stating there are (potential) problems(s) arising - >>>>>>would you please be more specific on what are these potential >>>>>>issue(s) >>>>> >>>>>and/or >>>>> >>>>> >>>>>>problems ? (not related to policy/config. - note: all the issues > > you > >>>>>>have pointed here below are simply policy/config specific but none >>>>>>of them highlights a missing IP control plane resiliency feature) >>>>>> >>>>>>thanks, >>>>>>- dimitri. >>>>>> >>>>>> >>>>>>Igor Bryskin wrote: >>>>>> >>>>>> >>>>>> >>>>>>>Zafar, >>>>>>> >>>>>>>The problem arises when the control plane is decoupled from the >>>>>>>data plane. The question is do we need such decoupling in IP >>>>>>>networks? Consider, for example, the situation when several >>>>>>>parallel PSC data links bundled together and controlled by a > > single > >>>>>>>control channel. >>>>>>>Does it mean in this case that when the control channel fails all >>>>>>>associated data links also fail? Do we need to reroute in this > > case > >>>>>>>LSPs that use the data links? Can we rely in this case on control >>>>>>>plane indications to decide whether an associated data link is >>>>>>>healthy or not (in other words, can we rely on RSVP Hellos or >>>>>>>should we use, for example, BTD)? Should we be capable to recover >>>>>>>control channels without disturbing data plane? I think control >>>>>>>plane resilience is important for all layers. You are right, >>>>>>>Internet does work, however, we do need for some reason TE and >>>>>>>(fast) recovery in IP as much as in other layers,don't we? >>>>>>> >>>>>>>Cheers, >>>>>>>Igor >>>>>>> >>>>>>>--- "Zafar Ali (zali)" wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>>Hi All, >>>>>>>> >>>>>>>>I am unable to understand the problem we are trying to solve or >>>>>>>>fabricate. My control network is IP based and IP has proven >>>>>>>>resiliency (Internet *does* work), why would I like to take >>>>>>>>control plan resiliency problem at a layer *above-IP* and >>>>>>>>complicate my life. Did I miss something? >>>>>>>> >>>>>>>>Thanks >>>>>>>> >>>>>>>>Regards... Zafar >>>>>>>> >>>>>>>> >>>>>>>>________________________________ >>>>>>>> >>>>>>>> From: owner-ccamp@ops.ietf.org >>>>>>>>[mailto:owner-ccamp@ops.ietf.org] >>>>>>>>On Behalf Of Kim Young Hwa >>>>>>>> Sent: Friday, October 28, 2005 6:04 AM >>>>>>>> To: ccamp@ops.ietf.org >>>>>>>> Subject: Two Drafts for Resilience of Control Plane >>>>>>>> >>>>>>>> >>>>>>>> Dear all, >>>>>>>> >>>>>>>> I posted two drafts for the resilience of control plane. >>>>>>>> One is for requirements of the resilience of control > > plane, > >>the >> >>>>>>>>other is for a protocol specification as a solution of that . >>>>>>>> These are now available at: >>>>>>>> >>>>>>>> >>>>>>> >>>>>>http://www.ietf.org/internet-drafts/draft-kim-ccamp-cpr-reqts-01.tx >>>>>> >>>>>>>t >>>>>>> >>>>>>> >>>>>>> >>>>http://www.ietf.org/internet-drafts/draft-kim-ccamp-accp-protocol-00. >>>> >>>>>txt >>>>> >>>>> >>>>>>>> I want your comments. >>>>>>>> >>>>>>>> Regards >>>>>>>> >>>>>>>> Young. >>>>>>>> >>>>>>>> ===================================> >> Young-Hwa Kim >>>>>>>> Principal Member / Ph.D >>>>>>>> BcN Research Division, ETRI >>>>>>>> Tel: +82-42-860-5819 >>>>>>>> Fax: +82-42-860-5440 >>>>>>>> e-mail: yhwkim@etri.re.kr >>>>>>>> ===================================> >> >>>>>>>> >>>>>>> >>>>>.or >>>>> >>>>> >>>>g&name=ccamp%40ops.ietf.org&fromemail=yhwkim@etri.re.kr&messageid=%3C >>>> >>>>>863 >>>>> >>>>> >>>>>>>>0a6db-0c31-49ab-a798-13b0dda04553@etri.re.kr%3E> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>__________________________________ >>>>>>>Yahoo! Mail - PC Magazine Editors' Choice 2005 >>>>>>>http://mail.yahoo.com >>>>>>> >>>>>>> >>>>>>>. >>>>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>>. >>>> >>> > > > > . > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 28 Oct 2005 23:27:32 +0000 Message-ID: <4362B390.1090609@psg.com> Date: Sat, 29 Oct 2005 01:26:08 +0200 From: dimitri papadimitriou Reply-To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.11) Gecko/20050728 MIME-Version: 1.0 To: ibryskin@movaz.com CC: dimitri.papadimitriou@alcatel.be, Drake@movaz.com, John E , Igor Bryskin , Zafar Ali , Kim Young Hwa , ccamp@ops.ietf.org Subject: Re: Two Drafts for Resilience of Control Plane Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit igor - see in-line ibryskin@movaz.com wrote: > Dimitri, > See in-line. > >>igor - >> >>you are already going beyond the specific discussion context >> >>1. what is a control plane partitioned LSP ? > > LSPs with one or more controllers down, so there is/are partitions in > hop-by-hop signaling > >>2. when you state "Suppose one or more signaling controllers managing >> some LSP went out of service leaving the LSP’s data plane intact." >> >> what does it mean "one or more controllers" ? what if you support >> RSVP GR ? why are you not able to recover the states ? etc. > > See my response to John. There are no restarts in my example you stated "I think you missed my point here. "Dead" controllers in my example *do not* come back for a considerable period of time. So there are no restarts here (graceful or not graceful) :=)" but this is exactly issue i am pointing here below - if a controller is really DEAD (and i included here any redundant controller pair) - beside *replacing* the damaged controller and restart i don't know which kind of additional extension you are asking for in the present context ... and this is logical we are discussing control plane availability/MTBF issues rather than resiliency issues >>hence, i still miss the exact problem wrt to the control plane protocol >>resilience >> >>but i think there is another issue (which is even more important) - the >>resilience mechanisms of the control plane that we have today have been >>provided based on experience from the common use of the control plane >>and for being resilient wrt common failures - but not for ALL use of the >>control plane in ANY condition and for ALL possible failures - indeed >>what you are asking here is like what shall i do when the CP is >>completely down and the DP still up; it would surprise me that the CP >>would be of any help in this specific condition > > Believe me, CP could be still of a great help in such conditions. You need > some signaling extensions - which is why I think CP resilience is an > important topic within CCAMP - and then you can manage LSPs with control > plane gaps at least to the extend I described. > Igor > > >>thanks, >>- dimitri. >> >>ibryskin@movaz.com wrote: >> >> >>>Hi, >>> >>>Here is one of the problems that I’ve been thinking for a while – >>>control >>>plane partitioned LSPs. Suppose one or more signaling controllers >>>managing >>>some LSP went out of service leaving the LSP’s data plane intact. As far >>>as the user is concerned such LSP is perfectly healthy and operational. >>>Such situation could last for a considerable period of time. Do we need >>>to >>>manage such LSP via control plane? Sure, we must be capable to tear down >>>such LSP, perform mb4b rerouting, distribute alarms between operational >>>controllers, signal data plane faults and perform recovery switchover, >>>modify LSP status, etc. Can we do this today? No, but with some >>>(signaling) extensions the problem I believe is solvable. Is this some >>>artificial, “fabricated” problem? No, I think it is real. Does it fall >>>under the control plane resilience problem space? I believe it does. >>> >>>Igor >>> >>> >>> >>>>I agree with Zafar and Dimitri. If someone wanted to document the GMPLS >>>>control plane resiliency features, as was done for GMPLS addressing, >>>>that might be a useful activity. >>>> >>>> >>>> >>>>>-----Original Message----- >>>>>From: dimitri papadimitriou [mailto:dpapadimitriou@psg.com] >>>>>Sent: Friday, October 28, 2005 9:56 AM >>>>>To: Igor Bryskin >>>>>Cc: Zafar Ali (zali); Kim Young Hwa; ccamp@ops.ietf.org >>>>>Subject: Re: Two Drafts for Resilience of Control Plane >>>>> >>>>>igor - >>>>> >>>>>over time CCAMP came with a set of mechanims to improve control plane >>>>>resilience (RSVP and LMP GR upon channel/node failure) other WG >>>> >>>>protocol >>>> >>>> >>>>>work are also usable used here OSPF GR, etc. ... on the other side, >>>>>mechanism such as link bundling have built-in resilience capabilities >>>>>and most GMPLS control plane capabilities have been designed such as >>>> >>>>to >>>> >>>> >>>>>be independent of the control plane realisation (in-band, out-of-band, >>>>>etc.) >>>>> >>>>>so indeed i share the concern of Zafar what could we do more here than >>>>>document these tools and provide our experience in using them; >>>>> >>>>>now, before stating there are (potential) problems(s) arising - would >>>>>you please be more specific on what are these potential issue(s) >>>> >>>>and/or >>>> >>>> >>>>>problems ? (not related to policy/config. - note: all the issues you >>>>>have pointed here below are simply policy/config specific but none of >>>>>them highlights a missing IP control plane resiliency feature) >>>>> >>>>>thanks, >>>>>- dimitri. >>>>> >>>>> >>>>>Igor Bryskin wrote: >>>>> >>>>> >>>>> >>>>>>Zafar, >>>>>> >>>>>>The problem arises when the control plane is decoupled >>>>> >>>>>>from the data plane. The question is do we need such >>>>> >>>>>>decoupling in IP networks? Consider, for example, the >>>>>>situation when several parallel PSC data links bundled >>>>>>together and controlled by a single control channel. >>>>>>Does it mean in this case that when the control >>>>>>channel fails all associated data links also fail? Do >>>>>>we need to reroute in this case LSPs that use the data >>>>>>links? Can we rely in this case on control plane >>>>>>indications to decide whether an associated data link >>>>>>is healthy or not (in other words, can we rely on RSVP >>>>>>Hellos or should we use, for example, BTD)? Should we >>>>>>be capable to recover control channels without >>>>>>disturbing data plane? I think control plane >>>>>>resilience is important for all layers. You are right, >>>>>>Internet does work, however, we do need for some >>>>>>reason TE and (fast) recovery in IP as much as in >>>>>>other layers,don't we? >>>>>> >>>>>>Cheers, >>>>>>Igor >>>>>> >>>>>>--- "Zafar Ali (zali)" wrote: >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>Hi All, >>>>>>> >>>>>>>I am unable to understand the problem we are trying >>>>>>>to solve or >>>>>>>fabricate. My control network is IP based and IP has >>>>>>>proven resiliency >>>>>>>(Internet *does* work), why would I like to take >>>>>>>control plan resiliency >>>>>>>problem at a layer *above-IP* and complicate my >>>>>>>life. Did I miss >>>>>>>something? >>>>>>> >>>>>>>Thanks >>>>>>> >>>>>>>Regards... Zafar >>>>>>> >>>>>>> >>>>>>>________________________________ >>>>>>> >>>>>>> From: owner-ccamp@ops.ietf.org >>>>>>>[mailto:owner-ccamp@ops.ietf.org] >>>>>>>On Behalf Of Kim Young Hwa >>>>>>> Sent: Friday, October 28, 2005 6:04 AM >>>>>>> To: ccamp@ops.ietf.org >>>>>>> Subject: Two Drafts for Resilience of Control Plane >>>>>>> >>>>>>> >>>>>>> Dear all, >>>>>>> >>>>>>> I posted two drafts for the resilience of control >>>>>>>plane. >>>>>>> One is for requirements of the resilience of >>>>>>>control plane, the >>>>>>>other is for a protocol specification as a solution >>>>>>>of that . >>>>>>> These are now available at: >>>>>>> >>>>>>> >>>>>> >>>>>>http://www.ietf.org/internet-drafts/draft-kim-ccamp-cpr-reqts-01.txt >>>>>> >>>>>> >>>>>> >>>>http://www.ietf.org/internet-drafts/draft-kim-ccamp-accp-protocol-00.txt >>>> >>>> >>>>>>> I want your comments. >>>>>>> >>>>>>> Regards >>>>>>> >>>>>>> Young. >>>>>>> >>>>>>> ===================================> >> Young-Hwa Kim >>>>>>> Principal Member / Ph.D >>>>>>> BcN Research Division, ETRI >>>>>>> Tel: +82-42-860-5819 >>>>>>> Fax: +82-42-860-5440 >>>>>>> e-mail: yhwkim@etri.re.kr >>>>>>> ===================================> >> >>>>>>> >>>>>>> >>>> >>>>g&name=ccamp%40ops.ietf.org&fromemail=yhwkim@etri.re.kr&messageid=%3C863 >>>> >>>> >>>>>>>0a6db-0c31-49ab-a798-13b0dda04553@etri.re.kr%3E> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>__________________________________ >>>>>>Yahoo! Mail - PC Magazine Editors' Choice 2005 >>>>>>http://mail.yahoo.com >>>>>> >>>>>> >>>>>>. >>>>>> >>>> >>>> >>>> >>> >>> >>>. >>> >> > > > . > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 28 Oct 2005 22:34:55 +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: comments on draft-shiba-ccamp-gmpls-lambda-labels-00.txt Date: Fri, 28 Oct 2005 15:33:26 -0700 Message-ID: <626FC7C6A97381468FB872072AB5DDC8369708@XCH-SW-42.sw.nos.boeing.com> Thread-Topic: comments on draft-shiba-ccamp-gmpls-lambda-labels-00.txt Thread-Index: AcXbIzcAFoI5B5TzS9O/zBGY1cMJbwA6iz0A From: "Drake, John E" To: , "Shiba, Sidney" Cc: "Adrian Farrel" , , Hi, Below is the text of an e-mail is sent to the Ethernet/GMPLS mailing list. Upon reflection I am not sure using a real wavelength value makes much sense. Between a pair of adjacent nodes, there may be multiple pairs of switch ports in the same TE link that support a given frequency. If a real wavelength value is used, how do the two nodes agree on which pair of switch ports to use? Furthermore, the amount of configuration is the same - you still need to configure the wavelength of each switch port. Thanks, John =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D Adrian, In the transparent photonic lambda switch case, the labels also have only local significance. When an LSP is established, the input ports, as identified with local labels, are cross-connected to the output ports, as identified with local labels. There is just extra configuration to identify, using strictly local identifiers, the wavelength associated with the all of the switch's ports, and an additional CAC requirement that the wavelengths of the input and output ports are the same. Thanks, John =20 > -----Original Message----- > From: dimitri papadimitriou [mailto:dpapadimitriou@psg.com] > Sent: Thursday, October 27, 2005 10:03 AM > To: Shiba, Sidney > Cc: dimitri.papadimitriou@alcatel.be; Adrian Farrel; > richard.rabbat@us.fujitsu.com; ccamp@ops.ietf.org > Subject: Re: comments on draft-shiba-ccamp-gmpls-lambda-labels-00.txt >=20 > shiba - see inline for some additional hints: >=20 > >>Shiba, Sidney wrote: > >> > >>>Adrian, Dimitri, > >>> > >>>Thanks for reviewing these I-D. > >>> > >>>Wavelength continuity constraint does require the use of semanticful > >>>label whether it is spectral or index. > >> > >>=3D> see my reply to adrian on this specific point > >> > >>>I agree with Dimitri that the > >>>wavelength indexing requires document updating each time a new > >>>spectrum is introduced. > >> > >>=3D> indeed and in addition it requires updating the already > >>signaled path > >> > >>>The use of spectral label provides self maintainance, i.e., > >>>no need to update any document and the use of the nominal value > >>>provides a common semantic ground. > >> > >>=3D> what do you mean by self-maintenance - would you provide a > >>bit more detail > > > > [Sidney]What I've meant here was that it was not necessary to > > update any document when new wavelengths are inventoried. In the > > case of indexing approach, it would require the wavelength indexing > > document to be updated with implementation impacts. > > > > In the case, the nominal value is used, there is no need for > > documentation update. >=20 > ok - what you mean here is that you are going to make use of the already > defined C-Type 2 - what about the specific encoding of the value space ? >=20 > >>=3D> now i have a more specific question before being light-up > >>how do you know the frequency that you can support ? > > > > [Sidney] Some new technologies integrate optical switch and mux/demux > > capabilities, which allows the equipment to know the spectrum it > supports. >=20 > indeed - but the question is what does happen if the "detected" values > (during initialization) do not match the nominal values ? you don't > initialize then ? >=20 > >>if these differ from the nominal values how are you going to deal with > these > >>discrepancies ? > > > > [Sidney] These new technologies uses the nominal value as reference. We > can say > > that a lightpath wavelength is identified by its nominal value. If the > equipment > > is drifting from this nominal value, it is considered as a failure. >=20 > ok - but if the deviation is such you have overlap - how the control > plane is going to be able to detect such failure ? >=20 > >>this said i am not necessarily sure that having to maintain the data > plane > >>specifics as part of the control plane is really helping > >>operations (is this method not just duplicating complexity ?) > > > > [Sidney] The wavelength is WDM specific as much as the SUKLM label > encoding > > is for SONET. The wavelegth/frequency nominal value is used to identify > the > > facilities to cross-connect. >=20 > there is an equivalence but there is also a major difference, the > structure is invariant independently of the state of the network, with > spectral value space you may have labels that become unavailable due to > non-local usage of wavelength in the network >=20 > hence, there is also no real coupling to the data plane more than > knowing the type of interface and some generic capabilities >=20 > >>>I'm not sure if the draft needs to be updated before the > >>>face-to-face meeting or after all comments are collected. Please > advise. > >> > >>=3D> suggest to keep discussion on - document update can be > >>performed at a later stage >=20 > thanks, > - dimitri. >=20 > >>>>-----Original Message----- > >>>>From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On > >>>>Behalf Of Adrian Farrel > >>>>Sent: Thursday, October 27, 2005 4:45 AM > >>>>To: dpapadimitriou@psg.com; dimitri.papadimitriou@alcatel.be; > >>>>ccamp@ops.ietf.org > >>>>Subject: Re: comments on > >> > >>draft-shiba-ccamp-gmpls-lambda-labels-00.txt > >> > >>>> > >>>>Dimitri, > >>>> > >>>>Thanks for your work reviewing these recent I-Ds. It is > >>>>really valuable > >>>>and I'd welcome other people doing similar reviews. > >>>> > >>>> > >>>> > >>>>>there is a specific point to be clarified in this document: > >>>>> > >>>>>semanticless vs semanticful label (even here there is a distinction > >>>>>between spectral vs indexes i.e. using the wavelength index) > >>>>> > >>>>>domain-wide vs link local significant label > >>>> > >>>>Without being too picky, I think all labels are semanticful > >>>>otherwise, we > >>>>would not know what resource they refered to. > >>>> > >>>>So the point reduces to whether the scope of the semantics > >>>>are link-local > >>>>or wider. > >>>> > >>>> > >>>> > >>>>>so, the comparison from this perspective with TDM labels is > >>>> > >>>>difficult to > >>>> > >>>> > >>>>>parse, the latter is semanticful but link local > >>>>> > >>>>>now, i don't specifically see what has changed the late 90's, early > >>>>>y2k's, to have a change in the wavelength label definition; > >>>> > >>>>This is the question I would like to get to the bottom of. In > >>>>other words: > >>>>do we need this function? > >>>> > >>>>It seems to me that the question being asked is this: > >>>> > >>>> If I want to compute a path that has some form of wavelength > >>>> constraints, what information do I need access to? > >>>> > >>>>Another question might be: > >>>> > >>>> If I want to signal a path with wavelength constraints what > >>>> information do I need to include in the signaling message? > >>>> > >>>> > >>>>I'd suggest that when we started on GMPLS, we were > >> > >>enthusiastic about > >> > >>>>transparent optical networks, but we were not properly > >>>>focusing wavelength > >>>>constraints because lambda-switching PXCs didn't take off. > >>>>Therefore we > >>>>didn't examine the requirements for wavelength constraints in > >>>>routing and > >>>>signaling. The authors of this I-D are claiming new hardware > >>>>requirements > >>>>for the same function. > >>>> > >>>> > >>>> > >>>>>there are > >>>>>several solution possible > >>>>> > >>>>>- absolute values: the freq. of the wavelength: difficult to adopt > >>>>>because referenced values are nominal and knowing all interactions > >>>>>between wavelengths this knowledge is at the end of little > >> > >>practical > >> > >>>>>usage; (introduces implicit ordering) > >>>>> > >>>>>- indexed values: the # of the wavelength: it does not > >> > >>provide for a > >> > >>>>>future proof label space for inst. in case new frequencies > >>>> > >>>>are inserted > >>>> > >>>> > >>>>>in the grid (introduces explicit ordering) > >>>>> > >>>>>- diff. values e.g. freq spacing starting from a reference > >>>> > >>>>value: pauses > >>>> > >>>> > >>>>>the question of the reference value and does suffer from the former > >>>>>issue (introduces implicit ordering) > >>>>> > >>>>>- the solution available today - cumbersome in some control plane > >>>>>operations (e.g. label set translation) and not easy to > >>>> > >>>>troubleshoot but > >>>> > >>>> > >>>>>independent of any physical consideration (spectral), scale to any > >>>>>number of wavelength per fiber, does not introduce any > >> > >>ordering, the > >> > >>>>>most flexible (since allowing each system to maintain its specific > >>>>>control operations) and the less constraining since maintaining the > >>>>>control plane operations independent of any data plane specifics > >>>>> > >>>>> > >>>> > >>>> >>> > >>>ambda-labels > >>>-00.txt> > >>> > >>>. > >>> > >> > > > > . > > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 28 Oct 2005 20:52: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: Two Drafts for Resilience of Control Plane Date: Fri, 28 Oct 2005 13:51:36 -0700 Message-ID: <626FC7C6A97381468FB872072AB5DDC8369704@XCH-SW-42.sw.nos.boeing.com> Thread-Topic: Two Drafts for Resilience of Control Plane Thread-Index: AcXb+5sI7DBursUUSnCMr5SUjjw6QQAAZ19AAADmq6A= From: "Drake, John E" To: "Ong, Lyndon" , , , Cc: , , "Igor Bryskin" , "Zafar Ali" , "Kim Young Hwa" , > -----Original Message----- > From: Ong, Lyndon [mailto:Lyong@Ciena.com] > Sent: Friday, October 28, 2005 1:28 PM > To: ibryskin@movaz.com; dpapadimitriou@psg.com; > dimitri.papadimitriou@alcatel.be > Cc: Drake@movaz.com; Drake, John E; dimitri.papadimitriou@alcatel.be; Igor > Bryskin; Zafar Ali; Kim Young Hwa; ccamp@ops.ietf.org > Subject: RE: Two Drafts for Resilience of Control Plane >=20 > Hi Igor, >=20 > Are you referring to controlling the LSP while one of the controllers is > still down? That would mean that no restart has yet taken place. >=20 > The draft seems to be focused on providing standby control channels, [JD]=20 What is the utility of having standby control channels, as opposed to just having multiple *active* control channels? > what > you're suggesting sounds more like a standby signaling controller. [JD]=20 A standby signaling controller is an implementation option that shouldn't affect the existing GMPLS protocols >=20 > Cheers, >=20 > Lyndon >=20 > -----Original Message----- > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On > Behalf Of ibryskin@movaz.com > Sent: Friday, October 28, 2005 1:08 PM > To: dpapadimitriou@psg.com; dimitri.papadimitriou@alcatel.be > Cc: ibryskin@movaz.com; Drake@movaz.com; John E; > dimitri.papadimitriou@alcatel.be; Igor Bryskin; Zafar Ali; Kim Young > Hwa; ccamp@ops.ietf.org > Subject: Re: Two Drafts for Resilience of Control Plane >=20 > Dimitri, > See in-line. > > igor - > > > > you are already going beyond the specific discussion context > > > > 1. what is a control plane partitioned LSP ? >=20 > LSPs with one or more controllers down, so there is/are partitions in > hop-by-hop signaling > > > > 2. when you state "Suppose one or more signaling controllers managing > > some LSP went out of service leaving the LSP's data plane intact." > > > > what does it mean "one or more controllers" ? what if you support > > RSVP GR ? why are you not able to recover the states ? etc. >=20 > See my response to John. There are no restarts in my example >=20 > > > > hence, i still miss the exact problem wrt to the control plane > > protocol resilience > > > > but i think there is another issue (which is even more important) - > > the resilience mechanisms of the control plane that we have today have >=20 > > been provided based on experience from the common use of the control > > plane and for being resilient wrt common failures - but not for ALL > > use of the control plane in ANY condition and for ALL possible > > failures - indeed what you are asking here is like what shall i do > > when the CP is completely down and the DP still up; it would surprise > > me that the CP would be of any help in this specific condition >=20 > Believe me, CP could be still of a great help in such conditions. You > need some signaling extensions - which is why I think CP resilience is > an important topic within CCAMP - and then you can manage LSPs with > control plane gaps at least to the extend I described. >=20 > Igor >=20 > > > > thanks, > > - dimitri. > > > > ibryskin@movaz.com wrote: > > > >> Hi, > >> > >> Here is one of the problems that I've been thinking for a while - > >> control plane partitioned LSPs. Suppose one or more signaling > >> controllers managing some LSP went out of service leaving the LSP's > >> data plane intact. As far as the user is concerned such LSP is > >> perfectly healthy and operational. > >> Such situation could last for a considerable period of time. Do we > >> need to manage such LSP via control plane? Sure, we must be capable > >> to tear down such LSP, perform mb4b rerouting, distribute alarms > >> between operational controllers, signal data plane faults and perform >=20 > >> recovery switchover, modify LSP status, etc. Can we do this today? > >> No, but with some > >> (signaling) extensions the problem I believe is solvable. Is this > >> some artificial, "fabricated" problem? No, I think it is real. Does > >> it fall under the control plane resilience problem space? I believe > it does. > >> > >> Igor > >> > >> > >>>I agree with Zafar and Dimitri. If someone wanted to document the > >>>GMPLS control plane resiliency features, as was done for GMPLS > >>>addressing, that might be a useful activity. > >>> > >>> > >>>>-----Original Message----- > >>>>From: dimitri papadimitriou [mailto:dpapadimitriou@psg.com] > >>>>Sent: Friday, October 28, 2005 9:56 AM > >>>>To: Igor Bryskin > >>>>Cc: Zafar Ali (zali); Kim Young Hwa; ccamp@ops.ietf.org > >>>>Subject: Re: Two Drafts for Resilience of Control Plane > >>>> > >>>>igor - > >>>> > >>>>over time CCAMP came with a set of mechanims to improve control > >>>>plane resilience (RSVP and LMP GR upon channel/node failure) other > >>>>WG > >>> > >>>protocol > >>> > >>>>work are also usable used here OSPF GR, etc. ... on the other side, > >>>>mechanism such as link bundling have built-in resilience > >>>>capabilities and most GMPLS control plane capabilities have been > >>>>designed such as > >>> > >>>to > >>> > >>>>be independent of the control plane realisation (in-band, > >>>>out-of-band, > >>>>etc.) > >>>> > >>>>so indeed i share the concern of Zafar what could we do more here > >>>>than document these tools and provide our experience in using them; > >>>> > >>>>now, before stating there are (potential) problems(s) arising - > >>>>would you please be more specific on what are these potential > >>>>issue(s) > >>> > >>>and/or > >>> > >>>>problems ? (not related to policy/config. - note: all the issues you >=20 > >>>>have pointed here below are simply policy/config specific but none > >>>>of them highlights a missing IP control plane resiliency feature) > >>>> > >>>>thanks, > >>>>- dimitri. > >>>> > >>>> > >>>>Igor Bryskin wrote: > >>>> > >>>> > >>>>>Zafar, > >>>>> > >>>>>The problem arises when the control plane is decoupled from the > >>>>>data plane. The question is do we need such decoupling in IP > >>>>>networks? Consider, for example, the situation when several > >>>>>parallel PSC data links bundled together and controlled by a single >=20 > >>>>>control channel. > >>>>>Does it mean in this case that when the control channel fails all > >>>>>associated data links also fail? Do we need to reroute in this case >=20 > >>>>>LSPs that use the data links? Can we rely in this case on control > >>>>>plane indications to decide whether an associated data link is > >>>>>healthy or not (in other words, can we rely on RSVP Hellos or > >>>>>should we use, for example, BTD)? Should we be capable to recover > >>>>>control channels without disturbing data plane? I think control > >>>>>plane resilience is important for all layers. You are right, > >>>>>Internet does work, however, we do need for some reason TE and > >>>>>(fast) recovery in IP as much as in other layers,don't we? > >>>>> > >>>>>Cheers, > >>>>>Igor > >>>>> > >>>>>--- "Zafar Ali (zali)" wrote: > >>>>> > >>>>> > >>>>> > >>>>>>Hi All, > >>>>>> > >>>>>>I am unable to understand the problem we are trying to solve or > >>>>>>fabricate. My control network is IP based and IP has proven > >>>>>>resiliency (Internet *does* work), why would I like to take > >>>>>>control plan resiliency problem at a layer *above-IP* and > >>>>>>complicate my life. Did I miss something? > >>>>>> > >>>>>>Thanks > >>>>>> > >>>>>>Regards... Zafar > >>>>>> > >>>>>> > >>>>>>________________________________ > >>>>>> > >>>>>> From: owner-ccamp@ops.ietf.org > >>>>>>[mailto:owner-ccamp@ops.ietf.org] > >>>>>>On Behalf Of Kim Young Hwa > >>>>>> Sent: Friday, October 28, 2005 6:04 AM > >>>>>> To: ccamp@ops.ietf.org > >>>>>> Subject: Two Drafts for Resilience of Control Plane > >>>>>> > >>>>>> > >>>>>> Dear all, > >>>>>> > >>>>>> I posted two drafts for the resilience of control plane. > >>>>>> One is for requirements of the resilience of control plane, > the > >>>>>>other is for a protocol specification as a solution of that . > >>>>>> These are now available at: > >>>>>> > >>>>>> > >>>>> > >>>>>http://www.ietf.org/internet-drafts/draft-kim-ccamp-cpr-reqts-01.tx > >>>>>t > >>>>> > >>>>> > >>>>>> > >>>>> > >>>http://www.ietf.org/internet-drafts/draft-kim-ccamp-accp-protocol-00. > >>>txt > >>> > >>>>>> I want your comments. > >>>>>> > >>>>>> Regards > >>>>>> > >>>>>> Young. > >>>>>> > >>>>>> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D> >> Young-Hwa Kim > >>>>>> Principal Member / Ph.D > >>>>>> BcN Research Division, ETRI > >>>>>> Tel: +82-42-860-5819 > >>>>>> Fax: +82-42-860-5440 > >>>>>> e-mail: yhwkim@etri.re.kr > >>>>>> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D> >> > >>>>>> > >>>>> > >>> >>>.or > >>> > >>>>> > >>>g&name=3Dccamp%40ops.ietf.org&fromemail=3Dyhwkim@etri.re.kr&messageid=3D= %3C > >>>863 > >>> > >>>>>>0a6db-0c31-49ab-a798-13b0dda04553@etri.re.kr%3E> > >>>>>> > >>>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>__________________________________ > >>>>>Yahoo! Mail - PC Magazine Editors' Choice 2005 > >>>>>http://mail.yahoo.com > >>>>> > >>>>> > >>>>>. > >>>>> > >>> > >>> > >>> > >> > >> > >> > >> . > >> > > >=20 Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 28 Oct 2005 20:28:43 +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: Two Drafts for Resilience of Control Plane Date: Fri, 28 Oct 2005 16:28:20 -0400 Message-ID: <0901D1988E815341A0103206A834DA07902956@mdmxm02.ciena.com> Thread-Topic: Two Drafts for Resilience of Control Plane Thread-Index: AcXb+5sI7DBursUUSnCMr5SUjjw6QQAAZ19A From: "Ong, Lyndon" To: , , Cc: , "John E" , , "Igor Bryskin" , "Zafar Ali" , "Kim Young Hwa" , Hi Igor, Are you referring to controlling the LSP while one of the controllers is still down? That would mean that no restart has yet taken place. The draft seems to be focused on providing standby control channels, what you're suggesting sounds more like a standby signaling controller. Cheers, Lyndon -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of ibryskin@movaz.com Sent: Friday, October 28, 2005 1:08 PM To: dpapadimitriou@psg.com; dimitri.papadimitriou@alcatel.be Cc: ibryskin@movaz.com; Drake@movaz.com; John E; dimitri.papadimitriou@alcatel.be; Igor Bryskin; Zafar Ali; Kim Young Hwa; ccamp@ops.ietf.org Subject: Re: Two Drafts for Resilience of Control Plane Dimitri, See in-line. > igor - > > you are already going beyond the specific discussion context > > 1. what is a control plane partitioned LSP ? LSPs with one or more controllers down, so there is/are partitions in hop-by-hop signaling > > 2. when you state "Suppose one or more signaling controllers managing > some LSP went out of service leaving the LSP's data plane intact." > > what does it mean "one or more controllers" ? what if you support > RSVP GR ? why are you not able to recover the states ? etc. See my response to John. There are no restarts in my example > > hence, i still miss the exact problem wrt to the control plane=20 > protocol resilience > > but i think there is another issue (which is even more important) -=20 > the resilience mechanisms of the control plane that we have today have > been provided based on experience from the common use of the control=20 > plane and for being resilient wrt common failures - but not for ALL=20 > use of the control plane in ANY condition and for ALL possible=20 > failures - indeed what you are asking here is like what shall i do=20 > when the CP is completely down and the DP still up; it would surprise=20 > me that the CP would be of any help in this specific condition Believe me, CP could be still of a great help in such conditions. You need some signaling extensions - which is why I think CP resilience is an important topic within CCAMP - and then you can manage LSPs with control plane gaps at least to the extend I described. Igor > > thanks, > - dimitri. > > ibryskin@movaz.com wrote: > >> Hi, >> >> Here is one of the problems that I've been thinking for a while -=20 >> control plane partitioned LSPs. Suppose one or more signaling=20 >> controllers managing some LSP went out of service leaving the LSP's=20 >> data plane intact. As far as the user is concerned such LSP is=20 >> perfectly healthy and operational. >> Such situation could last for a considerable period of time. Do we=20 >> need to manage such LSP via control plane? Sure, we must be capable=20 >> to tear down such LSP, perform mb4b rerouting, distribute alarms=20 >> between operational controllers, signal data plane faults and perform >> recovery switchover, modify LSP status, etc. Can we do this today?=20 >> No, but with some >> (signaling) extensions the problem I believe is solvable. Is this=20 >> some artificial, "fabricated" problem? No, I think it is real. Does=20 >> it fall under the control plane resilience problem space? I believe it does. >> >> Igor >> >> >>>I agree with Zafar and Dimitri. If someone wanted to document the=20 >>>GMPLS control plane resiliency features, as was done for GMPLS=20 >>>addressing, that might be a useful activity. >>> >>> >>>>-----Original Message----- >>>>From: dimitri papadimitriou [mailto:dpapadimitriou@psg.com] >>>>Sent: Friday, October 28, 2005 9:56 AM >>>>To: Igor Bryskin >>>>Cc: Zafar Ali (zali); Kim Young Hwa; ccamp@ops.ietf.org >>>>Subject: Re: Two Drafts for Resilience of Control Plane >>>> >>>>igor - >>>> >>>>over time CCAMP came with a set of mechanims to improve control=20 >>>>plane resilience (RSVP and LMP GR upon channel/node failure) other=20 >>>>WG >>> >>>protocol >>> >>>>work are also usable used here OSPF GR, etc. ... on the other side,=20 >>>>mechanism such as link bundling have built-in resilience=20 >>>>capabilities and most GMPLS control plane capabilities have been=20 >>>>designed such as >>> >>>to >>> >>>>be independent of the control plane realisation (in-band,=20 >>>>out-of-band, >>>>etc.) >>>> >>>>so indeed i share the concern of Zafar what could we do more here=20 >>>>than document these tools and provide our experience in using them; >>>> >>>>now, before stating there are (potential) problems(s) arising -=20 >>>>would you please be more specific on what are these potential=20 >>>>issue(s) >>> >>>and/or >>> >>>>problems ? (not related to policy/config. - note: all the issues you >>>>have pointed here below are simply policy/config specific but none=20 >>>>of them highlights a missing IP control plane resiliency feature) >>>> >>>>thanks, >>>>- dimitri. >>>> >>>> >>>>Igor Bryskin wrote: >>>> >>>> >>>>>Zafar, >>>>> >>>>>The problem arises when the control plane is decoupled from the=20 >>>>>data plane. The question is do we need such decoupling in IP=20 >>>>>networks? Consider, for example, the situation when several=20 >>>>>parallel PSC data links bundled together and controlled by a single >>>>>control channel. >>>>>Does it mean in this case that when the control channel fails all=20 >>>>>associated data links also fail? Do we need to reroute in this case >>>>>LSPs that use the data links? Can we rely in this case on control=20 >>>>>plane indications to decide whether an associated data link is=20 >>>>>healthy or not (in other words, can we rely on RSVP Hellos or=20 >>>>>should we use, for example, BTD)? Should we be capable to recover=20 >>>>>control channels without disturbing data plane? I think control=20 >>>>>plane resilience is important for all layers. You are right,=20 >>>>>Internet does work, however, we do need for some reason TE and=20 >>>>>(fast) recovery in IP as much as in other layers,don't we? >>>>> >>>>>Cheers, >>>>>Igor >>>>> >>>>>--- "Zafar Ali (zali)" wrote: >>>>> >>>>> >>>>> >>>>>>Hi All, >>>>>> >>>>>>I am unable to understand the problem we are trying to solve or=20 >>>>>>fabricate. My control network is IP based and IP has proven=20 >>>>>>resiliency (Internet *does* work), why would I like to take=20 >>>>>>control plan resiliency problem at a layer *above-IP* and=20 >>>>>>complicate my life. Did I miss something? >>>>>> >>>>>>Thanks >>>>>> >>>>>>Regards... Zafar >>>>>> >>>>>> >>>>>>________________________________ >>>>>> >>>>>> From: owner-ccamp@ops.ietf.org >>>>>>[mailto:owner-ccamp@ops.ietf.org] >>>>>>On Behalf Of Kim Young Hwa >>>>>> Sent: Friday, October 28, 2005 6:04 AM >>>>>> To: ccamp@ops.ietf.org >>>>>> Subject: Two Drafts for Resilience of Control Plane >>>>>> >>>>>> >>>>>> Dear all, >>>>>> >>>>>> I posted two drafts for the resilience of control plane. >>>>>> One is for requirements of the resilience of control plane, the=20 >>>>>>other is for a protocol specification as a solution of that . >>>>>> These are now available at: >>>>>> >>>>>> >>>>> >>>>>http://www.ietf.org/internet-drafts/draft-kim-ccamp-cpr-reqts-01.tx >>>>>t >>>>> >>>>> >>>>>> >>>>> >>>http://www.ietf.org/internet-drafts/draft-kim-ccamp-accp-protocol-00. >>>txt >>> >>>>>> I want your comments. >>>>>> >>>>>> Regards >>>>>> >>>>>> Young. >>>>>> >>>>>> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D> >> Young-Hwa Kim >>>>>> Principal Member / Ph.D >>>>>> BcN Research Division, ETRI >>>>>> Tel: +82-42-860-5819 >>>>>> Fax: +82-42-860-5440 >>>>>> e-mail: yhwkim@etri.re.kr >>>>>> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D> >> >>>>>> >>>>> >>>>>.or >>> >>>>> >>>g&name=3Dccamp%40ops.ietf.org&fromemail=3Dyhwkim@etri.re.kr&messageid=3D= %3C >>>863 >>> >>>>>>0a6db-0c31-49ab-a798-13b0dda04553@etri.re.kr%3E> >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>__________________________________ >>>>>Yahoo! Mail - PC Magazine Editors' Choice 2005=20 >>>>>http://mail.yahoo.com >>>>> >>>>> >>>>>. >>>>> >>> >>> >>> >> >> >> >> . >> > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 28 Oct 2005 20:12:47 +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: Two Drafts for Resilience of Control Plane Date: Fri, 28 Oct 2005 13:12:03 -0700 Message-ID: <626FC7C6A97381468FB872072AB5DDC8369701@XCH-SW-42.sw.nos.boeing.com> Thread-Topic: Two Drafts for Resilience of Control Plane Thread-Index: AcXb+jnJdj0+wNOWTniYJbc2ZmRFkAAAGuoA From: "Drake, John E" To: Cc: , , "Igor Bryskin" , "Zafar Ali" , "Kim Young Hwa" , Igor, What you wrote was: "Suppose one or more signaling controllers managing some LSP went out of service leaving the LSP's data plane intact. As far as the user is concerned such LSP is perfectly healthy and operational. Such situation could last for a considerable period of time." What part of this is *not* handled by RSVP graceful restart? In your subsequent e-mail, you then changed the problem statement to: ""Dead" controllers in my example *do not* come back for a considerable period of time. So there are no restarts here (graceful or not graceful)" If "Considerable period of time" is not equal to infinity, then there will be an RSVP graceful restart. If a controller is really and truly dead, then presumably the operator will either replace it or re-assign its data-plane resources to another signaling controller. In either case, there will then be an RSVP graceful restart. Thanks, John > -----Original Message----- > From: ibryskin@movaz.com [mailto:ibryskin@movaz.com] > Sent: Friday, October 28, 2005 1:00 PM > To: Drake, John E > Cc: ibryskin@movaz.com; dpapadimitriou@psg.com; > dimitri.papadimitriou@alcatel.be; Igor Bryskin; Zafar Ali; Kim Young Hwa; > ccamp@ops.ietf.org > Subject: RE: Two Drafts for Resilience of Control Plane >=20 > John, >=20 > I think you missed my point here. "Dead" controllers in my example *do > not* come back for a considerable period of time. So there are no restarts > here (graceful or not graceful) :=3D) >=20 > Igor >=20 > > What part of your problem, as stated below, is not handled by RSVP > > graceful restart? > > > >> -----Original Message----- > >> From: ibryskin@movaz.com [mailto:ibryskin@movaz.com] > >> Sent: Friday, October 28, 2005 11:41 AM > >> To: Drake, John E > >> Cc: dpapadimitriou@psg.com; dimitri.papadimitriou@alcatel.be; Igor > >> Bryskin; Zafar Ali; Kim Young Hwa; ccamp@ops.ietf.org > >> Subject: RE: Two Drafts for Resilience of Control Plane > >> > >> Hi, > >> > >> Here is one of the problems that I've been thinking for a while - > > control > >> plane partitioned LSPs. Suppose one or more signaling controllers > > managing > >> some LSP went out of service leaving the LSP's data plane intact. As > > far > >> as the user is concerned such LSP is perfectly healthy and > > operational. > >> Such situation could last for a considerable period of time. Do we > > need to > >> manage such LSP via control plane? Sure, we must be capable to tear > > down > >> such LSP, perform mb4b rerouting, distribute alarms between > > operational > >> controllers, signal data plane faults and perform recovery switchover, > >> modify LSP status, etc. Can we do this today? No, but with some > >> (signaling) extensions the problem I believe is solvable. Is this some > >> artificial, "fabricated" problem? No, I think it is real. Does it fall > >> under the control plane resilience problem space? I believe it does. > >> > >> Igor > >> > >> > I agree with Zafar and Dimitri. If someone wanted to document the > > GMPLS > >> > control plane resiliency features, as was done for GMPLS addressing, > >> > that might be a useful activity. > >> > > >> >> -----Original Message----- > >> >> From: dimitri papadimitriou [mailto:dpapadimitriou@psg.com] > >> >> Sent: Friday, October 28, 2005 9:56 AM > >> >> To: Igor Bryskin > >> >> Cc: Zafar Ali (zali); Kim Young Hwa; ccamp@ops.ietf.org > >> >> Subject: Re: Two Drafts for Resilience of Control Plane > >> >> > >> >> igor - > >> >> > >> >> over time CCAMP came with a set of mechanims to improve control > > plane > >> >> resilience (RSVP and LMP GR upon channel/node failure) other WG > >> > protocol > >> >> work are also usable used here OSPF GR, etc. ... on the other side, > >> >> mechanism such as link bundling have built-in resilience > > capabilities > >> >> and most GMPLS control plane capabilities have been designed such > > as > >> > to > >> >> be independent of the control plane realisation (in-band, > > out-of-band, > >> >> etc.) > >> >> > >> >> so indeed i share the concern of Zafar what could we do more here > > than > >> >> document these tools and provide our experience in using them; > >> >> > >> >> now, before stating there are (potential) problems(s) arising - > > would > >> >> you please be more specific on what are these potential issue(s) > >> > and/or > >> >> problems ? (not related to policy/config. - note: all the issues > > you > >> >> have pointed here below are simply policy/config specific but none > > of > >> >> them highlights a missing IP control plane resiliency feature) > >> >> > >> >> thanks, > >> >> - dimitri. > >> >> > >> >> > >> >> Igor Bryskin wrote: > >> >> > >> >> > Zafar, > >> >> > > >> >> > The problem arises when the control plane is decoupled > >> >> > from the data plane. The question is do we need such > >> >> > decoupling in IP networks? Consider, for example, the > >> >> > situation when several parallel PSC data links bundled > >> >> > together and controlled by a single control channel. > >> >> > Does it mean in this case that when the control > >> >> > channel fails all associated data links also fail? Do > >> >> > we need to reroute in this case LSPs that use the data > >> >> > links? Can we rely in this case on control plane > >> >> > indications to decide whether an associated data link > >> >> > is healthy or not (in other words, can we rely on RSVP > >> >> > Hellos or should we use, for example, BTD)? Should we > >> >> > be capable to recover control channels without > >> >> > disturbing data plane? I think control plane > >> >> > resilience is important for all layers. You are right, > >> >> > Internet does work, however, we do need for some > >> >> > reason TE and (fast) recovery in IP as much as in > >> >> > other layers,don't we? > >> >> > > >> >> > Cheers, > >> >> > Igor > >> >> > > >> >> > --- "Zafar Ali (zali)" wrote: > >> >> > > >> >> > > >> >> >>Hi All, > >> >> >> > >> >> >>I am unable to understand the problem we are trying > >> >> >>to solve or > >> >> >>fabricate. My control network is IP based and IP has > >> >> >>proven resiliency > >> >> >>(Internet *does* work), why would I like to take > >> >> >>control plan resiliency > >> >> >>problem at a layer *above-IP* and complicate my > >> >> >>life. Did I miss > >> >> >>something? > >> >> >> > >> >> >>Thanks > >> >> >> > >> >> >>Regards... Zafar > >> >> >> > >> >> >> > >> >> >>________________________________ > >> >> >> > >> >> >> From: owner-ccamp@ops.ietf.org > >> >> >>[mailto:owner-ccamp@ops.ietf.org] > >> >> >>On Behalf Of Kim Young Hwa > >> >> >> Sent: Friday, October 28, 2005 6:04 AM > >> >> >> To: ccamp@ops.ietf.org > >> >> >> Subject: Two Drafts for Resilience of Control Plane > >> >> >> > >> >> >> > >> >> >> Dear all, > >> >> >> > >> >> >> I posted two drafts for the resilience of control > >> >> >>plane. > >> >> >> One is for requirements of the resilience of > >> >> >>control plane, the > >> >> >>other is for a protocol specification as a solution > >> >> >>of that . > >> >> >> These are now available at: > >> >> >> > >> >> >> > >> >> > > >> >> > > > http://www.ietf.org/internet-drafts/draft-kim-ccamp-cpr-reqts-01.txt > >> >> > > >> >> >> > >> >> >> > >> >> > > >> >> > > >> > > > http://www.ietf.org/internet-drafts/draft-kim-ccamp-accp-protocol-00.txt > >> >> > > >> >> >> > >> >> >> I want your comments. > >> >> >> > >> >> >> Regards > >> >> >> > >> >> >> Young. > >> >> >> > >> >> >> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D> >> Young-Hwa Kim > >> >> >> Principal Member / Ph.D > >> >> >> BcN Research Division, ETRI > >> >> >> Tel: +82-42-860-5819 > >> >> >> Fax: +82-42-860-5440 > >> >> >> e-mail: yhwkim@etri.re.kr > >> >> >> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D> >> > >> >> >> > >> >> > > >> >> > > >> > > > >> >> > > >> >> > > >> > > > g&name=3Dccamp%40ops.ietf.org&fromemail=3Dyhwkim@etri.re.kr&messageid=3D%= 3C863 > >> >> > > >> >> >>0a6db-0c31-49ab-a798-13b0dda04553@etri.re.kr%3E> > >> >> >> > >> >> >> > >> >> > > >> >> > > >> >> > > >> >> > > >> >> > > >> >> > > >> >> > __________________________________ > >> >> > Yahoo! Mail - PC Magazine Editors' Choice 2005 > >> >> > http://mail.yahoo.com > >> >> > > >> >> > > >> >> > . > >> >> > > >> > > >> > > >> > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 28 Oct 2005 20:08:46 +0000 Message-ID: <4658.68.100.80.11.1130530098.squirrel@webmail.movaz.com> Date: Fri, 28 Oct 2005 16:08:18 -0400 (EDT) Subject: Re: Two Drafts for Resilience of Control Plane From: ibryskin@movaz.com To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be Cc: ibryskin@movaz.com, Drake@movaz.com, "John E" , dimitri.papadimitriou@alcatel.be, "Igor Bryskin" , "Zafar Ali" , "Kim Young Hwa" , ccamp@ops.ietf.org User-Agent: SquirrelMail/1.4.1 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit Dimitri, See in-line. > igor - > > you are already going beyond the specific discussion context > > 1. what is a control plane partitioned LSP ? LSPs with one or more controllers down, so there is/are partitions in hop-by-hop signaling > > 2. when you state "Suppose one or more signaling controllers managing > some LSP went out of service leaving the LSP’s data plane intact." > > what does it mean "one or more controllers" ? what if you support > RSVP GR ? why are you not able to recover the states ? etc. See my response to John. There are no restarts in my example > > hence, i still miss the exact problem wrt to the control plane protocol > resilience > > but i think there is another issue (which is even more important) - the > resilience mechanisms of the control plane that we have today have been > provided based on experience from the common use of the control plane > and for being resilient wrt common failures - but not for ALL use of the > control plane in ANY condition and for ALL possible failures - indeed > what you are asking here is like what shall i do when the CP is > completely down and the DP still up; it would surprise me that the CP > would be of any help in this specific condition Believe me, CP could be still of a great help in such conditions. You need some signaling extensions - which is why I think CP resilience is an important topic within CCAMP - and then you can manage LSPs with control plane gaps at least to the extend I described. Igor > > thanks, > - dimitri. > > ibryskin@movaz.com wrote: > >> Hi, >> >> Here is one of the problems that I’ve been thinking for a while – >> control >> plane partitioned LSPs. Suppose one or more signaling controllers >> managing >> some LSP went out of service leaving the LSP’s data plane intact. As far >> as the user is concerned such LSP is perfectly healthy and operational. >> Such situation could last for a considerable period of time. Do we need >> to >> manage such LSP via control plane? Sure, we must be capable to tear down >> such LSP, perform mb4b rerouting, distribute alarms between operational >> controllers, signal data plane faults and perform recovery switchover, >> modify LSP status, etc. Can we do this today? No, but with some >> (signaling) extensions the problem I believe is solvable. Is this some >> artificial, “fabricated” problem? No, I think it is real. Does it fall >> under the control plane resilience problem space? I believe it does. >> >> Igor >> >> >>>I agree with Zafar and Dimitri. If someone wanted to document the GMPLS >>>control plane resiliency features, as was done for GMPLS addressing, >>>that might be a useful activity. >>> >>> >>>>-----Original Message----- >>>>From: dimitri papadimitriou [mailto:dpapadimitriou@psg.com] >>>>Sent: Friday, October 28, 2005 9:56 AM >>>>To: Igor Bryskin >>>>Cc: Zafar Ali (zali); Kim Young Hwa; ccamp@ops.ietf.org >>>>Subject: Re: Two Drafts for Resilience of Control Plane >>>> >>>>igor - >>>> >>>>over time CCAMP came with a set of mechanims to improve control plane >>>>resilience (RSVP and LMP GR upon channel/node failure) other WG >>> >>>protocol >>> >>>>work are also usable used here OSPF GR, etc. ... on the other side, >>>>mechanism such as link bundling have built-in resilience capabilities >>>>and most GMPLS control plane capabilities have been designed such as >>> >>>to >>> >>>>be independent of the control plane realisation (in-band, out-of-band, >>>>etc.) >>>> >>>>so indeed i share the concern of Zafar what could we do more here than >>>>document these tools and provide our experience in using them; >>>> >>>>now, before stating there are (potential) problems(s) arising - would >>>>you please be more specific on what are these potential issue(s) >>> >>>and/or >>> >>>>problems ? (not related to policy/config. - note: all the issues you >>>>have pointed here below are simply policy/config specific but none of >>>>them highlights a missing IP control plane resiliency feature) >>>> >>>>thanks, >>>>- dimitri. >>>> >>>> >>>>Igor Bryskin wrote: >>>> >>>> >>>>>Zafar, >>>>> >>>>>The problem arises when the control plane is decoupled >>>>>from the data plane. The question is do we need such >>>>>decoupling in IP networks? Consider, for example, the >>>>>situation when several parallel PSC data links bundled >>>>>together and controlled by a single control channel. >>>>>Does it mean in this case that when the control >>>>>channel fails all associated data links also fail? Do >>>>>we need to reroute in this case LSPs that use the data >>>>>links? Can we rely in this case on control plane >>>>>indications to decide whether an associated data link >>>>>is healthy or not (in other words, can we rely on RSVP >>>>>Hellos or should we use, for example, BTD)? Should we >>>>>be capable to recover control channels without >>>>>disturbing data plane? I think control plane >>>>>resilience is important for all layers. You are right, >>>>>Internet does work, however, we do need for some >>>>>reason TE and (fast) recovery in IP as much as in >>>>>other layers,don't we? >>>>> >>>>>Cheers, >>>>>Igor >>>>> >>>>>--- "Zafar Ali (zali)" wrote: >>>>> >>>>> >>>>> >>>>>>Hi All, >>>>>> >>>>>>I am unable to understand the problem we are trying >>>>>>to solve or >>>>>>fabricate. My control network is IP based and IP has >>>>>>proven resiliency >>>>>>(Internet *does* work), why would I like to take >>>>>>control plan resiliency >>>>>>problem at a layer *above-IP* and complicate my >>>>>>life. Did I miss >>>>>>something? >>>>>> >>>>>>Thanks >>>>>> >>>>>>Regards... Zafar >>>>>> >>>>>> >>>>>>________________________________ >>>>>> >>>>>> From: owner-ccamp@ops.ietf.org >>>>>>[mailto:owner-ccamp@ops.ietf.org] >>>>>>On Behalf Of Kim Young Hwa >>>>>> Sent: Friday, October 28, 2005 6:04 AM >>>>>> To: ccamp@ops.ietf.org >>>>>> Subject: Two Drafts for Resilience of Control Plane >>>>>> >>>>>> >>>>>> Dear all, >>>>>> >>>>>> I posted two drafts for the resilience of control >>>>>>plane. >>>>>> One is for requirements of the resilience of >>>>>>control plane, the >>>>>>other is for a protocol specification as a solution >>>>>>of that . >>>>>> These are now available at: >>>>>> >>>>>> >>>>> >>>>>http://www.ietf.org/internet-drafts/draft-kim-ccamp-cpr-reqts-01.txt >>>>> >>>>> >>>>>> >>>>> >>>http://www.ietf.org/internet-drafts/draft-kim-ccamp-accp-protocol-00.txt >>> >>>>>> I want your comments. >>>>>> >>>>>> Regards >>>>>> >>>>>> Young. >>>>>> >>>>>> ===================================> >> Young-Hwa Kim >>>>>> Principal Member / Ph.D >>>>>> BcN Research Division, ETRI >>>>>> Tel: +82-42-860-5819 >>>>>> Fax: +82-42-860-5440 >>>>>> e-mail: yhwkim@etri.re.kr >>>>>> ===================================> >> >>>>>> >>>>> >>>>> >>>>> >>>g&name=ccamp%40ops.ietf.org&fromemail=yhwkim@etri.re.kr&messageid=%3C863 >>> >>>>>>0a6db-0c31-49ab-a798-13b0dda04553@etri.re.kr%3E> >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>__________________________________ >>>>>Yahoo! Mail - PC Magazine Editors' Choice 2005 >>>>>http://mail.yahoo.com >>>>> >>>>> >>>>>. >>>>> >>> >>> >>> >> >> >> >> . >> > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 28 Oct 2005 20:01:19 +0000 Message-ID: <4650.68.100.80.11.1130529616.squirrel@webmail.movaz.com> Date: Fri, 28 Oct 2005 16:00:16 -0400 (EDT) Subject: RE: Two Drafts for Resilience of Control Plane From: ibryskin@movaz.com To: "Drake, John E" Cc: ibryskin@movaz.com, dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be, "Igor Bryskin" , "Zafar Ali" , "Kim Young Hwa" , ccamp@ops.ietf.org User-Agent: SquirrelMail/1.4.1 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit John, I think you missed my point here. "Dead" controllers in my example *do not* come back for a considerable period of time. So there are no restarts here (graceful or not graceful) :=) Igor > What part of your problem, as stated below, is not handled by RSVP > graceful restart? > >> -----Original Message----- >> From: ibryskin@movaz.com [mailto:ibryskin@movaz.com] >> Sent: Friday, October 28, 2005 11:41 AM >> To: Drake, John E >> Cc: dpapadimitriou@psg.com; dimitri.papadimitriou@alcatel.be; Igor >> Bryskin; Zafar Ali; Kim Young Hwa; ccamp@ops.ietf.org >> Subject: RE: Two Drafts for Resilience of Control Plane >> >> Hi, >> >> Here is one of the problems that I've been thinking for a while - > control >> plane partitioned LSPs. Suppose one or more signaling controllers > managing >> some LSP went out of service leaving the LSP's data plane intact. As > far >> as the user is concerned such LSP is perfectly healthy and > operational. >> Such situation could last for a considerable period of time. Do we > need to >> manage such LSP via control plane? Sure, we must be capable to tear > down >> such LSP, perform mb4b rerouting, distribute alarms between > operational >> controllers, signal data plane faults and perform recovery switchover, >> modify LSP status, etc. Can we do this today? No, but with some >> (signaling) extensions the problem I believe is solvable. Is this some >> artificial, "fabricated" problem? No, I think it is real. Does it fall >> under the control plane resilience problem space? I believe it does. >> >> Igor >> >> > I agree with Zafar and Dimitri. If someone wanted to document the > GMPLS >> > control plane resiliency features, as was done for GMPLS addressing, >> > that might be a useful activity. >> > >> >> -----Original Message----- >> >> From: dimitri papadimitriou [mailto:dpapadimitriou@psg.com] >> >> Sent: Friday, October 28, 2005 9:56 AM >> >> To: Igor Bryskin >> >> Cc: Zafar Ali (zali); Kim Young Hwa; ccamp@ops.ietf.org >> >> Subject: Re: Two Drafts for Resilience of Control Plane >> >> >> >> igor - >> >> >> >> over time CCAMP came with a set of mechanims to improve control > plane >> >> resilience (RSVP and LMP GR upon channel/node failure) other WG >> > protocol >> >> work are also usable used here OSPF GR, etc. ... on the other side, >> >> mechanism such as link bundling have built-in resilience > capabilities >> >> and most GMPLS control plane capabilities have been designed such > as >> > to >> >> be independent of the control plane realisation (in-band, > out-of-band, >> >> etc.) >> >> >> >> so indeed i share the concern of Zafar what could we do more here > than >> >> document these tools and provide our experience in using them; >> >> >> >> now, before stating there are (potential) problems(s) arising - > would >> >> you please be more specific on what are these potential issue(s) >> > and/or >> >> problems ? (not related to policy/config. - note: all the issues > you >> >> have pointed here below are simply policy/config specific but none > of >> >> them highlights a missing IP control plane resiliency feature) >> >> >> >> thanks, >> >> - dimitri. >> >> >> >> >> >> Igor Bryskin wrote: >> >> >> >> > Zafar, >> >> > >> >> > The problem arises when the control plane is decoupled >> >> > from the data plane. The question is do we need such >> >> > decoupling in IP networks? Consider, for example, the >> >> > situation when several parallel PSC data links bundled >> >> > together and controlled by a single control channel. >> >> > Does it mean in this case that when the control >> >> > channel fails all associated data links also fail? Do >> >> > we need to reroute in this case LSPs that use the data >> >> > links? Can we rely in this case on control plane >> >> > indications to decide whether an associated data link >> >> > is healthy or not (in other words, can we rely on RSVP >> >> > Hellos or should we use, for example, BTD)? Should we >> >> > be capable to recover control channels without >> >> > disturbing data plane? I think control plane >> >> > resilience is important for all layers. You are right, >> >> > Internet does work, however, we do need for some >> >> > reason TE and (fast) recovery in IP as much as in >> >> > other layers,don't we? >> >> > >> >> > Cheers, >> >> > Igor >> >> > >> >> > --- "Zafar Ali (zali)" wrote: >> >> > >> >> > >> >> >>Hi All, >> >> >> >> >> >>I am unable to understand the problem we are trying >> >> >>to solve or >> >> >>fabricate. My control network is IP based and IP has >> >> >>proven resiliency >> >> >>(Internet *does* work), why would I like to take >> >> >>control plan resiliency >> >> >>problem at a layer *above-IP* and complicate my >> >> >>life. Did I miss >> >> >>something? >> >> >> >> >> >>Thanks >> >> >> >> >> >>Regards... Zafar >> >> >> >> >> >> >> >> >>________________________________ >> >> >> >> >> >> From: owner-ccamp@ops.ietf.org >> >> >>[mailto:owner-ccamp@ops.ietf.org] >> >> >>On Behalf Of Kim Young Hwa >> >> >> Sent: Friday, October 28, 2005 6:04 AM >> >> >> To: ccamp@ops.ietf.org >> >> >> Subject: Two Drafts for Resilience of Control Plane >> >> >> >> >> >> >> >> >> Dear all, >> >> >> >> >> >> I posted two drafts for the resilience of control >> >> >>plane. >> >> >> One is for requirements of the resilience of >> >> >>control plane, the >> >> >>other is for a protocol specification as a solution >> >> >>of that . >> >> >> These are now available at: >> >> >> >> >> >> >> >> > >> >> > > http://www.ietf.org/internet-drafts/draft-kim-ccamp-cpr-reqts-01.txt >> >> > >> >> >> >> >> >> >> >> > >> >> > >> > > http://www.ietf.org/internet-drafts/draft-kim-ccamp-accp-protocol-00.txt >> >> > >> >> >> >> >> >> I want your comments. >> >> >> >> >> >> Regards >> >> >> >> >> >> Young. >> >> >> >> >> >> ===================================> >> Young-Hwa Kim >> >> >> Principal Member / Ph.D >> >> >> BcN Research Division, ETRI >> >> >> Tel: +82-42-860-5819 >> >> >> Fax: +82-42-860-5440 >> >> >> e-mail: yhwkim@etri.re.kr >> >> >> ===================================> >> >> >> >> >> >> > >> >> > >> > > > >> > >> >> > >> > > g&name=ccamp%40ops.ietf.org&fromemail=yhwkim@etri.re.kr&messageid=%3C863 >> >> > >> >> >>0a6db-0c31-49ab-a798-13b0dda04553@etri.re.kr%3E> >> >> >> >> >> >> >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > __________________________________ >> >> > Yahoo! Mail - PC Magazine Editors' Choice 2005 >> >> > http://mail.yahoo.com >> >> > >> >> > >> >> > . >> >> > >> > >> > >> > > > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 28 Oct 2005 19:04:19 +0000 Message-ID: <436275E3.9040504@psg.com> Date: Fri, 28 Oct 2005 21:02:59 +0200 From: dimitri papadimitriou Reply-To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.11) Gecko/20050728 MIME-Version: 1.0 To: ibryskin@movaz.com CC: "Drake, John E" , dimitri.papadimitriou@alcatel.be, Igor Bryskin , Zafar Ali , Kim Young Hwa , ccamp@ops.ietf.org Subject: Re: Two Drafts for Resilience of Control Plane Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit igor - you are already going beyond the specific discussion context 1. what is a control plane partitioned LSP ? 2. when you state "Suppose one or more signaling controllers managing some LSP went out of service leaving the LSP’s data plane intact." what does it mean "one or more controllers" ? what if you support RSVP GR ? why are you not able to recover the states ? etc. hence, i still miss the exact problem wrt to the control plane protocol resilience but i think there is another issue (which is even more important) - the resilience mechanisms of the control plane that we have today have been provided based on experience from the common use of the control plane and for being resilient wrt common failures - but not for ALL use of the control plane in ANY condition and for ALL possible failures - indeed what you are asking here is like what shall i do when the CP is completely down and the DP still up; it would surprise me that the CP would be of any help in this specific condition thanks, - dimitri. ibryskin@movaz.com wrote: > Hi, > > Here is one of the problems that I’ve been thinking for a while – control > plane partitioned LSPs. Suppose one or more signaling controllers managing > some LSP went out of service leaving the LSP’s data plane intact. As far > as the user is concerned such LSP is perfectly healthy and operational. > Such situation could last for a considerable period of time. Do we need to > manage such LSP via control plane? Sure, we must be capable to tear down > such LSP, perform mb4b rerouting, distribute alarms between operational > controllers, signal data plane faults and perform recovery switchover, > modify LSP status, etc. Can we do this today? No, but with some > (signaling) extensions the problem I believe is solvable. Is this some > artificial, “fabricated” problem? No, I think it is real. Does it fall > under the control plane resilience problem space? I believe it does. > > Igor > > >>I agree with Zafar and Dimitri. If someone wanted to document the GMPLS >>control plane resiliency features, as was done for GMPLS addressing, >>that might be a useful activity. >> >> >>>-----Original Message----- >>>From: dimitri papadimitriou [mailto:dpapadimitriou@psg.com] >>>Sent: Friday, October 28, 2005 9:56 AM >>>To: Igor Bryskin >>>Cc: Zafar Ali (zali); Kim Young Hwa; ccamp@ops.ietf.org >>>Subject: Re: Two Drafts for Resilience of Control Plane >>> >>>igor - >>> >>>over time CCAMP came with a set of mechanims to improve control plane >>>resilience (RSVP and LMP GR upon channel/node failure) other WG >> >>protocol >> >>>work are also usable used here OSPF GR, etc. ... on the other side, >>>mechanism such as link bundling have built-in resilience capabilities >>>and most GMPLS control plane capabilities have been designed such as >> >>to >> >>>be independent of the control plane realisation (in-band, out-of-band, >>>etc.) >>> >>>so indeed i share the concern of Zafar what could we do more here than >>>document these tools and provide our experience in using them; >>> >>>now, before stating there are (potential) problems(s) arising - would >>>you please be more specific on what are these potential issue(s) >> >>and/or >> >>>problems ? (not related to policy/config. - note: all the issues you >>>have pointed here below are simply policy/config specific but none of >>>them highlights a missing IP control plane resiliency feature) >>> >>>thanks, >>>- dimitri. >>> >>> >>>Igor Bryskin wrote: >>> >>> >>>>Zafar, >>>> >>>>The problem arises when the control plane is decoupled >>>>from the data plane. The question is do we need such >>>>decoupling in IP networks? Consider, for example, the >>>>situation when several parallel PSC data links bundled >>>>together and controlled by a single control channel. >>>>Does it mean in this case that when the control >>>>channel fails all associated data links also fail? Do >>>>we need to reroute in this case LSPs that use the data >>>>links? Can we rely in this case on control plane >>>>indications to decide whether an associated data link >>>>is healthy or not (in other words, can we rely on RSVP >>>>Hellos or should we use, for example, BTD)? Should we >>>>be capable to recover control channels without >>>>disturbing data plane? I think control plane >>>>resilience is important for all layers. You are right, >>>>Internet does work, however, we do need for some >>>>reason TE and (fast) recovery in IP as much as in >>>>other layers,don't we? >>>> >>>>Cheers, >>>>Igor >>>> >>>>--- "Zafar Ali (zali)" wrote: >>>> >>>> >>>> >>>>>Hi All, >>>>> >>>>>I am unable to understand the problem we are trying >>>>>to solve or >>>>>fabricate. My control network is IP based and IP has >>>>>proven resiliency >>>>>(Internet *does* work), why would I like to take >>>>>control plan resiliency >>>>>problem at a layer *above-IP* and complicate my >>>>>life. Did I miss >>>>>something? >>>>> >>>>>Thanks >>>>> >>>>>Regards... Zafar >>>>> >>>>> >>>>>________________________________ >>>>> >>>>> From: owner-ccamp@ops.ietf.org >>>>>[mailto:owner-ccamp@ops.ietf.org] >>>>>On Behalf Of Kim Young Hwa >>>>> Sent: Friday, October 28, 2005 6:04 AM >>>>> To: ccamp@ops.ietf.org >>>>> Subject: Two Drafts for Resilience of Control Plane >>>>> >>>>> >>>>> Dear all, >>>>> >>>>> I posted two drafts for the resilience of control >>>>>plane. >>>>> One is for requirements of the resilience of >>>>>control plane, the >>>>>other is for a protocol specification as a solution >>>>>of that . >>>>> These are now available at: >>>>> >>>>> >>>> >>>>http://www.ietf.org/internet-drafts/draft-kim-ccamp-cpr-reqts-01.txt >>>> >>>> >>>>> >>>> >>http://www.ietf.org/internet-drafts/draft-kim-ccamp-accp-protocol-00.txt >> >>>>> I want your comments. >>>>> >>>>> Regards >>>>> >>>>> Young. >>>>> >>>>> ===================================> >> Young-Hwa Kim >>>>> Principal Member / Ph.D >>>>> BcN Research Division, ETRI >>>>> Tel: +82-42-860-5819 >>>>> Fax: +82-42-860-5440 >>>>> e-mail: yhwkim@etri.re.kr >>>>> ===================================> >> >>>>> >>>> >>> >>>> >>g&name=ccamp%40ops.ietf.org&fromemail=yhwkim@etri.re.kr&messageid=%3C863 >> >>>>>0a6db-0c31-49ab-a798-13b0dda04553@etri.re.kr%3E> >>>>> >>>>> >>>> >>>> >>>> >>>> >>>> >>>>__________________________________ >>>>Yahoo! Mail - PC Magazine Editors' Choice 2005 >>>>http://mail.yahoo.com >>>> >>>> >>>>. >>>> >> >> >> > > > > . > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 28 Oct 2005 18:53:00 +0000 Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed Message-Id: <9CD44DF1-E80A-4722-9191-BB90D5292111@cisco.com> Content-Transfer-Encoding: quoted-printable From: "Thomas D. Nadeau" Subject: Re: Two Drafts for Resilience of Control Plane Date: Fri, 28 Oct 2005 14:52:47 -0400 To: ccamp@ops.ietf.org Just like with 'classic' MPLS, with GMPLS I think you have a situation where the data and control planes could be out of sync., or at least out of contact with each other for a period of time. This is certainly not a fabricated problem, but a matter of 'how often' and 'how bad' when it happens (i.e.: is the IP control plane sufficiently resilient) As Zafar said earlier, there are already some mechanisms in place to handle this. Some folks (vendors only) have said they are sufficient. To me, this should be a question that operator types should be answering. --Tom > Hi, > > Here is one of the problems that I=92ve been thinking for a while =96 =20= > control > plane partitioned LSPs. Suppose one or more signaling controllers =20 > managing > some LSP went out of service leaving the LSP=92s data plane intact. =20= > As far > as the user is concerned such LSP is perfectly healthy and =20 > operational. > Such situation could last for a considerable period of time. Do we =20 > need to > manage such LSP via control plane? Sure, we must be capable to tear =20= > down > such LSP, perform mb4b rerouting, distribute alarms between =20 > operational > controllers, signal data plane faults and perform recovery switchover, > modify LSP status, etc. Can we do this today? No, but with some > (signaling) extensions the problem I believe is solvable. Is this some > artificial, =93fabricated=94 problem? No, I think it is real. Does it = fall > under the control plane resilience problem space? I believe it does. > > Igor > > >> I agree with Zafar and Dimitri. If someone wanted to document the =20= >> GMPLS >> control plane resiliency features, as was done for GMPLS addressing, >> that might be a useful activity. >> >> >>> -----Original Message----- >>> From: dimitri papadimitriou [mailto:dpapadimitriou@psg.com] >>> Sent: Friday, October 28, 2005 9:56 AM >>> To: Igor Bryskin >>> Cc: Zafar Ali (zali); Kim Young Hwa; ccamp@ops.ietf.org >>> Subject: Re: Two Drafts for Resilience of Control Plane >>> >>> igor - >>> >>> over time CCAMP came with a set of mechanims to improve control =20 >>> plane >>> resilience (RSVP and LMP GR upon channel/node failure) other WG >>> >> protocol >> >>> work are also usable used here OSPF GR, etc. ... on the other side, >>> mechanism such as link bundling have built-in resilience =20 >>> capabilities >>> and most GMPLS control plane capabilities have been designed such as >>> >> to >> >>> be independent of the control plane realisation (in-band, out-of-=20 >>> band, >>> etc.) >>> >>> so indeed i share the concern of Zafar what could we do more here =20= >>> than >>> document these tools and provide our experience in using them; >>> >>> now, before stating there are (potential) problems(s) arising - =20 >>> would >>> you please be more specific on what are these potential issue(s) >>> >> and/or >> >>> problems ? (not related to policy/config. - note: all the issues you >>> have pointed here below are simply policy/config specific but =20 >>> none of >>> them highlights a missing IP control plane resiliency feature) >>> >>> thanks, >>> - dimitri. >>> >>> >>> Igor Bryskin wrote: >>> >>> >>>> Zafar, >>>> >>>> The problem arises when the control plane is decoupled >>>> from the data plane. The question is do we need such >>>> decoupling in IP networks? Consider, for example, the >>>> situation when several parallel PSC data links bundled >>>> together and controlled by a single control channel. >>>> Does it mean in this case that when the control >>>> channel fails all associated data links also fail? Do >>>> we need to reroute in this case LSPs that use the data >>>> links? Can we rely in this case on control plane >>>> indications to decide whether an associated data link >>>> is healthy or not (in other words, can we rely on RSVP >>>> Hellos or should we use, for example, BTD)? Should we >>>> be capable to recover control channels without >>>> disturbing data plane? I think control plane >>>> resilience is important for all layers. You are right, >>>> Internet does work, however, we do need for some >>>> reason TE and (fast) recovery in IP as much as in >>>> other layers,don't we? >>>> >>>> Cheers, >>>> Igor >>>> >>>> --- "Zafar Ali (zali)" wrote: >>>> >>>> >>>> >>>>> Hi All, >>>>> >>>>> I am unable to understand the problem we are trying >>>>> to solve or >>>>> fabricate. My control network is IP based and IP has >>>>> proven resiliency >>>>> (Internet *does* work), why would I like to take >>>>> control plan resiliency >>>>> problem at a layer *above-IP* and complicate my >>>>> life. Did I miss >>>>> something? >>>>> >>>>> Thanks >>>>> >>>>> Regards... Zafar >>>>> >>>>> >>>>> ________________________________ >>>>> >>>>> From: owner-ccamp@ops.ietf.org >>>>> [mailto:owner-ccamp@ops.ietf.org] >>>>> On Behalf Of Kim Young Hwa >>>>> Sent: Friday, October 28, 2005 6:04 AM >>>>> To: ccamp@ops.ietf.org >>>>> Subject: Two Drafts for Resilience of Control Plane >>>>> >>>>> >>>>> Dear all, >>>>> >>>>> I posted two drafts for the resilience of control >>>>> plane. >>>>> One is for requirements of the resilience of >>>>> control plane, the >>>>> other is for a protocol specification as a solution >>>>> of that . >>>>> These are now available at: >>>>> >>>>> >>>>> >>>> >>>> http://www.ietf.org/internet-drafts/draft-kim-ccamp-cpr-=20 >>>> reqts-01.txt >>>> >>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >> http://www.ietf.org/internet-drafts/draft-kim-ccamp-accp-=20 >> protocol-00.txt >> >>>> >>>> >>>>> >>>>> I want your comments. >>>>> >>>>> Regards >>>>> >>>>> Young. >>>>> >>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D> >> Young-Hwa Kim >>>>> Principal Member / Ph.D >>>>> BcN Research Division, ETRI >>>>> Tel: +82-42-860-5819 >>>>> Fax: +82-42-860-5440 >>>>> e-mail: yhwkim@etri.re.kr >>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D> >> >>>>> >>>>> >>>> >>>> >>>> >> > email=3Dccamp@ops.ietf.or >> >>>> >>>> >>>> >> g&name=3Dccamp%40ops.ietf.org&fromemail=3Dyhwkim@etri.re.kr&messageid=3D= %=20 >> 3C863 >> >>>> >>>> >>>>> 0a6db-0c31-49ab-a798-13b0dda04553@etri.re.kr%3E> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> __________________________________ >>>> Yahoo! Mail - PC Magazine Editors' Choice 2005 >>>> http://mail.yahoo.com >>>> >>>> >>>> . >>>> >>>> >> >> >> > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 28 Oct 2005 18:48:45 +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: Two Drafts for Resilience of Control Plane Date: Fri, 28 Oct 2005 11:48:19 -0700 Message-ID: <626FC7C6A97381468FB872072AB5DDC83696FE@XCH-SW-42.sw.nos.boeing.com> Thread-Topic: Two Drafts for Resilience of Control Plane Thread-Index: AcXb7zdjVlvAUlhGQAOKUI2nmgJ52QAAKYjQ From: "Drake, John E" To: Cc: , , "Igor Bryskin" , "Zafar Ali" , "Kim Young Hwa" , What part of your problem, as stated below, is not handled by RSVP graceful restart? > -----Original Message----- > From: ibryskin@movaz.com [mailto:ibryskin@movaz.com] > Sent: Friday, October 28, 2005 11:41 AM > To: Drake, John E > Cc: dpapadimitriou@psg.com; dimitri.papadimitriou@alcatel.be; Igor > Bryskin; Zafar Ali; Kim Young Hwa; ccamp@ops.ietf.org > Subject: RE: Two Drafts for Resilience of Control Plane >=20 > Hi, >=20 > Here is one of the problems that I've been thinking for a while - control > plane partitioned LSPs. Suppose one or more signaling controllers managing > some LSP went out of service leaving the LSP's data plane intact. As far > as the user is concerned such LSP is perfectly healthy and operational. > Such situation could last for a considerable period of time. Do we need to > manage such LSP via control plane? Sure, we must be capable to tear down > such LSP, perform mb4b rerouting, distribute alarms between operational > controllers, signal data plane faults and perform recovery switchover, > modify LSP status, etc. Can we do this today? No, but with some > (signaling) extensions the problem I believe is solvable. Is this some > artificial, "fabricated" problem? No, I think it is real. Does it fall > under the control plane resilience problem space? I believe it does. >=20 > Igor >=20 > > I agree with Zafar and Dimitri. If someone wanted to document the GMPLS > > control plane resiliency features, as was done for GMPLS addressing, > > that might be a useful activity. > > > >> -----Original Message----- > >> From: dimitri papadimitriou [mailto:dpapadimitriou@psg.com] > >> Sent: Friday, October 28, 2005 9:56 AM > >> To: Igor Bryskin > >> Cc: Zafar Ali (zali); Kim Young Hwa; ccamp@ops.ietf.org > >> Subject: Re: Two Drafts for Resilience of Control Plane > >> > >> igor - > >> > >> over time CCAMP came with a set of mechanims to improve control plane > >> resilience (RSVP and LMP GR upon channel/node failure) other WG > > protocol > >> work are also usable used here OSPF GR, etc. ... on the other side, > >> mechanism such as link bundling have built-in resilience capabilities > >> and most GMPLS control plane capabilities have been designed such as > > to > >> be independent of the control plane realisation (in-band, out-of-band, > >> etc.) > >> > >> so indeed i share the concern of Zafar what could we do more here than > >> document these tools and provide our experience in using them; > >> > >> now, before stating there are (potential) problems(s) arising - would > >> you please be more specific on what are these potential issue(s) > > and/or > >> problems ? (not related to policy/config. - note: all the issues you > >> have pointed here below are simply policy/config specific but none of > >> them highlights a missing IP control plane resiliency feature) > >> > >> thanks, > >> - dimitri. > >> > >> > >> Igor Bryskin wrote: > >> > >> > Zafar, > >> > > >> > The problem arises when the control plane is decoupled > >> > from the data plane. The question is do we need such > >> > decoupling in IP networks? Consider, for example, the > >> > situation when several parallel PSC data links bundled > >> > together and controlled by a single control channel. > >> > Does it mean in this case that when the control > >> > channel fails all associated data links also fail? Do > >> > we need to reroute in this case LSPs that use the data > >> > links? Can we rely in this case on control plane > >> > indications to decide whether an associated data link > >> > is healthy or not (in other words, can we rely on RSVP > >> > Hellos or should we use, for example, BTD)? Should we > >> > be capable to recover control channels without > >> > disturbing data plane? I think control plane > >> > resilience is important for all layers. You are right, > >> > Internet does work, however, we do need for some > >> > reason TE and (fast) recovery in IP as much as in > >> > other layers,don't we? > >> > > >> > Cheers, > >> > Igor > >> > > >> > --- "Zafar Ali (zali)" wrote: > >> > > >> > > >> >>Hi All, > >> >> > >> >>I am unable to understand the problem we are trying > >> >>to solve or > >> >>fabricate. My control network is IP based and IP has > >> >>proven resiliency > >> >>(Internet *does* work), why would I like to take > >> >>control plan resiliency > >> >>problem at a layer *above-IP* and complicate my > >> >>life. Did I miss > >> >>something? > >> >> > >> >>Thanks > >> >> > >> >>Regards... Zafar > >> >> > >> >> > >> >>________________________________ > >> >> > >> >> From: owner-ccamp@ops.ietf.org > >> >>[mailto:owner-ccamp@ops.ietf.org] > >> >>On Behalf Of Kim Young Hwa > >> >> Sent: Friday, October 28, 2005 6:04 AM > >> >> To: ccamp@ops.ietf.org > >> >> Subject: Two Drafts for Resilience of Control Plane > >> >> > >> >> > >> >> Dear all, > >> >> > >> >> I posted two drafts for the resilience of control > >> >>plane. > >> >> One is for requirements of the resilience of > >> >>control plane, the > >> >>other is for a protocol specification as a solution > >> >>of that . > >> >> These are now available at: > >> >> > >> >> > >> > > >> > http://www.ietf.org/internet-drafts/draft-kim-ccamp-cpr-reqts-01.txt > >> > > >> >> > >> >> > >> > > >> > > > http://www.ietf.org/internet-drafts/draft-kim-ccamp-accp-protocol-00.txt > >> > > >> >> > >> >> I want your comments. > >> >> > >> >> Regards > >> >> > >> >> Young. > >> >> > >> >> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D> >> Young-Hwa Kim > >> >> Principal Member / Ph.D > >> >> BcN Research Division, ETRI > >> >> Tel: +82-42-860-5819 > >> >> Fax: +82-42-860-5440 > >> >> e-mail: yhwkim@etri.re.kr > >> >> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D> >> > >> >> > >> > > >> > > > >> > > >> > > > g&name=3Dccamp%40ops.ietf.org&fromemail=3Dyhwkim@etri.re.kr&messageid=3D%= 3C863 > >> > > >> >>0a6db-0c31-49ab-a798-13b0dda04553@etri.re.kr%3E> > >> >> > >> >> > >> > > >> > > >> > > >> > > >> > > >> > > >> > __________________________________ > >> > Yahoo! Mail - PC Magazine Editors' Choice 2005 > >> > http://mail.yahoo.com > >> > > >> > > >> > . > >> > > > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 28 Oct 2005 18:42:03 +0000 Message-ID: <4618.68.100.80.11.1130524889.squirrel@webmail.movaz.com> Date: Fri, 28 Oct 2005 14:41:29 -0400 (EDT) Subject: RE: Two Drafts for Resilience of Control Plane From: ibryskin@movaz.com To: "Drake, John E" Cc: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be, "Igor Bryskin" , "Zafar Ali" , "Kim Young Hwa" , ccamp@ops.ietf.org User-Agent: SquirrelMail/1.4.1 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hi, Here is one of the problems that I’ve been thinking for a while – control plane partitioned LSPs. Suppose one or more signaling controllers managing some LSP went out of service leaving the LSP’s data plane intact. As far as the user is concerned such LSP is perfectly healthy and operational. Such situation could last for a considerable period of time. Do we need to manage such LSP via control plane? Sure, we must be capable to tear down such LSP, perform mb4b rerouting, distribute alarms between operational controllers, signal data plane faults and perform recovery switchover, modify LSP status, etc. Can we do this today? No, but with some (signaling) extensions the problem I believe is solvable. Is this some artificial, “fabricated” problem? No, I think it is real. Does it fall under the control plane resilience problem space? I believe it does. Igor > I agree with Zafar and Dimitri. If someone wanted to document the GMPLS > control plane resiliency features, as was done for GMPLS addressing, > that might be a useful activity. > >> -----Original Message----- >> From: dimitri papadimitriou [mailto:dpapadimitriou@psg.com] >> Sent: Friday, October 28, 2005 9:56 AM >> To: Igor Bryskin >> Cc: Zafar Ali (zali); Kim Young Hwa; ccamp@ops.ietf.org >> Subject: Re: Two Drafts for Resilience of Control Plane >> >> igor - >> >> over time CCAMP came with a set of mechanims to improve control plane >> resilience (RSVP and LMP GR upon channel/node failure) other WG > protocol >> work are also usable used here OSPF GR, etc. ... on the other side, >> mechanism such as link bundling have built-in resilience capabilities >> and most GMPLS control plane capabilities have been designed such as > to >> be independent of the control plane realisation (in-band, out-of-band, >> etc.) >> >> so indeed i share the concern of Zafar what could we do more here than >> document these tools and provide our experience in using them; >> >> now, before stating there are (potential) problems(s) arising - would >> you please be more specific on what are these potential issue(s) > and/or >> problems ? (not related to policy/config. - note: all the issues you >> have pointed here below are simply policy/config specific but none of >> them highlights a missing IP control plane resiliency feature) >> >> thanks, >> - dimitri. >> >> >> Igor Bryskin wrote: >> >> > Zafar, >> > >> > The problem arises when the control plane is decoupled >> > from the data plane. The question is do we need such >> > decoupling in IP networks? Consider, for example, the >> > situation when several parallel PSC data links bundled >> > together and controlled by a single control channel. >> > Does it mean in this case that when the control >> > channel fails all associated data links also fail? Do >> > we need to reroute in this case LSPs that use the data >> > links? Can we rely in this case on control plane >> > indications to decide whether an associated data link >> > is healthy or not (in other words, can we rely on RSVP >> > Hellos or should we use, for example, BTD)? Should we >> > be capable to recover control channels without >> > disturbing data plane? I think control plane >> > resilience is important for all layers. You are right, >> > Internet does work, however, we do need for some >> > reason TE and (fast) recovery in IP as much as in >> > other layers,don't we? >> > >> > Cheers, >> > Igor >> > >> > --- "Zafar Ali (zali)" wrote: >> > >> > >> >>Hi All, >> >> >> >>I am unable to understand the problem we are trying >> >>to solve or >> >>fabricate. My control network is IP based and IP has >> >>proven resiliency >> >>(Internet *does* work), why would I like to take >> >>control plan resiliency >> >>problem at a layer *above-IP* and complicate my >> >>life. Did I miss >> >>something? >> >> >> >>Thanks >> >> >> >>Regards... Zafar >> >> >> >> >> >>________________________________ >> >> >> >> From: owner-ccamp@ops.ietf.org >> >>[mailto:owner-ccamp@ops.ietf.org] >> >>On Behalf Of Kim Young Hwa >> >> Sent: Friday, October 28, 2005 6:04 AM >> >> To: ccamp@ops.ietf.org >> >> Subject: Two Drafts for Resilience of Control Plane >> >> >> >> >> >> Dear all, >> >> >> >> I posted two drafts for the resilience of control >> >>plane. >> >> One is for requirements of the resilience of >> >>control plane, the >> >>other is for a protocol specification as a solution >> >>of that . >> >> These are now available at: >> >> >> >> >> > >> > http://www.ietf.org/internet-drafts/draft-kim-ccamp-cpr-reqts-01.txt >> > >> >> >> >> >> > >> > > http://www.ietf.org/internet-drafts/draft-kim-ccamp-accp-protocol-00.txt >> > >> >> >> >> I want your comments. >> >> >> >> Regards >> >> >> >> Young. >> >> >> >> ===================================> >> Young-Hwa Kim >> >> Principal Member / Ph.D >> >> BcN Research Division, ETRI >> >> Tel: +82-42-860-5819 >> >> Fax: +82-42-860-5440 >> >> e-mail: yhwkim@etri.re.kr >> >> ===================================> >> >> >> >> > >> > > > > >> > > g&name=ccamp%40ops.ietf.org&fromemail=yhwkim@etri.re.kr&messageid=%3C863 >> > >> >>0a6db-0c31-49ab-a798-13b0dda04553@etri.re.kr%3E> >> >> >> >> >> > >> > >> > >> > >> > >> > >> > __________________________________ >> > Yahoo! Mail - PC Magazine Editors' Choice 2005 >> > http://mail.yahoo.com >> > >> > >> > . >> > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 28 Oct 2005 18:23:36 +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: Two Drafts for Resilience of Control Plane Date: Fri, 28 Oct 2005 14:22:28 -0400 Message-ID: Thread-Topic: Two Drafts for Resilience of Control Plane Thread-Index: AcXb11THC5FHtbFMShalW0lcPamnOgACYLyw From: "Zafar Ali \(zali\)" To: "Igor Bryskin" , "Kim Young Hwa" , > -----Original Message----- > From: Igor Bryskin [mailto:i_bryskin@yahoo.com]=20 > Sent: Friday, October 28, 2005 11:50 AM > To: Zafar Ali (zali); Kim Young Hwa; ccamp@ops.ietf.org > Subject: RE: Two Drafts for Resilience of Control Plane >=20 > Zafar, >=20 > The problem arises when the control plane is decoupled from=20 > the data plane.=20 But control network is still (and needs to be) an IP network.=20 >The question is do we need such decoupling in=20 > IP networks? Consider, for example, the situation when=20 > several parallel PSC data links bundled together and=20 > controlled by a single control channel. If this "single control channel" is "IP routing" the control packets, as long as there is resilience in the control network (i.e., alternate IP routes), we should be see "single control channel" as a deficiency. It's as best of resiliency that it gets.=20 > Does it mean in this case that when the control channel fails=20 > all associated data links also fail?=20 > Do we need to reroute in=20 > this case LSPs that use the data links?=20 We have (RSVP/ LMP) GR procedures for recovery of control network failures.=20 >Can we rely in this=20 > case on control plane indications to decide whether an=20 > associated data link is healthy or not (in other words, can=20 > we rely on RSVP Hellos or should we use, for example, BTD)?=20 > Should we be capable to recover control channels without=20 > disturbing data plane?=20 All these things are already addressed, please also see Dimitri's email on this.=20 > I think control plane resilience is=20 > important for all layers.=20 What is your definition of layers here? What I am saying is that having control network resilience build outside IP layer is "bad complexity".=20 > You are right, Internet does work,=20 > however, we do need for some reason TE and (fast) recovery in=20 > IP as much as in other layers,don't we? >=20 > Cheers, > Igor >=20 > --- "Zafar Ali (zali)" wrote: >=20 > > Hi All, > > =20 > > I am unable to understand the problem we are trying to solve or=20 > > fabricate. My control network is IP based and IP has proven=20 > resiliency=20 > > (Internet *does* work), why would I like to take control plan=20 > > resiliency problem at a layer *above-IP* and complicate my=20 > life. Did I=20 > > miss something? > > =20 > > Thanks > > =20 > > Regards... Zafar > >=20 > >=20 > > ________________________________ > >=20 > > From: owner-ccamp@ops.ietf.org > > [mailto:owner-ccamp@ops.ietf.org] > > On Behalf Of Kim Young Hwa > > Sent: Friday, October 28, 2005 6:04 AM > > To: ccamp@ops.ietf.org > > Subject: Two Drafts for Resilience of Control Plane > > =09 > > =09 > > Dear all, > > =20 > > I posted two drafts for the resilience of control plane. > > One is for requirements of the resilience of control=20 > plane, the other=20 > > is for a protocol specification as a solution of that . > > These are now available at: > > =09 > > > http://www.ietf.org/internet-drafts/draft-kim-ccamp-cpr-reqts-01.txt > > =09 > > > http://www.ietf.org/internet-drafts/draft-kim-ccamp-accp-proto > col-00.txt > > =20 > > I want your comments. > > =20 > > Regards > > =20 > > Young. > > =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 > > Young-Hwa Kim > > Principal Member / Ph.D > > BcN Research Division, ETRI > > Tel: +82-42-860-5819 > > Fax: +82-42-860-5440 > > e-mail: yhwkim@etri.re.kr > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > =09 > > > ps.ietf.or > > > g&name=3Dccamp%40ops.ietf.org&fromemail=3Dyhwkim@etri.re.kr&messag > eid=3D%3C863 > > 0a6db-0c31-49ab-a798-13b0dda04553@etri.re.kr%3E> > >=20 > >=20 >=20 >=20 >=20 > =09 > =09 > __________________________________ > Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com >=20 Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 28 Oct 2005 17:57:28 +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: Two Drafts for Resilience of Control Plane Date: Fri, 28 Oct 2005 10:56:22 -0700 Message-ID: <626FC7C6A97381468FB872072AB5DDC83696FA@XCH-SW-42.sw.nos.boeing.com> Thread-Topic: Two Drafts for Resilience of Control Plane Thread-Index: AcXb4gqeAeS5AmH7SQKkqh+S5btlSgABlHCQ From: "Drake, John E" To: , , "Igor Bryskin" Cc: "Zafar Ali \(zali\)" , "Kim Young Hwa" , I agree with Zafar and Dimitri. If someone wanted to document the GMPLS control plane resiliency features, as was done for GMPLS addressing, that might be a useful activity. > -----Original Message----- > From: dimitri papadimitriou [mailto:dpapadimitriou@psg.com] > Sent: Friday, October 28, 2005 9:56 AM > To: Igor Bryskin > Cc: Zafar Ali (zali); Kim Young Hwa; ccamp@ops.ietf.org > Subject: Re: Two Drafts for Resilience of Control Plane >=20 > igor - >=20 > over time CCAMP came with a set of mechanims to improve control plane > resilience (RSVP and LMP GR upon channel/node failure) other WG protocol > work are also usable used here OSPF GR, etc. ... on the other side, > mechanism such as link bundling have built-in resilience capabilities > and most GMPLS control plane capabilities have been designed such as to > be independent of the control plane realisation (in-band, out-of-band, > etc.) >=20 > so indeed i share the concern of Zafar what could we do more here than > document these tools and provide our experience in using them; >=20 > now, before stating there are (potential) problems(s) arising - would > you please be more specific on what are these potential issue(s) and/or > problems ? (not related to policy/config. - note: all the issues you > have pointed here below are simply policy/config specific but none of > them highlights a missing IP control plane resiliency feature) >=20 > thanks, > - dimitri. >=20 >=20 > Igor Bryskin wrote: >=20 > > Zafar, > > > > The problem arises when the control plane is decoupled > > from the data plane. The question is do we need such > > decoupling in IP networks? Consider, for example, the > > situation when several parallel PSC data links bundled > > together and controlled by a single control channel. > > Does it mean in this case that when the control > > channel fails all associated data links also fail? Do > > we need to reroute in this case LSPs that use the data > > links? Can we rely in this case on control plane > > indications to decide whether an associated data link > > is healthy or not (in other words, can we rely on RSVP > > Hellos or should we use, for example, BTD)? Should we > > be capable to recover control channels without > > disturbing data plane? I think control plane > > resilience is important for all layers. You are right, > > Internet does work, however, we do need for some > > reason TE and (fast) recovery in IP as much as in > > other layers,don't we? > > > > Cheers, > > Igor > > > > --- "Zafar Ali (zali)" wrote: > > > > > >>Hi All, > >> > >>I am unable to understand the problem we are trying > >>to solve or > >>fabricate. My control network is IP based and IP has > >>proven resiliency > >>(Internet *does* work), why would I like to take > >>control plan resiliency > >>problem at a layer *above-IP* and complicate my > >>life. Did I miss > >>something? > >> > >>Thanks > >> > >>Regards... Zafar > >> > >> > >>________________________________ > >> > >> From: owner-ccamp@ops.ietf.org > >>[mailto:owner-ccamp@ops.ietf.org] > >>On Behalf Of Kim Young Hwa > >> Sent: Friday, October 28, 2005 6:04 AM > >> To: ccamp@ops.ietf.org > >> Subject: Two Drafts for Resilience of Control Plane > >> > >> > >> Dear all, > >> > >> I posted two drafts for the resilience of control > >>plane. > >> One is for requirements of the resilience of > >>control plane, the > >>other is for a protocol specification as a solution > >>of that . > >> These are now available at: > >> > >> > > > > http://www.ietf.org/internet-drafts/draft-kim-ccamp-cpr-reqts-01.txt > > > >> > >> > > > > http://www.ietf.org/internet-drafts/draft-kim-ccamp-accp-protocol-00.txt > > > >> > >> I want your comments. > >> > >> Regards > >> > >> Young. > >> > >> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >> Young-Hwa Kim > >> Principal Member / Ph.D > >> BcN Research Division, ETRI > >> Tel: +82-42-860-5819 > >> Fax: +82-42-860-5440 > >> e-mail: yhwkim@etri.re.kr > >> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >> > >> > > > > > > > g&name=3Dccamp%40ops.ietf.org&fromemail=3Dyhwkim@etri.re.kr&messageid=3D%= 3C863 > > > >>0a6db-0c31-49ab-a798-13b0dda04553@etri.re.kr%3E> > >> > >> > > > > > > > > > > > > > > __________________________________ > > Yahoo! Mail - PC Magazine Editors' Choice 2005 > > http://mail.yahoo.com > > > > > > . > > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 28 Oct 2005 16:57:38 +0000 Message-ID: <4362581B.7050503@psg.com> Date: Fri, 28 Oct 2005 18:55:55 +0200 From: dimitri papadimitriou Reply-To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.11) Gecko/20050728 MIME-Version: 1.0 To: Igor Bryskin CC: "Zafar Ali (zali)" , Kim Young Hwa , ccamp@ops.ietf.org Subject: Re: Two Drafts for Resilience of Control Plane Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit igor - over time CCAMP came with a set of mechanims to improve control plane resilience (RSVP and LMP GR upon channel/node failure) other WG protocol work are also usable used here OSPF GR, etc. ... on the other side, mechanism such as link bundling have built-in resilience capabilities and most GMPLS control plane capabilities have been designed such as to be independent of the control plane realisation (in-band, out-of-band, etc.) so indeed i share the concern of Zafar what could we do more here than document these tools and provide our experience in using them; now, before stating there are (potential) problems(s) arising - would you please be more specific on what are these potential issue(s) and/or problems ? (not related to policy/config. - note: all the issues you have pointed here below are simply policy/config specific but none of them highlights a missing IP control plane resiliency feature) thanks, - dimitri. Igor Bryskin wrote: > Zafar, > > The problem arises when the control plane is decoupled > from the data plane. The question is do we need such > decoupling in IP networks? Consider, for example, the > situation when several parallel PSC data links bundled > together and controlled by a single control channel. > Does it mean in this case that when the control > channel fails all associated data links also fail? Do > we need to reroute in this case LSPs that use the data > links? Can we rely in this case on control plane > indications to decide whether an associated data link > is healthy or not (in other words, can we rely on RSVP > Hellos or should we use, for example, BTD)? Should we > be capable to recover control channels without > disturbing data plane? I think control plane > resilience is important for all layers. You are right, > Internet does work, however, we do need for some > reason TE and (fast) recovery in IP as much as in > other layers,don't we? > > Cheers, > Igor > > --- "Zafar Ali (zali)" wrote: > > >>Hi All, >> >>I am unable to understand the problem we are trying >>to solve or >>fabricate. My control network is IP based and IP has >>proven resiliency >>(Internet *does* work), why would I like to take >>control plan resiliency >>problem at a layer *above-IP* and complicate my >>life. Did I miss >>something? >> >>Thanks >> >>Regards... Zafar >> >> >>________________________________ >> >> From: owner-ccamp@ops.ietf.org >>[mailto:owner-ccamp@ops.ietf.org] >>On Behalf Of Kim Young Hwa >> Sent: Friday, October 28, 2005 6:04 AM >> To: ccamp@ops.ietf.org >> Subject: Two Drafts for Resilience of Control Plane >> >> >> Dear all, >> >> I posted two drafts for the resilience of control >>plane. >> One is for requirements of the resilience of >>control plane, the >>other is for a protocol specification as a solution >>of that . >> These are now available at: >> >> > > http://www.ietf.org/internet-drafts/draft-kim-ccamp-cpr-reqts-01.txt > >> >> > > http://www.ietf.org/internet-drafts/draft-kim-ccamp-accp-protocol-00.txt > >> >> I want your comments. >> >> Regards >> >> Young. >> >> ==================================== >> Young-Hwa Kim >> Principal Member / Ph.D >> BcN Research Division, ETRI >> Tel: +82-42-860-5819 >> Fax: +82-42-860-5440 >> e-mail: yhwkim@etri.re.kr >> ==================================== >> >> > > > g&name=ccamp%40ops.ietf.org&fromemail=yhwkim@etri.re.kr&messageid=%3C863 > >>0a6db-0c31-49ab-a798-13b0dda04553@etri.re.kr%3E> >> >> > > > > > > > __________________________________ > Yahoo! Mail - PC Magazine Editors' Choice 2005 > http://mail.yahoo.com > > > . > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 28 Oct 2005 16:29:11 +0000 Message-ID: <43625184.5020208@psg.com> Date: Fri, 28 Oct 2005 18:27:48 +0200 From: dimitri papadimitriou Reply-To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.11) Gecko/20050728 MIME-Version: 1.0 To: "Zafar Ali (zali)" CC: Kim Young Hwa , ccamp@ops.ietf.org Subject: Re: Two Drafts for Resilience of Control Plane Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit zafar - Zafar Ali (zali) wrote: > Hi All, > > I am unable to understand the problem we are trying to solve or > fabricate. My control network is IP based and IP has proven resiliency > (Internet *does* work), why would I like to take control plan resiliency > problem at a layer *above-IP* and complicate my life. Did I miss > something? ... i don't think the issue is to invent new problems but at some point in time it may be become advisable to document the mechanisms available at hand and applicable to support control plane resilience - note they are disseminated in several I-Ds and RFCs today - at least this would prevent from re-discussing periodically this issue while at the end the initial problem has been covered progressively since CCAMP work started > Thanks > > Regards... Zafar > > > ________________________________ > > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] > On Behalf Of Kim Young Hwa > Sent: Friday, October 28, 2005 6:04 AM > To: ccamp@ops.ietf.org > Subject: Two Drafts for Resilience of Control Plane > > > Dear all, > > I posted two drafts for the resilience of control plane. > One is for requirements of the resilience of control plane, the > other is for a protocol specification as a solution of that . > These are now available at: > > http://www.ietf.org/internet-drafts/draft-kim-ccamp-cpr-reqts-01.txt > > http://www.ietf.org/internet-drafts/draft-kim-ccamp-accp-protocol-00.txt > > I want your comments. > > Regards > > Young. > > ==================================== > Young-Hwa Kim > Principal Member / Ph.D > BcN Research Division, ETRI > Tel: +82-42-860-5819 > Fax: +82-42-860-5440 > e-mail: yhwkim@etri.re.kr > ==================================== > > g&name=ccamp%40ops.ietf.org&fromemail=yhwkim@etri.re.kr&messageid=%3C863 > 0a6db-0c31-49ab-a798-13b0dda04553@etri.re.kr%3E> > > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 28 Oct 2005 15:58:42 +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: Two Drafts for Resilience of Control Plane Date: Fri, 28 Oct 2005 16:58:26 +0100 Message-ID: <0536FC9B908BEC4597EE721BE6A35389121B05E7@i2km07-ukbr.domain1.systemhost.net> Thread-Topic: Two Drafts for Resilience of Control Plane Thread-Index: AcXb15NliMHpReJpQZqOhK30NpkCigAAN+7g From: To: , , , To add..... There are some fairly significant differences between cl-ps mode, co-ps mode and co-cs mode networks. Indeed, in the co-cs mode an OOB control/management *network* is a forced solution. And note there are (at least) 2 different networks in the same networking system....and how one addresses resilience for these 2 networks is quite different. In fact because the control/management plane network is so important it should only ever take its design cues from the duct topology. And there are other ways to deal with resilience other than 'an IGP' here, cf the link-set in C7 (which btw is a cl-ps OOB network) as used in the PSTN..........don't knock it, its a very simple and excellent idea....maybe a researcher should look at it for some inspiration ;-) regards, Neil > -----Original Message----- > From: owner-ccamp@ops.ietf.org > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Igor Bryskin > Sent: 28 October 2005 16:50 > To: Zafar Ali (zali); Kim Young Hwa; ccamp@ops.ietf.org > Subject: RE: Two Drafts for Resilience of Control Plane >=20 >=20 > Zafar, >=20 > The problem arises when the control plane is decoupled > from the data plane. The question is do we need such decoupling in IP=20 > networks? Consider, for example, the situation when several parallel=20 > PSC data links bundled together and controlled by a single control=20 > channel. Does it mean in this case that when the control > channel fails all associated data links also fail? Do > we need to reroute in this case LSPs that use the data > links? Can we rely in this case on control plane > indications to decide whether an associated data link > is healthy or not (in other words, can we rely on RSVP > Hellos or should we use, for example, BTD)? Should we > be capable to recover control channels without > disturbing data plane? I think control plane > resilience is important for all layers. You are right, > Internet does work, however, we do need for some > reason TE and (fast) recovery in IP as much as in > other layers,don't we? >=20 > Cheers, > Igor >=20 > --- "Zafar Ali (zali)" wrote: >=20 > > Hi All, > > =20 > > I am unable to understand the problem we are trying > > to solve or > > fabricate. My control network is IP based and IP has > > proven resiliency > > (Internet *does* work), why would I like to take > > control plan resiliency > > problem at a layer *above-IP* and complicate my > > life. Did I miss > > something? > > =20 > > Thanks > > =20 > > Regards... Zafar > >=20 > >=20 > > ________________________________ > >=20 > > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On=20 > > Behalf Of Kim Young Hwa > > Sent: Friday, October 28, 2005 6:04 AM > > To: ccamp@ops.ietf.org > > Subject: Two Drafts for Resilience of Control Plane > > =09 > > =09 > > Dear all, > > =20 > > I posted two drafts for the resilience of control > > plane. > > One is for requirements of the resilience of > > control plane, the > > other is for a protocol specification as a solution > > of that . > > These are now available at: > > =09 > > > http://www.ietf.org/internet-drafts/draft-kim-ccamp-cpr-reqts-01.txt > > =09 > > > http://www.ietf.org/internet-drafts/draft-kim-ccamp-accp-proto col-00.txt > =20 > I want your comments. > =20 > Regards > =20 > Young. > =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 > Young-Hwa Kim > Principal Member / Ph.D > BcN Research Division, ETRI > Tel: +82-42-860-5819 > Fax: +82-42-860-5440 > e-mail: yhwkim@etri.re.kr > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > =09 > g&name=3Dccamp%40ops.ietf.org&fromemail=3Dyhwkim@etri.re.kr&messageid=3D%= 3C863 > 0a6db-0c31-49ab-a798-13b0dda04553@etri.re.kr%3E> >=20 >=20 =09 =09 __________________________________=20 Yahoo! Mail - PC Magazine Editors' Choice 2005=20 http://mail.yahoo.com Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 28 Oct 2005 15:51:59 +0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=Xy/KC/QEQUOOD9b+s8ebToX45nE5kCMvHPscXK0oAaRP30jBIYeBx2+T9CSZOaFdvy7keIbVFd0ptAO23NxGGJ08g4ExLgMirGdKUoYSSsNcZxGpHSFdG2lq97NJrr6EgUuwcz4xNCfKREynW+qgX9F/m2ix5uwZaWGDxZwedKs= ; Message-ID: <20051028155012.73678.qmail@web30806.mail.mud.yahoo.com> Date: Fri, 28 Oct 2005 08:50:12 -0700 (PDT) From: Igor Bryskin Subject: RE: Two Drafts for Resilience of Control Plane To: "Zafar Ali \(zali\)" , Kim Young Hwa , ccamp@ops.ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Zafar, The problem arises when the control plane is decoupled from the data plane. The question is do we need such decoupling in IP networks? Consider, for example, the situation when several parallel PSC data links bundled together and controlled by a single control channel. Does it mean in this case that when the control channel fails all associated data links also fail? Do we need to reroute in this case LSPs that use the data links? Can we rely in this case on control plane indications to decide whether an associated data link is healthy or not (in other words, can we rely on RSVP Hellos or should we use, for example, BTD)? Should we be capable to recover control channels without disturbing data plane? I think control plane resilience is important for all layers. You are right, Internet does work, however, we do need for some reason TE and (fast) recovery in IP as much as in other layers,don't we? Cheers, Igor --- "Zafar Ali (zali)" wrote: > Hi All, > > I am unable to understand the problem we are trying > to solve or > fabricate. My control network is IP based and IP has > proven resiliency > (Internet *does* work), why would I like to take > control plan resiliency > problem at a layer *above-IP* and complicate my > life. Did I miss > something? > > Thanks > > Regards... Zafar > > > ________________________________ > > From: owner-ccamp@ops.ietf.org > [mailto:owner-ccamp@ops.ietf.org] > On Behalf Of Kim Young Hwa > Sent: Friday, October 28, 2005 6:04 AM > To: ccamp@ops.ietf.org > Subject: Two Drafts for Resilience of Control Plane > > > Dear all, > > I posted two drafts for the resilience of control > plane. > One is for requirements of the resilience of > control plane, the > other is for a protocol specification as a solution > of that . > These are now available at: > > http://www.ietf.org/internet-drafts/draft-kim-ccamp-cpr-reqts-01.txt > > http://www.ietf.org/internet-drafts/draft-kim-ccamp-accp-protocol-00.txt > > I want your comments. > > Regards > > Young. > > ==================================== > Young-Hwa Kim > Principal Member / Ph.D > BcN Research Division, ETRI > Tel: +82-42-860-5819 > Fax: +82-42-860-5440 > e-mail: yhwkim@etri.re.kr > ==================================== > > g&name=ccamp%40ops.ietf.org&fromemail=yhwkim@etri.re.kr&messageid=%3C863 > 0a6db-0c31-49ab-a798-13b0dda04553@etri.re.kr%3E> > > __________________________________ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 28 Oct 2005 14:14:33 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5DBC9.D19D9A71" Subject: RE: Two Drafts for Resilience of Control Plane Date: Fri, 28 Oct 2005 10:13:49 -0400 Message-ID: Thread-Topic: Two Drafts for Resilience of Control Plane Thread-Index: AcXbpva8X72puaIDTr2d5rSGc74m/gAIju6g From: "Zafar Ali \(zali\)" To: "Kim Young Hwa" , This is a multi-part message in MIME format. ------_=_NextPart_001_01C5DBC9.D19D9A71 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi All,=20 =20 I am unable to understand the problem we are trying to solve or fabricate. My control network is IP based and IP has proven resiliency (Internet *does* work), why would I like to take control plan resiliency problem at a layer *above-IP* and complicate my life. Did I miss something?=20 =20 Thanks =20 Regards... Zafar=20 ________________________________ From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Kim Young Hwa Sent: Friday, October 28, 2005 6:04 AM To: ccamp@ops.ietf.org Subject: Two Drafts for Resilience of Control Plane =09 =09 Dear all, =20 I posted two drafts for the resilience of control plane. One is for requirements of the resilience of control plane, the other is for a protocol specification as a solution of that . These are now available at: =09 http://www.ietf.org/internet-drafts/draft-kim-ccamp-cpr-reqts-01.txt =09 http://www.ietf.org/internet-drafts/draft-kim-ccamp-accp-protocol-00.txt =20 I want your comments. =20 Regards =20 Young. =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 Young-Hwa Kim Principal Member / Ph.D BcN Research Division, ETRI Tel: +82-42-860-5819 Fax: +82-42-860-5440 e-mail: yhwkim@etri.re.kr = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =09 =20 ------_=_NextPart_001_01C5DBC9.D19D9A71 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
Hi All,
 
I am unable to understand the problem we are = trying to=20 solve or fabricate. My control network is IP based and = IP has proven=20 resiliency (Internet *does* work), why would I like to take control plan = resiliency problem at a layer *above-IP* and complicate my life. Did I = miss=20 something?
 
Thanks
 
Regards... Zafar

From: owner-ccamp@ops.ietf.org=20 [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Kim Young=20 Hwa
Sent: Friday, October 28, 2005 6:04 AM
To:=20 ccamp@ops.ietf.org
Subject: Two Drafts for Resilience of = Control=20 Plane

Dear all,
 
I posted two drafts for the resilience of control plane.
One is for requirements of the resilience of control plane, the = other is=20 for a protocol specification as a solution of that .
These are now available at:
http://www.ietf.org/internet-drafts/draft-kim-ccamp-cpr-r= eqts-01.txt
http://www.ietf.org/internet-drafts/draft-kim-ccamp-accp-= protocol-00.txt
 
I want your comments.
 
Regards
 
Young.
 
=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Young-Hwa Kim
Principal = Member=20 / Ph.D
BcN Research Division, ETRI
Tel:    =20 +82-42-860-5819
Fax:    +82-42-860-5440
e-mail: = yhwkim@etri.re.kr
=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D
------_=_NextPart_001_01C5DBC9.D19D9A71-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 28 Oct 2005 13:48:43 +0000 To: "Kim Young Hwa" Cc: MIME-Version: 1.0 From: Dimitri.Papadimitriou@alcatel.be Subject: Re: Two Drafts for Resilience of Control Plane Date: Fri, 28 Oct 2005 15:47:15 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: base64 PFA+PEZPTlQgRkFDRT0iTW9ub3NwYWNlLENvdXJpZXIiPmhpIDwvRk9OVD48L1A+PFA+PEZPTlQg RkFDRT0iTW9ub3NwYWNlLENvdXJpZXIiPmkgaGF2ZSBzZW50IGEgY291cGxlIG9mIGNvbW1lbnRz IG9uIHRoaXMgbGlzdCBvbiB0aGUgZmlyc3QgZG9jdW1lbnQgKHJlcXVpcmVtZW50cykgYSBjb3Vw bGUgb2YgZGF5cyBhZ288L0ZPTlQ+PC9QPjxQPjxGT05UIEZBQ0U9Ik1vbm9zcGFjZSxDb3VyaWVy Ij48VT5ub3RlPC9VPjogaSB3b3VsZCByYXRoZXIgcmUtb3JpZW50IHRoaXMgZG9jIGEgcG9zaXRp b25pbmcgYW5kIHByb2JsZW0gc3RhdGVtZW50IGRvY3VtZW50IChpbmNsdWRpbmcgZGlzY3Vzc2lv biBvbiBmZWF0dXJlIHNldCkgPC9GT05UPjxCUj48QlI+PEZPTlQgU0laRT0yPjxCPiZxdW90O0tp bSBZb3VuZyBId2EmcXVvdDsgJmx0O3lod2tpbUBldHJpLnJlLmtyJmd0OzwvQj48L0ZPTlQ+PEJS PjxGT05UIFNJWkU9Mj5TZW50IGJ5OiBvd25lci1jY2FtcEBvcHMuaWV0Zi5vcmc8L0ZPTlQ+PEJS PjxGT05UIFNJWkU9Mj4xMC8yOC8yMDA1IDE5OjA0IFpFOTwvRk9OVD48QlI+PEZPTlQgU0laRT0y PlBsZWFzZSByZXNwb25kIHRvICZxdW90O0tpbSBZb3VuZyBId2EmcXVvdDs8L0ZPTlQ+PEJSPjxC Uj4gPEZPTlQgU0laRT0yPlRvOjwvRk9OVD4gPEZPTlQgU0laRT0yPiZsdDtjY2FtcEBvcHMuaWV0 Zi5vcmcmZ3Q7PC9GT05UPjxCUj4gPEZPTlQgU0laRT0yPmNjOjwvRk9OVD4gPEJSPiA8Rk9OVCBT SVpFPTI+YmNjOjwvRk9OVD4gPEJSPiA8Rk9OVCBTSVpFPTI+U3ViamVjdDo8L0ZPTlQ+IDxGT05U IFNJWkU9Mj5bU1BBTT9dIFR3byBEcmFmdHMgZm9yIFJlc2lsaWVuY2Ugb2YgQ29udHJvbCBQbGFu ZTwvRk9OVD48QlI+IDxCUj48QlI+PC9QPjxQPjxGT05UIFNJWkU9ND5EZWFyIGFsbCw8L0ZPTlQ+ PEJSPjxCUj48Rk9OVCBTSVpFPTQ+SSBwb3N0ZWQgdHdvIGRyYWZ0cyBmb3IgdGhlIHJlc2lsaWVu Y2Ugb2YgY29udHJvbCBwbGFuZS48L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND5PbmUgaXMgZm9yIHJl cXVpcmVtZW50cyBvZiB0aGUgcmVzaWxpZW5jZSBvZiBjb250cm9sIHBsYW5lLCB0aGUgb3RoZXIg aXMgZm9yIGEgcHJvdG9jb2wgc3BlY2lmaWNhdGlvbiBhcyBhIHNvbHV0aW9uIG9mIHRoYXQgLjwv Rk9OVD48QlI+PEZPTlQgU0laRT00PlRoZXNlIGFyZSBub3cgYXZhaWxhYmxlIGF0OjwvRk9OVD48 QlI+PEZPTlQgU0laRT00IENPTE9SPUJMVUU+PFU+PEEgSFJFRj1odHRwOi8vd3d3LmlldGYub3Jn L2ludGVybmV0LWRyYWZ0cy9kcmFmdC1raW0tY2NhbXAtY3ByLXJlcXRzLTAxLnR4dD5odHRwOi8v d3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1raW0tY2NhbXAtY3ByLXJlcXRzLTAx LnR4dDwvQT48L1U+PC9GT05UPjxGT05UIENPTE9SPUJMQUNLPjxCUj48L0ZPTlQ+PEZPTlQgU0la RT00IENPTE9SPUJMVUU+PFU+PEEgSFJFRj1odHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRy YWZ0cy9kcmFmdC1raW0tY2NhbXAtYWNjcC1wcm90b2NvbC0wMC50eHQ+aHR0cDovL3d3dy5pZXRm Lm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQta2ltLWNjYW1wLWFjY3AtcHJvdG9jb2wtMDAudHh0 PC9BPjwvVT48L0ZPTlQ+PEZPTlQgQ09MT1I9QkxBQ0s+PEJSPjxCUj48L0ZPTlQ+PEZPTlQgU0la RT00Pkkgd2FudCB5b3VyIGNvbW1lbnRzLjwvRk9OVD48QlI+PEJSPjxGT05UIFNJWkU9ND5SZWdh cmRzPC9GT05UPjxCUj48QlI+PEZPTlQgU0laRT00PllvdW5nLjwvRk9OVD48QlI+PEJSPjxGT05U IFNJWkU9ND49PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT08L0ZPTlQ+PEJSPjxG T05UIFNJWkU9ND5Zb3VuZy1Id2EgS2ltPC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+UHJpbmNpcGFs IE1lbWJlciAvIFBoLkQ8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND5CY04gUmVzZWFyY2ggRGl2aXNp b24sIEVUUkk8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND5UZWw6Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7ICs4Mi00Mi04NjAtNTgxOTwvRk9OVD48QlI+PEZPTlQgU0laRT00PkZheDombmJzcDsmbmJz cDsmbmJzcDsgKzgyLTQyLTg2MC01NDQwPC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+ZS1tYWlsOiA8 L0ZPTlQ+PEZPTlQgU0laRT00IENPTE9SPUJMVUU+PFU+PEEgSFJFRj1tYWlsdG86eWh3a2ltQGV0 cmkucmUua3I+eWh3a2ltQGV0cmkucmUua3I8L0E+PC9VPjwvRk9OVD48Rk9OVCBDT0xPUj1CTEFD Sz48QlI+PC9GT05UPjxGT05UIFNJWkU9ND49PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT08L0ZPTlQ+PEJSPjxGT05UIFNJWkU9MiBDT0xPUj1SRUQ+W0lNQUdFXTwvRk9OVD48Rk9O VCBDT0xPUj1CTEFDSz48QlI+PC9GT05UPjxGT05UIEZBQ0U9Ik1vbm9zcGFjZSxDb3VyaWVyIj4t LS0tLS0tLS0tLS0tLS0tLS0tLSBBTlRJU1BBTSBjbGFzc2lmeSB0b29sIHJlc3VsdHMgLS0tLS0t LS0tLS0tLS0tLS0tPEJSPlRoaXMgbWFpbCB3YXMgcXVhbGlmaWVkIGFzIHNwYW0gYXQgdGhlIFNN VFAgSW50ZXJuZXQgZ2F0ZXdheSBiZXR3ZWVuPEJSPkludGVybmV0IGFuZCBBbGNhbmV0LjxCUj5U aGUgb3JpZ2luYWwgbWVzc2FnZSBoYXMgYmVlbiBhbHRlcmVkIHNvIHlvdSBjYW4gcmVjb2duaXNl IG9yPEJSPm9yIGJsb2NrIHNpbWlsYXIgdW53YW50ZWQgbWFpbCBpbiBmdXR1cmUuPEJSPkZlZWwg ZnJlZSB0byByZXBvcnQgYW55IGluY29udmluaWVuY2VzIHRvIHBvc3RtYXN0ZXJAYWxjYXRlbC5m cjxCUj48L0ZPTlQ+PEJSPjxGT05UIEZBQ0U9Ik1vbm9zcGFjZSxDb3VyaWVyIj5NYWtlIHN1cmUg dG8gcmVhZCBjYXJlZnVsbHkgdGhlIEFsY2F0ZWwgQW50aXNwYW0gUG9saWN5PEJSPm9uIDxBIEhS RUY9aHR0cDovL2RlZG9tMDAyLnN0Z2wuc2VsLmFsY2F0ZWwuZGUvc21hcHNSMi8xQUEvMDAxMDMv MDA3NS9BU1paQS8xQUEwMDEwMzAwNzVBU1paQS5wZGY+aHR0cDovL2RlZG9tMDAyLnN0Z2wuc2Vs LmFsY2F0ZWwuZGUvc21hcHNSMi8xQUEvMDAxMDMvMDA3NS9BU1paQS8xQUEwMDEwMzAwNzVBU1pa QS5wZGY8L0E+PEJSPjwvRk9OVD48QlI+PEZPTlQgRkFDRT0iTW9ub3NwYWNlLENvdXJpZXIiPlRl Y2huaWNhbCBEZXRhaWxzPEJSPkNvbnRlbnQgYW5hbHlzaXMgZGV0YWlsczogJm5ic3A7ICg3LjYg aGl0cywgNi4wIHJlcXVpcmVkKTwvRk9OVD48QlI+PEZPTlQgRkFDRT0iTW9ub3NwYWNlLENvdXJp ZXIiPjEuMSBIVE1MXzUwXzYwICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7IEJPRFk6IE1lc3NhZ2UgaXMgNTAlIHRvIDYwJSBIVE1MPEJSPjEuNSBNSU1FX0hUTUxfTU9T VExZICZuYnNwOyAmbmJzcDsgJm5ic3A7IEJPRFk6IE11bHRpcGFydCBtZXNzYWdlIG1vc3RseSB0 ZXh0L2h0bWwgTUlNRTxCUj4wLjAgSFRNTF9NRVNTQUdFICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgQk9EWTogSFRNTCBpbmNsdWRlZCBpbiBtZXNzYWdlPEJSPjEuNCBIVE1MX0lN QUdFX09OTFlfMTYgJm5ic3A7ICZuYnNwOyBCT0RZOiBIVE1MOiBpbWFnZXMgd2l0aCAxMjAwLTE2 MDAgYnl0ZXMgb2Ygd29yZHM8QlI+MS44IE1QQVJUX0FMVF9ESUZGICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyBCT0RZOiBIVE1MIGFuZCB0ZXh0IHBhcnRzIGFyZSBkaWZmZXJlbnQ8QlI+MC4w IE1JTUVfQkFTRTY0X05PX05BTUUgJm5ic3A7ICZuYnNwO1JBVzogYmFzZTY0IGF0dGFjaG1lbnQg ZG9lcyBub3QgaGF2ZSBhIGZpbGUgbmFtZTxCUj4xLjggTUlNRV9CQVNFNjRfVEVYVCAmbmJzcDsg Jm5ic3A7ICZuYnNwOyBSQVc6IE1lc3NhZ2UgdGV4dCBkaXNndWlzZWQgdXNpbmcgYmFzZTY0IGVu Y29kaW5nPC9GT05UPjxCUj48QlI+PEZPTlQgRkFDRT0iTW9ub3NwYWNlLENvdXJpZXIiPi0tLS0t LS0tLS0tLS0tLS0tLS0tIEVuZCBvZiBBTlRJU1BBTSByZXBvcnQgcmVzdWx0cyAtLS0tLS0tLS0t LS0tLS0tLS0tPEJSPjwvRk9OVD48QlI+PC9QPg== Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 28 Oct 2005 10:08:36 +0000 Message-ID: <077001c5dba7$efd60850$de849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Startling news : new RFCs Date: Fri, 28 Oct 2005 11:10:50 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_076D_01C5DBB0.41536A80" This is a multi-part message in MIME format. ------=_NextPart_000_076D_01C5DBB0.41536A80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, As you'll have seen, a few new RFCs have just been announced. The full list is as follows. RFC 4201 Link Bundling in MPLS Traffic Engineering (TE) RFC 4202 Routing Extensions in Support of Generalized=20 Multi-Protocol Label Switching (GMPLS) RFC 4203 OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS) RFC 4204 Link Management Protocol (LMP) RFC 4205 Intermediate System to Intermediate System (IS-IS) Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS) RFC 4206 Label Switched Paths (LSP) Hierarchy with=20 Generalized Multi-Protocol Label Switching (GMPLS) Traffic Engineering (TE) RFC 4207 Synchronous Optical Network (SONET)/Synchronous Digital Hierarchy (SDH) Encoding for Link Management Protocol (LMP) Test Messages RFC 4208 Generalized Multiprotocol Label Switching (GMPLS) User-Network Interface (UNI): Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Support for the Overlay Model RFC 4209 Link Management Protocol (LMP) for Dense=20 Wavelength Division Multiplexing (DWDM) Optical Line Systems (Note that RFC4209 doesn't appear to have been announced, but it has = been published any way.) The charter page will be updated to reflect this soon. Many thanks to everyone involved.=20 Adrian ------=_NextPart_000_076D_01C5DBB0.41536A80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,

As you'll have seen, a few = new RFCs=20 have just been announced.
The full list is as follows.

RFC = 4201 Link=20 Bundling in MPLS Traffic Engineering (TE)
RFC 4202 Routing Extensions = in=20 Support of Generalized =
        =20 Multi-Protocol Label Switching (GMPLS)
RFC 4203 OSPF Extensions in = Support of=20 Generalized
         = Multi-Protocol=20 Label Switching (GMPLS)
RFC 4204 Link Management Protocol = (LMP)
RFC 4205=20 Intermediate System to Intermediate System=20 (IS-IS)
         Extensions = in=20 Support of Generalized=20 Multi-Protocol
         Label = Switching (GMPLS)
RFC 4206 Label Switched Paths (LSP) Hierarchy with=20
         Generalized = Multi-Protocol=20 Label Switching = (GMPLS)
        =20 Traffic Engineering (TE)
RFC 4207 Synchronous Optical Network=20 (SONET)/Synchronous
         = Digital=20 Hierarchy (SDH) Encoding for=20 Link
         Management = Protocol=20 (LMP) Test Messages
RFC 4208 Generalized Multiprotocol Label = Switching=20 (GMPLS)
         User-Network = Interface (UNI):
         = Resource=20 ReserVation Protocol-Traffic=20 Engineering
         = (RSVP-TE)=20 Support for the Overlay Model
RFC 4209 Link Management Protocol (LMP) = for Dense
        =20 Wavelength Division Multiplexing (DWDM) Optical
       =20  Line Systems
 
(Note that RFC4209 doesn't appear to = have been=20 announced, but it has been published any way.)
 
The charter page will be updated to reflect this soon.

Many = thanks=20 to everyone involved.

Adrian
------=_NextPart_000_076D_01C5DBB0.41536A80-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 28 Oct 2005 10:03:54 +0000 Thread-Topic: Two Drafts for Resilience of Control Plane thread-index: AcXbpva8X72puaIDTr2d5rSGc74m/g== Content-Transfer-Encoding: 7bit Reply-To: "Kim Young Hwa" From: "Kim Young Hwa" To: Cc: Bcc: Subject: Two Drafts for Resilience of Control Plane Date: Fri, 28 Oct 2005 19:04:20 +0900 Comment: GQ19@|@ZEk=E?,18?x, OAM1b MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_92B4_01C5DBF2.66A6C060" Content-Class: urn:content-classes:message This is a multi-part message in MIME format. ------=_NextPart_000_92B4_01C5DBF2.66A6C060 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: base64 ------=_NextPart_000_92B4_01C5DBF2.66A6C060 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: base64 PERJViBpZD1tc2dib2R5IHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBTeXN0 ZW0iPg0KPERJVj5EZWFyIGFsbCw8L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPkkgcG9z dGVkIHR3byBkcmFmdHMgZm9yIHRoZSByZXNpbGllbmNlIG9mIGNvbnRyb2wgcGxhbmUuPC9ESVY+ DQo8RElWPk9uZSBpcyBmb3IgcmVxdWlyZW1lbnRzIG9mIHRoZSByZXNpbGllbmNlIG9mIGNvbnRy b2wgcGxhbmUsIHRoZSBvdGhlciBpcyBmb3IgYSBwcm90b2NvbCBzcGVjaWZpY2F0aW9uIGFzIGEg c29sdXRpb24gb2YgdGhhdCAuPC9ESVY+DQo8RElWPlRoZXNlIGFyZSBub3cgYXZhaWxhYmxlIGF0 OjwvRElWPg0KPERJVj48QSBocmVmPSJodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC1raW0tY2NhbXAtY3ByLXJlcXRzLTAxLnR4dCIgdGFyZ2V0PV9ibGFuaz5odHRwOi8v d3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1raW0tY2NhbXAtY3ByLXJlcXRzLTAx LnR4dDwvQT48L0RJVj4NCjxESVY+PEEgaHJlZj0iaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5l dC1kcmFmdHMvZHJhZnQta2ltLWNjYW1wLWFjY3AtcHJvdG9jb2wtMDAudHh0IiB0YXJnZXQ9X2Js YW5rPmh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWtpbS1jY2FtcC1h Y2NwLXByb3RvY29sLTAwLnR4dDwvQT48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPkkg d2FudCB5b3VyIGNvbW1lbnRzLjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+UmVnYXJk czwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+WW91bmcuPC9ESVY+DQo8RElWPiZuYnNw OzwvRElWPg0KPERJVj49PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT08QlI+WW91 bmctSHdhIEtpbTxCUj5QcmluY2lwYWwgTWVtYmVyIC8gUGguRDxCUj5CY04gUmVzZWFyY2ggRGl2 aXNpb24sIEVUUkk8QlI+VGVsOiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyArODItNDItODYwLTU4 MTk8QlI+RmF4OiZuYnNwOyZuYnNwOyZuYnNwOyArODItNDItODYwLTU0NDA8QlI+ZS1tYWlsOiA8 QSBocmVmPSJtYWlsdG86eWh3a2ltQGV0cmkucmUua3IiPnlod2tpbUBldHJpLnJlLmtyPC9BPjxC Uj49PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT08L0RJVj48L0RJVj48aW1nIHN0 eWxlPSJkaXNwbGF5Om5vbmUiIHdpZHRoPTAgaGVpZ2h0PTAgc3JjPSJodHRwOi8vdW1haWwuZXRy aS5yZS5rci9FeHRlcm5hbF9SZWFkQ2hlY2suYXNweD9lbWFpbD1jY2FtcEBvcHMuaWV0Zi5vcmcm bmFtZT1jY2FtcCU0MG9wcy5pZXRmLm9yZyZmcm9tZW1haWw9eWh3a2ltQGV0cmkucmUua3ImbWVz c2FnZWlkPSUzQzg2MzBhNmRiLTBjMzEtNDlhYi1hNzk4LTEzYjBkZGEwNDU1M0BldHJpLnJlLmty JTNFIj4= ------=_NextPart_000_92B4_01C5DBF2.66A6C060-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 28 Oct 2005 00:39:57 +0000 To: IETF-Announce From: The IESG Subject: Last Call: 'Node ID based RSVP Hello: A Clarification Statement' to BCP Reply-to: iesg@ietf.org CC: Message-Id: Date: Thu, 27 Oct 2005 20:39:37 -0400 The IESG has received a request from the Common Control and Measurement Plane WG to consider the following document: - 'Node ID based RSVP Hello: A Clarification Statement ' as a BCP 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 2005-11-25. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rsvp-node-id-based-hello-02.txt Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 28 Oct 2005 00:30:16 +0000 Message-Id: <200510280023.j9S0NBL21587@boreas.isi.edu> To: ietf-announce@ietf.org Subject: RFC 4208 on Generalized Multiprotocol Label Switching (GMPLS) User-Network Interface (UNI): Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Support for the Overlay Model Cc: rfc-editor@rfc-editor.org, ccamp@ops.ietf.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Thu, 27 Oct 2005 17:23:11 -0700 --NextPart A new Request for Comments is now available in online RFC libraries. RFC 4208 Title: Generalized Multiprotocol Label Switching (GMPLS) User-Network Interface (UNI): Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Support for the Overlay Model Author(s): G. Swallow, J. Drake, H. Ishimatsu, Y. Rekhter Status: Standards Track Date: October 2005 Mailbox: swallow@cisco.com, John.E.Drake2@boeing.com, hirokazu.ishimatsu@g1m.jp, yakov@juniper.net Pages: 13 Characters: 28693 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-ccamp-gmpls-overlay-05.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc4208.txt Generalized Multiprotocol Label Switching (GMPLS) defines both routing and signaling protocols for the creation of Label Switched Paths (LSPs) in various switching technologies. These protocols can be used to support a number of deployment scenarios. This memo addresses the application of GMPLS to the overlay model. This document is a product of the Common Control and Measurement Plane Working Group of the IETF. This is now a Proposed Standard Protocol. 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 ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <051027172201.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc4208 --OtherAccess Content-Type: Message/External-body; name="rfc4208.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <051027172201.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 28 Oct 2005 00:23:32 +0000 Message-Id: <200510280021.j9S0LAL20987@boreas.isi.edu> To: ietf-announce@ietf.org Subject: RFC 4207 on Synchronous Optical Network (SONET)/Synchronous Digital Hierarchy (SDH) Encoding for Link Management Protocol (LMP) Test Messages Cc: rfc-editor@rfc-editor.org, ccamp@ops.ietf.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Thu, 27 Oct 2005 17:21:10 -0700 --NextPart A new Request for Comments is now available in online RFC libraries. RFC 4207 Title: Synchronous Optical Network (SONET)/Synchronous Digital Hierarchy (SDH) Encoding for Link Management Protocol (LMP) Test Messages Author(s): J. Lang, D. Papadimitriou Status: Standards Track Date: October 2005 Mailbox: jplang@ieee.org, dimitri.papadimitriou@alcatel.be Pages: 15 Characters: 29390 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-ccamp-lmp-test-sonet-sdh-04.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc4207.txt This document details the Synchronous Optical Network (SONET)/Synchronous Digital Hierarchy (SDH) technology-specific information needed when sending Link Management Protocol (LMP) test messages. This document is a product of the Common Control and Measurement Plane Working Group of the IETF. This is now a Proposed Standard Protocol. 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 ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <051027171637.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc4207 --OtherAccess Content-Type: Message/External-body; name="rfc4207.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <051027171637.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 28 Oct 2005 00:18:51 +0000 Message-Id: <200510280013.j9S0DBL17392@boreas.isi.edu> To: ietf-announce@ietf.org Subject: RFC 4204 on Link Management Protocol (LMP) Cc: rfc-editor@rfc-editor.org, ccamp@ops.ietf.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Thu, 27 Oct 2005 17:13:11 -0700 --NextPart A new Request for Comments is now available in online RFC libraries. RFC 4204 Title: Link Management Protocol (LMP) Author(s): J. Lang, Ed. Status: Standards Track Date: October 2005 Mailbox: jplang@ieee.org Pages: 86 Characters: 186515 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-ccamp-lmp-10.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc4204.txt For scalability purposes, multiple data links can be combined to form a single traffic engineering (TE) link. Furthermore, the management of TE links is not restricted to in-band messaging, but instead can be done using out-of-band techniques. This document specifies a link management protocol (LMP) that runs between a pair of nodes and is used to manage TE links. Specifically, LMP will be used to maintain control channel connectivity, verify the physical connectivity of the data links, correlate the link property information, suppress downstream alarms, and localize link failures for protection/restoration purposes in multiple kinds of networks. This document is a product of the Common Control and Measurement Plane Working Group of the IETF. This is now a Proposed Standard Protocol. 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 ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <051027171200.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc4204 --OtherAccess Content-Type: Message/External-body; name="rfc4204.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <051027171200.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 28 Oct 2005 00:13:53 +0000 Message-Id: <200510280011.j9S0BsL17198@boreas.isi.edu> To: ietf-announce@ietf.org Subject: RFC 4203 on OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS) Cc: rfc-editor@rfc-editor.org, ccamp@ops.ietf.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Thu, 27 Oct 2005 17:11:54 -0700 --NextPart A new Request for Comments is now available in online RFC libraries. RFC 4203 Title: OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS) Author(s): K. Kompella, Ed., Y. Rekhter, Ed. Status: Standards Track Date: October 2005 Mailbox: kireeti@juniper.net, yakov@juniper.net Pages: 11 Characters: 23130 Updates: 3630 I-D Tag: draft-ietf-ccamp-ospf-gmpls-extensions-12.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc4203.txt This document specifies encoding of extensions to the OSPF routing protocol in support of Generalized Multi-Protocol Label Switching (GMPLS). This document is a product of the Common Control and Measurement Plane Working Group of the IETF. This is now a Proposed Standard Protocol. 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 ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <051027171050.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc4203 --OtherAccess Content-Type: Message/External-body; name="rfc4203.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <051027171050.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 28 Oct 2005 00:12:23 +0000 Message-Id: <200510280010.j9S0AWL16553@boreas.isi.edu> To: ietf-announce@ietf.org Subject: RFC 4202 on Routing Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS) Cc: rfc-editor@rfc-editor.org, ccamp@ops.ietf.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Thu, 27 Oct 2005 17:10:32 -0700 --NextPart A new Request for Comments is now available in online RFC libraries. RFC 4202 Title: Routing Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS) Author(s): K. Kompella, Ed., Y. Rekhter, Ed. Status: Standards Track Date: October 2005 Mailbox: kireeti@juniper.net, yakov@juniper.net Pages: 27 Characters: 57333 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-ccamp-gmpls-routing-09.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc4202.txt This document specifies routing extensions in support of carrying link state information for Generalized Multi-Protocol Label Switching (GMPLS). This document enhances the routing extensions required to support MPLS Traffic Engineering (TE). This document is a product of the Common Control and Measurement Plane Working Group of the IETF. This is now a Proposed Standard Protocol. 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 ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <051027170924.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc4202 --OtherAccess Content-Type: Message/External-body; name="rfc4202.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <051027170924.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 27 Oct 2005 22:54:19 +0000 Date: Thu, 27 Oct 2005 15:52:40 -0700 From: Alex Zinin Reply-To: Alex Zinin Message-ID: <15410687771.20051027155240@psg.com> To: "Adrian Farrel" CC: ccamp@ops.ietf.org, "Bill Fenner" , "'Kireeti Kompella'" Subject: Re: draft-ietf-ccamp-rsvp-node-id-based-hello-02.txt now back with AD MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Adrian, Just requested LC for it, extending it by 2 weeks b/c of the IETF meeting. -- Alex http://www.psg.com/~zinin Friday, September 23, 2005, 5:29:24 AM, Adrian Farrel wrote: > Hi Alex, > We held a further WG last call on this I-D after updating it to Proposed > Standard as you requested. > No-one objected to this change, so the I-D is now back with you for > approval. > Thanks, > Adrian > ----- Original Message ----- > From: "Adrian Farrel" > To: > Sent: Wednesday, September 07, 2005 9:48 PM > Subject: Short further last call on > draft-ietf-ccamp-rsvp-node-id-based-hello-02.txt >> Hi, >> >> Alex has reviewed this I-D as AD and says it is fine, but he thinks we >> should take it down the standards track as Proposed Standard not BCP as > it >> was previously marked. >> >> This revision changes: >> - proposed status >> - IPR boilerplate >> - IANA clause to be a little more (about 10 words) detailed >> >> Since we have changed the proposed status, we need to check back with > you >> guys. >> >> Let's have a two week last call on this change. >> >> If you do spot other issues as you go, then I guess we can handle them >> too. >> >> Last call will end 12 noon GMT on Thursday 22nd September. >> >> Thanks, >> Adrian >> >> >> ----- Original Message ----- >> From: >> To: >> Cc: >> Sent: Wednesday, September 07, 2005 8:50 PM >> Subject: I-D ACTION:draft-ietf-ccamp-rsvp-node-id-based-hello-02.txt >> >> >> > A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> > This draft is a work item of the Common Control and Measurement Plane >> Working Group of the IETF. >> > >> > Title : Node ID based RSVP Hello: A Clarification Statement >> > Author(s) : Z. Ali, et al. >> > Filename : draft-ietf-ccamp-rsvp-node-id-based-hello-02.txt >> > Pages : 7 >> > Date : 2005-9-7 >> > >> > Use of Node-ID based RSVP Hello messages is implied in a number of >> > cases, e.g., when data and control plan are separated, when TE > links >> > are unnumbered. Furthermore, when link level failure detection is >> > performed by some means other than exchanging RSVP Hello messages, >> > use of Node-ID based Hello session is optimal for detecting > signaling >> > adjacency failure for Resource reSerVation Protocol-Traffic >> > Engineering (RSVP-TE). Nonetheless, this implied behavior is > unclear >> > and this document formalizes use of Node-ID based RSVP Hello > session >> > as a best current practice (BCP) in some scenarios. The procedure >> > described in this document applies to both Multi-Protocol Label >> > Switching (MPLS) and Generalized MPLS (GMPLS) capable nodes. >> > >> > A URL for this Internet-Draft is: >> > >> > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rsvp-node-id-based-hello-02.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-rsvp-node-id-based-hello-02.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-rsvp-node-id-based-hello-02.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. >> > >> >> >> ------------------------------------------------------------------------ > -- >> ------ >> >> >> > _______________________________________________ >> > I-D-Announce mailing list >> > I-D-Announce@ietf.org >> > https://www1.ietf.org/mailman/listinfo/i-d-announce >> > >> >> >> >> Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 27 Oct 2005 17:41:36 +0000 Message-ID: <436110D3.6070207@psg.com> Date: Thu, 27 Oct 2005 19:39:31 +0200 From: dimitri papadimitriou Reply-To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.11) Gecko/20050728 MIME-Version: 1.0 To: "Shiba, Sidney" CC: dimitri.papadimitriou@alcatel.be, Adrian Farrel , richard.rabbat@us.fujitsu.com, ccamp@ops.ietf.org Subject: Re: comments on draft-shiba-ccamp-gmpls-lambda-labels-00.txt Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit shiba Shiba, Sidney wrote: [snip] >>>>>Another question might be: >>>>> >>>>> If I want to signal a path with wavelength constraints what >>>>> information do I need to include in the signaling message? >>>> >>>>shouldn't you ask the question, what's not workable with >>>>the present solution we have at hand in RFC3473 ? >>>> >>>>>I'd suggest that when we started on GMPLS, we were >>>>>enthusiastic about transparent optical networks, but we were >>>>>not properly focusing wavelength constraints because lambda- >>>>>switching PXCs didn't take off. >>>>> >>>>>Therefore we didn't examine the requirements for wavelength >>>>>constraints in routing and signaling. The authors of this I-D >>>>>are claiming new hardware requirements for the same function. >>>> >>>>adrian, i am not sure to understand ... hence, i would like >>>>to know from authors how the following cornerstone problem has >>>>been solved >>>> >>>>1. either the network is pre-engineered and you don't need to >>>>take care about any spectral routing specifics for traffic >>>>engineering purposes >> >>>[Sidney] In most of the cases, the network is pre-engineered using >>>spectral data, which will require a mapping effort. Of course, this >>>is feasable but we are proposing an approach that does not require >>>mapping effort when possible. >> >>would it be possible that you provide with a real estimate of >>the effort required for such mapping - i did it and it just >>requires to have a single/common profile per wavelength/color >>that you can use based on the received label value index (in >>the pre-engineered case there properties are known) > > [Sidney] An equipment that integrates an optical switch and mux/demux > can't use port mapping as the optical signal transmitted/received is > a waveband. As an analogy, the optical signal transmitted/received by > a SONET equipment is OCn and it is mux/demux internally to individual > STS-nC facilities. > > For the case of these new technology, the wavelength/frequency (nominal) > value is used to identify the facilities. but then we are in agreement there is no added value in this specific case for having such LSC value space - is my deduction from your reply correct ? >>>>2. or the network is not pre-engineered and i would like to >>>>know if the specifics of analog transmission/switching have been >>>>addressed such as to be compatible with the constraint-based routing >>>>mechanisms used today while keeping a low blocking probability >>> >>>[Sidney] As I said previously, we might need to increase the scope >>>of the draft to include wavelength availability information for the >>>routing in order to keep low the blocking probability. >> >>yes but this is where all complexity lies, as you don't know >>about the routing/selection of the wavelenght you are creating a >>closed loop such that your network will convergence problems; the >>major issue with lambda switching is that locality principle is not >>preserved, setting up a path in a non pre-engineered network implies >>that a reservation on a link can have impact on other link along the >>path but even on links that are not followed by that - > > [Sidney] You touched a very important point. What I propose is to > extend the scope of this discussion to include the wavelength availability > as LSA routing information in order to allow path computation to take > into account wavelength continuity constraint. For scalability the following > structure could be used: the issue here is the coupling between the spectral information to the TE routing advertisement, as the former does not respect any locality principle a given event may create instability in your TEDB (in fact it may never converge again) the reason is that lighting up a certain path is not only disabling the lambda on the link where used but may also disable usage of certain frequencies on links that are not traversed by this LSC LSP; the latter can subsequently enable other wavelength(s) that were previously not possible ... hence, you can reach state where you would be oscillating when there is no appropriate pre-engineering of the network > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Start Frequency | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Frequency spacing | Number of Frequencies | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Frequency Availability Bitmap | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Frequency Availability Bitmap (cont) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > - Start Frequency (32-bit) - this attribute indicates the first > frequency identified by the least significant bit in the Frequency > Availability bitmap field. IEEE Floating point value. > - Frequency Spacing (20-bit) - this attribute indicates the spacing > (in MHz) between adjacent frequencies. > - Number of Frequencies (12-bit) - this attribute indicates the number > of frequencies that is encoded in the Frequency Availability Bitmap > field. > - Frequency Availability Bitmap (variable) - This variable length > attribute is a bitmap structure where each bit indicates if a frequency > is available or not. When set to 0, the frequency is available and when > set to 1 it indicates that the frequency is already in use. The least > significant bit (LSB) identifies the start frequency. The remaining bits > indicate the subsequent frequencies in decrement of spacing. For example, > if bit0 = 195.70, bit1 = 195.60, bit2 = 195.50, and so on for a spacing > of 100 GHz. Each 32-bit word can encode the availability of 32 wavelengths. > As an example, a 40 wavelength capable system, 2 x 32-bit data structure > is necessary, where bit40 - bit63 are padding bits. the issue is not (only) about the representation (note that there are representation that are more efficient (it terms of encoding) than others) the issue is about feasibility, there is another specific issue about the amount of information that would need to be flooded but more importantly - the homogeneity - you seem to assume that spacing/and other properties are homogeneously distributed but this is not necessarily the case; hence how a given system would be able to process information of other systems for which it is not capable to process the specifics Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 27 Oct 2005 17:04:12 +0000 Message-ID: <4361083E.8010307@psg.com> Date: Thu, 27 Oct 2005 19:02:54 +0200 From: dimitri papadimitriou Reply-To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.11) Gecko/20050728 MIME-Version: 1.0 To: "Shiba, Sidney" CC: dimitri.papadimitriou@alcatel.be, Adrian Farrel , richard.rabbat@us.fujitsu.com, ccamp@ops.ietf.org Subject: Re: comments on draft-shiba-ccamp-gmpls-lambda-labels-00.txt Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit shiba - see inline for some additional hints: >>Shiba, Sidney wrote: >> >>>Adrian, Dimitri, >>> >>>Thanks for reviewing these I-D. >>> >>>Wavelength continuity constraint does require the use of semanticful >>>label whether it is spectral or index. >> >>=> see my reply to adrian on this specific point >> >>>I agree with Dimitri that the >>>wavelength indexing requires document updating each time a new >>>spectrum is introduced. >> >>=> indeed and in addition it requires updating the already >>signaled path >> >>>The use of spectral label provides self maintainance, i.e., >>>no need to update any document and the use of the nominal value >>>provides a common semantic ground. >> >>=> what do you mean by self-maintenance - would you provide a >>bit more detail > > [Sidney]What I've meant here was that it was not necessary to > update any document when new wavelengths are inventoried. In the > case of indexing approach, it would require the wavelength indexing > document to be updated with implementation impacts. > > In the case, the nominal value is used, there is no need for > documentation update. ok - what you mean here is that you are going to make use of the already defined C-Type 2 - what about the specific encoding of the value space ? >>=> now i have a more specific question before being light-up >>how do you know the frequency that you can support ? > > [Sidney] Some new technologies integrate optical switch and mux/demux > capabilities, which allows the equipment to know the spectrum it supports. indeed - but the question is what does happen if the "detected" values (during initialization) do not match the nominal values ? you don't initialize then ? >>if these differ from the nominal values how are you going to deal with these >>discrepancies ? > > [Sidney] These new technologies uses the nominal value as reference. We can say > that a lightpath wavelength is identified by its nominal value. If the equipment > is drifting from this nominal value, it is considered as a failure. ok - but if the deviation is such you have overlap - how the control plane is going to be able to detect such failure ? >>this said i am not necessarily sure that having to maintain the data plane >>specifics as part of the control plane is really helping >>operations (is this method not just duplicating complexity ?) > > [Sidney] The wavelength is WDM specific as much as the SUKLM label encoding > is for SONET. The wavelegth/frequency nominal value is used to identify the > facilities to cross-connect. there is an equivalence but there is also a major difference, the structure is invariant independently of the state of the network, with spectral value space you may have labels that become unavailable due to non-local usage of wavelength in the network hence, there is also no real coupling to the data plane more than knowing the type of interface and some generic capabilities >>>I'm not sure if the draft needs to be updated before the >>>face-to-face meeting or after all comments are collected. Please advise. >> >>=> suggest to keep discussion on - document update can be >>performed at a later stage thanks, - dimitri. >>>>-----Original Message----- >>>>From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On >>>>Behalf Of Adrian Farrel >>>>Sent: Thursday, October 27, 2005 4:45 AM >>>>To: dpapadimitriou@psg.com; dimitri.papadimitriou@alcatel.be; >>>>ccamp@ops.ietf.org >>>>Subject: Re: comments on >> >>draft-shiba-ccamp-gmpls-lambda-labels-00.txt >> >>>> >>>>Dimitri, >>>> >>>>Thanks for your work reviewing these recent I-Ds. It is >>>>really valuable >>>>and I'd welcome other people doing similar reviews. >>>> >>>> >>>> >>>>>there is a specific point to be clarified in this document: >>>>> >>>>>semanticless vs semanticful label (even here there is a distinction >>>>>between spectral vs indexes i.e. using the wavelength index) >>>>> >>>>>domain-wide vs link local significant label >>>> >>>>Without being too picky, I think all labels are semanticful >>>>otherwise, we >>>>would not know what resource they refered to. >>>> >>>>So the point reduces to whether the scope of the semantics >>>>are link-local >>>>or wider. >>>> >>>> >>>> >>>>>so, the comparison from this perspective with TDM labels is >>>> >>>>difficult to >>>> >>>> >>>>>parse, the latter is semanticful but link local >>>>> >>>>>now, i don't specifically see what has changed the late 90's, early >>>>>y2k's, to have a change in the wavelength label definition; >>>> >>>>This is the question I would like to get to the bottom of. In >>>>other words: >>>>do we need this function? >>>> >>>>It seems to me that the question being asked is this: >>>> >>>> If I want to compute a path that has some form of wavelength >>>> constraints, what information do I need access to? >>>> >>>>Another question might be: >>>> >>>> If I want to signal a path with wavelength constraints what >>>> information do I need to include in the signaling message? >>>> >>>> >>>>I'd suggest that when we started on GMPLS, we were >> >>enthusiastic about >> >>>>transparent optical networks, but we were not properly >>>>focusing wavelength >>>>constraints because lambda-switching PXCs didn't take off. >>>>Therefore we >>>>didn't examine the requirements for wavelength constraints in >>>>routing and >>>>signaling. The authors of this I-D are claiming new hardware >>>>requirements >>>>for the same function. >>>> >>>> >>>> >>>>>there are >>>>>several solution possible >>>>> >>>>>- absolute values: the freq. of the wavelength: difficult to adopt >>>>>because referenced values are nominal and knowing all interactions >>>>>between wavelengths this knowledge is at the end of little >> >>practical >> >>>>>usage; (introduces implicit ordering) >>>>> >>>>>- indexed values: the # of the wavelength: it does not >> >>provide for a >> >>>>>future proof label space for inst. in case new frequencies >>>> >>>>are inserted >>>> >>>> >>>>>in the grid (introduces explicit ordering) >>>>> >>>>>- diff. values e.g. freq spacing starting from a reference >>>> >>>>value: pauses >>>> >>>> >>>>>the question of the reference value and does suffer from the former >>>>>issue (introduces implicit ordering) >>>>> >>>>>- the solution available today - cumbersome in some control plane >>>>>operations (e.g. label set translation) and not easy to >>>> >>>>troubleshoot but >>>> >>>> >>>>>independent of any physical consideration (spectral), scale to any >>>>>number of wavelength per fiber, does not introduce any >> >>ordering, the >> >>>>>most flexible (since allowing each system to maintain its specific >>>>>control operations) and the less constraining since maintaining the >>>>>control plane operations independent of any data plane specifics >>>>> >>>>> >>>> >>>>>> >>>ambda-labels >>>-00.txt> >>> >>>. >>> >> > > . > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 27 Oct 2005 16:23:16 +0000 Message-ID: <4360FE9E.7080103@psg.com> Date: Thu, 27 Oct 2005 18:21:50 +0200 From: dimitri papadimitriou Reply-To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.11) Gecko/20050728 MIME-Version: 1.0 To: "Shiba, Sidney" CC: dimitri.papadimitriou@alcatel.be, Adrian Farrel , richard.rabbat@us.fujitsu.com, ccamp@ops.ietf.org Subject: Re: comments on draft-shiba-ccamp-gmpls-lambda-labels-00.txt Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit shiba, see inline Shiba, Sidney wrote: > Dimitri, > > See inline > > >>-----Original Message----- >>From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On >>Behalf Of dimitri papadimitriou >>Sent: Thursday, October 27, 2005 8:16 AM >>To: Adrian Farrel >>Cc: dimitri.papadimitriou@alcatel.be; ccamp@ops.ietf.org >>Subject: Re: comments on draft-shiba-ccamp-gmpls-lambda-labels-00.txt >> >> >>adrian - see in-line >> >>Adrian Farrel wrote: >> >> >>>Dimitri, >>> >>>Thanks for your work reviewing these recent I-Ds. It is >> >>really valuable >> >>>and I'd welcome other people doing similar reviews. >>> >>> >>> >>>>there is a specific point to be clarified in this document: >>>> >>>>semanticless vs semanticful label (even here there is a distinction >>>>between spectral vs indexes i.e. using the wavelength index) >>>> >>>>domain-wide vs link local significant label >>> >>> >>>Without being too picky, I think all labels are semanticful >> >>otherwise, we >> >>>would not know what resource they refered to. >> >>actually you have unstructured label space whose >>interpretation can only >>be done in the context of the link associated to this label >>exchange and >>if you have an additional level of indirection -> >>"semanticless" as the >>value in itself (with its associated link) does not tell you >>more about >>the resource to be used (its just equivalent to an index) you >>need for >>instance to perform initial LMP exchange to know the data >>plane resource >>correspondance >> >>but you have also structured label spaces like TDM whose >>interpretation >>can be done (together with the associated link) since they >>provide you >>with the exact timeslot position in the SONET/SDH >>multiplexing tree -> >>so the label value space carries a semantic > > [Sidney] The use of spectral label allows to provide a consistent > solution from network engineering tool to the circuit provisioning. > No need to translate wavelength (engineering tool) to local id (ERO) > and back to wavelength (NE). > > Note that this is not the main reason for the spectral label but > can be considered as extra that comes with this approach. would be helphul to know the main reason then ? >>hope this clarifies - >> >> >>>So the point reduces to whether the scope of the semantics >> >>are link-local >> >>>or wider. >> >>see above - the discussion is important, in TDM this has been done in >>order to avoid timeslot position/index exchange while the >>structure is >>perfectly know and invariant - hence, draw an analogy with >>LSC requires >>careful thought >> >> >>>>so, the comparison from this perspective with TDM labels is >> >>difficult to >> >>>>parse, the latter is semanticful but link local >>>> >>>>now, i don't specifically see what has changed the late 90's, early >>>>y2k's, to have a change in the wavelength label definition; >>> >>>This is the question I would like to get to the bottom of. >> >>In other words: >> >>>do we need this function? >>> >>>It seems to me that the question being asked is this: >>> >>> If I want to compute a path that has some form of wavelength >>> constraints, what information do I need access to? >> >>you have at this level three type of constraints: spatial, >>spectral and link >> >>currently GMPLS for wavelegnth constraints works with source-driven >>spatial routing (constraint-based source-routing so implying both TE >>routing and signaling exchanges) and receiver-driven spectral routing >>(via the label set/acceptable label set mechanism so implying only >>signaling exchanges) > > [Sidney]We may need to increase the scope of this draft and add wavelength > availability for allowing to shift from the spectral routing to spatial > routing for optical networks. This approach would take care of wavelength > blocking issue for non pre-engineered circuits. well this is why i am asking the question, soon or later in order to benefit from these spectral labels you are going to come up with TE routing information exchange - before jumping there i would suggest that you take a look at the scaling properties of such approach >>>Another question might be: >>> >>> If I want to signal a path with wavelength constraints what >>> information do I need to include in the signaling message? >> >>shouldn't you ask the question, what's not workable with the present >>solution we have at hand in RFC3473 ? >> >> >>>I'd suggest that when we started on GMPLS, we were >> >>enthusiastic about >> >>>transparent optical networks, but we were not properly >> >>focusing wavelength >> >>>constraints because lambda-switching PXCs didn't take off. >> >>Therefore we >> >>>didn't examine the requirements for wavelength constraints >> >>in routing and >> >>>signaling. The authors of this I-D are claiming new >> >>hardware requirements >> >>>for the same function. >> >>adrian, i am not sure to understand ... hence, i would like >>to know from >>authors how the following cornerstone problem has been solved >> >>1. either the network is pre-engineered and you don't need to >>take care >>about any spectral routing specifics for traffic engineering purposes >> > > [Sidney] In most of the cases, the network is pre-engineered using > spectral data, which will require a mapping effort. Of course, this > is feasable but we are proposing an approach that does not require > mapping effort when possible. would it be possible that you provide with a real estimate of the effort required for such mapping - i did it and it just requires to have a single/common profile per wavelength/color that you can use based on the received label value index (in the pre-engineered case there properties are known) >>2. or the network is not pre-engineered and i would like to >>know if the >>specifics of analog transmission/switching have been >>addressed such as >>to be compatible with the constraint-based routing mechanisms >>used today >>while keeping a low blocking probability > > [Sidney] As I said previously, we might need to increase the scope > of the draft to include wavelength availability information for the > routing in order to keep low the blocking probability. yes but this is where all complexity lies, as you don't know about the routing/selection of the wavelenght you are creating a closed loop such that your network will convergence problems; the major issue with lambda switching is that locality principle is not preserved, setting up a path in a non pre-engineered network implies that a reservation on a link can have impact on other link along the path but even on links that are not followed by that - >>>>there are >>>>several solution possible >>>> >>>>- absolute values: the freq. of the wavelength: difficult to adopt >>>>because referenced values are nominal and knowing all interactions >>>>between wavelengths this knowledge is at the end of little practical >>>>usage; (introduces implicit ordering) >>>> >>>>- indexed values: the # of the wavelength: it does not provide for a >>>>future proof label space for inst. in case new frequencies >> >>are inserted >> >>>>in the grid (introduces explicit ordering) >>>> >>>>- diff. values e.g. freq spacing starting from a reference >> >>value: pauses >> >>>>the question of the reference value and does suffer from the former >>>>issue (introduces implicit ordering) >>>> >>>>- the solution available today - cumbersome in some control plane >>>>operations (e.g. label set translation) and not easy to >> >>troubleshoot but >> >>>>independent of any physical consideration (spectral), scale to any >>>>number of wavelength per fiber, does not introduce any ordering, the >>>>most flexible (since allowing each system to maintain its specific >>>>control operations) and the less constraining since maintaining the >>>>control plane operations independent of any data plane specifics >>>> >>>> >>> >>> >> > ambda-labels > >>-00.txt> >> >> >> >>. >> > > > . > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 27 Oct 2005 16:12:30 +0000 Message-ID: <4360FC18.8090906@psg.com> Date: Thu, 27 Oct 2005 18:11:04 +0200 From: dimitri papadimitriou Reply-To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.11) Gecko/20050728 MIME-Version: 1.0 To: "Shiba, Sidney" CC: Adrian Farrel , dimitri.papadimitriou@alcatel.be, richard.rabbat@us.fujitsu.com, ccamp@ops.ietf.org Subject: Re: comments on draft-shiba-ccamp-gmpls-lambda-labels-00.txt Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit shiba Shiba, Sidney wrote: > Adrian, Dimitri, > > Thanks for reviewing these I-D. > > Wavelength continuity constraint does require the use of semanticful > label whether it is spectral or index. => see my reply to adrian on this specific point > I agree with Dimitri that the > wavelength indexing requires document updating each time a new > spectrum is introduced. => indeed and in addition it requires updating the already signaled path > The use of spectral label provides self maintainance, i.e., no need to > update any document and the use of the nominal value provides a common > semantic ground. => what do you mean by self-maintenance - would you provide a bit more detail => now i have a more specific question before being light-up how do you know the frequency that you can support ? if these differ from the nominal values how are you going to deal with these discrepancies ? this said i am not necessarily sure that having to maintain the data plane specifics as part of the control plane is really helping operations (is this method not just duplicating complexity ?) > I'm not sure if the draft needs to be updated before the face-to-face > meeting or after all comments are collected. Please advise. => suggest to keep discussion on - document update can be performed at a later stage > Thanks, > > Sidney > > >>-----Original Message----- >>From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On >>Behalf Of Adrian Farrel >>Sent: Thursday, October 27, 2005 4:45 AM >>To: dpapadimitriou@psg.com; dimitri.papadimitriou@alcatel.be; >>ccamp@ops.ietf.org >>Subject: Re: comments on draft-shiba-ccamp-gmpls-lambda-labels-00.txt >> >> >>Dimitri, >> >>Thanks for your work reviewing these recent I-Ds. It is >>really valuable >>and I'd welcome other people doing similar reviews. >> >> >>>there is a specific point to be clarified in this document: >>> >>>semanticless vs semanticful label (even here there is a distinction >>>between spectral vs indexes i.e. using the wavelength index) >>> >>>domain-wide vs link local significant label >> >>Without being too picky, I think all labels are semanticful >>otherwise, we >>would not know what resource they refered to. >> >>So the point reduces to whether the scope of the semantics >>are link-local >>or wider. >> >> >>>so, the comparison from this perspective with TDM labels is >> >>difficult to >> >>>parse, the latter is semanticful but link local >>> >>>now, i don't specifically see what has changed the late 90's, early >>>y2k's, to have a change in the wavelength label definition; >> >>This is the question I would like to get to the bottom of. In >>other words: >>do we need this function? >> >>It seems to me that the question being asked is this: >> >> If I want to compute a path that has some form of wavelength >> constraints, what information do I need access to? >> >>Another question might be: >> >> If I want to signal a path with wavelength constraints what >> information do I need to include in the signaling message? >> >> >>I'd suggest that when we started on GMPLS, we were enthusiastic about >>transparent optical networks, but we were not properly >>focusing wavelength >>constraints because lambda-switching PXCs didn't take off. >>Therefore we >>didn't examine the requirements for wavelength constraints in >>routing and >>signaling. The authors of this I-D are claiming new hardware >>requirements >>for the same function. >> >> >>>there are >>>several solution possible >>> >>>- absolute values: the freq. of the wavelength: difficult to adopt >>>because referenced values are nominal and knowing all interactions >>>between wavelengths this knowledge is at the end of little practical >>>usage; (introduces implicit ordering) >>> >>>- indexed values: the # of the wavelength: it does not provide for a >>>future proof label space for inst. in case new frequencies >> >>are inserted >> >>>in the grid (introduces explicit ordering) >>> >>>- diff. values e.g. freq spacing starting from a reference >> >>value: pauses >> >>>the question of the reference value and does suffer from the former >>>issue (introduces implicit ordering) >>> >>>- the solution available today - cumbersome in some control plane >>>operations (e.g. label set translation) and not easy to >> >>troubleshoot but >> >>>independent of any physical consideration (spectral), scale to any >>>number of wavelength per fiber, does not introduce any ordering, the >>>most flexible (since allowing each system to maintain its specific >>>control operations) and the less constraining since maintaining the >>>control plane operations independent of any data plane specifics >>> >>> >> >> > ambda-labels > -00.txt> > > . > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 27 Oct 2005 15:18:41 +0000 Message-ID: <05ad01c5db08$63e65d30$de849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Bouncing I-D submissions Date: Thu, 27 Oct 2005 16:06:50 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi, I am in the (un)fortunate position of being cc'ed when many of your attempts to submit I-Ds are rejected by the Secretariat. The Secretariat has to maintain certain standards for I-Ds before they can publish them, and it is particularly hard work for them in the immediate run-up to an IETF meeting. You can help them and yourselves by checking that your submissions conform to the requirements by running the idnits script available at: http://ietf.levkowetz.com/tools/idnits/ Thanks, Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 27 Oct 2005 13:18:13 +0000 Message-ID: <4360D31D.2010809@psg.com> Date: Thu, 27 Oct 2005 15:16:13 +0200 From: dimitri papadimitriou Reply-To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.11) Gecko/20050728 MIME-Version: 1.0 To: Adrian Farrel CC: dimitri.papadimitriou@alcatel.be, ccamp@ops.ietf.org Subject: Re: comments on draft-shiba-ccamp-gmpls-lambda-labels-00.txt Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit adrian - see in-line Adrian Farrel wrote: > Dimitri, > > Thanks for your work reviewing these recent I-Ds. It is really valuable > and I'd welcome other people doing similar reviews. > > >>there is a specific point to be clarified in this document: >> >>semanticless vs semanticful label (even here there is a distinction >>between spectral vs indexes i.e. using the wavelength index) >> >>domain-wide vs link local significant label > > > Without being too picky, I think all labels are semanticful otherwise, we > would not know what resource they refered to. actually you have unstructured label space whose interpretation can only be done in the context of the link associated to this label exchange and if you have an additional level of indirection -> "semanticless" as the value in itself (with its associated link) does not tell you more about the resource to be used (its just equivalent to an index) you need for instance to perform initial LMP exchange to know the data plane resource correspondance but you have also structured label spaces like TDM whose interpretation can be done (together with the associated link) since they provide you with the exact timeslot position in the SONET/SDH multiplexing tree -> so the label value space carries a semantic hope this clarifies - > So the point reduces to whether the scope of the semantics are link-local > or wider. see above - the discussion is important, in TDM this has been done in order to avoid timeslot position/index exchange while the structure is perfectly know and invariant - hence, draw an analogy with LSC requires careful thought >>so, the comparison from this perspective with TDM labels is difficult to >>parse, the latter is semanticful but link local >> >>now, i don't specifically see what has changed the late 90's, early >>y2k's, to have a change in the wavelength label definition; > > This is the question I would like to get to the bottom of. In other words: > do we need this function? > > It seems to me that the question being asked is this: > > If I want to compute a path that has some form of wavelength > constraints, what information do I need access to? you have at this level three type of constraints: spatial, spectral and link currently GMPLS for wavelegnth constraints works with source-driven spatial routing (constraint-based source-routing so implying both TE routing and signaling exchanges) and receiver-driven spectral routing (via the label set/acceptable label set mechanism so implying only signaling exchanges) > Another question might be: > > If I want to signal a path with wavelength constraints what > information do I need to include in the signaling message? shouldn't you ask the question, what's not workable with the present solution we have at hand in RFC3473 ? > I'd suggest that when we started on GMPLS, we were enthusiastic about > transparent optical networks, but we were not properly focusing wavelength > constraints because lambda-switching PXCs didn't take off. Therefore we > didn't examine the requirements for wavelength constraints in routing and > signaling. The authors of this I-D are claiming new hardware requirements > for the same function. adrian, i am not sure to understand ... hence, i would like to know from authors how the following cornerstone problem has been solved 1. either the network is pre-engineered and you don't need to take care about any spectral routing specifics for traffic engineering purposes 2. or the network is not pre-engineered and i would like to know if the specifics of analog transmission/switching have been addressed such as to be compatible with the constraint-based routing mechanisms used today while keeping a low blocking probability >>there are >>several solution possible >> >>- absolute values: the freq. of the wavelength: difficult to adopt >>because referenced values are nominal and knowing all interactions >>between wavelengths this knowledge is at the end of little practical >>usage; (introduces implicit ordering) >> >>- indexed values: the # of the wavelength: it does not provide for a >>future proof label space for inst. in case new frequencies are inserted >>in the grid (introduces explicit ordering) >> >>- diff. values e.g. freq spacing starting from a reference value: pauses >>the question of the reference value and does suffer from the former >>issue (introduces implicit ordering) >> >>- the solution available today - cumbersome in some control plane >>operations (e.g. label set translation) and not easy to troubleshoot but >>independent of any physical consideration (spectral), scale to any >>number of wavelength per fiber, does not introduce any ordering, the >>most flexible (since allowing each system to maintain its specific >>control operations) and the less constraining since maintaining the >>control plane operations independent of any data plane specifics >> >> > > -00.txt> > > > > . > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 27 Oct 2005 10:24:06 +0000 Message-ID: <050d01c5dadf$374d6b70$de849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: , , Subject: Re: comments on draft-shiba-ccamp-gmpls-lambda-labels-00.txt Date: Thu, 27 Oct 2005 10:44:52 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Dimitri, Thanks for your work reviewing these recent I-Ds. It is really valuable and I'd welcome other people doing similar reviews. > there is a specific point to be clarified in this document: > > semanticless vs semanticful label (even here there is a distinction > between spectral vs indexes i.e. using the wavelength index) > > domain-wide vs link local significant label Without being too picky, I think all labels are semanticful otherwise, we would not know what resource they refered to. So the point reduces to whether the scope of the semantics are link-local or wider. > so, the comparison from this perspective with TDM labels is difficult to > parse, the latter is semanticful but link local > > now, i don't specifically see what has changed the late 90's, early > y2k's, to have a change in the wavelength label definition; This is the question I would like to get to the bottom of. In other words: do we need this function? It seems to me that the question being asked is this: If I want to compute a path that has some form of wavelength constraints, what information do I need access to? Another question might be: If I want to signal a path with wavelength constraints what information do I need to include in the signaling message? I'd suggest that when we started on GMPLS, we were enthusiastic about transparent optical networks, but we were not properly focusing wavelength constraints because lambda-switching PXCs didn't take off. Therefore we didn't examine the requirements for wavelength constraints in routing and signaling. The authors of this I-D are claiming new hardware requirements for the same function. > there are > several solution possible > > - absolute values: the freq. of the wavelength: difficult to adopt > because referenced values are nominal and knowing all interactions > between wavelengths this knowledge is at the end of little practical > usage; (introduces implicit ordering) > > - indexed values: the # of the wavelength: it does not provide for a > future proof label space for inst. in case new frequencies are inserted > in the grid (introduces explicit ordering) > > - diff. values e.g. freq spacing starting from a reference value: pauses > the question of the reference value and does suffer from the former > issue (introduces implicit ordering) > > - the solution available today - cumbersome in some control plane > operations (e.g. label set translation) and not easy to troubleshoot but > independent of any physical consideration (spectral), scale to any > number of wavelength per fiber, does not introduce any ordering, the > most flexible (since allowing each system to maintain its specific > control operations) and the less constraining since maintaining the > control plane operations independent of any data plane specifics > > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 27 Oct 2005 09:11:59 +0000 Message-ID: <43609999.8020709@psg.com> Date: Thu, 27 Oct 2005 11:10:49 +0200 From: dimitri papadimitriou Reply-To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be, dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be, dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.11) Gecko/20050728 MIME-Version: 1.0 To: ccamp@ops.ietf.org Subject: comments on draft-ietf-ccamp-gmpls-addressing-02.txt Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit hi - some comment on this document after first reading (note: text has improved since last version but some shaded sub-sections remain and i still find some sentences with ambiguous/dual interpretation but this would be normally to be tackled during the editorial review) Section 7.1.1 " 4. Outgoing TE link ID optionally followed by Component Interface ID subobject and/or one or two Label subobjects " applies for so called egress control so there no such "optional" follow-up object; these are present by definition - see also RFC 4003 that clarifies the procedures for the control of the label used on an output/downstream interface of the egress node of an LSP " There is no way to specify in the ERO whether a subobject is associated with the incoming or outgoing TE link. This is unfortunate because the address specified in a loose subobject is used as a target for the path computation, and there is a big difference for the path selection process whether the intention is to reach the target node over the specified link (the case of incoming TE link) or to reach the node over some other link, so that it would be possible to continue the path to its final destination over the specified link (the case of outgoing TE link). In the case where a subobject in an ERO is marked as a loose hop and identifies an interface, the subobject SHOULD include the address of the Incoming interface specifying the TE link in the data plane. " but by definition the latter applies (it is not a "SHOULD" its de-facto) so why is this indication needed ? - see RFC3209 section 4.3.4 + would you drop a line on ERO processing at region boundaries per LSP-HIER (Section 8.2) Section 8.2 " If the control plane interface is unnumbered, the RECOMMENDED value for the control plane address is the TE Router-ID. " what does "control plane interface is unnumbered" means ? btw i thought IP source/dest. address settings were discussed in section 5. - why re-discuss this here ? Section 9 is this section really dealing with usage of addressing in GMPLS nets ? Section 10 For this feature to be used, all LSRs in the network MUST advertise a 32-bit value that can be used to identify the LSR. In this document, this is referred to as the 32-bit LSR ID. The 32-bit LSR ID is the OSPFv3 router ID [RFC2740] or the ISIS IPv4 TE Router ID [RFC3784]. Note that these are different from TE router ID (See Section 3). => in section 10 a new definition falls 'LSR ID'; i found the text confusing; it is different from the TE Router ID but it is named the TE Router ID; it is the Router ID of OSPFv3 and not sure it is the Traffic Engineering router ID TLV is TLV type 134 of IS-IS - last sentence seems to say the contrary Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 27 Oct 2005 08:17:48 +0000 Message-ID: <43608C91.8070109@psg.com> Date: Thu, 27 Oct 2005 10:15:13 +0200 From: dimitri papadimitriou Reply-To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be, dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.11) Gecko/20050728 MIME-Version: 1.0 To: "ccamp@ops.ietf.org" Subject: comments on draft-shiba-ccamp-gmpls-lambda-labels-00.txt Content-Type: multipart/mixed; boundary="------------010409090105030700040000" This is a multi-part message in MIME format. --------------010409090105030700040000 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit hi, there is a specific point to be clarified in this document: semanticless vs semanticful label (even here there is a distinction between spectral vs indexes i.e. using the wavelength index) domain-wide vs link local significant label so, the comparison from this perspective with TDM labels is difficult to parse, the latter is semanticful but link local now, i don't specifically see what has changed the late 90's, early y2k's, to have a change in the wavelength label definition; there are several solution possible - absolute values: the freq. of the wavelength: difficult to adopt because referenced values are nominal and knowing all interactions between wavelengths this knowledge is at the end of little practical usage; (introduces implicit ordering) - indexed values: the # of the wavelength: it does not provide for a future proof label space for inst. in case new frequencies are inserted in the grid (introduces explicit ordering) - diff. values e.g. freq spacing starting from a reference value: pauses the question of the reference value and does suffer from the former issue (introduces implicit ordering) - the solution available today - cumbersome in some control plane operations (e.g. label set translation) and not easy to troubleshoot but independent of any physical consideration (spectral), scale to any number of wavelength per fiber, does not introduce any ordering, the most flexible (since allowing each system to maintain its specific control operations) and the less constraining since maintaining the control plane operations independent of any data plane specifics --------------010409090105030700040000 Content-Type: text/plain; name="www.ietf.org/internet-drafts/draft-shiba-ccamp-gmpls-lambda-labels-00.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="www.ietf.org/internet-drafts/draft-shiba-ccamp-gmpls-lambda-labels-00.txt" CCAMP Working Group Sidney Shiba (Fujitsu) Internet Draft Richard Rabbat (Fujitsu) Updates: 3471 Proposed Category: Standards Track Expires: March 2006 September 2005 Generalized Labels of Lambda-Switching Capable Label Switching Routers (LSR)s draft-shiba-ccamp-gmpls-lambda-labels-00.doc.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119, reference [RFC2119]. Abstract Technology in the optical domain is constantly evolving and as a consequence new equipment providing lambda switching capability has been developed and is currently being deployed. [RFC3471] has defined that a wavelength label (section 3.2.1.1) "only has significance between two neighbors". However, in a network composed of a new Expires March 2006 [Page 1] Generalized Labels for LSC-Capable LSRs October 2005 generation of lambda switch-capable equipment, this document explains why the label should have global meaning similarly to the label defined for SONET/SDH technology (SUKLM format defined in [RFC3946]) and describes extensions to enable global meaning. This document is a companion to the Generalized Multi-Protocol Label Switching (GMPLS) signaling. It defines the Label Switching Capable (LSC) technology specific information needed when using GMPLS. Table of Contents 1. Introduction.....................................................2 1.1. Problem Description............................................2 2. Label Related Formats............................................4 2.1. Wavelength Labels..............................................4 2.2. Label Set Wavelength Subchannel................................4 2.3. RSVP-TE Extensions.............................................5 3. IANA Considerations..............................................5 4. Security Considerations..........................................5 5. Acknowledgements.................................................6 6. References.......................................................7 6.1. Normative References...........................................7 6.2. Informative Reference..........................................8 7. Copyright Statement.............................................10 8. Intellectual Property Statement.................................11 1. Introduction As described in [RFC3945], Generalized MPLS (GMPLS) extends MPLS from supporting only packet (Packet Switching Capable - PSC) interfaces and switching to also include support of four new classes of interfaces and switching: Layer-2 Switch Capable (L2SC), Time- Division Multiplex (TDM), Lambda Switch Capable (LSC) and Fiber- Switch Capable (FSC). A functional description of the extensions to MPLS signaling needed to support new classes of interfaces and switching is provided in [RFC3471]. 1.1. Problem Description This document presents details that are specific to the use of GMPLS with a new generation of Lambda Switch Capable (LSC) equipment as opposed to a the prior generation of LSC equipment composed of of Wavelength Division Multiplexing (WDM) + Photonic Cross Connect (PXC) combined system (shown below) that was originally considered at the time of writing of RFC 3471. Expires October 2005 [Page 2] Generalized Labels for LSC-Capable LSRs October 2005 Technologies such as Reconfigurable Optical Add/Drop Multiplex (ROADM) and Dynamic-OADM operate at the wavelength switching level. As such, the wavelength is important information that is necessary to successfully setup a wavelength LSP. _______ _______ _______ /|_|6 1|_|\ /|_|5 1|_|\ /|_|5 1|_|\ | |_|7 PXC 2|_| | WDM | |_|6 PXC 2|_| | WDM | |_|6 PXC 2|_| | WDM ===| |_|8 (1) 3|_| |=====| |_|7 (2) 3|_| |======| |_|7 (3) 3|_| |==== | |_|9 4|_| | | |_|8 4|_| | | |_|8 4|_| | \| |_______| |/ \| |_______| |/ \| |_______| |/ For technologies such as the ROADM and DOADM, the WDM port mapping does not provide sufficient information for selecting the required wavelength for an LSP. Here are four cases that highlight where it is important to have wavelength information available globally. 1. Label Set: A Label Set object may be used to limit the label choices of a downstream node (section 3.5 of RFC 3471). This Label Set object needs to carry one of the labels defined in section 3.2 of that same document, i.e. either port, wavelength label or waveband label. In order to be able to generate that wavelength information, it is important to have global dissemination of wavelength information. 2. Explicit Route Object/Record Route Object: Here as well, any meaningful information should be global, which implies the use of wavelength since a locally-significant label will have no meaning. 3. In SONET/SDH, one can think of the label with the set values of SUKLM bits as locally significant and set their values as a matter of policy to have global meaning. This would add undue burden on the operator to enforce policy. In addition, manual provisioning may lead to misconfiguration. 4. Finally, the values for the wavelengths need to be out of the same pool of values to have global meaning. Any representation of the lambdas needs to be the same on all nodes irrespective of the manufacturer. _______ _______ _______ | | | | | | WDM | LSC | WDM | LSC | WDM | LSC | WDM =======|1 2|=========|1 2|=========|1 2|======= | | | | | | |_______| |_______| |_______| Expires October 2005 [Page 3] Generalized Labels for LSC-Capable LSRs October 2005 The ITU-T frequency grid specified in [G.694.1] for Dense WDM (DWDM) and [G.694.2] for Coarse WDM (CWDM) are the labels that SHOULD be used by these LSC LSRs. 2. Label Related Formats To deal with the widening scope of MPLS into the optical and time domains, several new forms of "label" have been defined in [RFC3471]. This section contains clarifications for the Wavelength label and Label Set definition specific for LSC LSRs. 2.1. Wavelength Labels In section 3.2.1.1 of [RFC3471], a Wavelength label is defined to have significance between two neighbors, and the receiver may need to convert the received value into a value that has local significance. Equipment providing "true" lambda switching (LSC) uses multiple wavelengths controlled by a single control channel. In such case, the label indicates the wavelength to be used for the LSP. In order to allow global meaning, this document redefines the Wavelength label as being an IEEE floating point encoding of the wavelength. As an example of wavelength values, the reader is referred to [G.694.1] which lists the frequencies from the ITU-T DWDM frequency grid. The same can be done for CWDM technology by using the wavelength defined in [G.694.2]. The information carried in a Wavelength label is: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Label: 32 bits The label indicates the frequency value to be used. The value is IEEE Floating point encoded. This may be an ITU-T DWDM frequency. For convenience, Appendix 1 provides the list of IEEE Floating point values for the ITU-T DWDM frequency grid. 2.2. Label Set Wavelength Subchannel This document aligns with the general definition of Label Set in section 3.5 of [RFC3471]. However, it provides a clarification Expires October 2005 [Page 4] Generalized Labels for LSC-Capable LSRs October 2005 related to the subchannel value to be used by an LSC LSR. For this type of equipment the subchannel field SHOULD represent the Wavelength label (ITU-T DWDM frequency grid). 2.3. RSVP-TE Extensions In other to distinguish Wavelength label with local significance from the Wavelength label with global meaning, the latter SHOULD use the same format as the generalized label with the new C-Type (TBA). In the context of "true" lambda switching, the generalized label has the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | Class-Num (16)| C-Type (TBA) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ITU-T DWDM Frequency Grid Label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3. IANA Considerations IANA assigns values to RSVP protocol parameters. Within the current document an object is defined. This object contains a C-Type. This section defines the rules for the assignment of the related C-Type value. This section uses the terminology of BCP 26 "Guidelines for Writing an IANA Considerations Section in RFCs" [BCP26]. As per [RFC2205], C-Type is an 8-bit number that identifies the function of an object. All possible values except zero are available for assignment. The assignment of the C-Type value of the object defined in this document inherits C-Type from the Label object, i.e., object class number 16 [RFC3209]. The Wavelength Switching Label defined in this document has the following C-Type value to be assigned by IANA: o RSVP_LABEL (Class-Num = 16) - Wavelength Switching Label (C-Type = To Be Assigned) 4. Security Considerations Expires October 2005 [Page 5] Generalized Labels for LSC-Capable LSRs October 2005 There may be an argument that by giving the label global meaning, one would decrease security. The closest example of using global meaning is the label setting for SONET/SDH. By using a global meaning for its labels, SONET/SDH did not introduce any new security considerations. This serves as an indication that this document introduces no new security considerations to either [RFC3473] or [RFC3472]. GMPLS security is described in section 11 of [RFC3471] and refers to [RFC3209] for RSVP-TE and to [RFC3212] for CR-LDP. 5. Acknowledgements The authors would like to thank Adrian Farrel for his feedback and comments. Expires October 2005 [Page 6] Generalized Labels for LSC-Capable LSRs October 2005 6. References 6.1. Normative References [G.694.1] ITU-T Recommendation G.694.1, "Spectral grids for WDM applications: DWDM frequency grid", June 2002. [G.694.2] ITU-T Recommendation G.694.2, "Spectral grids for WDM applications: CWDM wavelength grid", December 2003. [IEEE754] "Standard for Binary Floating-Point Arithmetic", IEEE- 754, 1985. [RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) - Version 1 Functional Specification", RFC 2205, September 1997. [RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated Services", RFC 2210, September 1997. [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001. [RFC3212] Jamoussi, B., Andersson, L., Callon, R., Dantu, R., Wu, L., Doolan, P., Worster, T., Feldman, N., Fredette, A., Girish, M., Gray, E., Heinanen, J., Kilty, T., and A. Malis, "Constrained-Based LSP Setup using LDP", RFC 3212, January 2002. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels," BCP 14, IETF RFC 2119, March 1997. [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching (MPLS) Signaling Functional Description", RFC 3471, January 2003. [RFC3472] Ashwood-Smith, P. and L. Berger, "Generalized Multi- Protocol Label Switching (MPLS) Signaling - Constraint- based Routed Label Distribution Protocol (CR-LDP) Extensions", RFC 3472, January 2003. [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching (MPLS} Signaling - Resource ReserVation Protocol Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. Expires October 2005 [Page 7] Generalized Labels for LSC-Capable LSRs October 2005 [RFC3945] Mannie, E., Ed., "Generalized Multiprotocol Label Switching (GMPLS) Architecture", RFC 3945, October 2004. 6.2. Informative Reference [BCP26] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [RFC2026] Bradner, S., "The Internet Standards Process - Revision 3", BCP 9, RFC 2026, October 1996. Appendix 1 - ITU-T DWDM frequency grid and IEEE floating point The list below illustrates some nominal central frequencies within the C and L bands of the DWDM grid (12.5THz spacing) taken from [G.694.1]and their respective IEEE floating point (32 bits encoding) value [IEEE754]. Nominal central Wavelength label Frequency (THz) (IEEE Floating point) --------------------- ------------------------ . . . . . . 195.9375 0x4343F000 195.9250 0x4343ECCD 195.9125 0x4343E99A 195.9000 0x4343E666 195.8875 0x4343E333 195.8750 0x4343E000 195.8625 0x4343DCCD 195.8500 0x4343D99A 195.8375 0x4343D666 195.8250 0x4343D333 195.8125 0x4343D000 195.8000 0x4343CCCD 195.7875 0x4343C99A 195.7750 0x4343C666 195.7625 0x4343C333 195.7500 0x4343C000 195.7375 0x4343BCCD 195.7250 0x4343B99A 195.7125 0x4343B666 195.6875 0x4343B000 195.6750 0x4343ACCD Expires October 2005 [Page 8] Generalized Labels for LSC-Capable LSRs October 2005 195.6625 0x4343A99A . . . . . . . . . . . . 193.2375 0x43413CCD 193.2250 0x4341399A 193.2125 0x43413666 193.2000 0x43413333 193.1875 0x43413000 193.1750 0x43412CCD 193.1625 0x4341299A 193.1500 0x43412666 193.1375 0x43412333 193.1250 0x43412000 193.1125 0x43411CCD 193.1000 0x4341199A 193.0875 0x43411666 193.0750 0x43411333 193.0625 0x43411000 193.0500 0x43410CCD 193.0375 0x4341099A 193.0250 0x43410666 193.0125 0x43410333 193.0000 0x43410000 192.9875 0x4340FCCD 192.9750 0x4340F99A 192.9625 0x4340F666 . . . . . . . . . . . . 184.7750 0x4338C666 184.7625 0x4338C333 184.7500 0x4338C000 184.7375 0x4338BCCD 184.7250 0x4338B99A 184.7125 0x4338B666 184.7000 0x4338B333 184.6875 0x4338B000 184.6750 0x4338ACCD 184.6625 0x4338A99A 184.6500 0x4338A666 184.6375 0x4338A333 Expires October 2005 [Page 9] Generalized Labels for LSC-Capable LSRs October 2005 184.6250 0x4338A000 184.6125 0x43389CCD 184.6000 0x4338999A 184.5875 0x43389666 184.5750 0x43389333 184.5625 0x43389000 184.5500 0x43388CCD 184.5375 0x4338899A 184.5250 0x43388666 184.5125 0x43388333 184.5000 0x43388000 . . . . . . Authors' Addresses Sidney Shiba (Fujitsu) 2801 Telecom Parkway Richardson, TX 75082, USA Phone: +1 972 479 6041 Email: sidney.shiba@us.fujitsu.com Richard Rabbat (Fujitsu) 1240 East Arques Ave, MS 345 Sunnyvale, CA 94085, USA Phone: +1 408 530 4537 Email: richard@us.fujitsu.com Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 7. Copyright Statement Expires October 2005 [Page 10] Generalized Labels for LSC-Capable LSRs October 2005 Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 8. Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Expires October 2005 [Page 11] --------------010409090105030700040000-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 26 Oct 2005 21:15:38 +0000 Message-ID: <435FF197.3090408@psg.com> Date: Wed, 26 Oct 2005 23:13:59 +0200 From: dimitri papadimitriou Reply-To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be, dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.11) Gecko/20050728 MIME-Version: 1.0 To: yhwkim@etri.re.kr CC: ccamp@ops.ietf.org Subject: comments on draft-kim-ccamp-cpr-reqts-01.txt Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit hi, to fuel the discussion (and even if the topic is not going to be discussed during the f2f meeting) here below some comments after a first reading 1. "Then, GMPLS based IP networks come to be capable of handling control channels separated from data channels. It means that channels carrying data and control packets do not have an impact upon each other. Several control channels such as SONET/SDH DCC channels and Ethernet OAM channels defined by the OIF, MPLS based LSPs applied as dedicated control channels, public IP networks, out-of-fiber based dedicated control channels, and so on can be configured independent from data channels for the purpose." indeed, but this has an architectural impact, we are currently dealing with "converged" networks hence if the control channels do involve the need for a separated control infrastructure even logically there is a price to pay - it would be of interest to have such considerations discussed in this document - 2. "- Standby control channels: Physical control channels which are not currently carrying the control information, but can carry them upon the failure of active control channel. Once one of standby control channels is used to carry the control information, the standby control channel becomes an active control channel." what is the purpose of maintaining "standby channels" this aspect should be further discussed is it to provide some rate shaping to the control traffic ? 3. "In traditional IP networks or MPLS networks, there is an implicit one-to-one association of a control channel to a data channel. Under the one-to-one association between control channels and data channels, the protection of control channels may be resolved using the protection schemes for data channels such as 1+1, 1:1, and 1:N protections. In other words, where there is fate sharing, failures of data channels could instantly influence the own control channels." why is there a distinction made with "MPLS networks" i.e. what does chnage here from having an label based forwarding ? 4. the distinction between the quasi and the non-associated mode is quite unclear "- Quasi-associated mode in which control packets between nodes A and B follow a predetermined routing path over several control channels while the traffic channels are routed directly between A and B; - Non-associated mode in which control packets between two network elements A and B are routed over several control channels, while traffic signals are routed directly between A and B." could you explain the difference between these two terms ? 5. "As recognized in the IP world, IP routing protocols have slow convergence time due to the hello interval and expiration times for the normal operation of IP networks. Under this situation, fast and reliable recovery is very difficult from one or more failures occurred over interfaces between adjacent nodes. " "slow" is not an absolute indication ... you should point out here "slow" compare to what ? by the way i am not in agreement with this statement there are currently ongoing efforts within IETF to allow for fast IP re-routing (meant to provde "simple" techniques) 6. "When RSVP variant protocols are used between adjacent nodes, if there is no self-refresh procedure, the failure of control channels may result effects such as unwanted connection teardown. In particular, as described in [ITU-G7712], such a failure that could not transport ASTN messages over the SCN may impact restoration when ASTN is used to provide restoration of existing connections. It is therefore critical for a control network to provide the resilience of control channels that could sufficiently use direct and indirect ones between adjacent nodes." indeed if you don't use a feature (in present case RSVP resilience to cnotrol channel failure) you can't benefit from it - the same would apply with whatever new mechanism you are going to define - hence this argument is not valid 7. it is totally unclear to me how with the previous section arguments you come out and require MPLS 1+1 for control plane resilience - that's probably a very nice and very cumbersome solution but i really doubt this is satisfying much specific requirements when designing the IP control plane topology 8. the rest of the document (as section 5.1) is solution specific thus beyond the scope of the document itself - this is not a document about LMP requirements for control channel management afaik note: more detailed comments could follow depending on the progress we are going to make on this specific topic thanks, - dimitri. -------- Original Message -------- Subject: I-D ACTION:draft-kim-ccamp-cpr-reqts-01.txt Date: Tue, 25 Oct 2005 10:50:01 -0400 From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Requirements for the Resilience of Control Plane Author(s) : Y. Kim Filename : draft-kim-ccamp-cpr-reqts-01.txt Pages : 13 Date : 2005-10-25 The resilience of control plane refers to the ability of control plane to continue its operation even under failure conditions of control components such as control entities, control nodes, and control channels. This document describes requirements for providing the resilience capability of control plane (in other words, control network) in non-(G)MPLS and (G)MPLS. This contribution, as a document that proposes a framework to provide the resilience capability of control plane, include terminologies, basic concepts of control networks, possible configurations, necessities and requirements, additional considerations including the relationship with other protocol such as LMP for the resilience of control plane. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-kim-ccamp-cpr-reqts-01.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-kim-ccamp-cpr-reqts-01.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-kim-ccamp-cpr-reqts-01.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. Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 26 Oct 2005 19:51:12 +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-addressing-02.txt Message-Id: Date: Wed, 26 Oct 2005 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 : Use of Addresses in Generalized Multi-Protocol Label Switching (GMPLS) Networks Author(s) : K. Shiomoto, et al. Filename : draft-ietf-ccamp-gmpls-addressing-02.txt Pages : 26 Date : 2005-10-26 This document explains and clarifies the use of addresses in Generalized Multi-Protocol Label Switching (GMPLS) networks. The aim of this document is to facilitate and ensure better interworking of GMPLS-capable Label Switching Routers (LSRs) based on experience gained in deployments and interoperability testing and proper interpretation of published RFCs. The document recommends a proper approach for the interpretation and choice of address and identifier fields within GMPLS protocols and references specific control plane usage models. It also examines some common GMPLS Resource Reservation Protocol-Traffic Engineering (RSVP-TE) signaling message processing issues and recommends solutions. Finally, it discusses how to handle IPv6 sources and destinations in the MPLS and GMPLS TE (Traffic Engineering) MIB (Management Information Base) modules. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-addressing-02.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-addressing-02.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-addressing-02.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: <2005-10-26104458.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-gmpls-addressing-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-gmpls-addressing-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-10-26104459.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 26 Oct 2005 17:23:16 +0000 Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0A644684-BDF3-43E4-845C-4C55AC97D5D9@cisco.com> Cc: Igor Bryskin , Adrian Farrel , "JP Vasseur (Cisco)" , ccamp@ops.ietf.org, Arthi Ayyangar Content-Transfer-Encoding: 7bit From: JP Vasseur Subject: Re: I-D ACTION:draft-ietf-ccamp-inter-domain-pd-path-comp-01.txt Date: Tue, 25 Oct 2005 09:51:42 -0400 To: Igor Bryskin Hi Igor, On Oct 25, 2005, at 10:47 PM, Arthi Ayyangar wrote: > Hi Igor, > > Just to reiterate what Adrian said, this ID is only intended to > cover the case where you do not have a PCE. > As I told you before the PCE case used to be in scenario 2 of the former inter-domain draft and will be resurrected and discussed in the PCE WG for IETF-65. JP. > I do, however, agree with what you say below in "The bottom line". > > thanks, > -arthi > > > >> The bottom line: when PCE is available one should never consult IP >> routing >> to determine the outgoing border node when one performs per-domain >> path >> computation. If PCE is not available, than in case of IP network, >> I agree, >> there is a value to consult IP routing. This is because in IP >> world TE >> resources are still tightly coupled with IP interfaces. In the non- >> IP world, >> I'd say, consulting IP routing makes much lesser sense: it could >> give you a >> path when no TE path exists or, more importantly, fail the request >> when one >> or more TE paths do exist. I'd suggest in this case rather than >> consulting >> IP (which is as useful IMO as consulting somebody's Outlook >> address book) to >> route the LSP towards any known domain border node and hope that >> the latter >> will crankback the request specifying the proper border node if >> necessary. >> >> >> >> Cheers, >> >> Igor >> >> >> >> ----- Original Message ----- >> From: "Adrian Farrel" >> To: "Igor Bryskin" ; ; "Arthi >> Ayyangar" >> >> Cc: >> Sent: Friday, October 21, 2005 2:20 PM >> Subject: Re: I-D ACTION:draft-ietf-ccamp-inter-domain-pd-path- >> comp-01.txt >> >> >> >>> Hi Igor, >>> >>> I think you have to set the context of this I-D carefully, and then >>> understand the limited scope that is additionally proposed. >>> >>> The context of the I-D is limited to the per-domain computation >>> case. >>> Hence, consulting an external PCE is out of scope. This is not to >>> say that >>> it is not valid to consult a PCE (in fact, you might expect JP >>> and me to >>> support that technique), but this I-D is demonstrating what we >>> can do and >>> how we can solve the problem without using PCE. >>> >>> With respect to the use of the IP reachability, you may recall >>> that I >>> raised this concern in Paris and on the list. The conclusion was >>> that if >>> you have no other way of determining an exit router for your >>> domain, then >>> attempting to use the IP reachability is no worse than giving up, >>> and may >>> be much better. >>> >>> In the cases you raise: >>> 1. Yes, an interface address may be unreachable. >>> Do we lose anything by consulting IP reachability in this case? >>> No. >>> 2. Yes, the IP reachability may give us a sub-optimal TE path. >>> Is this path worse than no path? >>> No. >>> >>> So I asked the authors to be clear that what they are suggesting has >>> limitations, and should not be applied in some specific cases. I >>> haven't >>> looked at the text yet, but I hope they have covered this. >>> >>> Cheers, >>> Adrian >>> ----- Original Message ----- >>> From: "Igor Bryskin" >>> To: ; "Arthi Ayyangar" >>> Cc: >>> Sent: Friday, October 21, 2005 4:27 PM >>> Subject: Re: I-D ACTION:draft-ietf-ccamp-inter-domain-pd-path- >>> comp-01.txt >>> >>> >>> >>>> Arthi, JP >>>> >>>> >>>> >>>> I have a problem with the auto-discovery mechanism you described >>>> in the >>>> draft (one that is based on query to IGP or BGP to determine >>>> outgoing >>>> ABR/ASBR). >>>> >>>> >>>> >>>> 1. Destination ID must be network unique but it does not have to >>>> be IP >>>> routable, for example, it could be a numbered link ID. >>>> >>>> 2. Even in case when destination is IP address, the path >>>> computing node >>>> >>> can >>> >>>> only obtain the ID of an ABR or ASBR that advertises IP route to >>>> the >>>> destination, which would be one that knows about the shortest IP >>>> path to >>>> >>> the >>> >>>> destination. However, it does not mean that properly constrained >>>> TE path >>>> from this ABR/ASBR to the destination or the next ABR/ASBR >>>> exist, or is >>>> >>> not >>> >>>> suboptimal compared to one from some other ABR/ASBR which knows >>>> about >>>> >>> worse >>> >>>> IP path to the destination and hence will not be reported to the >>>> >>> computing >>> >>>> entity by the routing sub-system. >>>> >>>> >>>> >>>> I wonder why not to use the remote PCE service for this purpose. >>>> For >>>> instance a PCC may ask a PCE to determine either the ID of the >>>> outgoing >>>> domain border node or entire path in terms of domain border >>>> nodes. You >>>> >>> may >>> >>>> ask why not to request explicit path(s) in this case? Several >>>> reasons >>>> >>> why >>> >>>> the PCC wouldn't want to do so: >>>> >>>> >>>> >>>> a) it could be easier and faster for the PCE to determine domain >>>> border >>>> >>> node >>> >>>> in direction towards the destination rather than explicit path >>>> (s). For >>>> instance, the latter may require cooperation of other PCEs; >>>> >>>> >>>> >>>> b) security considerations - PCE may not want to reveal remote >>>> domain >>>> topology(ies) >>>> >>>> >>>> >>>> c) it may be desirable to compute and setup services on per-domain >>>> >>> basis, >>> >>>> for instance, to have each domain take separate care for service >>>> restoration. >>>> >>>> >>>> >>>> What do you think? >>>> >>>> >>>> >>>> Igor >>>> >>>> >>>> >>>> ----- Original Message ----- >>>> >>>> From: >>>> >>>> To: >>>> >>>> Cc: >>>> >>>> Sent: Thursday, October 20, 2005 6:50 PM >>>> >>>> Subject: I-D ACTION:draft-ietf-ccamp-inter-domain-pd-path- >>>> comp-01.txt >>>> >>>> >>>> >>>> >>>>> A New Internet-Draft is available from the on-line Internet-Drafts >>>>> >>>> directories. >>>> >>>>> This draft is a work item of the Common Control and Measurement >>>>> Plane >>>>> >>>> Working Group of the IETF. >>>> >>>>> >>>>> Title : A Per-domain path computation method for establishing >>>>> Inter-domain Traffic Engineering (TE) >>>>> Label >>>>> >>>> Switched Paths (LSPs) >>>> >>>>> Author(s) : J. Vasseur, et al. >>>>> Filename : draft-ietf-ccamp-inter-domain-pd-path-comp-01.txt >>>>> Pages : 18 >>>>> Date : 2005-10-20 >>>>> >>>>> This document specifies a per-domain path computation technique >>>>> for >>>>> establishing inter-domain Traffic Engineering (TE) >>>>> Multiprotocol Label >>>>> Switching (MPLS) and Generalized MPLS (GMPLS) Label Switched Paths >>>>> (LSPs). In this document a domain refers to a collection of >>>>> network >>>>> elements within a common sphere of address management or path >>>>> computational responsibility such as IGP areas and Autonomous >>>>> Systems. >>>>> >>>>> Per-domain computation applies where the full path of an inter- >>>>> domain >>>>> TE LSP cannot be or is not determined at the ingress node of >>>>> the TE >>>>> LSP, and is not signaled across domain boundaries. This is most >>>>> likely >>>>> to arise owing to TE visibility limitations. The signaling message >>>>> indicates the destination and nodes up to the next domain >>>>> boundary. It >>>>> may also indicate further domain boundaries or domain >>>>> identifiers. The >>>>> path through each domain, possibly including the choice of exit >>>>> point >>>>> from the domain, must be determined within the domain. >>>>> >>>>> A URL for this Internet-Draft is: >>>>> >>>>> >>>> >>>> >>> >>> >> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-inter-domain- >> pd-path-comp-01.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-inter-domain-pd-path-comp-01.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-inter-domain-pd-path-comp-01.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. >>>>> >>>>> >>>> >>>> >>>> >>>> >>>> >>> >>> >> > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 26 Oct 2005 16:44:02 +0000 Message-ID: <038601c5da4b$ea570120$de849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Draft agenda Date: Wed, 26 Oct 2005 17:39:54 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi, You can see a draft agenda at http://www3.ietf.org/proceedings/05nov/agenda/ccamp.txt You'll notice it is pretty full (again). Our objective in formulating this agenda has been to prompt discussion that will make valuable use of face-to-face meeting time. Presentation of what is in your draft is not the main reason for addressing the room: you should be seeking input and discussion. In order to make this work a bit better than previously, the agenda is interspersed with questions that we want you to raise *not* answer. That is, you should be leading the discussion that will help the room debate and discuss these questions. If you turn up and just answer the questions leaving no room for discussion (or worse if you just present your draft) I will allow Kireeti to bite you. I know that there will be a few of you disappointed not to have your topics/drafts on the agenda. our decisions were made based on what we feel needs face-to-face discussion. In particular, if you have a new revision of an existing I-D that has progressed but has not made any radical changes, we will probably have left you off. Also, if you have a new I-D that has not been discussed on the mailing list, we may also have left you off. Thanks, Adrian PS We are very nearly there with a new set of milestones for CCAMP. This has reached the secretariat and should be up on the web page soon. PPS Don't forget the GELS BoF (GMPLS controlled Ethernet Label Switching) that is very relevant to several drafts first raised in CCAMP Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 26 Oct 2005 14:06:24 +0000 Message-ID: <005101c5da36$19b30920$7a1810ac@movaz.com> From: "Igor Bryskin" To: "Arthi Ayyangar" Cc: "Adrian Farrel" , , Subject: Re: I-D ACTION:draft-ietf-ccamp-inter-domain-pd-path-comp-01.txt Date: Wed, 26 Oct 2005 10:03:54 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Arthi, I think we are in complete agreement here. Igor ----- Original Message ----- From: "Arthi Ayyangar" To: "Igor Bryskin" Cc: "Adrian Farrel" ; ; Sent: Tuesday, October 25, 2005 10:47 PM Subject: Re: I-D ACTION:draft-ietf-ccamp-inter-domain-pd-path-comp-01.txt > Hi Igor, > > Just to reiterate what Adrian said, this ID is only intended to cover the > case where you do not have a PCE. > > I do, however, agree with what you say below in "The bottom line". > > thanks, > -arthi > > > > The bottom line: when PCE is available one should never consult IP routing > > to determine the outgoing border node when one performs per-domain path > > computation. If PCE is not available, than in case of IP network, I agree, > > there is a value to consult IP routing. This is because in IP world TE > > resources are still tightly coupled with IP interfaces. In the non-IP world, > > I'd say, consulting IP routing makes much lesser sense: it could give you a > > path when no TE path exists or, more importantly, fail the request when one > > or more TE paths do exist. I'd suggest in this case rather than consulting > > IP (which is as useful IMO as consulting somebody's Outlook address book) to > > route the LSP towards any known domain border node and hope that the latter > > will crankback the request specifying the proper border node if necessary. > > > > > > > > Cheers, > > > > Igor > > > > > > > > ----- Original Message ----- > > From: "Adrian Farrel" > > To: "Igor Bryskin" ; ; "Arthi Ayyangar" > > > > Cc: > > Sent: Friday, October 21, 2005 2:20 PM > > Subject: Re: I-D ACTION:draft-ietf-ccamp-inter-domain-pd-path-comp-01.txt > > > > > >> Hi Igor, > >> > >> I think you have to set the context of this I-D carefully, and then > >> understand the limited scope that is additionally proposed. > >> > >> The context of the I-D is limited to the per-domain computation case. > >> Hence, consulting an external PCE is out of scope. This is not to say that > >> it is not valid to consult a PCE (in fact, you might expect JP and me to > >> support that technique), but this I-D is demonstrating what we can do and > >> how we can solve the problem without using PCE. > >> > >> With respect to the use of the IP reachability, you may recall that I > >> raised this concern in Paris and on the list. The conclusion was that if > >> you have no other way of determining an exit router for your domain, then > >> attempting to use the IP reachability is no worse than giving up, and may > >> be much better. > >> > >> In the cases you raise: > >> 1. Yes, an interface address may be unreachable. > >> Do we lose anything by consulting IP reachability in this case? > >> No. > >> 2. Yes, the IP reachability may give us a sub-optimal TE path. > >> Is this path worse than no path? > >> No. > >> > >> So I asked the authors to be clear that what they are suggesting has > >> limitations, and should not be applied in some specific cases. I haven't > >> looked at the text yet, but I hope they have covered this. > >> > >> Cheers, > >> Adrian > >> ----- Original Message ----- > >> From: "Igor Bryskin" > >> To: ; "Arthi Ayyangar" > >> Cc: > >> Sent: Friday, October 21, 2005 4:27 PM > >> Subject: Re: I-D ACTION:draft-ietf-ccamp-inter-domain-pd-path-comp-01.txt > >> > >> > >>> Arthi, JP > >>> > >>> > >>> > >>> I have a problem with the auto-discovery mechanism you described in the > >>> draft (one that is based on query to IGP or BGP to determine outgoing > >>> ABR/ASBR). > >>> > >>> > >>> > >>> 1. Destination ID must be network unique but it does not have to be IP > >>> routable, for example, it could be a numbered link ID. > >>> > >>> 2. Even in case when destination is IP address, the path computing node > >> can > >>> only obtain the ID of an ABR or ASBR that advertises IP route to the > >>> destination, which would be one that knows about the shortest IP path to > >> the > >>> destination. However, it does not mean that properly constrained TE path > >>> from this ABR/ASBR to the destination or the next ABR/ASBR exist, or is > >> not > >>> suboptimal compared to one from some other ABR/ASBR which knows about > >> worse > >>> IP path to the destination and hence will not be reported to the > >> computing > >>> entity by the routing sub-system. > >>> > >>> > >>> > >>> I wonder why not to use the remote PCE service for this purpose. For > >>> instance a PCC may ask a PCE to determine either the ID of the outgoing > >>> domain border node or entire path in terms of domain border nodes. You > >> may > >>> ask why not to request explicit path(s) in this case? Several reasons > >> why > >>> the PCC wouldn't want to do so: > >>> > >>> > >>> > >>> a) it could be easier and faster for the PCE to determine domain border > >> node > >>> in direction towards the destination rather than explicit path(s). For > >>> instance, the latter may require cooperation of other PCEs; > >>> > >>> > >>> > >>> b) security considerations - PCE may not want to reveal remote domain > >>> topology(ies) > >>> > >>> > >>> > >>> c) it may be desirable to compute and setup services on per-domain > >> basis, > >>> for instance, to have each domain take separate care for service > >>> restoration. > >>> > >>> > >>> > >>> What do you think? > >>> > >>> > >>> > >>> Igor > >>> > >>> > >>> > >>> ----- Original Message ----- > >>> > >>> From: > >>> > >>> To: > >>> > >>> Cc: > >>> > >>> Sent: Thursday, October 20, 2005 6:50 PM > >>> > >>> Subject: I-D ACTION:draft-ietf-ccamp-inter-domain-pd-path-comp-01.txt > >>> > >>> > >>> > >>>> A New Internet-Draft is available from the on-line Internet-Drafts > >>> directories. > >>>> This draft is a work item of the Common Control and Measurement Plane > >>> Working Group of the IETF. > >>>> > >>>> Title : A Per-domain path computation method for establishing > >>>> Inter-domain Traffic Engineering (TE) Label > >>> Switched Paths (LSPs) > >>>> Author(s) : J. Vasseur, et al. > >>>> Filename : draft-ietf-ccamp-inter-domain-pd-path-comp-01.txt > >>>> Pages : 18 > >>>> Date : 2005-10-20 > >>>> > >>>> This document specifies a per-domain path computation technique for > >>>> establishing inter-domain Traffic Engineering (TE) Multiprotocol Label > >>>> Switching (MPLS) and Generalized MPLS (GMPLS) Label Switched Paths > >>>> (LSPs). In this document a domain refers to a collection of network > >>>> elements within a common sphere of address management or path > >>>> computational responsibility such as IGP areas and Autonomous Systems. > >>>> > >>>> Per-domain computation applies where the full path of an inter-domain > >>>> TE LSP cannot be or is not determined at the ingress node of the TE > >>>> LSP, and is not signaled across domain boundaries. This is most likely > >>>> to arise owing to TE visibility limitations. The signaling message > >>>> indicates the destination and nodes up to the next domain boundary. It > >>>> may also indicate further domain boundaries or domain identifiers. The > >>>> path through each domain, possibly including the choice of exit point > >>>> from the domain, must be determined within the domain. > >>>> > >>>> A URL for this Internet-Draft is: > >>>> > >>> > >> > > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-inter-domain-pd-path-comp-01.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-inter-domain-pd-path-comp-01.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-inter-domain-pd-path-comp-01.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. > >>>> > >>> > >>> > >>> > >>> > >> > > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 26 Oct 2005 11:32:00 +0000 Message-ID: <029001c5da20$90712530$de849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Correspondence from OIF Date: Wed, 26 Oct 2005 11:28:46 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi, Please find below the text of a correspondence from the OIF. This will be posted on the alternate CCAMP pages at http://www.olddog.co.uk/ccamp.htm No response is required, but we should follow up with RFC3946-bis and through the GELS BoF. Cheers, Adrian =========== To: Adrian Farrel and Kireeti Kompella, IETF CCAMP WG Co-Chairs From: Jim Jones, OIF TC Chair Copy: Alex Zinin and Bill Fenner, IETF Routing Area Directors Subject: Follow up questions concerning GMPLS parameters Dear Adrian and Kireeti, OIF very much appreciates your help with our questions concerning GMPLS parameters in your response liaison of October 2005. After discussion of your liaison letter, we had a number of follow-up questions (issues are numbered as in our liaison of July 2005): 1. NCC and RCC field values for STS-3c/VC-4 connections The revision to RFC 3946 proposed by CCAMP looks acceptable to us. We also agree that the receiving entity should be liberal in what it accepts, i.e., either 0 or 1 should be accepted at the receiver. We would ideally prefer that a single value be identified as the "recommended" value to use by the sender, to further remove any potential interoperability issue. 2. Setting of NVC for VCAT connections It is our understanding from CCAMP's response that NVC is always >0 for VCAT setup, e.g., if a single connection is being set up as part of a larger VCAT connection, the value NVC=1 would be used in the PATH message. We note that there may be more complex scenarios that need to be considered, such as connections being set up initially without being part of a VCAT group and subsequently being added to a VCAT group. An ITU-T Liaison with related discussion has been received by us and was also copied to CCAMP. 3. Length of the Switching Capability Descriptor We appreciate the verification from CCAMP. 4. Use of ADMIN_STATUS in the PATH message We appreciate CCAMP's advice. 5. Handling of multiple received ResvConf Request objects It is our understanding from CCAMP's response that a ResvConf Request object received in the Resv message should only trigger sending of the ResvConf message if there is a change in the Resv message, i.e., it is not a refresh message. If in fact it is desirable to trigger a new ResvConf message without making a change to an existing session and associated connection, we believe that a possible mechanism for doing this is to first send a Resv message removing the ResvConf Request object and then send a subsequent Resv message with the ResvConf Request object reinserted, thus differentiating the request from a refresh. We also noted the advice that the ADMIN_STATUS object offers a reliable mechanism as an alternative to ResvConf, however are unclear as to the procedure for triggering ADMIN_STATUS, for example, to determine when the originating endpoint is ready to receive signal during connection setup. 6. Symmetry of Refresh Reduction We appreciate the clarification from CCAMP. 7. Sending of ACKs bundled with RSVP Hello We appreciate the clarification from CCAMP. We did in fact mean "piggybacking" of ACKs with the Hello message, which we now understand is prohibited based on RFC 3209. 8. TSPEC format for Ethernet We appreciate CCAMP's interest in OIF requirements for Ethernet connection control. As a result of discussions within OIF and review of ITU-T G.8011 and MEF.6 and MEF.10, we have identified the following attributes as requiring support in signaling to specify the Ethernet bandwidth profile and request that CCAMP identify a mechanism for carrying this in the protocol, e.g., a new Sender_Tspec/Flowspec format for Ethernet : CIR (Committed Information Rate): Maximum rate required under normal conditions, service level guaranteed. CBS (Committed Burst Size): Limits the number of bytes for a burst while conforming to CIR. EIR (Excess Information Rate): Maximum rate required under burst conditions, no guarantee of performance. EBS (Excess Burst Size): Limits the number of bytes for a burst while conforming to EIR. CF (Coupling Flag) and CM (Colour Mode): Give a choice for different modes of operation. These are defined in the following references: 1.. [1] Metro Ethernet Forum, MEF.10 - Ethernet Services Attributes Phase 1, Nov. 2004 2.. [2] ITU-T Recommendation G.8011/Y.1307 (2004), Am. 1 (2005), "Ethernet Services Framework". We would like to also bring to CCAMP's attention that MEF has defined as set of TLVs for these attributes for use in their E-LMI (Ethernet Link Management Interface) specification and these may be of use to CCAMP in its work. Best regards, Jim Jones OIF Technical Committee Chair Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 26 Oct 2005 10:22:59 +0000 Message-ID: <026401c5da16$4d552ad0$de849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Cc: "WG Milestone Tracker" , "Bill Fenner" , Subject: Publication request: draft-ietf-ccamp-rsvp-restart-ext-05.txt Date: Wed, 26 Oct 2005 11:12:19 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi Alex, This I-D has been through CCAMP working group last call (twice) and has been updated to my satisfaction. Could you please add it to the pile pending publication. Thanks, Adrian ----- Original Message ----- From: To: Cc: Sent: Tuesday, October 25, 2005 11:50 PM Subject: I-D ACTION:draft-ietf-ccamp-rsvp-restart-ext-05.txt > Title : Extensions to GMPLS RSVP Graceful Restart > Author(s) : A. Satyanarayana, R. Rahman > Filename : draft-ietf-ccamp-rsvp-restart-ext-05.txt > Pages : 24 > Date : 2005-10-25 > > This document describes extensions to the RSVP Graceful Restart > mechanisms defined in RFC 3473. The extensions enable the recovery > of RSVP signaling state based on the Path message last sent by the > node being restarted. Previously defined Graceful Restart > mechanisms, also called recovery from nodal faults, permit recovery > of signaling state from adjacent nodes when the data plane has > retained the associated forwarding state across a restart. These > mechanisms do not fully support signaling state recovery on ingress > nodes or recovery of all RSVP objects. The presented extensions use > the RSVP Hello extensions defined in RFC 3209, and extensions for > state recovery on nodal faults defined in RFC 3473. With the > presented extensions the restarting node can recover all previously > transmitted Path state including the Explicit Route Object and the > downstream (outgoing) interface identifiers. The extensions can also > be used to recover signaling state after the restart of an ingress > node. The extensions optionally support the use of Summary Refresh, > defined in RFC 2961, to reduce the number of messages exchanged > during the Recovery Phase when the restarting node has recovered > signaling state locally for one or more LSPs. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rsvp-restart-ext-05.txt Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 26 Oct 2005 02:48:45 +0000 Date: Tue, 25 Oct 2005 19:47:20 -0700 (PDT) From: Arthi Ayyangar To: Igor Bryskin cc: Adrian Farrel , jpv@cisco.com, ccamp@ops.ietf.org Subject: Re: I-D ACTION:draft-ietf-ccamp-inter-domain-pd-path-comp-01.txt Message-ID: <20051025192049.T10870@zircon.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Hi Igor, Just to reiterate what Adrian said, this ID is only intended to cover the case where you do not have a PCE. I do, however, agree with what you say below in "The bottom line". thanks, -arthi > The bottom line: when PCE is available one should never consult IP routing > to determine the outgoing border node when one performs per-domain path > computation. If PCE is not available, than in case of IP network, I agree, > there is a value to consult IP routing. This is because in IP world TE > resources are still tightly coupled with IP interfaces. In the non-IP world, > I'd say, consulting IP routing makes much lesser sense: it could give you a > path when no TE path exists or, more importantly, fail the request when one > or more TE paths do exist. I'd suggest in this case rather than consulting > IP (which is as useful IMO as consulting somebody's Outlook address book) to > route the LSP towards any known domain border node and hope that the latter > will crankback the request specifying the proper border node if necessary. > > > > Cheers, > > Igor > > > > ----- Original Message ----- > From: "Adrian Farrel" > To: "Igor Bryskin" ; ; "Arthi Ayyangar" > > Cc: > Sent: Friday, October 21, 2005 2:20 PM > Subject: Re: I-D ACTION:draft-ietf-ccamp-inter-domain-pd-path-comp-01.txt > > >> Hi Igor, >> >> I think you have to set the context of this I-D carefully, and then >> understand the limited scope that is additionally proposed. >> >> The context of the I-D is limited to the per-domain computation case. >> Hence, consulting an external PCE is out of scope. This is not to say that >> it is not valid to consult a PCE (in fact, you might expect JP and me to >> support that technique), but this I-D is demonstrating what we can do and >> how we can solve the problem without using PCE. >> >> With respect to the use of the IP reachability, you may recall that I >> raised this concern in Paris and on the list. The conclusion was that if >> you have no other way of determining an exit router for your domain, then >> attempting to use the IP reachability is no worse than giving up, and may >> be much better. >> >> In the cases you raise: >> 1. Yes, an interface address may be unreachable. >> Do we lose anything by consulting IP reachability in this case? >> No. >> 2. Yes, the IP reachability may give us a sub-optimal TE path. >> Is this path worse than no path? >> No. >> >> So I asked the authors to be clear that what they are suggesting has >> limitations, and should not be applied in some specific cases. I haven't >> looked at the text yet, but I hope they have covered this. >> >> Cheers, >> Adrian >> ----- Original Message ----- >> From: "Igor Bryskin" >> To: ; "Arthi Ayyangar" >> Cc: >> Sent: Friday, October 21, 2005 4:27 PM >> Subject: Re: I-D ACTION:draft-ietf-ccamp-inter-domain-pd-path-comp-01.txt >> >> >>> Arthi, JP >>> >>> >>> >>> I have a problem with the auto-discovery mechanism you described in the >>> draft (one that is based on query to IGP or BGP to determine outgoing >>> ABR/ASBR). >>> >>> >>> >>> 1. Destination ID must be network unique but it does not have to be IP >>> routable, for example, it could be a numbered link ID. >>> >>> 2. Even in case when destination is IP address, the path computing node >> can >>> only obtain the ID of an ABR or ASBR that advertises IP route to the >>> destination, which would be one that knows about the shortest IP path to >> the >>> destination. However, it does not mean that properly constrained TE path >>> from this ABR/ASBR to the destination or the next ABR/ASBR exist, or is >> not >>> suboptimal compared to one from some other ABR/ASBR which knows about >> worse >>> IP path to the destination and hence will not be reported to the >> computing >>> entity by the routing sub-system. >>> >>> >>> >>> I wonder why not to use the remote PCE service for this purpose. For >>> instance a PCC may ask a PCE to determine either the ID of the outgoing >>> domain border node or entire path in terms of domain border nodes. You >> may >>> ask why not to request explicit path(s) in this case? Several reasons >> why >>> the PCC wouldn't want to do so: >>> >>> >>> >>> a) it could be easier and faster for the PCE to determine domain border >> node >>> in direction towards the destination rather than explicit path(s). For >>> instance, the latter may require cooperation of other PCEs; >>> >>> >>> >>> b) security considerations - PCE may not want to reveal remote domain >>> topology(ies) >>> >>> >>> >>> c) it may be desirable to compute and setup services on per-domain >> basis, >>> for instance, to have each domain take separate care for service >>> restoration. >>> >>> >>> >>> What do you think? >>> >>> >>> >>> Igor >>> >>> >>> >>> ----- Original Message ----- >>> >>> From: >>> >>> To: >>> >>> Cc: >>> >>> Sent: Thursday, October 20, 2005 6:50 PM >>> >>> Subject: I-D ACTION:draft-ietf-ccamp-inter-domain-pd-path-comp-01.txt >>> >>> >>> >>>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>>> This draft is a work item of the Common Control and Measurement Plane >>> Working Group of the IETF. >>>> >>>> Title : A Per-domain path computation method for establishing >>>> Inter-domain Traffic Engineering (TE) Label >>> Switched Paths (LSPs) >>>> Author(s) : J. Vasseur, et al. >>>> Filename : draft-ietf-ccamp-inter-domain-pd-path-comp-01.txt >>>> Pages : 18 >>>> Date : 2005-10-20 >>>> >>>> This document specifies a per-domain path computation technique for >>>> establishing inter-domain Traffic Engineering (TE) Multiprotocol Label >>>> Switching (MPLS) and Generalized MPLS (GMPLS) Label Switched Paths >>>> (LSPs). In this document a domain refers to a collection of network >>>> elements within a common sphere of address management or path >>>> computational responsibility such as IGP areas and Autonomous Systems. >>>> >>>> Per-domain computation applies where the full path of an inter-domain >>>> TE LSP cannot be or is not determined at the ingress node of the TE >>>> LSP, and is not signaled across domain boundaries. This is most likely >>>> to arise owing to TE visibility limitations. The signaling message >>>> indicates the destination and nodes up to the next domain boundary. It >>>> may also indicate further domain boundaries or domain identifiers. The >>>> path through each domain, possibly including the choice of exit point >>>> from the domain, must be determined within the domain. >>>> >>>> A URL for this Internet-Draft is: >>>> >>> >> > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-inter-domain-pd-path-comp-01.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-inter-domain-pd-path-comp-01.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-inter-domain-pd-path-comp-01.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. >>>> >>> >>> >>> >>> >> > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 25 Oct 2005 22:51:25 +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-rsvp-restart-ext-05.txt Message-Id: Date: Tue, 25 Oct 2005 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 : Extensions to GMPLS RSVP Graceful Restart Author(s) : A. Satyanarayana, R. Rahman Filename : draft-ietf-ccamp-rsvp-restart-ext-05.txt Pages : 24 Date : 2005-10-25 This document describes extensions to the RSVP Graceful Restart mechanisms defined in RFC 3473. The extensions enable the recovery of RSVP signaling state based on the Path message last sent by the node being restarted. Previously defined Graceful Restart mechanisms, also called recovery from nodal faults, permit recovery of signaling state from adjacent nodes when the data plane has retained the associated forwarding state across a restart. These mechanisms do not fully support signaling state recovery on ingress nodes or recovery of all RSVP objects. The presented extensions use the RSVP Hello extensions defined in RFC 3209, and extensions for state recovery on nodal faults defined in RFC 3473. With the presented extensions the restarting node can recover all previously transmitted Path state including the Explicit Route Object and the downstream (outgoing) interface identifiers. The extensions can also be used to recover signaling state after the restart of an ingress node. The extensions optionally support the use of Summary Refresh, defined in RFC 2961, to reduce the number of messages exchanged during the Recovery Phase when the restarting node has recovered signaling state locally for one or more LSPs. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rsvp-restart-ext-05.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-rsvp-restart-ext-05.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-rsvp-restart-ext-05.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: <2005-10-25161743.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-rsvp-restart-ext-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-rsvp-restart-ext-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-10-25161743.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 25 Oct 2005 17:36:09 +0000 Message-ID: <011f01c5d98a$e9292830$de849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Marco Ruffini" , Subject: Re: draft-ietf-ccamp-lmp-10 comments Date: Tue, 25 Oct 2005 18:38:19 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi Marco, I think the first quote comes from a paragraph that begins "A unique characteristic of transparent devices" making clear that this text applies specifically to transparent devices, while the second quote comes from the subsequent paragraph and is more general, applying to opaque and transparent devices (as the text later in that paragraph makes clear). Thus there is no contradiction. The question may be phrased another way. In the case that you have a transparent switch, how will you send a test signal on a link? The answer is usually: I will turn off all signals except for the one I am testing. That means two things... 1. You need to turn off all other signals at the sender 2. You must not transparently forward signals at the receiver (because a. you would not notice the signal and b. the next downstream node would receive the signal) Cheers, Adrian ----- Original Message ----- From: "Marco Ruffini" To: Sent: Tuesday, October 25, 2005 5:59 PM Subject: draft-ietf-ccamp-lmp-10 comments Hi all, I was reading the draft-ietf-ccamp-lmp-10 document and in the paragraph 5 I found a part which is not completely clear to me. Suppose I want to verify the link connectivity between two transparent switches, A and B, where A is the node that initiates the procedure. - One part of the text asserts that "to ensure proper verification of data link connectivity, it is required that until the data links are allocated for user traffic, they must be opaque (i.e., lose their transparency).": from here I understand that node B has to terminate all the ports that are not currently transmitting data (i.e. all the ports that have not been already verified). - On another part I found: "There is no requirement that all data links be terminated simultaneously, but at a minimum, the data links MUST be able to be terminated one at a time": here it looks like B does not have to terminate all the not-yet-verified ports at the same time. However in this case B may not receive a message sent from node A over a certain link even if that link is actually connecting node A to B (in fact the port of B relative to that link may be not terminated in that occasion). Which one is the correct interpretation? Should node B have all the not-yet-verified ports terminated at the same time when node A starts the link verification? This is the text of paragraph 5 I referred to: "A unique characteristic of transparent devices is that the data is not modified or examined in normal operation. This characteristic poses a challenge for validating the connectivity of the data links and establish the label mappings. Therefore, to ensure proper verification of data link connectivity, it is required that until the data links are allocated for user traffic, they must be opaque (i.e., lose their transparency). To support various degrees of opaqueness (e.g., examining overhead bytes, terminating the IP payload, etc.), and hence different mechanisms to transport the Test messages, a Verify Transport Mechanism field is included in the BeginVerify and BeginVerifyAck messages. There is no requirement that all data links be terminated simultaneously, but at a minimum, the data links MUST be able to be terminated one at a time. Furthermore, for the link verification procedure it is assumed that the nodal architecture is designed so that messages can be sent and received over any data link. Note that this requirement is trivial for opaque devices since each data link is electrically terminated and processed before being forwarded to the next opaque device, but that in transparent devices this is an additional requirement." Best Regards, Marco Ruffini. CTVR, Trinity College, Dublin 2, Ireland. Phone: +353-1-608 8442 Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 25 Oct 2005 17:00:41 +0000 From: "Marco Ruffini" To: Subject: draft-ietf-ccamp-lmp-10 comments Date: Tue, 25 Oct 2005 17:59:23 +0100 Message-ID: <002a01c5d985$73511aa0$1737e286@PC> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_002B_01C5D98D.D51582A0" This is a multi-part message in MIME format. ------=_NextPart_000_002B_01C5D98D.D51582A0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, I was reading the draft-ietf-ccamp-lmp-10 document and in the paragraph = 5 I found a part which is not completely clear to me. =20 Suppose I want to verify the link connectivity between two transparent switches, A and B, where A is the node that initiates the procedure.=20 - One part of the text asserts that "to ensure proper = verification of data link connectivity, it is required that until the data links are allocated for user traffic, they must be opaque (i.e., lose their transparency).": from here I understand that node B has to terminate all = the ports that are not currently transmitting data (i.e. all the ports that = have not been already verified). - On another part I found: "There is no requirement that all = data links be terminated simultaneously, but at a minimum, the data links = MUST be able to be terminated one at a time": here it looks like B does not have = to terminate all the not-yet-verified ports at the same time. However in = this case B may not receive a message sent from node A over a certain link = even if that link is actually connecting node A to B (in fact the port of B relative to that link may be not terminated in that occasion). =20 Which one is the correct interpretation? Should node B have all the not-yet-verified ports terminated at the same time when node A starts = the link verification? =20 =20 This is the text of paragraph 5 I referred to: "A unique characteristic of transparent devices is that the data is not modified or examined in normal operation. This characteristic poses a challenge for validating the connectivity of the data links and establish the label mappings. Therefore, to ensure proper verification of data link connectivity, it is required that until the data links are allocated for user traffic, they must be opaque (i.e., lose their transparency). To support various degrees of opaqueness (e.g., examining overhead bytes, terminating the IP payload, etc.), and hence different mechanisms to transport the Test messages, a Verify Transport Mechanism field is included in the BeginVerify and BeginVerifyAck messages. =20 There is no requirement that all data links be terminated simultaneously, but at a minimum, the data links MUST be able to be terminated one at a time. Furthermore, for the link verification procedure it is assumed that the nodal architecture is designed so that messages can be sent and received over any data link. Note that this requirement is trivial for opaque devices since each data link is electrically terminated and processed before being forwarded to the next opaque device, but that in transparent devices this is an additional requirement." =20 =20 =20 Best Regards, Marco Ruffini. =20 CTVR, Trinity College,=20 Dublin 2, Ireland. Phone: +353-1-608 8442 =20 ------=_NextPart_000_002B_01C5D98D.D51582A0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

I was reading the draft-ietf-ccamp-lmp-10 = document and in the paragraph 5 I found a part which is not completely clear to = me.

 

Suppose I want to verify the link connectivity between two transparent switches, A and B, where A is the node that = initiates the procedure.

-          One part of the text = asserts that “to ensure proper verification of data link connectivity, it is required = that until the data links are allocated for user traffic, they must be opaque = (i.e., lose their transparency).”: from here I understand that node B has to terminate all the ports that are not currently transmitting data (i.e. = all the ports that have not been already verified).

-          On another part I found: = “There is no requirement that all data links be terminated simultaneously, but = at a minimum, the data links MUST be able to be terminated one at a = time”: here it looks like B does not have to terminate all the not-yet-verified = ports at the same time. However in this case B may not receive a message sent = from node A over a certain link even if that link is actually connecting node = A to B (in fact the port of B relative to that link may be not terminated in = that occasion).

 

Which one is the correct interpretation? = Should node B have all the not-yet-verified ports terminated at the same time when = node A starts the link verification?

 

 

This is the text of paragraph 5 I referred = to:

“A unique characteristic of transparent = devices is that the data is

   not modified or examined in = normal operation. This characteristic

   poses a challenge for validating = the connectivity of the data links

   and establish the label = mappings. Therefore, to ensure = proper

  = ; verification of data link connectivity, it is required that = until

  = ; the data links are allocated for user traffic, they must be = opaque

  = ; (i.e., lose their transparency). To support = various degrees of

   opaqueness (e.g., examining = overhead bytes, terminating the IP

   payload, etc.), and hence = different mechanisms to transport the Test

   messages, a Verify Transport = Mechanism field is included in the

   BeginVerify and BeginVerifyAck = messages.

 

   There is no requirement that all data links be = terminated

  = ; simultaneously, but at a minimum, the data links MUST be able to = be

  = ; terminated one at a time. Furthermore, for the link verification

   procedure it is assumed that the = nodal architecture is designed so

   that messages can be sent and = received over any data link. Note that

   this requirement is trivial for = opaque devices since each data link

   is electrically terminated and = processed before being forwarded to

   the next opaque device, but that = in transparent devices this is an

   additional = requirement.”

 

 

 

Best Regards,

Marco Ruffini.

 

CTVR, Trinity College, =

Dublin = 2,

Ireland.

Phone: +353-1-608 8442

 

------=_NextPart_000_002B_01C5D98D.D51582A0-- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 25 Oct 2005 13:46:27 +0000 Message-ID: <435E369D.10301@info.ucl.ac.be> Date: Tue, 25 Oct 2005 09:43:57 -0400 From: Cristel Pelsser User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040413 Debian/1.6-5 MIME-Version: 1.0 To: Igor Bryskin CC: ccamp@ops.ietf.org Subject: Re: I-D ACTION:draft-ietf-ccamp-inter-domain-pd-path-comp-01.txt Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi Igor, all, I made some simulations with a per-domain path computation where the border node is selected by the PCE. You can find a brief description of this path computation method at http://www.info.ucl.ac.be/~cpe/pelsser_conext2005.pdf and http://www.info.ucl.ac.be/~cpe/poster_conext_cpe.pdf Cristel Igor Bryskin wrote: >Adrian, > >I understand and agree with what you are saying. My point was that a) when >PCE is available, the PCE service could be a better way for determining the >outgoing domain border node, and b) per-domain path computation could be >useful even when you have PCE service available. > >In other words I was just suggesting an alternative method for per-domain >path computation, that's all. > >Igor > >----- Original Message ----- >From: "Adrian Farrel" >To: "Igor Bryskin" ; ; "Arthi Ayyangar" > >Cc: >Sent: Friday, October 21, 2005 2:20 PM >Subject: Re: I-D ACTION:draft-ietf-ccamp-inter-domain-pd-path-comp-01.txt > > > > >>Hi Igor, >> >>I think you have to set the context of this I-D carefully, and then >>understand the limited scope that is additionally proposed. >> >>The context of the I-D is limited to the per-domain computation case. >>Hence, consulting an external PCE is out of scope. This is not to say that >>it is not valid to consult a PCE (in fact, you might expect JP and me to >>support that technique), but this I-D is demonstrating what we can do and >>how we can solve the problem without using PCE. >> >>With respect to the use of the IP reachability, you may recall that I >>raised this concern in Paris and on the list. The conclusion was that if >>you have no other way of determining an exit router for your domain, then >>attempting to use the IP reachability is no worse than giving up, and may >>be much better. >> >>In the cases you raise: >>1. Yes, an interface address may be unreachable. >> Do we lose anything by consulting IP reachability in this case? >> No. >>2. Yes, the IP reachability may give us a sub-optimal TE path. >> Is this path worse than no path? >> No. >> >>So I asked the authors to be clear that what they are suggesting has >>limitations, and should not be applied in some specific cases. I haven't >>looked at the text yet, but I hope they have covered this. >> >>Cheers, >>Adrian >>----- Original Message ----- >>From: "Igor Bryskin" >>To: ; "Arthi Ayyangar" >>Cc: >>Sent: Friday, October 21, 2005 4:27 PM >>Subject: Re: I-D ACTION:draft-ietf-ccamp-inter-domain-pd-path-comp-01.txt >> >> >> >> >>>Arthi, JP >>> >>> >>> >>>I have a problem with the auto-discovery mechanism you described in the >>>draft (one that is based on query to IGP or BGP to determine outgoing >>>ABR/ASBR). >>> >>> >>> >>>1. Destination ID must be network unique but it does not have to be IP >>>routable, for example, it could be a numbered link ID. >>> >>>2. Even in case when destination is IP address, the path computing node >>> >>> >>can >> >> >>>only obtain the ID of an ABR or ASBR that advertises IP route to the >>>destination, which would be one that knows about the shortest IP path to >>> >>> >>the >> >> >>>destination. However, it does not mean that properly constrained TE path >>>from this ABR/ASBR to the destination or the next ABR/ASBR exist, or is >>> >>> >>not >> >> >>>suboptimal compared to one from some other ABR/ASBR which knows about >>> >>> >>worse >> >> >>>IP path to the destination and hence will not be reported to the >>> >>> >>computing >> >> >>>entity by the routing sub-system. >>> >>> >>> >>>I wonder why not to use the remote PCE service for this purpose. For >>>instance a PCC may ask a PCE to determine either the ID of the outgoing >>>domain border node or entire path in terms of domain border nodes. You >>> >>> >>may >> >> >>>ask why not to request explicit path(s) in this case? Several reasons >>> >>> >>why >> >> >>>the PCC wouldn't want to do so: >>> >>> >>> >>>a) it could be easier and faster for the PCE to determine domain border >>> >>> >>node >> >> >>>in direction towards the destination rather than explicit path(s). For >>>instance, the latter may require cooperation of other PCEs; >>> >>> >>> >>>b) security considerations - PCE may not want to reveal remote domain >>>topology(ies) >>> >>> >>> >>>c) it may be desirable to compute and setup services on per-domain >>> >>> >>basis, >> >> >>>for instance, to have each domain take separate care for service >>>restoration. >>> >>> >>> >>>What do you think? >>> >>> >>> >>>Igor >>> >>> >>> >>>----- Original Message ----- >>> >>>From: >>> >>>To: >>> >>>Cc: >>> >>>Sent: Thursday, October 20, 2005 6:50 PM >>> >>>Subject: I-D ACTION:draft-ietf-ccamp-inter-domain-pd-path-comp-01.txt >>> >>> >>> >>> >>> >>>>A New Internet-Draft is available from the on-line Internet-Drafts >>>> >>>> >>>directories. >>> >>> >>>>This draft is a work item of the Common Control and Measurement Plane >>>> >>>> >>>Working Group of the IETF. >>> >>> >>>>Title : A Per-domain path computation method for establishing >>>> Inter-domain Traffic Engineering (TE) Label >>>> >>>> >>>Switched Paths (LSPs) >>> >>> >>>>Author(s) : J. Vasseur, et al. >>>>Filename : draft-ietf-ccamp-inter-domain-pd-path-comp-01.txt >>>>Pages : 18 >>>>Date : 2005-10-20 >>>> >>>>This document specifies a per-domain path computation technique for >>>>establishing inter-domain Traffic Engineering (TE) Multiprotocol Label >>>>Switching (MPLS) and Generalized MPLS (GMPLS) Label Switched Paths >>>>(LSPs). In this document a domain refers to a collection of network >>>>elements within a common sphere of address management or path >>>>computational responsibility such as IGP areas and Autonomous Systems. >>>> >>>>Per-domain computation applies where the full path of an inter-domain >>>>TE LSP cannot be or is not determined at the ingress node of the TE >>>>LSP, and is not signaled across domain boundaries. This is most likely >>>>to arise owing to TE visibility limitations. The signaling message >>>>indicates the destination and nodes up to the next domain boundary. It >>>>may also indicate further domain boundaries or domain identifiers. The >>>>path through each domain, possibly including the choice of exit point >>>>from the domain, must be determined within the domain. >>>> >>>>A URL for this Internet-Draft is: >>>> >>>> >>>> >http://www.ietf.org/internet-drafts/draft-ietf-ccamp-inter-domain-pd-path-comp-01.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-inter-domain-pd-path-comp-01.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-inter-domain-pd-path-comp-01.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. >>>> >>>> >>>> >>> >>> >>> >>> > > > Envelope-to: ccamp-data@psg.com Delivery-date: Sun, 23 Oct 2005 13:51:58 +0000 Message-ID: <435B5845.2040502@chello.nl> Date: Sun, 23 Oct 2005 11:30:45 +0200 From: Huub van Helvoort User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) MIME-Version: 1.0 To: ccamp Subject: Re: draft-bernstein-ccamp-gmpls-vcat-lcas-01 comments - 3rd try Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Thanks Adrian, > Huub, I don't see them in the spam bucket, but given the rate of arrival > of new spam it is possible they went out the over flow before I got there > :-( > > Please post again. OK, the resend with attachment did not work, this time in-line without diff-marks. My comments are based on ITU-T recommendation G.806 clause 10 and appendix VII. This may be a good reference to add at the end of the draft. If you need more information, please feel free to ask me or read all about VCAT, LCAS (and GFP) in my book: "Next generation SDH/SONET: Evolution or Revolution?" John Wiley & Sons ISBN: 0-470-09120-7 Cheers, Huub. ================================================================ http://members.chello.nl/hhelvoort ================================================================ Always remember that you are unique...just like everyone else... @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ CCAMP working Group G. Bernstein Internet-Draft Grotto Networking Expires: April 14, 2006 D. Caviglia Marconi R. Rabbat Fujitsu October 11, 2005 Operating Virtual concatenation (VCAT) and the Link Capacity Adjustment Scheme (LCAS) with Generalized Multi-Protocol Label Switching (GMPLS) draft-bernstein-ccamp-gmpls-vcat-lcas-01 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 14, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This document describes the use of the Generalized Multi-Protocol Label Switching (GMPLS) control plane in conjunction with the Virtual Concatenation (VCAT) layer 1 inverse multiplexing mechanism and its companion Link Capacity Adjustment Scheme (LCAS) which can be used Bernstein, et al. Expires April 14, 2006 [Page 1] Internet-Draft GMPLS, VCAT and LCAS October 2005 for hitless dynamic resizing of the inverse multiplex group. These techniques apply to the Optical Transport Network (OTN), Synchronous Optical Network (SONET), Synchronous Digital Hierarchy (SDH) and Plesiochronous Digital Hierarchy (PDH) signals. Table of Contents 1. Overview of VCAT and LCAS . . . . . . . . . . . . . . . . . . 3 1.1. VCAT signals and components . . . . . . . . . . . . . . . 3 1.2. VCAT Capabilities and Limitations . . . . . . . . . . . . 3 1.3. The LCAS Protocol . . . . . . . . . . . . . . . . . . . . 4 2. Problem Statement and Current Support . . . . . . . . . . . . 5 2.1. Discovery of Enabled End Systems . . . . . . . . . . . . . 5 2.2. Client to End Point Mappings . . . . . . . . . . . . . . . 5 2.3. VCAT configuration without LCAS . . . . . . . . . . . . . 6 2.4. VCAT configuration with LCAS . . . . . . . . . . . . . . . 7 2.5. Component Signal Configuration Scenarios . . . . . . . . . 8 3. Possible Extensions to GMPLS to support additional VCAT/LCAS scenarios . . . . . . . . . . . . . . . . . . . . . 10 3.1. Mechanisms for Discovery of VCAT/LCAS . . . . . . . . . . 10 3.2. Mechanism to Support Multiple Client to End Point Mappings . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.3. Support for Component Signal Configuration Scenarios . . . 10 4. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 Intellectual Property and Copyright Statements . . . . . . . . . . 14 Bernstein, et al. Expires April 14, 2006 [Page 2] Internet-Draft GMPLS, VCAT and LCAS October 2005 1. Overview of VCAT and LCAS Virtual Concatenation (VCAT) is a standardized layer 1 inverse multiplexing technique that can be applied to OTN [6], SONET [3], SDH [2], and PDH [5] component signals. By inverse multiplexing we mean a method that combines multiple links at a particular layer into an aggregate link to achieve a commensurate bandwidth capacity on that aggregate link. More formally, VCAT essentially combines the payload bandwidth of multiple path layer network signals (or trails) to support a single client (e.g. Ethernet) layer link. For a more detailed introduction see [1]. 1.1. VCAT signals and components In the following we will use SDH terminology rather than both SONET and SDH terminology. In SDH Virtual Concatenation (VCAT) can be applied to the following component time division multiplex (TDM) signals referred to as Virtual Containers (VCs): VC-11, VC-12, VC-2, VC-3, and VC-4. Only like component signals can be aggregated into a VCAT group (VCG). These VCGs are respectively known as: VC-11-Xv, VC-12-Xv, VC-2-Xv, VC-3-Xv, and VC-4-Xv. In the previous designations X is an integer indicating the number of members in the VCG. The value of X for high order VCs (VC-3 and VC-4)can be from 1 to 256; and for low order VCs (VC-11 VC-12 and VC-2) the value of X can be 1 to 64. See [2] for details. VCAT can be applied to the following PDH signals as specified in reference [5]: DS1,E1, E3, DS3. Similar to the SONET/SDH case these component signals can only be combined with like signals to produce aggregates. For some reason the VCGs of the PDH signals were not given unique designations in [5] so we shall adopt a similar notation to the SDH VCAT signals for the permitted PDH VCAT signals that follow: DS1-Xv, E1-Xv, E3-Xv, DS3-Xv. Concatenation in the optical transport network (OTN) is realized by means of virtual concatenation of Optical Channel Payload Unit (OPU) signals. OPUk signals (k=1, 2, 3) can be concatenated into OPUk-Xv aggregates with X= 1,..., 256. See reference [6] for details. 1.2. VCAT Capabilities and Limitations VCAT performs inverse multiplexing by octet/byte de-interleaving of the encapsulated client bit stream into the individual VCs of the VCG and the VCs are transported across the network independently from each other. Due to the possible different propagation times of the VCs, a differential delay may occur between the individual VCs at the path termination. This differential delay has to be compensated and the VCs have to be realigned. This is summarized for the different signal types in reference [1] with details given in the respective standards documents [2] [3]. Bernstein, et al. Expires April 14, 2006 [Page 3] Internet-Draft GMPLS, VCAT and LCAS October 2005 1.3. The LCAS Protocol The Link Capacity Adjustment Scheme for VCAT signals is a protocol for dynamically and hitlessly changing (i.e., increasing and decreasing) the capacity of a VCG. LCAS also provides survivability capabilities, automatically decreasing the capacity if a member of the VCG experiences a failure in the network, and increasing the capacity when the network fault is repaired. LCAS, itself, provides a mechanism for interworking between LCAS and non-LCAS VCAT end points. VCAT does not require LCAS for its operation. LCAS functionality does not overlap or conflict with GMPLS' routing or signaling functionality for the establishment of component links or entire VCGs. LCAS instead is used to control whether a particular component signal is actually put into service carrying traffic for the VCG. LCAS provides for graceful degradation of failed links by having the sink end(s) report back the receive status of all member components. In the case of a reported member failure, the source end will stop using the failed member and distribute the data over the remaining ‘good’ members, thus transmission is restored to a reduced bandwidth capacity. The source end will send an LCAS message to the sink end that it is not transmitting data on that failed member. The worst case notification times are summarized in [1]. Bernstein, et al. Expires April 14, 2006 [Page 4] Internet-Draft GMPLS, VCAT and LCAS October 2005 2. Problem Statement and Current Support In this section we list a number of VCAT/LCAS usage scenarios and their current level of support. We will evaluate the applicability of GMPLS to these scenarios and for those scenarios that GMPLS does not currently support we describe possible GMPLS extensions in Section 3. Note the term "component" signal in the text is used as a simplified notion to the more formal concepts of VC-n, ODUk, and PDH termination function as well as VC-n, ODUk and PDH path/trail. 2.1. Discovery of Enabled End Systems Discovering VCAT: VCAT sources can only communicate with VCAT capable sinks. Hence the VCAT capabilities of a PDH, SDH, or OTN path termination points need to be known. Currently no support for discovery of VCAT or LCAS apriori, i.e., via routing information. Support for "discovery" of VCAT capability at connection establishment time via signaling, i.e., we can request VCAT connection and if the end system cannot support it,it would refuse the connection. TBD -- is there a specific error code concerning "VCAT not supported". Discovering LCAS: LCAS offers additional functionality between VCAT capable sources and sinks. Hence the LCAS capabilities of VCAT enabled path termination points can be useful to know in advance of component signal setup. Currently there is no mechanism to ask for an LCAS enabled end point nor is there a way to find out if the other end is LCAS enabled until after the connection is established. This is a problem if we specifically want hitless dynamic resizing or fast graceful degradation for a VCG. 2.2. Client to End Point Mappings Fixed Client to End point Mapping: Per client signal there is a VC-n-Xv circuit in which the X VC-n termination points are dedicated to this client signal. At any point in time, Xa (active members) out of Xp (provisioned members) VC-n termination points may be set up to carry client traffic. For example when VCAT is deployed on a Router, the VCG connects directly to one STM-N interface port (in absence of a HO or LO switch fabric in the router). The transport network may then transport the individual VCs via one or more routes. Diverse routing will incur a differtial delay. Bernstein, et al. Expires April 14, 2006 [Page 5] Internet-Draft GMPLS, VCAT and LCAS October 2005 Variable Client to End point Mapping: For a set of M client signals there are M*VC-n-Xv VCAT endpoints sharing a set of N (N>M) VC-n termination points. It is possible that M*X > N (example: M=10, X=7, N=64); i.e. there may be a kind of overbooking. Implication: must be able to accommodate multiple different sized VCGs at an "interface". For example an STM-64 interface can support many different VC-4-Xv groups, providing the total number of VCs does not exceed the interface total capacity. Implications: In both these cases we can have more than one VCG per GMPLS link. In general it is the responsibility of the signaling entity at the source and destination ends to choose the appropriate VC-n termination points for the VCG and in the case of "variable client mapping" to perform needed internal configuration. However multiple VCGs per GMPLS link or GMPLS addressed entity introduces an unresolvable ambiguity when disjoint connections are set up or dynamic resizing is applied since there is currently no "VCG identifier" in GMPLS signaling. 2.3. VCAT configuration without LCAS (MI_LCASEnable=false) Base Configuration: For VCAT to operate the sink end needs to be informed of how many components are in the VCG. It has no other way of knowing if it is currently receiving all components intended to be in the group. Fixed sized co-routed groups are supported with current GMPLS signaling. Diversely routed groups are not currently supported. Group Resizing: Additions or removals of components from a non-LCAS VCG are not hitless, that is data loss will occur while the source and sink are reprovisioned as to the number of members in the group. Currently not supported within GMPLS. In particular, with each addition or removal of a component the sink end point needs to be told the expected number of components in the group. Failure Conditions: Failure of a component must detected external to VCAT system. The entire group is rendered inoperable until the failed component is taken out of service (or replaced) by re-provisioning both source and sink to that effect. Currently not supported within GMPLS. The source and sink need to be told what component has failed and remove it from service. Bernstein, et al. Expires April 14, 2006 [Page 6] Internet-Draft GMPLS, VCAT and LCAS October 2005 2.4. VCAT configuration with LCAS (MI_LCASEnable=true) Base Configuration: Sink end (and source end) are first configured with the value of Xp (the provisioned number of members), out of Xm (the technology specific maximum number of members) with Xm ³ Xp. LCAS then determines automatically the number of active members Xa and puts them into service for the group. NOTE: The value of Xm is not only technology dependent, it can also be implementation dependent. E.g. in a routerinterface with STM-64 line rate for a VC-4-Xv based VCG Xm = 64 and not 256. Xm cannot be provisioned, it can be retreived from the VCG (as well as Xa). Currently both co-routed and diversely routed VCGs can be supported if there is no VCG ambiguity. Component Addition: When a new component signal has to be added to a VCG the following procedure applies. 1. Establish a connection from Source to Sink for the member to be added. 2. Provision the Source to use the ‘new’ member as one of the active group (Xp -> Xp+1). This entails sending the ADD command by the new member. 3. Provision the Sink to recognize the ‘new’ member of the VCG (Xp -> Xp+1). The order of doing the above is not important. When the ADD command is received by the sink it will return an ‘OK’ to the Source at which time the Source will use all active members (old + new) to transport the client traffic. This procedure does not affect the already established LCAS members, that is, client traffic is not sent on the new component until the LCAS procedure is complete; This can be supported within GMPLS if, after GMPLS has successfully established a potential new component, the source end LCAS is (internally) told to add it to the group. Component Removal: When a component is removed the following procedure applies: 1. On receipt of a remove command (for a particular member) from the management system, LCAS Source will stop using that member; the Sink will recognize that that member no longer carrier client traffic and will use only the remaining members to reconstitute the client signal. Note: The current LCAS protocol allows for the ‘decrease’ command to be initiated at either the LCAS source or the LCAS sink; if it is initiated at the sink there will be a hit to the reconstructed data. 2. The connection, source provisioning and sink provisioning of that member can then be removed from the VCG. Bernstein, et al. Expires April 14, 2006 [Page 7] Internet-Draft GMPLS, VCAT and LCAS October 2005 3. The component connection can be, if needed, removed from the transport network. This can be supported within GMPLS if, before GMPLS tears down a component, LCAS is told (local to source end) to remove the component from service in the group. Component Failure: When a component fails: 1. The LCAS sink detects the failure (how this is done is outside the scope of this ID) and informs the source of this failure via the member status (MST)information. : 2. The source then takes the failed component out of service and uses only the remaining ‘good’ members to transport the client traffic (Xa -> Xa-1). Note: No re-sequencing of the VCG is done at this time. When the failed component is repaired, LCAS can automatically add the repaired component back to the group, or alternatively a new component can be added to bring the group back to its original size. Note that component failure is not hitless, but note the fast notification times of [BernDiegoRabbat]. Currently supported since no action required of GMPLS. 2.5. Component Signal Configuration Scenarios Here we use the term "group" to refer to the entire VCG and the terminology "set" and "subset" to refer to the collection of potential VCG member signals. Note that all assesments of whether a scenario is currently supported assumes either (a) a single VCG per GMPLS addressable entity, or (b) a mechanism is in place to disambiguate multiple VCGs (see Section 2.2). Fixed, Co-routed: A fixed bandwidth VCG, with all members transported over the same route. This is the case where the intended bandwidth of the VCG does not change and all member signals follow the same route. The intent here is the capability to allocate the "right" amount of bandwidth. Currently supported in GMPLS. Fixed, Diverse-routes: A fixed bandwidth VCG, with the members transported over at least two different routes. The intent here is additional resilience and graceful degradation in the case of failure. Bernstein, et al. Expires April 14, 2006 [Page 8] Internet-Draft GMPLS, VCAT and LCAS October 2005 If LCAS is present this scenario is supported under GMPLS. Not supported without LCAS since we need two-way communications of some type between source and sink to coordinate which members are to be used in the group in a failure scenario. Dynamic, Co-routed: A dynamic VCG (bandwidth can be increased or decreased via the addition or removal of member signals), with all the members transported over the same route. Intent here is dynamic sizing of bandwidth. If LCAS present this scenario is currently supported by GMPLS. Implications: LCAS is needed for hitless resizing. Note before LCAS can do its part of getting traffic over the modified VCG, the two VCAT/LCAS endpoints need to be configured (Xp -> Xp+1 or Xp -> Xp-1); this requires either "communication" between the two endpoints (when one of the endpoints is configured by call/ connection controller, or simple communication of the call/ connection controller with both endpoints. Without LCAS we still need two way communications between source and sink to coordinate which members are used in the group and changes will not be hitless. Dynamic, Diverse-routes: A dynamic VCG, with the members transported over at least two different routes. Intent here is dynamic resizing and resilience. Currently support and implications similar to the "dynamic, co- routed" and "fixed, diverse-routes" cases. Shared Pool: Two or more VCGs between the same source and sink who desire to share a pool of component signals between them. Each VCG may have a dedicated set of members, and may also obtain additional members from a "common pool" of components. Note that at any given point in time a component signal can belong to at most one VCG. The intent here is to allow dynamic resizing of VCGs via the sharing of a pool of established component signals without requiring complete circuit provisioning, i.e., only the group membership of the component signal would change. Currently not supported by GMPLS. Implications: a communications mechanism between source and sink to indicate during a "change" which group a component should now belong. Bernstein, et al. Expires April 14, 2006 [Page 9] Internet-Draft GMPLS, VCAT and LCAS October 2005 3. Possible Extensions to GMPLS to support additional VCAT/LCAS scenarios Here we look at what might be reasonable to add to GMPLS to support the interest scenarios of Section 2 that were not currently covered. 3.1. Mechanisms for Discovery of VCAT/LCAS Would like to get both VCAT and LCAS capability of end systems via routing... Would like to be able to specifically ask for LCAS capability via signaling... 3.2. Mechanism to Support Multiple Client to End Point Mappings This is a very important capability and it is very similar to one that is being proposed in the end-to-end signaling for recovery I-D. In particular the ASSOCIATION object. Note, however, since there is a rather high probability that at some point we might use VCAT/LCAS with GMPLS based protection we would really need an ASSOCIATION object type specific to VCAT. Association objects are not unique and therefore adding a new type to the Association object would make it a good candidate to support this requirement. 3.3. Support for Component Signal Configuration Scenarios TBD based on analysis of use of admin-status object. If the admin- status object is sufficient we will detail its use in this application since it is currently an optional object. 4. References [1] Bernstein, G., Caviglia, D., and R. Rabbat, "VCAT/LCAS in a Clamshell", To Be Published available at http:// www.grotto-networking.com/pages/VCAT-in-a-Clamshell-DRAFT.pdf, October 2005. [2] International Telecommunications Union, "Network node interface for the synchronous digital hierarchy (SDH)", ITU- T Recommendation G.707, December 2003. [3] American National Standards Institute, "Synchronous Optical Network (SONET) - Basic Description including Multiplex Structure, Rates, and Formats", ANSI T1.105-2001, 2001. [4] "Link capacity adjustment scheme (LCAS) for virtual concatenated signals", ITU-T Recommendation G.7042, February 2004. Bernstein, et al. Expires April 14, 2006 [Page 10] Internet-Draft GMPLS, VCAT and LCAS October 2005 [5] "Virtual concatenation of plesiochronous digital hierarchy (PDH) signals", ITU-T Recommendation G.7043, July 2004. [6] "Interfaces for the Optical Transport Network (OTN)", ITU- T Recommendation G.709, March 2003. [7] Sklower, K., Lloyd, B., McGregor, G., Carr, D., and T. Coradetti, "The PPP Multilink Protocol (MP)", RFC 1990, August 1996. [8] "Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Specific requirements - Part 3: Carrier sense multiple access with collision detection (CSMA/CD) access method and physical layer specifications", IEEE Standard 802.3, March 2002. [9] Bernstein, G., Rajagopalan, B., and D. Saha, "Optical Network Control: Archtecture, Protocols", Addison-Wesley, 2004. Bernstein, et al. Expires April 14, 2006 [Page 11] Internet-Draft GMPLS, VCAT and LCAS October 2005 Appendix A. Acknowledgements The authors would like to thank Maarten Vissers for extensive reviews and contributions to this draft. Bernstein, et al. Expires April 14, 2006 [Page 12] Internet-Draft GMPLS, VCAT and LCAS October 2005 Authors' Addresses Greg Bernstein Grotto Networking Phone: +1 510 573 2237 Email: gregb@grotto-networking.com Diego Caviglia Marconi Email: Diego.Caviglia@marconi.com Richard Rabbat Fujitsu Phone: +1 408 530 4537 Email: richard@us.fujitsu.com Bernstein, et al. Expires April 14, 2006 [Page 13] Internet-Draft GMPLS, VCAT and LCAS October 2005 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Bernstein, et al. Expires April 14, 2006 [Page 14] Envelope-to: ccamp-data@psg.com Delivery-date: Sun, 23 Oct 2005 02:11:39 +0000 Message-ID: <041601c5d720$167419c0$ca00470a@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Huub van Helvoort" , Subject: Re: draft-bernstein-ccamp-gmpls-vcat-lcas-01 comments - delay Date: Sat, 22 Oct 2005 16:45:46 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Huub, I don't see them in the spam bucket, but given the rate of arrival of new spam it is possible they went out the over flow before I got there :-( Please post again. In general, attachments can be a bit risky as they are more likely to be excised. In line text is better. Cheers, Adrian ----- Original Message ----- From: "Huub van Helvoort" To: Sent: Saturday, October 22, 2005 10:24 AM Subject: Re: draft-bernstein-ccamp-gmpls-vcat-lcas-01 comments - delay > FYI, > > before sending the email quoted below I already did send > two other emails, one with comments and the other with the > forgotten attachment. Without the attachment the comment > below is worthless. > > Sofar these messages have not appeared on the ccamp list > (but they did on the SG15/Q9 and SG15/Q11 lists). > > So maybe they are in the ccamp spam-trap. > If they do not re-appear soon I will repost them. > Sorry for the inconvenience. > > regards, Huub. > =============================================================== > Huub van Helvoort wrote: > > > Hello Greg et al, > > > > One additional comment: > > > > Depending on the level of detail to be provided in this document. > > > > In section 2.4 VCAT configuration with LCAS (MI_LCASEnable=true) > > > > The value of Xm is not only technology dependent, it can also be > > implementation dependent. E.g. in a routerinterface with STM-64 > > line rate for a VC-4-Xv based VCG Xm = 64 and not 256. > > Xm cannot be provisioned, it can be retreived from the VCG > > (as well as Xa). > > > > Have a nice weekend, Huub. > > > > -- > ================================================================ > http://members.chello.nl/hhelvoort/ > ================================================================ > Always remember that you are unique...just like everyone else... > > > Envelope-to: ccamp-data@psg.com Delivery-date: Sat, 22 Oct 2005 21:07:25 +0000 Message-ID: <435AA948.8070409@psg.com> Date: Sat, 22 Oct 2005 23:04:08 +0200 From: dimitri papadimitriou Reply-To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.11) Gecko/20050728 MIME-Version: 1.0 To: Adrian Farrel CC: Igor Bryskin , jpv@cisco.com, Arthi Ayyangar , ccamp@ops.ietf.org Subject: Re: I-D ACTION:draft-ietf-ccamp-inter-domain-pd-path-comp-01.txt Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit hi, i have specific comments - on the kernel section of this document (starting at section 4) " - If the domain is PSC (Packet Switch Capable) and uses in-band control channel " which domain ? and how to ensure the sequence of domains to reach the "next-hop" are satisfying this constraint ? "If the next-hop is reachable, then it SHOULD find a domain boundary LSR (domain boundary point) to get to the next-hop. The determination of domain boundary point based on routing information is what we term as "auto-discovery" in this document. In the absence of such an auto-discovery mechanism, a) the ABR in the case of inter-area TE or the ASBR in the next-hop AS in the case of inter-AS TE should be the signaled loose next-hop in the ERO and hence should be accessible via the TED" i don't understand the "the signaled loose next-hop in the ERO and hence should be accessible via the TED" would it be possible to clarify ? i have some troubles to understand the sentence: the ingress ASBR receives a ERO being e.g. a collection of ASs and then performs expansion e.g. strict route until the head-end ABR and then loose-hop until the tail-end ASBR within that AS but the latter will not necessarily be in the TED; still the procedure works this is classical loose routing; hence, the process shall be defined such as being recursive, and the "signaled loose next-hop" must be process as the initial "non-TE reachable but IP reachable next-hop" by the head-end ABR receiving the incoming ERO on the other side, what is the specific "auto-discovery" mechanism ? and what is the "domain boundary point" ? the concern i have here is that the default loose routing case appears like the particular case when not delivering a mechanism which is not specified ? the document should be constructed such that the process can provide BASE loose routing computation (local domain strict routing based on TE information and loose routing based on IP reachability) and allow for accommodating additional mechanism (and so information) when possible not the other way around; thanks for clarifying, ps: what the purpose of sections 3.2, 3.3, 4.1, and 4.2 ? - dimitri. Adrian Farrel wrote: > Hi Igor, > > I think you have to set the context of this I-D carefully, and then > understand the limited scope that is additionally proposed. > > The context of the I-D is limited to the per-domain computation case. > Hence, consulting an external PCE is out of scope. This is not to say that > it is not valid to consult a PCE (in fact, you might expect JP and me to > support that technique), but this I-D is demonstrating what we can do and > how we can solve the problem without using PCE. > > With respect to the use of the IP reachability, you may recall that I > raised this concern in Paris and on the list. The conclusion was that if > you have no other way of determining an exit router for your domain, then > attempting to use the IP reachability is no worse than giving up, and may > be much better. > > In the cases you raise: > 1. Yes, an interface address may be unreachable. > Do we lose anything by consulting IP reachability in this case? > No. > 2. Yes, the IP reachability may give us a sub-optimal TE path. > Is this path worse than no path? > No. > > So I asked the authors to be clear that what they are suggesting has > limitations, and should not be applied in some specific cases. I haven't > looked at the text yet, but I hope they have covered this. > > Cheers, > Adrian > ----- Original Message ----- > From: "Igor Bryskin" > To: ; "Arthi Ayyangar" > Cc: > Sent: Friday, October 21, 2005 4:27 PM > Subject: Re: I-D ACTION:draft-ietf-ccamp-inter-domain-pd-path-comp-01.txt > > > >>Arthi, JP >> >> >> >>I have a problem with the auto-discovery mechanism you described in the >>draft (one that is based on query to IGP or BGP to determine outgoing >>ABR/ASBR). >> >> >> >>1. Destination ID must be network unique but it does not have to be IP >>routable, for example, it could be a numbered link ID. >> >>2. Even in case when destination is IP address, the path computing node > > can > >>only obtain the ID of an ABR or ASBR that advertises IP route to the >>destination, which would be one that knows about the shortest IP path to > > the > >>destination. However, it does not mean that properly constrained TE path >>from this ABR/ASBR to the destination or the next ABR/ASBR exist, or is > > not > >>suboptimal compared to one from some other ABR/ASBR which knows about > > worse > >>IP path to the destination and hence will not be reported to the > > computing > >>entity by the routing sub-system. >> >> >> >>I wonder why not to use the remote PCE service for this purpose. For >>instance a PCC may ask a PCE to determine either the ID of the outgoing >>domain border node or entire path in terms of domain border nodes. You > > may > >>ask why not to request explicit path(s) in this case? Several reasons > > why > >>the PCC wouldn't want to do so: >> >> >> >>a) it could be easier and faster for the PCE to determine domain border > > node > >>in direction towards the destination rather than explicit path(s). For >>instance, the latter may require cooperation of other PCEs; >> >> >> >>b) security considerations - PCE may not want to reveal remote domain >>topology(ies) >> >> >> >>c) it may be desirable to compute and setup services on per-domain > > basis, > >>for instance, to have each domain take separate care for service >>restoration. >> >> >> >>What do you think? >> >> >> >>Igor >> >> >> >>----- Original Message ----- >> >>From: >> >>To: >> >>Cc: >> >>Sent: Thursday, October 20, 2005 6:50 PM >> >>Subject: I-D ACTION:draft-ietf-ccamp-inter-domain-pd-path-comp-01.txt >> >> >> >> >>>A New Internet-Draft is available from the on-line Internet-Drafts >> >>directories. >> >>>This draft is a work item of the Common Control and Measurement Plane >> >>Working Group of the IETF. >> >>>Title : A Per-domain path computation method for establishing >>> Inter-domain Traffic Engineering (TE) Label >> >>Switched Paths (LSPs) >> >>>Author(s) : J. Vasseur, et al. >>>Filename : draft-ietf-ccamp-inter-domain-pd-path-comp-01.txt >>>Pages : 18 >>>Date : 2005-10-20 >>> >>>This document specifies a per-domain path computation technique for >>>establishing inter-domain Traffic Engineering (TE) Multiprotocol Label >>>Switching (MPLS) and Generalized MPLS (GMPLS) Label Switched Paths >>>(LSPs). In this document a domain refers to a collection of network >>>elements within a common sphere of address management or path >>>computational responsibility such as IGP areas and Autonomous Systems. >>> >>>Per-domain computation applies where the full path of an inter-domain >>>TE LSP cannot be or is not determined at the ingress node of the TE >>>LSP, and is not signaled across domain boundaries. This is most likely >>>to arise owing to TE visibility limitations. The signaling message >>>indicates the destination and nodes up to the next domain boundary. It >>>may also indicate further domain boundaries or domain identifiers. The >>>path through each domain, possibly including the choice of exit point >>>from the domain, must be determined within the domain. >>> >>>A URL for this Internet-Draft is: >>> >> > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-inter-domain-pd-path-comp-01.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-inter-domain-pd-path-comp-01.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-inter-domain-pd-path-comp-01.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. >>> >> >> >> >> > > > > . > Envelope-to: ccamp-data@psg.com Delivery-date: Sat, 22 Oct 2005 09:25:23 +0000 Message-ID: <435A0545.5000902@chello.nl> Date: Sat, 22 Oct 2005 11:24:21 +0200 From: Huub van Helvoort User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) MIME-Version: 1.0 To: ccamp@ops.ietf.org Subject: Re: draft-bernstein-ccamp-gmpls-vcat-lcas-01 comments - delay Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit FYI, before sending the email quoted below I already did send two other emails, one with comments and the other with the forgotten attachment. Without the attachment the comment below is worthless. Sofar these messages have not appeared on the ccamp list (but they did on the SG15/Q9 and SG15/Q11 lists). So maybe they are in the ccamp spam-trap. If they do not re-appear soon I will repost them. Sorry for the inconvenience. regards, Huub. =============================================================== Huub van Helvoort wrote: > Hello Greg et al, > > One additional comment: > > Depending on the level of detail to be provided in this document. > > In section 2.4 VCAT configuration with LCAS (MI_LCASEnable=true) > > The value of Xm is not only technology dependent, it can also be > implementation dependent. E.g. in a routerinterface with STM-64 > line rate for a VC-4-Xv based VCG Xm = 64 and not 256. > Xm cannot be provisioned, it can be retreived from the VCG > (as well as Xa). > > Have a nice weekend, Huub. > -- ================================================================ http://members.chello.nl/hhelvoort/ ================================================================ Always remember that you are unique...just like everyone else... Envelope-to: ccamp-data@psg.com Delivery-date: Sat, 22 Oct 2005 08:03:25 +0000 Message-ID: <4359F1DB.1010504@chello.nl> Date: Sat, 22 Oct 2005 10:01:31 +0200 From: Huub van Helvoort User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) MIME-Version: 1.0 To: ccamp@ops.ietf.org CC: tsg15q11@itu.int, tsg15q9@itu.int Subject: Re: draft-bernstein-ccamp-gmpls-vcat-lcas-01 comments Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hello Greg et al, One additional comment: Depending on the level of detail to be provided in this document. In section 2.4 VCAT configuration with LCAS (MI_LCASEnable=true) The value of Xm is not only technology dependent, it can also be implementation dependent. E.g. in a routerinterface with STM-64 line rate for a VC-4-Xv based VCG Xm = 64 and not 256. Xm cannot be provisioned, it can be retreived from the VCG (as well as Xa). Have a nice weekend, Huub. -- ================================================================ http://members.chello.nl/hhelvoort/ ================================================================ Always remember that you are unique...just like everyone else... Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 21 Oct 2005 20:00:50 +0000 Message-ID: <010201c5d679$ec6f9650$6601a8c0@movaz.com> From: "Igor Bryskin" To: "Adrian Farrel" , , "Arthi Ayyangar" Cc: Subject: Re: I-D ACTION:draft-ietf-ccamp-inter-domain-pd-path-comp-01.txt Date: Fri, 21 Oct 2005 15:59:18 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Adrian, On a closer look: > In the cases you raise: > 1. Yes, an interface address may be unreachable. > Do we lose anything by consulting IP reachability in this case? > No. This is not what I was talking about, which was a destination located in some remote domain and TE reachable to the source while not IP routable (because destination is a numbered link ID, this is a very usual case in a multi-area GMPLS non-packet network). The only guy who would know about such destination is a PCE with sufficient TE visibility. There is no point in such case to consult IP routing and we do loose by doing so rather than consulting PCE (provided, of course, that PCE is available) > 2. Yes, the IP reachability may give us a sub-optimal TE path. > Is this path worse than no path? > No. Again, the path provided by IP has nothing to do with the TE path, and PCE is certainly in a better position to provide (albeit loose) path specifying a list of proper border nodes or just the next border node. The bottom line: when PCE is available one should never consult IP routing to determine the outgoing border node when one performs per-domain path computation. If PCE is not available, than in case of IP network, I agree, there is a value to consult IP routing. This is because in IP world TE resources are still tightly coupled with IP interfaces. In the non-IP world, I'd say, consulting IP routing makes much lesser sense: it could give you a path when no TE path exists or, more importantly, fail the request when one or more TE paths do exist. I'd suggest in this case rather than consulting IP (which is as useful IMO as consulting somebody's Outlook address book) to route the LSP towards any known domain border node and hope that the latter will crankback the request specifying the proper border node if necessary. Cheers, Igor ----- Original Message ----- From: "Adrian Farrel" To: "Igor Bryskin" ; ; "Arthi Ayyangar" Cc: Sent: Friday, October 21, 2005 2:20 PM Subject: Re: I-D ACTION:draft-ietf-ccamp-inter-domain-pd-path-comp-01.txt > Hi Igor, > > I think you have to set the context of this I-D carefully, and then > understand the limited scope that is additionally proposed. > > The context of the I-D is limited to the per-domain computation case. > Hence, consulting an external PCE is out of scope. This is not to say that > it is not valid to consult a PCE (in fact, you might expect JP and me to > support that technique), but this I-D is demonstrating what we can do and > how we can solve the problem without using PCE. > > With respect to the use of the IP reachability, you may recall that I > raised this concern in Paris and on the list. The conclusion was that if > you have no other way of determining an exit router for your domain, then > attempting to use the IP reachability is no worse than giving up, and may > be much better. > > In the cases you raise: > 1. Yes, an interface address may be unreachable. > Do we lose anything by consulting IP reachability in this case? > No. > 2. Yes, the IP reachability may give us a sub-optimal TE path. > Is this path worse than no path? > No. > > So I asked the authors to be clear that what they are suggesting has > limitations, and should not be applied in some specific cases. I haven't > looked at the text yet, but I hope they have covered this. > > Cheers, > Adrian > ----- Original Message ----- > From: "Igor Bryskin" > To: ; "Arthi Ayyangar" > Cc: > Sent: Friday, October 21, 2005 4:27 PM > Subject: Re: I-D ACTION:draft-ietf-ccamp-inter-domain-pd-path-comp-01.txt > > > > Arthi, JP > > > > > > > > I have a problem with the auto-discovery mechanism you described in the > > draft (one that is based on query to IGP or BGP to determine outgoing > > ABR/ASBR). > > > > > > > > 1. Destination ID must be network unique but it does not have to be IP > > routable, for example, it could be a numbered link ID. > > > > 2. Even in case when destination is IP address, the path computing node > can > > only obtain the ID of an ABR or ASBR that advertises IP route to the > > destination, which would be one that knows about the shortest IP path to > the > > destination. However, it does not mean that properly constrained TE path > > from this ABR/ASBR to the destination or the next ABR/ASBR exist, or is > not > > suboptimal compared to one from some other ABR/ASBR which knows about > worse > > IP path to the destination and hence will not be reported to the > computing > > entity by the routing sub-system. > > > > > > > > I wonder why not to use the remote PCE service for this purpose. For > > instance a PCC may ask a PCE to determine either the ID of the outgoing > > domain border node or entire path in terms of domain border nodes. You > may > > ask why not to request explicit path(s) in this case? Several reasons > why > > the PCC wouldn't want to do so: > > > > > > > > a) it could be easier and faster for the PCE to determine domain border > node > > in direction towards the destination rather than explicit path(s). For > > instance, the latter may require cooperation of other PCEs; > > > > > > > > b) security considerations - PCE may not want to reveal remote domain > > topology(ies) > > > > > > > > c) it may be desirable to compute and setup services on per-domain > basis, > > for instance, to have each domain take separate care for service > > restoration. > > > > > > > > What do you think? > > > > > > > > Igor > > > > > > > > ----- Original Message ----- > > > > From: > > > > To: > > > > Cc: > > > > Sent: Thursday, October 20, 2005 6:50 PM > > > > Subject: I-D ACTION:draft-ietf-ccamp-inter-domain-pd-path-comp-01.txt > > > > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > > This draft is a work item of the Common Control and Measurement Plane > > Working Group of the IETF. > > > > > > Title : A Per-domain path computation method for establishing > > > Inter-domain Traffic Engineering (TE) Label > > Switched Paths (LSPs) > > > Author(s) : J. Vasseur, et al. > > > Filename : draft-ietf-ccamp-inter-domain-pd-path-comp-01.txt > > > Pages : 18 > > > Date : 2005-10-20 > > > > > > This document specifies a per-domain path computation technique for > > > establishing inter-domain Traffic Engineering (TE) Multiprotocol Label > > > Switching (MPLS) and Generalized MPLS (GMPLS) Label Switched Paths > > > (LSPs). In this document a domain refers to a collection of network > > > elements within a common sphere of address management or path > > > computational responsibility such as IGP areas and Autonomous Systems. > > > > > > Per-domain computation applies where the full path of an inter-domain > > > TE LSP cannot be or is not determined at the ingress node of the TE > > > LSP, and is not signaled across domain boundaries. This is most likely > > > to arise owing to TE visibility limitations. The signaling message > > > indicates the destination and nodes up to the next domain boundary. It > > > may also indicate further domain boundaries or domain identifiers. The > > > path through each domain, possibly including the choice of exit point > > > from the domain, must be determined within the domain. > > > > > > A URL for this Internet-Draft is: > > > > > > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-inter-domain-pd-path-comp-01.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-inter-domain-pd-path-comp-01.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-inter-domain-pd-path-comp-01.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. > > > > > > > > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 21 Oct 2005 18:32:23 +0000 Message-ID: <00cf01c5d66d$a8af7ea0$6601a8c0@movaz.com> From: "Igor Bryskin" To: "Adrian Farrel" , , "Arthi Ayyangar" Cc: Subject: Re: I-D ACTION:draft-ietf-ccamp-inter-domain-pd-path-comp-01.txt Date: Fri, 21 Oct 2005 14:31:30 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Adrian, I understand and agree with what you are saying. My point was that a) when PCE is available, the PCE service could be a better way for determining the outgoing domain border node, and b) per-domain path computation could be useful even when you have PCE service available. In other words I was just suggesting an alternative method for per-domain path computation, that's all. Igor ----- Original Message ----- From: "Adrian Farrel" To: "Igor Bryskin" ; ; "Arthi Ayyangar" Cc: Sent: Friday, October 21, 2005 2:20 PM Subject: Re: I-D ACTION:draft-ietf-ccamp-inter-domain-pd-path-comp-01.txt > Hi Igor, > > I think you have to set the context of this I-D carefully, and then > understand the limited scope that is additionally proposed. > > The context of the I-D is limited to the per-domain computation case. > Hence, consulting an external PCE is out of scope. This is not to say that > it is not valid to consult a PCE (in fact, you might expect JP and me to > support that technique), but this I-D is demonstrating what we can do and > how we can solve the problem without using PCE. > > With respect to the use of the IP reachability, you may recall that I > raised this concern in Paris and on the list. The conclusion was that if > you have no other way of determining an exit router for your domain, then > attempting to use the IP reachability is no worse than giving up, and may > be much better. > > In the cases you raise: > 1. Yes, an interface address may be unreachable. > Do we lose anything by consulting IP reachability in this case? > No. > 2. Yes, the IP reachability may give us a sub-optimal TE path. > Is this path worse than no path? > No. > > So I asked the authors to be clear that what they are suggesting has > limitations, and should not be applied in some specific cases. I haven't > looked at the text yet, but I hope they have covered this. > > Cheers, > Adrian > ----- Original Message ----- > From: "Igor Bryskin" > To: ; "Arthi Ayyangar" > Cc: > Sent: Friday, October 21, 2005 4:27 PM > Subject: Re: I-D ACTION:draft-ietf-ccamp-inter-domain-pd-path-comp-01.txt > > > > Arthi, JP > > > > > > > > I have a problem with the auto-discovery mechanism you described in the > > draft (one that is based on query to IGP or BGP to determine outgoing > > ABR/ASBR). > > > > > > > > 1. Destination ID must be network unique but it does not have to be IP > > routable, for example, it could be a numbered link ID. > > > > 2. Even in case when destination is IP address, the path computing node > can > > only obtain the ID of an ABR or ASBR that advertises IP route to the > > destination, which would be one that knows about the shortest IP path to > the > > destination. However, it does not mean that properly constrained TE path > > from this ABR/ASBR to the destination or the next ABR/ASBR exist, or is > not > > suboptimal compared to one from some other ABR/ASBR which knows about > worse > > IP path to the destination and hence will not be reported to the > computing > > entity by the routing sub-system. > > > > > > > > I wonder why not to use the remote PCE service for this purpose. For > > instance a PCC may ask a PCE to determine either the ID of the outgoing > > domain border node or entire path in terms of domain border nodes. You > may > > ask why not to request explicit path(s) in this case? Several reasons > why > > the PCC wouldn't want to do so: > > > > > > > > a) it could be easier and faster for the PCE to determine domain border > node > > in direction towards the destination rather than explicit path(s). For > > instance, the latter may require cooperation of other PCEs; > > > > > > > > b) security considerations - PCE may not want to reveal remote domain > > topology(ies) > > > > > > > > c) it may be desirable to compute and setup services on per-domain > basis, > > for instance, to have each domain take separate care for service > > restoration. > > > > > > > > What do you think? > > > > > > > > Igor > > > > > > > > ----- Original Message ----- > > > > From: > > > > To: > > > > Cc: > > > > Sent: Thursday, October 20, 2005 6:50 PM > > > > Subject: I-D ACTION:draft-ietf-ccamp-inter-domain-pd-path-comp-01.txt > > > > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > > This draft is a work item of the Common Control and Measurement Plane > > Working Group of the IETF. > > > > > > Title : A Per-domain path computation method for establishing > > > Inter-domain Traffic Engineering (TE) Label > > Switched Paths (LSPs) > > > Author(s) : J. Vasseur, et al. > > > Filename : draft-ietf-ccamp-inter-domain-pd-path-comp-01.txt > > > Pages : 18 > > > Date : 2005-10-20 > > > > > > This document specifies a per-domain path computation technique for > > > establishing inter-domain Traffic Engineering (TE) Multiprotocol Label > > > Switching (MPLS) and Generalized MPLS (GMPLS) Label Switched Paths > > > (LSPs). In this document a domain refers to a collection of network > > > elements within a common sphere of address management or path > > > computational responsibility such as IGP areas and Autonomous Systems. > > > > > > Per-domain computation applies where the full path of an inter-domain > > > TE LSP cannot be or is not determined at the ingress node of the TE > > > LSP, and is not signaled across domain boundaries. This is most likely > > > to arise owing to TE visibility limitations. The signaling message > > > indicates the destination and nodes up to the next domain boundary. It > > > may also indicate further domain boundaries or domain identifiers. The > > > path through each domain, possibly including the choice of exit point > > > from the domain, must be determined within the domain. > > > > > > A URL for this Internet-Draft is: > > > > > > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-inter-domain-pd-path-comp-01.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-inter-domain-pd-path-comp-01.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-inter-domain-pd-path-comp-01.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. > > > > > > > > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 21 Oct 2005 18:22:59 +0000 Message-ID: <028501c5d66c$3d075570$ca00470a@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Igor Bryskin" , , "Arthi Ayyangar" Cc: Subject: Re: I-D ACTION:draft-ietf-ccamp-inter-domain-pd-path-comp-01.txt Date: Fri, 21 Oct 2005 19:20:30 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi Igor, I think you have to set the context of this I-D carefully, and then understand the limited scope that is additionally proposed. The context of the I-D is limited to the per-domain computation case. Hence, consulting an external PCE is out of scope. This is not to say that it is not valid to consult a PCE (in fact, you might expect JP and me to support that technique), but this I-D is demonstrating what we can do and how we can solve the problem without using PCE. With respect to the use of the IP reachability, you may recall that I raised this concern in Paris and on the list. The conclusion was that if you have no other way of determining an exit router for your domain, then attempting to use the IP reachability is no worse than giving up, and may be much better. In the cases you raise: 1. Yes, an interface address may be unreachable. Do we lose anything by consulting IP reachability in this case? No. 2. Yes, the IP reachability may give us a sub-optimal TE path. Is this path worse than no path? No. So I asked the authors to be clear that what they are suggesting has limitations, and should not be applied in some specific cases. I haven't looked at the text yet, but I hope they have covered this. Cheers, Adrian ----- Original Message ----- From: "Igor Bryskin" To: ; "Arthi Ayyangar" Cc: Sent: Friday, October 21, 2005 4:27 PM Subject: Re: I-D ACTION:draft-ietf-ccamp-inter-domain-pd-path-comp-01.txt > Arthi, JP > > > > I have a problem with the auto-discovery mechanism you described in the > draft (one that is based on query to IGP or BGP to determine outgoing > ABR/ASBR). > > > > 1. Destination ID must be network unique but it does not have to be IP > routable, for example, it could be a numbered link ID. > > 2. Even in case when destination is IP address, the path computing node can > only obtain the ID of an ABR or ASBR that advertises IP route to the > destination, which would be one that knows about the shortest IP path to the > destination. However, it does not mean that properly constrained TE path > from this ABR/ASBR to the destination or the next ABR/ASBR exist, or is not > suboptimal compared to one from some other ABR/ASBR which knows about worse > IP path to the destination and hence will not be reported to the computing > entity by the routing sub-system. > > > > I wonder why not to use the remote PCE service for this purpose. For > instance a PCC may ask a PCE to determine either the ID of the outgoing > domain border node or entire path in terms of domain border nodes. You may > ask why not to request explicit path(s) in this case? Several reasons why > the PCC wouldn't want to do so: > > > > a) it could be easier and faster for the PCE to determine domain border node > in direction towards the destination rather than explicit path(s). For > instance, the latter may require cooperation of other PCEs; > > > > b) security considerations - PCE may not want to reveal remote domain > topology(ies) > > > > c) it may be desirable to compute and setup services on per-domain basis, > for instance, to have each domain take separate care for service > restoration. > > > > What do you think? > > > > Igor > > > > ----- Original Message ----- > > From: > > To: > > Cc: > > Sent: Thursday, October 20, 2005 6:50 PM > > Subject: I-D ACTION:draft-ietf-ccamp-inter-domain-pd-path-comp-01.txt > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > This draft is a work item of the Common Control and Measurement Plane > Working Group of the IETF. > > > > Title : A Per-domain path computation method for establishing > > Inter-domain Traffic Engineering (TE) Label > Switched Paths (LSPs) > > Author(s) : J. Vasseur, et al. > > Filename : draft-ietf-ccamp-inter-domain-pd-path-comp-01.txt > > Pages : 18 > > Date : 2005-10-20 > > > > This document specifies a per-domain path computation technique for > > establishing inter-domain Traffic Engineering (TE) Multiprotocol Label > > Switching (MPLS) and Generalized MPLS (GMPLS) Label Switched Paths > > (LSPs). In this document a domain refers to a collection of network > > elements within a common sphere of address management or path > > computational responsibility such as IGP areas and Autonomous Systems. > > > > Per-domain computation applies where the full path of an inter-domain > > TE LSP cannot be or is not determined at the ingress node of the TE > > LSP, and is not signaled across domain boundaries. This is most likely > > to arise owing to TE visibility limitations. The signaling message > > indicates the destination and nodes up to the next domain boundary. It > > may also indicate further domain boundaries or domain identifiers. The > > path through each domain, possibly including the choice of exit point > > from the domain, must be determined within the domain. > > > > A URL for this Internet-Draft is: > > > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-inter-domain-pd-path-comp-01.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-inter-domain-pd-path-comp-01.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-inter-domain-pd-path-comp-01.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. > > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 21 Oct 2005 17:29:18 +0000 Message-ID: <01a101c5d664$e4e76210$ca00470a@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Cc: "Lou Berger" , "Dimitri Papadimitriou" , "Dimitri Papadimitriou" , "Anca Zamfir" , "Reshad Rahman" , "Junaid Israr" , "Arun Satyanarayana (asatyana)" , "Kireeti Kompella" Subject: Re: Further Working Group last call: draft-ietf-ccamp-rsvp-restart-ext-04.txt Date: Fri, 21 Oct 2005 18:27:12 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi, This last call completed without further comment. Arun needs to make one minor format modification to appease the RFC editor and then we will pass this on to the AD. Thanks, Adrian ----- Original Message ----- From: "Adrian Farrel" To: Cc: "Lou Berger" ; "Dimitri Papadimitriou" ; "Dimitri Papadimitriou" ; "Anca Zamfir" ; "Reshad Rahman" ; "Junaid Israr" ; "Arun Satyanarayana (asatyana)" ; "Kireeti Kompella" Sent: Tuesday, October 11, 2005 8:48 PM Subject: Further Working Group last call: draft-ietf-ccamp-rsvp-restart-ext-04.txt > Thanks for the note Arun, > > It looks to me that while most of these changes are editorial, the change > to 4.5.2 is substantive. > > Therefore we will have a further short WG last call. > > The last call will complete on Wednesday 19th October at 12 noon GMT. > > Send your comments to the list please. > > Thanks, > Adrian > ----- Original Message ----- > From: "Arun Satyanarayana" > To: "Adrian Farrel" ; "Kireeti Kompella" > > Cc: ; "Lou Berger" ; "Dimitri > Papadimitriou" ; "Dimitri Papadimitriou" > ; "Anca Zamfir" ; "Reshad Rahman" > ; "Junaid Israr" ; "Arun > Satyanarayana (asatyana)" > Sent: Tuesday, October 11, 2005 8:09 PM > Subject: Re: I-D ACTION:draft-ietf-ccamp-rsvp-restart-ext-04.txt > > > > Hi Adrian, Kireeti, > > > > Following are the mods to version -03, based on last call comments. Can > > we go through another short last call on this rev please? > > > > - Section 2 Terminology: > > Fix bad text > > < The reader is assumed to be familiar with the terminology defined in > > < xref target="RFC3209" /> and [RFC3473]. > > > The reader is assumed to be familiar with the terminology defined > in > > > [RFC3209] and [RFC3473]. > > > > - Section 4.2 Capability Object: > > Reverse ordering of definitions of T and R bits to match ordering in > > object > > > > - Full I-D: > > Change "Restart_Caps" to "Restart_Cap" (to match definition in 3473). > > > > - Section 4.4.1 Procedures for the Downstream Neighbor > > Clarify text: the downstream neighbor must send the T-bit in all > > Hellos > > < If the downstream RSVP neighbor of a restarting node is capable of > > < sending RecoveryPath messages to the restarting node, it MUST > > include > > < the Capability object with the RecoveryPath Transmit Enabled (T) bit > > < set (1) in all its Hello messages sent to the restarting node. > > > If a node is capable of sending RecoveryPath messages, it MUST > > > include the Capability object with the RecoveryPath Transmit > Enabled > > > (T) bit set (1) in all its Hello messages. > > > > - Section 4.4.2 Procedures for the Restarting Node > > Clarify text: the restarting node must send the R-bit in all Hellos > > < A restarting node that expects to recover RSVP state by the receipt > > < and processing of RecoveryPath messages according to procedures > > < defined in this document, MUST include the Capability object with > the > > < RecoveryPath Desired (R) bit set (1) in its RSVP Hello messages to > > < its neighbors, during the Recovery Period. The node MUST also > > < include the Restart_Caps object as defined in [RFC3473], in all > those > > < Hello messages. > > > A node that expects to recover RSVP state by the receipt and > > > processing of RecoveryPath messages according to procedures defined > > > in this document, MUST include the Capability object with the > > > RecoveryPath Desired (R) bit set (1) in its RSVP Hello messages to > > > its neighbors. The node MUST also include the Restart_Cap object > as > > > defined in [RFC3473], in all those Hello messages. > > > > - Section 4.5.2 Procedures for the Restarting Node > > Change response to received RecoveryPath messages outside the > Recovery > > Period: > > < These procedures apply during the "state recovery process" and > > < "Recovery Period" as defined in Section 9.5.2 in [RFC3473]. Any > > < RecoveryPath message received after the Recovery Period has expired > > < MUST be discarded. If no LSP state matching the RecoveryPath > message > > < is located, the restarted node MAY send a PathTear message > > < constructed from the RecoveryPath message, to expedite the cleanup > of > > < unrecovered RSVP and associated forwarding state downstream of the > > < restarted node. > > > These procedures apply during the "state recovery process" and > > > "Recovery Period" as defined in Section 9.5.2 in [RFC3473]. Any > > > RecoveryPath message received after the Recovery Period has expired > > > SHOULD be matched against local LSP state. If matching fully > > > resynchronized state is located, the node SHOULD send a Path > message > > > downstream. If non-resynchronized or no LSP state matching the > > > RecoveryPath message is located, the restarted node MAY send a > > > PathTear message constructed from the RecoveryPath message, to > > > expedite the cleanup of unrecovered RSVP and associated forwarding > > > state downstream of the restarted node. > > > > - Section 5.2.1 Procedures > > (Srefresh mechanism), clarify text: the restarting node must send > > the R-bit in all Hellos > > < To indicate to an RSVP neighbor that selective transmission of > > < RecoveryPath messages is desired, a restarting node MUST set (1) the > > < S-bit in the Capability object in all Hello messages it sends during > > < the Recovery Period to the neighbor. When the restarting node does > > > To indicate to an RSVP neighbor that selective transmission of > > > RecoveryPath messages is desired, a node MUST set (1) the S-bit in > > > the Capability object in all Hello messages it sends. When the > > > > - Section 7. Acknowledgments > > Add Pavan Beeram. > > > > - Section 8. IANA Considerations > > Suggest values for the RecoveryPath msg and the Capability object > > < A new RSVP object using a Class-Number of form 10bbbbbb called the > > < Capability Object is defined in Section 4.2 in this document. The > > < Class-Number is TBA by IANA. > > > A new RSVP object using a Class-Number of form 10bbbbbb called the > > > Capability Object is defined in Section 4.2 in this document. The > > > Class-Number is TBA by IANA. A value of 132 is suggested. > > > > < A new RSVP message type called a RecoveryPath message is defined in > > < Section 4.1 of this document. The RSVP message type is TBA by IANA. > > > A new RSVP message type called a RecoveryPath message is defined in > > > Section 4.1 of this document. The RSVP message type is TBA by > IANA. > > > A value of 30 is suggested. > > > > - Section 8. IANA Considerations > > Fix typo in the bit names > > < +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > < | |S|P|R| > > < +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | |T|R|S| > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > Thanks, > > Arun (and co-authors) > > ============================================================== > > -------- Original Message -------- > > Subject: I-D ACTION:draft-ietf-ccamp-rsvp-restart-ext-04.txt > > Date: Mon, 03 Oct 2005 15:50:02 -0400 > > From: Internet-Drafts@ietf.org > > To: i-d-announce@ietf.org > > CC: ccamp@ops.ietf.org > > > > 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 GMPLS RSVP Graceful Restart > > Author(s) : A. Satyanarayana, et al. > > Filename : draft-ietf-ccamp-rsvp-restart-ext-04.txt > > Pages : 24 > > Date : 2005-10-3 > > > > This document describes extensions to the RSVP Graceful Restart > > mechanisms defined in RFC 3473. The extensions enable the recovery > > of RSVP signaling state based on the Path message last sent by the > > node being restarted. Previously defined Graceful Restart > > mechanisms, also called recovery from nodal faults, permit recovery > > of signaling state from adjacent nodes when the data plane has > > retained the associated forwarding state across a restart. These > > mechanisms do not fully support signaling state recovery on ingress > > nodes or recovery of all RSVP objects. The presented extensions use > > the RSVP Hello extensions defined in RFC 3209, and extensions for > > state recovery on nodal faults defined in RFC 3473. With the > > presented extensions the restarting node can recover all previously > > transmitted Path state including the Explicit Route Object and the > > downstream (outgoing) interface identifiers. The extensions can > also > > be used to recover signaling state after the restart of an ingress > > node. The extensions optionally support the use of Summary Refresh, > > defined in RFC 2961, to reduce the number of messages exchanged > > during the Recovery Phase when the restarting node has recovered > > signaling state locally for one or more LSPs. > > > > A URL for this Internet-Draft is: > > > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rsvp-restart-ext-04.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-rsvp-restart-ext-04.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-rsvp-restart-ext-04.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. > > > > > > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 21 Oct 2005 15:28:41 +0000 Message-ID: <007a01c5d653$ec5302e0$6601a8c0@movaz.com> From: "Igor Bryskin" To: , "Arthi Ayyangar" Cc: Subject: Re: I-D ACTION:draft-ietf-ccamp-inter-domain-pd-path-comp-01.txt Date: Fri, 21 Oct 2005 11:27:16 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Arthi, JP I have a problem with the auto-discovery mechanism you described in the draft (one that is based on query to IGP or BGP to determine outgoing ABR/ASBR). 1. Destination ID must be network unique but it does not have to be IP routable, for example, it could be a numbered link ID. 2. Even in case when destination is IP address, the path computing node can only obtain the ID of an ABR or ASBR that advertises IP route to the destination, which would be one that knows about the shortest IP path to the destination. However, it does not mean that properly constrained TE path from this ABR/ASBR to the destination or the next ABR/ASBR exist, or is not suboptimal compared to one from some other ABR/ASBR which knows about worse IP path to the destination and hence will not be reported to the computing entity by the routing sub-system. I wonder why not to use the remote PCE service for this purpose. For instance a PCC may ask a PCE to determine either the ID of the outgoing domain border node or entire path in terms of domain border nodes. You may ask why not to request explicit path(s) in this case? Several reasons why the PCC wouldn't want to do so: a) it could be easier and faster for the PCE to determine domain border node in direction towards the destination rather than explicit path(s). For instance, the latter may require cooperation of other PCEs; b) security considerations - PCE may not want to reveal remote domain topology(ies) c) it may be desirable to compute and setup services on per-domain basis, for instance, to have each domain take separate care for service restoration. What do you think? Igor ----- Original Message ----- From: To: Cc: Sent: Thursday, October 20, 2005 6:50 PM Subject: I-D ACTION:draft-ietf-ccamp-inter-domain-pd-path-comp-01.txt > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. > > Title : A Per-domain path computation method for establishing > Inter-domain Traffic Engineering (TE) Label Switched Paths (LSPs) > Author(s) : J. Vasseur, et al. > Filename : draft-ietf-ccamp-inter-domain-pd-path-comp-01.txt > Pages : 18 > Date : 2005-10-20 > > This document specifies a per-domain path computation technique for > establishing inter-domain Traffic Engineering (TE) Multiprotocol Label > Switching (MPLS) and Generalized MPLS (GMPLS) Label Switched Paths > (LSPs). In this document a domain refers to a collection of network > elements within a common sphere of address management or path > computational responsibility such as IGP areas and Autonomous Systems. > > Per-domain computation applies where the full path of an inter-domain > TE LSP cannot be or is not determined at the ingress node of the TE > LSP, and is not signaled across domain boundaries. This is most likely > to arise owing to TE visibility limitations. The signaling message > indicates the destination and nodes up to the next domain boundary. It > may also indicate further domain boundaries or domain identifiers. The > path through each domain, possibly including the choice of exit point > from the domain, must be determined within the domain. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-inter-domain-pd-path-comp-01.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-inter-domain-pd-path-comp-01.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-inter-domain-pd-path-comp-01.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. > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 21 Oct 2005 13:57:34 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C5D647.2A748015" Subject: draft-bernstein-ccamp-gmpls-vcat-lcas-01 comments Date: Fri, 21 Oct 2005 14:55:56 +0100 Message-ID: Thread-Topic: draft-bernstein-ccamp-gmpls-vcat-lcas-01 comments Thread-Index: AcXWRyhSnwEmYcnETpaSNdiLS6oWKw== From: "Trevor Wilson" To: Cc: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C5D647.2A748015 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C5D647.2A748015" ------_=_NextPart_002_01C5D647.2A748015 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Greg et al, I have read your latest "draft-bernstein-ccamp-gmpls-vcat-lcas-01" and have inserted some comments and made some suggested modifications using the 'track-changes' feature in word. I apologise if the indentations etc. are not fully correct. If you require further information please do not hesitate to contact me. Best regards, Trevor Trevor Wilson Nortel Networks Belfast Lab Tel: +44 2890 363701 ESN 751 3701 > This is the Way. This is Nortel.=20 >=20 >=20 <>=20 Confidentiality Notice: This message and any attachments may contain information that is privileged and confidential. If you have reason to believe that you are not the intended recipient or a person responsible for delivering this message to an intended recipient, you are hereby notified that any review, dissemination, distribution, or copying of this message is strictly prohibited. If you have reason to believe that you are not the intended recipient or a person responsible for delivering this message to an intended recipient, please contact the sender immediately by reply email and destroy all copies of the original message. ------_=_NextPart_002_01C5D647.2A748015 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable draft-bernstein-ccamp-gmpls-vcat-lcas-01 comments

Greg et al,

I have read your latest = "draft-bernstein-ccamp-gmpls-vcat-lcas-01" and have inserted some comments and made some suggested = modifications using the 'track-changes' feature in word.

I apologise if the indentations etc. = are not fully correct.

If you require further information = please do not hesitate to contact me.

Best regards,

Trevor

Trevor Wilson
Nortel Networks
Belfast Lab
Tel: +44 2890 363701
       = ESN 751 3701
This is the Way. This is = Nortel.


= <<draft-bernstein-ccamp-gmpls-vcat-lcas-01_tw-2110-comments.doc>= >
Confidentiality = Notice:  This = message and any attachments may contain information that is privileged = and confidential. If you have reason to believe that you are not the = intended recipient or a person responsible for delivering this message = to an intended recipient, you are hereby notified that any review, = dissemination, distribution, or copying of this message is strictly = prohibited. If you have reason to believe that you are not the intended = recipient or a person responsible for delivering this message to an = intended recipient, please contact the sender immediately by reply email = and destroy all copies of the original message.


------_=_NextPart_002_01C5D647.2A748015-- ------_=_NextPart_001_01C5D647.2A748015 Content-Type: application/msword; name="draft-bernstein-ccamp-gmpls-vcat-lcas-01_tw-2110-comments.doc" Content-Transfer-Encoding: base64 Content-Description: draft-bernstein-ccamp-gmpls-vcat-lcas-01_tw-2110-comments.doc Content-Disposition: attachment; filename="draft-bernstein-ccamp-gmpls-vcat-lcas-01_tw-2110-comments.doc" 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAADAAAADQEAAAAAAAAA EAAADwEAAAEAAAD+////AAAAAAYBAAATAQAADgEAAP////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////s pcEAW0AJBAAA8BK/AAAAAAAAMAAAAAAABgAAbu0AAA4AYmpiajQDNAMAAAAAAAAAAAAAAAAAAAAA AAAJBBYAKO4AAFZpAQBWaQEAUHMAAAAAAAAAAAAAAAAAAJIGAAAAAAAAAAAAAAAAAAD//w8AAAAA AAAAAAD//w8AAAAAAAAAAAD//w8AAAAAAAAAAAAAAAAAAAAAAIgAAAAAAIoCAAAAAAAAigIAAIoC AAAAAAAAigIAAAAAAACmAgAANgEAAH4EAAAsAAAAqgQAABQAAAAAAAAAAAAAAL4EAAAAAAAABs4A AAAAAAAGzgAAAAAAAAbOAAAAAAAABs4AAIwAAACSzgAAFAEAAL4EAAAAAAAAceYAAGgBAACyzwAA AAAAALLPAAAAAAAAss8AAAAAAACyzwAAAAAAALLPAAAAAAAAjdAAAAAAAACN0AAAAAAAAI3QAAAA AAAApOUAAAIAAACm5QAAAAAAAKblAAAAAAAApuUAAAAAAACm5QAAAAAAAKblAAAAAAAApuUAACQA AADZ5wAAUgIAACvqAADGAAAAyuUAADkAAAAAAAAAAAAAAAAAAAAAAAAAigIAABwAAAAE0wAAEgAA AAAAAAAAAAAAAAAAAAAAAACN0AAAAAAAAI3QAAAAAAAAFtMAAAwAAAAi0wAACAAAAMrlAAAAAAAA AAAAAAAAAACKAgAAAAAAAIoCAAAAAAAAss8AAAAAAAAAAAAAAAAAALLPAADbAAAAA+YAADIAAADA 5AAAAAAAAMDkAAAAAAAAwOQAAAAAAAAq0wAAqgIAAIoCAAAAAAAAss8AAAAAAACKAgAAAAAAALLP AAAAAAAApOUAAAAAAAAAAAAAAAAAALDkAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAABNMAAAAAAACk5QAAAAAAAMDkAAAwAAAAwOQAAAAAAAAAAAAA AAAAAPDkAAAAAAAAigIAAAAAAACKAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA8OQAAAAAAACyzwAAAAAAAKbPAAAMAAAAgPlWgkbW xQEAAAAAAAAAAAbOAAAAAAAA1NUAAAoMAADw5AAAAAAAAAAAAAAAAAAApOUAAAAAAAA15gAAPAAA AHHmAAAAAAAA8OQAAAAAAADx6gAAAAAAAN7hAACkAgAA8eoAAAAAAADw5AAAAAAAAAAAAAAAAAAA vgQAAAAAAAC+BAAAAAAAAIoCAAAAAAAAigIAAAAAAACKAgAAAAAAAIoCAAAAAAAAAAAAAAAAAAAA AAAAAAAAAPHqAAAAAAAAAAAAAAAAAADcAwAAogAAAPDkAAC0AAAAjdAAAHYAAAAD0QAAVAAAAJ7k AAASAAAAV9EAAEQAAACb0QAAaQEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAjdAA AAAAAACN0AAAAAAAAI3QAAAAAAAAyuUAAAAAAADK5QAAAAAAAL4EAAAAAAAAvgQAAKRkAABiaQAA pGQAAAAAAAAAAAAAguQAABwAAAC+BAAAAAAAAL4EAAAAAAAAYmkAAAAAAAACAAEBAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA0NQ0NB TVAgd29ya2luZyBHcm91cCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg Ry4gQmVybnN0ZWluDUludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBHcm90dG8gTmV0d29ya2luZw1FeHBpcmVzOiBBcHJpbCAxNCwgMjAwNiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgRC4gQ2F2aWdsaWENICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBNYXJj b25pDSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIFIuIFJhYmJhdA0gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIEZ1aml0c3UNICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBPY3RvYmVyIDExLCAyMDA1DQ0NT3Bl cmF0aW5nIFZpcnR1YWwgY29uY2F0ZW5hdGlvbiAoVkNBVCkgYW5kIHRoZSAgTGluayBDYXBhY2l0 eSBBZGp1c3RtZW50DSBTY2hlbWUgKExDQVMpIHdpdGggR2VuZXJhbGl6ZWQgTXVsdGktUHJvdG9j b2wgTGFiZWwgIFN3aXRjaGluZyAoR01QTFMpDSAgICAgICAgICAgICAgICBkcmFmdC1iZXJuc3Rl aW4tY2NhbXAtZ21wbHMtdmNhdC1sY2FzLTAxDQ1TdGF0dXMgb2YgdGhpcyBNZW1vDQ0gICBCeSBz dWJtaXR0aW5nIHRoaXMgSW50ZXJuZXQtRHJhZnQsIGVhY2ggYXV0aG9yIHJlcHJlc2VudHMgdGhh dCBhbnkNICAgYXBwbGljYWJsZSBwYXRlbnQgb3Igb3RoZXIgSVBSIGNsYWltcyBvZiB3aGljaCBo ZSBvciBzaGUgaXMgYXdhcmUNICAgaGF2ZSBiZWVuIG9yIHdpbGwgYmUgZGlzY2xvc2VkLCBhbmQg YW55IG9mIHdoaWNoIGhlIG9yIHNoZSBiZWNvbWVzDSAgIGF3YXJlIHdpbGwgYmUgZGlzY2xvc2Vk LCBpbiBhY2NvcmRhbmNlIHdpdGggU2VjdGlvbiA2IG9mIEJDUCA3OS4NDSAgIEludGVybmV0LURy YWZ0cyBhcmUgd29ya2luZyBkb2N1bWVudHMgb2YgdGhlIEludGVybmV0IEVuZ2luZWVyaW5nDSAg IFRhc2sgRm9yY2UgKElFVEYpLCBpdHMgYXJlYXMsIGFuZCBpdHMgd29ya2luZyBncm91cHMuICBO b3RlIHRoYXQNICAgb3RoZXIgZ3JvdXBzIG1heSBhbHNvIGRpc3RyaWJ1dGUgd29ya2luZyBkb2N1 bWVudHMgYXMgSW50ZXJuZXQtDSAgIERyYWZ0cy4NDSAgIEludGVybmV0LURyYWZ0cyBhcmUgZHJh ZnQgZG9jdW1lbnRzIHZhbGlkIGZvciBhIG1heGltdW0gb2Ygc2l4IG1vbnRocw0gICBhbmQgbWF5 IGJlIHVwZGF0ZWQsIHJlcGxhY2VkLCBvciBvYnNvbGV0ZWQgYnkgb3RoZXIgZG9jdW1lbnRzIGF0 IGFueQ0gICB0aW1lLiAgSXQgaXMgaW5hcHByb3ByaWF0ZSB0byB1c2UgSW50ZXJuZXQtRHJhZnRz IGFzIHJlZmVyZW5jZQ0gICBtYXRlcmlhbCBvciB0byBjaXRlIHRoZW0gb3RoZXIgdGhhbiBhcyAi d29yayBpbiBwcm9ncmVzcy4iDQ0NICAgVGhlIGxpc3Qgb2YgY3VycmVudCBJbnRlcm5ldC1EcmFm dHMgY2FuIGJlIGFjY2Vzc2VkIGF0DSAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaWV0Zi8xaWQtYWJz dHJhY3RzLnR4dC4NDSAgIFRoZSBsaXN0IG9mIEludGVybmV0LURyYWZ0IFNoYWRvdyBEaXJlY3Rv cmllcyBjYW4gYmUgYWNjZXNzZWQgYXQNICAgaHR0cDovL3d3dy5pZXRmLm9yZy9zaGFkb3cuaHRt bC4NDSAgIFRoaXMgSW50ZXJuZXQtRHJhZnQgd2lsbCBleHBpcmUgb24gQXByaWwgMTQsIDIwMDYu DQ1Db3B5cmlnaHQgTm90aWNlDQ0gICBDb3B5cmlnaHQgKEMpIFRoZSBJbnRlcm5ldCBTb2NpZXR5 ICgyMDA1KS4NDUFic3RyYWN0DQ0gICBUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyB0aGUgdXNlIG9m IHRoZSBHZW5lcmFsaXplZCBNdWx0aS1Qcm90b2NvbA0gICBMYWJlbCBTd2l0Y2hpbmcgKEdNUExT KSBjb250cm9sIHBsYW5lIGluIGNvbmp1bmN0aW9uIHdpdGggdGhlIFZpcnR1YWwNICAgQ29uY2F0 ZW5hdGlvbiAoVkNBVCkgbGF5ZXIgMSBpbnZlcnNlIG11bHRpcGxleGluZyBtZWNoYW5pc20gYW5k IGl0cw0gICBjb21wYW5pb24gTGluayBDYXBhY2l0eSBBZGp1c3RtZW50IFNjaGVtZSAoTENBUykg d2hpY2ggY2FuIGJlIHVzZWQNDQ0NQmVybnN0ZWluLCBldCBhbC4gICAgICAgIEV4cGlyZXMgQXBy aWwgMTQsIDIwMDYgICAgICAgICAgICAgICAgIFtQYWdlIDFdDQwNSW50ZXJuZXQtRHJhZnQgICAg ICAgICAgICBHTVBMUywgVkNBVCBhbmQgTENBUyAgICAgICAgICAgICAgT2N0b2JlciAyMDA1DQ0N ICAgZm9yIGhpdGxlc3MgZHluYW1pYyByZXNpemluZyBvZiB0aGUgaW52ZXJzZSBtdWx0aXBsZXgg Z3JvdXAuICBUaGVzZQ0gICB0ZWNobmlxdWVzIGFwcGx5IHRvIHRoZSBPcHRpY2FsIFRyYW5zcG9y dCBOZXR3b3JrIChPVE4pLCBTeW5jaHJvbm91cw0gICBPcHRpY2FsIE5ldHdvcmsgKFNPTkVUKSwg U3luY2hyb25vdXMgRGlnaXRhbCBIaWVyYXJjaHkgKFNESCkgYW5kDSAgIFBsZXNpb2Nocm9ub3Vz IERpZ2l0YWwgSGllcmFyY2h5IChQREgpIHNpZ25hbHMuDQ0NVGFibGUgb2YgQ29udGVudHMNDSAg IDEuICBPdmVydmlldyBvZiBWQ0FUIGFuZCBMQ0FTICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAgMw0gICAgIDEuMS4gIFZDQVQgc2lnbmFscyBhbmQgY29tcG9uZW50cyAgLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDMNICAgICAxLjIuICBWQ0FUIENhcGFiaWxpdGll cyBhbmQgTGltaXRhdGlvbnMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAzDSAgICAgMS4zLiAg VGhlIExDQVMgUHJvdG9jb2wgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAgNA0gICAyLiAgUHJvYmxlbSBTdGF0ZW1lbnQgYW5kIEN1cnJlbnQgU3VwcG9ydCAgLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gIDUNICAgICAyLjEuICBEaXNjb3Zlcnkgb2YgRW5hYmxlZCBFbmQg U3lzdGVtcyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA1DSAgICAgMi4yLiAgQ2xpZW50IHRv IEVuZCBQb2ludCBNYXBwaW5ncyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgNQ0gICAg IDIuMy4gIFZDQVQgY29uZmlndXJhdGlvbiB3aXRob3V0IExDQVMgIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gIDYNICAgICAyLjQuICBWQ0FUIGNvbmZpZ3VyYXRpb24gd2l0aCBMQ0FTIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA3DSAgICAgMi41LiAgQ29tcG9uZW50IFNpZ25hbCBD b25maWd1cmF0aW9uIFNjZW5hcmlvcyAuIC4gLiAuIC4gLiAuIC4gLiAgOA0gICAzLiAgUG9zc2li bGUgRXh0ZW5zaW9ucyB0byBHTVBMUyB0byBzdXBwb3J0IGFkZGl0aW9uYWwNICAgICAgIFZDQVQv TENBUyBzY2VuYXJpb3MgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IDEwDSAgICAgMy4xLiAgTWVjaGFuaXNtcyBmb3IgRGlzY292ZXJ5IG9mIFZDQVQvTENBUyAgLiAu IC4gLiAuIC4gLiAuIC4gLiAxMA0gICAgIDMuMi4gIE1lY2hhbmlzbSB0byBTdXBwb3J0IE11bHRp cGxlIENsaWVudCB0byBFbmQgUG9pbnQNICAgICAgICAgICBNYXBwaW5ncyAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDEwDSAgICAgMy4zLiAgU3VwcG9y dCBmb3IgQ29tcG9uZW50IFNpZ25hbCBDb25maWd1cmF0aW9uIFNjZW5hcmlvcyAuIC4gLiAxMA0g ICA0LiAgUmVmZXJlbmNlcyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gMTANICAgQXBwZW5kaXggQS4gIEFja25vd2xlZGdlbWVudHMgIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDEyDSAgIEF1dGhvcnMnIEFkZHJlc3NlcyAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxMw0gICBJbnRlbGxl Y3R1YWwgUHJvcGVydHkgYW5kIENvcHlyaWdodCBTdGF0ZW1lbnRzIC4gLiAuIC4gLiAuIC4gLiAu IC4gMTQNDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ1CZXJuc3RlaW4sIGV0IGFsLiAgICAgICAgRXhw aXJlcyBBcHJpbCAxNCwgMjAwNiAgICAgICAgICAgICAgICAgW1BhZ2UgMl0NDA1JbnRlcm5ldC1E cmFmdCAgICAgICAgICAgIEdNUExTLCBWQ0FUIGFuZCBMQ0FTICAgICAgICAgICAgICBPY3RvYmVy IDIwMDUNDQ0xLiAgT3ZlcnZpZXcgb2YgVkNBVCBhbmQgTENBUw0NICAgVmlydHVhbCBDb25jYXRl bmF0aW9uIChWQ0FUKSBpcyBhIHN0YW5kYXJkaXplZCBsYXllciAxIGludmVyc2UNICAgbXVsdGlw bGV4aW5nIHRlY2huaXF1ZSB0aGF0IGNhbiBiZSBhcHBsaWVkIHRvIE9UTiBbNl0sIFNPTkVUIFsz XSwgU0RIDSAgIFsyXSwgYW5kIFBESCBbNV0gY29tcG9uZW50IHNpZ25hbHMuICBCeSBpbnZlcnNl IG11bHRpcGxleGluZyB3ZSBtZWFuDSAgIGEgbWV0aG9kIHRoYXQgY29tYmluZXMgbXVsdGlwbGUg bGlua3MgYXQgYSBwYXJ0aWN1bGFyIGxheWVyIGludG8gYW4NICAgYWdncmVnYXRlIGxpbmsgdG8g YWNoaWV2ZSBhIGNvbW1lbnN1cmF0ZSBpbmNyZWFzZSBpbiBhdmFpbGFibGUNICAgYmFuZHdpZHRo IGNhcGFjaXR5IG9uIHRoYXQgYWdncmVnYXRlIGxpbmsuICBNb3JlIGZvcm1hbGx5LCBWQ0FUIGVz c2VudGlhbGx5DSAgIGNvbWJpbmVzIHRoZSBwYXlsb2FkIGJhbmR3aWR0aCBvZiBtdWx0aXBsZSBw YXRoIGxheWVyIG5ldHdvcmsgc2lnbmFscw0gICAob3IgdHJhaWxzKSB0byBzdXBwb3J0IGEgc2lu Z2xlIGNsaWVudCAoZS5nLiAgRXRoZXJuZXQpIGxheWVyIGxpbmsuDSAgIEZvciBhIG1vcmUgZGV0 YWlsZWQgaW50cm9kdWN0aW9uIHNlZSBbMV0uDQ0xLjEuICBWQ0FUIHNpZ25hbHMgYW5kIGNvbXBv bmVudHMNDSAgIEluIHRoZSBmb2xsb3dpbmcgd2Ugd2lsbCB1c2UgU0RIIHRlcm1pbm9sb2d5IHJh dGhlciB0aGFuIGJvdGggU09ORVQNICAgYW5kIFNESCB0ZXJtaW5vbG9neS4gIEluIFNESCBWaXJ0 dWFsIENvbmNhdGVuYXRpb24gKFZDQVQpIGNhbiBiZQ0gICBhcHBsaWVkIHRvIHRoZSBmb2xsb3dp bmcgY29tcG9uZW50IHRpbWUgZGl2aXNpb24gbXVsdGlwbGV4IChURE0pDSAgIHNpZ25hbHMgcmVm ZXJyZWQgdG8gYXMgVmlydHVhbCBDb250YWluZXJzIChWQ3MpOiBWQy0xMSwgVkMtMTIsIFZDLTIs DSAgIFZDLTMsIGFuZCBWQy00DQ0gICBPbmx5IGxpa2UgY29tcG9uZW50IHNpZ25hbHMgY2FuIGJl IGFnZ3JlZ2F0ZWQgaW50byBhIFZDQVQgZ3JvdXAgKFZDRykuDSAgIFRoZXNlIGdyb3VwcyBWQ0dz IGFyZSByZXNwZWN0aXZlbHkga25vd24gYXM6IFZDLTExLVh2LCBWQy0xMi1YdiwgVkMtMi1YdiwN ICAgVkMtMy1YdiwgYW5kIFZDLTQtWHYuICBJbiB0aGUgcHJldmlvdXMgZGVzaWduYXRpb25zIFgg aXMgYW4gaW50ZWdlciBpbmRpY2F0aW5nIHRoZSBudW1iZXIgb2YgbWVtYmVycyBpbiB0aGUgVkNH LiBUaGUgdmFsdWUgb2YgWCBmb3IgaGlnaCBvcmRlciBWQ3MgKFZDLTMgYW5kIFZDLTQpY2FuIGJl IGZyb20gMSB0byAyNTY7IGFuZCBmb3IgbG93IG9yZGVyIFZDcyAoVkMtMTEgVkMtMTIgYW5kIFZD LTIpIHRoZSB2YWx1ZSBvZiBYIGNhbiBiZSAxIHRvIDY0LiANICAgcnVubmluZyBmcm9tIDEgdG8g YSB2YWx1ZSBOIGRlcGVuZGVudCB1cG9uIHRoZSBjb21wb25lbnQgdHlwZS4gIFNlZQ0gICBbMl0g Zm9yIGRldGFpbHMuDQ0gICBWQ0FUIGNhbiBiZSBhcHBsaWVkIHRvIHRoZSBmb2xsb3dpbmcgUERI IHNpZ25hbHMgYXMgc3BlY2lmaWVkIGluDSAgIHJlZmVyZW5jZSBbNV06IERTMSxFMSwgRTMsIERT My4gIFNpbWlsYXIgdG8gdGhlIFNPTkVUL1NESCBjYXNlIHRoZXNlDSAgIGNvbXBvbmVudCBzaWdu YWxzIGNhbiBvbmx5IGJlIGNvbWJpbmVkIHdpdGggbGlrZSBzaWduYWxzIHRvIHByb2R1Y2UNICAg YWdncmVnYXRlcy4gIEZvciBzb21lIHJlYXNvbiB0aGUgdmlydHVhbCBjb25jYXRlbmF0aW9uIGdy b3VwVkNHcyBvZiB0aGUNICAgUERIIHNpZ25hbHMgd2VyZSBub3QgZ2l2ZW4gdW5pcXVlIGRlc2ln bmF0aW9ucyBpbiBbNV0gc28gd2Ugc2hhbGwNICAgYWRvcHQgYSBzaW1pbGFyIG5vdGF0aW9uIHRv IHRoZSBTREggVkNBVCBzaWduYWxzIGZvciB0aGUgcGVybWl0dGVkDSAgIFBESCBWQ0FUIHNpZ25h bHMgdGhhdCBmb2xsb3c6IERTMS1YdiwgRTEtWHYsIEUzLVh2LCBEUzMtWHYuBQ0NICAgQ29uY2F0 ZW5hdGlvbiBpbiB0aGUgb3B0aWNhbCB0cmFuc3BvcnQgbmV0d29yayAoT1ROKSBpcyByZWFsaXpl ZCBieQ0gICBtZWFucyBvZiB2aXJ0dWFsIGNvbmNhdGVuYXRpb24gb2YgT3B0aWNhbCBDaGFubmVs IFBheWxvYWQgVW5pdCAoT1BVKQ0gICBzaWduYWxzLiAgT1BVayBzaWduYWxzIChrPTEsIDIsIDMp IGNhbiBiZSBjb25jYXRlbmF0ZWQgaW50byBPUFVrLVh2DSAgIGFnZ3JlZ2F0ZXMgd2l0aCBYPSAx LC4uLiwgMjU2LiAgU2VlIHJlZmVyZW5jZSBbNl0gZm9yIGRldGFpbHMuDQ0xLjIuICBWQ0FUIENh cGFiaWxpdGllcyBhbmQgTGltaXRhdGlvbnMNDSAgIFZDQVQgcGVyZm9ybXMgaW52ZXJzZSBtdWx0 aXBsZXhpbmcgYnkgb2N0ZXQvYnl0ZSBkZS1pbnRlcmxlYXZpbmcgb2YNICAgdGhlIGVuY2Fwc3Vs YXRlZCBjbGllbnQgYml0IHN0cmVhbSBpbnRvIHRoZSBpbmRpdmlkdWFsIFZDcyBvZiB0aGUgVkNH IGFuZCB0aGVzZSBWQ3MgYXJlIHRyYW5zcG9ydGVkIGFjcm9zcyB0aGUgbmV0d29yayBpbmRlcGVu ZGVudGx5IGZyb20gZWFjaCBvdGhlci4gRHVlIHRvIHRoZSBwb3NzaWJsZSBkaWZmZXJlbnQgcHJv cGFnYXRpb24gdGltZXMgb2YgdGhlIFZDcywgYSBkaWZmZXJlbnRpYWwgZGVsYXkgbWF5IG9jY3Vy IGJldHdlZW4gdGhlIGluZGl2aWR1YWwgVkNzIGF0IHRoZSBwYXRoIHRlcm1pbmF0aW9uLiBUaGlz IGRpZmZlcmVudGlhbCBkZWxheSBoYXMgdG8gYmUgY29tcGVuc2F0ZWQgYW5kIHRoZSBWQ3MgaGF2 ZSB0byBiZSByZWFsaWduZWQuLiAgSGVuY2UgdGhlIG1haW4gbGltaXRhdGlvbiBvZiBhbnkNICAg VkNBVCBzdGFuZGFyZCBvciBpbXBsZW1lbnRhdGlvbiBpcyB0aGUgYW1tb3VudCBvZiBkaWZmZXJl bnRpYWwgZGVsYXkNICAgdGhhdCBjYW4gYmUgYWNjb21vZGF0ZWQgYmV0d2VlbiB0aGUgY29tcG9u ZW50IHNpZ25hbHMuICBUaGVzZSBhcmVUaGlzIGlzIA0gICBzdW1tYXJpemVkIGZvciB0aGUgZGlm ZmVyZW50IHNpZ25hbCB0eXBlcyBpbiByZWZlcmVuY2UgWzFdIHdpdGgNICAgZGV0YWlscyBnaXZl biBpbiB0aGUgcmVzcGVjdGl2ZSBzdGFuZGFyZHMgZG9jdW1lbnRzIFsyXSBbM10uDQ0NDQ1CZXJu c3RlaW4sIGV0IGFsLiAgICAgICAgRXhwaXJlcyBBcHJpbCAxNCwgMjAwNiAgICAgICAgICAgICAg ICAgW1BhZ2UgM10NDA1JbnRlcm5ldC1EcmFmdCAgICAgICAgICAgIEdNUExTLCBWQ0FUIGFuZCBM Q0FTICAgICAgICAgICAgICBPY3RvYmVyIDIwMDUNDQ0xLjMuICBUaGUgTENBUyBQcm90b2NvbA0N ICAgVGhlIExpbmsgQ2FwYWNpdHkgQWRqdXN0bWVudCBTY2hlbWUgZm9yIFZDQVQgc2lnbmFscyBp cyBhIHByb3RvY29sDSAgIGZvciBkeW5hbWljYWxseSBhbmQgaGl0bGVzc2x5IGNoYW5naW5nIChp LmUuLCBpbmNyZWFzaW5nIGFuZA0gICBkZWNyZWFzaW5nKSB0aGUgY2FwYWNpdHkgb2YgYSBWQ0FU IGdyb3VwVkNHLiAgTENBUyBhbHNvIHByb3ZpZGVzDSAgIHN1cnZpdmFiaWxpdHkgY2FwYWJpbGl0 aWVzLCBhdXRvbWF0aWNhbGx5IGRlY3JlYXNpbmcgdGhlIGNhcGFjaXR5IGlmDSAgIGEgbWVtYmVy IG9mIHRoZSBWQ0FUIGdyb3VwVkNHIGV4cGVyaWVuY2VzIGEgZmFpbHVyZSBpbiB0aGUgbmV0d29y aywgYW5kDSAgIGluY3JlYXNpbmcgdGhlIGNhcGFjaXR5IHdoZW4gdGhlIG5ldHdvcmsgZmF1bHQg aXMgcmVwYWlyZWQuICBMQ0FTLA0gICBpdHNlbGYsIHByb3ZpZGVzIGEgbWVjaGFuaXNtIGZvciBp bnRlcndvcmtpbmcgYmV0d2VlbiBMQ0FTIGFuZCBub24tDSAgIExDQVMgVkNBVCBlbmQgcG9pbnRz LiAgVkNBVCBkb2VzIG5vdCByZXF1aXJlIExDQVMgZm9yIGl0cyBvcGVyYXRpb24uDQ0gICBMQ0FT IGZ1bmN0aW9uYWxpdHkgZG9lcyBub3Qgb3ZlcmxhcCBvciBjb25mbGljdCB3aXRoIEdNUExTJyBy b3V0aW5nDSAgIG9yIHNpZ25hbGluZyBmdW5jdGlvbmFsaXR5IGZvciB0aGUgZXN0YWJsaXNobWVu dCBvZiBjb21wb25lbnQgbGlua3MNICAgb3IgZW50aXJlIFZDQVQgZ3JvdXBWQ0dzLiAgTENBUyBp bnN0ZWFkIGlzIHVzZWQgdG8gY29udHJvbCB3aGV0aGVyIGENICAgcGFydGljdWxhciBjb21wb25l bnQgc2lnbmFsIGlzIGFjdHVhbGx5IHB1dCBpbnRvIHNlcnZpY2UgY2FycnlpbmcNICAgdHJhZmZp YyBmb3IgdGhlIFZDQVQgZ3JvdXBWQ0cuDQ0gICBMQ0FTIHByb3ZpZGVzIGZvciBncmFjZWZ1bCBk ZWdyYWRhdGlvbiBvZiBmYWlsZWQgbGlua3MgYnkgaGF2aW5nIHRoZQ0gICBzaW5rIGVuZChzKSBy ZXBvcnQgYmFjayB0aGUgcmVjZWl2ZSBzdGF0dXMgb2YgYWxsIG1lbWJlciBjb21wb25lbnRzLiAg SW4NICAgdGhlIGNhc2Ugb2YgYSByZXBvcnRlZCBtZW1iZXIgZmFpbHVyZSwgdGhlIHNvdXJjZSBl bmQgd2lsbCBzdG9wIHVzaW5nDSAgIHRoZSBmYWlsZWQgY29tcG9uZW50IG1lbWJlciBhbmQgZGlz dHJpYnV0ZSB0aGUgZGF0YSBvdmVyIHRoZSByZW1haW5pbmcgkWdvb2SSIG1lbWJlcnMsIHRodXMg dHJhbnNtaXNzaW9uIGlzIHJlc3RvcmVkIHRvIGEgcmVkdWNlZCBiYW5kd2lkdGggY2FwYWNpdHku IGFuZCB0VGhlIHNvdXJjZSBlbmQgd2lsbCBzZW5kIGFuIExDQVMgbWVzc2FnZSB0byB0aGUNICAg c2luayBlbmQgdGhhdCBpdCBpcyBub3QgdHJhbnNtaXR0aW5nIGRhdGEgb24gdGhhdCBjb21wb25l bnRtZW1iZXIuICBUaGUNICAgd29yc3QgY2FzZSBub3RpZmljYXRpb24gdGltZXMgYXJlIHN1bW1h cml6ZWQgaW4gWzFdLgUNDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDUJlcm5zdGVpbiwgZXQg YWwuICAgICAgICBFeHBpcmVzIEFwcmlsIDE0LCAyMDA2ICAgICAgICAgICAgICAgICBbUGFnZSA0 XQ0MDUludGVybmV0LURyYWZ0ICAgICAgICAgICAgR01QTFMsIFZDQVQgYW5kIExDQVMgICAgICAg ICAgICAgIE9jdG9iZXIgMjAwNQ0NDTIuICBQcm9ibGVtIFN0YXRlbWVudCBhbmQgQ3VycmVudCBT dXBwb3J0DQ0gICBJbiB0aGlzIHNlY3Rpb24gd2UgbGlzdCBhIG51bWJlciBvZiBWQ0FUL0xDQVMg dXNhZ2Ugc2NlbmFyaW9zIGFuZA0gICB0aGVpciBjdXJyZW50IGxldmVsIG9mIHN1cHBvcnQuICBX ZSB3aWxsIGV2YWx1YXRlIHRoZSBhcHBsaWNhYmlsaXR5DSAgIG9mIEdNUExTIHRvIHRoZXNlIHNj ZW5hcmlvcyBhbmQgZm9yIHRob3NlIHNjZW5hcmlvcyB0aGF0IEdNUExTIGRvZXMNICAgbm90IGN1 cnJlbnRseSBzdXBwb3J0IHdlIGRlc2NyaWJlIHBvc3NpYmxlIEdNUExTIGV4dGVuc2lvbnMgaW4N ICAgU2VjdGlvbiAzLiAgTm90ZSB0aGUgdGVybSAiY29tcG9uZW50IiBzaWduYWwgaW4gdGhlIHRl eHQgaXMgdXNlZCBhcyBhDSAgIHNpbXBsaWZpZWQgbm90aW9uIHRvIHRoZSBtb3JlIGZvcm1hbCBj b25jZXB0cyBvZiBWQy1uLCBPRFVrLCBhbmQgUERIDSAgIHRlcm1pbmF0aW9uIGZ1bmN0aW9uIGFz IHdlbGwgYXMgVkMtbiwgT0RVayBhbmQgUERIIHBhdGgvdHJhaWwuDQ0yLjEuICBEaXNjb3Zlcnkg b2YgRW5hYmxlZCBFbmQgU3lzdGVtcw0NICAgRGlzY292ZXJpbmcgVkNBVDogVkNBVCBzb3VyY2Vz IGNhbiBvbmx5IGNvbW11bmljYXRlIHdpdGggVkNBVCBjYXBhYmxlDSAgICAgIHNpbmtzLiAgSGVu Y2UgdGhlIFZDQVQgY2FwYWJpbGl0aWVzIG9mIGEgUERILCBTREgsIG9yIE9UTiBwYXRoDSAgICAg IHRlcm1pbmF0aW9uIHBvaW50cyBuZWVkIHRvIGJlIGtub3duLg0NICAgICAgQ3VycmVudGx5IG5v IHN1cHBvcnQgZm9yIGRpc2NvdmVyeSBvZiBWQ0FUIG9yIExDQVMgYXByaW9yaSwgaS5lLiwNICAg ICAgdmlhIHJvdXRpbmcgaW5mb3JtYXRpb24uICBTdXBwb3J0IGZvciAiZGlzY292ZXJ5IiBvZiBW Q0FUDSAgICAgIGNhcGFiaWxpdHkgYXQgY29ubmVjdGlvbiBlc3RhYmxpc2htZW50IHRpbWUgdmlh IHNpZ25hbGluZywgaS5lLiwNICAgICAgd2UgY2FuIHJlcXVlc3QgVkNBVCBjb25uZWN0aW9uIGFu ZCBpZiB0aGUgZW5kIHN5c3RlbSBjYW5ub3QNICAgICAgc3VwcG9ydCBpdCxpdCB3b3VsZCByZWZ1 c2UgdGhlIGNvbm5lY3Rpb24uICBUQkQgLS0gaXMgdGhlcmUgYQ0gICAgICBzcGVjaWZpYyBlcnJv ciBjb2RlIGNvbmNlcm5pbmcgIlZDQVQgbm90IHN1cHBvcnRlZCIuDQ0gICBEaXNjb3ZlcmluZyBM Q0FTOiBMQ0FTIG9mZmVycyBhZGRpdGlvbmFsIGZ1bmN0aW9uYWxpdHkgYmV0d2VlbiBWQ0FUDSAg ICAgIGNhcGFibGUgc291cmNlcyBhbmQgc2lua3MuICBIZW5jZSB0aGUgTENBUyBjYXBhYmlsaXRp ZXMgb2YgVkNBVA0gICAgICBlbmFibGVkIHBhdGggdGVybWluYXRpb24gcG9pbnRzIGNhbiBiZSB1 c2VmdWwgdG8ga25vdyBpbiBhZHZhbmNlDSAgICAgIG9mIGNvbXBvbmVudCBzaWduYWwgc2V0dXAu DQ0gICAgICBDdXJyZW50bHkgdGhlcmUgaXMgbm8gbWVjaGFuaXNtIHRvIGFzayBmb3IgYW4gTENB UyBlbmFibGVkIGVuZA0gICAgICBwb2ludCBub3IgaXMgdGhlcmUgYSB3YXkgdG8gZmluZCBvdXQg aWYgdGhlIG90aGVyIGVuZCBpcyBMQ0FTDSAgICAgIGVuYWJsZWQgdW50aWwgYWZ0ZXIgdGhlIGNv bm5lY3Rpb24gaXMgZXN0YWJsaXNoZWQuICBUaGlzIGlzIGENICAgICAgcHJvYmxlbSBpZiB3ZSBz cGVjaWZpY2FsbHkgd2FudCBoaXRsZXNzIGR5bmFtaWMgcmVzaXppbmcgb3IgZmFzdA0NICAgICAg Z3JhY2VmdWwgZGVncmFkYXRpb24gZm9yIGEgVkNBVCBncm91cFZDRy4NDTIuMi4gIENsaWVudCB0 byBFbmQgUG9pbnQgTWFwcGluZ3MNDSAgIEZpeGVkIENsaWVudCB0byBFbmQgcG9pbnQgTWFwcGlu ZzogUGVyIGNsaWVudCBzaWduYWwgdGhlcmUgaXMgYQ0gICAgICBWQy1uLVh2IGNpcmN1aXQgaW4g d2hpY2ggdGhlIFggVkMtbiB0ZXJtaW5hdGlvbiBwb2ludHMgYXJlDSAgICAgIGRlZGljYXRlZCB0 byB0aGlzIGNsaWVudCBzaWduYWwuICBBdCBhbnkgcG9pbnQgaW4gdGltZSwgWSBYYSAoYWN0aXZl IG1lbWJlcnMpIG91dCBvZiBYbSAobWF4aW11bSBtZW1iZXJzKQ0gICAgICBWQy1uIHRlcm1pbmF0 aW9uIHBvaW50cyBtYXkgYmUgc2V0IHVwIHRvIGNhcnJ5IGNsaWVudCB0cmFmZmljLg0gICAgICBG b3IgZXhhbXBsZSB3aGVuIFZDQVQgaXMgZGVwbG95ZWQgb24gYSBSb3V0ZXIsIHRoZSBWQ0FUIGdy b3VwVkNHDSAgICAgIGNvbm5lY3RzIGRpcmVjdGx5IHRvIG9uZSBTVE0tTiBpbnRlcmZhY2UgcG9y dCAoaW4gYWJzZW5jZSBvZiBhIEhPDSAgICAgIG9yIExPIHN3aXRjaCBmYWJyaWMgaW4gdGhlIHJv dXRlcikuICBUaGUgdHJhbnNwb3J0IG5ldHdvcmsgd2lsbG1heQ0gICAgICB0aGVuIHNwbGl0IHRo ZSBWQ0FUIGdyb3VwIGludG8gdHdvIG9yIG1vcmUgc3ViZ3JvdXBzIG9mDSAgICAgIGNvbXBvbmVu dHMsIGVhY2ggdHJhbnNwb3J0IHRoZSBpbmRpdmlkdWFsIFZDcyBiZWluZyByb3V0ZWQgdmlhIG9u ZSBvciBtb3JlIGRpdmVyc2Ugcm91dGVzLiBEaXZlcnNlIHJvdXRpbmcgd2lsbCBpbmN1ciBhIGRp ZmZlcnRpYWwgZGVsYXkuDQ0NDQ0NDUJlcm5zdGVpbiwgZXQgYWwuICAgICAgICBFeHBpcmVzIEFw cmlsIDE0LCAyMDA2ICAgICAgICAgICAgICAgICBbUGFnZSA1XQ0MDUludGVybmV0LURyYWZ0ICAg ICAgICAgICAgR01QTFMsIFZDQVQgYW5kIExDQVMgICAgICAgICAgICAgIE9jdG9iZXIgMjAwNQ0N DSAgIFZhcmlhYmxlIENsaWVudCB0byBFbmQgcG9pbnQgTWFwcGluZzogRm9yIGEgc2V0IG9mIE0g Y2xpZW50IHNpZ25hbHMNICAgICAgdGhlcmUgYXJlIE0qIFZDLW4tWHYgVkNBVCBlbmRwb2ludHMg c2hhcmluZyBhIHNldCBvZiBOIChOPk0pIFZDLW4NICAgICAgdGVybWluYXRpb24gcG9pbnRzLiAg VHlwaWNhbGx5IEl0IGlzIHBvc3NpYmxlIHRoYXQgTXhYID4gTiAoZXhhbXBsZTogTT0xMCwgWD03 LCBOPTY0KTsNICAgICAgaS5lLiB0aGVyZSBpcyBtYXkgYmUgYSBraW5kIG9mIG92ZXJib29raW5n LiAgSW1wbGljYXRpb246IG11c3QgYmUgYWJsZSB0bw0gICAgICBhY2NvbW1vZGF0ZSBtdWx0aXBs ZSBkaWZmZXJlbnQgc2l6ZWQgVkNBVCBncm91cFZDR3MgYXQgYW4NICAgICAgImludGVyZmFjZSIu ICBGb3IgZXhhbXBsZSBhbiBTVE0tNjQgaW50ZXJmYWNlIGNhbiBzdXBwb3J0IG1hbnkNICAgICAg ZGlmZmVyZW50IFZDLTQtWHYgZ3JvdXBzLCBwcm92aWRpbmcgdGhlIHRvdGFsIG51bWJlciBvZiBW Q3MgZG9lcyBub3QgZXhjZWVkIHRoZSBpbnRlcmZhY2UgdG90YWwgY2FwYWNpdHkuDQ0gICBJbXBs aWNhdGlvbnM6IEluIGJvdGggdGhlc2UgY2FzZXMgd2UgY2FuIGhhdmUgbW9yZSB0aGFuIG9uZSBW Q0FUDSAgICAgIGdyb3VwVkNHIHBlciBHTVBMUyBsaW5rLiAgSW4gZ2VuZXJhbCBpdCBpcyB0aGUg cmVzcG9uc2liaWxpdHkgb2YgdGhlDSAgICAgIHNpZ25hbGluZyBlbnRpdHkgYXQgdGhlIHNvdXJj ZSBhbmQgZGVzdGluYXRpb24gZW5kcyB0byBjaG9vc2UgdGhlDSAgICAgIGFwcHJvcHJpYXRlIFZD LW4gdGVybWluYXRpb24gcG9pbnRzIGZvciB0aGUgVkNBVCBncm91cFZDRyBhbmQgaW4gdGhlDSAg ICAgIGNhc2Ugb2YgInZhcmlhYmxlIGNsaWVudCBtYXBwaW5nIiB0byBwZXJmb3JtIG5lZWRlZCBp bnRlcm5hbA0gICAgICBjb25maWd1cmF0aW9uLiAgSG93ZXZlciBtdWx0aXBsZSBWQ0FUIGdyb3Vw VkNHcyBwZXIgR01QTFMgbGluayBvcg0gICAgICBHTVBMUyBhZGRyZXNzZWQgZW50aXR5IGludHJv ZHVjZXMgYW4gdW5yZXNvbHZhYmxlIGFtYmlndWl0eSB3aGVuDSAgICAgIGRpc2pvaW50BSBjb25u ZWN0aW9ucyBhcmUgc2V0IHVwIG9yIGR5bmFtaWMgcmVzaXppbmcgaXMgYXBwbGllZA0gICAgICBz aW5jZSB0aGVyZSBpcyBjdXJyZW50bHkgbm8gIlZDQVQgZ3JvdXBWQ0cgaWRlbnRpZmllciIgaW4g R01QTFMNICAgICAgc2lnbmFsaW5nLg0NMi4zLiAgVkNBVCBjb25maWd1cmF0aW9uIHdpdGhvdXQg TENBUw0NICAgQmFzZSBDb25maWd1cmF0aW9uOiBGb3IgVkNBVCB0byBvcGVyYXRlIHRoZSBzaW5r IGVuZCBuZWVkcyB0byBiZQ0gICAgICBpbmZvcm1lZCBvZiBob3cgbWFueSBjb21wb25lbnRzIGFy ZSBpbiB0aGUgVkNBVCBncm91cFZDRy4gIEl0IGhhcyBubw0gICAgICBvdGhlciB3YXkgb2Yga25v d2luZyBpZiBpdCBpcyBjdXJyZW50bHkgcmVjZWl2aW5nIGFsbCBjb21wb25lbnRzDSAgICAgIGlu dGVuZGVkIHRvIGJlIGluIHRoZSBncm91cC4NDSAgICAgIEZpeGVkIHNpemVkIGNvLXJvdXRlZCBn cm91cHMgYXJlIHN1cHBvcnRlZCB3aXRoIGN1cnJlbnQgR01QTFMNICAgICAgc2lnbmFsaW5nLiAg RGlzam9pbnRseSBEaXZlcnNlbHkgcm91dGVkIGdyb3VwcyBhcmUgbm90IGN1cnJlbnRseSBzdXBw b3J0ZWQuBQ0NICAgR3JvdXAgUmVzaXppbmc6IEFkZGl0aW9ucyBvciByZW1vdmFscyBvZiBjb21w b25lbnRzIGZyb20gYSBub24tTENBUyBWQ0FUIGdyb3VwVkNHDSAgICAgIHdpdGhvdXQgYXJlIG5v dCBoaXRsZXNzLCB0aGF0IGlzIGRhdGEgbG9zcyB3aWxsIG9jY3VyIHdoaWxlIHRoZQ0gICAgICBz b3VyY2UgYW5kIHNpbmsgYmVjb21lIHN5bmNocm9uaXplZGFyZSByZXByb3Zpc2lvbmVkIGFzIHRv IHRoZSBudW1iZXIgb2YgbWVtYmVycyBpbg0gICAgICB0aGUgZ3JvdXAuDQ0gICAgICBDdXJyZW50 bHkgbm90IHN1cHBvcnRlZCB3aXRoaW4gR01QTFMuICBJbiBwYXJ0aWN1bGFyLCB3aXRoIGVhY2gN ICAgICAgYWRkaXRpb24gb3IgcmVtb3ZhbCBvZiBhIGNvbXBvbmVudCB0aGUgc2luayBlbmQgcG9p bnQgbmVlZHMgdG8gYmUNICAgICAgdG9sZCB0aGUgZXhwZWN0ZWQgbnVtYmVyIG9mIGNvbXBvbmVu dHMgaW4gdGhlIGdyb3VwLg0NICAgRmFpbHVyZSBDb25kaXRpb25zOiBGYWlsdXJlIG9mIGEgY29t cG9uZW50IG11c3QgZGV0ZWN0ZWQgZXh0ZXJuYWwgdG8NICAgICAgVkNBVCBzeXN0ZW0uICBUaGUg ZW50aXJlIGdyb3VwIGlzIHJlbmRlcmVkIGlub3BlcmFibGUgdW50aWwgc291cmNlDSAgICAgIHRh a2VzIHRoZSBmYWlsZWQgY29tcG9uZW50IGlzIHRha2VuIG91dCBvZiBzZXJ2aWNlIChvciByZXBs YWNlZCkgYW5kIHNpbmsgZW5kIGlzIG5vdGlmaWVkDSAgICAgIHRvIHRha2UgY29tcG9uZW50IG91 dCBvZiBzZXJ2aWNlYnkgcmUtcHJvdmlzaW9uaW5nIGJvdGggc291cmNlIGFuZCBzaW5rIHRvIHRo YXQgZWZmZWN0Lg0NICAgICAgQ3VycmVudGx5IG5vdCBzdXBwb3J0ZWQgd2l0aGluIEdNUExTLiAg VGhlIHNvdXJjZSBhbmQgc2luayBuZWVkcyB0byBiZSB0b2xkDSAgICAgIHdoYXQgY29tcG9uZW50 IGhhcyBmYWlsZWQgYW5kIHJlbW92ZSBpdCBmcm9tIHNlcnZpY2UuLCB0aGVuIHRoZQ0gICAgICBz aW5rIG11c3QgYmUgdG9sZCB0byBhbHNvIHJlbW92ZSBpdCBmcm9tIHNlcnZpY2UuDQ0NDQ0NDUJl cm5zdGVpbiwgZXQgYWwuICAgICAgICBFeHBpcmVzIEFwcmlsIDE0LCAyMDA2ICAgICAgICAgICAg ICAgICBbUGFnZSA2XQ0MDUludGVybmV0LURyYWZ0ICAgICAgICAgICAgR01QTFMsIFZDQVQgYW5k IExDQVMgICAgICAgICAgICAgIE9jdG9iZXIgMjAwNQ0NDTIuNC4gIFZDQVQgY29uZmlndXJhdGlv biB3aXRoIExDQVMNDSAgIEJhc2UgQ29uZmlndXJhdGlvbjogU2luayBlbmQgKGFuZCBzb3VyY2Ug ZW5kKSBhcmUgZmlyc3QgY29uZmlndXJlZA0gICAgICB3aXRoIHRoZSB2YWx1ZSBvZiAiWSJYbSAo dGhlIG1heGltdW0gbnVtYmVyIG9mIGNvbXBvbmVudHMpLCBhbmQgdGhlIGFjdGl2ZSBjb21wb25l bnRzIFhhIGFyZSBhbGxvY2F0ZWQgKFhtIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAABlIiAAWABhACkAYQBuAGQAIABtAG8AcgBlAA0AIAAgACAA IAAgACAAcwBwAGUAYwBpAGYAaQBjAGEAbABsAHkAIAB3AGgAaQBjAGgAIABvAGYAIAB0AGgAZQAg AFgAIAAoAGUALgBnAC4AIAAgAFYAQwAtAG4AKQAgAGEAYwBjAGUAcwBzACAAcABvAGkAbgB0AHMA IAAoAGEAbgBkACAAdABoAHUAcwANACAAIAAgACAAIAAgACgAVgBDAC0AbgApACAAdABlAHIAbQBp AG4AYQB0AGkAbwBuACAAZgB1AG4AYwB0AGkAbwBuAHMAKQAgAGEAcgBlACAAYQBsAGwAbwBjAGEA dABlAGQAIAB0AG8AIAB0AGgAZQAgAFYAQwBBAFQAIABnAHIAbwB1AHAAIAB3AGkAdABoAA0AIAAg ACAAIAAgACAAWQAgACgAVgBDAC0AbgApACAAYwBvAG0AcABvAG4AZQBuAHQAcwAuACAAIABMAEMA QQBTACAAdABoAGUAbgAgAGQAZQB0AGUAYwB0AHMAIABhAHUAdABvAG0AYQB0AGkAYwBhAGwAbAB5 ACAAdABoAGUAIABYAGEAIAB3AGgAaQBjAGgAIABvAGYADQAgACAAIAAgACAAIAB0AGgAbwBzAGUA IABZACAAKABWAEMALQBuACkAIABjAG9tcG9uZW50cyBpcyBjYXJyeWluZyBhY3R1YWwgdHJhZmZp YyBhbmQgcHV0cyB0aGVtDSAgICAgIGludG8gc2VydmljZSBmb3IgdGhlIGdyb3VwLg0NICAgICAg Q3VycmVudGx5IGJvdGggY28tcm91dGVkIGFuZCBkaXNqb2ludGx5IGRpdmVyc2VseSByb3V0ZWQg VkNBVCBncm91cFZDR3MgY2FuIGJlDSAgICAgIHN1cHBvcnRlZCBpZiB0aGVyZSBpcyBubyBWQ0FU IGdyb3VwVkNHIGFtYmlndWl0eS4NDSAgIENvbXBvbmVudCBBZGRpdGlvbjogV2hlbiBhIG5ldyBj b21wb25lbnQgc2lnbmFsIGhhcyB0byBiZSBhZGRlZCB0byBhDSAgICAgIFZDQVQgZ3JvdXBWQ0cg dGhlIGZvbGxvd2luZyBwcm9jZWR1cmUgYXBwbGllcy4NDSAgICAgIDEuCUVzdGFibGlzaCBhIGNv bm5lY3Rpb24gdXNpbmcgb25lIG9mIHRoZSBpbi1hY3RpdmUgbWVtYmVycyBvZiB0aGUgVkNHDQky LglQcm92aXNpb24gdGhlIFNvdXJjZSB0byB1c2UgdGhlIJFuZXeSIG1lbWJlciBhcyBvbmUgb2Yg dGhlIGFjdGl2ZSBncm91cC4gVGhpcyBlbnRhaWxzIHNlbmRpbmcgdGhlIEFERCBjb21tYW5kLg0J My4JUHJvdmlzaW9uIHRoZSBTaW5rIHRvIHJlY29nbml6ZSB0aGUgkW5ld5IgbWVtYmVyIG9mIHRo ZSBWQ0cuDQ0JVGhlIG9yZGVyIG9mIGRvaW5nIHRoZSBhYm92ZSBpcyBub3QgaW1wb3J0YW50LiBX aGVuIHRoZSBBREQgY29tbWFuZCBpcyByZWNlaXZlZCBieSB0aGUgc2luayBpdCB3aWxsIHJldHVy biBhbiCRT0uSIHRvIHRoZSBTb3VyY2UgYXQgd2hpY2ggdGltZSB0aGUgU291cmNlIHdpbGwgdXNl IGFsbCBhY3RpdmUgbWVtYmVycyAob2xkICsgbmV3KSB0byB0cmFuc3BvcnQgdGhlIGNsaWVudCB0 cmFmZmljLg0xLiAgQ29uZmlndXJlIHRoZSBhZGFwdGF0aW9uIHNvdXJjZS9zaW5rIGZ1bmN0aW9u cyBhbmQgY2hhbmdlIHRoZQ0gICAgICAgICAgbnVtYmVyIG9mIGNvbXBvbmVudHMsIFksIHRvIFkr MSBieSBpZGVudGlmeWluZyB3aGljaCBvZiB0aGUNICAgICAgICAgIFgtWSAoZS5nLiAgVkMtbikg YWNjZXNzIHBvaW50cyBjdXJyZW50bHkgb3V0c2lkZSB0aGUgZ3JvdXAgaXMNICAgICAgICAgIGFk ZGVkIHRvIHRoZSBncm91cDsNDSAgICAgIDIuICBUaGUgbmV3IGNvbXBvbmVudCBpcyBjcmVhdGVk LCBlLmcuLCB0aGUgY3Jvc3MtY29ubmVjdGlvbnMgYXJlDSAgICAgICAgICBlc3RhYmxpc2ggYWxv bmcgdGhlIGNvbXBvbmVudHMgcGF0aC4NDSAgICAgIDMuICBBcyBzb29uIGFzIExDQVMgcHJvdG9j b2wgaW5mb3JtYXRpb24gZXhjaGFuZ2UgaXMgZmluaXNoZWQsDSAgICAgICAgICBpLmUuLCB0aGUg c3RhdGUgTk9STSBpcyByZWFjaGVkLCBjbGllbnQgdHJhZmZpYyBpcyBzZW50IG9uIHRoZQ0gICAg ICAgICAgYWRkZWQgY29tcG9uZW50Lg0NICAgICAgVGhpcyBwcm9jZWR1cmUgZG9lcyBub3QgYWZm ZWN0IHRoZSBhbHJlYWR5IGVzdGFibGlzaGVkIExDQVMNICAgICAgbWVtYmVycywgdGhhdCBpcywg Y2xpZW50IHRyYWZmaWMgaXMgbm90IHNlbnQgb24gdGhlIG5ldyBjb21wb25lbnQNICAgICAgdW50 aWwgdGhlIExDQVMgcHJvY2VkdXJlIGlzIGNvbXBsZXRlOw0NICAgICAgVGhpcyBjYW4gYmUgc3Vw cG9ydGVkIHdpdGhpbiBHTVBMUyBpZiwgYWZ0ZXIgR01QTFMgaGFzDSAgICAgIHN1Y2Nlc3NmdWxs eSBlc3RhYmxpc2hlZCBhIHBvdGVudGlhbCBuZXcgY29tcG9uZW50LCB0aGUgc291cmNlIGVuZA0g ICAgICBMQ0FTIGlzIChpbnRlcm5hbGx5KSB0b2xkIHRvIGFkZCBpdCB0byB0aGUgZ3JvdXAuDQ0g ICBDb21wb25lbnQgUmVtb3ZhbDogV2hlbiBhIGNvbXBvbmVudCBpcyByZW1vdmVkIHRoZSBmb2xs b3dpbmcNICAgICAgcHJvY2VkdXJlIGFwcGxpZXM6DQ0JMS4gCU9uIHJlY2VpcHQgb2YgYSByZW1v dmUgY29tbWFuZCAoZm9yIGEgcGFydGljdWxhciBtZW1iZXIpIGZyb20gdGhlIG1hbmFnZW1lbnQg c3lzdGVtLCBMQ0FTIFNvdXJjZSB3aWxsIHN0b3AgdXNpbmcgdGhhdCBtZW1iZXI7IHRoZSBTaW5r IHdpbGwgcmVjb2duaXplIHRoYXQgdGhhdCBtZW1iZXIgbm8gbG9uZ2VyIGNhcnJpZXIgY2xpZW50 IHRyYWZmaWMgYW5kIHdpbGwgdXNlIG9ubHkgdGhlIHJlbWFpbmluZyBtZW1iZXJzIHRvIHJlY29u c3RpdHV0ZSB0aGUgY2xpZW50IHNpZ25hbC4gTm90ZTogVGhlIGN1cnJlbnQgTENBUyBwcm90b2Nv bCBhbGxvd3MgZm9yIHRoZSCRZGVjcmVhc2WSIGNvbW1hbmQgdG8gYmUgaW5pdGlhdGVkIGF0IGVp dGhlciB0aGUgTENBUyBzb3VyY2Ugb3IgdGhlIExDQVMgc2luazsgaWYgaXQgaXMgaW5pdGlhdGVk IGF0IHRoZSBzaW5rIHRoZXJlIHdpbGwgYmUgYSBoaXQgdG8gdGhlIHJlY29uc3RydWN0ZWQgZGF0 YS4gDQkNCTIuCVRoZSBjb25uZWN0aW9uLCBzb3VyY2UgcHJvdmlzaW9uaW5nIGFuZCBzaW5rIHBy b3Zpc2lvbmluZyBvZiB0aGF0IG1lbWJlciBjYW4gdGhlbiBiZSByZW1vdmVkIGZyb20gdGhlIFZD Ry4NDSAgICAgIDEuICBMQ0FTIHByb3RvY29sIGlzIHVzZWQgdG8gcmVtb3ZlIHRoZSBjb21wb25l bnQgZnJvbSB0aGUgZ3JvdXAsDSAgICAgICAgICB0aGF0IGlzLCBpbmNvbWluZyB0cmFmZmljIGNs aWVudCBkYXRhIGlzIHRyYW5zbWl0dGVkIG9uIHRoZQ0gICAgICAgICAgb3RoZXIgVkNBVCBjb21w b25lbnQocykgdG8gYXNzdXJlIHRoYXQgdGhlIHByb2NlZHVyZSBpcyBub3QNICAgICAgICAgIHRy YWZmaWMgYWZmZWN0aW5nDQ0gICAgICAyLiAgQ29uZmlndXJlIHRoZSBhZGFwdGF0aW9uIHNvdXJj ZS9zaW5rIGZ1bmN0aW9ucyBhbmQgY2hhbmdlIHRoZQ0gICAgICAgICAgbnVtYmVyIG9mIGNvbXBv bmVudHMgWSB0byBZLTE7IGkuZS4gcmVtb3ZlIHRoZSBWQy1uIGFjY2Vzcw0gICAgICAgICAgcG9p bnQgZnJvbSB0aGUgZ3JvdXAuDQ0NDQ1CZXJuc3RlaW4sIGV0IGFsLiAgICAgICAgRXhwaXJlcyBB cHJpbCAxNCwgMjAwNiAgICAgICAgICAgICAgICAgW1BhZ2UgN10NDA1JbnRlcm5ldC1EcmFmdCAg ICAgICAgICAgIEdNUExTLCBWQ0FUIGFuZCBMQ0FTICAgICAgICAgICAgICBPY3RvYmVyIDIwMDUN DQ0gICAgICAzLiAgVGhlIGNvbXBvbmVudCBjb25uZWN0aW9uIGNhbiBiZSwgaWYgbmVlZGVkLCBy ZW1vdmVkIGZyb20gdGhlDSAgICAgICAgICB0cmFuc3BvcnQgbmV0d29yay4NDSAgICAgIFRoaXMg Y2FuIGJlIHN1cHBvcnRlZCB3aXRoaW4gR01QTFMgaWYsIGJlZm9yZSBHTVBMUyB0ZWFycyBkb3du IGENICAgICAgY29tcG9uZW50LCBMQ0FTIGlzIHRvbGQgKGxvY2FsIHRvIHNvdXJjZSBlbmQpIHRv IHJlbW92ZSB0aGUNICAgICAgY29tcG9uZW50IGZyb20gc2VydmljZSBpbiB0aGUgZ3JvdXAuDQ0N ICAgQ29tcG9uZW50IEZhaWx1cmU6IFdoZW4gYSBjb21wb25lbnQgZmFpbHM6LCANDQkxLgl0VGhl IExDQVMgc2luayBkZXRlY3RzIHRoZSANICAgICAgZmFpbHVyZSAoaG93IHRoaXMgaXMgZG9uZSBp cyBvdXRzaWRlIHRoZSBzY29wZSBvZiB0aGlzIElEKSBhbmQgDSAgICAgIGluZm9ybXMgdGhlIHNv dXJjZSBvZiB0aGlzIGZhaWx1cmUgdmlhIHRoZSBtZW1iZXIgc3RhdHVzIChNU1QpDSAgICAgIGlu Zm9ybWF0aW9uLiAgVGhlIHNvdXJjZSB0aGVuOg0NDSAgICAgIDIxLgkgIFRoZSBzb3VyY2UgdGhl biBUdGFrZXMgdGhlIGZhaWxlZCBjb21wb25lbnQgb3V0IG9mIHNlcnZpY2UgYW5kIGFuZCB1c2Vz IG9ubHkgdGhlIHJlbWFpbmluZyCRZ29vZJIgbWVtYmVycyB0byB0cmFuc3BvcnQgdGhlIGNsaWVu dCB0cmFmZmljLiBOb3RlOiBObyByZS1zZXF1ZW5jaW5nIG9mIHRoZSBWQ0cgaXMgZG9uZSBhdCB0 aGlzIHRpbWUuaWYgbmVjZXNzYXJ5DSAgICAgICAgICByZWFycmFuZ2VzIHRoZSBzZXF1ZW5jaW5n IG9mIHRoZSBWQ0FUIGdyb3VwLg0NICAgICAgMi4gIEluZm9ybXMgdGhlIHNpbmsgYWJvdXQgdGhl IGNvbXBvbmVudCByZW1vdmVkIGZyb20gc2VydmljZSBhbmQNICAgICAgICAgIGFueSByZS1hcnJh bmdpbmcgb2YgdGhlIFZDQVQgZ3JvdXAuDQ0gICAgICBXaGVuIHRoZSBmYWlsZWQgY29tcG9uZW50 IGlzIHJlcGFpcmVkLCBMQ0FTIGNhbiBhdXRvbWF0aWNhbGx5IGFkZA0gICAgICB0aGUgcmVwYWly ZWQgY29tcG9uZW50IGJhY2sgdG8gdGhlIGdyb3VwLCBvciBhbHRlcm5hdGl2ZWx5IGEgbmV3DSAg ICAgIGNvbXBvbmVudCBjYW4gYmUgYWRkZWQgdG8gYnJpbmcgdGhlIGdyb3VwIGJhY2sgdG8gaXRz IG9yaWdpbmFsDSAgICAgIHNpemUuICBOb3RlIHRoYXQgY29tcG9uZW50IGZhaWx1cmUgaXMgbm90 IGhpdGxlc3MsIGJ1dCBub3RlIHRoZQ0gICAgICBmYXN0IG5vdGlmaWNhdGlvbiB0aW1lcyBvZiBb QmVybkRpZWdvUmFiYmF0XS4FDQ0gICAgICBDdXJyZW50bHkgc3VwcG9ydGVkIHNpbmNlIG5vIGFj dGlvbiByZXF1aXJlZCBvZiBHTVBMUy4FDQ0yLjUuICBDb21wb25lbnQgU2lnbmFsIENvbmZpZ3Vy YXRpb24gU2NlbmFyaW9zDQ0gICBIZXJlIHdlIHVzZSB0aGUgdGVybSAiZ3JvdXAiIHRvIHJlZmVy IHRvIHRoZSBlbnRpcmUgVkNBVCBncm91cFZDRyBhbmQNICAgdGhlIHRlcm1pbm9sb2d5ICJzZXQi IGFuZCAic3Vic2V0IiB0byByZWZlciB0byB0aGUgY29sbGVjdGlvbiBvZg0gICBwb3RlbnRpYWwg VkNBVCBncm91cFZDRyBtZW1iZXIgc2lnbmFscwUuICBOb3RlIHRoYXQgYWxsIGFzc2VzbWVudHMg b2YNICAgd2hldGhlciBhIHNjZW5hcmlvIGlzIGN1cnJldGx5IHN1cHBvcnRlZCBhc3N1bWVzIGVp dGhlciAoYSkgYSBzaW5nbGUNICAgVkNBVCBncm91cFZDRyBwZXIgR01QTFMgYWRkcmVzc2FibGUg ZW50aXR5LCBvciAoYikgYSBtZWNoYW5pc20gaXMgaW4NICAgcGxhY2UgdG8gZGlzYW1iaWd1YXRl IG11bHRpcGxlIFZDQVQgZ3JvdXBWQ0dzIChzZWUgU2VjdGlvbiAyLjIpLg0NICAgRml4ZWQsIENv LXJvdXRlZDogQSBmaXhlZCBiYW5kd2lkdGggVkNBVCBncm91cFZDRywgd2l0aCBhbGwgbWVtYmVy cyB0cmFuc3BvcnRlZCBvdmVyIGENICAgICAgY28tcm91dGVkIHNldCBvZiBtZW1iZXIgc2lnbmFs c3RoZSBzYW1lIHJvdXRlLiAgVGhpcyBpcyB0aGUgY2FzZSB3aGVyZSB0aGUNICAgICAgaW50ZW5k ZWQgYmFuZHdpZHRoIG9mIHRoZSBWQ0FUIGdyb3VwVkNHIGRvZXMgbm90IGNoYW5nZSBhbmQgYWxs DSAgICAgIG1lbWJlciBzaWduYWxzIGZvbGxvdyBhIHNpbWlsYXJ0aGUgc2FtZSByb3V0ZS4gIFRo ZSBpbnRlbnQgaGVyZSBpcyB0aGUNICAgICAgY2FwYWJpbGl0eSB0byBhbGxvY2F0ZSB0aGUgInJp Z2h0IiBhbW91bnQgb2YgYmFuZHdpZHRoLg0NICAgICAgQ3VycmVudGx5IHN1cHBvcnRlZCBpbiBH TVBMUy4NDSAgIEZpeGVkLCBEaXNqb2ludERpdmVyc2Utcm91dGVzOiBBIGZpeGVkIGJhbmR3aWR0 aCBWQ0FUIGdyb3VwVkNHLCB3aXRoIHRoZSBtZW1iZXJzIHRyYW5zcG9ydGVkIG92ZXIgYXQNICAg ICAgbGVhc3QgdHdvIGRpc2pvaW50bHkgZGlmZmVyZW50IHJvdXRlZCBzdWJzZXRzIG9mIG1lbWJl ciBzaWduYWxzcm91dGVzLiAgVGhlIGludGVudA0gICAgICBoZXJlIGlzIGFkZGl0aW9uYWwgcmVz aWxpZW5jZSBhbmQgZ3JhY2VmdWwgZGVncmFkYXRpb24gaW4gdGhlIGNhc2UNICAgICAgb2YgZmFp bHVyZS4NDQ0NDUJlcm5zdGVpbiwgZXQgYWwuICAgICAgICBFeHBpcmVzIEFwcmlsIDE0LCAyMDA2 ICAgICAgICAgICAgICAgICBbUGFnZSA4XQ0MDUludGVybmV0LURyYWZ0ICAgICAgICAgICAgR01Q TFMsIFZDQVQgYW5kIExDQVMgICAgICAgICAgICAgIE9jdG9iZXIgMjAwNQ0NDSAgICAgIElmIExD QVMgaXMgcHJlc2VudCB0aGlzIHNjZW5hcmlvIGlzIHN1cHBvcnRlZCB1bmRlciBHTVBMUy4gIE5v dA0gICAgICBzdXBwb3J0ZWQgd2l0aG91dCBMQ0FTIHNpbmNlIHdlIG5lZWQgdHdvLXdheSBjb21t dW5pY2F0aW9ucyBvZg0gICAgICBzb21lIHR5cGUgYmV0d2VlbiBzb3VyY2UgYW5kIHNpbmsgdG8g Y29vcmRpbmF0ZSB3aGljaCBtZW1iZXJzIGFyZQ0gICAgICB0byBiZSB1c2VkIGluIHRoZSBncm91 cCBpbiBhIGZhaWx1cmUgc2NlbmFyaW8uDQ0gICBEeW5hbWljLCBDby1yb3V0ZWQ6IEEgZHluYW1p YyBWQ0FUIGdyb3VwVkNHIChiYW5kd2lkdGggY2FuIGJlIGluY3JlYXNlZA0gICAgICBvciBkZWNy ZWFzZWQgdmlhIHRoZSBhZGRpdGlvbiBvciByZW1vdmFsIG9mIG1lbWJlciBzaWduYWxzKSwNICAg ICAgd2l0aCBhbGwgdGhlIG1lbWJlcnMgdHJhbnNwb3J0ZWQgb3ZlciBhIGNvLXJvdXRlZCBzZXQg b2YgbWVtYmVyc3RoZSBzYW1lIHJvdXRlLiAgSW50ZW50IGhlcmUgaXMNICAgICAgZHluYW1pYyBz aXppbmcgb2YgYmFuZHdpZHRoLg0NICAgICAgSWYgTENBUyBwcmVzZW50IHRoaXMgc2NlbmFyaW8g aXMgY3VycmVudGx5IHN1cHBvcnRlZCBieSBHTVBMUy4NICAgICAgSW1wbGljYXRpb25zOiBMQ0FT IGlzIG5lZWRlZCBmb3IgaGl0bGVzcyByZXNpemluZy4gIE5vdGUgYmVmb3JlDSAgICAgIExDQVMg Y2FuIGRvIGl0cyBwYXJ0IG9mIGdldHRpbmcgdHJhZmZpYyBvdmVyIHRoZSBtb2RpZmllZCBWQ0FU DSAgICAgIGdyb3VwVkNHLCB0aGUgdHdvIFZDQVQvTENBUyBlbmRwb2ludHMgbmVlZCB0byBiZSBj b25maWd1cmVkIChZIC0+IFkrMQ0gICAgICBvciBZIC0+IFktMSlYbSBhbmQgWGE7IHRoaXMgcmVx dWlyZXMgZWl0aGVyICJjb21tdW5pY2F0aW9uIiBiZXR3ZWVuIHRoZSB0d28NICAgICAgZW5kcG9p bnRzICh3aGVuIG9uZSBvZiB0aGUgZW5kcG9pbnRzIGlzIGNvbmZpZ3VyZWQgYnkgY2FsbC8NICAg ICAgY29ubmVjdGlvbiBjb250cm9sbGVyLCBvciBzaW1wbGUgY29tbXVuaWNhdGlvbiBvZiB0aGUg Y2FsbC8NICAgICAgY29ubmVjdGlvbiBjb250cm9sbGVyIHdpdGggYm90aCBlbmRwb2ludHMuICBX aXRob3V0IExDQVMgd2Ugc3RpbGwNICAgICAgbmVlZCB0d28gd2F5IGNvbW11bmljYXRpb25zIGJl dHdlZW4gc291cmNlIGFuZCBzaW5rIHRvIGNvb3JkaW5hdGUNICAgICAgd2hpY2ggbWVtYmVycyBh cmUgdXNlZCBpbiB0aGUgZ3JvdXAgYW5kBSBjaGFuZ2VzIHdpbGwgbm90IGJlDSAgICAgIGhpdGxl c3MuDQ0gICBEeW5hbWljLCBEaXNqb2ludERpdmVyc2Utcm91dGVzOiBBIGR5bmFtaWMgVkNBVCBn cm91cFZDRywgd2l0aCB0aGUgbWVtYmVycyB0cmFuc3BvcnRlZCBvdmVyIGF0IGxlYXN0DSAgICAg IHR3byBkaXNqb2ludGx5IGRpZmZlcmVudCByb3V0ZWQgc3Vic2V0cyBvZiBtZW1iZXIgc2lnbmFs c3JvdXRlcy4gIEludGVudCBoZXJlIGlzDSAgICAgIGR5bmFtaWMgcmVzaXppbmcgYW5kIHJlc2ls aWVuY2UuDQ0gICAgICBDdXJyZW50bHkgc3VwcG9ydCBhbmQgaW1wbGljYXRpb25zIHNpbWlsYXIg dG8gdGhlICJkeW5hbWljLCBjby0NICAgICAgcm91dGVkIiBhbmQgImZpeGVkLCBkaXNqb2ludGRp dmVyc2Utcm91dGVzIiBjYXNlcy4NDSAgIFNoYXJlZCBQb29sOiBUd28gb3IgbW9yZSBWQ0FUIGdy b3VwVkNHcyBiZXR3ZWVuIHRoZSBzYW1lIHNvdXJjZSBhbmQgc2luaw0gICAgICB3aG8gZGVzaXJl IHRvIHNoYXJlIGEgcG9vbCBvZiBjb21wb25lbnQgc2lnbmFscyBiZXR3ZWVuIHRoZW0uDSAgICAg IEVhY2ggVkNBVCBncm91cFZDRyBtYXkgaGF2ZSBhIGRlZGljYXRlZCBzZXQgb2YgbWVtYmVycywg YW5kIG1heSBhbHNvDSAgICAgIG9idGFpbiBhZGRpdGlvbmFsIG1lbWJlcnMgZnJvbSBhICJjb21t b24gcG9vbCIgb2YgY29tcG9uZW50cy4NICAgICAgTm90ZSB0aGF0IGF0IGFueSBnaXZlbiBwb2lu dCBpbiB0aW1lIGEgY29tcG9uZW50IHNpZ25hbCBjYW4gYmVsb25nDSAgICAgIHRvIGF0IG1vc3Qg b25lIFZDQVQgZ3JvdXBWQ0cuICBUaGUgaW50ZW50IGhlcmUgaXMgdG8gYWxsb3cgZHluYW1pYw0g ICAgICByZXNpemluZyBvZiBWQ0FUIGdyb3VwVkNHcyB2aWEgdGhlIHNoYXJpbmcgb2YgYSBwb29s IG9mIGVzdGFibGlzaGVkDSAgICAgIGNvbXBvbmVudCBzaWduYWxzIHdpdGhvdXQgcmVxdWlyaW5n IGNvbXBsZXRlIGNpcmN1aXQgcHJvdmlzaW9uaW5nLA0gICAgICBpLmUuLCBvbmx5IHRoZSBncm91 cCBtZW1iZXJzaGlwIG9mIHRoZSBjb21wb25lbnQgc2lnbmFsIHdvdWxkDSAgICAgIGNoYW5nZS4F DQ0gICAgICBDdXJyZW50bHkgbm90IHN1cHBvcnRlZCBieSBHTVBMUy4gIEltcGxpY2F0aW9uczog YSBjb21tdW5pY2F0aW9ucw0gICAgICBtZWNoYW5pc20gYmV0d2VlbiBzb3VyY2UgYW5kIHNpbmsg dG8gaW5kaWNhdGUgZHVyaW5nIGEgImNoYW5nZSINICAgICAgd2hpY2ggZ3JvdXAgYSBjb21wb25l bnQgc2hvdWxkIG5vdyBiZWxvbmcuDQ0NDQ0NDQ0NQmVybnN0ZWluLCBldCBhbC4gICAgICAgIEV4 cGlyZXMgQXByaWwgMTQsIDIwMDYgICAgICAgICAgICAgICAgIFtQYWdlIDldDQwNSW50ZXJuZXQt RHJhZnQgICAgICAgICAgICBHTVBMUywgVkNBVCBhbmQgTENBUyAgICAgICAgICAgICAgT2N0b2Jl ciAyMDA1DQ0NMy4gIFBvc3NpYmxlIEV4dGVuc2lvbnMgdG8gR01QTFMgdG8gc3VwcG9ydCBhZGRp dGlvbmFsIFZDQVQvTENBUw0gICAgc2NlbmFyaW9zDQ0gICBIZXJlIHdlIGxvb2sgYXQgd2hhdCBt aWdodCBiZSByZWFzb25hYmxlIHRvIGFkZCB0byBHTVBMUyB0byBzdXBwb3J0DSAgIHRoZSBpbnRl cmVzdCBzY2VuYXJpb3Mgb2YgU2VjdGlvbiAyIHRoYXQgd2VyZSBub3QgY3VycmVudGx5IGNvdmVy ZWQuDQ0zLjEuICBNZWNoYW5pc21zIGZvciBEaXNjb3Zlcnkgb2YgVkNBVC9MQ0FTDQ0gICBXb3Vs ZCBsaWtlIHRvIGdldCBib3RoIFZDQVQgYW5kIExDQVMgY2FwYWJpbGl0eSBvZiBlbmQgc3lzdGVt cyB2aWENICAgcm91dGluZy4uLg0NICAgV291bGQgbGlrZSB0byBiZSBhYmxlIHRvIHNwZWNpZmlj YWxseSBhc2sgZm9yIExDQVMgY2FwYWJpbGl0eSB2aWENICAgc2lnbmFsaW5nLi4uDQ0zLjIuICBN ZWNoYW5pc20gdG8gU3VwcG9ydCBNdWx0aXBsZSBDbGllbnQgdG8gRW5kIFBvaW50IE1hcHBpbmdz DQ0gICBUaGlzIGlzIGEgdmVyeSBpbXBvcnRhbnQgY2FwYWJpbGl0eSBhbmQgaXQgaXMgdmVyeSBz aW1pbGFyIHRvIG9uZQ0gICB0aGF0IGlzIGJlaW5nIHByb3Bvc2VkIGluIHRoZSBlbmQtdG8tZW5k IHNpZ25hbGluZyBmb3IgcmVjb3ZlcnkgSS1ELg0gICBJbiBwYXJ0aWN1bGFyIHRoZSBBU1NPQ0lB VElPTiBvYmplY3QuICBOb3RlLCBob3dldmVyLCBzaW5jZSB0aGVyZSBpcw0gICBhIHJhdGhlciBo aWdoIHByb2JhYmlsaXR5IHRoYXQgYXQgc29tZSBwb2ludCB3ZSBtaWdodCB1c2UgVkNBVC9MQ0FT DSAgIHdpdGggR01QTFMgYmFzZWQgcHJvdGVjdGlvbiB3ZSB3b3VsZCByZWFsbHkgbmVlZCBhbiBB U1NPQ0lBVElPTg0gICBvYmplY3QgdHlwZSBzcGVjaWZpYyB0byBWQ0FULiAgQXNzb2NpYXRpb24g b2JqZWN0cyBhcmUgbm90IHVuaXF1ZSBhbmQNICAgdGhlcmVmb3JlIGFkZGluZyBhIG5ldyB0eXBl IHRvIHRoZSBBc3NvY2lhdGlvbiBvYmplY3Qgd291bGQgbWFrZSBpdCBhDSAgIGdvb2QgY2FuZGlk YXRlIHRvIHN1cHBvcnQgdGhpcyByZXF1aXJlbWVudC4NDTMuMy4gIFN1cHBvcnQgZm9yIENvbXBv bmVudCBTaWduYWwgQ29uZmlndXJhdGlvbiBTY2VuYXJpb3MNDSAgIFRCRCBiYXNlZCBvbiBhbmFs eXNpcyBvZiB1c2Ugb2YgYWRtaW4tc3RhdHVzIG9iamVjdC4gIElmIHRoZSBhZG1pbi0NICAgc3Rh dHVzIG9iamVjdCBpcyBzdWZmaWNpZW50IHdlIHdpbGwgZGV0YWlsIGl0cyB1c2UgaW4gdGhpcw0g ICBhcHBsaWNhdGlvbiBzaW5jZSBpdCBpcyBjdXJyZW50bHkgYW4gb3B0aW9uYWwgb2JqZWN0Lg0N NC4gIFJlZmVyZW5jZXMNDSAgIFsxXSAgQmVybnN0ZWluLCBHLiwgQ2F2aWdsaWEsIEQuLCBhbmQg Ui4gUmFiYmF0LCAiVkNBVC9MQ0FTIGluIGENICAgICAgICBDbGFtc2hlbGwiLCBUbyBCZSBQdWJs aXNoZWQgYXZhaWxhYmxlIGF0IGh0dHA6Ly8NICAgICAgICB3d3cuZ3JvdHRvLW5ldHdvcmtpbmcu Y29tL3BhZ2VzL1ZDQVQtaW4tYS1DbGFtc2hlbGwtRFJBRlQucGRmLA0gICAgICAgIE9jdG9iZXIg MjAwNS4NDSAgIFsyXSAgSW50ZXJuYXRpb25hbCBUZWxlY29tbXVuaWNhdGlvbnMgVW5pb24sICJO ZXR3b3JrIG5vZGUgaW50ZXJmYWNlDSAgICAgICAgZm9yIHRoZSBzeW5jaHJvbm91cyBkaWdpdGFs IGhpZXJhcmNoeSAoU0RIKSIsIElUVS0NICAgICAgICBUIFJlY29tbWVuZGF0aW9uIEcuNzA3LCBE ZWNlbWJlciAyMDAzLg0NICAgWzNdICBBbWVyaWNhbiBOYXRpb25hbCBTdGFuZGFyZHMgSW5zdGl0 dXRlLCAiU3luY2hyb25vdXMgT3B0aWNhbA0gICAgICAgIE5ldHdvcmsgKFNPTkVUKSAtIEJhc2lj IERlc2NyaXB0aW9uIGluY2x1ZGluZyBNdWx0aXBsZXgNICAgICAgICBTdHJ1Y3R1cmUsIFJhdGVz LCBhbmQgRm9ybWF0cyIsIEFOU0kgVDEuMTA1LTIwMDEsIDIwMDEuDQ0gICBbNF0gICJMaW5rIGNh cGFjaXR5IGFkanVzdG1lbnQgc2NoZW1lIChMQ0FTKSBmb3IgdmlydHVhbCBjb25jYXRlbmF0ZWQN ICAgICAgICBzaWduYWxzIiwgSVRVLVQgUmVjb21tZW5kYXRpb24gRy43MDQyLCBGZWJydWFyeSAy MDA0Lg0NDQ1CZXJuc3RlaW4sIGV0IGFsLiAgICAgICAgRXhwaXJlcyBBcHJpbCAxNCwgMjAwNiAg ICAgICAgICAgICAgICBbUGFnZSAxMF0NDA1JbnRlcm5ldC1EcmFmdCAgICAgICAgICAgIEdNUExT LCBWQ0FUIGFuZCBMQ0FTICAgICAgICAgICAgICBPY3RvYmVyIDIwMDUNDQ0gICBbNV0gICJWaXJ0 dWFsIGNvbmNhdGVuYXRpb24gb2YgcGxlc2lvY2hyb25vdXMgZGlnaXRhbCBoaWVyYXJjaHkgKFBE SCkNICAgICAgICBzaWduYWxzIiwgSVRVLVQgUmVjb21tZW5kYXRpb24gRy43MDQzLCBKdWx5IDIw MDQuDQ0gICBbNl0gICJJbnRlcmZhY2VzIGZvciB0aGUgT3B0aWNhbCBUcmFuc3BvcnQgTmV0d29y ayAoT1ROKSIsIElUVS0NICAgICAgICBUIFJlY29tbWVuZGF0aW9uIEcuNzA5LCBNYXJjaCAyMDAz Lg0NICAgWzddICBTa2xvd2VyLCBLLiwgTGxveWQsIEIuLCBNY0dyZWdvciwgRy4sIENhcnIsIEQu LCBhbmQgVC4NICAgICAgICBDb3JhZGV0dGksICJUaGUgUFBQIE11bHRpbGluayBQcm90b2NvbCAo TVApIiwgUkZDIDE5OTAsDSAgICAgICAgQXVndXN0IDE5OTYuDQ0gICBbOF0gICJJbmZvcm1hdGlv biB0ZWNobm9sb2d5IC0gVGVsZWNvbW11bmljYXRpb25zIGFuZCBpbmZvcm1hdGlvbg0gICAgICAg IGV4Y2hhbmdlIGJldHdlZW4gc3lzdGVtcyAtIExvY2FsIGFuZCBtZXRyb3BvbGl0YW4gYXJlYSBu ZXR3b3Jrcw0gICAgICAgIC0gU3BlY2lmaWMgcmVxdWlyZW1lbnRzIC0gUGFydCAzOiBDYXJyaWVy IHNlbnNlIG11bHRpcGxlIGFjY2Vzcw0gICAgICAgIHdpdGggY29sbGlzaW9uIGRldGVjdGlvbiAo Q1NNQS9DRCkgYWNjZXNzIG1ldGhvZCBhbmQgcGh5c2ljYWwNICAgICAgICBsYXllciBzcGVjaWZp Y2F0aW9ucyIsIElFRUUgU3RhbmRhcmQgODAyLjMsIE1hcmNoIDIwMDIuDQ0gICBbOV0gIEJlcm5z dGVpbiwgRy4sIFJhamFnb3BhbGFuLCBCLiwgYW5kIEQuIFNhaGEsICJPcHRpY2FsIE5ldHdvcmsN ICAgICAgICBDb250cm9sOiBBcmNodGVjdHVyZSwgUHJvdG9jb2xzIiwgQWRkaXNvbi1XZXNsZXks IDIwMDQuDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDUJlcm5zdGVpbiwgZXQgYWwu ICAgICAgICBFeHBpcmVzIEFwcmlsIDE0LCAyMDA2ICAgICAgICAgICAgICAgIFtQYWdlIDExXQ0M DUludGVybmV0LURyYWZ0ICAgICAgICAgICAgR01QTFMsIFZDQVQgYW5kIExDQVMgICAgICAgICAg ICAgIE9jdG9iZXIgMjAwNQ0NDUFwcGVuZGl4IEEuICBBY2tub3dsZWRnZW1lbnRzDQ0gICBUaGUg YXV0aG9ycyB3b3VsZCBsaWtlIHRvIHRoYW5rIE1hYXJ0ZW4gVmlzc2VycyBmb3IgZXh0ZW5zaXZl IHJldmlld3MNICAgYW5kIGNvbnRyaWJ1dGlvbnMgdG8gdGhpcyBkcmFmdC4NDQ0NDQ0NDQ0NDQ0N DQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ1CZXJuc3RlaW4sIGV0IGFsLiAgICAg ICAgRXhwaXJlcyBBcHJpbCAxNCwgMjAwNiAgICAgICAgICAgICAgICBbUGFnZSAxMl0NDA1JbnRl cm5ldC1EcmFmdCAgICAgICAgICAgIEdNUExTLCBWQ0FUIGFuZCBMQ0FTICAgICAgICAgICAgICBP Y3RvYmVyIDIwMDUNDQ1BdXRob3JzJyBBZGRyZXNzZXMNDSAgIEdyZWcgQmVybnN0ZWluDSAgIEdy b3R0byBOZXR3b3JraW5nDQ0gICBQaG9uZTogKzEgNTEwIDU3MyAyMjM3DSAgIEVtYWlsOiBncmVn YkBncm90dG8tbmV0d29ya2luZy5jb20NDQ0gICBEaWVnbyBDYXZpZ2xpYQ0gICBNYXJjb25pDQ0g ICBFbWFpbDogRGllZ28uQ2F2aWdsaWFAbWFyY29uaS5jb20NDQ0gICBSaWNoYXJkIFJhYmJhdA0g ICBGdWppdHN1DQ0gICBQaG9uZTogKzEgNDA4IDUzMCA0NTM3DSAgIEVtYWlsOiByaWNoYXJkQHVz LmZ1aml0c3UuY29tDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ1CZXJuc3RlaW4sIGV0 IGFsLiAgICAgICAgRXhwaXJlcyBBcHJpbCAxNCwgMjAwNiAgICAgICAgICAgICAgICBbUGFnZSAx M10NDA1JbnRlcm5ldC1EcmFmdCAgICAgICAgICAgIEdNUExTLCBWQ0FUIGFuZCBMQ0FTICAgICAg ICAgICAgICBPY3RvYmVyIDIwMDUNDQ1JbnRlbGxlY3R1YWwgUHJvcGVydHkgU3RhdGVtZW50DQ0g ICBUaGUgSUVURiB0YWtlcyBubyBwb3NpdGlvbiByZWdhcmRpbmcgdGhlIHZhbGlkaXR5IG9yIHNj b3BlIG9mIGFueQ0gICBJbnRlbGxlY3R1YWwgUHJvcGVydHkgUmlnaHRzIG9yIG90aGVyIHJpZ2h0 cyB0aGF0IG1pZ2h0IGJlIGNsYWltZWQgdG8NICAgcGVydGFpbiB0byB0aGUgaW1wbGVtZW50YXRp b24gb3IgdXNlIG9mIHRoZSB0ZWNobm9sb2d5IGRlc2NyaWJlZCBpbg0gICB0aGlzIGRvY3VtZW50 IG9yIHRoZSBleHRlbnQgdG8gd2hpY2ggYW55IGxpY2Vuc2UgdW5kZXIgc3VjaCByaWdodHMNICAg bWlnaHQgb3IgbWlnaHQgbm90IGJlIGF2YWlsYWJsZTsgbm9yIGRvZXMgaXQgcmVwcmVzZW50IHRo YXQgaXQgaGFzDSAgIG1hZGUgYW55IGluZGVwZW5kZW50IGVmZm9ydCB0byBpZGVudGlmeSBhbnkg c3VjaCByaWdodHMuICBJbmZvcm1hdGlvbg0gICBvbiB0aGUgcHJvY2VkdXJlcyB3aXRoIHJlc3Bl Y3QgdG8gcmlnaHRzIGluIFJGQyBkb2N1bWVudHMgY2FuIGJlDSAgIGZvdW5kIGluIEJDUCA3OCBh bmQgQkNQIDc5Lg0NICAgQ29waWVzIG9mIElQUiBkaXNjbG9zdXJlcyBtYWRlIHRvIHRoZSBJRVRG IFNlY3JldGFyaWF0IGFuZCBhbnkNICAgYXNzdXJhbmNlcyBvZiBsaWNlbnNlcyB0byBiZSBtYWRl IGF2YWlsYWJsZSwgb3IgdGhlIHJlc3VsdCBvZiBhbg0gICBhdHRlbXB0IG1hZGUgdG8gb2J0YWlu IGEgZ2VuZXJhbCBsaWNlbnNlIG9yIHBlcm1pc3Npb24gZm9yIHRoZSB1c2Ugb2YNICAgc3VjaCBw cm9wcmlldGFyeSByaWdodHMgYnkgaW1wbGVtZW50ZXJzIG9yIHVzZXJzIG9mIHRoaXMNICAgc3Bl Y2lmaWNhdGlvbiBjYW4gYmUgb2J0YWluZWQgZnJvbSB0aGUgSUVURiBvbi1saW5lIElQUiByZXBv c2l0b3J5IGF0DSAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaXByLg0NICAgVGhlIElFVEYgaW52aXRl cyBhbnkgaW50ZXJlc3RlZCBwYXJ0eSB0byBicmluZyB0byBpdHMgYXR0ZW50aW9uIGFueQ0gICBj b3B5cmlnaHRzLCBwYXRlbnRzIG9yIHBhdGVudCBhcHBsaWNhdGlvbnMsIG9yIG90aGVyIHByb3By aWV0YXJ5DSAgIHJpZ2h0cyB0aGF0IG1heSBjb3ZlciB0ZWNobm9sb2d5IHRoYXQgbWF5IGJlIHJl cXVpcmVkIHRvIGltcGxlbWVudA0gICB0aGlzIHN0YW5kYXJkLiAgUGxlYXNlIGFkZHJlc3MgdGhl IGluZm9ybWF0aW9uIHRvIHRoZSBJRVRGIGF0DQ0gICBpZXRmLWlwckBpZXRmLm9yZy4NDQ1EaXNj bGFpbWVyIG9mIFZhbGlkaXR5DQ0gICBUaGlzIGRvY3VtZW50IGFuZCB0aGUgaW5mb3JtYXRpb24g Y29udGFpbmVkIGhlcmVpbiBhcmUgcHJvdmlkZWQgb24gYW4NICAgIkFTIElTIiBiYXNpcyBhbmQg VEhFIENPTlRSSUJVVE9SLCBUSEUgT1JHQU5JWkFUSU9OIEhFL1NIRSBSRVBSRVNFTlRTDSAgIE9S IElTIFNQT05TT1JFRCBCWSAoSUYgQU5ZKSwgVEhFIElOVEVSTkVUIFNPQ0lFVFkgQU5EIFRIRSBJ TlRFUk5FVA0gICBFTkdJTkVFUklORyBUQVNLIEZPUkNFIERJU0NMQUlNIEFMTCBXQVJSQU5USUVT LCBFWFBSRVNTIE9SIElNUExJRUQsDSAgIElOQ0xVRElORyBCVVQgTk9UIExJTUlURUQgVE8gQU5Z IFdBUlJBTlRZIFRIQVQgVEhFIFVTRSBPRiBUSEUNICAgSU5GT1JNQVRJT04gSEVSRUlOIFdJTEwg Tk9UIElORlJJTkdFIEFOWSBSSUdIVFMgT1IgQU5ZIElNUExJRUQNICAgV0FSUkFOVElFUyBPRiBN RVJDSEFOVEFCSUxJVFkgT1IgRklUTkVTUyBGT1IgQSBQQVJUSUNVTEFSIFBVUlBPU0UuDQ0NQ29w eXJpZ2h0IFN0YXRlbWVudA0NICAgQ29weXJpZ2h0IChDKSBUaGUgSW50ZXJuZXQgU29jaWV0eSAo MjAwNSkuICBUaGlzIGRvY3VtZW50IGlzIHN1YmplY3QNICAgdG8gdGhlIHJpZ2h0cywgbGljZW5z ZXMgYW5kIHJlc3RyaWN0aW9ucyBjb250YWluZWQgaW4gQkNQIDc4LCBhbmQNICAgZXhjZXB0IGFz IHNldCBmb3J0aCB0aGVyZWluLCB0aGUgYXV0aG9ycyByZXRhaW4gYWxsIHRoZWlyIHJpZ2h0cy4N DQ1BY2tub3dsZWRnbWVudA0NICAgRnVuZGluZyBmb3IgdGhlIFJGQyBFZGl0b3IgZnVuY3Rpb24g aXMgY3VycmVudGx5IHByb3ZpZGVkIGJ5IHRoZQ0gICBJbnRlcm5ldCBTb2NpZXR5Lg0NDQ0NQmVy bnN0ZWluLCBldCBhbC4gICAgICAgIEV4cGlyZXMgQXByaWwgMTQsIDIwMDYgICAgICAgICAgICAg ICAgW1BhZ2UgMTRdDQwNBVdoaWxlIEkgYWdyZWUgd2l0aCB5b3VyIG5vbWVuY2xhdHVyZSBmb3Ig VkNBVHRlZCBQREggc2lnbmFscywgaXQgc2hvdWxkIGJlIHBvaW50ZWQgb3V0IHRoYXQgdGhpcyBo YXMgbm90IHlldCBiZWVuIHByb3Bvc2VkIG9yIGFjY2VwdGVkIHdpdGhpbiB0aGUgSVRVLVQgU0cx NS4NBUkgZG9uknQgaGF2ZSB0aGlzIHJlZmVyZW5jZSwgYnV0IHRoaW5rIGl0IHdvdWxkIGJlIHVz ZWZ1bCBmb3IgdGhlIHJlYWRlciB0byBiZSB0b2xkIHRoYXQgdGhlIG9wZXJhdGlvbiB0aW1lIG9m IExDQVMgYXJlIHNvbGUgZGVwZW5kYW50IG9uICgxKSB0aGUgcHJvcGFnYXRpb24gdGltZSBmb3Jt IFNvIHRvIFNrIGFuZCB0aGUgdGltZSB0aGF0IExDQVMgdGFrZXMgdG8gkWN5Y2xlkiByb3VuZCB0 byB0aGUgYXBwcm9wcmlhdGUgTVNUIGJ5dGUgdGhhdCBjb250YWlucyB0aGUgTVNUIGZvciB0aGUg cmVsZXZhbnQgbWVtYmVyLiBUaGUgd29yc3QgY2FzZSBjeWNsZSB0aW1lIGZvciBITyBpcyA2NCBt cyBhbmQgZm9yIExPIGl0IGlzIDEyOCBtcy4gTm90ZSB0aGlzIGRvZXMgbm90IHRha2UgaW50byBh Y2NvdW50IHRoZSBwcm9wYWdhdGlvbiB0aW1lKHMpLg0FSZJtIG5vdCBzdXJlIHdoYXQgaXMgbWVh bnQgaGVyZS4gSWYgkWRpdmVyc2Ugcm91dGluZ5IgaXMgbWVhbnQsIHRoZW4gSSB0aGluayB0aGlz IGlzIHRoZSB0ZXJtIHRoYXQgc2hvdWxkIGJlIHVzZWQ7IGhvd2V2ZXIgSSBhbSBub3QgZmFtaWxp YXIgZW5vdWdoIHdpdGggR01QTFMgdG8gY29tbWVudCBvbiB0aGlzIHN0YXRlbWVudC4NBUkgYW0g bm90IGZhbWlsaWFyIGVub3VnaCB3aXRoIEdNUExTIHRvIHVuZGVyc3RhbmQgd2h5IHRoaXMgaXMg c28uIFRoZSBWQ0FUIChvciBMQ0FTKSBmdW5jdGlvbiBkb2VzIG5vdCBrbm93IG9yIGNhcmUgYWJv dXQgdGhlIHJvdXRpbmcgb2YgdGhlIGluZGl2aWR1YWwgbWVtYmVycyBvZiB0aGUgVkNHOyBleGNl cHQgb2YgY291cnNlIHRoZSBkaWZmZXJlbnRpYWwgZGVsYXkgbXVzdCBiZSBrZXB0IHdpdGhpbiBt ZWFzdXJhYmxlIGFuZCBjb21wZW5zYXRhYmxlIGxpbWl0cy4NBVNlZSBwcmV2aW91cyBjb21tZW50 IGluIHNlY3Rpb24gMS4zLg0FVG8gYWRkIGFuIGFsdGVybmF0aXZlIG1lbWJlciBpbiBwbGFjZSBv ZiB0aGUgZmFpbGVkIG1lbWJlciB3aWxsIHJlcXVpcmUgbWFuYWdlbWVudCBpbnRlcnZlbnRpb24u DQVJIGJlbGlldmUgdGhlIHVzZSBvZiB0aGUgdGVybSBzdWJzZXQgaXMgZGFuZ2Vyb3VzIHNpbmNl IHNvbWUgcGVvcGxlIHdpbGwgdGhpbmsgb2YgYSBzdWJzZXQgYXMgYW5vdGhlciBWQ0cuIA0FU2hv dWxkIHRoaXMgYmUgkW9ykiA/Pw0FAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYAALMZAADI GQAA1hkAAN8ZAABlHAAAaxwAAHYcAAB9HAAAgBwAAIIcAAAAHQAADB0AACwdAAA9HQAAXx0AAGwd AABwHQAAcx0AAIsdAAChHQAAwR0AAMUdAAAFHgAAFR8AADAfAAAzHwAABSAAAPnj+dn5z/m5r6L5 z5iOhI6YeoRwZvlQ+bmv+QAAAAAAAAAAAAAAAAAAAAAAAAAAACsACIEVaAIIoAAWaCRU7gAXaBV2 PwBjSAEAZGgAAAAAZGgAAAAAZGjrcpqmEwEIgQRIAQAFaOtymqYWaBV2PwATAQiBBEgBAAVo5HKa phZoRQrKABMBCIEESAEABWjjcpqmFmgVdj8AEwEIgQRIAQAFaOpymqYWaBV2PwATAQiBBEgBAAVo 4XKaphZoFXY/ABMBCIEESAEABWjhcpqmFmhFCsoAGQEIgQRIAQAFaIZzmqYVaAIIoAAWaEJaFwAT AQiBBEgBAAVohnOaphZoQloXACsACIEVaAIIoAAWaCRU7gAXaEJaFwBjSAEAZGgAAAAAZGgAAAAA ZGiGc5qmEwEIgQRIAQAFaOBymqYWaEUKygATAQiBBEgBAAVo3nKaphZoRQrKACsACIEVaAIIoAAW aCRU7gAXaEUKygBjSAEAZGgAAAAAZGgAAAAAZGjecpqmDBVoAgigABZoJFTuABsABgAAAQgAAAII AABLCAAAlAgAAN0IAAAmCQAAbwkAALgJAAABCgAAAgoAAAMKAABMCgAAlAoAAM0KAADOCgAA4goA AOMKAAApCwAAbgsAALQLAAD4CwAA+QsAAD4MAACCDAAAxQwAANAMAADRDAAAGg0AAGINAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAAAAAAAEDwBnZAIIoAAAHQAGAADAfAAAbe0A AP7+AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAQECYg0AAKQNAADjDQAA 5A0AAB4OAABNDgAATg4AAJIOAAC2DgAAtw4AAO0OAADuDgAA/w4AAAAPAAAuDwAALw8AADgPAAA5 DwAAfg8AAMcPAAAOEAAAVBAAAFUQAABWEAAAVxAAAKAQAACiEAAA6xAAAOwQAADtEAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAAAAAAABA8AZ2QCCKAAAB3tEAAANBEAAHwRAADA EQAA8xEAAPQRAAD1EQAABxIAAAgSAABREgAAmhIAAOMSAAAsEwAAdRMAAL4TAAAHFAAAUBQAAJkU AADiFAAAHBUAAGUVAACuFQAA6xUAADQWAAB9FgAAxhYAAA8XAABYFwAAoRcAAKIXAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAAAAAAAEDwBnZAIIoAAAHaIXAACjFwAApBcAAKUX AACmFwAApxcAAKgXAACpFwAAqhcAAKsXAACsFwAArRcAAK4XAACvFwAAsBcAALEXAACyFwAAsxcA ALQXAAC1FwAAthcAALcXAAC4FwAAARgAAAMYAABMGAAATRgAAE4YAABsGAAAbRgAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAAAAAAAAQPAGdkAgigAAAdbRgAAK8YAAD4GAAAQBkA AIcZAADJGQAAGBoAAGEaAACoGgAA1RoAANYaAAD4GgAA+RoAAEAbAACEGwAAyBsAABAcAAAiHAAA IxwAAG0cAAC6HAAAwh0AAAkeAAAdHgAAHh4AAGIeAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA9QAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA8AAAAAAA AAAAAAAAAN0AAAAAAAAAAAAAAADYAAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAAAAAAAAQPAGdkFXY/ABMPAGdkFXY/AG/GBwEBAOtymqZkJgEPhGgBEYSY /l6EaAFghJj+AAQPAGdkQloXAAAEDwBnZEUKygAABA8AZ2QCCKAAABliHgAAqh4AAPEeAAA8HwAA gR8AAMcfAAAHIAAACCAAAE8gAACXIAAA3iAAACAhAAAhIQAASSEAAEohAACRIQAALCMAAHQjAADB IwAABCQAAEQkAABFJAAARiQAAEckAABIJAAAkSQAAJMkAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPUAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AADqAAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAOUAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEDwBnZP0qhQALDwBn ZOYcywBvxgcBAQB6kppGZCYBAAQPAGdkQloXAAAEDwBnZAIIoAAAGgUgAAAGIAAAtiEAAOQhAAAq IgAANSIAAD4iAABUIgAAWSIAAGMiAABkIgAAeyIAAH4iAACfIgAAoSIAALciAAC4IgAAuSIAALoi AAAHIwAACCMAAK0jAACvIwAAuCMAAMAjAAA6JAAAQiQAAJ4lAACoJQAA7ufd08m/ybXJq8m1yaHJ ocmhyZeB52th52HnSwAAAAAAACsACIEVaAIIoAAWaCRU7gAXaMA9rwBjSAEAZGgAAAAAZGgAAAAA ZGiCc5qmEwEIgQRIAQAFaCpzmqYWaP0qhQArAAiBFWgCCKAAFmgkVO4AF2j9KoUAY0gBAGRoAAAA AGRoAAAAAGRoKnOapisACIEVaAIIoAAWaCRU7gAXaP0qhQBjSAEAZGgAAAAAZGgAAAAAZGgpc5qm EwEIgQRIAQAFaClzmqYWaP0qhQATAQiBBEgBAAVo+XKaphZoZ2EkABMBCIEESAEABWgmc5qmFmj9 KoUAEwEIgQRIAQAFaHqSmkYWaOYcywATAQiBBEgBAAVoeZKaRhZo5hzLABMBCIEESAEABWj4cpqm FmhnYSQAEwEIgQRIAQAFaPJymqYWaBV2PwATAQiBBEgBAAVo8XKaphZoFXY/AAwVaAIIoAAWaCRU 7gAAIgNqAAAAABZoFXY/ADBKEAA8CIFPSgAAUUoAAFUIAV5KAAAckyQAANwkAADdJAAA3iQAAPYk AAD3JAAAPSUAAH0lAADBJQAACSYAAFQmAACaJgAA4SYAACknAAAqJwAAcScAALgnAAAAKAAARSgA AGcoAABoKAAAsCgAAPwoAABFKQAAEyoAAF4qAACXKgAAmCoAAJkqAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPUA AAAAAAAAAAAAAAD1AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAEDwBnZEZgKQAABA8AZ2QCCKAAAByoJQAAqyUAABwmAAAmJgAAKSYA AMUnAADPJwAA0icAAFgoAABiKAAAZSgAALsoAAC+KAAATCkAAFMpAABdKQAAYykAAGQpAACfKQAA 3SkAAN4pAADjKQAA5CkAAEgqAABRKgAAVyoAAJUqAACWKgAA/DEAAAYyAAAJMgAA8jIAAPXu2PXu 2PXu2PXuzu7ErqSXjYN5Y3nurqTuUe7Y9e4AAAAiA2oAAAAAFmhzXAwAMEoQADwIgU9KAABRSgAA VQgBXkoAAAArAAiBFWgCCKAAFmgkVO4AF2hGYCkAY0gBAGRoAAAAAGRoAAAAAGRoaXOaphMBCIEE SAEABWhpc5qmFmhGYCkAEwEIgQRIAQAFaGhzmqYWaEZgKQATAQiBBEgBAAVoZ3OaphZoRmApABkB CIEESAEABWhlc5qmFWgCCKAAFmhGYCkAEwEIgQRIAQAFaGVzmqYWaEZgKQArAAiBFWgCCKAAFmgk VO4AF2hGYCkAY0gBAGRoAAAAAGRoAAAAAGRoZXOaphMBCIEESAEABWhcc5qmFmiVP4cAEwEIgQRI AQAFaFtzmqYWaJU/hwArAAiBFWgCCKAAFmgkVO4AF2jAPa8AY0gBAGRoAAAAAGRoAAAAAGRognOa pgwVaAIIoAAWaCRU7gAAEwEIgQRIAQAFaIJzmqYWaMA9rwAAH5kqAACaKgAAmyoAAJwqAACdKgAA nioAAJ8qAACgKgAAoSoAAKIqAACjKgAApCoAAKUqAACmKgAApyoAAKgqAACpKgAAqioAAKsqAACs KgAArSoAAK4qAACvKgAAsCoAALEqAACyKgAAsyoAAPwqAAD+KgAARysAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAAAAAAAAQPAGdkAgigAAAdRysAAEgrAABJKwAAcysAAHQrAAC5 KwAAACwAAEcsAACJLAAA0iwAABotAABcLQAAXS0AAIQtAACFLQAAzi0AABMuAAA+LgAAPy4AAIcu AADHLgAADi8AAFAvAACULwAAzy8AANAvAAAXMAAAXTAAAKQwAADFMAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAAAAAAABA8AZ2QCCKAAAB3FMAAAxjAAAAsxAABPMQAAkzEAANsx AAALMgAADDIAAC8yAAAwMgAAczIAALQyAAAkMwAAaTMAALAzAAD4MwAAQTQAAH80AAAPNQAAEDUA ABE1AAASNQAAEzUAABQ1AAAVNQAAXjUAAGA1AACpNQAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD1AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA 8AAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAADrAAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAAAAAAAAAAAAAEDwBnZIMH bwAABA8AZ2TAPa8AAAQPAGdk5yR1AAAEDwBnZAIIoAAAG/IyAAD0MgAABzMAAAgzAAAQMwAAIzMA AKIzAACsMwAArzMAADk0AAA9NAAAQDQAAEw0AABWNAAAYDQAAJY0AACvNAAAszQAALg0AAC/NAAA xDQAAMc0AADQNAAA6d/Sy9/LtavLlYvLdbV1a2FLdctBYQAAAAAAAAAAAAAAAAAAAAATAQiBBEgB AAVomnOaphZogwdvACsACIEVaAIIoAAWaCRU7gAXaMA9rwBjSAEAZGgAAAAAZGgAAAAAZGh6c5qm EwEIgQRIAQAFaIlzmqYWaEJaFwATAQiBBEgBAAVoiHOaphZoQloXACsACIEVaAIIoAAWaCRU7gAX aEJaFwBjSAEAZGgAAAAAZGgAAAAAZGiIc5qmEwEIgQRIAQAFaHlzmqYWaMA9rwArAAiBFWgCCKAA FmgkVO4AF2jAPa8AY0gBAGRoAAAAAGRoAAAAAGRoeXOaphMBCIEESAEABWiCc5qmFmjAPa8AKwAI gRVoAgigABZoJFTuABdowD2vAGNIAQBkaAAAAABkaAAAAABkaIJzmqYMFWgCCKAAFmgkVO4AABkB CIEESAEABWiJkppGFWgCCKAAFmjnJHUAEwEIgQRIAQAFaImSmkYWaOckdQArAAiBFWgCCKAAFmgk VO4AF2jnJHUAY0gBAGRoAAAAAGRoAAAAAGRoiZKaRgAW0DQAANg0AADfNAAACjUAAA41AAADNgAA BDYAAAU2AABVNgAAXzYAAHI2AABzNgAAqDYAAKs2AACxNgAAsjYAABI3AAAcNwAAHzcAAIo3AADp 4tjO4sSu4piOgeJrYVTiPjTiAAAAAAATAQiBBEgBAAVognOaphZowD2vACsACIEVaAIIoAAWaCRU 7gAXaMA9rwBjSAEAZGgAAAAAZGgAAAAAZGiCc5qmGQEIgQRIAQAFaIuSmkYVaAIIoAAWaOckdQAT AQiBBEgBAAVoi5KaRhZo5yR1ACsACIEVaAIIoAAWaCRU7gAXaOckdQBjSAEAZGgAAAAAZGgAAAAA ZGiLkppGGQEIgQRIAQAFaHtzmqYVaAIIoAAWaMA9rwATAQiBBEgBAAVoe3OaphZowD2vACsACIEV aAIIoAAWaCRU7gAXaMA9rwBjSAEAZGgAAAAAZGgAAAAAZGh7c5qmKwAIgRVoAgigABZoJFTuABdo 5yR1AGNIAQBkaAAAAABkaAAAAABkaIqSmkYTAQiBBEgBAAVoipKaRhZo5yR1ABMBCIEESAEABWib c5qmFmiDB28AEwEIgQRIAQAFaJpzmqYWaIMHbwAMFWgCCKAAFmgkVO4AACsACIEVaAIIoAAWaCRU 7gAXaIMHbwBjSAEAZGgAAAAAZGgAAAAAZGiac5qmABOpNQAAqjUAAKs1AADyNQAAOjYAAJc2AADn NgAAJzcAAGw3AADcNwAA3TcAACE4AABsOAAAtDgAAP84AABCOQAAijkAANE5AAAXOgAAXToAAG46 AABvOgAAlToAAJY6AADaOgAAJTsAAGw7AACPOwAAkDsAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD1AAAAAAAAAAAAAAAA8AAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAAA BA8AZ2TnJHUAAAQPAGdkwD2vAAAEDwBnZAIIoAAAHIo3AADMNwAA0jcAANo3AAAcOAAALDgAAC84 AADmOAAA8DgAAPM4AABpOQAAczkAAHY5AADfOQAA4DkAADo6AABEOgAARzoAAAs7AAAVOwAAGDsA AOY7AADxOwAA+jsAAPs7AAAlPAAA9ev15M7E5K6k5K6k5JLkrqTkfHLkXFJF5AAAAAAAAAAAABkB CIEESAEABWjic5qmFWgCCKAAFmjBG28AEwEIgQRIAQAFaOJzmqYWaMEbbwArAAiBFWgCCKAAFmgk VO4AF2jBG28AY0gBAGRoAAAAAGRoAAAAAGRo4nOaphMBCIEESAEABWiDc5qmFmjAPa8AKwAIgRVo AgigABZoJFTuABdowD2vAGNIAQBkaAAAAABkaAAAAABkaINzmqYiA2oAAAAAFmjnJHUAMEoQADwI gU9KAABRSgAAVQgBXkoAAAATAQiBBEgBAAVognOaphZowD2vACsACIEVaAIIoAAWaCRU7gAXaMA9 rwBjSAEAZGgAAAAAZGgAAAAAZGiCc5qmEwEIgQRIAQAFaIRzmqYWaEJaFwArAAiBFWgCCKAAFmgk VO4AF2hCWhcAY0gBAGRoAAAAAGRoAAAAAGRohHOapgwVaAIIoAAWaCRU7gAAEwEIgQRIAQAFaIuS mkYWaOckdQATAQiBBEgBAAVozXOaphZo9yF5AAAZkDsAANQ7AAAnPAAAKDwAAH08AADDPAAAHT0A AC49AAAvPQAAdT0AAL09AAD4PQAA+T0AAEE+AACKPgAA6j4AAEg/AABJPwAAmz8AAOE/AAAZQAAA G0AAABxAAAAdQAAAHkAAAB9AAABoQAAAakAAALNAAAD6AAAAAAAAAAAAAAAA9QAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA9QAAAAAAAAAAAAAAAPUAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPUAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAEDwBnZMEbbwAABA8AZ2QCCKAAABwlPAAAJjwAAGY8AABvPAAAeTwAAHw8AACDPAAA izwAANk8AADsPAAA/TwAAIM+AACWPgAAqz4AALQ+AADCPgAA0D4AANE+AAAQPwAARj8AAIE/AACK PwAAjj8AAI8/AADVPwAA1j8AABhAAAA3QQAA7ufdx73np+en3eeR54fnfeeRh+dz513nc13nAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAArAAiBFWgCCKAAFmgk VO4AF2jBG28AY0gBAGRoAAAAAGRoAAAAAGRo53OaphMBCIEESAEABWjnc5qmFmjBG28AEwEIgQRI AQAFaKGSmkYWaMRXOgATAQiBBEgBAAVo5nOaphZowRtvACsACIEVaAIIoAAWaCRU7gAXaMEbbwBj SAEAZGgAAAAAZGgAAAAAZGjmc5qmKwAIgRVoAgigABZoJFTuABdowRtvAGNIAQBkaAAAAABkaAAA AABkaORzmqYTAQiBBEgBAAVog3OaphZowD2vACsACIEVaAIIoAAWaCRU7gAXaMA9rwBjSAEAZGgA AAAAZGgAAAAAZGiDc5qmEwEIgQRIAQAFaORzmqYWaMEbbwAMFWgCCKAAFmgkVO4AACIDagAAAAAW aMRXOgAwShAAPAiBT0oAAFFKAABVCAFeSgAAG7NAAAC0QAAAtUAAANhAAADZQAAAH0EAABxCAACq QgAAPEMAANRDAAAzRAAAVUQAAFZEAACrRAAA40QAAOREAAAsRQAAYUUAAGJFAACwRQAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD1AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAADqAAAAAAAAAAAAAAAA5QAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA4AAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA 0QAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAPDwBnZBVt0ABv xgcBAQAijJomZCYBDcYFAAHsBIAABA8AZ2TBG28AAAQPAGdkiySxAAsPAGdkiySxAG/GBwEBADeL miZkJgEABA8AZ2TBNrQAAAQPAGdkAgigAAATN0EAADpBAAA7QQAAPEEAAEJBAABKQQAAYUEAAGVB AAB+QQAAjUEAAABCAAACQgAABEIAAAhCAAAKQgAAEEIAABxDAAAwQwAAcEMAALRDAADCQwAA6d/S y9/LwbetoJOtk4lzXUddyz0AAAAAAAAAAAAAAAAAAAAAAAATAQiBBEgBAAVoNouaJhZoiySxACsA CIEVaAIIoAAWaCRU7gAXaMA9rwBjSAEAZGgAAAAAZGgAAAAAZGiDc5qmKwAIgRVoAgigABZoJFTu ABdoiySxAGNIAQBkaAAAAABkaAAAAABkaDaLmiYrAAiBFWiLJLEAFmgkVO4AF2iLJLEAY0gBAGRo AAAAAGRoAAAAAGRoNouaJhMBCIEESAEABWg1i5omFmiLJLEAGQEIgQRIAQAFaDSLmiYVaIsksQAW aIsksQAZAQiBBEgBAAVoM4uaJhVoiySxABZoiySxABMBCIEESAEABWgzi5omFmiLJLEAEwEIgQRI AQAFaDKLmiYWaIsksQATAQiBBEgBAAVoopKaRhZoxFc6AAwVaAIIoAAWaCRU7gAAGQEIgQRIAQAF aK6KmiYVaIsksQAWaME2tAATAQiBBEgBAAVoroqaJhZowTa0ACsACIEVaAIIoAAWaCRU7gAXaME2 tABjSAEAZGgAAAAAZGgAAAAAZGiuipomABTCQwAA7EMAAPBDAAD+QwAACkQAACVEAAB5RAAAhEQA AI1EAACORAAAlUQAAJ9EAACiRAAAykQAANREAADXRAAAMkUAADxFAAA/RQAAaEUAAGtFAADURQAA +0UAACJGAAA6RgAAYkYAAHpGAADp0+nM6cy2rJ/MiX/MiX/MiX/MdWthV2FNVwAAAAAAAAAAAAAA AAAAAAAAAAAAEwEIgQRIAQAFaCSMmiYWaBVt0AATAQiBBEgBAAVoJYyaJhZoFW3QABMBCIEESAEA BWgjjJomFmgVbdAAEwEIgQRIAQAFaCKMmiYWaBVt0AATAQiBBEgBAAVoIYyaJhZoFW3QABMBCIEE SAEABWiDc5qmFmjAPa8AKwAIgRVoAgigABZoJFTuABdowD2vAGNIAQBkaAAAAABkaAAAAABkaINz mqYZAQiBBEgBAAVo6XOaphVoAgigABZowRtvABMBCIEESAEABWjpc5qmFmjBG28AKwAIgRVoAgig ABZoJFTuABdowRtvAGNIAQBkaAAAAABkaAAAAABkaOlzmqYMFWgCCKAAFmgkVO4AACsACIEVaAII oAAWaCRU7gAXaHV9AABjSAEAZGgAAAAAZGgAAAAAZGjFipomKwAIgRVoAgigABZoJFTuABdoiySx AGNIAQBkaAAAAABkaAAAAABkaDeLmiYAGrBFAAAjRgAAZEYAAKMAAAAAAAAAAAAAAABHAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAWw8A QyQBRcaAAAABACOMmiYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAABnZBVt0ABvxgcBAQAjjJomZCYBDcYIAALQAuwEwIAPhOwEEYQU +16E7ARghBT7AFsPAEMkAUXGgAAAAQAijJomAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAZ2QVbdAAb8YHAQEAI4yaJmQmAQ3GCAAC 0ALsBMCAD4TsBBGEFPtehOwEYIQU+wACZEYAAGVGAABJRwAAowAAAAAAAAAAAAAAAEcAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABbDwBD JAFFxoAAAAEAJYyaJgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAGdkBSbKAG/GBwEBACmMmiZkJgENxggAAtAC7ATAgA+E7AQRhBT7 XoTsBGCEFPsAWw8AQyQBRcaAAAABACWMmiYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABnZBVt0ABvxgcBAQAjjJomZCYBDcYIAALQ AuwEwIAPhOwEEYQU+16E7ARghBT7AAJ6RgAAlUYAAEFHAABCRwAAR0cAAEhHAABJRwAAq0cAAKxH AABZSQAAKUsAACpLAAA9SwAAiUsAAJBLAACVSwAAtUsAADNMAAA6TAAAQUwAAIpMAACTTAAAokwA AKdMAAC1TAAAukwAAL5MAADJTAAA0kwAAPXr4evh18GrwaSakIZ8hnxyaHJeVF5KXkpeSlQAAAAA EwEIgQRIAQAFaKWrmqYWaPRw8AATAQiBBEgBAAVopquaphZo9HDwABMBCIEESAEABWikq5qmFmj0 cPAAEwEIgQRIAQAFaKOSmkYWaMRXOgATAQiBBEgBAAVoL4yaJhZoBSbKABMBCIEESAEABWgujJom FmgFJsoAEwEIgQRIAQAFaC2MmiYWaAUmygATAQiBBEgBAAVoLIyaJhZoBSbKABMBCIEESAEABWgs jJomFmgkVO4ADBVoAgigABZoJFTuAAArAAiBFWgCCKAAFmgkVO4AF2goDXgAY0gBAGRoAAAAAGRo AAAAAGRoCIyaJisACIEVaAIIoAAWaCRU7gAXaAUmygBjSAEAZGgAAAAAZGgAAAAAZGgrjJomEwEI gQRIAQAFaCqMmiYWaBVt0AATAQiBBEgBAAVoKoyaJhZoBSbKABMBCIEESAEABWgpjJomFmgFJsoA EwEIgQRIAQAFaCWMmiYWaAUmygAAHElHAACLRwAA0UcAABlIAAA3SAAAOEgAAIBIAACvSAAAsEgA APVIAAA+SQAAWUkAAFpJAACcSQAA5EkAABBKAAARSgAATkoAAJdKAADPSgAA0EoAALcAAAAAAAAA AAAAAACyAAAAAAAAAAAAAAAArQAAAAAAAAAAAAAAAK0AAAAAAAAAAAAAAACtAAAAAAAAAAAAAAAA rQAAAAAAAAAAAAAAAK0AAAAAAAAAAAAAAACtAAAAAAAAAAAAAAAArQAAAAAAAAAAAAAAAK0AAAAA AAAAAAAAAACtAAAAAAAAAAAAAAAArQAAAAAAAAAAAAAAAK0AAAAAAAAAAAAAAACtAAAAAAAAAAAA AAAArQAAAAAAAAAAAAAAAK0AAAAAAAAAAAAAAACtAAAAAAAAAAAAAAAArQAAAAAAAAAAAAAAAK0A AAAAAAAAAAAAAACtAAAAAAAAAAAAAAAAAAAABA8AZ2QCCKAAAAQPAGdkKA14AABHDwBDJAFFxoAA AAEAIoyaJgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAGdkAgigAAAU0EoAABBLAAApSwAAKksAAA9NAAARTQAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAACyAAAAAAAAAAAAAAAAmQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAWw8AQyQBRcaAAAABADCMmiYAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABnZAUm ygBvxgcBAQAujJomZCYBDcYIAALQAuwEQEAPhOwEEYQU+16E7ARghBT7ABgPAGdk9HDwAG/GBwEB AKermqZkJgENxggAAtAC7ARAQA+E7AQRhBT7XoTsBGCEFPsARw8AQyQBRcaAAAABACyMmiYAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AABnZAIIoAAABA8AZ2QCCKAAAAXSTAAA00wAANRMAAD6TAAADE0AAA1NAAAPTQAAak0AAH5NAAB/ TQAAgE0AAIFNAACHTQAAHk8AAABRAAABUQAAAlEAAANRAAAJUQAAClEAAAtRAAAjUQAAJFEAACtR AABpUQAAalEAAHFRAACvUQAAtlEAAMRRAADTUQAA1VEAAPXr9ev14dfNw7myq5Wri3Wri19Vq1Vf q1Vfq1+rX6sAAAAAAAAAAAAAABMBCIEESAEABWg2jJomFmgjNwEAKwAIgRVoAgigABZoJFTuABdo IzcBAGNIAQBkaAAAAABkaAAAAABkaDaMmiYrAAiBFWgCCKAAFmgkVO4AF2gjNwEAY0gBAGRoAAAA AGRoAAAAAGRoNYyaJhMBCIEESAEABWg1jJomFmgjNwEAKwAIgRVoAgigABZoJFTuABdoIzcBAGNI AQBkaAAAAABkaAAAAABkaDKMmiYMFWgCCKAAFmgkVO4AAAwVaAIIoAAWaCM3AQAAEwEIgQRIAQAF aDGMmiYWaAUmygATAQiBBEgBAAVoMYyaJhZoIzcBABMBCIEESAEABWgyjJomFmgjNwEAEwEIgQRI AQAFaDCMmiYWaAUmygATAQiBBEgBAAVoL4yaJhZoBSbKABMBCIEESAEABWinq5qmFmj0cPAAEwEI gQRIAQAFaKWrmqYWaPRw8AAAHxFNAACATQAAgU0AAMlNAAAPTgAAVU4AAHFOAAByTgAAowAAAAAA AAAAAAAAAEcAAAAAAAAAAAAAAABCAAAAAAAAAAAAAAAAQgAAAAAAAAAAAAAAAEIAAAAAAAAAAAAA AABCAAAAAAAAAAAAAAAAQgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEDwBnZAIIoAAAWw8AQyQBRcaA AAABADGMmiYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAABnZAUmygBvxgcBAQAujJomZCYBDcYIAALQAuwEQEAPhOwEEYQU+16E7ARg hBT7AFsPAEMkAUXGgAAAAQAwjJomAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAZ2QjNwEAb8YHAQEAMoyaJmQmAQ3GCAAC0ALsBEBA D4TsBBGEFPtehOwEYIQU+wAHck4AALpOAAD/TgAAH08AACBPAAAhTwAAIk8AACNPAABsTwAAbk8A ALdPAAC4TwAAuU8AAABQAAAdUAAAHlAAAGVQAACnUAAA0lAAANRQAAAEUQAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAABA8AZ2QCCKAAABQEUQAABVEAACVRAABrUQAAsFEAANVRAADWUQAAtwAAAAAAAAAAAAAA AFsAAAAAAAAAAAAAAABBAAAAAAAAAAAAAAAAQQAAAAAAAAAAAAAAAEEAAAAAAAAAAAAAAAC3AAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGg8AQyQBZ2QjNwEAb8YHAQEANoyaJmQm AQ3GCAAC0ALsBEBAD4TsBBGEFPtehOwEYIQU+wBbDwBDJAFFxoAAAAEANYyaJgAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGdkIzcB AG/GBwEBADaMmiZkJgENxggAAtAC7ARAQA+E7AQRhBT7XoTsBGCEFPsARw8AQyQBRcaAAAABADWM miYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAABnZAIIoAAABtVRAADWUQAA11EAAN1RAADeUQAA31EAAOBRAADhUQAA41EAAPNRAAD0 UQAA9VEAAB5SAAAiUgAAKlIAACtSAAAwUgAAZ1IAAKVSAADdUgAA51IAAOhSAADqUgAA9e7n3cfn vaeahL3np3pwvXBmUDpQ5wAAKwAIgRVoAgigABZoJFTuABdowD2vAGNIAQBkaAAAAABkaAAAAABk aINzmqYrAAiBFWgCCKAAFmgkVO4AF2gjNwEAY0gBAGRoAAAAAGRoAAAAAGRoNIyaJhMBCIEESAEA BWg0jJomFmgjNwEAEwEIgQRIAQAFaDOMmiYWaCM3AQATAQiBBEgBAAVopJKaRhZoNhlHACsACIEV aAIIoAAWaCRU7gAXaCM3AQBjSAEAZGgAAAAAZGgAAAAAZGg2jJomGQEIgQRIAQAFaDaMmiYVaAII oAAWaCM3AQArAAiBFWgCCKAAFmgkVO4AF2gjNwEAY0gBAGRoAAAAAGRoAAAAAGRoN4yaJhMBCIEE SAEABWg3jJomFmgjNwEAKwAIgRVoAgigABZoJFTuABdoniG1AGNIAQBkaAAAAABkaAAAAABkaFmM miYTAQiBBEgBAAVoWYyaJhZoniG1AAwVaAIIoAAWaCRU7gAADBVoAgigABZoIzcBAAATAQiBBEgB AAVoNYyaJhZoJFTuAAAW1lEAANdRAACyUgAA6VIAAOpSAAAyUwAAYFMAAGFTAACpUwAA8FMAADVU AAB7VAAAsFQAALFUAADvVAAA8FQAAB9VAAAgVQAAaVUAAK1VAAD2VQAAPlYAAIZWAADKVgAA+gAA AAAAAAAAAAAAAOMAAAAAAAAAAAAAAADKAAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAAAAAAAAAAAAAAAGA8AZ2QjNwEAb8YHAQEAN4yaJmQmAQ3GCAAC0ALsBACAD4Ts BBGEFPtehOwEYIQU+xcPAGdkNhlHAG/GBwEBAKSSmkZkJgENxgUAAewEgA+E7AQRhBT7XoTsBGCE FPsABA8AZ2QCCKAAABfqUgAAVFMAAF5TAABgUwAArlQAAK9UAADtVAAA7lQAAFdVAABhVQAAZFUA ALpVAADEVQAAx1UAANZVAADXVQAAQVYAAEtWAABOVgAAqFYAALJWAAC1VgAA8lYAAPxWAAD/VgAA AVcAABJXAAAjVwAASlcAAFhXAACWVwAAoFcAAKNXAADYVwAA6dPpzLrMqMzTnszTnsyMzNOezNOe zNOezILMbGLM057MAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEwEIgQRIAQAFaFCMmiYWaH4q BwArAAiBFWgCCKAAFmgkVO4AF2h+KgcAY0gBAGRoAAAAAGRoAAAAAGRoUIyaJhMBCIEESAEABWhP jJomFmh+KgcAIgNqAAAAABZofioHADBKEAA8CIFPSgAAUUoAAFUIAV5KAAAAEwEIgQRIAQAFaINz mqYWaMA9rwAiA2oAAAAAFmgjNwEAMEoQADwIgU9KAABRSgAAVQgBXkoAAAAiA2oAAAAAFmhzXAwA MEoQADwIgU9KAABRSgAAVQgBXkoAAAAMFWgCCKAAFmgkVO4AACsACIEVaAIIoAAWaCRU7gAXaMA9 rwBjSAEAZGgAAAAAZGgAAAAAZGiDc5qmKwAIgRVoAgigABZoJFTuABdoIzcBAGNIAQBkaAAAAABk aAAAAABkaDiMmiYAIcpWAADLVgAAJVcAAHZXAAC8VwAACVgAAEdYAABIWAAAbFgAAG1YAADVWAAA LlkAAHdZAACJWQAAilkAAItZAACMWQAAjVkAANZZAADYWQAAIVoAACJaAAAjWgAAaVoAAK5aAAD2 WgAAK1sAACxbAAD6AAAAAAAAAAAAAAAA7wAAAAAAAAAAAAAAAOoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA6gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAADqAAAAAAAAAAAAAAAA6gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAAAAAAAAAAEDwBnZH4qBwALDwBnZH4qBwBvxgcBAQBRjJomZCYB AAQPAGdkAgigAAAb2FcAAOFXAADpVwAAd1gAAH9YAACBWAAAhlgAAIdYAACMWAAAjVgAAKFYAACr WAAArlgAALBYAADBWAAA5VgAAPBYAADyWAAA+VgAAPpYAAAaWQAAIFkAAE1bAABXWwAAWlsAAMBb AADVWwAA6d/YwrWroZeN2Hdt2GPYwpdjtU1j2Hdt2EMTAQiBBEgBAAVoU4yaJhZoykpfACsACIEV aAIIoAAWaCRU7gAXaH4qBwBjSAEAZGgAAAAAZGgAAAAAZGhSjJomEwEIgQRIAQAFaFKMmiYWaH4q BwATAQiBBEgBAAVog3OaphZowD2vACsACIEVaAIIoAAWaCRU7gAXaMA9rwBjSAEAZGgAAAAAZGgA AAAAZGiDc5qmEwEIgQRIAQAFaFWMmiYWaMpKXwATAQiBBEgBAAVoS4yaJhZofioHABMBCIEESAEA BWhXjJomFmjKSl8AEwEIgQRIAQAFaEuMmiYWaMpKXwAZAQiBBEgBAAVoS4yaJhVoAgigABZofioH ACsACIEVaAIIoAAWaCRU7gAXaH4qBwBjSAEAZGgAAAAAZGgAAAAAZGhLjJomDBVoAgigABZoJFTu AAATAQiBBEgBAAVoUYyaJhZofioHACsACIEVaAIIoAAWaCRU7gAXaH4qBwBjSAEAZGgAAAAAZGgA AAAAZGhRjJomABosWwAAd1sAALpbAAAgXAAAQ1wAAERcAACJXAAAz1wAABRdAABgXQAAsl0AAPRd AAA2XgAAfl4AAMZeAAAJXwAAGF8AABlfAACBXwAA2F8AAP9fAAAAYAAARmAAAH9gAACAYAAAzGAA ABBhAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPUAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAOIAAAAA AAAAAAAAAADiAAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPUA AAAAAAAAAAAAAAD1AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA9QAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA AAAAAAAAABMPAGdkykpfAG/GBwEBAFSMmiZkJgEPhNACEYQw/V6E0AJghDD9AAQPAGdkykpfAAAE DwBnZAIIoAAAGtVbAADmWwAAAFwAAA5cAAAPXQAAH10AACJdAABWXQAAcl0AAHtdAADzXgAA9F4A ACVfAAAtXwAAL18AADRfAAA1XwAAO18AAEdfAABRXwAA+ePZ+cO5+aOZ+Yf5cWRaUFr5OgAAAAAA AAAAAAAAAAAAAAAAKwAIgRVoAgigABZoJFTuABdowD2vAGNIAQBkaAAAAABkaAAAAABkaINzmqYT AQiBBEgBAAVoVoyaJhZoykpfABMBCIEESAEABWhVjJomFmjKSl8AGQEIgQRIAQAFaFWMmiYVaAII oAAWaMpKXwArAAiBFWgCCKAAFmgkVO4AF2jKSl8AY0gBAGRoAAAAAGRoAAAAAGRoVYyaJiIDagAA AAAWaMpKXwAwShAAPAiBT0oAAFFKAABVCAFeSgAAABMBCIEESAEABWhUjJomFmjKSl8AKwAIgRVo AgigABZoJFTuABdoykpfAGNIAQBkaAAAAABkaAAAAABkaFSMmiYTAQiBBEgBAAVomHOaphZogwdv ACsACIEVaAIIoAAWaCRU7gAXaIMHbwBjSAEAZGgAAAAAZGgAAAAAZGiYc5qmEwEIgQRIAQAFaFOM miYWaMpKXwArAAiBFWgCCKAAFmgkVO4AF2jKSl8AY0gBAGRoAAAAAGRoAAAAAGRoU4yaJgwVaAII oAAWaCRU7gATUV8AAFRfAABWXwAAZ18AAItfAACWXwAAmF8AAJ9fAACgXwAAwF8AAMZfAABgYAAA aGAAAGpgAAB2YAAAnGAAAKZgAACpYAAAG2EAACVhAAAoYQAA/WEAAAdiAAAKYgAAQ2IAAE1iAABQ YgAAFWMAABZjAAC/fAAAwHwAAMF8AABffQAAYH0AAAt/AAAMfwAA9e7k7s7B5MHO5O6rnpTufvXu fvXufvXufvXubO5oXlpeWl4ABhZo9HDwAAATA2oAAAAAFmj0cPAAMEoQAFUIAQYWaAIIoAAAIgNq AAAAABZohTfEADBKEAA8CIFPSgAAUUoAAFUIAV5KAAAAKwAIgRVoAgigABZoJFTuABdowD2vAGNI AQBkaAAAAABkaAAAAABkaINzmqYTAQiBBEgBAAVoV4yaJhZoykpfABkBCIEESAEABWhXjJomFWgC CKAAFmjKSl8AKwAIgRVoAgigABZoJFTuABdoykpfAGNIAQBkaAAAAABkaAAAAABkaFeMmiYZAQiB BEgBAAVoVoyaJhVoAgigABZoykpfACsACIEVaAIIoAAWaCRU7gAXaMpKXwBjSAEAZGgAAAAAZGgA AAAAZGhWjJomEwEIgQRIAQAFaFaMmiYWaMpKXwAMFWgCCKAAFmgkVO4AABMBCIEESAEABWiDc5qm FmjAPa8AACMQYQAAW2EAAJ9hAADoYQAAMWIAAHtiAADEYgAACGMAABdjAAAYYwAAYGMAAKZjAADX YwAA2GMAANljAADaYwAA22MAANxjAADdYwAA3mMAAN9jAAAoZAAAKmQAAHNkAAB0ZAAAdWQAALZk AADEZAAAxWQAAAxlAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAAAAAAAEDwBn ZAIIoAAAHQxlAABUZQAAVWUAAIFlAACCZQAAyGUAANZlAADXZQAAHGYAACxmAAAtZgAAbmYAAG9m AAC0ZgAA/GYAAERnAACLZwAAzmcAABdoAABgaAAAj2gAAJBoAADLaAAAzGgAABNpAABRaQAAimkA AItpAACaaQAAm2kAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAAAAAAAAQPAGdk AgigAAAdm2kAAN9pAAAYagAAX2oAAHVqAAB2agAAvmoAAPlqAAAoawAAKWsAAG1rAACtawAA7WsA AO5rAAA3bAAAdWwAAHZsAAB3bAAAeGwAAMFsAADDbAAADG0AAA1tAAAObQAAV20AAJFtAACSbQAA 1W0AAAFuAAACbgAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAAAAAAABA8AZ2QC CKAAAB0CbgAAQW4AAIFuAACWbgAAl24AANxuAAAkbwAAbG8AALJvAADybwAA828AADlwAAB5cAAA enAAAHtwAAB8cAAAfXAAAH5wAAB/cAAAgHAAAIFwAACCcAAAg3AAAIRwAACFcAAAhnAAAIdwAACI cAAAiXAAAIpwAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAAAAAAAEDwBnZAII oAAAHYpwAACLcAAAjHAAAI1wAACOcAAAj3AAAJBwAACRcAAAknAAAJNwAACUcAAAlXAAAJZwAACX cAAAmHAAAJlwAACacAAA43AAAOVwAAAucQAAL3EAADBxAABOcQAAT3EAAJhxAAC8cQAAvXEAAL5x AAC/cQAAwHEAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAAAAAAAAQPAGdkAgig AAAdwHEAAMFxAADCcQAAw3EAAMRxAADFcQAAxnEAAMdxAADIcQAAyXEAAMpxAADLcQAAzHEAAM1x AADOcQAAz3EAANBxAADRcQAA0nEAANNxAADUcQAA1XEAANZxAADXcQAA2HEAANlxAADacQAA23EA ANxxAADdcQAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAAAAAAABA8AZ2QCCKAA AB3dcQAA3nEAAN9xAADgcQAA4XEAAOJxAADjcQAA5HEAAOVxAADmcQAA53EAAOhxAADpcQAA6nEA AOtxAAA0cgAANnIAAH9yAACAcgAAgXIAAJRyAACVcgAAp3IAALxyAAC9cgAA13IAAP1yAAD+cgAA /3IAABFzAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAAAAAAAEDwBnZAIIoAAA HRFzAAAccwAAHXMAAEJzAABDcwAARHMAAFZzAABhcwAAYnMAAHxzAACdcwAAnnMAAJ9zAACgcwAA oXMAAKJzAACjcwAApHMAAKVzAACmcwAAp3MAAKhzAACpcwAAqnMAAKtzAACscwAArXMAAK5zAACv cwAAsHMAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAAAAAAAAQPAGdkAgigAAAd sHMAALFzAACycwAAs3MAALRzAAC1cwAAtnMAALdzAAC4cwAAuXMAALpzAAC7cwAAvHMAAAV0AAAH dAAAUHQAAFF0AABSdAAAcnQAAHN0AAC4dAAAAXUAAEh1AACOdQAA1HUAAB12AABhdgAAgHYAAIF2 AADDdgAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAAAAAAABA8AZ2QCCKAAAB3D dgAAB3cAAFB3AACMdwAA1XcAAPF3AADydwAAOXgAAH14AADDeAAABXkAABt5AAAceQAAHXkAADR5 AAA1eQAAfnkAAMd5AAANegAAVHoAAJV6AADXegAAHXsAAB57AAAfewAAM3sAADR7AAB8ewAAwXsA AAZ8AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAAAAAAAEDwBnZAIIoAAAHQZ8 AAAHfAAACHwAABd8AAAYfAAAXHwAAHF8AAByfAAAc3wAAHR8AAB1fAAAvnwAAMB8AABffQAAC38A AMl/AADXgAAA/YAAAF+BAADMgQAA5IEAAGztAABt7QAAbu0AAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAA AAAAAPMAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA7gAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD4 AAAAAAAAAAAAAAAA6QAAAAAAAAAAAAAAAOcAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAABAAAABBEAZ2SFN8QAAAQRAGdkfioHAAAEEQBnZMRXOgAAAREAAAQPAGdkAgigAAAXDH8A AMl/AADKfwAA14AAANiAAAD9gAAA/oAAAF+BAABggQAAzIEAAM2BAADkgQAA5YEAAADsAABs7QAA be0AAG7tAAD88vzy/PL88vzy/PLw/OzoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAGFmgCCKAAAAYWaDNsGAAAA1UIARMDagAAAAAWaPRw8AAwShAAVQgBBhZo9HDwABAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFRoZSB1 c2Ugb2YgYSCRY29tbW9uIHBvb2ySIG9mIG1lbWJlcnMgaXMgb3V0c2lkZSB0aGUgc2NvcGUgb2Yg TENBUy4gVGhlIGNvbXBsaWNhdGlvbiBoZXJlIChmb3IgZGV0ZXJtaW5pc3RpYyBwdXJwb3Nlcykg aXMgdGhhdCB0aGVzZSBjb21wb25lbnRzIGFyZSBub3QgbWVtYmVycyBvZiBhbnkgVkNHIGFuZCBi ZWZvcmUgdGhleSBjYW4gYmUgdXNlZCBieSBMQ0FTIHRoZSBtYW5hZ2VtZW50IHN5c3RlbSB3b3Vs ZCBuZWVkIHRvIGFsbG9jYXRlIHRoZW0gdG8gYSBwYXJ0aWN1bGFyIFZDRzsgdGhpcyB3aWxsIGFk ZCBvcGVyYXRpb24gdGltZSB0byB0aGUgb3ZlcmFsbCB0aW1lIHRvIHB1dCBpdCh0aGVtKSBpbnRv IGFjdGl2ZSBzZXJ2aWNlLg0NDQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJgAxkGgB OnACCKAAH7DQLyCw4D0hsCcFIrAnBSOQoAUkkKAFJbAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFAAUABIAAQCcAA8AAwAA AAMAAAAAAEQAAEDx/wIARAAMAAAAAAAAAAAABgBOAG8AcgBtAGEAbAAAAAIAAAAcAENKGABfSA0E YUoYAG1ICQRuSAQIc0gJBHRIBAgAAAAAAAAAAAAAAAAAAAAAAABEAEFA8v+hAEQADAEAAAAAAAAA ABYARABlAGYAYQB1AGwAdAAgAFAAYQByAGEAZwByAGEAcABoACAARgBvAG4AdAAAAAAAUgBpAPP/ swBSAAwBAAAAAAAAAAAMAFQAYQBiAGwAZQAgAE4AbwByAG0AYQBsAAAAHAAX9gMAADTWBgABCgNs ADTWBgABBQMAAGH2AwAAAgALAAAAKABrAPT/wQAoAAABAAAAAAAAAAAHAE4AbwAgAEwAaQBzAHQA AAACAAAAAAAAAEQAWkABAPIARAAMAAAAAgigAAAACgBQAGwAYQBpAG4AIABUAGUAeAB0AAAAAgAP ABQAQ0oUAE9KBABRSgQAXkoEAGFKFABCACdAogABAUIADAEAABV2PwAAABEAQwBvAG0AbQBlAG4A dAAgAFIAZQBmAGUAcgBlAG4AYwBlAAAACABDShAAYUoQADwAHkABABIBPAAMAQAAFXY/AAAADABD AG8AbQBtAGUAbgB0ACAAVABlAHgAdAAAAAIAEQAIAENKFABhShQAQABqABEBEgFAAAwBAAAVdj8A AAAPAEMAbwBtAG0AZQBuAHQAIABTAHUAYgBqAGUAYwB0AAAAAgASAAYANQiBXAiBSACZQAEAMgFI AAwBAAAVdj8AAAAMAEIAYQBsAGwAbwBvAG4AIABUAGUAeAB0AAAAAgATABQAQ0oQAE9KBQBRSgUA XkoFAGFKEAANAFQAcgBlAHYAbwByACAAVwBpAGwAcwBvAG4ABRgAAJUiAADfMQAAJTQAAD5LAAB9 SwAAZkwAAINVAAClWQAA43kAAAIAVABXAAAAAAAAAAAAAAAAAAAAAAAAAAAA/////wIAVABXAAAA AAAAAAAAAAAAAAAAAAAAAAAA/////wIAVABXAAAAAAAAAAAAAAAAAAAAAAAAAAAA/////wIAVABX AAAAAAAAAAAAAAAAAAAAAAAAAAAA/////wIAVABXAAAAAAAAAAAAAAAAAAAAAAAAAAAA/////wIA VABXAAAAAAAAAAAAAAAAAAAAAAAAAAAA/////wIAVABXAAAAAAAAAAAAAAAAAAAAAAAAAAAA//// /wIAVABXAAAAAAAAAAAAAAAAAAAAAAAAAAAAAlz+BgIAVABXAAAAAAAAAAAAAAAAAAAAAAAAAAAA //////pymqYAAAAAAAAAAAAAAAAAALKSmkYAAAAAAAAAAAAAAAAAAKGSmkYAAAAAAAAAAAAAAAAA AKCSmkYAAAAAAAAAAAAAAAAAALKSmkYAAAAAAAAAAAAAAAAAAEmMmiYAAAAAAAAAAAAAAAAAAE6M miYAAAAAAAAAAAAAAAAAAFWMmiYAAAAAAAAAAAAAAAAAAKKrmqYAAAAAAAAAAAAAAAAAAAAAAACf AAAASwIAAAkDAAAXBAAAPQQAAJ8EAAAMBQAAJAUAAJEGAACUBgAAAAAAAON5AAAMAADuAAAAAP// //8AAAAAAQAAAAIAAABLAAAAlAAAAN0AAAAmAQAAbwEAALgBAAABAgAAAgIAAAMCAABMAgAAlAIA AM0CAADOAgAA4gIAAOMCAAApAwAAbgMAALQDAAD4AwAA+QMAAD4EAACCBAAAxQQAANAEAADRBAAA GgUAAGIFAACkBQAA4wUAAOQFAAAeBgAATQYAAE4GAACSBgAAtgYAALcGAADtBgAA7gYAAP8GAAAA BwAALgcAAC8HAAA4BwAAOQcAAH4HAADHBwAADggAAFQIAABVCAAAVggAAFcIAACgCAAAoggAAOsI AADsCAAA7QgAADQJAAB8CQAAwAkAAPMJAAD0CQAA9QkAAAcKAAAICgAAUQoAAJoKAADjCgAALAsA AHULAAC+CwAABwwAAFAMAACZDAAA4gwAABwNAABlDQAArg0AAOsNAAA0DgAAfQ4AAMYOAAAPDwAA WA8AAKEPAACiDwAAow8AAKQPAAClDwAApg8AAKcPAACoDwAAqQ8AAKoPAACrDwAArA8AAK0PAACu DwAArw8AALAPAACxDwAAsg8AALMPAAC0DwAAtQ8AALYPAAC3DwAAuA8AAAEQAAADEAAATBAAAE0Q AABOEAAAbBAAAG0QAACvEAAA+BAAAEARAACHEQAAyREAABgSAABhEgAAqBIAANUSAADWEgAA+BIA APkSAABAEwAAhBMAAMgTAAAQFAAAIhQAACMUAABtFAAAuhQAAMIVAAAJFgAAHRYAAB4WAABiFgAA qhYAAPEWAAA8FwAAgRcAAMcXAAAHGAAACBgAAE8YAACXGAAA3hgAACAZAAAhGQAASRkAAEoZAACR GQAALBsAAHQbAADBGwAABBwAAEQcAABFHAAARhwAAEccAABIHAAAkRwAAJMcAADcHAAA3RwAAN4c AAD2HAAA9xwAAD0dAAB9HQAAwR0AAAkeAABUHgAAmh4AAOEeAAApHwAAKh8AAHEfAAC4HwAAACAA AEUgAABnIAAAaCAAALAgAAD8IAAARSEAABMiAABeIgAAlyIAAJgiAACZIgAAmiIAAJsiAACcIgAA nSIAAJ4iAACfIgAAoCIAAKEiAACiIgAAoyIAAKQiAAClIgAApiIAAKciAACoIgAAqSIAAKoiAACr IgAArCIAAK0iAACuIgAAryIAALAiAACxIgAAsiIAALMiAAD8IgAA/iIAAEcjAABIIwAASSMAAHMj AAB0IwAAuSMAAAAkAABHJAAAiSQAANIkAAAaJQAAXCUAAF0lAACEJQAAhSUAAM4lAAATJgAAPiYA AD8mAACHJgAAxyYAAA4nAABQJwAAlCcAAM8nAADQJwAAFygAAF0oAACkKAAAxSgAAMYoAAALKQAA TykAAJMpAADbKQAACyoAAAwqAAAvKgAAMCoAAHMqAAC0KgAAJCsAAGkrAACwKwAA+CsAAEEsAAB/ LAAADy0AABAtAAARLQAAEi0AABMtAAAULQAAFS0AAF4tAABgLQAAqS0AAKotAACrLQAA8i0AADou AACXLgAA5y4AACcvAABsLwAA3C8AAN0vAAAhMAAAbDAAALQwAAD/MAAAQjEAAIoxAADRMQAAFzIA AF0yAABuMgAAbzIAAJUyAACWMgAA2jIAACUzAABsMwAAjzMAAJAzAADUMwAAJzQAACg0AAB9NAAA wzQAAB01AAAuNQAALzUAAHU1AAC9NQAA+DUAAPk1AABBNgAAijYAAOo2AABINwAASTcAAJs3AADh NwAAGTgAABs4AAAcOAAAHTgAAB44AAAfOAAAaDgAAGo4AACzOAAAtDgAALU4AADYOAAA2TgAAB85 AACeOQAA5TkAAC46AAB6OgAAwzoAAOU6AADmOgAAOzsAAHM7AAB0OwAAvDsAAPE7AADyOwAAQDwA ALM8AAD0PAAA9TwAANk9AAAbPgAAYT4AAKk+AADHPgAAyD4AABA/AAA/PwAAQD8AAIU/AADOPwAA 6T8AAOo/AAAsQAAAdEAAAKBAAAChQAAA3kAAACdBAABfQQAAYEEAAKBBAAC5QQAAukEAAJ9DAACh QwAAEEQAABFEAABZRAAAn0QAAOVEAAABRQAAAkUAAEpFAACPRQAAr0UAALBFAACxRQAAskUAALNF AAD8RQAA/kUAAEdGAABIRgAASUYAAJBGAACtRgAArkYAAPVGAAA3RwAAYkcAAGRHAACURwAAlUcA ALVHAAD7RwAAQEgAAGVIAABmSAAAZ0gAAEJJAAB5SQAAekkAAMJJAADwSQAA8UkAADlKAACASgAA xUoAAAtLAABASwAAQUsAAH9LAACASwAAr0sAALBLAAD5SwAAPUwAAIZMAADOTAAAFk0AAFpNAABb TQAAtU0AAAZOAABMTgAAmU4AANdOAADYTgAA/E4AAP1OAABlTwAAvk8AAAdQAAAZUAAAGlAAABtQ AAAcUAAAHVAAAGZQAABoUAAAsVAAALJQAACzUAAA+VAAAD5RAACGUQAAu1EAALxRAAAHUgAASlIA ALBSAADTUgAA1FIAABlTAABfUwAApFMAAPBTAABCVAAAhFQAAMZUAAAOVQAAVlUAAJlVAACoVQAA qVUAABFWAABoVgAAj1YAAJBWAADWVgAAD1cAABBXAABcVwAAoFcAAOtXAAAvWAAAeFgAAMFYAAAL WQAAVFkAAJhZAACnWQAAqFkAAPBZAAA2WgAAZ1oAAGhaAABpWgAAaloAAGtaAABsWgAAbVoAAG5a AABvWgAAuFoAALpaAAADWwAABFsAAAVbAABGWwAAVFsAAFVbAACcWwAA5FsAAOVbAAARXAAAElwA AFhcAABmXAAAZ1wAAKxcAAC8XAAAvVwAAP5cAAD/XAAARF0AAIxdAADUXQAAG14AAF5eAACnXgAA 8F4AAB9fAAAgXwAAW18AAFxfAACjXwAA4V8AABpgAAAbYAAAKmAAACtgAABvYAAAqGAAAO9gAAAF YQAABmEAAE5hAACJYQAAuGEAALlhAAD9YQAAPWIAAH1iAAB+YgAAx2IAAAVjAAAGYwAAB2MAAAhj AABRYwAAU2MAAJxjAACdYwAAnmMAAOdjAAAhZAAAImQAAGVkAACRZAAAkmQAANFkAAARZQAAJmUA ACdlAABsZQAAtGUAAPxlAABCZgAAgmYAAINmAADJZgAACWcAAApnAAALZwAADGcAAA1nAAAOZwAA D2cAABBnAAARZwAAEmcAABNnAAAUZwAAFWcAABZnAAAXZwAAGGcAABlnAAAaZwAAG2cAABxnAAAd ZwAAHmcAAB9nAAAgZwAAIWcAACJnAAAjZwAAJGcAACVnAAAmZwAAJ2cAAChnAAApZwAAKmcAAHNn AAB1ZwAAvmcAAL9nAADAZwAA3mcAAN9nAAAoaAAATGgAAE1oAABOaAAAT2gAAFBoAABRaAAAUmgA AFNoAABUaAAAVWgAAFZoAABXaAAAWGgAAFloAABaaAAAW2gAAFxoAABdaAAAXmgAAF9oAABgaAAA YWgAAGJoAABjaAAAZGgAAGVoAABmaAAAZ2gAAGhoAABpaAAAamgAAGtoAABsaAAAbWgAAG5oAABv aAAAcGgAAHFoAAByaAAAc2gAAHRoAAB1aAAAdmgAAHdoAAB4aAAAeWgAAHpoAAB7aAAAxGgAAMZo AAAPaQAAEGkAABFpAAAkaQAAJWkAADdpAABMaQAATWkAAGdpAACNaQAAjmkAAI9pAAChaQAArGkA AK1pAADSaQAA02kAANRpAADmaQAA8WkAAPJpAAAMagAALWoAAC5qAAAvagAAMGoAADFqAAAyagAA M2oAADRqAAA1agAANmoAADdqAAA4agAAOWoAADpqAAA7agAAPGoAAD1qAAA+agAAP2oAAEBqAABB agAAQmoAAENqAABEagAARWoAAEZqAABHagAASGoAAElqAABKagAAS2oAAExqAACVagAAl2oAAOBq AADhagAA4moAAAJrAAADawAASGsAAJFrAADYawAAHmwAAGRsAACtbAAA8WwAABBtAAARbQAAU20A AJdtAADgbQAAHG4AAGVuAACBbgAAgm4AAMluAAANbwAAU28AAJVvAACrbwAArG8AAK1vAADEbwAA xW8AAA5wAABXcAAAnXAAAORwAAAlcQAAZ3EAAK1xAACucQAAr3EAAMNxAADEcQAADHIAAFFyAACW cgAAl3IAAJhyAACncgAAqHIAAOxyAAABcwAAAnMAAANzAAAEcwAABXMAAE5zAABQcwAA73MAAJt1 AABZdgAAZ3cAAI13AADvdwAAXHgAAHR4AADheQAA5HkAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAA AAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAA AAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAA AJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACY AAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAA AA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAP MAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAA AAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAA AAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAA AACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAA gAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAA AACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAA gAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAA AAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAA AAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAA AAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAA AAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAA AJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACY AAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAA AA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAP MAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAA AAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAA AAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAA AACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAA gAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAA AACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAA gAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAA AAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAA AAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAHgAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAB4 AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAeAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAHgA AAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAB4AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAeAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAHgAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAB4AAAA AAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAeAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAA AJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACY AAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAA AA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAP MAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAA AAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAA AAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAA AACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAA gAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAA AACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAACACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAgAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAA gAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAA AAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAA AAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAA AAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAA AAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAA AJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACY AAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAA AA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAP MAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAA AAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAA AAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAA AACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAA gAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAA AACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAA gAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAA AAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAA AAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAA AAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAA AAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAA AJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACY AAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAA AA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAP MAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAA AAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAA AAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAA AACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAA gAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAA AACAAAAAAAAAAAAIAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAA gAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAA AAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAA AAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAA AAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAA AAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAIAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAA AJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACY AAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAA AA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAP MAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAA AAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAA AAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAA AACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAACACYAAAADzAAAAAAAAAA gAAAAIAAAAAAAAAAAAgAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAA AACAAAAAAAAAAAAIAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAA gAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAA AAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAA AAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAIAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAA AAAACACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAgAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAIAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAA AAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAA AJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAEACY AAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAABAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAQAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAEACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAABAAmAAA AA8wAAAAAAAAAIAAAACAAAAAAAAAAAAIAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAACACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAgAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAIAJgAAAAP MAAAAAAAAACAAAAAgAAAAAAAAAAACACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAgAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAIAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAACACYAAAADzAA AAAAAAAAgAAAAIAAAAAAAAAAAAgAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAIAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAACACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAA AAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAA AACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAA gAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAEACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAABAAmAAAAA8wAAAAAAAAAIAA AACAAAAAAAAAAAAQAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAEACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAIAJgAAAAPMAAAAAAAAACAAAAA gAAAAAAAAAAACAGYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAgBmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAIAZgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAACAGYAAAADzAAAAAAAAAAgAAAAIAA AAAAAAAAAAgBmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAIAZgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAAGYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAA AAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAA AAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAA AAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAA AJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAQAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAEACY AAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAgAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAIAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAACACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAA AA8wAAAAAAAAAIAAAACAAAAAAAAAAAAQAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAgAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAP MAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAgAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAIAZgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAA AAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAA AAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAA AACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAA gAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAA AACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAACACYQAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAABmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAA gAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAA AAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAA AAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAA AAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAA AAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAA AJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACY AAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAA AA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAACACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAgAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAP MAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAA AAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAA AAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAA AACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAA gAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAA AACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAA gAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAA AAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAA AAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAA AAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAA AAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAA AJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACY AAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAA AA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAP MAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAA AAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAA AAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAA AACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAA gAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAA AACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAA gAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAA AAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAA AAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAA AAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAA AAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAA AJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACY AAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAA AA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAP MAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAA AAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAA AAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAA AACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAA gAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAA AACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAA gAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAA AAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAA AAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAA AAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAA AAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAA AJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACY AAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAA AA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAP MAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAA AAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAA AAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAA AACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAA gAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAA AACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAA gAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAA AAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAA AAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAA AAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAA AAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAA AJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACY AAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAA AA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAP MAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAA AAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAA AAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAA AACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAA gAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAA AACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAA gAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAA AAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAA AAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAA AAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAA AAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAA AJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACY AAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAA AA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAP MAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAA AAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAA AAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAA AACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAA gAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAA AACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAA gAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAA AAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAA AAAAAAAAAJpAAAARMAAAAAAAAACAAAAAgAAAAAAAAAAAAASYQAAAETAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmEAAABEwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJhAAAARMAAAAAAAAACAAAAAgAAAAAAA AAAAAACYQAAAETAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmEAAABEwAAAAAAAAAIAAAACAAAAAAAAA AAAAAJhAAAARMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYQAAAETAAAAAAAAAAgAAAAIAAAAAAAAAA AAAAmEAAABEwAAAAAAAAAIAAAACAAAAAAAAAAAAABAoAAAAAMAAAAAAAAAAAAAAAAAAAyEjfDAoA AAcAAAAAAQAAAAIAAABLAAAAlAAAAN0AAAAmAQAAbwEAALgBAAABAgAAAgIAAAMCAABMAgAAlAIA AM0CAADOAgAA4gIAAOMCAAApAwAAbgMAALQDAAD4AwAA+QMAAD4EAACCBAAAxQQAANAEAADRBAAA GgUAAGIFAACkBQAA4wUAAOQFAAAeBgAATQYAAE4GAACSBgAAtgYAALcGAADtBgAA7gYAAP8GAAAA BwAALgcAAC8HAAA4BwAAOQcAAH4HAADHBwAADggAAFQIAABVCAAAVggAAFcIAACgCAAAoggAAOsI AADsCAAA7QgAADQJAAB8CQAAwAkAAPMJAAD0CQAA9QkAAAcKAAAICgAAUQoAAJoKAADjCgAALAsA AHULAAC+CwAABwwAAFAMAACZDAAA4gwAABwNAABlDQAArg0AAOsNAAA0DgAAfQ4AAMYOAAAPDwAA WA8AAKEPAACiDwAAow8AAKQPAAClDwAApg8AAKcPAACoDwAAqQ8AAKoPAACrDwAArA8AAK0PAACu DwAArw8AALAPAACxDwAAsg8AALMPAAC0DwAAtQ8AALYPAAC3DwAAuA8AAAEQAAADEAAATBAAAE0Q AABOEAAAbBAAAG0QAACvEAAA+BAAAEARAACHEQAAyREAABgSAABhEgAAqBIAANUSAADWEgAA+BIA APkSAABAEwAAhBMAAMgTAAAQFAAAIhQAACMUAABtFAAAuhQAAMIVAAAJFgAAHRYAAB4WAABiFgAA qhYAAPEWAAA8FwAAgRcAAMcXAAAHGAAACBgAAE8YAACXGAAA3hgAACAZAAAhGQAASRkAAEoZAACR GQAALBsAAHQbAADBGwAABBwAAEQcAABFHAAARhwAAEccAABIHAAAkRwAAJMcAADcHAAA3RwAAN4c AAD2HAAA9xwAAD0dAAB9HQAAwR0AAAkeAABUHgAAmh4AAOEeAAApHwAAKh8AAHEfAAC4HwAAACAA AEUgAABnIAAAaCAAALAgAAD8IAAARSEAABMiAABeIgAAlyIAAJgiAACZIgAAmiIAAJsiAACcIgAA nSIAAJ4iAACfIgAAoCIAAKEiAACiIgAAoyIAAKQiAAClIgAApiIAAKciAACoIgAAqSIAAKoiAACr IgAArCIAAK0iAACuIgAAryIAALAiAACxIgAAsiIAALMiAAD8IgAA/iIAAEcjAABIIwAASSMAAHMj AAB0IwAAuSMAAAAkAABHJAAAiSQAANIkAAAaJQAAXCUAAF0lAACEJQAAhSUAAM4lAAATJgAAPiYA AD8mAACHJgAAxyYAAA4nAABQJwAAlCcAAM8nAADQJwAAFygAAF0oAACkKAAAxSgAAMYoAAALKQAA TykAAJMpAADbKQAACyoAAAwqAAAvKgAAMCoAAHMqAAC0KgAAJCsAAGkrAACwKwAA+CsAAEEsAAB/ LAAADy0AABAtAAARLQAAEi0AABMtAAAULQAAFS0AAF4tAABgLQAAqS0AAKotAACrLQAA8i0AADou AACXLgAA5y4AACcvAABsLwAA3C8AAN0vAAAhMAAAbDAAALQwAAD/MAAAQjEAAIoxAADRMQAAFzIA AF0yAABuMgAAbzIAAJUyAACWMgAA2jIAACUzAABsMwAAjzMAAJAzAADUMwAAJzQAACg0AAB9NAAA wzQAAB01AAAuNQAALzUAAHU1AAC9NQAA+DUAAPk1AABBNgAAijYAAOo2AABINwAASTcAAJs3AADh NwAAGTgAABs4AAAcOAAAHTgAAB44AAAfOAAAaDgAAGo4AACzOAAAtDgAALU4AADYOAAA2TgAAB85 AACeOQAA5TkAAC46AAB6OgAAwzoAAOU6AADmOgAAOzsAAHM7AAB0OwAAvDsAAPE7AADyOwAAQDwA ALM8AAD0PAAA9TwAANk9AAAbPgAAYT4AAKk+AADHPgAAyD4AABA/AAA/PwAAQD8AAIU/AADOPwAA 6T8AAOo/AAAsQAAAdEAAAKBAAAChQAAA3kAAACdBAABfQQAAYEEAAKBBAAC5QQAAukEAAJ9DAACh QwAAEEQAABFEAABZRAAAn0QAAOVEAAABRQAAAkUAAEpFAACPRQAAr0UAALBFAACxRQAAskUAALNF AAD8RQAA/kUAAEdGAABIRgAASUYAAJBGAACtRgAArkYAAPVGAAA3RwAAYkcAAGRHAACURwAAlUcA ALVHAAD7RwAAQEgAAGVIAABmSAAAZ0gAAEJJAAB5SQAAekkAAMJJAADwSQAA8UkAADlKAACASgAA xUoAAAtLAABASwAAQUsAAH9LAACASwAAr0sAALBLAAD5SwAAPUwAAIZMAADOTAAAFk0AAFpNAABb TQAAtU0AAAZOAABMTgAAmU4AANdOAADYTgAA/E4AAP1OAABlTwAAvk8AAAdQAAAZUAAAGlAAABtQ AAAcUAAAHVAAAGZQAABoUAAAsVAAALJQAACzUAAA+VAAAD5RAACGUQAAu1EAALxRAAAHUgAASlIA ALBSAADTUgAA1FIAABlTAABfUwAApFMAAPBTAABCVAAAhFQAAMZUAAAOVQAAVlUAAJlVAACoVQAA qVUAABFWAABoVgAAj1YAAJBWAADWVgAAD1cAABBXAABcVwAAoFcAAOtXAAAvWAAAeFgAAMFYAAAL WQAAVFkAAJhZAACnWQAAqFkAAPBZAAA2WgAAZ1oAAGhaAABpWgAAaloAAGtaAABsWgAAbVoAAG5a AABvWgAAuFoAALpaAAADWwAABFsAAAVbAABGWwAAVFsAAFVbAACcWwAA5FsAAOVbAAARXAAAElwA AFhcAABmXAAAZ1wAAKxcAAC8XAAAvVwAAP5cAAD/XAAARF0AAIxdAADUXQAAG14AAF5eAACnXgAA 8F4AAB9fAAAgXwAAW18AAFxfAACjXwAA4V8AABpgAAAbYAAAKmAAACtgAABvYAAAqGAAAO9gAAAF YQAABmEAAE5hAACJYQAAuGEAALlhAAD9YQAAPWIAAH1iAAB+YgAAx2IAAAVjAAAGYwAAB2MAAAhj AABRYwAAU2MAAJxjAACdYwAAnmMAAOdjAAAhZAAAImQAAGVkAACRZAAAkmQAANFkAAARZQAAJmUA ACdlAABsZQAAtGUAAPxlAABCZgAAgmYAAINmAADJZgAACWcAAApnAAALZwAADGcAAA1nAAAOZwAA D2cAABBnAAARZwAAEmcAABNnAAAUZwAAFWcAABZnAAAXZwAAGGcAABlnAAAaZwAAG2cAABxnAAAd ZwAAHmcAAB9nAAAgZwAAIWcAACJnAAAjZwAAJGcAACVnAAAmZwAAJ2cAAChnAAApZwAAKmcAAHNn AAB1ZwAAvmcAAL9nAADAZwAA3mcAAN9nAAAoaAAATGgAAE1oAABOaAAAT2gAAFBoAABRaAAAUmgA AFNoAABUaAAAVWgAAFZoAABXaAAAWGgAAFloAABaaAAAW2gAAFxoAABdaAAAXmgAAF9oAABgaAAA YWgAAGJoAABjaAAAZGgAAGVoAABmaAAAZ2gAAGhoAABpaAAAamgAAGtoAABsaAAAbWgAAG5oAABv aAAAcGgAAHFoAAByaAAAc2gAAHRoAAB1aAAAdmgAAHdoAAB4aAAAeWgAAHpoAAB7aAAAxGgAAMZo AAAPaQAAEGkAABFpAAAkaQAAJWkAADdpAABMaQAATWkAAGdpAACNaQAAjmkAAI9pAAChaQAArGkA AK1pAADSaQAA02kAANRpAADmaQAA8WkAAPJpAAAMagAALWoAAC5qAAAvagAAMGoAADFqAAAyagAA M2oAADRqAAA1agAANmoAADdqAAA4agAAOWoAADpqAAA7agAAPGoAAD1qAAA+agAAP2oAAEBqAABB agAAQmoAAENqAABEagAARWoAAEZqAABHagAASGoAAElqAABKagAAS2oAAExqAACVagAAl2oAAOBq AADhagAA4moAAAJrAAADawAASGsAAJFrAADYawAAHmwAAGRsAACtbAAA8WwAABBtAAARbQAAU20A AJdtAADgbQAAHG4AAGVuAACBbgAAgm4AAMluAAANbwAAU28AAJVvAACrbwAArG8AAK1vAADEbwAA xW8AAA5wAABXcAAAnXAAAORwAAAlcQAAZ3EAAK1xAACucQAAr3EAAMNxAADEcQAADHIAAFFyAACW cgAAl3IAAJhyAACncgAAqHIAAOxyAAABcwAAAnMAAANzAAAEcwAABXMAAE5zAABQcwAA73MAAJt1 AABZdgAAZ3cAAI13AADvdwAAXHgAAHR4AADheQAA5HkAADw7ATAAMAAAAAAAAAEAAAABAAAAAAAA AAAAgAE8OwEwADAAAAAAAAABAAAAAQAAAAAAAAAAAIABPDsBMAAwAAAAAAAAAQAAAAEAAAAAAAAA AACAATw7ATAAMAAAAAAAAAEAAAABAAAAAAAAAAAAgAE8OwEwADAAAAAAAAABAAAAAQAAAAAAAAAA AIABPDsBMAAwAAAAAAAAAQAAAAEAAAAAAAAAAACAATw7ATAAMAAAAAAAAAEAAAABAAAAAAAAAAAA gAE8OwEwADAAAAAAAAABAAAAAQAAAAAAAAAAAIABPDsBMAAwAAAAAAAAAQAAAAEAAAAAAAAAAACA ATw7ATAAMAAAAAAAAAEAAAABAAAAAAAAAAAAgAE8OwEwADAAAAAAAAABAAAAAQAAAAAAAAAAAIAB PDsBMAAwAAAAAAAAAQAAAAEAAAAAAAAAAACAATw7ATAAMAAAAAAAAAEAAAABAAAAAAAAAAAAgAE8 OwEwADAAAAAAAAABAAAAAQAAAAAAAAAAAIABPDsBMAAwAAAAAAAAAQAAAAEAAAAAAAAAAACAATw7 ATAAMAAAAAAAAAEAAAABAAAAAAAAAAAAgAE8OwEwADAAAAAAAAABAAAAAQAAAAAAAAAAAIABPDsB MAAwAAAAAAAAAQAAAAEAAAAAAAAAAACAATw7ATAAMAAAAAAAAAEAAAABAAAAAAAAAAAAgAE8OwEw ADAAAAAAAAABAAAAAQAAAAAAAAAAAIABPDsBMAAwAAAAAAAAAQAAAAEAAAAAAAAAAACAATw7ATAA MAAAAAAAAAEAAAABAAAAAAAAAAAAgAE8OwEwADAAAAAAAAABAAAAAQAAAAAAAAAAAIABPDsBMAAw AAAAAAAAAQAAAAEAAAAAAAAAAACAATw7ATAAMAAAAAAAAAEAAAABAAAAAAAAAAAAgAE8OwEwADAA AAAAAAABAAAAAQAAAAAAAAAAAIABPDsBMAAwAAAAAAAAAQAAAAEAAAAAAAAAAACAATw7ATAAMAAA AAAAAAEAAAABAAAAAAAAAAAAgAE8OwEwADAAAAAAAAABAAAAAQAAAAAAAAAAAIABPDsBMAAwAAAA AAAAAQAAAAEAAAAAAAAAAACAATw7ATAAMAAAAAAAAAEAAAABAAAAAAAAAAAAgAE8OwEwADAAAAAA AAABAAAAAQAAAAAAAAAAAIABPDsBMAAwAAAAAAAAAQAAAAEAAAAAAAAAAACAATw7ATAAMAAAAAAA AAEAAAABAAAAAAAAAAAAgAE8OwEwADAAAAAAAAABAAAAAQAAAAAAAAAAAIABPDsBMAAwAAAAAAAA AQAAAAEAAAAAAAAAAACAATw7ATAAMAAAAAAAAAEAAAABAAAAAAAAAAAAgAE8OwEwADAAAAAAAAAB AAAAAQAAAAAAAAAAAIABPDsBMAAwAAAAAAAAAQAAAAEAAAAAAAAAAACAATw7ATAAMAAAAAAAAAEA AAABAAAAAAAAAAAAgAE8OwEwADAAAAAAAAABAAAAAQAAAAAAAAAAAIABPDsBMAAwAAAAAAAAAQAA AAEAAAAAAAAAAACAATw7ATAAMAAAAAAAAAEAAAABAAAAAAAAAAAAgAE8OwEwADAAAAAAAAABAAAA AQAAAAAAAAAAAIABPDsBMAAwAAAAAAAAAQAAAAEAAAAAAAAAAACAATw7ATAAMAAAAAAAAAEAAAAB AAAAAAAAAAAAgAE8OwEwADAAAAAAAAABAAAAAQAAAAAAAAAAAIABPDsBMAAwAAAAAAAAAQAAAAEA AAAAAAAAAACAATw7ATAAMAAAAAAAAAEAAAABAAAAAAAAAAAAgAE8OwEwADAAAAAAAAABAAAAAQAA AAAAAAAAAIABPDsBMAAwAAAAAAAAAQAAAAEAAAAAAAAAAACAATw7ATAAMAAAAAAAAAEAAAABAAAA AAAAAAAAgAE8OwEwADAAAAAAAAABAAAAAQAAAAAAAAAAAIABPDsBMAAwAAAAAAAAAQAAAAEAAAAA AAAAAACAATw7ATAAMAAAAAAAAAEAAAABAAAAAAAAAAAAgAE8OwEwADAAAAAAAAABAAAAAQAAAAAA AAAAAIABPDsBMAAwAAAAAAAAAQAAAAEAAAAAAAAAAACAATw7ATAAMAAAAAAAAAEAAAABAAAAAAAA AAAAgAE8OwEwADAAAAAAAAABAAAAAQAAAAAAAAAAAIABPDsBMAAwAAAAAAAAAQAAAAEAAAAAAAAA AACAATw7ATAAMAAAAAAAAAEAAAABAAAAAAAAAAAAgAE8OwEwADAAAAAAAAABAAAAAQAAAAAAAAAA AIABPDsBMAAwAAAAAAAAAQAAAAEAAAAAAAAAAACAATw7ATAAMAAAAAAAAAEAAAABAAAAAAAAAAAA gAE8OwEwADAAAAAAAAABAAAAAQAAAAAAAAAAAIABPDsBMAAwAAAAAAAAAQAAAAEAAAAAAAAAAACA ATw7ATAAMAAAAAAAAAEAAAABAAAAAAAAAAAAgAE8OwEwADAAAAAAAAABAAAAAQAAAAAAAAAAAIAB PDsBMAAwAAAAAAAAAQAAAAEAAAAAAAAAAACAATw7ATAAMAAAAAAAAAEAAAABAAAAAAAAAAAAgAE8 OwEwADAAAAAAAAABAAAAAQAAAAAAAAAAAIABPDsBMAAwAAAAAAAAAQAAAAEAAAAAAAAAAACAATw7 ATAAMAAAAAAAAAEAAAABAAAAAAAAAAAAgAE8OwEwADAAAAAAAAABAAAAAQAAAAAAAAAAAIABPDsB MAAwAAAAAAAAAQAAAAEAAAAAAAAAAACAATw7ATAAMAAAAAAAAAEAAAABAAAAAAAAAAAAgAE8OwEw ADAAAAAAAAABAAAAAQAAAAAAAAAAAIABPDsBMAAwAAAAAAAAAQAAAAEAAAAAAAAAAACAATw7ATAA MAAAAAAAAAEAAAABAAAAAAAAAAAAgAE8OwEwADAAAAAAAAABAAAAAQAAAAAAAAAAAIABPDsBMAAw AAAAAAAAAQAAAAEAAAAAAAAAAACAATw7ATAAMAAAAAAAAAEAAAABAAAAAAAAAAAAgAE8OwEwADAA AAAAAAABAAAAAQAAAAAAAAAAAIABPDsBMAAwAAAAAAAAAQAAAAEAAAAAAAAAAACAATw7ATAAMAAA AAAAAAEAAAABAAAAAAAAAAAAgAE8OwEwADAAAAAAAAABAAAAAQAAAAAAAAAAAIABPDsBMAAwAAAA AAAAAQAAAAEAAAAAAAAAAACAATw7ATAAMAAAAAAAAAEAAAABAAAAAAAAAAAAgAE8OwEwADAAAAAA AAABAAAAAQAAAAAAAAAAAIABPDsBMAAwAAAAAAAAAQAAAAEAAAAAAAAAAACAATw7ATAAMAAAAAAA AAEAAAABAAAAAAAAAAAAgAE8OwEwADAAAAAAAAABAAAAAQAAAAAAAAAAAIABPDsBMAAwAAAAAAAA AQAAAAEAAAAAAAAAAACAATw7ATAAMAAAAAAAAAEAAAABAAAAAAAAAAAAgAE8OwEwADAAAAAAAAAB AAAAAQAAAAAAAAAAAIABPDsBMAAwAAAAAAAAAQAAAAEAAAAAAAAAAACAATw7ATAAMAAAAAAAAAEA AAABAAAAAAAAAAAAgAE8OwEwADAAAAAAAAABAAAAAQAAAAAAAAAAAIABPDsBMAAwAAAAAAAAAQAA AAEAAAAAAAAAAACAATw7ATAAMAAAAAAAAAEAAAABAAAAAAAAAAAAgAE8OwEwADAAAAAAAAABAAAA AQAAAAAAAAAAAIABPDsBMAAwAAAAAAAAAQAAAAEAAAAAAAAAAACAATw7ATAAMAAAAAAAAAEAAAAB AAAAAAAAAAAAgAE8OwEwADAAAAAAAAABAAAAAQAAAAAAAAAAAIABPDsBMAAwAAAAAAAAAQAAAAEA AAAAAAAAAACAATw7ATAAMAAAAAAAAAEAAAABAAAAAAAAAAAAgAE8OwEwADAAAAAAAAABAAAAAQAA AAAAAAAAAIABPDsBMAAwAAAAAAAAAQAAAAEAAAAAAAAAAACAATw7ATAAMAAAAAAAAAEAAAABAAAA AAAAAAAAgAE8OwEwADAAAAAAAAABAAAAAQAAAAAAAAAAAIABmAAAAA8wAAAAAAAAAIAAAACAAAAA AAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAA AAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAADAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAA AAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAA AJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACY AAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAMAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAwAAAAAAAAmAAA AA8wAAAAAAAAAIAAAACAAAAAMAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAADAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAwAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAMAAAAAAAAJgAAAAP MAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAgAAAAAIAAmAAAAA8w AAAAAAAAAIAAAACAAAAAIAAAAACAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAA AAAAAAAAgAAAAIAAAAAgAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAIAAAAACAAJgAAAAPMAAA AAAAAACAAAAAgAAAABgAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAgAAAAAIAAmAAAAA8wAAAA AAAAAIAAAACAAAAAMAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAACgAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAgAAAAAIAAmAAAAA8wAAAAAAAAAIAAAACAAAAAIAAAAAAAAJgAAAAPMAAAAAAA AACAAAAAgAAAACAAAAAAgACYAAAADzAAAAAAAAAAgAAAAIAAAAAgAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAMAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAACAAAAAAgACYAAAADzAAAAAAAAAA gAAAAIAAAAAQAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAIAAAAACAAJgAAAAPMAAAAAAAAACA AAAAgAAAABgAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAoAAAAAAAAmAAAAA8wAAAAAAAAAIAA AACAAAAAIAAAAACAAJgAAAAPMAAAAAAAAACAAAAAgAAAADAAAAAACAeYAAAADzAAAAAAAAAAgAAA AIAAAAAgAAAAAIgAmAAAAA8wAAAAAAAAAIAAAACAAAAAIAAAAACAAJgAAAAPMAAAAAAAAACAAAAA gAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAA AAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAA AAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAA AAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAA AAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAA AJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACY AAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAA AA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAP MAAAAAAAAACAAAAAgAAAAAAAAAAAAAeYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAA AAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAA AAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAA AACAAAAAgAAAADAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAwAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAMAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAADAAAAAAAACYAAAADzAAAAAAAAAA gAAAAIAAAAAgAAAAAIAAmAAAAA8wAAAAAAAAAIAAAACAAAAAMAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAACAAAAAAgACYAAAADzAAAAAAAAAAgAAAAIAAAAAwAAAAAAAAmAAAAA8wAAAAAAAAAIAA AACAAAAAIAAAAACAAJgAAAAPMAAAAAAAAACAAAAAgAAAADAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAgAAAAAIAAmAAAAA8wAAAAAAAAAIAAAACAAAAAMAAAAAAAAJgAAAAPMAAAAAAAAACAAAAA gAAAACAAAAAAgACYAAAADzAAAAAAAAAAgAAAAIAAAAAwAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAIAAAAACAAJgAAAAPMAAAAAAAAACAAAAAgAAAACgAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAA AABAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAIAAAAACAAJgAAAAPMAAAAAAAAACAAAAAgAAA ACAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAA AAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAA AAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAA AAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAA AJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACY AAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAA AA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAP MAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAA AAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAA AAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAADAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAA AACAAAAAgAAAADAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAMAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAACAAAAAAgAeYAAAADzAAAAAAAAAA gAAAAIAAAAAwAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAADAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAwAAAAAAAAmAAAAA8wAAAAAAAAAIAA AACAAAAAAAAAAAAIAJgAAAAPMAAAAAAAAACAAAAAgAAAADAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAYAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAQAAAAAAAAJgAAAAPMAAAAAAAAACAAAAA gAAAACAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAgAAAAAIAAmAAAAA8wAAAAAAAAAIAAAACA AAAAMAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAACAAAAAAgACYAAAADzAAAAAAAAAAgAAAAIAA AAAgAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAQAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAA AAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAABmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAA AAAAAAGYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAADAAAAAAAAeYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAA AAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAIAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAA AJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAAeY AAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAA AA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAP MAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAAeYAAAADzAA AAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAAGYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAHmAAAAA8wAAAA AAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAA AACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAMAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAACAGYAAAADzAAAAAAAAAA gAAAAIAAAAAwAAAAAAgHmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAPMAAAAAAAAACA AAAAgAAAADAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAA8wAAAAAAAAAIAA AACAAAAAMAAAAAAIB5gAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAAeYAAAADzAAAAAAAAAAgAAA AIAAAAAwAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAA gAAAADAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAMAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAA AAAgAAAAAIAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAA AAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAIB5gAAAAPMAAAAAAAAACAAAAAgAAAAAAA AAAACAGYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAgBmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAIAZgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAAeYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAA AAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AAeYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAA AJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAEAE8 OwEwYzEAAAAAAAABAAAAAQAAAAAAAAAAABABmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAQAZgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAEAE8OwEwZjEAAAAAAAABAAAAAQAAAAAAAAAAABABmAAA AA8wAAAAAAAAAIAAAACAAAAAAAAAAAAIB5gAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAACAeYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAgHmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAIB5gAAAAP MAAAAAAAAACAAAAAgAAAAAAAAAAACAeYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAgHmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAIB5gAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAACAeYAAAADzAA AAAAAAAAgAAAAIAAAAAAAAAAAAgHmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAIB5gAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAACAeYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAA AAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAA AACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAwAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAMAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAA gAAAAIAAAAAwAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAADAAAAAAEAE8OwEwfjEAAAAAAAABAAAAAQAAAAAAAAAAABAHmAAAAA8wAAAAAAAAAIAA AACAAAAAMAAAAAAQATw7ATCAMQAAAAAAAAEAAAABAAAAAAAAAAAAEAeYAAAADzAAAAAAAAAAgAAA AIAAAAAwAAAAAAABmAAAAA8wAAAAAAAAAIAAAACAAAAAGAAAAAAIB5gAAAAPMAAAAAAAAACAAAAA gAAAABgAAAAACAeYAAAADzAAAAAAAAAAgAAAAIAAAAAYAAAAAAgHmAAAAA8wAAAAAAAAAIAAAACA AAAAKAAAAAAIB5hAAAAPMAAAAAAAAACAAAAAgAAAACgAAAAACAeYAAAADzAAAAAAAAAAgAAAAIAA AAAoAAAAAAgHmAAAAA8wAAAAAAAAAIAAAACAAAAAKAAAAAAIB5gAAAAPMAAAAAAAAACAAAAAgAAA ACgAAAAAAAeYAAAADzAAAAAAAAAAgAAAAIAAAAAoAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAA KAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAACgAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAo AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAKAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAACAA AAAAgACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAA AAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAA AJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAQAZgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAEAGY AAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAgHmEAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAIAZhA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAACAGYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAA AA8wAAAAAAAAAIAAAACAAAAAAAAAAAAQAZgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAgHmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAP MAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAgHmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAIB5gAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAA AAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAA AAAAAIAAAACAAAAAAAAAAAAAB5gAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAHmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAA AACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAwAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAADAAAAAAAACYAAAADzAAAAAAAAAA gAAAAIAAAAAAAAAAAAAHmAAAAA8wAAAAAAAAAIAAAACAAAAAMAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAADAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAwAAAAAAAAmAAAAA8wAAAAAAAAAIAA AACAAAAAAAAAAAAAAJhAAAAPMAAAAAAAAACAAAAAgAAAADAAAAAACAGYQAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAABmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAPMAAAAAAAAACAAAAA gAAAAAAAAAAAAAGYAAAADzAAAAAAAAAAgAAAAIAAAAAgAAAAAIAAmAAAAA8wAAAAAAAAAIAAAACA AAAAGAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAADAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAA AAAgAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAMAAAAAAAB5gAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAAeYAAAADzAAAAAAAAAAgAAAAIAAAAAgAAAAAIAAmAAAAA8wAAAAAAAAAIAAAACAAAAA IAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAEAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAg AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAIAAAAACAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAA AAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAgAAAAAIAAmAAAAA8wAAAAAAAAAIAAAACAAAAAGAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAA AAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAA AJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACY AAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAHmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAA AA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAACAGYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAgBmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAB5gAAAAP MAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAA AAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAHmAAAAA8wAAAA AAAAAIAAAACAAAAAAAAAAAAAB5gAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAA AACAAAAAgAAAAAAAAAAAAAeYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAA gAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAMAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAADAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAA AACAAAAAMAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAwAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAB5gAAAAPMAAAAAAAAACAAAAA gAAAACAAAAAAgACYAAAADzAAAAAAAAAAgAAAAIAAAAAgAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAOAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAACgAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAA AAAgAAAAAIAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA ACAAAAAAgACYAAAADzAAAAAAAAAAgAAAAIAAAAAoAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAA QAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAACAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAg AAAAAIAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAACAA AAAAgACYAAAADzAAAAAAAAAAgAAAAIAAAAAgAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAA AAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAA AJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACY AAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAA AA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAP MAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAA AAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAA AAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAA AACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAA gAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAA AACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAMAAAAAAAAJgAAAAPMAAAAAAAAACAAAAA gAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAwAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAADAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAA AAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAIAAAAACAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAgAAAAAIAAmAAAAA8wAAAAAAAAAIAAAACAAAAA AAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAACAAAAAAgACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAIAAAAACAAJgAAAAPMAAAAAAAAACAAAAAgAAAACAA AAAAgACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAA AAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAA AJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACY AAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAA AA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAADAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAP MAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAA AAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAA AAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAA AACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAA gAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAMAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAADAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAwAAAAAAAAmAAAAA8wAAAAAAAAAIAA AACAAAAAMAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAACAAAAAAgACYAAAADzAAAAAAAAAAgAAA AIAAAAAYAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAIAAAAACAAJgAAAAPMAAAAAAAAACAAAAA gAAAADAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAgAAAAAIAAmAAAAA8wAAAAAAAAAIAAAACA AAAAGAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAADAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAA AAAgAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAIAAAAACAAJgAAAAPMAAAAAAAAACAAAAAgAAA ADAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAgAAAAAIAAmAAAAA8wAAAAAAAAAIAAAACAAAAA IAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAEAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAg AAAAAIAAmAAAAA8wAAAAAAAAAIAAAACAAAAAIAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAA AAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAA AAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAA AJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACY AAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAA AA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAP MAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAA AAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAA AAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAA AACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAA gAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAA AACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAADAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAMAAAAAAAAJgAAAAPMAAAAAAAAACAAAAA gAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAwAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAADAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAA AAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAMAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAwAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAA AAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAACAAAAAAgACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAA AAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAA AAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAA AJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACY AAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAA AA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAP MAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAA AAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAA AAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAA AACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAADAAAAAAAACYAAAADzAAAAAAAAAA gAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAMAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAwAAAAAAAAmAAAAA8wAAAAAAAAAIAA AACAAAAAIAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAACAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAgAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAIAAAAAAAAJgAAAAPMAAAAAAAAACAAAAA gAAAACAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAgAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAIAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAACAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAA AAAgAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAIAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA ACAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAgAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAA IAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAACAAAAAAgACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAA AAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAA AAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAA AJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACY AAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAA AA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAP MAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAA AAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAwAAAAAAAAmAAAAA8wAAAA AAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAADAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAMAAAAAAAAJgAAAAPMAAAAAAA AACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAwAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAADAAAAAAAACYAAAADzAAAAAAAAAA gAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAMAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAgAAAAAIAAmAAAAA8wAAAAAAAAAIAA AACAAAAAGAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAADAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAgAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAIAAAAACAAJgAAAAPMAAAAAAAAACAAAAA gAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAgAAAAAIAAmAAAAA8wAAAAAAAAAIAAAACA AAAAIAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAEAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAA AAAgAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAIAAAAACAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAgAAAAAIAACAAAAAAwAAAAAAAAAAAAAAAA4QDU AVMECgAAB5hAAAARMAAAAAAAAACAAAAAgAAAAAAAAAAAAAeYQAAAADAAAAAAAAAAgAAAAIAAAAAA AAAAAIABmEAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAACAAZhAAAAAMAAAAAAAAACAAAAAgAAAAAAA AAAAgAGYQAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAIAHmEAAAAAwAAAAAAAAAIAAAACAAAAAAAAA AACAAZhAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAgAGYQAAAADAAAAAAAAAAgAAAAIAAAAAAAAAA AIABmEAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAACABwgAAAAAMAAAAAAAAAAAAAAAAOEAjErfDAoA AAcABgAABSAAAKglAADyMgAA0DQAAIo3AAAlPAAAN0EAAMJDAAB6RgAA0kwAANVRAADqUgAA2FcA ANVbAABRXwAADH8AAG7tAABBAAAASQAAAEsAAABPAAAAUAAAAFIAAABUAAAAVgAAAFcAAABaAAAA XQAAAGEAAABjAAAAZQAAAGcAAABoAAAAdAAAAAAGAABiDQAA7RAAAKIXAABtGAAAYh4AAJMkAACZ KgAARysAAMUwAACpNQAAkDsAALNAAACwRQAAZEYAAElHAADQSgAAEU0AAHJOAAAEUQAA1lEAAMpW AAAsWwAAEGEAAAxlAACbaQAAAm4AAIpwAADAcQAA3XEAABFzAACwcwAAw3YAAAZ8AABu7QAAQgAA AEQAAABFAAAARgAAAEcAAABIAAAASgAAAEwAAABNAAAATgAAAFEAAABTAAAAVQAAAFgAAABZAAAA WwAAAFwAAABeAAAAXwAAAGAAAABiAAAAZAAAAGYAAABpAAAAagAAAGsAAABsAAAAbQAAAG4AAABv AAAAcAAAAHEAAAByAAAAcwAAAAAGAABt7QAAQwAAAA8AAPA4AAAAAAAG8BgAAAACCAAAAgAAAAEA AAABAAAAAQAAAAIAAABAAB7xEAAAAP//AAAAAP8AgICAAPcAABAADwAC8JIAAAAQAAjwCAAAAAEA AAABBAAADwAD8DAAAAAPAATwKAAAAAEACfAQAAAAAAAAAAAAAAAAAAAAAAAAAAIACvAIAAAAAAQA AAUAAAAPAATwQgAAABIACvAIAAAAAQQAAAAOAABTAAvwHgAAAL8BAAAQAMsBAAAAAP8BAAAIAAQD CQAAAD8DAQABAAAAEfAEAAAAAQAAAP//CAAAAAYAHUgMAAAAAQAcW8wCBgAeSAwAAAABAGxczAIG AB9IDAAAAAEAjJwZAAYAIEgMAAAAAQD0zxcABgAhSAwAAAABAGw8zgIGACJIDAAAAAEAzFPOAgYA I0gMAAAAAQBMnBkABgAkSAwAAAABAAzQwAKdAAAA8AEAAN0GAAB4CAAA2Q8AAGkcAADUIgAANi0A AOR5AAAAAAAAAQABAAAAAQACAAAAAQADAAAAAQAEAAAAAQAFAAAAAQAGAAAAAQAHAAAAAQCrAAAA AAIAAOsGAACGCAAA5w8AAHccAADiIgAARC0AAOR5AAAAAAAAAQAAAAIAAAADAAAABAAAAAUAAAAG AAAABwAAAAEAAAA4AAAACAAAACqAdXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6c21h cnR0YWdzBIBkYXRlAIAMAAABAQAAAAkAAAACgDEwAoAxMQKAMTQEgDIwMDUEgDIwMDYBgDQDgERh eQWATW9udGgEgFllYXIIAAMAAAAHAAAABQAAAAYAAAACAAAACAAAAAQAAAAIAAMAAAAHAAAAAAAA AAYAAAABAAAACAAAAAMAAAAIAAMAAAAHAAAABQAAAAYAAAACAAAACAAAAAQAAAAIAAMAAAAHAAAA BQAAAAYAAAACAAAACAAAAAQAAAAIAAMAAAAHAAAABQAAAAYAAAACAAAACAAAAAQAAAAIAAMAAAAH AAAABQAAAAYAAAACAAAACAAAAAQAAAAIAAMAAAAHAAAABQAAAAYAAAACAAAACAAAAAQAAAAIAAMA AAAHAAAABQAAAAYAAAACAAAACAAAAAQAAAD//wEACgAAAAABAlz+Bv////+AVQAAUnMAAAAAAACD VQAAUnMAAAAAAADUAAAA3AAAAGgBAABuAQAAPgUAAEcFAADDCQAA0QkAAH0UAACBFAAAMBcAADQX AACkGAAAqBgAANYYAADaGAAAVB0AAF0dAAC+HgAAyh4AAM8fAADTHwAADCUAABAlAABDJQAARyUA AHgmAAB/JgAAXicAAGMnAAD0KgAA9ioAAA8rAAARKwAA/SwAAActAABzLgAAdi4AABwvAAAgLwAA czEAAHcxAAC1MQAAwTEAAPA0AAD9NAAAOjkAADw5AAB7OQAAfTkAAI05AACPOQAAkjkAAJQ5AABu OgAAcDoAAC87AAAzOwAAmEMAAJxDAACiQwAAo0MAAC1LAAA8SwAAeEwAAIJMAACfTAAAp0wAAEJN AABGTQAAAlQAAARUAAAJVAAAC1QAADZXAAA6VwAA3VgAAOFYAABCYAAASmAAAFdgAABdYAAAsGAA AO1gAADAYwAAzmMAAJpkAAChZAAA2WQAAOJkAACaZgAApWYAALJmAAC2ZgAA2mYAAOVmAAACaAAA CWgAAApoAAARaAAAmGkAAKBpAADfaQAA5WkAAFBzAAB6cwAAgXMAAJ50AACgdAAAUXcAAF53AADh eQAA5HkAAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcA HAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAc AAcAHAAHABwABwADAAcABwAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwA BwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHAAcAHAAHABwABwAc AAcABwAAAAAALgIAADcCAAB7AgAAiwIAAKQCAADMAgAALAMAADYDAABxAwAAdQMAALcDAAC8AwAA QQQAAHYEAACFBAAAigQAAMgEAADPBAAAHQUAACAFAABlBQAAaQUAAKcFAACvBQAAEQcAABQHAAAR CAAAGggAAFcIAABoCAAA8AgAAPMIAAA3CQAAQQkAAFkKAABgCgAAogoAAKkKAADrCgAA8QoAAH0L AACJCwAAxgsAAM8LAAAPDAAAFgwAAFgMAABfDAAAoQwAAK0MAABtDQAAeg0AALYNAADCDQAAPA4A AEYOAADJDgAA1A4AALgPAADJDwAAshAAAL4QAABDEQAARBEAAIoRAACTEQAAzBEAANURAAAbEgAA IxIAAGUSAABnEgAAkhIAAKcSAADZEgAA4BIAAEMTAABGEwAAhxMAAI4TAADLEwAA0hMAABMUAAAY FAAAvRQAAMUUAABeFQAAYhUAABAWAAATFgAAZRYAAG4WAACtFgAAthYAAPQWAAD+FgAAhBcAAIkX AAD+FwAAARgAAFIYAABXGAAAmhgAAKEYAADhGAAA6xgAACQZAAArGQAAlBkAAJcZAADEGwAAzhsA AAccAAAOHAAASBwAAFkcAADhHAAA5xwAAEAdAABDHQAAgB0AAIodAADEHQAA0R0AAAweAAANHgAA Vx4AAGEeAACdHgAAox4AAOQeAAD5HgAAdB8AAHYfAAC7HwAAvR8AAAMgAAANIAAASCAAAE8gAACz IAAAtyAAAP8gAAACIQAASCEAAEshAAAWIgAAGiIAAGEiAABmIgAAsyIAAMQiAAC8IwAAwSMAAAMk AAAFJAAASiQAAE0kAACMJAAAliQAANUkAADfJAAAHSUAACglAABgJQAAbCUAANQlAADZJQAAGSYA ACQmAACEJgAAhiYAAI0mAACQJgAAzSYAANcmAAAUJwAAFicAAFYnAABdJwAAmicAAKInAAAdKAAA JCgAAGMoAABqKAAAqigAAKwoAAARKQAAFikAAFUpAABcKQAAmSkAAKApAADhKQAA6SkAAA8qAAAY KgAAuioAAMMqAAC2KwAAvisAAP4rAAAALAAARywAAEssAACWLAAAnywAABUtAAAmLQAA+C0AAP0t AABALgAASy4AAJ0uAACgLgAA7S4AAPguAAAuLwAANy8AAHIvAAB7LwAALDAAAD8wAAByMAAAezAA ALowAADFMAAABTEAAAkxAABIMQAAVTEAANcxAADfMQAAHTIAACIyAABjMgAAbDIAAHIyAAB5MgAA 4DIAAOgyAAArMwAAMDMAAHIzAAB6MwAA2jMAAOMzAACLNAAAjjQAAMk0AADPNAAAIzUAACY1AAA1 NQAAWjUAAHs1AACDNQAAwzUAAMc1AABHNgAAUzYAAJY2AACZNgAAEDcAABI3AABPNwAAdDcAAKE3 AAClNwAAHzgAADA4AAC4OAAAvzgAAPU4AAANOQAAJTkAACk5AACPOgAAmToAAMk6AADNOgAAQTsA AEo7AAAyQAAAOUAAAHpAAAB/QAAA5EAAAPBAAACmQQAAr0EAALNFAADERQAAmkYAAKNGAAD7RgAA BEcAAD1HAABGRwAAu0cAAMJHAAABSAAACEgAAEZIAABRSAAAP0oAAEJKAACGSgAAj0oAAMtKAADP SgAAEUsAABVLAABHSwAAfUsAAINLAACPSwAA/EsAAP9LAABATAAASUwAAIlMAACQTAAA9UwAAPxM AAAZTQAAHk0AANpNAADdTQAADE4AABROAABSTgAAWE4AAJ9OAACpTgAA3k4AAPtOAABrTwAAcE8A AMRPAADITwAADVAAAA9QAAAdUAAALlAAAP9QAAAIUQAARFEAAEhRAACMUQAAjlEAAA1SAAAPUgAA UFIAAFRSAAC2UgAAvVIAAEhUAABRVAAAilQAAJRUAADMVAAA1lQAABRVAAAYVQAAXFUAAGFVAACf VQAAplUAABdWAAAaVgAAblYAAHVWAADcVgAA4lYAAGJXAABlVwAA8VcAAPdXAAB+WAAAgFgAAMdY AADPWAAAEVkAABpZAACeWQAApFkAAK5ZAADPWQAA9lkAAP9ZAAA8WgAAQVoAAG9aAACAWgAASlsA AFNbAACfWwAAolsAAOhbAAD1WwAAW1wAAGJcAACvXAAAuFwAAMBcAADMXAAAR10AAEtdAACPXQAA tF0AANddAADYXQAAHl4AACJeAABhXgAAZ14AAKpeAACzXgAA814AAPdeAAAjXwAALV8AAKZfAACs XwAA5F8AAO9fAAAwYAAAPGAAAAthAAAbYQAAVmEAAFlhAAC+YQAAyWEAAINiAACHYgAAz2IAANZi AAAIYwAAGWMAAKNjAACnYwAA72MAAPZjAAAnZAAAK2QAAJdkAAChZAAALGUAADBlAAB0ZQAAfGUA AARmAAAIZgAASmYAAE9mAACIZgAAlGYAACpnAAA7ZwAAwGcAAMtnAAAraAAALmgAAHtoAACMaAAA TGoAAF1qAACUawAAm2sAANtrAADfawAAIWwAACZsAABnbAAAa2wAALBsAACybAAA9GwAAPlsAABW bQAAYG0AAJptAAChbQAA420AAOdtAAAfbgAALG4AAMxuAADWbgAAEG8AABZvAABWbwAAWm8AAGpx AACscQAA1XEAANhxAAAPcgAAEXIAAFRyAABacgAA73IAAABzAAAFcwAAFnMAAFBzAABseAAAc3gA AOF5AADkeQAABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAH ADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAz AAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAH ADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAz AAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAH ADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAz AAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAH ADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAz AAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAH AAcAMwAHAAcAAAAAADUaAAA+GgAAVBoAAFkaAAB7GgAAfhoAAJUiAACWIgAA9CoAAAcrAAAIKwAA CCsAABArAAAjKwAAAy4AAAQuAAAFLgAABS4AAKsuAACxLgAAsi4AALIuAADMLwAA0i8AAN8xAADg MQAAJTQAACY0AADCNgAA0DYAAGE5AABlOQAAw0IAAMpCAADRQgAAnUMAAG1IAABuSAAAb0gAAG9I AABwSAAAcUgAAHJIAABySAAAc0gAAINIAACESAAAhUgAALJIAAC6SAAAu0gAAMBIAADuSQAA7kkA AD5LAAA/SwAAfUsAAH5LAABmTAAAZ0wAAJFNAACiTQAAs00AALNNAADaTQAA6E0AAAZOAAAGTgAA cU4AAHlOAAAPTwAAD08AABFPAAAdTwAAQE8AAFFPAACATwAAiU8AAIpPAACKTwAAqk8AALBPAABQ UgAAZVIAAJBSAACeUgAAAlQAAAtUAACDVQAAhFUAAL1VAAC9VQAAv1UAAMtVAADmVQAA91UAACZW AAAmVgAAKFYAAC9WAAAwVgAAMFYAAFBWAABWVgAA+FYAAPhWAAD6VgAABlcAAKVZAACmWQAAT3MA AOR5AAADAAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQA AwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAEAAMABAAD AAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAEAAMA BAADAAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAH AAAAAACYQwAAnEMAAFBzAADkeQAABwAEAAcABwAAAAAA5HkAAMMHAAAIAAAADJEQAAAAAQAAAAQA AAAAAAIA//8EAAAABABTAGgAZQB3AAAADQBUAHIAZQB2AG8AcgAgAFcAaQBsAHMAbwBuAAAAJwAA AAQAAAAIAAAA5QAAAAAAAAAmAAAAdX0AACM3AQB+KgcAc1wMAEJaFwAzbBgAZ2EkAEZgKQDEVzoA FXY/ADYZRwAPEVQAlw1VAOVxVQAmAV4AykpfAFoDYQAEaGEAPh9jAIMHbwDBG28A5yR1ACgNeAD3 IXkA/SqFAJU/hwACCKAAwD2vAIsksQDBNrQAniG1AIU3xABFCsoABSbKAOYcywAVbdAAHTfuACRU 7gD0cPAA/0AAgAEAAAAAAAAAAABIEXwTAQABAAAAAAAAAAAAAAAAAAAAAAACNAAAAAAAAACQOQAA kDoAAHV4AADjeQAAwAAAEABAAADAAABCAAAAAMAAAIgAQAAAwAAA2AFAAAD//wIAAAAHAFUAbgBr AG4AbwB3AG4ADQBUAHIAZQB2AG8AcgAgAFcAaQBsAHMAbwBuAP//AgAIAAAAAAAAAAAAAAAAAAAA AAAAAAEA//8CAAAAAAAAAP//AAACAP//AAAAAP//AAACAP//AAAAAAYAAABHFpABAAACAgYDBQQF AgMEh3oAIAAAAIAIAAAAAAAAAP8BAAAAAAAAVABpAG0AZQBzACAATgBlAHcAIABSAG8AbQBhAG4A AAA1FpABAgAFBQECAQcGAgUHAAAAAAAAABAAAAAAAAAAAAAAAIAAAAAAUwB5AG0AYgBvAGwAAAAz JpABAAACCwYEAgICAgIEh3oAIAAAAIAIAAAAAAAAAP8BAAAAAAAAQQByAGkAYQBsAAAAOwaQAYYH AgEGAAMBAQEBAQMAAAAAAA4IEAAAAAAAAAABAAQAAAAAAFMAaQBtAFMAdQBuAAAAi1tTTwAAPzWQ AQAAAgcDCQICBQIEBId6ACAAAACACAAAAAAAAAD/AQAAAAAAAEMAbwB1AHIAaQBlAHIAIABOAGUA dwAAADUmkAEAAAILBgQDBQQEAgSHegAhAAAAgAgAAAAAAAAA/wEBAAAAAABUAGEAaABvAG0AYQAA ACIABAAxiIwYAPDQAgAAaAEAAAAAs6uaprOrmqYAAAAAAgABAAAANREAABtiAAABADoAAAAEAAMQ 0QAAADURAAAbYgAAAQA6AAAA0QAAAAAAAAAhAwDwEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAnBaAFtAC0AIGBMjQAABAAGQBkAAAAGQAAABZzAAAWcwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAAAAAAAAAAAgzg3EA8BAA CAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAASAAAAAAAKPD/DwEAAT8AAAAAAACzEQAA//// f////38AAAAA////f////3////9/AgigAP//EgAAAAAAAAA9AEMAQwBBAE0AUAAgAHcAbwByAGsA aQBuAGcAIABHAHIAbwB1AHAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAg ACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgAEcAAAAAAAAABABTAGgA ZQB3AA0AVAByAGUAdgBvAHIAIABXAGkAbABzAG8AbgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD+/wAABQACAAAAAAAAAAAAAAAA AAAAAAABAAAA4IWf8vlPaBCrkQgAKyez2TAAAACsAQAAEQAAAAEAAACQAAAAAgAAAJgAAAADAAAA 4AAAAAQAAADsAAAABQAAAPwAAAAGAAAACAEAAAcAAAAUAQAACAAAACgBAAAJAAAAQAEAABIAAABM AQAACgAAAGgBAAAMAAAAdAEAAA0AAACAAQAADgAAAIwBAAAPAAAAlAEAABAAAACcAQAAEwAAAKQB AAACAAAA5AQAAB4AAAA+AAAAQ0NBTVAgd29ya2luZyBHcm91cCAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgRwAgAB4AAAABAAAAAENBTR4AAAAFAAAAU2hldwAgd28eAAAA AQAAAABoZXceAAAAAQAAAABoZXceAAAACwAAAE5vcm1hbC5kb3QAbh4AAAAOAAAAVHJldm9yIFdp bHNvbgBHch4AAAACAAAAMgBldh4AAAAUAAAATWljcm9zb2Z0IFdvcmQgMTAuMABAAAAAAEbDIwAA AABAAAAAAHoLeEbWxQFAAAAAAHoLeEbWxQEDAAAAAQAAAAMAAAA1EQAAAwAAABtiAAADAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/v8AAAUAAgAAAAAAAAAAAAAAAAAAAAAAAgAA AALVzdWcLhsQk5cIACss+a5EAAAABdXN1ZwuGxCTlwgAKyz5rnQBAAAwAQAADAAAAAEAAABoAAAA DwAAAHAAAAAFAAAAiAAAAAYAAACQAAAAEQAAAJgAAAAXAAAAoAAAAAsAAACoAAAAEAAAALAAAAAT AAAAuAAAABYAAADAAAAADQAAAMgAAAAMAAAAEgEAAAIAAADkBAAAHgAAABAAAABOb3J0ZWwgTmV0 d29ya3MAAwAAANEAAAADAAAAOgAAAAMAAAAWcwAAAwAAAE8aCgALAAAAAAAAAAsAAAAAAAAACwAA AAAAAAALAAAAAAAAAB4QAAABAAAAPgAAAENDQU1QIHdvcmtpbmcgR3JvdXAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIEcADBAAAAIAAAAeAAAABgAAAFRpdGxlAAMAAAAB AAAAgAEAAAcAAAAAAAAAQAAAAAEAAADMAAAAAgAAANQAAAADAAAA3AAAAAQAAAAoAQAABQAAAEwB AAAGAAAAdAEAAAUAAAACAAAAFAAAAF9BZEhvY1Jldmlld0N5Y2xlSUQAAwAAAA4AAABfRW1haWxT dWJqZWN0AAQAAAANAAAAX0F1dGhvckVtYWlsAAUAAAAYAAAAX0F1dGhvckVtYWlsRGlzcGxheU5h bWUABgAAABkAAABfUmV2aWV3aW5nVG9vbHNTaG93bk9uY2UAAgAAAOQEAAADAAAArpqBLh4AAABB AAAAVkNBVC9MQ0FTIGRyYWZ0IHVwZGF0ZTogZHJhZnQtYmVybnN0ZWluLWNjYW1wLWdtcGxzLXZj YXQtbGNhcy0wMQBlAEMeAAAAGgAAAHNkc2hld0BhbWVyaWNhc20wMS5udC5jb20AYWYeAAAAHgAA AFNoZXcsIFN0ZXBoZW4gW0NBUjpRVDMwOkVYQ0hdAGJlHgAAAAEAAAAAaGV3AAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAACAAAAAwAAAAQAAAAFAAAABgAAAAcAAAAIAAAACQAA AAoAAAALAAAADAAAAA0AAAAOAAAADwAAABAAAAARAAAAEgAAABMAAAAUAAAAFQAAABYAAAAXAAAA GAAAABkAAAAaAAAAGwAAABwAAAAdAAAAHgAAAB8AAAAgAAAAIQAAACIAAAAjAAAAJAAAACUAAAAm AAAAJwAAACgAAAApAAAAKgAAACsAAAAsAAAALQAAAC4AAAAvAAAAMAAAADEAAAAyAAAAMwAAADQA AAA1AAAANgAAADcAAAA4AAAAOQAAADoAAAA7AAAAPAAAAD0AAAA+AAAAPwAAAEAAAABBAAAAQgAA AEMAAABEAAAARQAAAEYAAABHAAAASAAAAEkAAABKAAAASwAAAEwAAABNAAAATgAAAE8AAABQAAAA UQAAAFIAAABTAAAAVAAAAFUAAABWAAAAVwAAAFgAAABZAAAAWgAAAFsAAABcAAAAXQAAAF4AAABf AAAAYAAAAGEAAABiAAAAYwAAAGQAAABlAAAAZgAAAGcAAABoAAAAaQAAAGoAAABrAAAAbAAAAG0A AABuAAAAbwAAAHAAAABxAAAAcgAAAHMAAAB0AAAAdQAAAHYAAAB3AAAA/v///3kAAAB6AAAAewAA AHwAAAB9AAAAfgAAAH8AAAD+////gQAAAIIAAACDAAAAhAAAAIUAAACGAAAAhwAAAIgAAACJAAAA igAAAIsAAACMAAAAjQAAAI4AAACPAAAAkAAAAJEAAACSAAAAkwAAAJQAAACVAAAAlgAAAJcAAACY AAAAmQAAAJoAAACbAAAAnAAAAJ0AAACeAAAAnwAAAKAAAAChAAAAogAAAKMAAACkAAAApQAAAKYA AACnAAAAqAAAAKkAAACqAAAAqwAAAKwAAACtAAAArgAAAK8AAACwAAAAsQAAALIAAACzAAAAtAAA ALUAAAC2AAAAtwAAALgAAAC5AAAAugAAALsAAAC8AAAAvQAAAL4AAAC/AAAAwAAAAMEAAADCAAAA wwAAAMQAAADFAAAAxgAAAMcAAADIAAAAyQAAAMoAAADLAAAAzAAAAM0AAADOAAAAzwAAANAAAADR AAAA0gAAANMAAADUAAAA1QAAANYAAADXAAAA2AAAANkAAADaAAAA2wAAANwAAADdAAAA3gAAAN8A AADgAAAA4QAAAOIAAADjAAAA5AAAAOUAAADmAAAA5wAAAOgAAADpAAAA6gAAAOsAAADsAAAA7QAA AO4AAADvAAAA8AAAAPEAAADyAAAA8wAAAPQAAAD1AAAA/v////cAAAD4AAAA+QAAAPoAAAD7AAAA /AAAAP0AAAD+/////wAAAAABAAABAQAAAgEAAAMBAAAEAQAABQEAAP7////9/////f////3///8K AQAA/v////7////+//////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /////////////////////////1IAbwBvAHQAIABFAG4AdAByAHkAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAWAAUB//////////8DAAAABgkCAAAAAADAAAAAAAAA RgAAAAAAAAAAAAAAAABJaYJG1sUBDAEAAIAAAAAAAAAARABhAHQAYQAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAoAAgH///////////////8A AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB4AAAAABAAAAAAAAAxAFQAYQBiAGwA ZQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADgAC AQEAAAAGAAAA/////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAADx6gAA AAAAAFcAbwByAGQARABvAGMAdQBtAGUAbgB0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAaAAIBAgAAAAUAAAD/////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAACjuAAAAAAAABQBTAHUAbQBtAGEAcgB5AEkAbgBmAG8AcgBtAGEAdABpAG8AbgAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACgAAgH///////////////8AAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAD2AAAAABAAAAAAAAAFAEQAbwBjAHUAbQBlAG4AdABTAHUAbQBt AGEAcgB5AEkAbgBmAG8AcgBtAGEAdABpAG8AbgAAAAAAAAAAAAAAOAACAQQAAAD//////////wAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP4AAAAAEAAAAAAAAAEAQwBvAG0AcABP AGIAagAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAASAAIA ////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGoAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAD///////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAABAAAA/v////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /////////////////////wEA/v8DCgAA/////wYJAgAAAAAAwAAAAAAAAEYYAAAATWljcm9zb2Z0 IFdvcmQgRG9jdW1lbnQACgAAAE1TV29yZERvYwAQAAAAV29yZC5Eb2N1bWVudC44APQ5snEAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAUgBvAG8AdAAgAEUAbgB0AHIAeQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAABYABQH//////////wMAAAAGCQIAAAAAAMAAAAAAAABGAAAA AAAAAAAAAAAA8D9oKEfWxQESAQAAAAQAAAAAAABEAGEAdABhAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACgACAf///////////////wAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHgAAAAAEAAAAAAAADEAVABhAGIAbABlAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAOAAIBAQAA AAYAAAD/////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAAAPHqAAAAAAAA VwBvAHIAZABEAG8AYwB1AG0AZQBuAHQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAABoAAgECAAAABQAAAP////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAKO4AAAAAAAD////////////////////////////////9//////////////////////// ////////////EQEAAP3////+/////v////7///8QAQAA/f////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /////////////////wEAAAD+////AwAAAAQAAAAFAAAABgAAAAcAAAAIAAAACQAAAAoAAAALAAAA DAAAAA0AAAAOAAAADwAAAP7///////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ////////////////QAAAAAEAAADwAAAAAgAAAPgAAAADAAAAAAEAAAQAAABsAQAABQAAAKwBAAAH AAAA+AEAAAYAAAACAAAAFAAAAF9BZEhvY1Jldmlld0N5Y2xlSUQAAwAAAA4AAABfRW1haWxTdWJq ZWN0AAQAAAANAAAAX0F1dGhvckVtYWlsAAUAAAAYAAAAX0F1dGhvckVtYWlsRGlzcGxheU5hbWUA BgAAABkAAABfUmV2aWV3aW5nVG9vbHNTaG93bk9uY2UABwAAABwAAABfUHJldmlvdXNBZEhvY1Jl dmlld0N5Y2xlSUQAAgAAAOQEAAADAAAAiwgt9x8AAAAyAAAAZAByAGEAZgB0AC0AYgBlAHIAbgBz AHQAZQBpAG4ALQBjAGMAYQBtAHAALQBnAG0AcABsAHMALQB2AGMAYQB0AC0AbABjAGEAcwAtADAA MQAgAGMAbwBtAG0AZQBuAHQAcwAAAB8AAAAbAAAAdwBpAGwAcwBvAG4AdABAAGEAbQBlAHIAaQBj AGEAcwBtADAAMQAuAG4AdAAuAGMAbwBtAAAAAAAfAAAAIQAAAFcAaQBsAHMAbwBuACwAIABUAHIA ZQB2AG8AcgAgAFsASQBSAEUAMAA3ADoAUQA4ADQAMAA6AEUAWABDAEgAXQAAAAAAAwAAAK6agS4A AAAAAAAAAAAAAAAFAFMAdQBtAG0AYQByAHkASQBuAGYAbwByAG0AYQB0AGkAbwBuAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAKAACAf///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAPYAAAAAEAAAAAAAAAUARABvAGMAdQBtAGUAbgB0AFMAdQBtAG0AYQByAHkA SQBuAGYAbwByAG0AYQB0AGkAbwBuAAAAAAAAAAAAAAA4AAIBBAAAAP//////////AAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAAHQDAAAAAAAAAQBDAG8AbQBwAE8AYgBqAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABIAAgD///////// //////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAagAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAP///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAEA/v8DCgAA/////wYJAgAAAAAAwAAAAAAAAEYYAAAATWljcm9zb2Z0IFdvcmQg RG9jdW1lbnQACgAAAE1TV29yZERvYwAQAAAAV29yZC5Eb2N1bWVudC44APQ5snEAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/v8AAAUAAgAAAAAAAAAAAAAAAAAAAAAAAgAAAALVzdWc LhsQk5cIACss+a5EAAAABdXN1ZwuGxCTlwgAKyz5rnQBAAAwAQAADAAAAAEAAABoAAAADwAAAHAA AAAFAAAAiAAAAAYAAACQAAAAEQAAAJgAAAAXAAAAoAAAAAsAAACoAAAAEAAAALAAAAATAAAAuAAA ABYAAADAAAAADQAAAMgAAAAMAAAAEgEAAAIAAADkBAAAHgAAABAAAABOb3J0ZWwgTmV0d29ya3MA AwAAANEAAAADAAAAOgAAAAMAAAAWcwAAAwAAAE8aCgALAAAAAAAAAAsAAAAAAAAACwAAAAAAAAAL AAAAAAAAAB4QAAABAAAAPgAAAENDQU1QIHdvcmtpbmcgR3JvdXAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIEcADBAAAAIAAAAeAAAABgAAAFRpdGxlAAMAAAABAAAAAAIA AAcAAAAAAAAAgQAAAIIAAACDAAAAhAAAAIUAAACGAAAAhwAAAIgAAACJAAAAigAAAIsAAACMAAAA jQAAAI4AAACPAAAAkAAAAJEAAACSAAAAkwAAAJQAAACVAAAAlgAAAJcAAACYAAAAmQAAAJoAAACb AAAAnAAAAJ0AAACeAAAAnwAAAKAAAAChAAAAogAAAKMAAACkAAAApQAAAKYAAACnAAAAqAAAAKkA AACqAAAAqwAAAKwAAACtAAAArgAAAK8AAACwAAAAsQAAALIAAACzAAAAtAAAALUAAAC2AAAAtwAA ALgAAAC5AAAAugAAALsAAAC8AAAAvQAAAL4AAAC/AAAAwAAAAMEAAADCAAAAwwAAAMQAAADFAAAA xgAAAMcAAADIAAAAyQAAAMoAAADLAAAAzAAAAM0AAADOAAAAzwAAANAAAADRAAAA0gAAANMAAADU AAAA1QAAANYAAADXAAAA2AAAANkAAADaAAAA2wAAANwAAADdAAAA3gAAAN8AAADgAAAA4QAAAOIA AADjAAAA5AAAAOUAAADmAAAA5wAAAOgAAADpAAAA6gAAAOsAAADsAAAA7QAAAO4AAADvAAAA8AAA APEAAADyAAAA8wAAAPQAAAD1AAAA/v////cAAAD4AAAA+QAAAPoAAAD7AAAA/AAAAP0AAAD+//// //////////8= ------_=_NextPart_001_01C5D647.2A748015-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 21 Oct 2005 11:12:08 +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: Question on Administratively down bit Date: Fri, 21 Oct 2005 07:10:40 -0400 Message-ID: Thread-Topic: Question on Administratively down bit Thread-Index: AcXWBAEvn6sBhSpVTaqywiT34yEgfwAKhEBw From: "Zafar Ali \(zali\)" To: "Akira NAGATA" , "Adrian Farrel" Cc: Hi Akira,=20 The sequence you mentioned is correct. Also this is my understanding that when an LSP is in "Admin.A =3D 1", an optical node may be = performing some power monitoring and adjustment related to the commissioning process (again, this is a local action by an optical node). From a router's prospective, I do see a need for router NOT to send any data traffic on the LSP that is in "Admin.A=3D1", in addition of suppressing alarm on the interface in question. I.e., an LSP can ONLY carrying data traffic when it is back to "Admin.A=3D0". =20 Comments/ additions?=20 Thanks Regards... Zafar=20 > -----Original Message----- > From: owner-ccamp@ops.ietf.org=20 > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Akira NAGATA > Sent: Friday, October 21, 2005 1:52 AM > To: Adrian Farrel > Cc: Akira_NAGATA; ccamp@ops.ietf.org > Subject: Re: Question on Administratively down bit >=20 > Hi Adrian, >=20 > Thank you for your discussing this issue. >=20 > I understand that a hardware behavior triggered by=20 > AdminStatus bit will differ from one vendor to another. >=20 > Alarm inhibition is just an example of application by A-bit, > RFC3471 or 3473 can not achieve interoperability on the=20 > hardware behavior itself triggered by A-bit in multi-vendor=20 > network. Is it right? > In a fact, I think it cannot be helped. >=20 > I believe, however, RFC3471 or 3473 shall achieve=20 > interoperability on AdminStatus bit including A-bit from the=20 > perspective of message handling, at least. >=20 > RFC3473 has no explicit clarification of handling A-bit or=20 > T-bit, where it has an explicit description of handling the=20 > pair of D and R-bit (in Section 7.2). > In order to achieve interoperability at message level, more=20 > explicit description will be needed for A-bit or T-bit like=20 > the case of D+R-bit. >=20 > How do you think about this point? >=20 > According to my understanding using examples from D+R-bit in=20 > Sec 7.2.1, Path/Resv sequence for alarm report inhibition by=20 > A-bit (i.e. > degradation > of established LSP) can be shown as following: >=20 > Path (A=3D1, R=3D1) > ingress -------------------> egress > node Resv (A=3D1, R=3D0) node > <------------------ >=20 > Similarly, Path/Resv sequence for enabling alarm report by=20 > A-bit (i.e. activation of degradated LSP) can be shown as following: >=20 > Path (A=3D0, R=3D1) > ingress -------------------> egress > node Resv (A=3D0, R=3D0) node > <------------------ >=20 > Would you mind letting me know if something wrong? >=20 > best regards, > Akira >=20 > On Wed, 19 Oct 2005 14:57:35 +0100 > "Adrian Farrel" san wrote: >=20 > > Hi Akira, > >=20 > > I have been thinking about your question and discussing it=20 > with a few=20 > > people. > >=20 > > The general consensus is that it is important to have well-defined=20 > > mechanisms for the signaling exchange of the Admin Status bits, but=20 > > that the actions to take on receipt of some the bits may be=20 > dependent=20 > > on local policy or on data plane technology. > >=20 > > Thus an implementation may decide that certain alarms should be=20 > > suppressed during LSP establishment because it knows them to be=20 > > "false" alarms triggered by the process of establishing the LSP. On=20 > > the other hand, an implementation may decide that other alarms that=20 > > are first raised during LSP establishment represent a=20 > different set of=20 > > circumstances and should be raised. I would be worried if=20 > we tried to=20 > > list and categorise all such alarms within the CCAMP working group. > >=20 > > It might be useful to consider whether the behavior of switch under=20 > > alarm suppression conditions should be configurable to allow the=20 > > operator to select consistent behavior, or whether this is=20 > adding too much complexity. > >=20 > > Cheers, > > Adrian > >=20 > > ----- Original Message ----- > > From: "Akira NAGATA" > > To: > > Cc: "Akira_NAGATA" > > Sent: Friday, August 19, 2005 12:13 PM > > Subject: Question on Administratively down bit > >=20 > >=20 > > > Mr. Lou Berger and editors of RFC3471 and RFC3473, > > > > > > This is my first time to send e-mail to ccamp. > > > Thanks in advance. > > > > > > I'd like to ask one question about the handling of=20 > Administratively=20 > > > down > > bit > > > in GMPLS RSVP-TE's Admin_Status object. > > > > > > RFC3471 introduces "inhibiting alarm reporting" as an example > > application > > > of local action to "down" state (that is, A-bit=3D1) in Section 8. > > > But I can't find any other explicit descriptions about this=20 > > > procedure in RFC3471 or 3473. > > > > > > I understand that actions to be taken by each node receiving > > Admin_Status > > > object shall be based on local policy. > > > > > > With regard to inhibition of alarm reporting, however, in order to > > achieve it > > > through end-to-end, I believe that we had better take a unified=20 > > > action as a response to A-bit ("down" or "up"). > > > Operator will expect this feature. > > > > > > (Here I mean alarm report is not reporting via RSVP messages as > > described > > > in ID-alarm-spec, but one from NE to external system such=20 > as network=20 > > > management system.) > > > > > > Are there any considerations, drafts or RFCs to define it? > > > > > > Thanks, > > > --- > > > Akira NAGATA > > > > > > > > > > > > > >=20 >=20 > --- > Akira NAGATA Photonic Node=20 > Laboratory, Photonics Networking Laboratories, Fujitsu=20 > Laboratories Ltd. > TEL: +81-44-754-2765 FAX: +81-44-754-2741 >=20 >=20 Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 21 Oct 2005 05:54:17 +0000 Date: Fri, 21 Oct 2005 14:51:33 +0900 From: Akira NAGATA To: "Adrian Farrel" Subject: Re: Question on Administratively down bit Cc: Akira_NAGATA , Message-Id: <20051021133213.6ADC.NAGATA.AKIRA@jp.fujitsu.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Hi Adrian, Thank you for your discussing this issue. I understand that a hardware behavior triggered by AdminStatus bit will differ from one vendor to another. Alarm inhibition is just an example of application by A-bit, RFC3471 or 3473 can not achieve interoperability on the hardware behavior itself triggered by A-bit in multi-vendor network. Is it right? In a fact, I think it cannot be helped. I believe, however, RFC3471 or 3473 shall achieve interoperability on AdminStatus bit including A-bit from the perspective of message handling, at least. RFC3473 has no explicit clarification of handling A-bit or T-bit, where it has an explicit description of handling the pair of D and R-bit (in Section 7.2). In order to achieve interoperability at message level, more explicit description will be needed for A-bit or T-bit like the case of D+R-bit. How do you think about this point? According to my understanding using examples from D+R-bit in Sec 7.2.1, Path/Resv sequence for alarm report inhibition by A-bit (i.e. degradation of established LSP) can be shown as following: Path (A=1, R=1) ingress -------------------> egress node Resv (A=1, R=0) node <------------------ Similarly, Path/Resv sequence for enabling alarm report by A-bit (i.e. activation of degradated LSP) can be shown as following: Path (A=0, R=1) ingress -------------------> egress node Resv (A=0, R=0) node <------------------ Would you mind letting me know if something wrong? best regards, Akira On Wed, 19 Oct 2005 14:57:35 +0100 "Adrian Farrel" san wrote: > Hi Akira, > > I have been thinking about your question and discussing it with a few > people. > > The general consensus is that it is important to have well-defined > mechanisms for the signaling exchange of the Admin Status bits, but that > the actions to take on receipt of some the bits may be dependent on local > policy or on data plane technology. > > Thus an implementation may decide that certain alarms should be suppressed > during LSP establishment because it knows them to be "false" alarms > triggered by the process of establishing the LSP. On the other hand, an > implementation may decide that other alarms that are first raised during > LSP establishment represent a different set of circumstances and should be > raised. I would be worried if we tried to list and categorise all such > alarms within the CCAMP working group. > > It might be useful to consider whether the behavior of switch under alarm > suppression conditions should be configurable to allow the operator to > select consistent behavior, or whether this is adding too much complexity. > > Cheers, > Adrian > > ----- Original Message ----- > From: "Akira NAGATA" > To: > Cc: "Akira_NAGATA" > Sent: Friday, August 19, 2005 12:13 PM > Subject: Question on Administratively down bit > > > > Mr. Lou Berger and editors of RFC3471 and RFC3473, > > > > This is my first time to send e-mail to ccamp. > > Thanks in advance. > > > > I'd like to ask one question about the handling of Administratively down > bit > > in GMPLS RSVP-TE's Admin_Status object. > > > > RFC3471 introduces "inhibiting alarm reporting" as an example > application > > of local action to "down" state (that is, A-bit=1) in Section 8. > > But I can't find any other explicit descriptions about this procedure > > in RFC3471 or 3473. > > > > I understand that actions to be taken by each node receiving > Admin_Status > > object shall be based on local policy. > > > > With regard to inhibition of alarm reporting, however, in order to > achieve it > > through end-to-end, I believe that we had better take a unified action > > as a response to A-bit ("down" or "up"). > > Operator will expect this feature. > > > > (Here I mean alarm report is not reporting via RSVP messages as > described > > in ID-alarm-spec, but one from NE to external system such as network > > management system.) > > > > Are there any considerations, drafts or RFCs to define it? > > > > Thanks, > > --- > > Akira NAGATA > > > > > > > > > --- Akira NAGATA Photonic Node Laboratory, Photonics Networking Laboratories, Fujitsu Laboratories Ltd. TEL: +81-44-754-2765 FAX: +81-44-754-2741 Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 20 Oct 2005 22:51:53 +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-inter-domain-pd-path-comp-01.txt Message-Id: Date: Thu, 20 Oct 2005 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 : A Per-domain path computation method for establishing Inter-domain Traffic Engineering (TE) Label Switched Paths (LSPs) Author(s) : J. Vasseur, et al. Filename : draft-ietf-ccamp-inter-domain-pd-path-comp-01.txt Pages : 18 Date : 2005-10-20 This document specifies a per-domain path computation technique for establishing inter-domain Traffic Engineering (TE) Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Label Switched Paths (LSPs). In this document a domain refers to a collection of network elements within a common sphere of address management or path computational responsibility such as IGP areas and Autonomous Systems. Per-domain computation applies where the full path of an inter-domain TE LSP cannot be or is not determined at the ingress node of the TE LSP, and is not signaled across domain boundaries. This is most likely to arise owing to TE visibility limitations. The signaling message indicates the destination and nodes up to the next domain boundary. It may also indicate further domain boundaries or domain identifiers. The path through each domain, possibly including the choice of exit point from the domain, must be determined within the domain. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-inter-domain-pd-path-comp-01.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-inter-domain-pd-path-comp-01.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-inter-domain-pd-path-comp-01.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: <2005-10-20173251.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-inter-domain-pd-path-comp-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-inter-domain-pd-path-comp-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-10-20173251.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 20 Oct 2005 18:48:28 +0000 Message-ID: <011101c5d5a6$72136bd0$7a1810ac@movaz.com> From: "Igor Bryskin" To: "Kohei Shiomoto" Cc: , "Adrian Farrel" , "Arthi Ayyangar" , "Richard Rabbat" Subject: Re: I-D ACTION:draft-shiomoto-ccamp-lsp-hierarchy-bis-00.txt Date: Thu, 20 Oct 2005 14:45:30 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi, I believe the draft could be very useful. I have several suggestions that IMO would make it stronger. 1.. It is possible that the same H-LSP is advertised into several control planes (for example, L1VPN provider H-LSP could be advertised into several VPNs in the Virtual Link mode) each time with different link IDs (possibly sometimes as numbered and sometimes as unnumbered). This fact could be negotiated between the H-LSP ends by including several LSP_TUNNEL_INTERFACE_ID objects (one per target control plane) into Path/Resv message. I've probably missed it, but I didn't see anywhere in the draft an explicit statement of such possibility. 2.. There are no currently any signaling mechanisms for negotiating how parallel H-LSPs should be bundled together before advertising them as a TE link. Normally, such negotiation is provided via LMP. However, you suggest (and rightfully so) to avoid using LMP for TE links based on H-LSPs, hence, all negotiations should be achieved via signaling. Note that bundling schemes could be different for each target control plane. One way of achieving this is by introducing a new sub-TLV of the LSP_TUNNEL_INTERFACE_ID object - let's call it BUNDLE sub-TLV - and have the ends of the H-LSPs to bundle those H-LSPs which share the same bundle ID for the same target control plane. Note also that bundle ID could be used as a link ID when advertising the bundle as a single TE link 3.. H-LSP does not necessarily have to be advertised as a TE link into any control plane. For instance, an H-LSP could be used as a dedicated protection for some other H-LSP or as a data link for a higher layer LSPs (note that not all data links are advertised as TE links). However, in order for such H-LSP to be capable to nest other LSPs the ends of the H-LSP need to know at least that the LSP is intended to be used as H-LSP (that is, resources will be dynamically allocated within the LSP) as well as remote link IDs (otherwise, it would impossible to map the information in the PHOP object with the local end of the link). Again, usually this is the job of the LMP. One way to signal an H-LSP that needs not to be advertised into any control plane is to specify some special value (e.g. NULL) as a target control plane ID. Regards, Igor Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 19 Oct 2005 14:24:43 +0000 Message-ID: <002d01c5d4b5$1273df80$cd1ffccd@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Akira NAGATA" Cc: Subject: Re: Question on Administratively down bit Date: Wed, 19 Oct 2005 14:57:35 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi Akira, I have been thinking about your question and discussing it with a few people. The general consensus is that it is important to have well-defined mechanisms for the signaling exchange of the Admin Status bits, but that the actions to take on receipt of some the bits may be dependent on local policy or on data plane technology. Thus an implementation may decide that certain alarms should be suppressed during LSP establishment because it knows them to be "false" alarms triggered by the process of establishing the LSP. On the other hand, an implementation may decide that other alarms that are first raised during LSP establishment represent a different set of circumstances and should be raised. I would be worried if we tried to list and categorise all such alarms within the CCAMP working group. It might be useful to consider whether the behavior of switch under alarm suppression conditions should be configurable to allow the operator to select consistent behavior, or whether this is adding too much complexity. Cheers, Adrian ----- Original Message ----- From: "Akira NAGATA" To: Cc: "Akira_NAGATA" Sent: Friday, August 19, 2005 12:13 PM Subject: Question on Administratively down bit > Mr. Lou Berger and editors of RFC3471 and RFC3473, > > This is my first time to send e-mail to ccamp. > Thanks in advance. > > I'd like to ask one question about the handling of Administratively down bit > in GMPLS RSVP-TE's Admin_Status object. > > RFC3471 introduces "inhibiting alarm reporting" as an example application > of local action to "down" state (that is, A-bit=1) in Section 8. > But I can't find any other explicit descriptions about this procedure > in RFC3471 or 3473. > > I understand that actions to be taken by each node receiving Admin_Status > object shall be based on local policy. > > With regard to inhibition of alarm reporting, however, in order to achieve it > through end-to-end, I believe that we had better take a unified action > as a response to A-bit ("down" or "up"). > Operator will expect this feature. > > (Here I mean alarm report is not reporting via RSVP messages as described > in ID-alarm-spec, but one from NE to external system such as network > management system.) > > Are there any considerations, drafts or RFCs to define it? > > Thanks, > --- > Akira NAGATA > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 19 Oct 2005 12:36:05 +0000 Message-ID: <43563D39.4080200@psg.com> Date: Wed, 19 Oct 2005 14:34:01 +0200 From: dimitri papadimitriou Reply-To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.11) Gecko/20050728 MIME-Version: 1.0 To: Kohei Shiomoto CC: dimitri.papadimitriou@alcatel.be, ccamp@ops.ietf.org, Adrian Farrel , Arthi Ayyangar , Richard Rabbat Subject: Re: I-D ACTION:draft-shiomoto-ccamp-lsp-hierarchy-bis-00.txt Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit hi kohei Kohei Shiomoto wrote: > Hi Dimitri, > > dimitri papadimitriou wrote: > >>all, >> >>i don't think the issues of advertising an LSP as a TE link in another >>instance of the control plane than the one used for creating the LSP - >>ditto >> >>"[HIERAR] did not consider scenarios where an LSP is created (and >>maintained) by one instance of the GMPLS control plane, and is used as a >>(TE) link by another instance of the GMPLS control plane." >> >>is only a matter of indicating to which instance this advertisement >>should be done; > > I am happy if you could point out what is missing. it is a matter of knowing whether the head-end (of the "LSP") is 1. within the same area than the tail-end 2. the advertisement generated by the tail-end is going to reach the head-end and vice versa (as i think the draft makes no assumption about the routing adjacencies that allows exchanging this information) - note: this condition was kind of implicitly guaranteed in the [HIER] document >>now, in addition to the "routing" part, there is the whole discussion >>about the maintenance of the (inherited) TE link - as we are speaking >>here about separate instance - some specific mechanism may be needed >>otherwise after their creation there may be no easy way to communicate >>their unavailability > > The draft proposes the method to advertise the LSP created in the GMPLS > domain to the different routing instance, MPLS domain for instance. the difference is now that either you rely on the signaling capabilities to tell you (Notify, PathErr) whether the LSP is down - but you have to pass the information to the upper instance - or you are being made aware from the upper instance advertisement but the convergence time may be higher now there is a side issue here a loss of routing adjacency may be such that you loss a TE link even if the TE link is not down >>another more specific question on this document, what is the definition >>of the value space for the "Target Control Plane Instance" ? > > Good question. We use a 32-bit space at this time. If you have any > recommendation, I would be happy to hear that. You think that RD might > be a good choice for instance, don't you. what do you mean by RD ? i would say for instance the Area ID in OSPF >>a last point, section 4 mentions >> >>"This is not believed to be an issue as an informal survey indicated >>that dynamically signalled numbered FAs had not been deployed. Indeed >>it was the attempt to implement numbered FAs that gave rise to the work >>on this document." ... is there a general feeling that having this >>mechanism will make dynamically triggered numbered FA a reality ? > > I hope so. it may be a good sense to know whether provisioned numbered FAs where used before advising a specific mechanism for triggered once - do we have some feedback on this ? thanks, - dimitri. > Thank you for your comments. > --- > Kohei > > PS > I am now about to be on trip. I may not be able to respond timely. I > apologize. > > >>thanks, >>- dimitri. >> >>Internet-Drafts@ietf.org wrote: >> >> >>>A New Internet-Draft is available from the on-line Internet-Drafts >>>directories. >>> >>> >>> Title : Advertisement of hierarchical and stitchable LSPs >>>as TE Links Author(s) : K. Shiomoto, et al. >>> Filename : draft-shiomoto-ccamp-lsp-hierarchy-bis-00.txt >>> Pages : 15 >>> Date : 2005-10-18 >>> >>>This document addresses topics related to hierarchical and stitched >>>Label Switched Paths (LSPs). It describes extensions to allow an >>>egress to identify that an LSP will be used as a dynamically signaled >>>Forwarding Adjacency LSP (FA-LSP) in the case of numbered FA's. In >>>addition, the document addresses the issue of how to indicate that an >>>LSP should be advertised as a TE link into a different instance of the >>>control plane and how to identify the instance that should be used. >>>A URL for this Internet-Draft is: >>>http://www.ietf.org/internet-drafts/draft-shiomoto-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-shiomoto-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-shiomoto-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. >>> >>> >>>------------------------------------------------------------------------ >>> >>>_______________________________________________ >>>I-D-Announce mailing list >>>I-D-Announce@ietf.org > > > > . > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 19 Oct 2005 02:38:03 +0000 Thread-Topic: Re: I-D ACTION:draft-jaihyung-ccamp-lse-architecture-00.txt thread-index: AcXUVjB/KM5nWPfeQ1O3pH8SVA/SzQ== Reply-To: "CHO, JAI HYUNG" From: "CHO, JAI HYUNG" To: "Adrian Farrel" , Cc: Bcc: Subject: RE: Re: I-D ACTION:draft-jaihyung-ccamp-lse-architecture-00.txt Date: Wed, 19 Oct 2005 11:38:29 +0900 Comment: GQ19@|@ZEk=E?,18?x, BcN1b MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Content-Class: urn:content-classes:message Thank you Adrian, I hope the GELS BoF is fine place to harmonize both Ethernet community and GMPLS. I look forward the BoF meeting in Vancouver and community support. I also hope we achieve best solution for this issue out of broad discussion on many potential solutions. Thank you. Regards Jaihyung -----?? ???----- From: "Adrian Farrel" >From Date: 2005-10-18 ?? 11:22:10 To: "CHO, JAI HYUNG" , "ccamp@ops.ietf.org" Cc: Subject: Re: I-D ACTION:draft-jaihyung-ccamp-lse-architecture-00.txt Hi Jaihyung, Thank you for this draft. You are correct that the selection of a label encoding is fundamental to the success of GMPLS control of Ethernet switches, and we must be careful to select a solution that is applicable to all target environments, and which (ideally) is extensible to environments and scenarios that we have not yet determined. As you know, a BoF meeting is planned for Vancouver. The GMPLS controlled Ethernet Label Switching (GELS) BOF agenda and description can be seen at http://www3.ietf.org/proceedings/05nov/agenda/gels.txt One of the objectives of this BoF will be to determine whether the work for Ethernet label switching should be carried out within CCAMP or in a new working group (if the work is done in the IETF at all). The BoF has a proposed scope, but (of course) that will be part of the discussion. Once we know the scope of the work we are doing, and once the location of the work has been determined, it will be appropriate to get into the details of the solutions and what labels we use. In the mean time, your draft is a valuable contribution to the debate about what form that label should take and I would urge people to think about different potential label formats (there are several suggestions circulating) so that we are ready to move forward if/when the work is chartered. Thanks, Adrian ----- Original Message ----- From: "CHO, JAI HYUNG" To: Sent: Sunday, October 16, 2005 6:58 AM Subject: I-D ACTION:draft-jaihyung-ccamp-lse-architecture-00.txt > > > Dear All, > > Following is an announcement of new I-D proposing a solution for > GMPLS implementation over Ethernet. > In last 63rd Paris meeting, it was agreed that this issue belong to > CCAMP work scope. > > Any feedback or participation in this approach will be appreciated. > > % Note : Currently a new BoF (GELS) of similar work is being formed, > however, it is not clear whether the matrerial included in this I-D > fit in the scope of GELS. In particular, this proposal aims to > apply in bridged core network, as well as access network > where GELS precludes in the proposed work scope. > When this I-D is acknowledged in the scope of GELS, > the discussion may be moved to the BoF. > > Thanks > > Jaihyung Cho > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > > > > Title : Label Switched Ethernet (LSE) Architecture > > Author(s) : J. Cho, et al. > > Filename : draft-jaihyung-ccamp-lse-architecture-00.txt > > Pages : 15 > > Date : 2005-10-14 > > > > A solution for GMPLS implementation over Ethernet based on label > > encoding method using 48bits of Ethernet address is proposed. > > Ethernet switches supporting this approach control L2-LSP using > > source & destination MAC addresses. The format of GMPLS label > > encoding on Ethernet header is described. GMPLS bridge model and > > three implementation models over bridged core network are presented. > > The purpose of this draft is not to define new bridge architecture > > but to help understanding some aspects of this approach, and identify > > requirements for potential extension to current GMPLS protocols and > > bridge. > > > > > > A URL for this Internet-Draft is: > > > http://www.ietf.org/internet-drafts/draft-jaihyung-ccamp-lse-architecture-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-jaihyung-ccamp-lse-architecture-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-jaihyung-ccamp-lse-architecture-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. > > > > > ------------------------------------------------------------------------ -- > ------ > > > > _______________________________________________ > > I-D-Announce mailing list > > I-D-Announce@ietf.org > > https://www1.ietf.org/mailman/listinfo/i-d-announce > > > > > > > > > > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 19 Oct 2005 00:37:06 +0000 Message-ID: <027e01c5d3ef$c56210b0$cd1ffccd@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "CHO, JAI HYUNG" , Subject: Re: I-D ACTION:draft-jaihyung-ccamp-lse-architecture-00.txt Date: Tue, 18 Oct 2005 15:22:10 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi Jaihyung, Thank you for this draft. You are correct that the selection of a label encoding is fundamental to the success of GMPLS control of Ethernet switches, and we must be careful to select a solution that is applicable to all target environments, and which (ideally) is extensible to environments and scenarios that we have not yet determined. As you know, a BoF meeting is planned for Vancouver. The GMPLS controlled Ethernet Label Switching (GELS) BOF agenda and description can be seen at http://www3.ietf.org/proceedings/05nov/agenda/gels.txt One of the objectives of this BoF will be to determine whether the work for Ethernet label switching should be carried out within CCAMP or in a new working group (if the work is done in the IETF at all). The BoF has a proposed scope, but (of course) that will be part of the discussion. Once we know the scope of the work we are doing, and once the location of the work has been determined, it will be appropriate to get into the details of the solutions and what labels we use. In the mean time, your draft is a valuable contribution to the debate about what form that label should take and I would urge people to think about different potential label formats (there are several suggestions circulating) so that we are ready to move forward if/when the work is chartered. Thanks, Adrian ----- Original Message ----- From: "CHO, JAI HYUNG" To: Sent: Sunday, October 16, 2005 6:58 AM Subject: I-D ACTION:draft-jaihyung-ccamp-lse-architecture-00.txt > > > Dear All, > > Following is an announcement of new I-D proposing a solution for > GMPLS implementation over Ethernet. > In last 63rd Paris meeting, it was agreed that this issue belong to > CCAMP work scope. > > Any feedback or participation in this approach will be appreciated. > > % Note : Currently a new BoF (GELS) of similar work is being formed, > however, it is not clear whether the matrerial included in this I-D > fit in the scope of GELS. In particular, this proposal aims to > apply in bridged core network, as well as access network > where GELS precludes in the proposed work scope. > When this I-D is acknowledged in the scope of GELS, > the discussion may be moved to the BoF. > > Thanks > > Jaihyung Cho > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > > > > Title : Label Switched Ethernet (LSE) Architecture > > Author(s) : J. Cho, et al. > > Filename : draft-jaihyung-ccamp-lse-architecture-00.txt > > Pages : 15 > > Date : 2005-10-14 > > > > A solution for GMPLS implementation over Ethernet based on label > > encoding method using 48bits of Ethernet address is proposed. > > Ethernet switches supporting this approach control L2-LSP using > > source & destination MAC addresses. The format of GMPLS label > > encoding on Ethernet header is described. GMPLS bridge model and > > three implementation models over bridged core network are presented. > > The purpose of this draft is not to define new bridge architecture > > but to help understanding some aspects of this approach, and identify > > requirements for potential extension to current GMPLS protocols and > > bridge. > > > > > > A URL for this Internet-Draft is: > > > http://www.ietf.org/internet-drafts/draft-jaihyung-ccamp-lse-architecture-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-jaihyung-ccamp-lse-architecture-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-jaihyung-ccamp-lse-architecture-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. > > > > > ------------------------------------------------------------------------ -- > ------ > > > > _______________________________________________ > > I-D-Announce mailing list > > I-D-Announce@ietf.org > > https://www1.ietf.org/mailman/listinfo/i-d-announce > > > > > > > > > > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 19 Oct 2005 00:20:12 +0000 Message-ID: <435590C5.5010002@lab.ntt.co.jp> Date: Wed, 19 Oct 2005 09:18:13 +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: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be CC: ccamp@ops.ietf.org, Adrian Farrel , Arthi Ayyangar , Richard Rabbat Subject: Re: I-D ACTION:draft-shiomoto-ccamp-lsp-hierarchy-bis-00.txt Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Dimitri, dimitri papadimitriou wrote: > all, > > i don't think the issues of advertising an LSP as a TE link in another > instance of the control plane than the one used for creating the LSP - > ditto > > "[HIERAR] did not consider scenarios where an LSP is created (and > maintained) by one instance of the GMPLS control plane, and is used as a > (TE) link by another instance of the GMPLS control plane." > > is only a matter of indicating to which instance this advertisement > should be done; I am happy if you could point out what is missing. > > now, in addition to the "routing" part, there is the whole discussion > about the maintenance of the (inherited) TE link - as we are speaking > here about separate instance - some specific mechanism may be needed > otherwise after their creation there may be no easy way to communicate > their unavailability The draft proposes the method to advertise the LSP created in the GMPLS domain to the different routing instance, MPLS domain for instance. > another more specific question on this document, what is the definition > of the value space for the "Target Control Plane Instance" ? Good question. We use a 32-bit space at this time. If you have any recommendation, I would be happy to hear that. You think that RD might be a good choice for instance, don't you. > > a last point, section 4 mentions > > "This is not believed to be an issue as an informal survey indicated > that dynamically signalled numbered FAs had not been deployed. Indeed > it was the attempt to implement numbered FAs that gave rise to the work > on this document." ... is there a general feeling that having this > mechanism will make dynamically triggered numbered FA a reality ? I hope so. Thank you for your comments. --- Kohei PS I am now about to be on trip. I may not be able to respond timely. I apologize. > > thanks, > - dimitri. > > Internet-Drafts@ietf.org wrote: > >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> >> Title : Advertisement of hierarchical and stitchable LSPs >> as TE Links Author(s) : K. Shiomoto, et al. >> Filename : draft-shiomoto-ccamp-lsp-hierarchy-bis-00.txt >> Pages : 15 >> Date : 2005-10-18 >> >> This document addresses topics related to hierarchical and stitched >> Label Switched Paths (LSPs). It describes extensions to allow an >> egress to identify that an LSP will be used as a dynamically signaled >> Forwarding Adjacency LSP (FA-LSP) in the case of numbered FA's. In >> addition, the document addresses the issue of how to indicate that an >> LSP should be advertised as a TE link into a different instance of the >> control plane and how to identify the instance that should be used. >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-shiomoto-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-shiomoto-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-shiomoto-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. >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 18 Oct 2005 21:39:05 +0000 Message-ID: <43556AAB.8000803@psg.com> Date: Tue, 18 Oct 2005 23:35:39 +0200 From: dimitri papadimitriou Reply-To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.11) Gecko/20050728 MIME-Version: 1.0 To: ccamp@ops.ietf.org CC: Adrian Farrel , Arthi Ayyangar , Richard Rabbat , Kohei Shiomoto Subject: Re: I-D ACTION:draft-shiomoto-ccamp-lsp-hierarchy-bis-00.txt Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit all, i don't think the issues of advertising an LSP as a TE link in another instance of the control plane than the one used for creating the LSP - ditto "[HIERAR] did not consider scenarios where an LSP is created (and maintained) by one instance of the GMPLS control plane, and is used as a (TE) link by another instance of the GMPLS control plane." is only a matter of indicating to which instance this advertisement should be done; now, in addition to the "routing" part, there is the whole discussion about the maintenance of the (inherited) TE link - as we are speaking here about separate instance - some specific mechanism may be needed otherwise after their creation there may be no easy way to communicate their unavailability another more specific question on this document, what is the definition of the value space for the "Target Control Plane Instance" ? a last point, section 4 mentions "This is not believed to be an issue as an informal survey indicated that dynamically signalled numbered FAs had not been deployed. Indeed it was the attempt to implement numbered FAs that gave rise to the work on this document." ... is there a general feeling that having this mechanism will make dynamically triggered numbered FA a reality ? thanks, - dimitri. Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : Advertisement of hierarchical and stitchable LSPs as TE Links > Author(s) : K. Shiomoto, et al. > Filename : draft-shiomoto-ccamp-lsp-hierarchy-bis-00.txt > Pages : 15 > Date : 2005-10-18 > > This document addresses topics related to hierarchical and stitched > Label Switched Paths (LSPs). It describes extensions to allow an > egress to identify that an LSP will be used as a dynamically signaled > Forwarding Adjacency LSP (FA-LSP) in the case of numbered FA's. In > addition, the document addresses the issue of how to indicate that an > LSP should be advertised as a TE link into a different instance of > the control plane and how to identify the instance that should be > used. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-shiomoto-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-shiomoto-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-shiomoto-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. > > > ------------------------------------------------------------------------ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/i-d-announce Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 18 Oct 2005 13:35:40 +0000 Message-Id: <200510181333.j9IDXcTX021314@tm2.ca.alcatel.com> From: "Andrew Dolganow" To: Cc: Subject: FW: I-D ACTION:draft-dolganow-pce-cost-object-00.txt Date: Tue, 18 Oct 2005 09:32:39 -0400 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0004_01C5D3C6.E28C5480" Thread-index: AcXTVwPXwnITnkd0QXylAw6spNWA8AAj5bxg This is a multi-part message in MIME format. ------=_NextPart_000_0004_01C5D3C6.E28C5480 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit All, Please find attach the new draft proposing a cost object to accumulate TE-LSP path cost. As per the below abstract, the draft proposes changes to PCEP and RSVP. A single draft has been created to focus initial technical discussions around the single point of reference. It is the intend of the authors to split the draft later on into 2 separate drafts (as marked in the draft). Section 8 of the document list future work items intended to be handled by the authors as part of this technical topic. Any comments are welcome. Please address those comments to the PCE WG list for now, again to ensure that we have a single forum on which the discussions take place, and so nobody accidentally misses on something. Cheers, Andrew -----Original Message----- From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Monday, October 17, 2005 3:50 PM To: i-d-announce@ietf.org Subject: I-D ACTION:draft-dolganow-pce-cost-object-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : A new object to specify a Traffic Engineering (TE) Label Switch Path (LSP) cost Author(s) : A. Dolganow, J. Vasseur Filename : draft-dolganow-pce-cost-object-00.txt Pages : 11 Date : 2005-10-17 This document proposes a new object (named the COST object) used to specify the cost of a Traffic Engineering (TE) Label Switched Path (LSP). The COST object can be carried within an RSVP message so as to record a TE LSP cost during LSP establishment or within a Path Computation Element (PCE) path computation protocol message so as to provide the cost of a computed path to a Path Computation Client (PCC). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-dolganow-pce-cost-object-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-dolganow-pce-cost-object-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-dolganow-pce-cost-object-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_000_0004_01C5D3C6.E28C5480 Content-Type: Message/External-body; name="ATT00179.dat" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="ATT00179.dat" Content-Type: text/plain Content-ID: <2005-10-17144514.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-dolganow-pce-cost-object-00.txt ------=_NextPart_000_0004_01C5D3C6.E28C5480 Content-Type: Message/External-body; name="draft-dolganow-pce-cost-object-00.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="draft-dolganow-pce-cost-object-00.txt" Content-Type: text/plain Content-ID: <2005-10-17144514.I-D@ietf.org> ------=_NextPart_000_0004_01C5D3C6.E28C5480 Content-Type: text/plain; name="ATT00182.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="ATT00182.txt" _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce ------=_NextPart_000_0004_01C5D3C6.E28C5480-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 17 Oct 2005 16:11:56 +0000 Message-ID: <00cb01c5d334$ef7fafd0$cd1ffccd@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Cc: "Joan Cucchiara" , "Wijnen, Bert \(Bert\)" Subject: GMPLS MIB updates Date: Mon, 17 Oct 2005 17:07:46 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Just to keep you in the loop... The new revisions fix compilation issues. They do not fix: - IANA text as per discussions with Tom P on the list - conformance/compliance issues from the MIB Doctor. Stepwise, we're getting there. Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Sun, 16 Oct 2005 05:59:05 +0000 Reply-To: "CHO, JAI HYUNG" From: "CHO, JAI HYUNG" To: Cc: Bcc: thread-index: AcXSEZT6ifpVyAaXSO2MSjgAJbiJZgABRFYz Date: Sun, 16 Oct 2005 14:58:37 +0900 Thread-Topic: I-D ACTION:draft-jaihyung-ccamp-lse-architecture-00.txt Message-ID: <04e801c5d216$a65503b0$8310fe81@email1> Subject: I-D ACTION:draft-jaihyung-ccamp-lse-architecture-00.txt Comment: GQ19@|@ZEk=E?,18?x, BcN1b A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : Label Switched Ethernet (LSE) Architecture > Author(s) : J. Cho, et al. > Filename : draft-jaihyung-ccamp-lse-architecture-00.txt > Pages : 15 > Date : 2005-10-14 > > A solution for GMPLS implementation over Ethernet based on label > encoding method using 48bits of Ethernet address is proposed. > Ethernet switches supporting this approach control L2-LSP using > source & destination MAC addresses. The format of GMPLS label > encoding on Ethernet header is described. GMPLS bridge model and > three implementation models over bridged core network are presented. > The purpose of this draft is not to define new bridge architecture > but to help understanding some aspects of this approach, and identify > requirements for potential extension to current GMPLS protocols and > bridge. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-jaihyung-ccamp-lse-architecture-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-jaihyung-ccamp-lse-architecture-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-jaihyung-ccamp-lse-architecture-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. > -------------------------------------------------------------------------- ------ > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/i-d-announce > Envelope-to: ccamp-data@psg.com Delivery-date: Sat, 15 Oct 2005 12:23:57 +0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=nfjJvtSlU/HH98pGkW06ItkEvbyl7woOJOLhlC1ZTBg7CICWaKPfnmwqL2isW+FlhIY8ZdV1PWbiH4QrzXrtJFLBl3snWvkGtzdUDQjkvlrnJgctpPIMhscsMZBYhCEWz3j4X5UX0K0kIveZlSlJMr1VDmlkjQ1Q2tyeFsFwVJI= ; Message-ID: <20051015122231.77856.qmail@web30809.mail.mud.yahoo.com> Date: Sat, 15 Oct 2005 05:22:31 -0700 (PDT) From: Igor Bryskin Subject: Re: GMPLS for MS-SPRing To: George Swallow Cc: Diego Caviglia , julien.meuric@francetelecom.com, ccamp@ops.ietf.org, swallow@cisco.com MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1809996778-1129378951=:76768" Content-Transfer-Encoding: 8bit --0-1809996778-1129378951=:76768 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Agree. Note that I was talking about signaling and *path computation*. The laterr cannot be performed without proper advertisings Igor George Swallow wrote: > One thing that I'd suggest adding to your draft is > ability to compute and signal LSP paths in terms of > rings rather than in terms of links, and let ring > border LSRs to expend the paths - provide paths within > the rings. This mechanism is especially handy when > there is a need for path-segment recovery on per-ring > basis. Perhaps I'm reading too much into this as I note that you only talked about signalling and not routing. But if you want to accurately show the state of the ring (e.g. bandwidth), then you have to advertise each segment of the ring. I worked out a lot of the details quite a long time ago. Be glad to help out on the protocol part. ...George ======================================================================== George Swallow Cisco Systems (978) 936-1398 1414 Massachusetts Avenue Boxborough, MA 01719 --------------------------------- Yahoo! Music Unlimited - Access over 1 million songs. Try it free. --0-1809996778-1129378951=:76768 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit
Agree. Note that I was talking about signaling and *path computation*. The laterr cannot be performed without proper advertisings
 
Igor

George Swallow <swallow@cisco.com> wrote:
> One thing that I'd suggest adding to your draft is
> ability to compute and signal LSP paths in terms of
> rings rather than in terms of links, and let ring
> border LSRs to expend the paths - provide paths within
> the rings. This mechanism is especially handy when
> there is a need for path-segment recovery on per-ring
> basis.

Perhaps I'm reading too much into this as I note that you only talked
about signalling and not routing.

But if you want to accurately show the state of the ring (e.g.
bandwidth), then you have to advertise each segment of the ring.

I worked out a lot of the details quite a long time ago. Be glad to
help out on the protocol part.

...George

========================================================================
George Swallow Cisco Systems (978) 936-1398
1414 Massachusetts Avenue
Boxborough, MA 01719

Yahoo! Music Unlimited - Access over 1 million songs. Try it free. --0-1809996778-1129378951=:76768-- Envelope-to: ccamp-data@psg.com Delivery-date: Sat, 15 Oct 2005 00:34:43 +0000 Message-ID: <43504E1D.4030501@grotto-networking.com> Date: Fri, 14 Oct 2005 17:32:29 -0700 From: Greg Bernstein User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) MIME-Version: 1.0 To: George Swallow CC: Diego Caviglia , "Igor Bryskin , "julien.meuric" , ccamp Subject: Re: GMPLS for MS-SPRing Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit George, I believe that the LSPs discussed are indeed General LSPs, i.e., SDH VC-4, or MPLS LSP. Note that I'm all for lots of topology info about the rings via routing protocols. I'd like to see what links are involved with what rings, so if there is a ring switch on a particular ring we can see where we stand as far as what traffic maybe currently more vulnerable (e.g. if we get multiple faults on the same ring). One could also then see what the current ring "covering" on your network looks like. However, this draft is starting with basic requirements. Whether GMPLS can ever help us get around the lack of interoperability of MS-SPRing from multiple vendors may be a bit much to take on... Greg B. George Swallow wrote: >Diego - > >Is there anything that's General about this? All that I can think of >off the top of my head is MPLS specific. If this is the case, then the >draft belongs in MPLS. > >...George > >======================================================================== >George Swallow Cisco Systems (978) 936-1398 > 1414 Massachusetts Avenue > Boxborough, MA 01719 > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 14 Oct 2005 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-tc-mib-09.txt Message-Id: Date: Fri, 14 Oct 2005 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 : Definitions of Textual Conventions for Generalized Multiprotocol Label Switching (GMPLS) Management Author(s) : T. Nadeau, et al. Filename : draft-ietf-ccamp-gmpls-tc-mib-09.txt Pages : 9 Date : 2005-10-14 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-09.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-09.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-09.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: <2005-10-14151042.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-gmpls-tc-mib-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-gmpls-tc-mib-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-10-14151042.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 14 Oct 2005 19:51:28 +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-10.txt Message-Id: Date: Fri, 14 Oct 2005 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) Label Switching Router (LSR) Management Information Base Author(s) : T. Nadeau, et al. Filename : draft-ietf-ccamp-gmpls-lsr-mib-10.txt Pages : 43 Date : 2005-10-14 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-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-lsr-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-lsr-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: <2005-10-14150008.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-gmpls-lsr-mib-10.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-gmpls-lsr-mib-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-10-14150008.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 14 Oct 2005 19:51:20 +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-11.txt Message-Id: Date: Fri, 14 Oct 2005 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, et al. Filename : draft-ietf-ccamp-gmpls-te-mib-11.txt Pages : 61 Date : 2005-10-14 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-11.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-11.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-11.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: <2005-10-14150518.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-gmpls-te-mib-11.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-gmpls-te-mib-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-10-14150518.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 14 Oct 2005 19:06:20 +0000 Message-ID: <43500190.3050604@chello.nl> Date: Fri, 14 Oct 2005 21:05:52 +0200 From: Huub van Helvoort User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) MIME-Version: 1.0 To: ccamp Subject: Re: GMPLS for MS-SPRing Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hello Diego, You wrote: > Hi Igor, > I agree with you but the ID is only a requiremet ID, we tried to > avoid possible signalling and routing implementation that can satisfy the > requiremnts. I agree with you that adding more specific/implementation information will change the scope of theis I-D. Kind regards, Huub. == > If there is interest in the community about this topic we'll produce IDs to > satisfy the requiremets. > > Regards > > Diego > > > Igor Bryskin on 14/10/2005 16.39.55 > > To: Diego Caviglia , > julien.meuric@francetelecom.com > cc: ccamp@ops.ietf.org > > Subject: Re: GMPLS for MS-SPRing > > Hi Diego, > > One thing that I'd suggest adding to your draft is > ability to compute and signal LSP paths in terms of > rings rather than in terms of links, and let ring > border LSRs to expend the paths - provide paths within > the rings. This mechanism is especially handy when > there is a need for path-segment recovery on per-ring > basis. > > Igor > > --- Diego Caviglia wrote: > >>Hi Julien, >> is always a pleasure to discuss this >>topics with you. >> >>You are right and a clarification is definitely >>needed here. >>Basically Ring ID parameter is a common identifier >>for all the TE links >>belonging to the same ring. >> >>In such a way, in a no-control plane/pre-GMPLS >>scenario, from a management >>plane point of view it is possible to >>discern if a given node belongs to a given ring by >>checking its Ring ID. >> >>In an advanced scenario, where a control plane >>(GMPLS based) is in place >>"between" data and management plane, the Ring ID >>parameter keeps on >>doing the same function of making possible the >>association of a given TE >>link with the ring it belongs to. >> >>Why is this information needed at control plane >>level? Think of a routing >>protocol deployed over control plane, say GOSPF-TE. >>When we come at dealing >>with MSSPRING inherent requirements that control >>plane has to be compliant >>with, there are spring related informations that a >>routing protocol has to >>flood over the network (as opaque) to make possible >>correct operation. >>Among them there could be (depending on the strategy >>that'll be followed) >>the information about a TE link as belonging or not >>to a ring and, if yes, >>to which ring. In this case Ring ID serves the >>purpose. >>For a ingress node running Path Computation Engine >>it is important to know >>this attribute of a TE link to take special routing >>decisions or to try to >>satisfy given requirements involving MSSPRING >>traversing. >> >>In addition, ring ID information could be used if >>some information >>interests only the TNE's belonging to a given ring >>and has to be flooded >>only to the TNEs in that ring. In this case Ring ID >>could be used by a TNE >>belonging to a ring to check if its OSPF neighbor >>belongs tho the same ring >>and hence if a given LSA has to be sent to it or >>not. >> >>These are examples of possible usage of Ring ID >>within control plane. Apart >>from these specifc uses, there could be other cases >>to be defined where a >>similar identifier is needed. Of course it depends >>on which strategy is >>chosen to handle MSSPRING management and >>requirements from control plane. >> >>Hope this clarify. >> >>Best Regards >> >>Diego >> >> >>"MEURIC Julien RD-CORE-LAN" >>@ops.ietf.org >>on 14/10/2005 13.58.16 >> >>Sent by: owner-ccamp@ops.ietf.org >> >> >>To: "Diego Caviglia" >>cc: "ccamp" >> >>Subject: GMPLS for MS-SPRing >> >>Hello Diego. >> >>I have just read your >>draft-caviglia-ccamp-gmpls-msspring-req-00.txt about >>GMPLS requirements for MS-SPRing. I am glad to see >>you have again a >>pragmatic approach to ease operators' migration from >>legacy SDH to GMPLS. >> >>In paragraph "2.1 LSP Set-Up", you mention a >>"RingId" required by the >>management plane and useless for the data plane >>itself. I am not >>questionning this necessity (I am not a management >>expert), but I do not >>really understand why it should be handled by the >>control plane. I imagine >>this is related to communication between control and >>management, but a >>clarification may be required here. >> >>Thanks >> >>Julien -- ================================================================ http://members.chello.nl/hhelvoort/ ================================================================ Always remember that you are unique...just like everyone else... Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 14 Oct 2005 18:51:30 +0000 Cc: "Diego Caviglia" , "Igor Bryskin , "julien.meuric" , "ccamp" Cc: swallow@cisco.com Subject: Re: GMPLS for MS-SPRing From: George Swallow Date: Fri, 14 Oct 2005 14:51:05 -0400 Message-Id: <20051014185105.54F0615521A@swallow-mini-mac.local> Ignore my last post! Acronym dyslexia on my part. Looked at SPRing and thought I saw SRPring... ...George ======================================================================== George Swallow Cisco Systems (978) 936-1398 1414 Massachusetts Avenue Boxborough, MA 01719 Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 14 Oct 2005 18:38:57 +0000 To: "Diego Caviglia" Cc: "Igor Bryskin , "julien.meuric" , "ccamp" Cc: swallow@cisco.com Subject: Re: GMPLS for MS-SPRing From: George Swallow Date: Fri, 14 Oct 2005 14:38:39 -0400 Message-Id: <20051014183839.B6BC4154FBF@swallow-mini-mac.local> Diego - Is there anything that's General about this? All that I can think of off the top of my head is MPLS specific. If this is the case, then the draft belongs in MPLS. ...George ======================================================================== George Swallow Cisco Systems (978) 936-1398 1414 Massachusetts Avenue Boxborough, MA 01719 Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 14 Oct 2005 18:34:25 +0000 To: Igor Bryskin Cc: Diego Caviglia , julien.meuric@francetelecom.com, ccamp@ops.ietf.org Cc: swallow@cisco.com Subject: Re: GMPLS for MS-SPRing From: George Swallow Date: Fri, 14 Oct 2005 14:32:38 -0400 Message-Id: <20051014183238.53643154ECD@swallow-mini-mac.local> > One thing that I'd suggest adding to your draft is > ability to compute and signal LSP paths in terms of > rings rather than in terms of links, and let ring > border LSRs to expend the paths - provide paths within > the rings. This mechanism is especially handy when > there is a need for path-segment recovery on per-ring > basis. Perhaps I'm reading too much into this as I note that you only talked about signalling and not routing. But if you want to accurately show the state of the ring (e.g. bandwidth), then you have to advertise each segment of the ring. I worked out a lot of the details quite a long time ago. Be glad to help out on the protocol part. ...George ======================================================================== George Swallow Cisco Systems (978) 936-1398 1414 Massachusetts Avenue Boxborough, MA 01719 Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 14 Oct 2005 15:11:47 +0000 Message-ID: <004901c5d0d1$877cc310$6601a8c0@movaz.com> From: "Igor Bryskin" To: "Igor Bryskin , "Diego Caviglia" Cc: "julien.meuric" , "ccamp" Subject: Re: GMPLS for MS-SPRing Date: Fri, 14 Oct 2005 11:11:18 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sure, Would be happy to work on this together. Igor ----- Original Message ----- From: "Diego Caviglia" To: "Igor Bryskin Cc: "julien.meuric" ; "ccamp" Sent: Friday, October 14, 2005 10:46 AM Subject: Re: GMPLS for MS-SPRing > > Hi Igor, > I agree with you but the ID is only a requiremet ID, we tried to > avoid possible signalling and routing implementation that can satisfy the > requiremnts. > > If there is interest in the community about this topic we'll produce IDs to > satisfy the requiremets. > > Regards > > Diego > > > > Igor Bryskin on 14/10/2005 16.39.55 > > To: Diego Caviglia , > julien.meuric@francetelecom.com > cc: ccamp@ops.ietf.org > > Subject: Re: GMPLS for MS-SPRing > > Hi Diego, > > One thing that I'd suggest adding to your draft is > ability to compute and signal LSP paths in terms of > rings rather than in terms of links, and let ring > border LSRs to expend the paths - provide paths within > the rings. This mechanism is especially handy when > there is a need for path-segment recovery on per-ring > basis. > > Igor > > --- Diego Caviglia wrote: > > > > > Hi Julien, > > is always a pleasure to discuss this > > topics with you. > > > > You are right and a clarification is definitely > > needed here. > > Basically Ring ID parameter is a common identifier > > for all the TE links > > belonging to the same ring. > > > > In such a way, in a no-control plane/pre-GMPLS > > scenario, from a management > > plane point of view it is possible to > > discern if a given node belongs to a given ring by > > checking its Ring ID. > > > > In an advanced scenario, where a control plane > > (GMPLS based) is in place > > "between" data and management plane, the Ring ID > > parameter keeps on > > doing the same function of making possible the > > association of a given TE > > link with the ring it belongs to. > > > > Why is this information needed at control plane > > level? Think of a routing > > protocol deployed over control plane, say GOSPF-TE. > > When we come at dealing > > with MSSPRING inherent requirements that control > > plane has to be compliant > > with, there are spring related informations that a > > routing protocol has to > > flood over the network (as opaque) to make possible > > correct operation. > > Among them there could be (depending on the strategy > > that'll be followed) > > the information about a TE link as belonging or not > > to a ring and, if yes, > > to which ring. In this case Ring ID serves the > > purpose. > > For a ingress node running Path Computation Engine > > it is important to know > > this attribute of a TE link to take special routing > > decisions or to try to > > satisfy given requirements involving MSSPRING > > traversing. > > > > In addition, ring ID information could be used if > > some information > > interests only the TNE's belonging to a given ring > > and has to be flooded > > only to the TNEs in that ring. In this case Ring ID > > could be used by a TNE > > belonging to a ring to check if its OSPF neighbor > > belongs tho the same ring > > and hence if a given LSA has to be sent to it or > > not. > > > > These are examples of possible usage of Ring ID > > within control plane. Apart > > from these specifc uses, there could be other cases > > to be defined where a > > similar identifier is needed. Of course it depends > > on which strategy is > > chosen to handle MSSPRING management and > > requirements from control plane. > > > > Hope this clarify. > > > > Best Regards > > > > Diego > > > > > > > > > > "MEURIC Julien RD-CORE-LAN" > > @ops.ietf.org > > on 14/10/2005 13.58.16 > > > > Sent by: owner-ccamp@ops.ietf.org > > > > > > To: "Diego Caviglia" > > cc: "ccamp" > > > > Subject: GMPLS for MS-SPRing > > > > Hello Diego. > > > > I have just read your > > draft-caviglia-ccamp-gmpls-msspring-req-00.txt about > > GMPLS requirements for MS-SPRing. I am glad to see > > you have again a > > pragmatic approach to ease operators' migration from > > legacy SDH to GMPLS. > > > > In paragraph "2.1 LSP Set-Up", you mention a > > "RingId" required by the > > management plane and useless for the data plane > > itself. I am not > > questionning this necessity (I am not a management > > expert), but I do not > > really understand why it should be handled by the > > control plane. I imagine > > this is related to communication between control and > > management, but a > > clarification may be required here. > > > > Thanks > > > > Julien > > > > > > > > > > > > > > > > > > > > > > __________________________________ > Yahoo! Mail - PC Magazine Editors' Choice 2005 > http://mail.yahoo.com > > > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 14 Oct 2005 14:47:30 +0000 Sensitivity: Subject: Re: GMPLS for MS-SPRing To: "Igor Bryskin Cc: "julien.meuric" , "ccamp" Message-ID: From: "Diego Caviglia" Date: Fri, 14 Oct 2005 16:46:21 +0200 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Hi Igor, I agree with you but the ID is only a requiremet ID, we tried to avoid possible signalling and routing implementation that can satisfy the requiremnts. If there is interest in the community about this topic we'll produce IDs to satisfy the requiremets. Regards Diego Igor Bryskin on 14/10/2005 16.39.55 To: Diego Caviglia , julien.meuric@francetelecom.com cc: ccamp@ops.ietf.org Subject: Re: GMPLS for MS-SPRing Hi Diego, One thing that I'd suggest adding to your draft is ability to compute and signal LSP paths in terms of rings rather than in terms of links, and let ring border LSRs to expend the paths - provide paths within the rings. This mechanism is especially handy when there is a need for path-segment recovery on per-ring basis. Igor --- Diego Caviglia wrote: > > Hi Julien, > is always a pleasure to discuss this > topics with you. > > You are right and a clarification is definitely > needed here. > Basically Ring ID parameter is a common identifier > for all the TE links > belonging to the same ring. > > In such a way, in a no-control plane/pre-GMPLS > scenario, from a management > plane point of view it is possible to > discern if a given node belongs to a given ring by > checking its Ring ID. > > In an advanced scenario, where a control plane > (GMPLS based) is in place > "between" data and management plane, the Ring ID > parameter keeps on > doing the same function of making possible the > association of a given TE > link with the ring it belongs to. > > Why is this information needed at control plane > level? Think of a routing > protocol deployed over control plane, say GOSPF-TE. > When we come at dealing > with MSSPRING inherent requirements that control > plane has to be compliant > with, there are spring related informations that a > routing protocol has to > flood over the network (as opaque) to make possible > correct operation. > Among them there could be (depending on the strategy > that'll be followed) > the information about a TE link as belonging or not > to a ring and, if yes, > to which ring. In this case Ring ID serves the > purpose. > For a ingress node running Path Computation Engine > it is important to know > this attribute of a TE link to take special routing > decisions or to try to > satisfy given requirements involving MSSPRING > traversing. > > In addition, ring ID information could be used if > some information > interests only the TNE's belonging to a given ring > and has to be flooded > only to the TNEs in that ring. In this case Ring ID > could be used by a TNE > belonging to a ring to check if its OSPF neighbor > belongs tho the same ring > and hence if a given LSA has to be sent to it or > not. > > These are examples of possible usage of Ring ID > within control plane. Apart > from these specifc uses, there could be other cases > to be defined where a > similar identifier is needed. Of course it depends > on which strategy is > chosen to handle MSSPRING management and > requirements from control plane. > > Hope this clarify. > > Best Regards > > Diego > > > > > "MEURIC Julien RD-CORE-LAN" > @ops.ietf.org > on 14/10/2005 13.58.16 > > Sent by: owner-ccamp@ops.ietf.org > > > To: "Diego Caviglia" > cc: "ccamp" > > Subject: GMPLS for MS-SPRing > > Hello Diego. > > I have just read your > draft-caviglia-ccamp-gmpls-msspring-req-00.txt about > GMPLS requirements for MS-SPRing. I am glad to see > you have again a > pragmatic approach to ease operators' migration from > legacy SDH to GMPLS. > > In paragraph "2.1 LSP Set-Up", you mention a > "RingId" required by the > management plane and useless for the data plane > itself. I am not > questionning this necessity (I am not a management > expert), but I do not > really understand why it should be handled by the > control plane. I imagine > this is related to communication between control and > management, but a > clarification may be required here. > > Thanks > > Julien > > > > > > > > __________________________________ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 14 Oct 2005 14:40:28 +0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=faFV4eZJhp+YB5veoXYT+fj/FINoRmAvozVdQmSEtmVjATz2aCit4sA+iDuS4VAFRM7c0od5SBFMsoi9xuFhpclSkydXHJMK6c/YrX8yB5ihskUDSJddU4wgvkyD2AMRbTZHeQv/vli6Ly0uAaD59UJnR0x4/otxwInZBZEPRE8= ; Message-ID: <20051014143956.88356.qmail@web30808.mail.mud.yahoo.com> Date: Fri, 14 Oct 2005 07:39:55 -0700 (PDT) From: Igor Bryskin Subject: Re: GMPLS for MS-SPRing To: Diego Caviglia , julien.meuric@francetelecom.com Cc: ccamp@ops.ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hi Diego, One thing that I'd suggest adding to your draft is ability to compute and signal LSP paths in terms of rings rather than in terms of links, and let ring border LSRs to expend the paths - provide paths within the rings. This mechanism is especially handy when there is a need for path-segment recovery on per-ring basis. Igor --- Diego Caviglia wrote: > > Hi Julien, > is always a pleasure to discuss this > topics with you. > > You are right and a clarification is definitely > needed here. > Basically Ring ID parameter is a common identifier > for all the TE links > belonging to the same ring. > > In such a way, in a no-control plane/pre-GMPLS > scenario, from a management > plane point of view it is possible to > discern if a given node belongs to a given ring by > checking its Ring ID. > > In an advanced scenario, where a control plane > (GMPLS based) is in place > "between" data and management plane, the Ring ID > parameter keeps on > doing the same function of making possible the > association of a given TE > link with the ring it belongs to. > > Why is this information needed at control plane > level? Think of a routing > protocol deployed over control plane, say GOSPF-TE. > When we come at dealing > with MSSPRING inherent requirements that control > plane has to be compliant > with, there are spring related informations that a > routing protocol has to > flood over the network (as opaque) to make possible > correct operation. > Among them there could be (depending on the strategy > that'll be followed) > the information about a TE link as belonging or not > to a ring and, if yes, > to which ring. In this case Ring ID serves the > purpose. > For a ingress node running Path Computation Engine > it is important to know > this attribute of a TE link to take special routing > decisions or to try to > satisfy given requirements involving MSSPRING > traversing. > > In addition, ring ID information could be used if > some information > interests only the TNE's belonging to a given ring > and has to be flooded > only to the TNEs in that ring. In this case Ring ID > could be used by a TNE > belonging to a ring to check if its OSPF neighbor > belongs tho the same ring > and hence if a given LSA has to be sent to it or > not. > > These are examples of possible usage of Ring ID > within control plane. Apart > from these specifc uses, there could be other cases > to be defined where a > similar identifier is needed. Of course it depends > on which strategy is > chosen to handle MSSPRING management and > requirements from control plane. > > Hope this clarify. > > Best Regards > > Diego > > > > > "MEURIC Julien RD-CORE-LAN" > @ops.ietf.org > on 14/10/2005 13.58.16 > > Sent by: owner-ccamp@ops.ietf.org > > > To: "Diego Caviglia" > cc: "ccamp" > > Subject: GMPLS for MS-SPRing > > Hello Diego. > > I have just read your > draft-caviglia-ccamp-gmpls-msspring-req-00.txt about > GMPLS requirements for MS-SPRing. I am glad to see > you have again a > pragmatic approach to ease operators' migration from > legacy SDH to GMPLS. > > In paragraph "2.1 LSP Set-Up", you mention a > "RingId" required by the > management plane and useless for the data plane > itself. I am not > questionning this necessity (I am not a management > expert), but I do not > really understand why it should be handled by the > control plane. I imagine > this is related to communication between control and > management, but a > clarification may be required here. > > Thanks > > Julien > > > > > > > > __________________________________ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 14 Oct 2005 14:22:28 +0000 Sensitivity: Subject: Re: GMPLS for MS-SPRing To: julien.meuric@francetelecom.com Cc: ccamp@ops.ietf.org Message-ID: From: "Diego Caviglia" Date: Fri, 14 Oct 2005 16:21:34 +0200 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Hi Julien, is always a pleasure to discuss this topics with you. You are right and a clarification is definitely needed here. Basically Ring ID parameter is a common identifier for all the TE links belonging to the same ring. In such a way, in a no-control plane/pre-GMPLS scenario, from a management plane point of view it is possible to discern if a given node belongs to a given ring by checking its Ring ID. In an advanced scenario, where a control plane (GMPLS based) is in place "between" data and management plane, the Ring ID parameter keeps on doing the same function of making possible the association of a given TE link with the ring it belongs to. Why is this information needed at control plane level? Think of a routing protocol deployed over control plane, say GOSPF-TE. When we come at dealing with MSSPRING inherent requirements that control plane has to be compliant with, there are spring related informations that a routing protocol has to flood over the network (as opaque) to make possible correct operation. Among them there could be (depending on the strategy that'll be followed) the information about a TE link as belonging or not to a ring and, if yes, to which ring. In this case Ring ID serves the purpose. For a ingress node running Path Computation Engine it is important to know this attribute of a TE link to take special routing decisions or to try to satisfy given requirements involving MSSPRING traversing. In addition, ring ID information could be used if some information interests only the TNE's belonging to a given ring and has to be flooded only to the TNEs in that ring. In this case Ring ID could be used by a TNE belonging to a ring to check if its OSPF neighbor belongs tho the same ring and hence if a given LSA has to be sent to it or not. These are examples of possible usage of Ring ID within control plane. Apart from these specifc uses, there could be other cases to be defined where a similar identifier is needed. Of course it depends on which strategy is chosen to handle MSSPRING management and requirements from control plane. Hope this clarify. Best Regards Diego "MEURIC Julien RD-CORE-LAN" @ops.ietf.org on 14/10/2005 13.58.16 Sent by: owner-ccamp@ops.ietf.org To: "Diego Caviglia" cc: "ccamp" Subject: GMPLS for MS-SPRing Hello Diego. I have just read your draft-caviglia-ccamp-gmpls-msspring-req-00.txt about GMPLS requirements for MS-SPRing. I am glad to see you have again a pragmatic approach to ease operators' migration from legacy SDH to GMPLS. In paragraph "2.1 LSP Set-Up", you mention a "RingId" required by the management plane and useless for the data plane itself. I am not questionning this necessity (I am not a management expert), but I do not really understand why it should be handled by the control plane. I imagine this is related to communication between control and management, but a clarification may be required here. Thanks Julien Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 14 Oct 2005 13:46:28 +0000 Message-ID: <00ca01c5d0bd$01c7e100$0601a8c0@pc6> Reply-To: "Tom Petch" From: "Tom Petch" To: "Adrian Farrel" , Cc: "Thomas D. Nadeau" , "joan cucchiara" Subject: Re: IANA-GMPLS-TC-MIB was New versions of GMPLS MIBs Date: Fri, 14 Oct 2005 14:40:06 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Aaaah, now I see; I had not imagined that the values in the MIB registry would be different to those in the GMPLS registry (but I understand why they might). Since I have been confused, I suggest expanding that sentence to "However, the numerical values used in this textual convention are solely within the purview of IANA and, for a given enumeration, will not necessarily be the same as the value in the Switching Types sub-registry. This might arise if the values in the Switching Types sub-registry are unsuitable for use in SMIv2." I am fine with your other sentence below (with similar sentences for each TC). Tom Petch ----- Original Message ----- From: "Adrian Farrel" To: "Tom Petch" ; Cc: "Thomas D. Nadeau" Sent: Friday, October 14, 2005 2:54 AM Subject: Re: IANA-GMPLS-TC-MIB was New versions of GMPLS MIBs Hi Tom, OK, I think I understand your concerns better now. Would your issue be solved by the inclusion of a statement like... Values of IANAGmplsSwitchingType are reserved for switching types that correspond to entries in the Switching Types sub-registry of the GMPLS Signaling Parameters registry managed by IANA. Since that registry is controlled by allocation policies already agreed by IETF consensus, this text would ensure that new allocations within the textual convention would be equally controlled. I want to retain the "However, the actual values..." text because I do not want to force the values used in the textual conventions to match the values used in the protocol elements. For example, if the relevant working group decided to assign widely discontiguous values for a protocol field, I would not want to force the IANA to use those identical values in the textual convention. It would be adequate that they assigned values that corresponded but were not equal. A concrete example is provided by IANAGmplsSwitchingType. This takes values to correspond to the GMPLS switching types, but these have values in the IANA registry of 1, 2, 3, 4, 51, 100, 150, 200. The IANA may consider that it is inappropriate to assign enumerations in a TC that are discontiguous, and could assign values 0 through 8 rather than those suggested in the draft. You are correct that the text in section 11.2 is broken and should point to the description clauses of the individual TCs. Thanks for catching this. Question: does all this address your concerns? Note: We have just submitted new revisions of the MIB modules to fix compilation issues, and those revisions do not attempt to address this issue. Cheers, Adrian > I am still uncomfortable with the apparent lack of constraints for the > allocation of new values in IANA-GMPLS-TC-MIB. There is now > > "The rules for additions or changes to the IANA-GMPLS-TC-MIB are > outlined in the DESCRIPTION clause associated with its > MODULE-IDENTITY statement." > > but I do not see anything about this in the DESCRIPTION clause. Rather, it is > the DESCRIPTION clauses of individual TCs that contain the information, e.g. > > "This textual convention is strongly tied to the Switching > Types sub-registry of the GMPLS Signaling Parameters > registry managed by IANA. Values should be assigned by IANA > in step with the Switching Types sub-registry and using the > same registry management rules. However, the actual values > used in this textual convention are solely within the > purview of IANA and do not necessarily match the values in > the values in the Switching Types sub-registry. > > Requests for new values should be made to IANA via > email (iana@isi.edu)." > . > It is that "However ..." that bugs me; coupled with the final sentence, I still > see an e-mail from anyone in any SDO or elsewhere causing IANA to allocate a new > value regardless of on-going work in the IETF. Perhaps unlikely given the > close-knit world of GMPLS but I would still like to see tighter control, Expert > Review would be my choice. > > But I am also unclear what change control was intended by the wording in the > latest draft. > > As with my my earlier e-mail, > > "Somewhat bigger issue; I am concerned that no constraint is placed on the > allocation by IANA of new values in the IANA MIB module, where the base > documents call for more stringent action (although there is some disagreement as > to what that is). As it stands, it seems to me that anyone in the world can > e-mail IANA and get a new value assigned in the IANA MIB module, whereas I think > it should be the appearance of an RFC, eg draft-ietf-ccamp-gmpls-routing or > draft-ietf-ccamp-ospf-gmpls-extensions, which triggers that action, perhaps by > Expert Review ie the existence of a new name/number mapping is documented in an > RFC or I-D and Expert Review allows that mapping to be added to IANA MIB module. > We could require the RFC that introduces a new mapping to have an IANA section > that updates the MIB module but I fear that most editors would forget to include > it, so Expert Review seems best. > > > Tom Petch > > ----- Original Message ----- > From: "Adrian Farrel" > To: > Cc: "Thomas D. Nadeau" > Sent: Wednesday, October 12, 2005 10:41 PM > Subject: New versions of GMPLS MIBs > > > > Hi, > > > > We have been working on the GMPLS MIBs after MIB Doctor comments. > > The revisions just being posted have addressed all of the nits and > > editorial issues except: > > > > - conformance/compliance > > - lint > > - compilation > > > > Tom has just been working on these issues and the ball is now back with me > > to integrate his changes and republish. I hope to do this in the next > > couple of days. > > > > In the mean time, if you have any comments on the revised versions then > > please let us know. > > > > Cheers, > > Adrian > > > > > > ----- Original Message ----- > > From: > > To: > > Cc: > > Sent: Wednesday, October 12, 2005 8:50 PM > > Subject: I-D ACTION:draft-ietf-ccamp-gmpls-te-mib-10.txt > > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > > This draft is a work item of the Common Control and Measurement Plane > > Working Group of the IETF. > > > > > > Title : Generalized Multiprotocol Label Switching > > > (GMPLS) Traffic Engineering Management > > Information Base > > > Author(s) : T. Nadeau, et al. > > > Filename : draft-ietf-ccamp-gmpls-te-mib-10.txt > > > Pages : 61 > > > Date : 2005-10-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-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-te-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-te-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. > > > > > > > > > -------------------------------------------------------------------------- > > ------ > > > > > > > _______________________________________________ > > > I-D-Announce mailing list > > > I-D-Announce@ietf.org > > > https://www1.ietf.org/mailman/listinfo/i-d-announce > > > > > > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 14 Oct 2005 11:59:43 +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: GMPLS for MS-SPRing Date: Fri, 14 Oct 2005 13:58:16 +0200 Message-ID: <7DBAFEC6A76F3E42817DF1EBE64CB02602A447CA@FTRDMEL2.rd.francetelecom.fr> Thread-Topic: GMPLS for MS-SPRing Thread-Index: AcXQsqQJgLCOmC2uRmSRf3ODA27bdAAAwSJw From: "MEURIC Julien RD-CORE-LAN" To: "Diego Caviglia" Cc: "ccamp" Hello Diego. I have just read your draft-caviglia-ccamp-gmpls-msspring-req-00.txt = about GMPLS requirements for MS-SPRing. I am glad to see you have again = a pragmatic approach to ease operators' migration from legacy SDH to = GMPLS. In paragraph "2.1 LSP Set-Up", you mention a "RingId" required by the = management plane and useless for the data plane itself. I am not = questionning this necessity (I am not a management expert), but I do not = really understand why it should be handled by the control plane. I = imagine this is related to communication between control and management, = but a clarification may be required here. Thanks Julien Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 14 Oct 2005 07:10:10 +0000 Message-ID: <027801c5d059$e5117340$230ca8c0@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Tom Petch" , Cc: "Thomas D. Nadeau" Subject: Re: IANA-GMPLS-TC-MIB was New versions of GMPLS MIBs Date: Fri, 14 Oct 2005 01:54:47 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0275_01C5D062.41B090B0" This is a multi-part message in MIME format. ------=_NextPart_000_0275_01C5D062.41B090B0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Tom, OK, I think I understand your concerns better now. Would your issue be solved by the inclusion of a statement like... Values of IANAGmplsSwitchingType are reserved for switching types that correspond to entries in the=20 Switching Types sub-registry of the GMPLS Signaling Parameters registry managed by IANA. Since that registry is controlled by allocation policies already agreed = by IETF consensus, this text would ensure that new allocations within = the textual convention would be equally controlled. I want to retain the "However, the actual values..." text because I do = not want to force the values used in the textual conventions to match = the values used in the protocol elements. For example, if the relevant = working group decided to assign widely discontiguous values for a = protocol field, I would not want to force the IANA to use those = identical values in the textual convention. It would be adequate that = they assigned values that corresponded but were not equal. A concrete example is provided by IANAGmplsSwitchingType. This takes = values to correspond to the GMPLS switching types, but these have values = in the IANA registry of 1, 2, 3, 4, 51, 100, 150, 200. The IANA may = consider that it is inappropriate to assign enumerations in a TC that = are discontiguous, and could assign values 0 through 8 rather than those = suggested in the draft. You are correct that the text in section 11.2 is broken and should point = to the description clauses of the individual TCs. Thanks for catching = this. Question: does all this address your concerns? Note: We have just submitted new revisions of the MIB modules to fix = compilation issues, and those revisions do not attempt to address this = issue. Cheers, Adrian > I am still uncomfortable with the apparent lack of constraints for the > allocation of new values in IANA-GMPLS-TC-MIB. There is now >=20 > "The rules for additions or changes to the IANA-GMPLS-TC-MIB are > outlined in the DESCRIPTION clause associated with its > MODULE-IDENTITY statement." >=20 > but I do not see anything about this in the DESCRIPTION clause. = Rather, it is > the DESCRIPTION clauses of individual TCs that contain the = information, e.g. >=20 > "This textual convention is strongly tied to the Switching > Types sub-registry of the GMPLS Signaling Parameters > registry managed by IANA. Values should be assigned by = IANA > in step with the Switching Types sub-registry and using = the > same registry management rules. However, the actual = values > used in this textual convention are solely within the > purview of IANA and do not necessarily match the values = in > the values in the Switching Types sub-registry. > > Requests for new values should be made to IANA via > email (iana@isi.edu)." > . > It is that "However ..." that bugs me; coupled with the final = sentence, I still > see an e-mail from anyone in any SDO or elsewhere causing IANA to = allocate a new > value regardless of on-going work in the IETF. Perhaps unlikely given = the > close-knit world of GMPLS but I would still like to see tighter = control, Expert > Review would be my choice. >=20 > But I am also unclear what change control was intended by the wording = in the > latest draft. >=20 > As with my my earlier e-mail, >=20 > "Somewhat bigger issue; I am concerned that no constraint is placed on = the > allocation by IANA of new values in the IANA MIB module, where the = base > documents call for more stringent action (although there is some = disagreement as > to what that is). As it stands, it seems to me that anyone in the = world can > e-mail IANA and get a new value assigned in the IANA MIB module, = whereas I think > it should be the appearance of an RFC, eg = draft-ietf-ccamp-gmpls-routing or > draft-ietf-ccamp-ospf-gmpls-extensions, which triggers that action, = perhaps by > Expert Review ie the existence of a new name/number mapping is = documented in an > RFC or I-D and Expert Review allows that mapping to be added to IANA = MIB module. > We could require the RFC that introduces a new mapping to have an IANA = section > that updates the MIB module but I fear that most editors would forget = to include > it, so Expert Review seems best. >=20 >=20 > Tom Petch >=20 > ----- Original Message ----- > From: "Adrian Farrel" > To: > Cc: "Thomas D. Nadeau" > Sent: Wednesday, October 12, 2005 10:41 PM > Subject: New versions of GMPLS MIBs >=20 >=20 > > Hi, > > > > We have been working on the GMPLS MIBs after MIB Doctor comments. > > The revisions just being posted have addressed all of the nits and > > editorial issues except: > > > > - conformance/compliance > > - lint > > - compilation > > > > Tom has just been working on these issues and the ball is now back = with me > > to integrate his changes and republish. I hope to do this in the = next > > couple of days. > > > > In the mean time, if you have any comments on the revised versions = then > > please let us know. > > > > Cheers, > > Adrian > > > > > > ----- Original Message ----- > > From: > > To: > > Cc: > > Sent: Wednesday, October 12, 2005 8:50 PM > > Subject: I-D ACTION:draft-ietf-ccamp-gmpls-te-mib-10.txt > > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > > This draft is a work item of the Common Control and Measurement = Plane > > Working Group of the IETF. > > > > > > Title : Generalized Multiprotocol Label Switching > > > (GMPLS) Traffic Engineering Management > > Information Base > > > Author(s) : T. Nadeau, et al. > > > Filename : draft-ietf-ccamp-gmpls-te-mib-10.txt > > > Pages : 61 > > > Date : 2005-10-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-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-te-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-te-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. > > > > > > > > > = -------------------------------------------------------------------------= - > > ------ > > > > > > > _______________________________________________ > > > I-D-Announce mailing list > > > I-D-Announce@ietf.org > > > https://www1.ietf.org/mailman/listinfo/i-d-announce > > > > > > > >=20 >=20 > ------=_NextPart_000_0275_01C5D062.41B090B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Tom,
 
OK, I think I understand your = concerns better=20 now.
 
Would your issue be solved by the = inclusion of a=20 statement like...
 
        =20 Values of IANAGmplsSwitchingType are reserved for
       =20  switching types that correspond to entries in the =
        =20 Switching Types sub-registry of the GMPLS Signaling
       =20  Parameters registry managed by IANA.
 
Since that registry is controlled by = allocation=20 policies already agreed by IETF consensus, this text would ensure that = new=20 allocations within the textual convention would be equally=20 controlled.
 
I want to retain the "However, the = actual=20 values..." text because I do not want to force the values used in the = textual=20 conventions to match the values used in the protocol elements. For = example, if=20 the relevant working group decided to assign widely discontiguous values = for a=20 protocol field, I would not want to force the IANA to use those = identical values=20 in the textual convention. It would be adequate that they assigned = values that=20 corresponded but were not equal.
 
A concrete example is provided by=20 IANAGmplsSwitchingType. This takes values to correspond to the GMPLS = switching=20 types, but these have values in the IANA registry of 1, 2, 3, 4, = 51, 100,=20 150, 200. The IANA may consider that it is inappropriate to assign = enumerations=20 in a TC that are discontiguous, and could assign values 0 through 8 = rather than=20 those suggested in the draft.
 
You are correct that the text in = section 11.2 is=20 broken and should point to the description clauses of the individual = TCs. Thanks=20 for catching this.
 
 
Question: does all this address your=20 concerns?
 
Note: We have just submitted new = revisions of the=20 MIB modules to fix compilation issues, and those revisions do not = attempt to=20 address this issue.
 
 
Cheers,
Adrian
 
 
>=20 I am still uncomfortable with the apparent lack of constraints for = the
>=20 allocation of new values in IANA-GMPLS-TC-MIB.  There is = now
>=20
> "The rules for additions or changes to the IANA-GMPLS-TC-MIB=20 are
>    outlined in the DESCRIPTION clause associated = with=20 its
>    MODULE-IDENTITY statement."
>
> = but I do=20 not see anything about this in the DESCRIPTION clause.  Rather, it=20 is
> the DESCRIPTION clauses of individual TCs that contain the=20 information, e.g.
>
> "This textual convention is strongly = tied to=20 the Switching
>=20              = Types=20 sub-registry of the GMPLS Signaling Parameters
>=20              = registry managed by IANA. Values should be assigned by IANA
>=20              = in step=20 with the Switching Types sub-registry and using the
>=20              = same=20 registry management rules. However, the actual values
>=20              = used in=20 this textual convention are solely within the
>=20              = purview=20 of IANA and do not necessarily match the values in
>=20              = the=20 values in the Switching Types sub-registry.
> <snip>
> =              = Requests for new values should be made to IANA via
>=20              = email=20 (iana@isi.edu)."
> .
> It=20 is that "However ..." that bugs me; coupled with the final sentence, I=20 still
> see an e-mail from anyone in any SDO or elsewhere causing = IANA to=20 allocate a new
> value regardless of on-going work in the = IETF. =20 Perhaps unlikely given the
> close-knit world of GMPLS but I would = still=20 like to see tighter control, Expert
> Review would be my = choice.
>=20
> But I am also unclear what change control was intended by the = wording=20 in the
> latest draft.
>
> As with my my earlier=20 e-mail,
>
> "Somewhat bigger issue; I am concerned that no=20 constraint is placed on the
> allocation by IANA of new values in = the IANA=20 MIB module, where the base
> documents call for more stringent = action=20 (although there is some disagreement as
> to what that is).  = As it=20 stands, it seems to me that anyone in the world can
> e-mail IANA = and get=20 a new value assigned in the IANA MIB module, whereas I think
> it = should=20 be the appearance of an RFC, eg draft-ietf-ccamp-gmpls-routing = or
>=20 draft-ietf-ccamp-ospf-gmpls-extensions, which triggers that action, = perhaps=20 by
> Expert Review ie the existence of a new name/number mapping = is=20 documented in an
> RFC or I-D and Expert Review allows that = mapping to be=20 added to IANA MIB module.
> We could require the RFC that = introduces a new=20 mapping to have an IANA section
> that updates the MIB module but = I fear=20 that most editors would forget to include
> it, so Expert Review = seems=20 best.
>
>
> Tom Petch
>
> ----- = Original=20 Message -----
> From: "Adrian Farrel" <adrian@olddog.co.uk>
> To:=20 <ccamp@ops.ietf.org>
> Cc:=20 "Thomas D. Nadeau" <tnadeau@cisco.com>
> Sent: Wednesday, October 12, 2005 10:41 PM
> = Subject:=20 New versions of GMPLS MIBs
>
>
> > Hi,
>=20 >
> > We have been working on the GMPLS MIBs after MIB = Doctor=20 comments.
> > The revisions just being posted have addressed = all of the=20 nits and
> > editorial issues except:
> >
> > = -=20 conformance/compliance
> > - lint
> > - = compilation
>=20 >
> > Tom has just been working on these issues and the ball = is now=20 back with me
> > to integrate his changes and republish. I hope = to do=20 this in the next
> > couple of days.
> >
> > = In the=20 mean time, if you have any comments on the revised versions then
> = >=20 please let us know.
> >
> > Cheers,
> >=20 Adrian
> >
> >
> > ----- Original Message=20 -----
> > From: <Internet-Drafts@ietf.org>
>=20 > To: <i-d-announce@ietf.org>
>=20 > Cc: <ccamp@ops.ietf.org>
> >=20 Sent: Wednesday, October 12, 2005 8:50 PM
> > Subject: I-D=20 ACTION:draft-ietf-ccamp-gmpls-te-mib-10.txt
> >
> = >
>=20 > > A New Internet-Draft is available from the on-line=20 Internet-Drafts
> > directories.
> > > This draft = is a work=20 item of the Common Control and Measurement Plane
> > Working = Group of=20 the IETF.
> > >
> > > Title : Generalized = Multiprotocol=20 Label Switching
> >=20 >           &nb= sp;           &nbs= p;  =20 (GMPLS) Traffic Engineering Management
> > Information = Base
>=20 > > Author(s) : T. Nadeau, et al.
> > > Filename :=20 draft-ietf-ccamp-gmpls-te-mib-10.txt
> > > Pages : = 61
> >=20 > Date : 2005-10-12
> > >
> > > This memo = defines a=20 portion of the Management Information Base (MIB)
> >=20 >    for use with network management protocols in the = Internet=20 community.
> > >    In particular, it = describes=20 managed objects for Generalized
> > >   =20 Multiprotocol Label Switching (GMPLS) based traffic engineering.
> = >=20 >
> > > A URL for this Internet-Draft is:
> > = >=20 http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-te-mi= b-10.txt
> > >
> > > To remove = yourself from the=20 I-D Announcement list, send a message to
> > > i-d-announce-request@ietf.org with=20 the word unsubscribe in the body of
> > the message.
> = > >=20 You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce> > > to change your subscription = settings.
>=20 > >
> > >
> > > Internet-Drafts are also = available=20 by anonymous FTP. Login with the
> > username
> > > = "anonymous" and a password of your e-mail address. After logging = in,
>=20 > > type "cd internet-drafts" and then
> > > "get=20 draft-ietf-ccamp-gmpls-te-mib-10.txt".
> > >
> > = > A=20 list of Internet-Drafts directories can be found in
> > > = http://www.ietf.org/shadow.html
> > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> > >
> > >
> > = >=20 Internet-Drafts can also be obtained by e-mail.
> > = >
> >=20 > Send a message to:
> > > mailserv@ietf.org.
> > >=20 In the body type:
> > > "FILE=20 /internet-drafts/draft-ietf-ccamp-gmpls-te-mib-10.txt".
> >=20 >
> > > NOTE: The mail server at ietf.org can return the = document=20 in
> > > MIME-encoded form by using the "mpack" = utility.  To=20 use this
> > > feature, insert the command "ENCODING mime" = before=20 the "FILE"
> > > command.  To decode the response(s), = you will=20 need "munpack" or
> > > a MIME-compliant mail reader. =20 Different MIME-compliant mail readers
> > > exhibit = different=20 behavior, especially when dealing with
> > > "multipart" = MIME=20 messages (i.e. documents which have been split
> > > up into = multiple messages), so check your local documentation on
> > = > how=20 to manipulate these messages.
> > >
> > = >
> >=20 > Below is the data which will enable a MIME compliant mail = reader
>=20 > > implementation to automatically retrieve the ASCII version of=20 the
> > > Internet-Draft.
> > >
> = >
>=20 >
> >=20 -------------------------------------------------------------------------= -
>=20 > ------
> >
> >
> > >=20 _______________________________________________
> > > = I-D-Announce=20 mailing list
> > > I-D-Announce@ietf.org
> >=20 > https://www1.ietf.org/mailman/listinfo/i-d-announce> > >
> >
> >
> =
>=20
> ------=_NextPart_000_0275_01C5D062.41B090B0-- Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 13 Oct 2005 20:43:05 +0000 Message-ID: <067a01c5d02e$24fc1360$0601a8c0@pc6> Reply-To: "Tom Petch" From: "Tom Petch" To: "Adrian Farrel" , Cc: "Thomas D. Nadeau" Subject: IANA-GMPLS-TC-MIB was New versions of GMPLS MIBs Date: Thu, 13 Oct 2005 17:50:51 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Adrian I am still uncomfortable with the apparent lack of constraints for the allocation of new values in IANA-GMPLS-TC-MIB. There is now "The rules for additions or changes to the IANA-GMPLS-TC-MIB are outlined in the DESCRIPTION clause associated with its MODULE-IDENTITY statement." but I do not see anything about this in the DESCRIPTION clause. Rather, it is the DESCRIPTION clauses of individual TCs that contain the information, e.g. "This textual convention is strongly tied to the Switching Types sub-registry of the GMPLS Signaling Parameters registry managed by IANA. Values should be assigned by IANA in step with the Switching Types sub-registry and using the same registry management rules. However, the actual values used in this textual convention are solely within the purview of IANA and do not necessarily match the values in the values in the Switching Types sub-registry. Requests for new values should be made to IANA via email (iana@isi.edu)." . It is that "However ..." that bugs me; coupled with the final sentence, I still see an e-mail from anyone in any SDO or elsewhere causing IANA to allocate a new value regardless of on-going work in the IETF. Perhaps unlikely given the close-knit world of GMPLS but I would still like to see tighter control, Expert Review would be my choice. But I am also unclear what change control was intended by the wording in the latest draft. As with my my earlier e-mail, "Somewhat bigger issue; I am concerned that no constraint is placed on the allocation by IANA of new values in the IANA MIB module, where the base documents call for more stringent action (although there is some disagreement as to what that is). As it stands, it seems to me that anyone in the world can e-mail IANA and get a new value assigned in the IANA MIB module, whereas I think it should be the appearance of an RFC, eg draft-ietf-ccamp-gmpls-routing or draft-ietf-ccamp-ospf-gmpls-extensions, which triggers that action, perhaps by Expert Review ie the existence of a new name/number mapping is documented in an RFC or I-D and Expert Review allows that mapping to be added to IANA MIB module. We could require the RFC that introduces a new mapping to have an IANA section that updates the MIB module but I fear that most editors would forget to include it, so Expert Review seems best. Tom Petch ----- Original Message ----- From: "Adrian Farrel" To: Cc: "Thomas D. Nadeau" Sent: Wednesday, October 12, 2005 10:41 PM Subject: New versions of GMPLS MIBs > Hi, > > We have been working on the GMPLS MIBs after MIB Doctor comments. > The revisions just being posted have addressed all of the nits and > editorial issues except: > > - conformance/compliance > - lint > - compilation > > Tom has just been working on these issues and the ball is now back with me > to integrate his changes and republish. I hope to do this in the next > couple of days. > > In the mean time, if you have any comments on the revised versions then > please let us know. > > Cheers, > Adrian > > > ----- Original Message ----- > From: > To: > Cc: > Sent: Wednesday, October 12, 2005 8:50 PM > Subject: I-D ACTION:draft-ietf-ccamp-gmpls-te-mib-10.txt > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > This draft is a work item of the Common Control and Measurement Plane > Working Group of the IETF. > > > > Title : Generalized Multiprotocol Label Switching > > (GMPLS) Traffic Engineering Management > Information Base > > Author(s) : T. Nadeau, et al. > > Filename : draft-ietf-ccamp-gmpls-te-mib-10.txt > > Pages : 61 > > Date : 2005-10-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-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-te-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-te-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. > > > > > -------------------------------------------------------------------------- > ------ > > > > _______________________________________________ > > I-D-Announce mailing list > > I-D-Announce@ietf.org > > https://www1.ietf.org/mailman/listinfo/i-d-announce > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 13 Oct 2005 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-lsr-mib-09.txt Message-Id: Date: Thu, 13 Oct 2005 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, et al. Filename : draft-ietf-ccamp-gmpls-lsr-mib-09.txt Pages : 43 Date : 2005-10-13 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-09.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-09.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-09.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: <2005-10-13144205.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-gmpls-lsr-mib-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-gmpls-lsr-mib-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-10-13144205.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 13 Oct 2005 19:51:59 +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-08.txt Message-Id: Date: Thu, 13 Oct 2005 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, et al. Filename : draft-ietf-ccamp-gmpls-tc-mib-08.txt Pages : 9 Date : 2005-10-13 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-08.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-08.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-08.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: <2005-10-13142503.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-gmpls-tc-mib-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-gmpls-tc-mib-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-10-13142503.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 13 Oct 2005 02:06:34 +0000 Message-ID: <434DC106.1040906@grotto-networking.com> Date: Wed, 12 Oct 2005 19:05:58 -0700 From: Greg Bernstein User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) MIME-Version: 1.0 To: ccamp@ops.ietf.org Subject: VCAT/LCAS draft update: draft-bernstein-ccamp-gmpls-vcat-lcas-01 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Folks the latest, significantly shortened version of the VCAT/LCAS GMPLS draft is now available at: http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-gmpls-vcat-lcas-01.txt This draft points out how GMPLS and VCAT/LCAS get along and how they might play nicer together. We'll be proposing something along these lines getting adopted as a workgroup item at the Vancouver meeting. Regards Greg B. --------------------- Dr. Greg Bernstein, Grotto Networking Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 13 Oct 2005 01:35:54 +0000 Message-ID: <434DB995.5090301@us.fujitsu.com> Date: Wed, 12 Oct 2005 18:34:13 -0700 From: Richard Rabbat Organization: Fujitsu Labs of America User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) MIME-Version: 1.0 To: ccamp@ops.ietf.org CC: "Shiba, Sidney" , Richard Rabbat Subject: draft announcement: draft-shiba-ccamp-gmpls-lambda-labels-00.txt Content-Type: multipart/mixed; boundary="------------030704080901000402020100" This is a multi-part message in MIME format. --------------030704080901000402020100 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear all, we have submitted the following draft for consideration by the CCAMP WG. http://www.ietf.org/internet-drafts/draft-shiba-ccamp-gmpls-lambda-labels-00.txt Subject: I-D ACTION:draft-shiba-ccamp-gmpls-lambda-labels-00.txt Date: 2005-10-07 19:50:02 GMT (5 days, 1 hour and 21 minutes ago) A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Generalized Labels of Lambda-Switching Capable Label Switching Routers (LSR)s Author(s) : S. Shiba, R. Rabbat Filename : draft-shiba-ccamp-gmpls-lambda-labels-00.txt Pages : 10 Date : 2005-10-7 Technology in the optical domain is constantly evolving and as a consequence equipment providing true lambda switching capability has been developed and is currently being deployed. [RFC3471] has defined that a wavelength label (section 3.2.1.1) "only has significance between two neighbors". However, in a network composed of "true" lambda switch capable equipments, the label should have global meaning similarly to the label defined for SONET/SDH technology (SUKLM format defined in [RFC3946]). This document is a companion to the Generalized Multi-Protocol Label Switching (GMPLS) signaling. It defines the Label Switching Capable (LSC) technology specific information needed when using GMPLS. -- We look forward to feedback from ccamp members. Specifically, is the problem statement well posed? Is this a topic that CCAMP would like to address? Richard & Sidney. --------------030704080901000402020100 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 Labs of America;IP Networking Research 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 --------------030704080901000402020100-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 12 Oct 2005 20:39:28 +0000 Message-ID: <2d5c01c5cf6d$601f0e00$f2849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Cc: "Thomas D. Nadeau" Subject: New versions of GMPLS MIBs Date: Wed, 12 Oct 2005 21:41:46 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi, We have been working on the GMPLS MIBs after MIB Doctor comments. The revisions just being posted have addressed all of the nits and editorial issues except: - conformance/compliance - lint - compilation Tom has just been working on these issues and the ball is now back with me to integrate his changes and republish. I hope to do this in the next couple of days. In the mean time, if you have any comments on the revised versions then please let us know. Cheers, Adrian ----- Original Message ----- From: To: Cc: Sent: Wednesday, October 12, 2005 8:50 PM Subject: I-D ACTION:draft-ietf-ccamp-gmpls-te-mib-10.txt > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. > > Title : Generalized Multiprotocol Label Switching > (GMPLS) Traffic Engineering Management Information Base > Author(s) : T. Nadeau, et al. > Filename : draft-ietf-ccamp-gmpls-te-mib-10.txt > Pages : 61 > Date : 2005-10-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-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-te-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-te-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. > -------------------------------------------------------------------------- ------ > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/i-d-announce > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 12 Oct 2005 20:27:35 +0000 Message-ID: <2d3501c5cf6a$f7c987b0$f2849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Agenda slot requests for Vancouver Date: Wed, 12 Oct 2005 20:09:22 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi, I know I am going to regret this, but... Please send me your requests to go on the agenda in Vancouver. Given the positive and encouraging feedback that our AD gave us in Paris, I would like to try to limit our work to issues and items that will benefit from face to face discussion. Thus, presentation of status (this is the 37th revision of our I-D, we hope to be finished in early 2012, we have made 209 small and insignificant typographical changes) will be frowned upon. Similarly, presentation of the content of I-Ds will not be welcome except where this is a new I-D and the content is interesting ;-) What I would really like is: - problem statements and requests for discussion of solutions - suggested solutions where the authors are not sure and want feedback In other words, I would like presenters to be actively soliciting input from the meeting. If you don't need input from the meeting, then you don't need to stand up at the front of the room. Anyway, over to you guys. Thanks, Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 12 Oct 2005 19:51:45 +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-10.txt Message-Id: Date: Wed, 12 Oct 2005 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, et al. Filename : draft-ietf-ccamp-gmpls-te-mib-10.txt Pages : 61 Date : 2005-10-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-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-te-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-te-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: <2005-10-12121307.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-gmpls-te-mib-10.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-gmpls-te-mib-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-10-12121307.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 11 Oct 2005 19:46:47 +0000 Message-ID: <295c01c5ce9c$d0ac9b00$f2849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Cc: "Lou Berger" , "Dimitri Papadimitriou" , "Dimitri Papadimitriou" , "Anca Zamfir" , "Reshad Rahman" , "Junaid Israr" , "Arun Satyanarayana \(asatyana\)" , "Kireeti Kompella" Subject: Further Working Group last call: draft-ietf-ccamp-rsvp-restart-ext-04.txt Date: Tue, 11 Oct 2005 20:48:44 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Thanks for the note Arun, It looks to me that while most of these changes are editorial, the change to 4.5.2 is substantive. Therefore we will have a further short WG last call. The last call will complete on Wednesday 19th October at 12 noon GMT. Send your comments to the list please. Thanks, Adrian ----- Original Message ----- From: "Arun Satyanarayana" To: "Adrian Farrel" ; "Kireeti Kompella" Cc: ; "Lou Berger" ; "Dimitri Papadimitriou" ; "Dimitri Papadimitriou" ; "Anca Zamfir" ; "Reshad Rahman" ; "Junaid Israr" ; "Arun Satyanarayana (asatyana)" Sent: Tuesday, October 11, 2005 8:09 PM Subject: Re: I-D ACTION:draft-ietf-ccamp-rsvp-restart-ext-04.txt > Hi Adrian, Kireeti, > > Following are the mods to version -03, based on last call comments. Can > we go through another short last call on this rev please? > > - Section 2 Terminology: > Fix bad text > < The reader is assumed to be familiar with the terminology defined in > < xref target="RFC3209" /> and [RFC3473]. > > The reader is assumed to be familiar with the terminology defined in > > [RFC3209] and [RFC3473]. > > - Section 4.2 Capability Object: > Reverse ordering of definitions of T and R bits to match ordering in > object > > - Full I-D: > Change "Restart_Caps" to "Restart_Cap" (to match definition in 3473). > > - Section 4.4.1 Procedures for the Downstream Neighbor > Clarify text: the downstream neighbor must send the T-bit in all > Hellos > < If the downstream RSVP neighbor of a restarting node is capable of > < sending RecoveryPath messages to the restarting node, it MUST > include > < the Capability object with the RecoveryPath Transmit Enabled (T) bit > < set (1) in all its Hello messages sent to the restarting node. > > If a node is capable of sending RecoveryPath messages, it MUST > > include the Capability object with the RecoveryPath Transmit Enabled > > (T) bit set (1) in all its Hello messages. > > - Section 4.4.2 Procedures for the Restarting Node > Clarify text: the restarting node must send the R-bit in all Hellos > < A restarting node that expects to recover RSVP state by the receipt > < and processing of RecoveryPath messages according to procedures > < defined in this document, MUST include the Capability object with the > < RecoveryPath Desired (R) bit set (1) in its RSVP Hello messages to > < its neighbors, during the Recovery Period. The node MUST also > < include the Restart_Caps object as defined in [RFC3473], in all those > < Hello messages. > > A node that expects to recover RSVP state by the receipt and > > processing of RecoveryPath messages according to procedures defined > > in this document, MUST include the Capability object with the > > RecoveryPath Desired (R) bit set (1) in its RSVP Hello messages to > > its neighbors. The node MUST also include the Restart_Cap object as > > defined in [RFC3473], in all those Hello messages. > > - Section 4.5.2 Procedures for the Restarting Node > Change response to received RecoveryPath messages outside the Recovery > Period: > < These procedures apply during the "state recovery process" and > < "Recovery Period" as defined in Section 9.5.2 in [RFC3473]. Any > < RecoveryPath message received after the Recovery Period has expired > < MUST be discarded. If no LSP state matching the RecoveryPath message > < is located, the restarted node MAY send a PathTear message > < constructed from the RecoveryPath message, to expedite the cleanup of > < unrecovered RSVP and associated forwarding state downstream of the > < restarted node. > > These procedures apply during the "state recovery process" and > > "Recovery Period" as defined in Section 9.5.2 in [RFC3473]. Any > > RecoveryPath message received after the Recovery Period has expired > > SHOULD be matched against local LSP state. If matching fully > > resynchronized state is located, the node SHOULD send a Path message > > downstream. If non-resynchronized or no LSP state matching the > > RecoveryPath message is located, the restarted node MAY send a > > PathTear message constructed from the RecoveryPath message, to > > expedite the cleanup of unrecovered RSVP and associated forwarding > > state downstream of the restarted node. > > - Section 5.2.1 Procedures > (Srefresh mechanism), clarify text: the restarting node must send > the R-bit in all Hellos > < To indicate to an RSVP neighbor that selective transmission of > < RecoveryPath messages is desired, a restarting node MUST set (1) the > < S-bit in the Capability object in all Hello messages it sends during > < the Recovery Period to the neighbor. When the restarting node does > > To indicate to an RSVP neighbor that selective transmission of > > RecoveryPath messages is desired, a node MUST set (1) the S-bit in > > the Capability object in all Hello messages it sends. When the > > - Section 7. Acknowledgments > Add Pavan Beeram. > > - Section 8. IANA Considerations > Suggest values for the RecoveryPath msg and the Capability object > < A new RSVP object using a Class-Number of form 10bbbbbb called the > < Capability Object is defined in Section 4.2 in this document. The > < Class-Number is TBA by IANA. > > A new RSVP object using a Class-Number of form 10bbbbbb called the > > Capability Object is defined in Section 4.2 in this document. The > > Class-Number is TBA by IANA. A value of 132 is suggested. > > < A new RSVP message type called a RecoveryPath message is defined in > < Section 4.1 of this document. The RSVP message type is TBA by IANA. > > A new RSVP message type called a RecoveryPath message is defined in > > Section 4.1 of this document. The RSVP message type is TBA by IANA. > > A value of 30 is suggested. > > - Section 8. IANA Considerations > Fix typo in the bit names > < +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > < | |S|P|R| > < +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | |T|R|S| > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Thanks, > Arun (and co-authors) > ============================================================== > -------- Original Message -------- > Subject: I-D ACTION:draft-ietf-ccamp-rsvp-restart-ext-04.txt > Date: Mon, 03 Oct 2005 15:50:02 -0400 > From: Internet-Drafts@ietf.org > To: i-d-announce@ietf.org > CC: ccamp@ops.ietf.org > > 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 GMPLS RSVP Graceful Restart > Author(s) : A. Satyanarayana, et al. > Filename : draft-ietf-ccamp-rsvp-restart-ext-04.txt > Pages : 24 > Date : 2005-10-3 > > This document describes extensions to the RSVP Graceful Restart > mechanisms defined in RFC 3473. The extensions enable the recovery > of RSVP signaling state based on the Path message last sent by the > node being restarted. Previously defined Graceful Restart > mechanisms, also called recovery from nodal faults, permit recovery > of signaling state from adjacent nodes when the data plane has > retained the associated forwarding state across a restart. These > mechanisms do not fully support signaling state recovery on ingress > nodes or recovery of all RSVP objects. The presented extensions use > the RSVP Hello extensions defined in RFC 3209, and extensions for > state recovery on nodal faults defined in RFC 3473. With the > presented extensions the restarting node can recover all previously > transmitted Path state including the Explicit Route Object and the > downstream (outgoing) interface identifiers. The extensions can also > be used to recover signaling state after the restart of an ingress > node. The extensions optionally support the use of Summary Refresh, > defined in RFC 2961, to reduce the number of messages exchanged > during the Recovery Phase when the restarting node has recovered > signaling state locally for one or more LSPs. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rsvp-restart-ext-04.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-rsvp-restart-ext-04.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-rsvp-restart-ext-04.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. > > > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 11 Oct 2005 19:11:15 +0000 Message-ID: <434C0DFA.80102@cisco.com> Date: Tue, 11 Oct 2005 12:09:46 -0700 From: Arun Satyanarayana Organization: Cisco Systems User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) MIME-Version: 1.0 To: Adrian Farrel , Kireeti Kompella CC: ccamp@ops.ietf.org, Lou Berger , Dimitri Papadimitriou , Dimitri Papadimitriou , Anca Zamfir , Reshad Rahman , Junaid Israr , "Arun Satyanarayana (asatyana)" Subject: Re: I-D ACTION:draft-ietf-ccamp-rsvp-restart-ext-04.txt Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Adrian, Kireeti, Following are the mods to version -03, based on last call comments. Can we go through another short last call on this rev please? - Section 2 Terminology: Fix bad text < The reader is assumed to be familiar with the terminology defined in < xref target="RFC3209" /> and [RFC3473]. > The reader is assumed to be familiar with the terminology defined in > [RFC3209] and [RFC3473]. - Section 4.2 Capability Object: Reverse ordering of definitions of T and R bits to match ordering in object - Full I-D: Change "Restart_Caps" to "Restart_Cap" (to match definition in 3473). - Section 4.4.1 Procedures for the Downstream Neighbor Clarify text: the downstream neighbor must send the T-bit in all Hellos < If the downstream RSVP neighbor of a restarting node is capable of < sending RecoveryPath messages to the restarting node, it MUST include < the Capability object with the RecoveryPath Transmit Enabled (T) bit < set (1) in all its Hello messages sent to the restarting node. > If a node is capable of sending RecoveryPath messages, it MUST > include the Capability object with the RecoveryPath Transmit Enabled > (T) bit set (1) in all its Hello messages. - Section 4.4.2 Procedures for the Restarting Node Clarify text: the restarting node must send the R-bit in all Hellos < A restarting node that expects to recover RSVP state by the receipt < and processing of RecoveryPath messages according to procedures < defined in this document, MUST include the Capability object with the < RecoveryPath Desired (R) bit set (1) in its RSVP Hello messages to < its neighbors, during the Recovery Period. The node MUST also < include the Restart_Caps object as defined in [RFC3473], in all those < Hello messages. > A node that expects to recover RSVP state by the receipt and > processing of RecoveryPath messages according to procedures defined > in this document, MUST include the Capability object with the > RecoveryPath Desired (R) bit set (1) in its RSVP Hello messages to > its neighbors. The node MUST also include the Restart_Cap object as > defined in [RFC3473], in all those Hello messages. - Section 4.5.2 Procedures for the Restarting Node Change response to received RecoveryPath messages outside the Recovery Period: < These procedures apply during the "state recovery process" and < "Recovery Period" as defined in Section 9.5.2 in [RFC3473]. Any < RecoveryPath message received after the Recovery Period has expired < MUST be discarded. If no LSP state matching the RecoveryPath message < is located, the restarted node MAY send a PathTear message < constructed from the RecoveryPath message, to expedite the cleanup of < unrecovered RSVP and associated forwarding state downstream of the < restarted node. > These procedures apply during the "state recovery process" and > "Recovery Period" as defined in Section 9.5.2 in [RFC3473]. Any > RecoveryPath message received after the Recovery Period has expired > SHOULD be matched against local LSP state. If matching fully > resynchronized state is located, the node SHOULD send a Path message > downstream. If non-resynchronized or no LSP state matching the > RecoveryPath message is located, the restarted node MAY send a > PathTear message constructed from the RecoveryPath message, to > expedite the cleanup of unrecovered RSVP and associated forwarding > state downstream of the restarted node. - Section 5.2.1 Procedures (Srefresh mechanism), clarify text: the restarting node must send the R-bit in all Hellos < To indicate to an RSVP neighbor that selective transmission of < RecoveryPath messages is desired, a restarting node MUST set (1) the < S-bit in the Capability object in all Hello messages it sends during < the Recovery Period to the neighbor. When the restarting node does > To indicate to an RSVP neighbor that selective transmission of > RecoveryPath messages is desired, a node MUST set (1) the S-bit in > the Capability object in all Hello messages it sends. When the - Section 7. Acknowledgments Add Pavan Beeram. - Section 8. IANA Considerations Suggest values for the RecoveryPath msg and the Capability object < A new RSVP object using a Class-Number of form 10bbbbbb called the < Capability Object is defined in Section 4.2 in this document. The < Class-Number is TBA by IANA. > A new RSVP object using a Class-Number of form 10bbbbbb called the > Capability Object is defined in Section 4.2 in this document. The > Class-Number is TBA by IANA. A value of 132 is suggested. < A new RSVP message type called a RecoveryPath message is defined in < Section 4.1 of this document. The RSVP message type is TBA by IANA. > A new RSVP message type called a RecoveryPath message is defined in > Section 4.1 of this document. The RSVP message type is TBA by IANA. > A value of 30 is suggested. - Section 8. IANA Considerations Fix typo in the bit names < +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ < | |S|P|R| < +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | |T|R|S| > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Thanks, Arun (and co-authors) ============================================================== -------- Original Message -------- Subject: I-D ACTION:draft-ietf-ccamp-rsvp-restart-ext-04.txt Date: Mon, 03 Oct 2005 15:50:02 -0400 From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org CC: ccamp@ops.ietf.org 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 GMPLS RSVP Graceful Restart Author(s) : A. Satyanarayana, et al. Filename : draft-ietf-ccamp-rsvp-restart-ext-04.txt Pages : 24 Date : 2005-10-3 This document describes extensions to the RSVP Graceful Restart mechanisms defined in RFC 3473. The extensions enable the recovery of RSVP signaling state based on the Path message last sent by the node being restarted. Previously defined Graceful Restart mechanisms, also called recovery from nodal faults, permit recovery of signaling state from adjacent nodes when the data plane has retained the associated forwarding state across a restart. These mechanisms do not fully support signaling state recovery on ingress nodes or recovery of all RSVP objects. The presented extensions use the RSVP Hello extensions defined in RFC 3209, and extensions for state recovery on nodal faults defined in RFC 3473. With the presented extensions the restarting node can recover all previously transmitted Path state including the Explicit Route Object and the downstream (outgoing) interface identifiers. The extensions can also be used to recover signaling state after the restart of an ingress node. The extensions optionally support the use of Summary Refresh, defined in RFC 2961, to reduce the number of messages exchanged during the Recovery Phase when the restarting node has recovered signaling state locally for one or more LSPs. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rsvp-restart-ext-04.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-rsvp-restart-ext-04.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-rsvp-restart-ext-04.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. Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 11 Oct 2005 12:39:52 +0000 Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: "Tom Petch" , , Content-Transfer-Encoding: 7bit From: "Thomas D. Nadeau" Subject: Re: MIB Dr. review of draft-ietf-ccamp-gmpls-te-mib-09.txt Date: Tue, 11 Oct 2005 08:38:26 -0400 To: "Adrian Farrel" Sorry, just getting back to my emails... > Hi Tom, > > >> I am still unsure about MSB/LSB in IANAGmplsAdminStatusFlags. >> This has >> > reflect > >> (31) while RFC3471 has reflect as bit 0. >> >> As Joan says, "The BITS as specified look backwards when viewing the >> > TLV". > >> >> This is fine if one is MSB, the other LSB (although that might be >> worth >> > adding a > >> note about). >> > > You are both right. > We have reversed the order of the bits in the IANA MIB and also > filled the > gap with "reserved" bits. Just a clarification Tom P., we will add a statement to the object explaining what Adrian posted above, which will hopefully allay future questions on the object. --Tom Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 11 Oct 2005 05:38:27 +0000 Message-ID: <00f101c5cd88$1957d4c0$f2849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: , "Tom Petch" , "Thomas D. Nadeau" , Cc: Subject: Re: MIB Dr. review of draft-ietf-ccamp-gmpls-te-mib-09.txt Date: Mon, 10 Oct 2005 11:40:38 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi Joan, > Please add a note as to why the bits are reversed for the managed object. No, no, no, no! :-) I said... > > You are both right. > > We have reversed the order of the bits in the IANA MIB and also filled the > > gap with "reserved" bits. That means we have changed the order from what it used to be to what you have asked for. Thanks, Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 10 Oct 2005 13:06:50 +0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=S6Yae/GU7ykdeCLXu2Www1+fEtQj6qjmLNx3LV3dygMiuSvWeZUG1lqHUiKM9glm; 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: <01b901c5cd9b$0a274d60$0500a8c0@jlucianilaptop> From: To: "Adrian Farrel" , "Tom Petch" , "Thomas D. Nadeau" , Cc: Subject: Re: MIB Dr. review of draft-ietf-ccamp-gmpls-te-mib-09.txt Date: Mon, 10 Oct 2005 09:03:41 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit ----- Original Message ----- From: Adrian Farrel To: ; Tom Petch ; Thomas D. Nadeau ; Cc: Sent: Monday, October 10, 2005 6:40 AM Subject: Re: MIB Dr. review of draft-ietf-ccamp-gmpls-te-mib-09.txt > Hi Joan, > > > Please add a note as to why the bits are reversed for the managed > object. > > No, no, no, no! :-) > > I said... > > > > You are both right. > > > We have reversed the order of the bits in the IANA MIB and also filled > the > > > gap with "reserved" bits. > > That means we have changed the order from what it used to be to what you > have asked for. Okay, sorry for my confusion. -Joan > > Thanks, > Adrian > > Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 10 Oct 2005 04:37:38 +0000 Message-ID: <008b01c5ccc3$0c4d03b0$f2849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Fw: 64th IETF - DRAFT Agenda Date: Sun, 9 Oct 2005 12:01:36 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi, Early plans have CCAMP scheduled as MONDAY, November 7, 2005 0900-1130 Morning Session I RTG ccamp Common Control and Measurement Plane WG This may get changed. Cheers, Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 10 Oct 2005 04:37:30 +0000 Message-ID: <00c701c5ccc3$ee1db320$f2849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Tom Petch" , "Thomas D. Nadeau" , Cc: Subject: Re: MIB Dr. review of draft-ietf-ccamp-gmpls-te-mib-09.txt Date: Sun, 9 Oct 2005 12:18:41 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi Tom, > I am still unsure about MSB/LSB in IANAGmplsAdminStatusFlags. This has reflect > (31) while RFC3471 has reflect as bit 0. > > As Joan says, "The BITS as specified look backwards when viewing the TLV". > > This is fine if one is MSB, the other LSB (although that might be worth adding a > note about). You are both right. We have reversed the order of the bits in the IANA MIB and also filled the gap with "reserved" bits. Cheers, Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 10 Oct 2005 01:59:03 +0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=WjgBY3rKMJkY5V6KIYHmCpQEOpRkvGO08ICdDUWGJKJVDjFW0DUsif8C+s/VLl1C; 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: <015c01c5cd3d$bbe87500$0500a8c0@jlucianilaptop> From: To: "Adrian Farrel" , "Tom Petch" , "Thomas D. Nadeau" , Cc: Subject: Re: MIB Dr. review of draft-ietf-ccamp-gmpls-te-mib-09.txt Date: Sun, 9 Oct 2005 21:55:47 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Adrian, Please add a note as to why the bits are reversed for the managed object. Thanks, Joan ----- Original Message ----- From: Adrian Farrel To: Tom Petch ; Thomas D. Nadeau ; Cc: Sent: Sunday, October 09, 2005 7:18 AM Subject: Re: MIB Dr. review of draft-ietf-ccamp-gmpls-te-mib-09.txt > Hi Tom, > > > I am still unsure about MSB/LSB in IANAGmplsAdminStatusFlags. This has > reflect > > (31) while RFC3471 has reflect as bit 0. > > > > As Joan says, "The BITS as specified look backwards when viewing the > TLV". > > > > This is fine if one is MSB, the other LSB (although that might be worth > adding a > > note about). > > You are both right. > We have reversed the order of the bits in the IANA MIB and also filled the > gap with "reserved" bits. > > Cheers, > Adrian > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 06 Oct 2005 14:43:59 +0000 Message-ID: <036501c5ca7b$a2c16a60$0601a8c0@pc6> Reply-To: "Tom Petch" From: "Tom Petch" To: "Adrian Farrel" , , Cc: Subject: Re: MIB Dr. review of draft-ietf-ccamp-gmpls-te-mib-09.txt Date: Thu, 6 Oct 2005 12:36:06 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Adrian I am still unsure about MSB/LSB in IANAGmplsAdminStatusFlags. This has reflect (31) while RFC3471 has reflect as bit 0. As Joan says, "The BITS as specified look backwards when viewing the TLV". This is fine if one is MSB, the other LSB (although that might be worth adding a note about). Tom Petch ----- Original Message ----- From: To: "Adrian Farrel" ; ; Cc: ; Sent: Friday, September 30, 2005 4:13 AM Subject: Re: MIB Dr. review of draft-ietf-ccamp-gmpls-te-mib-09.txt > > hi Adrian, > > Please see comments inline below, I have snipped parts where we > are in agreement. > > thanks, joan > > > > ----- Original Message ----- > From: Adrian Farrel > To: ; ; > Cc: ; > Sent: Thursday, September 22, 2005 8:59 AM > Subject: Re: MIB Dr. review of draft-ietf-ccamp-gmpls-te-mib-09.txt > > > > Hi Joan, > > > > Last but not least, the GMPLS TE MIB module. > > > > > Here are some comments on draft-ietf-ccamp-gmpls-te-mib-09.txt. > > > All 3 docs show a good deal of work. > > > > Yes, but fortunatley most of the work appears to be editorial with only > > very minor changes to the basis of the module. > > > > Please find acks and nacks in line below. > > > > We will also include the comments made by David and Tom Petch. > > > > Cheers, > > Adrian > > > > > > > > Section 8. GMPLS Traffic Engineering MIB Module > > > ----------------------------------------------- > > > > > > smicngPRO gives the following: > > > > > > W: f(GMPLS-TE-STD-MIB), (1181,14) Item "gmplsTunnelErrorTLVs" should > > have > > > SIZE specified > > > > Ack > > Understood this to be optional, but planning to add size as per David's > > comments > > > > > W: f(GMPLS-TE-STD-MIB), (1362,13) For "gmplsTunnelDirection", syntax is > > > identical > > > W: f(GMPLS-TE-STD-MIB), (1371,13) For "gmplsTunnelPathComp", syntax is > > > identical > > > W: f(GMPLS-TE-STD-MIB), (1382,14) For "gmplsTunnelUpNotRecip", syntax is > > > identical > > > W: f(GMPLS-TE-STD-MIB), (1389,14) For "gmplsTunnelDownNotRecip", syntax > > is > > > identical > > > W: f(GMPLS-TE-STD-MIB), (1401,14) For "gmplsTunnelExtraParamsPtr", > > syntax > > > is identical > > > > Nack > > Meaningless warning message. Cannot fix without explanation. > > > The object is defined as: > > > gmplsTunnelDirection OBJECT-TYPE > SYNTAX INTEGER { > forward (0), > bidirectional (1) > } > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "Whether this tunnel carries forward data only (is > unidirectional) or is bidirectional. > > Values of this object other than 'forward' are meaningful > only if gmplsTunnelLSPEncoding is not set to > 'tunnelLspNotGmpls'." > DEFVAL { forward } > ::= { gmplsTunnelEntry 8 } > > > The following (part of the ReadOnly compliance statement) is causing > the warning because the SYNTAX defined in the object and the > SYNTAX below are the same. (Following the OBJECT are a > few alternatives.) > > OBJECT gmplsTunnelDirection > SYNTAX INTEGER { > forward (0), > bidirectional (1) > } > MIN-ACCESS read-only > DESCRIPTION > "Only forward (0) is required." > > > If you do intend for the SYNTAX in both the OBJECT-TYPE and > the OBJECT to be the same, then removing it from the OBJECT > would get rid of the warning. This is not a blocking issue, but > it is duplicate info that does not need to be duplicated. > So here is what the OBJECT statement would like: > > OBJECT gmplsTunnelDirection > MIN-ACCESS read-only > DESCRIPTION > "Only forward (0) is required." > > Another alternative would be to specify forward(0) only since > this is what the DESCRIPTION is specifying, however, it is > likely that you are probably allowing both, so I don't think this > is what you intend, but this would also solve the compiler warning: > > OBJECT gmplsTunnelDirection > SYNTAX INTEGER { > forward (0), > } > MIN-ACCESS read-only > DESCRIPTION > "Only forward (0) is required." > > > > > > > 5) gmplsTunnelTable > > > > > > DESCRIPTION > > > > > > "The row status of an entry in this table is controlled by > > > mplsTunnelRowStatus in the corresponding entry in > > > mplsTunnelTable. That is, it is not permitted to create a row in > > > this table, nor to modify an existing row, when the > > > corresponding mplsTunnelRowStatus has value active(1).... > > > > > > The sentence beginning with "That is," is awkward. Could you say > > > something like: A row in this table is created when a row is created > > > in the mplsTunnelTable. Entries in this table cannot be modified > > > when the corresponding mplsTunnelRowStatus has a value of active(1). > > > The exception.... > > > > > > Please also update this other places in this MIB (e.g > > gmplsTunnelHopTable). > > > > Nack > > "A row in this table is created when a row is created in the > > mplsTunnelTable" is false. > > Will attempt to reword to make this clearer. > > > > > 6) gmplsTunnelEntry > > > DESCRIPTION: > > > "... > > > An entry can be created by a network administrator or by an SNMP > > > agent as instructed by a signaling protocol." > > > > > > Please change the above to: > > > > > > "An entry can be created by a network administrator via SNMP SET > > commands, or > > > by the network management entity as instructed by a signaling > > > protocol." > > > > Nack > > "network management entity" implies a remote entity such as an NMS. > > Yes, I should have said, "network management entity (e.g., snmp agent). > > > > Will change to: > > > > "An entry can be created by a network administrator via SNMP SET > > commands, or in response to signaling protocol events." > > > > good. > > > > 7) gmplsTunnelUnnumIf > > > > > > What IF-MIB object are referring to in the DESCRIPTION? > > > Could you state which object in the description? > > > > Ack > > An entry in ifTable. > > > > Could you specify the ifType(s)? > > > > 8) gmplsTunnelAttributes > > > Could you specify what happens when the bit is set (i.e. 1) > > > vs. 0? > > > > Ack > > Don't want to restate the protocol I-D, so this text will simply > > replace "This flag indicates that" with "This flag is set to indicate > > that" > > > > > 9) gmplsTunnelLSPEncoding > > > > > > The DESCRIPTION states: > > > ...A value of 'tunnelLspNotGmpls' indicates that GMPLS signaling > > is > > > not in use. Some objects in this MIB module may be of use for > > > MPLS signaling extensions that do not use GMPLS signaling. By > > > setting this object to 'tunnelLspNotGmpls', an application may > > > indicate that only those objects meaningful in MPLS should be > > > examined.... > > > > > > I believe that such objects should be put in to an MPLS MIB module > > > and not included in this GMPLS MIB module. This is also true with > > > the gmplsTunnelErrorTable. > > > > Nack > > We strongly disagree with any implication that MPLS and GMPLS should be > > separated in this way. GMPLS protocol extensions are likely to be > > moved into MPLS implementations piecemeal and there is no clear > > separation that you imply. The G in GMPLS stands for "generalized". > > > > Can you please indicate whether this is a sticking point for you. > > > > As was suggested in an email on draft-ietf-ccamp-gmpls-lsr-mib, could > you put these objects in a separate object group? Also, please separate > MPLS and MPLS-TE objects into separate object groups. > > > > > > > 12) gmplsTunnelUpNotRecip > > > > > > Need to use InetAddressType and InetAddress. IpAddress > > > is not used in MIBs anymore. Please be sure to support > > > both v4 and v6 IP address Types. If you can't support > > > v6 for some reason, that should be stated clearly. > > > > Ack per exchange with David. > > > > > Please change the name of this object to: > > > gmplsTunnelUpstreamRecipientForNotify > > > > Nack > > We are trying to keep to the (mythical?) 32 character limit. > > How about: > > gmplsTunnelUpNotifyRecipient > > How about gmplsTunnelUpstreamNotifyRecipient > > As for the 32 char limit, we've already addressed that, so won't > repeat that discussion. > > > > > > 13) gmplsTunnelDownNotRecip > > > Same comment as above wrt to IpAddress. > > > > Ack > > > > > Please change the name to gmplsTunnelDownstreamRecipientForNotify > > > > Nack as above > > How about: > > gmplsTunnelDownNotifyRecipient > > How about gmplsTunnelDownstreamNotifyRecipient > > > >> > 18) gmplsTunnelHopExpLabel and gmplsTunnelHopExpLabelPtr > > > > > > Need to add the word "Forward" in here as in > > > gmplsTunnelHopExpForwardLabel and gmplsTunnelHopExpForwardLabelPtr > > > > > > That way it will be consistent with the Reverse counterparts. > > > > Nack > > Please see point 21 about name lengths. > > We will insert "Fwd" > > > > > 19) gmplsTunnelHopExpRvrsLabel and gmplsTunnelHopExpReverseLabelPtr > > > > > > Please change Rvrs to Reverse. > > > > Nack > > Please see point 21 about name lengths > > In other objects in this MIB module are named using the entire > word Reverse ( e.g. > GmplsTunnelReversePerfEntry ::= SEQUENCE { > gmplsTunnelReversePerfPackets Counter32, > gmplsTunnelReversePerfHCPackets Counter64, > gmplsTunnelReversePerfErrors Counter32, > gmplsTunnelReversePerfBytes Counter32, > gmplsTunnelReversePerfHCBytes Counter64 > }) > > So please either change these to all use Rvrs or instead of Rvrs use > the entire word, Reverse. Similarly with the use of Fwd and Forward, > if you decide to use Reverse, then please use the entire word, Forward. > If you decide to use Rvrs, then please use Fwd. I prefer the words > spelled out but just please be consistent. > > > > > > 21) gmplsTunnelARHopExpLable and gmplsTunnelARHopExpLabelPtr > > > > > > Need to add the word "Forward" in here as in > > > gmplsTunnelARHopExpForwardLabel and gmplsTunnelARHopExpForwardLabelPtr > > > > Nack > > Would excede 32 characters. > > Will use "Fwd" > > See discussion above wrt Rvrs and Reverse. > > > > > > 22) gmplsTunnelARHopExpRvrsLabel and gmplsTunnelARHopExpRvrsLabelPtr > > > > > > Please change Rvrs to Reverse > > > > Nack > > See point 21 > > > > > 23) gmplsTunnelARHopProtection OBJECT-TYPE > > > > > > Please add what the BIT set (i.e. 1) vs. 0 means in the > > > DESCRIPTION. > > > > Ack > > Limited change as before. > > > > > 24) gmplsTunnelCHopLabelTable objects > > > > > > Similar comments regarding the objects in this table > > > to those above with regard to naming > > > conventions (Forward and Reverse) and DESCRIPTIONs. Will not repeat the > > > details, please refer to above comments on the > > > prior 2 tables. > > > > Nack > > Same answers as before. > > Will use "Fwd" > > > > > 25) gmplsTunnelReversePerfTable > > > Please add to the DESCRIPTION how a user knows if > > > this is a bidirectional tunnel (i.e. what object > > > or objects in the gmplsTunnelTable need to have > > > what values?). > > > > Ack > > > > > 26) gmplsTunnelReversePerfPackets > > > > > > Does this object represent the 32-bit > > > value of the least significant part of the > > > 64-bit value (which is contained in gmplsTunnelReversePerfHCPackets)? > > > > Ack > > > > > 27) gmplsTunnelReversePerfBytes > > > > > > Does this object represent the 32-bit > > > value of the least significant part of the > > > 64-bit value (which is contained in gmplsTunnelReversePerfHCBytes)? > > > > Ack > > > > > 28) gmplsTunnelErrorTable OBJECT-TYPE > > > > > > Since this table applies to MPLS, it should be > > > put in a separate MIB module which is MPLS specific. The > > > prefix of gmpls could be confusing. > > > > Nack > > This is applicable across MPLS and GMPLS. > > Error TLVs are not present in MPLS RSVP-TE at this time. They may be added > > later. > > > > Discussed previously about separate OBJECT groups. > > > > 31) Compliance > > > > > > Please move some of the following comment in the > > > DESCRIPTION of gmplsTeModuleFullCompliance > > > > > > -- The mandatory group has to be implemented by all LSRs that > > > -- originate, terminate or act as transit for TE-LSPs/tunnels. > > > -- In addition, depending on the type of tunnels supported, other > > > -- groups become mandatory as explained below. > > > > Ack > > > > > 32) gmplsTunnelUnnumIf does not appear in the ReadOnly compliance > > > and it probably should. > > > > Ack > > > > > Section 11.2.1. IANA-GMPLS-MIB Definition > > > ----------------------------------------- > > > > > 38) I believe that the TC > > > > > > IANAGmplsAdminStatusFlags ::= TEXTUAL-CONVENTION > > > > > > should be put in the GMPLS-TC-STD-MIB or should just > > > remain in the GMPLS-TE-STD-MIB. The reason is that this > > > is not an assigned numbers list maintained by IANA, so > > > should not be in the IANA GMPLS MIB. If I am incorrect > > > about this please let me know, but I didn't see an IANA > > > maintained Administrative Status Information enum. > > > > Nack > > There are no fewer than three requests in CCAMP I-Ds that have passed WG > > last call > > for this space to be managed by IANA. > > Is this going to be managed by IANA soon? (just curious) > > > > > > Additionally, this should be renamed to > > > GmplsAdminStatusInformation which more closely matches rfc3471. > > > > Ack > > > > > 39) Several comments on the SYNTAX clause: > > > > > > 40a) smicngPRO gives the error > > > > > > E: f(IANA-GMPLS-MIB.my), (252,22) Named bits for BITS > > > must be in contiguous positions > > > > > > SYNTAX BITS { > > > delInProgress (0), > > > adminDown (1), > > > testing (2), > > > reflect (31) > > > } > > > > > > > > > RFC2578 specifies that BITS should be contiguous > > > (although there are exceptions to this, but this > > > object does not seem to be an exception). > > > > Nack > > > > To quote the DESCRIPTION... > > The relationship between the assignment of > > gmplsTunnelAdminStatusFlags values and of the bit flags > > in the Admin Status object or TLV within the GMPLS > > signaling protocols is solely the purview of IANA and is > > subject to change without notice." > > However, it seems to us that making the bits match the flags in the > > Admin Status object is a Good Idea (TM). > > > > Here is the TLV that the object represents: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |R| Reserved |T|A|D| > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Reflect (R): 1 bit > Reserved: 28 bits > Testing (T): 1 bit > Administratively down (A): 1 bit > Deletion in progress (D): 1 bit > > The BITS as specified look backwards when viewing the TLV. > Are the BITS correctly specified? > > I consulted with other MIB Doctors and the following was suggested: > SYNTAX BITS { > delInProgress (0), > adminDown (1), > testing (2), > reserved3(3), -- 0 on send, ignored on receive > reserved4(4), -- 0 on send, ignored on receive > .. > reserved30(30), -- 0 on send, ignored on receive > reflect (31) > } > > Would this be acceptable? > > > > > Could delInProgress, be renamed to deleteInProgress ? > > > Could adminDown be renamed to administrativelyDown? > > > These names more closely match 3471. > > > > Ack > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 04 Oct 2005 08:36:15 +0000 Message-ID: <07f401c5c5da$9a3fc4e0$be849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: , , Cc: , Subject: Re: MIB Dr. review of draft-ietf-ccamp-gmpls-te-mib-09.txt Date: Fri, 30 Sep 2005 17:15:21 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi Joan, > > > 7) gmplsTunnelUnnumIf > > > > > > What IF-MIB object are referring to in the DESCRIPTION? > > > Could you state which object in the description? > > > > Ack > > An entry in ifTable. > > Could you specify the ifType(s)? Yup. It'll be 166 (MPLS). Added to document. > > > Section 11.2.1. IANA-GMPLS-MIB Definition > > > ----------------------------------------- > > > > > 38) I believe that the TC > > > > > > IANAGmplsAdminStatusFlags ::= TEXTUAL-CONVENTION > > > > > > should be put in the GMPLS-TC-STD-MIB or should just > > > remain in the GMPLS-TE-STD-MIB. The reason is that this > > > is not an assigned numbers list maintained by IANA, so > > > should not be in the IANA GMPLS MIB. If I am incorrect > > > about this please let me know, but I didn't see an IANA > > > maintained Administrative Status Information enum. > > > > Nack > > There are no fewer than three requests in CCAMP I-Ds that have passed WG > > last call for this space to be managed by IANA. > > Is this going to be managed by IANA soon? (just curious) Cerainly it'll happen before this I-D is an RFC. Soon? I wouldn't want to comment on the IESG review process and RFC Editor process (but I am serving on the PESCI team). > > > 39) Several comments on the SYNTAX clause: > > > > > > 40a) smicngPRO gives the error > > > > > > E: f(IANA-GMPLS-MIB.my), (252,22) Named bits for BITS > > > must be in contiguous positions > > > > > > SYNTAX BITS { > > > delInProgress (0), > > > adminDown (1), > > > testing (2), > > > reflect (31) > > > } > > > > > > > > > RFC2578 specifies that BITS should be contiguous > > > (although there are exceptions to this, but this > > > object does not seem to be an exception). > > > > Nack > > > > To quote the DESCRIPTION... > > The relationship between the assignment of > > gmplsTunnelAdminStatusFlags values and of the bit flags > > in the Admin Status object or TLV within the GMPLS > > signaling protocols is solely the purview of IANA and is > > subject to change without notice." > > However, it seems to us that making the bits match the flags in the > > Admin Status object is a Good Idea (TM). > > > > Here is the TLV that the object represents: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |R| Reserved |T|A|D| > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Reflect (R): 1 bit > Reserved: 28 bits > Testing (T): 1 bit > Administratively down (A): 1 bit > Deletion in progress (D): 1 bit > > The BITS as specified look backwards when viewing the TLV. > Are the BITS correctly specified? > > I consulted with other MIB Doctors and the following was suggested: > SYNTAX BITS { > delInProgress (0), > adminDown (1), > testing (2), > reserved3(3), -- 0 on send, ignored on receive > reserved4(4), -- 0 on send, ignored on receive > .. > reserved30(30), -- 0 on send, ignored on receive > reflect (31) > } > > Would this be acceptable? We can fill in the gaps. Thanks once again for engaging. Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 04 Oct 2005 07:19:07 +0000 Message-ID: <43422CA4.2050203@psg.com> Date: Tue, 04 Oct 2005 09:17:56 +0200 From: dimitri papadimitriou Reply-To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.11) Gecko/20050728 MIME-Version: 1.0 To: Adrian Farrel CC: Dimitri Papadimitriou , Christian E Hopps , Lyndon Ong , Jonathan Sadler , Dave Ward , Stephen Shew , ccamp@ops.ietf.org Subject: Re: Last call comments on draft-ietf-ccamp-gmpls-ason-routing-eval-01.txt Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit hi adrian Adrian Farrel wrote: > Hi, > > Here are my comments on this I-D. Most of these comments are very minor > editorial nits. We need to try to get these resolved at this stage because > it will improve the speed at which the IESG can review the I-D and reduce > the time in the RFC Editor process. thank for commenting here this will help in progressing the document > However, there are a few more > substantial questions hidden in the middle of what I have written. will provide on the list how these comments have been addressed when document will be re-submitted (assuming that the last call is over now) > I suspect that this email will take some while to show up at the CCAMP > mailing list because psg (which hosts the CCAMP list) is in dispute with > my ISP. Sorry about that. > > Thanks, > Adrian > > ==== > > Section 4 > > The following functionality is expected from GMPLS routing protocol > s/protocol/protocols/ > > Section 4 > - Processing of routing information exchanged between adjacent > levels of the hierarchy (i.e. Level N+1 and N) including > reachability and upon policy decision summarized topology > information. > s/and upon policy decision summarized/and (upon policy decision) > summarized > > Section 4 > - Self-consistent information at the receiving level resulting from > any transformation (filter, summarize, etc.) and forwarding of > information from one Routing Controller (RC) to RC(s) at different > levels when multiple RCs bound to a single RA. > s/bound/are bound/ > > Section 4 > As ASON does not restrict the control plane architecture choice used, > either a co-located architecture or a physically separated > architecture may be used. A collection of links and nodes such as a > s/architecture choice used/architecture choice/ > s/co-locate/collocate/ > > Section 5 > This section evaluates support of existing IETF routing protocols > with respect to the requirements summarized from [ASON-RR] in Section > 4. Candidate routing protocols are IGP (OSPF and IS-IS) and BGP. The > latter in not addressed in the current version of this document. > There will be no future versions of this document (we hope). > What should you then say about BGP? > Probably that BGP is not considered a candidate protocol because... > > Section 5.1 > - Li is a logical control plane entity that is associated to a > single data plane (abstract) node. The Li is identified by the > TE Router_ID. The latter is a control plane identifier defined as > . RFC 3630: Router_Address (top level) TLV of the Type 1 TE LSA > . RFC 3784: Traffic Engineering Router ID TLV (Type 134) > s/data plane (abstract) node/physical node/ > 1. Use same terminology as defined in previous bullet > 2. Why say "abstract" for something that is physical? > > Section 5.1 > This contains multiple references to RFCs. Can you please insert square > bracket citations. > > Section 5.1 > - Li is a logical control plane entity that is associated to a > single data plane (abstract) node. The Li is identified by the > TE Router_ID. The latter is a control plane identifier defined as > . RFC 3630: Router_Address (top level) TLV of the Type 1 TE LSA > . RFC 3784: Traffic Engineering Router ID TLV (Type 134) > > Note: this document does not define what the TE Router ID is. This > document simply states the use of the TE Router ID to identify > the Li. Other documents (the referenced RFC 3630 and RFC > 3784) provide the definitions. > There appear to be two contradictory paragraphs here. The first says > "...defined as...". The second says "...does not define..." Need to tweak > the words. > > Section 5.1 > Thus, the routing protocol MUST be able to advertise multiple TE > Router IDs. > You need to comment on whether this requires a modification to the > protocols as currently specified or not. This is, after all, the purpose > of this document. > > Section 5.1 > [ASON-REQ], does not enter into the identification of the logical > s/ASON-REQ/ASON-RR/ > > Section 5.2 > Under these conditions, GMPLS link state routing protocols provide > the capability for RA Identification. > Add "without further modification" > > Section 5.3 > We focus on routing information exchange between Ri entities > (through routing adjacencies) within single hierarchical level. > s/within single/within a single/ > > Section 5.3 > Routing information mapping between levels may require specific > guidelines. > ...and these are out of scope? > > Section 5.3 > The control plane does not transport Pi information as these are > data plane addresses for which the Li/Pi mapping is kept (link) > local - see for instance the transport LMP document [LMP-T] where > s/information/identifiers/ > > Section 5.3 (three times) > Are "666B.F999.AF10.222C" and "1.1.1.1" intended to be representative of > specific address forms. If the latter is an IPv4 address, you should pick > one from the range allowed for example IP addresses. > > Section 5.3 > You should conclude with a statement that "OSPF and IS-IS therefore carry > sufficient node identification information without further modification." > > Section 5.3 > 3) when using OSPF or ISIS as the IGP in support of traffic > engineering, RFC 3477 RECOMMENDS that the Li value (referred to the > "LSR Router ID") to be set to the TE Router ID value. > Please add citation for [RFC3477]. > > Section 5.3.1 > From the list of link attributes and characteristics (detailed in > [ASON-RR], the Local Adaptation support information is missing as TE > link attribute. GMPLS routing does not currently consider the use of > dedicated TE link attribute(s) to describe the cross/inter-layer > relationships. All other TE link attributes and characteristics are > currently covered (see Table 1.) > I think this could be written more clearly. Try... > [ASON-RR] provides a list of link attributes and characteristics > that need to be advertised by a routing protocol. All TE link > attributes and characteristics are currently handled by OSPF and > IS-IS (see Table 1) with the exception of Local Adaptation support. > GMPLS routing does not currently consider the use of dedicated TE > link attribute(s) to describe the cross/inter-layer relationships. > > Section 5.3.1 > However, the representation of bandwidth requires further analysis > i.e. GMPLS Routing defines an Interface Switching Capability > Descriptor (ISCD) that delivers information about the (maximum/ > minimum) bandwidth per priority an LSP can make use of. > s/an LSP can make use of/of which an LSP can make use/ > > Section 5.3.1 > The latter > also may require definition of additional signal types (from those > defined in [RFC 3496]) to represent contiguous concatenation i.e. > STS-(3xN)c SPE / VC-4-Nc, N = 4, 16, 64, 256. > s/also may/may also/ > s/RFC 3496/RFC3946/ !!! > Note that 3946 is a signaling I-D. It does not mention routing > advertisement. You may need to add some detail here to explain how this > RFC is relevant. > > Section 5.3.1 > perspective. However, it introduces some lost of information. This > lost of information affects the number of signals that can be used > but not the range they cover. On the other hand, if additional > technology specific information (such as capabilities) are > s/lost/loss/ (twice) > s/capabilities) are/capabilities) is/ > > Section 5.3.1 > sub-TLV [GMPLS-OSPF] > GMPLS-OSPF is not in the references. > > Section 5.3.1 > Local SNPP link ID Link local part of the TE link identifier > sub-TLV [GMPLS-ISIS] > GMPLS-ISIS is not in the references. > > Section 5.3.1 > Note: Link Attributes represent layer resource capabilities and > their utilization. > Undoubtedly true, but missing a little context? > > Section 5.3.2 > Nodes attributes include the "Logical Node ID" (as detailed in > Section 5.1) and the reachability information as described in > Section 5.3.3. > The use of "include" implies there are other node attributes not discussed > here. > Either discuss them (if they exist) or fix the text by s/include/are/ > > Section 5.3.3 > defined per address family, e.g., IPv4 and IPv6). However, [OSPF- > NODE] restricts to advertisement of Host addresses and not prefixes, > and therefore requires enhancement (see below). > s/restricts to advertisement/is restricted to advertisement/ > > Section 5.3.3 > A similar mechanism does not exist for IS-IS as the Extended IP > Reachability TLV [RFC3784] focuses on IP reachable end-points > (terminating points), as its name indicates. > I assume you mean that "An extension similar to [OSPF-NODE] is not > required for IS-IS because the function is already included in the > Reachability TLV. However, both the Reachability TLV and [OSPF-TLV] do not > support the advertisement of reachability prefixes." > > Section 5.4. > hence no specific capabilities are added to the routing protocol > s/are/need to be/ > > Section 5.5 > level hierarchy, and disallow the advertising of routing information > s/disallow/disallows/ > > Section 5.5 > downward in the hierarchy. [RFC2966] defines the up/down bit to > [RFC2966] is not in the references. > > Section 5.5 > [RFC1195] allows only advertising routing information upward in the > RFC 1195 is not in the references. > > Section 5.5 > downward in the hierarchy. [RFC2966] defines the up/down bit to > RFC 2966 is not in the references. > > Section 5.5 > OSPFv2 prevents that inter-area routes, which are learned from area > 0 are not passed back to area 0. However, GMPLS makes use of Type 10 > Rewrite as... > OSPFv2 prevents inter-area routes (which are learned from area 0) > from being passed back to area 0. However, GMPLS makes use of Type 10 > > Section 5.5 > (area-local scope) LSA to propagate TE information [RFC3630], [GMPLS- > s/LSA/LSAs/ > > Section 5.5 > which Type 10 Opaque LSA may carry the information that particular > s/LSA/LSAs/ > s/particular/a particular piece of/ > > Section 5.5 > back into an higher level RC. > s/an/a/ > > Section 5.6 > Link state protocols have been designed to detect topological > changes (such as interface failures, link attributes modification). > Convergence period is short and involves a minimum of routing > information exchange. > Do link state protocols detect the changes or propagate them? > s/Convergence/The convergence/ > s/and involves/and convergence involves/ > > Section 5.7 > behalf multiple Li's creates the following issue as there is no more > a 1:1 relationship between the Router_ID and the TE Router_ID but a > /more/longer/ > > Section 5.7 > and link remote (unnumbered) ID association may be not unique per > s/be not/not be/ > > Section 5.7 > retrieve the [Li;Lj] relationship(s). In brief, as unnumbered links > The RFC Ed. prefers that square brackets [] are used only for citations. > Can you use {}? > > Section 6 > respectively case 1), 2), 3) and 4). Additional base scenarios > (being not combinations or decomposition of entities) may further > complete this set in a future revision of this document. > Remove this sentence. > > Section 6 > In the below Figure 1: > s/In the below Figure 1:/In Figure 1 below: > > Section 6 > Please add captions to the figures. At the moment it is not completely > clear that cases 1, 2 and 3 appear in Figure 1, while case 4 appears in > Figure 3, and Figure 2 is a special representation of case 1. > > New Section 7 > Please add a new section after Section 6 > "Summary of Necessary Additions to OSPF and IS-IS" > It is too hard for the reader to extract these from the I-D with complete > certainty. > > Section 8.1 > Is [LMP-T] really normative? > Is [OSPF-NODE] really normative? The draft will progress better if it is > not. > [RFC3667] and [RFC3668] don't need to be listed. > [RFC3946] is not referenced. > > Section 8.2 > [ASON-RR] is surely normative. > > > . > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 04 Oct 2005 05:37:49 +0000 Message-ID: <008f01c5c738$0b006b40$6b849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Dimitri Papadimitriou" , "Dimitri Papadimitriou" , "Christian E Hopps" , "Lyndon Ong" , "Jonathan Sadler" , "Dave Ward" , "Stephen Shew" Cc: Subject: Last call comments on draft-ietf-ccamp-gmpls-ason-routing-eval-01.txt Date: Sun, 2 Oct 2005 10:58:29 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi, Here are my comments on this I-D. Most of these comments are very minor editorial nits. We need to try to get these resolved at this stage because it will improve the speed at which the IESG can review the I-D and reduce the time in the RFC Editor process. However, there are a few more substantial questions hidden in the middle of what I have written. I suspect that this email will take some while to show up at the CCAMP mailing list because psg (which hosts the CCAMP list) is in dispute with my ISP. Sorry about that. Thanks, Adrian ==== Section 4 The following functionality is expected from GMPLS routing protocol s/protocol/protocols/ Section 4 - Processing of routing information exchanged between adjacent levels of the hierarchy (i.e. Level N+1 and N) including reachability and upon policy decision summarized topology information. s/and upon policy decision summarized/and (upon policy decision) summarized Section 4 - Self-consistent information at the receiving level resulting from any transformation (filter, summarize, etc.) and forwarding of information from one Routing Controller (RC) to RC(s) at different levels when multiple RCs bound to a single RA. s/bound/are bound/ Section 4 As ASON does not restrict the control plane architecture choice used, either a co-located architecture or a physically separated architecture may be used. A collection of links and nodes such as a s/architecture choice used/architecture choice/ s/co-locate/collocate/ Section 5 This section evaluates support of existing IETF routing protocols with respect to the requirements summarized from [ASON-RR] in Section 4. Candidate routing protocols are IGP (OSPF and IS-IS) and BGP. The latter in not addressed in the current version of this document. There will be no future versions of this document (we hope). What should you then say about BGP? Probably that BGP is not considered a candidate protocol because... Section 5.1 - Li is a logical control plane entity that is associated to a single data plane (abstract) node. The Li is identified by the TE Router_ID. The latter is a control plane identifier defined as . RFC 3630: Router_Address (top level) TLV of the Type 1 TE LSA . RFC 3784: Traffic Engineering Router ID TLV (Type 134) s/data plane (abstract) node/physical node/ 1. Use same terminology as defined in previous bullet 2. Why say "abstract" for something that is physical? Section 5.1 This contains multiple references to RFCs. Can you please insert square bracket citations. Section 5.1 - Li is a logical control plane entity that is associated to a single data plane (abstract) node. The Li is identified by the TE Router_ID. The latter is a control plane identifier defined as . RFC 3630: Router_Address (top level) TLV of the Type 1 TE LSA . RFC 3784: Traffic Engineering Router ID TLV (Type 134) Note: this document does not define what the TE Router ID is. This document simply states the use of the TE Router ID to identify the Li. Other documents (the referenced RFC 3630 and RFC 3784) provide the definitions. There appear to be two contradictory paragraphs here. The first says "...defined as...". The second says "...does not define..." Need to tweak the words. Section 5.1 Thus, the routing protocol MUST be able to advertise multiple TE Router IDs. You need to comment on whether this requires a modification to the protocols as currently specified or not. This is, after all, the purpose of this document. Section 5.1 [ASON-REQ], does not enter into the identification of the logical s/ASON-REQ/ASON-RR/ Section 5.2 Under these conditions, GMPLS link state routing protocols provide the capability for RA Identification. Add "without further modification" Section 5.3 We focus on routing information exchange between Ri entities (through routing adjacencies) within single hierarchical level. s/within single/within a single/ Section 5.3 Routing information mapping between levels may require specific guidelines. ...and these are out of scope? Section 5.3 The control plane does not transport Pi information as these are data plane addresses for which the Li/Pi mapping is kept (link) local - see for instance the transport LMP document [LMP-T] where s/information/identifiers/ Section 5.3 (three times) Are "666B.F999.AF10.222C" and "1.1.1.1" intended to be representative of specific address forms. If the latter is an IPv4 address, you should pick one from the range allowed for example IP addresses. Section 5.3 You should conclude with a statement that "OSPF and IS-IS therefore carry sufficient node identification information without further modification." Section 5.3 3) when using OSPF or ISIS as the IGP in support of traffic engineering, RFC 3477 RECOMMENDS that the Li value (referred to the "LSR Router ID") to be set to the TE Router ID value. Please add citation for [RFC3477]. Section 5.3.1 From the list of link attributes and characteristics (detailed in [ASON-RR], the Local Adaptation support information is missing as TE link attribute. GMPLS routing does not currently consider the use of dedicated TE link attribute(s) to describe the cross/inter-layer relationships. All other TE link attributes and characteristics are currently covered (see Table 1.) I think this could be written more clearly. Try... [ASON-RR] provides a list of link attributes and characteristics that need to be advertised by a routing protocol. All TE link attributes and characteristics are currently handled by OSPF and IS-IS (see Table 1) with the exception of Local Adaptation support. GMPLS routing does not currently consider the use of dedicated TE link attribute(s) to describe the cross/inter-layer relationships. Section 5.3.1 However, the representation of bandwidth requires further analysis i.e. GMPLS Routing defines an Interface Switching Capability Descriptor (ISCD) that delivers information about the (maximum/ minimum) bandwidth per priority an LSP can make use of. s/an LSP can make use of/of which an LSP can make use/ Section 5.3.1 The latter also may require definition of additional signal types (from those defined in [RFC 3496]) to represent contiguous concatenation i.e. STS-(3xN)c SPE / VC-4-Nc, N = 4, 16, 64, 256. s/also may/may also/ s/RFC 3496/RFC3946/ !!! Note that 3946 is a signaling I-D. It does not mention routing advertisement. You may need to add some detail here to explain how this RFC is relevant. Section 5.3.1 perspective. However, it introduces some lost of information. This lost of information affects the number of signals that can be used but not the range they cover. On the other hand, if additional technology specific information (such as capabilities) are s/lost/loss/ (twice) s/capabilities) are/capabilities) is/ Section 5.3.1 sub-TLV [GMPLS-OSPF] GMPLS-OSPF is not in the references. Section 5.3.1 Local SNPP link ID Link local part of the TE link identifier sub-TLV [GMPLS-ISIS] GMPLS-ISIS is not in the references. Section 5.3.1 Note: Link Attributes represent layer resource capabilities and their utilization. Undoubtedly true, but missing a little context? Section 5.3.2 Nodes attributes include the "Logical Node ID" (as detailed in Section 5.1) and the reachability information as described in Section 5.3.3. The use of "include" implies there are other node attributes not discussed here. Either discuss them (if they exist) or fix the text by s/include/are/ Section 5.3.3 defined per address family, e.g., IPv4 and IPv6). However, [OSPF- NODE] restricts to advertisement of Host addresses and not prefixes, and therefore requires enhancement (see below). s/restricts to advertisement/is restricted to advertisement/ Section 5.3.3 A similar mechanism does not exist for IS-IS as the Extended IP Reachability TLV [RFC3784] focuses on IP reachable end-points (terminating points), as its name indicates. I assume you mean that "An extension similar to [OSPF-NODE] is not required for IS-IS because the function is already included in the Reachability TLV. However, both the Reachability TLV and [OSPF-TLV] do not support the advertisement of reachability prefixes." Section 5.4. hence no specific capabilities are added to the routing protocol s/are/need to be/ Section 5.5 level hierarchy, and disallow the advertising of routing information s/disallow/disallows/ Section 5.5 downward in the hierarchy. [RFC2966] defines the up/down bit to [RFC2966] is not in the references. Section 5.5 [RFC1195] allows only advertising routing information upward in the RFC 1195 is not in the references. Section 5.5 downward in the hierarchy. [RFC2966] defines the up/down bit to RFC 2966 is not in the references. Section 5.5 OSPFv2 prevents that inter-area routes, which are learned from area 0 are not passed back to area 0. However, GMPLS makes use of Type 10 Rewrite as... OSPFv2 prevents inter-area routes (which are learned from area 0) from being passed back to area 0. However, GMPLS makes use of Type 10 Section 5.5 (area-local scope) LSA to propagate TE information [RFC3630], [GMPLS- s/LSA/LSAs/ Section 5.5 which Type 10 Opaque LSA may carry the information that particular s/LSA/LSAs/ s/particular/a particular piece of/ Section 5.5 back into an higher level RC. s/an/a/ Section 5.6 Link state protocols have been designed to detect topological changes (such as interface failures, link attributes modification). Convergence period is short and involves a minimum of routing information exchange. Do link state protocols detect the changes or propagate them? s/Convergence/The convergence/ s/and involves/and convergence involves/ Section 5.7 behalf multiple Li's creates the following issue as there is no more a 1:1 relationship between the Router_ID and the TE Router_ID but a /more/longer/ Section 5.7 and link remote (unnumbered) ID association may be not unique per s/be not/not be/ Section 5.7 retrieve the [Li;Lj] relationship(s). In brief, as unnumbered links The RFC Ed. prefers that square brackets [] are used only for citations. Can you use {}? Section 6 respectively case 1), 2), 3) and 4). Additional base scenarios (being not combinations or decomposition of entities) may further complete this set in a future revision of this document. Remove this sentence. Section 6 In the below Figure 1: s/In the below Figure 1:/In Figure 1 below: Section 6 Please add captions to the figures. At the moment it is not completely clear that cases 1, 2 and 3 appear in Figure 1, while case 4 appears in Figure 3, and Figure 2 is a special representation of case 1. New Section 7 Please add a new section after Section 6 "Summary of Necessary Additions to OSPF and IS-IS" It is too hard for the reader to extract these from the I-D with complete certainty. Section 8.1 Is [LMP-T] really normative? Is [OSPF-NODE] really normative? The draft will progress better if it is not. [RFC3667] and [RFC3668] don't need to be listed. [RFC3946] is not referenced. Section 8.2 [ASON-RR] is surely normative. Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 03 Oct 2005 19:51:41 +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-rsvp-restart-ext-04.txt Message-Id: Date: Mon, 03 Oct 2005 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 : Extensions to GMPLS RSVP Graceful Restart Author(s) : A. Satyanarayana, et al. Filename : draft-ietf-ccamp-rsvp-restart-ext-04.txt Pages : 24 Date : 2005-10-3 This document describes extensions to the RSVP Graceful Restart mechanisms defined in RFC 3473. The extensions enable the recovery of RSVP signaling state based on the Path message last sent by the node being restarted. Previously defined Graceful Restart mechanisms, also called recovery from nodal faults, permit recovery of signaling state from adjacent nodes when the data plane has retained the associated forwarding state across a restart. These mechanisms do not fully support signaling state recovery on ingress nodes or recovery of all RSVP objects. The presented extensions use the RSVP Hello extensions defined in RFC 3209, and extensions for state recovery on nodal faults defined in RFC 3473. With the presented extensions the restarting node can recover all previously transmitted Path state including the Explicit Route Object and the downstream (outgoing) interface identifiers. The extensions can also be used to recover signaling state after the restart of an ingress node. The extensions optionally support the use of Summary Refresh, defined in RFC 2961, to reduce the number of messages exchanged during the Recovery Phase when the restarting node has recovered signaling state locally for one or more LSPs. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rsvp-restart-ext-04.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-rsvp-restart-ext-04.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-rsvp-restart-ext-04.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: <2005-10-3121452.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-rsvp-restart-ext-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-rsvp-restart-ext-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-10-3121452.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 03 Oct 2005 19:51:34 +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-inter-domain-rsvp-te-02.txt Message-Id: Date: Mon, 03 Oct 2005 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 : Inter domain GMPLS Traffic Engineering - RSVP-TE extensions Author(s) : A. Ayyangar, J. Vasseur Filename : draft-ietf-ccamp-inter-domain-rsvp-te-02.txt Pages : 24 Date : 2005-10-3 This document describes extensions to Generalized Multi-Protocol Label Switching (GMPLS) Resource ReserVation Protocol - Traffic Engineering (RSVP-TE) signaling required to support mechanisms for the establishment and maintenance of GMPLS Traffic Engineering (TE) Label Switched Paths (LSPs), both packet and non-packet, that traverse multiple domains. For the purpose of this document, a domain is considered to be any collection of network elements within a common realm of address space or path computation responsibility. Examples of such domains include Autonomous Systems, IGP areas and GMPLS overlay networks. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-inter-domain-rsvp-te-02.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-inter-domain-rsvp-te-02.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-inter-domain-rsvp-te-02.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: <2005-10-3121247.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-inter-domain-rsvp-te-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-inter-domain-rsvp-te-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-10-3121247.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 03 Oct 2005 06:04:01 +0000 Message-ID: <074c01c5c5bf$34289f30$be849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Wijnen, Bert \(Bert\)" , , , Cc: Subject: Re: MIB Dr. review of draft-ietf-ccamp-gmpls-te-mib-09.txt Date: Fri, 30 Sep 2005 14:01:32 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Bert, > I have explained repeatedly (and it has been in the MIB review guidelines > (now RFC4181) for a long time), the 32 char limit is relaxed. > > And in general, consistency is MUCH more important (I think) than > limiting to 32 chars. Yes, yes. But you are replying to an old message from before you made that point. As soon as you made the point I acquiesced and have made many changes in the new versions we are working on. Thanks, Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 03 Oct 2005 05:49:30 +0000 Message-ID: <000501c5c684$68d68880$6b849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Reminder: ASON Routing evaluation Last Call Date: Sat, 1 Oct 2005 11:56:36 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Just a reminder that this WG last call ends on 2nd October. I recall that in Paris there were a couple of comments that "few minor editorial changes" were needed. If you don't comment during the last call, could be that you have changed your mind. Thanks, Adrian