From owner-ccamp@ops.ietf.org Thu Apr 1 12:31:12 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23057 for ; Thu, 1 Apr 2004 12:31:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9626-0004Qi-00 for ccamp-archive@ietf.org; Thu, 01 Apr 2004 12:31:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B961B-0004JY-00 for ccamp-archive@ietf.org; Thu, 01 Apr 2004 12:30:18 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1B960Q-0004Cq-00 for ccamp-archive@ietf.org; Thu, 01 Apr 2004 12:29:30 -0500 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B95iG-000L0x-13 for ccamp-data@psg.com; Thu, 01 Apr 2004 17:10:44 +0000 Received: from [195.8.69.103] (helo=cerberus.uk.clara.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B95hs-000KwW-22; Thu, 01 Apr 2004 18:10:20 +0100 Received: from du-069-0754.access.clara.net ([217.158.156.245] helo=Puppy) by cerberus.uk.clara.net with smtp (Exim 4.22) id 1B95hp-000AOK-6Q; Thu, 01 Apr 2004 18:10:18 +0100 Message-ID: <00aa01c4180c$368497f0$7a9c9ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Cc: "'Kireeti Kompella'" , Subject: Fw: I-D ACTION:draft-ietf-ccamp-gmpls-g709-07.txt Date: Thu, 1 Apr 2004 15:30:06 +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-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Alex, draft-ietf-ccamp-gmpls-g709 has successfully completed working group last call and has been marked up to fix the minor comments that were raised. Would you take this draft to the IESG on our behalf with a view to it becoming a standards track RFC. Thank you (let me know if there is any other formal process I should complete). Adrian ----- Original Message ----- From: To: Sent: Thursday, April 01, 2004 2:11 PM Subject: I-D ACTION:draft-ietf-ccamp-gmpls-g709-07.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 MPLS Signalling Extensions for G.709 Optical Transport Networks Control > Author(s) : D. Papadimitriou > Filename : draft-ietf-ccamp-gmpls-g709-07.txt > Pages : 21 > Date : 2004-3-31 > > This document is a companion to the Generalized MPLS (GMPLS) > signalling documents. It describes the technology specific > information needed to extend GMPLS signalling to control Optical > Transport Networks (OTN); it also includes the so-called pre-OTN > developments. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-g709-07.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-g709-07.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-g709-07.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 Thu Apr 1 13:23:15 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24772 for ; Thu, 1 Apr 2004 13:23:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B96qU-0001x7-00 for ccamp-archive@ietf.org; Thu, 01 Apr 2004 13:23:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B96pZ-0001pL-00 for ccamp-archive@ietf.org; Thu, 01 Apr 2004 13:22:22 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1B96ob-0001jj-00 for ccamp-archive@ietf.org; Thu, 01 Apr 2004 13:21:22 -0500 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B96bB-0003VS-Lc for ccamp-data@psg.com; Thu, 01 Apr 2004 18:07:29 +0000 Received: from [12.7.169.25] (helo=w2ksjexg01.ciena.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B96ay-0003U3-Ad for ccamp@ops.ietf.org; Thu, 01 Apr 2004 19:07:16 +0100 Received: by w2ksjexg01.ciena.com with Internet Mail Service (5.5.2657.72) id ; Thu, 1 Apr 2004 10:06:43 -0800 Message-ID: <829F074A10F98943A218DC363D09C92A01476BE6@w2ksjexg06.ciena.com> From: "Ong, Lyndon" To: "'Dimitri.Papadimitriou@alcatel.be'" Cc: "'Lou Berger'" , Kireeti Kompella , ccamp@ops.ietf.org Subject: RE: Label type to be used Date: Thu, 1 Apr 2004 10:07:06 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Hi Dimitri, I think it was my mistake, in testing I have seen people use FSC to describe an interface to an opaque OXC with SDH framing when they wish to have the entire signal (minus some SDH overhead) switched rather than sorting through individual channels. On further reading of draft-ietf-ccamp-gmpls-routing-09.txt it looks like section 3.5 specifically describes this as a case where LSC would be advertised rather than FSC, since there is conceptually a single wavelength, is this still correct? Thanks, Lyndon -----Original Message----- From: Dimitri.Papadimitriou@alcatel.be [mailto:Dimitri.Papadimitriou@alcatel.be] Sent: Saturday, March 27, 2004 4:31 AM To: Ong, Lyndon Cc: 'Lou Berger'; Kireeti Kompella; ccamp@ops.ietf.org Subject: Re: Label type to be used the proposal that makes a fully transparent Sonet/SDH encoded capable link appearing as [X,LSC] or [LSC,X], or [LSC,LSC] w/ a label defined as a port and/or lambda is aligned with the evolution of the definition towards OTN (coming from the so-called pre-OTN) technology and thus probably better than trying to retain the TDM value for it (with several flavours) so you would have something like this when trying to harmonize in between the several documents we have tnat deals with this specific representation issue, i also think it provides the distinction you're asking for b/w fiber and so-called clear channels: 2.4.4. Lambda-Switch Capable If an interface is of type LSC, it means that the node receiving data over this interface can recognize and switch individual lambdas within the interface. An interface that allows only one lambda per interface, and switches just that lambda is of type LSC. > This includes interfaces that only support fully transparent SONET/SDH > signals, as defined in [GMPLS-SONET-SDH]. [...] 2.4.7. Interface Switching Capabilities and Labels [PSC, PSC] - label is carried in the "shim" header [RFC3032] > [TDM, TDM] - label represents a timeslot ([GMPLS-SONET-SDH], [GMPLS-G709]) > [LSC, LSC] - label represents a G.709 OCh/lambda/port > [FSC, FSC] - label represents a fiber (i.e. physical port) > [PSC, TDM] - label represents a timeslot ([GMPLS-SONET-SDH], [GMPLS-G709]) > [PSC, LSC] - label represents a G.709 OCh/lambda/port > [PSC, FSC] - label represents a fiber > [TDM, LSC] - label represents a G.709 OCh/lambda/port > [TDM, FSC] - label represents a fiber > [LSC, FSC] - label represents a fiber > Note: except when explicitly indicated the label encoding MUST follow > the rules defined in [RFC3471] Section 3.2. ps: in fact one sees here that for the "timeslot" case, the switching type TDM value equates the encoding one Ong, Lyndon wrote: > Hi Lou, > > Your proposed text looks pretty good to me. > > Side note: is there a way that the > existing text can be clarified to distinguish > between the case of only one lambda allowed > on an interface and the case of fiber switching? > > Currently the text seems to allow an overlap > in the case of a non-channelized OC-12/48/etc. as in > a sense there is only one "lambda" but you would > typically request fiber switching. > > Cheers, > > Lyndon > > -----Original Message----- > From: Lou Berger [mailto:lberger@movaz.com] > Sent: Friday, March 26, 2004 11:17 AM > To: Kireeti Kompella > Cc: ccamp@ops.ietf.org; John Drake > Subject: RE: Label type to be used > > > Kireeti, > I think John's points on (a) and (c) are reasonable. I think the > only changes needed to the draft-ietf-ccamp-gmpls-routing-09.txt to make > this clear are: > > 2.4.4. Lambda-Switch Capable > > If an interface is of type LSC, it means that the node receiving data > over this interface can recognize and switch individual lambdas > within the interface. An interface that allows only one lambda per > interface, and switches just that lambda is of type LSC. > > This includes interfaces that only support fully transparent SONET/SDH > > signals, as defined in [GMPLS-SONET-SDH]. > > and > [PSC, PSC] - label is carried in the "shim" header [RFC3032] > [TDM, TDM] - label represents a TDM time slot [GMPLS-SONET-SDH] > > [LSC, LSC] - label represents a lambda/port > [FSC, FSC] - label represents a port on an OXC > [PSC, TDM] - label represents a TDM time slot [GMPLS-SONET-SDH] > > [PSC, LSC] - label represents a lambda/port > [PSC, FSC] - label represents a port > > [TDM, LSC] - label represents a lambda/port > [TDM, FSC] - label represents a port > [LSC, FSC] - label represents a port > > Lou > > PS This matches all but one implementation we've interoperated with. > > At 01:49 PM 3/26/2004 -0500, John Drake wrote: > > > >>>-----Original Message----- >>>From: Kireeti Kompella >> >>[mailto:kireeti@juniper.net] >> >>>Sent: Thursday, March 18, 2004 9:58 AM >>>To: ccamp@ops.ietf.org >>>Subject: Label type to be used >>> >>>Hi, >>> >>>Arthi and Lou pointed out the following typos in the GMPLS routing doc >>>(draft-ietf-ccamp-gmpls-routing-09.txt) which is now in the RFC >>>Editor's queue: >>> >>>In section 2.4.7 is the following table defining the type of label >>>for various combinations of switching types: >>> >>> [PSC, PSC] - label is carried in the "shim" header [RFC3032] >>> [TDM, TDM] - label represents a TDM time slot [GMPLS-SONET-SDH] >>> [LSC, LSC] - label represents a lambda >>> [FSC, FSC] - label represents a port on an OXC >>> [PSC, TDM] - label represents a TDM time slot [GMPLS-SONET-SDH] >>> [PSC, LSC] - label represents a lambda >>> [PSC, FSC] - label represents a port >>> [TDM, LSC] - label represents a lambda >>> [TDM, FSC] - label represents a port >>> [LSC, FSC] - label represents a port >>> >>>The one at issue is [PSC, LSC]; above it says that the label >>>represents a lambda; and in the case of [PSC, TDM] with a fully >>>transparent signal, the above indicates the label represents a TDM >>>time slot. The proposal is to change this to: >>> >>> [PSC, PSC] - label is carried in the "shim" header [RFC3032] >>> [TDM, TDM] - label represents a TDM time slot [GMPLS-SONET-SDH] >>> [LSC, LSC] - label represents a lambda >>> [FSC, FSC] - label represents a port on an OXC >>> [PSC, TDM] - fully transparent signal: label represents a port >>> ("transparency" is defined in [GMPLS-SONET-SDH]) >>> [PSC, TDM] - non-transparent signal: label represents a TDM time >>> slot [GMPLS-SONET-SDH] >>> [PSC, LSC] - label represents a port >>> [PSC, FSC] - label represents a port >>> [TDM, LSC] - label represents a lambda >>> [TDM, FSC] - label represents a port >>> [LSC, FSC] - label represents a port >>> >>>Please respond by Friday 3/26, 5pm PST with comments on: >>> >>>a) do you agree with the above change? >> >>[John Drake] >> >>I don't have a problem with the [PSC, LSC] change but I don't >>understand the distinction between transparent and non-transparent >>TDM as it pertains to GMPLS routing. As I indicated in a previous >>e-mail, I think the transparent TDM case should be handled with a >>switching type of LSC and an encoding type of SDH/SONET, and I think >>that this should be specified in the SDH/SONET I-D, where the distinction >>between transparent and non-transparent TDM is defined, rather than in >>this document. >> >> >>>b) in your implementation today, what do expect the label to represent >>> i) in the case of [PSC, LSC]? >> >>[John Drake] >> >>Port/lambda >> >> >>> ii) in the case of [PSC, TDM] with a fully transparent signal? >>>c) if you implement as the draft says, would it be a hardship to change >>> this? >> >>[John Drake] >> >>N/A. Labels for SDH/SONET are defined in the SDH/SONET I-D and it's pretty >>clear about which types of labels are in the transparent and non-transparent >>TDM cases. >> >> >>>If we can get closure on this, I'll take up the task of modifying the >>>pending RFC with the ADs. >>> >>>Kireeti. >>>------- > > > -- Papadimitriou Dimitri E-mail : dimitri.papadimitriou@alcatel.be E-mail : dpapadimitriou@psg.com Webpage: http://psg.com/~dpapadimitriou/ Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium Phone : +32 3 240-8491 From owner-ccamp@ops.ietf.org Thu Apr 1 15:08:14 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28437 for ; Thu, 1 Apr 2004 15:08:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B98U5-0004eA-00 for ccamp-archive@ietf.org; Thu, 01 Apr 2004 15:08:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B98TC-0004Xh-00 for ccamp-archive@ietf.org; Thu, 01 Apr 2004 15:07:22 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1B98ST-0004Sb-00 for ccamp-archive@ietf.org; Thu, 01 Apr 2004 15:06:37 -0500 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B98DE-000I0p-Jj for ccamp-data@psg.com; Thu, 01 Apr 2004 19:50:52 +0000 Received: from [171.71.176.70] (helo=sj-iport-1.cisco.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B98D3-000Hzb-M3 for ccamp@ops.ietf.org; Thu, 01 Apr 2004 20:50:41 +0100 X-BrightmailFiltered: true Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i31JoWn2016869; Thu, 1 Apr 2004 11:50:32 -0800 (PST) Received: from jvasseur-w2k01.cisco.com (che-vpn-cluster-2-109.cisco.com [10.86.242.109]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id LAA10137; Thu, 1 Apr 2004 11:50:30 -0800 (PST) Message-Id: <4.3.2.7.2.20040401144213.020c7ce0@wells.cisco.com> X-Sender: jvasseur@wells.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 01 Apr 2004 14:50:28 -0500 To: raymond zhang From: Jean Philippe Vasseur Subject: Re: Some minor comments on the loose-path-opt draft Cc: y.ikejiri@ntt.com, ccamp@ops.ietf.org In-Reply-To: <6.0.3.0.2.20040329220222.02a41a10@delta.info.net> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Hi Raymond, Thanks for your comments and support for the draft - see in line. At 09:25 AM 4/1/2004 -0800, raymond zhang wrote: >Hi JP and Yuichi, > >Just gone through=20 >http://www.ietf.org/internet-drafts/draft-vasseur-ccamp-loose-path-reopt-00= .txt=20 >and here are some minor comments: > >This draft describes a very useful mechanism solving part of the reopt=20 >issues documented in the inter-AS requirements draft=20 >(http://www.ietf.org/internet-drafts/draft-ietf-tewg-interas-mpls-te-req-06= .txt)... > >1. Editorial comments: > >1.1. Editorial - clean up the strange characters, for example, in Section= =20 >4.2, page 5 >" ...=AA=AALink-UP=AA=AA event). " ok >1.2. Section 1, page 2, " >A loosely routed explicit path is as a path specified as a ..." > > >The "as" proceeding "a path" above should be removed. right, thanks. >1.3. Section 1, page 2, "...of the Ipv4 prefix sub-object..." >should IPv6 prefix be included as well ? > >Also in Section 3.2, may need to list a IPv6 error_spec object also... Agree, we'll fix that, >1.4. In section 4.3.1, page 7: > >"Example: > >Let call " > >It should be "Let's call..." ok >1.5. In section 4.3.1, page 7: >"... pi such that li is a next (loose) hop of pi for i=3D1+n" > >- delete "pi" >- "i=3D1+n" should be changed to "i=3D1 to n" >- it may read better if you change "for i=3D1 to n" to for "i=3D1 to n= which=20 >is illustrated in the following example:" > >Then after "Pn=3D" > >add "where L1=3DR3 is the next loose hop of P1=3DR1, etc." right >2. Other comments: > >2.1. In section 4.3.1, page 7 >"- If a better path can be found, the LSR MUST > immediately send a Path Error to the head-end LSR > (Error code 25 (Notify), sub-code=3D6 (better path > exists))" > >I wonder if you should also add "and go ahead with reopt by sending RSVP=20 >path messages for the new path". Otherwise there is no action described=20 >for this mid-point LSR what it will do after it found a better path and=20 >notify the HE LSR. In this case, the TE LSP is contiguous, hence the mid-point's role is just= =20 to notify of the existence of a better path (or the requirement for local=20 maintenance) in some downstream area/AS. Note that it cannot locally=20 reoptimize since the LSP ID would not match. Moreover, the intention is to= =20 let the Head-end LSR decide on whether to reoptimize depending on the TE=20 LSP attributes (pending back-off, ...). Does that make sense ? >2.2. Some general comments regarding the mode of operations > >There are couple more cases which may be considered: > >Mode 1 If it is TE-LSP HE LSR initiated, >- Midpoint LSR can ignore this request and not to perform reopt even if=20 >there is a better path within its AS; > >This can either be part of the interconnect agreement between two=20 >providers or to protect transit AS for reasons such as HE LSR triggers=20 >reopt in an unusually high frequency due to mis-configuration... But=20 >mid-point LSR does need to notify the HE LSR why via patherr msg. Totally agree, this is a good point which will be in the next revision. >Mode 2 If it is mid-point LSR initiated and midpoint LSR find out there is= =20 >a better path for an existing TE-LSP and notifies the TE-LSP HE, TE-LSP HE= =20 >LSR does not want to reopt, for example, configured not to repot that way= =20 >for operational reasons at that time. (except for local link maint.=20 >reasons of course) I am not sure what's the process here next - both HE=20 >and midpoint LSR do nothing and continue to refresh ? Yes, head-end and the mid-point LSRs could respectively ignore the polling= =20 and the notification but this is again a good point which is worth being=20 clarified. Thanks for your useful comments: they will be incorporated in the next=20 revision. JP. >Regards, >Raymond > > > From owner-ccamp@ops.ietf.org Thu Apr 1 16:02:20 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02441 for ; Thu, 1 Apr 2004 16:02:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B99KP-0003IF-00 for ccamp-archive@ietf.org; Thu, 01 Apr 2004 16:02:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B99JX-0003DX-00 for ccamp-archive@ietf.org; Thu, 01 Apr 2004 16:01:28 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1B99Is-00038Y-00 for ccamp-archive@ietf.org; Thu, 01 Apr 2004 16:00:46 -0500 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B99Av-0000iL-VB for ccamp-data@psg.com; Thu, 01 Apr 2004 20:52:33 +0000 Received: from [171.71.176.72] (helo=sj-iport-3.cisco.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B99Aq-0000i2-Lx for ccamp@ops.ietf.org; Thu, 01 Apr 2004 21:52:28 +0100 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 01 Apr 2004 13:00:18 +0000 Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i31KqJUe002081; Thu, 1 Apr 2004 12:52:23 -0800 (PST) Received: from jvasseur-w2k01.cisco.com (che-vpn-cluster-2-109.cisco.com [10.86.242.109]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id MAA08386; Thu, 1 Apr 2004 12:52:18 -0800 (PST) Message-Id: <4.3.2.7.2.20040401154828.03ce9410@wells.cisco.com> X-Sender: jvasseur@wells.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 01 Apr 2004 15:52:15 -0500 To: Dimitri.Papadimitriou@alcatel.be From: Jean Philippe Vasseur Subject: Re: TR : I-D ACTION:draft-ietf-tewg-interarea-mpls-te-req-00.txt Cc: LE ROUX Jean-Louis FTRD/DAC/LAN , ccamp@ops.ietf.org, mpls@UU.NET In-Reply-To: <406B0542.7020103@alcatel.be> References: <4.3.2.7.2.20040330071929.062659e8@wells.cisco.com> <4.3.2.7.2.20040330071929.062659e8@wells.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Hi Dimitri, At 07:52 PM 3/31/2004 +0200, Dimitri.Papadimitriou@alcatel.be wrote: >hi jp, > >see in-line: > >>Thanks for your useful comments here. See below, >>At 02:18 PM 3/30/2004 +0200, Dimitri.Papadimitriou@alcatel.be wrote: >> >>>hi jl, here below several comments on this updated version of the document: >>> >>>1) section 5.3.1 mentions: >>> >>>"The solution MUST entirely preserve the concept of IGP hierarchy. In >>> other words, flooding of TE link information across areas MUST be >>> precluded." >>> >>>section 5.3.2 mentions: >>> >>>"The solution MUST also not increase IGP load which could compromise >>> IGP scalability. In particular, a solution satisfying those >>> requirements MUST not require for the IGP to carry some unreasonable >>> amount of extra information and MUST not unreasonably increase the >>> IGP flooding frequency." >>> >>>but section 7.12 tells: >>> >>>"The discovery mechanism SHOULD >>> be applicable across multiple IGP areas, and SHOULD not impact the >>> IGP scalability, provided that IGP extensions are used for such a >>> discovery mechanism." >>> >>>-> would it be possible to align these requirements, i get the >>>impression (please confirm) that you preclude TE link information but >>>you would allow for node information (auto-mesh) ? note also that the >>>section 7.12 doesn't tell us a lot about the expected distribution of the mesh >> >>The solution MUST preclude to flood TE-related link information and MUST >>not compromise the IGP scalability in any circumstances. That being said, >>IGP based mechanisms can be used for the discovery which will respect the >>requirement mentioned above, > >i understand to what you're referring, but please make it clear >imho it would help if in section 7.12 the exact meaning of the >following "*some* discovery mechanisms" was detailed so that the >reader can more accurately assess the scope of the above ok, will do >>>2) section 7.3 >>> >>>" In the context of this requirement document, an optimal path is >>> defined as the shortest path across multiple areas taking into >>> account either the IGP or TE metric. " >>> >>>are you referring here to >>> >>> >>>would you clarify ? >> >>Sure, we will add some text. The reason for this clarification is that >>there are a multitude of definitions for an optimal path: paths that >>minimize the max link utilization, call set up failure, ... here we just >>refer to the ability to compute a shortest path (using either the IGP or >>TE metric). > >ok > >>>3) section 7.3 >>> >>>it is not clear for me what is behind the last part of the following >>>sentence >>> >>>"So a solution should support both mechanisms, and SHOULD allow >>> the operator to select by configuration, and on a per-LSP basis, the >>> required level of optimality. " >>> >>>what is meant by "level of optimality" ? is it simply "optimal - >>>sub-optimal" or do you have something else in mind ? >> >>We will clarify. The idea is that the ability to compute an end to end >>shortest path may not be required for all inter-area TE LSPs. Hence the >>solution should allow the operator to select the appropriate path >>computation method. > >ok, would be interesting to see whether operators would like to have >selection based on the computational method (allow for intermediate >computation or any other option suitable in this context) or based on the >optimality level (then the solution itself selects the appropriate >computational method) or simply both > >>>4) section 7.4 >>> >>>"Another example is the requirement to set up multiple TE LSPs between >>> a pair of LSRs residing in different IGP areas in case a single TE >>> LSP satisfying the set of requirements could not be found. " >>> >>>why in such a case diversity would be desirable ? >> >>for either path protection or load balancing while minimizing the impact >>in case of failure. >> >>>got the impression that if a single path would have been feasible it >>>would have been selected in this case - isn't it ? >> >>That being said, we need to rephrase, I agree with you that this >>paragraph is not clear. It should read: >>"Another example is the requirement to set up multiple TE LSPs between a >>pair of LSRs residing in different IGP areas. For instance, this would >>occur if TE LSP satisfying for instance the bandwidth requirement could >>be found, hence, requiring to set up multiple TE LSPs" > >the former point(s) seem clearer, is it "could be found" or "could not be >found" ? oups ... typo, yes "could not be found" >>>5) section 7.7 >>> >>>"This may reduce the recovery delay, but with the risk of >>> multiple crankbacks, and sub-optimality. " >>> >>>i agree, but this is valid iff the head-end has initially computed an >>>end-to-end optimal path, >> >>more exactly this applies to contiguous LSP. For sub-optimality this >>applies to any kind of LSP. > >well i think that a contiguous LSP can still be sub-optimal hence >i would suggest to not implicitly attach the crankback functionality >to the signaling method, but to make clear what are the potential >issues in terms of optimality as said "iff the path was initially >computed as an end-to-end optimal" not sure to see your point here ? >>>also unclear if you refer also here to the provisioning delay ? >>> >>>editorially speaking it is also a bit unclear why you've splitted >>>section 7.7 and section 7.8 both refers to inter-area lsp recovery > >i don't know if this could be taken into account, this would simplify >reading and subsequent utilisation of the document ok >>>6) section 7.11 >>> >>>would it be possible to mention what's expected (or not expected) in >>>terms also of hard preemption ? >> >>ok > >just a hint here, is my understanding correct that the following sentence >"The lower priority LSP is not torn down and can continue to forward >traffic on a best-effort basis." infers that you would have to priority >high/low only so i'd would instead be more generic here in >terms of priorities the latter >>>7) section 8.2 >>> >>>what's meant by stability ? ie stability of what ? (for instance, as i >>>read the document, but please correct me, stability and re-optimization >>>are imho two features that are going in somehow opposite directions so a >>>trade-off has to be found here) >> >>We will clarify. > >ok > >>thanks for your comments ! > >hope to see the next version soon, would also be interesting to see other >people commenting here sure, thanks for your comments. Note that this draft is already the collection of many feed-backs from several SPs. thanks. JP. >thanks, >- dimitri. > >>JP. >> >>>thanks in advance, >>>- dimitri. >>> >>>LE ROUX Jean-Louis FTRD/DAC/LAN wrote: >>> >>>>Hi all, >>>>Thanks in advance for your comments on this new revision of inter-area >>>>TE requirements. >>>>Regards, >>>>JL >>>> >>>>>A New Internet-Draft is available from the on-line Internet-Drafts >>>>>directories. This draft is a work item of the Internet Traffic >>>>>Engineering Working Group of the IETF. >>>>> >>>>> Title : Requirements for Inter-area MPLS Traffic >>>> >>>>Engineering >>>> >>>>> Author(s) : J. Le Roux, et al. >>>>> Filename : draft-ietf-tewg-interarea-mpls-te-req-00.txt >>>>> Pages : 20 >>>>> Date : 2004-3-26 >>>>> >>>>>This document lists a detailed set of functional requirements for the >>>>>support of inter-area MPLS Traffic Engineering (inter-area MPLS TE) >>>>>which could serve as a guideline to develop the required set of >>>>>protocol extensions. >>>>> >>>>>A URL for this Internet-Draft is: >>>>>http://www.ietf.org/internet-drafts/draft-ietf-tewg-interarea-mpls-te-r >>>> >>>>eq-00.txt >>>> >>>>>To remove yourself from the IETF Announcement list, send a message to >>>>>ietf-announce-request with the word unsubscribe in the body of the >>>>>message. >>>>> >>>>>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-tewg-interarea-mpls-te-req-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 >>>> >>> >>>-- >>>Papadimitriou Dimitri >>>E-mail : dimitri.papadimitriou@alcatel.be >>>E-mail : dpapadimitriou@psg.com >>>Webpage: http://psg.com/~dpapadimitriou/ >>>Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium >>>Phone : +32 3 240-8491 >>> > >-- >Papadimitriou Dimitri >E-mail : dimitri.papadimitriou@alcatel.be >E-mail : dpapadimitriou@psg.com >Webpage: http://psg.com/~dpapadimitriou/ >Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium >Phone : +32 3 240-8491 > > From owner-ccamp@ops.ietf.org Thu Apr 1 17:35:18 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05016 for ; Thu, 1 Apr 2004 17:35:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9AmO-0004B9-00 for ccamp-archive@ietf.org; Thu, 01 Apr 2004 17:35:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9AlS-000441-00 for ccamp-archive@ietf.org; Thu, 01 Apr 2004 17:34:23 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1B9AkW-0003x2-00 for ccamp-archive@ietf.org; Thu, 01 Apr 2004 17:33:24 -0500 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B9ATi-000BeI-QP for ccamp-data@psg.com; Thu, 01 Apr 2004 22:16:02 +0000 Received: from [64.208.49.165] (helo=smail.alcatel.fr) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B9ATg-000Bde-Ft for ccamp@ops.ietf.org; Thu, 01 Apr 2004 23:16:00 +0100 Received: from bemail05.netfr.alcatel.fr (bemail05.netfr.alcatel.fr [155.132.251.11]) by smail.alcatel.fr (ALCANET/NETFR) with ESMTP id i31MFfpv021980; Fri, 2 Apr 2004 00:15:42 +0200 Received: from alcatel.be ([138.203.118.2]) by bemail05.netfr.alcatel.fr (Lotus Domino Release 5.0.11) with ESMTP id 2004040200153860:204 ; Fri, 2 Apr 2004 00:15:38 +0200 Message-ID: <406C950B.7010706@alcatel.be> Date: Fri, 02 Apr 2004 00:17:47 +0200 From: Dimitri.Papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.5) Gecko/20030925 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Ong, Lyndon" Cc: "'Lou Berger'" , Kireeti Kompella , ccamp@ops.ietf.org Subject: Re: Label type to be used References: <829F074A10F98943A218DC363D09C92A01476BE6@w2ksjexg06.ciena.com> In-Reply-To: <829F074A10F98943A218DC363D09C92A01476BE6@w2ksjexg06.ciena.com> X-MIMETrack: Itemize by SMTP Server on BEMAIL05/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 04/02/2004 00:15:39, Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 04/02/2004 00:15:41, Serialize complete at 04/02/2004 00:15:41 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed X-Alcanet-MTA-scanned-and-authorized: yes Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit hi lyndon, Ong, Lyndon wrote: > Hi Dimitri, > > I think it was my mistake, in testing I have seen people use > FSC to describe an interface to an opaque OXC with SDH framing > when they wish to have the entire signal (minus some SDH > overhead) switched rather than sorting through individual > channels. On further reading of draft-ietf-ccamp-gmpls-routing-09.txt > it looks like section 3.5 specifically describes this as a > case where LSC would be advertised rather than FSC, since > there is conceptually a single wavelength, is this > still correct? yes, this is why i have proposed the below to adapt the below in-line with the following paragraph of section 3.5 " An interface on an opaque OXC handles a single wavelength, and cannot switch multiple wavelengths as a whole. Thus, an interface on an opaque OXC is always LSC, and not FSC, irrespective of whether there is DWDM external to it." thanks, - dimitri. > Thanks, > > Lyndon > > -----Original Message----- > From: Dimitri.Papadimitriou@alcatel.be > [mailto:Dimitri.Papadimitriou@alcatel.be] > Sent: Saturday, March 27, 2004 4:31 AM > To: Ong, Lyndon > Cc: 'Lou Berger'; Kireeti Kompella; ccamp@ops.ietf.org > Subject: Re: Label type to be used > > > the proposal that makes a fully transparent Sonet/SDH encoded capable > link appearing as [X,LSC] or [LSC,X], or [LSC,LSC] w/ a label defined as > a port and/or lambda is aligned with the evolution of the definition > towards OTN (coming from the so-called pre-OTN) technology and thus > probably better than trying to retain the TDM value for it (with several > flavours) > > so you would have something like this when trying to harmonize in > between the several documents we have tnat deals with this specific > representation issue, i also think it provides the distinction you're > asking for b/w fiber and so-called clear channels: > > 2.4.4. Lambda-Switch Capable > > If an interface is of type LSC, it means that the node receiving data > over this interface can recognize and switch individual lambdas > within the interface. An interface that allows only one lambda per > interface, and switches just that lambda is of type LSC. > > This includes interfaces that only support fully transparent SONET/SDH > > signals, as defined in [GMPLS-SONET-SDH]. > > [...] > > 2.4.7. Interface Switching Capabilities and Labels > > [PSC, PSC] - label is carried in the "shim" header [RFC3032] > > [TDM, TDM] - label represents a timeslot ([GMPLS-SONET-SDH], > [GMPLS-G709]) > > [LSC, LSC] - label represents a G.709 OCh/lambda/port > > [FSC, FSC] - label represents a fiber (i.e. physical port) > > [PSC, TDM] - label represents a timeslot ([GMPLS-SONET-SDH], > [GMPLS-G709]) > > [PSC, LSC] - label represents a G.709 OCh/lambda/port > > [PSC, FSC] - label represents a fiber > > [TDM, LSC] - label represents a G.709 OCh/lambda/port > > [TDM, FSC] - label represents a fiber > > [LSC, FSC] - label represents a fiber > > > Note: except when explicitly indicated the label encoding MUST follow > > the rules defined in [RFC3471] Section 3.2. > > ps: in fact one sees here that for the "timeslot" case, the switching > type TDM value equates the encoding one > > > Ong, Lyndon wrote: > >>Hi Lou, >> >>Your proposed text looks pretty good to me. >> >>Side note: is there a way that the >>existing text can be clarified to distinguish >>between the case of only one lambda allowed >>on an interface and the case of fiber switching? >> >>Currently the text seems to allow an overlap >>in the case of a non-channelized OC-12/48/etc. as in >>a sense there is only one "lambda" but you would >>typically request fiber switching. >> >>Cheers, >> >>Lyndon >> >>-----Original Message----- >>From: Lou Berger [mailto:lberger@movaz.com] >>Sent: Friday, March 26, 2004 11:17 AM >>To: Kireeti Kompella >>Cc: ccamp@ops.ietf.org; John Drake >>Subject: RE: Label type to be used >> >> >>Kireeti, >> I think John's points on (a) and (c) are reasonable. I think the >>only changes needed to the draft-ietf-ccamp-gmpls-routing-09.txt to make >>this clear are: >> >> 2.4.4. Lambda-Switch Capable >> >> If an interface is of type LSC, it means that the node receiving data >> over this interface can recognize and switch individual lambdas >> within the interface. An interface that allows only one lambda per >> interface, and switches just that lambda is of type LSC. >> > This includes interfaces that only support fully transparent SONET/SDH >> > signals, as defined in [GMPLS-SONET-SDH]. >> >>and >> [PSC, PSC] - label is carried in the "shim" header [RFC3032] >> [TDM, TDM] - label represents a TDM time slot [GMPLS-SONET-SDH] >> > [LSC, LSC] - label represents a lambda/port >> [FSC, FSC] - label represents a port on an OXC >> [PSC, TDM] - label represents a TDM time slot [GMPLS-SONET-SDH] >> > [PSC, LSC] - label represents a lambda/port >> [PSC, FSC] - label represents a port >> > [TDM, LSC] - label represents a lambda/port >> [TDM, FSC] - label represents a port >> [LSC, FSC] - label represents a port >> >>Lou >> >>PS This matches all but one implementation we've interoperated with. >> >>At 01:49 PM 3/26/2004 -0500, John Drake wrote: >> >> >> >> >>>>-----Original Message----- >>>>From: Kireeti Kompella >>> >>>[mailto:kireeti@juniper.net] >>> >>> >>>>Sent: Thursday, March 18, 2004 9:58 AM >>>>To: ccamp@ops.ietf.org >>>>Subject: Label type to be used >>>> >>>>Hi, >>>> >>>>Arthi and Lou pointed out the following typos in the GMPLS routing doc >>>>(draft-ietf-ccamp-gmpls-routing-09.txt) which is now in the RFC >>>>Editor's queue: >>>> >>>>In section 2.4.7 is the following table defining the type of label >>>>for various combinations of switching types: >>>> >>>> [PSC, PSC] - label is carried in the "shim" header [RFC3032] >>>> [TDM, TDM] - label represents a TDM time slot [GMPLS-SONET-SDH] >>>> [LSC, LSC] - label represents a lambda >>>> [FSC, FSC] - label represents a port on an OXC >>>> [PSC, TDM] - label represents a TDM time slot [GMPLS-SONET-SDH] >>>> [PSC, LSC] - label represents a lambda >>>> [PSC, FSC] - label represents a port >>>> [TDM, LSC] - label represents a lambda >>>> [TDM, FSC] - label represents a port >>>> [LSC, FSC] - label represents a port >>>> >>>>The one at issue is [PSC, LSC]; above it says that the label >>>>represents a lambda; and in the case of [PSC, TDM] with a fully >>>>transparent signal, the above indicates the label represents a TDM >>>>time slot. The proposal is to change this to: >>>> >>>> [PSC, PSC] - label is carried in the "shim" header [RFC3032] >>>> [TDM, TDM] - label represents a TDM time slot [GMPLS-SONET-SDH] >>>> [LSC, LSC] - label represents a lambda >>>> [FSC, FSC] - label represents a port on an OXC >>>> [PSC, TDM] - fully transparent signal: label represents a port >>>> ("transparency" is defined in [GMPLS-SONET-SDH]) >>>> [PSC, TDM] - non-transparent signal: label represents a TDM time >>>> slot [GMPLS-SONET-SDH] >>>> [PSC, LSC] - label represents a port >>>> [PSC, FSC] - label represents a port >>>> [TDM, LSC] - label represents a lambda >>>> [TDM, FSC] - label represents a port >>>> [LSC, FSC] - label represents a port >>>> >>>>Please respond by Friday 3/26, 5pm PST with comments on: >>>> >>>>a) do you agree with the above change? >>> >>>[John Drake] >>> >>>I don't have a problem with the [PSC, LSC] change but I don't >>>understand the distinction between transparent and non-transparent >>>TDM as it pertains to GMPLS routing. As I indicated in a previous >>>e-mail, I think the transparent TDM case should be handled with a >>>switching type of LSC and an encoding type of SDH/SONET, and I think >>>that this should be specified in the SDH/SONET I-D, where the distinction >>>between transparent and non-transparent TDM is defined, rather than in >>>this document. >>> >>> >>> >>>>b) in your implementation today, what do expect the label to represent >>>> i) in the case of [PSC, LSC]? >>> >>>[John Drake] >>> >>>Port/lambda >>> >>> >>> >>>> ii) in the case of [PSC, TDM] with a fully transparent signal? >>>>c) if you implement as the draft says, would it be a hardship to change >>>> this? >>> >>>[John Drake] >>> >>>N/A. Labels for SDH/SONET are defined in the SDH/SONET I-D and it's pretty >>>clear about which types of labels are in the transparent and non-transparent >>>TDM cases. >>> >>> >>> >>>>If we can get closure on this, I'll take up the task of modifying the >>>>pending RFC with the ADs. >>>> >>>>Kireeti. >>>>------- >> >> >> > -- Papadimitriou Dimitri E-mail : dimitri.papadimitriou@alcatel.be E-mail : dpapadimitriou@psg.com Webpage: http://psg.com/~dpapadimitriou/ Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium Phone : +32 3 240-8491 From owner-ccamp@ops.ietf.org Thu Apr 1 22:03:31 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA28949 for ; Thu, 1 Apr 2004 22:03:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9Exw-0001ot-00 for ccamp-archive@ietf.org; Thu, 01 Apr 2004 22:03:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9Ex1-0001jC-00 for ccamp-archive@ietf.org; Thu, 01 Apr 2004 22:02:36 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1B9EwA-0001dK-00 for ccamp-archive@ietf.org; Thu, 01 Apr 2004 22:01:42 -0500 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B9Ehw-000N4O-8x for ccamp-data@psg.com; Fri, 02 Apr 2004 02:47:00 +0000 Received: from [210.146.35.35] (helo=Yellow.japan-telecom.co.jp) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B9Ehu-000N45-L9 for ccamp@ops.ietf.org; Fri, 02 Apr 2004 03:46:58 +0100 Received: from sw41a201.japan-telecom.co.jp (localhost [127.0.0.1]) by Yellow.japan-telecom.co.jp with ESMTP id i322kr6q012653; Fri, 2 Apr 2004 11:46:53 +0900 (JST) Received: from VAIO505EXTREME ([172.31.172.50]) by rs41ag02.japan-telecom.co.jp (Lotus Domino Release 5.0.11) with ESMTP id 2004040211465107:55 ; Fri, 2 Apr 2004 11:46:51 +0900 From: "Hirokazu Ishimatsu" To: "'Yakov Rekhter'" , "'Adrian Farrel'" Cc: Subject: RE: Layer One VPNs Date: Fri, 2 Apr 2004 11:46:45 +0900 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcQVpcJ9yzpapSpfTAankV6DwgcZxwCtuGVQ In-Reply-To: <200403291535.i2TFZAJ51059@merlot.juniper.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-MIMETrack: Itemize by SMTP Server on RS41AG02/JTOA(Release 5.0.11 |July 24, 2002) at 04/02/2004 11:46:51 AM, Serialize by Router on SW41A201/JTOA(Release 5.0.12 |February 13, 2003) at 2004/04/02 11:46:53 AM, Serialize complete at 2004/04/02 11:46:53 AM Message-ID: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii" Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=MISSING_OUTLOOK_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit I agree with Yakov. Hiro Ishimatsu > -----Original Message----- > From: owner-ccamp@ops.ietf.org > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Yakov Rekhter > Sent: Tuesday, March 30, 2004 12:35 AM > To: Adrian Farrel > Cc: ccamp@ops.ietf.org > Subject: Layer One VPNs > > Adrian, > > > Hi, > > > > Although Layer One VPNs do not currently have a home in any IETF > > working group, we were the recipients of a liaison from ITU-T SG13 > > informing us about the work they are doing on this topic > and pointing > > us at > > > http://www.ietf.org/internet-drafts/draft-takeda-l1vpn-framework-00.tx > > t > > > > If anyone has comments on this work they can send them to > this mailing > > list (until another home is found in the IETF) or to the > authors direct. > > I think that this is important work, and that the home for > this work in the IETF should be the CCAMP WG. > > Yakov. > > From owner-ccamp@ops.ietf.org Thu Apr 1 22:56:29 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00303 for ; Thu, 1 Apr 2004 22:56:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9FnC-0006yt-00 for ccamp-archive@ietf.org; Thu, 01 Apr 2004 22:56:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9FmE-0006sF-00 for ccamp-archive@ietf.org; Thu, 01 Apr 2004 22:55:31 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1B9Flh-0006nh-00 for ccamp-archive@ietf.org; Thu, 01 Apr 2004 22:54:57 -0500 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B9Fct-000AW0-Fe for ccamp-data@psg.com; Fri, 02 Apr 2004 03:45:51 +0000 Received: from [12.146.0.143] (helo=cabo.sycamorenet.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B9Fcs-000AVh-4f for ccamp@ops.ietf.org; Fri, 02 Apr 2004 04:45:50 +0100 Received: by cabo.sycamorenet.com with Internet Mail Service (5.5.2653.19) id <2DL2K1CC>; Thu, 1 Apr 2004 22:49:23 -0500 Message-ID: <5533E74FC0108E41A8217C0899CA56CF081D46@mach5.sycamorenet.com> From: "Pandian, Vijay" To: "'Dimitri.Papadimitriou@alcatel.be'" , "Ong, Lyndon" Cc: "'Lou Berger'" , Kireeti Kompella , ccamp@ops.ietf.org Subject: RE: Label type to be used Date: Thu, 1 Apr 2004 22:49:22 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Dimitri, I would like a clarification on the following three combinations of your proposal: > > [LSC, LSC] - label represents a G.709 OCh/lambda/port > > [PSC, LSC] - label represents a G.709 OCh/lambda/port > > [TDM, LSC] - label represents a G.709 OCh/lambda/port What exactly you mean by OCh? What exactly you mean by OCh/lambda/port? Does it mean that the devices on both sides of such a TE-Link must be able to generate and accept all these three types? If the answer is yes, then it is not clear to me how a TDM/PSC capable device be able to do that. A TDM device knows how to switch time slots and that's it. Does it make sense for a TDM capable device that is also an LTE to advertise FSC capability for the TE-Links? Thanks, Vijay -----Original Message----- From: Dimitri.Papadimitriou@alcatel.be [mailto:Dimitri.Papadimitriou@alcatel.be] Sent: Thursday, April 01, 2004 5:18 PM To: Ong, Lyndon Cc: 'Lou Berger'; Kireeti Kompella; ccamp@ops.ietf.org Subject: Re: Label type to be used hi lyndon, Ong, Lyndon wrote: > Hi Dimitri, > > I think it was my mistake, in testing I have seen people use > FSC to describe an interface to an opaque OXC with SDH framing > when they wish to have the entire signal (minus some SDH > overhead) switched rather than sorting through individual > channels. On further reading of draft-ietf-ccamp-gmpls-routing-09.txt > it looks like section 3.5 specifically describes this as a > case where LSC would be advertised rather than FSC, since > there is conceptually a single wavelength, is this > still correct? yes, this is why i have proposed the below to adapt the below in-line with the following paragraph of section 3.5 " An interface on an opaque OXC handles a single wavelength, and cannot switch multiple wavelengths as a whole. Thus, an interface on an opaque OXC is always LSC, and not FSC, irrespective of whether there is DWDM external to it." thanks, - dimitri. > Thanks, > > Lyndon > > -----Original Message----- > From: Dimitri.Papadimitriou@alcatel.be > [mailto:Dimitri.Papadimitriou@alcatel.be] > Sent: Saturday, March 27, 2004 4:31 AM > To: Ong, Lyndon > Cc: 'Lou Berger'; Kireeti Kompella; ccamp@ops.ietf.org > Subject: Re: Label type to be used > > > the proposal that makes a fully transparent Sonet/SDH encoded capable > link appearing as [X,LSC] or [LSC,X], or [LSC,LSC] w/ a label defined as > a port and/or lambda is aligned with the evolution of the definition > towards OTN (coming from the so-called pre-OTN) technology and thus > probably better than trying to retain the TDM value for it (with several > flavours) > > so you would have something like this when trying to harmonize in > between the several documents we have tnat deals with this specific > representation issue, i also think it provides the distinction you're > asking for b/w fiber and so-called clear channels: > > 2.4.4. Lambda-Switch Capable > > If an interface is of type LSC, it means that the node receiving data > over this interface can recognize and switch individual lambdas > within the interface. An interface that allows only one lambda per > interface, and switches just that lambda is of type LSC. > > This includes interfaces that only support fully transparent SONET/SDH > > signals, as defined in [GMPLS-SONET-SDH]. > > [...] > > 2.4.7. Interface Switching Capabilities and Labels > > [PSC, PSC] - label is carried in the "shim" header [RFC3032] > > [TDM, TDM] - label represents a timeslot ([GMPLS-SONET-SDH], > [GMPLS-G709]) > > [LSC, LSC] - label represents a G.709 OCh/lambda/port > > [FSC, FSC] - label represents a fiber (i.e. physical port) > > [PSC, TDM] - label represents a timeslot ([GMPLS-SONET-SDH], > [GMPLS-G709]) > > [PSC, LSC] - label represents a G.709 OCh/lambda/port > > [PSC, FSC] - label represents a fiber > > [TDM, LSC] - label represents a G.709 OCh/lambda/port > > [TDM, FSC] - label represents a fiber > > [LSC, FSC] - label represents a fiber > > > Note: except when explicitly indicated the label encoding MUST follow > > the rules defined in [RFC3471] Section 3.2. > > ps: in fact one sees here that for the "timeslot" case, the switching > type TDM value equates the encoding one > > > Ong, Lyndon wrote: > >>Hi Lou, >> >>Your proposed text looks pretty good to me. >> >>Side note: is there a way that the >>existing text can be clarified to distinguish >>between the case of only one lambda allowed >>on an interface and the case of fiber switching? >> >>Currently the text seems to allow an overlap >>in the case of a non-channelized OC-12/48/etc. as in >>a sense there is only one "lambda" but you would >>typically request fiber switching. >> >>Cheers, >> >>Lyndon >> >>-----Original Message----- >>From: Lou Berger [mailto:lberger@movaz.com] >>Sent: Friday, March 26, 2004 11:17 AM >>To: Kireeti Kompella >>Cc: ccamp@ops.ietf.org; John Drake >>Subject: RE: Label type to be used >> >> >>Kireeti, >> I think John's points on (a) and (c) are reasonable. I think the >>only changes needed to the draft-ietf-ccamp-gmpls-routing-09.txt to make >>this clear are: >> >> 2.4.4. Lambda-Switch Capable >> >> If an interface is of type LSC, it means that the node receiving data >> over this interface can recognize and switch individual lambdas >> within the interface. An interface that allows only one lambda per >> interface, and switches just that lambda is of type LSC. >> > This includes interfaces that only support fully transparent SONET/SDH >> > signals, as defined in [GMPLS-SONET-SDH]. >> >>and >> [PSC, PSC] - label is carried in the "shim" header [RFC3032] >> [TDM, TDM] - label represents a TDM time slot [GMPLS-SONET-SDH] >> > [LSC, LSC] - label represents a lambda/port >> [FSC, FSC] - label represents a port on an OXC >> [PSC, TDM] - label represents a TDM time slot [GMPLS-SONET-SDH] >> > [PSC, LSC] - label represents a lambda/port >> [PSC, FSC] - label represents a port >> > [TDM, LSC] - label represents a lambda/port >> [TDM, FSC] - label represents a port >> [LSC, FSC] - label represents a port >> >>Lou >> >>PS This matches all but one implementation we've interoperated with. >> >>At 01:49 PM 3/26/2004 -0500, John Drake wrote: >> >> >> >> >>>>-----Original Message----- >>>>From: Kireeti Kompella >>> >>>[mailto:kireeti@juniper.net] >>> >>> >>>>Sent: Thursday, March 18, 2004 9:58 AM >>>>To: ccamp@ops.ietf.org >>>>Subject: Label type to be used >>>> >>>>Hi, >>>> >>>>Arthi and Lou pointed out the following typos in the GMPLS routing doc >>>>(draft-ietf-ccamp-gmpls-routing-09.txt) which is now in the RFC >>>>Editor's queue: >>>> >>>>In section 2.4.7 is the following table defining the type of label >>>>for various combinations of switching types: >>>> >>>> [PSC, PSC] - label is carried in the "shim" header [RFC3032] >>>> [TDM, TDM] - label represents a TDM time slot [GMPLS-SONET-SDH] >>>> [LSC, LSC] - label represents a lambda >>>> [FSC, FSC] - label represents a port on an OXC >>>> [PSC, TDM] - label represents a TDM time slot [GMPLS-SONET-SDH] >>>> [PSC, LSC] - label represents a lambda >>>> [PSC, FSC] - label represents a port >>>> [TDM, LSC] - label represents a lambda >>>> [TDM, FSC] - label represents a port >>>> [LSC, FSC] - label represents a port >>>> >>>>The one at issue is [PSC, LSC]; above it says that the label >>>>represents a lambda; and in the case of [PSC, TDM] with a fully >>>>transparent signal, the above indicates the label represents a TDM >>>>time slot. The proposal is to change this to: >>>> >>>> [PSC, PSC] - label is carried in the "shim" header [RFC3032] >>>> [TDM, TDM] - label represents a TDM time slot [GMPLS-SONET-SDH] >>>> [LSC, LSC] - label represents a lambda >>>> [FSC, FSC] - label represents a port on an OXC >>>> [PSC, TDM] - fully transparent signal: label represents a port >>>> ("transparency" is defined in [GMPLS-SONET-SDH]) >>>> [PSC, TDM] - non-transparent signal: label represents a TDM time >>>> slot [GMPLS-SONET-SDH] >>>> [PSC, LSC] - label represents a port >>>> [PSC, FSC] - label represents a port >>>> [TDM, LSC] - label represents a lambda >>>> [TDM, FSC] - label represents a port >>>> [LSC, FSC] - label represents a port >>>> >>>>Please respond by Friday 3/26, 5pm PST with comments on: >>>> >>>>a) do you agree with the above change? >>> >>>[John Drake] >>> >>>I don't have a problem with the [PSC, LSC] change but I don't >>>understand the distinction between transparent and non-transparent >>>TDM as it pertains to GMPLS routing. As I indicated in a previous >>>e-mail, I think the transparent TDM case should be handled with a >>>switching type of LSC and an encoding type of SDH/SONET, and I think >>>that this should be specified in the SDH/SONET I-D, where the distinction >>>between transparent and non-transparent TDM is defined, rather than in >>>this document. >>> >>> >>> >>>>b) in your implementation today, what do expect the label to represent >>>> i) in the case of [PSC, LSC]? >>> >>>[John Drake] >>> >>>Port/lambda >>> >>> >>> >>>> ii) in the case of [PSC, TDM] with a fully transparent signal? >>>>c) if you implement as the draft says, would it be a hardship to change >>>> this? >>> >>>[John Drake] >>> >>>N/A. Labels for SDH/SONET are defined in the SDH/SONET I-D and it's pretty >>>clear about which types of labels are in the transparent and non-transparent >>>TDM cases. >>> >>> >>> >>>>If we can get closure on this, I'll take up the task of modifying the >>>>pending RFC with the ADs. >>>> >>>>Kireeti. >>>>------- >> >> >> > -- Papadimitriou Dimitri E-mail : dimitri.papadimitriou@alcatel.be E-mail : dpapadimitriou@psg.com Webpage: http://psg.com/~dpapadimitriou/ Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium Phone : +32 3 240-8491 From owner-ccamp@ops.ietf.org Fri Apr 2 01:27:38 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11974 for ; Fri, 2 Apr 2004 01:27:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9I9R-00048l-00 for ccamp-archive@ietf.org; Fri, 02 Apr 2004 01:27:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9I8S-00043Z-00 for ccamp-archive@ietf.org; Fri, 02 Apr 2004 01:26:37 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1B9I8G-0003yg-00 for ccamp-archive@ietf.org; Fri, 02 Apr 2004 01:26:24 -0500 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B9HuR-00066h-Sn for ccamp-data@psg.com; Fri, 02 Apr 2004 06:12:07 +0000 Received: from [129.60.39.102] (helo=tama5.ecl.ntt.co.jp) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B9HuQ-00066S-D0 for ccamp@ops.ietf.org; Fri, 02 Apr 2004 07:12:06 +0100 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 i326BhLb027779; Fri, 2 Apr 2004 15:11:43 +0900 (JST) Received: from mfs3.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 i326Bg4M006311; Fri, 2 Apr 2004 15:11:42 +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 i326BgwS029233; Fri, 2 Apr 2004 15:11:42 +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 i326Bf8A029230; Fri, 2 Apr 2004 15:11:41 +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 i326Bf38023261; Fri, 2 Apr 2004 15:11:41 +0900 (JST) Received: from imf.m.ecl.ntt.co.jp (localhost [127.0.0.1]) by eclscan3.m.ecl.ntt.co.jp (8.9.3p2/3.7W) with ESMTP id PAA06072; Fri, 2 Apr 2004 15:11:41 +0900 (JST) Received: from TAKEDA_PANA.lab.ntt.co.jp by imf.m.ecl.ntt.co.jp (8.9.3p2/3.7W) with ESMTP id PAA09247; Fri, 2 Apr 2004 15:11:39 +0900 (JST) Message-Id: <5.1.1.9.2.20040402150722.05a91c70@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: Fri, 02 Apr 2004 15:11:51 +0900 To: Tomohiro Otani , "Adrian Farrel" , From: Tomonori TAKEDA Subject: Re: Layer One VPNs In-Reply-To: <5.1.1.9.2.20040330102049.04df0790@mail.onw.kddlabs.co.jp> References: <081401c408ee$67e81c40$1100050a@Puppy> 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-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Hi, Tomohiro Thank you for your comments. Let me try to answer your question. First of all, these two drafts differ in terms of where it comse from. The L1VPN framework ID summarizes the work in ITU-T SG13, while the GVPN ID is a solution draft proposed directly to IETF. Note that the L1VPN framework ID covers L1VPN components addressed in the GVPN draft where they are inserted within a solution context. The L1VPN framework ID "intends to set a framework of requirements and architectures into which all possible solutions can fit", as is stated in the ID. To me, the L1VPN framework ID covers wide range of scenarios, with no protocol proposal. Hope this clarifies. Best regards, At 10:25 04/03/30 +0900, Tomohiro Otani wrote: >Hi Aridian > >I also agree to investigate this item as a WG document. >Is this related to a former WG document of >"draft-ouldbrahim-ppvpn-gvpn-bgpgmpls-xx.txt" > >Regards, > >tomo > >At 11:28 04/03/13 +0000, Adrian Farrel wrote: > >Hi, > > > >Although Layer One VPNs do not currently have a home in any IETF working > >group, we were > >the recipients of a liaison from ITU-T SG13 informing us about the work > >they are doing on > >this topic and pointing us at > >http://www.ietf.org/internet-drafts/draft-takeda-l1vpn-framework-00.txt > > > >If anyone has comments on this work they can send them to this mailing list > >(until another > >home is found in the IETF) or to the authors direct. > > > >Thanks, > >Adrian > >------------------------------------ >Tomohiro Otani >KDDI R&D Laboratories, Inc. >Optical network architecture lab. >2-1-15 Ohara Kamifukuoka Saitama, 356-8502, Japan >TEL: +81-49-278-7357 >FAX: +81-49-278-7811 >E-mail: otani@kddilabs.jp >------------------------------------ ----- Tomonori TAKEDA NTT Network Service Systems Lab. Phone: +81-422-59-7434 From owner-ccamp@ops.ietf.org Fri Apr 2 03:04:42 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27692 for ; Fri, 2 Apr 2004 03:04:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9JfN-0006aF-00 for ccamp-archive@ietf.org; Fri, 02 Apr 2004 03:04:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9JeR-0006Ul-00 for ccamp-archive@ietf.org; Fri, 02 Apr 2004 03:03:45 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1B9Je2-0006P6-00 for ccamp-archive@ietf.org; Fri, 02 Apr 2004 03:03:18 -0500 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B9JHt-000D2j-Un for ccamp-data@psg.com; Fri, 02 Apr 2004 07:40:25 +0000 Received: from [62.23.212.165] (helo=smail.alcatel.fr) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B9JHr-000D2N-OZ; Fri, 02 Apr 2004 07:40:23 +0000 Received: from bemail05.netfr.alcatel.fr (bemail05.netfr.alcatel.fr [155.132.251.11]) by smail.alcatel.fr (ALCANET/NETFR) with ESMTP id i327eGpv020596; Fri, 2 Apr 2004 09:40:17 +0200 Received: from alcatel.be ([138.203.118.2]) by bemail05.netfr.alcatel.fr (Lotus Domino Release 5.0.11) with ESMTP id 2004040209401391:1424 ; Fri, 2 Apr 2004 09:40:13 +0200 Message-ID: <406D195A.8030308@alcatel.be> Date: Fri, 02 Apr 2004 09:42:18 +0200 From: Dimitri.Papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.5) Gecko/20030925 X-Accept-Language: en-us, en MIME-Version: 1.0 To: LE ROUX Jean-Louis FTRD/DAC/LAN Cc: ccamp@ops.ietf.org, mpls@UU.NET, te-wg@ops.ietf.org, Jean Philippe Vasseur Subject: Re: RE : TR : I-D ACTION:draft-ietf-tewg-interarea-mpls-te-req-00.txt References: In-Reply-To: X-MIMETrack: Itemize by SMTP Server on BEMAIL05/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 04/02/2004 09:40:14, Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 04/02/2004 09:40:17 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: base64 X-Alcanet-MTA-scanned-and-authorized: yes Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.4 required=5.0 tests=AWL,MIME_BASE64_LATIN, MIME_BASE64_TEXT,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: base64 aGkgamVhbi1sb3Vpcw0KDQp0aGFua3MgZm9yIHRoZSBjbGFyaWZpY2F0aW9uczsgc2VlIGluLWxp bmUgZm9yIHNvbWUgaGludHMNCg0KTEUgUk9VWCBKZWFuLUxvdWlzIEZUUkQvREFDL0xBTiB3cm90 ZToNCg0KPiBIaSBEaW1pdHJpLA0KPiANCj4gVGhhbmtzIGEgbG90IGZvciB0aGVzZSBjb21tZW50 cy4gU2VlIGFkZGl0aW9uYWwgY29tbWVudHMgb24gdG9wIG9mIEpQDQo+IGNvbW1lbnRzLg0KPiAN Cj4gQ2hlZXJzDQo+IA0KPiBKTA0KPiANCj4gDQo+PiAtLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0t LS0gRGUgOiBKZWFuIFBoaWxpcHBlIFZhc3NldXINCj4+IFttYWlsdG86anZhc3NldXJAY2lzY28u Y29tXSBFbnZveekgOiBtYXJkaSAzMCBtYXJzIDIwMDQgMTQ6MzYgwCA6DQo+PiBEaW1pdHJpLlBh cGFkaW1pdHJpb3VAYWxjYXRlbC5iZSBDYyA6IExFIFJPVVggSmVhbi1Mb3Vpcw0KPj4gRlRSRC9E QUMvTEFOOyBjY2FtcEBvcHMuaWV0Zi5vcmc7IG1wbHNAVVUuTkVUIE9iamV0IDogUmU6IFRSIDog SS1EDQo+PiAgQUNUSU9OOmRyYWZ0LWlldGYtdGV3Zy1pbnRlcmFyZWEtbXBscy10ZS1yZXEtMDAu dHh0DQo+PiANCj4+IA0KPj4gSGkgRGltaXRyaSwNCj4+IA0KPj4gVGhhbmtzIGZvciB5b3VyIHVz ZWZ1bCBjb21tZW50cyBoZXJlLiBTZWUgYmVsb3csDQo+PiANCj4+IEF0IDAyOjE4IFBNIDMvMzAv MjAwNCArMDIwMCwgRGltaXRyaS5QYXBhZGltaXRyaW91QGFsY2F0ZWwuYmUNCj4+IHdyb3RlOg0K Pj4gDQo+Pj4gaGkgamwsIGhlcmUgYmVsb3cgc2V2ZXJhbCBjb21tZW50cyBvbiB0aGlzIHVwZGF0 ZWQgdmVyc2lvbiBvZiB0aGUNCj4+PiAgZG9jdW1lbnQ6DQo+Pj4gDQo+Pj4gMSkgc2VjdGlvbiA1 LjMuMSBtZW50aW9uczoNCj4+PiANCj4+PiAiVGhlIHNvbHV0aW9uIE1VU1QgZW50aXJlbHkgcHJl c2VydmUgdGhlIGNvbmNlcHQgb2YgSUdQDQo+Pj4gaGllcmFyY2h5LiBJbiBvdGhlciB3b3Jkcywg Zmxvb2Rpbmcgb2YgVEUgbGluayBpbmZvcm1hdGlvbiBhY3Jvc3MNCj4+PiBhcmVhcyBNVVNUIGJl IHByZWNsdWRlZC4iDQo+Pj4gDQo+Pj4gc2VjdGlvbiA1LjMuMiBtZW50aW9uczoNCj4+PiANCj4+ PiAiVGhlIHNvbHV0aW9uIE1VU1QgYWxzbyBub3QgaW5jcmVhc2UgSUdQIGxvYWQgd2hpY2ggY291 bGQNCj4+PiBjb21wcm9taXNlIElHUCBzY2FsYWJpbGl0eS4gSW4gcGFydGljdWxhciwgYSBzb2x1 dGlvbiBzYXRpc2Z5aW5nDQo+Pj4gdGhvc2UgcmVxdWlyZW1lbnRzIE1VU1Qgbm90IHJlcXVpcmUg Zm9yIHRoZSBJR1AgdG8gY2Fycnkgc29tZQ0KPj4gDQo+PiB1bnJlYXNvbmFibGUNCj4+IA0KPj4+ IGFtb3VudCBvZiBleHRyYSBpbmZvcm1hdGlvbiBhbmQgTVVTVCBub3QgdW5yZWFzb25hYmx5DQo+ PiANCj4+IGluY3JlYXNlIHRoZQ0KPj4gDQo+Pj4gSUdQIGZsb29kaW5nIGZyZXF1ZW5jeS4iDQo+ Pj4gDQo+Pj4gYnV0IHNlY3Rpb24gNy4xMiB0ZWxsczoNCj4+PiANCj4+PiAiVGhlIGRpc2NvdmVy eSBtZWNoYW5pc20gU0hPVUxEIGJlIGFwcGxpY2FibGUgYWNyb3NzIG11bHRpcGxlIElHUA0KPj4+ IGFyZWFzLCBhbmQgU0hPVUxEIG5vdA0KPj4gDQo+PiBpbXBhY3QgdGhlDQo+PiANCj4+PiBJR1Ag c2NhbGFiaWxpdHksIHByb3ZpZGVkIHRoYXQgSUdQIGV4dGVuc2lvbnMgYXJlIHVzZWQgZm9yIHN1 Y2ggYQ0KPj4+ICBkaXNjb3ZlcnkgbWVjaGFuaXNtLiINCj4+PiANCj4+PiAtPiB3b3VsZCBpdCBi ZSBwb3NzaWJsZSB0byBhbGlnbiB0aGVzZSByZXF1aXJlbWVudHMsIGkgZ2V0IHRoZSAtPg0KPj4+ IGltcHJlc3Npb24gKHBsZWFzZSBjb25maXJtKSB0aGF0IHlvdSBwcmVjbHVkZSBURSBsaW5rIGlu Zm9ybWF0aW9uDQo+Pj4gYnV0IHlvdSB3b3VsZCBhbGxvdyBmb3Igbm9kZSBpbmZvcm1hdGlvbiAo YXV0by1tZXNoKSA/IG5vdGUgYWxzbw0KPj4+IHRoYXQgdGhlDQo+PiANCj4+IHNlY3Rpb24gNy4x MiBkb2Vzbid0DQo+PiANCj4+PiB0ZWxsIHVzIGEgbG90IGFib3V0IHRoZSBleHBlY3RlZCBkaXN0 cmlidXRpb24gb2YgdGhlIG1lc2gNCj4+IA0KPj4gVGhlIHNvbHV0aW9uIE1VU1QgcHJlY2x1ZGUg dG8gZmxvb2QgVEUtcmVsYXRlZCBsaW5rIGluZm9ybWF0aW9uIGFuZA0KPj4gTVVTVCBub3QgY29t cHJvbWlzZSB0aGUgSUdQIHNjYWxhYmlsaXR5IGluIGFueSBjaXJjdW1zdGFuY2VzLiBUaGF0DQo+ PiAgYmVpbmcgc2FpZCwgSUdQIGJhc2VkIG1lY2hhbmlzbXMgY2FuIGJlIHVzZWQgZm9yIHRoZSBk aXNjb3ZlcnkNCj4+IHdoaWNoIHdpbGwgcmVzcGVjdCB0aGUgcmVxdWlyZW1lbnQgbWVudGlvbmVk IGFib3ZlLA0KPiANCj4gQmFzaWNhbGx5IHRoZSBzb2x1dGlvbiBtdXN0IHByZXNlcnZlIElHUCBo aWVyYXJjaHksIGFuZCB0aHVzIG11c3QNCj4gcHJlY2x1ZGUgbGVha2luZyBvZiBhbnkgVE9QT0xP R1kgcmVsYXRlZCBpbmZvcm1hdGlvbiBhY2Nyb3NzIGFyZWFzLA0KPiBpbmNsdWRpbmcgVEUgbGlu ayBpbmZvcm1hdGlvbiBzdWNoIGFzIGNhcnJpZWQgaW4gSVNJUyBFeHRlbmRlZCBJUw0KPiByZWFj aGVhYmlsaXR5IFRMViwgb3IgT1NQRiBURSBMU0EgTGluayBUTFYuIE5vdGUgdGhhdCB0aGlzIGFs c28NCj4gcHJlY2x1ZGVzIGxlYWtpbmcgb2YgYW55IHN1bW1hcml6ZWQvYWdncmVnYXRlZCBURSBp bmZvcm1hdGlvbiwgc3VjaA0KPiB0aGF0IHRoZSBhZHZlcnRpc2VtZW50IG9mIG1heGltdW0gdW5y ZXNlcnZlZCBiYW5kd2RpdGggYmV0d2VlbiBhbiBBQlINCj4gYW5kIGFueSBlbmQtcG9pbnQgTFNS LiBXZSB3aWxsIGNsYXJpZnkgdGhhdCBpbiBuZXh0IHJldmlzaW9uLg0KDQp0aGlzIHdvdWxkIHJl ZmluZSB0aGUgYWJvdmUgcmVxdWlyZW1lbnQgKHN1Y2ggVEUgbGluayBpbmZvcm1hdGlvbg0Kd291 bGQgYmUgcHJlY2x1ZGVkIGluIGFueSBvZiBpdHMgZm9ybSkNCg0KPiBJbiByZXR1cm4gd2UgZGVm aW5pdGVseSBub3QgcHJlY2x1ZGUgbGVha2luZyBvZiBOT04gVE9QT0xPR1kgcmVsYXRlZA0KPiBp bmZvcm1hdGlvbiBzdWNoIGFzIFRFIG5vZGUgY2FwYWJpbGl0aWVzLCBwcm92aWRlZCB0aGF0IElH UA0KPiBzY2FsYWJpbGl0eSBpcyBub3QgaW1wYWN0ZWQuDQoNCm1vcmUgdGhhbiBwcm9iYWJseSwg aXQgaXMgbm90IHdpdGhpbiB0aGlzIGtpbmQgb2YgZG9jdW1lbnQgdG8NCnByb3ZpZGUgYSBraW5k IG9mIGNsYXNzaWZpY2F0aW9uIG9mIHN1Y2ggaW5mb3JtYXRpb24gYnV0IHRoZQ0KbGF0dGVyIHdv dWxkIGhlbHAgaW4gZGV0YWlsaW5nIHRoZSAiZGlzY292ZXJ5IiBjb25jZXB0cyAoc2VlDQphbHNv IHNlY3Rpb24gNy4xMikgaW4gdGVybXMgb2YgZnVuY3Rpb25hbGl0eSB0aGF0IHdvdWxkIGJlDQpy ZXF1aXJlZCBoZXJlOiBpZGVudGl0eSwgY2FwYWJpbGl0eSAmIGFzc29jaWF0ZWQgY2FwYWJpbGl0 eQ0KDQo+Pj4gMikgc2VjdGlvbiA3LjMNCj4+PiANCj4+PiAiICAgSW4gdGhlIGNvbnRleHQgb2Yg dGhpcyByZXF1aXJlbWVudCBkb2N1bWVudCwgYW4gb3B0aW1hbCBwYXRoDQo+Pj4gaXMgZGVmaW5l ZCBhcyB0aGUgc2hvcnRlc3QgcGF0aCBhY3Jvc3MgbXVsdGlwbGUgYXJlYXMgdGFraW5nIGludG8N Cj4+PiAgYWNjb3VudCBlaXRoZXIgdGhlIElHUCBvciBURSBtZXRyaWMuICINCj4+PiANCj4+PiBh cmUgeW91IHJlZmVycmluZyBoZXJlIHRvIA0KPj4+IDxodHRwOi8vd3d3LmlldGYub3JnL2ludGVy bmV0LWRyYWZ0cy9kcmFmdC1pZXRmLXRld2ctdGUtbWV0cmkNCj4+IA0KPj4gYy1pZ3AtMDIudA0K Pj4gDQo+Pj4geHQ+DQo+Pj4gDQo+Pj4gd291bGQgeW91IGNsYXJpZnkgPw0KPj4gDQo+PiBTdXJl LCB3ZSB3aWxsIGFkZCBzb21lIHRleHQuIFRoZSByZWFzb24gZm9yIHRoaXMgY2xhcmlmaWNhdGlv biBpcw0KPj4gdGhhdCB0aGVyZSBhcmUgYSBtdWx0aXR1ZGUgb2YgZGVmaW5pdGlvbnMgZm9yIGFu IG9wdGltYWwgcGF0aDoNCj4+IHBhdGhzIHRoYXQgbWluaW1pemUgdGhlIG1heCBsaW5rIHV0aWxp emF0aW9uLCBjYWxsIHNldCB1cCBmYWlsdXJlLA0KPj4gLi4uIGhlcmUgd2UganVzdCByZWZlciB0 byB0aGUgYWJpbGl0eSB0byBjb21wdXRlIGEgc2hvcnRlc3QgcGF0aA0KPj4gKHVzaW5nIGVpdGhl ciB0aGUgSUdQIG9yIFRFIG1ldHJpYykuDQo+PiANCj4+IA0KPj4gDQo+Pj4gMykgc2VjdGlvbiA3 LjMNCj4+PiANCj4+PiBpdCBpcyBub3QgY2xlYXIgZm9yIG1lIHdoYXQgaXMgYmVoaW5kIHRoZSBs YXN0IHBhcnQgb2YgdGhlDQo+Pj4gZm9sbG93aW5nIHNlbnRlbmNlDQo+Pj4gDQo+Pj4gIlNvIGEg c29sdXRpb24gc2hvdWxkIHN1cHBvcnQgYm90aCBtZWNoYW5pc21zLCBhbmQgU0hPVUxEIGFsbG93 IA0KPj4+IHRoZSBvcGVyYXRvciB0byBzZWxlY3QgYnkgY29uZmlndXJhdGlvbiwgYW5kIG9uIGEN Cj4+IA0KPj4gcGVyLUxTUCBiYXNpcywgdGhlDQo+PiANCj4+PiByZXF1aXJlZCBsZXZlbCBvZiBv cHRpbWFsaXR5LiAiDQo+Pj4gDQo+Pj4gd2hhdCBpcyBtZWFudCBieSAibGV2ZWwgb2Ygb3B0aW1h bGl0eSIgPyBpcyBpdCBzaW1wbHkgIm9wdGltYWwgLSANCj4+PiBzdWItb3B0aW1hbCIgb3IgZG8g eW91IGhhdmUgc29tZXRoaW5nIGVsc2UgaW4gbWluZCA/DQo+PiANCj4+IFdlIHdpbGwgY2xhcmlm eS4gVGhlIGlkZWEgaXMgdGhhdCB0aGUgYWJpbGl0eSB0byBjb21wdXRlIGFuIGVuZCB0bw0KPj4g ZW5kIHNob3J0ZXN0IHBhdGggbWF5IG5vdCBiZSByZXF1aXJlZCBmb3IgYWxsIGludGVyLWFyZWEg VEUgTFNQcy4gDQo+PiBIZW5jZSB0aGUgc29sdXRpb24gc2hvdWxkIGFsbG93IHRoZSBvcGVyYXRv ciB0byBzZWxlY3QgdGhlDQo+PiBhcHByb3ByaWF0ZSBwYXRoIGNvbXB1dGF0aW9uIG1ldGhvZC4N Cj4gDQo+IA0KPiBJIHNlZSB5b3VyIHBvaW50IGhlcmUuIEJhc2ljYWxseSB0aGVyZSBhcmUgdHdv IHBvc3NpYmxlIGFwcHJvYWNoZXMNCj4gZm9yIExTUCBjb25maWd1YXRpb24gLU9wdGlvbiAxOiBD b25maWd1cmUgb25seSB0aGUgZGVzaXJlZCBsZXZlbCBvZg0KPiBvcHRpbWFsaXR5OiBPcHRpbWFs LCBzdWItb3B0aW1hbCwgdGhlbiB0aGUgaGVhZC1lbmQgY2hvb3NlIHRoZQ0KPiBjb3JyZXNwb25k aW5nIHBhdGggY29tcHV0YXRpb24gYXBwcm9hY2guIC1PcHRpb24gMjogQ29uZmlndXJlDQo+IGRp cmVjdGx5IHRoZSBkZXNpcmVkIHBhdGggY29tcHV0YXRpb24gbWV0aG9kOiBlLmcuIEVSTyBleHBh bnNpb24gb3INCj4gUENFIGNvbXB1dGF0aW9uDQo+IA0KPiBPcHRpb24gMSBpcyBJTUhPIHRvbyBn ZW5lcmljLCBhbmQgYSBTZXJ2aWNlIFByb3ZpZGVyIHdhbnRzIHRvIGhhdmUNCj4gZGlyZWN0IGNv bnRyb2wgb24gdGhlIHNlbGVjdGlvbiBvZiB0aGUgcGF0aCBjb21wdXRhdGlvbiBtZXRob2QuDQo+ IA0KPiBXZSB3aWxsIGNsYXJpZnkgdGhhdCBpbiBuZXh0IHJldmlzaW9uDQoNCm9rDQoNCj4+PiA0 KSBzZWN0aW9uIDcuNA0KPj4+IA0KPj4+ICJBbm90aGVyIGV4YW1wbGUgaXMgdGhlIHJlcXVpcmVt ZW50IHRvIHNldCB1cCBtdWx0aXBsZSBURQ0KPj4gDQo+PiBMU1BzIGJldHdlZW4NCj4+IA0KPj4+ IGEgcGFpciBvZiBMU1JzIHJlc2lkaW5nIGluIGRpZmZlcmVudCBJR1AgYXJlYXMgaW4gY2FzZSBh DQo+PiANCj4+IHNpbmdsZSBURQ0KPj4gDQo+Pj4gTFNQIHNhdGlzZnlpbmcgdGhlIHNldCBvZiBy ZXF1aXJlbWVudHMgY291bGQgbm90IGJlIGZvdW5kLiAiDQo+Pj4gDQo+Pj4gd2h5IGluIHN1Y2gg YSBjYXNlIGRpdmVyc2l0eSB3b3VsZCBiZSBkZXNpcmFibGUgPw0KPj4gDQo+PiBmb3IgZWl0aGVy IHBhdGggcHJvdGVjdGlvbiBvciBsb2FkIGJhbGFuY2luZyB3aGlsZSBtaW5pbWl6aW5nIHRoZQ0K Pj4gaW1wYWN0IGluIGNhc2Ugb2YgZmFpbHVyZS4NCj4+IA0KPj4gDQo+Pj4gZ290IHRoZSBpbXBy ZXNzaW9uIHRoYXQgaWYgYSBzaW5nbGUgcGF0aCB3b3VsZCBoYXZlIGJlZW4gZmVhc2libGUNCj4+ PiBpdCB3b3VsZCBoYXZlIGJlZW4gc2VsZWN0ZWQgaW4gdGhpcyBjYXNlIC0gaXNuJ3QgaXQgPw0K Pj4gDQo+PiBUaGF0IGJlaW5nIHNhaWQsIHdlIG5lZWQgdG8gcmVwaHJhc2UsIEkgYWdyZWUgd2l0 aCB5b3UgdGhhdCB0aGlzDQo+PiBwYXJhZ3JhcGggaXMgbm90IGNsZWFyLiBJdCBzaG91bGQgcmVh ZDoNCj4+IA0KPj4gIkFub3RoZXIgZXhhbXBsZSBpcyB0aGUgcmVxdWlyZW1lbnQgdG8gc2V0IHVw IG11bHRpcGxlIFRFIExTUHMNCj4+IGJldHdlZW4gYSBwYWlyIG9mIExTUnMgcmVzaWRpbmcgaW4g ZGlmZmVyZW50IElHUCBhcmVhcy4gRm9yDQo+PiBpbnN0YW5jZSwgdGhpcyB3b3VsZCBvY2N1ciBp ZiBURSBMU1Agc2F0aXNmeWluZyBmb3IgaW5zdGFuY2UgdGhlDQo+PiBiYW5kd2lkdGggcmVxdWly ZW1lbnQgY291bGQgYmUgZm91bmQsIGhlbmNlLCByZXF1aXJpbmcgdG8gc2V0IHVwDQo+PiBtdWx0 aXBsZSBURSBMU1BzIg0KPj4gDQo+PiANCj4+PiA1KSBzZWN0aW9uIDcuNw0KPj4+IA0KPj4+ICJU aGlzIG1heSByZWR1Y2UgdGhlIHJlY292ZXJ5IGRlbGF5LCBidXQgd2l0aCB0aGUgcmlzayBvZiAN Cj4+PiBtdWx0aXBsZSBjcmFua2JhY2tzLCBhbmQgc3ViLW9wdGltYWxpdHkuICAiDQo+Pj4gDQo+ Pj4gaSBhZ3JlZSwgYnV0IHRoaXMgaXMgdmFsaWQgaWZmIHRoZSBoZWFkLWVuZCBoYXMgaW5pdGlh bGx5DQo+Pj4gY29tcHV0ZWQgYW4gZW5kLXRvLWVuZCBvcHRpbWFsIHBhdGgsDQo+PiANCj4+IG1v cmUgZXhhY3RseSB0aGlzIGFwcGxpZXMgdG8gY29udGlndW91cyBMU1AuIEZvciBzdWItb3B0aW1h bGl0eQ0KPj4gdGhpcyBhcHBsaWVzIHRvIGFueSBraW5kIG9mIExTUC4NCj4+IA0KPj4gDQo+Pj4g YWxzbyB1bmNsZWFyIGlmIHlvdSByZWZlciBhbHNvIGhlcmUgdG8gdGhlIHByb3Zpc2lvbmluZyBk ZWxheSA/DQo+IA0KPiANCj4gQWN0dWFsbHkgdGhpcyBzZWN0aW9uIGlzIG5vdCBkZWRpY2F0ZWQg dG8gY3JhbmtiYWNrIHJvdXRpbmcgYXMgYSBwYXRoDQo+IGNvbXB1dGF0aW9uIG1ldGhvZCwgIGl0 IG9ubHkgYWRkcmVzc2VzIHBvc3NpYmxlIHVzZSBvZiBjcmFua2JhY2sgaW4NCj4gY2FzZSBvZiBu ZXR3b3JrIGZhaWx1cmUuIFRodXMgd2UgcmVmZXIgaGVyZSBvbmx5IHRvIHRoZSByZWNvdmVyeQ0K PiBkZWxheS4gV2UgbWF5IGFkZCBhIHNlY3Rpb24gZGVkaWNhdGVkIHRvIGNyYW5rYmFjayByb3V0 aW5nIGluIHRoZQ0KPiBuZXh0IHJldmlzaW9uDQoNCmkgd291bGQgYWdyZWUgdG8gaGF2ZSBhIHJl cXVpcmVtZW50IGRvY3VtZW50IHRoYXQgaW5jbHVkZXMgYSBkZWRpY2F0ZWQgDQpzZWN0aW9uIG9u IGNyYW5rYmFjayBmdW5jdGlvbmFsaXR5LCBob3BlIHRoZSBuZXh0IHJlbGVhc2Ugd2lsbCBjbGFy aWZ5DQoNCj4+PiBlZGl0b3JpYWxseSBzcGVha2luZyBpdCBpcyBhbHNvIGEgYml0IHVuY2xlYXIg d2h5IHlvdSd2ZSBzcGxpdHRlZA0KPj4+ICBzZWN0aW9uIDcuNyBhbmQgc2VjdGlvbiA3LjggYm90 aCByZWZlcnMgdG8gaW50ZXItYXJlYSBsc3ANCj4+PiByZWNvdmVyeQ0KPj4+IA0KPiANCj4gDQo+ IFllcyB5b3UgYXJlIHJpZ2h0LCBib3RoIHNlY3Rpb25zIHJlZmVyIHRvIGxzcCByZWNvdmVyeSBC YXNpY2FsbHkNCj4gc2VjdGlvbiA3LjcgZGVhbHMgd2l0aCBMU1AgcmVyb3V0aW5nIGFuZCBzZWN0 aW9uIDcuOCBpcyBkZWRpY2F0ZWQgdG8NCj4gRmFzdCBSZXJvdXRlIHByb3RlY3Rpb24gV2Ugd2ls bCB1cGRhdGUgYXMgZm9sbG93cyA3LjcgTFNQIHJlY292ZXJ5IA0KPiA3LjcuMSBMU1AgcmVyb3V0 aW5nIDcuNy4yIEZhc3QgUmVyb3V0ZQ0KDQpvaw0KDQo+Pj4gNikgc2VjdGlvbiA3LjExDQo+Pj4g DQo+Pj4gd291bGQgaXQgYmUgcG9zc2libGUgdG8gbWVudGlvbiB3aGF0J3MgZXhwZWN0ZWQgKG9y IG5vdCBleHBlY3RlZCkNCj4+PiBpbiB0ZXJtcyBhbHNvIG9mIGhhcmQgcHJlZW1wdGlvbiA/DQo+ PiANCj4+IG9rDQo+IA0KPiANCj4+IA0KPj4+IDcpIHNlY3Rpb24gOC4yDQo+Pj4gDQo+Pj4gd2hh dCdzIG1lYW50IGJ5IHN0YWJpbGl0eSA/IGllIHN0YWJpbGl0eSBvZiB3aGF0ID8gKGZvcg0KPj4g DQo+PiBpbnN0YW5jZSwgYXMgaQ0KPj4gDQo+Pj4gcmVhZCB0aGUgZG9jdW1lbnQsIGJ1dCBwbGVh c2UgY29ycmVjdCBtZSwgc3RhYmlsaXR5IGFuZA0KPj4gDQo+PiByZS1vcHRpbWl6YXRpb24NCj4+ IA0KPj4+IGFyZSBpbWhvIHR3byBmZWF0dXJlcyB0aGF0IGFyZSBnb2luZyBpbiBzb21laG93IG9w cG9zaXRlDQo+PiANCj4+IGRpcmVjdGlvbnMgc28gYQ0KPj4gDQo+Pj4gdHJhZGUtb2ZmIGhhcyB0 byBiZSBmb3VuZCBoZXJlKQ0KPj4gDQo+PiBXZSB3aWxsIGNsYXJpZnkuDQo+PiANCj4+IHRoYW5r cyBmb3IgeW91ciBjb21tZW50cyAhDQo+PiANCj4+IEpQLg0KPj4gDQo+PiANCj4+PiB0aGFua3Mg aW4gYWR2YW5jZSwgLSBkaW1pdHJpLg0KPj4+IA0KPj4+IExFIFJPVVggSmVhbi1Mb3VpcyBGVFJE L0RBQy9MQU4gd3JvdGU6DQo+Pj4gDQo+Pj4gDQo+Pj4+IEhpIGFsbCwgVGhhbmtzIGluIGFkdmFu Y2UgZm9yIHlvdXIgY29tbWVudHMgb24gdGhpcyBuZXcNCj4+Pj4gcmV2aXNpb24gb2YNCj4+IA0K Pj4gaW50ZXItYXJlYQ0KPj4gDQo+Pj4+IFRFIHJlcXVpcmVtZW50cy4gUmVnYXJkcywgSkwNCj4+ Pj4gDQo+Pj4+IA0KPj4+Pj4gQSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20g dGhlIG9uLWxpbmUNCj4+Pj4+IEludGVybmV0LURyYWZ0cyBkaXJlY3Rvcmllcy4gVGhpcyBkcmFm dCBpcyBhIHdvcmsgaXRlbSBvZiB0aGUNCj4+Pj4+IEludGVybmV0IFRyYWZmaWMgRW5naW5lZXJp bmcgV29ya2luZyBHcm91cCBvZiB0aGUgSUVURi4NCj4+Pj4+IA0KPj4+Pj4gVGl0bGUgICAgICAg ICAgIDogUmVxdWlyZW1lbnRzIGZvciBJbnRlci1hcmVhIE1QTFMgVHJhZmZpYw0KPj4+PiANCj4+ Pj4gRW5naW5lZXJpbmcNCj4+Pj4gDQo+Pj4+IA0KPj4+Pj4gQXV0aG9yKHMpICAgICAgIDogSi4g TGUgUm91eCwgZXQgYWwuIEZpbGVuYW1lICAgICAgICA6DQo+PiANCj4+IGRyYWZ0LWlldGYtdGV3 Zy1pbnRlcmFyZWEtbXBscy10ZS1yZXEtMDAudHh0DQo+PiANCj4+Pj4+IFBhZ2VzICAgICAgICAg ICA6IDIwIERhdGUgICAgICAgICAgICA6IDIwMDQtMy0yNg0KPj4+Pj4gDQo+Pj4+PiBUaGlzIGRv Y3VtZW50IGxpc3RzIGEgZGV0YWlsZWQgc2V0IG9mIGZ1bmN0aW9uYWwNCj4+IA0KPj4gcmVxdWly ZW1lbnRzIGZvciB0aGUNCj4+IA0KPj4+Pj4gc3VwcG9ydCBvZiBpbnRlci1hcmVhIE1QTFMgVHJh ZmZpYyBFbmdpbmVlcmluZyAoaW50ZXItYXJlYQ0KPj4gDQo+PiBNUExTIFRFKQ0KPj4gDQo+Pj4+ PiB3aGljaCBjb3VsZCBzZXJ2ZSBhcyBhIGd1aWRlbGluZSB0byBkZXZlbG9wIHRoZSByZXF1aXJl ZCBzZXQNCj4+Pj4+IG9mIHByb3RvY29sIGV4dGVuc2lvbnMuDQo+Pj4+PiANCj4+Pj4+IEEgVVJM IGZvciB0aGlzIEludGVybmV0LURyYWZ0IGlzOiANCj4+Pj4+IGh0dHA6Ly93d3cuaWV0Zi5vcmcv aW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYtdGV3Zy1pbnRlcmFyDQo+IA0KPiBlYS1tcGxzLXRl DQo+IA0KPj4+PiAtcg0KPj4+IA0KPj4+IGVxLTAwLnR4dA0KPj4+IA0KPj4+IA0KPj4+PiBUbyBy ZW1vdmUgeW91cnNlbGYgZnJvbSB0aGUgSUVURiBBbm5vdW5jZW1lbnQgbGlzdCwgc2VuZCBhDQo+ Pj4+IG1lc3NhZ2UgdG8gaWV0Zi1hbm5vdW5jZS1yZXF1ZXN0IHdpdGggdGhlIHdvcmQgdW5zdWJz Y3JpYmUgaW4NCj4+Pj4gdGhlIGJvZHkgb2YgdGhlIG1lc3NhZ2UuDQo+Pj4+IA0KPj4+PiBJbnRl cm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91cyBGVFAuIExvZ2luIHdp dGgNCj4+Pj4gdGhlIHVzZXJuYW1lICJhbm9ueW1vdXMiIGFuZCBhIHBhc3N3b3JkIG9mIHlvdXIg ZS1tYWlsIGFkZHJlc3MuDQo+Pj4+IEFmdGVyIGxvZ2dpbmcgaW4sIHR5cGUgImNkIGludGVybmV0 LWRyYWZ0cyIgYW5kIHRoZW4gImdldA0KPj4+PiBkcmFmdC1pZXRmLXRld2ctaW50ZXJhcmVhLW1w bHMtdGUtcmVxLTAwLnR4dCIuDQo+Pj4+IA0KPj4+PiBBIGxpc3Qgb2YgSW50ZXJuZXQtRHJhZnRz IGRpcmVjdG9yaWVzIGNhbiBiZSBmb3VuZCBpbiANCj4+Pj4gaHR0cDovL3d3dy5pZXRmLm9yZy9z aGFkb3cuaHRtbCBvciANCj4+Pj4gZnRwOi8vZnRwLmlldGYub3JnL2lldGYvMXNoYWRvdy1zaXRl cy50eHQNCj4+PiANCj4+IC0tIFBhcGFkaW1pdHJpb3UgRGltaXRyaSBFLW1haWwgOiBkaW1pdHJp LnBhcGFkaW1pdHJpb3VAYWxjYXRlbC5iZSANCj4+IEUtbWFpbCA6IGRwYXBhZGltaXRyaW91QHBz Zy5jb20gV2VicGFnZToNCj4+IGh0dHA6Ly9wc2cuY29tL35kcGFwYWRpbWl0cmlvdS8gQWRkcmVz czogRnIuIFdlbGxlc3BsZWluIDEsIEItMjAxOA0KPj4gQW50d2VycGVuLCBCZWxnaXVtIFBob25l ICA6ICszMiAzIDI0MC04NDkxDQo+PiANCj4+IA0KPiANCj4gDQoNCi0tIA0KUGFwYWRpbWl0cmlv dSBEaW1pdHJpDQpFLW1haWwgOiBkaW1pdHJpLnBhcGFkaW1pdHJpb3VAYWxjYXRlbC5iZQ0KRS1t YWlsIDogZHBhcGFkaW1pdHJpb3VAcHNnLmNvbQ0KV2VicGFnZTogaHR0cDovL3BzZy5jb20vfmRw YXBhZGltaXRyaW91Lw0KQWRkcmVzczogRnIuIFdlbGxlc3BsZWluIDEsIEItMjAxOCBBbnR3ZXJw ZW4sIEJlbGdpdW0NClBob25lICA6ICszMiAzIDI0MC04NDkxDQoNCg== From owner-ccamp@ops.ietf.org Fri Apr 2 03:12:51 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27869 for ; Fri, 2 Apr 2004 03:12:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9JnG-0007RN-00 for ccamp-archive@ietf.org; Fri, 02 Apr 2004 03:12:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9JmQ-0007KL-00 for ccamp-archive@ietf.org; Fri, 02 Apr 2004 03:12:00 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1B9Jm1-0007CE-00 for ccamp-archive@ietf.org; Fri, 02 Apr 2004 03:11:33 -0500 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B9JTc-000HpF-L8 for ccamp-data@psg.com; Fri, 02 Apr 2004 07:52:32 +0000 Received: from [62.23.212.165] (helo=smail.alcatel.fr) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B9JTa-000Hp1-Vi for ccamp@ops.ietf.org; Fri, 02 Apr 2004 07:52:31 +0000 Received: from bemail05.netfr.alcatel.fr (bemail05.netfr.alcatel.fr [155.132.251.11]) by smail.alcatel.fr (ALCANET/NETFR) with ESMTP id i327qJpv025711; Fri, 2 Apr 2004 09:52:19 +0200 Received: from alcatel.be ([138.203.118.2]) by bemail05.netfr.alcatel.fr (Lotus Domino Release 5.0.11) with ESMTP id 2004040209521591:1493 ; Fri, 2 Apr 2004 09:52:15 +0200 Message-ID: <406D1C2C.7060400@alcatel.be> Date: Fri, 02 Apr 2004 09:54:20 +0200 From: Dimitri.Papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.5) Gecko/20030925 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Pandian, Vijay" Cc: "Ong, Lyndon" , "'Lou Berger'" , Kireeti Kompella , ccamp@ops.ietf.org Subject: Re: Label type to be used References: <5533E74FC0108E41A8217C0899CA56CF081D46@mach5.sycamorenet.com> In-Reply-To: <5533E74FC0108E41A8217C0899CA56CF081D46@mach5.sycamorenet.com> X-MIMETrack: Itemize by SMTP Server on BEMAIL05/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 04/02/2004 09:52:16, Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 04/02/2004 09:52:19, Serialize complete at 04/02/2004 09:52:19 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed X-Alcanet-MTA-scanned-and-authorized: yes Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit hi > I would like a clarification on the following three combinations of your > proposal: > > >> > [LSC, LSC] - label represents a G.709 OCh/lambda/port >> > [PSC, LSC] - label represents a G.709 OCh/lambda/port >> > [TDM, LSC] - label represents a G.709 OCh/lambda/port > > > What exactly you mean by OCh? optical channel > What exactly you mean by OCh/lambda/port? these combinations described in gmpls-routing tells what the label represents when considering both ends of the te link from their interface switching capability perspective - taking the examples here above it is either an optical channel, or a lambda or a port > Does it mean that the devices on both sides of such a TE-Link must be able > to generate and accept all these three types? If the answer is yes, then it > is not clear to me how a TDM/PSC capable device be able to do that. A TDM > device knows how to switch time slots and that's it. Does it make sense for > a TDM capable device that is also an LTE to advertise FSC capability for the > TE-Links? i don't think this FSC interpretation would be inline with the FSC definition, so the response to your last question is no thanks, - dimitri. > Thanks, > > Vijay > > > -----Original Message----- > From: Dimitri.Papadimitriou@alcatel.be > [mailto:Dimitri.Papadimitriou@alcatel.be] > Sent: Thursday, April 01, 2004 5:18 PM > To: Ong, Lyndon > Cc: 'Lou Berger'; Kireeti Kompella; ccamp@ops.ietf.org > Subject: Re: Label type to be used > > > hi lyndon, > > Ong, Lyndon wrote: > > >>Hi Dimitri, >> >>I think it was my mistake, in testing I have seen people use >>FSC to describe an interface to an opaque OXC with SDH framing >>when they wish to have the entire signal (minus some SDH >>overhead) switched rather than sorting through individual >>channels. On further reading of draft-ietf-ccamp-gmpls-routing-09.txt >>it looks like section 3.5 specifically describes this as a >>case where LSC would be advertised rather than FSC, since >>there is conceptually a single wavelength, is this >>still correct? > > > yes, this is why i have proposed the below to adapt the below > in-line with the following paragraph of section 3.5 > > " An interface on an opaque OXC handles a single wavelength, and > cannot switch multiple wavelengths as a whole. Thus, an interface on > an opaque OXC is always LSC, and not FSC, irrespective of whether > there is DWDM external to it." > > > thanks, > - dimitri. > > >>Thanks, >> >>Lyndon >> >>-----Original Message----- >>From: Dimitri.Papadimitriou@alcatel.be >>[mailto:Dimitri.Papadimitriou@alcatel.be] >>Sent: Saturday, March 27, 2004 4:31 AM >>To: Ong, Lyndon >>Cc: 'Lou Berger'; Kireeti Kompella; ccamp@ops.ietf.org >>Subject: Re: Label type to be used >> >> >>the proposal that makes a fully transparent Sonet/SDH encoded capable >>link appearing as [X,LSC] or [LSC,X], or [LSC,LSC] w/ a label defined as >>a port and/or lambda is aligned with the evolution of the definition >>towards OTN (coming from the so-called pre-OTN) technology and thus >>probably better than trying to retain the TDM value for it (with several >>flavours) >> >>so you would have something like this when trying to harmonize in >>between the several documents we have tnat deals with this specific >>representation issue, i also think it provides the distinction you're >>asking for b/w fiber and so-called clear channels: >> >>2.4.4. Lambda-Switch Capable >> >> If an interface is of type LSC, it means that the node receiving data >> over this interface can recognize and switch individual lambdas >> within the interface. An interface that allows only one lambda per >> interface, and switches just that lambda is of type LSC. >> > This includes interfaces that only support fully transparent SONET/SDH >> > signals, as defined in [GMPLS-SONET-SDH]. >> >>[...] >> >>2.4.7. Interface Switching Capabilities and Labels >> >> [PSC, PSC] - label is carried in the "shim" header [RFC3032] >> > [TDM, TDM] - label represents a timeslot ([GMPLS-SONET-SDH], >> [GMPLS-G709]) >> > [LSC, LSC] - label represents a G.709 OCh/lambda/port >> > [FSC, FSC] - label represents a fiber (i.e. physical port) >> > [PSC, TDM] - label represents a timeslot ([GMPLS-SONET-SDH], >> [GMPLS-G709]) >> > [PSC, LSC] - label represents a G.709 OCh/lambda/port >> > [PSC, FSC] - label represents a fiber >> > [TDM, LSC] - label represents a G.709 OCh/lambda/port >> > [TDM, FSC] - label represents a fiber >> > [LSC, FSC] - label represents a fiber >> >> > Note: except when explicitly indicated the label encoding MUST follow >> > the rules defined in [RFC3471] Section 3.2. >> >>ps: in fact one sees here that for the "timeslot" case, the switching >>type TDM value equates the encoding one >> >> >>Ong, Lyndon wrote: >> >> >>>Hi Lou, >>> >>>Your proposed text looks pretty good to me. >>> >>>Side note: is there a way that the >>>existing text can be clarified to distinguish >>>between the case of only one lambda allowed >>>on an interface and the case of fiber switching? >>> >>>Currently the text seems to allow an overlap >>>in the case of a non-channelized OC-12/48/etc. as in >>>a sense there is only one "lambda" but you would >>>typically request fiber switching. >>> >>>Cheers, >>> >>>Lyndon >>> >>>-----Original Message----- >>>From: Lou Berger [mailto:lberger@movaz.com] >>>Sent: Friday, March 26, 2004 11:17 AM >>>To: Kireeti Kompella >>>Cc: ccamp@ops.ietf.org; John Drake >>>Subject: RE: Label type to be used >>> >>> >>>Kireeti, >>> I think John's points on (a) and (c) are reasonable. I think the > > >>>only changes needed to the draft-ietf-ccamp-gmpls-routing-09.txt to make >>>this clear are: >>> >>> 2.4.4. Lambda-Switch Capable >>> >>> If an interface is of type LSC, it means that the node receiving data >>> over this interface can recognize and switch individual lambdas >>> within the interface. An interface that allows only one lambda per >>> interface, and switches just that lambda is of type LSC. >>> >>>> This includes interfaces that only support fully transparent SONET/SDH >>>> signals, as defined in [GMPLS-SONET-SDH]. >>> >>>and >>> [PSC, PSC] - label is carried in the "shim" header [RFC3032] >>> [TDM, TDM] - label represents a TDM time slot [GMPLS-SONET-SDH] >>> >>>> [LSC, LSC] - label represents a lambda/port >>> >>> [FSC, FSC] - label represents a port on an OXC >>> [PSC, TDM] - label represents a TDM time slot [GMPLS-SONET-SDH] >>> >>>> [PSC, LSC] - label represents a lambda/port >>> >>> [PSC, FSC] - label represents a port >>> >>>> [TDM, LSC] - label represents a lambda/port >>> >>> [TDM, FSC] - label represents a port >>> [LSC, FSC] - label represents a port >>> >>>Lou >>> >>>PS This matches all but one implementation we've interoperated with. >>> >>>At 01:49 PM 3/26/2004 -0500, John Drake wrote: >>> >>> >>> >>> >>> >>>>>-----Original Message----- >>>>>From: Kireeti Kompella >>>> >>>>[mailto:kireeti@juniper.net] >>>> >>>> >>>> >>>>>Sent: Thursday, March 18, 2004 9:58 AM >>>>>To: ccamp@ops.ietf.org >>>>>Subject: Label type to be used >>>>> >>>>>Hi, >>>>> >>>>>Arthi and Lou pointed out the following typos in the GMPLS routing doc >>>>>(draft-ietf-ccamp-gmpls-routing-09.txt) which is now in the RFC >>>>>Editor's queue: >>>>> >>>>>In section 2.4.7 is the following table defining the type of label >>>>>for various combinations of switching types: >>>>> >>>>> [PSC, PSC] - label is carried in the "shim" header [RFC3032] >>>>> [TDM, TDM] - label represents a TDM time slot [GMPLS-SONET-SDH] >>>>> [LSC, LSC] - label represents a lambda >>>>> [FSC, FSC] - label represents a port on an OXC >>>>> [PSC, TDM] - label represents a TDM time slot [GMPLS-SONET-SDH] >>>>> [PSC, LSC] - label represents a lambda >>>>> [PSC, FSC] - label represents a port >>>>> [TDM, LSC] - label represents a lambda >>>>> [TDM, FSC] - label represents a port >>>>> [LSC, FSC] - label represents a port >>>>> >>>>>The one at issue is [PSC, LSC]; above it says that the label >>>>>represents a lambda; and in the case of [PSC, TDM] with a fully >>>>>transparent signal, the above indicates the label represents a TDM >>>>>time slot. The proposal is to change this to: >>>>> >>>>> [PSC, PSC] - label is carried in the "shim" header [RFC3032] >>>>> [TDM, TDM] - label represents a TDM time slot [GMPLS-SONET-SDH] >>>>> [LSC, LSC] - label represents a lambda >>>>> [FSC, FSC] - label represents a port on an OXC >>>>> [PSC, TDM] - fully transparent signal: label represents a port >>>>> ("transparency" is defined in [GMPLS-SONET-SDH]) >>>>> [PSC, TDM] - non-transparent signal: label represents a TDM time >>>>> slot [GMPLS-SONET-SDH] >>>>> [PSC, LSC] - label represents a port >>>>> [PSC, FSC] - label represents a port >>>>> [TDM, LSC] - label represents a lambda >>>>> [TDM, FSC] - label represents a port >>>>> [LSC, FSC] - label represents a port >>>>> >>>>>Please respond by Friday 3/26, 5pm PST with comments on: >>>>> >>>>>a) do you agree with the above change? >>>> >>>>[John Drake] >>>> >>>>I don't have a problem with the [PSC, LSC] change but I don't >>>>understand the distinction between transparent and non-transparent >>>>TDM as it pertains to GMPLS routing. As I indicated in a previous >>>>e-mail, I think the transparent TDM case should be handled with a >>>>switching type of LSC and an encoding type of SDH/SONET, and I think >>>>that this should be specified in the SDH/SONET I-D, where the distinction >>>>between transparent and non-transparent TDM is defined, rather than in >>>>this document. >>>> >>>> >>>> >>>> >>>>>b) in your implementation today, what do expect the label to represent >>>>> i) in the case of [PSC, LSC]? >>>> >>>>[John Drake] >>>> >>>>Port/lambda >>>> >>>> >>>> >>>> >>>>> ii) in the case of [PSC, TDM] with a fully transparent signal? >>>>>c) if you implement as the draft says, would it be a hardship to change >>>>> this? >>>> >>>>[John Drake] >>>> >>>>N/A. Labels for SDH/SONET are defined in the SDH/SONET I-D and it's > > pretty > >>>>clear about which types of labels are in the transparent and > > non-transparent > >>>>TDM cases. >>>> >>>> >>>> >>>> >>>>>If we can get closure on this, I'll take up the task of modifying the >>>>>pending RFC with the ADs. >>>>> >>>>>Kireeti. >>>>>------- >>> >>> >>> > -- Papadimitriou Dimitri E-mail : dimitri.papadimitriou@alcatel.be E-mail : dpapadimitriou@psg.com Webpage: http://psg.com/~dpapadimitriou/ Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium Phone : +32 3 240-8491 From owner-ccamp@ops.ietf.org Fri Apr 2 11:25:01 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16803 for ; Fri, 2 Apr 2004 11:25:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9RTa-0007YS-00 for ccamp-archive@ietf.org; Fri, 02 Apr 2004 11:25:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9RSg-0007RL-00 for ccamp-archive@ietf.org; Fri, 02 Apr 2004 11:24:07 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1B9RRs-0007Jz-00 for ccamp-archive@ietf.org; Fri, 02 Apr 2004 11:23:16 -0500 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B9RCc-000H1S-HH for ccamp-data@psg.com; Fri, 02 Apr 2004 16:07:30 +0000 Received: from [195.101.245.15] (helo=p-mail1.rd.francetelecom.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B9RC0-000Go7-2C for ccamp@ops.ietf.org; Fri, 02 Apr 2004 16:06:52 +0000 Received: from lanmhs30.rd.francetelecom.fr ([10.193.21.61]) by parsmtp2.rd.francetelecom.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 2 Apr 2004 18:06:44 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: Comments on draft-vasseur-ccamp-loose-path-reopt-00.txt Date: Fri, 2 Apr 2004 18:06:41 +0200 Message-ID: Thread-Topic: Comments on draft-vasseur-ccamp-loose-path-reopt-00.txt Thread-Index: AcQCH+OQccr2mM1QTkKewTXvmKgZsAVw2z3A From: "LE ROUX Jean-Louis FTRD/DAC/LAN" To: "Jean Philippe Vasseur" , Cc: X-OriginalArrivalTime: 02 Apr 2004 16:06:44.0399 (UTC) FILETIME=[7E43E3F0:01C418CC] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Hi JP, Yuichi Please find below comments related to your loose path reoptimization ID 1) General Comment As regards applicability to inter-area/AS TE, this proposal seems really relevant.=20 IMHO, mid-point indication of better path/local maintenance may also be extended to the case of strictly routed inter-area/AS TE-LSPs whose path have been computed thanks to PCE based computation. Indeed, if PCE based inter-area/AS path computation allows for timer driven reoptimization (the HE LSR periodically sends a PC request to check if there is a better e2e path), in return it does not allow for event driven reoptimization (PCEs in downstream area/AS won't react to any network event, as they are stateless).=20 Thus it may, IMHO, be relevant that an ABR/ASBR notify the HE LSR when there is a better path or local maintenance in a donwstream area, on a strictely routed inter-area/AS TE-LSPs whose path has been computed by PCEs, so that the HE LSR trigger a PCE based e2e reoptimization.=20 2) Section 3: IMHO it would be better to encode the ERO Expansion Request in the newly defined LSP_ATTRIBUTE Object, or maybe in a=20 new dedicated object, as this is not, stictly speaking, an attribute of the LSP. Clarification is required for the Note in 3.1: Do you mean that the ERO Exapnsion Request bit itself could directly trigger a change of component link in a bundle ? 3) Section 4.1 I would remove the following sentence "In particular, when a better path is discovered, one could conceivably envisage reoptimizing the TE LSP=20 on a mid-point LSR",=20 Your draft applies to contiguous LSPs. Mid-point reoptimization cannot be envisaged anyway, for the simple reason that this would require change in the LSP id that is under strict control of the HE LSR. 4) Section 4.3.1 "By default,=20 an LSR uses the IGP metric in their CSPF to compute the shortest path=20 that obeys a set of constraints."=20 TE metric is the default metric in CSPF isn't it ? 5) Section 4.3.1 The operation that is triggered on a mid-point LSR, on receipt of a Path with the ERO expansion desired bit set, is , IMHO not actually an ERO expansion but just a new path compuation to the next loose hop. Here the mid-point LSR does not modify the ERO of the currently signaled LSP.=20 Strictly speaking the ERO expansion =3D Computation of the path to the loose next hop + inclusion of the path in the ERO. Actually ERO expansion is triggered on mid-points only when the HE LSR starts the make-before-break procedure and signals a new LSP (new LSP id). Thus I would suggest to change the name of the "ERO Expansion Request" bit, to "Path Re-evaluation Desired" bit. Same comment in section 4.3.2: "In this mode, a mid-point LSR whose next abstract node is a loose hop=20 can locally trigger an ERO expansion (when a configurable timer expires=20 or on event-driven basis" Actually the mid-point LSR does not trigger ERO expansion, but only path re-evaluation 6) End of section 4.3.2: "Note that those modes are not exclusive: both the timer and even-driven reoptimization triggers can be implemented on the head-end and/or any=20 mid-point LSR with potentially different timer values for the timer=20 driven reoptimization case".=20 Agree, but is there really an interest to configure at the same time: -Timer driven reoptimization on head-end LSRs, ie peridoc HE reopt request thanks the ERO Expansion bit -Timer driven reoptimization on mid-point LSRs This seems quite redundant as the periodic HE reopt request triggers periodic path re-evaluation on mid-point LSRs. 7)=20 I suggest adding the use of the RSVP Notify message as an alternative to the RSVP PathErr message, for signaling of better path/local maintenance to the Head-End , as this draft actually also applies to GMPLS. Hope this will help Regards JL From owner-ccamp@ops.ietf.org Fri Apr 2 11:45:57 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17760 for ; Fri, 2 Apr 2004 11:45:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9Rnq-0002qZ-00 for ccamp-archive@ietf.org; Fri, 02 Apr 2004 11:45:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9Rms-0002iR-00 for ccamp-archive@ietf.org; Fri, 02 Apr 2004 11:44:58 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1B9Rlw-0002Yc-00 for ccamp-archive@ietf.org; Fri, 02 Apr 2004 11:44:00 -0500 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B9Rc7-0009jN-Up for ccamp-data@psg.com; Fri, 02 Apr 2004 16:33:51 +0000 Received: from [195.101.245.16] (helo=p-mail2.rd.francetelecom.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B9RbW-00099x-O3; Fri, 02 Apr 2004 16:33:14 +0000 Received: from lanmhs30.rd.francetelecom.fr ([10.193.21.61]) by parsmtp2.rd.francetelecom.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 2 Apr 2004 18:33:08 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE : RE : TR : I-D ACTION:draft-ietf-tewg-interarea-mpls-te-req-00.txt Date: Fri, 2 Apr 2004 18:33:05 +0200 Message-ID: Thread-Topic: RE : TR : I-D ACTION:draft-ietf-tewg-interarea-mpls-te-req-00.txt Thread-Index: AcQYhcIyp7uZkgsvSFetYCNV94sw3AAR4b1w From: "LE ROUX Jean-Louis FTRD/DAC/LAN" To: Cc: , , , "Jean Philippe Vasseur" X-OriginalArrivalTime: 02 Apr 2004 16:33:08.0367 (UTC) FILETIME=[2E6239F0:01C418D0] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Hi Dimitri, See in-line > > Basically the solution must preserve IGP hierarchy, and thus must=20 > > preclude leaking of any TOPOLOGY related information accross areas,=20 > > including TE link information such as carried in ISIS Extended IS=20 > > reacheability TLV, or OSPF TE LSA Link TLV. Note that this also=20 > > precludes leaking of any summarized/aggregated TE information, such=20 > > that the advertisement of maximum unreserved bandwdith=20 > between an ABR=20 > > and any end-point LSR. We will clarify that in next revision. >=20 > this would refine the above requirement (such TE link=20 > information would be precluded in any of its form) Yes , and such precluding is IMHO a key requirement to preserve=20 the main interests of IGP area partitionning isn't it ? > > In return we definitely not preclude leaking of NON=20 > TOPOLOGY related=20 > > information such as TE node capabilities, provided that IGP=20 > > scalability is not impacted. >=20 > more than probably, it is not within this kind of document to=20 > provide a kind of classification of such information but the=20 > latter would help in detailing the "discovery" concepts (see=20 > also section 7.12) in terms of functionality that would be=20 > required here: identity, capability & associated capability You are right, we will try to be more precise as regards discovery, in the next revision. Not sure to well understand what you mean by associated capability ? > >>> 5) section 7.7 > >>>=20 > >>> "This may reduce the recovery delay, but with the risk of > >>> multiple crankbacks, and sub-optimality. " > >>>=20 > >>> i agree, but this is valid iff the head-end has initially=20 > computed=20 > >>> an end-to-end optimal path, > >>=20 > >> more exactly this applies to contiguous LSP. For=20 > sub-optimality this=20 > >> applies to any kind of LSP. > >>=20 > >>=20 > >>> also unclear if you refer also here to the provisioning delay ? > >=20 > >=20 > > Actually this section is not dedicated to crankback routing=20 > as a path=20 > > computation method, it only addresses possible use of crankback in=20 > > case of network failure. Thus we refer here only to the recovery=20 > > delay. We may add a section dedicated to crankback routing=20 > in the next=20 > > revision >=20 > i would agree to have a requirement document that includes a=20 > dedicated=20 > section on crankback functionality, hope the next release will clarify >=20 We will do it, while trying to stay, as far as possible, solution agnostic. Again thanks for these really helpfull comments Regards JL From owner-ccamp@ops.ietf.org Fri Apr 2 12:36:03 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20413 for ; Fri, 2 Apr 2004 12:36:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9SaL-0002hl-00 for ccamp-archive@ietf.org; Fri, 02 Apr 2004 12:36:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9SZf-0002af-00 for ccamp-archive@ietf.org; Fri, 02 Apr 2004 12:35:24 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1B9SZC-0002Ra-00 for ccamp-archive@ietf.org; Fri, 02 Apr 2004 12:34:54 -0500 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B9SP5-000MdC-S9 for ccamp-data@psg.com; Fri, 02 Apr 2004 17:24:27 +0000 Received: from [171.71.176.72] (helo=sj-iport-3.cisco.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B9SOr-000McV-FC for ccamp@ops.ietf.org; Fri, 02 Apr 2004 17:24:13 +0000 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 02 Apr 2004 09:32:13 +0000 Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i32HOAUe000377; Fri, 2 Apr 2004 09:24:10 -0800 (PST) Received: from jvasseur-w2k01.cisco.com (che-vpn-cluster-1-134.cisco.com [10.86.240.134]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id JAA03836; Fri, 2 Apr 2004 09:24:09 -0800 (PST) Message-Id: <4.3.2.7.2.20040402120415.071e1128@wells.cisco.com> X-Sender: jvasseur@wells.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 02 Apr 2004 12:24:07 -0500 To: "LE ROUX Jean-Louis FTRD/DAC/LAN" From: Jean Philippe Vasseur Subject: Re: Comments on draft-vasseur-ccamp-loose-path-reopt-00.txt Cc: , In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Hi Jean-Louis, At 06:06 PM 4/2/2004 +0200, LE ROUX Jean-Louis FTRD/DAC/LAN wrote: >Hi JP, Yuichi > >Please find below comments related to your loose path reoptimization ID > > >1) General Comment > >As regards applicability to inter-area/AS TE, this proposal seems really >relevant. Thanks, >IMHO, mid-point indication of better path/local maintenance may also be >extended to the case of strictly routed inter-area/AS TE-LSPs whose path >have been computed thanks to PCE based computation. >Indeed, if PCE based inter-area/AS path computation allows for timer >driven reoptimization (the HE LSR periodically sends a PC request to >check if there is a better e2e path), in return it does not allow for >event driven reoptimization (PCEs in downstream area/AS won't react to >any network event, as they are stateless). >Thus it may, IMHO, be relevant that an ABR/ASBR notify the HE LSR when >there is a better path or local maintenance in a donwstream area, on a >strictely routed inter-area/AS TE-LSPs whose path has been computed by >PCEs, so that the HE LSR trigger a PCE based e2e reoptimization. This is an excellent point, fully agree. >2) >Section 3: >IMHO it would be better to encode the ERO Expansion Request in the newly >defined LSP_ATTRIBUTE Object, or maybe in a >new dedicated object, as this is not, stictly speaking, an attribute of >the LSP. > >Clarification is required for the Note in 3.1: >Do you mean that the ERO Exapnsion Request bit itself could directly >trigger a change of component link in a bundle ? right >3) >Section 4.1 > >I would remove the following sentence "In particular, when a better path > >is discovered, one could conceivably envisage reoptimizing the TE LSP >on a mid-point LSR", >Your draft applies to contiguous LSPs. Mid-point reoptimization cannot >be envisaged anyway, for the simple reason that this would require >change in the LSP id that is under strict control of the HE LSR. I agree, you see what we meant here, but indeed, this could be confusing. >4) >Section 4.3.1 > "By default, >an LSR uses the IGP metric in their CSPF to compute the shortest path >that obeys a set of constraints." > >TE metric is the default metric in CSPF isn't it ? Well sure, this will be fixed. The point was just to mention the possibility to use either the IGP or the TE metric to compute the shortest path. >5) >Section 4.3.1 > >The operation that is triggered on a mid-point LSR, on receipt of a Path >with the ERO expansion desired bit set, is , IMHO not actually an ERO >expansion but just a new path compuation to the next loose hop. Right >Here the >mid-point LSR does not modify the ERO of the currently signaled LSP. >Strictly speaking the ERO expansion = Computation of the path to the >loose next hop + inclusion of the path in the ERO. >Actually ERO expansion is triggered on mid-points only when the HE LSR >starts the make-before-break procedure and signals a new LSP (new LSP >id). > >Thus I would suggest to change the name of the "ERO Expansion Request" >bit, to "Path Re-evaluation Desired" bit. > >Same comment in section 4.3.2: "In this mode, a mid-point LSR whose next >abstract node is a loose hop >can locally trigger an ERO expansion (when a configurable timer expires >or on event-driven basis" > >Actually the mid-point LSR does not trigger ERO expansion, but only path >re-evaluation This is right (more a question of terminology though). >6) >End of section 4.3.2: > >"Note that those modes are not exclusive: both the timer and even-driven > >reoptimization triggers can be implemented on the head-end and/or any >mid-point LSR with potentially different timer values for the timer >driven reoptimization case". > >Agree, but is there really an interest to configure at the same time: > -Timer driven reoptimization on head-end LSRs, ie peridoc HE >reopt request thanks the ERO Expansion bit > -Timer driven reoptimization on mid-point LSRs >This seems quite redundant as the periodic HE reopt request triggers >periodic path re-evaluation on mid-point LSRs. Well it is not quite redundant since there might be some cases where it might be desirable to configure different timers. For instance, consider the fact of a head-end LSR having inter-area/AS TE LSPs traversing different area/AS each having different characteristics. You may want to have a slow timer on the head-end LSR, and more aggressive timers in *some* areas/ASes (ABRs/ASBRs). Note that the receipt of a unsolicited "better path exists" notification can have the effect of delaying the next "ERO expansion request" sent by the LSR. >7) >I suggest adding the use of the RSVP Notify message as an alternative to >the RSVP PathErr message, for signaling of better path/local maintenance >to the Head-End , as this draft actually also applies to GMPLS. Well I would prefer to keep one message type for the purpose of notification rather than 2 (moreover PERR Notify also applies to GMPLS). >Hope this will help It does, thanks for your, as usual, very valuable comments. JP. >Regards > >JL From owner-ccamp@ops.ietf.org Fri Apr 2 14:47:03 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24612 for ; Fri, 2 Apr 2004 14:47:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9Ud5-0004BJ-00 for ccamp-archive@ietf.org; Fri, 02 Apr 2004 14:47:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9Uc7-00041v-00 for ccamp-archive@ietf.org; Fri, 02 Apr 2004 14:46:03 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1B9Ub7-0003n4-00 for ccamp-archive@ietf.org; Fri, 02 Apr 2004 14:45:01 -0500 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B9ULu-000NYS-J0 for ccamp-data@psg.com; Fri, 02 Apr 2004 19:29:18 +0000 Received: from [192.157.130.21] (helo=sa.infonet.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B9ULe-000NUS-JT for ccamp@ops.ietf.org; Fri, 02 Apr 2004 19:29:02 +0000 Received: from zhangr2.sa.infonet.com (sfjl114.us.info.net [204.79.139.114] (may be forged)) by sa.infonet.com with ESMTP id i32JSs0r013987; Fri, 2 Apr 2004 19:28:54 GMT Message-Id: <6.0.3.0.2.20040402112532.04240998@sa.infonet.com> X-Mailer: QUALCOMM Windows Eudora Version 6.0.3.0 Date: Fri, 02 Apr 2004 11:28:50 -0800 To: Jean Philippe Vasseur , raymond zhang From: raymond zhang Subject: Re: Some minor comments on the loose-path-opt draft Cc: y.ikejiri@ntt.com, ccamp@ops.ietf.org In-Reply-To: <4.3.2.7.2.20040401144213.020c7ce0@wells.cisco.com> References: <6.0.3.0.2.20040329220222.02a41a10@delta.info.net> <4.3.2.7.2.20040401144213.020c7ce0@wells.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Hi JP, [snop...] >>2. Other comments: >> >>2.1. In section 4.3.1, page 7 >>"- If a better path can be found, the LSR MUST >> immediately send a Path Error to the head-end LSR >> (Error code 25 (Notify), sub-code=6 (better path >> exists))" >> >>I wonder if you should also add "and go ahead with reopt by sending RSVP >>path messages for the new path". Otherwise there is no action described >>for this mid-point LSR what it will do after it found a better path and >>notify the HE LSR. > >In this case, the TE LSP is contiguous, hence the mid-point's role is just >to notify of the existence of a better path (or the requirement for local >maintenance) in some downstream area/AS. Note that it cannot locally >reoptimize since the LSP ID would not match. Moreover, the intention is to >let the Head-end LSR decide on whether to reoptimize depending on the TE >LSP attributes (pending back-off, ...). > >Does that make sense ? yes it does... your're right that the mid-point LSR can not reopt on its own since HE LSR controls the LSP ID but it will need to re-expand the ERO to the next loop hop. That's what I meant. Cheers, Raymond >Thanks for your useful comments: they will be incorporated in the next >revision. > >JP. > > >>Regards, >>Raymond >> >> > From owner-ccamp@ops.ietf.org Fri Apr 2 15:02:06 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25302 for ; Fri, 2 Apr 2004 15:02:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9Ure-0006M3-00 for ccamp-archive@ietf.org; Fri, 02 Apr 2004 15:02:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9Uqk-0006Ee-00 for ccamp-archive@ietf.org; Fri, 02 Apr 2004 15:01:11 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1B9UqF-00067a-00 for ccamp-archive@ietf.org; Fri, 02 Apr 2004 15:00:39 -0500 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B9UiU-000Iwv-Fq for ccamp-data@psg.com; Fri, 02 Apr 2004 19:52:38 +0000 Received: from [171.71.176.72] (helo=sj-iport-3.cisco.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B9Ui8-000ILy-Qq for ccamp@ops.ietf.org; Fri, 02 Apr 2004 19:52:16 +0000 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 02 Apr 2004 12:00:18 +0000 Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i32JqEn2019065; Fri, 2 Apr 2004 11:52:14 -0800 (PST) Received: from jvasseur-w2k01.cisco.com (che-vpn-cluster-1-134.cisco.com [10.86.240.134]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id LAA29481; Fri, 2 Apr 2004 11:52:13 -0800 (PST) Message-Id: <4.3.2.7.2.20040402145128.06346fd8@wells.cisco.com> X-Sender: jvasseur@wells.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 02 Apr 2004 14:52:12 -0500 To: raymond zhang From: Jean Philippe Vasseur Subject: Re: Some minor comments on the loose-path-opt draft Cc: raymond zhang , y.ikejiri@ntt.com, ccamp@ops.ietf.org In-Reply-To: <6.0.3.0.2.20040402112532.04240998@sa.infonet.com> References: <4.3.2.7.2.20040401144213.020c7ce0@wells.cisco.com> <6.0.3.0.2.20040329220222.02a41a10@delta.info.net> <4.3.2.7.2.20040401144213.020c7ce0@wells.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Hi Raymond, At 11:28 AM 4/2/2004 -0800, raymond zhang wrote: >Hi JP, > >[snop...] >>>2. Other comments: >>> >>>2.1. In section 4.3.1, page 7 >>>"- If a better path can be found, the LSR MUST >>> immediately send a Path Error to the head-end LSR >>> (Error code 25 (Notify), sub-code=6 (better path >>> exists))" >>> >>>I wonder if you should also add "and go ahead with reopt by sending RSVP >>>path messages for the new path". Otherwise there is no action described >>>for this mid-point LSR what it will do after it found a better path and >>>notify the HE LSR. >> >>In this case, the TE LSP is contiguous, hence the mid-point's role is >>just to notify of the existence of a better path (or the requirement for >>local maintenance) in some downstream area/AS. Note that it cannot >>locally reoptimize since the LSP ID would not match. Moreover, the >>intention is to let the Head-end LSR decide on whether to reoptimize >>depending on the TE LSP attributes (pending back-off, ...). >> >>Does that make sense ? > >yes it does... your're right that the mid-point LSR can not reopt on its >own since HE LSR controls the LSP ID but it will need to re-expand the ERO >to the next loop hop. That's what I meant. Excellent, we're in full sync, Thanks JP. >Cheers, >Raymond > > > > >>Thanks for your useful comments: they will be incorporated in the next >>revision. >> >>JP. >> >> >>>Regards, >>>Raymond >>> > > From owner-ccamp@ops.ietf.org Fri Apr 2 16:41:49 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02923 for ; Fri, 2 Apr 2004 16:41:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9WQA-0007G9-00 for ccamp-archive@ietf.org; Fri, 02 Apr 2004 16:41:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9WP7-000715-00 for ccamp-archive@ietf.org; Fri, 02 Apr 2004 16:40:46 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1B9WNX-0006e8-00 for ccamp-archive@ietf.org; Fri, 02 Apr 2004 16:39:07 -0500 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B9W8J-000Kba-PY for ccamp-data@psg.com; Fri, 02 Apr 2004 21:23:23 +0000 Received: from [80.168.70.142] (helo=relay2.mail.uk.clara.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B9W7I-000JfL-2f for ccamp@ops.ietf.org; Fri, 02 Apr 2004 21:22:20 +0000 Received: from du-069-0605.access.clara.net ([217.158.156.96] helo=Puppy) by relay2.mail.uk.clara.net with smtp (Exim 4.30) id 1B9W7G-000Ess-Bw for ccamp@ops.ietf.org; Fri, 02 Apr 2004 22:22:19 +0100 Message-ID: <032101c418f8$9603bd40$7a9c9ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Fw: I-D ACTION:draft-ietf-ccamp-gmpls-alarm-spec-00.txt Date: Fri, 2 Apr 2004 22:22:14 +0100 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_031D_01C41900.F3698610" 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-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 This is a multi-part message in MIME format. ------=_NextPart_000_031D_01C41900.F3698610 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Forwarded as mailing list was not copied ----- Original Message ----- From: To: Sent: Friday, April 02, 2004 6:15 PM Subject: I-D ACTION:draft-ietf-ccamp-gmpls-alarm-spec-00.txt > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. > > Title : GMPLS - Communication of Alarm Information > Author(s) : L. Berger > Filename : draft-ietf-ccamp-gmpls-alarm-spec-00.txt > Pages : 17 > Date : 2004-4-1 > > This document describes an extension to Generalized MPLS (Multi- > Protocol Label Switching) signaling to support communication of alarm > information. GMPLS signaling already supports the control of alarm > reporting, but not the communication of alarm information. This > document presents both a functional description and GMPLS-RSVP > specifics of such an extension. This document also proposes > modification of the RSVP ERROR_SPEC object. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-alarm-spec-00.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > > Internet-Drafts are also available by anonymous FTP. Login with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-ccamp-gmpls-alarm-spec-00.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-ccamp-gmpls-alarm-spec-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_031D_01C41900.F3698610 Content-Type: application/octet-stream; name="ATT00762.dat" Content-Disposition: attachment; filename="ATT00762.dat" Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <2004-4-2122933.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-gmpls-alarm-spec-00.txt ------=_NextPart_000_031D_01C41900.F3698610 Content-Type: text/plain; name="draft-ietf-ccamp-gmpls-alarm-spec-00.txt" Content-Disposition: attachment; filename="draft-ietf-ccamp-gmpls-alarm-spec-00.txt" Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <2004-4-2122933.I-D@ietf.org> ------=_NextPart_000_031D_01C41900.F3698610-- From owner-ccamp@ops.ietf.org Fri Apr 2 16:44:35 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03249 for ; Fri, 2 Apr 2004 16:44:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9WSq-00000I-00 for ccamp-archive@ietf.org; Fri, 02 Apr 2004 16:44:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9WRv-0007cX-00 for ccamp-archive@ietf.org; Fri, 02 Apr 2004 16:43:40 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1B9WQx-0007RC-00 for ccamp-archive@ietf.org; Fri, 02 Apr 2004 16:42:39 -0500 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B9W93-000LPZ-Cc for ccamp-data@psg.com; Fri, 02 Apr 2004 21:24:09 +0000 Received: from [80.168.70.142] (helo=relay2.mail.uk.clara.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B9W7G-000JfE-Rz for ccamp@ops.ietf.org; Fri, 02 Apr 2004 21:22:19 +0000 Received: from du-069-0605.access.clara.net ([217.158.156.96] helo=Puppy) by relay2.mail.uk.clara.net with smtp (Exim 4.30) id 1B9W7F-000Ess-AN for ccamp@ops.ietf.org; Fri, 02 Apr 2004 22:22:17 +0100 Message-ID: <032001c418f8$9522fa30$7a9c9ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Fw: I-D ACTION:draft-ietf-ccamp-gmpls-egress-control-00.txt Date: Fri, 2 Apr 2004 22:21:58 +0100 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_030D_01C41900.E9AD2730" 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-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 This is a multi-part message in MIME format. ------=_NextPart_000_030D_01C41900.E9AD2730 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Forwarded as mailing list was not copied ----- Original Message ----- From: To: Sent: Friday, April 02, 2004 6:15 PM Subject: I-D ACTION:draft-ietf-ccamp-gmpls-egress-control-00.txt > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. > > Title : GMPLS Signaling Procedure For Egress Control > Author(s) : L. Berger > Filename : draft-ietf-ccamp-gmpls-egress-control-00.txt > Pages : 5 > Date : 2004-4-1 > > This note clarifies the procedures for the control of a label used on > an egress output/downstream interface. Such control is also known as > "Egress Control". Support for Egress Control is implicit in > Generalized Multi-Protocol Label Switching (GMPLS) Signaling. This > note does not modify GMPLS signaling mechanisms and procedures and > should be viewed as an informative clarification of GMPLS Signaling > - Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) > Extensions, [RFC3473]. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-egress-control-00.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > > Internet-Drafts are also available by anonymous FTP. Login with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-ccamp-gmpls-egress-control-00.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-ccamp-gmpls-egress-control-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_030D_01C41900.E9AD2730 Content-Type: application/octet-stream; name="ATT00776.dat" Content-Disposition: attachment; filename="ATT00776.dat" Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <2004-4-2123056.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-gmpls-egress-control-00.txt ------=_NextPart_000_030D_01C41900.E9AD2730 Content-Type: text/plain; name="draft-ietf-ccamp-gmpls-egress-control-00.txt" Content-Disposition: attachment; filename="draft-ietf-ccamp-gmpls-egress-control-00.txt" Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <2004-4-2123056.I-D@ietf.org> ------=_NextPart_000_030D_01C41900.E9AD2730-- From owner-ccamp@ops.ietf.org Fri Apr 2 18:39:11 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13814 for ; Fri, 2 Apr 2004 18:39:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9YFl-0003Ka-00 for ccamp-archive@ietf.org; Fri, 02 Apr 2004 18:39:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9YEn-0003Cx-00 for ccamp-archive@ietf.org; Fri, 02 Apr 2004 18:38:13 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1B9YDr-00035X-00 for ccamp-archive@ietf.org; Fri, 02 Apr 2004 18:37:16 -0500 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B9Xw7-000M0X-Mg for ccamp-data@psg.com; Fri, 02 Apr 2004 23:18:55 +0000 Received: from [63.102.55.206] (helo=lightwave.chromisys.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B9Xw6-000M0B-MQ for ccamp@ops.ietf.org; Fri, 02 Apr 2004 23:18:54 +0000 Received: by lightwave.chromisys.com with Internet Mail Service (5.5.2653.19) id ; Fri, 2 Apr 2004 15:18:50 -0800 Message-ID: <9D42C6E086250248810DCADA39CE7EFC011446A7@nimbus.chromisys.com> From: Ayan Banerjee To: "'Adrian Farrel'" Cc: ccamp@ops.ietf.org Subject: RE: Layer One VPNs Date: Fri, 2 Apr 2004 15:18:49 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 I agree with Yakov. Ayan > -----Original Message----- > From: owner-ccamp@ops.ietf.org > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Yakov Rekhter > Sent: Tuesday, March 30, 2004 12:35 AM > To: Adrian Farrel > Cc: ccamp@ops.ietf.org > Subject: Layer One VPNs > > Adrian, > > > Hi, > > > > Although Layer One VPNs do not currently have a home in any IETF > > working group, we were the recipients of a liaison from ITU-T SG13 > > informing us about the work they are doing on this topic > and pointing > > us at > > > http://www.ietf.org/internet-drafts/draft-takeda-l1vpn-framework-00.tx > > t > > > > If anyone has comments on this work they can send them to > this mailing > > list (until another home is found in the IETF) or to the > authors direct. > > I think that this is important work, and that the home for > this work in the IETF should be the CCAMP WG. > > Yakov. > > From owner-ccamp@ops.ietf.org Fri Apr 2 21:30:25 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19165 for ; Fri, 2 Apr 2004 21:30:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9avR-0002XX-00 for ccamp-archive@ietf.org; Fri, 02 Apr 2004 21:30:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9auX-0002Pw-00 for ccamp-archive@ietf.org; Fri, 02 Apr 2004 21:29:29 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1B9auG-0002I0-00 for ccamp-archive@ietf.org; Fri, 02 Apr 2004 21:29:12 -0500 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B9ac9-000Imv-Hi for ccamp-data@psg.com; Sat, 03 Apr 2004 02:10:29 +0000 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B9ac8-000Ij4-Ge; Sat, 03 Apr 2004 02:10:28 +0000 Date: Fri, 2 Apr 2004 18:10:26 -0800 From: Alex Zinin Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <264514881.20040402181026@psg.com> To: "Adrian Farrel" CC: "'Kireeti Kompella'" , ccamp@ops.ietf.org Subject: Re: Fw: I-D ACTION:draft-ietf-ccamp-gmpls-g709-07.txt In-Reply-To: <00aa01c4180c$368497f0$7a9c9ed9@Puppy> References: <00aa01c4180c$368497f0$7a9c9ed9@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-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.7 required=5.0 tests=AWL,PRIORITY_NO_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Adrian, Ack. Thanks! -- Alex http://www.psg.com/~zinin/ Thursday, April 1, 2004, 6:30:06 AM, Adrian Farrel wrote: > Alex, > draft-ietf-ccamp-gmpls-g709 has successfully completed working group last call and has > been marked up to fix the minor comments that were raised. > Would you take this draft to the IESG on our behalf with a view to it becoming a standards > track RFC. > Thank you (let me know if there is any other formal process I should complete). > Adrian > ----- Original Message ----- > From: > To: > Sent: Thursday, April 01, 2004 2:11 PM > Subject: I-D ACTION:draft-ietf-ccamp-gmpls-g709-07.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 MPLS Signalling Extensions for G.709 Optical Transport Networks > Control >> Author(s) : D. Papadimitriou >> Filename : draft-ietf-ccamp-gmpls-g709-07.txt >> Pages : 21 >> Date : 2004-3-31 >> >> This document is a companion to the Generalized MPLS (GMPLS) >> signalling documents. It describes the technology specific >> information needed to extend GMPLS signalling to control Optical >> Transport Networks (OTN); it also includes the so-called pre-OTN >> developments. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-g709-07.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-g709-07.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-g709-07.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 Apr 3 04:04:34 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13002 for ; Sat, 3 Apr 2004 04:04:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9h4s-0004hl-00 for ccamp-archive@ietf.org; Sat, 03 Apr 2004 04:04:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9h46-0004bD-00 for ccamp-archive@ietf.org; Sat, 03 Apr 2004 04:03:47 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1B9h3G-0004UI-00 for ccamp-archive@ietf.org; Sat, 03 Apr 2004 04:02:54 -0500 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B9gqE-000614-RK for ccamp-data@psg.com; Sat, 03 Apr 2004 08:49:26 +0000 Received: from [62.23.212.165] (helo=smail.alcatel.fr) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B9gqD-00060W-50; Sat, 03 Apr 2004 08:49:25 +0000 Received: from bemail05.netfr.alcatel.fr (bemail05.netfr.alcatel.fr [155.132.251.11]) by smail.alcatel.fr (ALCANET/NETFR) with ESMTP id i338nJpv027774; Sat, 3 Apr 2004 10:49:19 +0200 Received: from alcatel.be ([138.203.118.2]) by bemail05.netfr.alcatel.fr (Lotus Domino Release 5.0.11) with ESMTP id 2004040310491688:855 ; Sat, 3 Apr 2004 10:49:16 +0200 Message-ID: <406E7AFB.2060704@alcatel.be> Date: Sat, 03 Apr 2004 10:51:07 +0200 From: Dimitri.Papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.5) Gecko/20030925 X-Accept-Language: en-us, en MIME-Version: 1.0 To: LE ROUX Jean-Louis FTRD/DAC/LAN Cc: ccamp@ops.ietf.org, mpls@UU.NET, te-wg@ops.ietf.org, Jean Philippe Vasseur Subject: Re: RE : RE : TR : I-D ACTION:draft-ietf-tewg-interarea-mpls-te-req-00.txt References: In-Reply-To: X-MIMETrack: Itemize by SMTP Server on BEMAIL05/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 04/03/2004 10:49:17, Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 04/03/2004 10:49:19, Serialize complete at 04/03/2004 10:49:19 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed X-Alcanet-MTA-scanned-and-authorized: yes Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit hi jean-louis: >>>Basically the solution must preserve IGP hierarchy, and thus must >>>preclude leaking of any TOPOLOGY related information accross areas, >>>including TE link information such as carried in ISIS Extended IS >>>reacheability TLV, or OSPF TE LSA Link TLV. Note that this also >>>precludes leaking of any summarized/aggregated TE information, such >>>that the advertisement of maximum unreserved bandwdith >> >>between an ABR >> >>>and any end-point LSR. We will clarify that in next revision. >> >>this would refine the above requirement (such TE link >>information would be precluded in any of its form) > > > Yes , and such precluding is IMHO a key requirement to preserve > the main interests of IGP area partitionning isn't it ? > > > >>>In return we definitely not preclude leaking of NON >> >>TOPOLOGY related >> >>>information such as TE node capabilities, provided that IGP >>>scalability is not impacted. >> >>more than probably, it is not within this kind of document to >>provide a kind of classification of such information but the >>latter would help in detailing the "discovery" concepts (see >>also section 7.12) in terms of functionality that would be >>required here: identity, capability & associated capability > > > You are right, we will try to be more precise as regards discovery, in > the next revision. > Not sure to well understand what you mean by associated capability ? i could have call it auxiliary or something like this, it would be capabilities attached to a node but that are not part of the information from which path computation for the inter-area lsp is performed and not part of the information from which the signaling decisions for the inter-area lsp is performed (i.e. typically the pce would fall in this category that would indicate an access to such pce) hope this clarifies, - dimitri. >>>>>5) section 7.7 >>>>> >>>>>"This may reduce the recovery delay, but with the risk of >>>>>multiple crankbacks, and sub-optimality. " >>>>> >>>>>i agree, but this is valid iff the head-end has initially >> >>computed >> >>>>>an end-to-end optimal path, >>>> >>>>more exactly this applies to contiguous LSP. For >> >>sub-optimality this >> >>>>applies to any kind of LSP. >>>> >>>> >>>> >>>>>also unclear if you refer also here to the provisioning delay ? >>> >>> >>>Actually this section is not dedicated to crankback routing >> >>as a path >> >>>computation method, it only addresses possible use of crankback in >>>case of network failure. Thus we refer here only to the recovery >>>delay. We may add a section dedicated to crankback routing >> >>in the next >> >>>revision >> >>i would agree to have a requirement document that includes a >>dedicated >>section on crankback functionality, hope the next release will clarify >> > > > We will do it, while trying to stay, as far as possible, solution > agnostic. > > Again thanks for these really helpfull comments > > Regards > > JL > -- Papadimitriou Dimitri E-mail : dimitri.papadimitriou@alcatel.be E-mail : dpapadimitriou@psg.com Webpage: http://psg.com/~dpapadimitriou/ Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium Phone : +32 3 240-8491 From owner-ccamp@ops.ietf.org Mon Apr 5 14:30:48 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23232 for ; Mon, 5 Apr 2004 14:30:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAYrx-00013O-00 for ccamp-archive@ietf.org; Mon, 05 Apr 2004 14:30:49 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAYdB-0006Sz-00 for ccamp-archive@ietf.org; Mon, 05 Apr 2004 14:15:36 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BAYGV-0003w7-00 for ccamp-archive@ietf.org; Mon, 05 Apr 2004 13:52:07 -0400 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BAXzY-000Kf0-Ui for ccamp-data@psg.com; Mon, 05 Apr 2004 17:34:36 +0000 Received: from [195.8.69.53] (helo=zephir.uk.clara.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BAXzL-000KWK-Pl for ccamp@ops.ietf.org; Mon, 05 Apr 2004 17:34:23 +0000 Received: from du-069-0996.access.clara.net ([217.158.170.233] helo=Puppy) by zephir.uk.clara.net with smtp (Exim 4.22) id 1BAXzH-000OFW-8a; Mon, 05 Apr 2004 18:34:20 +0100 Message-ID: <004501c41b34$3cbd3a20$f99c9ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Cc: Subject: draft-ietf-ccamp-gmpls-egress-control-00.txt Date: Mon, 5 Apr 2004 16:23: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 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Hi Lou, In Seoul we agreed that this draft would become a WG document and we talked a little about doing a working group last call immediately thereafter. Thanks for re-spinning the draft as a WG draft. There are, however, a few nits that I think you should tidy up before we do the last call. Perhaps others would like to pitch in now if they have any substantive comments before the last call. Thanks, Adrian Please give the intended category of the work... Proposed Category: Best Common Practice Please correct draft name as it appears in the title and footers. draft-ietf-ccamp-gmpls-egress-control-00.txt Abstract Please remove [bracketed] citation from abstract. Abstract This note clarifies the procedures for the control of a label used on an egress output/downstream interface. I think this would be better phrased as... This note clarifies the procedures for the control of the label used on output/downstream interface of the final (egress) Label Switching Router (LSR) of a Label Switched Path (LSP). 1. Background The ability to control a label used on an egress output/downstream interface was one of the early requirements for GMPLS. Again, rephrase as... The ability to control the label used on the output/downstream interface of an egress LSR was one of the early requirements for GMPLS. 2.1. ERO Procedures Egress Control occurs when the node processing an ERO is the egress and the ERO contains one or more label subobjects. In view of the text quoted from section 6 of an early draft of GMPLS, we either need to re-cast this whole draft as "Egress Label Control" or we need to generalize the text here as egress control that allows the control of interface, component link and label. I prefer the second option. Compare with section 2.2 which is more general. To support Egress Control, an egress checks to see if the received ERO contains an outgoing/downstream interface. If it does, the type of the subobject or subobjects following the interface are examined. If the associated LSP is unidirectional, one subobject is examined. Two subobjects are examined for bidirectional LSPs. If the U-bit of the subobject being examined is clear (0), then the value of the label is copied into a new Label_Set object. Note, this Label_Set object is for internal use only. This Label_Set object indicates the label value that MUST be used for transmitting traffic associated with the LSP on the indicated outgoing/downstream interface. Not withstanding "this Label_Set object is for internal use only", I find this text a bit peculiar! You really just want to say that this subobject is used to specify the label that the egress MUST apply to traffic that it forwards from this LSP. (Compare with the next paragraph where you do not describe creating an Upstream_Label object for internal use only.) If you insist on talking about the Label_Set object, you will have to be far more specific because there are four different varieties of that object. including if the listed label(s) are not acceptable or cannot be supported in forwarding, SHOULD result in the generation of a PathErr message containing a "Bad EXPLICIT_ROUTE object" error. I'd prefer you to be more explicit... ... containing a "Routing Problem"/"Bad EXPLICIT_ROUTE object" error. 3. Security Considerations < This note clarifies procedures defined in [RFC3473]. As such, no new < security considerations are introduced. > This note reiterates procedures defined in [RFC3473], but does not > define any new procedures. As such, no new security considerations > are introduced. <5. References >5. Normative References Need BCP 78, and 79 as informational references. Also RFC 3668. 8. Intellectual Property Missing the personal disclaimer... By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Don't need the footer... Generated on: Mon Mar 15 10:52:32 2004 From owner-ccamp@ops.ietf.org Mon Apr 5 14:48:41 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23644 for ; Mon, 5 Apr 2004 14:48:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAZ9G-0002bA-00 for ccamp-archive@ietf.org; Mon, 05 Apr 2004 14:48:42 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAYkL-00008f-00 for ccamp-archive@ietf.org; Mon, 05 Apr 2004 14:22:59 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BAYXc-0005UZ-00 for ccamp-archive@ietf.org; Mon, 05 Apr 2004 14:09:48 -0400 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BAYOH-000116-QT for ccamp-data@psg.com; Mon, 05 Apr 2004 18:00:09 +0000 Received: from [195.8.69.53] (helo=zephir.uk.clara.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BAYO7-0000xw-Tm for ccamp@ops.ietf.org; Mon, 05 Apr 2004 18:00:00 +0000 Received: from du-069-0996.access.clara.net ([217.158.170.233] helo=Puppy) by zephir.uk.clara.net with smtp (Exim 4.22) id 1BAYO6-0008eV-8r for ccamp@ops.ietf.org; Mon, 05 Apr 2004 18:59:59 +0100 Message-ID: <008501c41b37$d223cf90$f99c9ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Additional CCAMP info now on the Web Date: Mon, 5 Apr 2004 18:58:24 +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-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Hi, We have posted some additional CCAMP information at http://www.olddog.co.uk/ccamp.htm You can find a link to this from the CCAMP charter page http://www.ietf.org/html.charters/ccamp-charter.html At the moment, probably the most useful piece of information is the page that tracks the status of all CCAMP drafts. I'm sure you'll let me know if I have got something wrong or left something out. It would also be interesting to know what other information you would regard as useful. Cheers, Adrian From owner-ccamp@ops.ietf.org Mon Apr 5 16:50:09 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06655 for ; Mon, 5 Apr 2004 16:50:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAb2o-0001aV-00 for ccamp-archive@ietf.org; Mon, 05 Apr 2004 16:50:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAabu-0006Xw-00 for ccamp-archive@ietf.org; Mon, 05 Apr 2004 16:22:24 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BAaMR-0004y2-00 for ccamp-archive@ietf.org; Mon, 05 Apr 2004 16:06:23 -0400 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BAa4f-00025R-3S for ccamp-data@psg.com; Mon, 05 Apr 2004 19:48:01 +0000 Received: from [65.205.166.188] (helo=jera.movaz.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BAa4R-0001u0-Sz for ccamp@ops.ietf.org; Mon, 05 Apr 2004 19:47:48 +0000 Received: from lb-laptop.movaz.com (movaz-hw.atlanta.movaz.com [172.16.8.183]) by jera.movaz.com (Postfix) with ESMTP id A39E710CC; Mon, 5 Apr 2004 15:47:45 -0400 (EDT) Message-Id: <6.0.3.0.2.20040405152933.03474b88@mo-ex1> X-Sender: lb@mo-ex1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.3.0 Date: Mon, 05 Apr 2004 15:47:34 -0400 To: "Adrian Farrel" From: Lou Berger Subject: Re: draft-ietf-ccamp-gmpls-egress-control-00.txt Cc: , "Berger, Lou" In-Reply-To: <004501c41b34$3cbd3a20$f99c9ed9@Puppy> References: <004501c41b34$3cbd3a20$f99c9ed9@Puppy> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Adrian, Thanks for the comments. See below. Lou At 11:23 AM 4/5/2004 -0400, Adrian Farrel wrote: >Hi Lou, > >In Seoul we agreed that this draft would become a WG document and we >talked a little about doing a working group last call immediately thereafter. > >Thanks for re-spinning the draft as a WG draft. There are, however, a few >nits that I think you should tidy up before we do the last call. > >Perhaps others would like to pitch in now if they have any substantive >comments before the last call. > >Thanks, >Adrian > > >Please give the intended category of the work... >Proposed Category: Best Common Practice this is normally done outside of the draft. >Please correct draft name as it appears in the title and footers. > >draft-ietf-ccamp-gmpls-egress-control-00.txt fixed last week. >Abstract >Please remove [bracketed] citation from abstract. done >Abstract > This note clarifies the procedures for the control of a label used on > an egress output/downstream interface. >I think this would be better phrased as... > This note clarifies the procedures for the control of the label used > on output/downstream interface of the final (egress) Label Switching > Router (LSR) of a Label Switched Path (LSP). sure. > > >1. Background > > The ability to control a label used on an egress output/downstream > interface was one of the early requirements for GMPLS. >Again, rephrase as... > The ability to control the label used on the output/downstream > interface of an egress LSR was one of the early requirements for > GMPLS. > sure, why not. >2.1. ERO Procedures > > Egress Control occurs when the node processing an ERO is the egress > and the ERO contains one or more label subobjects. >In view of the text quoted from section 6 of an early draft of GMPLS, >we either need to re-cast this whole draft as "Egress Label Control" >or we need to generalize the text here as egress control that allows >the control of interface, component link and label. >I prefer the second option. no problem. changed to ... "one or more subobjects related to the output/downstream interface" >Compare with section 2.2 which is more general. > > To support Egress Control, an egress checks to see if the received > ERO contains an outgoing/downstream interface. If it does, the type > of the subobject or subobjects following the interface are examined. > If the associated LSP is unidirectional, one subobject is examined. > Two subobjects are examined for bidirectional LSPs. If the U-bit of > the subobject being examined is clear (0), then the value of the > label is copied into a new Label_Set object. Note, this Label_Set > object is for internal use only. This Label_Set object indicates the > label value that MUST be used for transmitting traffic associated > with the LSP on the indicated outgoing/downstream interface. >Not withstanding "this Label_Set object is for internal use only", I >find this text a bit peculiar! >You really just want to say that this subobject is used to specify the >label that the egress MUST apply to traffic that it forwards from this >LSP. (Compare with the next paragraph where you do not describe >creating an Upstream_Label object for internal use only.) >If you insist on talking about the Label_Set object, you will have to be >far more specific because there are four different varieties of that >object. I think the wording is consistent with RFC3473 and unambiguous. Please suggest alternate wording. > including if the listed label(s) are not acceptable or cannot be > supported in forwarding, SHOULD result in the generation of a PathErr > message containing a "Bad EXPLICIT_ROUTE object" error. >I'd prefer you to be more explicit... >... containing a "Routing Problem"/"Bad EXPLICIT_ROUTE object" error. sure, will use phrasing from rfc3209. >3. Security Considerations > >< This note clarifies procedures defined in [RFC3473]. As such, no new >< security considerations are introduced. > > This note reiterates procedures defined in [RFC3473], but does not > > define any new procedures. As such, no new security considerations > > are introduced. okay. ><5. References > >5. Normative References > >Need BCP 78, and 79 as informational references. >Also RFC 3668. will do, but do you really want me to reference BCP 79 and RFC 3668? >8. Intellectual Property > >Missing the personal disclaimer... > By submitting this Internet-Draft, I certify that any applicable > patent or other IPR claims of which I am aware have been disclosed, > and any of which I become aware will be disclosed, in accordance with > RFC 3668. sure. >Don't need the footer... >Generated on: Mon Mar 15 10:52:32 2004 picky, picky, picky... From owner-ccamp@ops.ietf.org Tue Apr 6 13:23:35 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08692 for ; Tue, 6 Apr 2004 13:23:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAuIS-0003sB-00 for ccamp-archive@ietf.org; Tue, 06 Apr 2004 13:23:36 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAu8d-0002Wq-00 for ccamp-archive@ietf.org; Tue, 06 Apr 2004 13:13:28 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BAtqU-0000NO-00 for ccamp-archive@ietf.org; Tue, 06 Apr 2004 12:54:42 -0400 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BAtXZ-0002nE-5j for ccamp-data@psg.com; Tue, 06 Apr 2004 16:35:09 +0000 Received: from [211.6.83.103] (helo=smtp.cronos.ocn.ne.jp) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BAtX5-0002WQ-Bc for ccamp@ops.ietf.org; Tue, 06 Apr 2004 16:34:39 +0000 Received: from TAKEDAPANA.lab.ntt.co.jp (FLA1Acw229.tky.mesh.ad.jp [218.42.66.229]) by smtp.cronos.ocn.ne.jp (Postfix) with ESMTP id 3811920D0; Wed, 7 Apr 2004 01:34:37 +0900 (JST) Message-Id: <5.0.2.5.2.20040407012556.06446ec8@cronos.ocn.ne.jp> X-Sender: takeda.tomonori@cronos.ocn.ne.jp X-Mailer: QUALCOMM Windows Eudora Version 5.0.2-J Date: Wed, 07 Apr 2004 01:34:17 +0900 To: Dimitri.Papadimitriou@alcatel.be From: Tomonori TAKEDA Subject: Re: [RE] Layer One VPNs - sorry for the previous email Cc: yhwkim@etri.re.kr, ccamp@ops.ietf.org In-Reply-To: <4058B0D0.9080100@alcatel.be> References: <5.0.2.5.2.20040317234418.04415ec8@cronos.ocn.ne.jp> <5.0.2.5.2.20040316005611.0458cec8@cronos.ocn.ne.jp> <5.0.2.5.2.20040316005611.0458cec8@cronos.ocn.ne.jp> <5.0.2.5.2.20040317234418.04415ec8@cronos.ocn.ne.jp> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Hi, Dimitri Thank you for your comments. And I am sorry for late response. [snipped] >>>- there is the issue of the "PE-PE virtual links" and in case of >>>"Per VPN Peer model" more details should be provided in order to >>>assess whether existing GMPLS mechanisms are sufficient (from >>>that perspective details about the following sentence might be >>>of interest because it seems you took this as initial working >>>assumption "there is currently no leakage of routing information >>>across the PE to CE boundary.") >> >>Agree. Providing more details about service requirements may be helpful ? >>Functional requirements are also important, but before going that in >>details, more clear service level requirements may be useful. > >do you plan to deliver those as part of the user community or do you >expect this input to come from SG13 - or both - ? just to know about the >timeframe we may expect here since there are very interesting issues >you're introducing with the above approaches Understood. I think this requires further discussion. I would personally think joint collaboration between IETF and SG13 would be a good approach. Anyway, a simple step further at this point could be to enhance the current service level requirements according to all material produced in SG13. We (authors of the L1VPN framework draft) are happy to provide such text for the next version of the draft. Inputs and comments would be also appreciated. >>Concerning the initial working assumption you mentioned, we started from >>the most acknowledged model for the service interface, that is the UNI. >>That is why we put above text. > >so you started with a signaling interface, and then try to build on top >of it the necessary pieces > >>>- i would suggest to conclude the document with the expected >>>delta requirement from gmpls perspective (this would help in >>>assessing what's expected in terms of protocol for the next >>>step(s)) >> >>Okay, if CCAMP is going to work on the L1 VPN, I agree delta requirement >>would be an important step. >>Do you have anything in your mind ? > >try to collect all the sentences that are part of the present document >that either implicitly or explicitly determine a feature to be covered >list them in terms of signaling and routing, i think we would gain a lot >of precious time in having such conclusion in case decision to work on >solution is accepted Thanks. Yes, as already said, delta requirements will be certainly useful. Having a good understanding of the service and architecture needs is beneficial to drive later the discussion on protocols in a comprehensive way (how protocols and mechanisms fit the service and the architecture). [snipped] Any comments are appreciated. Best regards, ----- Tomonori TAKEDA NTT Network Service Systems Lab. Phone: +81-422-59-7434 From owner-ccamp@ops.ietf.org Tue Apr 6 13:37:49 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09836 for ; Tue, 6 Apr 2004 13:37:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAuWE-0005rE-00 for ccamp-archive@ietf.org; Tue, 06 Apr 2004 13:37:50 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAuMZ-0004Po-00 for ccamp-archive@ietf.org; Tue, 06 Apr 2004 13:27:53 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BAuAh-0002ko-00 for ccamp-archive@ietf.org; Tue, 06 Apr 2004 13:15:35 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by mx2.foretec.com with esmtp (Exim 4.24) id 1BAuAj-0005kL-9F for ccamp-archive@ietf.org; Tue, 06 Apr 2004 13:15:37 -0400 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BAtxB-000CDB-0R for ccamp-data@psg.com; Tue, 06 Apr 2004 17:01:37 +0000 Received: from [63.161.60.29] (helo=mail8-kan-R.bigfish.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BAtwp-000C9l-RQ for ccamp@ops.ietf.org; Tue, 06 Apr 2004 17:01:15 +0000 Received: from mail8-kan.bigfish.com (localhost.localdomain [127.0.0.1]) by mail8-kan-R.bigfish.com (Postfix) with ESMTP id 0FDD4165B57; Tue, 6 Apr 2004 17:01:15 +0000 (UCT) Received: by mail8-kan (MessageSwitch) id 10812708759724_5752; Tue, 6 Apr 2004 17:01:15 +0000 (UCT) Received: from smtpgw5.sprintspectrum.com (smtpgw5.sprintspectrum.com [207.40.188.13]) by mail8-kan.bigfish.com (Postfix) with ESMTP id DD4A6165B4F; Tue, 6 Apr 2004 17:01:14 +0000 (UCT) Received: from mailhost.sprintspectrum.com (smtpgw7.it.sprintspectrum.com [207.40.65.55]) by smtpgw5.sprintspectrum.com (8.12.10/8.12.8) with ESMTP id i36H1EaY008280; Tue, 6 Apr 2004 12:01:14 -0500 (CDT) Received: from PDAWG01A.corp.sprint.com (PDAWG01A.corp.sprint.com [10.184.134.78]) by mailhost.sprintspectrum.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i36H1DB17431; Tue, 6 Apr 2004 12:01:13 -0500 (CDT) Received: from pkdwb06c.ad.sprint.com ([10.185.12.46]) by PDAWG01A.corp.sprint.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 6 Apr 2004 12:01:03 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [RE] Layer One VPNs - sorry for the previous email Date: Tue, 6 Apr 2004 12:00:59 -0500 Message-ID: Thread-Topic: [RE] Layer One VPNs - sorry for the previous email Thread-Index: AcQb9fTALp91f0k6Tk2QpR69Cne7kQAAkNhg From: "Alanqar, Wesam I [NTK]" To: "Tomonori TAKEDA" , , Cc: X-OriginalArrivalTime: 06 Apr 2004 17:01:03.0373 (UTC) FILETIME=[BE6ADBD0:01C41BF8] X-BigFish: cv Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Will SG15 be included in this effort mainly addressing ASON architectural enhancements for L1 VPN? I believe that there should be collaboration on the (protocols, generic control plane architectures, service architectures) to support L1 VPN. Thanks, -Wesam -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Tomonori TAKEDA Sent: Tuesday, April 06, 2004 11:34 AM To: Dimitri.Papadimitriou@alcatel.be Cc: yhwkim@etri.re.kr; ccamp@ops.ietf.org Subject: Re: [RE] Layer One VPNs - sorry for the previous email Hi, Dimitri Thank you for your comments. And I am sorry for late response. [snipped] >>>- there is the issue of the "PE-PE virtual links" and in case of >>>"Per VPN Peer model" more details should be provided in order to >>>assess whether existing GMPLS mechanisms are sufficient (from >>>that perspective details about the following sentence might be >>>of interest because it seems you took this as initial working >>>assumption "there is currently no leakage of routing information >>>across the PE to CE boundary.") >> >>Agree. Providing more details about service requirements may be helpful ?=20 >>Functional requirements are also important, but before going that in=20 >>details, more clear service level requirements may be useful. > >do you plan to deliver those as part of the user community or do you=20 >expect this input to come from SG13 - or both - ? just to know about the=20 >timeframe we may expect here since there are very interesting issues=20 >you're introducing with the above approaches Understood. I think this requires further discussion. I would personally think joint collaboration between IETF and SG13 would be a good approach.=20 Anyway, a simple step further at this point could be to enhance the=20 current service level requirements according to all material produced in SG13. We (authors of the L1VPN framework draft) are happy to provide such=20 text for the next version of the draft. Inputs and comments would be also=20 appreciated. >>Concerning the initial working assumption you mentioned, we started from=20 >>the most acknowledged model for the service interface, that is the UNI.=20 >>That is why we put above text. > >so you started with a signaling interface, and then try to build on top >of it the necessary pieces > >>>- i would suggest to conclude the document with the expected >>>delta requirement from gmpls perspective (this would help in >>>assessing what's expected in terms of protocol for the next >>>step(s)) >> >>Okay, if CCAMP is going to work on the L1 VPN, I agree delta requirement=20 >>would be an important step. >>Do you have anything in your mind ? > >try to collect all the sentences that are part of the present document=20 >that either implicitly or explicitly determine a feature to be covered >list them in terms of signaling and routing, i think we would gain a lot=20 >of precious time in having such conclusion in case decision to work on=20 >solution is accepted Thanks. Yes, as already said, delta requirements will be certainly useful.=20 Having a good understanding of the service and architecture needs is=20 beneficial to drive later the discussion on protocols in a comprehensive way (how protocols and mechanisms fit the service and the architecture). [snipped] Any comments are appreciated. Best regards, ----- Tomonori TAKEDA NTT Network Service Systems Lab. Phone: +81-422-59-7434 From owner-ccamp@ops.ietf.org Tue Apr 6 14:29:40 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15102 for ; Tue, 6 Apr 2004 14:29:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAvKP-00064b-00 for ccamp-archive@ietf.org; Tue, 06 Apr 2004 14:29:41 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAvJ1-0005kY-00 for ccamp-archive@ietf.org; Tue, 06 Apr 2004 14:28:16 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BAvHI-0005HN-00 for ccamp-archive@ietf.org; Tue, 06 Apr 2004 14:26:28 -0400 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BAv10-0007mo-PT for ccamp-data@psg.com; Tue, 06 Apr 2004 18:09:38 +0000 Received: from [47.164.128.120] (helo=zctfs063.nortelnetworks.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BAv0h-0007Zz-5F for ccamp@ops.ietf.org; Tue, 06 Apr 2004 18:09:19 +0000 Received: from zctfc040.europe.nortel.com (zctfc040.europe.nortel.com [47.164.129.95]) by zctfs063.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i36I99c20517; Tue, 6 Apr 2004 20:09:10 +0200 (MEST) Received: by zctfc040.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 6 Apr 2004 20:09:08 +0200 Message-ID: From: "Marco Carugi" To: "Brungard, Deborah A, ALABS" Cc: ccamp@ops.ietf.org Subject: RE: [RE] Layer One VPNs - sorry for the previous email Date: Tue, 6 Apr 2004 20:09:09 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C41C02.41FE9654" Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=HTML_20_30,HTML_MESSAGE autolearn=no version=2.60 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C41C02.41FE9654 Content-Type: text/plain Deborah, > I noted the SG13 liaison has a response date of September > 2004 (the l1vpn questionnaire responses are due June). Will > we wait until the August IETF meeting to respond? (hopefully > there will have been a decision on the l1vpn work allocation) thank you for noting this out. SG13 will welcome a liaison statement from IETF. Regarding the time frame, next SG13 (interim) meeting discussing L1 VPNs will be in September, so waiting until the August IETF meeting would still be okay. Marco ------_=_NextPart_001_01C41C02.41FE9654 Content-Type: text/html RE: [RE] Layer One VPNs - sorry for the previous email

Deborah,
 
> I noted the SG13 liaison has a response date of September
> 2004 (the l1vpn questionnaire responses are due June).  Will
> we wait until the August IETF meeting to respond? (hopefully
> there will have been a decision on the l1vpn work allocation)

thank you for noting this out. SG13 will welcome a liaison statement
from IETF. Regarding the time frame, next SG13 (interim) meeting discussing L1 VPNs
will be in September, so waiting until the August IETF meeting would still be okay.

Marco

------_=_NextPart_001_01C41C02.41FE9654-- From owner-ccamp@ops.ietf.org Wed Apr 7 13:49:07 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18314 for ; Wed, 7 Apr 2004 13:49:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBHAh-0004Ww-00 for ccamp-archive@ietf.org; Wed, 07 Apr 2004 13:49:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBGFI-0003Rf-00 for ccamp-archive@ietf.org; Wed, 07 Apr 2004 12:49:49 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BBEpw-00018J-00 for ccamp-archive@ietf.org; Wed, 07 Apr 2004 11:19:32 -0400 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BBEas-000JYh-JP for ccamp-data@psg.com; Wed, 07 Apr 2004 15:03:58 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BBEad-000JLl-Db for ccamp@ops.ietf.org; Wed, 07 Apr 2004 15:03:43 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00320; Wed, 7 Apr 2004 11:03:40 -0400 (EDT) Message-Id: <200404071503.LAA00320@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-gmpls-recovery-e2e-signaling-00.txt Date: Wed, 07 Apr 2004 11:03:40 -0400 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --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 : RSVP-TE Extensions in support of End-to-End GMPLS-based Recovery Author(s) : J. Lang, et al Filename : draft-ietf-ccamp-gmpls-recovery-e2e-signaling-00.txt Pages : 33 Date : 2004-4-6 This document describes protocol specific procedures for GMPLS (Generalized Multi-Protocol Label Switching) RSVP-TE (Resource ReserVation Protocol - Traffic Engineering) signaling extensions to support end-to-end LSP recovery (protection and restoration). A generic functional description of GMPLS recovery can be found in a companion document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-recovery-e2e-signaling-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ccamp-gmpls-recovery-e2e-signaling-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ccamp-gmpls-recovery-e2e-signaling-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-4-7110409.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-gmpls-recovery-e2e-signaling-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-gmpls-recovery-e2e-signaling-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-4-7110409.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ccamp@ops.ietf.org Wed Apr 7 13:49:15 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18358 for ; Wed, 7 Apr 2004 13:49:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBHAp-0004YU-00 for ccamp-archive@ietf.org; Wed, 07 Apr 2004 13:49:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBGFV-0003U7-00 for ccamp-archive@ietf.org; Wed, 07 Apr 2004 12:50:03 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BBEqV-0001Ap-00 for ccamp-archive@ietf.org; Wed, 07 Apr 2004 11:20:07 -0400 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BBEZm-000J5p-Qg for ccamp-data@psg.com; Wed, 07 Apr 2004 15:02:50 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BBEZU-000IyC-Hr for ccamp@ops.ietf.org; Wed, 07 Apr 2004 15:02:32 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00285; Wed, 7 Apr 2004 11:02:29 -0400 (EDT) Message-Id: <200404071502.LAA00285@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-tunproto-00.txt Date: Wed, 07 Apr 2004 11:02:29 -0400 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --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 : Generic Tunnel Tracing Protocol (GTTP) Specification Author(s) : R. Bonica, et al Filename : draft-ietf-ccamp-tunproto-00.txt Pages : 38 Date : 2004-4-6 This document describes the Generic Tunnel Tracing Protocol (GTTP). GTTP supports enhanced route-tracing applications. Network operators use enhanced route-tracing applications to trace the path between any two points in an IP network. Enhanced route-tracing applications can trace through a network's forwarding plane, its control plane or both. Furthermore, enhanced route-tracing applications can reveal details concerning tunnels that support the traced path. Tunnel details can be revealed regardless of tunneling technology. For example, enhanced route-tracing applications can trace through an MPLS LSP as well as they can trace through an IP-in-IP tunnel. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-tunproto-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ccamp-tunproto-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ccamp-tunproto-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-4-7110344.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-tunproto-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-tunproto-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-4-7110344.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ccamp@ops.ietf.org Wed Apr 7 13:49:37 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18446 for ; Wed, 7 Apr 2004 13:49:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBHBB-0004cT-00 for ccamp-archive@ietf.org; Wed, 07 Apr 2004 13:49:37 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBGGC-0003ZF-00 for ccamp-archive@ietf.org; Wed, 07 Apr 2004 12:50:45 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BBErC-0001E9-00 for ccamp-archive@ietf.org; Wed, 07 Apr 2004 11:20:50 -0400 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BBEcm-000KUH-3h for ccamp-data@psg.com; Wed, 07 Apr 2004 15:05:56 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BBEcX-000KHf-0A for ccamp@ops.ietf.org; Wed, 07 Apr 2004 15:05:41 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00417; Wed, 7 Apr 2004 11:05:38 -0400 (EDT) Message-Id: <200404071505.LAA00417@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-gmpls-recovery-e2e-signaling-00.txt Date: Wed, 07 Apr 2004 11:05:38 -0400 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --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 : RSVP-TE Extensions in support of End-to-End GMPLS-based Recovery Author(s) : J. Lang, et al Filename : draft-ietf-ccamp-gmpls-recovery-e2e-signaling-00.txt Pages : 33 Date : 2004-4-6 This document describes protocol specific procedures for GMPLS (Generalized Multi-Protocol Label Switching) RSVP-TE (Resource ReserVation Protocol - Traffic Engineering) signaling extensions to support end-to-end LSP recovery (protection and restoration). A generic functional description of GMPLS recovery can be found in a companion document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-recovery-e2e-signaling-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ccamp-gmpls-recovery-e2e-signaling-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ccamp-gmpls-recovery-e2e-signaling-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-4-7110409.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-gmpls-recovery-e2e-signaling-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-gmpls-recovery-e2e-signaling-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-4-7110409.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ccamp@ops.ietf.org Thu Apr 8 13:23:31 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05159 for ; Thu, 8 Apr 2004 13:23:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBdFR-0002qz-00 for ccamp-archive@ietf.org; Thu, 08 Apr 2004 13:23:29 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBaWl-00009Z-00 for ccamp-archive@ietf.org; Thu, 08 Apr 2004 10:29:12 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BBYDk-0007Jy-00 for ccamp-archive@ietf.org; Thu, 08 Apr 2004 08:01:24 -0400 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BBXvg-000M61-Km for ccamp-data@psg.com; Thu, 08 Apr 2004 11:42:44 +0000 Received: from [195.8.69.53] (helo=zephir.uk.clara.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BBXvf-000M5l-NP for ccamp@ops.ietf.org; Thu, 08 Apr 2004 11:42:43 +0000 Received: from du-069-0848.access.clara.net ([217.158.170.85] helo=Puppy) by zephir.uk.clara.net with smtp (Exim 4.22) id 1BBXve-000PeI-80 for ccamp@ops.ietf.org; Thu, 08 Apr 2004 12:42:42 +0100 Message-ID: <01ba01c41d5e$9b8989b0$7caa9ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Further WG Last Call on LMP MIB Complete Date: Thu, 8 Apr 2004 12:42: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 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Hi, The further WG last call on this draft has completed without further comments. Alex, Bert, Can you please take this draft forward to the IESG. Thanks, Adrian ----- Original Message ----- From: "Adrian Farrel" To: Cc: "Martin Dubuc" ; "Wijnen, Bert (Bert)" Sent: Tuesday, March 30, 2004 12:25 AM Subject: Further WG Last Call on LMP MIB > Hi, > > Martin has done a sterling job updating the LMP MIB after the usual thorough and careful > review by Bert. > > In view of the number of changes (although none is very major) we are holding another > working group last call on this draft. > > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-lmp-mib-08.txt > > Please send your comments to the list. > > The last call will end on Thursday 8th April at 12 noon GMT. > > Thanks, > Adrian From owner-ccamp@ops.ietf.org Thu Apr 8 19:10:38 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05971 for ; Thu, 8 Apr 2004 19:10:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBifN-00022p-00 for ccamp-archive@ietf.org; Thu, 08 Apr 2004 19:10:37 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBhqU-0004Ht-00 for ccamp-archive@ietf.org; Thu, 08 Apr 2004 18:18:10 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BBfqN-0003M7-00 for ccamp-archive@ietf.org; Thu, 08 Apr 2004 16:09:47 -0400 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BBfVA-0007rx-Pc for ccamp-data@psg.com; Thu, 08 Apr 2004 19:47:52 +0000 Received: from [195.8.69.103] (helo=cerberus.uk.clara.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BBfV1-0007pS-SN for ccamp@ops.ietf.org; Thu, 08 Apr 2004 19:47:44 +0000 Received: from du-069-0343.access.clara.net ([217.158.145.89] helo=Puppy) by cerberus.uk.clara.net with smtp (Exim 4.22) id 1BBfUr-0005or-5g; Thu, 08 Apr 2004 20:47:34 +0100 Message-ID: <01f801c41da2$57c6a480$7caa9ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Lou Berger" Cc: References: <004501c41b34$3cbd3a20$f99c9ed9@Puppy> <6.0.3.0.2.20040405152933.03474b88@mo-ex1> Subject: Re: draft-ietf-ccamp-gmpls-egress-control-00.txt Date: Thu, 8 Apr 2004 20:46:47 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01F1_01C41DAA.9C2235B0" 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-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,HTML_20_30,HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format. ------=_NextPart_000_01F1_01C41DAA.9C2235B0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Lou, > >Please give the intended category of the work... > >Proposed Category: Best Common Practice >=20 > this is normally done outside of the draft. Hmmm. The draft needs to indicate its intended status so that folks can review = it with that in mind. If you don't want to say that the proposed status is BCP then please at = least say informational. > >Please correct draft name as it appears in the title and footers. > > > >draft-ietf-ccamp-gmpls-egress-control-00.txt >=20 > fixed last week. Hah! But the secretariat has published it according to your first = submission. Actually, the version on the LabN site is also wrong. I don't mean the document name, I mean the draft name as it appears = throughout the document. > >Abstract > >Please remove [bracketed] citation from abstract. > done >=20 > >Abstract > > This note clarifies the procedures for the control of a label = used on > > an egress output/downstream interface. > >I think this would be better phrased as... > > This note clarifies the procedures for the control of the label = used > > on output/downstream interface of the final (egress) Label = Switching > > Router (LSR) of a Label Switched Path (LSP). > sure. >=20 > >1. Background > > > > The ability to control a label used on an egress = output/downstream > > interface was one of the early requirements for GMPLS. > >Again, rephrase as... > > The ability to control the label used on the output/downstream > > interface of an egress LSR was one of the early requirements for > > GMPLS. > sure, why not. >=20 > >2.1. ERO Procedures > > > > Egress Control occurs when the node processing an ERO is the = egress > > and the ERO contains one or more label subobjects. > >In view of the text quoted from section 6 of an early draft of GMPLS, > >we either need to re-cast this whole draft as "Egress Label Control" > >or we need to generalize the text here as egress control that allows > >the control of interface, component link and label. > >I prefer the second option. > no problem. changed to ... "one or more subobjects related to the=20 > output/downstream interface" >=20 > >Compare with section 2.2 which is more general. > > > > To support Egress Control, an egress checks to see if the = received > > ERO contains an outgoing/downstream interface. If it does, the = type > > of the subobject or subobjects following the interface are = examined. > > If the associated LSP is unidirectional, one subobject is = examined. > > Two subobjects are examined for bidirectional LSPs. If the U-bit = of > > the subobject being examined is clear (0), then the value of the > > label is copied into a new Label_Set object. Note, this = Label_Set > > object is for internal use only. This Label_Set object indicates = the > > label value that MUST be used for transmitting traffic associated > > with the LSP on the indicated outgoing/downstream interface. > >Not withstanding "this Label_Set object is for internal use only", I > >find this text a bit peculiar! > >You really just want to say that this subobject is used to specify = the > >label that the egress MUST apply to traffic that it forwards from = this > >LSP. (Compare with the next paragraph where you do not describe > >creating an Upstream_Label object for internal use only.) > >If you insist on talking about the Label_Set object, you will have to = be > >far more specific because there are four different varieties of that > >object. >=20 > I think the wording is consistent with RFC3473 and unambiguous. = Please=20 > suggest alternate wording. Well! I can't be held responsible for the failings of the editor of = that RFC :-) Section 5.1.1 says with respect to the ERO Label Subobject... If the U-bit of the subobject being examined is clear (0), then value of the label is copied into a new Label_Set object. This Label_Set object MUST be included on the corresponding outgoing Path message. So I see where you are coming from, but I think this text is aimed at specifying how you build the outgoing Path message, not how you manage the label allocation on your downstream interface. It is=20 wrong to suggest that an implementation must create a protocol object for this purpose if no Path message is to be sent. In fact, since there is no corresponding Resv with a Label Object we need to pin this text down a little more clearly. How about the following edit... To support Egress Control, an egress checks to see if the received ERO contains an outgoing/downstream interface. If it does, the type of the subobject or subobjects following the interface are examined. If the associated LSP is unidirectional, one subobject is examined. Two subobjects are examined for bidirectional LSPs. If the U-bit of the subobject being examined is clear (0), then the value of the=20 label MUST be used for transmitting traffic associated with the LSP on the indicated outgoing/downstream interface. > > including if the listed label(s) are not acceptable or cannot be > > supported in forwarding, SHOULD result in the generation of a = PathErr > > message containing a "Bad EXPLICIT_ROUTE object" error. > >I'd prefer you to be more explicit... > >... containing a "Routing Problem"/"Bad EXPLICIT_ROUTE object" error. > sure, will use phrasing from rfc3209. >=20 > >3. Security Considerations > > > >< This note clarifies procedures defined in [RFC3473]. As such, no = new > >< security considerations are introduced. > > > This note reiterates procedures defined in [RFC3473], but does = not > > > define any new procedures. As such, no new security = considerations > > > are introduced. > okay. >=20 > ><5. References > > >5. Normative References > > > >Need BCP 78, and 79 as informational references. > >Also RFC 3668. >=20 > will do, but do you really want me to reference BCP 79 and RFC 3668? It is unclear whether this is a requirement, but since the boilerplate = text makes these references it seems reasonable to include them in the = list. > >8. Intellectual Property > > > >Missing the personal disclaimer... > > By submitting this Internet-Draft, I certify that any applicable > > patent or other IPR claims of which I am aware have been = disclosed, > > and any of which I become aware will be disclosed, in accordance = with > > RFC 3668. > sure. >=20 > >Don't need the footer... > >Generated on: Mon Mar 15 10:52:32 2004 >=20 > picky, picky, picky... That's what I'm paid for. Thanks, Lou. Looking forward to seeing the revision published. Adrian ------=_NextPart_000_01F1_01C41DAA.9C2235B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Lou,
 
> >Please give the intended = category of the=20 work...
> >Proposed Category: Best Common Practice
> =
>=20 this is normally done outside of the draft.
 
Hmmm.
The draft needs to indicate its = intended status=20 so that folks can review it with that in mind.
If you don't want to say that the = proposed status=20 is BCP then please at least say informational.
 
> >Please correct draft name as = it appears=20 in the title and footers.
>=20 ><draft-ccamp-gmpls-egress-control-00.txt
> >=20 >draft-ietf-ccamp-gmpls-egress-control-00.txt
>
> fixed = last=20 week.
 
Hah! But the secretariat has = published it=20 according to your first submission.
Actually, the version on the LabN = site is also=20 wrong.
 
I don't mean the document name, I = mean the draft=20 name as it appears throughout the document.

> >Abstract
> = >Please remove=20 [bracketed] citation from abstract.
> done
>
>=20 >Abstract
> >    This note clarifies the = procedures=20 for the control of a label used on
> >    an = egress=20 output/downstream interface.
> >I think this would be better = phrased=20 as...
> >    This note clarifies the procedures = for the=20 control of the label used
> >    on = output/downstream=20 interface of the final (egress) Label Switching
> = >   =20 Router (LSR) of a Label Switched Path (LSP).
> sure.
> =
>=20 >1. Background
> >
> >    The = ability to=20 control a label used on an egress output/downstream
>=20 >    interface was one of the early requirements for=20 GMPLS.
> >Again, rephrase as...
> >    = The=20 ability to control the label used on the output/downstream
>=20 >    interface of an egress LSR was one of the early=20 requirements for
> >    GMPLS.
> sure, why = not.
>
> >2.1. ERO Procedures
> >
>=20 >    Egress Control occurs when the node processing an = ERO is=20 the egress
> >    and the ERO contains one or = more label=20 subobjects.
> >In view of the text quoted from section 6 of an = early=20 draft of GMPLS,
> >we either need to re-cast this whole draft = as=20 "Egress Label Control"
> >or we need to generalize the text = here as=20 egress control that allows
> >the control of interface, = component link=20 and label.
> >I prefer the second option.
> no = problem. =20 changed to ... "one or more subobjects related to the
> = output/downstream=20 interface"
>
> >Compare with section 2.2 which is more=20 general.
> >
> >    To support Egress = Control,=20 an egress checks to see if the received
> >    = ERO=20 contains an outgoing/downstream interface.  If it does, the = type
>=20 >    of the subobject or subobjects following the = interface=20 are examined.
> >    If the associated LSP is=20 unidirectional, one subobject is examined.
> = >    Two=20 subobjects are examined for bidirectional LSPs.  If the U-bit = of
>=20 >    the subobject being examined is clear (0), then = the value=20 of the
> >    label is copied into a new = Label_Set=20 object.  Note, this Label_Set
> >    object = is for=20 internal use only.  This Label_Set object indicates the
>=20 >    label value that MUST be used for transmitting = traffic=20 associated
> >    with the LSP on the indicated=20 outgoing/downstream interface.
> >Not withstanding "this = Label_Set=20 object is for internal use only", I
> >find this text a bit=20 peculiar!
> >You really just want to say that this subobject is = used to=20 specify the
> >label that the egress MUST apply to traffic that = it=20 forwards from this
> >LSP. (Compare with the next paragraph = where you=20 do not describe
> >creating an Upstream_Label object for = internal use=20 only.)
> >If you insist on talking about the Label_Set object, = you will=20 have to be
> >far more specific because there are four = different=20 varieties of that
> >object.
>
> I think the = wording is=20 consistent with RFC3473 and unambiguous.  Please
> suggest = alternate=20 wording.
 
Well!  I can't be held = responsible for the=20 failings of the editor of that RFC  :-)
 
Section 5.1.1 says with respect to = the ERO Label=20 Subobject...
   If the U-bit of = the
  =20 subobject being examined is clear (0), then value of the label=20 is
   copied into a new Label_Set object.  This = Label_Set=20 object MUST be
   included on the corresponding outgoing = Path=20 message.
 
So I see where you are coming from, = but I think=20 this text is aimed at
specifying how you build the outgoing = Path=20 message, not how you
manage the label allocation on your = downstream=20 interface. It is
wrong to suggest that an = implementation must=20 create a protocol
object for this purpose if no Path = message is to=20 be sent.
 
In fact, since there is no = corresponding Resv=20 with a Label Object
we need to pin this text down a = little more=20 clearly. How about the
following edit...
 
    To support Egress = Control, an=20 egress checks to see if the received
    ERO contains = an=20 outgoing/downstream interface.  If it does, the = type
   =20 of the subobject or subobjects following the interface are=20 examined.
    If the associated LSP is unidirectional, = one=20 subobject is examined.
    Two subobjects are examined = for=20 bidirectional LSPs.  If the U-bit of
    the subobject = being=20 examined is clear (0), then the value of the 
    label MUST be used=20 for transmitting traffic associated with the LSP
    on the indicated=20 outgoing/downstream interface.
> >    including = if the=20 listed label(s) are not acceptable or cannot be
> = >   =20 supported in forwarding, SHOULD result in the generation of a = PathErr
>=20 >    message containing a "Bad EXPLICIT_ROUTE object"=20 error.
> >I'd prefer you to be more explicit...
> >... = containing a "Routing Problem"/"Bad EXPLICIT_ROUTE object" = error.
> sure,=20 will use phrasing from rfc3209.
>
> >3. Security=20 Considerations
> >
> ><  This note clarifies=20 procedures defined in [RFC3473].  As such, no new
> = >< =20 security considerations are introduced.
> > >  This = note=20 reiterates procedures defined in [RFC3473], but does not
> > = > =20 define any new procedures.  As such, no new security = considerations
>=20 > >  are introduced.
> okay.
>
> = ><5.=20 References
> > >5. Normative References
> >
> = >Need BCP 78, and 79 as informational references.
> >Also = RFC=20 3668.
>
> will do, but do you really want me to reference = BCP 79=20 and  RFC 3668?
 
It is unclear whether this is a = requirement, but=20 since the boilerplate text makes these references it seems reasonable to = include=20 them in the list.
 
> >8. Intellectual Property
> >
> >Missing = the=20 personal disclaimer...
> >    By submitting this = Internet-Draft, I certify that any applicable
> = >   =20 patent or other IPR claims of which I am aware have been = disclosed,
>=20 >    and any of which I become aware will be = disclosed, in=20 accordance with
> >    RFC 3668.
> = sure.
>=20
> >Don't need the footer...
> >Generated on: Mon Mar = 15=20 10:52:32 2004
>
> picky, picky, picky...
That's what I'm paid for.
 
Thanks, Lou. Looking forward to seeing the revision = published.
 
Adrian
 
------=_NextPart_000_01F1_01C41DAA.9C2235B0-- From owner-ccamp@ops.ietf.org Thu Apr 8 19:14:11 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06651 for ; Thu, 8 Apr 2004 19:14:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBiip-0002cp-00 for ccamp-archive@ietf.org; Thu, 08 Apr 2004 19:14:12 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBiVf-0001Ma-00 for ccamp-archive@ietf.org; Thu, 08 Apr 2004 19:00:38 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BBh0l-0005aU-00 for ccamp-archive@ietf.org; Thu, 08 Apr 2004 17:24:35 -0400 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BBgnM-000CzD-Vs for ccamp-data@psg.com; Thu, 08 Apr 2004 21:10:44 +0000 Received: from [65.205.166.188] (helo=jera.movaz.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BBgnI-000Cy0-Vx for ccamp@ops.ietf.org; Thu, 08 Apr 2004 21:10:41 +0000 Received: from lb-laptop.movaz.com (kenaz.atlanta.movaz.com [172.16.8.184]) by jera.movaz.com (Postfix) with ESMTP id DE453C6A; Thu, 8 Apr 2004 17:10:36 -0400 (EDT) Message-Id: <6.0.3.0.2.20040408164716.04eb8808@mo-ex1> X-Sender: lb@mo-ex1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.3.0 Date: Thu, 08 Apr 2004 17:10:33 -0400 To: "Adrian Farrel" From: Lou Berger Subject: Re: draft-ietf-ccamp-gmpls-egress-control-00.txt Cc: "Berger, Lou" , In-Reply-To: <01f801c41da2$57c6a480$7caa9ed9@Puppy> References: <004501c41b34$3cbd3a20$f99c9ed9@Puppy> <6.0.3.0.2.20040405152933.03474b88@mo-ex1> <01f801c41da2$57c6a480$7caa9ed9@Puppy> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Adrian, See responses below. At 03:46 PM 4/8/2004 -0400, Adrian Farrel wrote: >Hi Lou, > > > >Please give the intended category of the work... > > >Proposed Category: Best Common Practice > > > > this is normally done outside of the draft. > >Hmmm. >The draft needs to indicate its intended status so that folks can review >it with that in mind. >If you don't want to say that the proposed status is BCP then please at >least say informational. will put into draft - I've always seen this in the last call announcement - but whatever... > > > >Please correct draft name as it appears in the title and footers. > > > > > >draft-ietf-ccamp-gmpls-egress-control-00.txt > > > > fixed last week. > >Hah! But the secretariat has published it according to your first submission. >Actually, the version on the LabN site is also wrong. > >I don't mean the document name, I mean the draft name as it appears >throughout the document. will be fixed in next rev... >[...]> > > >Compare with section 2.2 which is more general. > > > > > > To support Egress Control, an egress checks to see if the received > > > ERO contains an outgoing/downstream interface. If it does, the type > > > of the subobject or subobjects following the interface are examined. > > > If the associated LSP is unidirectional, one subobject is examined. > > > Two subobjects are examined for bidirectional LSPs. If the U-bit of > > > the subobject being examined is clear (0), then the value of the > > > label is copied into a new Label_Set object. Note, this Label_Set > > > object is for internal use only. This Label_Set object indicates the > > > label value that MUST be used for transmitting traffic associated > > > with the LSP on the indicated outgoing/downstream interface. > > >Not withstanding "this Label_Set object is for internal use only", I > > >find this text a bit peculiar! > > >You really just want to say that this subobject is used to specify the > > >label that the egress MUST apply to traffic that it forwards from this > > >LSP. (Compare with the next paragraph where you do not describe > > >creating an Upstream_Label object for internal use only.) > > >If you insist on talking about the Label_Set object, you will have to be > > >far more specific because there are four different varieties of that > > >object. > > > > I think the wording is consistent with RFC3473 and unambiguous. Please > > suggest alternate wording. > >Well! I can't be held responsible for the failings of the editor of that >RFC :-) > >Section 5.1.1 says with respect to the ERO Label Subobject... > If the U-bit of the > subobject being examined is clear (0), then value of the label is > copied into a new Label_Set object. This Label_Set object MUST be > included on the corresponding outgoing Path message. > >So I see where you are coming from, but I think this text is aimed at >specifying how you build the outgoing Path message, not how you >manage the label allocation on your downstream interface. It is >wrong to suggest that an implementation must create a protocol >object for this purpose if no Path message is to be sent. > >In fact, since there is no corresponding Resv with a Label Object >we need to pin this text down a little more clearly. How about the >following edit... > > To support Egress Control, an egress checks to see if the received > ERO contains an outgoing/downstream interface. If it does, the type > of the subobject or subobjects following the interface are examined. > If the associated LSP is unidirectional, one subobject is examined. > Two subobjects are examined for bidirectional LSPs. If the U-bit of > the subobject being examined is clear (0), then the value of the > label MUST be used for transmitting traffic associated with the LSP > on the indicated outgoing/downstream interface. Done! > > > including if the listed label(s) are not acceptable or cannot be > > > supported in forwarding, SHOULD result in the generation of a PathErr > > > message containing a "Bad EXPLICIT_ROUTE object" error. > > >I'd prefer you to be more explicit... > > >... containing a "Routing Problem"/"Bad EXPLICIT_ROUTE object" error. > > sure, will use phrasing from rfc3209. > > > > >3. Security Considerations > > > > > >< This note clarifies procedures defined in [RFC3473]. As such, no new > > >< security considerations are introduced. > > > > This note reiterates procedures defined in [RFC3473], but does not > > > > define any new procedures. As such, no new security considerations > > > > are introduced. > > okay. > > > > ><5. References > > > >5. Normative References > > > > > >Need BCP 78, and 79 as informational references. > > >Also RFC 3668. > > > > will do, but do you really want me to reference BCP 79 and RFC 3668? > >It is unclear whether this is a requirement, but since the boilerplate >text makes these references it seems reasonable to include them in the list. ahh, you fell for my trick question! (they're the same document ;-) > > > >8. Intellectual Property > > > > > >Missing the personal disclaimer... > > > By submitting this Internet-Draft, I certify that any applicable > > > patent or other IPR claims of which I am aware have been disclosed, > > > and any of which I become aware will be disclosed, in accordance with > > > RFC 3668. > > sure. > > > > >Don't need the footer... > > >Generated on: Mon Mar 15 10:52:32 2004 > > > > picky, picky, picky... >That's what I'm paid for. > >Thanks, Lou. Looking forward to seeing the revision published. > >Adrian > Thanks again. submitting in a few minutes... Lou From owner-ccamp@ops.ietf.org Thu Apr 8 20:03:28 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12848 for ; Thu, 8 Apr 2004 20:03:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBjUV-0000Sc-00 for ccamp-archive@ietf.org; Thu, 08 Apr 2004 20:03:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBidM-0001of-00 for ccamp-archive@ietf.org; Thu, 08 Apr 2004 19:08:35 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BBhCX-00072f-00 for ccamp-archive@ietf.org; Thu, 08 Apr 2004 17:36:45 -0400 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BBgwu-000GTc-9j for ccamp-data@psg.com; Thu, 08 Apr 2004 21:20:36 +0000 Received: from [12.7.169.25] (helo=w2ksjexg01.ciena.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BBgwt-000GTH-3j for ccamp@ops.ietf.org; Thu, 08 Apr 2004 21:20:35 +0000 Received: by w2ksjexg01.ciena.com with Internet Mail Service (5.5.2657.72) id ; Thu, 8 Apr 2004 14:20:05 -0700 Message-ID: <829F074A10F98943A218DC363D09C92A01476C49@w2ksjexg06.ciena.com> From: "Ong, Lyndon" To: "'Lou Berger'" , Adrian Farrel Cc: ccamp@ops.ietf.org Subject: RE: draft-ietf-ccamp-gmpls-egress-control-00.txt Date: Thu, 8 Apr 2004 14:20:28 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Hi Guys, Administrative question - if this comes out as a BCP, does the RFC table note this as some kind of update to 3473? I'd be a little worried if there is no notation against the RFC to point people to the clarification. Thanks, Lyndon -----Original Message----- From: Lou Berger [mailto:lberger@movaz.com] Sent: Thursday, April 08, 2004 2:11 PM To: Adrian Farrel Cc: Berger, Lou; ccamp@ops.ietf.org Subject: Re: draft-ietf-ccamp-gmpls-egress-control-00.txt Adrian, See responses below. At 03:46 PM 4/8/2004 -0400, Adrian Farrel wrote: >Hi Lou, > > > >Please give the intended category of the work... > > >Proposed Category: Best Common Practice > > > > this is normally done outside of the draft. > >Hmmm. >The draft needs to indicate its intended status so that folks can review >it with that in mind. >If you don't want to say that the proposed status is BCP then please at >least say informational. will put into draft - I've always seen this in the last call announcement - but whatever... > > > >Please correct draft name as it appears in the title and footers. > > > > > >draft-ietf-ccamp-gmpls-egress-control-00.txt > > > > fixed last week. > >Hah! But the secretariat has published it according to your first submission. >Actually, the version on the LabN site is also wrong. > >I don't mean the document name, I mean the draft name as it appears >throughout the document. will be fixed in next rev... >[...]> > > >Compare with section 2.2 which is more general. > > > > > > To support Egress Control, an egress checks to see if the received > > > ERO contains an outgoing/downstream interface. If it does, the type > > > of the subobject or subobjects following the interface are examined. > > > If the associated LSP is unidirectional, one subobject is examined. > > > Two subobjects are examined for bidirectional LSPs. If the U-bit of > > > the subobject being examined is clear (0), then the value of the > > > label is copied into a new Label_Set object. Note, this Label_Set > > > object is for internal use only. This Label_Set object indicates the > > > label value that MUST be used for transmitting traffic associated > > > with the LSP on the indicated outgoing/downstream interface. > > >Not withstanding "this Label_Set object is for internal use only", I > > >find this text a bit peculiar! > > >You really just want to say that this subobject is used to specify the > > >label that the egress MUST apply to traffic that it forwards from this > > >LSP. (Compare with the next paragraph where you do not describe > > >creating an Upstream_Label object for internal use only.) > > >If you insist on talking about the Label_Set object, you will have to be > > >far more specific because there are four different varieties of that > > >object. > > > > I think the wording is consistent with RFC3473 and unambiguous. Please > > suggest alternate wording. > >Well! I can't be held responsible for the failings of the editor of that >RFC :-) > >Section 5.1.1 says with respect to the ERO Label Subobject... > If the U-bit of the > subobject being examined is clear (0), then value of the label is > copied into a new Label_Set object. This Label_Set object MUST be > included on the corresponding outgoing Path message. > >So I see where you are coming from, but I think this text is aimed at >specifying how you build the outgoing Path message, not how you >manage the label allocation on your downstream interface. It is >wrong to suggest that an implementation must create a protocol >object for this purpose if no Path message is to be sent. > >In fact, since there is no corresponding Resv with a Label Object >we need to pin this text down a little more clearly. How about the >following edit... > > To support Egress Control, an egress checks to see if the received > ERO contains an outgoing/downstream interface. If it does, the type > of the subobject or subobjects following the interface are examined. > If the associated LSP is unidirectional, one subobject is examined. > Two subobjects are examined for bidirectional LSPs. If the U-bit of > the subobject being examined is clear (0), then the value of the > label MUST be used for transmitting traffic associated with the LSP > on the indicated outgoing/downstream interface. Done! > > > including if the listed label(s) are not acceptable or cannot be > > > supported in forwarding, SHOULD result in the generation of a PathErr > > > message containing a "Bad EXPLICIT_ROUTE object" error. > > >I'd prefer you to be more explicit... > > >... containing a "Routing Problem"/"Bad EXPLICIT_ROUTE object" error. > > sure, will use phrasing from rfc3209. > > > > >3. Security Considerations > > > > > >< This note clarifies procedures defined in [RFC3473]. As such, no new > > >< security considerations are introduced. > > > > This note reiterates procedures defined in [RFC3473], but does not > > > > define any new procedures. As such, no new security considerations > > > > are introduced. > > okay. > > > > ><5. References > > > >5. Normative References > > > > > >Need BCP 78, and 79 as informational references. > > >Also RFC 3668. > > > > will do, but do you really want me to reference BCP 79 and RFC 3668? > >It is unclear whether this is a requirement, but since the boilerplate >text makes these references it seems reasonable to include them in the list. ahh, you fell for my trick question! (they're the same document ;-) > > > >8. Intellectual Property > > > > > >Missing the personal disclaimer... > > > By submitting this Internet-Draft, I certify that any applicable > > > patent or other IPR claims of which I am aware have been disclosed, > > > and any of which I become aware will be disclosed, in accordance with > > > RFC 3668. > > sure. > > > > >Don't need the footer... > > >Generated on: Mon Mar 15 10:52:32 2004 > > > > picky, picky, picky... >That's what I'm paid for. > >Thanks, Lou. Looking forward to seeing the revision published. > >Adrian > Thanks again. submitting in a few minutes... Lou From owner-ccamp@ops.ietf.org Thu Apr 8 20:06:15 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13391 for ; Thu, 8 Apr 2004 20:06:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBjXC-0000qi-00 for ccamp-archive@ietf.org; Thu, 08 Apr 2004 20:06:14 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBihR-0002OB-00 for ccamp-archive@ietf.org; Thu, 08 Apr 2004 19:12:51 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BBiEg-00073V-00 for ccamp-archive@ietf.org; Thu, 08 Apr 2004 18:43:02 -0400 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BBi1S-000JAe-Gb for ccamp-data@psg.com; Thu, 08 Apr 2004 22:29:22 +0000 Received: from [195.8.69.103] (helo=cerberus.uk.clara.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BBi1Q-000J9h-RX for ccamp@ops.ietf.org; Thu, 08 Apr 2004 22:29:21 +0000 Received: from du-069-0164.access.clara.net ([217.158.132.164] helo=Puppy) by cerberus.uk.clara.net with smtp (Exim 4.22) id 1BBi1O-00079o-3Z; Thu, 08 Apr 2004 23:29:18 +0100 Message-ID: <021d01c41db8$f02bb240$7caa9ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Ong, Lyndon" Cc: , "'Lou Berger'" References: <829F074A10F98943A218DC363D09C92A01476C49@w2ksjexg06.ciena.com> Subject: Re: draft-ietf-ccamp-gmpls-egress-control-00.txt Date: Thu, 8 Apr 2004 23:29:14 +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-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Hi Lyndon, First note that this draft does not update the protocols and procedures of RFC3473. It restates them more explicitly. If you look at the RFC index (http://www.ietf.org/iesg/1rfc_index.txt) you'll see there is very little precedent for this type of work. We can find BCP 75 and 76 ( and http://www.ietf.org/rfc/rfc3666.txt) which could sort of be said to update (or at least qualify) RFC 3261 and RFC 3264. Neither is listed with an "updates" clause. Nor does RFC 3481 (BCP 71) have any back/forward pointer with the TCP standard. However, I take your point: how does someone wanting to know everything about GMPLS know to read this new document? We will look to see how this can be managed. In return can you tell me: how does anyone wanting to see all of the RFCs related to (say) TCP find them all? Cheers, Adrian ----- Original Message ----- From: "Ong, Lyndon" To: "'Lou Berger'" ; "Adrian Farrel" Cc: Sent: Thursday, April 08, 2004 10:20 PM Subject: RE: draft-ietf-ccamp-gmpls-egress-control-00.txt > Hi Guys, > > Administrative question - if this comes out as a BCP, > does the RFC table note this as some kind of update > to 3473? > > I'd be a little worried if there is no notation against > the RFC to point people to the clarification. > > Thanks, > > Lyndon > > -----Original Message----- > From: Lou Berger [mailto:lberger@movaz.com] > Sent: Thursday, April 08, 2004 2:11 PM > To: Adrian Farrel > Cc: Berger, Lou; ccamp@ops.ietf.org > Subject: Re: draft-ietf-ccamp-gmpls-egress-control-00.txt > > > Adrian, > See responses below. > > At 03:46 PM 4/8/2004 -0400, Adrian Farrel wrote: > >Hi Lou, > > > > > >Please give the intended category of the work... > > > >Proposed Category: Best Common Practice > > > > > > this is normally done outside of the draft. > > > >Hmmm. > >The draft needs to indicate its intended status so that folks can review > >it with that in mind. > >If you don't want to say that the proposed status is BCP then please at > >least say informational. > > will put into draft - I've always seen this in the last call announcement - > but whatever... > > > > > > > >Please correct draft name as it appears in the title and footers. > > > > > > > >draft-ietf-ccamp-gmpls-egress-control-00.txt > > > > > > fixed last week. > > > >Hah! But the secretariat has published it according to your first submission. > >Actually, the version on the LabN site is also wrong. > > > >I don't mean the document name, I mean the draft name as it appears > >throughout the document. > > will be fixed in next rev... > > >[...]> > > > >Compare with section 2.2 which is more general. > > > > > > > > To support Egress Control, an egress checks to see if the received > > > > ERO contains an outgoing/downstream interface. If it does, the type > > > > of the subobject or subobjects following the interface are examined. > > > > If the associated LSP is unidirectional, one subobject is examined. > > > > Two subobjects are examined for bidirectional LSPs. If the U-bit of > > > > the subobject being examined is clear (0), then the value of the > > > > label is copied into a new Label_Set object. Note, this Label_Set > > > > object is for internal use only. This Label_Set object indicates the > > > > label value that MUST be used for transmitting traffic associated > > > > with the LSP on the indicated outgoing/downstream interface. > > > >Not withstanding "this Label_Set object is for internal use only", I > > > >find this text a bit peculiar! > > > >You really just want to say that this subobject is used to specify the > > > >label that the egress MUST apply to traffic that it forwards from this > > > >LSP. (Compare with the next paragraph where you do not describe > > > >creating an Upstream_Label object for internal use only.) > > > >If you insist on talking about the Label_Set object, you will have to be > > > >far more specific because there are four different varieties of that > > > >object. > > > > > > I think the wording is consistent with RFC3473 and unambiguous. Please > > > suggest alternate wording. > > > >Well! I can't be held responsible for the failings of the editor of that > >RFC :-) > > > >Section 5.1.1 says with respect to the ERO Label Subobject... > > If the U-bit of the > > subobject being examined is clear (0), then value of the label is > > copied into a new Label_Set object. This Label_Set object MUST be > > included on the corresponding outgoing Path message. > > > >So I see where you are coming from, but I think this text is aimed at > >specifying how you build the outgoing Path message, not how you > >manage the label allocation on your downstream interface. It is > >wrong to suggest that an implementation must create a protocol > >object for this purpose if no Path message is to be sent. > > > >In fact, since there is no corresponding Resv with a Label Object > >we need to pin this text down a little more clearly. How about the > >following edit... > > > > To support Egress Control, an egress checks to see if the received > > ERO contains an outgoing/downstream interface. If it does, the type > > of the subobject or subobjects following the interface are examined. > > If the associated LSP is unidirectional, one subobject is examined. > > Two subobjects are examined for bidirectional LSPs. If the U-bit of > > the subobject being examined is clear (0), then the value of the > > label MUST be used for transmitting traffic associated with the LSP > > on the indicated outgoing/downstream interface. > > Done! > > > > > including if the listed label(s) are not acceptable or cannot be > > > > supported in forwarding, SHOULD result in the generation of a PathErr > > > > message containing a "Bad EXPLICIT_ROUTE object" error. > > > >I'd prefer you to be more explicit... > > > >... containing a "Routing Problem"/"Bad EXPLICIT_ROUTE object" error. > > > sure, will use phrasing from rfc3209. > > > > > > >3. Security Considerations > > > > > > > >< This note clarifies procedures defined in [RFC3473]. As such, no new > > > >< security considerations are introduced. > > > > > This note reiterates procedures defined in [RFC3473], but does not > > > > > define any new procedures. As such, no new security considerations > > > > > are introduced. > > > okay. > > > > > > ><5. References > > > > >5. Normative References > > > > > > > >Need BCP 78, and 79 as informational references. > > > >Also RFC 3668. > > > > > > will do, but do you really want me to reference BCP 79 and RFC 3668? > > > >It is unclear whether this is a requirement, but since the boilerplate > >text makes these references it seems reasonable to include them in the list. > > ahh, you fell for my trick question! (they're the same document ;-) > > > > > > >8. Intellectual Property > > > > > > > >Missing the personal disclaimer... > > > > By submitting this Internet-Draft, I certify that any applicable > > > > patent or other IPR claims of which I am aware have been disclosed, > > > > and any of which I become aware will be disclosed, in accordance with > > > > RFC 3668. > > > sure. > > > > > > >Don't need the footer... > > > >Generated on: Mon Mar 15 10:52:32 2004 > > > > > > picky, picky, picky... > >That's what I'm paid for. > > > >Thanks, Lou. Looking forward to seeing the revision published. > > > >Adrian > > > > Thanks again. > > submitting in a few minutes... > > Lou > > > From pqm_press@hotmail.com Fri Apr 9 10:59:54 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01822 for ; Fri, 9 Apr 2004 10:59:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBxU2-0005HC-00 for ccamp-archive@ietf.org; Fri, 09 Apr 2004 10:59:54 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBxT3-0005A8-00 for ccamp-archive@ietf.org; Fri, 09 Apr 2004 10:58:54 -0400 Received: from dpvc-68-161-240-106.ny325.east.verizon.net ([68.161.240.106] helo=ietf.org) by ietf-mx with smtp (Exim 4.12) id 1BBxRp-000502-00; Fri, 09 Apr 2004 10:57:38 -0400 From: "Atualidade Brasileira . xfg" To: ccamp-archive@ietf.org Subject: Livre-comércio: divisor de águas at.: pxy 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 MIME-Version: 1.0 Content-Type: text/html Message-Id: Date: Fri, 09 Apr 2004 10:57:38 -0400 X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=13.9 required=5.0 tests=FORGED_MUA_OUTLOOK, FORGED_OUTLOOK_HTML,HTML_40_50,HTML_FONT_BIG,HTML_MESSAGE, MAILTO_SUBJ_REMOVE,MAILTO_TO_REMOVE,MAILTO_TO_SPAM_ADDR, MIME_HTML_NO_CHARSET,MIME_HTML_ONLY,MSGID_FROM_MTA_SHORT, REMOVE_REMOVAL_2WORD,SUBJ_HAS_SPACES,SUBJ_ILLEGAL_CHARS autolearn=no version=2.60 X-Spam-Report: * 1.0 SUBJ_HAS_SPACES Subject contains lots of white space * 0.5 REMOVE_REMOVAL_2WORD BODY: List removal information * 0.5 HTML_40_50 BODY: Message is 40% to 50% HTML * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 HTML_FONT_BIG BODY: HTML has a big font * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 1.3 MAILTO_SUBJ_REMOVE BODY: mailto URI includes removal text * 0.7 MIME_HTML_NO_CHARSET RAW: Message text in HTML without charset * 1.1 MAILTO_TO_SPAM_ADDR URI: Includes a link to a likely spammer email * 0.0 MAILTO_TO_REMOVE URI: Includes a 'remove' email address * 2.7 SUBJ_ILLEGAL_CHARS Subject contains too many raw illegal characters * 3.3 MSGID_FROM_MTA_SHORT Message-Id was added by a relay * 1.1 FORGED_OUTLOOK_HTML Outlook can't send HTML message only * 1.6 FORGED_MUA_OUTLOOK Forged mail pretending to be from MS Outlook

(ref.:tcc) ConstruNews deseja uma Feliz Páscoa a todos os seus amigos e suas respectivas famílias!

Lindenberg:EnEspañol - Lindenberg:InEnglish(LinkToFreeTranslator)

Série Temas Patrulhados (5)

"Livre-comércio, divisor de águas entre os favoráveis e os contrários à liberdade econômica"

No atual governo brasileiro, o componente ideológico que impregna setores do Itamaraty, regredindo ao terceiro-mundismo dos anos 70, os leva a admitir acordos comerciais com qualquer país, especialmente, os do "sul", mas não com os Estados Unidos, uma atitude irrealista e míope de nossa diplomacia, afirma Adolpho Lindenberg em recente artigo

* Adolpho Lindenberg é autor do livro "Os católicos e a economia de mercado", em que denuncia uma política com viés esquerdista que censura, marginaliza ou encobre com um manto de silêncio, opiniões "politicamente incorretas", não afinados com as assim denominadas "causas sociais" inspiradas na teologia da libertação e nos Fóruns Sociais. Assim, os meios de comunicação, e a própria sociedade brasileira, estão sendo "patrulhados".

* Em seu recente artigo "A economia de mercado e o livre-comércio", da Série Temas Patrulhados, o autor lamenta que a economia de mercado e o livre-comércio continuem sendo o alvo predileto da dialética intervencionista e progressista. Os argumentos usados se repetem como certas melodias dos clássicos realejos de antigamente, comenta Lindenberg, que em seu artigo enumera uma série dessas diatribes, das quais citamos aqui:

- Livres de quaisquer tabelamento ou fiscalização de "órgãos competentes", os preços subiriam assustadoramente, empobrecendo os consumidores, deixando-os indefesos diante da ganância dos industriais, fazendeiros, comerciantes, etc.

- A ganância dos industriais e o esmagamento das pequenas empresas incapazes de competir contra os gigantes empresariais, só sofreriam limites se o Estado intervier no mercado, via controle de preços, estatização das empresas de serviços públicos, subsídios e barreiras alfandegárias.

- O livre-comércio seria a porta de entrada dos produtos das multinacionais em nosso país com o intuito de nos explorar e nos submeter ao imperialismo norte-americano.

* A estas e outras diatribes analisadas e refutadas no artigo, se soma, no atual governo brasileiro, o componente ideológico que passou a impregnar setores do Itamaraty, parecendo ter regredido ao terceiro-mundismo dos anos 70, dispostos a admitir acordos comerciais com qualquer país, especialmente, os do "sul", mas não com os Estados Unidos. Atitude de nossa diplomacia que tem sido qualificada de "irrealista" por analistas políticos e criticada enfaticamente.

* A única correção possível para essa miopia consiste numa boa compreensão do que seja uma concorrência sadia e de como a competitividade entre os produtores constitui o instrumento natural para manter os preços dos produtos pouco acima de seu preço de custo, explica Lindenberg.

* O mercado é uma realidade funcional que oferece condições para produtores e consumidores, vendedores e compradores entrarem em contato entre si, com vistas a conhecer, avaliar e comparar os bens oferecidos e eventualmente chegar a acordos sobre preços. Tais combinações são obtidas mediante o livre jogo da oferta e da procura.

* Todos quantos consideram preferível a determinação dos preços por via governamental - evitando destarte os "desmandos da lei da oferta e da procura" - por mais bem-intencionados que possam ser (requisito não muito comum em nossos dias...), por melhores que sejam os programas de seus computadores, nunca conseguirão combinar as centenas de fatores que condicionam os preços de um modo tão perfeito, vivo e atualizado, como aqueles que emergem das práticas mercadológicas.

* A aceitação ou recusa do livre-comércio e suas conseqüências naturais, é o divisor de águas entre as mentalidades favoráveis e as contrárias à liberdade econômica, conclui Lindenberg, cujo artigo oferecemos gratuitamente.

Link gratuito:

* Para receber gratuitamente, por e-mail, o texto completo deste artigo, clique em: Lindenberg:EsteArtigoCompletoGratuitamente(No.5)

Outros links gratuitos (e-Book e outros artigos):

Lindenberg:e-BookGratuitoBr (em formato Word, com 11 artigos de Lindenberg)

Lindenberg:IntroduçãoGratuitaDoLivro (em formato Word, Introdução do livro "Os católicos e a economia de mercado")

Lindenberg:ArtigosAnteriores

Lindenberg:ProximosArtigos

 Links de opinião

Gostariamos muito de receber seu seu voto eletrônico sobre a temática abordada neste e-mail e, se possível, conhecer sua valiosa opinião:

Lindenberg:Concordo - Lindenberg:Discrepo - Lindenberg:MinhaOpinião

Outros links

Lindenberg:DesejoAdquirirLivro (receberá instruções sobre como poder adquirir o livro no Brasil)

Remover (para ser retirado imediatamente de nosso Address Book).

A difusão desta mensagem, com uma finalidade cultural e com o intuito de promover um debate construtivo e respeitoso de idéias, é de exclusiva responsabilidade da ConstruNews. Telefone de contato: (11) 9252 - 7873

 

 From owner-ccamp@ops.ietf.org Fri Apr 9 17:15:19 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22672 for ; Fri, 9 Apr 2004 17:15:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BC3LL-00041W-00 for ccamp-archive@ietf.org; Fri, 09 Apr 2004 17:15:20 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BC36V-0002RZ-00 for ccamp-archive@ietf.org; Fri, 09 Apr 2004 17:00:00 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BC2qz-0000qV-00 for ccamp-archive@ietf.org; Fri, 09 Apr 2004 16:43:57 -0400 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BC2b7-0004oJ-5r for ccamp-data@psg.com; Fri, 09 Apr 2004 20:27:33 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BC2b4-0004nM-P0 for ccamp@ops.ietf.org; Fri, 09 Apr 2004 20:27:30 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15366; Fri, 9 Apr 2004 15:36:34 -0400 (EDT) Message-Id: <200404091936.PAA15366@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-gmpls-ason-routing-reqts-03.txt Date: Fri, 09 Apr 2004 15:36:34 -0400 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --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 : Requirements for Generalized MPLS (GMPLS) Routing for Automatically Switched Optical Network (ASON) Author(s) : W. Alanqar, et al Filename : draft-ietf-ccamp-gmpls-ason-routing-reqts-03.txt Pages : 19 Date : 2004-4-9 The Generalized MPLS (GMPLS) suite of protocols has been defined to control different switching technologies as well as different applications. These include support for requesting TDM connections including SONET/SDH and Optical Transport Networks (OTNs). This document concentrates on the routing requirements on the GMPLS suite of protocols to support the capabilities and functionalities for an Automatically Switched Optical Network (ASON) as defined by ITU-T. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-ason-routing-reqts-03.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-ason-routing-reqts-03.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-ason-routing-reqts-03.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: <2004-4-9154858.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-gmpls-ason-routing-reqts-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-gmpls-ason-routing-reqts-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-4-9154858.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ccamp@ops.ietf.org Fri Apr 9 18:25:34 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28102 for ; Fri, 9 Apr 2004 18:25:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BC4RL-0001Ni-00 for ccamp-archive@ietf.org; Fri, 09 Apr 2004 18:25:36 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BC4Li-0000pg-00 for ccamp-archive@ietf.org; Fri, 09 Apr 2004 18:19:47 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BC4D4-0000BO-00 for ccamp-archive@ietf.org; Fri, 09 Apr 2004 18:10:50 -0400 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BC40I-0008GS-NP for ccamp-data@psg.com; Fri, 09 Apr 2004 21:57:38 +0000 Received: from [66.163.170.80] (helo=smtp810.mail.sc5.yahoo.com) by psg.com with smtp (Exim 4.30; FreeBSD) id 1BC40H-0008Fp-IW for ccamp@ops.ietf.org; Fri, 09 Apr 2004 21:57:37 +0000 Received: from unknown (HELO RAKHILAPTOP) (vishal.sharma@sbcglobal.net@67.117.150.108 with login) by smtp810.mail.sc5.yahoo.com with SMTP; 9 Apr 2004 21:57:36 -0000 Reply-To: From: "Vishal Sharma" To: "Adrian Farrel" , "Ong, Lyndon" Cc: , "'Lou Berger'" Subject: RE: draft-ietf-ccamp-gmpls-egress-control-00.txt Date: Fri, 9 Apr 2004 14:57:30 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <021d01c41db8$f02bb240$7caa9ed9@Puppy> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Adrian, > -----Original Message----- > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On > Behalf Of Adrian Farrel > Sent: Thursday, April 08, 2004 3:29 PM > To: Ong, Lyndon > Cc: ccamp@ops.ietf.org; 'Lou Berger' > Subject: Re: draft-ietf-ccamp-gmpls-egress-control-00.txt > > > Hi Lyndon, > > First note that this draft does not update the protocols and > procedures of RFC3473. It > restates them more explicitly. > > If you look at the RFC index > (http://www.ietf.org/iesg/1rfc_index.txt) you'll see there is > very little precedent for this type of work. > We can find BCP 75 and 76 ( and > http://www.ietf.org/rfc/rfc3666.txt) which could sort of > be said to update (or at least qualify) RFC 3261 and RFC 3264. > Neither is listed with an "updates" clause. > > Nor does RFC 3481 (BCP 71) have any back/forward pointer with the > TCP standard. > > > However, I take your point: how does someone wanting to know > everything about GMPLS know > to read this new document? > > We will look to see how this can be managed. > > In return can you tell me: how does anyone wanting to see all of > the RFCs related to (say) > TCP find them all? I guess that's when one consults either Stevens' tome, or one of Peter Loshin's "Big Book of X RFCs" where "X" = technology or protocol in question. :-) (I am not actually sure whether he has a big book of TCP/IP RFCs.) -Vishal From owner-ccamp@ops.ietf.org Mon Apr 12 15:06:59 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05488 for ; Mon, 12 Apr 2004 15:06:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BD6ln-0004hV-00 for ccamp-archive@ietf.org; Mon, 12 Apr 2004 15:06:59 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BD6kf-0004Wi-00 for ccamp-archive@ietf.org; Mon, 12 Apr 2004 15:05:50 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BD6jD-0004Fj-00 for ccamp-archive@ietf.org; Mon, 12 Apr 2004 15:04:19 -0400 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BD6Qh-000D7t-On for ccamp-data@psg.com; Mon, 12 Apr 2004 18:45:11 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BD6Qd-000D6m-8r for ccamp@ops.ietf.org; Mon, 12 Apr 2004 18:45:07 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04020; Mon, 12 Apr 2004 14:45:03 -0400 (EDT) Message-Id: <200404121845.OAA04020@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-gmpls-ason-routing-reqts-03.txt Date: Mon, 12 Apr 2004 14:45:03 -0400 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --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 : Requirements for Generalized MPLS (GMPLS) Routing for Automatically Switched Optical Network (ASON) Author(s) : W. Alanqar, et al Filename : draft-ietf-ccamp-gmpls-ason-routing-reqts-03.txt Pages : 19 Date : 2004-4-9 The Generalized MPLS (GMPLS) suite of protocols has been defined to control different switching technologies as well as different applications. These include support for requesting TDM connections including SONET/SDH and Optical Transport Networks (OTNs). This document concentrates on the routing requirements on the GMPLS suite of protocols to support the capabilities and functionalities for an Automatically Switched Optical Network (ASON) as defined by ITU-T. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-ason-routing-reqts-03.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-ason-routing-reqts-03.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-ason-routing-reqts-03.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: <2004-4-9154858.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-gmpls-ason-routing-reqts-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-gmpls-ason-routing-reqts-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-4-9154858.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ccamp@ops.ietf.org Mon Apr 12 15:53:55 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10350 for ; Mon, 12 Apr 2004 15:53:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BD7VE-0004B4-00 for ccamp-archive@ietf.org; Mon, 12 Apr 2004 15:53:56 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BD7Q6-0003GL-00 for ccamp-archive@ietf.org; Mon, 12 Apr 2004 15:48:39 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BD7Ma-0002bs-00 for ccamp-archive@ietf.org; Mon, 12 Apr 2004 15:45:00 -0400 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BD78s-000OaE-O7 for ccamp-data@psg.com; Mon, 12 Apr 2004 19:30:50 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BD78r-000OZm-N2 for ccamp@ops.ietf.org; Mon, 12 Apr 2004 19:30:49 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08622; Mon, 12 Apr 2004 15:30:46 -0400 (EDT) Message-Id: <200404121930.PAA08622@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-gmpls-recovery-terminology-04.txt Date: Mon, 12 Apr 2004 15:30:46 -0400 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --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 : Recovery (Protection and Restoration) Terminology for GMPLS Author(s) : E. Mannie, D. Papadimitriou Filename : draft-ietf-ccamp-gmpls-recovery-terminology-04.txt Pages : 21 Date : 2004-4-12 This document defines a common terminology for Generalized Multi- Protocol Label Switching (GMPLS) based recovery mechanisms (i.e. protection and restoration). The terminology is independent of the underlying transport technologies covered by GMPLS. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-recovery-terminology-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-gmpls-recovery-terminology-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-gmpls-recovery-terminology-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: <2004-4-12153758.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-gmpls-recovery-terminology-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-gmpls-recovery-terminology-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-4-12153758.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ccamp@ops.ietf.org Mon Apr 12 15:57:16 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10520 for ; Mon, 12 Apr 2004 15:57:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BD7YT-0004eU-00 for ccamp-archive@ietf.org; Mon, 12 Apr 2004 15:57:17 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BD7RF-0003Q4-00 for ccamp-archive@ietf.org; Mon, 12 Apr 2004 15:49:50 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BD7NU-0002jP-00 for ccamp-archive@ietf.org; Mon, 12 Apr 2004 15:45:56 -0400 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BD78l-000OYr-T7 for ccamp-data@psg.com; Mon, 12 Apr 2004 19:30:43 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BD78k-000OYB-Nx for ccamp@ops.ietf.org; Mon, 12 Apr 2004 19:30:42 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08614; Mon, 12 Apr 2004 15:30:40 -0400 (EDT) Message-Id: <200404121930.PAA08614@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-gmpls-recovery-analysis-03.txt Date: Mon, 12 Apr 2004 15:30:40 -0400 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --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 : Analysis of Generalized Multi-Protocol Label Switching (GMPLS)-based Recovery Mechanisms (including Protection and Restoration) Author(s) : D. Papadimitriou, E. Mannie Filename : draft-ietf-ccamp-gmpls-recovery-analysis-03.txt Pages : 42 Date : 2004-4-12 This document provides an analysis grid to evaluate, compare and contrast the Generalized Multi-Protocol Label Switching (GMPLS) protocol suite capabilities with respect to the recovery mechanisms currently proposed at the IETF CCAMP Working Group. A detailed analysis of each of the recovery phases is provided using the terminology defined in a companion document. This document focuses on transport plane survivability and recovery issues and not on control plane resilience and related aspects. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-recovery-analysis-03.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-recovery-analysis-03.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-recovery-analysis-03.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: <2004-4-12153729.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-gmpls-recovery-analysis-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-gmpls-recovery-analysis-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-4-12153729.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ccamp@ops.ietf.org Mon Apr 12 19:00:48 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23617 for ; Mon, 12 Apr 2004 19:00:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDAQ5-0002CD-00 for ccamp-archive@ietf.org; Mon, 12 Apr 2004 19:00:49 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BD9zk-0000L2-00 for ccamp-archive@ietf.org; Mon, 12 Apr 2004 18:33:36 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BD9UE-00063h-00 for ccamp-archive@ietf.org; Mon, 12 Apr 2004 18:01:02 -0400 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BD9Js-0006nB-K7 for ccamp-data@psg.com; Mon, 12 Apr 2004 21:50:20 +0000 Received: from [80.168.70.142] (helo=relay2.mail.uk.clara.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BD9Jr-0006mX-FU; Mon, 12 Apr 2004 21:50:19 +0000 Received: from du-069-0224.access.clara.net ([217.158.132.224] helo=Puppy) by relay2.mail.uk.clara.net with smtp (Exim 4.30) id 1BD9Jq-0000eG-Aq; Mon, 12 Apr 2004 22:50:18 +0100 Message-ID: <00b901c420d8$27e2b450$60849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Cc: Subject: Fw: I-D ACTION:draft-ietf-ccamp-gmpls-recovery-terminology-04.txt Date: Mon, 12 Apr 2004 22:36:28 +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-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Hi Alex, This draft has been updated after WG last call minor comment. Could you please take this draft forward to the IESG. Thanks, Adrian ----- Original Message ----- From: > 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 : Recovery (Protection and Restoration) Terminology for GMPLS > Author(s) : E. Mannie, D. Papadimitriou > Filename : draft-ietf-ccamp-gmpls-recovery-terminology-04.txt > Pages : 21 > Date : 2004-4-12 > > This document defines a common terminology for Generalized Multi- > Protocol Label Switching (GMPLS) based recovery mechanisms (i.e. > protection and restoration). The terminology is independent of the > underlying transport technologies covered by GMPLS. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-recovery-terminology-04.txt From owner-ccamp@ops.ietf.org Mon Apr 12 19:46:24 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23640 for ; Mon, 12 Apr 2004 19:00:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDAQ7-0002CQ-00 for ccamp-archive@ietf.org; Mon, 12 Apr 2004 19:00:51 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BD9zm-0000LM-00 for ccamp-archive@ietf.org; Mon, 12 Apr 2004 18:33:39 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BD9UR-00064X-00 for ccamp-archive@ietf.org; Mon, 12 Apr 2004 18:01:15 -0400 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BD9Jt-0006nh-Cu for ccamp-data@psg.com; Mon, 12 Apr 2004 21:50:21 +0000 Received: from [80.168.70.142] (helo=relay2.mail.uk.clara.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BD9Js-0006mw-Ks; Mon, 12 Apr 2004 21:50:20 +0000 Received: from du-069-0224.access.clara.net ([217.158.132.224] helo=Puppy) by relay2.mail.uk.clara.net with smtp (Exim 4.30) id 1BD9Jr-0000eG-C1; Mon, 12 Apr 2004 22:50:19 +0100 Message-ID: <00ba01c420d8$28b100d0$60849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Cc: Subject: Fw: I-D ACTION:draft-ietf-ccamp-gmpls-recovery-analysis-03.txt Date: Mon, 12 Apr 2004 22:38:33 +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-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Hi again Alex, This draft, too, has been updated after minor comments in WG last call. Would be grateful if you could progress it towards the IESG. Thanks, Adrian ----- Original Message ----- From: > 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 : Analysis of Generalized Multi-Protocol Label Switching (GMPLS)-based Recovery Mechanisms (including Protection and Restoration) > Author(s) : D. Papadimitriou, E. Mannie > Filename : draft-ietf-ccamp-gmpls-recovery-analysis-03.txt > Pages : 42 > Date : 2004-4-12 > > This document provides an analysis grid to evaluate, compare and > contrast the Generalized Multi-Protocol Label Switching (GMPLS) > protocol suite capabilities with respect to the recovery mechanisms > currently proposed at the IETF CCAMP Working Group. A detailed > analysis of each of the recovery phases is provided using the > terminology defined in a companion document. This document focuses > on transport plane survivability and recovery issues and not on > control plane resilience and related aspects. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-recovery-analysis-03.txt From owner-ccamp@ops.ietf.org Wed Apr 14 08:14:44 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19709 for ; Wed, 14 Apr 2004 08:14:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDjHw-0000oK-00 for ccamp-archive@ietf.org; Wed, 14 Apr 2004 08:14:44 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDjH2-0000fF-00 for ccamp-archive@ietf.org; Wed, 14 Apr 2004 08:13:49 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BDjFz-0000XP-00 for ccamp-archive@ietf.org; Wed, 14 Apr 2004 08:12:43 -0400 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BDix1-0004Xw-Hm for ccamp-data@psg.com; Wed, 14 Apr 2004 11:53:07 +0000 Received: from [80.168.70.142] (helo=relay2.mail.uk.clara.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BDiwz-0004XF-UL for ccamp@ops.ietf.org; Wed, 14 Apr 2004 11:53:06 +0000 Received: from du-069-0166.access.clara.net ([217.158.132.166] helo=Puppy) by relay2.mail.uk.clara.net with smtp (Exim 4.30) id 1BDiwy-000Nvw-9i for ccamp@ops.ietf.org; Wed, 14 Apr 2004 12:53:04 +0100 Message-ID: <02a601c42217$0b13dda0$60849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Proposed strategy for Inter-area/AS Date: Wed, 14 Apr 2004 12:49:56 +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-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit All, JP and Arthi have done a fine job of pulling together all of the threads of inter-area and inter-AS solutions into a single draft. This gives us a single place to look for information, but the resulting draft is (of course) quite large. As additional details need to be filled in, it is clear that this draft would only grow and that would make it unusably large. So, we are proposing to use the material in the draft to produce a series of detailed drafts that would, over time, replace JP and Arthi's document. 1. Framework for Interdomain MPLS and GMPLS A short draft that introduces the routing and signaling options for multi-domain LSPs, and explains the options for path computation. This does not describe applicability or any necessary protocol procedures or extensions. Material will be taken from draft-vasseur-ccamp-inter-area-as-te and draft-kompella-mpls-multiarea-te as required. Authors: Adrian, JP, Arthi Due date: End of April. 2. Individual signaling extension drafts If any one of the signaling approaches described in 1. requires additional protocol procedures or extensions then a single draft will be written for each. The base assumption is that such a draft will only be written if there someone planning to implement and deploy. Authors: Dependent on extension Due date: Aim for San Diego 3. Individual routing extension drafts There are two dimensions to this: - the different routing protocols (IGPs and EGPs) - the different solution models The aim should be to have one draft per protocol to provide the generic mechanisms, and one draft per model per protocol to provide procedures and field values etc. Note that path computation functions are described under point 5, below. As with the signaling extensions, this work will only be done once we understand that there is a need *and* what is needed. Authors: Again dependent on deployment plans Due date: Slightly later than signaling work 4. Applicability A draft to explain when it is appropriate to use which model and options. The aim is not to rubbish the opposition, but to say when a particular model can/should be used. Much of this material can already be found in draft-vasseur-ccamp-inter-area-as-te, but it may need some tidying up. For political/expediency reasons this may result in multiple applicability drafts in the first instance. Authors: A supporter of each model Due date: Quite soon - to accompany signaling extensions. 5. Path computation Some solution models call for a (or many) path computation servers (PCS). This demands several functions: - discovery of PCS by network elements - communication protocol between PCS and network elements - some regulation of computation technique to avoid looping etc. At the moment we are discussing precisely where this work should be done, but that should not stop us starting the work within CCAMP since it is clearly related to the inter-area/AS solution. 6. Advanced functions. There are several advanced functions that will be required, but which are not part of the immediate work. - Path reoptimization - Protection path diversity - crankback We expect that once the initial work has been done on the solutions, it will be possible to set out the requirements for these functions and to develop solutions based on the many drafts that are already out there. Comments please. Thanks, Adrian and Kireeti From owner-ccamp@ops.ietf.org Wed Apr 14 14:23:14 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12806 for ; Wed, 14 Apr 2004 14:23:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDp2Z-0005yP-00 for ccamp-archive@ietf.org; Wed, 14 Apr 2004 14:23:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDp1g-0005v0-00 for ccamp-archive@ietf.org; Wed, 14 Apr 2004 14:22:21 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BDp11-0005rc-00 for ccamp-archive@ietf.org; Wed, 14 Apr 2004 14:21:39 -0400 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BDohe-000Cnq-51 for ccamp-data@psg.com; Wed, 14 Apr 2004 18:01:38 +0000 Received: from [12.20.58.69] (helo=ckmso1.proxy.att.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BDohd-000Cne-0w for ccamp@ops.ietf.org; Wed, 14 Apr 2004 18:01:37 +0000 Received: from attrh5i.attrh.att.com ([135.38.62.12]) by ckmso1.proxy.att.com (AT&T IPNS/MSO-5.0) with ESMTP id i3EHxmgH013524 for ; Wed, 14 Apr 2004 14:01:36 -0400 Received: from OCCLUST04EVS1.ugd.att.com (135.38.164.12) by attrh5i.attrh.att.com (6.5.032) id 405DCB76006BF4B7 for ccamp@ops.ietf.org; Wed, 14 Apr 2004 14:00:58 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6489.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: FW: I-D ACTION:draft-ietf-ccamp-gmpls-ason-routing-reqts-03.txt Date: Wed, 14 Apr 2004 13:01:35 -0500 Message-ID: <449B2580D802A443A923DABF3EAB82AF0572A347@OCCLUST04EVS1.ugd.att.com> Thread-Topic: I-D ACTION:draft-ietf-ccamp-gmpls-ason-routing-reqts-03.txt Thread-Index: AcQgvqvLuB0OdcS7SOiZ0/y9Z/sJ/ABiV6qw From: "Brungard, Deborah A, ALABS" To: Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable CCAMP, The ASON Routing Reqts DT has updated the following draft based on ITU = Q14/15's Liaison and CCAMP mail list comments. We recommend this document as ready for WG Last Call. Thanks, Deborah -----Original Message----- From: i-d-announce-admin@ietf.org [mailto:i-d-announce-admin@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Monday, April 12, 2004 2:45 PM To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org Subject: I-D ACTION:draft-ietf-ccamp-gmpls-ason-routing-reqts-03.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 : Requirements for Generalized MPLS (GMPLS) Routing for = Automatically Switched Optical Network (ASON) Author(s) : W. Alanqar, et al Filename : draft-ietf-ccamp-gmpls-ason-routing-reqts-03.txt Pages : 19 Date : 2004-4-9 =09 The Generalized MPLS (GMPLS) suite of protocols has been defined to control different switching technologies as well as different applications. These include support for requesting TDM connections including SONET/SDH and Optical Transport Networks (OTNs). This document concentrates on the routing requirements on the GMPLS suite of protocols to support the capabilities and functionalities for an Automatically Switched Optical Network (ASON) as defined by ITU-T. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-ason-routing-r= eqts-03.txt To remove yourself from the I-D Announcement list, send a message to=20 i-d-announce-request@ietf.org with the word unsubscribe in the body of = the message. =20 You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce=20 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-ason-routing-reqts-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html=20 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-ason-routing-reqts-03.txt". =09 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. =09 =09 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 Apr 14 20:03:49 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06651 for ; Wed, 14 Apr 2004 20:03:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDuM8-0007IH-00 for ccamp-archive@ietf.org; Wed, 14 Apr 2004 20:03:49 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDuL3-0007DJ-00 for ccamp-archive@ietf.org; Wed, 14 Apr 2004 20:02:42 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BDuKB-00079v-00 for ccamp-archive@ietf.org; Wed, 14 Apr 2004 20:01:48 -0400 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BDu5J-0001rd-65 for ccamp-data@psg.com; Wed, 14 Apr 2004 23:46:25 +0000 Received: from [207.17.136.150] (helo=kummer.juniper.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BDu5I-0001rO-7f for ccamp@ops.ietf.org; Wed, 14 Apr 2004 23:46:24 +0000 Received: from kummer.juniper.net (localhost [127.0.0.1]) by kummer.juniper.net (8.12.8p1/8.12.3) with ESMTP id i3ENkOPg035848 for ; Wed, 14 Apr 2004 16:46:24 -0700 (PDT) (envelope-from kireeti@juniper.net) Received: from localhost (kireeti@localhost) by kummer.juniper.net (8.12.8p1/8.12.3/Submit) with ESMTP id i3ENkOgI035845 for ; Wed, 14 Apr 2004 16:46:24 -0700 (PDT) X-Authentication-Warning: kummer.juniper.net: kireeti owned process doing -bs Date: Wed, 14 Apr 2004 16:46:23 -0700 (PDT) From: Kireeti Kompella To: ccamp@ops.ietf.org Subject: Re: FW: I-D ACTION:draft-ietf-ccamp-gmpls-ason-routing-reqts-03.txt In-Reply-To: <449B2580D802A443A923DABF3EAB82AF0572A347@OCCLUST04EVS1.ugd.att.com> Message-ID: <20040414163803.G35765@kummer.juniper.net> References: <449B2580D802A443A923DABF3EAB82AF0572A347@OCCLUST04EVS1.ugd.att.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Hi All, On Wed, 14 Apr 2004, Brungard, Deborah A, ALABS wrote: > The ASON Routing Reqts DT has updated the following draft based on > ITU Q14/15's Liaison and CCAMP mail list comments. > > We recommend this document as ready for WG Last Call. This commences a two-week WG Last Call on the GMPLS ASON routing requirements. Last Call ends April 28th, 5pm PDT. Please send your comments to the list. The proposed category is Informational. Kireeti. ------- From owner-ccamp@ops.ietf.org Thu Apr 15 15:54:51 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22615 for ; Thu, 15 Apr 2004 15:54:51 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BECwm-00069e-Dt for ccamp-archive@ietf.org; Thu, 15 Apr 2004 15:54:52 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BECvr-00068E-00 for ccamp-archive@ietf.org; Thu, 15 Apr 2004 15:53:56 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BECvZ-00066t-00 for ccamp-archive@ietf.org; Thu, 15 Apr 2004 15:53:37 -0400 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BECVq-0000RE-KA for ccamp-data@psg.com; Thu, 15 Apr 2004 19:27:02 +0000 Received: from [62.23.212.165] (helo=smail.alcatel.fr) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BECVh-0000PR-2f for ccamp@ops.ietf.org; Thu, 15 Apr 2004 19:26:53 +0000 Received: from bemail05.netfr.alcatel.fr (bemail05.netfr.alcatel.fr [155.132.251.11]) by smail.alcatel.fr (ALCANET/NETFR) with ESMTP id i3FJQnI8004346; Thu, 15 Apr 2004 21:26:49 +0200 Received: from alcatel.be ([138.203.118.2]) by bemail05.netfr.alcatel.fr (Lotus Domino Release 5.0.11) with ESMTP id 2004041521264682:4487 ; Thu, 15 Apr 2004 21:26:46 +0200 Message-ID: <407EE27A.6010000@alcatel.be> Date: Thu, 15 Apr 2004 21:28:58 +0200 From: Dimitri.Papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.5) Gecko/20030925 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Adrian Farrel CC: ccamp@ops.ietf.org Subject: Re: Proposed strategy for Inter-area/AS References: <02a601c42217$0b13dda0$60849ed9@Puppy> In-Reply-To: <02a601c42217$0b13dda0$60849ed9@Puppy> X-MIMETrack: Itemize by SMTP Server on BEMAIL05/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 04/15/2004 21:26:47, Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 04/15/2004 21:26:49, Serialize complete at 04/15/2004 21:26:49 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed X-Alcanet-MTA-scanned-and-authorized: yes Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit hi adrian, some comments in-line: Adrian Farrel wrote: > All, > > JP and Arthi have done a fine job of pulling together all of the threads of inter-area and > inter-AS solutions into a single draft. This gives us a single place to look for > information, but the resulting draft is (of course) quite large. As additional details > need to be filled in, it is clear that this draft would only grow and that would make it > unusably large. > > So, we are proposing to use the material in the draft to produce a series of detailed > drafts that would, over time, replace JP and Arthi's document. > > 1. Framework for Interdomain MPLS and GMPLS > A short draft that introduces the routing and signaling options > for multi-domain LSPs, and explains the options for path > computation. > This does not describe applicability or any necessary protocol > procedures or extensions. > Material will be taken from draft-vasseur-ccamp-inter-area-as-te > and draft-kompella-mpls-multiarea-te as required. > Authors: Adrian, JP, Arthi > Due date: End of April. is there an intention to take the tewg requirement documents into account at some in time within the first step of the process ? or are these documents their to assess solutions at the end of the process (at step 4, and further, in particular 6) > 2. Individual signaling extension drafts > If any one of the signaling approaches described in 1. > requires additional protocol procedures or extensions > then a single draft will be written for each. > The base assumption is that such a draft will only be > written if there someone planning to implement and > deploy. can we make clear that mechanisms are expected to differentiate inter-area vs inter-as only as part of point 4 (applicability) ie it is part of the task to provide generic signaling protocol extensions & procedures - as far as i see some of them will be part of the last step - > Authors: Dependent on extension > Due date: Aim for San Diego > > 3. Individual routing extension drafts > There are two dimensions to this: > - the different routing protocols (IGPs and EGPs) > - the different solution models > The aim should be to have one draft per protocol to provide the > generic mechanisms, and one draft per model per protocol to > provide procedures and field values etc. do you mean one generic document (per solution model) and one document per protocol or something else ? > Note that path computation functions are described under point > 5, below. > As with the signaling extensions, this work will only be done once > we understand that there is a need *and* what is needed. > Authors: Again dependent on deployment plans > Due date: Slightly later than signaling work > > 4. Applicability > A draft to explain when it is appropriate to use which model and > options. The aim is not to rubbish the opposition, but to say when > a particular model can/should be used. > Much of this material can already be found in > draft-vasseur-ccamp-inter-area-as-te, but it may need > some tidying up. > For political/expediency reasons this may result in multiple > applicability drafts in the first instance. > Authors: A supporter of each model > Due date: Quite soon - to accompany signaling extensions. if these reasons are verified, imho this should be part of each specific solution model/option document (if included into an appropriate section(s)), in order to avoid duplicating the number of documents that at the end should be put together in a single document that would include applicability of signaling (routing if any) procedure/ extensions and this due to the interaction aspects > 5. Path computation > Some solution models call for a (or many) path computation > servers (PCS). This demands several functions: > - discovery of PCS by network elements > - communication protocol between PCS and network elements > - some regulation of computation technique to avoid looping etc. > At the moment we are discussing precisely where this work should > be done, but that should not stop us starting the work within CCAMP > since it is clearly related to the inter-area/AS solution. and communication between PCSs once you have more than one PCS (~ sc.2 & and sc.4 of draft-kompella) > 6. Advanced functions. > There are several advanced functions that will be required, but which > are not part of the immediate work. > - Path reoptimization > - Protection path diversity > - crankback > We expect that once the initial work has been done on the solutions, it > will be possible to set out the requirements for these functions and to > develop solutions based on the many drafts that are already out there. i see that you didn't include any specific timeframe for this one (probably wiser) but would it be possible to have a rough estimation when you think these could be considered (as crankback started since quite a few months as w-g item) thanks, - dimitri. > Comments please. > > Thanks, > Adrian and Kireeti > > -- Papadimitriou Dimitri E-mail : dimitri.papadimitriou@alcatel.be E-mail : dpapadimitriou@psg.com Webpage: http://psg.com/~dpapadimitriou/ Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium Phone : +32 3 240-8491 From owner-ccamp@ops.ietf.org Fri Apr 16 13:40:16 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23646 for ; Fri, 16 Apr 2004 13:40:16 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BEXK4-0006zJ-6I for ccamp-archive@ietf.org; Fri, 16 Apr 2004 13:40:16 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEXJ8-0006uw-00 for ccamp-archive@ietf.org; Fri, 16 Apr 2004 13:39:19 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BEXIE-0006qw-00 for ccamp-archive@ietf.org; Fri, 16 Apr 2004 13:38:22 -0400 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BEX2X-000BPe-MA for ccamp-data@psg.com; Fri, 16 Apr 2004 17:22:09 +0000 Received: from [66.163.168.184] (helo=smtp805.mail.sc5.yahoo.com) by psg.com with smtp (Exim 4.30; FreeBSD) id 1BEX2V-000BPC-T1 for ccamp@ops.ietf.org; Fri, 16 Apr 2004 17:22:07 +0000 Received: from unknown (HELO RAKHILAPTOP) (vishal.sharma@sbcglobal.net@67.117.150.228 with login) by smtp805.mail.sc5.yahoo.com with SMTP; 16 Apr 2004 17:22:07 -0000 Reply-To: From: "Vishal Sharma" To: "CCAMP" Cc: "Fabio Ricciato" , "Alessio D'Achille" , "Ugo Monaco" Subject: Feedback on draft-dachille-inter-area-path-protection-01.txt Date: Fri, 16 Apr 2004 10:21:56 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Folks, During the Seoul meeting, we received a lot of useful feedback and inputs on our draft that we have now had time to consolidate and discuss amongst ourselves. Thanks to Jean-Louis, Aarthi, Adrian, Stefaan, JP, Zafar, Dmitri, and Richard for their excellent inputs. To have a fruitful discussion of the comments, we will soon send a summary of the comments on the ML, to help confirm that we captured everyone's comments accurately, and to help the WG at large appreciate the subsequent discussions (and contribute to it!). Comments from others who have feedback are welcome, and much appreciated. Thanks, -Vishal From owner-ccamp@ops.ietf.org Fri Apr 16 14:56:23 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27504 for ; Fri, 16 Apr 2004 14:56:23 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BEYVj-0005Iv-Ql for ccamp-archive@ietf.org; Fri, 16 Apr 2004 14:56:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEYUs-0005Ep-00 for ccamp-archive@ietf.org; Fri, 16 Apr 2004 14:55:31 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BEYUP-0005AJ-00 for ccamp-archive@ietf.org; Fri, 16 Apr 2004 14:55:01 -0400 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BEYGL-0006fu-Br for ccamp-data@psg.com; Fri, 16 Apr 2004 18:40:29 +0000 Received: from [66.163.168.186] (helo=smtp807.mail.sc5.yahoo.com) by psg.com with smtp (Exim 4.30; FreeBSD) id 1BEYGH-0006ei-Cu for ccamp@ops.ietf.org; Fri, 16 Apr 2004 18:40:25 +0000 Received: from unknown (HELO RAKHILAPTOP) (vishal.sharma@sbcglobal.net@67.117.151.73 with login) by smtp807.mail.sc5.yahoo.com with SMTP; 16 Apr 2004 18:40:23 -0000 Reply-To: From: "Vishal Sharma" To: "Adrian Farrel" , , "Kireeti Kompella" Cc: "Arthi Ayyangar" , "Jean-Philippe Vasseur" Subject: RE: Proposed strategy for Inter-area/AS Date: Fri, 16 Apr 2004 11:40:12 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <02a601c42217$0b13dda0$60849ed9@Puppy> Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Hi Adrian and Kireeti, Thanks for outlining the strategy for this important work item, which I think is well-laid out. Since some of the functions (e.g. diverse path computation, crankback, etc.) are quite closely tied to the signaling and routing extensions needed, I think they should not be decoupled from discussions of these extensions. So the ordering below probably needs to be modified a bit to reflect this coupling. Some further comments/questions and suggestions in-line. -Vishal > -----Original Message----- > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On > Behalf Of Adrian Farrel > Sent: Wednesday, April 14, 2004 4:50 AM > To: ccamp@ops.ietf.org > Subject: Proposed strategy for Inter-area/AS > > > All, > > JP and Arthi have done a fine job of pulling together all of the > threads of inter-area and > inter-AS solutions into a single draft. This gives us a single > place to look for > information, but the resulting draft is (of course) quite large. > As additional details > need to be filled in, it is clear that this draft would only grow > and that would make it > unusably large. > > So, we are proposing to use the material in the draft to produce > a series of detailed > drafts that would, over time, replace JP and Arthi's document. > > 1. Framework for Interdomain MPLS and GMPLS > A short draft that introduces the routing and signaling options > for multi-domain LSPs, and explains the options for path > computation. > This does not describe applicability or any necessary protocol > procedures or extensions. > Material will be taken from draft-vasseur-ccamp-inter-area-as-te > and draft-kompella-mpls-multiarea-te as required. > Authors: Adrian, JP, Arthi > Due date: End of April. As I mentioned at Seoul, I will be happy to help here. Particularly, with adding some material on options for diverse path computation. The current draft-vasseur-ccamp lists two options, but a hybrid that involves partial path computation in each domain (along the lines of what I presented at Seoul) is also possible, and can be a useful tradeoff for meeting several of the requirements listed in the corresponding requirements drafts. Also, I am assuming that the TE requirements documents will be the guiding documents in presenting options for routing/signaling and path computation in the above doc. I think it is important that the framework draft be in synch. with the requirements documents, rather than applying them only for 4 and 6. > 2. Individual signaling extension drafts > If any one of the signaling approaches described in 1. > requires additional protocol procedures or extensions > then a single draft will be written for each. > The base assumption is that such a draft will only be > written if there someone planning to implement and > deploy. > Authors: Dependent on extension > Due date: Aim for San Diego Please see initial note, about relation to other functions. > 3. Individual routing extension drafts > There are two dimensions to this: > - the different routing protocols (IGPs and EGPs) > - the different solution models > The aim should be to have one draft per protocol to provide the > generic mechanisms, and one draft per model per protocol to > provide procedures and field values etc. > Note that path computation functions are described under point > 5, below. > As with the signaling extensions, this work will only be done once > we understand that there is a need *and* what is needed. > Authors: Again dependent on deployment plans > Due date: Slightly later than signaling work Please see initial note, about relation to other functions. Also, when you say "solution models" above, do you mean things like a centralized versus a distributed model? What other models did you have in mind? > 4. Applicability > A draft to explain when it is appropriate to use which model and > options. The aim is not to rubbish the opposition, but to say when > a particular model can/should be used. > Much of this material can already be found in > draft-vasseur-ccamp-inter-area-as-te, but it may need > some tidying up. > For political/expediency reasons this may result in multiple > applicability drafts in the first instance. > Authors: A supporter of each model > Due date: Quite soon - to accompany signaling extensions. > > 5. Path computation > Some solution models call for a (or many) path computation > servers (PCS). This demands several functions: > - discovery of PCS by network elements > - communication protocol between PCS and network elements > - some regulation of computation technique to avoid looping etc. > At the moment we are discussing precisely where this work should > be done, but that should not stop us starting the work within CCAMP > since it is clearly related to the inter-area/AS solution. Is the discussion referred to above about where the PCS model should be done, or is it about path computation in general. Will the other path computation models will be discussed within CCAMP? > 6. Advanced functions. > There are several advanced functions that will be required, but which > are not part of the immediate work. > - Path reoptimization > - Protection path diversity > - crankback > We expect that once the initial work has been done on the > solutions, it > will be possible to set out the requirements for these > functions and to > develop solutions based on the many drafts that are already > out there. As I said earlier, some of these functions are coupled to the signaling and routing extensions, so it would be useful to discuss the signaling and routing extensions keeping some of these functions in mind. Otherwise, we run the risk of developing signaling and routing extensions first, and then retro-fitting them to accommodate such functions, which I think are pretty key to inter-domain TE. From owner-ccamp@ops.ietf.org Fri Apr 16 16:23:25 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05148 for ; Fri, 16 Apr 2004 16:23:25 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BEZry-0004dq-9r for ccamp-archive@ietf.org; Fri, 16 Apr 2004 16:23:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEZqz-0004WV-00 for ccamp-archive@ietf.org; Fri, 16 Apr 2004 16:22:27 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BEZq4-0004O6-00 for ccamp-archive@ietf.org; Fri, 16 Apr 2004 16:21:28 -0400 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BEZdR-0005cv-Q8 for ccamp-data@psg.com; Fri, 16 Apr 2004 20:08:25 +0000 Received: from [195.8.69.53] (helo=zephir.uk.clara.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BEZdP-0005cg-Vn for ccamp@ops.ietf.org; Fri, 16 Apr 2004 20:08:24 +0000 Received: from du-069-0432.access.clara.net ([217.158.145.178] helo=Puppy) by zephir.uk.clara.net with smtp (Exim 4.22) id 1BEZdN-0007k5-6T; Fri, 16 Apr 2004 21:08:21 +0100 Message-ID: <018801c423ee$92dca9a0$83919ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: , Cc: "Arthi Ayyangar" , "Jean-Philippe Vasseur" , "Kireeti Kompella" References: Subject: Re: Proposed strategy for Inter-area/AS Date: Fri, 16 Apr 2004 20:56:48 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Hi Vishal, Thanks for your useful comments. Yes, clearly we need to consider all requirements as we move forward, but at the same time looking for a single solution that does everything is often the kiss of death in the IETF. So the first thing I want to do (in the framework) is set out the different basic models for signaling, routing and computation. Then there is a bit of a hiatus while the proponents of the different models work out what solutions they need and what their applicability is - at this stage I would expect (since diverse paths are a requirement) that you will find your self working with one or more of the solution groups. Similarly, the other drafts that provide extensions that may be useful will also (or not) be called on. One thing the framework does not do is list all of the available bits and pieces. Nor does it make any statements about what should or should not be done to provide a solution. You may be right that adding a little more text on diverse computation models will help since this will impact the choice of basic model, but I don't think it introduces any mode basic models. We will take you up on your offer of a contribution to the document as soon as we have got the first version done. On PCE... We are open to discussions both about whether PCE should be done, and how it should be done. On TEWG requirements... Obviously we take our base requirements from the TEWG documents. Hope this clarifies. Adrian ----- Original Message ----- From: "Vishal Sharma" To: "Adrian Farrel" ; ; "Kireeti Kompella" Cc: "Arthi Ayyangar" ; "Jean-Philippe Vasseur" Sent: Friday, April 16, 2004 7:40 PM Subject: RE: Proposed strategy for Inter-area/AS > Hi Adrian and Kireeti, > > Thanks for outlining the strategy for this important work > item, which I think is well-laid out. > > Since some of the functions (e.g. diverse path computation, crankback, > etc.) are quite closely tied to the signaling and routing extensions needed, > I think they should not be decoupled from discussions of these extensions. > So the ordering below probably needs to be modified a bit to reflect this > coupling. > > Some further comments/questions and suggestions in-line. > > -Vishal > > > -----Original Message----- > > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On > > Behalf Of Adrian Farrel > > Sent: Wednesday, April 14, 2004 4:50 AM > > To: ccamp@ops.ietf.org > > Subject: Proposed strategy for Inter-area/AS > > > > > > All, > > > > JP and Arthi have done a fine job of pulling together all of the > > threads of inter-area and > > inter-AS solutions into a single draft. This gives us a single > > place to look for > > information, but the resulting draft is (of course) quite large. > > As additional details > > need to be filled in, it is clear that this draft would only grow > > and that would make it > > unusably large. > > > > So, we are proposing to use the material in the draft to produce > > a series of detailed > > drafts that would, over time, replace JP and Arthi's document. > > > > 1. Framework for Interdomain MPLS and GMPLS > > A short draft that introduces the routing and signaling options > > for multi-domain LSPs, and explains the options for path > > computation. > > This does not describe applicability or any necessary protocol > > procedures or extensions. > > Material will be taken from draft-vasseur-ccamp-inter-area-as-te > > and draft-kompella-mpls-multiarea-te as required. > > Authors: Adrian, JP, Arthi > > Due date: End of April. > > As I mentioned at Seoul, I will be happy to help here. Particularly, > with adding some material on options for diverse path computation. > The current draft-vasseur-ccamp lists two options, but a hybrid > that involves partial path computation in each domain (along the > lines of what I presented at Seoul) is also possible, and can be a > useful tradeoff for meeting several of the requirements listed > in the corresponding requirements drafts. > > Also, I am assuming that the TE requirements documents will be > the guiding documents in presenting options for routing/signaling > and path computation in the above doc. I think it is important > that the framework draft be in synch. with the requirements documents, > rather than applying them only for 4 and 6. > > > 2. Individual signaling extension drafts > > If any one of the signaling approaches described in 1. > > requires additional protocol procedures or extensions > > then a single draft will be written for each. > > The base assumption is that such a draft will only be > > written if there someone planning to implement and > > deploy. > > Authors: Dependent on extension > > Due date: Aim for San Diego > > Please see initial note, about relation to other functions. > > > 3. Individual routing extension drafts > > There are two dimensions to this: > > - the different routing protocols (IGPs and EGPs) > > - the different solution models > > The aim should be to have one draft per protocol to provide the > > generic mechanisms, and one draft per model per protocol to > > provide procedures and field values etc. > > Note that path computation functions are described under point > > 5, below. > > As with the signaling extensions, this work will only be done once > > we understand that there is a need *and* what is needed. > > Authors: Again dependent on deployment plans > > Due date: Slightly later than signaling work > > Please see initial note, about relation to other functions. > > Also, when you say "solution models" above, do you mean things > like a centralized versus a distributed model? What other > models did you have in mind? > > > 4. Applicability > > A draft to explain when it is appropriate to use which model and > > options. The aim is not to rubbish the opposition, but to say when > > a particular model can/should be used. > > Much of this material can already be found in > > draft-vasseur-ccamp-inter-area-as-te, but it may need > > some tidying up. > > For political/expediency reasons this may result in multiple > > applicability drafts in the first instance. > > Authors: A supporter of each model > > Due date: Quite soon - to accompany signaling extensions. > > > > 5. Path computation > > Some solution models call for a (or many) path computation > > servers (PCS). This demands several functions: > > - discovery of PCS by network elements > > - communication protocol between PCS and network elements > > - some regulation of computation technique to avoid looping etc. > > At the moment we are discussing precisely where this work should > > be done, but that should not stop us starting the work within CCAMP > > since it is clearly related to the inter-area/AS solution. > > Is the discussion referred to above about where the PCS model should > be done, or is it about path computation in general. > > Will the other path computation models will be discussed within > CCAMP? > > > > 6. Advanced functions. > > There are several advanced functions that will be required, but which > > are not part of the immediate work. > > - Path reoptimization > > - Protection path diversity > > - crankback > > We expect that once the initial work has been done on the > > solutions, it > > will be possible to set out the requirements for these > > functions and to > > develop solutions based on the many drafts that are already > > out there. > > As I said earlier, some of these functions are coupled to the signaling and > routing extensions, so it would be useful to discuss the signaling and > routing extensions keeping some of these functions in mind. > Otherwise, we run the risk of developing signaling and routing extensions > first, and then retro-fitting them to accommodate such functions, which > I think are pretty key to inter-domain TE. From owner-ccamp@ops.ietf.org Fri Apr 16 16:49:23 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07872 for ; Fri, 16 Apr 2004 16:49:23 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BEaH6-0007Nv-Cc for ccamp-archive@ietf.org; Fri, 16 Apr 2004 16:49:24 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEaGD-0007LF-00 for ccamp-archive@ietf.org; Fri, 16 Apr 2004 16:48:29 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BEaFm-0007Jg-00 for ccamp-archive@ietf.org; Fri, 16 Apr 2004 16:48:02 -0400 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BEa33-000Ctl-L3 for ccamp-data@psg.com; Fri, 16 Apr 2004 20:34:53 +0000 Received: from [66.163.168.187] (helo=smtp808.mail.sc5.yahoo.com) by psg.com with smtp (Exim 4.30; FreeBSD) id 1BEa32-000CtD-Km for ccamp@ops.ietf.org; Fri, 16 Apr 2004 20:34:52 +0000 Received: from unknown (HELO RAKHILAPTOP) (vishal.sharma@sbcglobal.net@63.202.176.211 with login) by smtp808.mail.sc5.yahoo.com with SMTP; 16 Apr 2004 20:34:52 -0000 Reply-To: From: "Vishal Sharma" To: "CCAMP" Cc: "Richard Rabbat" , "Toshio Soumiya" , "Shinoya Kanoh" , "Fabio Ricciato" , "Roberto Albanese" , Subject: Status of "Implementation and Perf. of Flooding-based Fault Notification" Date: Fri, 16 Apr 2004 13:34:40 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Dear CCAMPers, This draft was prepared following extensive discussions with several people during the Minneapolis IETF, as a way to share some of our implementation experience with the community. Unfortunately, this was one of the many "missing drafts" just before Seoul, and was posted by the IETF Secretariat at the end of February, so we did not have an opportunity to discuss this during the CCAMP WG meeting. http://www.ietf.org/internet-drafts/draft-rabbat-ccamp-perf-flooding-notific ation-exp-00.txt So, we would like to solicit feedback and inputs now. Basically, the draft highlights the results from deploying flooding-based notification in two independent testbeds, at the transport and packet layers. We have made the draft complete and self-contained, by having it present not only the experiences and actual performance measurements from these implementations on FreeBSD/Linux platforms, but also the protocol enhancements, object formats, etc. that were made to LMP and OSPF, respectively, to realize the rapid flooding function. In this way, we believe the observations, results, and formats in the draft serve as a very useful repository of information related to restoration techniques/issues. Our objective is to progress this as an experimental document, to make the experiences & results from these testbeds available to the IETF/CCAMP community. Comments/inputs very welcome! Thanks, -Vishal From owner-ccamp@ops.ietf.org Fri Apr 16 18:09:33 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13814 for ; Fri, 16 Apr 2004 18:09:33 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BEbWg-00058r-RL for ccamp-archive@ietf.org; Fri, 16 Apr 2004 18:09:34 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEbVp-000568-00 for ccamp-archive@ietf.org; Fri, 16 Apr 2004 18:08:42 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BEbVG-00052h-00 for ccamp-archive@ietf.org; Fri, 16 Apr 2004 18:08:07 -0400 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BEbLB-000FXg-VF for ccamp-data@psg.com; Fri, 16 Apr 2004 21:57:41 +0000 Received: from [171.71.176.71] (helo=sj-iport-2.cisco.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BEbLA-000FWs-EU for ccamp@ops.ietf.org; Fri, 16 Apr 2004 21:57:40 +0000 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 16 Apr 2004 14:07:16 +0000 Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i3GLvc7t004466; Fri, 16 Apr 2004 14:57:38 -0700 (PDT) Received: from jvasseur-w2k01.cisco.com (che-vpn-cluster-1-123.cisco.com [10.86.240.123]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id OAA17107; Fri, 16 Apr 2004 14:57:36 -0700 (PDT) Message-Id: <4.3.2.7.2.20040416174900.06190ec8@wells.cisco.com> X-Sender: jvasseur@wells.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 16 Apr 2004 17:57:35 -0400 To: From: Jean Philippe Vasseur Subject: RE: Proposed strategy for Inter-area/AS Cc: "Adrian Farrel" , , "Kireeti Kompella" , "Arthi Ayyangar" In-Reply-To: References: <02a601c42217$0b13dda0$60849ed9@Puppy> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Hi Vishal, At 11:40 AM 4/16/2004 -0700, Vishal Sharma wrote: >Hi Adrian and Kireeti, > >Thanks for outlining the strategy for this important work >item, which I think is well-laid out. > >Since some of the functions (e.g. diverse path computation, crankback, >etc.) are quite closely tied to the signaling and routing extensions needed, >I think they should not be decoupled from discussions of these extensions. Sure, path diversity is a requirement listed in the requirement draft >So the ordering below probably needs to be modified a bit to reflect this >coupling. > >Some further comments/questions and suggestions in-line. > >-Vishal > > > -----Original Message----- > > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On > > Behalf Of Adrian Farrel > > Sent: Wednesday, April 14, 2004 4:50 AM > > To: ccamp@ops.ietf.org > > Subject: Proposed strategy for Inter-area/AS > > > > > > All, > > > > JP and Arthi have done a fine job of pulling together all of the > > threads of inter-area and > > inter-AS solutions into a single draft. This gives us a single > > place to look for > > information, but the resulting draft is (of course) quite large. > > As additional details > > need to be filled in, it is clear that this draft would only grow > > and that would make it > > unusably large. > > > > So, we are proposing to use the material in the draft to produce > > a series of detailed > > drafts that would, over time, replace JP and Arthi's document. > > > > 1. Framework for Interdomain MPLS and GMPLS > > A short draft that introduces the routing and signaling options > > for multi-domain LSPs, and explains the options for path > > computation. > > This does not describe applicability or any necessary protocol > > procedures or extensions. > > Material will be taken from draft-vasseur-ccamp-inter-area-as-te > > and draft-kompella-mpls-multiarea-te as required. > > Authors: Adrian, JP, Arthi > > Due date: End of April. > >As I mentioned at Seoul, I will be happy to help here. Particularly, >with adding some material on options for diverse path computation. >The current draft-vasseur-ccamp lists two options, but a hybrid >that involves partial path computation in each domain (along the >lines of what I presented at Seoul) is also possible, and can be a >useful tradeoff for meeting several of the requirements listed >in the corresponding requirements drafts. > >Also, I am assuming that the TE requirements documents will be >the guiding documents in presenting options for routing/signaling >and path computation in the above doc. I think it is important >that the framework draft be in synch. with the requirements documents, >rather than applying them only for 4 and 6. Sure, But I guess that the solution that you propose to compute path diversity is one among others. Indeed, there are two path computation solutions proposed in draft-vasseur-ccamp-inter-area-as-te that both support path diversity computation: (1) Per-area/AS in combination with EXCLUDE-OBJECT (2) Distributed PCE-based approach which compute end to end shortest path that can also easily support diversity path computation with a high granularity Whether a third method can of course be debated. Cheers JP. > > 2. Individual signaling extension drafts > > If any one of the signaling approaches described in 1. > > requires additional protocol procedures or extensions > > then a single draft will be written for each. > > The base assumption is that such a draft will only be > > written if there someone planning to implement and > > deploy. > > Authors: Dependent on extension > > Due date: Aim for San Diego > >Please see initial note, about relation to other functions. > > 3. Individual routing extension drafts > > There are two dimensions to this: > > - the different routing protocols (IGPs and EGPs) > > - the different solution models > > The aim should be to have one draft per protocol to provide the > > generic mechanisms, and one draft per model per protocol to > > provide procedures and field values etc. > > Note that path computation functions are described under point > > 5, below. > > As with the signaling extensions, this work will only be done once > > we understand that there is a need *and* what is needed. > > Authors: Again dependent on deployment plans > > Due date: Slightly later than signaling work > >Please see initial note, about relation to other functions. > >Also, when you say "solution models" above, do you mean things >like a centralized versus a distributed model? What other >models did you have in mind? > > > 4. Applicability > > A draft to explain when it is appropriate to use which model and > > options. The aim is not to rubbish the opposition, but to say when > > a particular model can/should be used. > > Much of this material can already be found in > > draft-vasseur-ccamp-inter-area-as-te, but it may need > > some tidying up. > > For political/expediency reasons this may result in multiple > > applicability drafts in the first instance. > > Authors: A supporter of each model > > Due date: Quite soon - to accompany signaling extensions. > > > > 5. Path computation > > Some solution models call for a (or many) path computation > > servers (PCS). This demands several functions: > > - discovery of PCS by network elements > > - communication protocol between PCS and network elements > > - some regulation of computation technique to avoid looping etc. > > At the moment we are discussing precisely where this work should > > be done, but that should not stop us starting the work within CCAMP > > since it is clearly related to the inter-area/AS solution. > >Is the discussion referred to above about where the PCS model should >be done, or is it about path computation in general. > >Will the other path computation models will be discussed within >CCAMP? > > > > 6. Advanced functions. > > There are several advanced functions that will be required, but which > > are not part of the immediate work. > > - Path reoptimization > > - Protection path diversity > > - crankback > > We expect that once the initial work has been done on the > > solutions, it > > will be possible to set out the requirements for these > > functions and to > > develop solutions based on the many drafts that are already > > out there. > >As I said earlier, some of these functions are coupled to the signaling and >routing extensions, so it would be useful to discuss the signaling and >routing extensions keeping some of these functions in mind. >Otherwise, we run the risk of developing signaling and routing extensions >first, and then retro-fitting them to accommodate such functions, which >I think are pretty key to inter-domain TE. From owner-ccamp@ops.ietf.org Fri Apr 16 19:12:27 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18669 for ; Fri, 16 Apr 2004 19:12:27 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BEcVW-0001kl-EL for ccamp-archive@ietf.org; Fri, 16 Apr 2004 19:12:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEcUf-0001jH-00 for ccamp-archive@ietf.org; Fri, 16 Apr 2004 19:11:34 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BEcTy-0001h5-00 for ccamp-archive@ietf.org; Fri, 16 Apr 2004 19:10:50 -0400 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BEcFM-0008Gk-5w for ccamp-data@psg.com; Fri, 16 Apr 2004 22:55:44 +0000 Received: from [66.163.168.182] (helo=smtp803.mail.sc5.yahoo.com) by psg.com with smtp (Exim 4.30; FreeBSD) id 1BEcFL-0008GX-2Q for ccamp@ops.ietf.org; Fri, 16 Apr 2004 22:55:43 +0000 Received: from unknown (HELO RAKHILAPTOP) (vishal.sharma@sbcglobal.net@67.117.148.148 with login) by smtp803.mail.sc5.yahoo.com with SMTP; 16 Apr 2004 22:55:42 -0000 Reply-To: From: "Vishal Sharma" To: "Jean Philippe Vasseur" Cc: "Adrian Farrel" , , "Kireeti Kompella" , "Arthi Ayyangar" Subject: RE: Proposed strategy for Inter-area/AS Date: Fri, 16 Apr 2004 15:55:29 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <4.3.2.7.2.20040416174900.06190ec8@wells.cisco.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Hi JP, Thanks much for your comments. Response in-line. > -----Original Message----- > From: Jean Philippe Vasseur [mailto:jvasseur@cisco.com] > Sent: Friday, April 16, 2004 2:58 PM > To: v.sharma@ieee.org > Cc: Adrian Farrel; ccamp@ops.ietf.org; Kireeti Kompella; Arthi Ayyangar > Subject: RE: Proposed strategy for Inter-area/AS > > > > > > > > 1. Framework for Interdomain MPLS and GMPLS > > > A short draft that introduces the routing and signaling options > > > for multi-domain LSPs, and explains the options for path > > > computation. > > > This does not describe applicability or any necessary protocol > > > procedures or extensions. > > > Material will be taken from draft-vasseur-ccamp-inter-area-as-te > > > and draft-kompella-mpls-multiarea-te as required. > > > Authors: Adrian, JP, Arthi > > > Due date: End of April. > > > >As I mentioned at Seoul, I will be happy to help here. Particularly, > >with adding some material on options for diverse path computation. > >The current draft-vasseur-ccamp lists two options, but a hybrid > >that involves partial path computation in each domain (along the > >lines of what I presented at Seoul) is also possible, and can be a > >useful tradeoff for meeting several of the requirements listed > >in the corresponding requirements drafts. > > > >Also, I am assuming that the TE requirements documents will be > >the guiding documents in presenting options for routing/signaling > >and path computation in the above doc. I think it is important > >that the framework draft be in synch. with the requirements documents, > >rather than applying them only for 4 and 6. > > Sure, > > But I guess that the solution that you propose to compute path > diversity is > one among others. Indeed, there are two path computation > solutions proposed > in draft-vasseur-ccamp-inter-area-as-te that both support path diversity > computation: > (1) Per-area/AS in combination with EXCLUDE-OBJECT > (2) Distributed PCE-based approach which compute end to end > shortest path that can also easily support diversity path computation with > a high granularity > > Whether a third method can of course be debated. Actually, the way I see it, there are I believe 4 basic ways to perform path (and diverse path) computation, which we can break down as follows. (Diverse) Path Computation Methods | | | +-----------------------------+ | | | | Centralized Distributed (Global) | | | +-----+------+ +---+--------------+ | | | | Parallel Sequential Parallel Sequential Joint path 1st path, 2nd path Per-domain 1st path, 2nd path computation ... path selection ... (semi-global) -PCE-based -Head-end based ] or PCS-based -PCE-based -Using XRO ] Approaches ] -Head-end or -draft-dachille based ] server-based The various current approaches/solutions to perform path computation may be classified under one of the 4 heads, as I have done above. I called solution we proposed in draft-dachille (and that I presented in Seoul) a hybrid for computing diverse paths, because it can compute end-to-end diverse paths like in the PCE approach, with the simplicity of the per-domain approach, and essentially without any changes to the signaling protocols (save for an ERO-formatted ARO obj.), which is a requirement stated in the inter-area/AS TE requirements drafts. Thus, I believe this solution (not the specific realization presented in draft-dachille, but rather the basic idea) is worth mentioning in the interdomain TE framework document. Best, -Vishal From owner-ccamp@ops.ietf.org Fri Apr 16 19:21:41 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19278 for ; Fri, 16 Apr 2004 19:21:41 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BEceT-0002It-E2 for ccamp-archive@ietf.org; Fri, 16 Apr 2004 19:21:41 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEcdZ-0002Ff-00 for ccamp-archive@ietf.org; Fri, 16 Apr 2004 19:20:46 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BEcd5-0002Ay-00 for ccamp-archive@ietf.org; Fri, 16 Apr 2004 19:20:15 -0400 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BEcRJ-000Cdq-54 for ccamp-data@psg.com; Fri, 16 Apr 2004 23:08:05 +0000 Received: from [66.163.170.80] (helo=smtp810.mail.sc5.yahoo.com) by psg.com with smtp (Exim 4.30; FreeBSD) id 1BEcRH-000Cda-Rh for ccamp@ops.ietf.org; Fri, 16 Apr 2004 23:08:03 +0000 Received: from unknown (HELO RAKHILAPTOP) (vishal.sharma@sbcglobal.net@67.117.149.181 with login) by smtp810.mail.sc5.yahoo.com with SMTP; 16 Apr 2004 23:08:03 -0000 Reply-To: From: "Vishal Sharma" To: "Jean-Philippe Vasseur" Cc: "Adrian Farrel" , "Arthi Ayyangar" , "Kireeti Kompella" , "CCAMP" Subject: RE: Proposed strategy for Inter-area/AS (corrected) Date: Fri, 16 Apr 2004 16:07:50 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Hi JP, Thanks much for your comments. Response in-line. (Please ignore the previous message, as the ASCII figure got distorted in that one.) > -----Original Message----- > From: Jean Philippe Vasseur [mailto:jvasseur@cisco.com] > Sent: Friday, April 16, 2004 2:58 PM > To: v.sharma@ieee.org > Cc: Adrian Farrel; ccamp@ops.ietf.org; Kireeti Kompella; Arthi Ayyangar > Subject: RE: Proposed strategy for Inter-area/AS > > > > > > > > 1. Framework for Interdomain MPLS and GMPLS > > > A short draft that introduces the routing and signaling options > > > for multi-domain LSPs, and explains the options for path > > > computation. > > > This does not describe applicability or any necessary protocol > > > procedures or extensions. > > > Material will be taken from draft-vasseur-ccamp-inter-area-as-te > > > and draft-kompella-mpls-multiarea-te as required. > > > Authors: Adrian, JP, Arthi > > > Due date: End of April. > > > >As I mentioned at Seoul, I will be happy to help here. Particularly, > >with adding some material on options for diverse path computation. > >The current draft-vasseur-ccamp lists two options, but a hybrid > >that involves partial path computation in each domain (along the > >lines of what I presented at Seoul) is also possible, and can be a > >useful tradeoff for meeting several of the requirements listed > >in the corresponding requirements drafts. > > > >Also, I am assuming that the TE requirements documents will be > >the guiding documents in presenting options for routing/signaling > >and path computation in the above doc. I think it is important > >that the framework draft be in synch. with the requirements documents, > >rather than applying them only for 4 and 6. > > Sure, > > But I guess that the solution that you propose to compute path > diversity is > one among others. Indeed, there are two path computation > solutions proposed > in draft-vasseur-ccamp-inter-area-as-te that both support path diversity > computation: > (1) Per-area/AS in combination with EXCLUDE-OBJECT > (2) Distributed PCE-based approach which compute end to end > shortest path that can also easily support diversity path computation with > a high granularity > > Whether a third method can of course be debated. Actually, the way I see it, there are I believe 4 basic ways to perform path (and diverse path) computation, which we can break down as follows. (Diverse) Path Computation Methods | | | +-----------------------------+ | | | | Centralized Distributed (Global) | | | +-----+------+ +---+--------------+ | | | | Parallel Sequential Parallel Sequential Joint path 1st path, 2nd path Per-domain 1st path, 2nd path computation ... path selection ... | | (semi-global) | | | | | | | | | Approaches | | | | ----------- -PCE-based -Head-end based | | ] or PCS-based -PCE-based -Using XRO ] ] -Head-end or -draft-dachille based ] server-based The various current approaches/solutions to perform path computation may be classified under one of the 4 heads, as I have done above. I called solution we proposed in draft-dachille (and that I presented in Seoul)a hybrid for computing diverse paths, because it can compute end-to-end diverse paths like in the PCE approach, with the simplicity of the per-domain approach,and essentially without any changes to the signaling protocols (save for an ERO-formatted ARO obj.), which is a requirement stated in the inter-area/AS TE requirements drafts. Thus, I believe this solution (not the specific realization presented in draft-dachille, but rather the basic idea) is worth mentioning in the interdomain TE framework document. Best, -Vishal From owner-ccamp@ops.ietf.org Sun Apr 18 03:40:45 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05823 for ; Sun, 18 Apr 2004 03:40:45 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BF6uy-0007Lh-SB for ccamp-archive@ietf.org; Sun, 18 Apr 2004 03:40:44 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BF6u1-0007C6-00 for ccamp-archive@ietf.org; Sun, 18 Apr 2004 03:39:45 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BF6ti-00072L-00 for ccamp-archive@ietf.org; Sun, 18 Apr 2004 03:39:26 -0400 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BF6Xn-0006bl-SS for ccamp-data@psg.com; Sun, 18 Apr 2004 07:16:47 +0000 Received: from [66.163.168.188] (helo=smtp809.mail.sc5.yahoo.com) by psg.com with smtp (Exim 4.30; FreeBSD) id 1BF6Xm-0006bR-KL for ccamp@ops.ietf.org; Sun, 18 Apr 2004 07:16:46 +0000 Received: from unknown (HELO RAKHILAPTOP) (vishal.sharma@sbcglobal.net@67.117.150.71 with login) by smtp809.mail.sc5.yahoo.com with SMTP; 18 Apr 2004 07:16:46 -0000 Reply-To: From: "Vishal Sharma" To: "CCAMP" Cc: "Jean-Louis Le Roux" , "Fabio Ricciato" , "Alessio D'Achille" , "Ugo Monaco" , "Marco Listanti" Subject: draft-dachille: Comments on topology summarization and optimality Date: Sun, 18 Apr 2004 00:16:42 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Hi JL, Thanks for your feedback on our draft/scheme during the Seoul IETF. As mentioned in an earlier email to the ML, before we address the various points made by folks who gave us their valuable feedback, we are summarizing their comments to ensure that (a) we rightly understood their inputs :-), and (b) to help people on the ML follow and contribute to the subsequent discussions. After reviewing my notes from our discussions and discussing them with my co-authors, I have summarized your comments as below. If I missed something or did not capture some of your questions/comments correctly, please do let us know. We will take this into account in providing our responses, and, later, in updating the document. Best regards, -Vishal ********************************************************************* Editorial: i) Replace "area" --> "region" throughout, since you cover ASs as well. ii) Note in the draft that the scheme is general and does more that merely helping with efficient backup path computation and setup. Technical: iii) The draft needs to make clear what is meant by a virtual topology, and what info. is used to create it. This is because it seems from a current reading of the draft that the virtual topology relies on info. about TE links and their bandwidth, but there is a strong requirement not to advertise TE link info. between areas. iv) How does this approach differ from the PCS/PCE approach? Some comparison and contrasting would be useful. v) You also suggested that one needn't be confined to carrying only one ARO. So for better optimality, one might carry multiple ARO's computed for the secondary path, and when the secondary is being set up, the ingress for the secondary could select one of the ARO segments for traversing it's area. This might lead to a more optimal setup than would otherwise be possible. vi) Sec. 4.1 on inter-area is ok. vii) However, for the section on inter-AS, you asked "how does the scheme computes the set of AS's that the diverse paths will use?" viii) Do you need the optical island ID? Even in the optical case, if one is using IP protocols, it is likely that OSFP/IS-IS areas/levels and ASs will be defined, so this then becomes the same as the inter-area/inter-AS cases. ix) Mention that the scheme can work for IS-IS levels as well. (Note IS-IS levels can, in turn, have areas.) (One issue here is how does one identify IS-IS levels?) From owner-ccamp@ops.ietf.org Sun Apr 18 03:47:42 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05977 for ; Sun, 18 Apr 2004 03:47:42 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BF71h-0000cV-9H for ccamp-archive@ietf.org; Sun, 18 Apr 2004 03:47:41 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BF70i-0000TE-00 for ccamp-archive@ietf.org; Sun, 18 Apr 2004 03:46:41 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BF70E-0000KE-00 for ccamp-archive@ietf.org; Sun, 18 Apr 2004 03:46:10 -0400 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BF6ia-0008bz-LG for ccamp-data@psg.com; Sun, 18 Apr 2004 07:27:56 +0000 Received: from [66.163.168.180] (helo=smtp801.mail.sc5.yahoo.com) by psg.com with smtp (Exim 4.30; FreeBSD) id 1BF6iZ-0008bm-Um for ccamp@ops.ietf.org; Sun, 18 Apr 2004 07:27:55 +0000 Received: from unknown (HELO RAKHILAPTOP) (vishal.sharma@sbcglobal.net@67.117.150.71 with login) by smtp801.mail.sc5.yahoo.com with SMTP; 18 Apr 2004 07:27:47 -0000 Reply-To: From: "Vishal Sharma" To: "CCAMP" , "Arthi Ayyangar" Cc: "Fabio Ricciato" , "Ugo Monaco" , "Alessio D'Achille" , "Marco Listanti" Subject: draft-dachille: Comments on CAC issues Date: Sun, 18 Apr 2004 00:27:43 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Hi Arthi, Thanks for your feedback on our draft/scheme during the Seoul IETF. As mentioned in the email to the ML and to JL, before addressing people's comments, we are summarizing them ensure that (a) we rightly understood the comments, and (b) to help people on the ML follow and contribute to the subsequent discussions. Upon looking at my notes from our discussions, I see that your main comments related to aspects of CAC in our scheme, and have summarized them below. Please let me know if you had any additional comments as well. We will take these into account in providing our responses, and, later, in updating the document. Best regards, -Vishal **************************************************************** i) What happens to bandwidth accounting during path set up? Since the border router that is the entry point for the primary path into an area/AS is the one that also computes the secondary path, how does bandwidth accounting work to minimize CAC failures during the actual setting up of the secondary? (Note that other nodes in the area would not immediately learn of the amount of bandwidth that primary and secondary paths have consumed.) ii) What happens if the diverse path setup fails due to a CAC failure? (Namely, the set up of the second path fails.) To what does the scheme default then? iii) If I recall correctly, you also had a comment on the security of such schemes. That is, the problem of hiding info. about one area from other (remote) areas. From owner-ccamp@ops.ietf.org Mon Apr 19 01:18:43 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA03849 for ; Mon, 19 Apr 2004 01:18:43 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFRB4-00062h-0G for ccamp-archive@ietf.org; Mon, 19 Apr 2004 01:18:42 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFRA7-0005pA-00 for ccamp-archive@ietf.org; Mon, 19 Apr 2004 01:17:44 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BFR9T-0005bk-00 for ccamp-archive@ietf.org; Mon, 19 Apr 2004 01:17:03 -0400 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BFQmz-000Nkl-1e for ccamp-data@psg.com; Mon, 19 Apr 2004 04:53:49 +0000 Received: from [66.163.168.179] (helo=smtp800.mail.sc5.yahoo.com) by psg.com with smtp (Exim 4.30; FreeBSD) id 1BFQmv-000NkL-D6 for ccamp@ops.ietf.org; Mon, 19 Apr 2004 04:53:45 +0000 Received: from unknown (HELO RAKHILAPTOP) (vishal.sharma@sbcglobal.net@63.206.92.0 with login) by smtp800.mail.sc5.yahoo.com with SMTP; 19 Apr 2004 04:53:44 -0000 Reply-To: From: "Vishal Sharma" To: "Adrian Farrel" , Cc: "Arthi Ayyangar" , "Jean-Philippe Vasseur" , "Kireeti Kompella" Subject: RE: Proposed strategy for Inter-area/AS Date: Sun, 18 Apr 2004 21:53:34 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <018801c423ee$92dca9a0$83919ed9@Puppy> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Adrian, Great, thanks for the clarifications. Since the framework takes its lead from the inter-area/AS requirements documents, I agree that it needn't say what a solution should provide (this should already be covered by the requirements docs.). For the diverse path computation aspect, please see my response to JP, where I've provided some elucidation. Personally, I think the PCS/PCE approach is a useful one, and should certainly be continued. And, I'll be glad to contribute, once the first version of the framework is done. -Vishal > -----Original Message----- > From: Adrian Farrel [mailto:adrian@olddog.co.uk] > Sent: Friday, April 16, 2004 12:57 PM > To: v.sharma@ieee.org; ccamp@ops.ietf.org > Cc: Arthi Ayyangar; Jean-Philippe Vasseur; Kireeti Kompella > Subject: Re: Proposed strategy for Inter-area/AS > > > Hi Vishal, > > Thanks for your useful comments. > > Yes, clearly we need to consider all requirements as we move > forward, but at the same time > looking for a single solution that does everything is often the > kiss of death in the IETF. > > So the first thing I want to do (in the framework) is set out the > different basic models > for signaling, routing and computation. Then there is a bit of a > hiatus while the > proponents of the different models work out what solutions they > need and what their > applicability is - at this stage I would expect (since diverse > paths are a requirement) > that you will find your self working with one or more of the > solution groups. Similarly, > the other drafts that provide extensions that may be useful will > also (or not) be called > on. > > One thing the framework does not do is list all of the available > bits and pieces. Nor does > it make any statements about what should or should not be done to > provide a solution. > > You may be right that adding a little more text on diverse > computation models will help > since this will impact the choice of basic model, but I don't > think it introduces any mode > basic models. > We will take you up on your offer of a contribution to the > document as soon as we have got > the first version done. > > On PCE... > We are open to discussions both about whether PCE should be done, > and how it should be > done. > > On TEWG requirements... > Obviously we take our base requirements from the TEWG documents. > > Hope this clarifies. > > Adrian > > ----- Original Message ----- > From: "Vishal Sharma" > To: "Adrian Farrel" ; ; > "Kireeti Kompella" > > Cc: "Arthi Ayyangar" ; "Jean-Philippe Vasseur" > > Sent: Friday, April 16, 2004 7:40 PM > Subject: RE: Proposed strategy for Inter-area/AS > > > > Hi Adrian and Kireeti, > > > > Thanks for outlining the strategy for this important work > > item, which I think is well-laid out. > > > > Since some of the functions (e.g. diverse path computation, crankback, > > etc.) are quite closely tied to the signaling and routing > extensions needed, > > I think they should not be decoupled from discussions of these > extensions. > > So the ordering below probably needs to be modified a bit to > reflect this > > coupling. > > > > Some further comments/questions and suggestions in-line. > > > > -Vishal > > > > > -----Original Message----- > > > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On > > > Behalf Of Adrian Farrel > > > Sent: Wednesday, April 14, 2004 4:50 AM > > > To: ccamp@ops.ietf.org > > > Subject: Proposed strategy for Inter-area/AS > > > > > > > > > All, > > > > > > JP and Arthi have done a fine job of pulling together all of the > > > threads of inter-area and > > > inter-AS solutions into a single draft. This gives us a single > > > place to look for > > > information, but the resulting draft is (of course) quite large. > > > As additional details > > > need to be filled in, it is clear that this draft would only grow > > > and that would make it > > > unusably large. > > > > > > So, we are proposing to use the material in the draft to produce > > > a series of detailed > > > drafts that would, over time, replace JP and Arthi's document. > > > > > > 1. Framework for Interdomain MPLS and GMPLS > > > A short draft that introduces the routing and signaling options > > > for multi-domain LSPs, and explains the options for path > > > computation. > > > This does not describe applicability or any necessary protocol > > > procedures or extensions. > > > Material will be taken from draft-vasseur-ccamp-inter-area-as-te > > > and draft-kompella-mpls-multiarea-te as required. > > > Authors: Adrian, JP, Arthi > > > Due date: End of April. > > > > As I mentioned at Seoul, I will be happy to help here. Particularly, > > with adding some material on options for diverse path computation. > > The current draft-vasseur-ccamp lists two options, but a hybrid > > that involves partial path computation in each domain (along the > > lines of what I presented at Seoul) is also possible, and can be a > > useful tradeoff for meeting several of the requirements listed > > in the corresponding requirements drafts. > > > > Also, I am assuming that the TE requirements documents will be > > the guiding documents in presenting options for routing/signaling > > and path computation in the above doc. I think it is important > > that the framework draft be in synch. with the requirements documents, > > rather than applying them only for 4 and 6. > > > > > 2. Individual signaling extension drafts > > > If any one of the signaling approaches described in 1. > > > requires additional protocol procedures or extensions > > > then a single draft will be written for each. > > > The base assumption is that such a draft will only be > > > written if there someone planning to implement and > > > deploy. > > > Authors: Dependent on extension > > > Due date: Aim for San Diego > > > > Please see initial note, about relation to other functions. > > > > > 3. Individual routing extension drafts > > > There are two dimensions to this: > > > - the different routing protocols (IGPs and EGPs) > > > - the different solution models > > > The aim should be to have one draft per protocol to provide the > > > generic mechanisms, and one draft per model per protocol to > > > provide procedures and field values etc. > > > Note that path computation functions are described under point > > > 5, below. > > > As with the signaling extensions, this work will only be > done once > > > we understand that there is a need *and* what is needed. > > > Authors: Again dependent on deployment plans > > > Due date: Slightly later than signaling work > > > > Please see initial note, about relation to other functions. > > > > Also, when you say "solution models" above, do you mean things > > like a centralized versus a distributed model? What other > > models did you have in mind? > > > > > 4. Applicability > > > A draft to explain when it is appropriate to use which model and > > > options. The aim is not to rubbish the opposition, but to say when > > > a particular model can/should be used. > > > Much of this material can already be found in > > > draft-vasseur-ccamp-inter-area-as-te, but it may need > > > some tidying up. > > > For political/expediency reasons this may result in multiple > > > applicability drafts in the first instance. > > > Authors: A supporter of each model > > > Due date: Quite soon - to accompany signaling extensions. > > > > > > 5. Path computation > > > Some solution models call for a (or many) path computation > > > servers (PCS). This demands several functions: > > > - discovery of PCS by network elements > > > - communication protocol between PCS and network elements > > > - some regulation of computation technique to avoid looping etc. > > > At the moment we are discussing precisely where this work should > > > be done, but that should not stop us starting the work > within CCAMP > > > since it is clearly related to the inter-area/AS solution. > > > > Is the discussion referred to above about where the PCS model should > > be done, or is it about path computation in general. > > > > Will the other path computation models will be discussed within > > CCAMP? > > > > > > > 6. Advanced functions. > > > There are several advanced functions that will be > required, but which > > > are not part of the immediate work. > > > - Path reoptimization > > > - Protection path diversity > > > - crankback > > > We expect that once the initial work has been done on the > > > solutions, it > > > will be possible to set out the requirements for these > > > functions and to > > > develop solutions based on the many drafts that are already > > > out there. > > > > As I said earlier, some of these functions are coupled to the > signaling and > > routing extensions, so it would be useful to discuss the signaling and > > routing extensions keeping some of these functions in mind. > > Otherwise, we run the risk of developing signaling and routing > extensions > > first, and then retro-fitting them to accommodate such functions, which > > I think are pretty key to inter-domain TE. > > > From owner-ccamp@ops.ietf.org Mon Apr 19 03:28:04 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22346 for ; Mon, 19 Apr 2004 03:28:03 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFTCF-0003ci-53 for ccamp-archive@ietf.org; Mon, 19 Apr 2004 03:28:03 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFTBA-0003Oa-00 for ccamp-archive@ietf.org; Mon, 19 Apr 2004 03:26:57 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BFTAP-0003AU-00 for ccamp-archive@ietf.org; Mon, 19 Apr 2004 03:26:10 -0400 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BFSpc-0002X2-JL for ccamp-data@psg.com; Mon, 19 Apr 2004 07:04:40 +0000 Received: from [128.87.251.126] (helo=smtp3.marconicomms.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BFSpZ-0002Wg-CT for ccamp@ops.ietf.org; Mon, 19 Apr 2004 07:04:37 +0000 Received: from cvis151.mail.marconicomms.com by smtp3.marconicomms.com with ESMTP (8.12.10+Sun/mcig-6) id i3J74aO8015193; Mon, 19 Apr 2004 08:04:36 +0100 (BST) Received: from cvdgwy01.uk.marconicomms.com (unverified) by cvis151.mail.marconicomms.com (Content Technologies SMTPRS 4.3.12) with ESMTP id for ; Mon, 19 Apr 2004 07:49:18 +0100 Subject: draft-caviglia-mp2cp&cp2mp-00 To: ccamp@ops.ietf.org X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Diego Caviglia" Date: Mon, 19 Apr 2004 08:48:03 +0200 X-MIMETrack: Serialize by Router on CVDGWY01/S/EXT/MC1 (5012HF354 | August 26, 2003) at 19/04/2004 07:49:17 MIME-Version: 1.0 Content-type: text/plain; charset="us-ascii" Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Hi all, a new ID is available at the following address http://www.ietf.org/internet-drafts/draft-caviglia-mp2cp&cp2mp-00.txt. Here is the abstract: Abstract This memo introduces a new flag in the Administrative Status object, namely the Fake flag. This flag SHOULD be used in order to move under the Control Plane (CP) domain LSPs that were created by the Management Plane (MP), and vice versa. The result of the Fake flag in GRSVP-TE is twofold: at the end of the set-up signaling flow, an LSP that was created by Management Plane is moved under to Control Plane domain. Similarly, at the end of a deletion procedure the LSP that was under the Control Plane domain is moved under the Management Plane domain. Comments and suggestion are very appreciated. Regards, Diego ---------------------- Forwarded by Diego Caviglia/MAIN/MC1 on 04/19/2004 08:46 AM --------------------------- ietfauto@ietf.org (Internet Draft Submission Manager) on 04/15/2004 02:01:08 PM Please respond to dinaras@ietf.org To: Diego.Caviglia@marconi.com cc: Subject: Re: Submitting of ID draft-caviglia-mp2cp&cp2mp-00 Greetings: This message is being sent to acknowledge receipt of your Internet-Draft submission or message to internet-drafts@ietf.org. If you submitted an Internet-Draft, then it will be posted on the Internet-Drafts page of the IETF Web site, and an I-D Action message will be sent to the IETF Announcement List. Please note that all Internet-Drafts offered for publication as RFCs must conform to the requirements specified in ID Nits (http://www.ietf.org/ID-nits.html) or they will be returned to the author(s) for revision. Therefore, the IETF Secretariat strongly recommends that you address all of the issues raised in this document before submitting a request to publish your Internet-Draft to the IESG. The IETF Secretariat From owner-ccamp@ops.ietf.org Mon Apr 19 04:16:48 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24738 for ; Mon, 19 Apr 2004 04:16:48 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFTxP-0006lY-Uo for ccamp-archive@ietf.org; Mon, 19 Apr 2004 04:16:48 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFTwU-0006Yz-00 for ccamp-archive@ietf.org; Mon, 19 Apr 2004 04:15:51 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BFTw9-0006MC-00 for ccamp-archive@ietf.org; Mon, 19 Apr 2004 04:15:29 -0400 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BFTkU-000F7F-FL for ccamp-data@psg.com; Mon, 19 Apr 2004 08:03:26 +0000 Received: from [128.130.90.21] (helo=nt-ftw.ftw.tuwien.ac.at) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BFTkR-000F6j-Ji for ccamp@ops.ietf.org; Mon, 19 Apr 2004 08:03:23 +0000 Received: from nt_ftw.ftw.tuwien.ac.at by nt-ftw.ftw.tuwien.ac.at via smtpd (for psg.com [147.28.0.62]) with ESMTP; Mon, 19 Apr 2004 10:17:27 +0100 Received: from coritel.it (spirit.ftw.at [192.168.0.19]) by nt_ftw.ftw.at with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 20F8QQ37; Mon, 19 Apr 2004 10:02:46 +0200 Message-ID: <408387C8.1010108@coritel.it> Date: Mon, 19 Apr 2004 10:03:20 +0200 From: ricciato User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030821 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dimitri.Papadimitriou@alcatel.be, ccamp CC: LE ROUX Jean-Louis FTRD/DAC/LAN Subject: About optimality of inter-AS parallel computation in draft-dachille-inter-area-path-protection X-Enigmail-Version: 0.76.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Dear ccampers, Dimitri, we were reported by Vishal several comments collected at Seoul regarding draft-dachille, proposing the parallel computation (or joint-computation) approach with ARO for diverse path-pair computation. After several internal discussions and thoughts, we are now going to react to these, as anticipated in the recent mail by Vishal. Among other comments there was one issued by Dimitri. If I correctly understood, his point was the following: the joint computation (with ARO) is guaranteed to *achieve* the global optimum only in the trivial case of a single AS, but not along a path with multiple AS. This is indeed due to the distributed nature of the route selection process, that can optimize local route segments, but can not generally achieve the *global* optimum (in fact, distributed optimization would need an iterative process to converge to global optimum, which is not the case here). Now, the Dimitri point was: why prefer the joint computation (with ARO) to sequential computation (with XRO), since neither of the two in general achieve the global optimum ? This is a good question and gives me the opportunity to make some more general considerations about the ARO approach scketched in the draft. 1. If you consider the classical problem (i.e., find two disjoint paths with the objective of minimizing some link metric) despite joint-computation does not reach the global optimum, it definitely improves the quality of the solution w.r.t. sequential-computation. The exact gain depends on the particular topology, and there are of course cases in which it can be zero (see note 1). 2. An additional benefit of joint- (or "parallel-") vs. sequential-computation is robusteness against trap-topologies (ref. to draft-dachille) 3. The joint-computation with ARO can be applied to a vast class of problems dealing with path-pair computation. I'm giving below some few examples. (I think this also adrresses some comment by Jean-Louis). In general, in each problem of path-pair computation one can distinguish the constraint(s) from the optimization objective: Case-I: find a pair of disjoint paths (i.e., disjointedness is a constraint) wich minimize some link metric (hop-length, link-load, etc.) Case-II: find a pair of maximally disjoint paths (disjointedness becomes an objective) Case-III: find a pair of disjoint paths P1 and P2 that minimizes the difference |d(P1)-d(P2)|, where d() is some metric associated to the path (e.g., delay....might make sense in optical networks ??). Case-IV: Assuming that for each link pair (i,j) it is possible to assign a "correlation" factor r(i,j) accounting for the probability of contemporary failures, find a pair of paths that minimizes the max{r(i,j)} over all pairs such that i is in P1 and j is in P2 [see note 2]. Maybe not all the above items are of practical interest in real applications, but the fact that our approach encompasses all of them proves the flexibility and usefulness of joint-computation with ARO. Several other problems can be found. In general, joint-selection with ARO can address to all problems presenting some *joint constraints* and/or *joint optimization objective* on the pair of paths. Needless to say, each such case requires ad-hoc route-selection _algorithms_ to be implemented in the ingress border nodes (or in a centralized server within each AS), but all can be accommodated with the signaling procedure based on ARO. Admittedly, the current draft version exclusively focused on case-I, and fails to make it clear that the set of possible applications is far broader. We will improve this point in the future version. Incidentally, I notice here that this is indeed the reason why we proposed the (quite neutral) term "Associated Route Object" instead of the more specific "Disjoint R.O." or "Backup R.O." etc.: we wanted to leave it open to a broad set of possible applications. Maybe it would make sense to add some additional semantic in the PATH messages that specify the contraint(s) and/or the objectives to which the primary (in the ERO) and secondary (in the ARO) paths should (jointly!) comform. This might be an associated sub-object of the ARO, perhaps ? Might be named "Route Pair Requirements" (RPR) ? In other words, the overall semantic in the PATH messages should sound like: "compute a primary route segment (in the ERO), and an associated secondary route segment (in the ARO), such that they are subject to the contraint(s) X and optimize objective Y (X,Y are contained somehow in the RPR)". The ERO+ARO+RPR scheme, in the framework of distributed *joint* route selection, would be really a quite flexible and general scheme. What do you think about that ? Looking forwards to get more comments, best regards Fabio Ricciato Note 1: Having available some guidelines about realistic inter- and intra-AS topologies, we would be available to run extensive simulations to assess this gain in realistic case. Is there anyone interested in this activity ? Note 2: In general 0<=r(i,j)<=1. This is a "fuzzy" extension of the SRLG concept. In fact, a SLRG can be defined as a set of links S having r(i,j)=1 for each i,j in S. From owner-ccamp@ops.ietf.org Mon Apr 19 04:29:42 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA25441 for ; Mon, 19 Apr 2004 04:29:42 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFU9t-0001wd-PV for ccamp-archive@ietf.org; Mon, 19 Apr 2004 04:29:41 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFU8R-0001aV-00 for ccamp-archive@ietf.org; Mon, 19 Apr 2004 04:28:11 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BFU7P-0001J2-00 for ccamp-archive@ietf.org; Mon, 19 Apr 2004 04:27:07 -0400 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BFTxS-000IJu-OL for ccamp-data@psg.com; Mon, 19 Apr 2004 08:16:50 +0000 Received: from [128.130.90.21] (helo=nt-ftw.ftw.tuwien.ac.at) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BFTxR-000IJZ-2g for ccamp@ops.ietf.org; Mon, 19 Apr 2004 08:16:49 +0000 Received: from nt_ftw.ftw.tuwien.ac.at by nt-ftw.ftw.tuwien.ac.at via smtpd (for psg.com [147.28.0.62]) with ESMTP; Mon, 19 Apr 2004 10:30:52 +0100 Received: from coritel.it (spirit.ftw.at [192.168.0.19]) by nt_ftw.ftw.at with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 20F8QQP4; Mon, 19 Apr 2004 10:16:13 +0200 Message-ID: <40838AEE.9010704@coritel.it> Date: Mon, 19 Apr 2004 10:16:46 +0200 From: ricciato User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030821 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ccamp , Adrian Farrel CC: Vishal Sharma , Marco Listanti Subject: About egress-influenced path computation in draft-dachille-inter-area-path-protection X-Enigmail-Version: 0.76.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 8bit Dear ccmapers, Alan I'm giving my comment to one question raised at Seoul by Alan to Vishal regarding the joint-selection with ARO of diverse paths, i.e. the approach proposed in draft-dachille. It was mentioned in point (v) of last mail from Vishal. Consider a linear topology of ASs from AS(1) (the source AS) to AS(N) (the destination AS). Denote by I(k) and E(k), respectively, the ingress and egress nodes to AS(k). Where needed, I'll distinguish between the ingress of the primary and secondary path, respectively, by I1(k) and I2(k). Same for th egress nodes (i.e., E1(k), E2(k)). In the proposed approach, the selection process run as follows: a. I1(k) selects the path-pair inside AS(k), thus explicitely determining I2(k), E1(k) and E2(k). b. In the case that each single node E(k) has a single link to I(k+1), this means that I1(k) is implicitely determining I(k+1) too. Let's call this special case "1:1 border-nodes". I do not know if this is a common case in practice, or rather if each single border node is connected to >1 adjacent border nodes (anyone can comment on that ?) If I understood it correctly, the Adrian´s point was: would it be possible to modify the scheme such that the egress nodes can influence the selection of the ingress nodes, by expressing some "preference" within the set of possible ingress nodes ? This sounds quite contradictory to the original scheme. In fact this is based on the following sequence of selections: I(k)-->E(k)-->I(k+1)-->... , while Adrian's approach would add to that a E(k)-->I(k) dependance. One might think to a variation of the scheme in which the secondary path computation for AS(k), i.e. the ARO expansion, is run during the RESV phase. In this case, the selection sequence would be I1(k)-->E1(k)-->{I2(k),E2(k)}, in place of I1(k)-->{E1(k),I2(k),E2(k)} (see above point 'a') However, this approach would break the joint-selection concept that, we think, is a key point of our approach (see my previous mail to Dimitri). Another possibility would be to carry two AROs, instead of one, thus having two secondary paths from which the downstream nodes (E1(k) or I(k+1) can choose. However, the main drawback of this approach is that it is quite restrictive. Consider the case in which three paths are available that pair-wise disjoint, but not three-wise disjoint. In this case it is not possible to expand two AROs with complete disjointedness constraints and the procedure fails, while there are up to three possible disjoint pairs to select. Instead, if really one is willing to implement this capability (namely: "egress-driven selection"), several alternative solutions might be considered (e.g. partial "soft" cranckback, preliminary signaling, etc.) which however can not avoid some additional burden to the signaling procedure (at least, this is what I see now, but maybe I'm worng). On the other hand, I would ask Adrian why it would be convenient to have this "egress-driven selection". In my humber opinion a possible answer might be that the egress nodes E(k) have knowledge about the load of inter-AS links E(k)-I(k+1), so that they can optimize the path selection taking into account the load on these external links, in addition to the load of internal links to AS(k). If this is the case, my answer would be: why don't we let the ingress nodes I(k) be aware of the load state of downstream external links E(k)-I(k+1) ? In fact, this information is already available to E(k), then I see no problems in sharing it with I(k) nodes since both are in the same domain AS(k). This can be achieved quite easily. Consider the original scheme proposed in the draft xxx. The ERO and ARO expansion is done at I1(k). The computation, however, can be run on the I1(k) node itself, or in a centralized route server that border nodes can query. In both cases the computation relies on a topology/load database (that, in a fully distributed environment might be fed by OSPF-TE Opaque-LSAs). So, why not augmenting this database to include external links also ? In both cases (centralized server, or OSPF-TE flooding) this does *not* require any protocol modification. Note that both adjacent ASs will consider this information as "private", and will not export it to other ASs. In conclusion, with this approach the ingress node I(k) would have exactly the same view of egress nodes E(k), so there is no additional benefit in having "egress-driven selection". I would aks you to comment on that. In particular, I'd like to know if you are aware of any other reasons or potential benefits for "egress-driven selection" beside that considered here. In this case we could further think about how to develop it in the framework of the ARO scheme. Looking forwards to get more comments, best regards Fabio Ricciato From owner-ccamp@ops.ietf.org Mon Apr 19 15:28:30 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04070 for ; Mon, 19 Apr 2004 15:28:30 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFeRS-00075l-Pk for ccamp-archive@ietf.org; Mon, 19 Apr 2004 15:28:30 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFeQT-0006q8-00 for ccamp-archive@ietf.org; Mon, 19 Apr 2004 15:27:30 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BFePu-0006bS-00 for ccamp-archive@ietf.org; Mon, 19 Apr 2004 15:26:54 -0400 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BFe82-0004lW-LO for ccamp-data@psg.com; Mon, 19 Apr 2004 19:08:26 +0000 Received: from [62.23.212.165] (helo=smail.alcatel.fr) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BFe7x-0004k0-UC for ccamp@ops.ietf.org; Mon, 19 Apr 2004 19:08:22 +0000 Received: from bemail06.netfr.alcatel.fr (bemail06.netfr.alcatel.fr [155.132.251.30]) by smail.alcatel.fr (ALCANET/NETFR) with ESMTP id i3JJ8HQP020382; Mon, 19 Apr 2004 21:08:17 +0200 Received: from alcatel.be ([138.203.87.246]) by bemail06.netfr.alcatel.fr (Lotus Domino Release 5.0.11) with ESMTP id 2004041921081593:9856 ; Mon, 19 Apr 2004 21:08:15 +0200 Message-ID: <40842395.2DD1A674@alcatel.be> Date: Mon, 19 Apr 2004 21:08:05 +0200 From: stefaan.de_cnodder@alcatel.be X-Mailer: Mozilla 4.72 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: v.sharma@ieee.org CC: ccamp@ops.ietf.org Subject: comments on ARO X-MIMETrack: Itemize by SMTP Server on BEMAIL06/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 04/19/2004 21:08:15, Serialize by Router on BEMAIL06/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 04/19/2004 21:08:17, Serialize complete at 04/19/2004 21:08:17 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-Alcanet-MTA-scanned-and-authorized: yes Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Hi Vishal, looking to draft-dachille, I have following comments: 1) Second paragraph in section 2 is not clear: "we will assume that every inter-area connection is duplicated". I understood from it that when the primary path follows Area1-Area2-Area3, then also the secondary has to follow this path but using other border nodes. But then from section 4.2 I understand that this is not an assumption? 2) step 2c on page 5: also E, G and H has to be pruned? It is also not clear which path is selected in area 3: I guess it is E-G-H for primary and F-H for secondary? 3) (!) page 7, about the trap-avoid reference: If fact it is just a matter of doing a good path calculation. If the primary is signaled and border nodes know that also a secondary has to be established, then it can make sure that the primary does not introduce such a trap. This assumes that the border node also has to know that a secondary has to be established. This is known by the presence of the ARO object but this does not mean that at the end, the ARO has to contain a full strict path of the secondary. Border nodes can expand the ARO by only including the border nodes for the secondary. This means that the path calculation of the secondary is not anymore 100% bound to the primary. Also I would prefer that the ARO is more like a "hint" than the real path. With this, you do not have to interaction problems with re-optimization of secondary, crankback, ... For instance: when the secondary fails, it can be re-established ignoring the ARO. Or when the secondary can be re-optimzed between border nodes, then it can be done without impacting the primary or when the global re-optimization is possible, then the ARO can be simple ignored. I prefer to have the ARO only recording border nodes, and optionally only acting as a hint for the ingress LSR. The latter is less important to me. 4) text below figure 3: primary has to be as short as possible. I do not care much about the secondary becuase it is almost never used. Also, the resources that it reserves can be shared with other secondaries. The problem here is: what are you optimizing? According to me the path of the primary has to be optimized. 5) I do not understand why the ARO has to contain Area-Ids to indicate the route. If the ingress can put the "area-path" in the ARO, then it can also put the border nodes in the ERO of the secondary immediately. I.e. refering to figure 5: A knows that the path of the secondary is A1-A2-A5-A6. How does A know this? And if it is possible to let A know this information, then why could it also not know that the path is B1-B7-B9. If A can do this, then there is no need anymore for ARO. So the basic question is: what makes it easier for A to know A1-A2-A5-A6 instead of B1-B7-B9. This means to me that section 4.2 is not valid and that the ARO assumes that the "area-path" of primary and secondary is the same, which is true for IGP areas. See also comment 2. Maybe better to remove the AREA-IDs from the ARO. 6) step 1d page 14, second last line: how does the ABR know that B7 has to be used and not B8? 7) section 4.3: also describe the L-bit that is in the ERO subobjects. 8) Is the Addr_len in for instance subobject 1 always 32 or can it be something else. I agree here that you should re-use ERO subobjects but I see that you are doing this. 9) Section 4.3.2.3, area_ID: types 3, 4 and 5 are defined but that conflicts with what is described in the middle of page 19 where the numbers are 32, 33, 34. 10) the text in section 4.3.3 is rather confusing (the part in the middle of page 22, about pruning the nodes). Take figure 5, area 5: If B6 has to calculate a path from B6 to B10, then this path can pass via B5, B8, B7 and/or B9. This is because border nodes can also act as core nodes at the same time. This seems to be excluded from the draft. Is that correct? 11) First refinement in section 5 about the cost of virtual links: this has been proposed before in http://www.watersprings.org/pub/id/draft-venkatachalam-interarea-mpls-te-02.txt which is not a good idea: it only works for inter-IGP area and it decreases the scalability although it also has some advantages. 12) (!) There are conflicts with re-optimization, crankback, re-establishement after failure of secondary LSP, ... because in all of these cases a working primary LSP also have to be re-signaled which is not good. Therefore it is better to let the ARO only record border nodes, and/or to use the ARO more as a hint for the secondary: using the ARO in the primary makes sure that a trap is avoided, and then it is up to the signaling of the secondary to find this path by using crankback, .... There is no need that the primary LSP also gives the path, it only has to make sure that there is a path. 13) (!) The method seems not to be applicable for inter-AS calculations. 14) Following the classification of methods (ARO, XRO, PCE) that you described earlier on ccamp based on parallel/sequential and distributed/centralized computation, ARO looks more an alternative for PCE than for XRO? In fact, would it be possible to combine methods? It would be good to explain the interaction (if any) with these other methods. Hope this helps, regards, Stefaan From owner-ccamp@ops.ietf.org Mon Apr 19 17:46:23 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12647 for ; Mon, 19 Apr 2004 17:46:23 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFgau-0002DG-MR for ccamp-archive@ietf.org; Mon, 19 Apr 2004 17:46:24 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFga2-0001zA-00 for ccamp-archive@ietf.org; Mon, 19 Apr 2004 17:45:30 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BFgZL-0001kn-00 for ccamp-archive@ietf.org; Mon, 19 Apr 2004 17:44:47 -0400 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BFgNy-000GbV-Au for ccamp-data@psg.com; Mon, 19 Apr 2004 21:33:02 +0000 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BFgNx-000GbI-Ik for ccamp@ops.ietf.org; Mon, 19 Apr 2004 21:33:01 +0000 Date: Mon, 19 Apr 2004 14:33:01 -0700 From: Alex Zinin Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <1683572413.20040419143301@psg.com> To: ccamp@ops.ietf.org Subject: On PCS-based traffic-engineering solutions 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-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.8 required=5.0 tests=AWL,PRIORITY_NO_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Folks- I've been asked for a clarification on where the discussion and work on the PCS-based solutions (e.g. draft-vasseur-ccamp-inter-area-as-te-00.txt) belong. The reason for the question was the fact that PCS-based approach uses a paradigm that is rather different from the currently used one and requires a set of new mechanisms that CCAMP is not chartered to work on. After a consultation with the CCAMP WG chairs, my recommendation is as follows: 1. The PCS-based solutions should be included in the discussion on inter-area/AS traffic engineering in the CCAMP WG. The WG needs to select the best solution and ruling one of the possible approaches out at this time would be unfair. 2. A BOF on the PCS-based approach will be scheduled for the San Diego IETF meeting. The goal for the BOF meeting will be to gather wider community feedback on the approach and gauge the level of interest in it. Depending on the results of the discussion in CCAMP and the BOF, decisions will be made on: a) Whether the PCS-related work should be taken on in the IETF, and if so b) Where this work should be hosted (e.g., a separate WG, or in CCAMP) -- Alex IETF RTG Area co-Director From owner-ccamp@ops.ietf.org Mon Apr 19 17:56:26 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13387 for ; Mon, 19 Apr 2004 17:56:26 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFgkd-0004yB-53 for ccamp-archive@ietf.org; Mon, 19 Apr 2004 17:56:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFgjc-0004gT-00 for ccamp-archive@ietf.org; Mon, 19 Apr 2004 17:55:25 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BFgii-0004P5-00 for ccamp-archive@ietf.org; Mon, 19 Apr 2004 17:54:28 -0400 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BFgYj-000KVN-G9 for ccamp-data@psg.com; Mon, 19 Apr 2004 21:44:09 +0000 Received: from [216.109.118.116] (helo=web60305.mail.yahoo.com) by psg.com with smtp (Exim 4.30; FreeBSD) id 1BFgYh-000KTT-W2 for ccamp@ops.ietf.org; Mon, 19 Apr 2004 21:44:08 +0000 Message-ID: <20040419214407.99669.qmail@web60305.mail.yahoo.com> Received: from [24.6.129.102] by web60305.mail.yahoo.com via HTTP; Mon, 19 Apr 2004 14:44:07 PDT Date: Mon, 19 Apr 2004 14:44:07 -0700 (PDT) From: Greg Bernstein Subject: Re: Proposed strategy for Inter-area/AS To: Adrian Farrel , ccamp IETF In-Reply-To: <02a601c42217$0b13dda0$60849ed9@Puppy> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Nice work breakdown Adrian. Agree that the applicability should be tackled early on. On of the issues that has been a problem in the past was of differing applicabilities. Thanks also for putting the drafts in once nice easy to access place. The only one I didn't see there was the kompella-multi-area-te draft that you mention below. Also agree in principle with Vishal's path computation hierarchy. When dealing with different granularity signal types, e.g., from 1 or 2Mbps MPLS LSPs all the way to lambda or waveband switched GMPLS LSPs different methods are generally called for. For example, a distributed PCS approach would initially be overkill, versus a centralized approach (not that many LSPs to get set up that often) while if one is dealing with lower rate MLPS LSPs a distributed PCS approach (hopefully) would be more appropriate. Just saw Alex's question on where the PCS work is... I went looking for drafts to see where this is at... Greg B. P.S. Yes, consulting has picked up... --- Adrian Farrel wrote: > All, > > JP and Arthi have done a fine job of pulling > together all of the threads of inter-area and > inter-AS solutions into a single draft. This gives > us a single place to look for > information, but the resulting draft is (of course) > quite large. As additional details > need to be filled in, it is clear that this draft > would only grow and that would make it > unusably large. > > So, we are proposing to use the material in the > draft to produce a series of detailed > drafts that would, over time, replace JP and Arthi's > document. > > 1. Framework for Interdomain MPLS and GMPLS > A short draft that introduces the routing and > signaling options > for multi-domain LSPs, and explains the options > for path > computation. > This does not describe applicability or any > necessary protocol > procedures or extensions. > Material will be taken from > draft-vasseur-ccamp-inter-area-as-te > and draft-kompella-mpls-multiarea-te as > required. > Authors: Adrian, JP, Arthi > Due date: End of April. > > 2. Individual signaling extension drafts > If any one of the signaling approaches described > in 1. > requires additional protocol procedures or > extensions > then a single draft will be written for each. > The base assumption is that such a draft will > only be > written if there someone planning to implement > and > deploy. > Authors: Dependent on extension > Due date: Aim for San Diego > > 3. Individual routing extension drafts > There are two dimensions to this: > - the different routing protocols (IGPs and > EGPs) > - the different solution models > The aim should be to have one draft per > protocol to provide the > generic mechanisms, and one draft per model per > protocol to > provide procedures and field values etc. > Note that path computation functions are > described under point > 5, below. > As with the signaling extensions, this work > will only be done once > we understand that there is a need *and* what > is needed. > Authors: Again dependent on deployment plans > Due date: Slightly later than signaling work > > 4. Applicability > A draft to explain when it is appropriate to use > which model and > options. The aim is not to rubbish the > opposition, but to say when > a particular model can/should be used. > Much of this material can already be found in > draft-vasseur-ccamp-inter-area-as-te, but it may > need > some tidying up. > For political/expediency reasons this may result > in multiple > applicability drafts in the first instance. > Authors: A supporter of each model > Due date: Quite soon - to accompany signaling > extensions. > > 5. Path computation > Some solution models call for a (or many) path > computation > servers (PCS). This demands several functions: > - discovery of PCS by network elements > - communication protocol between PCS and network > elements > - some regulation of computation technique to > avoid looping etc. > At the moment we are discussing precisely where > this work should > be done, but that should not stop us starting > the work within CCAMP > since it is clearly related to the inter-area/AS > solution. > > 6. Advanced functions. > There are several advanced functions that will > be required, but which > are not part of the immediate work. > - Path reoptimization > - Protection path diversity > - crankback > We expect that once the initial work has been > done on the solutions, it > will be possible to set out the requirements > for these functions and to > develop solutions based on the many drafts that > are already out there. > > Comments please. > > Thanks, > Adrian and Kireeti > > __________________________________ Do you Yahoo!? Yahoo! Photos: High-quality 4x6 digital prints for 25¢ http://photos.yahoo.com/ph/print_splash From owner-ccamp@ops.ietf.org Mon Apr 19 23:25:41 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA02322 for ; Mon, 19 Apr 2004 23:25:40 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFltF-0002PT-HU for ccamp-archive@ietf.org; Mon, 19 Apr 2004 23:25:41 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFlsS-00029f-00 for ccamp-archive@ietf.org; Mon, 19 Apr 2004 23:24:52 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BFlrj-0001sG-00 for ccamp-archive@ietf.org; Mon, 19 Apr 2004 23:24:07 -0400 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BFlcg-000ADD-1W for ccamp-data@psg.com; Tue, 20 Apr 2004 03:08:34 +0000 Received: from [171.71.176.71] (helo=sj-iport-2.cisco.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BFlcf-000ACg-81 for ccamp@ops.ietf.org; Tue, 20 Apr 2004 03:08:33 +0000 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 19 Apr 2004 19:18:46 +0000 Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i3K38V7t025239 for ; Mon, 19 Apr 2004 20:08:31 -0700 (PDT) Received: from jvasseur-w2k01.cisco.com (rtp-dial-1-131.cisco.com [10.83.97.131]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id UAA04019 for ; Mon, 19 Apr 2004 20:08:29 -0700 (PDT) Message-Id: <4.3.2.7.2.20040419230500.06379700@wells.cisco.com> X-Sender: jvasseur@wells.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 19 Apr 2004 23:08:08 -0400 To: ccamp@ops.ietf.org From: Jean Philippe Vasseur Subject: Draft draft-vasseur-ccamp-loose-path-reopt-01.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Hi, Just to mention that we posted a new revision of draft-vasseur-ccamp-loose-path-reopt-01.txt that proposes some mechanisms for the reoptimization of loosely routed TE LSP (intra-area, inter-area and Inter-AS). Thanks for the various comments and support that we got on this ID, this new revision incorporates the comments that we received + various edits and clarifications. JP. From owner-ccamp@ops.ietf.org Tue Apr 20 03:33:42 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28564 for ; Tue, 20 Apr 2004 03:33:42 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFplF-0004BO-NS for ccamp-archive@ietf.org; Tue, 20 Apr 2004 03:33:41 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFpkI-0003wA-00 for ccamp-archive@ietf.org; Tue, 20 Apr 2004 03:32:43 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BFpjS-0003VI-00 for ccamp-archive@ietf.org; Tue, 20 Apr 2004 03:31:51 -0400 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BFpSk-0002A9-IZ for ccamp-data@psg.com; Tue, 20 Apr 2004 07:14:34 +0000 Received: from [66.163.168.184] (helo=smtp805.mail.sc5.yahoo.com) by psg.com with smtp (Exim 4.30; FreeBSD) id 1BFpSj-00029h-Ez for ccamp@ops.ietf.org; Tue, 20 Apr 2004 07:14:33 +0000 Received: from unknown (HELO RAKHILAPTOP) (vishal.sharma@sbcglobal.net@63.202.178.144 with login) by smtp805.mail.sc5.yahoo.com with SMTP; 20 Apr 2004 07:14:32 -0000 Reply-To: From: "Vishal Sharma" To: "Stefaan De Cnodder" , "CCAMP" Cc: "Fabio Ricciato" , "Ugo Monaco" , "Alessio D'Achille" , "Marco Listanti" Subject: Observations/feedback on draft-decnodder-mpls-interas-protection Date: Tue, 20 Apr 2004 00:14:15 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Hi Stefaan, As promised at the Seoul IETF, here is my (rather belated!) feedback on the interas protection draft. (I am cc'ing it to my co-authors as well, so that we can minimize duplication of our comments.) To make things easier, I have divided my comments into technical and editorial. Regards, -Vishal PS: BTW, thanks for your comments on draft-dachille, will try to respond to them after having time to review your feedback. ******************************************************************* Technical --------- i) Abstract: I think it would be useful to make clear here that the techniques in this document apply to links between 2 ASs (or only to inter-AS links). ii) Intro., para 4, "Section 4 ... node protection," would be clearer if it specified that an e2e path for an LSP _crossing multiple ASs_ can only provide link or node protection. (Presumably, for LSPs within an AS, where the SRLG's would be consistent, it should be possible to provide SRLG protection using e2e protection.) iii) Sec. 3, para 1, "For instance, in Figure 2 ... multiple core routers," it is a bit confusing to have R23 and R24. Which links specifically are being referred to here? Is it, R21-R24, R21-R25, R25-R24? iv) Title of Sec. 4 might be better as "Problems in SRLG protection with disjoint e2e LSPs" v) The document uses "main" and "primary" for the working LSP. It might be better to have consistently the same term throughout. vi) It might be better to add another row of routers in both ASs in Fig. 2, to make it non-trivial. That way, it will be possible to illustrate that there are multiple secondary egress AS-BRs, and multiple secondary ingress AS-BRs, and also that the egress AS-BR has to make a choice of a route to an appropriately picked secondary egress AS-BR, etc. vii) The way the method is described, especially in Sec. 6, it appears that the technique applies only to packet LSPs. Is my understanding correct? viii) The entire segment in Sec. 6.1.1 para 2, from "In case this condition ..." until "... not in the downstream AS (AS2 in Figure 2)," might benefit from some simplification in the writing. It's a bit difficult to follow, as written. ix) Similary, in the same para, the description of what portion of an RRO should be in the ERO for the detour LSP emanating from the egress AS-BR is also confusing. It might be restated as "The ERO for the detour LSP starting at the egress AS-BR contains several segments. It must first contain a strict or loose path towards the secondary egress AS-BR, followed by a segment of the RRO for the primary LSP. This segment begins at the last hop in the downstream AS and contains all hops thereafter up until the destination." x) In the same para, it is mentioned that the ERO of the detour LSP consists of two segments. However, when elucidating this with a reference to Fig. 2, the ERO of the detour LSP is only said to be composed for router R14, R22 and all routers thereafter. The segment from R14 to R12 and R12 to R21 is not mentioned. xi) In the draft, in the sentence describing the ERO of the detour LSP, the last router should probably be R24 instead of R22 (as currently written). xii) Sec. 6.1.1, para 4, the last sentence could be reworded to make it a bit clearer. I think it is saying that when the primary and secondary egress AS-BRs are the same, and the primary and secondary ingress AS-BRs are the same, and they have multiple links between them, then the detour LSP must simply use an inter-domain link different than the one used by the primary LSP, and no path computation is needed at the egress AS-BR. xiii) It would be useful to explain the purpose and structure of the LSP-Merge object as well as the operations performed on it, in Sec. 6.1. itself. Otherwise, the reader sees this object mentioned in the main text, without having an idea of what it is. In any case, since the appendices are quite small, and sort of intergral to the subsequent text in the main doc., I think it would be best to pull them into the main text. xiv) This will make the description in Sec. 6.1.4 and 6.3.1 easier to follow. xv) The second last para in Sec. 6.3.1 mentions that the merge point of the detour and main LSP must ensure that it can switchover traffic from the incoming detour LSP to its originating detour LSP, since the egress link at this merge point may belong to the same SRLG as the inter-domain link that the incoming detour LSP was protecting. Is this trivial to ensure? It appears that there is a bit of work that an LSR would have to do to ensure that. No? (Since the normal procedure would be simply to merge traffic from the detour LSP on to the main LSP.) xvi) Sec. 6.3.4, the first sentence "If the secondary ... inside these objects" is worded in a rather confusing way. In which objects does the sec. ingress AS-BR add the list of SRLG's of the inter-AS link? xvii) In Sec. 6.3.6. it is not clear why there is a focus on the SRLG protection of the link _preceding_ the ingress AS-BR? xviii) In the same section, the para "To ensure that .... towards the egress AS-BR" is unclear, and perhaps needs to be reworded and better explained. Not sure which link the phrase "... SRLG disjoint with the next link of the main LSP computed towards the egress AS-BR" refers? xix)In Sec. 6.3.6, para 4, the phrase "IF only 1 detour LSP ... LSP setup would fail," is unclear. xx) Sec. 7, second last para states "We also note ... does not lead to the failure of the bypass tunnel." I guess it wasn't clear why teh interface failure does not cause a failure of the bypass tunnel. xxi) Appendix B, last sentence, why is the use of the sender-template specific detour LSP merely "recommended" as opposed to being "required"? xxii) The last sentence of Appendix B ends with "avoid merging with other LSPs". It would be useful to say here which those "other LSPs" are. I assume their are themselves other detour LSPs for the given main LSP? Editorial --------- i) Sec. 4, para 1, "first of all it supports fast recovery, and, second, it provides SRLG protection..." ii) Sec. 4, para 3, "This is because ... in common with AS1, and _neither_ AS1 nor AS3 will be aware ..." iii) Sec. 6.1.1, para 2, "in case this condition ... goes through the AS where the detour LSP originated causing loops." iv) Sec. 6.2, "The method to determine a secondary egress AS-Br is the same as for the _secondary_ egress AS-BR for link protection." v) Sec. 7, para 5, "The difficulty ... bypass tunnels _lies_ in the selection of the appropriate ..." From owner-ccamp@ops.ietf.org Tue Apr 20 04:14:09 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00677 for ; Tue, 20 Apr 2004 04:14:09 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFqOO-00070R-8h for ccamp-archive@ietf.org; Tue, 20 Apr 2004 04:14:08 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFqNH-0006j6-00 for ccamp-archive@ietf.org; Tue, 20 Apr 2004 04:13:00 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BFqMX-0006SJ-00 for ccamp-archive@ietf.org; Tue, 20 Apr 2004 04:12:13 -0400 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BFpyU-000Dk6-KH for ccamp-data@psg.com; Tue, 20 Apr 2004 07:47:22 +0000 Received: from [195.8.69.15] (helo=oceanus.uk.clara.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BFpyT-000Djp-LW for ccamp@ops.ietf.org; Tue, 20 Apr 2004 07:47:21 +0000 Received: from claranet by oceanus.uk.clara.net with local (Exim 4.22) id 1BFpyX-0009G4-45; Tue, 20 Apr 2004 08:47:25 +0100 From: "Adrian Farrel" To: gregbern@yahoo.com, ccamp@ops.ietf.org Cc: adrian@olddog.co.uk Reply-To: adrian@olddog.co.uk Subject: Re: Proposed strategy for Inter-area/AS Date: Tue, 20 Apr 2004 08:47:25 +0100 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Remote_Addr: 156.106.224.107 Message-Id: Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Hi Greg, > Nice work breakdown Adrian. Agree that the > applicability should be tackled early on. One of the > issues that has been a problem in the past was of > differing applicabilities. Agree. > Thanks also for putting the drafts in once nice easy > to access place. The only one I didn't see there was > the kompella-multi-area-te draft that you mention > below. Thanks. Yes, that draft was quite useful (and frankly, I missed it when I started on the inter-domain stuff which turns out to be really annoying because it contains some good text), however, it expired in December last year. I am parsing it to include relevant material in the framework draft. > Also agree in principle with Vishal's path computation > hierarchy. When dealing with different granularity > signal types, e.g., from 1 or 2Mbps MPLS LSPs all the > way to lambda or waveband switched GMPLS LSPs > different methods are generally called for. For > example, a distributed PCS approach would initially be > overkill, versus a centralized approach (not that many > LSPs to get set up that often) while if one is dealing > with lower rate MLPS LSPs a distributed PCS approach > (hopefully) would be more appropriate. Cheers, Adrian From owner-ccamp@ops.ietf.org Tue Apr 20 11:21:10 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24877 for ; Tue, 20 Apr 2004 11:21:09 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFx3f-0000Hg-3T for ccamp-archive@ietf.org; Tue, 20 Apr 2004 11:21:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFx2g-00000z-00 for ccamp-archive@ietf.org; Tue, 20 Apr 2004 11:20:11 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BFx1s-0007Yq-00 for ccamp-archive@ietf.org; Tue, 20 Apr 2004 11:19:20 -0400 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BFweL-000Jq0-UY for ccamp-data@psg.com; Tue, 20 Apr 2004 14:55:01 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BFwe3-000Jkc-4r for ccamp@ops.ietf.org; Tue, 20 Apr 2004 14:54:43 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23214; Tue, 20 Apr 2004 10:54:40 -0400 (EDT) Message-Id: <200404201454.KAA23214@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-gmpls-recovery-functional-02.txt Date: Tue, 20 Apr 2004 10:54:40 -0400 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : Generalized MPLS Recovery Functional Specification Author(s) : J. Lang, B. Rajagopalan Filename : draft-ietf-ccamp-gmpls-recovery-functional-02.txt Pages : 19 Date : 2004-4-19 This document presents a functional description of the protocol extensions needed to support GMPLS-based recovery (i.e. protection and restoration). Protocol specific formats and mechanisms will be described in companion documents. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-recovery-functional-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-recovery-functional-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-recovery-functional-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: <2004-4-20111538.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-gmpls-recovery-functional-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-gmpls-recovery-functional-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-4-20111538.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ccamp@ops.ietf.org Tue Apr 20 11:22:13 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24977 for ; Tue, 20 Apr 2004 11:22:13 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFx4g-0000Zf-Rb for ccamp-archive@ietf.org; Tue, 20 Apr 2004 11:22:14 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFx3l-0000Ij-00 for ccamp-archive@ietf.org; Tue, 20 Apr 2004 11:21:18 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BFx2w-00001n-00 for ccamp-archive@ietf.org; Tue, 20 Apr 2004 11:20:26 -0400 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BFwee-000JwZ-UC for ccamp-data@psg.com; Tue, 20 Apr 2004 14:55:20 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BFweF-000JnW-D4 for ccamp@ops.ietf.org; Tue, 20 Apr 2004 14:54:55 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23225; Tue, 20 Apr 2004 10:54:52 -0400 (EDT) Message-Id: <200404201454.KAA23225@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-gmpls-ason-reqts-06.txt Date: Tue, 20 Apr 2004 10:54:52 -0400 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --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 : Requirements for Generalized MPLS (GMPLS) Signaling Usage and Extensions for Automatically Switched Optical Network (ASON) Author(s) : D. Papadimitriou, et al. Filename : draft-ietf-ccamp-gmpls-ason-reqts-06.txt Pages : 14 Date : 2004-4-19 The Generalized MPLS (GMPLS) suite of protocol has been defined to control different switching technologies as well as different applications. These include support for requesting TDM connections including SONET/SDH and Optical Transport Networks (OTNs). This document concentrates on the signaling aspects of the GMPLS suite of protocols. It identifies the features to be covered by the GMPLS signalling protocol to support the capabilities of an Automatically Switched Optical Network (ASON). This document provides a problem statement and additional requirements on the GMPLS signaling protocol to support the ASON functionality. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-ason-reqts-06.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-ason-reqts-06.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-ason-reqts-06.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: <2004-4-20111614.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-gmpls-ason-reqts-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-gmpls-ason-reqts-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-4-20111614.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ccamp@ops.ietf.org Wed Apr 21 03:30:37 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00543 for ; Wed, 21 Apr 2004 03:30:37 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGCBo-0004cJ-Ew for ccamp-archive@ietf.org; Wed, 21 Apr 2004 03:30:36 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGCAy-0004XC-00 for ccamp-archive@ietf.org; Wed, 21 Apr 2004 03:29:48 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BGCAY-0004RH-00 for ccamp-archive@ietf.org; Wed, 21 Apr 2004 03:29:18 -0400 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BGBrV-0003ia-JB for ccamp-data@psg.com; Wed, 21 Apr 2004 07:09:37 +0000 Received: from [195.8.69.15] (helo=oceanus.uk.clara.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BGBrQ-0003i7-4X for ccamp@ops.ietf.org; Wed, 21 Apr 2004 07:09:32 +0000 Received: from claranet by oceanus.uk.clara.net with local (Exim 4.22) id 1BGBrS-0004TU-CI; Wed, 21 Apr 2004 08:09:34 +0100 From: "Adrian Farrel" To: ccamp@ops.ietf.org Cc: adrian@olddog.co.uk, wesam.alanqar@mail.sprint.com, dbrungard@att.com, dmm@1-4-5.net, LyOng@ciena.com, Dimitri.Papadimitriou@alcatel.be, jonathan.sadler@tellabs.com, sdshew@nortelnetworks.com Reply-To: adrian@olddog.co.uk Subject: Re: FW: I-D ACTION:draft-ietf-ccamp-gmpls-ason-routing-reqts-03.txt Date: Wed, 21 Apr 2004 08:08:35 +0100 Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=_0_17189_1082531367"; charset="iso-8859-1" X-Remote_Addr: 156.106.224.107 Message-Id: Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 This is a MIME-formatted message. If you see this text it means that your mail software cannot handle MIME-formatted messages. --=_0_17189_1082531367 Content-Type: text/plain; format=flowed; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Hi ASON Routing DT, Please find attached a marked up copy of the draft. All changes are typographical or nits. Thanks, Adrian ----- Original Message ----- From: "Kireeti Kompella" To: Sent: Thursday, April 15, 2004 12:46 AM Subject: Re: FW: I-D ACTION:draft-ietf-ccamp-gmpls-ason-routing-reqts-03.txt > Hi All, > > On Wed, 14 Apr 2004, Brungard, Deborah A, ALABS wrote: > > > The ASON Routing Reqts DT has updated the following draft based on > > ITU Q14/15's Liaison and CCAMP mail list comments. > > > > We recommend this document as ready for WG Last Call. > > This commences a two-week WG Last Call on the GMPLS ASON routing > requirements. Last Call ends April 28th, 5pm PDT. Please send your > comments to the list. > > The proposed category is Informational. > > Kireeti. --=_0_17189_1082531367 Content-Disposition: attachment; filename=draft-ietf-ccamp-gmpls-ason-routing-reqts-03-af.txt Content-Type: text/plain; charset="iso-8859-1"; name=draft-ietf-ccamp-gmpls-ason-routing-reqts-03-af.txt Content-Transfer-Encoding: 8bit CCAMP Working Group Wesam Alanqar (Sprint) Internet Draft Deborah Brungard (ATT) Category: Informational David Meyer (Cisco Systems) Lyndon Ong (Ciena) Expiration Date: October 2004 Dimitri Papadimitriou (Alcatel) Jonathan Sadler (Tellabs) Stephen Shew (Nortel) April 2004 Requirements for Generalized MPLS (GMPLS) Routing for Automatically Switched Optical Network (ASON) draft-ietf-ccamp-gmpls-ason-routing-reqts-03.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC-2026. 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. Abstract The Generalized MPLS (GMPLS) suite of protocols has been defined to control different switching technologies as well as different applications. These include support for requesting TDM connections including SONET/SDH and Optical Transport Networks (OTNs). This document concentrates on the routing requirements on the GMPLS suite of protocols to support the capabilities and functionalities for an Automatically Switched Optical Network (ASON) as defined by ITU-T. W.Alanqar et al. - Expires September 2004 1 ## Missing page throws draft-ietf-ccamp-gmpls-ason-routing-reqts-03.txt April 2004 Table of Contents Status of this Memo .............................................. 1 Abstract ......................................................... 1 1. Contributors .................................................. 2 2. Conventions used in this document ............................. 2 3. Introduction .................................................. 2 4. ASON Routing Architecture and Requirements .................... 4 4.1 Multiple Hierarchical Levels of ASON Routing Areas (RAs) ..... 5 4.2 Hierarchical Routing Information Dissemination ............... 5 4.3 Configuration ................................................ 7 4.3.1 Configuring the Multi-Level Hierarchy ...................... 7 4.3.2 Configuring RC Adjacencies ................................. 7 4.4 Evolution .................................................... 7 4.5 Routing Attributes ........................................... 8 4.5.1 Taxonomy of Routing Attributes ............................. 8 4.5.2 Commonly Advertised Information ............................ 9 4.5.3 Node Attributes ............................................ 9 4.5.4 Link Attributes ............................................ 9 5. Security Considerations ...................................... 11 6. Conclusions .................................................. 11 7. Acknowledgements ............................................. 13 8. Intellectual Property Considerations ......................... 13 8.1 IPR Disclosure Acknowledgement .............................. 13 9. References ................................................... 14 9.1 Normative References ........................................ 14 10. Author's Addresses .......................................... 14 Appendix 1: ASON Terminology .................................... 16 Appendix 2: ASON Routing Terminology ............................ 18 Full Copyright Statement ........................................ 19 1. Contributors This document is the result of the CCAMP Working Group ASON Routing Requirements design team joint effort. 2. Conventions used in this document 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 [RFC2119]. 3. Introduction The GMPLS suite of protocols provides among other capabilities support for controlling different switching technologies. These include support for requesting TDM connections utilizing SONET/SDH (see ANSI T1.105/ITU-T G.707) as well as Optical Transport Networks (OTN, see ITU-T G.709). However, there are certain capabilities that are needed to support the ITU-T G.8080 control plane architecture for Automatically Switched Optical Network (ASON). Therefore, it is W.Alanqar et al. - Expires October 2004 2 draft-ietf-ccamp-gmpls-ason-routing-reqts-03.txt April 2004 desirable to understand the corresponding requirements for the GMPLS protocol suite. The ASON control plane architecture is defined in [G.8080], ASON routing requirements are identified in [G.7715], and in [G.7715.1] for ASON link state protocols. These Recommendations apply to all G.805 layer networks (e.g. SDH and OTN), and provide protocol neutral functional requirements and architecture. This document focuses on the routing requirements for the GMPLS suite of protocols to support the capabilities and functionality of ASON control planes. This document summarizes the ASON requirements using ASON terminology. This document does not address GMPLS applicability or GMPLS capabilities. Any protocol (in particular, routing) applicability, design or suggested extensions is strictly outside the scope of this document. ASON (Routing) terminology sections are provided in Appendix 1 and 2. The ASON routing architecture is based on the following assumptions: - A network is subdivided based on operator decision and criteria (e.g. geography, administration, and/or technology), the network subdivisions are defined in ASON as Routing Areas (RAs). - The routing architecture and protocols applied after the network is subdivided is an operator's choice. A multi-level hierarchy of RAs, as defined in ITU-T [G.7715] and [G.7715.1], provides for a hierarchical relationship of RAs based on containment, i.e. child RAs are always contained within a parent RA. The hierarchical containment relationship of RAs provides for routing information abstraction, thereby enabling scalable routing information representation. The maximum number of hierarchical RA levels to be < supported is NOT specified (outside the scope). > supported is NOT specified (outside the scope of this document). - Within an ASON RA and for each level of the routing hierarchy, multiple routing paradigms (hierarchical, step- by-step, source- based), centralized or distributed path computation, and multiple different routing protocols MAY be supported. The architecture does NOT assume a one-to-one correspondence of a routing protocol and a RA level and allows the routing protocol(s) used within different RAs (including child and parent RAs) to be different. The realization of the routing paradigm(s) to support the hierarchical levels of RAs is NOT specified. - The routing adjacency topology (i.e. the associated Protocol Controller (PC) connectivity) and transport topology is NOT assumed to be congruent. - The requirements support architectural evolution, e.g. a change in the number of RA levels, as well as aggregation and segmentation of RAs. The description of the ASON routing architecture provides for a conceptual reference architecture, with definition of functional components and common information elements to enable end-to-end routing in the case of protocol heterogeneity and facilitate management of ASON networks. This description is only conceptual: no physical partitioning of these functions is implied. W.Alanqar et al. - Expires October 2004 3 draft-ietf-ccamp-gmpls-ason-routing-reqts-03.txt April 2004 4. ASON Routing Architecture and Requirements ## trivial: you have "a RA" also "an RP" The fundamental architectural concept is the RA and it's related functional components (see Appendix 2 on terminology). The routing services offered by a RA are provided by a Routing Performer (RP). An RP is responsible for a single RA, and it MAY be functionally realized using distributed Routing Controllers (RC). The RC, itself, MAY be implemented as a cluster of distributed entities (ASON refers to the cluster as a Routing Control Domain (RCD)). The RC components for a RA receive routing topology information from their associated Link Resource Manager(s) (LRMs) and store this information in the Routing Information Database (RDB). The RDB is replicated at each RC < bounded to the same Routing Area (RA), and MAY contain information > bounded to the same RA, and MAY contain information about multiple transport plane network layers. Whenever the routing topology changes, the LRM informs the corresponding RC, which in turn updates its associated RDB. In order to assure RDB synchronization, the RCs co-operate and exchange routing information. Path computation functions MAY exist in each RC, MAY exist on selected RCs within the same RA, or MAY be centralized for the RA. In this context, communication between RCs within the same RA is realized using a particular routing protocol (or multiple protocols). In ASON, the communication component is represented by the protocol controller (PC) component(s) and the protocol messages are conveyed over the ASON control plane's Signaling Control Network (SCN). The PC MAY convey information for one or more transport network layers (refer to Section 4.2 Note). The RC is protocol independent and RC communications MAY be realized by multiple, different PCs within a RA. The ASON routing architecture defines a multi-level routing hierarchy of RAs based on a containment model to support routing information abstraction. [G.7715.1] defines the ASON hierarchical link state routing protocol requirements for communication of routing information within an RA (one level) to support hierarchical routing information dissemination (including summarized routing information for other levels). The Communication between any of the other functional component(s) (e.g. SCN, LRM, and between RCDs (RC- RC communication between RAs)), is outside the scope of [G.7715.1] protocol requirements and, thus, is also outside the scope of this document. ASON Routing components are identified by identifiers that are drawn from different name spaces (see [G.7715.1]). These are control plane identifiers for transport resources, components, and SCN addresses. The formats of those identifiers in a routing protocol realization SHALL be implementation specific and outside the scope of this document. The failure of a RC, or the failure of communications between RCs, < and the subsequent recover from the failure condition MUST NOT > and the subsequent recovery from the failure condition MUST NOT W.Alanqar et al. - Expires October 2004 4 draft-ietf-ccamp-gmpls-ason-routing-reqts-03.txt April 2004 disrupt calls in progress and their associated connections. Calls being set up MAY fail to complete, and the call setup service MAY be unavailable during recovery actions. 4.1 Multiple Hierarchical Levels of ASON Routing Areas (RAs) [G.8080] introduces the concept of Routing Area (RA) in reference to a network subdivision. RAs provide for routing information abstraction. Except for the single RA case, RAs are hierarchically contained: a higher level (parent) RA contains lower level (child) RAs that in turn MAY also contain RAs, etc. Thus, RAs contain RAs that recursively define successive hierarchical RA levels. However, the RA containment relationship describes only an architectural hierarchical organization of RAs. It does not restrict a specific routing protocol's realization (e.g. OSPF multi-areas, path computation, etc.). Moreover, the realization of the routing paradigm to support a hierarchical organization of RAs and the number of hierarchical RA levels to be supported is routing protocol specific and outside the scope of this document. In a multi-level hierarchy of RAs, it is necessary to distinguish among RCs for the different levels of the RA hierarchy. Before any pair of RCs establishes communication, they MUST verify they are < bounded to the same parent RA (see Section 4.2). A RA identifier (RA > bound to the same parent RA (see Section 4.2). A RA identifier (RA ID) is required to provide the scope within which the RCs can < communicate. To distinguish between RCs bounded to the same RA, an > communicate. To distinguish between RCs bound to the same RA, an RC identifier (RC ID) is required; the RC ID MUST be unique within its containing RA. < A RA represents a partition of the data plane and its identifier > A RA represents a partition of the data plane, and its identifier (i.e. RA ID) is used within the control plane as a reference to the < data plane partition. Each RA SHALL be uniquely identifiable within < a carrier's network. RA IDs MAY be associated with a transport plane > data plane partition. Each RA within a carrier's network SHALL be > uniquely identifiable. RA IDs MAY be associated with a transport plane name space whereas RC IDs are associated with a control plane name space. 4.2 Hierarchical Routing Information Dissemination < Routing information can be exchanged between RCs bounded to adjacent > Routing information can be exchanged between RCs bound to adjacent levels of the RA hierarchy i.e. Level N+1 and N, where Level N represents the RAs contained by Level N+1. The links connecting RAs MAY be viewed as external links (inter-RA links), and the links representing connectivity within a RA MAY be viewed as internal links (intra-RA links). The external links to a RA at one level of the hierarchy may be internal links in the parent RA. Intra-RA links of a child RA MAY be hidden from the parent RA's view. The physical location of RCs for adjacent RA levels, their relationship and their communication protocol(s) are outside the scope of this document. No assumption is made regarding how RCs communicate between adjacent RA levels. If routing information is W.Alanqar et al. - Expires October 2004 5 draft-ietf-ccamp-gmpls-ason-routing-reqts-03.txt April 2004 exchanged between a RC, its parent, and its child RCs, it SHOULD include reachability and MAY include (upon policy decision) node and < link topology. Only the RCs of the parent RA communicate, RCs of one < childÆs RA never communicate with the RCs of other child RAs. There > link topology. Communication between RAs only takes place between > RCs with a parent/child relationship. RCs of one RA never communicate > with RCs of another RA at the same level. There SHOULD not be any dependencies on the different routing protocols used within a RA or in different RAs. < Multiple RCs bounded to the same RA MAY transform (filter, > Multiple RCs bound to the same RA MAY transform (filter, summarize, etc.) and then forward information to RCs at different levels. However in this case the resulting information at the receiving level must be self-consistent; this MAY be achieved using a number of mechanisms. Note: there is no implied relationship between multi-layer transport networks and multi-level routing. Implementations may support a hierarchical routing topology (multi-level) with a single routing protocol instance for multiple transport switching layers or a hierarchical routing topology for one transport switching layer. 1. Type of Information Exchanged The type of information flowing upward (i.e. Level N to Level N+1) and the information flowing downward (i.e. Level N+1 to Level N) are used for similar purposes, namely, the exchange of reachability information and summarized topology information to allow routing across multiple RAs. The summarization of topology information may impact the accuracy of routing and MAY require additional path calculation. < The following information exchange are expected: > The following information exchanges are expected: - Level N+1 visibility to Level N reachability and topology (or upward information communication) allowing RC(s) at Level N+1 to determine the reachable endpoints from Level N. - Level N visibility to Level N+1 reachability and topology (or downward information communication) allowing RC(s) bounded to a RA at Level N to develop paths to reachable endpoints outside of the RA. 2. Interactions between Upward and Downward Communication When both upward and downward information exchanges contain endpoint reachability information, a feedback loop could potentially be created. Consequently, the routing protocol MUST include a method to: - prevent information propagated from a Level N+1 RA's RC into < the Level N RA's RC to be re-introduced into the Level N+1 RA's < RC, and > the Level N RA's RC from being re-introduced into the Level N+1 > RA's RC, and - prevent information propagated from a Level N-1 RA's RC into < the Level N RA's RC to be re-introduced into the Level N-1 RA's > the Level N RA's RC from being re-introduced into the Level N-1 RA's W.Alanqar et al. - Expires October 2004 6 draft-ietf-ccamp-gmpls-ason-routing-reqts-03.txt April 2004 RC. The routing protocol SHALL differentiate the routing information originated at a given level RA from derived routing information (received from external RAs), even when this information is forwarded by another RC at the same level. This is a necessary condition to be fulfilled by routing protocols to be loop free. 3. Method of Communication Two approaches exist for communication between Level N and N+1. - The first approach places an instance of a Level N routing function and an instance of a Level N+1 routing function in the same system. The communications interface is within a single system and is thus not an open interface subject to standardization. - The second approach places the Level N routing function on a separate system from the Level N+1 routing function. In this case, a communication interface must be used between the systems containing the routing functions for different levels. This communication interface and mechanisms are outside the scope of this document. 4.3 Configuration 4.3.1 Configuring the Multi-Level Hierarchy The RC MUST support static (i.e. operator assisted) and MAY support automated configuration of the information describing its < relationship to parent and its child within the hierarchical > relationship to its parent and its children within the hierarchical structure (including RA ID and RC ID). When applied recursively, the whole hierarchy is thus configured. 4.3.2 Configuring RC Adjacencies The RC MUST support static (i.e. operator assisted) and MAY support automated configuration of the information describing its associated > PC adjacencies to other RCs bounded to the same parent RA. The < PC adjacencies to other RCs bound to the same parent RA. The ## Do you really mean PC or RC? routing protocol SHOULD support all the types of RC adjacencies described in Section 9 of [G.7715]. The latter includes congruent topology (with distributed RC) and hubbed topology (e.g. note that the latter does not automatically imply designated RC). 4.4 Evolution The containment relationships of RAs MAY change, motivated by events such as mergers, acquisitions, and divestitures. The routing protocol SHOULD be capable of supporting architectural evolution in terms of number of hierarchical levels of RAs, as well W.Alanqar et al. - Expires October 2004 7 draft-ietf-ccamp-gmpls-ason-routing-reqts-03.txt April 2004 < as aggregation and segmentation of RAs. RA IDs uniqueness within an > as aggregation and segmentation of RAs. RA ID uniqueness within an administrative domain MAY facilitate these operations. The routing protocol is not expected to automatically initiate and/or execute these operations. Reconfiguration of the RA hierarchy MAY not ## Surely this is MUST? disrupt calls in progress, though calls being set up may fail to complete, and the call setup service may be unavailable during reconfiguration actions. 4.5 Routing Attributes Routing for transport networks is performed on a per layer basis, where the routing paradigms MAY differ among layers and within a < layer. Not all equipment support the same set of transport layers or > layer. Not all equipment supports the same set of transport layers or the same degree of connection flexibility at any given layer. A server layer trail may support various clients, involving different adaptation functions. Additionally, equipment may support variable adaptation functionality, whereby a single server layer trail dynamically supports different multiplexing structures. As a result, routing information MAY include layer specific, layer independent, and client/server adaptation information. 4.5.1 Taxonomy of Routing Attributes Attributes can be organized according to the following categories: - Node related or link related - Provisioned, negotiated or automatically configured - Inherited or layer specific (client layers can inherit some attributes from the server layer while other attributes like Link Capacity are specified by layer). (Component) link attributes MAY be statically or automatically configured for each transport network layer. This may lead to unnecessary repetition. Hence, the inheritance property of attributes MAY also be used to optimize the configuration process. < ASON uses the term, SNP, for the control plane representation of a > ASON uses the term, Subnetwork Point (SNP), for the control plane representation of a transport plane resource. The control plane representation and transport plane topology is NOT assumed to be congruent, the control plane representation SHALL not be restricted by the physical topology. The relational grouping of SNPs for routing is termed a < SNPP. The routing function understands topology in terms of SNPP > SNP Pool (SNPP). The routing function understands topology in terms of SNPP links. Grouping MAY be based on different link attributes (e.g., SRLG information, link weight, etc). Two RAs may be linked by one or more SNPP links. Multiple SNPP links MAY be required when component links are not equivalent for routing purposes with respect to the RAs they are attached to, or to the containing RA, or when smaller groupings are required. W.Alanqar et al. - Expires October 2004 8 draft-ietf-ccamp-gmpls-ason-routing-reqts-03.txt April 2004 4.5.2 Commonly Advertised Information Advertisements MAY contain the following common set of information regardless of whether they are link or node related: < - RA ID of which the advertisement is bounded > - RA ID of the RA to which the advertisement is bound - RC ID of the entity generating the advertisement - Information to uniquely identify advertisements - Information to determine whether an advertisement has been updated - Information to indicate when an advertisement has been derived from a different level RA. 4.5.3 Node Attributes All nodes belong to a RA, hence, the RA ID can be considered an attribute of all nodes. Given that no distinction is made between abstract nodes and those that cannot be decomposed any further, the same attributes MAY be used for their advertisement. In the < following tables, Capability refers to level of support required in > following tables, Capability refers to the level of support required in the realization of a link state routing protocol, whereas Usage < refers to degree of operational and implementation flexibility. > refers to the degree of operational and implementation flexibility. The following Node Attributes are defined: Attribute Capability Usage ----------- ----------- --------- Node ID REQUIRED REQUIRED Reachability REQUIRED OPTIONAL Table 1. Node Attributes Reachability information describes the set of endpoints that are reachable by the associated node. It MAY be advertised as a set of associated external (e.g. UNI) address/address prefixes or a set of associated SNPP link IDs/SNPP ID prefixes, the selection of which MUST be consistent within the applicable scope. These are control plane identifiers, the formats of these identifiers in a protocol realization is implementation specific and outside the scope of this document. Note: no distinction is made between nodes that may have further internal details (i.e., abstract nodes) and those that cannot be < decomposed any further. Hence the attributes of a node are not be > decomposed any further. Hence the attributes of a node are not considered only as single switch attributes but MAY apply to a node at a higher level of the hierarchy that represents a sub-network. 4.5.4 Link Attributes The following Link Attributes are defined: Link Attribute Capability Usage --------------- ----------- --------- Local SNPP link ID REQUIRED REQUIRED W.Alanqar et al. - Expires October 2004 9 draft-ietf-ccamp-gmpls-ason-routing-reqts-03.txt April 2004 Remote SNPP link ID REQUIRED REQUIRED Layer Specific Characteristics see Table 3 Table 2. Link Attributes The SNPP link ID name MUST be sufficient to uniquely identify the ## Why do you say "SNPP link ID name"? This is not defined. ## Do you mean "SNPP link ID"? corresponding transport plane resource taking into account separation of data and control planes (see Section 4.5.1, the control plane representation and transport plane topology is not assumed to be congruent). The SNPP link ID format is routing protocol specific. Note: when the remote end of a SNPP link is located outside of the RA, the remote SNPP link ID is OPTIONAL. The following link characteristic attributes are defined: - Signal Type: This identifies the characteristic information of the layer network. - Link Weight: The metric indicating the relative desirability of a particular link over another e.g. during path computation. - Resource Class: This corresponds to the set of administrative groups assigned by the operator to this link. A link MAY belong to zero, one or more administrative groups. - Connection Types: This attribute identifies whether the local SNP represents a TCP, CP, or can be flexibly configured as a TCP. ## Please expand TCP and CP in their first uses - Link Capacity: This provides the sum of the available and potential bandwidth capacity for a particular network transport layer. Other capacity measures MAY be further considered. - Link Availability: This represents the survivability capability such as the protection type associated with the link. - Diversity Support: This represents diversity information such as the SRLG information associated with the link. - Local Adaptation Support: This indicates the set of client layer adaptations supported by the TCP associated with the Local SNPP. This is only applicable when the local SNP represents a TCP or can be flexibly configured as a TCP. Link Characteristics Capability Usage ----------------------- ---------- --------- Signal Type REQUIRED OPTIONAL Link Weight REQUIRED OPTIONAL Resource Class REQUIRED OPTIONAL Local Connection Types REQUIRED OPTIONAL Link Capacity REQUIRED OPTIONAL W.Alanqar et al. - Expires October 2004 10 draft-ietf-ccamp-gmpls-ason-routing-reqts-03.txt April 2004 Link Availability OPTIONAL OPTIONAL Diversity Support OPTIONAL OPTIONAL Local Adaptation support OPTIONAL OPTIONAL Table 3. Link Characteristics Note: separate advertisements of layer specific attributes MAY be < chosen. However this may lead to unnecessary duplication. This can > chosen. However, this may lead to unnecessary duplication. This can be avoided using the inheritance property, so that the attributes derivable from the local adaptation information do not need to be advertised. Thus, an optimization MAY be used when several layers are present by indicating when an attribute is inheritable from a server layer. 5. Security Considerations ASON routing protocol MUST deliver the operational security objectives where required. These objectives do not necessarily imply requirements on the routing protocol itself, and MAY be met by other established means. 6. Conclusions The description of the ASON routing architecture and components is provided in terms of routing functionality. This description is only conceptual: no physical partitioning of these functions is implied. In summary, the ASON routing architecture assumes: - A network is subdivided into ASON RAs, which MAY support multiple routing protocols, no one-to-one relationship SHALL be assumed - Routing Controllers (RC) provide for the exchange of routing information (primitives) for the RA. The RC is protocol independent and MAY be realized by multiple, different protocol controllers within a RA. The routing information exchanged between RCs SHALL be subject to policy constraints imposed at reference points (External- and Internal-NNI) < - A multi-level RA hierarchy based on containment, only the RCs of < the parent RA communicate. RCs of child RAs never communicate with > - In a multi-level RA hierarchy based on containment, communication > between RCs of different RAs only happens when there is a parent/ > child relationship between the RAs. RCs of child RAs never communicate with the RCs of other child RAs. There SHOULD not be any dependencies on the different routing protocols used within a child RA and that of its parent. The routing information exchanged within the parent RA SHALL be independent of both the routing protocol operating within a child RA, and any control distribution choice(s), e.g. centralized, fully distributed. - For a RA, the set of RCs is referred to as an ASON routing (control) domain. The routing information exchanged between routing domains (inter-RA, i.e. inter-domain) SHALL be independent of both the intra-domain routing protocol(s), and the intra-domain control distribution choice(s), e.g. centralized, fully distributed. RCs bounded to different RA levels MAY be co-located within the same physical element or physically distributed. - The routing adjacency topology (i.e. the associated PC W.Alanqar et al. - Expires October 2004 11 draft-ietf-ccamp-gmpls-ason-routing-reqts-03.txt April 2004 connectivity topology) and the transport network topology SHALL NOT be assumed to be congruent - The routing topology SHALL support multiple links between nodes and RAs In summary, the following functionality is expected from GMPLS routing to instantiate the ASON hierarchical routing architecture realization (see [G.7715] and [G.7715.1]): - RAs SHALL be uniquely identifiable within a carrier's network, each having a unique RA ID within the carrier's network. - Within a RA (one level), the routing protocol SHALL support dissemination of hierarchical routing information (including summarized routing information for other levels) in support of an architecture of multiple hierarchical levels of RAs; the number of hierarchical RA levels to be supported by a routing protocol is implementation specific. - The routing protocol SHALL support routing information based on a common set of information elements as defined in [G.7715] and [G.7715.1], divided between attributes pertaining to links and abstract nodes (each representing either a sub-network or simply a node). [G.7715] recognizes that the manner in which the routing information is represented and exchanged will vary with the routing protocol used. - The routing protocol SHALL converge such that the distributed RDBs become synchronized after a period of time. To support hierarchical routing information dissemination within an RA, the routing protocol MUST deliver: < - processing of routing information exchanged between adjacent > - 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 < - when multiple RCs bound to a RA transform (filter, summarize, < etc.) and then forward information to RC(s) at different levels < that the resulting information at the receiving level is self- < consistent > - Self-consistent information at the receiving level resulting from > any transformation (filter, summarize, etc.) and forwarding of > information from one RC to RC(s) at different levels when multiple > RCs bound to a single RA < - a mechanism to prevent re-introduction of information propagated > - A mechanism to prevent re-introduction of information propagated into the Level N RA's RC back to the adjacent level RA's RC from which this information has been initially received. In order to support operator assisted changes in the containment relationships of RAs, the routing protocol SHALL support evolution < in terms of number of hierarchical levels of RAs. Example: support > in terms of number of hierarchical levels of RAs. For example: support of non-disruptive operations such as adding and removing RAs at the top/bottom of the hierarchy, adding or removing a hierarchical level of RAs in or from the middle of the hierarchy, as well as aggregation and segmentation of RAs. The number of hierarchical levels to be supported is routing protocol specific, and reflects a containment relationship e.g. a RA insertion involves supporting a different routing protocol domain in a portion of the network. W.Alanqar et al. - Expires October 2004 12 draft-ietf-ccamp-gmpls-ason-routing-reqts-03.txt April 2004 Reachability information (see Section 4.5.3) of the set of endpoints reachable by a node may be advertised either as a set of UNI Transport Resource addresses/ address prefixes, or a set of associated SNPP link IDs/SNPP link ID prefixes, assigned and selected consistently in their applicability scope. The formats of the control plane identifiers in a protocol realization are implementation specific. Use of a routing protocol within a RA should not restrict the choice of routing protocols for use in other RAs (child or parent). 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 sub-network or RA MUST be able to represent itself to the wider network as a single logical entity with only its external links visible to the topology database. 7. Acknowledgements The authors would like to thank Kireeti Kompella for having initiated the proposal of an ASON Routing Requirement Design Team. ## Perhaps it would be good to acknowledge any other contributors you had. ## In particular SG14/15 for their careful review and input. 8. Intellectual Property Considerations 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. 8.1 IPR Disclosure Acknowledgement By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. W.Alanqar et al. - Expires October 2004 13 draft-ietf-ccamp-gmpls-ason-routing-reqts-03.txt April 2004 9. References 9.1 Normative References [RFC2026] S.Bradner, "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [RFC2119] S.Bradner, "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [G.7715] ITU-T Rec. G.7715/Y.1306, "Architecture and Requirements for the Automatically Switched Optical Network (ASON)," June 2002. [G.7715.1] ITU-T Draft Rec. G.7715.1/Y.1706.1, "ASON Routing Architecture and Requirements for Link State Protocols," November 2003. [G.8080] ITU-T Rec. G.8080/Y.1304, "Architecture for the Automatically Switched Optical Network (ASON)," November 2001 (and Revision, January 2003). [HIER] K.Kompella and Y.Rekhter, "LSP Hierarchy with Generalized MPLS TE," Internet draft (work in progress), draft-ietf-mpls-lsp-hierarchy, September 02. ## Would it be OK to make the external references informative? 10. Author's Addresses Wesam Alanqar (Sprint) EMail: wesam.alanqar@mail.sprint.com Deborah Brungard (AT&T) Rm. D1-3C22 - 200 S. Laurel Ave. Middletown, NJ 07748, USA Phone: +1 732 4201573 EMail: dbrungard@att.com David Meyer (Cisco Systems) EMail: dmm@1-4-5.net Lyndon Ong (Ciena Corporation) 5965 Silver Creek Valley Rd, San Jose, CA 95128, USA Phone: +1 408 8347894 EMail: lyong@ciena.com Dimitri Papadimitriou (Alcatel) Francis Wellensplein 1, B-2018 Antwerpen, Belgium Phone: +32 3 2408491 EMail: dimitri.papadimitriou@alcatel.be W.Alanqar et al. - Expires October 2004 14 draft-ietf-ccamp-gmpls-ason-routing-reqts-03.txt April 2004 Jonathan Sadler 1415 W. Diehl Rd Naperville, IL 60563 EMail: jonathan.sadler@tellabs.com Stephen Shew (Nortel Networks) PO Box 3511 Station C Ottawa, Ontario, CANADA K1Y 4H7 Phone: +1 613 7632462 EMail: sdshew@nortelnetworks.com W.Alanqar et al. - Expires October 2004 15 draft-ietf-ccamp-gmpls-ason-routing-reqts-03.txt April 2004 Appendix 1: ASON Terminology This document makes use of the following terms: Administrative domain: (Recommendation G.805 For the purposes of [G7715.1] an administrative domain represents the extent of resources which belong to a single player such as a network operator, a service provider, or an end-user. Administrative domains of different players do not overlap amongst themselves. Control plane: performs the call control and connection control functions. Through signaling, the control plane sets up and releases connections, and may restore a connection in case of a failure. (Control) Domain: represents a collection of (control) entities that are grouped for a particular purpose. The control plane is subdivided into domains matching administrative domains. Within an administrative domain, further subdivisions of the control plane are recursively applied. A routing control domain is an abstract entity that hides the details of the RC distribution. External NNI (E-NNI): interfaces are located between protocol controllers between control domains. Internal NNI (I-NNI): interfaces are located between protocol controllers within control domains. Link: [See Recommendation G.805] a "topological component" which describes a fixed relationship between a "subnetwork" or "access group" and another "subnetwork" or "access group". Links are not limited to being provided by a single server trail. Management plane: performs management functions for the Transport Plane, the control plane and the system as a whole. It also provides coordination between all the planes. The following management functional areas are performed in the management plane: performance, fault, configuration, accounting and security management Management domain: [See Recommendation G.805] A management domain defines a collection of managed objects which are grouped to meet organizational requirements according to geography, technology, policy or other structure, and for a number of functional areas such as configuration, security, (FCAPS), for the purpose of providing control in a consistent manner. Management domains can be disjoint, contained or overlapping. As such the resources within an administrative domain can be distributed into several possible overlapping management domains. The same resource can therefore belong to several management domains simultaneously, but a management domain shall not cross the border of an administrative domain. W.Alanqar et al. - Expires October 2004 16 draft-ietf-ccamp-gmpls-ason-routing-reqts-03.txt April 2004 SNP: The SNP is a control plane abstraction that represents an actual or potential transport plane resource. SNPs (in different subnetwork partitions) may represent the same transport resource. A one-to-one correspondence should not be assumed. ## Add SNPP ## Add TCP Transport plane: provides bi-directional or unidirectional transfer of user information, from one location to another. It can also provide transfer of some control and network management information. The Transport Plane is layered; it is equivalent to the Transport Network defined in G.805. User Network Interface (UNI): interfaces are located between protocol controllers between a user and a control domain. Note: there is no routing function associated with a UNI reference point. W.Alanqar et al. - Expires October 2004 17 draft-ietf-ccamp-gmpls-ason-routing-reqts-03.txt April 2004 Appendix 2: ASON Routing Terminology This document makes use of the following terms: Routing Area (RA): a RA represents a partition of the data plane and its identifier is used within the control plane as the representation of this partition. Per [G.8080] a RA is defined by a set of sub-networks, the TE links that interconnect them, and the interfaces representing the ends of the TE links exiting that RA. A RA may contain smaller RAs inter-connected by TE links. The limit of subdivision results in a RA that contains two sub-networks and a TE link with a single component link. Routing Database (RDB): repository for the local topology, network topology, reachability, and other routing information that is updated as part of the routing information exchange and may additionally contain information that is configured. The RDB may contain routing information for more than one Routing Area (RA). Routing Components: ASON routing architecture functions. These functions can be classified as protocol independent (Link Resource Manager or LRM, Routing Controller or RC) and protocol specific (Protocol Controller or PC). Routing Controller (RC): handles (abstract) information needed for routing and the routing information exchange with peering RCs by operating on the RDB. The RC has access to a view of the RDB. The RC is protocol independent. Note: Since the RDB may contain routing information pertaining to multiple RAs (and possibly to multiple layer networks), the RCs accessing the RDB may share the routing information. Link Resource Manager (LRM): supplies all the relevant component and TE link information to the RC. It informs the RC about any state changes of the link resources it controls. Protocol Controller (PC): handles protocol specific message exchanges according to the reference point over which the information is exchanged (e.g. E-NNI, I-NNI), and internal exchanges with the RC. The PC function is protocol dependent. W.Alanqar et al. - Expires October 2004 18 draft-ietf-ccamp-gmpls-ason-routing-reqts-03.txt April 2004 Full Copyright Statement ## Require new copyright boilerplate Copyright (C) The Internet Society (2004). 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 translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. W.Alanqar et al. - Expires October 2004 19 --=_0_17189_1082531367-- From owner-ccamp@ops.ietf.org Wed Apr 21 12:09:54 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29506 for ; Wed, 21 Apr 2004 12:09:54 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGKIO-0001WF-A8 for ccamp-archive@ietf.org; Wed, 21 Apr 2004 12:09:56 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGKHP-0001L6-00 for ccamp-archive@ietf.org; Wed, 21 Apr 2004 12:08:58 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BGKGT-0001AV-00 for ccamp-archive@ietf.org; Wed, 21 Apr 2004 12:07:57 -0400 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BGJtw-000Jj3-D0 for ccamp-data@psg.com; Wed, 21 Apr 2004 15:44:40 +0000 Received: from [195.8.69.15] (helo=oceanus.uk.clara.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BGJtk-000Jho-UZ for ccamp@ops.ietf.org; Wed, 21 Apr 2004 15:44:29 +0000 Received: from claranet by oceanus.uk.clara.net with local (Exim 4.22) id 1BGJto-00033U-HA; Wed, 21 Apr 2004 16:44:32 +0100 From: "Adrian Farrel" To: ccamp@ops.ietf.org, jvasseur@cisco.com Cc: adrian@olddog.co.uk Reply-To: adrian@olddog.co.uk Subject: Re: Draft draft-vasseur-ccamp-loose-path-reopt-01.txt Date: Wed, 21 Apr 2004 16:42:56 +0100 Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=_0_11699_1082562266"; charset="iso-8859-1" X-Remote_Addr: 156.106.224.107 Message-Id: Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,LINES_OF_YELLING, LINES_OF_YELLING_2 autolearn=no version=2.60 This is a MIME-formatted message. If you see this text it means that your mail software cannot handle MIME-formatted messages. --=_0_11699_1082562266 Content-Type: text/plain; format=flowed; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Hi JP, Please find attached a version of your draft with a bunch of comments, nits and questions. Cheers, Adrian PS Please see RFC3667 for new copyright and IPR boilerplate (or use one of the IETF editing tools) ----- Original Message ----- From: "Jean Philippe Vasseur" To: Sent: Tuesday, April 20, 2004 4:08 AM Subject: Draft draft-vasseur-ccamp-loose-path-reopt-01.txt > Hi, > > Just to mention that we posted a new revision of > draft-vasseur-ccamp-loose-path-reopt-01.txt that proposes some mechanisms > for the reoptimization of loosely routed TE LSP (intra-area, inter-area and > Inter-AS). Thanks for the various comments and support that we got on this > ID, this new revision incorporates the comments that we received + various > edits and clarifications. > > JP. --=_0_11699_1082562266 Content-Disposition: attachment; filename=draft-vasseur-ccamp-loose-path-reopt-01-af.txt Content-Type: text/plain; charset="iso-8859-1"; name=draft-vasseur-ccamp-loose-path-reopt-01-af.txt Content-Transfer-Encoding: 8bit ## please don't have header on first page draft-vasseur-ccamp-loose-path-reopt-01.txt April 2004 IETF Internet Draft Jean-Philippe Vasseur (Editor) Proposed Status : Standard Cisco Systems, Inc Expires: October 2004 Yuichi Ikejiri NTT Communications Corporation April 2004 draft-vasseur-ccamp-loose-path-reopt-01.txt Reoptimization of MPLS Traffic Engineering loosely routed LSP paths ## I really don't like "LSP path" ## "Label Switched Path path" ## How long before we write "LSPP"? ## Then we can introduce "LSPP path"! :-) ## Applies throughout the document. ## ## Can we mainly delete "path". I.e. "Loosely routed LSPs" or ## "LSP loose route" or "loose LSP route" Status of this Memo ## Please indent text correctly throughout document This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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. Vasseur and Ikejiri 1 ## please use page throws draft-vasseur-ccamp-loose-path-reopt-01.txt April 2004 ## Please place abstract before contents Table of content 1. Introduction 2. Establishment of a loosely routed TE LSP 3. Reoptimization of a loosely routed TE LSP path 4. Signalling extensions 4.1 ERO expansion signaling request 4.2 New Path Error sub-codes 5. Mode of operation 5.1 Head-end reoptimization control 5.2 Reoptimization triggers 5.3 Head-end request versus mid-point explicit notification modes 5.3.1 Head-end request mode 5.3.2 Mid-point explicit notification mode 5.3.3 ERO cashing 6. Interoperability 7. Security considerations 8. Acknowledgments 9. Intellectual property Abstract ## This abstract is a little long. Normally aim for about 10 lines. ## Probably OK, however. This document defines a mechanism for the reoptimization of MPLS Traffic Engineering loosely routed LSP paths. A loosely routed LSP path is a path specified as a combination of strict and loose hop(s) that contains at least one loose hop and zero or more strict hop(s). The path calculation (which implies an ERO expansion) to reach a loose hop is performed by the previous hop defined in the TE LSP path. This document proposes a mechanism that allows: ## Why is this draft limited to "loose" hops ## Surely strict hops that are non-specific abstract nodes are also ## important. For example, if I have an AS number in my ERO I might not ## use a loose hop, but reoptimization would still be important. - The TE LSP head-end LSR to trigger a new ERO expansion on every hop having a next hop defined as a loose hop, - A mid-point LSR to signal to the head-end LSR that either a better path exists to reach a loose hop (compared to the current path in use) or that the TE LSP must be reoptimized because of some maintenance required on the TE LSP path. A better path is defined as a lower cost path, where the cost is determined by the metric used to compute the path. The proposed mechanism applies to intra-domain and inter-domain packet and non-packet TE LSPs when the path is defined as a list of loose hops. Examples of domains are IGP areas and Autonomous Systems. 1. Introduction The Traffic Engineering Work Group has specified a set of requirements for inter-area [INTER-AREA-TE-REQ] and inter-AS [INTER-AS-TE-REQ] MPLS Traffic Engineering. Both requirements documents specify the need for ## well they say "SHOULD", not "MUST" some mechanism providing an option for the head-end to control the Vasseur and Ikejiri 2 draft-vasseur-ccamp-loose-path-reopt-01.txt April 2004 reoptimization process, should a more optimal path exist in a downstream domain (IGP area or Autonomous System). This document defines a solution to meet this requirement, in addition >to a mechanism to discover the existence of such a more optimal path ## Is this true? Do you discover the existence of a more optimal path or ## do you inform the head-end the of the existence of a more optimal ## path? ## So you should say "a mechanism to communicate the existence of a ## more optimal path or a request to reoptimize..." or the need to reoptimize due to some maintenance required in a downstream domain. ## Do you need to describe what you mean by "reoptimize"? ## In particular, you mean "...re-signal the LSP using a new LSP Id ## so that the LSP can be re-routed onto a more optimal (or simply ## different) path with minimal disruption to traffic. In particular, ## re-optimaization SHOULD NOT use a simple change to the ERO of the ## existing LSP because this may adversely impact traffic. The reasons ## for not using a change to the ERO are explained further in section x" 2. Establishment of a loosely routed TE LSP A loosely routed explicit path is a path specified as a combination of strict and loose hop(s) that contains at least one loose hop and a set of zero or more strict hop(s). Loose hops are listed in the ERO object of the RSVP Path message with the L flag of the IPv4 or the IPv6 prefix sub-object set, as defined in [RSVP-TE]. In this case, each LSR along the path whose next hop is specified as a loose hop triggers a path computation (also referred to as an ERO expansion), before forwarding ## You see, ERO expansion also refers to the expansion of abstract nodes ## Also what about when there are no loose hops, but the ERO does not go ## as far as the egress? Surely you want to include this, too. the RSVP Path message downstream. The path computation may either be performed by means of CSPF or any Path Computation Element (PCE) and can be partial (up to the next loose hop) and complete (up to the TE LSP destination). ## Note that whil *I* agree with your point here, this directly goes ## against 3209 which says that expansion is (at most) only as far as ## the next specified hop (loose or strict). ## I think that you need to explain the fact that you are extending the ## definition of 3209. Note that the examples in the rest of this document are provided in the context of MPLS inter-area TE but the proposed mechanism equally applies to loosely routed explicit paths within a single routing domain and across multiple Autonomous Systems. The examples below are provided with OSPF as the IGP but the described set of mechanisms similarly apply to IS-IS. ## Make the following into section 2.1 An example of an explicit loosely routed TE LSP signaling. <---area 1--><-area 0--><-area 2-> < R1---R2----R3---R6 R8-----R10 < | | | / |\ | < | | | -- | --\ | < | | |/ | \| < R4---------R5---R7----R9-----R11 > R1---R2----R3---R6 R8----R10 > | | | / |\ | > | | | / | \ | > | | | / | \ | > | | |/ | \| > R4---------R5---R7----R9----R11 Assumptions - R3, R5, R8 and R9 are ABRs <- The path an inter-area TE LSP T1 from R1 (head-End LSR) to R11 (tail- >- The path of an inter-area TE LSP T1 from R1 (head-End LSR) to R11 (tail- end LSR) is defined on R1 as the following loosely routed path: R1- R3(loose)-R8(loose)-R11(loose). R3, R8 and R11 are defined as loose hops. ## In step 3 you say how R3 determines how to expand the ERO. Why do you ## not say how R1 determines the ERO in step 1? Step 1: R1 builds the following ERO object: R1(S)-R2(S)-R3(S)-R8(L)- R11(L) where: S: Strict hop (L=0) L: Loose hop (L=1) Vasseur and Ikejiri 3 draft-vasseur-ccamp-loose-path-reopt-01.txt April 2004 The R1-R2-R3 path obeys T1Æs set of constraints ## Bad character in text Step 2: the RSVP Path message is then forwarded by R1 following the ERO path and reaches R3 with the following content: R8(L)-R11(L) Step 3: R3 determines that the next hop (R8) is a loose hop (not directly connected to R3) and then performs an ERO expansion operation ## Actually, even if it was directly connected, if it is a loose hop ## we should do a CSPF computation. We don't necessarily want to go ## on the direct link. to reach the next loose hops R8 either by means of CSPF or any other PCE-based path computation method. The new ERO becomes: R6(S)-R7(S)- R8(S)-R11(L) Note: in this example, the assumption is made that the path is computed on a per loose hop basis, also referred to a partial route computation. Note that PCE-based mechanisms may also allow for full route computation (up to the final destination). ## I suspect that people will complain about the strong use of PCE in ## the two previous paragraphs Step 4: the same procedure applies at R8 to reach T1Æs destination: R11. ## Bad character in text 3. Reoptimization of a loosely routed TE LSP path Once a loosely routed explicit TE LSP is set up, it is maintained through normal RSVP procedures. Then a more optimal path might appear between an LSR and its next loose hop (for the sake of illustration, suppose in the example above that a link between R6 and R8 is added or restored that provides a shorter path between R3 and R8 (R3-R6-R8) than the existing R3-R6-R7-R8 path). Since the better path is not visible from the head-end LSR by means of the IGP because it does not belong to the head-end IGP area, the head-end cannot make use of this better path <(and perform a make before break) when appropriate. Hence some >(and re-route the LSP using make before break) when appropriate. Hence some mechanism is required to detect the existence of such a better path and notify the head-end accordingly. This document defines a mechanism that allows: - A head-end LSR to trigger on every LSR whose next hop is a loose hop the re-evaluation of the current path in order to detect a potential more optimal path, - A mid-point LSR whose next hop is a loose-hop to signal (using a new ERROR-SPEC sub-code carried in a Path Error Notify ## What do you mean "sub-code"? ## Do you mean Error Value? ## ## What do you mean "Path Error Notify message"? ## Do you mean PathErr and Notify messages message) to the head-end that a better path exists (a path with a lower cost, where the cost is defined by the metric used to compute the path û see [SEC-METRIC], [METRIC]). ## Bad character in text ## Besides, I don't see that this is the time to start to describe ## what might be meant by a "better path" in terms of possible ## CSPF computations. This really is simply a statement that "if the ## path computation were to be applied for a second time it would ## produce a different result." This covers optimization, maintenance, ## and all forms of CSPF grooming. Then once the existence of such a better path is notified to the head- end, the head-end LSR can decide (depending on the TE LSP characteristics) whether to perform a TE LSP graceful reoptimization. There is another scenario whereby notifying the head-end of the Vasseur and Ikejiri 4 draft-vasseur-ccamp-loose-path-reopt-01.txt April 2004 existence of a better path is desirable: if the current path is about the fail due to some (link or node) required maintenance. This allows the head-end to reoptimize a TE LSP making use of the non disruptive make before break procedure if and only if a better path exists and if such a reoptimized is desired. ## There is a specific, more precise requirement here. What if the ## component link or label is about to go out of service? Do we ## also need to resignal using make-before break? ## ## I have been trying to formulate something for this in GMPLS. ## The specific concern here is that the maintenance decision may ## be taken at the network node (within the domain), not at the ## centralized management/routing controller (PCE) for the domain. ## Thus there is a need to signal this resource (i.e. not link) ## change back up the LSP to the point of computation, and possibly ## forward again in the new Path request as an explicit exclusion. ## For example, think of a 20 lambda link where the in-use lambda is ## about to be deprovisioned. The link and TE stays good, but the ## in-use label is about to go away. ## Hmmm, on reflection, it is fine simply to cause re-signaling the ## way you propose, and allow label re-negotiation on the make-before- ## break LSP. ## Perhaps it would be good to comment on this usage since it is a major ## requirement for GMPLS. 4. Signalling extensions 4.1. ERO expansion signaling request The following new flag of the SESSION_ATTRIBUTE object (C-Type 1 and 7) is defined: ERO Expansion request: 0x20 ## I think your IANA section should request that IANA manages this ## flags field and allocates you a new value. This flag indicates that a new ERO expansion is requested. ## If you do make-before-break, it is a new LSP. How would you use the ## "old" ERO in this case? Of course, the old LSP's resource attributes ## must be available for sharing during the computation, but still, you ## compute a new route every time you get a Path message for a new LSP. Note: in case of link bundling for instance, although the resulting ERO might be identical, this might give the opportunity for a mid-point LSR to locally select another link within a bundle, although strictly speaking, the ERO has not changed. ## Aha! But the change in ERO doesn't matter in this case because it is ## a new LSP so the LSRs are free to make a new choice in any case. ## ## I *think* the destinction you are trying to signal is that the new ## LSP is NOT simply another LSP in the session that should attempt to ## maximally share resources with the existing LSP, but is actually a ## replacement LSP (using make-before-break) and the other LSP in this ## session will be torn down later so resource sharing is not required ## except where it occurs fortuitously. ## ## Further (oh gods, he goes on!) don't you actually need to know which ## LSP is being replaced? Consider that you have two load sharing LSPs ## within one session. It is possible that these LSPs share links or ## nodes within some parts of the network (full path diversity is not a ## requirement ofr load sharing). In this case, when you do make before ## break to establish an LSP on a better path, it is important to ## indicate which LSP is being replaced. <4.2. New Path Error sub-code >4.2. New Error Spec Error Values As defined in [RSVP-TE], the ERROR-CODE 25 an ERROR SPEC object corresponds to a Notify Error. This document adds three new Error Values: 6 Better path exists 7 Local link maintenance required 8 Local node maintenance required ## Please add an IANA section for the allocation of these values. ## You may *suggest* these values. The details about the local maintenance required modes are detailed in section 5.3.2 5. Mode of operation 5.1. Head-end reoptimization control The notification process of a better path (shorter path or new path due to some maintenance required on the current path) is by nature de- correlated from the reoptimization operation. In other words, the location where a potentially more optimal path is discovered does not have to be where the TE LSP is actually reoptimized. This document applies to the context of a head-end reoptimization. 5.2. Reoptimization triggers There are three possible reoptimization triggers: Vasseur and Ikejiri 5 draft-vasseur-ccamp-loose-path-reopt-01.txt April 2004 - Timer-based: a reoptimization is triggered (process evaluating whether a more optimal path can be found) when a configurable timer expires, - Event-driven: a reoptimization is triggered when a particular network event occurs (such as a ôLink-UPö event), ## Bad characters in text ## ## Do you want to add "Deferred Event-driven" as a fourth class? - Operator-driven: a reoptimization is manually triggered by the Operator. It is RECOMMENDED for an implementation supporting the extensions proposed in this document to support both modes. ## Given that there are three modes, what do you want to recommend? 5.3. Head-end request versus mid-point explicit notification modes This document defines two modes: - ôHead-end requesting modeö: the request for a new path ## Bad characters in text evaluation of a loosely routed TE LSP is requested by the head- end LSR. ## I seriously misread this (and actually the draft up to this point). ## It was not previously clear that this mode is used by the head end ## to ask the network whether any better paths exist. This is done ## to determine whether there is value in make before break signaling. ## Could you make this clearer here and in earlier sections? - ôMid-point explicit notificationö: a mid-point LSR having ## Bad characters in text determined that a better path (than the current path is use) exists or having the desire to perform a link/node local maintenance explicitly notifies the head-end LSR which will in turn decide whether to perform a reoptimization. ## It is unclear from this text whether the reporting LSR/domain is ## requesting or requiring a re-optimization (you use "desire"). Perhaps ## you need different quality actions according to the Error Values. 5.3.1. Head-end request mode ## Format In this mode, when a timer-based reoptimization is triggered on the head-end LSR or the operator manually requests a reoptimization, the head-end LSR immediately sends an RSVP Path message with the ôERO Expansion requestö bit of the SESSION-ATTRIBUTE object set. This bit is ## bad characters in text then cleared in subsequent RSVP path messages sent downstream. ## Ouch! ## See the pain that is required for similar behavior in the GMPLS ## ADMIN_STATUS Object. Your problem here is that you need to be sure ## that this flag has properly propagated and been acted on before you ## send a new Path message with the bit cleared. ## ## Perhaps you need a sequence number. Perhpas you need a toggle bit ## so you only act when the bit toggles. Upon receiving a Path message with the ôERO expansion requestö bit set, ## bad characters in text every LSR for which the next abstract node contained in the ERO is defined as a loose hop, performs the following set of actions: ## ditto loose hop/abstract node ## Oh. Now you say what is going on!!! ## See my comment in 5.3 bullet one. 1) A new ERO expansion is triggered and the newly computed path is compared to the existing path: - If a better path can be found, the LSR MUST immediately send < a Path Error to the head-end LSR (Error code 25 (Notify), sub- < code=6 (better path exists)). At this point, the LSR MAY decide > a Path Error to the head-end LSR (Error code 25 (Notify), Error > Value=6 (better path exists)). At this point, the LSR MAY decide to clear the ERO expansion request bit of the SESSION-ATTRIBUTE object in subsequent RSVP Path messages sent downstream: this < mode is the RECOMMENDED mode. > mode is the RECOMMENDED mode for the reasons described below. The sending of a Path Error Notify message ôBetter path existsö ## bad characters in text ## Say: Path Error message with the error "Notify"/"Better path exists" to the head-end LSR will notify the head-end LSR of the Vasseur and Ikejiri 6 draft-vasseur-ccamp-loose-path-reopt-01.txt April 2004 existence of a better path (e.g in a downstream area/AS or in another location within a single domain). ## How does the head end distinguish between solicited and unsolicited ## information? Does it care? Hence, triggering additional ERO expansions on downstream nodes is unnecessary. The only motivation to forward subsequent RSVP Path messages with the ôExpansion request bitö of the SESSION-ATTRIBUTE ## bad characters in text object set would be to trigger path re-evaluation on downstream nodes that could in turn cache some potentially better paths downstream with the objective to reduce the signaling setup delay, should a reoptimization be performed by the head-end LSR. - If no better path can be found, the recommended mode is for an LSR to relay the request (by setting the ERO expansion bit of the SESSION-ATTRIBUTE object in RSVP path message sent downstream) only if no better path has been found on this mid- point LSR. ## When the bit reaches the egress, should there be some response so that ## the head-end is notified that nothing could be done and everyone has ## correctly processed the request. By better path, we mean a path having a lower cost. By default, an LSR uses the TE metric to compute the shortest path that obeys a set of constraints. Note that the head-end LSR might use the METRIC-TYPE object (defined in [PATH-COMP]) in its path message to request the LSR having a next hop defined as a loose hop in the ERO to use another metric to determine the best path. ## Same issue as above. "Better" really means "different". That is, ## it is a local matter what better/different would mean and what is ## reported is that a different path would be preferred. If the RSVP Path message with the ôERO expansion requestö bit set is ## bad characters in text lost, then the next request will be sent when the reoptimization event will trigger on the head-end LSR. The solution to handle RSVP reliable messaging has been defined in [REFRESH-REDUCTION]. ## It is unclear what you mean by "will trigger". If the operator has ## made a request, you must obey it or tell him that it has failed. ## How would he otherwise know to re-issue the request? ## ## Note that in MPLS the use of the refresh reduction mechanisms for ## guaranteed delivery can only be applied if refresh reduction is ## enabled. But not all nodes support refresh reduction (it is optional). ## GMPLS gets around this by specifically allowing Message ID without ## the use of Refresh Reduction. Is this what you are proposing here? If ## so, this is a significant change in RSVP-TE processing. ## ## In any case, reliable delivery is not enough since the subsequent ## Path message may catch up (and therefore overtake) the first message. ## This is actually highly likely since re-computation in many domains ## may take some considerable time. So your issue is that you may ## prematurely clear the computation required bit. ## Reliable delivery will not help here. The network administrator may decide to establish some local policy specifying to ignore such request or to consider those requests not more frequently than a certain rate. The proposed mechanism does not make any assumption of the path computation method performed by the ERO expansion process: it can either be CSPF or PCE based. ## Is PCE not also CSPF? :-) 5.3.2. Mid-point explicit notification mode ## Format In this mode, a mid-point LSR whose next abstract node is a loose hop can locally trigger an ERO expansion (when a configurable timer expires ## trigger or request? or on event-driven basis (link-up event for example) or the user explicitly requests it). If a better path is found compared to the existing one, the LSR sends a Path Error to the head-end LSR (Error code 25 (Notify), sub-code=6 (better path exists)). ## Error Value There are other circumstances in which a mid-point LSR MAY send an RSVP Path Error Notify message with the objective for the TE LSP to be ## PathError message rerouted by its head-end LSR: when a link or a node will go down for local maintenance reasons. In this case, the mid-point LSR where the local maintenance must be performed is responsible for sending an RSVP Vasseur and Ikejiri 7 draft-vasseur-ccamp-loose-path-reopt-01.txt April 2004 Path Error Notify message with the sub-code=7 or 8 depending on the ## PathError message with error code "Notify" and Error Value... ## ## By the way, it is better to always refer to the error value as a ## name string. That way there is only one editorial point for IANA ## to change. affected network element (link or node). Then the first upstream node having performed the ERO expansion MUST perform the following set of actions: - The link (sub-code=7) or the node (sub-code=8) MUST be locally registered for further reference (the TE database must be updated) - The RSVP Path Error message MUST be immediately forwarded unchanged upstream to the head-end LSR. ## But this crosses a domain boundary so there is a confidentiality ## issue. The domain boundary must be allowed to "aggregate" this ## information. Perhaps it would replace the link/node information ## with its own address. Upon, receiving a Path Error Notify message with sub-code 7 or 8, the ## PathError message with error code "Notify" and Error Value... Head-end LSR MUST perform a TE LSP reoptimization. Note that those modes are not exclusive: both the timer and event-driven reoptimization triggers can be implemented on the head-end and/or any mid-point LSR with potentially different timer values for the timer driven reoptimization case. A head-end LSR MAY decide upon receiving an explicit mid-point notification to delay its next ERO expansion request. ## If you talk about delays, you MUST specify a default timer value. ## I believe this is an editorial requirement. ## You need to be careful that this delay is not in contradiction of ## "Upon, receiving a Path Error Notify message with sub-code 7 or 8, ## the Head-end LSR MUST perform a TE LSP reoptimization." 5.3.3. ERO caching ## Format Once a mid-point LSR has determined that a better path exists (after a reoptimization request has been received by the head-end LSR or the reoptimization timer on the mid-point has fired), the more optimal path MAY be cached on the mid-point LSR for a limited amount of time to avoid having to recompute a route once the head-LSR performs a make before break. This mode is optional. Comment : ## Spurious text 6. Interoperability Comment : ## Spurious text An LSR not supporting the ôERO expansion requestö bit of the SESSION- ## Bad characters in text ATTRIBUTE object SHOULD just ignore it. ## 3209 says SHALL forward unmodified. I think you should say MUST and ## give reference to 3209. Any head-end LSR not supporting a Path Error Notify message with sub- code = 6, 7 or 8 MUST just silently ignore such Path Error messages. ## Erm, if it doesn't support them, you can't expect the code to be ## changed specially to ignore! ## It is interesting that there is a mistake in 3209 since it does not ## say that a Notify error code means anything special. ## Fortunately, it is well established that no PathErr message ever ## causes any change in the Path state at any transit LSR. Also, that ## the ingress that receives an error code/value that it does not ## understand. You can simply refer to 2205 for the correct processing ## at all legacy nodes. 7. Security Considerations The practice described in this document does not raise specific security issues beyond those of existing TE. ## Well, I have raised confidentiality for "maintenance required". ## ## What do you mean "existing TE"? 8. Acknowledgments The authors would like to thank Carol Iturralde, Miya Kohno, Francois Le Faucheur, Philip Matthews, Jim Gibson, Raymond Zhang, Jean-Louis Le Roux and Kenji Kumaki for their useful and valuable comments. Vasseur and Ikejiri 8 draft-vasseur-ccamp-loose-path-reopt-01.txt April 2004 9. Intellectual Property ## Ooooh! ## We have to use the new boiler plate. This includes personal IPR ## declarations. ## BTW, could you tell us what elements have been claimed? As you ## may be aware, there is debate about when drafts should not be ## moved forward by WGs if there is IPR claimed. This applies even ## if appropriate reasonable terms are in place. The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards- related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights. Normative References ## Format and bad characters throughout references. [RFC] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels," RFC 2119. [RSVP-TE] Awduche et al, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC3209, December 2001. Informative references [TE-REQ] Awduche et al, Requirements for Traffic Engineering over MPLS, RFC2702, September 1999. [METRICS] Fedyk et al, ôMultiple Metrics for Traffic Engineering with IS-IS and OSPFö, draft-fedyk-isis-ospf-te-metrics-01.txt, November 2000. [DS-TE] Le Faucheur et al, ôRequirements for support of Diff-Serv-aware MPLS Traffic Engineeringö, draft-ietf-tewg-diff-te-reqts-01.txt, June 2001. ## Not really relevant? Not referenced. Vasseur and Ikejiri 9 draft-vasseur-ccamp-loose-path-reopt-01.txt April 2004 [MULTI-AREA-TE] Kompella et al, ôMulti-area MPLS Traffic Engineeringö, draft-kompella-mpls-multiarea-te-03.txt, June 2002. [SEC-METRIC] Le Faucheur et all,ô Use of Interior Gateway Protocol (IGP) Metric as a second MPLS Traffic Engineering Metricö, draft-ietf- tewg-te-metric-igp-02.txt, September, 2002. [INTER-AREA-TE-REQ], Le Roux, Vasseur, Boyle et al. ½ Requirements for Inter-area MPLS Traffic Engineering ©, draft-ietf-tewg-interarea-mpls- te-req-01, April 2004 (Work in progress). [INTER-AS-TE-REQ] Zhang et al, ôMPLS Inter-AS Traffic Engineering requirementsö, draft-ietf-tewg-interas-mpls-te-req-06.txt, February 2004, Work in progress. [INTER-AREA-AS] Vasseur and Ayyangar, ôInter-area and Inter-AS Traffic Engineeringö, draft-vasseur-inter-area-AS-TE-00.txt, February 2004, work in progress. [REFRESH-REDUCTION] Berger et al, ôRSVP Refresh Overhead Reduction Extensionsö, April 2001 ## Spurious text below Authors' addresses: Formatted: Jean-Philippe Vasseur Cisco Systems, Inc. 300 Beaver Brook Road Boxborough , MA - 01719 USA Email: jpv@cisco.com Formatted: Formatted: Yuichi Ikejiri Formatted: NTT Communications Corporation Field Code 1-1-6, Uchisaiwai-cho, Chiyoda-ku Tokyo 100-8019 JAPAN Email: y.ikejiri@ntt.com Formatted: Formatted: Full Copyright Statement Formatted: Field Code Copyright (C) The Internet Society (2004). All Rights Reserved. ## please use new boilerplate for copyright. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by Vasseur and Ikejiri 10 draft-vasseur-ccamp-loose-path-reopt-01.txt April 2004 removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. Vasseur and Ikejiri 11 --=_0_11699_1082562266-- From owner-ccamp@ops.ietf.org Wed Apr 21 13:32:12 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03348 for ; Wed, 21 Apr 2004 13:32:11 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGLa0-0007Rv-52 for ccamp-archive@ietf.org; Wed, 21 Apr 2004 13:32:12 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGLZ1-0007Hc-00 for ccamp-archive@ietf.org; Wed, 21 Apr 2004 13:31:16 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BGLYV-000775-00 for ccamp-archive@ietf.org; Wed, 21 Apr 2004 13:30:39 -0400 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BGL8k-000DNl-AT for ccamp-data@psg.com; Wed, 21 Apr 2004 17:04:02 +0000 Received: from [62.23.212.165] (helo=smail.alcatel.fr) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BGL8d-000DMg-RC for ccamp@ops.ietf.org; Wed, 21 Apr 2004 17:03:56 +0000 Received: from bemail05.netfr.alcatel.fr (bemail05.netfr.alcatel.fr [155.132.251.11]) by smail.alcatel.fr (ALCANET/NETFR) with ESMTP id i3LGtGQP008310; Wed, 21 Apr 2004 18:55:16 +0200 Received: from alcatel.be ([138.203.67.90]) by bemail05.netfr.alcatel.fr (Lotus Domino Release 5.0.11) with ESMTP id 2004042118551488:4686 ; Wed, 21 Apr 2004 18:55:14 +0200 Message-ID: <4086A7F0.9070604@alcatel.be> Date: Wed, 21 Apr 2004 18:57:20 +0200 From: Dimitri.Papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.5) Gecko/20030925 X-Accept-Language: en-us, en MIME-Version: 1.0 To: adrian@olddog.co.uk Cc: ccamp@ops.ietf.org, wesam.alanqar@mail.sprint.com, dbrungard@att.com, dmm@1-4-5.net, LyOng@ciena.com, jonathan.sadler@tellabs.com, sdshew@nortelnetworks.com Subject: Re: FW: I-D ACTION:draft-ietf-ccamp-gmpls-ason-routing-reqts-03.txt References: In-Reply-To: X-MIMETrack: Itemize by SMTP Server on BEMAIL05/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 04/21/2004 18:55:15, Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 04/21/2004 18:55:19 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: base64 X-Alcanet-MTA-scanned-and-authorized: yes Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.4 required=5.0 tests=AWL,MIME_BASE64_LATIN, MIME_BASE64_TEXT,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: base64 aGkgYWRyaWFuLCBtdWNoIHRoYW5rcyBmb3IgdGhlIGRldGFpbGVkIHJldmlldywgY2hhbmdlcyB3 aWxsIGJlIGluY2x1ZGVkIA0KaW4gdGhlIHVwZGF0ZWQgdmVyc2lvbiB0aGF0IHdpbGwgYmUgc3Vi bWl0dGVkIGF0IHRoZSBlbmQgb2YgdGhlIHdnIGxhc3QgDQpjYWxsIHByb2Nlc3MgLQ0KDQotLS0N Cg0KQWRyaWFuIEZhcnJlbCB3cm90ZToNCg0KPiBIaSBBU09OIFJvdXRpbmcgRFQsDQo+IFBsZWFz ZSBmaW5kIGF0dGFjaGVkIGEgbWFya2VkIHVwIGNvcHkgb2YgdGhlIGRyYWZ0Lg0KPiBBbGwgY2hh bmdlcyBhcmUgdHlwb2dyYXBoaWNhbCBvciBuaXRzLg0KPiBUaGFua3MsDQo+IEFkcmlhbg0KPiAt LS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tDQo+IEZyb206ICJLaXJlZXRpIEtvbXBlbGxhIiA8 a2lyZWV0aUBqdW5pcGVyLm5ldD4NCj4gVG86IDxjY2FtcEBvcHMuaWV0Zi5vcmc+DQo+IFNlbnQ6 IFRodXJzZGF5LCBBcHJpbCAxNSwgMjAwNCAxMjo0NiBBTQ0KPiBTdWJqZWN0OiBSZTogRlc6IEkt RCANCj4gQUNUSU9OOmRyYWZ0LWlldGYtY2NhbXAtZ21wbHMtYXNvbi1yb3V0aW5nLXJlcXRzLTAz LnR4dA0KPiANCj4+IEhpIEFsbCwNCj4+IE9uIFdlZCwgMTQgQXByIDIwMDQsIEJydW5nYXJkLCBE ZWJvcmFoIEEsIEFMQUJTIHdyb3RlOg0KPj4gPiBUaGUgQVNPTiBSb3V0aW5nIFJlcXRzIERUIGhh cyB1cGRhdGVkIHRoZSBmb2xsb3dpbmcgZHJhZnQgYmFzZWQgb24NCj4+ID4gSVRVIFExNC8xNSdz IExpYWlzb24gYW5kIENDQU1QIG1haWwgbGlzdCBjb21tZW50cy4NCj4+ID4NCj4+ID4gV2UgcmVj b21tZW5kIHRoaXMgZG9jdW1lbnQgYXMgcmVhZHkgZm9yIFdHIExhc3QgQ2FsbC4NCj4+IFRoaXMg Y29tbWVuY2VzIGEgdHdvLXdlZWsgV0cgTGFzdCBDYWxsIG9uIHRoZSBHTVBMUyBBU09OIHJvdXRp bmcNCj4+IHJlcXVpcmVtZW50cy4gIExhc3QgQ2FsbCBlbmRzIEFwcmlsIDI4dGgsIDVwbSBQRFQu ICBQbGVhc2Ugc2VuZCB5b3VyDQo+PiBjb21tZW50cyB0byB0aGUgbGlzdC4NCj4+IFRoZSBwcm9w b3NlZCBjYXRlZ29yeSBpcyBJbmZvcm1hdGlvbmFsLg0KPj4gS2lyZWV0aS4NCj4gDQo+IA0KPiAN Cj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tDQo+IA0KPiBDQ0FNUCBXb3JraW5nIEdyb3VwICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBXZXNhbSBBbGFucWFyIChTcHJpbnQpDQo+IEludGVybmV0IERyYWZ0 ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIERlYm9yYWggQnJ1bmdhcmQgKEFUVCkN Cj4gQ2F0ZWdvcnk6IEluZm9ybWF0aW9uYWwgICAgICAgICAgICAgICAgICAgIERhdmlkIE1leWVy IChDaXNjbyBTeXN0ZW1zKQ0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgTHluZG9uIE9uZyAoQ2llbmEpDQo+IEV4cGlyYXRpb24gRGF0ZTogT2N0 b2JlciAyMDA0ICAgICAgICAgIERpbWl0cmkgUGFwYWRpbWl0cmlvdSAoQWxjYXRlbCkNCj4gICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgSm9uYXRoYW4gU2FkbGVy IChUZWxsYWJzKQ0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgU3RlcGhlbiBTaGV3IChOb3J0ZWwpDQo+IA0KPiANCj4gICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgQXByaWwgMjAwNA0KPiAN Cj4gDQo+IA0KPiANCj4gICAgICAgICAgICAgIFJlcXVpcmVtZW50cyBmb3IgR2VuZXJhbGl6ZWQg TVBMUyAoR01QTFMpIFJvdXRpbmcNCj4gICAgICAgICAgICAgIGZvciBBdXRvbWF0aWNhbGx5IFN3 aXRjaGVkIE9wdGljYWwgTmV0d29yayAoQVNPTikNCj4gDQo+IA0KPiAgICAgICAgICAgICAgZHJh ZnQtaWV0Zi1jY2FtcC1nbXBscy1hc29uLXJvdXRpbmctcmVxdHMtMDMudHh0DQo+IA0KPiANCj4g DQo+IA0KPiBTdGF0dXMgb2YgdGhpcyBNZW1vDQo+IA0KPiANCj4gICAgVGhpcyBkb2N1bWVudCBp cyBhbiBJbnRlcm5ldC1EcmFmdCBhbmQgaXMgaW4gZnVsbCBjb25mb3JtYW5jZSB3aXRoDQo+ICAg IGFsbCBwcm92aXNpb25zIG9mIFNlY3Rpb24gMTAgb2YgUkZDLTIwMjYuDQo+IA0KPiANCj4gICAg SW50ZXJuZXQtRHJhZnRzIGFyZSB3b3JraW5nIGRvY3VtZW50cyBvZiB0aGUgSW50ZXJuZXQgRW5n aW5lZXJpbmcNCj4gICAgVGFzayBGb3JjZSAoSUVURiksIGl0cyBhcmVhcywgYW5kIGl0cyB3b3Jr aW5nIGdyb3Vwcy4gTm90ZSB0aGF0DQo+ICAgIG90aGVyIGdyb3VwcyBtYXkgYWxzbyBkaXN0cmli dXRlIHdvcmtpbmcgZG9jdW1lbnRzIGFzIEludGVybmV0LQ0KPiAgICBEcmFmdHMuIEludGVybmV0 LURyYWZ0cyBhcmUgZHJhZnQgZG9jdW1lbnRzIHZhbGlkIGZvciBhIG1heGltdW0gb2YNCj4gICAg c2l4IG1vbnRocyBhbmQgbWF5IGJlIHVwZGF0ZWQsIHJlcGxhY2VkLCBvciBvYnNvbGV0ZWQgYnkg b3RoZXINCj4gICAgZG9jdW1lbnRzIGF0IGFueSB0aW1lLiBJdCBpcyBpbmFwcHJvcHJpYXRlIHRv IHVzZSBJbnRlcm5ldC0gRHJhZnRzDQo+ICAgIGFzIHJlZmVyZW5jZSBtYXRlcmlhbCBvciB0byBj aXRlIHRoZW0gb3RoZXIgdGhhbiBhcyAid29yayBpbg0KPiAgICBwcm9ncmVzcy4iDQo+IA0KPiAN Cj4gICAgVGhlIGxpc3Qgb2YgY3VycmVudCBJbnRlcm5ldC1EcmFmdHMgY2FuIGJlIGFjY2Vzc2Vk IGF0DQo+ICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaWV0Zi8xaWQtYWJzdHJhY3RzLnR4dA0KPiAN Cj4gDQo+ICAgIFRoZSBsaXN0IG9mIEludGVybmV0LURyYWZ0IFNoYWRvdyBEaXJlY3RvcmllcyBj YW4gYmUgYWNjZXNzZWQgYXQNCj4gICAgaHR0cDovL3d3dy5pZXRmLm9yZy9zaGFkb3cuaHRtbC4N Cj4gDQo+IA0KPiANCj4gQWJzdHJhY3QNCj4gDQo+IA0KPiAgICBUaGUgR2VuZXJhbGl6ZWQgTVBM UyAoR01QTFMpIHN1aXRlIG9mIHByb3RvY29scyBoYXMgYmVlbiBkZWZpbmVkIHRvDQo+ICAgIGNv bnRyb2wgZGlmZmVyZW50IHN3aXRjaGluZyB0ZWNobm9sb2dpZXMgYXMgd2VsbCBhcyBkaWZmZXJl bnQNCj4gICAgYXBwbGljYXRpb25zLiBUaGVzZSBpbmNsdWRlIHN1cHBvcnQgZm9yIHJlcXVlc3Rp bmcgVERNIGNvbm5lY3Rpb25zDQo+ICAgIGluY2x1ZGluZyBTT05FVC9TREggYW5kIE9wdGljYWwg VHJhbnNwb3J0IE5ldHdvcmtzIChPVE5zKS4NCj4gDQo+IA0KPiAgICBUaGlzIGRvY3VtZW50IGNv bmNlbnRyYXRlcyBvbiB0aGUgcm91dGluZyByZXF1aXJlbWVudHMgb24gdGhlIEdNUExTDQo+ICAg IHN1aXRlIG9mIHByb3RvY29scyB0byBzdXBwb3J0IHRoZSBjYXBhYmlsaXRpZXMgYW5kIGZ1bmN0 aW9uYWxpdGllcw0KPiAgICBmb3IgYW4gQXV0b21hdGljYWxseSBTd2l0Y2hlZCBPcHRpY2FsIE5l dHdvcmsgKEFTT04pIGFzIGRlZmluZWQgYnkNCj4gICAgSVRVLVQuDQo+IA0KPiANCj4gDQo+IA0K PiANCj4gVy5BbGFucWFyIGV0IGFsLiAtIEV4cGlyZXMgU2VwdGVtYmVyIDIwMDQgICAgICAgICAg ICAgICAgICAgICAgICAgICAgMQ0KPiAjIyBNaXNzaW5nIHBhZ2UgdGhyb3dzDQo+IGRyYWZ0LWll dGYtY2NhbXAtZ21wbHMtYXNvbi1yb3V0aW5nLXJlcXRzLTAzLnR4dCAgICAgICAgICAgIEFwcmls IDIwMDQNCj4gDQo+IA0KPiANCj4gVGFibGUgb2YgQ29udGVudHMNCj4gDQo+IA0KPiAgICBTdGF0 dXMgb2YgdGhpcyBNZW1vIC4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4gMQ0KPiAgICBBYnN0cmFjdCAuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4gMQ0KPiAgICAxLiBDb250cmlidXRvcnMgLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4gMg0KPiAgICAyLiBDb252 ZW50aW9ucyB1c2VkIGluIHRoaXMgZG9jdW1lbnQgLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4gMg0KPiAgICAzLiBJbnRyb2R1Y3Rpb24gLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4gMg0KPiAgICA0LiBBU09OIFJvdXRpbmcgQXJjaGl0ZWN0dXJl IGFuZCBSZXF1aXJlbWVudHMgLi4uLi4uLi4uLi4uLi4uLi4uLi4gNA0KPiAgICA0LjEgTXVsdGlw bGUgSGllcmFyY2hpY2FsIExldmVscyBvZiBBU09OIFJvdXRpbmcgQXJlYXMgKFJBcykgLi4uLi4g NQ0KPiAgICA0LjIgSGllcmFyY2hpY2FsIFJvdXRpbmcgSW5mb3JtYXRpb24gRGlzc2VtaW5hdGlv biAuLi4uLi4uLi4uLi4uLi4gNQ0KPiAgICA0LjMgQ29uZmlndXJhdGlvbiAuLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4gNw0KPiAgICA0LjMuMSBDb25maWd1 cmluZyB0aGUgTXVsdGktTGV2ZWwgSGllcmFyY2h5IC4uLi4uLi4uLi4uLi4uLi4uLi4uLi4gNw0K PiAgICA0LjMuMiBDb25maWd1cmluZyBSQyBBZGphY2VuY2llcyAuLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4gNw0KPiAgICA0LjQgRXZvbHV0aW9uIC4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4gNw0KPiAgICA0LjUgUm91dGluZyBBdHRy aWJ1dGVzIC4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4gOA0KPiAg ICA0LjUuMSBUYXhvbm9teSBvZiBSb3V0aW5nIEF0dHJpYnV0ZXMgLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4gOA0KPiAgICA0LjUuMiBDb21tb25seSBBZHZlcnRpc2VkIEluZm9ybWF0aW9u IC4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4gOQ0KPiAgICA0LjUuMyBOb2RlIEF0dHJpYnV0 ZXMgLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4gOQ0KPiAgICA0 LjUuNCBMaW5rIEF0dHJpYnV0ZXMgLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4gOQ0KPiAgICA1LiBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyAuLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLiAxMQ0KPiAgICA2LiBDb25jbHVzaW9ucyAuLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLiAxMQ0KPiAgICA3LiBB Y2tub3dsZWRnZW1lbnRzIC4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLiAxMw0KPiAgICA4LiBJbnRlbGxlY3R1YWwgUHJvcGVydHkgQ29uc2lkZXJhdGlvbnMgLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLiAxMw0KPiAgICA4LjEgSVBSIERpc2Nsb3N1cmUgQWNrbm93 bGVkZ2VtZW50IC4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLiAxMw0KPiAgICA5LiBSZWZl cmVuY2VzIC4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u LiAxNA0KPiAgICA5LjEgTm9ybWF0aXZlIFJlZmVyZW5jZXMgLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLiAxNA0KPiAgICAxMC4gQXV0aG9yJ3MgQWRkcmVzc2VzIC4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLiAxNA0KPiAgICBBcHBlbmRpeCAx OiBBU09OIFRlcm1pbm9sb2d5IC4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLiAx Ng0KPiAgICBBcHBlbmRpeCAyOiBBU09OIFJvdXRpbmcgVGVybWlub2xvZ3kgLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLiAxOA0KPiAgICBGdWxsIENvcHlyaWdodCBTdGF0ZW1lbnQgLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLiAxOQ0KPiANCj4gDQo+IDEuIENvbnRy aWJ1dG9ycw0KPiANCj4gDQo+ICAgIFRoaXMgZG9jdW1lbnQgaXMgdGhlIHJlc3VsdCBvZiB0aGUg Q0NBTVAgV29ya2luZyBHcm91cCBBU09OIFJvdXRpbmcNCj4gICAgUmVxdWlyZW1lbnRzIGRlc2ln biB0ZWFtIGpvaW50IGVmZm9ydC4NCj4gDQo+IA0KPiAyLiBDb252ZW50aW9ucyB1c2VkIGluIHRo aXMgZG9jdW1lbnQNCj4gDQo+IA0KPiAgICBUaGUga2V5IHdvcmRzICJNVVNUIiwgIk1VU1QgTk9U IiwgIlJFUVVJUkVEIiwgIlNIQUxMIiwgIlNIQUxMIE5PVCIsDQo+ICAgICJTSE9VTEQiLCAiU0hP VUxEIE5PVCIsICJSRUNPTU1FTkRFRCIsICAiTUFZIiwgYW5kICJPUFRJT05BTCIgaW4NCj4gICAg dGhpcyBkb2N1bWVudCBhcmUgdG8gYmUgaW50ZXJwcmV0ZWQgYXMgZGVzY3JpYmVkIGluIFJGQyAy MTE5DQo+ICAgIFtSRkMyMTE5XS4NCj4gDQo+IA0KPiAzLiBJbnRyb2R1Y3Rpb24NCj4gDQo+IA0K PiAgICBUaGUgR01QTFMgc3VpdGUgb2YgcHJvdG9jb2xzIHByb3ZpZGVzIGFtb25nIG90aGVyIGNh cGFiaWxpdGllcw0KPiAgICBzdXBwb3J0IGZvciBjb250cm9sbGluZyBkaWZmZXJlbnQgc3dpdGNo aW5nIHRlY2hub2xvZ2llcy4gVGhlc2UNCj4gICAgaW5jbHVkZSBzdXBwb3J0IGZvciByZXF1ZXN0 aW5nIFRETSBjb25uZWN0aW9ucyB1dGlsaXppbmcgU09ORVQvU0RIDQo+ICAgIChzZWUgQU5TSSBU MS4xMDUvSVRVLVQgRy43MDcpIGFzIHdlbGwgYXMgT3B0aWNhbCBUcmFuc3BvcnQgTmV0d29ya3MN Cj4gICAgKE9UTiwgc2VlIElUVS1UIEcuNzA5KS4gSG93ZXZlciwgdGhlcmUgYXJlIGNlcnRhaW4g Y2FwYWJpbGl0aWVzIHRoYXQNCj4gICAgYXJlIG5lZWRlZCB0byBzdXBwb3J0IHRoZSBJVFUtVCBH LjgwODAgY29udHJvbCBwbGFuZSBhcmNoaXRlY3R1cmUNCj4gICAgZm9yIEF1dG9tYXRpY2FsbHkg U3dpdGNoZWQgT3B0aWNhbCBOZXR3b3JrIChBU09OKS4gVGhlcmVmb3JlLCBpdCBpcw0KPiANCj4g DQo+IA0KPiBXLkFsYW5xYXIgZXQgYWwuIC0gRXhwaXJlcyBPY3RvYmVyIDIwMDQgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAyDQo+IGRyYWZ0LWlldGYtY2NhbXAtZ21wbHMtYXNvbi1yb3V0 aW5nLXJlcXRzLTAzLnR4dCAgICAgICAgICAgIEFwcmlsIDIwMDQNCj4gDQo+IA0KPiANCj4gICAg ZGVzaXJhYmxlIHRvIHVuZGVyc3RhbmQgdGhlIGNvcnJlc3BvbmRpbmcgcmVxdWlyZW1lbnRzIGZv ciB0aGUgR01QTFMNCj4gICAgcHJvdG9jb2wgc3VpdGUuIFRoZSBBU09OIGNvbnRyb2wgcGxhbmUg YXJjaGl0ZWN0dXJlIGlzIGRlZmluZWQgaW4NCj4gICAgW0cuODA4MF0sIEFTT04gcm91dGluZyBy ZXF1aXJlbWVudHMgYXJlIGlkZW50aWZpZWQgaW4gW0cuNzcxNV0sIGFuZA0KPiAgICBpbiBbRy43 NzE1LjFdIGZvciBBU09OIGxpbmsgc3RhdGUgcHJvdG9jb2xzLiBUaGVzZSBSZWNvbW1lbmRhdGlv bnMNCj4gICAgYXBwbHkgdG8gYWxsIEcuODA1IGxheWVyIG5ldHdvcmtzIChlLmcuIFNESCBhbmQg T1ROKSwgYW5kIHByb3ZpZGUNCj4gICAgcHJvdG9jb2wgbmV1dHJhbCBmdW5jdGlvbmFsIHJlcXVp cmVtZW50cyBhbmQgYXJjaGl0ZWN0dXJlLg0KPiANCj4gDQo+ICAgIFRoaXMgZG9jdW1lbnQgZm9j dXNlcyBvbiB0aGUgcm91dGluZyByZXF1aXJlbWVudHMgZm9yIHRoZSBHTVBMUw0KPiAgICBzdWl0 ZSBvZiBwcm90b2NvbHMgdG8gc3VwcG9ydCB0aGUgY2FwYWJpbGl0aWVzIGFuZCBmdW5jdGlvbmFs aXR5IG9mDQo+ICAgIEFTT04gY29udHJvbCBwbGFuZXMuIFRoaXMgZG9jdW1lbnQgc3VtbWFyaXpl cyB0aGUgQVNPTiByZXF1aXJlbWVudHMNCj4gICAgdXNpbmcgQVNPTiB0ZXJtaW5vbG9neS4gVGhp cyBkb2N1bWVudCBkb2VzIG5vdCBhZGRyZXNzIEdNUExTDQo+ICAgIGFwcGxpY2FiaWxpdHkgb3Ig R01QTFMgY2FwYWJpbGl0aWVzLiBBbnkgcHJvdG9jb2wgKGluIHBhcnRpY3VsYXIsDQo+ICAgIHJv dXRpbmcpIGFwcGxpY2FiaWxpdHksIGRlc2lnbiBvciBzdWdnZXN0ZWQgZXh0ZW5zaW9ucyBpcyBz dHJpY3RseQ0KPiAgICBvdXRzaWRlIHRoZSBzY29wZSBvZiB0aGlzIGRvY3VtZW50LiBBU09OIChS b3V0aW5nKSB0ZXJtaW5vbG9neQ0KPiAgICBzZWN0aW9ucyBhcmUgcHJvdmlkZWQgaW4gQXBwZW5k aXggMSBhbmQgMi4NCj4gDQo+IA0KPiAgICBUaGUgQVNPTiByb3V0aW5nIGFyY2hpdGVjdHVyZSBp cyBiYXNlZCBvbiB0aGUgZm9sbG93aW5nIGFzc3VtcHRpb25zOg0KPiAgICAtIEEgbmV0d29yayBp cyBzdWJkaXZpZGVkIGJhc2VkIG9uIG9wZXJhdG9yIGRlY2lzaW9uIGFuZCBjcml0ZXJpYQ0KPiAg ICAgIChlLmcuIGdlb2dyYXBoeSwgYWRtaW5pc3RyYXRpb24sIGFuZC9vciB0ZWNobm9sb2d5KSwg dGhlIG5ldHdvcmsNCj4gICAgICBzdWJkaXZpc2lvbnMgYXJlIGRlZmluZWQgaW4gQVNPTiBhcyBS b3V0aW5nIEFyZWFzIChSQXMpLg0KPiAgICAtIFRoZSByb3V0aW5nIGFyY2hpdGVjdHVyZSBhbmQg cHJvdG9jb2xzIGFwcGxpZWQgYWZ0ZXIgdGhlIG5ldHdvcmsNCj4gICAgICBpcyBzdWJkaXZpZGVk IGlzIGFuIG9wZXJhdG9yJ3MgY2hvaWNlLiBBIG11bHRpLWxldmVsIGhpZXJhcmNoeSBvZg0KPiAg ICAgIFJBcywgYXMgZGVmaW5lZCBpbiBJVFUtVCBbRy43NzE1XSBhbmQgW0cuNzcxNS4xXSwgcHJv dmlkZXMgZm9yIGENCj4gICAgICBoaWVyYXJjaGljYWwgcmVsYXRpb25zaGlwIG9mIFJBcyBiYXNl ZCBvbiBjb250YWlubWVudCwgaS5lLiBjaGlsZA0KPiAgICAgIFJBcyBhcmUgYWx3YXlzIGNvbnRh aW5lZCB3aXRoaW4gYSBwYXJlbnQgUkEuIFRoZSBoaWVyYXJjaGljYWwNCj4gICAgICBjb250YWlu bWVudCByZWxhdGlvbnNoaXAgb2YgUkFzIHByb3ZpZGVzIGZvciByb3V0aW5nIGluZm9ybWF0aW9u DQo+ICAgICAgYWJzdHJhY3Rpb24sIHRoZXJlYnkgZW5hYmxpbmcgc2NhbGFibGUgcm91dGluZyBp bmZvcm1hdGlvbg0KPiAgICAgIHJlcHJlc2VudGF0aW9uLiBUaGUgbWF4aW11bSBudW1iZXIgb2Yg aGllcmFyY2hpY2FsIFJBIGxldmVscyB0byBiZQ0KPiA8ICAgIHN1cHBvcnRlZCBpcyBOT1Qgc3Bl Y2lmaWVkIChvdXRzaWRlIHRoZSBzY29wZSkuDQo+IA0KPj4gICBzdXBwb3J0ZWQgaXMgTk9UIHNw ZWNpZmllZCAob3V0c2lkZSB0aGUgc2NvcGUgb2YgdGhpcyBkb2N1bWVudCkuDQo+IA0KPiAgICAt IFdpdGhpbiBhbiBBU09OIFJBIGFuZCBmb3IgZWFjaCBsZXZlbCBvZiB0aGUgcm91dGluZyBoaWVy YXJjaHksDQo+ICAgICAgbXVsdGlwbGUgcm91dGluZyBwYXJhZGlnbXMgKGhpZXJhcmNoaWNhbCwg c3RlcC0gYnktc3RlcCwgc291cmNlLQ0KPiAgICAgIGJhc2VkKSwgY2VudHJhbGl6ZWQgb3IgZGlz dHJpYnV0ZWQgcGF0aCBjb21wdXRhdGlvbiwgYW5kIG11bHRpcGxlDQo+ICAgICAgZGlmZmVyZW50 IHJvdXRpbmcgcHJvdG9jb2xzIE1BWSBiZSBzdXBwb3J0ZWQuIFRoZSBhcmNoaXRlY3R1cmUNCj4g ICAgICBkb2VzIE5PVCBhc3N1bWUgYSBvbmUtdG8tb25lIGNvcnJlc3BvbmRlbmNlIG9mIGEgcm91 dGluZyBwcm90b2NvbA0KPiAgICAgIGFuZCBhIFJBIGxldmVsIGFuZCBhbGxvd3MgdGhlIHJvdXRp bmcgcHJvdG9jb2wocykgdXNlZCB3aXRoaW4NCj4gICAgICBkaWZmZXJlbnQgUkFzIChpbmNsdWRp bmcgY2hpbGQgYW5kIHBhcmVudCBSQXMpIHRvIGJlIGRpZmZlcmVudC4NCj4gICAgICBUaGUgcmVh bGl6YXRpb24gb2YgdGhlIHJvdXRpbmcgcGFyYWRpZ20ocykgdG8gc3VwcG9ydCB0aGUNCj4gICAg ICBoaWVyYXJjaGljYWwgbGV2ZWxzIG9mIFJBcyBpcyBOT1Qgc3BlY2lmaWVkLg0KPiAgICAtIFRo ZSByb3V0aW5nIGFkamFjZW5jeSB0b3BvbG9neSAoaS5lLiB0aGUgYXNzb2NpYXRlZCBQcm90b2Nv bA0KPiAgICAgIENvbnRyb2xsZXIgKFBDKSBjb25uZWN0aXZpdHkpIGFuZCB0cmFuc3BvcnQgdG9w b2xvZ3kgaXMgTk9UDQo+ICAgICAgYXNzdW1lZCB0byBiZSBjb25ncnVlbnQuDQo+ICAgIC0gVGhl IHJlcXVpcmVtZW50cyBzdXBwb3J0IGFyY2hpdGVjdHVyYWwgZXZvbHV0aW9uLCBlLmcuIGEgY2hh bmdlIGluDQo+ICAgICAgdGhlIG51bWJlciBvZiBSQSBsZXZlbHMsIGFzIHdlbGwgYXMgYWdncmVn YXRpb24gYW5kIHNlZ21lbnRhdGlvbg0KPiAgICAgIG9mIFJBcy4NCj4gDQo+IA0KPiAgICBUaGUg ZGVzY3JpcHRpb24gb2YgdGhlIEFTT04gcm91dGluZyBhcmNoaXRlY3R1cmUgcHJvdmlkZXMgZm9y IGENCj4gICAgY29uY2VwdHVhbCByZWZlcmVuY2UgYXJjaGl0ZWN0dXJlLCB3aXRoIGRlZmluaXRp b24gb2YgZnVuY3Rpb25hbA0KPiAgICBjb21wb25lbnRzIGFuZCBjb21tb24gaW5mb3JtYXRpb24g ZWxlbWVudHMgdG8gZW5hYmxlIGVuZC10by1lbmQNCj4gICAgcm91dGluZyBpbiB0aGUgY2FzZSBv ZiBwcm90b2NvbCBoZXRlcm9nZW5laXR5IGFuZCBmYWNpbGl0YXRlDQo+ICAgIG1hbmFnZW1lbnQg b2YgQVNPTiBuZXR3b3Jrcy4gVGhpcyBkZXNjcmlwdGlvbiBpcyBvbmx5IGNvbmNlcHR1YWw6IG5v DQo+ICAgIHBoeXNpY2FsIHBhcnRpdGlvbmluZyBvZiB0aGVzZSBmdW5jdGlvbnMgaXMgaW1wbGll ZC4NCj4gDQo+IA0KPiANCj4gDQo+IFcuQWxhbnFhciBldCBhbC4gLSBFeHBpcmVzIE9jdG9iZXIg MjAwNCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDMNCj4gZHJhZnQtaWV0Zi1jY2FtcC1n bXBscy1hc29uLXJvdXRpbmctcmVxdHMtMDMudHh0ICAgICAgICAgICAgQXByaWwgMjAwNA0KPiAN Cj4gDQo+IA0KPiA0LiBBU09OIFJvdXRpbmcgQXJjaGl0ZWN0dXJlIGFuZCBSZXF1aXJlbWVudHMN Cj4gDQo+ICMjIHRyaXZpYWw6IHlvdSBoYXZlICJhIFJBIiBhbHNvICJhbiBSUCINCj4gDQo+ICAg IFRoZSBmdW5kYW1lbnRhbCBhcmNoaXRlY3R1cmFsIGNvbmNlcHQgaXMgdGhlIFJBIGFuZCBpdCdz IHJlbGF0ZWQNCj4gICAgZnVuY3Rpb25hbCBjb21wb25lbnRzIChzZWUgQXBwZW5kaXggMiBvbiB0 ZXJtaW5vbG9neSkuIFRoZSByb3V0aW5nDQo+ICAgIHNlcnZpY2VzIG9mZmVyZWQgYnkgYSBSQSBh cmUgcHJvdmlkZWQgYnkgYSBSb3V0aW5nIFBlcmZvcm1lciAoUlApLg0KPiAgICBBbiBSUCBpcyBy ZXNwb25zaWJsZSBmb3IgYSBzaW5nbGUgUkEsIGFuZCBpdCBNQVkgYmUgZnVuY3Rpb25hbGx5DQo+ ICAgIHJlYWxpemVkIHVzaW5nIGRpc3RyaWJ1dGVkIFJvdXRpbmcgQ29udHJvbGxlcnMgKFJDKS4g VGhlIFJDLCBpdHNlbGYsDQo+ICAgIE1BWSBiZSBpbXBsZW1lbnRlZCBhcyBhIGNsdXN0ZXIgb2Yg ZGlzdHJpYnV0ZWQgZW50aXRpZXMgKEFTT04gcmVmZXJzDQo+ICAgIHRvIHRoZSBjbHVzdGVyIGFz IGEgUm91dGluZyBDb250cm9sIERvbWFpbiAoUkNEKSkuIFRoZSBSQyBjb21wb25lbnRzDQo+ICAg IGZvciBhIFJBIHJlY2VpdmUgcm91dGluZyB0b3BvbG9neSBpbmZvcm1hdGlvbiBmcm9tIHRoZWly IGFzc29jaWF0ZWQNCj4gICAgTGluayBSZXNvdXJjZSBNYW5hZ2VyKHMpIChMUk1zKSBhbmQgc3Rv cmUgdGhpcyBpbmZvcm1hdGlvbiBpbiB0aGUNCj4gICAgUm91dGluZyBJbmZvcm1hdGlvbiBEYXRh YmFzZSAoUkRCKS4gVGhlIFJEQiBpcyByZXBsaWNhdGVkIGF0IGVhY2ggUkMNCj4gPCAgYm91bmRl ZCB0byB0aGUgc2FtZSBSb3V0aW5nIEFyZWEgKFJBKSwgYW5kIE1BWSBjb250YWluIGluZm9ybWF0 aW9uDQo+IA0KPj4gYm91bmRlZCB0byB0aGUgc2FtZSBSQSwgYW5kIE1BWSBjb250YWluIGluZm9y bWF0aW9uDQo+IA0KPiAgICBhYm91dCBtdWx0aXBsZSB0cmFuc3BvcnQgcGxhbmUgbmV0d29yayBs YXllcnMuIFdoZW5ldmVyIHRoZSByb3V0aW5nDQo+ICAgIHRvcG9sb2d5IGNoYW5nZXMsIHRoZSBM Uk0gaW5mb3JtcyB0aGUgY29ycmVzcG9uZGluZyBSQywgd2hpY2ggaW4NCj4gICAgdHVybiB1cGRh dGVzIGl0cyBhc3NvY2lhdGVkIFJEQi4gSW4gb3JkZXIgdG8gYXNzdXJlIFJEQg0KPiAgICBzeW5j aHJvbml6YXRpb24sIHRoZSBSQ3MgY28tb3BlcmF0ZSBhbmQgZXhjaGFuZ2Ugcm91dGluZw0KPiAg ICBpbmZvcm1hdGlvbi4gUGF0aCBjb21wdXRhdGlvbiBmdW5jdGlvbnMgTUFZIGV4aXN0IGluIGVh Y2ggUkMsIE1BWQ0KPiAgICBleGlzdCBvbiBzZWxlY3RlZCBSQ3Mgd2l0aGluIHRoZSBzYW1lIFJB LCBvciBNQVkgYmUgY2VudHJhbGl6ZWQgZm9yDQo+ICAgIHRoZSBSQS4NCj4gDQo+IA0KPiAgICBJ biB0aGlzIGNvbnRleHQsIGNvbW11bmljYXRpb24gYmV0d2VlbiBSQ3Mgd2l0aGluIHRoZSBzYW1l IFJBIGlzDQo+ICAgIHJlYWxpemVkIHVzaW5nIGEgcGFydGljdWxhciByb3V0aW5nIHByb3RvY29s IChvciBtdWx0aXBsZQ0KPiAgICBwcm90b2NvbHMpLiBJbiBBU09OLCB0aGUgY29tbXVuaWNhdGlv biBjb21wb25lbnQgaXMgcmVwcmVzZW50ZWQgYnkNCj4gICAgdGhlIHByb3RvY29sIGNvbnRyb2xs ZXIgKFBDKSBjb21wb25lbnQocykgYW5kIHRoZSBwcm90b2NvbCBtZXNzYWdlcw0KPiAgICBhcmUg Y29udmV5ZWQgb3ZlciB0aGUgQVNPTiBjb250cm9sIHBsYW5lJ3MgU2lnbmFsaW5nIENvbnRyb2wg TmV0d29yaw0KPiAgICAoU0NOKS4gVGhlIFBDIE1BWSBjb252ZXkgaW5mb3JtYXRpb24gZm9yIG9u ZSBvciBtb3JlIHRyYW5zcG9ydA0KPiAgICBuZXR3b3JrIGxheWVycyAocmVmZXIgdG8gU2VjdGlv biA0LjIgTm90ZSkuIFRoZSBSQyBpcyBwcm90b2NvbA0KPiAgICBpbmRlcGVuZGVudCBhbmQgUkMg Y29tbXVuaWNhdGlvbnMgTUFZIGJlIHJlYWxpemVkIGJ5IG11bHRpcGxlLA0KPiAgICBkaWZmZXJl bnQgUENzIHdpdGhpbiBhIFJBLg0KPiANCj4gDQo+ICAgIFRoZSBBU09OIHJvdXRpbmcgYXJjaGl0 ZWN0dXJlIGRlZmluZXMgYSBtdWx0aS1sZXZlbCByb3V0aW5nDQo+ICAgIGhpZXJhcmNoeSBvZiBS QXMgYmFzZWQgb24gYSBjb250YWlubWVudCBtb2RlbCB0byBzdXBwb3J0IHJvdXRpbmcNCj4gICAg aW5mb3JtYXRpb24gYWJzdHJhY3Rpb24uIFtHLjc3MTUuMV0gZGVmaW5lcyB0aGUgQVNPTiBoaWVy YXJjaGljYWwNCj4gICAgbGluayBzdGF0ZSByb3V0aW5nIHByb3RvY29sIHJlcXVpcmVtZW50cyBm b3IgY29tbXVuaWNhdGlvbiBvZg0KPiAgICByb3V0aW5nIGluZm9ybWF0aW9uIHdpdGhpbiBhbiBS QSAob25lIGxldmVsKSB0byBzdXBwb3J0IGhpZXJhcmNoaWNhbA0KPiAgICByb3V0aW5nIGluZm9y bWF0aW9uIGRpc3NlbWluYXRpb24gKGluY2x1ZGluZyBzdW1tYXJpemVkIHJvdXRpbmcNCj4gICAg aW5mb3JtYXRpb24gZm9yIG90aGVyIGxldmVscykuIFRoZSBDb21tdW5pY2F0aW9uIGJldHdlZW4g YW55IG9mIHRoZQ0KPiAgICBvdGhlciBmdW5jdGlvbmFsIGNvbXBvbmVudChzKSAoZS5nLiBTQ04s IExSTSwgYW5kIGJldHdlZW4gUkNEcyAoUkMtDQo+ICAgIFJDIGNvbW11bmljYXRpb24gYmV0d2Vl biBSQXMpKSwgaXMgb3V0c2lkZSB0aGUgc2NvcGUgb2YgW0cuNzcxNS4xXQ0KPiAgICBwcm90b2Nv bCByZXF1aXJlbWVudHMgYW5kLCB0aHVzLCBpcyBhbHNvIG91dHNpZGUgdGhlIHNjb3BlIG9mIHRo aXMNCj4gICAgZG9jdW1lbnQuDQo+IA0KPiANCj4gICAgQVNPTiBSb3V0aW5nIGNvbXBvbmVudHMg YXJlIGlkZW50aWZpZWQgYnkgaWRlbnRpZmllcnMgdGhhdCBhcmUgZHJhd24NCj4gICAgZnJvbSBk aWZmZXJlbnQgbmFtZSBzcGFjZXMgKHNlZSBbRy43NzE1LjFdKS4gVGhlc2UgYXJlIGNvbnRyb2wg cGxhbmUNCj4gICAgaWRlbnRpZmllcnMgZm9yIHRyYW5zcG9ydCByZXNvdXJjZXMsIGNvbXBvbmVu dHMsIGFuZCBTQ04gYWRkcmVzc2VzLg0KPiAgICBUaGUgZm9ybWF0cyBvZiB0aG9zZSBpZGVudGlm aWVycyBpbiBhIHJvdXRpbmcgcHJvdG9jb2wgcmVhbGl6YXRpb24NCj4gICAgU0hBTEwgYmUgaW1w bGVtZW50YXRpb24gc3BlY2lmaWMgYW5kIG91dHNpZGUgdGhlIHNjb3BlIG9mIHRoaXMNCj4gICAg ZG9jdW1lbnQuDQo+IA0KPiANCj4gICAgVGhlIGZhaWx1cmUgb2YgYSBSQywgb3IgdGhlIGZhaWx1 cmUgb2YgY29tbXVuaWNhdGlvbnMgYmV0d2VlbiBSQ3MsDQo+IDwgIGFuZCB0aGUgc3Vic2VxdWVu dCByZWNvdmVyIGZyb20gdGhlIGZhaWx1cmUgY29uZGl0aW9uIE1VU1QgTk9UDQo+IA0KPj4gYW5k IHRoZSBzdWJzZXF1ZW50IHJlY292ZXJ5IGZyb20gdGhlIGZhaWx1cmUgY29uZGl0aW9uIE1VU1Qg Tk9UDQo+IA0KPiANCj4gDQo+IA0KPiBXLkFsYW5xYXIgZXQgYWwuIC0gRXhwaXJlcyBPY3RvYmVy IDIwMDQgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA0DQo+IGRyYWZ0LWlldGYtY2NhbXAt Z21wbHMtYXNvbi1yb3V0aW5nLXJlcXRzLTAzLnR4dCAgICAgICAgICAgIEFwcmlsIDIwMDQNCj4g DQo+IA0KPiANCj4gICAgZGlzcnVwdCBjYWxscyBpbiBwcm9ncmVzcyBhbmQgdGhlaXIgYXNzb2Np YXRlZCBjb25uZWN0aW9ucy4gQ2FsbHMNCj4gICAgYmVpbmcgc2V0IHVwIE1BWSBmYWlsIHRvIGNv bXBsZXRlLCBhbmQgdGhlIGNhbGwgc2V0dXAgc2VydmljZSBNQVkgYmUNCj4gICAgdW5hdmFpbGFi bGUgZHVyaW5nIHJlY292ZXJ5IGFjdGlvbnMuDQo+IA0KPiANCj4gNC4xIE11bHRpcGxlIEhpZXJh cmNoaWNhbCBMZXZlbHMgb2YgQVNPTiBSb3V0aW5nIEFyZWFzIChSQXMpDQo+IA0KPiANCj4gICAg W0cuODA4MF0gaW50cm9kdWNlcyB0aGUgY29uY2VwdCBvZiBSb3V0aW5nIEFyZWEgKFJBKSBpbiBy ZWZlcmVuY2UgdG8NCj4gICAgYSBuZXR3b3JrIHN1YmRpdmlzaW9uLiBSQXMgcHJvdmlkZSBmb3Ig cm91dGluZyBpbmZvcm1hdGlvbg0KPiAgICBhYnN0cmFjdGlvbi4gRXhjZXB0IGZvciB0aGUgc2lu Z2xlIFJBIGNhc2UsIFJBcyBhcmUgaGllcmFyY2hpY2FsbHkNCj4gICAgY29udGFpbmVkOiBhIGhp Z2hlciBsZXZlbCAocGFyZW50KSBSQSBjb250YWlucyBsb3dlciBsZXZlbCAoY2hpbGQpDQo+ICAg IFJBcyB0aGF0IGluIHR1cm4gTUFZIGFsc28gY29udGFpbiBSQXMsIGV0Yy4gVGh1cywgUkFzIGNv bnRhaW4gUkFzDQo+ICAgIHRoYXQgcmVjdXJzaXZlbHkgZGVmaW5lIHN1Y2Nlc3NpdmUgaGllcmFy Y2hpY2FsIFJBIGxldmVscy4NCj4gDQo+IA0KPiAgICBIb3dldmVyLCB0aGUgUkEgY29udGFpbm1l bnQgcmVsYXRpb25zaGlwIGRlc2NyaWJlcyBvbmx5IGFuDQo+ICAgIGFyY2hpdGVjdHVyYWwgaGll cmFyY2hpY2FsIG9yZ2FuaXphdGlvbiBvZiBSQXMuIEl0IGRvZXMgbm90IHJlc3RyaWN0DQo+ICAg IGEgc3BlY2lmaWMgcm91dGluZyBwcm90b2NvbCdzIHJlYWxpemF0aW9uIChlLmcuIE9TUEYgbXVs dGktYXJlYXMsDQo+ICAgIHBhdGggY29tcHV0YXRpb24sIGV0Yy4pLiBNb3Jlb3ZlciwgdGhlIHJl YWxpemF0aW9uIG9mIHRoZSByb3V0aW5nDQo+ICAgIHBhcmFkaWdtIHRvIHN1cHBvcnQgYSBoaWVy YXJjaGljYWwgb3JnYW5pemF0aW9uIG9mIFJBcyBhbmQgdGhlDQo+ICAgIG51bWJlciBvZiBoaWVy YXJjaGljYWwgUkEgbGV2ZWxzIHRvIGJlIHN1cHBvcnRlZCBpcyByb3V0aW5nIHByb3RvY29sDQo+ ICAgIHNwZWNpZmljIGFuZCBvdXRzaWRlIHRoZSBzY29wZSBvZiB0aGlzIGRvY3VtZW50Lg0KPiAN Cj4gDQo+ICAgIEluIGEgbXVsdGktbGV2ZWwgaGllcmFyY2h5IG9mIFJBcywgaXQgaXMgbmVjZXNz YXJ5IHRvIGRpc3Rpbmd1aXNoDQo+ICAgIGFtb25nIFJDcyBmb3IgdGhlIGRpZmZlcmVudCBsZXZl bHMgb2YgdGhlIFJBIGhpZXJhcmNoeS4gQmVmb3JlIGFueQ0KPiAgICBwYWlyIG9mIFJDcyBlc3Rh Ymxpc2hlcyBjb21tdW5pY2F0aW9uLCB0aGV5IE1VU1QgdmVyaWZ5IHRoZXkgYXJlDQo+IDwgIGJv dW5kZWQgdG8gdGhlIHNhbWUgcGFyZW50IFJBIChzZWUgU2VjdGlvbiA0LjIpLiBBIFJBIGlkZW50 aWZpZXIgKFJBDQo+IA0KPj4gYm91bmQgdG8gdGhlIHNhbWUgcGFyZW50IFJBIChzZWUgU2VjdGlv biA0LjIpLiBBIFJBIGlkZW50aWZpZXIgKFJBDQo+IA0KPiAgICBJRCkgaXMgcmVxdWlyZWQgdG8g cHJvdmlkZSB0aGUgc2NvcGUgd2l0aGluIHdoaWNoIHRoZSBSQ3MgY2FuDQo+IDwgIGNvbW11bmlj YXRlLiBUbyBkaXN0aW5ndWlzaCBiZXR3ZWVuIFJDcyBib3VuZGVkIHRvIHRoZSBzYW1lIFJBLCBh bg0KPiANCj4+IGNvbW11bmljYXRlLiBUbyBkaXN0aW5ndWlzaCBiZXR3ZWVuIFJDcyBib3VuZCB0 byB0aGUgc2FtZSBSQSwgYW4NCj4gDQo+ICAgIFJDIGlkZW50aWZpZXIgKFJDIElEKSBpcyByZXF1 aXJlZDsgdGhlIFJDIElEIE1VU1QgYmUgdW5pcXVlIHdpdGhpbg0KPiAgICBpdHMgY29udGFpbmlu ZyBSQS4NCj4gDQo+IA0KPiA8ICBBIFJBIHJlcHJlc2VudHMgYSBwYXJ0aXRpb24gb2YgdGhlIGRh dGEgcGxhbmUgYW5kIGl0cyBpZGVudGlmaWVyDQo+IA0KPj4gQSBSQSByZXByZXNlbnRzIGEgcGFy dGl0aW9uIG9mIHRoZSBkYXRhIHBsYW5lLCBhbmQgaXRzIGlkZW50aWZpZXINCj4gDQo+ICAgIChp LmUuIFJBIElEKSBpcyB1c2VkIHdpdGhpbiB0aGUgY29udHJvbCBwbGFuZSBhcyBhIHJlZmVyZW5j ZSB0byB0aGUNCj4gPCAgZGF0YSBwbGFuZSBwYXJ0aXRpb24uIEVhY2ggUkEgU0hBTEwgYmUgdW5p cXVlbHkgaWRlbnRpZmlhYmxlIHdpdGhpbg0KPiA8ICBhIGNhcnJpZXIncyBuZXR3b3JrLiBSQSBJ RHMgTUFZIGJlIGFzc29jaWF0ZWQgd2l0aCBhIHRyYW5zcG9ydCBwbGFuZQ0KPiANCj4+IGRhdGEg cGxhbmUgcGFydGl0aW9uLiBFYWNoIFJBIHdpdGhpbiBhIGNhcnJpZXIncyBuZXR3b3JrIFNIQUxM IGJlDQo+PiB1bmlxdWVseSBpZGVudGlmaWFibGUuIFJBIElEcyBNQVkgYmUgYXNzb2NpYXRlZCB3 aXRoIGEgdHJhbnNwb3J0IHBsYW5lDQo+IA0KPiAgICBuYW1lIHNwYWNlIHdoZXJlYXMgUkMgSURz IGFyZSBhc3NvY2lhdGVkIHdpdGggYSBjb250cm9sIHBsYW5lIG5hbWUNCj4gICAgc3BhY2UuDQo+ IA0KPiANCj4gNC4yIEhpZXJhcmNoaWNhbCBSb3V0aW5nIEluZm9ybWF0aW9uIERpc3NlbWluYXRp b24NCj4gDQo+IA0KPiA8ICBSb3V0aW5nIGluZm9ybWF0aW9uIGNhbiBiZSBleGNoYW5nZWQgYmV0 d2VlbiBSQ3MgYm91bmRlZCB0byBhZGphY2VudA0KPiANCj4+IFJvdXRpbmcgaW5mb3JtYXRpb24g Y2FuIGJlIGV4Y2hhbmdlZCBiZXR3ZWVuIFJDcyBib3VuZCB0byBhZGphY2VudA0KPiANCj4gICAg bGV2ZWxzIG9mIHRoZSBSQSBoaWVyYXJjaHkgaS5lLiBMZXZlbCBOKzEgYW5kIE4sIHdoZXJlIExl dmVsIE4NCj4gICAgcmVwcmVzZW50cyB0aGUgUkFzIGNvbnRhaW5lZCBieSBMZXZlbCBOKzEuIFRo ZSBsaW5rcyBjb25uZWN0aW5nIFJBcw0KPiAgICBNQVkgYmUgdmlld2VkIGFzIGV4dGVybmFsIGxp bmtzIChpbnRlci1SQSBsaW5rcyksIGFuZCB0aGUgbGlua3MNCj4gICAgcmVwcmVzZW50aW5nIGNv bm5lY3Rpdml0eSB3aXRoaW4gYSBSQSBNQVkgYmUgdmlld2VkIGFzIGludGVybmFsDQo+ICAgIGxp bmtzIChpbnRyYS1SQSBsaW5rcykuIFRoZSBleHRlcm5hbCBsaW5rcyB0byBhIFJBIGF0IG9uZSBs ZXZlbCBvZg0KPiAgICB0aGUgaGllcmFyY2h5IG1heSBiZSBpbnRlcm5hbCBsaW5rcyBpbiB0aGUg cGFyZW50IFJBLiBJbnRyYS1SQSBsaW5rcw0KPiAgICBvZiBhIGNoaWxkIFJBIE1BWSBiZSBoaWRk ZW4gZnJvbSB0aGUgcGFyZW50IFJBJ3Mgdmlldy4NCj4gDQo+IA0KPiAgICBUaGUgcGh5c2ljYWwg bG9jYXRpb24gb2YgUkNzIGZvciBhZGphY2VudCBSQSBsZXZlbHMsIHRoZWlyDQo+ICAgIHJlbGF0 aW9uc2hpcCBhbmQgdGhlaXIgY29tbXVuaWNhdGlvbiBwcm90b2NvbChzKSBhcmUgb3V0c2lkZSB0 aGUNCj4gICAgc2NvcGUgb2YgdGhpcyBkb2N1bWVudC4gTm8gYXNzdW1wdGlvbiBpcyBtYWRlIHJl Z2FyZGluZyBob3cgUkNzDQo+ICAgIGNvbW11bmljYXRlIGJldHdlZW4gYWRqYWNlbnQgUkEgbGV2 ZWxzLiBJZiByb3V0aW5nIGluZm9ybWF0aW9uIGlzDQo+IA0KPiANCj4gDQo+IFcuQWxhbnFhciBl dCBhbC4gLSBFeHBpcmVzIE9jdG9iZXIgMjAwNCAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IDUNCj4gZHJhZnQtaWV0Zi1jY2FtcC1nbXBscy1hc29uLXJvdXRpbmctcmVxdHMtMDMudHh0ICAg ICAgICAgICAgQXByaWwgMjAwNA0KPiANCj4gDQo+IA0KPiAgICBleGNoYW5nZWQgYmV0d2VlbiBh IFJDLCBpdHMgcGFyZW50LCBhbmQgaXRzIGNoaWxkIFJDcywgaXQgU0hPVUxEDQo+ICAgIGluY2x1 ZGUgcmVhY2hhYmlsaXR5IGFuZCBNQVkgaW5jbHVkZSAodXBvbiBwb2xpY3kgZGVjaXNpb24pIG5v ZGUgYW5kDQo+IDwgIGxpbmsgdG9wb2xvZ3kuIE9ubHkgdGhlIFJDcyBvZiB0aGUgcGFyZW50IFJB IGNvbW11bmljYXRlLCBSQ3Mgb2Ygb25lDQo+IDwgIGNoaWxkxnMgUkEgbmV2ZXIgY29tbXVuaWNh dGUgd2l0aCB0aGUgUkNzIG9mIG90aGVyIGNoaWxkIFJBcy4gVGhlcmUNCj4gDQo+PiBsaW5rIHRv cG9sb2d5LiBDb21tdW5pY2F0aW9uIGJldHdlZW4gUkFzIG9ubHkgdGFrZXMgcGxhY2UgYmV0d2Vl bg0KPj4gUkNzIHdpdGggYSBwYXJlbnQvY2hpbGQgcmVsYXRpb25zaGlwLiBSQ3Mgb2Ygb25lIFJB IG5ldmVyIGNvbW11bmljYXRlDQo+PiB3aXRoIFJDcyBvZiBhbm90aGVyIFJBIGF0IHRoZSBzYW1l IGxldmVsLiBUaGVyZQ0KPiANCj4gICAgU0hPVUxEIG5vdCBiZSBhbnkgZGVwZW5kZW5jaWVzIG9u IHRoZSBkaWZmZXJlbnQgcm91dGluZyBwcm90b2NvbHMNCj4gICAgdXNlZCB3aXRoaW4gYSBSQSBv ciBpbiBkaWZmZXJlbnQgUkFzLg0KPiANCj4gDQo+IDwgIE11bHRpcGxlIFJDcyBib3VuZGVkIHRv IHRoZSBzYW1lIFJBIE1BWSB0cmFuc2Zvcm0gKGZpbHRlciwNCj4gDQo+PiBNdWx0aXBsZSBSQ3Mg Ym91bmQgdG8gdGhlIHNhbWUgUkEgTUFZIHRyYW5zZm9ybSAoZmlsdGVyLA0KPiANCj4gICAgc3Vt bWFyaXplLCBldGMuKSBhbmQgdGhlbiBmb3J3YXJkIGluZm9ybWF0aW9uIHRvIFJDcyBhdCBkaWZm ZXJlbnQNCj4gICAgbGV2ZWxzLiBIb3dldmVyIGluIHRoaXMgY2FzZSB0aGUgcmVzdWx0aW5nIGlu Zm9ybWF0aW9uIGF0IHRoZQ0KPiAgICByZWNlaXZpbmcgbGV2ZWwgbXVzdCBiZSBzZWxmLWNvbnNp c3RlbnQ7IHRoaXMgTUFZIGJlIGFjaGlldmVkIHVzaW5nDQo+ICAgIGEgbnVtYmVyIG9mIG1lY2hh bmlzbXMuDQo+IA0KPiANCj4gICAgTm90ZTogdGhlcmUgaXMgbm8gaW1wbGllZCByZWxhdGlvbnNo aXAgYmV0d2VlbiBtdWx0aS1sYXllciB0cmFuc3BvcnQNCj4gICAgbmV0d29ya3MgYW5kIG11bHRp LWxldmVsIHJvdXRpbmcuIEltcGxlbWVudGF0aW9ucyBtYXkgc3VwcG9ydCBhDQo+ICAgIGhpZXJh cmNoaWNhbCByb3V0aW5nIHRvcG9sb2d5IChtdWx0aS1sZXZlbCkgd2l0aCBhIHNpbmdsZSByb3V0 aW5nDQo+ICAgIHByb3RvY29sIGluc3RhbmNlIGZvciBtdWx0aXBsZSB0cmFuc3BvcnQgc3dpdGNo aW5nIGxheWVycyBvciBhDQo+ICAgIGhpZXJhcmNoaWNhbCByb3V0aW5nIHRvcG9sb2d5IGZvciBv bmUgdHJhbnNwb3J0IHN3aXRjaGluZyBsYXllci4NCj4gDQo+IA0KPiAgICAxLiBUeXBlIG9mIElu Zm9ybWF0aW9uIEV4Y2hhbmdlZA0KPiANCj4gDQo+ICAgICAgIFRoZSB0eXBlIG9mIGluZm9ybWF0 aW9uIGZsb3dpbmcgdXB3YXJkIChpLmUuIExldmVsIE4gdG8gTGV2ZWwNCj4gICAgICAgTisxKSBh bmQgdGhlIGluZm9ybWF0aW9uIGZsb3dpbmcgZG93bndhcmQgKGkuZS4gTGV2ZWwgTisxIHRvDQo+ ICAgICAgIExldmVsIE4pIGFyZSB1c2VkIGZvciBzaW1pbGFyIHB1cnBvc2VzLCBuYW1lbHksIHRo ZSBleGNoYW5nZSBvZg0KPiAgICAgICByZWFjaGFiaWxpdHkgaW5mb3JtYXRpb24gYW5kIHN1bW1h cml6ZWQgdG9wb2xvZ3kgaW5mb3JtYXRpb24gdG8NCj4gICAgICAgYWxsb3cgcm91dGluZyBhY3Jv c3MgbXVsdGlwbGUgUkFzLiBUaGUgc3VtbWFyaXphdGlvbiBvZiB0b3BvbG9neQ0KPiAgICAgICBp bmZvcm1hdGlvbiBtYXkgaW1wYWN0IHRoZSBhY2N1cmFjeSBvZiByb3V0aW5nIGFuZCBNQVkgcmVx dWlyZQ0KPiAgICAgICBhZGRpdGlvbmFsIHBhdGggY2FsY3VsYXRpb24uDQo+IA0KPiANCj4gPCAg ICAgVGhlIGZvbGxvd2luZyBpbmZvcm1hdGlvbiBleGNoYW5nZSBhcmUgZXhwZWN0ZWQ6DQo+IA0K Pj4gICAgVGhlIGZvbGxvd2luZyBpbmZvcm1hdGlvbiBleGNoYW5nZXMgYXJlIGV4cGVjdGVkOg0K PiANCj4gDQo+IA0KPiAgICAgICAtIExldmVsIE4rMSB2aXNpYmlsaXR5IHRvIExldmVsIE4gcmVh Y2hhYmlsaXR5IGFuZCB0b3BvbG9neSAob3INCj4gICAgICAgICB1cHdhcmQgaW5mb3JtYXRpb24g Y29tbXVuaWNhdGlvbikgYWxsb3dpbmcgUkMocykgYXQgTGV2ZWwgTisxDQo+ICAgICAgICAgdG8g ZGV0ZXJtaW5lIHRoZSByZWFjaGFibGUgZW5kcG9pbnRzIGZyb20gTGV2ZWwgTi4NCj4gICAgICAg LSBMZXZlbCBOIHZpc2liaWxpdHkgdG8gTGV2ZWwgTisxIHJlYWNoYWJpbGl0eSBhbmQgdG9wb2xv Z3kgKG9yDQo+ICAgICAgICAgZG93bndhcmQgaW5mb3JtYXRpb24gY29tbXVuaWNhdGlvbikgYWxs b3dpbmcgUkMocykgYm91bmRlZCB0byBhDQo+ICAgICAgICAgUkEgYXQgTGV2ZWwgTiB0byBkZXZl bG9wIHBhdGhzIHRvIHJlYWNoYWJsZSBlbmRwb2ludHMgb3V0c2lkZQ0KPiAgICAgICAgIG9mIHRo ZSBSQS4NCj4gDQo+IA0KPiAgICAyLiBJbnRlcmFjdGlvbnMgYmV0d2VlbiBVcHdhcmQgYW5kIERv d253YXJkIENvbW11bmljYXRpb24NCj4gDQo+IA0KPiAgICAgICBXaGVuIGJvdGggdXB3YXJkIGFu ZCBkb3dud2FyZCBpbmZvcm1hdGlvbiBleGNoYW5nZXMgY29udGFpbg0KPiAgICAgICBlbmRwb2lu dCByZWFjaGFiaWxpdHkgaW5mb3JtYXRpb24sIGEgZmVlZGJhY2sgbG9vcCBjb3VsZA0KPiAgICAg ICBwb3RlbnRpYWxseSBiZSBjcmVhdGVkLiBDb25zZXF1ZW50bHksIHRoZSByb3V0aW5nIHByb3Rv Y29sIE1VU1QNCj4gICAgICAgaW5jbHVkZSBhIG1ldGhvZCB0bzoNCj4gDQo+IA0KPiAgICAgICAt IHByZXZlbnQgaW5mb3JtYXRpb24gcHJvcGFnYXRlZCBmcm9tIGEgTGV2ZWwgTisxIFJBJ3MgUkMg aW50bw0KPiA8ICAgICAgIHRoZSBMZXZlbCBOIFJBJ3MgUkMgdG8gYmUgcmUtaW50cm9kdWNlZCBp bnRvIHRoZSBMZXZlbCBOKzEgUkEncw0KPiA8ICAgICAgIFJDLCBhbmQNCj4gDQo+PiAgICAgIHRo ZSBMZXZlbCBOIFJBJ3MgUkMgZnJvbSBiZWluZyByZS1pbnRyb2R1Y2VkIGludG8gdGhlIExldmVs IE4rMQ0KPj4gICAgICBSQSdzIFJDLCBhbmQNCj4gDQo+IA0KPiANCj4gICAgICAgLSBwcmV2ZW50 IGluZm9ybWF0aW9uIHByb3BhZ2F0ZWQgZnJvbSBhIExldmVsIE4tMSBSQSdzIFJDIGludG8NCj4g PCAgICAgICB0aGUgTGV2ZWwgTiBSQSdzIFJDIHRvIGJlIHJlLWludHJvZHVjZWQgaW50byB0aGUg TGV2ZWwgTi0xIFJBJ3MNCj4gDQo+PiAgICAgIHRoZSBMZXZlbCBOIFJBJ3MgUkMgZnJvbSBiZWlu ZyByZS1pbnRyb2R1Y2VkIGludG8gdGhlIExldmVsIE4tMSBSQSdzDQo+IA0KPiANCj4gDQo+IA0K PiBXLkFsYW5xYXIgZXQgYWwuIC0gRXhwaXJlcyBPY3RvYmVyIDIwMDQgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICA2DQo+IGRyYWZ0LWlldGYtY2NhbXAtZ21wbHMtYXNvbi1yb3V0aW5nLXJl cXRzLTAzLnR4dCAgICAgICAgICAgIEFwcmlsIDIwMDQNCj4gDQo+IA0KPiANCj4gICAgICAgICBS Qy4NCj4gDQo+IA0KPiAgICAgICBUaGUgcm91dGluZyBwcm90b2NvbCBTSEFMTCBkaWZmZXJlbnRp YXRlIHRoZSByb3V0aW5nIGluZm9ybWF0aW9uDQo+ICAgICAgIG9yaWdpbmF0ZWQgYXQgYSBnaXZl biBsZXZlbCBSQSBmcm9tIGRlcml2ZWQgcm91dGluZyBpbmZvcm1hdGlvbg0KPiAgICAgICAocmVj ZWl2ZWQgZnJvbSBleHRlcm5hbCBSQXMpLCBldmVuIHdoZW4gdGhpcyBpbmZvcm1hdGlvbiBpcw0K PiAgICAgICBmb3J3YXJkZWQgYnkgYW5vdGhlciBSQyBhdCB0aGUgc2FtZSBsZXZlbC4gVGhpcyBp cyBhIG5lY2Vzc2FyeQ0KPiAgICAgICBjb25kaXRpb24gdG8gYmUgZnVsZmlsbGVkIGJ5IHJvdXRp bmcgcHJvdG9jb2xzIHRvIGJlIGxvb3AgZnJlZS4NCj4gDQo+IA0KPiAgICAzLiBNZXRob2Qgb2Yg Q29tbXVuaWNhdGlvbg0KPiANCj4gDQo+ICAgICAgIFR3byBhcHByb2FjaGVzIGV4aXN0IGZvciBj b21tdW5pY2F0aW9uIGJldHdlZW4gTGV2ZWwgTiBhbmQgTisxLg0KPiANCj4gDQo+ICAgICAgIC0g VGhlIGZpcnN0IGFwcHJvYWNoIHBsYWNlcyBhbiBpbnN0YW5jZSBvZiBhIExldmVsIE4gcm91dGlu Zw0KPiAgICAgICAgIGZ1bmN0aW9uIGFuZCBhbiBpbnN0YW5jZSBvZiBhIExldmVsIE4rMSByb3V0 aW5nIGZ1bmN0aW9uIGluIHRoZQ0KPiAgICAgICAgIHNhbWUgc3lzdGVtLiBUaGUgY29tbXVuaWNh dGlvbnMgaW50ZXJmYWNlIGlzIHdpdGhpbiBhIHNpbmdsZQ0KPiAgICAgICAgIHN5c3RlbSBhbmQg aXMgdGh1cyBub3QgYW4gb3BlbiBpbnRlcmZhY2Ugc3ViamVjdCB0bw0KPiAgICAgICAgIHN0YW5k YXJkaXphdGlvbi4NCj4gDQo+IA0KPiAgICAgICAtIFRoZSBzZWNvbmQgYXBwcm9hY2ggcGxhY2Vz IHRoZSBMZXZlbCBOIHJvdXRpbmcgZnVuY3Rpb24gb24gYQ0KPiAgICAgICAgIHNlcGFyYXRlIHN5 c3RlbSBmcm9tIHRoZSBMZXZlbCBOKzEgcm91dGluZyBmdW5jdGlvbi4gSW4gdGhpcw0KPiAgICAg ICAgIGNhc2UsIGEgY29tbXVuaWNhdGlvbiBpbnRlcmZhY2UgbXVzdCBiZSB1c2VkIGJldHdlZW4g dGhlDQo+ICAgICAgICAgc3lzdGVtcyBjb250YWluaW5nIHRoZSByb3V0aW5nIGZ1bmN0aW9ucyBm b3IgZGlmZmVyZW50IGxldmVscy4NCj4gICAgICAgICBUaGlzIGNvbW11bmljYXRpb24gaW50ZXJm YWNlIGFuZCBtZWNoYW5pc21zIGFyZSBvdXRzaWRlIHRoZQ0KPiAgICAgICAgIHNjb3BlIG9mIHRo aXMgZG9jdW1lbnQuDQo+IA0KPiANCj4gNC4zIENvbmZpZ3VyYXRpb24NCj4gDQo+IA0KPiA0LjMu MSBDb25maWd1cmluZyB0aGUgTXVsdGktTGV2ZWwgSGllcmFyY2h5DQo+IA0KPiANCj4gICAgVGhl IFJDIE1VU1Qgc3VwcG9ydCBzdGF0aWMgKGkuZS4gb3BlcmF0b3IgYXNzaXN0ZWQpIGFuZCBNQVkg c3VwcG9ydA0KPiAgICBhdXRvbWF0ZWQgY29uZmlndXJhdGlvbiBvZiB0aGUgaW5mb3JtYXRpb24g ZGVzY3JpYmluZyBpdHMNCj4gPCAgcmVsYXRpb25zaGlwIHRvIHBhcmVudCBhbmQgaXRzIGNoaWxk IHdpdGhpbiB0aGUgaGllcmFyY2hpY2FsDQo+IA0KPj4gcmVsYXRpb25zaGlwIHRvIGl0cyBwYXJl bnQgYW5kIGl0cyBjaGlsZHJlbiB3aXRoaW4gdGhlIGhpZXJhcmNoaWNhbA0KPiANCj4gICAgc3Ry dWN0dXJlIChpbmNsdWRpbmcgUkEgSUQgYW5kIFJDIElEKS4gV2hlbiBhcHBsaWVkIHJlY3Vyc2l2 ZWx5LCB0aGUNCj4gICAgd2hvbGUgaGllcmFyY2h5IGlzIHRodXMgY29uZmlndXJlZC4NCj4gDQo+ IA0KPiA0LjMuMiBDb25maWd1cmluZyBSQyBBZGphY2VuY2llcw0KPiANCj4gDQo+ICAgIFRoZSBS QyBNVVNUIHN1cHBvcnQgc3RhdGljIChpLmUuIG9wZXJhdG9yIGFzc2lzdGVkKSBhbmQgTUFZIHN1 cHBvcnQNCj4gICAgYXV0b21hdGVkIGNvbmZpZ3VyYXRpb24gb2YgdGhlIGluZm9ybWF0aW9uIGRl c2NyaWJpbmcgaXRzIGFzc29jaWF0ZWQNCj4gDQo+PiBQQyBhZGphY2VuY2llcyB0byBvdGhlciBS Q3MgYm91bmRlZCB0byB0aGUgc2FtZSBwYXJlbnQgUkEuIFRoZQ0KPiANCj4gPCAgUEMgYWRqYWNl bmNpZXMgdG8gb3RoZXIgUkNzIGJvdW5kIHRvIHRoZSBzYW1lIHBhcmVudCBSQS4gVGhlDQo+ICMj IERvIHlvdSByZWFsbHkgbWVhbiBQQyBvciBSQz8NCj4gICAgcm91dGluZyBwcm90b2NvbCBTSE9V TEQgc3VwcG9ydCBhbGwgdGhlIHR5cGVzIG9mIFJDIGFkamFjZW5jaWVzDQo+ICAgIGRlc2NyaWJl ZCBpbiBTZWN0aW9uIDkgb2YgW0cuNzcxNV0uIFRoZSBsYXR0ZXIgaW5jbHVkZXMgY29uZ3J1ZW50 DQo+ICAgIHRvcG9sb2d5ICh3aXRoIGRpc3RyaWJ1dGVkIFJDKSBhbmQgaHViYmVkIHRvcG9sb2d5 IChlLmcuIG5vdGUgdGhhdA0KPiAgICB0aGUgbGF0dGVyIGRvZXMgbm90IGF1dG9tYXRpY2FsbHkg aW1wbHkgZGVzaWduYXRlZCBSQykuDQo+IA0KPiANCj4gNC40IEV2b2x1dGlvbg0KPiANCj4gDQo+ ICAgIFRoZSBjb250YWlubWVudCByZWxhdGlvbnNoaXBzIG9mIFJBcyBNQVkgY2hhbmdlLCBtb3Rp dmF0ZWQgYnkgZXZlbnRzDQo+ICAgIHN1Y2ggYXMgbWVyZ2VycywgYWNxdWlzaXRpb25zLCBhbmQg ZGl2ZXN0aXR1cmVzLg0KPiANCj4gDQo+ICAgIFRoZSByb3V0aW5nIHByb3RvY29sIFNIT1VMRCBi ZSBjYXBhYmxlIG9mIHN1cHBvcnRpbmcgYXJjaGl0ZWN0dXJhbA0KPiAgICBldm9sdXRpb24gaW4g dGVybXMgb2YgbnVtYmVyIG9mIGhpZXJhcmNoaWNhbCBsZXZlbHMgb2YgUkFzLCBhcyB3ZWxsDQo+ IA0KPiANCj4gDQo+IFcuQWxhbnFhciBldCBhbC4gLSBFeHBpcmVzIE9jdG9iZXIgMjAwNCAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIDcNCj4gZHJhZnQtaWV0Zi1jY2FtcC1nbXBscy1hc29u LXJvdXRpbmctcmVxdHMtMDMudHh0ICAgICAgICAgICAgQXByaWwgMjAwNA0KPiANCj4gDQo+IA0K PiA8ICBhcyBhZ2dyZWdhdGlvbiBhbmQgc2VnbWVudGF0aW9uIG9mIFJBcy4gUkEgSURzIHVuaXF1 ZW5lc3Mgd2l0aGluIGFuDQo+IA0KPj4gYXMgYWdncmVnYXRpb24gYW5kIHNlZ21lbnRhdGlvbiBv ZiBSQXMuIFJBIElEIHVuaXF1ZW5lc3Mgd2l0aGluIGFuDQo+IA0KPiAgICBhZG1pbmlzdHJhdGl2 ZSBkb21haW4gTUFZIGZhY2lsaXRhdGUgdGhlc2Ugb3BlcmF0aW9ucy4gVGhlIHJvdXRpbmcNCj4g ICAgcHJvdG9jb2wgaXMgbm90IGV4cGVjdGVkIHRvIGF1dG9tYXRpY2FsbHkgaW5pdGlhdGUgYW5k L29yIGV4ZWN1dGUNCj4gICAgdGhlc2Ugb3BlcmF0aW9ucy4gUmVjb25maWd1cmF0aW9uIG9mIHRo ZSBSQSBoaWVyYXJjaHkgTUFZIG5vdA0KPiAjIyBTdXJlbHkgdGhpcyBpcyBNVVNUPw0KPiAgICBk aXNydXB0IGNhbGxzIGluIHByb2dyZXNzLCB0aG91Z2ggY2FsbHMgYmVpbmcgc2V0IHVwIG1heSBm YWlsIHRvDQo+ICAgIGNvbXBsZXRlLCBhbmQgdGhlIGNhbGwgc2V0dXAgc2VydmljZSBtYXkgYmUg dW5hdmFpbGFibGUgZHVyaW5nDQo+ICAgIHJlY29uZmlndXJhdGlvbiBhY3Rpb25zLg0KPiANCj4g DQo+IDQuNSBSb3V0aW5nIEF0dHJpYnV0ZXMNCj4gDQo+IA0KPiAgICBSb3V0aW5nIGZvciB0cmFu c3BvcnQgbmV0d29ya3MgaXMgcGVyZm9ybWVkIG9uIGEgcGVyIGxheWVyIGJhc2lzLA0KPiAgICB3 aGVyZSB0aGUgcm91dGluZyBwYXJhZGlnbXMgTUFZIGRpZmZlciBhbW9uZyBsYXllcnMgYW5kIHdp dGhpbiBhDQo+IDwgIGxheWVyLiBOb3QgYWxsIGVxdWlwbWVudCBzdXBwb3J0IHRoZSBzYW1lIHNl dCBvZiB0cmFuc3BvcnQgbGF5ZXJzIG9yDQo+IA0KPj4gbGF5ZXIuIE5vdCBhbGwgZXF1aXBtZW50 IHN1cHBvcnRzIHRoZSBzYW1lIHNldCBvZiB0cmFuc3BvcnQgbGF5ZXJzIG9yDQo+IA0KPiAgICB0 aGUgc2FtZSBkZWdyZWUgb2YgY29ubmVjdGlvbiBmbGV4aWJpbGl0eSBhdCBhbnkgZ2l2ZW4gbGF5 ZXIuIEENCj4gICAgc2VydmVyIGxheWVyIHRyYWlsIG1heSBzdXBwb3J0IHZhcmlvdXMgY2xpZW50 cywgaW52b2x2aW5nIGRpZmZlcmVudA0KPiAgICBhZGFwdGF0aW9uIGZ1bmN0aW9ucy4gQWRkaXRp b25hbGx5LCBlcXVpcG1lbnQgbWF5IHN1cHBvcnQgdmFyaWFibGUNCj4gICAgYWRhcHRhdGlvbiBm dW5jdGlvbmFsaXR5LCB3aGVyZWJ5IGEgc2luZ2xlIHNlcnZlciBsYXllciB0cmFpbA0KPiAgICBk eW5hbWljYWxseSBzdXBwb3J0cyBkaWZmZXJlbnQgbXVsdGlwbGV4aW5nIHN0cnVjdHVyZXMuIEFz IGEgcmVzdWx0LA0KPiAgICByb3V0aW5nIGluZm9ybWF0aW9uIE1BWSBpbmNsdWRlIGxheWVyIHNw ZWNpZmljLCBsYXllciBpbmRlcGVuZGVudCwNCj4gICAgYW5kIGNsaWVudC9zZXJ2ZXIgYWRhcHRh dGlvbiBpbmZvcm1hdGlvbi4NCj4gDQo+IA0KPiA0LjUuMSBUYXhvbm9teSBvZiBSb3V0aW5nIEF0 dHJpYnV0ZXMNCj4gDQo+IA0KPiAgICBBdHRyaWJ1dGVzIGNhbiBiZSBvcmdhbml6ZWQgYWNjb3Jk aW5nIHRvIHRoZSBmb2xsb3dpbmcgY2F0ZWdvcmllczoNCj4gDQo+IA0KPiAgICAtIE5vZGUgcmVs YXRlZCBvciBsaW5rIHJlbGF0ZWQNCj4gDQo+IA0KPiAgICAtIFByb3Zpc2lvbmVkLCBuZWdvdGlh dGVkIG9yIGF1dG9tYXRpY2FsbHkgY29uZmlndXJlZA0KPiANCj4gDQo+ICAgIC0gSW5oZXJpdGVk IG9yIGxheWVyIHNwZWNpZmljIChjbGllbnQgbGF5ZXJzIGNhbiBpbmhlcml0IHNvbWUNCj4gICAg ICBhdHRyaWJ1dGVzIGZyb20gdGhlIHNlcnZlciBsYXllciB3aGlsZSBvdGhlciBhdHRyaWJ1dGVz IGxpa2UNCj4gICAgICBMaW5rIENhcGFjaXR5IGFyZSBzcGVjaWZpZWQgYnkgbGF5ZXIpLg0KPiAN Cj4gDQo+ICAgIChDb21wb25lbnQpIGxpbmsgYXR0cmlidXRlcyBNQVkgYmUgc3RhdGljYWxseSBv ciBhdXRvbWF0aWNhbGx5DQo+ICAgIGNvbmZpZ3VyZWQgZm9yIGVhY2ggdHJhbnNwb3J0IG5ldHdv cmsgbGF5ZXIuIFRoaXMgbWF5IGxlYWQgdG8NCj4gICAgdW5uZWNlc3NhcnkgcmVwZXRpdGlvbi4g SGVuY2UsIHRoZSBpbmhlcml0YW5jZSBwcm9wZXJ0eSBvZg0KPiAgICBhdHRyaWJ1dGVzIE1BWSBh bHNvIGJlIHVzZWQgdG8gb3B0aW1pemUgdGhlIGNvbmZpZ3VyYXRpb24gcHJvY2Vzcy4NCj4gDQo+ IA0KPiA8ICBBU09OIHVzZXMgdGhlIHRlcm0sIFNOUCwgZm9yIHRoZSBjb250cm9sIHBsYW5lIHJl cHJlc2VudGF0aW9uIG9mIGENCj4gDQo+PiBBU09OIHVzZXMgdGhlIHRlcm0sIFN1Ym5ldHdvcmsg UG9pbnQgKFNOUCksIGZvciB0aGUgY29udHJvbCBwbGFuZSByZXByZXNlbnRhdGlvbiBvZiBhDQo+ IA0KPiAgICB0cmFuc3BvcnQgcGxhbmUgcmVzb3VyY2UuIFRoZSBjb250cm9sIHBsYW5lIHJlcHJl c2VudGF0aW9uIGFuZA0KPiAgICB0cmFuc3BvcnQgcGxhbmUgdG9wb2xvZ3kgaXMgTk9UIGFzc3Vt ZWQgdG8gYmUgY29uZ3J1ZW50LCB0aGUgY29udHJvbA0KPiAgICBwbGFuZSByZXByZXNlbnRhdGlv biBTSEFMTCBub3QgYmUgcmVzdHJpY3RlZCBieSB0aGUgcGh5c2ljYWwNCj4gICAgdG9wb2xvZ3ku IFRoZSByZWxhdGlvbmFsIGdyb3VwaW5nIG9mIFNOUHMgZm9yIHJvdXRpbmcgaXMgdGVybWVkIGEN Cj4gPCAgU05QUC4gVGhlIHJvdXRpbmcgZnVuY3Rpb24gdW5kZXJzdGFuZHMgdG9wb2xvZ3kgaW4g dGVybXMgb2YgU05QUA0KPiANCj4+IFNOUCBQb29sIChTTlBQKS4gVGhlIHJvdXRpbmcgZnVuY3Rp b24gdW5kZXJzdGFuZHMgdG9wb2xvZ3kgaW4gdGVybXMgb2YgU05QUA0KPiANCj4gICAgbGlua3Mu IEdyb3VwaW5nIE1BWSBiZSBiYXNlZCBvbiBkaWZmZXJlbnQgbGluayBhdHRyaWJ1dGVzIChlLmcu LA0KPiAgICBTUkxHIGluZm9ybWF0aW9uLCBsaW5rIHdlaWdodCwgZXRjKS4NCj4gDQo+IA0KPiAg ICBUd28gUkFzIG1heSBiZSBsaW5rZWQgYnkgb25lIG9yIG1vcmUgU05QUCBsaW5rcy4gTXVsdGlw bGUgU05QUCBsaW5rcw0KPiAgICBNQVkgYmUgcmVxdWlyZWQgd2hlbiBjb21wb25lbnQgbGlua3Mg YXJlIG5vdCBlcXVpdmFsZW50IGZvciByb3V0aW5nDQo+ICAgIHB1cnBvc2VzIHdpdGggcmVzcGVj dCB0byB0aGUgUkFzIHRoZXkgYXJlIGF0dGFjaGVkIHRvLCBvciB0byB0aGUNCj4gICAgY29udGFp bmluZyBSQSwgb3Igd2hlbiBzbWFsbGVyIGdyb3VwaW5ncyBhcmUgcmVxdWlyZWQuDQo+IA0KPiAN Cj4gDQo+IA0KPiBXLkFsYW5xYXIgZXQgYWwuIC0gRXhwaXJlcyBPY3RvYmVyIDIwMDQgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICA4DQo+IGRyYWZ0LWlldGYtY2NhbXAtZ21wbHMtYXNvbi1y b3V0aW5nLXJlcXRzLTAzLnR4dCAgICAgICAgICAgIEFwcmlsIDIwMDQNCj4gDQo+IA0KPiANCj4g NC41LjIgQ29tbW9ubHkgQWR2ZXJ0aXNlZCBJbmZvcm1hdGlvbg0KPiANCj4gDQo+ICAgIEFkdmVy dGlzZW1lbnRzIE1BWSBjb250YWluIHRoZSBmb2xsb3dpbmcgY29tbW9uIHNldCBvZiBpbmZvcm1h dGlvbg0KPiAgICByZWdhcmRsZXNzIG9mIHdoZXRoZXIgdGhleSBhcmUgbGluayBvciBub2RlIHJl bGF0ZWQ6DQo+IDwgIC0gUkEgSUQgb2Ygd2hpY2ggdGhlIGFkdmVydGlzZW1lbnQgaXMgYm91bmRl ZA0KPiANCj4+IC0gUkEgSUQgb2YgdGhlIFJBIHRvIHdoaWNoIHRoZSBhZHZlcnRpc2VtZW50IGlz IGJvdW5kDQo+IA0KPiAgICAtIFJDIElEIG9mIHRoZSBlbnRpdHkgZ2VuZXJhdGluZyB0aGUgYWR2 ZXJ0aXNlbWVudA0KPiAgICAtIEluZm9ybWF0aW9uIHRvIHVuaXF1ZWx5IGlkZW50aWZ5IGFkdmVy dGlzZW1lbnRzDQo+ICAgIC0gSW5mb3JtYXRpb24gdG8gZGV0ZXJtaW5lIHdoZXRoZXIgYW4gYWR2 ZXJ0aXNlbWVudCBoYXMgYmVlbiB1cGRhdGVkDQo+ICAgIC0gSW5mb3JtYXRpb24gdG8gaW5kaWNh dGUgd2hlbiBhbiBhZHZlcnRpc2VtZW50IGhhcyBiZWVuIGRlcml2ZWQNCj4gICAgICBmcm9tIGEg ZGlmZmVyZW50IGxldmVsIFJBLg0KPiANCj4gDQo+IDQuNS4zIE5vZGUgQXR0cmlidXRlcw0KPiAN Cj4gDQo+ICAgIEFsbCBub2RlcyBiZWxvbmcgdG8gYSBSQSwgaGVuY2UsIHRoZSBSQSBJRCBjYW4g YmUgY29uc2lkZXJlZCBhbg0KPiAgICBhdHRyaWJ1dGUgb2YgYWxsIG5vZGVzLiBHaXZlbiB0aGF0 IG5vIGRpc3RpbmN0aW9uIGlzIG1hZGUgYmV0d2Vlbg0KPiAgICBhYnN0cmFjdCBub2RlcyBhbmQg dGhvc2UgdGhhdCBjYW5ub3QgYmUgZGVjb21wb3NlZCBhbnkgZnVydGhlciwgdGhlDQo+ICAgIHNh bWUgYXR0cmlidXRlcyBNQVkgYmUgdXNlZCBmb3IgdGhlaXIgYWR2ZXJ0aXNlbWVudC4gSW4gdGhl DQo+IDwgIGZvbGxvd2luZyB0YWJsZXMsIENhcGFiaWxpdHkgcmVmZXJzIHRvIGxldmVsIG9mIHN1 cHBvcnQgcmVxdWlyZWQgaW4NCj4gDQo+PiBmb2xsb3dpbmcgdGFibGVzLCBDYXBhYmlsaXR5IHJl ZmVycyB0byB0aGUgbGV2ZWwgb2Ygc3VwcG9ydCByZXF1aXJlZCBpbg0KPiANCj4gICAgdGhlIHJl YWxpemF0aW9uIG9mIGEgbGluayBzdGF0ZSByb3V0aW5nIHByb3RvY29sLCB3aGVyZWFzIFVzYWdl DQo+IDwgIHJlZmVycyB0byBkZWdyZWUgb2Ygb3BlcmF0aW9uYWwgYW5kIGltcGxlbWVudGF0aW9u IGZsZXhpYmlsaXR5Lg0KPiANCj4+IHJlZmVycyB0byB0aGUgZGVncmVlIG9mIG9wZXJhdGlvbmFs IGFuZCBpbXBsZW1lbnRhdGlvbiBmbGV4aWJpbGl0eS4NCj4gDQo+IA0KPiANCj4gICAgVGhlIGZv bGxvd2luZyBOb2RlIEF0dHJpYnV0ZXMgYXJlIGRlZmluZWQ6DQo+IA0KPiANCj4gICAgICAgIEF0 dHJpYnV0ZSAgICAgICAgQ2FwYWJpbGl0eSAgICAgIFVzYWdlDQo+ICAgICAgICAtLS0tLS0tLS0t LSAgICAgIC0tLS0tLS0tLS0tICAgICAtLS0tLS0tLS0NCj4gICAgICAgIE5vZGUgSUQgICAgICAg ICAgUkVRVUlSRUQgICAgICAgIFJFUVVJUkVEDQo+ICAgICAgICBSZWFjaGFiaWxpdHkgICAgIFJF UVVJUkVEICAgICAgICBPUFRJT05BTA0KPiANCj4gDQo+ICAgICAgICAgICAgICAgICBUYWJsZSAx LiBOb2RlIEF0dHJpYnV0ZXMNCj4gDQo+IA0KPiAgICBSZWFjaGFiaWxpdHkgaW5mb3JtYXRpb24g ZGVzY3JpYmVzIHRoZSBzZXQgb2YgZW5kcG9pbnRzIHRoYXQgYXJlDQo+ICAgIHJlYWNoYWJsZSBi eSB0aGUgYXNzb2NpYXRlZCBub2RlLiBJdCBNQVkgYmUgYWR2ZXJ0aXNlZCBhcyBhIHNldCBvZg0K PiAgICBhc3NvY2lhdGVkIGV4dGVybmFsIChlLmcuIFVOSSkgYWRkcmVzcy9hZGRyZXNzIHByZWZp eGVzIG9yIGEgc2V0IG9mDQo+ICAgIGFzc29jaWF0ZWQgU05QUCBsaW5rIElEcy9TTlBQIElEIHBy ZWZpeGVzLCB0aGUgc2VsZWN0aW9uIG9mIHdoaWNoDQo+ICAgIE1VU1QgYmUgY29uc2lzdGVudCB3 aXRoaW4gdGhlIGFwcGxpY2FibGUgc2NvcGUuIFRoZXNlIGFyZSBjb250cm9sDQo+ICAgIHBsYW5l IGlkZW50aWZpZXJzLCB0aGUgZm9ybWF0cyBvZiB0aGVzZSBpZGVudGlmaWVycyBpbiBhIHByb3Rv Y29sDQo+ICAgIHJlYWxpemF0aW9uIGlzIGltcGxlbWVudGF0aW9uIHNwZWNpZmljIGFuZCBvdXRz aWRlIHRoZSBzY29wZSBvZiB0aGlzDQo+ICAgIGRvY3VtZW50Lg0KPiANCj4gDQo+ICAgIE5vdGU6 IG5vIGRpc3RpbmN0aW9uIGlzIG1hZGUgYmV0d2VlbiBub2RlcyB0aGF0IG1heSBoYXZlIGZ1cnRo ZXINCj4gICAgaW50ZXJuYWwgZGV0YWlscyAoaS5lLiwgYWJzdHJhY3Qgbm9kZXMpIGFuZCB0aG9z ZSB0aGF0IGNhbm5vdCBiZQ0KPiA8ICBkZWNvbXBvc2VkIGFueSBmdXJ0aGVyLiBIZW5jZSB0aGUg YXR0cmlidXRlcyBvZiBhIG5vZGUgYXJlIG5vdCBiZQ0KPiANCj4+IGRlY29tcG9zZWQgYW55IGZ1 cnRoZXIuIEhlbmNlIHRoZSBhdHRyaWJ1dGVzIG9mIGEgbm9kZSBhcmUgbm90DQo+IA0KPiAgICBj b25zaWRlcmVkIG9ubHkgYXMgc2luZ2xlIHN3aXRjaCBhdHRyaWJ1dGVzIGJ1dCBNQVkgYXBwbHkg dG8gYSBub2RlDQo+ICAgIGF0IGEgaGlnaGVyIGxldmVsIG9mIHRoZSBoaWVyYXJjaHkgdGhhdCBy ZXByZXNlbnRzIGEgc3ViLW5ldHdvcmsuDQo+IA0KPiANCj4gNC41LjQgTGluayBBdHRyaWJ1dGVz DQo+IA0KPiANCj4gICAgVGhlIGZvbGxvd2luZyBMaW5rIEF0dHJpYnV0ZXMgYXJlIGRlZmluZWQ6 DQo+IA0KPiANCj4gICAgICAgIExpbmsgQXR0cmlidXRlICAgICAgICAgICAgICAgICAgIENhcGFi aWxpdHkgICAgICBVc2FnZQ0KPiAgICAgICAgLS0tLS0tLS0tLS0tLS0tICAgICAgICAgICAgICAg ICAgLS0tLS0tLS0tLS0gICAgIC0tLS0tLS0tLQ0KPiAgICAgICAgTG9jYWwgU05QUCBsaW5rIElE ICAgICAgICAgICAgICAgUkVRVUlSRUQgICAgICAgIFJFUVVJUkVEDQo+IA0KPiANCj4gDQo+IFcu QWxhbnFhciBldCBhbC4gLSBFeHBpcmVzIE9jdG9iZXIgMjAwNCAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIDkNCj4gZHJhZnQtaWV0Zi1jY2FtcC1nbXBscy1hc29uLXJvdXRpbmctcmVxdHMt MDMudHh0ICAgICAgICAgICAgQXByaWwgMjAwNA0KPiANCj4gDQo+IA0KPiAgICAgICAgUmVtb3Rl IFNOUFAgbGluayBJRCAgICAgICAgICAgICAgUkVRVUlSRUQgICAgICAgIFJFUVVJUkVEDQo+ICAg ICAgICBMYXllciBTcGVjaWZpYyBDaGFyYWN0ZXJpc3RpY3MgICBzZWUgVGFibGUgMw0KPiANCj4g DQo+ICAgICAgICAgICAgICAgICBUYWJsZSAyLiBMaW5rIEF0dHJpYnV0ZXMNCj4gDQo+IA0KPiAg ICBUaGUgU05QUCBsaW5rIElEIG5hbWUgTVVTVCBiZSBzdWZmaWNpZW50IHRvIHVuaXF1ZWx5IGlk ZW50aWZ5IHRoZQ0KPiAjIyBXaHkgZG8geW91IHNheSAiU05QUCBsaW5rIElEIG5hbWUiPyBUaGlz IGlzIG5vdCBkZWZpbmVkLg0KPiAjIyBEbyB5b3UgbWVhbiAiU05QUCBsaW5rIElEIj8NCj4gICAg Y29ycmVzcG9uZGluZyB0cmFuc3BvcnQgcGxhbmUgcmVzb3VyY2UgdGFraW5nIGludG8gYWNjb3Vu dA0KPiAgICBzZXBhcmF0aW9uIG9mIGRhdGEgYW5kIGNvbnRyb2wgcGxhbmVzIChzZWUgU2VjdGlv biA0LjUuMSwgdGhlDQo+ICAgIGNvbnRyb2wgcGxhbmUgcmVwcmVzZW50YXRpb24gYW5kIHRyYW5z cG9ydCBwbGFuZSB0b3BvbG9neSBpcyBub3QNCj4gICAgYXNzdW1lZCB0byBiZSBjb25ncnVlbnQp LiBUaGUgU05QUCBsaW5rIElEIGZvcm1hdCBpcyByb3V0aW5nDQo+ICAgIHByb3RvY29sIHNwZWNp ZmljLg0KPiANCj4gDQo+ICAgIE5vdGU6IHdoZW4gdGhlIHJlbW90ZSBlbmQgb2YgYSBTTlBQIGxp bmsgaXMgbG9jYXRlZCBvdXRzaWRlIG9mIHRoZQ0KPiAgICBSQSwgdGhlIHJlbW90ZSBTTlBQIGxp bmsgSUQgaXMgT1BUSU9OQUwuDQo+IA0KPiANCj4gICAgVGhlIGZvbGxvd2luZyBsaW5rIGNoYXJh Y3RlcmlzdGljIGF0dHJpYnV0ZXMgYXJlIGRlZmluZWQ6DQo+IA0KPiANCj4gICAgLSBTaWduYWwg VHlwZTogVGhpcyBpZGVudGlmaWVzIHRoZSBjaGFyYWN0ZXJpc3RpYyBpbmZvcm1hdGlvbiBvZiB0 aGUNCj4gICAgICBsYXllciBuZXR3b3JrLg0KPiANCj4gDQo+ICAgIC0gTGluayBXZWlnaHQ6IFRo ZSBtZXRyaWMgaW5kaWNhdGluZyB0aGUgcmVsYXRpdmUgZGVzaXJhYmlsaXR5IG9mIGENCj4gICAg ICBwYXJ0aWN1bGFyIGxpbmsgb3ZlciBhbm90aGVyIGUuZy4gZHVyaW5nIHBhdGggY29tcHV0YXRp b24uDQo+IA0KPiANCj4gICAgLSBSZXNvdXJjZSBDbGFzczogVGhpcyBjb3JyZXNwb25kcyB0byB0 aGUgc2V0IG9mIGFkbWluaXN0cmF0aXZlDQo+ICAgICAgZ3JvdXBzIGFzc2lnbmVkIGJ5IHRoZSBv cGVyYXRvciB0byB0aGlzIGxpbmsuIEEgbGluayBNQVkgYmVsb25nIHRvDQo+ICAgICAgemVybywg b25lIG9yIG1vcmUgYWRtaW5pc3RyYXRpdmUgZ3JvdXBzLg0KPiANCj4gDQo+ICAgIC0gQ29ubmVj dGlvbiBUeXBlczogVGhpcyBhdHRyaWJ1dGUgaWRlbnRpZmllcyB3aGV0aGVyIHRoZSBsb2NhbCBT TlANCj4gICAgICByZXByZXNlbnRzIGEgVENQLCBDUCwgb3IgY2FuIGJlIGZsZXhpYmx5IGNvbmZp Z3VyZWQgYXMgYSBUQ1AuDQo+ICMjIFBsZWFzZSBleHBhbmQgVENQIGFuZCBDUCBpbiB0aGVpciBm aXJzdCB1c2VzDQo+IA0KPiANCj4gICAgLSBMaW5rIENhcGFjaXR5OiBUaGlzIHByb3ZpZGVzIHRo ZSBzdW0gb2YgdGhlIGF2YWlsYWJsZSBhbmQNCj4gICAgICBwb3RlbnRpYWwgYmFuZHdpZHRoIGNh cGFjaXR5IGZvciBhIHBhcnRpY3VsYXIgbmV0d29yayB0cmFuc3BvcnQNCj4gICAgICBsYXllci4g T3RoZXIgY2FwYWNpdHkgbWVhc3VyZXMgTUFZIGJlIGZ1cnRoZXIgY29uc2lkZXJlZC4NCj4gDQo+ IA0KPiAgICAtIExpbmsgQXZhaWxhYmlsaXR5OiBUaGlzIHJlcHJlc2VudHMgdGhlIHN1cnZpdmFi aWxpdHkgY2FwYWJpbGl0eQ0KPiAgICAgIHN1Y2ggYXMgdGhlIHByb3RlY3Rpb24gdHlwZSBhc3Nv Y2lhdGVkIHdpdGggdGhlIGxpbmsuDQo+IA0KPiANCj4gICAgLSBEaXZlcnNpdHkgU3VwcG9ydDog VGhpcyByZXByZXNlbnRzIGRpdmVyc2l0eSBpbmZvcm1hdGlvbiBzdWNoIGFzDQo+ICAgICAgdGhl IFNSTEcgaW5mb3JtYXRpb24gYXNzb2NpYXRlZCB3aXRoIHRoZSBsaW5rLg0KPiANCj4gDQo+ICAg IC0gTG9jYWwgQWRhcHRhdGlvbiBTdXBwb3J0OiBUaGlzIGluZGljYXRlcyB0aGUgc2V0IG9mIGNs aWVudCBsYXllcg0KPiAgICAgIGFkYXB0YXRpb25zIHN1cHBvcnRlZCBieSB0aGUgVENQIGFzc29j aWF0ZWQgd2l0aCB0aGUgTG9jYWwgU05QUC4NCj4gICAgICBUaGlzIGlzIG9ubHkgYXBwbGljYWJs ZSB3aGVuIHRoZSBsb2NhbCBTTlAgcmVwcmVzZW50cyBhIFRDUCBvciBjYW4NCj4gICAgICBiZSBm bGV4aWJseSBjb25maWd1cmVkIGFzIGEgVENQLg0KPiANCj4gDQo+ICAgICAgICAgTGluayBDaGFy YWN0ZXJpc3RpY3MgICAgICAgICAgICBDYXBhYmlsaXR5ICAgICAgVXNhZ2UNCj4gICAgICAgICAt LS0tLS0tLS0tLS0tLS0tLS0tLS0tLSAgICAgICAgIC0tLS0tLS0tLS0gICAgICAtLS0tLS0tLS0N Cj4gICAgICAgICBTaWduYWwgVHlwZSAgICAgICAgICAgICAgICAgICAgIFJFUVVJUkVEICAgICAg ICBPUFRJT05BTA0KPiAgICAgICAgIExpbmsgV2VpZ2h0ICAgICAgICAgICAgICAgICAgICAgUkVR VUlSRUQgICAgICAgIE9QVElPTkFMDQo+ICAgICAgICAgUmVzb3VyY2UgQ2xhc3MgICAgICAgICAg ICAgICAgICBSRVFVSVJFRCAgICAgICAgT1BUSU9OQUwNCj4gICAgICAgICBMb2NhbCBDb25uZWN0 aW9uIFR5cGVzICAgICAgICAgIFJFUVVJUkVEICAgICAgICBPUFRJT05BTA0KPiAgICAgICAgIExp bmsgQ2FwYWNpdHkgICAgICAgICAgICAgICAgICAgUkVRVUlSRUQgICAgICAgIE9QVElPTkFMDQo+ IA0KPiANCj4gDQo+IFcuQWxhbnFhciBldCBhbC4gLSBFeHBpcmVzIE9jdG9iZXIgMjAwNCAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgMTANCj4gZHJhZnQtaWV0Zi1jY2FtcC1nbXBscy1hc29u LXJvdXRpbmctcmVxdHMtMDMudHh0ICAgICAgICAgICAgQXByaWwgMjAwNA0KPiANCj4gDQo+IA0K PiAgICAgICAgIExpbmsgQXZhaWxhYmlsaXR5ICAgICAgICAgICAgICAgT1BUSU9OQUwgICAgICAg IE9QVElPTkFMDQo+ICAgICAgICAgRGl2ZXJzaXR5IFN1cHBvcnQgICAgICAgICAgICAgICBPUFRJ T05BTCAgICAgICAgT1BUSU9OQUwNCj4gICAgICAgICBMb2NhbCBBZGFwdGF0aW9uIHN1cHBvcnQg ICAgICAgIE9QVElPTkFMICAgICAgICBPUFRJT05BTA0KPiANCj4gDQo+ICAgICAgICAgICAgICAg IFRhYmxlIDMuIExpbmsgQ2hhcmFjdGVyaXN0aWNzDQo+IA0KPiANCj4gICAgTm90ZTogc2VwYXJh dGUgYWR2ZXJ0aXNlbWVudHMgb2YgbGF5ZXIgc3BlY2lmaWMgYXR0cmlidXRlcyBNQVkgYmUNCj4g PCAgY2hvc2VuLiBIb3dldmVyIHRoaXMgbWF5IGxlYWQgdG8gdW5uZWNlc3NhcnkgZHVwbGljYXRp b24uIFRoaXMgY2FuDQo+IA0KPj4gY2hvc2VuLiBIb3dldmVyLCB0aGlzIG1heSBsZWFkIHRvIHVu bmVjZXNzYXJ5IGR1cGxpY2F0aW9uLiBUaGlzIGNhbg0KPiANCj4gICAgYmUgYXZvaWRlZCB1c2lu ZyB0aGUgaW5oZXJpdGFuY2UgcHJvcGVydHksIHNvIHRoYXQgdGhlIGF0dHJpYnV0ZXMNCj4gICAg ZGVyaXZhYmxlIGZyb20gdGhlIGxvY2FsIGFkYXB0YXRpb24gaW5mb3JtYXRpb24gZG8gbm90IG5l ZWQgdG8gYmUNCj4gICAgYWR2ZXJ0aXNlZC4gVGh1cywgYW4gb3B0aW1pemF0aW9uIE1BWSBiZSB1 c2VkIHdoZW4gc2V2ZXJhbCBsYXllcnMNCj4gICAgYXJlIHByZXNlbnQgYnkgaW5kaWNhdGluZyB3 aGVuIGFuIGF0dHJpYnV0ZSBpcyBpbmhlcml0YWJsZSBmcm9tIGENCj4gICAgc2VydmVyIGxheWVy Lg0KPiANCj4gDQo+IDUuIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zDQo+IA0KPiANCj4gICAgQVNP TiByb3V0aW5nIHByb3RvY29sIE1VU1QgZGVsaXZlciB0aGUgb3BlcmF0aW9uYWwgc2VjdXJpdHkN Cj4gICAgb2JqZWN0aXZlcyB3aGVyZSByZXF1aXJlZC4gVGhlc2Ugb2JqZWN0aXZlcyBkbyBub3Qg bmVjZXNzYXJpbHkgaW1wbHkNCj4gICAgcmVxdWlyZW1lbnRzIG9uIHRoZSByb3V0aW5nIHByb3Rv Y29sIGl0c2VsZiwgYW5kIE1BWSBiZSBtZXQgYnkgb3RoZXINCj4gICAgZXN0YWJsaXNoZWQgbWVh bnMuDQo+IA0KPiANCj4gNi4gQ29uY2x1c2lvbnMNCj4gDQo+IA0KPiAgICBUaGUgZGVzY3JpcHRp b24gb2YgdGhlIEFTT04gcm91dGluZyBhcmNoaXRlY3R1cmUgYW5kIGNvbXBvbmVudHMgaXMNCj4g ICAgcHJvdmlkZWQgaW4gdGVybXMgb2Ygcm91dGluZyBmdW5jdGlvbmFsaXR5LiBUaGlzIGRlc2Ny aXB0aW9uIGlzIG9ubHkNCj4gICAgY29uY2VwdHVhbDogbm8gcGh5c2ljYWwgcGFydGl0aW9uaW5n IG9mIHRoZXNlIGZ1bmN0aW9ucyBpcyBpbXBsaWVkLg0KPiANCj4gDQo+ICAgIEluIHN1bW1hcnks IHRoZSBBU09OIHJvdXRpbmcgYXJjaGl0ZWN0dXJlIGFzc3VtZXM6DQo+ICAgIC0gQSBuZXR3b3Jr IGlzIHN1YmRpdmlkZWQgaW50byBBU09OIFJBcywgd2hpY2ggTUFZIHN1cHBvcnQgbXVsdGlwbGUN Cj4gICAgICByb3V0aW5nIHByb3RvY29scywgbm8gb25lLXRvLW9uZSByZWxhdGlvbnNoaXAgU0hB TEwgYmUgYXNzdW1lZA0KPiAgICAtIFJvdXRpbmcgQ29udHJvbGxlcnMgKFJDKSBwcm92aWRlIGZv ciB0aGUgZXhjaGFuZ2Ugb2Ygcm91dGluZw0KPiAgICAgIGluZm9ybWF0aW9uIChwcmltaXRpdmVz KSBmb3IgdGhlIFJBLiBUaGUgUkMgaXMgcHJvdG9jb2wNCj4gICAgICBpbmRlcGVuZGVudCBhbmQg TUFZIGJlIHJlYWxpemVkIGJ5IG11bHRpcGxlLCBkaWZmZXJlbnQgcHJvdG9jb2wNCj4gICAgICBj b250cm9sbGVycyB3aXRoaW4gYSBSQS4gVGhlIHJvdXRpbmcgaW5mb3JtYXRpb24gZXhjaGFuZ2Vk IGJldHdlZW4NCj4gICAgICBSQ3MgU0hBTEwgYmUgc3ViamVjdCB0byBwb2xpY3kgY29uc3RyYWlu dHMgaW1wb3NlZCBhdCByZWZlcmVuY2UNCj4gICAgICBwb2ludHMgKEV4dGVybmFsLSBhbmQgSW50 ZXJuYWwtTk5JKQ0KPiA8ICAtIEEgbXVsdGktbGV2ZWwgUkEgaGllcmFyY2h5IGJhc2VkIG9uIGNv bnRhaW5tZW50LCBvbmx5IHRoZSBSQ3Mgb2YNCj4gPCAgICB0aGUgcGFyZW50IFJBIGNvbW11bmlj YXRlLiBSQ3Mgb2YgY2hpbGQgUkFzIG5ldmVyIGNvbW11bmljYXRlIHdpdGgNCj4gDQo+PiAtIElu IGEgbXVsdGktbGV2ZWwgUkEgaGllcmFyY2h5IGJhc2VkIG9uIGNvbnRhaW5tZW50LCBjb21tdW5p Y2F0aW9uDQo+PiAgIGJldHdlZW4gUkNzIG9mIGRpZmZlcmVudCBSQXMgb25seSBoYXBwZW5zIHdo ZW4gdGhlcmUgaXMgYSBwYXJlbnQvDQo+PiAgIGNoaWxkIHJlbGF0aW9uc2hpcCBiZXR3ZWVuIHRo ZSBSQXMuIFJDcyBvZiBjaGlsZCBSQXMgbmV2ZXIgY29tbXVuaWNhdGUgd2l0aA0KPiANCj4gICAg ICB0aGUgUkNzIG9mIG90aGVyIGNoaWxkIFJBcy4gVGhlcmUgU0hPVUxEIG5vdCBiZSBhbnkgZGVw ZW5kZW5jaWVzDQo+ICAgICAgb24gdGhlIGRpZmZlcmVudCByb3V0aW5nIHByb3RvY29scyB1c2Vk IHdpdGhpbiBhIGNoaWxkIFJBIGFuZCB0aGF0DQo+ICAgICAgb2YgaXRzIHBhcmVudC4gVGhlIHJv dXRpbmcgaW5mb3JtYXRpb24gZXhjaGFuZ2VkIHdpdGhpbiB0aGUgcGFyZW50DQo+ICAgICAgUkEg U0hBTEwgYmUgaW5kZXBlbmRlbnQgb2YgYm90aCB0aGUgcm91dGluZyBwcm90b2NvbCBvcGVyYXRp bmcNCj4gICAgICB3aXRoaW4gYSBjaGlsZCBSQSwgYW5kIGFueSBjb250cm9sIGRpc3RyaWJ1dGlv biBjaG9pY2UocyksIGUuZy4NCj4gICAgICBjZW50cmFsaXplZCwgZnVsbHkgZGlzdHJpYnV0ZWQu DQo+ICAgIC0gRm9yIGEgUkEsIHRoZSBzZXQgb2YgUkNzIGlzIHJlZmVycmVkIHRvIGFzIGFuIEFT T04gcm91dGluZw0KPiAgICAgIChjb250cm9sKSBkb21haW4uIFRoZSByb3V0aW5nIGluZm9ybWF0 aW9uIGV4Y2hhbmdlZCBiZXR3ZWVuDQo+ICAgICAgcm91dGluZyBkb21haW5zIChpbnRlci1SQSwg aS5lLiBpbnRlci1kb21haW4pIFNIQUxMIGJlIGluZGVwZW5kZW50DQo+ICAgICAgb2YgYm90aCB0 aGUgaW50cmEtZG9tYWluIHJvdXRpbmcgcHJvdG9jb2wocyksIGFuZCB0aGUgaW50cmEtZG9tYWlu DQo+ICAgICAgY29udHJvbCBkaXN0cmlidXRpb24gY2hvaWNlKHMpLCBlLmcuIGNlbnRyYWxpemVk LCBmdWxseQ0KPiAgICAgIGRpc3RyaWJ1dGVkLiBSQ3MgYm91bmRlZCB0byBkaWZmZXJlbnQgUkEg bGV2ZWxzIE1BWSBiZSBjby1sb2NhdGVkDQo+ICAgICAgd2l0aGluIHRoZSBzYW1lIHBoeXNpY2Fs IGVsZW1lbnQgb3IgcGh5c2ljYWxseSBkaXN0cmlidXRlZC4NCj4gICAgLSBUaGUgcm91dGluZyBh ZGphY2VuY3kgdG9wb2xvZ3kgKGkuZS4gdGhlIGFzc29jaWF0ZWQgUEMNCj4gDQo+IA0KPiANCj4g Vy5BbGFucWFyIGV0IGFsLiAtIEV4cGlyZXMgT2N0b2JlciAyMDA0ICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAxMQ0KPiBkcmFmdC1pZXRmLWNjYW1wLWdtcGxzLWFzb24tcm91dGluZy1yZXF0 cy0wMy50eHQgICAgICAgICAgICBBcHJpbCAyMDA0DQo+IA0KPiANCj4gDQo+ICAgICAgY29ubmVj dGl2aXR5IHRvcG9sb2d5KSBhbmQgdGhlIHRyYW5zcG9ydCBuZXR3b3JrIHRvcG9sb2d5IFNIQUxM DQo+ICAgICAgTk9UIGJlIGFzc3VtZWQgdG8gYmUgY29uZ3J1ZW50DQo+ICAgIC0gVGhlIHJvdXRp bmcgdG9wb2xvZ3kgU0hBTEwgc3VwcG9ydCBtdWx0aXBsZSBsaW5rcyBiZXR3ZWVuIG5vZGVzDQo+ ICAgICAgYW5kIFJBcw0KPiANCj4gDQo+ICAgIEluIHN1bW1hcnksIHRoZSBmb2xsb3dpbmcgZnVu Y3Rpb25hbGl0eSBpcyBleHBlY3RlZCBmcm9tIEdNUExTDQo+ICAgIHJvdXRpbmcgdG8gaW5zdGFu dGlhdGUgdGhlIEFTT04gaGllcmFyY2hpY2FsIHJvdXRpbmcgYXJjaGl0ZWN0dXJlDQo+ICAgIHJl YWxpemF0aW9uIChzZWUgW0cuNzcxNV0gYW5kIFtHLjc3MTUuMV0pOg0KPiAgICAtIFJBcyBTSEFM TCBiZSB1bmlxdWVseSBpZGVudGlmaWFibGUgd2l0aGluIGEgY2FycmllcidzIG5ldHdvcmssDQo+ ICAgICAgZWFjaCBoYXZpbmcgYSB1bmlxdWUgUkEgSUQgd2l0aGluIHRoZSBjYXJyaWVyJ3MgbmV0 d29yay4NCj4gICAgLSBXaXRoaW4gYSBSQSAob25lIGxldmVsKSwgdGhlIHJvdXRpbmcgcHJvdG9j b2wgU0hBTEwgc3VwcG9ydA0KPiAgICAgIGRpc3NlbWluYXRpb24gb2YgaGllcmFyY2hpY2FsIHJv dXRpbmcgaW5mb3JtYXRpb24gKGluY2x1ZGluZw0KPiAgICAgIHN1bW1hcml6ZWQgcm91dGluZyBp bmZvcm1hdGlvbiBmb3Igb3RoZXIgbGV2ZWxzKSBpbiBzdXBwb3J0IG9mIGFuDQo+ICAgICAgYXJj aGl0ZWN0dXJlIG9mIG11bHRpcGxlIGhpZXJhcmNoaWNhbCBsZXZlbHMgb2YgUkFzOyB0aGUgbnVt YmVyIG9mDQo+ICAgICAgaGllcmFyY2hpY2FsIFJBIGxldmVscyB0byBiZSBzdXBwb3J0ZWQgYnkg YSByb3V0aW5nIHByb3RvY29sIGlzDQo+ICAgICAgaW1wbGVtZW50YXRpb24gc3BlY2lmaWMuDQo+ ICAgIC0gVGhlIHJvdXRpbmcgcHJvdG9jb2wgU0hBTEwgc3VwcG9ydCByb3V0aW5nIGluZm9ybWF0 aW9uIGJhc2VkIG9uIGENCj4gICAgICBjb21tb24gc2V0IG9mIGluZm9ybWF0aW9uIGVsZW1lbnRz IGFzIGRlZmluZWQgaW4gW0cuNzcxNV0gYW5kDQo+ICAgICAgW0cuNzcxNS4xXSwgZGl2aWRlZCBi ZXR3ZWVuIGF0dHJpYnV0ZXMgcGVydGFpbmluZyB0byBsaW5rcyBhbmQNCj4gICAgICBhYnN0cmFj dCBub2RlcyAoZWFjaCByZXByZXNlbnRpbmcgZWl0aGVyIGEgc3ViLW5ldHdvcmsgb3Igc2ltcGx5 IGENCj4gICAgICBub2RlKS4gW0cuNzcxNV0gcmVjb2duaXplcyB0aGF0IHRoZSBtYW5uZXIgaW4g d2hpY2ggdGhlIHJvdXRpbmcNCj4gICAgICBpbmZvcm1hdGlvbiBpcyByZXByZXNlbnRlZCBhbmQg ZXhjaGFuZ2VkIHdpbGwgdmFyeSB3aXRoIHRoZQ0KPiAgICAgIHJvdXRpbmcgcHJvdG9jb2wgdXNl ZC4NCj4gICAgLSBUaGUgcm91dGluZyBwcm90b2NvbCBTSEFMTCBjb252ZXJnZSBzdWNoIHRoYXQg dGhlIGRpc3RyaWJ1dGVkIFJEQnMNCj4gICAgICBiZWNvbWUgc3luY2hyb25pemVkIGFmdGVyIGEg cGVyaW9kIG9mIHRpbWUuDQo+IA0KPiANCj4gICAgVG8gc3VwcG9ydCBoaWVyYXJjaGljYWwgcm91 dGluZyBpbmZvcm1hdGlvbiBkaXNzZW1pbmF0aW9uIHdpdGhpbiBhbg0KPiAgICBSQSwgdGhlIHJv dXRpbmcgcHJvdG9jb2wgTVVTVCBkZWxpdmVyOg0KPiA8ICAtIHByb2Nlc3Npbmcgb2Ygcm91dGlu ZyBpbmZvcm1hdGlvbiBleGNoYW5nZWQgYmV0d2VlbiBhZGphY2VudA0KPiANCj4+IC0gUHJvY2Vz c2luZyBvZiByb3V0aW5nIGluZm9ybWF0aW9uIGV4Y2hhbmdlZCBiZXR3ZWVuIGFkamFjZW50DQo+ IA0KPiAgICAgIGxldmVscyBvZiB0aGUgaGllcmFyY2h5IChpLmUuIExldmVsIE4rMSBhbmQgTikg aW5jbHVkaW5nDQo+ICAgICAgcmVhY2hhYmlsaXR5IGFuZCB1cG9uIHBvbGljeSBkZWNpc2lvbiBz dW1tYXJpemVkIHRvcG9sb2d5DQo+ICAgICAgaW5mb3JtYXRpb24NCj4gPCAgLSB3aGVuIG11bHRp cGxlIFJDcyBib3VuZCB0byBhIFJBIHRyYW5zZm9ybSAoZmlsdGVyLCBzdW1tYXJpemUsDQo+IDwg ICAgZXRjLikgYW5kIHRoZW4gZm9yd2FyZCBpbmZvcm1hdGlvbiB0byBSQyhzKSBhdCBkaWZmZXJl bnQgbGV2ZWxzDQo+IDwgICAgdGhhdCB0aGUgcmVzdWx0aW5nIGluZm9ybWF0aW9uIGF0IHRoZSBy ZWNlaXZpbmcgbGV2ZWwgaXMgc2VsZi0NCj4gPCAgICBjb25zaXN0ZW50DQo+IA0KPj4gLSBTZWxm LWNvbnNpc3RlbnQgaW5mb3JtYXRpb24gYXQgdGhlIHJlY2VpdmluZyBsZXZlbCByZXN1bHRpbmcg ZnJvbQ0KPj4gICBhbnkgdHJhbnNmb3JtYXRpb24gKGZpbHRlciwgc3VtbWFyaXplLCBldGMuKSBh bmQgZm9yd2FyZGluZyBvZg0KPj4gICBpbmZvcm1hdGlvbiBmcm9tIG9uZSBSQyB0byBSQyhzKSBh dCBkaWZmZXJlbnQgbGV2ZWxzIHdoZW4gbXVsdGlwbGUNCj4+ICAgUkNzIGJvdW5kIHRvIGEgc2lu Z2xlIFJBDQo+IA0KPiA8ICAtIGEgbWVjaGFuaXNtIHRvIHByZXZlbnQgcmUtaW50cm9kdWN0aW9u IG9mIGluZm9ybWF0aW9uIHByb3BhZ2F0ZWQNCj4gDQo+PiAtIEEgbWVjaGFuaXNtIHRvIHByZXZl bnQgcmUtaW50cm9kdWN0aW9uIG9mIGluZm9ybWF0aW9uIHByb3BhZ2F0ZWQNCj4gDQo+ICAgICAg aW50byB0aGUgTGV2ZWwgTiBSQSdzIFJDIGJhY2sgdG8gdGhlIGFkamFjZW50IGxldmVsIFJBJ3Mg UkMgZnJvbQ0KPiAgICAgIHdoaWNoIHRoaXMgaW5mb3JtYXRpb24gaGFzIGJlZW4gaW5pdGlhbGx5 IHJlY2VpdmVkLg0KPiANCj4gDQo+ICAgIEluIG9yZGVyIHRvIHN1cHBvcnQgb3BlcmF0b3IgYXNz aXN0ZWQgY2hhbmdlcyBpbiB0aGUgY29udGFpbm1lbnQNCj4gICAgcmVsYXRpb25zaGlwcyBvZiBS QXMsIHRoZSByb3V0aW5nIHByb3RvY29sIFNIQUxMIHN1cHBvcnQgZXZvbHV0aW9uDQo+IDwgIGlu IHRlcm1zIG9mIG51bWJlciBvZiBoaWVyYXJjaGljYWwgbGV2ZWxzIG9mIFJBcy4gRXhhbXBsZTog c3VwcG9ydA0KPiANCj4+IGluIHRlcm1zIG9mIG51bWJlciBvZiBoaWVyYXJjaGljYWwgbGV2ZWxz IG9mIFJBcy4gRm9yIGV4YW1wbGU6IHN1cHBvcnQNCj4gDQo+ICAgIG9mIG5vbi1kaXNydXB0aXZl IG9wZXJhdGlvbnMgc3VjaCBhcyBhZGRpbmcgYW5kIHJlbW92aW5nIFJBcyBhdCB0aGUNCj4gICAg dG9wL2JvdHRvbSBvZiB0aGUgaGllcmFyY2h5LCBhZGRpbmcgb3IgcmVtb3ZpbmcgYSBoaWVyYXJj aGljYWwgbGV2ZWwNCj4gICAgb2YgUkFzIGluIG9yIGZyb20gdGhlIG1pZGRsZSBvZiB0aGUgaGll cmFyY2h5LCBhcyB3ZWxsIGFzDQo+ICAgIGFnZ3JlZ2F0aW9uIGFuZCBzZWdtZW50YXRpb24gb2Yg UkFzLiBUaGUgbnVtYmVyIG9mIGhpZXJhcmNoaWNhbA0KPiAgICBsZXZlbHMgdG8gYmUgc3VwcG9y dGVkIGlzIHJvdXRpbmcgcHJvdG9jb2wgc3BlY2lmaWMsIGFuZCByZWZsZWN0cyBhDQo+ICAgIGNv bnRhaW5tZW50IHJlbGF0aW9uc2hpcCBlLmcuIGEgUkEgaW5zZXJ0aW9uIGludm9sdmVzIHN1cHBv cnRpbmcgYQ0KPiAgICBkaWZmZXJlbnQgcm91dGluZyBwcm90b2NvbCBkb21haW4gaW4gYSBwb3J0 aW9uIG9mIHRoZSBuZXR3b3JrLg0KPiANCj4gDQo+IA0KPiANCj4gDQo+IFcuQWxhbnFhciBldCBh bC4gLSBFeHBpcmVzIE9jdG9iZXIgMjAwNCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgMTIN Cj4gZHJhZnQtaWV0Zi1jY2FtcC1nbXBscy1hc29uLXJvdXRpbmctcmVxdHMtMDMudHh0ICAgICAg ICAgICAgQXByaWwgMjAwNA0KPiANCj4gDQo+IA0KPiAgICBSZWFjaGFiaWxpdHkgaW5mb3JtYXRp b24gKHNlZSBTZWN0aW9uIDQuNS4zKSBvZiB0aGUgc2V0IG9mIGVuZHBvaW50cw0KPiAgICByZWFj aGFibGUgYnkgYSBub2RlIG1heSBiZSBhZHZlcnRpc2VkIGVpdGhlciBhcyBhIHNldCBvZiBVTkkN Cj4gICAgVHJhbnNwb3J0IFJlc291cmNlIGFkZHJlc3Nlcy8gYWRkcmVzcyBwcmVmaXhlcywgb3Ig YSBzZXQgb2YNCj4gICAgYXNzb2NpYXRlZCBTTlBQIGxpbmsgSURzL1NOUFAgbGluayBJRCBwcmVm aXhlcywgYXNzaWduZWQgYW5kDQo+ICAgIHNlbGVjdGVkIGNvbnNpc3RlbnRseSBpbiB0aGVpciBh cHBsaWNhYmlsaXR5IHNjb3BlLiBUaGUgZm9ybWF0cyBvZg0KPiAgICB0aGUgY29udHJvbCBwbGFu ZSBpZGVudGlmaWVycyBpbiBhIHByb3RvY29sIHJlYWxpemF0aW9uIGFyZQ0KPiAgICBpbXBsZW1l bnRhdGlvbiBzcGVjaWZpYy4gVXNlIG9mIGEgcm91dGluZyBwcm90b2NvbCB3aXRoaW4gYSBSQQ0K PiAgICBzaG91bGQgbm90IHJlc3RyaWN0IHRoZSBjaG9pY2Ugb2Ygcm91dGluZyBwcm90b2NvbHMg Zm9yIHVzZSBpbiBvdGhlcg0KPiAgICBSQXMgKGNoaWxkIG9yIHBhcmVudCkuDQo+IA0KPiANCj4g ICAgQXMgQVNPTiBkb2VzIG5vdCByZXN0cmljdCB0aGUgY29udHJvbCBwbGFuZSBhcmNoaXRlY3R1 cmUgY2hvaWNlDQo+ICAgIHVzZWQsIGVpdGhlciBhIGNvLWxvY2F0ZWQgYXJjaGl0ZWN0dXJlIG9y IGEgcGh5c2ljYWxseSBzZXBhcmF0ZWQNCj4gICAgYXJjaGl0ZWN0dXJlIG1heSBiZSB1c2VkLiBB IGNvbGxlY3Rpb24gb2YgbGlua3MgYW5kIG5vZGVzIHN1Y2ggYXMgYQ0KPiAgICBzdWItbmV0d29y ayBvciBSQSBNVVNUIGJlIGFibGUgdG8gcmVwcmVzZW50IGl0c2VsZiB0byB0aGUgd2lkZXINCj4g ICAgbmV0d29yayBhcyBhIHNpbmdsZSBsb2dpY2FsIGVudGl0eSB3aXRoIG9ubHkgaXRzIGV4dGVy bmFsIGxpbmtzDQo+ICAgIHZpc2libGUgdG8gdGhlIHRvcG9sb2d5IGRhdGFiYXNlLg0KPiANCj4g DQo+IDcuIEFja25vd2xlZGdlbWVudHMNCj4gDQo+IA0KPiAgICBUaGUgYXV0aG9ycyB3b3VsZCBs aWtlIHRvIHRoYW5rIEtpcmVldGkgS29tcGVsbGEgZm9yIGhhdmluZw0KPiAgICBpbml0aWF0ZWQg dGhlIHByb3Bvc2FsIG9mIGFuIEFTT04gUm91dGluZyBSZXF1aXJlbWVudCBEZXNpZ24gVGVhbS4N Cj4gIyMgUGVyaGFwcyBpdCB3b3VsZCBiZSBnb29kIHRvIGFja25vd2xlZGdlIGFueSBvdGhlciBj b250cmlidXRvcnMgeW91IGhhZC4NCj4gIyMgSW4gcGFydGljdWxhciBTRzE0LzE1IGZvciB0aGVp ciBjYXJlZnVsIHJldmlldyBhbmQgaW5wdXQuDQo+IA0KPiA4LiBJbnRlbGxlY3R1YWwgUHJvcGVy dHkgQ29uc2lkZXJhdGlvbnMNCj4gDQo+IA0KPiAgICBUaGUgSUVURiB0YWtlcyBubyBwb3NpdGlv biByZWdhcmRpbmcgdGhlIHZhbGlkaXR5IG9yIHNjb3BlIG9mIGFueQ0KPiAgICBJbnRlbGxlY3R1 YWwgUHJvcGVydHkgUmlnaHRzIG9yIG90aGVyIHJpZ2h0cyB0aGF0IG1pZ2h0IGJlIGNsYWltZWQN Cj4gICAgdG8gcGVydGFpbiB0byB0aGUgaW1wbGVtZW50YXRpb24gb3IgdXNlIG9mIHRoZSB0ZWNo bm9sb2d5DQo+ICAgIGRlc2NyaWJlZCBpbiB0aGlzIGRvY3VtZW50IG9yIHRoZSBleHRlbnQgdG8g d2hpY2ggYW55IGxpY2Vuc2UNCj4gICAgdW5kZXIgc3VjaCByaWdodHMgbWlnaHQgb3IgbWlnaHQg bm90IGJlIGF2YWlsYWJsZTsgbm9yIGRvZXMgaXQNCj4gICAgcmVwcmVzZW50IHRoYXQgaXQgaGFz IG1hZGUgYW55IGluZGVwZW5kZW50IGVmZm9ydCB0byBpZGVudGlmeSBhbnkNCj4gICAgc3VjaCBy aWdodHMuIEluZm9ybWF0aW9uIG9uIHRoZSBwcm9jZWR1cmVzIHdpdGggcmVzcGVjdCB0byByaWdo dHMNCj4gICAgaW4gUkZDIGRvY3VtZW50cyBjYW4gYmUgZm91bmQgaW4gQkNQIDc4IGFuZCBCQ1Ag NzkuDQo+IA0KPiANCj4gICAgQ29waWVzIG9mIElQUiBkaXNjbG9zdXJlcyBtYWRlIHRvIHRoZSBJ RVRGIFNlY3JldGFyaWF0IGFuZCBhbnkNCj4gICAgYXNzdXJhbmNlcyBvZiBsaWNlbnNlcyB0byBi ZSBtYWRlIGF2YWlsYWJsZSwgb3IgdGhlIHJlc3VsdCBvZiBhbg0KPiAgICBhdHRlbXB0IG1hZGUg dG8gb2J0YWluIGEgZ2VuZXJhbCBsaWNlbnNlIG9yIHBlcm1pc3Npb24gZm9yIHRoZSB1c2UNCj4g ICAgb2Ygc3VjaCBwcm9wcmlldGFyeSByaWdodHMgYnkgaW1wbGVtZW50ZXJzIG9yIHVzZXJzIG9m IHRoaXMNCj4gICAgc3BlY2lmaWNhdGlvbiBjYW4gYmUgb2J0YWluZWQgZnJvbSB0aGUgSUVURiBv bi1saW5lIElQUiByZXBvc2l0b3J5DQo+ICAgIGF0IGh0dHA6Ly93d3cuaWV0Zi5vcmcvaXByLg0K PiANCj4gDQo+ICAgIFRoZSBJRVRGIGludml0ZXMgYW55IGludGVyZXN0ZWQgcGFydHkgdG8gYnJp bmcgdG8gaXRzIGF0dGVudGlvbg0KPiAgICBhbnkgY29weXJpZ2h0cywgcGF0ZW50cyBvciBwYXRl bnQgYXBwbGljYXRpb25zLCBvciBvdGhlcg0KPiAgICBwcm9wcmlldGFyeSByaWdodHMgdGhhdCBt YXkgY292ZXIgdGVjaG5vbG9neSB0aGF0IG1heSBiZSByZXF1aXJlZA0KPiAgICB0byBpbXBsZW1l bnQgdGhpcyBzdGFuZGFyZC4gIFBsZWFzZSBhZGRyZXNzIHRoZSBpbmZvcm1hdGlvbiB0byB0aGUN Cj4gICAgSUVURiBhdCBpZXRmLWlwckBpZXRmLm9yZy4NCj4gDQo+IA0KPiA4LjEgSVBSIERpc2Ns b3N1cmUgQWNrbm93bGVkZ2VtZW50DQo+IA0KPiANCj4gICAgQnkgc3VibWl0dGluZyB0aGlzIElu dGVybmV0LURyYWZ0LCBJIGNlcnRpZnkgdGhhdCBhbnkgYXBwbGljYWJsZQ0KPiAgICBwYXRlbnQg b3Igb3RoZXIgSVBSIGNsYWltcyBvZiB3aGljaCBJIGFtIGF3YXJlIGhhdmUgYmVlbiBkaXNjbG9z ZWQsDQo+ICAgIGFuZCBhbnkgb2Ygd2hpY2ggSSBiZWNvbWUgYXdhcmUgd2lsbCBiZSBkaXNjbG9z ZWQsIGluIGFjY29yZGFuY2UNCj4gICAgd2l0aCBSRkMgMzY2OC4NCj4gDQo+IA0KPiANCj4gVy5B bGFucWFyIGV0IGFsLiAtIEV4cGlyZXMgT2N0b2JlciAyMDA0ICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAxMw0KPiBkcmFmdC1pZXRmLWNjYW1wLWdtcGxzLWFzb24tcm91dGluZy1yZXF0cy0w My50eHQgICAgICAgICAgICBBcHJpbCAyMDA0DQo+IA0KPiANCj4gDQo+IDkuIFJlZmVyZW5jZXMN Cj4gDQo+IA0KPiA5LjEgTm9ybWF0aXZlIFJlZmVyZW5jZXMNCj4gDQo+IA0KPiAgICBbUkZDMjAy Nl0gICAgUy5CcmFkbmVyLCAiVGhlIEludGVybmV0IFN0YW5kYXJkcyBQcm9jZXNzIC0tDQo+ICAg ICAgICAgICAgICAgICBSZXZpc2lvbiAzIiwgQkNQIDksIFJGQyAyMDI2LCBPY3RvYmVyIDE5OTYu DQo+IA0KPiANCj4gICAgW1JGQzIxMTldICAgIFMuQnJhZG5lciwgIktleSB3b3JkcyBmb3IgdXNl IGluIFJGQ3MgdG8gSW5kaWNhdGUNCj4gICAgICAgICAgICAgICAgIFJlcXVpcmVtZW50IExldmVs cyIsIEJDUCAxNCwgUkZDIDIxMTksIE1hcmNoIDE5OTcuDQo+IA0KPiANCj4gICAgW0cuNzcxNV0g ICAgIElUVS1UIFJlYy4gRy43NzE1L1kuMTMwNiwgIkFyY2hpdGVjdHVyZSBhbmQNCj4gICAgICAg ICAgICAgICAgIFJlcXVpcmVtZW50cyBmb3IgdGhlIEF1dG9tYXRpY2FsbHkgU3dpdGNoZWQgT3B0 aWNhbA0KPiAgICAgICAgICAgICAgICAgTmV0d29yayAoQVNPTiksIiBKdW5lIDIwMDIuDQo+IA0K PiANCj4gICAgW0cuNzcxNS4xXSAgIElUVS1UIERyYWZ0IFJlYy4gRy43NzE1LjEvWS4xNzA2LjEs ICJBU09OIFJvdXRpbmcNCj4gICAgICAgICAgICAgICAgIEFyY2hpdGVjdHVyZSBhbmQgUmVxdWly ZW1lbnRzIGZvciBMaW5rIFN0YXRlDQo+ICAgICAgICAgICAgICAgICBQcm90b2NvbHMsIiBOb3Zl bWJlciAyMDAzLg0KPiANCj4gDQo+ICAgIFtHLjgwODBdICAgICBJVFUtVCBSZWMuIEcuODA4MC9Z LjEzMDQsICJBcmNoaXRlY3R1cmUgZm9yIHRoZQ0KPiAgICAgICAgICAgICAgICAgQXV0b21hdGlj YWxseSBTd2l0Y2hlZCBPcHRpY2FsIE5ldHdvcmsgKEFTT04pLCINCj4gICAgICAgICAgICAgICAg IE5vdmVtYmVyIDIwMDEgKGFuZCBSZXZpc2lvbiwgSmFudWFyeSAyMDAzKS4NCj4gDQo+IA0KPiAg ICBbSElFUl0gICAgICAgSy5Lb21wZWxsYSBhbmQgWS5SZWtodGVyLCAiTFNQIEhpZXJhcmNoeSB3 aXRoDQo+ICAgICAgICAgICAgICAgICBHZW5lcmFsaXplZCBNUExTIFRFLCIgSW50ZXJuZXQgZHJh ZnQgKHdvcmsgaW4NCj4gICAgICAgICAgICAgICAgIHByb2dyZXNzKSwgZHJhZnQtaWV0Zi1tcGxz LWxzcC1oaWVyYXJjaHksIFNlcHRlbWJlciAwMi4NCj4gDQo+ICMjIFdvdWxkIGl0IGJlIE9LIHRv IG1ha2UgdGhlIGV4dGVybmFsIHJlZmVyZW5jZXMgaW5mb3JtYXRpdmU/DQo+IA0KPiAxMC4gQXV0 aG9yJ3MgQWRkcmVzc2VzDQo+IA0KPiANCj4gICAgV2VzYW0gQWxhbnFhciAoU3ByaW50KQ0KPiAg ICBFTWFpbDogd2VzYW0uYWxhbnFhckBtYWlsLnNwcmludC5jb20NCj4gDQo+IA0KPiAgICBEZWJv cmFoIEJydW5nYXJkIChBVCZUKQ0KPiAgICBSbS4gRDEtM0MyMiAtIDIwMCBTLiBMYXVyZWwgQXZl Lg0KPiAgICBNaWRkbGV0b3duLCBOSiAwNzc0OCwgVVNBDQo+ICAgIFBob25lOiArMSA3MzIgNDIw MTU3Mw0KPiAgICBFTWFpbDogZGJydW5nYXJkQGF0dC5jb20NCj4gDQo+IA0KPiAgICBEYXZpZCBN ZXllciAoQ2lzY28gU3lzdGVtcykNCj4gICAgRU1haWw6IGRtbUAxLTQtNS5uZXQNCj4gDQo+IA0K PiAgICBMeW5kb24gT25nIChDaWVuYSBDb3Jwb3JhdGlvbikNCj4gICAgNTk2NSBTaWx2ZXIgQ3Jl ZWsgVmFsbGV5IFJkLA0KPiAgICBTYW4gSm9zZSwgQ0EgOTUxMjgsIFVTQQ0KPiAgICBQaG9uZTog KzEgNDA4IDgzNDc4OTQNCj4gICAgRU1haWw6IGx5b25nQGNpZW5hLmNvbQ0KPiANCj4gDQo+ICAg IERpbWl0cmkgUGFwYWRpbWl0cmlvdSAoQWxjYXRlbCkNCj4gICAgRnJhbmNpcyBXZWxsZW5zcGxl aW4gMSwNCj4gICAgQi0yMDE4IEFudHdlcnBlbiwgQmVsZ2l1bQ0KPiAgICBQaG9uZTogKzMyIDMg MjQwODQ5MQ0KPiAgICBFTWFpbDogZGltaXRyaS5wYXBhZGltaXRyaW91QGFsY2F0ZWwuYmUNCj4g DQo+IA0KPiANCj4gDQo+IFcuQWxhbnFhciBldCBhbC4gLSBFeHBpcmVzIE9jdG9iZXIgMjAwNCAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgMTQNCj4gZHJhZnQtaWV0Zi1jY2FtcC1nbXBscy1h c29uLXJvdXRpbmctcmVxdHMtMDMudHh0ICAgICAgICAgICAgQXByaWwgMjAwNA0KPiANCj4gDQo+ IA0KPiAgICBKb25hdGhhbiBTYWRsZXINCj4gICAgMTQxNSBXLiBEaWVobCBSZA0KPiAgICBOYXBl cnZpbGxlLCBJTCA2MDU2Mw0KPiAgICBFTWFpbDogam9uYXRoYW4uc2FkbGVyQHRlbGxhYnMuY29t DQo+IA0KPiANCj4gICAgU3RlcGhlbiBTaGV3IChOb3J0ZWwgTmV0d29ya3MpDQo+ICAgIFBPIEJv eCAzNTExIFN0YXRpb24gQw0KPiAgICBPdHRhd2EsIE9udGFyaW8sIENBTkFEQSBLMVkgNEg3DQo+ ICAgIFBob25lOiArMSA2MTMgNzYzMjQ2Mg0KPiAgICBFTWFpbDogc2RzaGV3QG5vcnRlbG5ldHdv cmtzLmNvbQ0KPiANCj4gDQo+IA0KPiANCj4gDQo+IA0KPiANCj4gDQo+IA0KPiANCj4gDQo+IA0K PiANCj4gDQo+IA0KPiANCj4gDQo+IA0KPiANCj4gDQo+IA0KPiANCj4gDQo+IA0KPiANCj4gDQo+ IA0KPiANCj4gDQo+IA0KPiANCj4gDQo+IA0KPiANCj4gDQo+IA0KPiANCj4gDQo+IA0KPiANCj4g DQo+IA0KPiANCj4gDQo+IA0KPiBXLkFsYW5xYXIgZXQgYWwuIC0gRXhwaXJlcyBPY3RvYmVyIDIw MDQgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDE1DQo+IGRyYWZ0LWlldGYtY2NhbXAtZ21w bHMtYXNvbi1yb3V0aW5nLXJlcXRzLTAzLnR4dCAgICAgICAgICAgIEFwcmlsIDIwMDQNCj4gDQo+ IA0KPiANCj4gQXBwZW5kaXggMTogQVNPTiBUZXJtaW5vbG9neQ0KPiANCj4gDQo+ICAgIFRoaXMg ZG9jdW1lbnQgbWFrZXMgdXNlIG9mIHRoZSBmb2xsb3dpbmcgdGVybXM6DQo+IA0KPiANCj4gICAg QWRtaW5pc3RyYXRpdmUgZG9tYWluOiAoUmVjb21tZW5kYXRpb24gRy44MDUgRm9yIHRoZSBwdXJw b3NlcyBvZg0KPiAgICBbRzc3MTUuMV0gYW4gYWRtaW5pc3RyYXRpdmUgZG9tYWluIHJlcHJlc2Vu dHMgdGhlIGV4dGVudCBvZg0KPiAgICByZXNvdXJjZXMgd2hpY2ggYmVsb25nIHRvIGEgc2luZ2xl IHBsYXllciBzdWNoIGFzIGEgbmV0d29yaw0KPiAgICBvcGVyYXRvciwgYSBzZXJ2aWNlIHByb3Zp ZGVyLCBvciBhbiBlbmQtdXNlci4gQWRtaW5pc3RyYXRpdmUgZG9tYWlucw0KPiAgICBvZiBkaWZm ZXJlbnQgcGxheWVycyBkbyBub3Qgb3ZlcmxhcCBhbW9uZ3N0IHRoZW1zZWx2ZXMuDQo+IA0KPiAN Cj4gICAgQ29udHJvbCBwbGFuZTogcGVyZm9ybXMgdGhlIGNhbGwgY29udHJvbCBhbmQgY29ubmVj dGlvbiBjb250cm9sDQo+ICAgIGZ1bmN0aW9ucy4gVGhyb3VnaCBzaWduYWxpbmcsIHRoZSBjb250 cm9sIHBsYW5lIHNldHMgdXAgYW5kIHJlbGVhc2VzDQo+ICAgIGNvbm5lY3Rpb25zLCBhbmQgbWF5 IHJlc3RvcmUgYSBjb25uZWN0aW9uIGluIGNhc2Ugb2YgYSBmYWlsdXJlLg0KPiANCj4gDQo+ICAg IChDb250cm9sKSBEb21haW46IHJlcHJlc2VudHMgYSBjb2xsZWN0aW9uIG9mIChjb250cm9sKSBl bnRpdGllcyB0aGF0DQo+ICAgIGFyZSBncm91cGVkIGZvciBhIHBhcnRpY3VsYXIgcHVycG9zZS4g VGhlIGNvbnRyb2wgcGxhbmUgaXMNCj4gICAgc3ViZGl2aWRlZCBpbnRvIGRvbWFpbnMgbWF0Y2hp bmcgYWRtaW5pc3RyYXRpdmUgZG9tYWlucy4gV2l0aGluIGFuDQo+ICAgIGFkbWluaXN0cmF0aXZl IGRvbWFpbiwgZnVydGhlciBzdWJkaXZpc2lvbnMgb2YgdGhlIGNvbnRyb2wgcGxhbmUgYXJlDQo+ ICAgIHJlY3Vyc2l2ZWx5IGFwcGxpZWQuIEEgcm91dGluZyBjb250cm9sIGRvbWFpbiBpcyBhbiBh YnN0cmFjdCBlbnRpdHkNCj4gICAgdGhhdCBoaWRlcyB0aGUgZGV0YWlscyBvZiB0aGUgUkMgZGlz dHJpYnV0aW9uLg0KPiANCj4gDQo+ICAgIEV4dGVybmFsIE5OSSAoRS1OTkkpOiBpbnRlcmZhY2Vz IGFyZSBsb2NhdGVkIGJldHdlZW4gcHJvdG9jb2wNCj4gICAgY29udHJvbGxlcnMgYmV0d2VlbiBj b250cm9sIGRvbWFpbnMuDQo+IA0KPiANCj4gICAgSW50ZXJuYWwgTk5JIChJLU5OSSk6IGludGVy ZmFjZXMgYXJlIGxvY2F0ZWQgYmV0d2VlbiBwcm90b2NvbA0KPiAgICBjb250cm9sbGVycyB3aXRo aW4gY29udHJvbCBkb21haW5zLg0KPiANCj4gDQo+ICAgIExpbms6IFtTZWUgUmVjb21tZW5kYXRp b24gRy44MDVdIGEgInRvcG9sb2dpY2FsIGNvbXBvbmVudCIgd2hpY2gNCj4gICAgZGVzY3JpYmVz IGEgZml4ZWQgcmVsYXRpb25zaGlwIGJldHdlZW4gYSAic3VibmV0d29yayIgb3IgImFjY2Vzcw0K PiAgICBncm91cCIgYW5kIGFub3RoZXIgInN1Ym5ldHdvcmsiIG9yICJhY2Nlc3MgZ3JvdXAiLiBM aW5rcyBhcmUgbm90DQo+ICAgIGxpbWl0ZWQgdG8gYmVpbmcgcHJvdmlkZWQgYnkgYSBzaW5nbGUg c2VydmVyIHRyYWlsLg0KPiANCj4gDQo+ICAgIE1hbmFnZW1lbnQgcGxhbmU6IHBlcmZvcm1zIG1h bmFnZW1lbnQgZnVuY3Rpb25zIGZvciB0aGUgVHJhbnNwb3J0DQo+ICAgIFBsYW5lLCB0aGUgY29u dHJvbCBwbGFuZSBhbmQgdGhlIHN5c3RlbSBhcyBhIHdob2xlLiBJdCBhbHNvIHByb3ZpZGVzDQo+ ICAgIGNvb3JkaW5hdGlvbiBiZXR3ZWVuIGFsbCB0aGUgcGxhbmVzLiBUaGUgZm9sbG93aW5nIG1h bmFnZW1lbnQNCj4gICAgZnVuY3Rpb25hbCBhcmVhcyBhcmUgcGVyZm9ybWVkIGluIHRoZSBtYW5h Z2VtZW50IHBsYW5lOiBwZXJmb3JtYW5jZSwNCj4gICAgZmF1bHQsIGNvbmZpZ3VyYXRpb24sIGFj Y291bnRpbmcgYW5kIHNlY3VyaXR5IG1hbmFnZW1lbnQNCj4gDQo+IA0KPiAgICBNYW5hZ2VtZW50 IGRvbWFpbjogW1NlZSBSZWNvbW1lbmRhdGlvbiBHLjgwNV0gQSBtYW5hZ2VtZW50IGRvbWFpbg0K PiAgICBkZWZpbmVzIGEgY29sbGVjdGlvbiBvZiBtYW5hZ2VkIG9iamVjdHMgd2hpY2ggYXJlIGdy b3VwZWQgdG8gbWVldA0KPiAgICBvcmdhbml6YXRpb25hbCByZXF1aXJlbWVudHMgYWNjb3JkaW5n IHRvIGdlb2dyYXBoeSwgdGVjaG5vbG9neSwNCj4gICAgcG9saWN5IG9yIG90aGVyIHN0cnVjdHVy ZSwgYW5kIGZvciBhIG51bWJlciBvZiBmdW5jdGlvbmFsIGFyZWFzIHN1Y2gNCj4gICAgYXMgY29u ZmlndXJhdGlvbiwgc2VjdXJpdHksIChGQ0FQUyksIGZvciB0aGUgcHVycG9zZSBvZiBwcm92aWRp bmcNCj4gICAgY29udHJvbCBpbiBhIGNvbnNpc3RlbnQgbWFubmVyLiBNYW5hZ2VtZW50IGRvbWFp bnMgY2FuIGJlIGRpc2pvaW50LA0KPiAgICBjb250YWluZWQgb3Igb3ZlcmxhcHBpbmcuIEFzIHN1 Y2ggdGhlIHJlc291cmNlcyB3aXRoaW4gYW4NCj4gICAgYWRtaW5pc3RyYXRpdmUgZG9tYWluIGNh biBiZSBkaXN0cmlidXRlZCBpbnRvIHNldmVyYWwgcG9zc2libGUNCj4gICAgb3ZlcmxhcHBpbmcg bWFuYWdlbWVudCBkb21haW5zLiBUaGUgc2FtZSByZXNvdXJjZSBjYW4gdGhlcmVmb3JlDQo+ICAg IGJlbG9uZyB0byBzZXZlcmFsIG1hbmFnZW1lbnQgZG9tYWlucyBzaW11bHRhbmVvdXNseSwgYnV0 IGENCj4gICAgbWFuYWdlbWVudCBkb21haW4gc2hhbGwgbm90IGNyb3NzIHRoZSBib3JkZXIgb2Yg YW4gYWRtaW5pc3RyYXRpdmUNCj4gICAgZG9tYWluLg0KPiANCj4gDQo+IA0KPiANCj4gDQo+IFcu QWxhbnFhciBldCBhbC4gLSBFeHBpcmVzIE9jdG9iZXIgMjAwNCAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgMTYNCj4gZHJhZnQtaWV0Zi1jY2FtcC1nbXBscy1hc29uLXJvdXRpbmctcmVxdHMt MDMudHh0ICAgICAgICAgICAgQXByaWwgMjAwNA0KPiANCj4gDQo+IA0KPiAgICBTTlA6IFRoZSBT TlAgaXMgYSBjb250cm9sIHBsYW5lIGFic3RyYWN0aW9uIHRoYXQgcmVwcmVzZW50cyBhbg0KPiAg ICBhY3R1YWwgb3IgcG90ZW50aWFsIHRyYW5zcG9ydCBwbGFuZSByZXNvdXJjZS4gU05QcyAoaW4g ZGlmZmVyZW50DQo+ICAgIHN1Ym5ldHdvcmsgcGFydGl0aW9ucykgbWF5IHJlcHJlc2VudCB0aGUg c2FtZSB0cmFuc3BvcnQgcmVzb3VyY2UuIEENCj4gICAgb25lLXRvLW9uZSBjb3JyZXNwb25kZW5j ZSBzaG91bGQgbm90IGJlIGFzc3VtZWQuDQo+IA0KPiANCj4gIyMgQWRkIFNOUFANCj4gIyMgQWRk IFRDUA0KPiANCj4gICAgVHJhbnNwb3J0IHBsYW5lOiBwcm92aWRlcyBiaS1kaXJlY3Rpb25hbCBv ciB1bmlkaXJlY3Rpb25hbCB0cmFuc2Zlcg0KPiAgICBvZiB1c2VyIGluZm9ybWF0aW9uLCBmcm9t IG9uZSBsb2NhdGlvbiB0byBhbm90aGVyLiBJdCBjYW4gYWxzbw0KPiAgICBwcm92aWRlIHRyYW5z ZmVyIG9mIHNvbWUgY29udHJvbCBhbmQgbmV0d29yayBtYW5hZ2VtZW50IGluZm9ybWF0aW9uLg0K PiAgICBUaGUgVHJhbnNwb3J0IFBsYW5lIGlzIGxheWVyZWQ7IGl0IGlzIGVxdWl2YWxlbnQgdG8g dGhlIFRyYW5zcG9ydA0KPiAgICBOZXR3b3JrIGRlZmluZWQgaW4gRy44MDUuDQo+IA0KPiANCj4g ICAgVXNlciBOZXR3b3JrIEludGVyZmFjZSAoVU5JKTogaW50ZXJmYWNlcyBhcmUgbG9jYXRlZCBi ZXR3ZWVuDQo+ICAgIHByb3RvY29sIGNvbnRyb2xsZXJzIGJldHdlZW4gYSB1c2VyIGFuZCBhIGNv bnRyb2wgZG9tYWluLiBOb3RlOg0KPiAgICB0aGVyZSBpcyBubyByb3V0aW5nIGZ1bmN0aW9uIGFz c29jaWF0ZWQgd2l0aCBhIFVOSSByZWZlcmVuY2UgcG9pbnQuDQo+IA0KPiANCj4gDQo+IA0KPiAN Cj4gDQo+IA0KPiANCj4gDQo+IA0KPiANCj4gDQo+IA0KPiANCj4gDQo+IA0KPiANCj4gDQo+IA0K PiANCj4gDQo+IA0KPiANCj4gDQo+IA0KPiANCj4gDQo+IA0KPiANCj4gDQo+IA0KPiANCj4gDQo+ IA0KPiANCj4gDQo+IA0KPiANCj4gDQo+IA0KPiANCj4gVy5BbGFucWFyIGV0IGFsLiAtIEV4cGly ZXMgT2N0b2JlciAyMDA0ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAxNw0KPiBkcmFmdC1p ZXRmLWNjYW1wLWdtcGxzLWFzb24tcm91dGluZy1yZXF0cy0wMy50eHQgICAgICAgICAgICBBcHJp bCAyMDA0DQo+IA0KPiANCj4gDQo+IEFwcGVuZGl4IDI6IEFTT04gUm91dGluZyBUZXJtaW5vbG9n eQ0KPiANCj4gDQo+ICAgIFRoaXMgZG9jdW1lbnQgbWFrZXMgdXNlIG9mIHRoZSBmb2xsb3dpbmcg dGVybXM6DQo+IA0KPiANCj4gICAgUm91dGluZyBBcmVhIChSQSk6IGEgUkEgcmVwcmVzZW50cyBh IHBhcnRpdGlvbiBvZiB0aGUgZGF0YSBwbGFuZSBhbmQNCj4gICAgaXRzIGlkZW50aWZpZXIgaXMg dXNlZCB3aXRoaW4gdGhlIGNvbnRyb2wgcGxhbmUgYXMgdGhlDQo+ICAgIHJlcHJlc2VudGF0aW9u IG9mIHRoaXMgcGFydGl0aW9uLiBQZXIgW0cuODA4MF0gYSBSQSBpcyBkZWZpbmVkIGJ5IGENCj4g ICAgc2V0IG9mIHN1Yi1uZXR3b3JrcywgdGhlIFRFIGxpbmtzIHRoYXQgaW50ZXJjb25uZWN0IHRo ZW0sIGFuZCB0aGUNCj4gICAgaW50ZXJmYWNlcyByZXByZXNlbnRpbmcgdGhlIGVuZHMgb2YgdGhl IFRFIGxpbmtzIGV4aXRpbmcgdGhhdCBSQS4gQQ0KPiAgICBSQSBtYXkgY29udGFpbiBzbWFsbGVy IFJBcyBpbnRlci1jb25uZWN0ZWQgYnkgVEUgbGlua3MuIFRoZSBsaW1pdCBvZg0KPiAgICBzdWJk aXZpc2lvbiByZXN1bHRzIGluIGEgUkEgdGhhdCBjb250YWlucyB0d28gc3ViLW5ldHdvcmtzIGFu ZCBhIFRFDQo+ICAgIGxpbmsgd2l0aCBhIHNpbmdsZSBjb21wb25lbnQgbGluay4NCj4gDQo+IA0K PiAgICBSb3V0aW5nIERhdGFiYXNlIChSREIpOiByZXBvc2l0b3J5IGZvciB0aGUgbG9jYWwgdG9w b2xvZ3ksIG5ldHdvcmsNCj4gICAgdG9wb2xvZ3ksIHJlYWNoYWJpbGl0eSwgYW5kIG90aGVyIHJv dXRpbmcgaW5mb3JtYXRpb24gdGhhdCBpcw0KPiAgICB1cGRhdGVkIGFzIHBhcnQgb2YgdGhlIHJv dXRpbmcgaW5mb3JtYXRpb24gZXhjaGFuZ2UgYW5kIG1heQ0KPiAgICBhZGRpdGlvbmFsbHkgY29u dGFpbiBpbmZvcm1hdGlvbiB0aGF0IGlzIGNvbmZpZ3VyZWQuIFRoZSBSREIgbWF5DQo+ICAgIGNv bnRhaW4gcm91dGluZyBpbmZvcm1hdGlvbiBmb3IgbW9yZSB0aGFuIG9uZSBSb3V0aW5nIEFyZWEg KFJBKS4NCj4gDQo+IA0KPiAgICBSb3V0aW5nIENvbXBvbmVudHM6IEFTT04gcm91dGluZyBhcmNo aXRlY3R1cmUgZnVuY3Rpb25zLiBUaGVzZQ0KPiAgICBmdW5jdGlvbnMgY2FuIGJlIGNsYXNzaWZp ZWQgYXMgcHJvdG9jb2wgaW5kZXBlbmRlbnQgKExpbmsgUmVzb3VyY2UNCj4gICAgTWFuYWdlciBv ciBMUk0sIFJvdXRpbmcgQ29udHJvbGxlciBvciBSQykgYW5kIHByb3RvY29sIHNwZWNpZmljDQo+ ICAgIChQcm90b2NvbCBDb250cm9sbGVyIG9yIFBDKS4NCj4gDQo+IA0KPiAgICBSb3V0aW5nIENv bnRyb2xsZXIgKFJDKTogaGFuZGxlcyAoYWJzdHJhY3QpIGluZm9ybWF0aW9uIG5lZWRlZCBmb3IN Cj4gICAgcm91dGluZyBhbmQgdGhlIHJvdXRpbmcgaW5mb3JtYXRpb24gZXhjaGFuZ2Ugd2l0aCBw ZWVyaW5nIFJDcyBieQ0KPiAgICBvcGVyYXRpbmcgb24gdGhlIFJEQi4gVGhlIFJDIGhhcyBhY2Nl c3MgdG8gYSB2aWV3IG9mIHRoZSBSREIuIFRoZSBSQw0KPiAgICBpcyBwcm90b2NvbCBpbmRlcGVu ZGVudC4NCj4gDQo+IA0KPiAgICBOb3RlOiBTaW5jZSB0aGUgUkRCIG1heSBjb250YWluIHJvdXRp bmcgaW5mb3JtYXRpb24gcGVydGFpbmluZyB0bw0KPiAgICBtdWx0aXBsZSBSQXMgKGFuZCBwb3Nz aWJseSB0byBtdWx0aXBsZSBsYXllciBuZXR3b3JrcyksIHRoZSBSQ3MNCj4gICAgYWNjZXNzaW5n IHRoZSBSREIgbWF5IHNoYXJlIHRoZSByb3V0aW5nIGluZm9ybWF0aW9uLg0KPiANCj4gDQo+ICAg IExpbmsgUmVzb3VyY2UgTWFuYWdlciAoTFJNKTogc3VwcGxpZXMgYWxsIHRoZSByZWxldmFudCBj b21wb25lbnQgYW5kDQo+ICAgIFRFIGxpbmsgaW5mb3JtYXRpb24gdG8gdGhlIFJDLiBJdCBpbmZv cm1zIHRoZSBSQyBhYm91dCBhbnkgc3RhdGUNCj4gICAgY2hhbmdlcyBvZiB0aGUgbGluayByZXNv dXJjZXMgaXQgY29udHJvbHMuDQo+IA0KPiANCj4gICAgUHJvdG9jb2wgQ29udHJvbGxlciAoUEMp OiBoYW5kbGVzIHByb3RvY29sIHNwZWNpZmljIG1lc3NhZ2UNCj4gICAgZXhjaGFuZ2VzIGFjY29y ZGluZyB0byB0aGUgcmVmZXJlbmNlIHBvaW50IG92ZXIgd2hpY2ggdGhlDQo+ICAgIGluZm9ybWF0 aW9uIGlzIGV4Y2hhbmdlZCAoZS5nLiBFLU5OSSwgSS1OTkkpLCBhbmQgaW50ZXJuYWwgZXhjaGFu Z2VzDQo+ICAgIHdpdGggdGhlIFJDLiBUaGUgUEMgZnVuY3Rpb24gaXMgcHJvdG9jb2wgZGVwZW5k ZW50Lg0KPiANCj4gDQo+IA0KPiANCj4gDQo+IA0KPiANCj4gDQo+IA0KPiANCj4gDQo+IA0KPiAN Cj4gDQo+IFcuQWxhbnFhciBldCBhbC4gLSBFeHBpcmVzIE9jdG9iZXIgMjAwNCAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgMTgNCj4gZHJhZnQtaWV0Zi1jY2FtcC1nbXBscy1hc29uLXJvdXRp bmctcmVxdHMtMDMudHh0ICAgICAgICAgICAgQXByaWwgMjAwNA0KPiANCj4gDQo+IA0KPiBGdWxs IENvcHlyaWdodCBTdGF0ZW1lbnQNCj4gDQo+ICMjIFJlcXVpcmUgbmV3IGNvcHlyaWdodCBib2ls ZXJwbGF0ZQ0KPiANCj4gDQo+ICAgIENvcHlyaWdodCAoQykgVGhlIEludGVybmV0IFNvY2lldHkg KDIwMDQpLiBUaGlzIGRvY3VtZW50IGlzIHN1YmplY3QNCj4gICAgdG8gdGhlIHJpZ2h0cywgbGlj ZW5zZXMgYW5kIHJlc3RyaWN0aW9ucyBjb250YWluZWQgaW4gQkNQIDc4IGFuZA0KPiAgICBleGNl cHQgYXMgc2V0IGZvcnRoIHRoZXJlaW4sIHRoZSBhdXRob3JzIHJldGFpbiBhbGwgdGhlaXIgcmln aHRzLg0KPiANCj4gDQo+ICAgIFRoaXMgZG9jdW1lbnQgYW5kIHRyYW5zbGF0aW9ucyBvZiBpdCBt YXkgYmUgY29waWVkIGFuZCBmdXJuaXNoZWQgdG8NCj4gICAgb3RoZXJzLCBhbmQgZGVyaXZhdGl2 ZSB3b3JrcyB0aGF0IGNvbW1lbnQgb24gb3Igb3RoZXJ3aXNlIGV4cGxhaW4gaXQNCj4gICAgb3Ig YXNzaXN0IGluIGl0cyBpbXBsZW1lbnRhdGlvbiBtYXkgYmUgcHJlcGFyZWQsIGNvcGllZCwgcHVi bGlzaGVkDQo+ICAgIGFuZCBkaXN0cmlidXRlZCwgaW4gd2hvbGUgb3IgaW4gcGFydCwgd2l0aG91 dCByZXN0cmljdGlvbiBvZiBhbnkNCj4gICAga2luZCwgcHJvdmlkZWQgdGhhdCB0aGUgYWJvdmUg Y29weXJpZ2h0IG5vdGljZSBhbmQgdGhpcyBwYXJhZ3JhcGgNCj4gICAgYXJlIGluY2x1ZGVkIG9u IGFsbCBzdWNoIGNvcGllcyBhbmQgZGVyaXZhdGl2ZSB3b3Jrcy4gSG93ZXZlciwgdGhpcw0KPiAg ICBkb2N1bWVudCBpdHNlbGYgbWF5IG5vdCBiZSBtb2RpZmllZCBpbiBhbnkgd2F5LCBzdWNoIGFz IGJ5IHJlbW92aW5nDQo+ICAgIHRoZSBjb3B5cmlnaHQgbm90aWNlIG9yIHJlZmVyZW5jZXMgdG8g dGhlIEludGVybmV0IFNvY2lldHkgb3Igb3RoZXINCj4gICAgSW50ZXJuZXQgb3JnYW5pemF0aW9u cywgZXhjZXB0IGFzIG5lZWRlZCBmb3IgdGhlIHB1cnBvc2Ugb2YNCj4gICAgZGV2ZWxvcGluZyBJ bnRlcm5ldCBzdGFuZGFyZHMgaW4gd2hpY2ggY2FzZSB0aGUgcHJvY2VkdXJlcyBmb3INCj4gICAg Y29weXJpZ2h0cyBkZWZpbmVkIGluIHRoZSBJbnRlcm5ldCBTdGFuZGFyZHMgcHJvY2VzcyBtdXN0 IGJlDQo+ICAgIGZvbGxvd2VkLCBvciBhcyByZXF1aXJlZCB0byB0cmFuc2xhdGUgaXQgaW50byBs YW5ndWFnZXMgb3RoZXIgdGhhbg0KPiAgICBFbmdsaXNoLg0KPiANCj4gDQo+ICAgIFRoZSBsaW1p dGVkIHBlcm1pc3Npb25zIGdyYW50ZWQgYWJvdmUgYXJlIHBlcnBldHVhbCBhbmQgd2lsbCBub3Qg YmUNCj4gICAgcmV2b2tlZCBieSB0aGUgSW50ZXJuZXQgU29jaWV0eSBvciBpdHMgc3VjY2Vzc29y cyBvciBhc3NpZ25zLg0KPiANCj4gDQo+ICAgIFRoaXMgZG9jdW1lbnQgYW5kIHRoZSBpbmZvcm1h dGlvbiBjb250YWluZWQgaGVyZWluIGlzIHByb3ZpZGVkIG9uIGFuDQo+ICAgICJBUyBJUyIgYmFz aXMgYW5kIFRIRSBJTlRFUk5FVCBTT0NJRVRZIEFORCBUSEUgSU5URVJORVQgRU5HSU5FRVJJTkcN Cj4gICAgVEFTSyBGT1JDRSBESVNDTEFJTVMgQUxMIFdBUlJBTlRJRVMsIEVYUFJFU1MgT1IgSU1Q TElFRCwgSU5DTFVESU5HDQo+ICAgIEJVVCBOT1QgTElNSVRFRCBUTyBBTlkgV0FSUkFOVFkgVEhB VCBUSEUgVVNFIE9GIFRIRSBJTkZPUk1BVElPTg0KPiAgICBIRVJFSU4gV0lMTCBOT1QgSU5GUklO R0UgQU5ZIFJJR0hUUyBPUiBBTlkgSU1QTElFRCBXQVJSQU5USUVTIE9GDQo+ICAgIE1FUkNIQU5U QUJJTElUWSBPUiBGSVRORVNTIEZPUiBBIFBBUlRJQ1VMQVIgUFVSUE9TRS4NCj4gDQo+IA0KPiAN Cj4gDQo+IA0KPiANCj4gDQo+IA0KPiANCj4gDQo+IA0KPiANCj4gDQo+IA0KPiANCj4gDQo+IA0K PiANCj4gDQo+IA0KPiANCj4gDQo+IA0KPiANCj4gDQo+IA0KPiBXLkFsYW5xYXIgZXQgYWwuIC0g RXhwaXJlcyBPY3RvYmVyIDIwMDQgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDE5DQoNCi0t IA0KUGFwYWRpbWl0cmlvdSBEaW1pdHJpDQpFLW1haWwgOiBkaW1pdHJpLnBhcGFkaW1pdHJpb3VA YWxjYXRlbC5iZQ0KRS1tYWlsIDogZHBhcGFkaW1pdHJpb3VAcHNnLmNvbQ0KV2VicGFnZTogaHR0 cDovL3BzZy5jb20vfmRwYXBhZGltaXRyaW91Lw0KQWRkcmVzczogRnIuIFdlbGxlc3BsZWluIDEs IEItMjAxOCBBbnR3ZXJwZW4sIEJlbGdpdW0NClBob25lICA6ICszMiAzIDI0MC04NDkxDQoNCg== From owner-ccamp@ops.ietf.org Wed Apr 21 15:13:11 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08512 for ; Wed, 21 Apr 2004 15:13:11 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGN9k-0001Ie-0A for ccamp-archive@ietf.org; Wed, 21 Apr 2004 15:13:12 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGN8m-00018C-00 for ccamp-archive@ietf.org; Wed, 21 Apr 2004 15:12:12 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BGN7s-0000xy-00 for ccamp-archive@ietf.org; Wed, 21 Apr 2004 15:11:16 -0400 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BGMqn-000Eh1-FW for ccamp-data@psg.com; Wed, 21 Apr 2004 18:53:37 +0000 Received: from [207.17.137.64] (helo=colo-dns-ext2.juniper.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BGMqm-000EgY-Ex for ccamp@ops.ietf.org; Wed, 21 Apr 2004 18:53:36 +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 i3LIrNBm089456; Wed, 21 Apr 2004 11:53:23 -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 i3LIrFJ62929; Wed, 21 Apr 2004 11:53:15 -0700 (PDT) (envelope-from arthi@juniper.net) Date: Wed, 21 Apr 2004 11:53:15 -0700 (PDT) From: Arthi Ayyangar To: Vishal Sharma cc: CCAMP , Fabio Ricciato , Ugo Monaco , "Alessio D'Achille" , Marco Listanti Subject: Re: draft-dachille: Comments on CAC issues In-Reply-To: Message-ID: <20040421114746.N96957@zircon.juniper.net> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Hi Vishal, Your summary regarding the CAC issues that I had raised basically looks fine. I think for ii) I meant any kind of setup failure, I suspected CAC failure to be more common due to i). I will also check my notes to see if there were any other issues and get back to you. thanks, -arthi > Thanks for your feedback on our draft/scheme during the > Seoul IETF. > > As mentioned in the email to the ML and to JL, > before addressing people's comments, we are summarizing them > ensure that (a) we rightly understood the comments, and (b) to > help people on the ML follow and contribute to the subsequent > discussions. > > Upon looking at my notes from our discussions, I see that > your main comments related to aspects of CAC in our scheme, > and have summarized them below. > > Please let me know if you had any additional comments > as well. We will take these into account in providing our > responses, and, later, in updating the document. > > Best regards, > -Vishal > > **************************************************************** > > i) What happens to bandwidth accounting during path set up? > Since the border router that is the entry point for the primary path > into an area/AS is the one that also computes the secondary path, how does > bandwidth accounting work to minimize CAC failures during the actual setting > up of the secondary? > (Note that other nodes in the area would not immediately learn of the amount > of bandwidth that primary and secondary paths have consumed.) > > ii) What happens if the diverse path setup fails due to a > CAC failure? (Namely, the set up of the second path fails.) > To what does the scheme default then? > > iii) If I recall correctly, you also had a comment on the > security of such schemes. That is, the problem of hiding info. > about one area from other (remote) areas. > > From owner-ccamp@ops.ietf.org Thu Apr 22 03:24:51 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08498 for ; Thu, 22 Apr 2004 03:24:51 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGYZn-0003iY-4B for ccamp-archive@ietf.org; Thu, 22 Apr 2004 03:24:51 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGYYk-0003QY-00 for ccamp-archive@ietf.org; Thu, 22 Apr 2004 03:23:47 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BGYXk-0003Bl-00 for ccamp-archive@ietf.org; Thu, 22 Apr 2004 03:22:44 -0400 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BGYFy-000NRX-PT for ccamp-data@psg.com; Thu, 22 Apr 2004 07:04:22 +0000 Received: from [195.8.69.15] (helo=oceanus.uk.clara.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BGYFw-000NRI-12 for ccamp@ops.ietf.org; Thu, 22 Apr 2004 07:04:20 +0000 Received: from claranet by oceanus.uk.clara.net with local (Exim 4.22) id 1BGYFz-0003W6-9E; Thu, 22 Apr 2004 08:04:23 +0100 From: "Adrian Farrel" To: ccamp@ops.ietf.org Cc: adrian@olddog.co.uk Reply-To: adrian@olddog.co.uk Subject: draft-ali-ccamp-rsvp-node-id-based-hello-01.txt as WG document? Date: Thu, 22 Apr 2004 08:04:23 +0100 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Remote_Addr: 156.106.224.107 Message-Id: Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit All, The authors of http://www.ietf.org/internet-drafts/draft-ali-ccamp-rsvp-node-id-based-hello -01.txt have re-positioned the draft as a BCP as discussed on the list. They have also included changes to address comments received on the list. Can I take a poll on whether you think this work should be (and is ready to be) adopted by the WG. You may go "hmmm" for yes, or "shhhh" for no. Alternatively, send a simple email to the list saying yes or no. Thanks, Adrian From owner-ccamp@ops.ietf.org Thu Apr 22 05:13:50 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13621 for ; Thu, 22 Apr 2004 05:13:50 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGaHG-00053E-JZ for ccamp-archive@ietf.org; Thu, 22 Apr 2004 05:13:50 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGaGP-0004pi-00 for ccamp-archive@ietf.org; Thu, 22 Apr 2004 05:12:57 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BGaFp-0004bI-00 for ccamp-archive@ietf.org; Thu, 22 Apr 2004 05:12:21 -0400 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BGa0X-000HQ9-9r for ccamp-data@psg.com; Thu, 22 Apr 2004 08:56:33 +0000 Received: from [195.8.69.15] (helo=oceanus.uk.clara.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BGa0W-000HPg-6A for ccamp@ops.ietf.org; Thu, 22 Apr 2004 08:56:32 +0000 Received: from claranet by oceanus.uk.clara.net with local (Exim 4.22) id 1BGa0Z-000Cmo-Rs; Thu, 22 Apr 2004 09:56:35 +0100 From: "Adrian Farrel" To: ccamp@ops.ietf.org Cc: adrian@olddog.co.uk, lberger@movaz.com Reply-To: adrian@olddog.co.uk Subject: Status of draft-ietf-ccamp-alarm-spec-00 Date: Thu, 22 Apr 2004 09:56:35 +0100 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Remote_Addr: 156.106.224.107 Message-Id: Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit All, Despite its low revision number, this work is actually quite mature and has seen some early implementation. I would like to get a sense from the working group for whether they think this draft has been sufficiently developed to be moved to last call. Hints - I think it is ready for working group last call (but I'm an author) - If you don't think it is ready, you MUST say what your issues with the draft are. "Not discussed enough" is not a real reason. Thanks, Adrian From owner-ccamp@ops.ietf.org Thu Apr 22 08:07:52 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20703 for ; Thu, 22 Apr 2004 08:07:52 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGczf-0007jg-PZ for ccamp-archive@ietf.org; Thu, 22 Apr 2004 08:07:51 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGcym-0007Vv-00 for ccamp-archive@ietf.org; Thu, 22 Apr 2004 08:06:56 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BGcyA-0007Hy-00 for ccamp-archive@ietf.org; Thu, 22 Apr 2004 08:06:18 -0400 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BGce6-000Ndn-0t for ccamp-data@psg.com; Thu, 22 Apr 2004 11:45:34 +0000 Received: from [192.128.166.71] (helo=almso2.proxy.att.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BGce4-000NdV-L9 for ccamp@ops.ietf.org; Thu, 22 Apr 2004 11:45:32 +0000 Received: from attrh5i.attrh.att.com ([135.38.62.12]) by almso2.proxy.att.com (AT&T IPNS/MSO-5.0) with ESMTP id i3MBj4os003348 for ; Thu, 22 Apr 2004 07:45:31 -0400 Received: from kcclust06evs1.ugd.att.com (135.38.164.88) by attrh5i.attrh.att.com (6.5.032) id 4082A75C000EFDDE; Thu, 22 Apr 2004 07:44:52 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6489.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: Status of draft-ietf-ccamp-alarm-spec-00 Date: Thu, 22 Apr 2004 06:45:31 -0500 Message-ID: <9473683187ADC049A855ED2DA739ABCA02BA3B1D@KCCLUST06EVS1.ugd.att.com> Thread-Topic: Status of draft-ietf-ccamp-alarm-spec-00 Thread-Index: AcQoR/exL3Gj1LS1Ro6CJt2qDLbSRgAFzEYQ From: "Ash, Gerald R (Jerry), ALABS" To: , Cc: "Ash, Gerald R (Jerry), ALABS" , Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable > I would like to get a sense from the working group for > whether they think this draft has been sufficiently > developed to be moved to last call. I think it's ready for last call. Jerry From owner-ccamp@ops.ietf.org Thu Apr 22 10:52:57 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01954 for ; Thu, 22 Apr 2004 10:52:57 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGfZR-0004W9-BW for ccamp-archive@ietf.org; Thu, 22 Apr 2004 10:52:57 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGfYV-0004FC-00 for ccamp-archive@ietf.org; Thu, 22 Apr 2004 10:51:59 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BGfXZ-00040b-00 for ccamp-archive@ietf.org; Thu, 22 Apr 2004 10:51:02 -0400 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BGfMm-000366-20 for ccamp-data@psg.com; Thu, 22 Apr 2004 14:39:52 +0000 Received: from [171.71.176.71] (helo=sj-iport-2.cisco.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BGfMl-00035m-0c for ccamp@ops.ietf.org; Thu, 22 Apr 2004 14:39:51 +0000 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 22 Apr 2004 06:50:34 +0000 Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i3MEdmW9001641; Thu, 22 Apr 2004 07:39:49 -0700 (PDT) Received: from jvasseur-w2k01.cisco.com (rtp-dial-1-27.cisco.com [10.83.97.27]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id HAA06706; Thu, 22 Apr 2004 07:39:44 -0700 (PDT) Message-Id: <4.3.2.7.2.20040422103827.047c7528@wells.cisco.com> X-Sender: jvasseur@wells.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 22 Apr 2004 10:39:24 -0400 To: adrian@olddog.co.uk From: Jean Philippe Vasseur Subject: Re: draft-ali-ccamp-rsvp-node-id-based-hello-01.txt as WG document? Cc: ccamp@ops.ietf.org, adrian@olddog.co.uk In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Hi Adrian, Yes I think that this ID is a useful BCP and should be adopted as a WG doc. JP. At 08:04 AM 4/22/2004 +0100, Adrian Farrel wrote: >All, >The authors of >http://www.ietf.org/internet-drafts/draft-ali-ccamp-rsvp-node-id-based-hello >-01.txt have re-positioned the draft as a BCP as discussed on the list. >They have also included changes to address comments received on the list. >Can I take a poll on whether you think this work should be (and is ready >to be) adopted by the WG. >You may go "hmmm" for yes, or "shhhh" for no. >Alternatively, send a simple email to the list saying yes or no. >Thanks, >Adrian > From owner-ccamp@ops.ietf.org Thu Apr 22 10:54:17 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02120 for ; Thu, 22 Apr 2004 10:54:17 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGfaj-0004qq-GX for ccamp-archive@ietf.org; Thu, 22 Apr 2004 10:54:17 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGfa4-0004aQ-00 for ccamp-archive@ietf.org; Thu, 22 Apr 2004 10:53:37 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BGfZ7-0004IC-00 for ccamp-archive@ietf.org; Thu, 22 Apr 2004 10:52:37 -0400 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BGfI8-00028u-1e for ccamp-data@psg.com; Thu, 22 Apr 2004 14:35:04 +0000 Received: from [62.23.212.165] (helo=smail.alcatel.fr) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BGfI5-00027h-G3 for ccamp@ops.ietf.org; Thu, 22 Apr 2004 14:35:01 +0000 Received: from bemail05.netfr.alcatel.fr (bemail05.netfr.alcatel.fr [155.132.251.11]) by smail.alcatel.fr (ALCANET/NETFR) with ESMTP id i3MCfvQP010289; Thu, 22 Apr 2004 14:41:57 +0200 Received: from alcatel.be ([138.203.67.90]) by bemail05.netfr.alcatel.fr (Lotus Domino Release 5.0.11) with ESMTP id 2004042214415650:3277 ; Thu, 22 Apr 2004 14:41:56 +0200 Message-ID: <4087BE2C.1090605@alcatel.be> Date: Thu, 22 Apr 2004 14:44:28 +0200 From: Dimitri.Papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.5) Gecko/20030925 X-Accept-Language: en-us, en MIME-Version: 1.0 To: adrian@olddog.co.uk Cc: ccamp@ops.ietf.org, lberger@movaz.com Subject: Re: Status of draft-ietf-ccamp-alarm-spec-00 References: In-Reply-To: X-MIMETrack: Itemize by SMTP Server on BEMAIL05/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 04/22/2004 14:41:56, Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 04/22/2004 14:41:57, Serialize complete at 04/22/2004 14:41:57 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed X-Alcanet-MTA-scanned-and-authorized: yes Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit > Despite its low revision number, this work is actually quite mature and has > seen some early implementation. > I would like to get a sense from the working group for whether they think > this draft has been sufficiently developed to be moved to last call. > Hints > - I think it is ready for working group last call (but I'm an author) i think it is ready for working group last call (but i'm an author) From owner-ccamp@ops.ietf.org Thu Apr 22 11:06:03 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03583 for ; Thu, 22 Apr 2004 11:06:03 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGfm7-0000Jn-5j for ccamp-archive@ietf.org; Thu, 22 Apr 2004 11:06:03 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGfl1-00000D-00 for ccamp-archive@ietf.org; Thu, 22 Apr 2004 11:04:55 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BGfk2-0007Vb-00 for ccamp-archive@ietf.org; Thu, 22 Apr 2004 11:03:54 -0400 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BGfXL-00054j-IW for ccamp-data@psg.com; Thu, 22 Apr 2004 14:50:47 +0000 Received: from [171.68.10.86] (helo=sj-iport-4.cisco.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BGfXK-00054P-Kr for ccamp@ops.ietf.org; Thu, 22 Apr 2004 14:50:46 +0000 Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i3MEoeW9019709; Thu, 22 Apr 2004 07:50:43 -0700 (PDT) Received: from jvasseur-w2k01.cisco.com (rtp-dial-1-27.cisco.com [10.83.97.27]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id HAA21840; Thu, 22 Apr 2004 07:50:38 -0700 (PDT) Message-Id: <4.3.2.7.2.20040422104952.0691a690@wells.cisco.com> X-Sender: jvasseur@wells.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 22 Apr 2004 10:50:18 -0400 To: adrian@olddog.co.uk From: Jean Philippe Vasseur Subject: Re: Status of draft-ietf-ccamp-alarm-spec-00 Cc: ccamp@ops.ietf.org, adrian@olddog.co.uk, lberger@movaz.com In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Hi, I also think that the draft is ready for last call (and I'm not an author ;-)) JP. At 09:56 AM 4/22/2004 +0100, Adrian Farrel wrote: >All, >Despite its low revision number, this work is actually quite mature and has >seen some early implementation. >I would like to get a sense from the working group for whether they think >this draft has been sufficiently developed to be moved to last call. >Hints >- I think it is ready for working group last call (but I'm an author) >- If you don't think it is ready, you MUST say what your issues with the >draft are. "Not discussed enough" is not a real reason. >Thanks, >Adrian > From owner-ccamp@ops.ietf.org Thu Apr 22 11:45:04 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06509 for ; Thu, 22 Apr 2004 11:45:04 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGgNs-0003m7-Li for ccamp-archive@ietf.org; Thu, 22 Apr 2004 11:45:04 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGgN3-0003Wx-00 for ccamp-archive@ietf.org; Thu, 22 Apr 2004 11:44:13 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BGgMc-0003Gx-00 for ccamp-archive@ietf.org; Thu, 22 Apr 2004 11:43:46 -0400 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BGgBn-000D6w-Iq for ccamp-data@psg.com; Thu, 22 Apr 2004 15:32:35 +0000 Received: from [171.71.176.72] (helo=sj-iport-3.cisco.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BGgBj-000D2p-Cu for ccamp@ops.ietf.org; Thu, 22 Apr 2004 15:32:31 +0000 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 22 Apr 2004 07:44:27 +0000 Received: from mira-kan-a.cisco.com (IDENT:mirapoint@mira-kan-a.cisco.com [161.44.201.17]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i3MFWQSu028144; Thu, 22 Apr 2004 08:32:28 -0700 (PDT) Received: from dprairiew2k02 (dhcp-kta1-161-44-193-130.cisco.com [161.44.193.130]) by mira-kan-a.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ABW43887; Thu, 22 Apr 2004 08:32:24 -0700 (PDT) Reply-To: From: "Danny Prairie" To: Cc: Subject: RE: draft-ali-ccamp-rsvp-node-id-based-hello-01.txt as WG document? Date: Thu, 22 Apr 2004 11:32:37 -0400 Organization: Cisco Systems Message-ID: <00fa01c4287f$0a4ea3a0$82c12ca1@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.5709 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Yes. >All,=20 > >The authors of=20 >http://www.ietf.org/internet-drafts/draft-ali-ccamp-rsvp->n ode-id-based->hello=20 >-01.txt have re-positioned the draft as a BCP as discussed on the list. >They=20 >have also included changes to address comments received on the list.=20 > >Can I take a poll on whether you think this work should be (and is ready >to=20 >be) adopted by the WG.=20 > >You may go "hmmm" for yes, or "shhhh" for no. >Alternatively, send a simple email to the list saying yes or no.=20 > >Thanks, >Adrian -- Danny Prairie dprairie@cisco.com From owner-ccamp@ops.ietf.org Thu Apr 22 11:52:00 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06809 for ; Thu, 22 Apr 2004 11:52:00 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGgUa-0005d1-Pf for ccamp-archive@ietf.org; Thu, 22 Apr 2004 11:52:00 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGgTg-0005L9-00 for ccamp-archive@ietf.org; Thu, 22 Apr 2004 11:51:05 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BGgSp-00055n-00 for ccamp-archive@ietf.org; Thu, 22 Apr 2004 11:50:11 -0400 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BGgGI-000Dzi-FU for ccamp-data@psg.com; Thu, 22 Apr 2004 15:37:14 +0000 Received: from [63.102.55.206] (helo=lightwave.chromisys.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BGgGD-000Dz7-2q for ccamp@ops.ietf.org; Thu, 22 Apr 2004 15:37:09 +0000 Received: by lightwave.chromisys.com with Internet Mail Service (5.5.2653.19) id ; Thu, 22 Apr 2004 08:37:07 -0700 Message-ID: <9D42C6E086250248810DCADA39CE7EFC017AD75E@nimbus.chromisys.com> From: John Drake To: adrian@olddog.co.uk, ccamp@ops.ietf.org Subject: RE: draft-ali-ccamp-rsvp-node-id-based-hello-01.txt as WG documen t? Date: Thu, 22 Apr 2004 08:37:07 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 yes > -----Original Message----- > From: Adrian Farrel [mailto:olddog@clara.co.uk] > Sent: Thursday, April 22, 2004 12:04 AM > To: ccamp@ops.ietf.org > Cc: adrian@olddog.co.uk > Subject: draft-ali-ccamp-rsvp-node-id-based-hello-01.txt as WG document? > > All, > > The authors of > http://www.ietf.org/internet-drafts/draft-ali-ccamp-rsvp-node-id-based- > hello > -01.txt have re-positioned the draft as a BCP as discussed on the list. > They > have also included changes to address comments received on the list. > > Can I take a poll on whether you think this work should be (and is ready > to > be) adopted by the WG. > > You may go "hmmm" for yes, or "shhhh" for no. > Alternatively, send a simple email to the list saying yes or no. > > Thanks, > Adrian From owner-ccamp@ops.ietf.org Thu Apr 22 12:07:58 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07761 for ; Thu, 22 Apr 2004 12:07:58 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGgk2-0002Gu-5z for ccamp-archive@ietf.org; Thu, 22 Apr 2004 12:07:58 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGgj3-0001y0-00 for ccamp-archive@ietf.org; Thu, 22 Apr 2004 12:06:58 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BGghz-0001To-00 for ccamp-archive@ietf.org; Thu, 22 Apr 2004 12:05:51 -0400 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BGgUE-000Gyk-Jk for ccamp-data@psg.com; Thu, 22 Apr 2004 15:51:38 +0000 Received: from [62.23.212.56] (helo=smail3.alcatel.fr) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BGgTt-000Gt6-9m for ccamp@ops.ietf.org; Thu, 22 Apr 2004 15:51:17 +0000 Received: from frmail30.netfr.alcatel.fr (frmail30.netfr.alcatel.fr [155.132.182.163]) by smail3.alcatel.fr (ALCANET/NETFR) with ESMTP id i3MFpDrK009075; Thu, 22 Apr 2004 17:51:14 +0200 Received: from alcatel.fr ([172.25.74.92]) by frmail30.netfr.alcatel.fr (Lotus Domino Release 5.0.9a) with ESMTP id 2004042217511219:4638 ; Thu, 22 Apr 2004 17:51:12 +0200 Message-ID: <4087E9F0.CCA42BB2@alcatel.fr> Date: Thu, 22 Apr 2004 17:51:12 +0200 From: Martin.Vigoureux@alcatel.fr Reply-To: martin.vigoureux@alcatel.fr Organization: ALCATEL - R&I X-Mailer: Mozilla 4.78 [fr] (Windows NT 5.0; U) X-Accept-Language: fr,en-GB MIME-Version: 1.0 To: adrian@olddog.co.uk CC: ccamp@ops.ietf.org Subject: Re: draft-ali-ccamp-rsvp-node-id-based-hello-01.txt as WG document? References: X-MIMETrack: Itemize by SMTP Server on FRMAIL30/FR/ALCATEL(Release 5.0.9a |January 7, 2002) at 04/22/2004 17:51:12, Serialize by Router on FRMAIL30/FR/ALCATEL(Release 5.0.9a |January 7, 2002) at 04/22/2004 17:51:13 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Alcanet-MTA-scanned-and-authorized: yes Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable yes Adrian Farrel a =E9crit : >=20 > All, >=20 > The authors of > http://www.ietf.org/internet-drafts/draft-ali-ccamp-rsvp-node-id-based-he= llo > -01.txt have re-positioned the draft as a BCP as discussed on the list. = They > have also included changes to address comments received on the list. >=20 > Can I take a poll on whether you think this work should be (and is ready = to > be) adopted by the WG. >=20 > You may go "hmmm" for yes, or "shhhh" for no. > Alternatively, send a simple email to the list saying yes or no. >=20 > Thanks, > Adrian From owner-ccamp@ops.ietf.org Thu Apr 22 12:08:01 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07786 for ; Thu, 22 Apr 2004 12:08:01 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGgk5-0002HC-I4 for ccamp-archive@ietf.org; Thu, 22 Apr 2004 12:08:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGgjK-0001zv-00 for ccamp-archive@ietf.org; Thu, 22 Apr 2004 12:07:15 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BGgii-0001jx-00 for ccamp-archive@ietf.org; Thu, 22 Apr 2004 12:06:36 -0400 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BGgY7-000HuT-L3 for ccamp-data@psg.com; Thu, 22 Apr 2004 15:55:39 +0000 Received: from [171.71.176.71] (helo=sj-iport-2.cisco.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BGgY3-000Htl-6w for ccamp@ops.ietf.org; Thu, 22 Apr 2004 15:55:35 +0000 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 22 Apr 2004 08:06:18 +0000 Received: from mira-kan-a.cisco.com (IDENT:mirapoint@mira-kan-a.cisco.com [161.44.201.17]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i3MFtWW9022182; Thu, 22 Apr 2004 08:55:33 -0700 (PDT) Received: from msiva-w2k01.cisco.com (dhcp-10-85-28-27.cisco.com [10.85.28.27]) by mira-kan-a.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ABW44689; Thu, 22 Apr 2004 08:55:31 -0700 (PDT) Message-Id: <4.3.2.7.2.20040422115524.02c56b88@toque.cisco.com> X-Sender: msiva@toque.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 22 Apr 2004 11:55:43 -0400 To: From: "Siva Sivabalan (msiva)" Subject: RE: draft-ali-ccamp-rsvp-node-id-based-hello-01.txt as WG document? Cc: , In-Reply-To: <00fa01c4287f$0a4ea3a0$82c12ca1@amer.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Yes. At 11:32 AM 4/22/2004 -0400, Danny Prairie wrote: >Yes. > > >All, > > > >The authors of > >http://www.ietf.org/internet-drafts/draft-ali-ccamp-rsvp->n >ode-id-based->hello > >-01.txt have re-positioned the draft as a BCP as discussed >on the list. >They > >have also included changes to address comments received on >the list. > > > >Can I take a poll on whether you think this work should be >(and is ready >to > >be) adopted by the WG. > > > >You may go "hmmm" for yes, or "shhhh" for no. > >Alternatively, send a simple email to the list saying yes >or no. > > > >Thanks, > >Adrian > >-- >Danny Prairie >dprairie@cisco.com From owner-ccamp@ops.ietf.org Thu Apr 22 12:40:18 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09408 for ; Thu, 22 Apr 2004 12:40:17 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGhFK-0003Nq-7q for ccamp-archive@ietf.org; Thu, 22 Apr 2004 12:40:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGhEP-00036f-00 for ccamp-archive@ietf.org; Thu, 22 Apr 2004 12:39:22 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BGhDu-0002p7-00 for ccamp-archive@ietf.org; Thu, 22 Apr 2004 12:38:50 -0400 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BGgzO-000N9C-32 for ccamp-data@psg.com; Thu, 22 Apr 2004 16:23:50 +0000 Received: from [171.71.176.72] (helo=sj-iport-3.cisco.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BGgzK-000N5l-JQ for ccamp@ops.ietf.org; Thu, 22 Apr 2004 16:23:46 +0000 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 22 Apr 2004 08:35:42 +0000 Received: from mira-kan-a.cisco.com (IDENT:mirapoint@mira-kan-a.cisco.com [161.44.201.17]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i3MGNiW9022986; Thu, 22 Apr 2004 09:23:44 -0700 (PDT) Received: from ancaz-w2k01.cisco.com (dhcp-kta1-161-44-193-236.cisco.com [161.44.193.236]) by mira-kan-a.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ABW45570; Thu, 22 Apr 2004 09:23:43 -0700 (PDT) Message-Id: <4.3.2.7.2.20040422122345.01d33e90@toque.cisco.com> X-Sender: ancaz@toque.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 22 Apr 2004 12:23:55 -0400 To: adrian@olddog.co.uk From: Anca Zamfir Subject: Re: draft-ali-ccamp-rsvp-node-id-based-hello-01.txt as WG document? Cc: ccamp@ops.ietf.org, adrian@olddog.co.uk In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Yes. At 08:04 AM 4/22/2004 +0100, Adrian Farrel wrote: >All, >The authors of >http://www.ietf.org/internet-drafts/draft-ali-ccamp-rsvp-node-id-based-hello >-01.txt have re-positioned the draft as a BCP as discussed on the list. >They have also included changes to address comments received on the list. >Can I take a poll on whether you think this work should be (and is ready >to be) adopted by the WG. >You may go "hmmm" for yes, or "shhhh" for no. >Alternatively, send a simple email to the list saying yes or no. >Thanks, >Adrian From owner-ccamp@ops.ietf.org Thu Apr 22 13:13:00 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11156 for ; Thu, 22 Apr 2004 13:13:00 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGhkz-0004a8-1Z for ccamp-archive@ietf.org; Thu, 22 Apr 2004 13:13:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGhk0-0004L2-00 for ccamp-archive@ietf.org; Thu, 22 Apr 2004 13:12:00 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BGhiz-0003yS-00 for ccamp-archive@ietf.org; Thu, 22 Apr 2004 13:10:57 -0400 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BGhOU-0001is-2W for ccamp-data@psg.com; Thu, 22 Apr 2004 16:49:46 +0000 Received: from [66.163.170.81] (helo=smtp811.mail.sc5.yahoo.com) by psg.com with smtp (Exim 4.30; FreeBSD) id 1BGhOS-0001iX-QL for ccamp@ops.ietf.org; Thu, 22 Apr 2004 16:49:44 +0000 Received: from unknown (HELO RAKHILAPTOP) (vishal.sharma@sbcglobal.net@67.117.150.3 with login) by smtp811.mail.sc5.yahoo.com with SMTP; 22 Apr 2004 16:47:34 -0000 Reply-To: From: "Vishal Sharma" To: , Subject: RE: draft-ali-ccamp-rsvp-node-id-based-hello-01.txt as WG document? Date: Thu, 22 Apr 2004 09:47:30 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Yes. -Vishal > -----Original Message----- > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On > Behalf Of Adrian Farrel > Sent: Thursday, April 22, 2004 12:04 AM > To: ccamp@ops.ietf.org > Cc: adrian@olddog.co.uk > Subject: draft-ali-ccamp-rsvp-node-id-based-hello-01.txt as WG document? > > > All, > > The authors of > http://www.ietf.org/internet-drafts/draft-ali-ccamp-rsvp-node-id-b > ased-hello > -01.txt have re-positioned the draft as a BCP as discussed on > the list. They > have also included changes to address comments received on the list. > > Can I take a poll on whether you think this work should be (and > is ready to > be) adopted by the WG. > > You may go "hmmm" for yes, or "shhhh" for no. > Alternatively, send a simple email to the list saying yes or no. > > Thanks, > Adrian > From owner-ccamp@ops.ietf.org Thu Apr 22 13:16:08 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11265 for ; Thu, 22 Apr 2004 13:16:07 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGho0-0005Nh-4o for ccamp-archive@ietf.org; Thu, 22 Apr 2004 13:16:08 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGhn4-00056d-00 for ccamp-archive@ietf.org; Thu, 22 Apr 2004 13:15:10 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BGhmP-0004r0-00 for ccamp-archive@ietf.org; Thu, 22 Apr 2004 13:14:29 -0400 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BGhao-0004TA-Qv for ccamp-data@psg.com; Thu, 22 Apr 2004 17:02:30 +0000 Received: from [171.68.10.86] (helo=sj-iport-4.cisco.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BGhan-0004SQ-4N for ccamp@ops.ietf.org; Thu, 22 Apr 2004 17:02:29 +0000 Received: from mira-kan-a.cisco.com (IDENT:mirapoint@mira-kan-a.cisco.com [161.44.201.17]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id i3MH2P0Q001744; Thu, 22 Apr 2004 10:02:25 -0700 (PDT) Received: from ancaz-w2k01.cisco.com (dhcp-kta1-161-44-193-236.cisco.com [161.44.193.236]) by mira-kan-a.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ABW46599; Thu, 22 Apr 2004 10:02:24 -0700 (PDT) Message-Id: <4.3.2.7.2.20040422122454.01d83df0@toque.cisco.com> X-Sender: ancaz@toque.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 22 Apr 2004 13:02:37 -0400 To: adrian@olddog.co.uk From: Anca Zamfir Subject: Re: Status of draft-ietf-ccamp-alarm-spec-00 Cc: ccamp@ops.ietf.org, adrian@olddog.co.uk, lberger@movaz.com In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Ready for WG last call. At 09:56 AM 4/22/2004 +0100, Adrian Farrel wrote: >All, >Despite its low revision number, this work is actually quite mature and has >seen some early implementation. >I would like to get a sense from the working group for whether they think >this draft has been sufficiently developed to be moved to last call. >Hints >- I think it is ready for working group last call (but I'm an author) >- If you don't think it is ready, you MUST say what your issues with the >draft are. "Not discussed enough" is not a real reason. >Thanks, >Adrian From owner-ccamp@ops.ietf.org Thu Apr 22 13:45:23 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13507 for ; Thu, 22 Apr 2004 13:45:23 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGiGI-0006Wj-By for ccamp-archive@ietf.org; Thu, 22 Apr 2004 13:45:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGiFU-0006EZ-00 for ccamp-archive@ietf.org; Thu, 22 Apr 2004 13:44:33 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BGiEc-0005vY-00 for ccamp-archive@ietf.org; Thu, 22 Apr 2004 13:43:38 -0400 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BGi2T-0009IN-Cf for ccamp-data@psg.com; Thu, 22 Apr 2004 17:31:05 +0000 Received: from [63.102.55.206] (helo=lightwave.chromisys.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BGi2S-0009I5-LD for ccamp@ops.ietf.org; Thu, 22 Apr 2004 17:31:04 +0000 Received: by lightwave.chromisys.com with Internet Mail Service (5.5.2653.19) id ; Thu, 22 Apr 2004 10:31:00 -0700 Message-ID: <9D42C6E086250248810DCADA39CE7EFC011446F1@nimbus.chromisys.com> From: Ayan Banerjee To: ccamp@ops.ietf.org Subject: RE: draft-ali-ccamp-rsvp-node-id-based-hello-01.txt as WG documen t? Date: Thu, 22 Apr 2004 10:31:00 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Yes. -Ayan > -----Original Message----- > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On > Behalf Of Adrian Farrel > Sent: Thursday, April 22, 2004 12:04 AM > To: ccamp@ops.ietf.org > Cc: adrian@olddog.co.uk > Subject: draft-ali-ccamp-rsvp-node-id-based-hello-01.txt as WG document? > > > All, > > The authors of > http://www.ietf.org/internet-drafts/draft-ali-ccamp-rsvp-node-id-b > ased-hello > -01.txt have re-positioned the draft as a BCP as discussed on > the list. They > have also included changes to address comments received on the list. > > Can I take a poll on whether you think this work should be (and > is ready to > be) adopted by the WG. > > You may go "hmmm" for yes, or "shhhh" for no. > Alternatively, send a simple email to the list saying yes or no. > > Thanks, > Adrian > From owner-ccamp@ops.ietf.org Thu Apr 22 14:49:14 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17289 for ; Thu, 22 Apr 2004 14:49:14 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGjG5-00016A-EV for ccamp-archive@ietf.org; Thu, 22 Apr 2004 14:49:13 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGjFE-0000q2-00 for ccamp-archive@ietf.org; Thu, 22 Apr 2004 14:48:21 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BGjEQ-0000Zo-00 for ccamp-archive@ietf.org; Thu, 22 Apr 2004 14:47:30 -0400 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BGj1Y-000NmT-SD for ccamp-data@psg.com; Thu, 22 Apr 2004 18:34:12 +0000 Received: from [195.8.69.15] (helo=oceanus.uk.clara.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BGj1X-000Nlt-AJ for ccamp@ops.ietf.org; Thu, 22 Apr 2004 18:34:11 +0000 Received: from claranet by oceanus.uk.clara.net with local (Exim 4.22) id 1BGj1a-0009Wp-Rn; Thu, 22 Apr 2004 19:34:14 +0100 From: "Adrian Farrel" To: ccamp@ops.ietf.org, OSPF@PEACH.EASE.LSOFT.COM Cc: adrian@olddog.co.uk Reply-To: adrian@olddog.co.uk Subject: Re: Interface Switching Capability Descriptor sub-tlv length Date: Thu, 22 Apr 2004 19:34:14 +0100 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Remote_Addr: 156.106.205.137 Message-Id: Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit This didn't seem to make it through to the CCAMp list. Acee wrote... > I'm copying the ccamp list since this is a CCAMP WG document. My > opinion is that the padding should not be included in the sub-TLV > length since this is stated explicitly in RFC 3630. I think you are wrong as follows Acee... I agree that the text could be a little confusing. RFC3630 implies that the actual space in the message is a multiple of 32bits regardless of the value of the length field, and that the length field represents the length of the value field(s). draft-ietf-ccamp-ospf-gmpls-extensions-12 does not contradict this. That is, the field labeled "Padding" is actually a value field of the TLV. (It might have been better labeled as "Reserved"). As the text says... The padding is 3 octets, and is used to make the Interface Switching Capability Descriptor sub-TLV 32-bits aligned. It SHOULD be set to zero by the sender and SHOULD be ignored by the receiver. That is, it makes the sub-TLV length up to a 32-bit multiple. Hope this clarifies. Adrian ----- Original Message ----- From: "Oliver Carter" To: Sent: Wednesday, April 21, 2004 2:35 PM Subject: Interface Switching Capability Descriptor sub-tlv length > Hi all, > > We have seen a minor interop problem with the Interface Switching > Capability Descriptor sub-tlv length value (defined in the > draft-ietf-ccamp-ospf-gmpls-extensions draft). In short, we are setting > the length so as to not include the pad bytes in the structure, and > another vendor is expecting the pad bytes to be included. As explained > below, the specifications are slightly ambiguous - can it be clarified > what should be filled out in the length value please? > > RFC 3630 Section 2.3.2 states that "The TLV is padded to four-octet > alignment; padding is not included in the length field (so a three octet > value would have a length of three, but the total size of the TLV would be > eight octets)." this would support the argument that the length should be > unpadded. > > However, draft-ietf-ccamp-ospf-gmpls-extensions-12, section 1.4 describes > the Interface Switching Capability Descriptor which states " The length is > the length of value field" and then shows the padding of the Switching > Capability field as part of the value field. This would support the > argument that the padding for this TLV should be included in the length > field. > > So which argument is correct, and can this be made explicit in the next > version of draft-ietf-ccamp-ospf-gmpls-extensions? > > Thanks > > Oli > > P.S. Apologies if this has already been resolved by the list - my > searching didn't turn up anything. From owner-ccamp@ops.ietf.org Fri Apr 23 02:13:03 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA15346 for ; Fri, 23 Apr 2004 02:13:03 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGtvp-0006LI-5W for ccamp-archive@ietf.org; Fri, 23 Apr 2004 02:13:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGtus-00063K-00 for ccamp-archive@ietf.org; Fri, 23 Apr 2004 02:12:03 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BGtu5-0005kj-00 for ccamp-archive@ietf.org; Fri, 23 Apr 2004 02:11:13 -0400 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BGtb8-000ENZ-Mt for ccamp-data@psg.com; Fri, 23 Apr 2004 05:51:38 +0000 Received: from [66.163.170.83] (helo=smtp813.mail.sc5.yahoo.com) by psg.com with smtp (Exim 4.30; FreeBSD) id 1BGtb7-000ENI-Pe for ccamp@ops.ietf.org; Fri, 23 Apr 2004 05:51:37 +0000 Received: from unknown (HELO RAKHILAPTOP) (vishal.sharma@sbcglobal.net@63.206.91.121 with login) by smtp813.mail.sc5.yahoo.com with SMTP; 23 Apr 2004 05:51:37 -0000 Reply-To: From: "Vishal Sharma" To: "LE ROUX Jean-Louis FTRD/DAC/LAN" , "CCAMP" Cc: "Fabio Ricciato" , "Alessio D'Achille" , "Ugo Monaco" , "Marco Listanti" Subject: RE: RE : draft-dachille: Comments on topology summarization and optimality Date: Thu, 22 Apr 2004 22:51:37 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 8bit Hi JL, Thanks much for your note, and for confirming that we had captured your comments correctly. Your point about virtual links and topology summarization is well taken. We recognize that the explanations in Section 4.1 and 4.2, w.r.t. virtual links need to be made clearer (and we need to think more about whether we require them). This is a point we have been discussing internally, and really appreciate your inputs on it. We will respond to your other comments in the next day or two, and to this issue a bit later, after we discuss it further and clarify our thinking on it. In the meantime, if there are any other inputs you have, please do let us know. Regards, -Vishal > -----Original Message----- > From: LE ROUX Jean-Louis FTRD/DAC/LAN > [mailto:jeanlouis.leroux@francetelecom.com] > Sent: Thursday, April 22, 2004 11:04 AM > To: v.sharma@ieee.org; CCAMP > Cc: Fabio Ricciato; Alessio D'Achille; Ugo Monaco; Marco Listanti > Subject: RE : draft-dachille: Comments on topology summarization and > optimality > > > Hi Vishal, > > This is a correct summary of the discussion we had during the > Seoul meeting. > > Just one clarification regarding comment iii, > > You make the following routing assumption (section 4): > "In the following we will assume that every border router, say B1, > that is directly attached to area X > maintains a summarized > topological view consisting of the exact > intra-area topology of X > plus several so called ôvirtual linksö. Virtual > link are present > between the border routers of area X, say B2 B3 > etc., and the > possible destinations: they merely represent > external paths to remote > destinations that are reachable through some > inter-area path. Virtual > link might be assigned a cost" > > The question is how do you perform such TE topology summarization ? > More particularly how do you summarize information on link > admin-groups, which basically need to be taken into acount during > path computation ? > Let's assume that there are N paths between an ABR an a > destination, each with a distinct avaialble bandwidth, and a > distinct admin group (a path admin group being expressed as a > logical AND of the afinities of each link in the path). > You then need to advertise N Virtual links, each with a distinct > admin group. > IMHO this does not scale and also compromises one of the main > motivations of IGP hierarchy, i.e. the containement of routing > information. > This is actually one of the reasons, in the inter-area > requirement draft, for precluding such leaking of summarized > TE-link information across areas. > > Actually you use this virtual topology, in 4.1 and 4.2, to select > downstream ABRs. > IMHO your JSA approach can work independantly of the method used > to select downstream ABRs. > Thus, you should IMHO let downstream ABR selection beyond the > scope of the draft, and remove all text related to virtual topologies. > > Regards, > > JL > > > -----Message d'origine----- > > De : owner-ccamp@ops.ietf.org > > [mailto:owner-ccamp@ops.ietf.org] De la part de Vishal Sharma > > Envoyé : dimanche 18 avril 2004 09:17 > > À : CCAMP > > Cc : LE ROUX Jean-Louis FTRD/DAC/LAN; Fabio Ricciato; Alessio > > D'Achille; Ugo Monaco; Marco Listanti > > Objet : draft-dachille: Comments on topology summarization > > and optimality > > > > > > Hi JL, > > > > Thanks for your feedback on our draft/scheme during the > > Seoul IETF. > > > > As mentioned in an earlier email to the ML, before we address > > the various points made by folks who gave us their valuable > > feedback, we are summarizing their comments to ensure that > > (a) we rightly understood their inputs :-), and (b) to help > > people on the ML follow and contribute to the subsequent discussions. > > > > After reviewing my notes from our discussions and discussing > > them with my co-authors, I have summarized your comments as below. > > > > If I missed something or did not capture some of your > > questions/comments correctly, please do let us know. We will > > take this into account in providing our responses, and, > > later, in updating the document. > > > > Best regards, > > -Vishal > > > > ********************************************************************* > > > > Editorial: > > i) Replace "area" --> "region" throughout, since you cover > > ASs as well. > > > > ii) Note in the draft that the scheme is general and does > > more that merely helping with efficient backup path > > computation and setup. > > > > Technical: > > iii) The draft needs to make clear what is meant by a virtual > > topology, and what info. is used to create it. This is > > because it seems from a current reading of the draft that the > > virtual topology relies on info. about TE links and their > > bandwidth, but there is a strong requirement not to advertise > > TE link info. between areas. > > > > iv) How does this approach differ from the PCS/PCE approach? > > Some comparison and contrasting would be useful. > > > > v) You also suggested that one needn't be confined to > > carrying only one ARO. So for better optimality, one might > > carry multiple ARO's computed for the secondary path, and > > when the secondary is being set up, the ingress for the > > secondary could select one of the ARO segments for traversing > > it's area. This might lead to a more optimal setup than would > > otherwise be possible. > > > > vi) Sec. 4.1 on inter-area is ok. > > > > vii) However, for the section on inter-AS, you asked "how > > does the scheme computes the set of AS's that the diverse > > paths will use?" > > > > viii) Do you need the optical island ID? > > Even in the optical case, if one is using IP protocols, it is > > likely that OSFP/IS-IS areas/levels and ASs will be defined, > > so this then becomes the same as the inter-area/inter-AS cases. > > > > ix) Mention that the scheme can work for IS-IS levels as > > well. (Note IS-IS levels can, in turn, have areas.) (One > > issue here is how does one identify IS-IS levels?) > > > > > > > > From owner-ccamp@ops.ietf.org Fri Apr 23 02:14:39 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA15776 for ; Fri, 23 Apr 2004 02:14:39 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGtxM-0006rx-Qu for ccamp-archive@ietf.org; Fri, 23 Apr 2004 02:14:36 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGtwQ-0006ak-00 for ccamp-archive@ietf.org; Fri, 23 Apr 2004 02:13:39 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BGtvV-0006Ie-00 for ccamp-archive@ietf.org; Fri, 23 Apr 2004 02:12:41 -0400 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BGtb7-000EN1-9w for ccamp-data@psg.com; Fri, 23 Apr 2004 05:51:37 +0000 Received: from [66.163.170.83] (helo=smtp813.mail.sc5.yahoo.com) by psg.com with smtp (Exim 4.30; FreeBSD) id 1BGtb6-000EMm-8N for ccamp@ops.ietf.org; Fri, 23 Apr 2004 05:51:36 +0000 Received: from unknown (HELO RAKHILAPTOP) (vishal.sharma@sbcglobal.net@63.206.91.121 with login) by smtp813.mail.sc5.yahoo.com with SMTP; 23 Apr 2004 05:51:35 -0000 Reply-To: From: "Vishal Sharma" To: "Arthi Ayyangar" Cc: "CCAMP" , "Fabio Ricciato" , "Ugo Monaco" , "Alessio D'Achille" , "Marco Listanti" Subject: RE: draft-dachille: Comments on CAC issues Date: Thu, 22 Apr 2004 22:51:35 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: <20040421114746.N96957@zircon.juniper.net> Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Hi Arthi, Thanks for your note. I've made a note of ii) referring to a general setup failure, and not just CAC failure. We'll take this into account when we post the responses in the next day or two. And, if you see any other points when reviewing your notes please do let us know. Thanks, -Vishal > -----Original Message----- > From: Arthi Ayyangar [mailto:arthi@juniper.net] > Sent: Wednesday, April 21, 2004 11:53 AM > To: Vishal Sharma > Cc: CCAMP; Fabio Ricciato; Ugo Monaco; Alessio D'Achille; Marco Listanti > Subject: Re: draft-dachille: Comments on CAC issues > > > Hi Vishal, > > Your summary regarding the CAC issues that I had raised basically looks > fine. I think for ii) I meant any kind of setup failure, I suspected CAC > failure to be more common due to i). I will also check my notes to see if > there were any other issues and get back to you. > > thanks, > -arthi > > > Thanks for your feedback on our draft/scheme during the > > Seoul IETF. > > > > As mentioned in the email to the ML and to JL, > > before addressing people's comments, we are summarizing them > > ensure that (a) we rightly understood the comments, and (b) to > > help people on the ML follow and contribute to the subsequent > > discussions. > > > > Upon looking at my notes from our discussions, I see that > > your main comments related to aspects of CAC in our scheme, > > and have summarized them below. > > > > Please let me know if you had any additional comments > > as well. We will take these into account in providing our > > responses, and, later, in updating the document. > > > > Best regards, > > -Vishal > > > > **************************************************************** > > > > i) What happens to bandwidth accounting during path set up? > > Since the border router that is the entry point for the primary path > > into an area/AS is the one that also computes the secondary > path, how does > > bandwidth accounting work to minimize CAC failures during the > actual setting > > up of the secondary? > > (Note that other nodes in the area would not immediately learn > of the amount > > of bandwidth that primary and secondary paths have consumed.) > > > > ii) What happens if the diverse path setup fails due to a > > CAC failure? (Namely, the set up of the second path fails.) > > To what does the scheme default then? > > > > iii) If I recall correctly, you also had a comment on the > > security of such schemes. That is, the problem of hiding info. > > about one area from other (remote) areas. > > > > From owner-ccamp@ops.ietf.org Fri Apr 23 02:29:38 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA16876 for ; Fri, 23 Apr 2004 02:29:37 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGuBr-0002vi-CB for ccamp-archive@ietf.org; Fri, 23 Apr 2004 02:29:35 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGuAs-0002gY-00 for ccamp-archive@ietf.org; Fri, 23 Apr 2004 02:28:36 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BGu9u-0002PR-00 for ccamp-archive@ietf.org; Fri, 23 Apr 2004 02:27:34 -0400 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BGtmu-000Hel-Os for ccamp-data@psg.com; Fri, 23 Apr 2004 06:03:48 +0000 Received: from [66.163.168.179] (helo=smtp800.mail.sc5.yahoo.com) by psg.com with smtp (Exim 4.30; FreeBSD) id 1BGtmt-000HYu-3G for ccamp@ops.ietf.org; Fri, 23 Apr 2004 06:03:47 +0000 Received: from unknown (HELO RAKHILAPTOP) (vishal.sharma@sbcglobal.net@63.206.92.226 with login) by smtp800.mail.sc5.yahoo.com with SMTP; 23 Apr 2004 06:03:46 -0000 Reply-To: From: "Vishal Sharma" To: , Cc: "Fabio Ricciato" , "Ugo Monaco" , "Alessio D'Achille" , "Marco Listanti" Subject: RE: comments on ARO Date: Thu, 22 Apr 2004 23:03:45 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: <40842395.2DD1A674@alcatel.be> Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Hi Stefaan, Thanks a lot for looking over the draft so carefully, and for your many detailed comments. While we will address the individual comments once we've digested them a bit (and in a separate email to avoid making this one too long :-)), let me try to address a couple of the most important points raised in your note below. 1) Recording only border nodes: Actually, if one only recorded border nodes, then upon signaling the secondary, the ingress border node for the secondary has no idea about the intra-area (or intra-AS) path of the primary (in its own area or AS), and therefore cannot ensure that the primary and secondary segments are in fact disjoint. This was a point I discussed with several other people (who initially proposed the same thing), including Arthi and Adrian, but we concluded, for the reason above, that merely recording the border nodes does not work for diversity. As a result, the ARO does, in fact, serve a very useful purpose. We can of course think more about what the trade-offs are, and see if there is some way to retain the main advantage of the proposal (diversity, joint optimization of both paths) while also recording less information. 2) With regard to optimizing only the path of the primary, I am not so sure about doing just that. I believe one can get into real problems if one does not constrain the path/cost of the secondary, with unduly long secondaries that will greatly limit the ability to setup further primaries (and secondaries). (This can be especially true of tranport networks, where one would set up very large bandwidth pipes, and optimizing their placement would be critical.) This scheme is optimizing jointly the cost of the primary and secondary, while ensuring diversity. I think you will find that most providers would be equally concerned with the cost/placement of the secondary path. Moreover, as I emphasized (and as discussed during CCAMP we wiil change the title and our intro. to reflect that), this is a: generic method for computing diverse paths that meets a variety of requirements: load balancing, multipe paths when a single one has insufficient capacity, multiple paths between VoIP gateways, etc. in all of which one would ideally be looking for paths with about equal length. Protection is just _one_ application of this scheme. 3) Re-optimization, crankback, and failure of secondary: I think the scheme works with all of these, and does not really conflict with any of them. With crankback, there should be no problem, whenever a crankback occurs on the primary, the secondary will also be recomputed at the ASBR/ABR to which there is crankback. With re-optimization, there are several options. -- Either default to sequential calculation, and use the XRO to re-optimize whichever of the two diverse paths requires re-optimization. (This might be an immediate response, while the below could be a more long-term response.) -- Or, if the goal really is joint optimization, the provider will have to setup a new set of diverse paths, and use make-before-break to transition the traffic over. -- If the secondary fails, again there are two options. Either use the XRO to perform another path setup (and, possibly, re-optimize the paths later), or use the joint optimization method above with make-before-break. 4) Relationship to XRO: As I mentioned in the Seoul presentation and also in our discussion, I think the XRO has many uses -- during computation after crankback, to enable adminstrative routing/re-routing, protection, etc. So I think the ARO and XRO are actually complementary. Regards, -Vishal > -----Original Message----- > From: stefaan.de_cnodder@alcatel.be > [mailto:stefaan.de_cnodder@alcatel.be] > Sent: Monday, April 19, 2004 12:08 PM > To: v.sharma@ieee.org > Cc: ccamp@ops.ietf.org > Subject: comments on ARO > > > > Hi Vishal, > > looking to draft-dachille, I have following comments: > > 1) Second paragraph in section 2 is not clear: "we will assume that > every > inter-area connection is duplicated". I understood from it that when > the > primary path follows Area1-Area2-Area3, then also the secondary has > to > follow this path but using other border nodes. But then from section > 4.2 I > understand that this is not an assumption? > > 2) step 2c on page 5: also E, G and H has to be pruned? It is also > not > clear which path is selected in area 3: I guess it is E-G-H for > primary and > F-H for secondary? > > 3) (!) page 7, about the trap-avoid reference: If fact it is just a > matter > of doing a good path calculation. If the primary is signaled and > border > nodes know that also a secondary has to be established, then it can > make > sure that the primary does not introduce such a trap. This assumes > that the > border node also has to know that a secondary has to be established. > This > is known by the presence of the ARO object but this does not mean > that at > the end, the ARO has to contain a full strict path of the secondary. > Border > nodes can expand the ARO by only including the border nodes for the > secondary. This means that the path calculation of the secondary is > not > anymore 100% bound to the primary. Also I would prefer that the ARO > is more > like a "hint" than the real path. With this, you do not have to > interaction > problems with re-optimization of secondary, crankback, ... For > instance: > when the secondary fails, it can be re-established ignoring the ARO. > Or > when the secondary can be re-optimzed between border nodes, then it > can be > done without impacting the primary or when the global > re-optimization is > possible, then the ARO can be simple ignored. > > I prefer to have the ARO only recording border nodes, and optionally > only > acting as a hint for the ingress LSR. The latter is less important > to me. > > 4) text below figure 3: primary has to be as short as possible. I do > not > care much about the secondary becuase it is almost never used. Also, > the > resources that it reserves can be shared with other secondaries. The > problem here is: what are you optimizing? According to me the path > of the > primary has to be optimized. > > 5) I do not understand why the ARO has to contain Area-Ids to > indicate the > route. If the ingress can put the "area-path" in the ARO, then it > can also > put the border nodes in the ERO of the secondary immediately. I.e. > refering > to figure 5: A knows that the path of the secondary is A1-A2-A5-A6. > How > does A know this? And if it is possible to let A know this > information, > then why could it also not know that the path is B1-B7-B9. If A can > do > this, then there is no need anymore for ARO. So the basic question > is: what > makes it easier for A to know A1-A2-A5-A6 instead of B1-B7-B9. This > means > to me that section 4.2 is not valid and that the ARO assumes that > the > "area-path" of primary and secondary is the same, which is true for > IGP > areas. See also comment 2. Maybe better to remove the AREA-IDs from > the > ARO. > > 6) step 1d page 14, second last line: how does the ABR know that B7 > has to > be used and not B8? > > 7) section 4.3: also describe the L-bit that is in the ERO > subobjects. > > 8) Is the Addr_len in for instance subobject 1 always 32 or can it > be > something else. I agree here that you should re-use ERO subobjects > but I > see that you are doing this. > > 9) Section 4.3.2.3, area_ID: types 3, 4 and 5 are defined but that > conflicts with what is described in the middle of page 19 where the > numbers > are 32, 33, 34. > > 10) the text in section 4.3.3 is rather confusing (the part in the > middle > of page 22, about pruning the nodes). Take figure 5, area 5: If B6 > has to > calculate a path from B6 to B10, then this path can pass via B5, B8, > B7 > and/or B9. This is because border nodes can also act as core nodes > at the > same time. This seems to be excluded from the draft. Is that > correct? > > 11) First refinement in section 5 about the cost of virtual links: > this has > been proposed before in > http://www.watersprings.org/pub/id/draft-venkatachalam-interarea-m >pls-te-02.txt >which is not a good idea: it only works for inter-IGP area and it >decreases >the scalability although it also has some advantages. >12) (!) There are conflicts with re-optimization, crankback, >re-establishement after failure of secondary LSP, ... because in all >of >these cases a working primary LSP also have to be re-signaled which >is not >good. Therefore it is better to let the ARO only record border >nodes, >and/or to use the ARO more as a hint for the secondary: using the >ARO in >the primary makes sure that a trap is avoided, and then it is up to >the >signaling of the secondary to find this path by using crankback, >.... There >is no need that the primary LSP also gives the path, it only has to >make >sure that there is a path. > >13) (!) The method seems not to be applicable for inter-AS >calculations. > >14) Following the classification of methods (ARO, XRO, PCE) that you >described earlier on ccamp based on parallel/sequential and >distributed/centralized computation, ARO looks more an alternative >for PCE than for XRO? In fact, would it be possible to combine >methods? It would be good to explain the interaction (if any) with >these other methods. > >Hope this helps, > >regards, > >Stefaan From owner-ccamp@ops.ietf.org Fri Apr 23 02:36:39 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17192 for ; Fri, 23 Apr 2004 02:36:39 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGuIf-0004sS-2H for ccamp-archive@ietf.org; Fri, 23 Apr 2004 02:36:37 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGuHl-0004dO-00 for ccamp-archive@ietf.org; Fri, 23 Apr 2004 02:35:41 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BGuH1-0004OG-00 for ccamp-archive@ietf.org; Fri, 23 Apr 2004 02:34:55 -0400 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BGu3S-000LzF-Kq for ccamp-data@psg.com; Fri, 23 Apr 2004 06:20:54 +0000 Received: from [66.163.170.83] (helo=smtp813.mail.sc5.yahoo.com) by psg.com with smtp (Exim 4.30; FreeBSD) id 1BGu3P-000LyP-Hy for ccamp@ops.ietf.org; Fri, 23 Apr 2004 06:20:51 +0000 Received: from unknown (HELO RAKHILAPTOP) (vishal.sharma@sbcglobal.net@63.202.179.107 with login) by smtp813.mail.sc5.yahoo.com with SMTP; 23 Apr 2004 06:20:51 -0000 Reply-To: From: "Vishal Sharma" To: , Cc: Subject: RE: Status of draft-ietf-ccamp-alarm-spec-00 Date: Thu, 22 Apr 2004 23:20:50 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Adrian, In discussions on this draft about a month ago, upon request from the authors, I had provided some specific feedback to them http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00184.html Since the document was submitted as "draft-ietf" soon thereafter without any changes, I don't think these changes/comments have been addressed in the document thus far. -Vishal > -----Original Message----- > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On > Behalf Of Adrian Farrel > Sent: Thursday, April 22, 2004 1:57 AM > To: ccamp@ops.ietf.org > Cc: adrian@olddog.co.uk; lberger@movaz.com > Subject: Status of draft-ietf-ccamp-alarm-spec-00 > > > All, > > Despite its low revision number, this work is actually quite > mature and has > seen some early implementation. > > I would like to get a sense from the working group for whether they think > this draft has been sufficiently developed to be moved to last call. > > Hints > - I think it is ready for working group last call (but I'm an author) > - If you don't think it is ready, you MUST say what your issues with the > draft are. "Not discussed enough" is not a real reason. > > Thanks, > Adrian From owner-ccamp@ops.ietf.org Fri Apr 23 05:52:01 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25179 for ; Fri, 23 Apr 2004 05:52:01 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGxLj-0002wJ-Qc for ccamp-archive@ietf.org; Fri, 23 Apr 2004 05:51:59 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGxKk-0002fR-00 for ccamp-archive@ietf.org; Fri, 23 Apr 2004 05:50:59 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BGxK6-0002Or-00 for ccamp-archive@ietf.org; Fri, 23 Apr 2004 05:50:18 -0400 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BGwwf-000AoI-Em for ccamp-data@psg.com; Fri, 23 Apr 2004 09:26:05 +0000 Received: from [62.23.212.165] (helo=smail.alcatel.fr) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BGwwd-000Ant-L6 for ccamp@ops.ietf.org; Fri, 23 Apr 2004 09:26:03 +0000 Received: from bemail05.netfr.alcatel.fr (bemail05.netfr.alcatel.fr [155.132.251.11]) by smail.alcatel.fr (ALCANET/NETFR) with ESMTP id i3N9OkQP021855; Fri, 23 Apr 2004 11:24:46 +0200 Received: from alcatel.be ([138.203.118.2]) by bemail05.netfr.alcatel.fr (Lotus Domino Release 5.0.11) with ESMTP id 2004042311244476:2064 ; Fri, 23 Apr 2004 11:24:44 +0200 Message-ID: <4088E15D.4000102@alcatel.be> Date: Fri, 23 Apr 2004 11:26:53 +0200 From: Dimitri.Papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.5) Gecko/20030925 X-Accept-Language: en-us, en MIME-Version: 1.0 To: v.sharma@ieee.org Cc: adrian@olddog.co.uk, ccamp@ops.ietf.org, lberger@movaz.com Subject: Re: Status of draft-ietf-ccamp-alarm-spec-00 References: In-Reply-To: X-MIMETrack: Itemize by SMTP Server on BEMAIL05/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 04/23/2004 11:24:45, Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 04/23/2004 11:24:48, Serialize complete at 04/23/2004 11:24:48 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed X-Alcanet-MTA-scanned-and-authorized: yes Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit vishal - some responses to the mail you were pointing out: > Hi Lou, > > While the document describes well _what_ it is doing, I think it is > not clear on why this needs to be done, why it is important > (motivation), what requirements it is satisfying, and how they relate > to the current WG charter. > (Note this does not mean that the problem may not be important or > should not be in the charter.) as said in section 1 "The extensions defined in this document allow an operator or a software component to obtain a full list of current alarms associated with all of the resources used to support an LSP. The extensions also ensure that this list is kept up-to-date and synchronized with the real alarm status in the network. Finally, the extensions make the list available at every node traversed by an LSP." what else do you see useful as text ? > Also, in response to your explanation below, it is not really clear > that alarm reporting is a component of path setup. Seems to me that > the two are decoupled. the document doesn't say it a component of the "setup" - procedures are described in section 3.2.2 > And, the "determing the actual route and other properties" phrase > mentioned in the CCAMP WG charter I thought is aimed at addressing the > issue of tunnel tracing (and determing LSP properties therefrom), > rather than reporting alarms at specific nodes along the path of an > LSP. > > With regard to your question, here is some additional feedback > on the draft: > > -- The following phrase is actually unclear, as I explain below. > > also: > > The communication of alarms within GMPLS does not imply any > modification in behavior of processing of alarms, or for the > communication of alarms outside of GMPLS. > > If there is no modification in the behavior of alarm processing, then > presumably there is already a way to monitor and process them, so how > (and with what) does this communication help? because as said in the introduction: " The extension described in this document defines how the alarm information associated with a GMPLS label-switched path (LSP) may be communicated along the path of the LSP. Communication both upstream and downstream is supported. The value in communicating such alarm information is that this information is then available at every node along the LSP for display and diagnostic purposes. " > (I have seen the few phrases in the document in Section 1, along the > lines of "there may be a desire to retain an LSP, particularly in > optical transport networks, and communicate > alarm information," but these do not say why.) > > -- The technique described in this draft relies on existing > techniques for monitoring and correlating alarms, and appears to > focus on the communication of this information along an LSP > path. > (While it may be argued that the latter is a "monitoring" > function, I am not sure how strong an argument that is, since > the monitoring (or most of it) has presumably happened before this > communication begins.) see procedure described in section 3.2.2 > -- Also, are there interactions/race conditions between this alarm > communication with other mechanisms conveying problems along an LSP? > Some discussion in the doc. would be valuable. > > -- The document mentions briefly that the LSP state must > be retained for the communicated alarm information to be useful. > > I think this is an important point, and worth expanding on in the doc. > I don't think there is any discussion right now of how one might > ensure that state has not been torn down by the time the alarm > information is correlated and ready to be communicated upstream > and downstream. agreed that as part of the last call process some text concerning the two above point might be clarifying even if strictly speaking the first one should be part of an applicability statement document > -- And, can the document provide some examples of the types of alarms > it is talking about/referring to? I think this will help a reader > understand better the why behind this approach. examples are illustrative anyway, if any they would be included in appendix, imho such examples would better fit in an applicability statement document > -- Finally, I wasn't sure if the issue of enumeration dicussed > with Tom Petch and Bert in Nov. was solved. (I saw that the draft > refers to GR833 for Error String enumerations and to the ALARM-MIB > for the Error Codes field.) yes, it is. > So these are my thoughts and feedback to the authors and WG. > It may be good to hear from some other WG participants who have also > read the document. > > -Vishal Vishal Sharma wrote: > Adrian, > > In discussions on this draft about a month ago, upon request from > the authors, I had provided some specific feedback to them > http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00184.html > > Since the document was submitted as "draft-ietf" soon thereafter > without any changes, I don't think these changes/comments have > been addressed in the document thus far. > > -Vishal > > >>-----Original Message----- >>From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On >>Behalf Of Adrian Farrel >>Sent: Thursday, April 22, 2004 1:57 AM >>To: ccamp@ops.ietf.org >>Cc: adrian@olddog.co.uk; lberger@movaz.com >>Subject: Status of draft-ietf-ccamp-alarm-spec-00 >> >> >>All, >> >>Despite its low revision number, this work is actually quite >>mature and has >>seen some early implementation. >> >>I would like to get a sense from the working group for whether they think >>this draft has been sufficiently developed to be moved to last call. >> >>Hints >> - I think it is ready for working group last call (but I'm an author) >> - If you don't think it is ready, you MUST say what your issues with the >>draft are. "Not discussed enough" is not a real reason. >> >>Thanks, >>Adrian > > -- Papadimitriou Dimitri E-mail : dimitri.papadimitriou@alcatel.be E-mail : dpapadimitriou@psg.com Webpage: http://psg.com/~dpapadimitriou/ Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium Phone : +32 3 240-8491 From owner-ccamp@ops.ietf.org Fri Apr 23 06:08:48 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25789 for ; Fri, 23 Apr 2004 06:08:48 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGxbz-0007RK-9n for ccamp-archive@ietf.org; Fri, 23 Apr 2004 06:08:47 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGxb3-0007Bt-00 for ccamp-archive@ietf.org; Fri, 23 Apr 2004 06:07:50 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BGxaE-0006wi-00 for ccamp-archive@ietf.org; Fri, 23 Apr 2004 06:06:58 -0400 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BGxQt-000Jps-Go for ccamp-data@psg.com; Fri, 23 Apr 2004 09:57:19 +0000 Received: from [195.8.69.15] (helo=oceanus.uk.clara.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BGxQs-000JpI-3T for ccamp@ops.ietf.org; Fri, 23 Apr 2004 09:57:18 +0000 Received: from claranet by oceanus.uk.clara.net with local (Exim 4.22) id 1BGxQq-000CgA-UN; Fri, 23 Apr 2004 10:57:16 +0100 From: "Adrian Farrel" To: Dimitri.Papadimitriou@alcatel.be, v.sharma@ieee.org Cc: adrian@olddog.co.uk, ccamp@ops.ietf.org, lberger@movaz.com Reply-To: adrian@olddog.co.uk Subject: Re: Status of draft-ietf-ccamp-alarm-spec-00 Date: Fri, 23 Apr 2004 10:57:16 +0100 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Remote_Addr: 156.106.224.107 Message-Id: Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit A few additional comments. > > -- Also, are there interactions/race conditions between this alarm > > communication with other mechanisms conveying problems along an LSP? > > Some discussion in the doc. would be valuable. Nothing to discuss. Unless you can suggest a problem that we should be worried about. > > -- The document mentions briefly that the LSP state must > > be retained for the communicated alarm information to be useful. > > > > I think this is an important point, and worth expanding on in the doc. > > I don't think there is any discussion right now of how one might > > ensure that state has not been torn down by the time the alarm > > information is correlated and ready to be communicated upstream > > and downstream. If the state has been torn down, there is clearly no LSP about which to communicate alarm state. > > -- And, can the document provide some examples of the types of alarms > > it is talking about/referring to? I think this will help a reader > > understand better the why behind this approach. > > examples are illustrative anyway, if any they would be included in > appendix, imho such examples would better fit in an applicability > statement document Agreed. Besides, there is no limit to the alarms that this could be applied to. Very specifically - any alarm that impacts or is related to the LSP. Thanks, Adrian From owner-ccamp@ops.ietf.org Fri Apr 23 06:18:03 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26069 for ; Fri, 23 Apr 2004 06:18:03 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGxkv-00026y-K9 for ccamp-archive@ietf.org; Fri, 23 Apr 2004 06:18:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGxkC-0001pq-00 for ccamp-archive@ietf.org; Fri, 23 Apr 2004 06:17:17 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BGxjS-0001YV-00 for ccamp-archive@ietf.org; Fri, 23 Apr 2004 06:16:30 -0400 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BGxbN-000OCU-K1 for ccamp-data@psg.com; Fri, 23 Apr 2004 10:08:09 +0000 Received: from [62.23.212.165] (helo=smail.alcatel.fr) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BGxbM-000OBY-7G for ccamp@ops.ietf.org; Fri, 23 Apr 2004 10:08:08 +0000 Received: from bemail05.netfr.alcatel.fr (bemail05.netfr.alcatel.fr [155.132.251.11]) by smail.alcatel.fr (ALCANET/NETFR) with ESMTP id i3NA6jQP021386; Fri, 23 Apr 2004 12:06:46 +0200 Received: from alcatel.be ([138.203.118.2]) by bemail05.netfr.alcatel.fr (Lotus Domino Release 5.0.11) with ESMTP id 2004042312064448:2327 ; Fri, 23 Apr 2004 12:06:44 +0200 Message-ID: <4088EB36.7080603@alcatel.be> Date: Fri, 23 Apr 2004 12:08:54 +0200 From: Dimitri.Papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.5) Gecko/20030925 X-Accept-Language: en-us, en MIME-Version: 1.0 To: adrian@olddog.co.uk Cc: v.sharma@ieee.org, ccamp@ops.ietf.org, lberger@movaz.com Subject: Re: Status of draft-ietf-ccamp-alarm-spec-00 References: In-Reply-To: X-MIMETrack: Itemize by SMTP Server on BEMAIL05/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 04/23/2004 12:06:44, Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 04/23/2004 12:06:45, Serialize complete at 04/23/2004 12:06:45 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed X-Alcanet-MTA-scanned-and-authorized: yes Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Adrian Farrel wrote: > A few additional comments. > >> > -- Also, are there interactions/race conditions between this alarm >> > communication with other mechanisms conveying problems along an LSP? >> > Some discussion in the doc. would be valuable. > > > Nothing to discuss. Unless you can suggest a problem that we should > be worried about. reason why i think this should be strictly speaking part of an applicability statement document (if such issue arise, anyway) >> > -- The document mentions briefly that the LSP state must >> > be retained for the communicated alarm information to be useful. >> > >> > I think this is an important point, and worth expanding on in the doc. >> > I don't think there is any discussion right now of how one might >> > ensure that state has not been torn down by the time the alarm >> > information is correlated and ready to be communicated upstream >> > and downstream. > > > If the state has been torn down, there is clearly no LSP about which to > communicate alarm state. this could be added (i didn't suggest to enter into more than this) >> > -- And, can the document provide some examples of the types of alarms >> > it is talking about/referring to? I think this will help a reader >> > understand better the why behind this approach. >> examples are illustrative anyway, if any they would be included in >> appendix, imho such examples would better fit in an applicability >> statement document > > > Agreed. > Besides, there is no limit to the alarms that this could be applied to. > Very specifically - any alarm that impacts or is related to the LSP. agreed > Thanks, > Adrian -- Papadimitriou Dimitri E-mail : dimitri.papadimitriou@alcatel.be E-mail : dpapadimitriou@psg.com Webpage: http://psg.com/~dpapadimitriou/ Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium Phone : +32 3 240-8491 From owner-ccamp@ops.ietf.org Fri Apr 23 07:54:00 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29388 for ; Fri, 23 Apr 2004 07:53:59 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGzFp-0003jK-1L for ccamp-archive@ietf.org; Fri, 23 Apr 2004 07:54:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGzEv-0003Sr-00 for ccamp-archive@ietf.org; Fri, 23 Apr 2004 07:53:06 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BGzDy-0003BJ-00 for ccamp-archive@ietf.org; Fri, 23 Apr 2004 07:52:06 -0400 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BGyw7-000J8f-3A for ccamp-data@psg.com; Fri, 23 Apr 2004 11:33:39 +0000 Received: from [195.8.69.15] (helo=oceanus.uk.clara.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BGyw5-000J88-4V for ccamp@ops.ietf.org; Fri, 23 Apr 2004 11:33:37 +0000 Received: from claranet by oceanus.uk.clara.net with local (Exim 4.22) id 1BGyw8-000LWw-KL; Fri, 23 Apr 2004 12:33:40 +0100 From: "Adrian Farrel" To: ospf@peach.ease.lsoft.com, ccamp@ops.ietf.org, Venkata.Naidu@MARCONI.COM Cc: adrian@olddog.co.uk Reply-To: adrian@olddog.co.uk Subject: Re: OSPF TLVs Date: Fri, 23 Apr 2004 12:33:40 +0100 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Remote_Addr: 156.106.224.107 Message-Id: Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Hi Venkata, > -> RFC3630 implies that the actual space in the message is a > -> multiple of 32bits regardless of the value of the length field, > -> and that the length field represents the length of the value field(s). > -> > -> draft-ietf-ccamp-ospf-gmpls-extensions-12 does not > -> contradict this. That is, the field labeled "Padding" is > -> actually a value field of the TLV. (It might have been > -> better labeled as "Reserved"). As the text says... > -> > -> The padding is 3 octets, and is used to make the > -> Interface Switching Capability Descriptor sub-TLV > -> 32-bits aligned. It SHOULD be set to zero by the > -> sender and SHOULD be ignored by the receiver. > -> > -> That is, it makes the sub-TLV length up to a 32-bit multiple. > > I agree with Acee. You confused me. Sorry. Not my aim to spoil your day. > We have two cases here: > > 1. Actual (Value) length carried in a TLV is explicit by the > "Length" field. In this case, padding/reserved space is > implicitly ignored based on next boundary math (here 32-bit) > if any, so that parser jump to next TLV with out ambiguity. No. This is NOT what 3630 says. 3630 says that if a TLV is not a multiple of 32-bits, padding is inserted between it and the next TLV. It does not comment on the contents of the TLV. For example, if a TLV had five reserved bytes at the end, we would not modify this so that it had only one reserved byte. In other words, the contents of the TLV are opaque to the TLV packing rules. The length field specifies the length of the V without saying anything about the format of the data in the V. All packing can be performed using the length field. > 2. Actual (Value) length carried in a TLV is implicit by the > "Type" field. In this case, the "Length" field signifies > total (actual + pad/reserved). So that, parser can jump > to next TLV with out ambiguity. > > I thought, (1) is what followed by TE community. I think, > you are supporting (2). I am? Length may be defined by type (with respect to documentation), but it is not implicit. That is, the length field ALWAYS gives the length of the V field. If the V field contains explicit padding or reserved bits, they are included in the length. In summary, there is a distinction between how TLVs are defined and how the message building rules are defined. The draft gives the former, the RFC gives the latter. > I don't argue which one is the correct > solution, but, it would be nice to synchronize same semantics > across all TE TLVs. I think there is no discrepency across these TLVs. > As a side note, I don't understand why padding is in place for > every granular TLV (sub-sub-TLV etc). Don't you think it is > efficient and bandwidth saving, if padding is used only at the > highest level of TLV/LSA. I don't understand why we try to > achieve 32-bit boundary for every TLV? I have no comments on the history of why this is what is done in OSPF, but it is. From an implementation perspective, 32-bit alignment may be nice. > Given that machines are > so fast, the difference in clock cycles in fetching a 32-bit > vs 8-bit number is not significant in processing speed (at least > with modern processors). Adrian From owner-ccamp@ops.ietf.org Fri Apr 23 08:00:52 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29640 for ; Fri, 23 Apr 2004 08:00:51 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGzMS-0005Wu-Us for ccamp-archive@ietf.org; Fri, 23 Apr 2004 08:00:53 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGzLU-0005Hm-00 for ccamp-archive@ietf.org; Fri, 23 Apr 2004 07:59:53 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BGzKS-0004t4-00 for ccamp-archive@ietf.org; Fri, 23 Apr 2004 07:58:48 -0400 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BGz73-000M92-2d for ccamp-data@psg.com; Fri, 23 Apr 2004 11:44:57 +0000 Received: from [195.8.69.15] (helo=oceanus.uk.clara.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BGz71-000M8K-Qj for ccamp@ops.ietf.org; Fri, 23 Apr 2004 11:44:55 +0000 Received: from claranet by oceanus.uk.clara.net with local (Exim 4.22) id 1BGz75-000MWK-GH; Fri, 23 Apr 2004 12:44:59 +0100 From: "Adrian Farrel" To: jeanlouis.leroux@francetelecom.com, ccamp@ops.ietf.org Cc: adrian@olddog.co.uk Reply-To: adrian@olddog.co.uk Subject: Re: Proposed strategy for Inter-area/AS Date: Fri, 23 Apr 2004 12:44:59 +0100 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Remote_Addr: 156.106.224.107 Message-Id: Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Jean-Louis > I think this is a good strategy. Thanks! I think we're pretty close to agreement on the points you raise. It may not have been apparent from my original email that I am NOT suggesting the work in one phase must complete before the work on the next phase can start. I am, however, saying that I expect the work to start in the order shown. This is not unreasonable and should reflect the natural processes anyway. > I have two comments: > > 1) As already mentionned by Vishal, we cannot, > IMHO, decorrelate 6 from 1, 2 3 and 5. > -The support of additional functions may require important > modifications, if they are not taken into account during the > initial step of specifications. >-Path Reoptimization is a MUST requirement and Path diversity is a > SHOULD requirement ( inter-area and inter-as reqt drafts). So we > should not address them as advanced functions, but rather as base > functions of the inter-area/AS tool-kit. > > 2) I'm not sure to well understand what do you put in 3. > What do you exaclty mean by routing model, and how do you > distinguish it from the path computation model ? Perhaps I should have said "distibution of TE and other information by the routing protocol or by other means". This is not path computation. > Requirement drafts clearly point out that routing (IGP, EGP) > extensions should be avoided, except some minor extensions to > advertise static parameters such as PCS capabilities for instance > (addressed in point 5). I am not sure that I can find any text in the two TEWG drafts that actually says what you suggest. There are comments on scalability which are, of course, related. There are also lots of comments about TE aggregation which might be considered as extensions. Regardless of how or where the path is computed the full system must have visibility across the whole of the system. This may be compartmentalised and restricted to domains relying on crankback, it may use cooperative PCEs, it may use some leakage of (aggregated) TE information. What is up for debate is closely linked to the choice of computation point(s) and focuses on what information is distributed and how. > Hope this will help. Very much appreciate your support and opinions. Cheers, Adrian From owner-ccamp@ops.ietf.org Fri Apr 23 08:24:05 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00392 for ; Fri, 23 Apr 2004 08:24:05 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGziw-0003aD-SI for ccamp-archive@ietf.org; Fri, 23 Apr 2004 08:24:06 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGzgy-00035p-00 for ccamp-archive@ietf.org; Fri, 23 Apr 2004 08:22:05 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BGzgV-0002q7-00 for ccamp-archive@ietf.org; Fri, 23 Apr 2004 08:21:35 -0400 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BGzVA-0003ry-Sm for ccamp-data@psg.com; Fri, 23 Apr 2004 12:09:52 +0000 Received: from [195.101.245.16] (helo=p-mail2.rd.francetelecom.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BGzV9-0003rj-G3 for ccamp@ops.ietf.org; Fri, 23 Apr 2004 12:09:51 +0000 Received: from lanmhs30.rd.francetelecom.fr ([10.193.21.61]) by parsmtp2.rd.francetelecom.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 23 Apr 2004 14:09:49 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE : Proposed strategy for Inter-area/AS Date: Fri, 23 Apr 2004 14:09:44 +0200 Message-ID: Thread-Topic: RE : Proposed strategy for Inter-area/AS Thread-Index: AcQiGDZlzpgx+qCBT0+NDcGUHVJAsgGfCgZwABxJAgAACZWi4A== From: "LE ROUX Jean-Louis FTRD/DAC/LAN" To: X-OriginalArrivalTime: 23 Apr 2004 12:09:49.0213 (UTC) FILETIME=[E00764D0:01C4292B] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Hi Adrian and Kireeti, I think this is a good strategy. I have two comments: 1) As already mentionned by Vishal, we cannot, IMHO, decorrelate 6 from = 1, 2 3 and 5. -The support of additional functions may require important = modifications, if they are not taken into account during the initial = step of specifications. -Path Reoptimization is a MUST requirement and Path diversity is a = SHOULD requirement ( inter-area and inter-as reqt drafts). So we should = not address them as advanced functions, but rather as base functions of = the inter-area/AS tool-kit. 2) I'm not sure to well understand what do you put in 3. What do you exaclty mean by routing model, and how do you distinguish it = from the path computation model ? Requirement drafts clearly point out = that routing (IGP, EGP) extensions should be avoided, except some minor = extensions to advertise static parameters such as PCS capabilities for = instance (addressed in point 5).=20 Hope this will help. Regards, JL > -----Message d'origine----- > De : owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] De la=20 > part de Adrian Farrel Envoy=E9 : mercredi 14 avril 2004 13:50 > =C0 : ccamp@ops.ietf.org > Objet : Proposed strategy for Inter-area/AS >=20 >=20 > All, >=20 > JP and Arthi have done a fine job of pulling together all of the=20 > threads of inter-area and inter-AS solutions into a single draft. This = > gives us a single place to look for information, but the resulting=20 > draft is (of course) quite large. As additional details need to be=20 > filled in, it is clear that this draft would only grow and that would=20 > make it unusably large. >=20 > So, we are proposing to use the material in the draft to produce a=20 > series of detailed drafts that would, over time, replace JP and=20 > Arthi's document. >=20 > 1. Framework for Interdomain MPLS and GMPLS > A short draft that introduces the routing and signaling options > for multi-domain LSPs, and explains the options for path > computation. > This does not describe applicability or any necessary protocol > procedures or extensions. > Material will be taken from draft-vasseur-ccamp-inter-area-as-te > and draft-kompella-mpls-multiarea-te as required. > Authors: Adrian, JP, Arthi > Due date: End of April. >=20 > 2. Individual signaling extension drafts > If any one of the signaling approaches described in 1. > requires additional protocol procedures or extensions > then a single draft will be written for each. > The base assumption is that such a draft will only be > written if there someone planning to implement and > deploy. > Authors: Dependent on extension > Due date: Aim for San Diego >=20 > 3. Individual routing extension drafts > There are two dimensions to this: > - the different routing protocols (IGPs and EGPs) > - the different solution models > The aim should be to have one draft per protocol to provide the > generic mechanisms, and one draft per model per protocol to > provide procedures and field values etc. > Note that path computation functions are described under point > 5, below. > As with the signaling extensions, this work will only be done=20 > once > we understand that there is a need *and* what is needed. > Authors: Again dependent on deployment plans > Due date: Slightly later than signaling work >=20 > 4. Applicability > A draft to explain when it is appropriate to use which model and > options. The aim is not to rubbish the opposition, but to say when > a particular model can/should be used. > Much of this material can already be found in > draft-vasseur-ccamp-inter-area-as-te, but it may need > some tidying up. > For political/expediency reasons this may result in multiple > applicability drafts in the first instance. > Authors: A supporter of each model > Due date: Quite soon - to accompany signaling extensions. >=20 > 5. Path computation > Some solution models call for a (or many) path computation > servers (PCS). This demands several functions: > - discovery of PCS by network elements > - communication protocol between PCS and network elements > - some regulation of computation technique to avoid looping etc. > At the moment we are discussing precisely where this work should > be done, but that should not stop us starting the work within=20 > CCAMP > since it is clearly related to the inter-area/AS solution. >=20 > 6. Advanced functions. > There are several advanced functions that will be required, but=20 > which > are not part of the immediate work. > - Path reoptimization > - Protection path diversity > - crankback > We expect that once the initial work has been done on > the solutions, it > will be possible to set out the requirements for these=20 > functions and to > develop solutions based on the many drafts that are=20 > already out there. >=20 > Comments please. >=20 > Thanks, > Adrian and Kireeti >=20 >=20 >=20 From owner-ccamp@ops.ietf.org Fri Apr 23 08:25:14 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00478 for ; Fri, 23 Apr 2004 08:25:14 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGzk4-0003tt-20 for ccamp-archive@ietf.org; Fri, 23 Apr 2004 08:25:16 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGzj6-0003bj-00 for ccamp-archive@ietf.org; Fri, 23 Apr 2004 08:24:17 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BGzhR-00036W-00 for ccamp-archive@ietf.org; Fri, 23 Apr 2004 08:22:34 -0400 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BGzVQ-0003vu-M0 for ccamp-data@psg.com; Fri, 23 Apr 2004 12:10:08 +0000 Received: from [195.101.245.15] (helo=p-mail1.rd.francetelecom.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BGzVN-0003v9-E2 for ccamp@ops.ietf.org; Fri, 23 Apr 2004 12:10:05 +0000 Received: from lanmhs30.rd.francetelecom.fr ([10.193.21.61]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 23 Apr 2004 14:09:16 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE : draft-ali-ccamp-rsvp-node-id-based-hello-01.txt as WG document? Date: Fri, 23 Apr 2004 14:09:11 +0200 Message-ID: Thread-Topic: RE : draft-ali-ccamp-rsvp-node-id-based-hello-01.txt as WG document? Thread-Index: AcQoORmMKxplggxkTKOq0ZlVCGBzawASjUVgACCEu9AACZiRQA== From: "LE ROUX Jean-Louis FTRD/DAC/LAN" To: X-OriginalArrivalTime: 23 Apr 2004 12:09:16.0132 (UTC) FILETIME=[CC4FA240:01C4292B] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Yes > -----Message d'origine----- > De : owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] De la=20 > part de Adrian Farrel Envoy=E9 : jeudi 22 avril 2004 09:04 > =C0 : ccamp@ops.ietf.org > Cc : adrian@olddog.co.uk > Objet : draft-ali-ccamp-rsvp-node-id-based-hello-01.txt as WG=20 > document? >=20 >=20 > All, >=20 > The authors of > http://www.ietf.org/internet-drafts/draft-ali-ccamp-rsvp-node- id-based-hello=20 -01.txt have re-positioned the draft as a BCP as discussed on the list. = They=20 have also included changes to address comments received on the list.=20 Can I take a poll on whether you think this work should be (and is ready = to=20 be) adopted by the WG.=20 You may go "hmmm" for yes, or "shhhh" for no. Alternatively, send a simple email to the list saying yes or no.=20 Thanks, Adrian=20 From owner-ccamp@ops.ietf.org Fri Apr 23 08:27:08 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00689 for ; Fri, 23 Apr 2004 08:27:08 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGzlt-0004TK-Gd for ccamp-archive@ietf.org; Fri, 23 Apr 2004 08:27:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGzl4-0004Cy-00 for ccamp-archive@ietf.org; Fri, 23 Apr 2004 08:26:19 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BGzkG-0003vP-00 for ccamp-archive@ietf.org; Fri, 23 Apr 2004 08:25:28 -0400 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BGzUv-0003r6-Ft for ccamp-data@psg.com; Fri, 23 Apr 2004 12:09:37 +0000 Received: from [195.101.245.16] (helo=p-mail2.rd.francetelecom.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BGzUu-0003qt-6t for ccamp@ops.ietf.org; Fri, 23 Apr 2004 12:09:36 +0000 Received: from lanmhs30.rd.francetelecom.fr ([10.193.21.61]) by parsmtp2.rd.francetelecom.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 23 Apr 2004 14:09:34 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE : draft-dachille: Comments on topology summarization and optimality Date: Fri, 23 Apr 2004 14:09:29 +0200 Message-ID: Thread-Topic: RE : draft-dachille: Comments on topology summarization and optimality Thread-Index: AcQlF4XaRLQ1QOlbR2enPVG+sXDZtADbWGnQAB/6pbAACb8J4A== From: "LE ROUX Jean-Louis FTRD/DAC/LAN" To: X-OriginalArrivalTime: 23 Apr 2004 12:09:34.0353 (UTC) FILETIME=[D72BF010:01C4292B] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Hi Vishal, This is a correct summary of the discussion we had during the Seoul = meeting. Just one clarification regarding comment iii,=20 You make the following routing assumption (section 4): "In the following we will assume that every border router, say B1,=20 that is directly attached to area X maintains = a summarized=20 topological view consisting of the exact intra-area = topology of X=20 plus several so called =F4virtual links=F6. Virtual = link are present=20 between the border routers of area X, say B2 B3 etc., = and the=20 possible destinations: they merely represent external = paths to remote=20 destinations that are reachable through some = inter-area path. Virtual=20 link might be assigned a cost" The question is how do you perform such TE topology summarization ?=20 More particularly how do you summarize information on link admin-groups, = which basically need to be taken into acount during path computation ? = Let's assume that there are N paths between an ABR an a destination, = each with a distinct avaialble bandwidth, and a distinct admin group (a = path admin group being expressed as a logical AND of the afinities of = each link in the path).=20 You then need to advertise N Virtual links, each with a distinct admin = group.=20 IMHO this does not scale and also compromises one of the main = motivations of IGP hierarchy, i.e. the containement of routing = information.=20 This is actually one of the reasons, in the inter-area requirement = draft, for precluding such leaking of summarized TE-link information = across areas. Actually you use this virtual topology, in 4.1 and 4.2, to select = downstream ABRs. IMHO your JSA approach can work independantly of the = method used to select downstream ABRs. Thus, you should IMHO let = downstream ABR selection beyond the scope of the draft, and remove all = text related to virtual topologies.=20 Regards, JL > -----Message d'origine----- > De : owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] De la=20 > part de Vishal Sharma Envoy=E9 : dimanche 18 avril 2004 09:17 > =C0 : CCAMP > Cc : LE ROUX Jean-Louis FTRD/DAC/LAN; Fabio Ricciato; Alessio=20 > D'Achille; Ugo Monaco; Marco Listanti > Objet : draft-dachille: Comments on topology summarization=20 > and optimality >=20 >=20 > Hi JL, >=20 > Thanks for your feedback on our draft/scheme during the > Seoul IETF. >=20 > As mentioned in an earlier email to the ML, before we address the=20 > various points made by folks who gave us their valuable feedback, we=20 > are summarizing their comments to ensure that > (a) we rightly understood their inputs :-), and (b) to help > people on the ML follow and contribute to the subsequent discussions. >=20 > After reviewing my notes from our discussions and discussing them with = > my co-authors, I have summarized your comments as below. >=20 > If I missed something or did not capture some of your=20 > questions/comments correctly, please do let us know. We will take this = > into account in providing our responses, and, later, in updating the=20 > document. >=20 > Best regards, > -Vishal >=20 > ********************************************************************* >=20 > Editorial: > i) Replace "area" --> "region" throughout, since you cover ASs as=20 > well. >=20 > ii) Note in the draft that the scheme is general and does more that=20 > merely helping with efficient backup path computation and setup. >=20 > Technical: > iii) The draft needs to make clear what is meant by a virtual=20 > topology, and what info. is used to create it. This is because it=20 > seems from a current reading of the draft that the virtual topology=20 > relies on info. about TE links and their bandwidth, but there is a=20 > strong requirement not to advertise TE link info. between areas. >=20 > iv) How does this approach differ from the PCS/PCE approach? Some=20 > comparison and contrasting would be useful. >=20 > v) You also suggested that one needn't be confined to carrying only=20 > one ARO. So for better optimality, one might carry multiple ARO's=20 > computed for the secondary path, and when the secondary is being set=20 > up, the ingress for the secondary could select one of the ARO segments = > for traversing it's area. This might lead to a more optimal setup than = > would otherwise be possible. >=20 > vi) Sec. 4.1 on inter-area is ok. >=20 > vii) However, for the section on inter-AS, you asked "how does the=20 > scheme computes the set of AS's that the diverse paths will use?" >=20 > viii) Do you need the optical island ID? > Even in the optical case, if one is using IP protocols, it is likely=20 > that OSFP/IS-IS areas/levels and ASs will be defined, so this then=20 > becomes the same as the inter-area/inter-AS cases. >=20 > ix) Mention that the scheme can work for IS-IS levels as well. (Note=20 > IS-IS levels can, in turn, have areas.) (One issue here is how does=20 > one identify IS-IS levels?) >=20 >=20 >=20 >=20 From owner-ccamp@ops.ietf.org Fri Apr 23 08:34:06 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01390 for ; Fri, 23 Apr 2004 08:34:06 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGzsd-0006WB-K8 for ccamp-archive@ietf.org; Fri, 23 Apr 2004 08:34:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGzrf-0006Gq-00 for ccamp-archive@ietf.org; Fri, 23 Apr 2004 08:33:08 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BGzrC-00061q-00 for ccamp-archive@ietf.org; Fri, 23 Apr 2004 08:32:38 -0400 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BGzkI-0006J7-P6 for ccamp-data@psg.com; Fri, 23 Apr 2004 12:25:30 +0000 Received: from [192.91.191.8] (helo=smtp2.datcon.co.uk) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BGzkH-0006Iq-Kd for ccamp@ops.ietf.org; Fri, 23 Apr 2004 12:25:29 +0000 Received: by beiderbecke.datcon.co.uk with Internet Mail Service (5.5.2653.19) id ; Fri, 23 Apr 2004 13:10:26 +0100 Message-ID: <53F74F5A7B94D511841C00B0D0AB16F802870927@baker.datcon.co.uk> From: Nic Neate To: Movaz Networks - Louis Berger , Movaz Networks - Igor Bryskin , "'adrian@olddog.co.uk'" , "'dimitri.papadimitriou@alcatel.be'" Cc: ccamp@ops.ietf.org, "'jplang@ieee.org'" , "'yakov@juniper.net'" Subject: The ASSOCIATION object usage in draft-berger-ccamp-gmpls-segment- recovery-00 Date: Fri, 23 Apr 2004 13:10:10 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Hi folks, I have a question concerning the usage of the new ASSOCIATION object in draft-berger-ccamp-gmpls-segment-recovery-00. This object is defined in draft-ietf-ccamp-gmpls-recovery-e2e-signaling-00, which only uses it to associate two LSPs in the same session. Consequently, it is defined with a 16 bit Association ID to identify the LSP it is associating with (filled in as the LSP ID of that LSP). The object is then used in draft-berger-ccamp-gmpls-segment-recovery-00 to associate LSPs in different sessions - the segment recovery LSPs and the LSP they are protecting. See the following quote from section 2. ... Each segment recovery LSP is signaled as an independent LSP. Specifically, the Sender_Template object uses the IP address of the node originating the recovery path, e.g., node C in the topology shown above, and the Session object contains the IP address of the node terminating the recovery path ... When [FRR] isn't being used, the association between segment recovery LSPs with other LSPs is indicated using the Association object defined in [E2E-RECOVERY]. The Association object is used to associate recovery LSPs with the LSP they are protecting. Clearly 16 bits is not enough to identify the associated LSP unless we know which session it's in. My question, then, is is it really necessary for the recovery LSPs to be in different sessions from the LSP they are protecting? Would it not be possible to do this in a more similar way to Fast Reroute, where the backup LSPs are in the same session as the protected LSP? The reason this concerns me is that historically (as far as I am aware) LSPs in different sessions have always operated independently of each other. This draft takes protocol messages from an LSP in one session and propagates them along an LSP in a different session, removing that independence. While I can't see a reason why this can't work, I do see it as a significant complication to the protocol which we would do well to avoid. If it really is necessary for the recovery LSPs to be in different sessions then I think we need some text in the draft explaining exactly how the Association ID is used in this scenario. Please let me know what you think. Thanks, Nic From owner-ccamp@ops.ietf.org Fri Apr 23 08:48:39 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02068 for ; Fri, 23 Apr 2004 08:48:39 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH06i-0002LD-Ho for ccamp-archive@ietf.org; Fri, 23 Apr 2004 08:48:40 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH051-00022m-00 for ccamp-archive@ietf.org; Fri, 23 Apr 2004 08:46:56 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BH047-0001n3-00 for ccamp-archive@ietf.org; Fri, 23 Apr 2004 08:45:59 -0400 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BGzr7-0007a4-Nc for ccamp-data@psg.com; Fri, 23 Apr 2004 12:32:33 +0000 Received: from [65.205.166.188] (helo=jera.movaz.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BGzr4-0007ZT-Az for ccamp@ops.ietf.org; Fri, 23 Apr 2004 12:32:30 +0000 Received: from lb-laptop.movaz.com (movaz-hw.atlanta.movaz.com [172.16.8.183]) by jera.movaz.com (Postfix) with ESMTP id B2957D25; Fri, 23 Apr 2004 08:32:28 -0400 (EDT) Message-Id: <6.0.3.0.2.20040423082835.04d1de78@mo-ex1> X-Sender: lb@mo-ex1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.3.0 Date: Fri, 23 Apr 2004 08:32:25 -0400 To: "Nic Neate" From: Lou Berger Subject: Re: The ASSOCIATION object usage in draft-berger-ccamp-gmpls-segment-recovery-00 Cc: "Berger, Lou" , "Bryskin, Igor" , , , , , In-Reply-To: <53F74F5A7B94D511841C00B0D0AB16F802870927@baker.datcon.co.u k> References: <53F74F5A7B94D511841C00B0D0AB16F802870927@baker.datcon.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,SUBJ_HAS_UNIQ_ID autolearn=no version=2.60 Nic, Note that the 16 bits are scoped within the association source (IP address). So there is really 48 bits in the association ID. Do you belive that 64K associations per IP address is insufficient??? Lou At 08:10 AM 4/23/2004 -0400, Nic Neate wrote: >The object is then used in draft-berger-ccamp-gmpls-segment-recovery-00 to >associate LSPs in different sessions - the segment recovery LSPs and the LSP >they are protecting. See the following quote from section 2. > > ... Each segment recovery LSP is > signaled as an independent LSP. Specifically, the Sender_Template > object uses the IP address of the node originating the recovery path, > e.g., node C in the topology shown above, and the Session object > contains the IP address of the node terminating the recovery path ... > > When [FRR] isn't being used, the association between segment recovery > LSPs with other LSPs is indicated using the Association object > defined in [E2E-RECOVERY]. The Association object is used to > associate recovery LSPs with the LSP they are protecting. > >Clearly 16 bits is not enough to identify the associated LSP unless we know >which session it's in. From owner-ccamp@ops.ietf.org Fri Apr 23 10:34:24 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11977 for ; Fri, 23 Apr 2004 10:34:23 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH1jt-0000b0-In for ccamp-archive@ietf.org; Fri, 23 Apr 2004 10:33:13 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH1io-0000K3-00 for ccamp-archive@ietf.org; Fri, 23 Apr 2004 10:32:07 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BH1iJ-000041-00 for ccamp-archive@ietf.org; Fri, 23 Apr 2004 10:31:35 -0400 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BH1SP-00099H-Tb for ccamp-data@psg.com; Fri, 23 Apr 2004 14:15:09 +0000 Received: from [192.91.191.8] (helo=smtp2.datcon.co.uk) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BH1SO-000990-Q9 for ccamp@ops.ietf.org; Fri, 23 Apr 2004 14:15:09 +0000 Received: by beiderbecke.datcon.co.uk with Internet Mail Service (5.5.2653.19) id ; Fri, 23 Apr 2004 15:15:10 +0100 Message-ID: <53F74F5A7B94D511841C00B0D0AB16F80287092A@baker.datcon.co.uk> From: Nic Neate To: Movaz Networks - Louis Berger Cc: Movaz Networks - Igor Bryskin , adrian@olddog.co.uk, dimitri.papadimitriou@alcatel.be, ccamp@ops.ietf.org, jplang@ieee.org, yakov@juniper.net Subject: RE: The ASSOCIATION object usage in draft-berger-ccamp-gmpls-segm ent-recovery-00 Date: Fri, 23 Apr 2004 15:14:58 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 That's clarified the ASSOCIATION usage for me, thanks (I was thinking the Association ID had to identify an LSP, not just another ASSOCIATION object). I'm willing to conceed that 64k associations is probably enough. To reiterate my primary question though, is there a strong reason that the recovery LSPs have to be in a different session to the protected LSP? If you simply disagree that there's any issue, or believe the solution you've presented to be the simplest, then fine. Thanks, Nic -----Original Message----- From: Movaz Networks - Louis Berger Sent: Friday, April 23, 2004 1:32 PM To: Nic Neate Cc: Movaz Networks - Louis Berger; Movaz Networks - Igor Bryskin; adrian@olddog.co.uk; dimitri.papadimitriou@alcatel.be; ccamp@ops.ietf.org; jplang@ieee.org; yakov@juniper.net Subject: Re: The ASSOCIATION object usage in draft-berger-ccamp-gmpls-segment-recovery-00 Nic, Note that the 16 bits are scoped within the association source (IP address). So there is really 48 bits in the association ID. Do you belive that 64K associations per IP address is insufficient??? Lou At 08:10 AM 4/23/2004 -0400, Nic Neate wrote: >The object is then used in draft-berger-ccamp-gmpls-segment-recovery-00 to >associate LSPs in different sessions - the segment recovery LSPs and the LSP >they are protecting. See the following quote from section 2. > > ... Each segment recovery LSP is > signaled as an independent LSP. Specifically, the Sender_Template > object uses the IP address of the node originating the recovery path, > e.g., node C in the topology shown above, and the Session object > contains the IP address of the node terminating the recovery path ... > > When [FRR] isn't being used, the association between segment recovery > LSPs with other LSPs is indicated using the Association object > defined in [E2E-RECOVERY]. The Association object is used to > associate recovery LSPs with the LSP they are protecting. > >Clearly 16 bits is not enough to identify the associated LSP unless we know >which session it's in. From owner-ccamp@ops.ietf.org Fri Apr 23 10:35:58 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12055 for ; Fri, 23 Apr 2004 10:35:58 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH1ma-0001J4-H8 for ccamp-archive@ietf.org; Fri, 23 Apr 2004 10:36:00 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH1lf-00014s-00 for ccamp-archive@ietf.org; Fri, 23 Apr 2004 10:35:03 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BH1kt-0000px-00 for ccamp-archive@ietf.org; Fri, 23 Apr 2004 10:34:15 -0400 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BH1az-000AYS-OI for ccamp-data@psg.com; Fri, 23 Apr 2004 14:24:01 +0000 Received: from [195.101.245.15] (helo=p-mail1.rd.francetelecom.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BH1ay-000AYE-JG for ccamp@ops.ietf.org; Fri, 23 Apr 2004 14:24:00 +0000 Received: from lanmhs30.rd.francetelecom.fr ([10.193.21.61]) by parsmtp2.rd.francetelecom.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 23 Apr 2004 16:23:58 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE : Proposed strategy for Inter-area/AS Date: Fri, 23 Apr 2004 16:23:53 +0200 Message-ID: Thread-Topic: Proposed strategy for Inter-area/AS Thread-Index: AcQpKGS28kTTVzLmTJyiP5niXdTdxwABO6lQ From: "LE ROUX Jean-Louis FTRD/DAC/LAN" To: , X-OriginalArrivalTime: 23 Apr 2004 14:23:58.0664 (UTC) FILETIME=[9DE02480:01C4293E] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Adrian, See inline > -----Message d'origine----- > De : Adrian Farrel [mailto:olddog@clara.co.uk]=20 > Envoy=E9 : vendredi 23 avril 2004 13:45 > =C0 : LE ROUX Jean-Louis FTRD/DAC/LAN; ccamp@ops.ietf.org > Cc : adrian@olddog.co.uk > Objet : Re: Proposed strategy for Inter-area/AS >=20 >=20 >=20 > Jean-Louis=20 >=20 > > I think this is a good strategy. >=20 > Thanks!=20 >=20 > I think we're pretty close to agreement on the points you=20 > raise. It may not have been apparent from my original email=20 > that I am NOT=20 > suggesting the work in one phase must complete before the=20 > work on the next=20 > phase can start. I am, however, saying that I expect the work=20 > to start in=20 > the order shown. > This is not unreasonable and should reflect the natural=20 > processes anyway.=20 OK >=20 > > I have two comments: > > > > 1) As already mentionned by Vishal, we cannot, > > IMHO, decorrelate 6 from 1, 2 3 and 5. > > -The support of additional functions may require important > > modifications, if they are not taken into account during the > > initial step of specifications. > >-Path Reoptimization is a MUST requirement and Path diversity is a =20 > >SHOULD requirement ( inter-area and inter-as reqt drafts). So we =20 > >should not address them as advanced functions, but rather as base =20 > >functions of the inter-area/AS tool-kit. > > > > 2) I'm not sure to well understand what do you put in 3. > > What do you exaclty mean by routing model, and how do you=20 > distinguish=20 > > it from the path computation model ? >=20 > Perhaps I should have said "distibution of TE and other=20 > information by the routing protocol or by other means". This=20 > is not path computation.=20 >=20 > > Requirement drafts clearly point out that routing (IGP, EGP)=20 > > extensions should be avoided, except some minor extensions to=20 > > advertise static parameters such as PCS capabilities for instance=20 > > (addressed in point 5). >=20 > I am not sure that I can find any text in the two TEWG drafts=20 > that actually=20 > says what you suggest. > There are comments on scalability which are, of course,=20 > related. There are also lots of comments about TE aggregation=20 > which might be=20 > considered as extensions.=20 > Regardless of how or where the path is computed the full=20 > system must have=20 > visibility across the whole of the system. This may be=20 > compartmentalised and=20 > restricted to domains relying on crankback, it may use=20 > cooperative PCEs, it=20 > may use some leakage of (aggregated) TE information.=20 In the inter-area requirement draft, we clearly point out that = information=20 propagation for path-selection should continue to be localized and that = leaking of TE link information across areas MUST be precluded (section 5.3.1).=20 Note that this includes any summarized/aggregated TE link information.=20 I agree that this is not clear in current version, we will clarify in = next revision. Cheers JL > What is=20 > up for debate=20 > is closely linked to the choice of computation point(s) and=20 > focuses on what=20 > information is distributed and how.=20 >=20 > > Hope this will help. >=20 > Very much appreciate your support and opinions.=20 >=20 > Cheers, > Adrian=20 >=20 >=20 From owner-ccamp@ops.ietf.org Fri Apr 23 11:21:09 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14238 for ; Fri, 23 Apr 2004 11:21:09 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH2UJ-00059h-Hp for ccamp-archive@ietf.org; Fri, 23 Apr 2004 11:21:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH2TJ-0004vA-00 for ccamp-archive@ietf.org; Fri, 23 Apr 2004 11:20:10 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BH2Sf-0004gd-00 for ccamp-archive@ietf.org; Fri, 23 Apr 2004 11:19:29 -0400 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BH2Au-000JpY-8a for ccamp-data@psg.com; Fri, 23 Apr 2004 15:01:08 +0000 Received: from [195.8.69.15] (helo=oceanus.uk.clara.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BH2As-000Jow-N2 for ccamp@ops.ietf.org; Fri, 23 Apr 2004 15:01:06 +0000 Received: from claranet by oceanus.uk.clara.net with local (Exim 4.22) id 1BH2Av-000DKX-P9; Fri, 23 Apr 2004 16:01:09 +0100 From: "Adrian Farrel" To: jeanlouis.leroux@francetelecom.com, ccamp@ops.ietf.org Cc: adrian@olddog.co.uk Reply-To: adrian@olddog.co.uk Subject: Re: Proposed strategy for Inter-area/AS Date: Fri, 23 Apr 2004 16:01:09 +0100 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Remote_Addr: 156.106.224.107 Message-Id: Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Hi, Thanks for clarifying. See below... >> > Requirement drafts clearly point out that routing (IGP, EGP) >> > extensions should be avoided, except some minor extensions to >> > advertise static parameters such as PCS capabilities for instance >> > (addressed in point 5). >> >> I am not sure that I can find any text in the two TEWG drafts >> that actually says what you suggest. > In the inter-area requirement draft, we clearly point out that > information propagation for path-selection should continue to be > localized and that leaking of TE link information across areas MUST be > precluded (section 5.3.1). > Note that this includes any summarized/aggregated TE link information. > I agree that this is not clear in current version, we will clarify in > next revision. How right you are :-) The draft currently says... The solution MUST entirely preserve the concept of IGP hierarchy. In other words, flooding of TE link information across areas MUST be precluded. I took "flooding" to be a more free distibution of information that "leaking". For example, I would consider that the Summary LSA is "leaking" routing information from one LSA to another, but it is not flooding that information. If you are saying that ABSOLUTELY NO TE information may be exchanged between areas, then I wonder how an ingress LSR can know the reachability to the egress (let alone the availability of suitable paths) when areas have more than one ABR. (Note that TE addresses are not necessarily routable!) I would have a problem with the requirements draft if it is precluding ALL exchange of TE information between areas. A more appropriate requirement would describe scalability and impact on existing operation of routing protocols, but would not constrain the solution in this way. . . . . . Can you tell me the status of this draft? Is it still alive in the TEWG? Is TEWG working on it? When is it scheduled to be completed? Thanks, Adrian From owner-ccamp@ops.ietf.org Fri Apr 23 13:20:05 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21404 for ; Fri, 23 Apr 2004 13:20:05 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH4LO-0005sj-DP for ccamp-archive@ietf.org; Fri, 23 Apr 2004 13:20:06 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH4KO-0005ci-00 for ccamp-archive@ietf.org; Fri, 23 Apr 2004 13:19:05 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BH4JK-00058b-00 for ccamp-archive@ietf.org; Fri, 23 Apr 2004 13:17:58 -0400 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BH44w-0001AJ-IS for ccamp-data@psg.com; Fri, 23 Apr 2004 17:03:06 +0000 Received: from [195.101.245.16] (helo=p-mail2.rd.francetelecom.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BH44t-00018v-85 for ccamp@ops.ietf.org; Fri, 23 Apr 2004 17:03:03 +0000 Received: from lanmhs30.rd.francetelecom.fr ([10.193.21.61]) by parsmtp2.rd.francetelecom.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 23 Apr 2004 19:02:59 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE : Proposed strategy for Inter-area/AS Date: Fri, 23 Apr 2004 19:02:54 +0200 Message-ID: Thread-Topic: Proposed strategy for Inter-area/AS Thread-Index: AcQpQ8xG5eKcNHlNQjql3jM9q2dkowAC4bfg From: "LE ROUX Jean-Louis FTRD/DAC/LAN" To: , X-OriginalArrivalTime: 23 Apr 2004 17:02:59.0754 (UTC) FILETIME=[D4CEF0A0:01C42954] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Hi Adrian, See inline > -----Message d'origine----- > De : Adrian Farrel [mailto:olddog@clara.co.uk]=20 > Envoy=E9 : vendredi 23 avril 2004 17:01 > =C0 : LE ROUX Jean-Louis FTRD/DAC/LAN; ccamp@ops.ietf.org > Cc : adrian@olddog.co.uk > Objet : Re: Proposed strategy for Inter-area/AS >=20 >=20 > Hi,=20 >=20 > Thanks for clarifying. See below...=20 >=20 > >> > Requirement drafts clearly point out that routing (IGP, EGP) > >> > extensions should be avoided, except some minor extensions to=20 > >> > advertise static parameters such as PCS capabilities for=20 > instance=20 > >> > (addressed in point 5).=20 > >>=20 > >> I am not sure that I can find any text in the two TEWG drafts > >> that actually says what you suggest. >=20 > > In the inter-area requirement draft, we clearly point out that > > information propagation for path-selection should continue to be=20 > > localized and that leaking of TE link information across=20 > areas MUST be=20 > > precluded (section 5.3.1).=20 > > Note that this includes any summarized/aggregated TE link=20 > information.=20 > > I agree that this is not clear in current version, we will=20 > clarify in=20 > > next revision. >=20 > How right you are :-)=20 >=20 > The draft currently says... > The solution MUST entirely preserve the concept of IGP hierarchy. In > other words, flooding of TE link information across areas MUST be > precluded.=20 >=20 > I took "flooding" to be a more free distibution of information that=20 > "leaking".=20 >=20 > For example, I would consider that the Summary LSA is=20 > "leaking" routing information from one LSA to another, but it=20 > is not flooding that=20 > information.=20 Right, we will clarify. >=20 > If you are saying that ABSOLUTELY NO TE information may be=20 > exchanged between areas, then I wonder how an ingress LSR can=20 > know the reachability to the egress (let alone the=20 > availability of suitable paths) when areas have more than one=20 > ABR. (Note that TE addresses are not necessarily routable!) No, we are not saying that. What we only want to preclude is the leaking = of=20 TE information related to bandwidth availability, including summarized = TE information because this definitely does not scale: Let's assume that there are N distinct paths from ABR A to a destination = X, each with a distinct bandwidth and distinct admin-group (a path admin group being expressed as a logical = AND of the link admin groups along the path) How can you summarize such topology ? Actually you need to advertise N = virtual links, each with a distinct admin-group and available bandwidth. Note that in return, we don't preclude the leaking of static TE = information related to LSR properties (such as PCE capabilities, TE = router ids...), Provided that there is no impact on the IGP. We are going to clarify that in next revision (01 posted next week)), = and your comments are highly welcome. =20 >=20 > I would have a problem with the requirements draft if it is=20 > precluding ALL exchange of TE information between areas. A=20 > more appropriate requirement would describe scalability and=20 > impact on existing operation of routing protocols, but would=20 > not constrain the solution in this way.=20 >=20 Yes this would be an approach, but as we consider that TE summarization = does not scale what about not precluding it directly in the requirement draft ? Note that this is a strong requirement expressed by 6 distinct ISPs. > . . . . .=20 >=20 > Can you tell me the status of this draft? Is it still alive=20 > in the TEWG? Is TEWG working on it? When is it scheduled to=20 > be completed?=20 This is a WG document of the TEWG, it was approved in March and TEWG is = still working on it. Cheers, JL >=20 > Thanks, > Adrian >=20 From owner-ccamp@ops.ietf.org Fri Apr 23 14:58:15 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28220 for ; Fri, 23 Apr 2004 14:58:15 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH5sO-0001xg-LZ for ccamp-archive@ietf.org; Fri, 23 Apr 2004 14:58:16 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH5om-0000we-00 for ccamp-archive@ietf.org; Fri, 23 Apr 2004 14:54:33 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BH5mO-00009w-00 for ccamp-archive@ietf.org; Fri, 23 Apr 2004 14:52:04 -0400 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BH5cp-0001Ol-B9 for ccamp-data@psg.com; Fri, 23 Apr 2004 18:42:11 +0000 Received: from [169.144.68.6] (helo=mailgate.pit.comms.marconi.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BH5co-0001OY-87 for ccamp@ops.ietf.org; Fri, 23 Apr 2004 18:42:10 +0000 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id i3NIg7QG029066; Fri, 23 Apr 2004 14:42:07 -0400 (EDT) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA11432; Fri, 23 Apr 2004 14:42:06 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Fri, 23 Apr 2004 14:42:06 -0400 Message-ID: <39469E08BD83D411A3D900204840EC55FB7262@vie-msgusr-01.dc.fore.com> From: "Naidu, Venkata" To: "'adrian@olddog.co.uk'" , ospf@peach.ease.lsoft.com, ccamp@ops.ietf.org, "Naidu, Venkata" Subject: RE: OSPF TLVs Date: Fri, 23 Apr 2004 14:41:59 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Adrain, -> > We have two cases here: -> > -> > 1. Actual (Value) length carried in a TLV is explicit by the -> > "Length" field. In this case, padding/reserved space is -> > implicitly ignored based on next boundary math (here 32-bit) -> > if any, so that parser jump to next TLV with out ambiguity. -> -> No. This is NOT what 3630 says. -> 3630 says that if a TLV is not a multiple of 32-bits, -> padding is inserted -> between it and the next TLV. -> It does not comment on the contents of the TLV. -> For example, if a TLV had five reserved bytes at the end, we -> would not -> modify this so that it had only one reserved byte. -> In other words, the contents of the TLV are opaque to the -> TLV packing rules. -> The length field specifies the length of the V without -> saying anything about -> the format of the data in the V. All packing can be -> performed using the -> length field. -> -> > 2. Actual (Value) length carried in a TLV is implicit by the -> > "Type" field. In this case, the "Length" field signifies -> > total (actual + pad/reserved). So that, parser can jump -> > to next TLV with out ambiguity. -> > -> > I thought, (1) is what followed by TE community. I think, -> > you are supporting (2). -> -> I am? -> Length may be defined by type (with respect to -> documentation), but it is not -> implicit. -> That is, the length field ALWAYS gives the length of the V field. -> If the V field contains explicit padding or reserved bits, -> they are included -> in the length. If V field contains explicit padding/reserve bits, the current value length must be known some how (mostly implicit by the type field). That is what I am saying. Let us come to a consensus. Let me know we are on same page or not based on below diagram: RFC 3630 section 2.3.2. TLV Header 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value... | . . . . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Length field defines the length of the value portion in octets (thus a TLV with no value portion would have a length of zero). The TLV is padded to four-octet alignment; padding is not included in the length field (so a three octet value would have a length of three, but the total size of the TLV would be eight octets). [Start Modification] 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value Current... | . . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . Value Reserved... . . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . | Pad ... (0-3 octet) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Length field defines the length of the value portion (current + reserved) in octets. Length of current value portion is implicit by the type field. The TLV is padded to four-octet alignment; padding is not included in the length field (so a three octet value would have a length of three, but the total size of the TLV would be eight octets). [End Modification] Venkata. From owner-ccamp@ops.ietf.org Fri Apr 23 15:54:36 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05254 for ; Fri, 23 Apr 2004 15:54:36 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH6kv-0002H3-BK for ccamp-archive@ietf.org; Fri, 23 Apr 2004 15:54:37 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH6jc-0001xX-00 for ccamp-archive@ietf.org; Fri, 23 Apr 2004 15:53:17 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BH6iW-0001cf-00 for ccamp-archive@ietf.org; Fri, 23 Apr 2004 15:52:08 -0400 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BH6Su-000Edw-2x for ccamp-data@psg.com; Fri, 23 Apr 2004 19:36:00 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BH6Ss-000EdH-Jd for ccamp@ops.ietf.org; Fri, 23 Apr 2004 19:35:58 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03379; Fri, 23 Apr 2004 15:35:55 -0400 (EDT) Message-Id: <200404231935.PAA03379@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-gmpls-egress-control-01.txt Date: Fri, 23 Apr 2004 15:35:55 -0400 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --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 : GMPLS Signaling Procedure For Egress Control Author(s) : L. Berger Filename : draft-ietf-ccamp-gmpls-egress-control-01.txt Pages : 6 Date : 2004-4-23 This note clarifies the procedures for the control of the label used on output/downstream interface of the egress node of a Label Switched Path (LSP). Such control is also known as "Egress Control". Support for Egress Control is implicit in Generalized Multi-Protocol Label Switching (GMPLS) Signaling. This note does not modify GMPLS signaling mechanisms and procedures and should be viewed as an informative clarification of GMPLS Signaling - Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-egress-control-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-gmpls-egress-control-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-gmpls-egress-control-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: <2004-4-23150455.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-gmpls-egress-control-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-gmpls-egress-control-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-4-23150455.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ccamp@ops.ietf.org Fri Apr 23 23:06:36 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01229 for ; Fri, 23 Apr 2004 23:06:35 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BHDUx-0002Ty-J9 for ccamp-archive@ietf.org; Fri, 23 Apr 2004 23:06:35 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BHDT1-00020f-00 for ccamp-archive@ietf.org; Fri, 23 Apr 2004 23:04:36 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BHDS0-0001kQ-00 for ccamp-archive@ietf.org; Fri, 23 Apr 2004 23:03:33 -0400 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BHDFB-000MEj-8S for ccamp-data@psg.com; Sat, 24 Apr 2004 02:50:17 +0000 Received: from [12.146.0.143] (helo=cabo.sycamorenet.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BHDFA-000MEV-Ap for ccamp@ops.ietf.org; Sat, 24 Apr 2004 02:50:16 +0000 Received: by cabo.sycamorenet.com with Internet Mail Service (5.5.2653.19) id <26ZJDXL4>; Fri, 23 Apr 2004 22:54:09 -0400 Message-ID: <5533E74FC0108E41A8217C0899CA56CF081E1B@mach5.sycamorenet.com> From: "Pandian, Vijay" To: ccamp@ops.ietf.org Subject: Routing and signaling across devices with different switching cap abilities Date: Fri, 23 Apr 2004 22:54:03 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Consider a mix of devices with varying switching capabilities connected as follows: PSC-1 <===> TDM-1 <===> LSC-1 <===> FSC <===> LSC-2 <===> TDM-2 <===> PSC-2 Is it fair to assume that PSC-1 and PSC-2 would advertise TE-LSA's with "PSC" as the switching capability, TDM-1 and TDM-2 would advertise TE-LSA's with "TDM" as the switching capability, LSC-1 and LSC-2 would advertise TE-LSA's with "LSC" as the switching capability...? Given this, would the PSC device (say PSC-1) be able to compute a path using CSPF to PSC-2? There had been some discussion regarding the type of label (SUKLM vs. lambda vs. port) to be used across these switching capabilities. How about the "LSP-Enc. Type", and "Switching Type" in the Generalized Label Request Object? How about the Bandwidth Encoding in the SENDER_TSPEC and FLOWSPEC object? According to rfc3471, section 3.1.1, the switching type is expected to map to one of the values advertised for the corresponding link. In that case, would the LSC-device accept a Generalized Label Request with TDM switching capability and "port" as the label coming from the TDM capable device? Any clarification on this is appreciated... Thanks, Vijay PS: During various GMPLS interop events, an additional FSC (and LSC?) switching capability in the TE-LSA's was required for the end devices to compute path. From owner-ccamp@ops.ietf.org Sat Apr 24 08:47:08 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12908 for ; Sat, 24 Apr 2004 08:47:07 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BHMYm-0003MZ-IX for ccamp-archive@ietf.org; Sat, 24 Apr 2004 08:47:08 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BHMXp-00036f-00 for ccamp-archive@ietf.org; Sat, 24 Apr 2004 08:46:09 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BHMXR-0002qB-00 for ccamp-archive@ietf.org; Sat, 24 Apr 2004 08:45:45 -0400 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BHM9a-00048B-60 for ccamp-data@psg.com; Sat, 24 Apr 2004 12:21:06 +0000 Received: from [62.23.212.165] (helo=smail.alcatel.fr) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BHM9Y-00047j-Qa for ccamp@ops.ietf.org; Sat, 24 Apr 2004 12:21:05 +0000 Received: from bemail05.netfr.alcatel.fr (bemail05.netfr.alcatel.fr [155.132.251.11]) by smail.alcatel.fr (ALCANET/NETFR) with ESMTP id i3O8G50O002793; Sat, 24 Apr 2004 10:16:05 +0200 Received: from alcatel.be ([138.203.118.2]) by bemail05.netfr.alcatel.fr (Lotus Domino Release 5.0.11) with ESMTP id 2004042410160405:705 ; Sat, 24 Apr 2004 10:16:04 +0200 Message-ID: <408A22B5.6020801@alcatel.be> Date: Sat, 24 Apr 2004 10:17:57 +0200 From: Dimitri.Papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.5) Gecko/20030925 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Pandian, Vijay" CC: ccamp@ops.ietf.org Subject: Re: Routing and signaling across devices with different switching cap abilities References: <5533E74FC0108E41A8217C0899CA56CF081E1B@mach5.sycamorenet.com> In-Reply-To: <5533E74FC0108E41A8217C0899CA56CF081E1B@mach5.sycamorenet.com> X-MIMETrack: Itemize by SMTP Server on BEMAIL05/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 04/24/2004 10:16:04, Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 04/24/2004 10:16:05, Serialize complete at 04/24/2004 10:16:05 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed X-Alcanet-MTA-scanned-and-authorized: yes Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,LINES_OF_YELLING, NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit hi, Pandian, Vijay wrote: > Consider a mix of devices with varying switching capabilities connected as > follows: > > PSC-1 <===> TDM-1 <===> LSC-1 <===> FSC <===> LSC-2 <===> TDM-2 <===> > PSC-2 > > Is it fair to assume that PSC-1 and PSC-2 would advertise TE-LSA's with > "PSC" as the switching capability, TDM-1 and TDM-2 would advertise TE-LSA's > with "TDM" as the switching capability, LSC-1 and LSC-2 would advertise > TE-LSA's with "LSC" as the switching capability...? what "fair" means in this context ? further the hierarchy refers to region boundaries as follows: PSC-1 < PSC-2 < PSC-3 < PSC-4 < L2SC < TDM < LSC < FSC so assuming you're using different values (non-reported in gmpls- routing see below) for TDM and LSC, GMPLS mandates that for inst. you're crossing region boundary at [TDM,LSC] the LSR at the edge of the TDM region must capable to find [LSC,TDM], and if such boundary doesn't exist it is fair to assume that the LSP will not be established - note that we've specific values for L2SC (51), TDM (100), LSC (150) and FSC (200) so what are you inferring with TDM-1 and TDM-2 ? > Given this, would the PSC device (say PSC-1) be able to compute a path using > CSPF to PSC-2? well why don't you use the value defined in gmpls-routing, instead of trying to assess a rule for SC relationship that doesn't exist ? > There had been some discussion regarding the type of label (SUKLM vs. lambda > vs. port) to be used across these switching capabilities. How about the > "LSP-Enc. Type", and "Switching Type" in the Generalized Label Request > Object? How about the Bandwidth Encoding in the SENDER_TSPEC and FLOWSPEC > object? what's more precisely the question here ? > According to rfc3471, section 3.1.1, the switching type is expected to map > to one of the values advertised for the corresponding link. In that case, > would the LSC-device accept a Generalized Label Request with TDM switching > capability and "port" as the label coming from the TDM capable device? i think we've sorted out this issue, during our previous discussion, and the response is "the LSC interface accepts a Generalized Label Request with LSC switching capability and "port" as the label coming from the TDM capable device" i guess you mean when crossing the [TDM,LSC] boundary > Any clarification on this is appreciated... > > Thanks, > > Vijay > > PS: During various GMPLS interop events, an additional FSC (and LSC?) > switching capability in the TE-LSA's was required for the end devices to > compute path. yes, because some people didn't quite accurately translated the term "port" in their implementation ("port" =/= "physical port" such as a fiber), but as discussed this is erroneous hope this clarifies, - dimitri. -- Papadimitriou Dimitri E-mail : dimitri.papadimitriou@alcatel.be E-mail : dpapadimitriou@psg.com Webpage: http://psg.com/~dpapadimitriou/ Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium Phone : +32 3 240-8491 From owner-ccamp@ops.ietf.org Sat Apr 24 21:57:25 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18504 for ; Sat, 24 Apr 2004 21:57:25 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BHYtZ-0007hy-PB for ccamp-archive@ietf.org; Sat, 24 Apr 2004 21:57:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BHYsb-0007UP-00 for ccamp-archive@ietf.org; Sat, 24 Apr 2004 21:56:26 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BHYrb-0007Cn-00 for ccamp-archive@ietf.org; Sat, 24 Apr 2004 21:55:23 -0400 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BHYbV-000Aom-Qy for ccamp-data@psg.com; Sun, 25 Apr 2004 01:38:45 +0000 Received: from [12.146.0.143] (helo=cabo.sycamorenet.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BHYbU-000AoY-Lw for ccamp@ops.ietf.org; Sun, 25 Apr 2004 01:38:44 +0000 Received: by cabo.sycamorenet.com with Internet Mail Service (5.5.2653.19) id <26ZJ1CX9>; Sat, 24 Apr 2004 21:42:52 -0400 Message-ID: <5533E74FC0108E41A8217C0899CA56CF081E1C@mach5.sycamorenet.com> From: "Pandian, Vijay" To: "'Dimitri.Papadimitriou@alcatel.be'" , "Pandian, Vijay" Cc: ccamp@ops.ietf.org Subject: RE: Routing and signaling across devices with different switching cap abilities Date: Sat, 24 Apr 2004 21:42:51 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Dimitri, Sorry for not being very clear with my previous e-mail. Let me re-phrase my question with a different picture: OC-48 OC-192 NxOC-192 NxOC-192 OC-192 OC-48 R1 <-----> S1 <------> L1 <--------> FX <--------> L2 <------> S2 <-----> R2 PSC-1 TDM LSC FSC LSC TDM PSC-1 OC-48 <-----> TE-Links R1 and R2 are routers that advertise TE-LSA's with PSC-1 as the Switching Capability (SC) for the TE-Links to S1 and S2. S1 and S2 are two High Order (at STS-1/STM-0 level) grooming switches that are in-capable of transparently switching a port/lambda (i.e., Section and Line OH bytes are terminated and re-generated). S1 and S2 thus advertise TE-LSA's with TDM as the SC for all their TE-Links in this picture. L1 and L2 are two OXC's that advertise TE-LSA's with LSC as the SC for all their TE-Links in this picture. FX is a PXC that advertise TE-LSA's with FSC as the SC for its TE-Links in this picture. This should be a valid configuration, right? Do we need any additional SC's in the TE-LSA's? Given this combination of TE-LSA's, will R1 be able to compute a path to R2? If R1 could successfully compute a PATH, what is the expected "LSP-Enc. Type", and "Switching Type" in the Generalized Label Request Object for each LINK? R1 ---> S1: SDH/SONET(5) and TDM (100) with "timeslot" as the label? S1 ---> L1: Lambda(8) and LSC(150) with "port" as the label? L1 ---> FX: Fiber(9) and FSC(200) with "port" as the label? FX ---> L2: Fiber(9) and FSC(200) with "port" as the label? L2 ---> S2: Lambda(8) and LSC(150) with "port" as the label? S2 ---> R2: SDH/SONET(5) and TDM (100) with "timeslot" as the label? How about the G-PID? Does it change as well? How about the Bandwidth Encoding? R1 may ask for an OC-48. Assume S1 is incapable of supporting FA-LSP, can the Bandwidth remain as OC-48 for the S1 ---> L1 Link? Thanks, Vijay > -----Original Message----- > From: Dimitri.Papadimitriou@alcatel.be > [mailto:Dimitri.Papadimitriou@alcatel.be] > Sent: Saturday, April 24, 2004 4:18 AM > To: Pandian, Vijay > Cc: ccamp@ops.ietf.org > Subject: Re: Routing and signaling across devices with different > switching cap abilities > > > hi, > > Pandian, Vijay wrote: > > Consider a mix of devices with varying switching > capabilities connected as > > follows: > > > > PSC-1 <===> TDM-1 <===> LSC-1 <===> FSC <===> LSC-2 > <===> TDM-2 <===> > > PSC-2 > > > > Is it fair to assume that PSC-1 and PSC-2 would advertise > TE-LSA's with > > "PSC" as the switching capability, TDM-1 and TDM-2 would > advertise TE-LSA's > > with "TDM" as the switching capability, LSC-1 and LSC-2 > would advertise > > TE-LSA's with "LSC" as the switching capability...? > > what "fair" means in this context ? further the hierarchy refers > to region boundaries as follows: > > PSC-1 < PSC-2 < PSC-3 < PSC-4 < L2SC < TDM < LSC < FSC > > so assuming you're using different values (non-reported in gmpls- > routing see below) for TDM and LSC, GMPLS mandates that for inst. > you're crossing region boundary at [TDM,LSC] the LSR at the edge > of the TDM region must capable to find [LSC,TDM], and if such > boundary doesn't exist it is fair to assume that the LSP will not > be established - note that we've specific values for L2SC (51), > TDM (100), LSC (150) and FSC (200) so what are you inferring with > TDM-1 and TDM-2 ? > > > Given this, would the PSC device (say PSC-1) be able to > compute a path using > > CSPF to PSC-2? > > well why don't you use the value defined in gmpls-routing, instead > of trying to assess a rule for SC relationship that doesn't exist ? > > > There had been some discussion regarding the type of label > (SUKLM vs. lambda > > vs. port) to be used across these switching capabilities. > How about the > > "LSP-Enc. Type", and "Switching Type" in the Generalized > Label Request > > Object? How about the Bandwidth Encoding in the > SENDER_TSPEC and FLOWSPEC > > object? > > what's more precisely the question here ? > > > According to rfc3471, section 3.1.1, the switching type is > expected to map > > to one of the values advertised for the corresponding link. > In that case, > > would the LSC-device accept a Generalized Label Request > with TDM switching > > capability and "port" as the label coming from the TDM > capable device? > > i think we've sorted out this issue, during our previous discussion, > and the response is "the LSC interface accepts a Generalized Label > Request with LSC switching capability and "port" as the label coming > from the TDM capable device" i guess you mean when crossing the > [TDM,LSC] boundary > > > Any clarification on this is appreciated... > > > > Thanks, > > > > Vijay > > > > PS: During various GMPLS interop events, an additional FSC > (and LSC?) > > switching capability in the TE-LSA's was required for the > end devices to > > compute path. > > yes, because some people didn't quite accurately translated the term > "port" in their implementation ("port" =/= "physical port" such as a > fiber), but as discussed this is erroneous > > hope this clarifies, > - dimitri. > -- > Papadimitriou Dimitri > E-mail : dimitri.papadimitriou@alcatel.be > E-mail : dpapadimitriou@psg.com > Webpage: http://psg.com/~dpapadimitriou/ > Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium > Phone : +32 3 240-8491 > > From owner-ccamp@ops.ietf.org Sun Apr 25 12:53:08 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05367 for ; Sun, 25 Apr 2004 12:53:08 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BHmsQ-00013f-EE for ccamp-archive@ietf.org; Sun, 25 Apr 2004 12:53:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BHmrY-0000r4-00 for ccamp-archive@ietf.org; Sun, 25 Apr 2004 12:52:17 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BHmqk-0000dw-00 for ccamp-archive@ietf.org; Sun, 25 Apr 2004 12:51:26 -0400 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BHmdJ-0007RU-7Z for ccamp-data@psg.com; Sun, 25 Apr 2004 16:37:33 +0000 Received: from [63.102.55.206] (helo=lightwave.chromisys.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BHmdG-0007RA-2D for ccamp@ops.ietf.org; Sun, 25 Apr 2004 16:37:30 +0000 Received: by lightwave.chromisys.com with Internet Mail Service (5.5.2653.19) id ; Sun, 25 Apr 2004 09:37:26 -0700 Message-ID: <9D42C6E086250248810DCADA39CE7EFC017AD7C4@nimbus.chromisys.com> From: John Drake To: "Pandian, Vijay" , "'Dimitri.Papadimitriou@alcatel.be'" Cc: ccamp@ops.ietf.org Subject: RE: Routing and signaling across devices with different switching cap abilities Date: Sun, 25 Apr 2004 09:37:24 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Vijay, I'd suggest that you study http://www.calient.net/files/IEEEGMPLSpublished.pdf Thanks, John > -----Original Message----- > From: Pandian, Vijay [mailto:Vijay.Pandian@sycamorenet.com] > Sent: Saturday, April 24, 2004 6:43 PM > To: 'Dimitri.Papadimitriou@alcatel.be'; Pandian, Vijay > Cc: ccamp@ops.ietf.org > Subject: RE: Routing and signaling across devices with different switching > cap abilities > > Dimitri, > > Sorry for not being very clear with my previous e-mail. > > Let me re-phrase my question with a different picture: > > OC-48 OC-192 NxOC-192 NxOC-192 OC-192 OC- > 48 > R1 <-----> S1 <------> L1 <--------> FX <--------> L2 <------> S2 <---- > -> > R2 > PSC-1 TDM LSC FSC LSC TDM > PSC-1 > > > OC-48 > <-----> TE-Links > > > R1 and R2 are routers that advertise TE-LSA's with PSC-1 as the Switching > Capability (SC) for the TE-Links to S1 and S2. > > S1 and S2 are two High Order (at STS-1/STM-0 level) grooming switches that > are in-capable of transparently switching a port/lambda (i.e., Section and > Line OH bytes are terminated and re-generated). S1 and S2 thus advertise > TE-LSA's with TDM as the SC for all their TE-Links in this picture. > > L1 and L2 are two OXC's that advertise TE-LSA's with LSC as the SC for all > their TE-Links in this picture. > > FX is a PXC that advertise TE-LSA's with FSC as the SC for its TE-Links in > this picture. > > This should be a valid configuration, right? Do we need any additional > SC's > in the TE-LSA's? > > Given this combination of TE-LSA's, will R1 be able to compute a path to > R2? > > If R1 could successfully compute a PATH, what is the expected "LSP-Enc. > Type", and "Switching Type" in the Generalized Label Request Object for > each > LINK? > > R1 ---> S1: SDH/SONET(5) and TDM (100) with "timeslot" as the label? > > S1 ---> L1: Lambda(8) and LSC(150) with "port" as the label? > > L1 ---> FX: Fiber(9) and FSC(200) with "port" as the label? > > FX ---> L2: Fiber(9) and FSC(200) with "port" as the label? > > L2 ---> S2: Lambda(8) and LSC(150) with "port" as the label? > > S2 ---> R2: SDH/SONET(5) and TDM (100) with "timeslot" as the label? > > How about the G-PID? Does it change as well? > > How about the Bandwidth Encoding? R1 may ask for an OC-48. Assume S1 is > incapable of supporting FA-LSP, can the Bandwidth remain as OC-48 for the > S1 > ---> L1 Link? > > Thanks, > > Vijay > > > -----Original Message----- > > From: Dimitri.Papadimitriou@alcatel.be > > [mailto:Dimitri.Papadimitriou@alcatel.be] > > Sent: Saturday, April 24, 2004 4:18 AM > > To: Pandian, Vijay > > Cc: ccamp@ops.ietf.org > > Subject: Re: Routing and signaling across devices with different > > switching cap abilities > > > > > > hi, > > > > Pandian, Vijay wrote: > > > Consider a mix of devices with varying switching > > capabilities connected as > > > follows: > > > > > > PSC-1 <===> TDM-1 <===> LSC-1 <===> FSC <===> LSC-2 > > <===> TDM-2 <===> > > > PSC-2 > > > > > > Is it fair to assume that PSC-1 and PSC-2 would advertise > > TE-LSA's with > > > "PSC" as the switching capability, TDM-1 and TDM-2 would > > advertise TE-LSA's > > > with "TDM" as the switching capability, LSC-1 and LSC-2 > > would advertise > > > TE-LSA's with "LSC" as the switching capability...? > > > > what "fair" means in this context ? further the hierarchy refers > > to region boundaries as follows: > > > > PSC-1 < PSC-2 < PSC-3 < PSC-4 < L2SC < TDM < LSC < FSC > > > > so assuming you're using different values (non-reported in gmpls- > > routing see below) for TDM and LSC, GMPLS mandates that for inst. > > you're crossing region boundary at [TDM,LSC] the LSR at the edge > > of the TDM region must capable to find [LSC,TDM], and if such > > boundary doesn't exist it is fair to assume that the LSP will not > > be established - note that we've specific values for L2SC (51), > > TDM (100), LSC (150) and FSC (200) so what are you inferring with > > TDM-1 and TDM-2 ? > > > > > Given this, would the PSC device (say PSC-1) be able to > > compute a path using > > > CSPF to PSC-2? > > > > well why don't you use the value defined in gmpls-routing, instead > > of trying to assess a rule for SC relationship that doesn't exist ? > > > > > There had been some discussion regarding the type of label > > (SUKLM vs. lambda > > > vs. port) to be used across these switching capabilities. > > How about the > > > "LSP-Enc. Type", and "Switching Type" in the Generalized > > Label Request > > > Object? How about the Bandwidth Encoding in the > > SENDER_TSPEC and FLOWSPEC > > > object? > > > > what's more precisely the question here ? > > > > > According to rfc3471, section 3.1.1, the switching type is > > expected to map > > > to one of the values advertised for the corresponding link. > > In that case, > > > would the LSC-device accept a Generalized Label Request > > with TDM switching > > > capability and "port" as the label coming from the TDM > > capable device? > > > > i think we've sorted out this issue, during our previous discussion, > > and the response is "the LSC interface accepts a Generalized Label > > Request with LSC switching capability and "port" as the label coming > > from the TDM capable device" i guess you mean when crossing the > > [TDM,LSC] boundary > > > > > Any clarification on this is appreciated... > > > > > > Thanks, > > > > > > Vijay > > > > > > PS: During various GMPLS interop events, an additional FSC > > (and LSC?) > > > switching capability in the TE-LSA's was required for the > > end devices to > > > compute path. > > > > yes, because some people didn't quite accurately translated the term > > "port" in their implementation ("port" =/= "physical port" such as a > > fiber), but as discussed this is erroneous > > > > hope this clarifies, > > - dimitri. > > -- > > Papadimitriou Dimitri > > E-mail : dimitri.papadimitriou@alcatel.be > > E-mail : dpapadimitriou@psg.com > > Webpage: http://psg.com/~dpapadimitriou/ > > Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium > > Phone : +32 3 240-8491 > > > > From owner-ccamp@ops.ietf.org Sun Apr 25 20:53:43 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27231 for ; Sun, 25 Apr 2004 20:53:43 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BHuNT-0005I6-9Y for ccamp-archive@ietf.org; Sun, 25 Apr 2004 20:53:43 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BHuMe-00052L-00 for ccamp-archive@ietf.org; Sun, 25 Apr 2004 20:52:52 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BHuLf-0004nl-02 for ccamp-archive@ietf.org; Sun, 25 Apr 2004 20:51:51 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by mx2.foretec.com with esmtp (Exim 4.24) id 1BHuAg-0004l3-OT for ccamp-archive@ietf.org; Sun, 25 Apr 2004 20:40:30 -0400 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BHtww-000FT2-U9 for ccamp-data@psg.com; Mon, 26 Apr 2004 00:26:18 +0000 Received: from [151.100.101.65] (helo=mail1.uniroma1.it) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BHtwv-000FSo-U9 for ccamp@ops.ietf.org; Mon, 26 Apr 2004 00:26:18 +0000 Received: from infocom.uniroma1.it ([151.100.55.87]) by mail1.uniroma1.it (Lotus Domino Release 6.0.3) with ESMTP id 2004042602261529-199910 ; Mon, 26 Apr 2004 02:26:15 +0200 Message-ID: <408C5733.1000708@infocom.uniroma1.it> Date: Mon, 26 Apr 2004 02:26:27 +0200 From: ugo monaco User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3.1) Gecko/20030428 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ccamp CC: Zafar Ali , Dimitri Papadimitriou Subject: Diverse path failure and optimality in draft-dachille-inter-area-path-protection X-MIMETrack: Itemize by SMTP Server on xmail1/Uniroma1/it(Release 6.0.3|September 18, 2003) at 26/04/2004 02:26:15, Serialize by Router on xmail1/Uniroma1/it(Release 6.0.3|September 18, 2003) at 26/04/2004 02:26:17, Serialize complete at 26/04/2004 02:26:17 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Dear ccamper, Zafar, Dimitri, as anticipated in the recent email by Vishal we are addressing several important comments collected at Seoul regarding the joint-selection of diverse paths with ARO, i.e. the approach proposed in . As Vishal did I summarized your comments to ensure that we rightly understood inputs, and to help people on the ML follow and contribute to the discussion. Comments from others who have feedback are welcome, and much appreciated. Please let me know if you had any additional comments as well. We will take these into account in providing our responses, and, later, in updating the document. Thanks again for your feedback on our draft during the Seoul meeting. Best Regards. Ugo Monaco +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Zafar's questions: i) What happens when the setup of the diverse path fails, or there is a failure on it after it has been set up? ii) Relationship of this scheme to PCS/PCE approach of JP? Dimitri Papadimitriou i) Your question was about why we are trying for optimality with a joint path selection scheme, when it is not possible, especially as the number of AS's or areas along a path increase, to achieve the *global* optimum. Your other comment was that we should mention this somewhere in the document. Please note that in response to this last question Fabio Ricciato listed many advantages of a joint computation (with ARO) of inter-area/AS paths in a prevoius email posted on the ML "About optimality of inter-AS parallel computation in draft-dachille-inter-area-path-protection". We hope that Fabio rightly addressed your input and we will appreciate further comments and notes. From owner-ccamp@ops.ietf.org Sun Apr 25 20:53:44 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27252 for ; Sun, 25 Apr 2004 20:53:44 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BHuNU-0005IK-PX for ccamp-archive@ietf.org; Sun, 25 Apr 2004 20:53:44 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BHuMf-00052c-00 for ccamp-archive@ietf.org; Sun, 25 Apr 2004 20:52:54 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BHuLf-0004no-01 for ccamp-archive@ietf.org; Sun, 25 Apr 2004 20:51:51 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by mx2.foretec.com with esmtp (Exim 4.24) id 1BHuDN-0004p7-Os for ccamp-archive@ietf.org; Sun, 25 Apr 2004 20:43:17 -0400 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BHtw4-000FE1-5C for ccamp-data@psg.com; Mon, 26 Apr 2004 00:25:24 +0000 Received: from [151.100.101.65] (helo=mail1.uniroma1.it) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BHtw1-000FCS-Uk for ccamp@ops.ietf.org; Mon, 26 Apr 2004 00:25:22 +0000 Received: from infocom.uniroma1.it ([151.100.55.87]) by mail1.uniroma1.it (Lotus Domino Release 6.0.3) with ESMTP id 2004042602251797-199858 ; Mon, 26 Apr 2004 02:25:17 +0200 Message-ID: <408C56F9.8010402@infocom.uniroma1.it> Date: Mon, 26 Apr 2004 02:25:29 +0200 From: ugo monaco User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3.1) Gecko/20030428 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ccamp CC: Adrian Farrel Subject: Security issues and egress-driven path comput in draft-dachille-inter-area-path-protection X-MIMETrack: Itemize by SMTP Server on xmail1/Uniroma1/it(Release 6.0.3|September 18, 2003) at 26/04/2004 02:25:19, Serialize by Router on xmail1/Uniroma1/it(Release 6.0.3|September 18, 2003) at 26/04/2004 02:25:21, Serialize complete at 26/04/2004 02:25:21 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Dear ccampers, Adrian, as anticipated in the recent email by Vishal we are addressing several important comments collected at Seoul regarding the joint-selection of diverse paths with ARO, i.e. the approach proposed in . As mentioned by Vishal I summarized your comments to ensure that we rightly understood inputs, and to help people on the ML follow and contribute to the discussion. Comments from others who have feedback are welcome, and much appreciated. Please let me know if you had any additional comments as well. We will take these into account in providing our responses, and, later, in updating the document. Thanks again for your feedback on our draft during the Seoul meeting. Best Regards. Ugo Monaco +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ i) Security issue of intra-area/AS specific information across areas/ASs. The problem is that ARO could provide private intra-area information outside the area/AS. ii) You asked if our proposed scheme could be modified to have the path for the secondary be computed when the Resv for the primary arrives at the border router of each area/AS? This might allow the egress node (and subsequently the exit node at each previous area/AS) to choose the entry point for the secondary into that area/AS. For example, refer to the attached figure. Consider a linear topology of ASs from AS(1), the source AS, to AS(3), the destination AS. Denote by I(k) and E(k), respectively, the ingress and egress nodes to AS(k). Where needed, the ingress of the primary and secondary path, will be respectively referred to by I1(k) and I2(k) and same for th egress nodes (i.e., E1(k), E2(k)). Your point was that by computing the path in the forward direction, the entry of the secondary path into Area 3 might be I2(3), where as the egress Z may have preferred that it be "Y". By computing things in the reverse direction, one would give the egress the flexibility to choose that entry point, and it could therefore choose "Y". But this way, the exit point at the previous area should be fixed to "X". Area 1 Area 2 Area 3 +----------+ +-----------+ +----------+ I(1)/+\ /+\-----------/+\ E1(2)/+\-----------/+\I1(3) | | | | | | | | | | | | /+\ E(3) | | | | | | | /+-------------+\ E2(2)/+\-----------/+\I2(3) | | | | + | | | | | X /+\xxxxxxxxxxx/+\ Y | +----------+ +-----------+ +----------+ Please note that some details and comments dealing with this "egress-driven selection" have been collected in a previous email posted by Fabio Ricciato on the ML "About egress-influenced path computation in draft-dachille-inter-area-path-protection". Further comments and notes on this issue are welcome. iii) You asked also info. about how ARO relates to the following objects: --- S-ERO, proposed in the draft dealing with setting up p2mp tunnels for multicast (on which you are a co-author); --- Primary Path Route Obj (PPRO) in the e2e protection draft (draft- lang-recovery-e2e, which is now draft-ietf-ccamp-recovery-e2e). iv) Your other question was, how does one select inter-area or inter-AS links when there is dense connectivity between them? Again, referring to the attached figure, if there are multiple choices to get from one area/AS to another, how does the scheme pick one of them? From owner-ccamp@ops.ietf.org Sun Apr 25 22:23:25 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA01454 for ; Sun, 25 Apr 2004 22:23:25 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BHvmI-0000SS-Et for ccamp-archive@ietf.org; Sun, 25 Apr 2004 22:23:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BHvlJ-0000Ht-00 for ccamp-archive@ietf.org; Sun, 25 Apr 2004 22:22:26 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BHvkS-00007d-00 for ccamp-archive@ietf.org; Sun, 25 Apr 2004 22:21:32 -0400 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BHvaS-000B2h-1H for ccamp-data@psg.com; Mon, 26 Apr 2004 02:11:12 +0000 Received: from [192.128.134.71] (helo=kcmso2.proxy.att.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BHvaQ-000B2S-VN for ccamp@ops.ietf.org; Mon, 26 Apr 2004 02:11:11 +0000 Received: from attrh5i.attrh.att.com ([135.38.62.12]) by kcmso2.proxy.att.com (AT&T IPNS/MSO-5.0) with ESMTP id i3Q2B9XS029508 for ; Sun, 25 Apr 2004 21:11:10 -0500 Received: from kcclust06evs1.ugd.att.com (135.38.164.88) by attrh5i.attrh.att.com (6.5.032) id 4082A75C0019660E for ccamp@ops.ietf.org; Sun, 25 Apr 2004 22:10:30 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6489.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: FW: I-D ACTION:draft-ietf-ccamp-gmpls-ason-routing-reqts-03.txt Date: Sun, 25 Apr 2004 21:11:09 -0500 Message-ID: <9473683187ADC049A855ED2DA739ABCA0201F147@KCCLUST06EVS1.ugd.att.com> Thread-Topic: FW: I-D ACTION:draft-ietf-ccamp-gmpls-ason-routing-reqts-03.txt Thread-Index: AcQieu4bHN0af3IZRtydwrnnsEwwEgFXa++AAAb/T8AAxHnOEAAK5hCw From: "Ash, Gerald R (Jerry), ALABS" To: Cc: "Ash, Gerald R (Jerry), ALABS" Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable I have a couple of comments: 1. I'm bothered by the statement in Section 3: "The maximum number of hierarchical RA levels to be supported is NOT = specified (outside the scope)." Why is it outside the scope, I think there should be some explanation. = Does the number of levels not matter? Is one level (i.e., flat network, = no hierarchy at all) OK? I would much prefer to have the maximum number = of required hierarchical levels stated in the draft. 2. There is quite a bit of discussion about hierarchy evolution, e.g., = in Section 3: "- The requirements support architectural evolution, e.g. a change in = the number of RA levels, as well as aggregation and segmentation of = RAs." This begins to suggest automatic 'insertion/deletion' of hierarchical = levels, which I believe is too complex. However, I find in Section 4.4: "The routing protocol SHOULD be capable of supporting architectural = evolution in terms of number of hierarchical levels of RAs, as well as = aggregation and segmentation of RAs. RA IDs uniqueness within an = administrative domain MAY facilitate these operations. The routing = protocol is not expected to automatically initiate and/or execute these = operations." It is the final "not" that says that automatic insertion/deletion is not = required within the protocol. Perhaps this NOT should be capitalized = for emphasis. 3. Regarding Adrian's comment on the text I referenced in comment #2: "The routing protocol is not expected to automatically initiate and/or = execute these operations. Reconfiguration of the RA hierarchy MAY not ## Surely this is MUST? disrupt calls in progress, though calls being set up may fail to = complete, and the call setup service may be unavailable during = reconfiguration actions." I think this should stay a "MAY". In normal hierarchy reconfiguration, = calls are going to be disrupted. It is far more complex to insist = somehow that the protocol keeps calls in tact during such = reconfigurations. Thanks, Jerry -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On Behalf Of Kireeti Kompella Sent: Wednesday, April 14, 2004 7:46 PM To: ccamp@ops.ietf.org Subject: Re: FW: I-D ACTION:draft-ietf-ccamp-gmpls-ason-routing-reqts-03.txt Hi All, On Wed, 14 Apr 2004, Brungard, Deborah A, ALABS wrote: > The ASON Routing Reqts DT has updated the following draft based on > ITU Q14/15's Liaison and CCAMP mail list comments. > > We recommend this document as ready for WG Last Call. This commences a two-week WG Last Call on the GMPLS ASON routing requirements. Last Call ends April 28th, 5pm PDT. Please send your comments to the list. The proposed category is Informational. Kireeti. ------- From owner-ccamp@ops.ietf.org Sun Apr 25 23:25:28 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04299 for ; Sun, 25 Apr 2004 23:25:28 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BHwkL-0004c3-GG for ccamp-archive@ietf.org; Sun, 25 Apr 2004 23:25:29 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BHwjQ-0004PY-00 for ccamp-archive@ietf.org; Sun, 25 Apr 2004 23:24:33 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BHwiX-0004Ec-00 for ccamp-archive@ietf.org; Sun, 25 Apr 2004 23:23:37 -0400 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BHwZR-000NL1-5F for ccamp-data@psg.com; Mon, 26 Apr 2004 03:14:13 +0000 Received: from [64.102.122.148] (helo=rtp-iport-1.cisco.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BHwZQ-000NKe-67 for ccamp@ops.ietf.org; Mon, 26 Apr 2004 03:14:12 +0000 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 25 Apr 2004 20:27:31 -0700 X-BrightmailFiltered: true Received: from zaliw2k01 (che-vpn-cluster-2-33.cisco.com [10.86.242.33]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i3Q3E8Yu007186; Sun, 25 Apr 2004 23:14:08 -0400 (EDT) From: "zafar ali" To: "'Ash, Gerald R \(Jerry\), ALABS'" , Subject: RE: FW: I-D ACTION:draft-ietf-ccamp-gmpls-ason-routing-reqts-03.txt Date: Sun, 25 Apr 2004 23:14:07 -0400 Organization: Cisco Systems Message-ID: <000001c42b3c$8a503180$0300a8c0@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.5709 Importance: Normal In-Reply-To: <9473683187ADC049A855ED2DA739ABCA0201F147@KCCLUST06EVS1.ugd.att.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Hi Jerry,=20 Please see in-line. Thanks =20 Regards... Zafar >-----Original Message----- >From: owner-ccamp@ops.ietf.org=20 >[mailto:owner-ccamp@ops.ietf.org] On Behalf Of Ash, Gerald R=20 >(Jerry), ALABS >Sent: Sunday, April 25, 2004 10:11 PM >To: ccamp@ops.ietf.org >Cc: Ash, Gerald R (Jerry), ALABS >Subject: RE: FW: I-D=20 >ACTION:draft-ietf-ccamp-gmpls-ason-routing-reqts-03.txt > > >I have a couple of comments: > >1. I'm bothered by the statement in Section 3: >"The maximum number of hierarchical RA levels to be supported=20 >is NOT specified (outside the scope)." Why is it outside the=20 >scope, I think there should be some explanation. Does the=20 >number of levels not matter? Is one level (i.e., flat=20 >network, no hierarchy at all) OK? I would much prefer to have=20 >the maximum number of required hierarchical levels stated in the draft. > I would disagree here. The number varies depending on networking = scenario. Furthermore, the problem is that as soon as we start picking a number = here, we tend to imply the solution. Let's keep it as an attribute of the networking scenario. >2. There is quite a bit of discussion about hierarchy=20 >evolution, e.g., in Section 3: >"- The requirements support architectural evolution, e.g. a=20 >change in the number of RA levels, as well as aggregation and=20 >segmentation of RAs." > >This begins to suggest automatic 'insertion/deletion' of=20 >hierarchical levels, which I believe is too complex. > I agree completely. I also think complexity greatly over-weight the = benefit. From owner-ccamp@ops.ietf.org Mon Apr 26 03:23:59 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28413 for ; Mon, 26 Apr 2004 03:23:59 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BI0T9-0005iP-Hv for ccamp-archive@ietf.org; Mon, 26 Apr 2004 03:23:59 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BI0SL-0005VQ-00 for ccamp-archive@ietf.org; Mon, 26 Apr 2004 03:23:09 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BI0Rh-0005HN-00 for ccamp-archive@ietf.org; Mon, 26 Apr 2004 03:22:29 -0400 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BI0Ey-000EMr-Io for ccamp-data@psg.com; Mon, 26 Apr 2004 07:09:20 +0000 Received: from [195.8.69.15] (helo=oceanus.uk.clara.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BI0Eu-000EMT-GU for ccamp@ops.ietf.org; Mon, 26 Apr 2004 07:09:16 +0000 Received: from claranet by oceanus.uk.clara.net with local (Exim 4.22) id 1BI0Ey-000Cp7-6V for ccamp@ops.ietf.org; Mon, 26 Apr 2004 08:09:20 +0100 From: "Adrian Farrel" To: ccamp@ops.ietf.org Reply-To: adrian@olddog.co.uk Subject: Re: draft-ali-ccamp-rsvp-node-id-based-hello-01.txt as WG document? Date: Mon, 26 Apr 2004 08:09:20 +0100 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Remote_Addr: 156.106.228.13 Message-Id: Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit OK authors, please republish as a working group draft. Please make no changes from the previous version except - check that you have all of the correct IPR boilerplate including the personal statement - check that you have the correct copyright boilerplate Thanks, Adrian From owner-ccamp@ops.ietf.org Mon Apr 26 04:01:46 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01205 for ; Mon, 26 Apr 2004 04:01:46 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BI13i-0006Oj-09 for ccamp-archive@ietf.org; Mon, 26 Apr 2004 04:01:46 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BI12p-0006Bk-00 for ccamp-archive@ietf.org; Mon, 26 Apr 2004 04:00:52 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BI11l-0005wl-00 for ccamp-archive@ietf.org; Mon, 26 Apr 2004 03:59:45 -0400 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BI0qj-000LJD-Uz for ccamp-data@psg.com; Mon, 26 Apr 2004 07:48:21 +0000 Received: from [128.130.90.21] (helo=publications.ftw.tuwien.ac.at) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BI0qi-000LIo-BM for ccamp@ops.ietf.org; Mon, 26 Apr 2004 07:48:20 +0000 Received: from nt_ftw.ftw.tuwien.ac.at by publications.ftw.tuwien.ac.at via smtpd (for psg.com [147.28.0.62]) with ESMTP; Mon, 26 Apr 2004 10:01:43 +0100 Received: from coritel.it (spirit.ftw.at [192.168.0.19]) by nt_ftw.ftw.at with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 20F8Q5M2; Mon, 26 Apr 2004 09:47:37 +0200 Message-ID: <408CBEBE.8090003@coritel.it> Date: Mon, 26 Apr 2004 09:48:14 +0200 From: ricciato User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030821 X-Accept-Language: en-us, en MIME-Version: 1.0 To: LE ROUX Jean-Louis FTRD/DAC/LAN CC: adrian@olddog.co.uk, ccamp@ops.ietf.org Subject: Re: RE : Proposed strategy for Inter-area/AS References: In-Reply-To: X-Enigmail-Version: 0.76.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Hi JL, just a quick remark: would it make sense in this case to advertise only a selected subset of the N virtual links (say the two with most residual bw) ? ciao fabio LE ROUX Jean-Louis FTRD/DAC/LAN wrote: >Let's assume that there are N distinct paths from ABR A to a destination X, each with a distinct bandwidth and >distinct admin-group (a path admin group being expressed as a logical AND of the link admin groups along the path) >How can you summarize such topology ? Actually you need to advertise N virtual links, each with a distinct admin-group and available bandwidth. > > > > > > From owner-ccamp@ops.ietf.org Mon Apr 26 04:13:52 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01742 for ; Mon, 26 Apr 2004 04:13:52 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BI1FQ-000156-I8 for ccamp-archive@ietf.org; Mon, 26 Apr 2004 04:13:52 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BI1EQ-0000s1-00 for ccamp-archive@ietf.org; Mon, 26 Apr 2004 04:12:51 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BI1Ds-0000fq-00 for ccamp-archive@ietf.org; Mon, 26 Apr 2004 04:12:16 -0400 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BI14v-000OyO-Tl for ccamp-data@psg.com; Mon, 26 Apr 2004 08:03:01 +0000 Received: from [195.8.69.15] (helo=oceanus.uk.clara.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BI14u-000Oy3-RW for ccamp@ops.ietf.org; Mon, 26 Apr 2004 08:03:01 +0000 Received: from claranet by oceanus.uk.clara.net with local (Exim 4.22) id 1BI14y-000GhB-PT; Mon, 26 Apr 2004 09:03:04 +0100 From: "Adrian Farrel" To: ccamp@ops.ietf.org Cc: adrian@olddog.co.uk Reply-To: adrian@olddog.co.uk Subject: Working Group Last Call on draft-ietf-ccamp-gmpls-egress-control-01.txt Date: Mon, 26 Apr 2004 09:03:04 +0100 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Remote_Addr: 156.106.228.13 Message-Id: Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit This email begins a two week working group last call on draft-ietf-ccamp-gmpls-egress-control-01.txt Last call will complete at 12 noon GMT on 10th May. Although this draft is essentially informational or perhaps a BCP, it will be presented as standards track updating RFC 3473. In that way it will be more easily tracked by people hunting for the relevant RFCs. Thanks, Adrian > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. > > Title : GMPLS Signaling Procedure For Egress Control > Author(s) : L. Berger > Filename : draft-ietf-ccamp-gmpls-egress-control-01.txt > Pages : 6 > Date : 2004-4-23 > > This note clarifies the procedures for the control of the label used > on output/downstream interface of the egress node of a Label Switched > Path (LSP). Such control is also known as "Egress Control". Support > for Egress Control is implicit in Generalized Multi-Protocol Label > Switching (GMPLS) Signaling. This note does not modify GMPLS > signaling mechanisms and procedures and should be viewed as an > informative clarification of GMPLS Signaling - Resource ReserVation > Protocol-Traffic Engineering (RSVP-TE) Extensions. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-egress-control-01.txt From owner-ccamp@ops.ietf.org Mon Apr 26 05:08:48 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05625 for ; Mon, 26 Apr 2004 05:08:48 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BI26a-0005Nn-DU for ccamp-archive@ietf.org; Mon, 26 Apr 2004 05:08:48 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BI25f-0005Br-00 for ccamp-archive@ietf.org; Mon, 26 Apr 2004 05:07:52 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BI25B-00050I-00 for ccamp-archive@ietf.org; Mon, 26 Apr 2004 05:07:21 -0400 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BI1qA-000881-Lt for ccamp-data@psg.com; Mon, 26 Apr 2004 08:51:50 +0000 Received: from [195.8.69.15] (helo=oceanus.uk.clara.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BI1q9-000877-1K for ccamp@ops.ietf.org; Mon, 26 Apr 2004 08:51:49 +0000 Received: from claranet by oceanus.uk.clara.net with local (Exim 4.22) id 1BI1qC-000Lsn-U2; Mon, 26 Apr 2004 09:51:52 +0100 From: "Adrian Farrel" To: ospf@peach.ease.lsoft.com, ccamp@ops.ietf.org, Venkata.Naidu@Marconi.com Cc: adrian@olddog.co.uk Reply-To: adrian@olddog.co.uk Subject: Re: OSPF TLVs Date: Mon, 26 Apr 2004 09:51:52 +0100 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Remote_Addr: 156.106.228.13 Message-Id: Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Venkata, I don't see why there is any change required. You appear to be precluding TLVs from having any length that is not a multiple of four bytes. This seems unnecessary. What we currently have is a rule that tells you how to encode a TLV into an OSPF LSA if it is not a multiple of four bytes. You have a separate rule that says that a specific TLV has some reserved bytes. Why do we need to make any changes? Further, if the length of the TLV is "implicit" we don't need to use a length field at all. There is a place for TVs, but this is not it. The only change that might be of use would be to change the name of any field that is included in a TLV from "padding" to "reserved" to avoid confusion. Perhaps the draft's authors would like to contribute to this thread. Thanks, Adrian ----- Original Message ----- From: "Naidu, Venkata" To: ; ; ; "Naidu, Venkata" Sent: Friday, April 23, 2004 7:41 PM Subject: RE: OSPF TLVs > Adrain, > > -> > We have two cases here: > -> > > -> > 1. Actual (Value) length carried in a TLV is explicit by the > -> > "Length" field. In this case, padding/reserved space is > -> > implicitly ignored based on next boundary math (here 32-bit) > -> > if any, so that parser jump to next TLV with out ambiguity. > -> > -> No. This is NOT what 3630 says. > -> 3630 says that if a TLV is not a multiple of 32-bits, > -> padding is inserted > -> between it and the next TLV. > -> It does not comment on the contents of the TLV. > -> For example, if a TLV had five reserved bytes at the end, we > -> would not > -> modify this so that it had only one reserved byte. > -> In other words, the contents of the TLV are opaque to the > -> TLV packing rules. > -> The length field specifies the length of the V without > -> saying anything about > -> the format of the data in the V. All packing can be > -> performed using the > -> length field. > -> > -> > 2. Actual (Value) length carried in a TLV is implicit by the > -> > "Type" field. In this case, the "Length" field signifies > -> > total (actual + pad/reserved). So that, parser can jump > -> > to next TLV with out ambiguity. > -> > > -> > I thought, (1) is what followed by TE community. I think, > -> > you are supporting (2). > -> > -> I am? > -> Length may be defined by type (with respect to > -> documentation), but it is not > -> implicit. > -> That is, the length field ALWAYS gives the length of the V field. > -> If the V field contains explicit padding or reserved bits, > -> they are included > -> in the length. > > If V field contains explicit padding/reserve bits, the current > value length must be known some how (mostly implicit by the type > field). That is what I am saying. > > Let us come to a consensus. Let me know we are on same page or not > based on below diagram: > > RFC 3630 section 2.3.2. TLV Header > > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Value... | > . . > . . > . . > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > The Length field defines the length of the value portion in octets > (thus a TLV with no value portion would have a length of zero). The > TLV is padded to four-octet alignment; padding is not included in the > length field (so a three octet value would have a length of three, > but the total size of the TLV would be eight octets). > > > [Start Modification] > > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Value Current... | > . . > . . > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > . Value Reserved... . > . . > . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > . | Pad ... (0-3 octet) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > The Length field defines the length of the value portion (current + > reserved) in octets. Length of current value portion is implicit by > the type field. The TLV is padded to four-octet alignment; padding > is not included in the length field (so a three octet value would > have a length of three, but the total size of the TLV would be eight > octets). > > [End Modification] > > > Venkata. > > From owner-ccamp@ops.ietf.org Mon Apr 26 09:13:02 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18510 for ; Mon, 26 Apr 2004 09:13:02 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BI5ux-0005lA-VA for ccamp-archive@ietf.org; Mon, 26 Apr 2004 09:13:04 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BI5u4-0005ib-00 for ccamp-archive@ietf.org; Mon, 26 Apr 2004 09:12:09 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BI5td-0005fL-00 for ccamp-archive@ietf.org; Mon, 26 Apr 2004 09:11:41 -0400 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BI5fu-0004iF-Ol for ccamp-data@psg.com; Mon, 26 Apr 2004 12:57:30 +0000 Received: from [195.8.69.15] (helo=oceanus.uk.clara.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BI5fl-0004hb-FB for ccamp@ops.ietf.org; Mon, 26 Apr 2004 12:57:21 +0000 Received: from claranet by oceanus.uk.clara.net with local (Exim 4.22) id 1BI5fo-000L8U-VL; Mon, 26 Apr 2004 13:57:24 +0100 From: "Adrian Farrel" To: ccamp@ops.ietf.org Cc: kireeti@juniper.net, adrian@olddog.co.uk Reply-To: adrian@olddog.co.uk Date: Mon, 26 Apr 2004 13:57:24 +0100 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Remote_Addr: 156.106.228.13 Message-Id: Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit All, The authors of this draft have updated it to reflect the comments on the mailing list and the helpful feedback from ITU-T SG15 Question 14. This email begins a two week Working Group last call on this draft. The last call will complete on 10th May at 12 noon GMT. On a point of procedure, I am an author of this draft therefore anyone who has an issue with this draft going to WG last call at this time should contact Kireeti (kireeti@juniper.net) Thanks, Adrian ----- Original Message ----- From: To: Cc: Sent: Tuesday, April 20, 2004 3:54 PM Subject: I-D ACTION:draft-ietf-ccamp-gmpls-ason-reqts-06.txt > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. > > Title : Requirements for Generalized MPLS (GMPLS) Signaling > Usage and Extensions for Automatically Switched > Optical Network (ASON) > Author(s) : D. Papadimitriou, et al. > Filename : draft-ietf-ccamp-gmpls-ason-reqts-06.txt > Pages : 14 > Date : 2004-4-19 > > The Generalized MPLS (GMPLS) suite of protocol has been defined to > control different switching technologies as well as different > applications. These include support for requesting TDM connections > including SONET/SDH and Optical Transport Networks (OTNs). > This document concentrates on the signaling aspects of the GMPLS > suite of protocols. It identifies the features to be covered by the > GMPLS signalling protocol to support the capabilities of an > Automatically Switched Optical Network (ASON). This document > provides a problem statement and additional requirements on the > GMPLS signaling protocol to support the ASON functionality. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-ason-reqts-06.txt From owner-ccamp@ops.ietf.org Mon Apr 26 09:17:08 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18688 for ; Mon, 26 Apr 2004 09:17:08 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BI5yv-00060h-QE for ccamp-archive@ietf.org; Mon, 26 Apr 2004 09:17:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BI5xu-0005uh-00 for ccamp-archive@ietf.org; Mon, 26 Apr 2004 09:16:07 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BI5ww-0005rG-00 for ccamp-archive@ietf.org; Mon, 26 Apr 2004 09:15:06 -0400 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BI5mU-0006VV-QR for ccamp-data@psg.com; Mon, 26 Apr 2004 13:04:18 +0000 Received: from [195.8.69.15] (helo=oceanus.uk.clara.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BI5mL-0006UY-Kg for ccamp@ops.ietf.org; Mon, 26 Apr 2004 13:04:09 +0000 Received: from claranet by oceanus.uk.clara.net with local (Exim 4.22) id 1BI5mP-000LpY-Ck for ccamp@ops.ietf.org; Mon, 26 Apr 2004 14:04:13 +0100 From: "Adrian Farrel" To: ccamp@ops.ietf.org Reply-To: adrian@olddog.co.uk Subject: Working Group Last Call on draft-ietf-ccamp-gmpls-ason-reqts-06.txt Date: Mon, 26 Apr 2004 14:04:13 +0100 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Remote_Addr: 156.106.228.13 Message-Id: Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Re-send with a subject line! ----- Original Message ----- From: "Adrian Farrel" To: Cc: ; Sent: Monday, April 26, 2004 1:57 PM > All, > > The authors of this draft have updated it to reflect the comments on the > mailing list and the helpful feedback from ITU-T SG15 Question 14. > > This email begins a two week Working Group last call on this draft. The > last call will complete on 10th May at 12 noon GMT. > > On a point of procedure, I am an author of this draft therefore anyone > who has an issue with this draft going to WG last call at this time > should contact Kireeti (kireeti@juniper.net) > > Thanks, > Adrian > > ----- Original Message ----- > From: > To: > Cc: > Sent: Tuesday, April 20, 2004 3:54 PM > Subject: I-D ACTION:draft-ietf-ccamp-gmpls-ason-reqts-06.txt > > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. > > > > Title : Requirements for Generalized MPLS (GMPLS) Signaling > > Usage and Extensions for Automatically Switched > > Optical Network (ASON) > > Author(s) : D. Papadimitriou, et al. > > Filename : draft-ietf-ccamp-gmpls-ason-reqts-06.txt > > Pages : 14 > > Date : 2004-4-19 > > > > The Generalized MPLS (GMPLS) suite of protocol has been defined to > > control different switching technologies as well as different > > applications. These include support for requesting TDM connections > > including SONET/SDH and Optical Transport Networks (OTNs). > > This document concentrates on the signaling aspects of the GMPLS > > suite of protocols. It identifies the features to be covered by the > > GMPLS signalling protocol to support the capabilities of an > > Automatically Switched Optical Network (ASON). This document > > provides a problem statement and additional requirements on the > > GMPLS signaling protocol to support the ASON functionality. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-ason-reqts-06.txt From owner-ccamp@ops.ietf.org Mon Apr 26 09:37:04 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19790 for ; Mon, 26 Apr 2004 09:37:03 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BI6IC-0007CE-Sh for ccamp-archive@ietf.org; Mon, 26 Apr 2004 09:37:04 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BI6HO-00079x-00 for ccamp-archive@ietf.org; Mon, 26 Apr 2004 09:36:15 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BI6Gr-00076I-00 for ccamp-archive@ietf.org; Mon, 26 Apr 2004 09:35:41 -0400 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BI67k-000AFx-Az for ccamp-data@psg.com; Mon, 26 Apr 2004 13:26:16 +0000 Received: from [171.71.176.71] (helo=sj-iport-2.cisco.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BI67j-000AFb-23 for ccamp@ops.ietf.org; Mon, 26 Apr 2004 13:26:15 +0000 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 26 Apr 2004 05:37:44 +0000 Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i3QDQBW9007020; Mon, 26 Apr 2004 06:26:12 -0700 (PDT) Received: from jvasseur-w2k01.cisco.com (che-vpn-cluster-1-61.cisco.com [10.86.240.61]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id GAA26602; Mon, 26 Apr 2004 06:26:10 -0700 (PDT) Message-Id: <4.3.2.7.2.20040426092307.04a4c740@wells.cisco.com> X-Sender: jvasseur@wells.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 26 Apr 2004 09:26:10 -0400 To: ricciato From: Jean Philippe Vasseur Subject: Re: RE : Proposed strategy for Inter-area/AS Cc: LE ROUX Jean-Louis FTRD/DAC/LAN , adrian@olddog.co.uk, ccamp@ops.ietf.org In-Reply-To: <408CBEBE.8090003@coritel.it> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Hi Fabio, At 09:48 AM 4/26/2004 +0200, ricciato wrote: >Hi JL, > >just a quick remark: would it make sense in this case to advertise only a >selected subset of the N virtual links (say the two with most residual bw) ? I do not think so ... think about all the constraints, which for some of them cannot be easily summarized (affinity), hence N becomes N*K where K might very well be a constantly increasing number. Moroever, this would require to run many CSPFs on the ABR/L1L2. JP. >ciao >fabio > >LE ROUX Jean-Louis FTRD/DAC/LAN wrote: > >>Let's assume that there are N distinct paths from ABR A to a destination >>X, each with a distinct bandwidth and >>distinct admin-group (a path admin group being expressed as a logical AND >>of the link admin groups along the path) >>How can you summarize such topology ? Actually you need to advertise N >>virtual links, each with a distinct admin-group and available bandwidth. >> >> >> >> >> > > From owner-ccamp@ops.ietf.org Mon Apr 26 10:01:51 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21076 for ; Mon, 26 Apr 2004 10:01:51 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BI6gC-0000rQ-OY for ccamp-archive@ietf.org; Mon, 26 Apr 2004 10:01:52 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BI6fI-0000p1-00 for ccamp-archive@ietf.org; Mon, 26 Apr 2004 10:00:57 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BI6eO-0000mo-00 for ccamp-archive@ietf.org; Mon, 26 Apr 2004 10:00:00 -0400 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BI6Pi-000Dc3-8W for ccamp-data@psg.com; Mon, 26 Apr 2004 13:44:50 +0000 Received: from [62.23.212.165] (helo=smail.alcatel.fr) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BI6Pg-000Dbg-SL for ccamp@ops.ietf.org; Mon, 26 Apr 2004 13:44:49 +0000 Received: from bemail05.netfr.alcatel.fr (bemail05.netfr.alcatel.fr [155.132.251.11]) by smail.alcatel.fr (ALCANET/NETFR) with ESMTP id i3QDid0O018791; Mon, 26 Apr 2004 15:44:39 +0200 Received: from alcatel.be ([138.203.67.90]) by bemail05.netfr.alcatel.fr (Lotus Domino Release 5.0.11) with ESMTP id 2004042615443838:3306 ; Mon, 26 Apr 2004 15:44:38 +0200 Message-ID: <408D12E3.5030806@alcatel.be> Date: Mon, 26 Apr 2004 15:47:15 +0200 From: Dimitri.Papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.5) Gecko/20030925 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ugo monaco Cc: ccamp , Zafar Ali Subject: Re: Diverse path failure and optimality in draft-dachille-inter-area-path-protection References: <408C5733.1000708@infocom.uniroma1.it> In-Reply-To: <408C5733.1000708@infocom.uniroma1.it> X-MIMETrack: Itemize by SMTP Server on BEMAIL05/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 04/26/2004 15:44:38, Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 04/26/2004 15:44:39, Serialize complete at 04/26/2004 15:44:39 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed X-Alcanet-MTA-scanned-and-authorized: yes Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit hi, by discussing the proposed method there seems to be three issues that make the method questionable in terms of guarantee to deliver what it intends to deliver, its usability (the time validity of the path is not guaranteed) and its applicability in terms of objective initially targeted wrt to the network topology 1) imagine three areas decoupled computation as explained at their respective ingress, with ARO method; how the third computation element (tail-end) is aware of srlg's that may affect a link selected in the head-end area example: link 1 is selected in area 1 (head-end) with srlg 1, link 2 is selected in in area 2 with srlg 2, and link 3 in area 3 (tail-end) with srlg 3 and 1 (since the tail end doesn't know that srlg 1 is associated to link 1 in addition to its association to link 3 even if it knows that the link 1 has been selected for the ARO) the problem is that you can not retrieve such kind of error (except but how practical is it if one start cumulating all this information between computation points) 2) resource contention, the secondary path may never be established since the computation point as *no* capability to make any reservation on it (except from the first segment) since by definition "disjoint" - it simply becomes a kind of "best effort" secondary path (in the sense use it if no other reservation are making use of these links) 3) the method seems to raise additional issues when the number of potential entry point for the secondary disjoint path increases, at each step of the computation (otherwise the method wouldn't provide what it intends to deliver) thanks, - dimitri. ugo monaco wrote: > Dear ccamper, Zafar, Dimitri, > > as anticipated in the recent email by Vishal we are addressing several > important comments collected at Seoul regarding the joint-selection of > diverse paths with ARO, i.e. the approach proposed in > . > > > As Vishal did I summarized your comments to ensure that we rightly > understood inputs, and to help people on the ML follow > and contribute to the discussion. > Comments from others who have feedback are welcome, and > much appreciated. > > Please let me know if you had any additional comments > as well. We will take these into account in providing our > responses, and, later, in updating the document. > > > > Thanks again for your feedback on our draft during the Seoul meeting. > Best Regards. > > Ugo Monaco > > > +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > > > Zafar's questions: > > i) What happens when the setup of the diverse path fails, or there is a > failure on it after it has been set up? > > ii) Relationship of this scheme to PCS/PCE approach of JP? > > > Dimitri Papadimitriou > > i) Your question was about why we are trying for optimality with a joint > path selection scheme, when it is not possible, especially as the number > of AS's or areas along a path increase, to achieve the *global* optimum. > Your other comment was that we should mention this somewhere in the > document. > > Please note that in response to this last question Fabio Ricciato listed > many > advantages of a joint computation (with ARO) of inter-area/AS paths in a > prevoius email posted on the ML "About optimality of inter-AS parallel > computation in draft-dachille-inter-area-path-protection". > We hope that Fabio rightly addressed your input and we will appreciate > further comments and notes. > > > > -- Papadimitriou Dimitri E-mail : dimitri.papadimitriou@alcatel.be E-mail : dpapadimitriou@psg.com Webpage: http://psg.com/~dpapadimitriou/ Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium Phone : +32 3 240-8491 From owner-ccamp@ops.ietf.org Mon Apr 26 11:54:13 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28739 for ; Mon, 26 Apr 2004 11:54:13 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BI8Qx-0000f0-9M for ccamp-archive@ietf.org; Mon, 26 Apr 2004 11:54:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BI8QH-0000aj-00 for ccamp-archive@ietf.org; Mon, 26 Apr 2004 11:53:34 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BI8PX-0000Tq-00 for ccamp-archive@ietf.org; Mon, 26 Apr 2004 11:52:47 -0400 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BI8Ar-0008Gt-HJ for ccamp-data@psg.com; Mon, 26 Apr 2004 15:37:37 +0000 Received: from [12.146.0.143] (helo=cabo.sycamorenet.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BI8Aq-0008Gc-A6 for ccamp@ops.ietf.org; Mon, 26 Apr 2004 15:37:36 +0000 Received: by cabo.sycamorenet.com with Internet Mail Service (5.5.2653.19) id <26ZJ1VQ7>; Mon, 26 Apr 2004 11:41:37 -0400 Message-ID: <5533E74FC0108E41A8217C0899CA56CF081E30@mach5.sycamorenet.com> From: "Pandian, Vijay" To: "'John Drake'" , "Pandian, Vijay" , "'Dimitri.Papadimitriou@alcatel.be'" Cc: ccamp@ops.ietf.org Subject: RE: Routing and signaling across devices with different switching cap abilities Date: Mon, 26 Apr 2004 11:41:28 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 John, Thanks for the pointer to this paper. So, in order to provision an LSP between R1 and R2, all the Border Nodes must be capable of forming high order LSPs (FA-LSP)? If there is at least one border node which is in-capable of supporting FA-LSP, the R1 to R2 LSP will fail? I am looking for a solution which does not use the FA-LSP and looks like there is none... Please correct me if my interpretation is wrong. Thanks, Vijay -----Original Message----- From: John Drake [mailto:jdrake@calient.net] Sent: Sunday, April 25, 2004 12:37 PM To: Pandian, Vijay; 'Dimitri.Papadimitriou@alcatel.be' Cc: ccamp@ops.ietf.org Subject: RE: Routing and signaling across devices with different switching cap abilities Vijay, I'd suggest that you study http://www.calient.net/files/IEEEGMPLSpublished.pdf Thanks, John > -----Original Message----- > From: Pandian, Vijay [mailto:Vijay.Pandian@sycamorenet.com] > Sent: Saturday, April 24, 2004 6:43 PM > To: 'Dimitri.Papadimitriou@alcatel.be'; Pandian, Vijay > Cc: ccamp@ops.ietf.org > Subject: RE: Routing and signaling across devices with different switching > cap abilities > > Dimitri, > > Sorry for not being very clear with my previous e-mail. > > Let me re-phrase my question with a different picture: > > OC-48 OC-192 NxOC-192 NxOC-192 OC-192 OC- > 48 > R1 <-----> S1 <------> L1 <--------> FX <--------> L2 <------> S2 <---- > -> > R2 > PSC-1 TDM LSC FSC LSC TDM > PSC-1 > > > OC-48 > <-----> TE-Links > > > R1 and R2 are routers that advertise TE-LSA's with PSC-1 as the Switching > Capability (SC) for the TE-Links to S1 and S2. > > S1 and S2 are two High Order (at STS-1/STM-0 level) grooming switches that > are in-capable of transparently switching a port/lambda (i.e., Section and > Line OH bytes are terminated and re-generated). S1 and S2 thus advertise > TE-LSA's with TDM as the SC for all their TE-Links in this picture. > > L1 and L2 are two OXC's that advertise TE-LSA's with LSC as the SC for all > their TE-Links in this picture. > > FX is a PXC that advertise TE-LSA's with FSC as the SC for its TE-Links in > this picture. > > This should be a valid configuration, right? Do we need any additional > SC's > in the TE-LSA's? > > Given this combination of TE-LSA's, will R1 be able to compute a path to > R2? > > If R1 could successfully compute a PATH, what is the expected "LSP-Enc. > Type", and "Switching Type" in the Generalized Label Request Object for > each > LINK? > > R1 ---> S1: SDH/SONET(5) and TDM (100) with "timeslot" as the label? > > S1 ---> L1: Lambda(8) and LSC(150) with "port" as the label? > > L1 ---> FX: Fiber(9) and FSC(200) with "port" as the label? > > FX ---> L2: Fiber(9) and FSC(200) with "port" as the label? > > L2 ---> S2: Lambda(8) and LSC(150) with "port" as the label? > > S2 ---> R2: SDH/SONET(5) and TDM (100) with "timeslot" as the label? > > How about the G-PID? Does it change as well? > > How about the Bandwidth Encoding? R1 may ask for an OC-48. Assume S1 is > incapable of supporting FA-LSP, can the Bandwidth remain as OC-48 for the > S1 > ---> L1 Link? > > Thanks, > > Vijay > > > -----Original Message----- > > From: Dimitri.Papadimitriou@alcatel.be > > [mailto:Dimitri.Papadimitriou@alcatel.be] > > Sent: Saturday, April 24, 2004 4:18 AM > > To: Pandian, Vijay > > Cc: ccamp@ops.ietf.org > > Subject: Re: Routing and signaling across devices with different > > switching cap abilities > > > > > > hi, > > > > Pandian, Vijay wrote: > > > Consider a mix of devices with varying switching > > capabilities connected as > > > follows: > > > > > > PSC-1 <===> TDM-1 <===> LSC-1 <===> FSC <===> LSC-2 > > <===> TDM-2 <===> > > > PSC-2 > > > > > > Is it fair to assume that PSC-1 and PSC-2 would advertise > > TE-LSA's with > > > "PSC" as the switching capability, TDM-1 and TDM-2 would > > advertise TE-LSA's > > > with "TDM" as the switching capability, LSC-1 and LSC-2 > > would advertise > > > TE-LSA's with "LSC" as the switching capability...? > > > > what "fair" means in this context ? further the hierarchy refers > > to region boundaries as follows: > > > > PSC-1 < PSC-2 < PSC-3 < PSC-4 < L2SC < TDM < LSC < FSC > > > > so assuming you're using different values (non-reported in gmpls- > > routing see below) for TDM and LSC, GMPLS mandates that for inst. > > you're crossing region boundary at [TDM,LSC] the LSR at the edge > > of the TDM region must capable to find [LSC,TDM], and if such > > boundary doesn't exist it is fair to assume that the LSP will not > > be established - note that we've specific values for L2SC (51), > > TDM (100), LSC (150) and FSC (200) so what are you inferring with > > TDM-1 and TDM-2 ? > > > > > Given this, would the PSC device (say PSC-1) be able to > > compute a path using > > > CSPF to PSC-2? > > > > well why don't you use the value defined in gmpls-routing, instead > > of trying to assess a rule for SC relationship that doesn't exist ? > > > > > There had been some discussion regarding the type of label > > (SUKLM vs. lambda > > > vs. port) to be used across these switching capabilities. > > How about the > > > "LSP-Enc. Type", and "Switching Type" in the Generalized > > Label Request > > > Object? How about the Bandwidth Encoding in the > > SENDER_TSPEC and FLOWSPEC > > > object? > > > > what's more precisely the question here ? > > > > > According to rfc3471, section 3.1.1, the switching type is > > expected to map > > > to one of the values advertised for the corresponding link. > > In that case, > > > would the LSC-device accept a Generalized Label Request > > with TDM switching > > > capability and "port" as the label coming from the TDM > > capable device? > > > > i think we've sorted out this issue, during our previous discussion, > > and the response is "the LSC interface accepts a Generalized Label > > Request with LSC switching capability and "port" as the label coming > > from the TDM capable device" i guess you mean when crossing the > > [TDM,LSC] boundary > > > > > Any clarification on this is appreciated... > > > > > > Thanks, > > > > > > Vijay > > > > > > PS: During various GMPLS interop events, an additional FSC > > (and LSC?) > > > switching capability in the TE-LSA's was required for the > > end devices to > > > compute path. > > > > yes, because some people didn't quite accurately translated the term > > "port" in their implementation ("port" =/= "physical port" such as a > > fiber), but as discussed this is erroneous > > > > hope this clarifies, > > - dimitri. > > -- > > Papadimitriou Dimitri > > E-mail : dimitri.papadimitriou@alcatel.be > > E-mail : dpapadimitriou@psg.com > > Webpage: http://psg.com/~dpapadimitriou/ > > Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium > > Phone : +32 3 240-8491 > > > > From owner-ccamp@ops.ietf.org Mon Apr 26 12:28:25 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00779 for ; Mon, 26 Apr 2004 12:28:25 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BI8y3-0003Fh-Dg for ccamp-archive@ietf.org; Mon, 26 Apr 2004 12:28:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BI8wz-0003A1-00 for ccamp-archive@ietf.org; Mon, 26 Apr 2004 12:27:21 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BI8wG-00034K-00 for ccamp-archive@ietf.org; Mon, 26 Apr 2004 12:26:36 -0400 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BI8le-000Fj9-HX for ccamp-data@psg.com; Mon, 26 Apr 2004 16:15:38 +0000 Received: from [195.101.245.16] (helo=p-mail2.rd.francetelecom.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BI8lW-000FiS-JN for ccamp@ops.ietf.org; Mon, 26 Apr 2004 16:15:30 +0000 Received: from lanmhs30.rd.francetelecom.fr ([10.193.21.61]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 26 Apr 2004 18:15:20 +0200 content-class: urn:content-classes:message Subject: RE : RE : Proposed strategy for Inter-area/AS MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 26 Apr 2004 18:15:15 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Message-ID: Thread-Topic: RE : Proposed strategy for Inter-area/AS Thread-Index: AcQrY5fS2MApmZkZSiamtuS91/qaFwAQ/hvg From: "LE ROUX Jean-Louis FTRD/DAC/LAN" To: "ricciato" Cc: , X-OriginalArrivalTime: 26 Apr 2004 16:15:20.0358 (UTC) FILETIME=[ABB6FC60:01C42BA9] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Hi Fabio, Advertising only a subset would improve scalability, but this would not be enough to correclty select the best path. Let's assume that there are three paths from a given ABR X to a given = destination D Path 1: bw 100M admin group {green;blue} Path 2: bw 50M admin group {red; blue} Path 3: bw 5M admin group {red;green} and a TE-LSP L : Destination D, bw=3D 4M, affinity=3D exlude blue If you advertise only Path 1 and Path 2 as virtual links, ABR X will = never be selected as next ABR for this TE-LSP, while path 3 is a = feasible path. Regards JL=20 > -----Message d'origine----- > De : owner-ccamp@ops.ietf.org=20 > [mailto:owner-ccamp@ops.ietf.org] De la part de ricciato > Envoy=E9 : lundi 26 avril 2004 09:48 > =C0 : LE ROUX Jean-Louis FTRD/DAC/LAN > Cc : adrian@olddog.co.uk; ccamp@ops.ietf.org > Objet : Re: RE : Proposed strategy for Inter-area/AS >=20 >=20 > Hi JL, >=20 > just a quick remark: would it make sense in this case to=20 > advertise only=20 > a selected subset of the N virtual links (say the two with=20 > most residual=20 > bw) ? >=20 > ciao > fabio >=20 > LE ROUX Jean-Louis FTRD/DAC/LAN wrote: >=20 > >Let's assume that there are N distinct paths from ABR A to a=20 > >destination X, each with a distinct bandwidth and distinct=20 > admin-group=20 > >(a path admin group being expressed as a logical AND of the=20 > link admin=20 > >groups along the path) How can you summarize such topology ?=20 > Actually=20 > >you need to advertise N virtual links, each with a distinct=20 > admin-group=20 > >and available bandwidth. > > > > > > =20 > > > > =20 > > >=20 >=20 >=20 From owner-ccamp@ops.ietf.org Mon Apr 26 12:43:55 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01773 for ; Mon, 26 Apr 2004 12:43:55 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BI9D3-0004ew-FP for ccamp-archive@ietf.org; Mon, 26 Apr 2004 12:43:57 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BI9C8-0004c0-00 for ccamp-archive@ietf.org; Mon, 26 Apr 2004 12:43:01 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BI9BI-0004Yq-00 for ccamp-archive@ietf.org; Mon, 26 Apr 2004 12:42:08 -0400 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BI8vX-000HEe-OP for ccamp-data@psg.com; Mon, 26 Apr 2004 16:25:51 +0000 Received: from [62.23.212.165] (helo=smail.alcatel.fr) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BI8vW-000HE8-5p for ccamp@ops.ietf.org; Mon, 26 Apr 2004 16:25:50 +0000 Received: from bemail06.netfr.alcatel.fr (bemail06.netfr.alcatel.fr [155.132.251.30]) by smail.alcatel.fr (ALCANET/NETFR) with ESMTP id i3QGPY0O010513; Mon, 26 Apr 2004 18:25:34 +0200 Received: from alcatel.be ([138.203.87.235]) by bemail06.netfr.alcatel.fr (Lotus Domino Release 5.0.11) with ESMTP id 2004042618253223:7071 ; Mon, 26 Apr 2004 18:25:32 +0200 Message-ID: <408D37FA.2254D30F@alcatel.be> Date: Mon, 26 Apr 2004 18:25:30 +0200 From: stefaan.de_cnodder@alcatel.be X-Mailer: Mozilla 4.72 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: v.sharma@ieee.org Cc: ccamp@ops.ietf.org, Fabio Ricciato , Ugo Monaco , "Alessio D'Achille" , Marco Listanti Subject: Re: comments on ARO References: X-MIMETrack: Itemize by SMTP Server on BEMAIL06/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 04/26/2004 18:25:32, Serialize by Router on BEMAIL06/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 04/26/2004 18:25:34, Serialize complete at 04/26/2004 18:25:34 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-Alcanet-MTA-scanned-and-authorized: yes Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Hi Vishal, please find some more comments inline... Vishal Sharma wrote: > > Hi Stefaan, > > Thanks a lot for looking over the draft so carefully, and for your > many detailed comments. > > While we will address the individual comments once we've digested > them a bit (and in a separate email to avoid making this one > too long :-)), let me try to address a couple of the most important > points raised in your note below. > > 1) Recording only border nodes: > > Actually, if one only recorded border nodes, then upon signaling > the secondary, the ingress border node for the secondary has no > idea about the intra-area (or intra-AS) path of the primary (in its > own area or AS), and therefore cannot ensure that the primary and > secondary segments are in fact disjoint. > > This was a point I discussed with several other people > (who initially proposed the same thing), including > Arthi and Adrian, but we concluded, for the reason above, that merely > recording the border nodes does not work for diversity. As a > result, the ARO does, in fact, serve a very useful purpose. > > We can of course think more about what the trade-offs are, and see if there > is some way to retain the main advantage of the proposal (diversity, > joint optimization of both paths) while also recording less information. > The problem I want to solve here is NOT to reduce the amount of information in the ARO, i.e. my purpose is not to reduce its length. Rather, by only recording the border nodes you give more freedom when signaling the secondary (using the XRO!) meaning that when crankback or re-optimization of the secondary is possible, the primary does not have to be resignaled to get a new ARO. > 2) With regard to optimizing only the path of the primary, I am not > so sure about doing just that. > > I believe one can get into real problems if one does not constrain > the path/cost of the secondary, with unduly long secondaries that > will greatly limit the ability to setup further primaries > (and secondaries). (This can be especially true of tranport networks, > where one would set up very large bandwidth pipes, and optimizing their > placement would be critical.) > > This scheme is optimizing jointly the cost of the primary and > secondary, while ensuring diversity. > My question was *what* is the metric being optimized. For instance with sequential computing, the cost of the primary is minimized, while the second metric is the cost of the secondary LSP. With parallel computing it is different: is the cost being minimized the cost of primary + cost of secondary, or is it something else? > I think you will find that most providers would be equally concerned > with the cost/placement of the secondary path. > > Moreover, as I emphasized (and as discussed during CCAMP we wiil change > the title and our intro. to reflect that), this is a: > generic method for computing diverse paths > that meets a variety of requirements: load balancing, multipe paths > when a single one has insufficient capacity, multiple paths between > VoIP gateways, etc. in all of which one would ideally be looking for > paths with about equal length. > Protection is just _one_ application of this scheme. > This load balancing over multiple paths looks like a good application. > 3) Re-optimization, crankback, and failure of secondary: > > I think the scheme works with all of these, and does not really > conflict with any of them. > > With crankback, there should be no problem, whenever a crankback occurs > on the primary, the secondary will also be recomputed at the ASBR/ABR > to which there is crankback. > > With re-optimization, there are several options. > > -- Either default to sequential calculation, and use the XRO to re-optimize > whichever of the two diverse paths requires re-optimization. > (This might be an immediate response, while the below could be > a more long-term response.) > Since an ABR on the secondary path only sees a full strict path in the ERO, the ABR does not know when there is a better path matching the constraints. This is because the ABR does not know the constraints. > -- Or, if the goal really is joint optimization, the provider will have > to setup a new set of diverse paths, and use make-before-break to > transition the traffic over. > > -- If the secondary fails, again there are two options. Either use > the XRO to perform another path setup (and, possibly, re-optimize > the paths later), or use the joint optimization method above with > make-before-break. > This looks ok. regards, Stefaan > 4) Relationship to XRO: > As I mentioned in the Seoul presentation and also > in our discussion, I think the XRO has many uses -- during computation > after crankback, to enable adminstrative routing/re-routing, protection, > etc. > > So I think the ARO and XRO are actually complementary. > > Regards, > -Vishal > > > -----Original Message----- > > From: stefaan.de_cnodder@alcatel.be > > [mailto:stefaan.de_cnodder@alcatel.be] > > Sent: Monday, April 19, 2004 12:08 PM > > To: v.sharma@ieee.org > > Cc: ccamp@ops.ietf.org > > Subject: comments on ARO > > > > > > > > Hi Vishal, > > > > looking to draft-dachille, I have following comments: > > > > 1) Second paragraph in section 2 is not clear: "we will assume that > > every > > inter-area connection is duplicated". I understood from it that when > > the > > primary path follows Area1-Area2-Area3, then also the secondary has > > to > > follow this path but using other border nodes. But then from section > > 4.2 I > > understand that this is not an assumption? > > > > 2) step 2c on page 5: also E, G and H has to be pruned? It is also > > not > > clear which path is selected in area 3: I guess it is E-G-H for > > primary and > > F-H for secondary? > > > > 3) (!) page 7, about the trap-avoid reference: If fact it is just a > > matter > > of doing a good path calculation. If the primary is signaled and > > border > > nodes know that also a secondary has to be established, then it can > > make > > sure that the primary does not introduce such a trap. This assumes > > that the > > border node also has to know that a secondary has to be established. > > This > > is known by the presence of the ARO object but this does not mean > > that at > > the end, the ARO has to contain a full strict path of the secondary. > > Border > > nodes can expand the ARO by only including the border nodes for the > > secondary. This means that the path calculation of the secondary is > > not > > anymore 100% bound to the primary. Also I would prefer that the ARO > > is more > > like a "hint" than the real path. With this, you do not have to > > interaction > > problems with re-optimization of secondary, crankback, ... For > > instance: > > when the secondary fails, it can be re-established ignoring the ARO. > > Or > > when the secondary can be re-optimzed between border nodes, then it > > can be > > done without impacting the primary or when the global > > re-optimization is > > possible, then the ARO can be simple ignored. > > > > I prefer to have the ARO only recording border nodes, and optionally > > only > > acting as a hint for the ingress LSR. The latter is less important > > to me. > > > > 4) text below figure 3: primary has to be as short as possible. I do > > not > > care much about the secondary becuase it is almost never used. Also, > > the > > resources that it reserves can be shared with other secondaries. The > > problem here is: what are you optimizing? According to me the path > > of the > > primary has to be optimized. > > > > 5) I do not understand why the ARO has to contain Area-Ids to > > indicate the > > route. If the ingress can put the "area-path" in the ARO, then it > > can also > > put the border nodes in the ERO of the secondary immediately. I.e. > > refering > > to figure 5: A knows that the path of the secondary is A1-A2-A5-A6. > > How > > does A know this? And if it is possible to let A know this > > information, > > then why could it also not know that the path is B1-B7-B9. If A can > > do > > this, then there is no need anymore for ARO. So the basic question > > is: what > > makes it easier for A to know A1-A2-A5-A6 instead of B1-B7-B9. This > > means > > to me that section 4.2 is not valid and that the ARO assumes that > > the > > "area-path" of primary and secondary is the same, which is true for > > IGP > > areas. See also comment 2. Maybe better to remove the AREA-IDs from > > the > > ARO. > > > > 6) step 1d page 14, second last line: how does the ABR know that B7 > > has to > > be used and not B8? > > > > 7) section 4.3: also describe the L-bit that is in the ERO > > subobjects. > > > > 8) Is the Addr_len in for instance subobject 1 always 32 or can it > > be > > something else. I agree here that you should re-use ERO subobjects > > but I > > see that you are doing this. > > > > 9) Section 4.3.2.3, area_ID: types 3, 4 and 5 are defined but that > > conflicts with what is described in the middle of page 19 where the > > numbers > > are 32, 33, 34. > > > > 10) the text in section 4.3.3 is rather confusing (the part in the > > middle > > of page 22, about pruning the nodes). Take figure 5, area 5: If B6 > > has to > > calculate a path from B6 to B10, then this path can pass via B5, B8, > > B7 > > and/or B9. This is because border nodes can also act as core nodes > > at the > > same time. This seems to be excluded from the draft. Is that > > correct? > > > > 11) First refinement in section 5 about the cost of virtual links: > > this has > > been proposed before in > > http://www.watersprings.org/pub/id/draft-venkatachalam-interarea-m > >pls-te-02.txt > >which is not a good idea: it only works for inter-IGP area and it > >decreases > >the scalability although it also has some advantages. > > >12) (!) There are conflicts with re-optimization, crankback, > >re-establishement after failure of secondary LSP, ... because in all > >of > >these cases a working primary LSP also have to be re-signaled which > >is not > >good. Therefore it is better to let the ARO only record border > >nodes, > >and/or to use the ARO more as a hint for the secondary: using the > >ARO in > >the primary makes sure that a trap is avoided, and then it is up to > >the > >signaling of the secondary to find this path by using crankback, > >.... There > >is no need that the primary LSP also gives the path, it only has to > >make > >sure that there is a path. > > > >13) (!) The method seems not to be applicable for inter-AS > >calculations. > > > >14) Following the classification of methods (ARO, XRO, PCE) that you > >described earlier on ccamp based on parallel/sequential and > >distributed/centralized computation, ARO looks more an alternative > >for PCE than for XRO? In fact, would it be possible to combine > >methods? It would be good to explain the interaction (if any) with > >these other methods. > > > >Hope this helps, > > > >regards, > > > >Stefaan From owner-ccamp@ops.ietf.org Mon Apr 26 12:48:06 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01961 for ; Mon, 26 Apr 2004 12:48:06 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BI9H6-0004tk-Ip for ccamp-archive@ietf.org; Mon, 26 Apr 2004 12:48:08 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BI9GG-0004qM-00 for ccamp-archive@ietf.org; Mon, 26 Apr 2004 12:47:17 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BI9Fp-0004mN-00 for ccamp-archive@ietf.org; Mon, 26 Apr 2004 12:46:49 -0400 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BI94z-000It5-OA for ccamp-data@psg.com; Mon, 26 Apr 2004 16:35:37 +0000 Received: from [171.71.176.70] (helo=sj-iport-1.cisco.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BI94y-000IsZ-If for ccamp@ops.ietf.org; Mon, 26 Apr 2004 16:35:36 +0000 Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i3QGZTW9022942; Mon, 26 Apr 2004 09:35:29 -0700 (PDT) Received: from jvasseur-w2k01.cisco.com (che-vpn-cluster-1-61.cisco.com [10.86.240.61]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id JAA06667; Mon, 26 Apr 2004 09:35:28 -0700 (PDT) Message-Id: <4.3.2.7.2.20040426123348.06af32e8@wells.cisco.com> X-Sender: jvasseur@wells.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 26 Apr 2004 12:35:27 -0400 To: "LE ROUX Jean-Louis FTRD/DAC/LAN" From: Jean Philippe Vasseur Subject: RE : RE : Proposed strategy for Inter-area/AS Cc: "ricciato" , , In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable At 06:15 PM 4/26/2004 +0200, LE ROUX Jean-Louis FTRD/DAC/LAN wrote: >Hi Fabio, > >Advertising only a subset would improve scalability, but >this would not be enough to correclty select the best path. > >Let's assume that there are three paths from a given ABR X to a given=20 >destination D >Path 1: bw 100M admin group {green;blue} >Path 2: bw 50M admin group {red; blue} >Path 3: bw 5M admin group {red;green} > >and a TE-LSP L : Destination D, bw=3D 4M, affinity=3D exlude blue > >If you advertise only Path 1 and Path 2 as virtual links, ABR X will never= =20 >be selected as next ABR for this TE-LSP, while path 3 is a feasible path. and moreover, this gets even more difficult if two ABRs must be traversed=20 between the source and the destination .... JP. >Regards > >JL > > > > > -----Message d'origine----- > > De : owner-ccamp@ops.ietf.org > > [mailto:owner-ccamp@ops.ietf.org] De la part de ricciato > > Envoy=E9 : lundi 26 avril 2004 09:48 > > =C0 : LE ROUX Jean-Louis FTRD/DAC/LAN > > Cc : adrian@olddog.co.uk; ccamp@ops.ietf.org > > Objet : Re: RE : Proposed strategy for Inter-area/AS > > > > > > Hi JL, > > > > just a quick remark: would it make sense in this case to > > advertise only > > a selected subset of the N virtual links (say the two with > > most residual > > bw) ? > > > > ciao > > fabio > > > > LE ROUX Jean-Louis FTRD/DAC/LAN wrote: > > > > >Let's assume that there are N distinct paths from ABR A to a > > >destination X, each with a distinct bandwidth and distinct > > admin-group > > >(a path admin group being expressed as a logical AND of the > > link admin > > >groups along the path) How can you summarize such topology ? > > Actually > > >you need to advertise N virtual links, each with a distinct > > admin-group > > >and available bandwidth. > > > > > > > > > > > > > > > > > > > > > > > > From owner-ccamp@ops.ietf.org Mon Apr 26 13:17:04 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03760 for ; Mon, 26 Apr 2004 13:17:04 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BI9j7-00079h-2p for ccamp-archive@ietf.org; Mon, 26 Apr 2004 13:17:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BI9iB-00075b-00 for ccamp-archive@ietf.org; Mon, 26 Apr 2004 13:16:07 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BI9hQ-00072G-00 for ccamp-archive@ietf.org; Mon, 26 Apr 2004 13:15:21 -0400 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BI9RR-000NeH-LX for ccamp-data@psg.com; Mon, 26 Apr 2004 16:58:49 +0000 Received: from [128.130.90.21] (helo=publications.ftw.tuwien.ac.at) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BI9RO-000NcY-QI for ccamp@ops.ietf.org; Mon, 26 Apr 2004 16:58:47 +0000 Received: from nt_ftw.ftw.tuwien.ac.at by publications.ftw.tuwien.ac.at via smtpd (for psg.com [147.28.0.62]) with ESMTP; Mon, 26 Apr 2004 19:12:08 +0100 Received: from coritel.it (spirit.ftw.at [192.168.0.19]) by nt_ftw.ftw.at with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 20F8Q6H7; Mon, 26 Apr 2004 18:58:05 +0200 Message-ID: <408D3FC2.5060606@coritel.it> Date: Mon, 26 Apr 2004 18:58:42 +0200 From: ricciato User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030821 X-Accept-Language: en-us, en MIME-Version: 1.0 To: LE ROUX Jean-Louis FTRD/DAC/LAN CC: adrian@olddog.co.uk, ccamp@ops.ietf.org Subject: Re: RE : RE : Proposed strategy for Inter-area/AS References: In-Reply-To: X-Enigmail-Version: 0.76.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 8bit Dear JL, you´re right. Just a quick proposal. In an attempt to limit the number of virtual link advertised, would it make sense to advertise only K virtual links, where K={number of colors}, and for each of them (say j) advertise the maximum bandwdith over all links that have color j into their admin_group ? For example, in your example (with Path 4 added) Path 1: bw 100M admin group {green;blue} Path 2: bw 50M admin group {red; blue} Path 3: bw 5M admin group {red;green} Path 4: bw 50M admin group {red} One should advertise Virtual Link 1: bw 100M admin group {green} --->max(100M,5M) Virtual Link 2: bw 50M admin group {red} --->max(50M,5M,50M) Virtual Link 3: bw 100M admin group {gblue} --->max(100M,50M) Assuming that the number of colors << number of possible links, this approach might cap the amount of advertisement. But I´m not sure it works ... ciao fabio LE ROUX Jean-Louis FTRD/DAC/LAN wrote: >Hi Fabio, > >Advertising only a subset would improve scalability, but >this would not be enough to correclty select the best path. > >Let's assume that there are three paths from a given ABR X to a given destination D >Path 1: bw 100M admin group {green;blue} >Path 2: bw 50M admin group {red; blue} >Path 3: bw 5M admin group {red;green} > >and a TE-LSP L : Destination D, bw= 4M, affinity= exlude blue > >If you advertise only Path 1 and Path 2 as virtual links, ABR X will never be selected as next ABR for this TE-LSP, while path 3 is a feasible path. > >Regards > >JL > > > > > >>-----Message d'origine----- >>De : owner-ccamp@ops.ietf.org >>[mailto:owner-ccamp@ops.ietf.org] De la part de ricciato >>Envoyé : lundi 26 avril 2004 09:48 >>À : LE ROUX Jean-Louis FTRD/DAC/LAN >>Cc : adrian@olddog.co.uk; ccamp@ops.ietf.org >>Objet : Re: RE : Proposed strategy for Inter-area/AS >> >> >>Hi JL, >> >>just a quick remark: would it make sense in this case to >>advertise only >>a selected subset of the N virtual links (say the two with >>most residual >>bw) ? >> >>ciao >>fabio >> >>LE ROUX Jean-Louis FTRD/DAC/LAN wrote: >> >> >> >>>Let's assume that there are N distinct paths from ABR A to a >>>destination X, each with a distinct bandwidth and distinct >>> >>> >>admin-group >> >> >>>(a path admin group being expressed as a logical AND of the >>> >>> >>link admin >> >> >>>groups along the path) How can you summarize such topology ? >>> >>> >>Actually >> >> >>>you need to advertise N virtual links, each with a distinct >>> >>> >>admin-group >> >> >>>and available bandwidth. >>> >>> >>> >>> >>> >>> >>> >>> >> >> >> > > > > From owner-ccamp@ops.ietf.org Mon Apr 26 16:53:12 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20158 for ; Mon, 26 Apr 2004 16:53:12 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BID6H-0001Jk-Qc for ccamp-archive@ietf.org; Mon, 26 Apr 2004 16:53:13 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BICwB-00077H-00 for ccamp-archive@ietf.org; Mon, 26 Apr 2004 16:42:49 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BICkF-00054Z-00 for ccamp-archive@ietf.org; Mon, 26 Apr 2004 16:30:27 -0400 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BICUA-0007XS-Kb for ccamp-data@psg.com; Mon, 26 Apr 2004 20:13:50 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BICU9-0007XG-I6 for ccamp@ops.ietf.org; Mon, 26 Apr 2004 20:13:49 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13135; Mon, 26 Apr 2004 15:25:58 -0400 (EDT) Message-Id: <200404261925.PAA13135@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-rsvp-node-id-based-hello-00.txt Date: Mon, 26 Apr 2004 15:25:58 -0400 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --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 : Node ID based RSVP Hello: A Clarification Statement Author(s) : Z. Ali, et al. Filename : draft-ietf-ccamp-rsvp-node-id-based-hello-00.txt Pages : 7 Date : 2004-4-26 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 RSVP Hellos, use of node-id based Hellos is optimal for detecting signaling adjacency failure for RSVP- TE. Nonetheless, this implied behavior is unclear and this document formalizes use of node-id based RSVP Hello sessions as a best current practice (BCP) in some scenarios. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rsvp-node-id-based-hello-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ccamp-rsvp-node-id-based-hello-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ccamp-rsvp-node-id-based-hello-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-4-26150345.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-rsvp-node-id-based-hello-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-rsvp-node-id-based-hello-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-4-26150345.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ccamp@ops.ietf.org Mon Apr 26 17:00:39 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21501 for ; Mon, 26 Apr 2004 17:00:39 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIDDV-0002aP-9D for ccamp-archive@ietf.org; Mon, 26 Apr 2004 17:00:41 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BID6f-0001NS-00 for ccamp-archive@ietf.org; Mon, 26 Apr 2004 16:53:37 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BICx3-0007I5-00 for ccamp-archive@ietf.org; Mon, 26 Apr 2004 16:43:41 -0400 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BICgs-0009OC-Es for ccamp-data@psg.com; Mon, 26 Apr 2004 20:26:58 +0000 Received: from [66.163.168.183] (helo=smtp804.mail.sc5.yahoo.com) by psg.com with smtp (Exim 4.30; FreeBSD) id 1BICgq-0009Nb-0N for ccamp@ops.ietf.org; Mon, 26 Apr 2004 20:26:56 +0000 Received: from unknown (HELO RAKHILAPTOP) (vishal.sharma@sbcglobal.net@67.117.149.229 with login) by smtp804.mail.sc5.yahoo.com with SMTP; 26 Apr 2004 20:26:53 -0000 Reply-To: From: "Vishal Sharma" To: "ricciato" , "LE ROUX Jean-Louis FTRD/DAC/LAN" Cc: , Subject: RE: RE : RE : Proposed strategy for Inter-area/AS Date: Mon, 26 Apr 2004 13:26:44 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <408D3FC2.5060606@coritel.it> Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 8bit Hi Fabio, JL, et al I think Fabio may have a good idea here. It provides the flexibility of having info. about all affinities, with the scalability of advertizing only limited information. Perhaps we can explore a bit where there might be issues, and refine this initial solution to get something that we believe is appropriate. -Vishal > -----Original Message----- > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On > Behalf Of ricciato > Sent: Monday, April 26, 2004 9:59 AM > To: LE ROUX Jean-Louis FTRD/DAC/LAN > Cc: adrian@olddog.co.uk; ccamp@ops.ietf.org > Subject: Re: RE : RE : Proposed strategy for Inter-area/AS > > > Dear JL, > > you´re right. > > Just a quick proposal. > In an attempt to limit the number of virtual link advertised, > would it make sense to advertise only K virtual links, where K={number > of colors}, and for each of them (say j) advertise the maximum > bandwdith over all links that have color j into their admin_group ? > > For example, in your example (with Path 4 added) > > Path 1: bw 100M admin group {green;blue} > Path 2: bw 50M admin group {red; blue} > Path 3: bw 5M admin group {red;green} > Path 4: bw 50M admin group {red} > > One should advertise > Virtual Link 1: bw 100M admin group {green} --->max(100M,5M) > Virtual Link 2: bw 50M admin group {red} --->max(50M,5M,50M) > Virtual Link 3: bw 100M admin group {gblue} --->max(100M,50M) > > > Assuming that the number of colors << number of possible links, > this approach might cap the amount of advertisement. > > But I´m not sure it works ... > > ciao > fabio > > LE ROUX Jean-Louis FTRD/DAC/LAN wrote: > > >Hi Fabio, > > > >Advertising only a subset would improve scalability, but > >this would not be enough to correclty select the best path. > > > >Let's assume that there are three paths from a given ABR X to a > given destination D > >Path 1: bw 100M admin group {green;blue} > >Path 2: bw 50M admin group {red; blue} > >Path 3: bw 5M admin group {red;green} > > > >and a TE-LSP L : Destination D, bw= 4M, affinity= exlude blue > > > >If you advertise only Path 1 and Path 2 as virtual links, ABR X > will never be selected as next ABR for this TE-LSP, while path 3 > is a feasible path. > > > >Regards > > > >JL > > > > > > > > > > > >>-----Message d'origine----- > >>De : owner-ccamp@ops.ietf.org > >>[mailto:owner-ccamp@ops.ietf.org] De la part de ricciato > >>Envoyé : lundi 26 avril 2004 09:48 > >>À : LE ROUX Jean-Louis FTRD/DAC/LAN > >>Cc : adrian@olddog.co.uk; ccamp@ops.ietf.org > >>Objet : Re: RE : Proposed strategy for Inter-area/AS > >> > >> > >>Hi JL, > >> > >>just a quick remark: would it make sense in this case to > >>advertise only > >>a selected subset of the N virtual links (say the two with > >>most residual > >>bw) ? > >> > >>ciao > >>fabio > >> > >>LE ROUX Jean-Louis FTRD/DAC/LAN wrote: > >> > >> > >> > >>>Let's assume that there are N distinct paths from ABR A to a > >>>destination X, each with a distinct bandwidth and distinct > >>> > >>> > >>admin-group > >> > >> > >>>(a path admin group being expressed as a logical AND of the > >>> > >>> > >>link admin > >> > >> > >>>groups along the path) How can you summarize such topology ? > >>> > >>> > >>Actually > >> > >> > >>>you need to advertise N virtual links, each with a distinct > >>> > >>> > >>admin-group > >> > >> > >>>and available bandwidth. > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >> > >> > >> > > > > > > > > > From owner-ccamp@ops.ietf.org Mon Apr 26 17:55:11 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26595 for ; Mon, 26 Apr 2004 17:55:11 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIE4H-0000CW-Ge for ccamp-archive@ietf.org; Mon, 26 Apr 2004 17:55:13 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIE3Q-00009G-00 for ccamp-archive@ietf.org; Mon, 26 Apr 2004 17:54:21 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BIE2l-00006W-00 for ccamp-archive@ietf.org; Mon, 26 Apr 2004 17:53:39 -0400 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BIDrk-000MNw-A2 for ccamp-data@psg.com; Mon, 26 Apr 2004 21:42:16 +0000 Received: from [66.163.170.80] (helo=smtp810.mail.sc5.yahoo.com) by psg.com with smtp (Exim 4.30; FreeBSD) id 1BIDri-000MMZ-Qb for ccamp@ops.ietf.org; Mon, 26 Apr 2004 21:42:14 +0000 Received: from unknown (HELO RAKHILAPTOP) (vishal.sharma@sbcglobal.net@67.117.149.229 with login) by smtp810.mail.sc5.yahoo.com with SMTP; 26 Apr 2004 20:18:59 -0000 Reply-To: From: "Vishal Sharma" To: Cc: , "Fabio Ricciato" , "Ugo Monaco" , "Alessio D'Achille" , "Marco Listanti" Subject: RE: comments on ARO Date: Mon, 26 Apr 2004 13:18:52 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <40842395.2DD1A674@alcatel.be> Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Hi Stefaan, Just following up on my earlier reply to your comments. We had promised to respond to your specific comments a bit later, and some respones are in-line. Again, thanks a lot for feedback, it will be very helpful in revising the document. Regards, -Vishal PS: A couple that are not addressed here, we will address jointly with others, such as when responding to Arthi's or JL's comments, and will CC you on them. > -----Original Message----- > From: stefaan.de_cnodder@alcatel.be > [mailto:stefaan.de_cnodder@alcatel.be] > Sent: Monday, April 19, 2004 12:08 PM > To: v.sharma@ieee.org > Cc: ccamp@ops.ietf.org > Subject: comments on ARO > > > > Hi Vishal, > > looking to draft-dachille, I have following comments: > > 1) Second paragraph in section 2 is not clear: "we will assume that > every > inter-area connection is duplicated". I understood from it that when > the > primary path follows Area1-Area2-Area3, then also the secondary has > to > follow this path but using other border nodes. But then from section > 4.2 I > understand that this is not an assumption? Your understanding is correct. That is, we do _not assume_ that the primary and secondary paths (or the two diverse paths, to be more accurate) follow he same areas/ASs. Thanks for the observation, we will make this clearer in the next revision. > > 2) step 2c on page 5: also E, G and H has to be pruned? It is also > not > clear which path is selected in area 3: I guess it is E-G-H for > primary and > F-H for secondary? Yes. Thanks for pointing this out, we will specify it clearly in the upcoming revision. > 3) (!) page 7, about the trap-avoid reference: If fact it is just a > matter > of doing a good path calculation. If the primary is signaled and > border > nodes know that also a secondary has to be established, then it can > make > sure that the primary does not introduce such a trap. This assumes > that the > border node also has to know that a secondary has to be established. > This > is known by the presence of the ARO object but this does not mean > that at > the end, the ARO has to contain a full strict path of the secondary. > Border > nodes can expand the ARO by only including the border nodes for the > secondary. This means that the path calculation of the secondary is > not > anymore 100% bound to the primary. Also I would prefer that the ARO > is more > like a "hint" than the real path. With this, you do not have to > interaction > problems with re-optimization of secondary, crankback, ... For > instance: > when the secondary fails, it can be re-established ignoring the ARO. > Or > when the secondary can be re-optimzed between border nodes, then it > can be > done without impacting the primary or when the global > re-optimization is > possible, then the ARO can be simple ignored. > > I prefer to have the ARO only recording border nodes, and optionally > only > acting as a hint for the ingress LSR. The latter is less important > to me. As explained in my earlier response, http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00504.html a difficulty with just recording the border nodes is that mere knowledge that the secondary is for some primary, without a knowing the path of the primary is not sufficient to ensure _diversity_ of the two paths. This is one of the main goals of the ARO scheme, thus we need to have knowledge that a primary _and_ a secondary are to be routed when jointly computing their path at each border node. > 4) text below figure 3: primary has to be as short as possible. I do > not > care much about the secondary becuase it is almost never used. Also, > the > resources that it reserves can be shared with other secondaries. The > problem here is: what are you optimizing? According to me the path > of the > primary has to be optimized. Addressed in detail in my earlier response http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00504.html. Briefly, with diversity as the goal, often it may be that the paths of both the primary and secondary are to be optimized or made as short as possible, so we cannot just optimize the one path while ignoring completely the other. (Even if not, one can get into real sub-optimal network operation with unduly long secondary/diverse paths, if their lengths are not controlled cleverly from the start.) But, I agree, we will make this clearer in the revised version, when we focus on diversity, and clarify that protection is one application of the scheme. > 5) I do not understand why the ARO has to contain Area-Ids to > indicate the > route. If the ingress can put the "area-path" in the ARO, then it > can also > put the border nodes in the ERO of the secondary immediately. I.e. > refering > to figure 5: A knows that the path of the secondary is A1-A2-A5-A6. > How > does A know this? And if it is possible to let A know this > information, > then why could it also not know that the path is B1-B7-B9. If A can > do > this, then there is no need anymore for ARO. So the basic question > is: what > makes it easier for A to know A1-A2-A5-A6 instead of B1-B7-B9. This > means > to me that section 4.2 is not valid and that the ARO assumes that > the > "area-path" of primary and secondary is the same, which is true for > IGP > areas. See also comment 2. Maybe better to remove the AREA-IDs from > the > ARO. > > 6) step 1d page 14, second last line: how does the ABR know that B7 > has to > be used and not B8? Referring to Fig. 5 of the draft, the ingress ABR in Area 2 would make that selection depending on what metrics it is optimizing. > 7) section 4.3: also describe the L-bit that is in the ERO > subobjects. Ok, thanks, we will in the next revision. > 8) Is the Addr_len in for instance subobject 1 always 32 or can it > be > something else. I agree here that you should re-use ERO subobjects > but I > see that you are doing this. As mentioned in Sec. 4.3.2.1, the address length allows the IPv4 address to be a prefix of length specified by the "Add_Len" field. So the address length can be different than 32. > 9) Section 4.3.2.3, area_ID: types 3, 4 and 5 are defined but that > conflicts with what is described in the middle of page 19 where the > numbers > are 32, 33, 34. Thanks for the catch! We will make these consistent. > 10) the text in section 4.3.3 is rather confusing (the part in the > middle > of page 22, about pruning the nodes). Take figure 5, area 5: If B6 > has to > calculate a path from B6 to B10, then this path can pass via B5, B8, > B7 > and/or B9. This is because border nodes can also act as core nodes > at the > same time. This seems to be excluded from the draft. Is that > correct? > > 11) First refinement in section 5 about the cost of virtual links: > this has > been proposed before in > http://www.watersprings.org/pub/id/draft-venkatachalam-interarea-m >pls-te-02.txt >which is not a good idea: it only works for inter-IGP area and it >decreases >the scalability although it also has some advantages. Thanks for the observation and the pointer. As you would see from my response to JL, we are thinking more about the virtual link case, and will be able to post some alternatives once we have given it a bit more thought. >12) (!) There are conflicts with re-optimization, crankback, >re-establishement after failure of secondary LSP, ... because in all >of >these cases a working primary LSP also have to be re-signaled which >is not >good. Actually, there are several options in each of these cases, and I have explained some in my earlier response http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00504.html. Further inputs from CCAMPers on interworking these will be much appreciated. We can probably add a discussion of some of these interworking options in the draft, although it is not a goal of the draft to document all possible interworking scenarios! >Therefore it is better to let the ARO only record border >nodes, >and/or to use the ARO more as a hint for the secondary: using the >ARO in >the primary makes sure that a trap is avoided, and then it is up to >the >signaling of the secondary to find this path by using crankback, >.... There >is no need that the primary LSP also gives the path, it only has to >make >sure that there is a path. As explained above, and in my earlier response, the goal is to ensure that there is a _diverse_ path, not just a path for the second LSP. >13) (!) The method seems not to be applicable for inter-AS >calculations. Not sure why you say that (perhaps because of point 12?). We have designed it to be applicable both for inter-area and inter-AS cases. While some refinement for the inter-AS case would improve the scheme, we certainly had that inter-AS case in mind when developing it. >14) Following the classification of methods (ARO, XRO, PCE) that you >described earlier on ccamp based on parallel/sequential and >distributed/centralized computation, ARO looks more an alternative >for PCE than for XRO? In fact, would it be possible to combine >methods? It would be good to explain the interaction (if any) with >these other methods. As I pointed out in my email to JP, http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00467.html we view the ARO as complementary to the PCS/PCE approach and to the XRO. The goal in designing it wasn't really to replace either of these. In fact, I explained there that the ARO is a hybrid approach that can can compute end-to-end diverse paths like in the PCE approach, with the simplicity of the per-domain approach, and without any changes to the signaling protocols (save for an ERO-formatted ARO obj.). As said earlier, it seems it would be useful for us to put in a short section discussing complementarity with other approaches. You already saw some of this in my earlier response to your email, where I explained how things could work with crankback, re-opt. etc. From owner-ccamp@ops.ietf.org Mon Apr 26 18:01:30 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27097 for ; Mon, 26 Apr 2004 18:01:30 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIEAO-0000ix-FL for ccamp-archive@ietf.org; Mon, 26 Apr 2004 18:01:32 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIE9Y-0000eb-00 for ccamp-archive@ietf.org; Mon, 26 Apr 2004 18:00:41 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BIE8u-0000ZD-00 for ccamp-archive@ietf.org; Mon, 26 Apr 2004 18:00:00 -0400 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BIDyN-000Nb6-Vp for ccamp-data@psg.com; Mon, 26 Apr 2004 21:49:07 +0000 Received: from [66.163.168.188] (helo=smtp809.mail.sc5.yahoo.com) by psg.com with smtp (Exim 4.30; FreeBSD) id 1BIDyM-000Naq-M1 for ccamp@ops.ietf.org; Mon, 26 Apr 2004 21:49:06 +0000 Received: from unknown (HELO RAKHILAPTOP) (vishal.sharma@sbcglobal.net@67.117.149.229 with login) by smtp809.mail.sc5.yahoo.com with SMTP; 26 Apr 2004 21:49:04 -0000 Reply-To: From: "Vishal Sharma" To: "Stefaan De Cnodder" , "CCAMP" Cc: "Fabio Ricciato" , "Ugo Monaco" , "Alessio D'Achille" , "Marco Listanti" Subject: RE: Comments on ARO Date: Mon, 26 Apr 2004 14:48:56 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Hi Stefaan, Just following up on my earlier reply to your comments. We had promised to respond to your specific comments a bit later, and some respones are in-line. Again, thanks a lot for feedback, it will be very helpful in revising the document. Regards, -Vishal PS: A couple that are not addressed here, we will address jointly with others, such as when responding to Arthi's or JL's comments, and will CC you on them. > -----Original Message----- > From: stefaan.de_cnodder@alcatel.be > [mailto:stefaan.de_cnodder@alcatel.be] > Sent: Monday, April 19, 2004 12:08 PM > To: v.sharma@ieee.org > Cc: ccamp@ops.ietf.org > Subject: comments on ARO > > > > Hi Vishal, > > looking to draft-dachille, I have following comments: > > 1) Second paragraph in section 2 is not clear: "we will assume that > every > inter-area connection is duplicated". I understood from it that when > the > primary path follows Area1-Area2-Area3, then also the secondary has > to > follow this path but using other border nodes. But then from section > 4.2 I > understand that this is not an assumption? Your understanding is correct. That is, we do _not assume_ that the primary and secondary paths (or the two diverse paths, to be more accurate) follow he same areas/ASs. Thanks for the observation, we will make this clearer in the next revision. > > 2) step 2c on page 5: also E, G and H has to be pruned? It is also > not > clear which path is selected in area 3: I guess it is E-G-H for > primary and > F-H for secondary? Yes. Thanks for pointing this out, we will specify it clearly in the upcoming revision. > 3) (!) page 7, about the trap-avoid reference: If fact it is just a > matter > of doing a good path calculation. If the primary is signaled and > border > nodes know that also a secondary has to be established, then it can > make > sure that the primary does not introduce such a trap. This assumes > that the > border node also has to know that a secondary has to be established. > This > is known by the presence of the ARO object but this does not mean > that at > the end, the ARO has to contain a full strict path of the secondary. > Border > nodes can expand the ARO by only including the border nodes for the > secondary. This means that the path calculation of the secondary is > not > anymore 100% bound to the primary. Also I would prefer that the ARO > is more > like a "hint" than the real path. With this, you do not have to > interaction > problems with re-optimization of secondary, crankback, ... For > instance: > when the secondary fails, it can be re-established ignoring the ARO. > Or > when the secondary can be re-optimzed between border nodes, then it > can be > done without impacting the primary or when the global > re-optimization is > possible, then the ARO can be simple ignored. > > I prefer to have the ARO only recording border nodes, and optionally > only > acting as a hint for the ingress LSR. The latter is less important > to me. As explained in my earlier response, http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00504.html a difficulty with just recording the border nodes is that mere knowledge that the secondary is for some primary, without a knowing the path of the primary is not sufficient to ensure _diversity_ of the two paths. This is one of the main goals of the ARO scheme, thus we need to have knowledge that a primary _and_ a secondary are to be routed when jointly computing their path at each border node. > 4) text below figure 3: primary has to be as short as possible. I do > not > care much about the secondary becuase it is almost never used. Also, > the > resources that it reserves can be shared with other secondaries. The > problem here is: what are you optimizing? According to me the path > of the > primary has to be optimized. Addressed in detail in my earlier response http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00504.html. Briefly, with diversity as the goal, often it may be that the paths of both the primary and secondary are to be optimized or made as short as possible, so we cannot just optimize the one path while ignoring completely the other. (Even if not, one can get into real sub-optimal network operation with unduly long secondary/diverse paths, if their lengths are not controlled cleverly from the start.) But, I agree, we will make this clearer in the revised version, when we focus on diversity, and clarify that protection is one application of the scheme. > 5) I do not understand why the ARO has to contain Area-Ids to > indicate the > route. If the ingress can put the "area-path" in the ARO, then it > can also > put the border nodes in the ERO of the secondary immediately. I.e. > refering > to figure 5: A knows that the path of the secondary is A1-A2-A5-A6. > How > does A know this? And if it is possible to let A know this > information, > then why could it also not know that the path is B1-B7-B9. If A can > do > this, then there is no need anymore for ARO. So the basic question > is: what > makes it easier for A to know A1-A2-A5-A6 instead of B1-B7-B9. This > means > to me that section 4.2 is not valid and that the ARO assumes that > the > "area-path" of primary and secondary is the same, which is true for > IGP > areas. See also comment 2. Maybe better to remove the AREA-IDs from > the > ARO. > > 6) step 1d page 14, second last line: how does the ABR know that B7 > has to > be used and not B8? Referring to Fig. 5 of the draft, the ingress ABR in Area 2 would make that selection depending on what metrics it is optimizing. > 7) section 4.3: also describe the L-bit that is in the ERO > subobjects. Ok, thanks, we will in the next revision. > 8) Is the Addr_len in for instance subobject 1 always 32 or can it > be > something else. I agree here that you should re-use ERO subobjects > but I > see that you are doing this. As mentioned in Sec. 4.3.2.1, the address length allows the IPv4 address to be a prefix of length specified by the "Add_Len" field. So the address length can be different than 32. > 9) Section 4.3.2.3, area_ID: types 3, 4 and 5 are defined but that > conflicts with what is described in the middle of page 19 where the > numbers > are 32, 33, 34. Thanks for the catch! We will make these consistent. > 10) the text in section 4.3.3 is rather confusing (the part in the > middle > of page 22, about pruning the nodes). Take figure 5, area 5: If B6 > has to > calculate a path from B6 to B10, then this path can pass via B5, B8, > B7 > and/or B9. This is because border nodes can also act as core nodes > at the > same time. This seems to be excluded from the draft. Is that > correct? > > 11) First refinement in section 5 about the cost of virtual links: > this has > been proposed before in > http://www.watersprings.org/pub/id/draft-venkatachalam-interarea-m >pls-te-02.txt >which is not a good idea: it only works for inter-IGP area and it >decreases >the scalability although it also has some advantages. Thanks for the observation and the pointer. As you would see from my response to JL, we are thinking more about the virtual link case, and will be able to post some alternatives once we have given it a bit more thought. >12) (!) There are conflicts with re-optimization, crankback, >re-establishement after failure of secondary LSP, ... because in all >of >these cases a working primary LSP also have to be re-signaled which >is not >good. Actually, there are several options in each of these cases, and I have explained some in my earlier response http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00504.html. Further inputs from CCAMPers on interworking these will be much appreciated. We can probably add a discussion of some of these interworking options in the draft, although it is not a goal of the draft to document all possible interworking scenarios! >Therefore it is better to let the ARO only record border >nodes, >and/or to use the ARO more as a hint for the secondary: using the >ARO in >the primary makes sure that a trap is avoided, and then it is up to >the >signaling of the secondary to find this path by using crankback, >.... There >is no need that the primary LSP also gives the path, it only has to >make >sure that there is a path. As explained above, and in my earlier response, the goal is to ensure that there is a _diverse_ path, not just a path for the second LSP. >13) (!) The method seems not to be applicable for inter-AS >calculations. Not sure why you say that (perhaps because of point 12?). We have designed it to be applicable both for inter-area and inter-AS cases. While some refinement for the inter-AS case would improve the scheme, we certainly had that inter-AS case in mind when developing it. >14) Following the classification of methods (ARO, XRO, PCE) that you >described earlier on ccamp based on parallel/sequential and >distributed/centralized computation, ARO looks more an alternative >for PCE than for XRO? In fact, would it be possible to combine >methods? It would be good to explain the interaction (if any) with >these other methods. As I pointed out in my email to JP, http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00467.html we view the ARO as complementary to the PCS/PCE approach and to the XRO. The goal in designing it wasn't really to replace either of these. In fact, I explained there that the ARO is a hybrid approach that can can compute end-to-end diverse paths like in the PCE approach, with the simplicity of the per-domain approach, and without any changes to the signaling protocols (save for an ERO-formatted ARO obj.). As said earlier, it seems it would be useful for us to put in a short section discussing complementarity with other approaches. You already saw some of this in my earlier response to your email, where I explained how things could work with crankback, re-opt. etc. From owner-ccamp@ops.ietf.org Mon Apr 26 19:19:18 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02828 for ; Mon, 26 Apr 2004 19:19:18 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIFNf-0006uK-KW for ccamp-archive@ietf.org; Mon, 26 Apr 2004 19:19:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIFMf-0006oL-00 for ccamp-archive@ietf.org; Mon, 26 Apr 2004 19:18:17 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BIFLf-0006gi-00 for ccamp-archive@ietf.org; Mon, 26 Apr 2004 19:17:15 -0400 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BIF7c-000AdK-Ad for ccamp-data@psg.com; Mon, 26 Apr 2004 23:02:44 +0000 Received: from [209.183.201.132] (helo=mailsrv01.vasw) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BIF7b-000Ad6-AR for ccamp@ops.ietf.org; Mon, 26 Apr 2004 23:02:43 +0000 Received: by mailsrv01.vasw with Internet Mail Service (5.5.2657.72) id ; Mon, 26 Apr 2004 18:57:47 -0400 Message-ID: <35800AB26A91D711A75D00B0D07935F31AD35C@mailsrv01.vasw> From: "Balasubramania N. Pillai" To: "'ccamp@ops.ietf.org'" Subject: Basic doubts on 1:1 path protection signaling. Date: Mon, 26 Apr 2004 18:57:46 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Hi All, I was reading the draft-ietf-ccamp-gmpls-recovery-e2e-signaling-00.txt and I have some basic doubts regarding signaling 1:1 protected LSP with extra traffic. 1. My understanding is that Section 7 talks about 1:1 Protection (the protection path is fully setup and cross-connects are made) and not 1:1 Restoration (no cross-connects for protection path) 2. Since the protection LSP is setup (cross-connected), I guess we should advertise that the resources used by the Protection LSP as "in use" in routing. 3. Section 7, Paragraph 3 says that Although the resources for the protecting LSP are pre-allocated, preemptable traffic may be carried end-to-end using this LSP (i.e. the protecting LSP is capable of carrying extra-traffic) with the caveat that this traffic will be preempted if the working LSP fails. Take the case where a 1:1 LSP is setup. Both the working LSP and the protection LSP are setup and cross-connected. Now if we want to add a extra-traffic, how do we signal, to setup the LSP carrying the Extra traffic. What objects do we use to associate the "Extra Traffic LSP" to the protection LSP. Thanks for you time Balu From owner-ccamp@ops.ietf.org Mon Apr 26 20:44:27 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06624 for ; Mon, 26 Apr 2004 20:44:27 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIGi3-0006JW-Tx for ccamp-archive@ietf.org; Mon, 26 Apr 2004 20:44:28 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIGhA-0006DV-00 for ccamp-archive@ietf.org; Mon, 26 Apr 2004 20:43:33 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BIGgJ-00067w-00 for ccamp-archive@ietf.org; Mon, 26 Apr 2004 20:42:39 -0400 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BIGRw-000O1M-OU for ccamp-data@psg.com; Tue, 27 Apr 2004 00:27:48 +0000 Received: from [64.102.122.149] (helo=rtp-iport-2.cisco.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BIGRv-000O17-Oe for ccamp@ops.ietf.org; Tue, 27 Apr 2004 00:27:47 +0000 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 26 Apr 2004 17:27:40 -0700 X-BrightmailFiltered: true Received: from zaliw2k01 (che-vpn-cluster-1-100.cisco.com [10.86.240.100]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i3R0RgYu003857; Mon, 26 Apr 2004 20:27:43 -0400 (EDT) From: "zafar ali" To: , Cc: "'Reshad Rahman'" , , Subject: RE: draft-ali-ccamp-rsvp-node-id-based-hello-01.txt as WG document? Date: Mon, 26 Apr 2004 20:27:42 -0400 Organization: Cisco Systems Message-ID: <000501c42bee$75870410$a39ce440@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.5709 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Hi Adrian,=20 Thanks for your follow-ups on the list; much appreciated.=20 We have updated the ID with ONLY changes as required by the IETF process (i.e., copyright, IPR, etc. stuff) and republished the ID. The updated version is at,=20 http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rsvp-node-id-based-h= ell o-00.txt Hi All,=20 Comments on the ID will be highly appreciated.=20 Thanks Regards... Zafar >-----Original Message----- >From: owner-ccamp@ops.ietf.org=20 >[mailto:owner-ccamp@ops.ietf.org] On Behalf Of Adrian Farrel >Sent: Monday, April 26, 2004 3:09 AM >To: ccamp@ops.ietf.org >Subject: Re: draft-ali-ccamp-rsvp-node-id-based-hello-01.txt=20 >as WG document? > > >OK authors, please republish as a working group draft.=20 > >Please make no changes from the previous version except > - check that you have all of the correct IPR boilerplate > including the personal statement > - check that you have the correct copyright boilerplate=20 > >Thanks, >Adrian > From owner-ccamp@ops.ietf.org Tue Apr 27 03:35:41 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11144 for ; Tue, 27 Apr 2004 03:35:40 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIN80-0001fn-PB for ccamp-archive@ietf.org; Tue, 27 Apr 2004 03:35:40 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIN76-0001WT-00 for ccamp-archive@ietf.org; Tue, 27 Apr 2004 03:34:45 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BIN6T-0001N3-00 for ccamp-archive@ietf.org; Tue, 27 Apr 2004 03:34:05 -0400 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BIMjX-000AJh-2l for ccamp-data@psg.com; Tue, 27 Apr 2004 07:10:23 +0000 Received: from [62.23.212.165] (helo=smail.alcatel.fr) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BIMjV-000AJ4-Oa for ccamp@ops.ietf.org; Tue, 27 Apr 2004 07:10:21 +0000 Received: from bemail05.netfr.alcatel.fr (bemail05.netfr.alcatel.fr [155.132.251.11]) by smail.alcatel.fr (ALCANET/NETFR) with ESMTP id i3R7AH0O000423; Tue, 27 Apr 2004 09:10:17 +0200 Received: from alcatel.be ([138.203.118.2]) by bemail05.netfr.alcatel.fr (Lotus Domino Release 5.0.11) with ESMTP id 2004042709101557:1075 ; Tue, 27 Apr 2004 09:10:15 +0200 Message-ID: <408E07F7.8010702@alcatel.be> Date: Tue, 27 Apr 2004 09:12:55 +0200 From: Dimitri.Papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.5) Gecko/20030925 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Balasubramania N. Pillai" CC: "'ccamp@ops.ietf.org'" Subject: Re: Basic doubts on 1:1 path protection signaling. References: <35800AB26A91D711A75D00B0D07935F31AD35C@mailsrv01.vasw> In-Reply-To: <35800AB26A91D711A75D00B0D07935F31AD35C@mailsrv01.vasw> X-MIMETrack: Itemize by SMTP Server on BEMAIL05/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 04/27/2004 09:10:15, Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 04/27/2004 09:10:17, Serialize complete at 04/27/2004 09:10:17 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed X-Alcanet-MTA-scanned-and-authorized: yes Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Balasubramania N. Pillai wrote: > Hi All, > > I was reading the draft-ietf-ccamp-gmpls-recovery-e2e-signaling-00.txt and I > have some basic doubts regarding signaling 1:1 protected LSP with extra > traffic. > > > 1. My understanding is that Section 7 talks about 1:1 Protection (the > protection path is fully setup and cross-connects are made) and not 1:1 > Restoration (no cross-connects for protection path) as the title indicates and explained in the text > 2. Since the protection LSP is setup (cross-connected), I guess we should > advertise that the resources used by the Protection LSP as "in use" in > routing. if it is cross-connected it is "in use" > 3. Section 7, Paragraph 3 says that > > Although the resources for the protecting LSP are pre-allocated, > preemptable traffic may be carried end-to-end using this LSP (i.e. > the protecting LSP is capable of carrying extra-traffic) with the > caveat that this traffic will be preempted if the working LSP fails. > > Take the case where a 1:1 LSP is setup. Both the working LSP and the > protection LSP are setup and cross-connected. Now if we want to add a > extra-traffic, how do we signal, to setup the LSP carrying the Extra > traffic. the protecting lsp allows carrying extra-traffic (in a sense you may see for the 1:1 protection case, the protecting lsp as the "extra-traffic lsp" but this terminology is misleading reason why it is not used) > What objects do we use to associate the "Extra Traffic LSP" to the > protection LSP. the association object is used to bind the protected and the protecting lsp hope this clarifies (note: an update is being prepared to further clarify some of the comments made on the list) thanks, - dimitri > Thanks for you time > > Balu > > > > -- Papadimitriou Dimitri E-mail : dimitri.papadimitriou@alcatel.be E-mail : dpapadimitriou@psg.com Webpage: http://psg.com/~dpapadimitriou/ Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium Phone : +32 3 240-8491 From owner-ccamp@ops.ietf.org Tue Apr 27 03:42:39 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11615 for ; Tue, 27 Apr 2004 03:42:39 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BINEl-0002vw-C4 for ccamp-archive@ietf.org; Tue, 27 Apr 2004 03:42:39 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BINDp-0002lM-00 for ccamp-archive@ietf.org; Tue, 27 Apr 2004 03:41:42 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BIND8-0002Yv-00 for ccamp-archive@ietf.org; Tue, 27 Apr 2004 03:40:58 -0400 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BIMnX-000Ajn-Q9 for ccamp-data@psg.com; Tue, 27 Apr 2004 07:14:31 +0000 Received: from [62.23.212.165] (helo=smail.alcatel.fr) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BIMnW-000AjP-D1 for ccamp@ops.ietf.org; Tue, 27 Apr 2004 07:14:30 +0000 Received: from bemail05.netfr.alcatel.fr (bemail05.netfr.alcatel.fr [155.132.251.11]) by smail.alcatel.fr (ALCANET/NETFR) with ESMTP id i3R7EO0O003136; Tue, 27 Apr 2004 09:14:25 +0200 Received: from alcatel.be ([138.203.118.2]) by bemail05.netfr.alcatel.fr (Lotus Domino Release 5.0.11) with ESMTP id 2004042709142215:1094 ; Tue, 27 Apr 2004 09:14:22 +0200 Message-ID: <408E08EE.8070805@alcatel.be> Date: Tue, 27 Apr 2004 09:17:02 +0200 From: Dimitri.Papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.5) Gecko/20030925 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Pandian, Vijay" Cc: "'John Drake'" , ccamp@ops.ietf.org Subject: Re: Routing and signaling across devices with different switching cap abilities References: <5533E74FC0108E41A8217C0899CA56CF081E30@mach5.sycamorenet.com> In-Reply-To: <5533E74FC0108E41A8217C0899CA56CF081E30@mach5.sycamorenet.com> X-MIMETrack: Itemize by SMTP Server on BEMAIL05/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 04/27/2004 09:14:23, Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 04/27/2004 09:14:24, Serialize complete at 04/27/2004 09:14:24 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed X-Alcanet-MTA-scanned-and-authorized: yes Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit vijay, would it be possible that you clarify either your concern wrt existing mechanisms or what you want to achieve when saying "I am looking for a solution which does not use the FA-LSP and looks like there is none..." what does that mean ? thanks, - dimitri. Pandian, Vijay wrote: > John, > > Thanks for the pointer to this paper. > > So, in order to provision an LSP between R1 and R2, all the Border Nodes > must be capable of forming high order LSPs (FA-LSP)? If there is at least > one border node which is in-capable of supporting FA-LSP, the R1 to R2 LSP > will fail? > > I am looking for a solution which does not use the FA-LSP and looks like > there is none... > > Please correct me if my interpretation is wrong. > > Thanks, > > Vijay > > -----Original Message----- > From: John Drake [mailto:jdrake@calient.net] > Sent: Sunday, April 25, 2004 12:37 PM > To: Pandian, Vijay; 'Dimitri.Papadimitriou@alcatel.be' > Cc: ccamp@ops.ietf.org > Subject: RE: Routing and signaling across devices with different > switching cap abilities > > > Vijay, > > I'd suggest that you study > > http://www.calient.net/files/IEEEGMPLSpublished.pdf > > Thanks, > > John > > >>-----Original Message----- >>From: Pandian, Vijay [mailto:Vijay.Pandian@sycamorenet.com] >>Sent: Saturday, April 24, 2004 6:43 PM >>To: 'Dimitri.Papadimitriou@alcatel.be'; Pandian, Vijay >>Cc: ccamp@ops.ietf.org >>Subject: RE: Routing and signaling across devices with different switching >>cap abilities >> >>Dimitri, >> >>Sorry for not being very clear with my previous e-mail. >> >>Let me re-phrase my question with a different picture: >> >> OC-48 OC-192 NxOC-192 NxOC-192 OC-192 OC- >>48 >> R1 <-----> S1 <------> L1 <--------> FX <--------> L2 <------> S2 <---- >>-> >>R2 >> PSC-1 TDM LSC FSC LSC TDM >>PSC-1 >> >> >> OC-48 >> <-----> TE-Links >> >> >>R1 and R2 are routers that advertise TE-LSA's with PSC-1 as the Switching >>Capability (SC) for the TE-Links to S1 and S2. >> >>S1 and S2 are two High Order (at STS-1/STM-0 level) grooming switches that >>are in-capable of transparently switching a port/lambda (i.e., Section and >>Line OH bytes are terminated and re-generated). S1 and S2 thus advertise >>TE-LSA's with TDM as the SC for all their TE-Links in this picture. >> >>L1 and L2 are two OXC's that advertise TE-LSA's with LSC as the SC for all >>their TE-Links in this picture. >> >>FX is a PXC that advertise TE-LSA's with FSC as the SC for its TE-Links in >>this picture. >> >>This should be a valid configuration, right? Do we need any additional >>SC's >>in the TE-LSA's? >> >>Given this combination of TE-LSA's, will R1 be able to compute a path to >>R2? >> >>If R1 could successfully compute a PATH, what is the expected "LSP-Enc. >>Type", and "Switching Type" in the Generalized Label Request Object for >>each >>LINK? >> >> R1 ---> S1: SDH/SONET(5) and TDM (100) with "timeslot" as the label? >> >> S1 ---> L1: Lambda(8) and LSC(150) with "port" as the label? >> >> L1 ---> FX: Fiber(9) and FSC(200) with "port" as the label? >> >> FX ---> L2: Fiber(9) and FSC(200) with "port" as the label? >> >> L2 ---> S2: Lambda(8) and LSC(150) with "port" as the label? >> >> S2 ---> R2: SDH/SONET(5) and TDM (100) with "timeslot" as the label? >> >>How about the G-PID? Does it change as well? >> >>How about the Bandwidth Encoding? R1 may ask for an OC-48. Assume S1 is >>incapable of supporting FA-LSP, can the Bandwidth remain as OC-48 for the >>S1 >>---> L1 Link? >> >>Thanks, >> >>Vijay >> >> >>>-----Original Message----- >>>From: Dimitri.Papadimitriou@alcatel.be >>>[mailto:Dimitri.Papadimitriou@alcatel.be] >>>Sent: Saturday, April 24, 2004 4:18 AM >>>To: Pandian, Vijay >>>Cc: ccamp@ops.ietf.org >>>Subject: Re: Routing and signaling across devices with different >>>switching cap abilities >>> >>> >>>hi, >>> >>>Pandian, Vijay wrote: >>> >>>>Consider a mix of devices with varying switching >>> >>>capabilities connected as >>> >>>>follows: >>>> >>>> PSC-1 <===> TDM-1 <===> LSC-1 <===> FSC <===> LSC-2 >>> >>><===> TDM-2 <===> >>> >>>>PSC-2 >>>> >>>>Is it fair to assume that PSC-1 and PSC-2 would advertise >>> >>>TE-LSA's with >>> >>>>"PSC" as the switching capability, TDM-1 and TDM-2 would >>> >>>advertise TE-LSA's >>> >>>>with "TDM" as the switching capability, LSC-1 and LSC-2 >>> >>>would advertise >>> >>>>TE-LSA's with "LSC" as the switching capability...? >>> >>>what "fair" means in this context ? further the hierarchy refers >>>to region boundaries as follows: >>> >>>PSC-1 < PSC-2 < PSC-3 < PSC-4 < L2SC < TDM < LSC < FSC >>> >>>so assuming you're using different values (non-reported in gmpls- >>>routing see below) for TDM and LSC, GMPLS mandates that for inst. >>>you're crossing region boundary at [TDM,LSC] the LSR at the edge >>>of the TDM region must capable to find [LSC,TDM], and if such >>>boundary doesn't exist it is fair to assume that the LSP will not >>>be established - note that we've specific values for L2SC (51), >>>TDM (100), LSC (150) and FSC (200) so what are you inferring with >>>TDM-1 and TDM-2 ? >>> >>> >>>>Given this, would the PSC device (say PSC-1) be able to >>> >>>compute a path using >>> >>>>CSPF to PSC-2? >>> >>>well why don't you use the value defined in gmpls-routing, instead >>>of trying to assess a rule for SC relationship that doesn't exist ? >>> >>> >>>>There had been some discussion regarding the type of label >>> >>>(SUKLM vs. lambda >>> >>>>vs. port) to be used across these switching capabilities. >>> >>>How about the >>> >>>>"LSP-Enc. Type", and "Switching Type" in the Generalized >>> >>>Label Request >>> >>>>Object? How about the Bandwidth Encoding in the >>> >>>SENDER_TSPEC and FLOWSPEC >>> >>>>object? >>> >>>what's more precisely the question here ? >>> >>> >>>>According to rfc3471, section 3.1.1, the switching type is >>> >>>expected to map >>> >>>>to one of the values advertised for the corresponding link. >>> >>>In that case, >>> >>>>would the LSC-device accept a Generalized Label Request >>> >>>with TDM switching >>> >>>>capability and "port" as the label coming from the TDM >>> >>>capable device? >>> >>>i think we've sorted out this issue, during our previous discussion, >>>and the response is "the LSC interface accepts a Generalized Label >>>Request with LSC switching capability and "port" as the label coming >>>from the TDM capable device" i guess you mean when crossing the >>>[TDM,LSC] boundary >>> >>> >>>>Any clarification on this is appreciated... >>>> >>>>Thanks, >>>> >>>>Vijay >>>> >>>>PS: During various GMPLS interop events, an additional FSC >>> >>>(and LSC?) >>> >>>>switching capability in the TE-LSA's was required for the >>> >>>end devices to >>> >>>>compute path. >>> >>>yes, because some people didn't quite accurately translated the term >>>"port" in their implementation ("port" =/= "physical port" such as a >>>fiber), but as discussed this is erroneous >>> >>>hope this clarifies, >>>- dimitri. >>>-- >>>Papadimitriou Dimitri >>>E-mail : dimitri.papadimitriou@alcatel.be >>>E-mail : dpapadimitriou@psg.com >>>Webpage: http://psg.com/~dpapadimitriou/ >>>Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium >>>Phone : +32 3 240-8491 >>> >>> -- Papadimitriou Dimitri E-mail : dimitri.papadimitriou@alcatel.be E-mail : dpapadimitriou@psg.com Webpage: http://psg.com/~dpapadimitriou/ Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium Phone : +32 3 240-8491 From owner-ccamp@ops.ietf.org Tue Apr 27 04:29:02 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13933 for ; Tue, 27 Apr 2004 04:29:02 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BINxe-0003ya-Pd for ccamp-archive@ietf.org; Tue, 27 Apr 2004 04:29:02 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BINwf-0003nd-00 for ccamp-archive@ietf.org; Tue, 27 Apr 2004 04:28:02 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BINw7-0003cv-00 for ccamp-archive@ietf.org; Tue, 27 Apr 2004 04:27:27 -0400 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BINgQ-000JeH-9U for ccamp-data@psg.com; Tue, 27 Apr 2004 08:11:14 +0000 Received: from [195.101.245.15] (helo=p-mail1.rd.francetelecom.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BINgO-000Jdr-Mv for ccamp@ops.ietf.org; Tue, 27 Apr 2004 08:11:12 +0000 Received: from lanmhs30.rd.francetelecom.fr ([10.193.21.61]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 27 Apr 2004 09:51:29 +0200 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 : RE : RE : Proposed strategy for Inter-area/AS X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Date: Tue, 27 Apr 2004 09:51:25 +0200 Message-ID: Thread-Topic: RE : RE : Proposed strategy for Inter-area/AS Thread-Index: AcQrsFwlWMHEGZuKRKOE1ikEaqHqJgAeTYVw From: "LE ROUX Jean-Louis FTRD/DAC/LAN" To: "ricciato" Cc: , X-OriginalArrivalTime: 27 Apr 2004 07:51:29.0595 (UTC) FILETIME=[733060B0:01C42C2C] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Hi Fabio and all, I see what you suggest, but IMHO this would not be sufficient, as an LSP = affinity can be a combination of colors inclusion/exclusion Using your proposed advertisement, there is no mean to know that there = is no path through the ABR, for an LSP bw=3D50M and affinity =3D exclude red & blue. Basically, IMHO in case you have N paths, each with a distinct = adm-group, the only solution, if you want to compute an optimal path using this approach, is to advertise N virtual = links. Note that an ABR would have to compute and advertise many paths to many = potential destinations,=20 This may generate higher flooding than the direct advertisement of = TE-links... and you are likely to loose all the interest for area partitionning. Cheers, JL > -----Message d'origine----- > De : ricciato [mailto:ricciato@coritel.it]=20 > Envoy=E9 : lundi 26 avril 2004 18:59 > =C0 : LE ROUX Jean-Louis FTRD/DAC/LAN > Cc : adrian@olddog.co.uk; ccamp@ops.ietf.org > Objet : Re: RE : RE : Proposed strategy for Inter-area/AS >=20 >=20 > Dear JL, >=20 > you=B4re right. >=20 > Just a quick proposal. > In an attempt to limit the number of virtual link advertised,=20 > would it make sense to advertise only K virtual links, where=20 > K=3D{number=20 > of colors}, and for each of them (say j) advertise the maximum=20 > bandwdith over all links that have color j into their admin_group ? >=20 > For example, in your example (with Path 4 added) >=20 > Path 1: bw 100M admin group {green;blue} > Path 2: bw 50M admin group {red; blue} > Path 3: bw 5M admin group {red;green} > Path 4: bw 50M admin group {red} >=20 > One should advertise=20 > Virtual Link 1: bw 100M admin group {green} --->max(100M,5M)=20 > Virtual Link 2: bw 50M admin group {red} --->max(50M,5M,50M)=20 > Virtual Link 3: bw 100M admin group {gblue} --->max(100M,50M) >=20 >=20 > Assuming that the number of colors << number of possible=20 > links, this approach might cap the amount of advertisement. >=20 > But I=B4m not sure it works ...=20 >=20 > ciao > fabio >=20 > LE ROUX Jean-Louis FTRD/DAC/LAN wrote: >=20 > >Hi Fabio, > > > >Advertising only a subset would improve scalability, but > >this would not be enough to correclty select the best path. > > > >Let's assume that there are three paths from a given ABR X=20 > to a given=20 > >destination D Path 1: bw 100M admin group {green;blue} Path=20 > 2: bw 50M=20 > >admin group {red; blue} Path 3: bw 5M admin group {red;green} > > > >and a TE-LSP L : Destination D, bw=3D 4M, affinity=3D exlude blue > > > >If you advertise only Path 1 and Path 2 as virtual links, ABR X will=20 > >never be selected as next ABR for this TE-LSP, while path 3 is a=20 > >feasible path. > > > >Regards > > > >JL > > > > > > > > =20 > > > >>-----Message d'origine----- > >>De : owner-ccamp@ops.ietf.org > >>[mailto:owner-ccamp@ops.ietf.org] De la part de ricciato > >>Envoy=E9 : lundi 26 avril 2004 09:48 > >>=C0 : LE ROUX Jean-Louis FTRD/DAC/LAN > >>Cc : adrian@olddog.co.uk; ccamp@ops.ietf.org > >>Objet : Re: RE : Proposed strategy for Inter-area/AS > >> > >> > >>Hi JL, > >> > >>just a quick remark: would it make sense in this case to > >>advertise only=20 > >>a selected subset of the N virtual links (say the two with=20 > >>most residual=20 > >>bw) ? > >> > >>ciao > >>fabio > >> > >>LE ROUX Jean-Louis FTRD/DAC/LAN wrote: > >> > >> =20 > >> > >>>Let's assume that there are N distinct paths from ABR A to a > >>>destination X, each with a distinct bandwidth and distinct=20 > >>> =20 > >>> > >>admin-group > >> =20 > >> > >>>(a path admin group being expressed as a logical AND of the > >>> =20 > >>> > >>link admin > >> =20 > >> > >>>groups along the path) How can you summarize such topology ? > >>> =20 > >>> > >>Actually > >> =20 > >> > >>>you need to advertise N virtual links, each with a distinct > >>> =20 > >>> > >>admin-group > >> =20 > >> > >>>and available bandwidth. > >>> > >>> > >>>=20 > >>> > >>>=20 > >>> > >>> =20 > >>> > >> > >> =20 > >> > > > > > > =20 > > >=20 >=20 From owner-ccamp@ops.ietf.org Tue Apr 27 05:56:49 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17861 for ; Tue, 27 Apr 2004 05:56:49 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIPKc-0005aX-9q for ccamp-archive@ietf.org; Tue, 27 Apr 2004 05:56:50 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIPJn-0005OB-00 for ccamp-archive@ietf.org; Tue, 27 Apr 2004 05:56:00 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BIPIy-0005AU-00 for ccamp-archive@ietf.org; Tue, 27 Apr 2004 05:55:08 -0400 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BIOvo-0004Lv-BO for ccamp-data@psg.com; Tue, 27 Apr 2004 09:31:12 +0000 Received: from [195.8.69.15] (helo=oceanus.uk.clara.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BIOvm-0004LO-P2; Tue, 27 Apr 2004 09:31:10 +0000 Received: from claranet by oceanus.uk.clara.net with local (Exim 4.22) id 1BIOvq-000Pb8-Js; Tue, 27 Apr 2004 10:31:14 +0100 From: "Adrian Farrel" To: zinin@psg.com Cc: ccamp@ops.ietf.org, adrian@olddog.co.uk Reply-To: adrian@olddog.co.uk Subject: Overlay draft ready for IESG consideration Date: Tue, 27 Apr 2004 10:31:14 +0100 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Remote_Addr: 156.106.228.13 Message-Id: Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Alex, draft-ietf-ccamp-gmpls-overlay-04.txt has been reviewed by the CCAMP WG and marked up after WG last call. Can you please move it forward on the standards track. Note, this is one of the relatively few CCAMP drafts that is blocking a large number of items on the RFC editor's queue. Thanks, Adrian ----- Original Message ----- From: To: Cc: Sent: Monday, April 26, 2004 8:25 PM Subject: I-D ACTION:draft-ietf-ccamp-gmpls-overlay-04.txt > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. > > Title : GMPLS RSVP Support for the Overlay Model > Author(s) : G. Swallow, et al. > Filename : draft-ietf-ccamp-gmpls-overlay-04.txt > Pages : 12 > Date : 2004-4-26 > > Generalized MPLS defines both routing and signaling protocols for the > creation of Label Switched Paths (LSPs) in various transport > technologies. These protocols can be used to support a number of > deployment scenarios. This memo addresses the application of GMPLS > to the overlay model. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-overlay-04.txt From owner-ccamp@ops.ietf.org Tue Apr 27 07:00:52 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22092 for ; Tue, 27 Apr 2004 07:00:52 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIQKb-0003wS-3u for ccamp-archive@ietf.org; Tue, 27 Apr 2004 07:00:53 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIQJb-0003kW-00 for ccamp-archive@ietf.org; Tue, 27 Apr 2004 06:59:52 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BIQJO-0003Yf-00 for ccamp-archive@ietf.org; Tue, 27 Apr 2004 06:59:38 -0400 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BIQ3e-000Ft7-90 for ccamp-data@psg.com; Tue, 27 Apr 2004 10:43:22 +0000 Received: from [128.130.90.21] (helo=publications.ftw.tuwien.ac.at) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BIQ3b-000Fsj-5J for ccamp@ops.ietf.org; Tue, 27 Apr 2004 10:43:20 +0000 Received: from nt_ftw.ftw.tuwien.ac.at by publications.ftw.tuwien.ac.at via smtpd (for psg.com [147.28.0.62]) with ESMTP; Tue, 27 Apr 2004 12:56:36 +0100 Received: from coritel.it (spirit.ftw.at [192.168.0.19]) by nt_ftw.ftw.at with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 20F8Q7QW; Tue, 27 Apr 2004 12:42:39 +0200 Message-ID: <408E3945.3030601@coritel.it> Date: Tue, 27 Apr 2004 12:43:17 +0200 From: ricciato User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030821 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dimitri.Papadimitriou@alcatel.be CC: ugo monaco , ccamp , Zafar Ali Subject: Re: Diverse path failure and optimality in draft-dachille-inter-area-path-protection References: <408C5733.1000708@infocom.uniroma1.it> <408D12E3.5030806@alcatel.be> In-Reply-To: <408D12E3.5030806@alcatel.be> X-Enigmail-Version: 0.76.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 8bit Hi Dimitri, thanks for your comments, see inline. ciao Fabio Dimitri.Papadimitriou@alcatel.be wrote: > > hi, by discussing the proposed method there seems to be three issues > that make the method questionable in terms of guarantee to deliver > what it intends to deliver, its usability (the time validity of the > path is not guaranteed) and its applicability in terms of objective > initially targeted wrt to the network topology > > 1) imagine three areas decoupled computation as explained at their > respective ingress, with ARO method; how the third computation element > (tail-end) is aware of srlg's that may affect a link selected in the > head-end area > > example: link 1 is selected in area 1 (head-end) with srlg 1, link 2 is > selected in in area 2 with srlg 2, and link 3 in area 3 (tail-end) with > srlg 3 and 1 (since the tail end doesn't know that srlg 1 is associated > to link 1 in addition to its association to link 3 even if it knows that > the link 1 has been selected for the ARO) the problem is that you can > not retrieve such kind of error (except but how practical is it if one > start cumulating all this information between computation points) You´re rising this problem with SRLGs spanning non-adjacent areas. First, I do not know if this is a common case in practical scenarios. Can other ccampers comment on that ? Second, IMHO this case is hard to handle for _any_ distributed scheme, in lack of any exchange of info between computation points about srlg spanning multiple area. For instance, I´m wondering if the sequential computation with RRO+XRO (as alternatve to parallel computation with ARO) can handle this scenario, or not. Could you comment on that ? > 2) resource contention, the secondary path may never be established > since the computation point as *no* capability to make any reservation > on it (except from the first segment) since by definition "disjoint" - > it simply becomes a kind of "best effort" secondary path (in the sense > use it if no other reservation are making use of these links) In the parallel approach with ARO, during the first phase the primary LSP is establisehed (including bw reservation), while for the secondary only the path is computed. This computation is base on the topology / load information available at the computation point, so that link without enough bw are pinned out and can not be included in the primary nor the secondary LSP. In a successive phase, the secondary LSP is reserved along the secondary path. What can happen is a race condition, where the bw along the secondary is available during the 1st phase, but not during the 2nd phase, since some other reservation occurred in between the two along some secondary link. If this occurr, the secondary path can not be established, and maybe all the signaling procedure has to be repeated, for primary for secondary. (btw, let me expand in a separate mail the discussion about the case of unsuccesful computation, which was also raised by others ) First, I remark that this time window in which the race can occurr is really short, in the order of one PATH/RESV round trip time, and since hopefully you´re not going to operate your network at it´s capacity limit, the probability of failing signaling due to a race should be really small. Second, I think that races are a well-known problem common to _all_ distributed computation/reservation schemes, i.e. not specific to parallel computation with ARO (incidentally, I note that RSVP itself is prone to race since the path computation occurss in the downstream PATH messages, while the bw reservation is applied during the upstream RESV messages). > > 3) the method seems to raise additional issues when the number of > potential entry point for the secondary disjoint path increases, at > each step of the computation (otherwise the method wouldn't provide > what it intends to deliver) It is not clear to me what are exactly these additional issues, maybe you´d like to provide some more concrete example. In general, my feeling is, again, that such issue might be non-specific to the parallel computation scheme, but rather common to any dstributed scheme. However, there was a point raised by Adrian that might have some relationship to the choice of the entry-point for the secondary path. If this is the case, you might find some interesting hints in my previous mail (posted Mon, 19 Apr 2004, http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00474.html ... sorry it´s so long :-) As a last but important remark, let me suggest to distnguish the problems that are intrinsic to _all_ distributed diverse path computation schemes, from those that are specific to one scheme (e.g. parallel comp. with ARO). Both are important of course, but it would be beneficial to the discussion to clearly separate them in different tracks in the ml. I´d solicit other ccamp-ers also to comment on that. From owner-ccamp@ops.ietf.org Tue Apr 27 11:28:15 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07299 for ; Tue, 27 Apr 2004 11:28:15 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIUVL-0005ov-HJ for ccamp-archive@ietf.org; Tue, 27 Apr 2004 11:28:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIUUL-0005kw-00 for ccamp-archive@ietf.org; Tue, 27 Apr 2004 11:27:14 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BIUTn-0005go-00 for ccamp-archive@ietf.org; Tue, 27 Apr 2004 11:26:39 -0400 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BIUBB-00074l-KI for ccamp-data@psg.com; Tue, 27 Apr 2004 15:07:25 +0000 Received: from [209.183.201.132] (helo=mailsrv01.vasw) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BIUBA-00074P-C8 for ccamp@ops.ietf.org; Tue, 27 Apr 2004 15:07:24 +0000 Received: by mailsrv01.vasw with Internet Mail Service (5.5.2657.72) id ; Tue, 27 Apr 2004 11:02:23 -0400 Message-ID: <35800AB26A91D711A75D00B0D07935F31AD35E@mailsrv01.vasw> From: "Balasubramania N. Pillai" To: "'Dimitri.Papadimitriou@alcatel.be'" Cc: "'ccamp@ops.ietf.org'" Subject: RE: Basic doubts on 1:1 path protection signaling. Date: Tue, 27 Apr 2004 11:02:22 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Thanks Dimitri and John for trying to help me. Thanks for the detailed reply. I am clear on the first two questions. But I am still a little bit confused with my third question. May be I didn't understand the concept right. So let me try again. I was most confused with how do we do signaling to setup the "Extra Traffic" LSP. Are you suggesting that there is not additional signaling to setup the "Extra Traffic LSP". Setup the protection LSP along with the working LSP. At this point the two LSP are setup and the user is free to use the protection LSP to carry extra traffic. My confusion is around this issue. Once the protection LSP is setup, do we need to do extra signaling to setup the "Extra Traffic LSP" on top of the protection LSP. Thanks in advance for you help. Balu -----Original Message----- From: Dimitri.Papadimitriou@alcatel.be [mailto:Dimitri.Papadimitriou@alcatel.be] Sent: Tuesday, April 27, 2004 3:13 AM To: Balasubramania N. Pillai Cc: 'ccamp@ops.ietf.org' Subject: Re: Basic doubts on 1:1 path protection signaling. Balasubramania N. Pillai wrote: > Hi All, > > I was reading the draft-ietf-ccamp-gmpls-recovery-e2e-signaling-00.txt and I > have some basic doubts regarding signaling 1:1 protected LSP with extra > traffic. > > > 1. My understanding is that Section 7 talks about 1:1 Protection (the > protection path is fully setup and cross-connects are made) and not 1:1 > Restoration (no cross-connects for protection path) as the title indicates and explained in the text > 2. Since the protection LSP is setup (cross-connected), I guess we should > advertise that the resources used by the Protection LSP as "in use" in > routing. if it is cross-connected it is "in use" > 3. Section 7, Paragraph 3 says that > > Although the resources for the protecting LSP are pre-allocated, > preemptable traffic may be carried end-to-end using this LSP (i.e. > the protecting LSP is capable of carrying extra-traffic) with the > caveat that this traffic will be preempted if the working LSP fails. > > Take the case where a 1:1 LSP is setup. Both the working LSP and the > protection LSP are setup and cross-connected. Now if we want to add a > extra-traffic, how do we signal, to setup the LSP carrying the Extra > traffic. the protecting lsp allows carrying extra-traffic (in a sense you may see for the 1:1 protection case, the protecting lsp as the "extra-traffic lsp" but this terminology is misleading reason why it is not used) > What objects do we use to associate the "Extra Traffic LSP" to the > protection LSP. the association object is used to bind the protected and the protecting lsp hope this clarifies (note: an update is being prepared to further clarify some of the comments made on the list) thanks, - dimitri > Thanks for you time > > Balu > > > > -- Papadimitriou Dimitri E-mail : dimitri.papadimitriou@alcatel.be E-mail : dpapadimitriou@psg.com Webpage: http://psg.com/~dpapadimitriou/ Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium Phone : +32 3 240-8491 From owner-ccamp@ops.ietf.org Tue Apr 27 11:58:52 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08879 for ; Tue, 27 Apr 2004 11:58:52 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIUyy-0000Dn-An for ccamp-archive@ietf.org; Tue, 27 Apr 2004 11:58:52 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIUxy-00003u-00 for ccamp-archive@ietf.org; Tue, 27 Apr 2004 11:57:51 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BIUwl-0007fQ-00 for ccamp-archive@ietf.org; Tue, 27 Apr 2004 11:56:35 -0400 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BIUgP-000Bc4-5e for ccamp-data@psg.com; Tue, 27 Apr 2004 15:39:41 +0000 Received: from [62.23.212.165] (helo=smail.alcatel.fr) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BIUgO-000Bbm-0d for ccamp@ops.ietf.org; Tue, 27 Apr 2004 15:39:40 +0000 Received: from bemail05.netfr.alcatel.fr (bemail05.netfr.alcatel.fr [155.132.251.11]) by smail.alcatel.fr (ALCANET/NETFR) with ESMTP id i3RFda0O015945; Tue, 27 Apr 2004 17:39:36 +0200 Received: from alcatel.be ([138.203.118.2]) by bemail05.netfr.alcatel.fr (Lotus Domino Release 5.0.11) with ESMTP id 2004042717393362:3704 ; Tue, 27 Apr 2004 17:39:33 +0200 Message-ID: <408E7F4D.4010506@alcatel.be> Date: Tue, 27 Apr 2004 17:42:05 +0200 From: Dimitri.Papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.5) Gecko/20030925 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Balasubramania N. Pillai" CC: "'ccamp@ops.ietf.org'" Subject: Re: Basic doubts on 1:1 path protection signaling. References: <35800AB26A91D711A75D00B0D07935F31AD35E@mailsrv01.vasw> In-Reply-To: <35800AB26A91D711A75D00B0D07935F31AD35E@mailsrv01.vasw> X-MIMETrack: Itemize by SMTP Server on BEMAIL05/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 04/27/2004 17:39:34, Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 04/27/2004 17:39:35, Serialize complete at 04/27/2004 17:39:35 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed X-Alcanet-MTA-scanned-and-authorized: yes Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Balasubramania N. Pillai wrote: > Thanks Dimitri and John for trying to help me. > > Thanks for the detailed reply. I am clear on the first two questions. But I > am still a little bit confused with my third question. May be I didn't > understand the concept right. So let me try again. > > I was most confused with how do we do signaling to setup the "Extra Traffic" > LSP. Are you suggesting that there is not additional signaling to setup the > "Extra Traffic LSP". Setup the protection LSP along with the working LSP. At > this point the two LSP are setup and the user is free to use the protection > LSP to carry extra traffic. > > My confusion is around this issue. Once the protection LSP is setup, do we > need to do extra signaling to setup the "Extra Traffic LSP" on top of the > protection LSP. as the protecting LSP is activated you don't need such operation which is performed during the signaling phase (as said in section 7: "working and protecting LSPs are signaled as primary LSPs; both are fully instantiated during the provisioning phase. [..] preemptable traffic may be carried end-to-end using this (read: protecting) LSP (i.e. the protecting LSP is capable of carrying extra-traffic)" > Thanks in advance for you help. > > Balu > > > > > -----Original Message----- > From: Dimitri.Papadimitriou@alcatel.be > [mailto:Dimitri.Papadimitriou@alcatel.be] > Sent: Tuesday, April 27, 2004 3:13 AM > To: Balasubramania N. Pillai > Cc: 'ccamp@ops.ietf.org' > Subject: Re: Basic doubts on 1:1 path protection signaling. > > > > > Balasubramania N. Pillai wrote: > >>Hi All, >> >>I was reading the draft-ietf-ccamp-gmpls-recovery-e2e-signaling-00.txt and > > I > >>have some basic doubts regarding signaling 1:1 protected LSP with extra >>traffic. >> >> >>1. My understanding is that Section 7 talks about 1:1 Protection (the >>protection path is fully setup and cross-connects are made) and not 1:1 >>Restoration (no cross-connects for protection path) > > > as the title indicates and explained in the text > > >>2. Since the protection LSP is setup (cross-connected), I guess we should >>advertise that the resources used by the Protection LSP as "in use" in >>routing. > > > if it is cross-connected it is "in use" > > >>3. Section 7, Paragraph 3 says that >> >> Although the resources for the protecting LSP are pre-allocated, >> preemptable traffic may be carried end-to-end using this LSP (i.e. >> the protecting LSP is capable of carrying extra-traffic) with the >> caveat that this traffic will be preempted if the working LSP fails. >> >>Take the case where a 1:1 LSP is setup. Both the working LSP and the >>protection LSP are setup and cross-connected. Now if we want to add a >>extra-traffic, how do we signal, to setup the LSP carrying the Extra >>traffic. > > > the protecting lsp allows carrying extra-traffic (in a sense you may see > for the 1:1 protection case, the protecting lsp as the "extra-traffic > lsp" but this terminology is misleading reason why it is not used) > > >>What objects do we use to associate the "Extra Traffic LSP" to the >>protection LSP. > > > the association object is used to bind the protected and the protecting lsp > > hope this clarifies (note: an update is being prepared to further > clarify some of the comments made on the list) > > thanks, > - dimitri > >>Thanks for you time >> >>Balu >> >> >> >> > > -- Papadimitriou Dimitri E-mail : dimitri.papadimitriou@alcatel.be E-mail : dpapadimitriou@psg.com Webpage: http://psg.com/~dpapadimitriou/ Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium Phone : +32 3 240-8491 From owner-ccamp@ops.ietf.org Tue Apr 27 12:36:58 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10805 for ; Tue, 27 Apr 2004 12:36:57 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIVZq-0002SG-2L for ccamp-archive@ietf.org; Tue, 27 Apr 2004 12:36:58 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIVYx-0002PM-00 for ccamp-archive@ietf.org; Tue, 27 Apr 2004 12:36:04 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BIVY7-0002M7-00 for ccamp-archive@ietf.org; Tue, 27 Apr 2004 12:35:11 -0400 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BIVK7-000IjH-GF for ccamp-data@psg.com; Tue, 27 Apr 2004 16:20:43 +0000 Received: from [66.163.168.179] (helo=smtp800.mail.sc5.yahoo.com) by psg.com with smtp (Exim 4.30; FreeBSD) id 1BIVK6-000Ij2-9N for ccamp@ops.ietf.org; Tue, 27 Apr 2004 16:20:42 +0000 Received: from unknown (HELO RAKHILAPTOP) (vishal.sharma@sbcglobal.net@67.117.148.20 with login) by smtp800.mail.sc5.yahoo.com with SMTP; 27 Apr 2004 16:20:40 -0000 Reply-To: From: "Vishal Sharma" To: , "Balasubramania N. Pillai" , Subject: RE: Basic doubts on 1:1 path protection signaling. Date: Tue, 27 Apr 2004 09:20:27 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <408E7F4D.4010506@alcatel.be> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Dimitri, Balu, Good discussion/clarification. A question in-line. -Vishal > -----Original Message----- > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On > Behalf Of Dimitri.Papadimitriou@alcatel.be > Sent: Tuesday, April 27, 2004 8:42 AM > To: Balasubramania N. Pillai > Cc: 'ccamp@ops.ietf.org' > Subject: Re: Basic doubts on 1:1 path protection signaling. > > > > > Balasubramania N. Pillai wrote: > > Thanks Dimitri and John for trying to help me. > > > > Thanks for the detailed reply. I am clear on the first two > questions. But I > > am still a little bit confused with my third question. May be I didn't > > understand the concept right. So let me try again. > > > > I was most confused with how do we do signaling to setup the > "Extra Traffic" > > LSP. Are you suggesting that there is not additional signaling > to setup the > > "Extra Traffic LSP". Setup the protection LSP along with the > working LSP. At > > this point the two LSP are setup and the user is free to use > the protection > > LSP to carry extra traffic. > > > > My confusion is around this issue. Once the protection LSP is > setup, do we > > need to do extra signaling to setup the "Extra Traffic LSP" on > top of the > > protection LSP. > > as the protecting LSP is activated you don't need such operation which > is performed during the signaling phase (as said in section 7: "working > and protecting LSPs are signaled as primary LSPs; both are fully > instantiated during the provisioning phase. [..] preemptable traffic may > be carried end-to-end using this (read: protecting) LSP (i.e. the > protecting LSP is capable of carrying extra-traffic)" This seems to make the assumption that the extra-traffic LSP will be between the same ingress/egress point as the original working LSP. In general, when using the capacity of the protection path in 1:1 protection for extra-traffic this is not really needed. It should be possible for extra-traffic to use only a segment of the protection LSP. Indeed, several extra-traffic LSPs may be use the capacity of the protection LSP, each using a different segment. (In fact, this is what I thought the P&R analysis/terminology drafts described, when I last looked at them.) Is this not supported by the scheme in the e2e draft? > > -----Original Message----- > > From: Dimitri.Papadimitriou@alcatel.be > > [mailto:Dimitri.Papadimitriou@alcatel.be] > > Sent: Tuesday, April 27, 2004 3:13 AM > > To: Balasubramania N. Pillai > > Cc: 'ccamp@ops.ietf.org' > > Subject: Re: Basic doubts on 1:1 path protection signaling. > > > > > > > > > > Balasubramania N. Pillai wrote: > > > >>Hi All, > >> > >>I was reading the > draft-ietf-ccamp-gmpls-recovery-e2e-signaling-00.txt and > > > > I > > > >>have some basic doubts regarding signaling 1:1 protected LSP with extra > >>traffic. > >> > >> > >>1. My understanding is that Section 7 talks about 1:1 Protection (the > >>protection path is fully setup and cross-connects are made) and not 1:1 > >>Restoration (no cross-connects for protection path) > > > > > > as the title indicates and explained in the text > > > > > >>2. Since the protection LSP is setup (cross-connected), I guess > we should > >>advertise that the resources used by the Protection LSP as "in use" in > >>routing. > > > > > > if it is cross-connected it is "in use" > > > > > >>3. Section 7, Paragraph 3 says that > >> > >> Although the resources for the protecting LSP are pre-allocated, > >> preemptable traffic may be carried end-to-end using this LSP (i.e. > >> the protecting LSP is capable of carrying extra-traffic) with the > >> caveat that this traffic will be preempted if the working LSP fails. > >> > >>Take the case where a 1:1 LSP is setup. Both the working LSP and the > >>protection LSP are setup and cross-connected. Now if we want to add a > >>extra-traffic, how do we signal, to setup the LSP carrying the Extra > >>traffic. > > > > > > the protecting lsp allows carrying extra-traffic (in a sense > you may see > > for the 1:1 protection case, the protecting lsp as the "extra-traffic > > lsp" but this terminology is misleading reason why it is not used) > > > > > >>What objects do we use to associate the "Extra Traffic LSP" to the > >>protection LSP. > > > > > > the association object is used to bind the protected and the > protecting lsp > > > > hope this clarifies (note: an update is being prepared to further > > clarify some of the comments made on the list) > > > > thanks, > > - dimitri > > > >>Thanks for you time > >> > >>Balu > >> > >> > >> > >> > > > > > > -- > Papadimitriou Dimitri > E-mail : dimitri.papadimitriou@alcatel.be > E-mail : dpapadimitriou@psg.com > Webpage: http://psg.com/~dpapadimitriou/ > Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium > Phone : +32 3 240-8491 > From owner-ccamp@ops.ietf.org Tue Apr 27 12:44:33 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11750 for ; Tue, 27 Apr 2004 12:44:32 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIVhA-0003b7-Qk for ccamp-archive@ietf.org; Tue, 27 Apr 2004 12:44:32 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIVf0-0003Cg-00 for ccamp-archive@ietf.org; Tue, 27 Apr 2004 12:42:18 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BIVcf-0002kT-00 for ccamp-archive@ietf.org; Tue, 27 Apr 2004 12:39:53 -0400 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BIVNj-000JE1-9T for ccamp-data@psg.com; Tue, 27 Apr 2004 16:24:27 +0000 Received: from [62.23.212.165] (helo=smail.alcatel.fr) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BIVNi-000JDl-4O for ccamp@ops.ietf.org; Tue, 27 Apr 2004 16:24:26 +0000 Received: from bemail05.netfr.alcatel.fr (bemail05.netfr.alcatel.fr [155.132.251.11]) by smail.alcatel.fr (ALCANET/NETFR) with ESMTP id i3RGOF0O002898; Tue, 27 Apr 2004 18:24:16 +0200 Received: from alcatel.be ([138.203.118.2]) by bemail05.netfr.alcatel.fr (Lotus Domino Release 5.0.11) with ESMTP id 2004042718241416:3882 ; Tue, 27 Apr 2004 18:24:14 +0200 Message-ID: <408E89C4.205@alcatel.be> Date: Tue, 27 Apr 2004 18:26:44 +0200 From: Dimitri.Papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.5) Gecko/20030925 X-Accept-Language: en-us, en MIME-Version: 1.0 To: v.sharma@ieee.org Cc: "Balasubramania N. Pillai" , ccamp@ops.ietf.org Subject: Re: Basic doubts on 1:1 path protection signaling. References: In-Reply-To: X-MIMETrack: Itemize by SMTP Server on BEMAIL05/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 04/27/2004 18:24:14, Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 04/27/2004 18:24:15, Serialize complete at 04/27/2004 18:24:15 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed X-Alcanet-MTA-scanned-and-authorized: yes Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit just read the next section 8. Vishal Sharma wrote: > Dimitri, Balu, > > Good discussion/clarification. A question in-line. > > -Vishal > > >>-----Original Message----- >>From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On >>Behalf Of Dimitri.Papadimitriou@alcatel.be >>Sent: Tuesday, April 27, 2004 8:42 AM >>To: Balasubramania N. Pillai >>Cc: 'ccamp@ops.ietf.org' >>Subject: Re: Basic doubts on 1:1 path protection signaling. >> >> >> >> >>Balasubramania N. Pillai wrote: >> >>>Thanks Dimitri and John for trying to help me. >>> >>>Thanks for the detailed reply. I am clear on the first two >> >>questions. But I >> >>>am still a little bit confused with my third question. May be I didn't >>>understand the concept right. So let me try again. >>> >>>I was most confused with how do we do signaling to setup the >> >>"Extra Traffic" >> >>>LSP. Are you suggesting that there is not additional signaling >> >>to setup the >> >>>"Extra Traffic LSP". Setup the protection LSP along with the >> >>working LSP. At >> >>>this point the two LSP are setup and the user is free to use >> >>the protection >> >>>LSP to carry extra traffic. >>> >>>My confusion is around this issue. Once the protection LSP is >> >>setup, do we >> >>>need to do extra signaling to setup the "Extra Traffic LSP" on >> >>top of the >> >>>protection LSP. >> >>as the protecting LSP is activated you don't need such operation which >>is performed during the signaling phase (as said in section 7: "working >>and protecting LSPs are signaled as primary LSPs; both are fully >>instantiated during the provisioning phase. [..] preemptable traffic may >>be carried end-to-end using this (read: protecting) LSP (i.e. the >>protecting LSP is capable of carrying extra-traffic)" > > > This seems to make the assumption that the extra-traffic LSP will > be between the same ingress/egress point as the original working LSP. > > In general, when using the capacity of the protection path in 1:1 protection > for extra-traffic this is not really needed. It should be possible > for extra-traffic to use only a segment of the protection LSP. > Indeed, several extra-traffic LSPs may be use the capacity of the > protection LSP, each using a different segment. > (In fact, this is what I thought the P&R analysis/terminology drafts > described, when I last looked at them.) > > Is this not supported by the scheme in the e2e draft? > > >>>-----Original Message----- >>>From: Dimitri.Papadimitriou@alcatel.be >>>[mailto:Dimitri.Papadimitriou@alcatel.be] >>>Sent: Tuesday, April 27, 2004 3:13 AM >>>To: Balasubramania N. Pillai >>>Cc: 'ccamp@ops.ietf.org' >>>Subject: Re: Basic doubts on 1:1 path protection signaling. >>> >>> >>> >>> >>>Balasubramania N. Pillai wrote: >>> >>> >>>>Hi All, >>>> >>>>I was reading the >> >>draft-ietf-ccamp-gmpls-recovery-e2e-signaling-00.txt and >> >>>I >>> >>> >>>>have some basic doubts regarding signaling 1:1 protected LSP with extra >>>>traffic. >>>> >>>> >>>>1. My understanding is that Section 7 talks about 1:1 Protection (the >>>>protection path is fully setup and cross-connects are made) and not 1:1 >>>>Restoration (no cross-connects for protection path) >>> >>> >>>as the title indicates and explained in the text >>> >>> >>> >>>>2. Since the protection LSP is setup (cross-connected), I guess >> >>we should >> >>>>advertise that the resources used by the Protection LSP as "in use" in >>>>routing. >>> >>> >>>if it is cross-connected it is "in use" >>> >>> >>> >>>>3. Section 7, Paragraph 3 says that >>>> >>>> Although the resources for the protecting LSP are pre-allocated, >>>> preemptable traffic may be carried end-to-end using this LSP (i.e. >>>> the protecting LSP is capable of carrying extra-traffic) with the >>>> caveat that this traffic will be preempted if the working LSP fails. >>>> >>>>Take the case where a 1:1 LSP is setup. Both the working LSP and the >>>>protection LSP are setup and cross-connected. Now if we want to add a >>>>extra-traffic, how do we signal, to setup the LSP carrying the Extra >>>>traffic. >>> >>> >>>the protecting lsp allows carrying extra-traffic (in a sense >> >>you may see >> >>>for the 1:1 protection case, the protecting lsp as the "extra-traffic >>>lsp" but this terminology is misleading reason why it is not used) >>> >>> >>> >>>>What objects do we use to associate the "Extra Traffic LSP" to the >>>>protection LSP. >>> >>> >>>the association object is used to bind the protected and the >> >>protecting lsp >> >>>hope this clarifies (note: an update is being prepared to further >>>clarify some of the comments made on the list) >>> >>>thanks, >>>- dimitri >>> >>> >>>>Thanks for you time >>>> >>>>Balu >>>> >>>> >>>> >>>> >>> >>> >>-- >>Papadimitriou Dimitri >>E-mail : dimitri.papadimitriou@alcatel.be >>E-mail : dpapadimitriou@psg.com >>Webpage: http://psg.com/~dpapadimitriou/ >>Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium >>Phone : +32 3 240-8491 >> > > -- Papadimitriou Dimitri E-mail : dimitri.papadimitriou@alcatel.be E-mail : dpapadimitriou@psg.com Webpage: http://psg.com/~dpapadimitriou/ Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium Phone : +32 3 240-8491 From owner-ccamp@ops.ietf.org Tue Apr 27 22:25:20 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17978 for ; Tue, 27 Apr 2004 22:25:20 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIelC-00023D-Uf for ccamp-archive@ietf.org; Tue, 27 Apr 2004 22:25:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIekF-0001w7-00 for ccamp-archive@ietf.org; Tue, 27 Apr 2004 22:24:21 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BIeje-0001pM-00 for ccamp-archive@ietf.org; Tue, 27 Apr 2004 22:23:42 -0400 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BIeUr-000LhQ-1J for ccamp-data@psg.com; Wed, 28 Apr 2004 02:08:25 +0000 Received: from [12.146.0.143] (helo=cabo.sycamorenet.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BIeUn-000Lh0-F2 for ccamp@ops.ietf.org; Wed, 28 Apr 2004 02:08:21 +0000 Received: by cabo.sycamorenet.com with Internet Mail Service (5.5.2653.19) id <26ZJF3Y8>; Tue, 27 Apr 2004 22:12:34 -0400 Message-ID: <5533E74FC0108E41A8217C0899CA56CF081E55@mach5.sycamorenet.com> From: "Pandian, Vijay" To: "'Dimitri.Papadimitriou@alcatel.be'" , "Pandian, Vijay" Cc: "'John Drake'" , ccamp@ops.ietf.org Subject: RE: Routing and signaling across devices with different switching cap abilities Date: Tue, 27 Apr 2004 22:12:33 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Dimitri, I have no concern with the existing mechanism. It seems logical to solve this using FA-LSP's. Thanks and best regards, Vijay -----Original Message----- From: Dimitri.Papadimitriou@alcatel.be [mailto:Dimitri.Papadimitriou@alcatel.be] Sent: Tuesday, April 27, 2004 3:17 AM To: Pandian, Vijay Cc: 'John Drake'; ccamp@ops.ietf.org Subject: Re: Routing and signaling across devices with different switching cap abilities vijay, would it be possible that you clarify either your concern wrt existing mechanisms or what you want to achieve when saying "I am looking for a solution which does not use the FA-LSP and looks like there is none..." what does that mean ? thanks, - dimitri. Pandian, Vijay wrote: > John, > > Thanks for the pointer to this paper. > > So, in order to provision an LSP between R1 and R2, all the Border Nodes > must be capable of forming high order LSPs (FA-LSP)? If there is at least > one border node which is in-capable of supporting FA-LSP, the R1 to R2 LSP > will fail? > > I am looking for a solution which does not use the FA-LSP and looks like > there is none... > > Please correct me if my interpretation is wrong. > > Thanks, > > Vijay > > -----Original Message----- > From: John Drake [mailto:jdrake@calient.net] > Sent: Sunday, April 25, 2004 12:37 PM > To: Pandian, Vijay; 'Dimitri.Papadimitriou@alcatel.be' > Cc: ccamp@ops.ietf.org > Subject: RE: Routing and signaling across devices with different > switching cap abilities > > > Vijay, > > I'd suggest that you study > > http://www.calient.net/files/IEEEGMPLSpublished.pdf > > Thanks, > > John > > >>-----Original Message----- >>From: Pandian, Vijay [mailto:Vijay.Pandian@sycamorenet.com] >>Sent: Saturday, April 24, 2004 6:43 PM >>To: 'Dimitri.Papadimitriou@alcatel.be'; Pandian, Vijay >>Cc: ccamp@ops.ietf.org >>Subject: RE: Routing and signaling across devices with different switching >>cap abilities >> >>Dimitri, >> >>Sorry for not being very clear with my previous e-mail. >> >>Let me re-phrase my question with a different picture: >> >> OC-48 OC-192 NxOC-192 NxOC-192 OC-192 OC- >>48 >> R1 <-----> S1 <------> L1 <--------> FX <--------> L2 <------> S2 <---- >>-> >>R2 >> PSC-1 TDM LSC FSC LSC TDM >>PSC-1 >> >> >> OC-48 >> <-----> TE-Links >> >> >>R1 and R2 are routers that advertise TE-LSA's with PSC-1 as the Switching >>Capability (SC) for the TE-Links to S1 and S2. >> >>S1 and S2 are two High Order (at STS-1/STM-0 level) grooming switches that >>are in-capable of transparently switching a port/lambda (i.e., Section and >>Line OH bytes are terminated and re-generated). S1 and S2 thus advertise >>TE-LSA's with TDM as the SC for all their TE-Links in this picture. >> >>L1 and L2 are two OXC's that advertise TE-LSA's with LSC as the SC for all >>their TE-Links in this picture. >> >>FX is a PXC that advertise TE-LSA's with FSC as the SC for its TE-Links in >>this picture. >> >>This should be a valid configuration, right? Do we need any additional >>SC's >>in the TE-LSA's? >> >>Given this combination of TE-LSA's, will R1 be able to compute a path to >>R2? >> >>If R1 could successfully compute a PATH, what is the expected "LSP-Enc. >>Type", and "Switching Type" in the Generalized Label Request Object for >>each >>LINK? >> >> R1 ---> S1: SDH/SONET(5) and TDM (100) with "timeslot" as the label? >> >> S1 ---> L1: Lambda(8) and LSC(150) with "port" as the label? >> >> L1 ---> FX: Fiber(9) and FSC(200) with "port" as the label? >> >> FX ---> L2: Fiber(9) and FSC(200) with "port" as the label? >> >> L2 ---> S2: Lambda(8) and LSC(150) with "port" as the label? >> >> S2 ---> R2: SDH/SONET(5) and TDM (100) with "timeslot" as the label? >> >>How about the G-PID? Does it change as well? >> >>How about the Bandwidth Encoding? R1 may ask for an OC-48. Assume S1 is >>incapable of supporting FA-LSP, can the Bandwidth remain as OC-48 for the >>S1 >>---> L1 Link? >> >>Thanks, >> >>Vijay >> >> >>>-----Original Message----- >>>From: Dimitri.Papadimitriou@alcatel.be >>>[mailto:Dimitri.Papadimitriou@alcatel.be] >>>Sent: Saturday, April 24, 2004 4:18 AM >>>To: Pandian, Vijay >>>Cc: ccamp@ops.ietf.org >>>Subject: Re: Routing and signaling across devices with different >>>switching cap abilities >>> >>> >>>hi, >>> >>>Pandian, Vijay wrote: >>> >>>>Consider a mix of devices with varying switching >>> >>>capabilities connected as >>> >>>>follows: >>>> >>>> PSC-1 <===> TDM-1 <===> LSC-1 <===> FSC <===> LSC-2 >>> >>><===> TDM-2 <===> >>> >>>>PSC-2 >>>> >>>>Is it fair to assume that PSC-1 and PSC-2 would advertise >>> >>>TE-LSA's with >>> >>>>"PSC" as the switching capability, TDM-1 and TDM-2 would >>> >>>advertise TE-LSA's >>> >>>>with "TDM" as the switching capability, LSC-1 and LSC-2 >>> >>>would advertise >>> >>>>TE-LSA's with "LSC" as the switching capability...? >>> >>>what "fair" means in this context ? further the hierarchy refers >>>to region boundaries as follows: >>> >>>PSC-1 < PSC-2 < PSC-3 < PSC-4 < L2SC < TDM < LSC < FSC >>> >>>so assuming you're using different values (non-reported in gmpls- >>>routing see below) for TDM and LSC, GMPLS mandates that for inst. >>>you're crossing region boundary at [TDM,LSC] the LSR at the edge >>>of the TDM region must capable to find [LSC,TDM], and if such >>>boundary doesn't exist it is fair to assume that the LSP will not >>>be established - note that we've specific values for L2SC (51), >>>TDM (100), LSC (150) and FSC (200) so what are you inferring with >>>TDM-1 and TDM-2 ? >>> >>> >>>>Given this, would the PSC device (say PSC-1) be able to >>> >>>compute a path using >>> >>>>CSPF to PSC-2? >>> >>>well why don't you use the value defined in gmpls-routing, instead >>>of trying to assess a rule for SC relationship that doesn't exist ? >>> >>> >>>>There had been some discussion regarding the type of label >>> >>>(SUKLM vs. lambda >>> >>>>vs. port) to be used across these switching capabilities. >>> >>>How about the >>> >>>>"LSP-Enc. Type", and "Switching Type" in the Generalized >>> >>>Label Request >>> >>>>Object? How about the Bandwidth Encoding in the >>> >>>SENDER_TSPEC and FLOWSPEC >>> >>>>object? >>> >>>what's more precisely the question here ? >>> >>> >>>>According to rfc3471, section 3.1.1, the switching type is >>> >>>expected to map >>> >>>>to one of the values advertised for the corresponding link. >>> >>>In that case, >>> >>>>would the LSC-device accept a Generalized Label Request >>> >>>with TDM switching >>> >>>>capability and "port" as the label coming from the TDM >>> >>>capable device? >>> >>>i think we've sorted out this issue, during our previous discussion, >>>and the response is "the LSC interface accepts a Generalized Label >>>Request with LSC switching capability and "port" as the label coming >>>from the TDM capable device" i guess you mean when crossing the >>>[TDM,LSC] boundary >>> >>> >>>>Any clarification on this is appreciated... >>>> >>>>Thanks, >>>> >>>>Vijay >>>> >>>>PS: During various GMPLS interop events, an additional FSC >>> >>>(and LSC?) >>> >>>>switching capability in the TE-LSA's was required for the >>> >>>end devices to >>> >>>>compute path. >>> >>>yes, because some people didn't quite accurately translated the term >>>"port" in their implementation ("port" =/= "physical port" such as a >>>fiber), but as discussed this is erroneous >>> >>>hope this clarifies, >>>- dimitri. >>>-- >>>Papadimitriou Dimitri >>>E-mail : dimitri.papadimitriou@alcatel.be >>>E-mail : dpapadimitriou@psg.com >>>Webpage: http://psg.com/~dpapadimitriou/ >>>Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium >>>Phone : +32 3 240-8491 >>> >>> -- Papadimitriou Dimitri E-mail : dimitri.papadimitriou@alcatel.be E-mail : dpapadimitriou@psg.com Webpage: http://psg.com/~dpapadimitriou/ Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium Phone : +32 3 240-8491 From owner-ccamp@ops.ietf.org Wed Apr 28 13:25:29 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00830 for ; Wed, 28 Apr 2004 13:25:28 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIsoJ-0000ua-Dy for ccamp-archive@ietf.org; Wed, 28 Apr 2004 13:25:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIsnI-0000mx-00 for ccamp-archive@ietf.org; Wed, 28 Apr 2004 13:24:25 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BIsmO-0000fy-00 for ccamp-archive@ietf.org; Wed, 28 Apr 2004 13:23:28 -0400 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BIsXQ-000ELG-6d for ccamp-data@psg.com; Wed, 28 Apr 2004 17:08:00 +0000 Received: from [62.23.212.165] (helo=smail.alcatel.fr) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BIsXN-000EK8-T8 for ccamp@ops.ietf.org; Wed, 28 Apr 2004 17:07:58 +0000 Received: from bemail06.netfr.alcatel.fr (bemail06.netfr.alcatel.fr [155.132.251.30]) by smail.alcatel.fr (ALCANET/NETFR) with ESMTP id i3SH7p0O013651; Wed, 28 Apr 2004 19:07:51 +0200 Received: from alcatel.be ([138.203.87.246]) by bemail06.netfr.alcatel.fr (Lotus Domino Release 5.0.11) with ESMTP id 2004042819074980:5463 ; Wed, 28 Apr 2004 19:07:49 +0200 Message-ID: <408FE4E1.DEDA142@alcatel.be> Date: Wed, 28 Apr 2004 19:07:45 +0200 From: stefaan.de_cnodder@alcatel.be X-Mailer: Mozilla 4.72 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Vishal Sharma CC: ccamp@ops.ietf.org Subject: Re: Observations/feedback on draft-decnodder-mpls-interas-protection References: X-MIMETrack: Itemize by SMTP Server on BEMAIL06/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 04/28/2004 19:07:49, Serialize by Router on BEMAIL06/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 04/28/2004 19:07:51, Serialize complete at 04/28/2004 19:07:51 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-Alcanet-MTA-scanned-and-authorized: yes Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Hi Vishal, Thanks for your comments. You find the answers below. I see that one of the confusing points is about SRLGs where SRLGs can be defined inside the ASs without looking to links in other ASs using the same physical resource (=let call them inconsistent or AS-local SRLGs) or whether the SRGs are defined globaly. I will add a definition of it in the draft. The scope of the draft is just to show how existing mechanisms (XRO in this case) can be used to provide any type of protection to inter-AS LSPs. A problem is that SRLG protection (largest part of the draft since the rest is rather trivial) is not well-defined for intra-AS LSPs, that's why I added a small appendix about this in the draft. regards, Stefaan Vishal Sharma wrote: > > Hi Stefaan, > > As promised at the Seoul IETF, here is my (rather belated!) > feedback on the interas protection draft. > (I am cc'ing it to my co-authors as well, so that we can > minimize duplication of our comments.) > > To make things easier, I have divided my comments into > technical and editorial. > > Regards, > -Vishal > > PS: BTW, thanks for your comments on draft-dachille, will try to > respond to them after having time to review your feedback. > > ******************************************************************* > Technical > --------- > i) Abstract: I think it would be useful to make clear here that the > techniques > in this document apply to links between 2 ASs (or only to inter-AS links). > [Stefaan] Not really. It is about protecting an inter-AS link. However, for the links and nodes inside the AS, the current FRR techniques can be used. A special case is comment xvii about the link preceding the exit ASBR in case of SRLG+node protection. I will make this clearer in the update of the document. > ii) Intro., para 4, "Section 4 ... node protection," would be clearer if > it specified that an e2e path for an LSP _crossing multiple ASs_ can only > provide link or node protection. (Presumably, for LSPs within an AS, where > the SRLG's would be consistent, it should be possible to provide SRLG > protection using e2e protection.) > [Stefaan] ok, also best to add an explanation on what consistent and inconsistent SRLG ids are, better: AS-local and AS-global SRLGs. > iii) Sec. 3, para 1, "For instance, in Figure 2 ... multiple core routers," > it is a bit confusing to have R23 and R24. Which links specifically are > being referred to here? Is it, R21-R24, R21-R25, R25-R24? > [Stefaan] I believe you are looking to figure 1... the text refers to figure 2. I will reword it somewhat. > iv) Title of Sec. 4 might be better as "Problems in SRLG protection with > disjoint > e2e LSPs" > [Stefaan] Ok > v) The document uses "main" and "primary" for the working LSP. It might be > better to have consistently the same term throughout. > [Stefaan] Indeed, I will use the words working and recovery. This terminology is in line with draft-ietf-ccamp-gmpls-recovery-terminology-03.txt > vi) It might be better to add another row of routers in both ASs in Fig. 2, > to make it non-trivial. That way, it will be possible to illustrate that > there are multiple secondary egress AS-BRs, and multiple secondary ingress > AS-BRs, and also that the egress AS-BR has to make a choice of a route > to an appropriately picked secondary egress AS-BR, etc. > [Stefaan] Ok, I will update the figure based on your suggestion. > vii) The way the method is described, especially in Sec. 6, it appears that > the technique applies only to packet LSPs. Is my understanding correct? > [Stefaan] That is correct. At the latest IETF there was a draft describing protection for non-packet LSPs. For non-packet LSPs, bypass tunnels make no sense and apparently for detours they also use another approach. In addition, it is only for ASes, and not for regions in general. > viii) The entire segment in Sec. 6.1.1 para 2, from "In case this condition > ..." > until "... not in the downstream AS (AS2 in Figure 2)," might benefit from > some simplification in the writing. It's a bit difficult to follow, as > written. > [Stefaan] Yes, maybe some more explanation with figures might be good here. Simply stated, if the link between AS1 and AS2 is to be protected, then the detour starts in AS1 and goes to AS2 without going through another AS. > ix) Similary, in the same para, the description of what portion of an RRO > should > be in the ERO for the detour LSP emanating from the egress AS-BR is also > confusing. > It might be restated as > "The ERO for the detour LSP starting at the egress AS-BR contains several > segments. > It must first contain a strict or loose path towards the secondary egress > AS-BR, followed > by a segment of the RRO for the primary LSP. This segment begins at the last > hop in > the downstream AS and contains all hops thereafter up until the > destination." > [Stefaan] Maybe also good to explain this based on the figure part by part. > x) In the same para, it is mentioned that the ERO of the detour LSP consists > of > two segments. However, when elucidating this with a reference to Fig. 2, the > ERO > of the detour LSP is only said to be composed for router R14, R22 and all > routers > thereafter. The segment from R14 to R12 and R12 to R21 is not mentioned. > [Stefaan] Indeed, you are right, I will update the example. > xi) In the draft, in the sentence describing the ERO of the detour LSP, > the last router should probably be R24 instead of R22 (as currently > written). > [Stefaan] There is something wrong with this example. The last node in the downstream AS of the main LSP must be in the ERO of the main to ensure that the detour merges in the downstream AS. > xii) Sec. 6.1.1, para 4, the last sentence could be reworded to make > it a bit clearer. I think it is saying that when the primary and secondary > egress AS-BRs are the same, and the primary and secondary ingress AS-BRs > are the same, and they have multiple links between them, then the detour > LSP must simply use an inter-domain link different than the one used by > the primary LSP, and no path computation is needed at the egress AS-BR. > [Stefaan] Your understanding is correct. I will reword it. > xiii) It would be useful to explain the purpose and structure of the > LSP-Merge > object as well as the operations performed on it, in Sec. 6.1. itself. > Otherwise, the reader sees this object mentioned in the main text, without > having > an idea of what it is. > In any case, since the appendices are quite small, and sort of intergral to > the > subsequent text in the main doc., I think it would be best to pull them into > the > main text. > [Stefaan] I prefer to keep it in the appendix to avoid that people start thinking that my main purpose is to define this RSVP extionsion, which is not the case but in principle I agree with you: forward references are never good but more drafts/RFCs are doing this. Best to add a sentence at the end of 6.1.1 to say what the result will be of using it. > xiv) This will make the description in Sec. 6.1.4 and 6.3.1 easier to > follow. > [Stefaan] see above. > xv) The second last para in Sec. 6.3.1 mentions that the merge point of > the detour and main LSP must ensure that it can switchover traffic from > the incoming detour LSP to its originating detour LSP, since the egress > link at this merge point may belong to the same SRLG as the inter-domain > link that the incoming detour LSP was protecting. > Is this trivial to ensure? It appears that there is a bit of work > that an LSR would have to do to ensure that. No? (Since the normal > procedure would be simply to merge traffic from the detour LSP > on to the main LSP.) > [Stefaan] FRR as currently defined in the FRR-draft assumes only single failure, i.e. no SRLG protection. In this case, only at most 1 detour LSP of a main LSP will be used at a particular time. With SRLG's their is indeed the requirement that multiple detours can be in use at the same time... that's the consequence of SRLGs and indeed, this requires extra functionality. So indeed, your comment is very valid. > xvi) Sec. 6.3.4, the first sentence "If the secondary ... inside these > objects" > is worded in a rather confusing way. In which objects does the sec. ingress > AS-BR add the list of SRLG's of the inter-AS link? > [Stefaan] Wording is indeed not good: list of SRLGs is added to XRO or EXRS. Will correct wording. > xvii) In Sec. 6.3.6. it is not clear why there is a focus on the SRLG > protection > of the link _preceding_ the ingress AS-BR? > [Stefaan] you mean the egress AS-BR I guess. Well normally when node+link protection is desired, then one bypass/detour is used to protect against a failure of the link or node. In case of SRLG+node protection, you would expect the same: one bypass/detour is used to protect against a failure of the SRLG or node. In the special case where the node is an egress AS-BR, then it is not possible anymore to use a single bypass/detour but 2 bypasses/detours have to be used. That is why there is a special focus on the SRLG protection of the link preceding the egress AS-BR + node protection of that egress AS-BR. This applies only when inconsistent SRLG numbering is used between the ASs (or AS-local SRLGs to name it differently). The detour/bypass protecting the SRLG must merge in the same AS, the detour/bypass protecting the node crosses the AS boundary. > xviii) In the same section, the para "To ensure that .... towards the > egress > AS-BR" is unclear, and perhaps needs to be reworded and better explained. > Not sure which link the phrase "... SRLG disjoint with the next link of the > main > LSP computed towards the egress AS-BR" refers? > [Stefaan] Ok, a slight rewording is required here. The "next link" is the link with its SRLGs to be protected, i.e. the link preceding the prim egress AS-BR. > xix)In Sec. 6.3.6, para 4, the phrase "IF only 1 detour LSP ... LSP setup > would fail," is unclear. > [Stefaan] This is a complex one. For detours protecting against SRLGs of the inter-AS link, the detour MUST merge in the downstream AS and MUST NOT cross other ASes when inconsistent SRLG numbering is used. For node (or link) protection, it is not really a MUST, but rather a SHOULD. If the downstream AS is only 1 hop, then for node protection there is not other choice then to let the detour merge in the "downstream-downstream AS", which is not allowed for SRLG. But for SRLG, the detour may merge at the primary ingress AS-BR, but that is then not allowed for node protection. Becuase of these conflicting requirements, it is recommended to use 2 detours: one for SRLG protection and one for node protection. It is hard to understand, but it is correct. Maybe a figure in the draft might help. > xx) Sec. 7, second last para states "We also note ... does not lead to the > failure of the bypass tunnel." I guess it wasn't clear why teh interface > failure > does not cause a failure of the bypass tunnel. > [Stefaan] If the interface fails and this interface was the destination of the bypass, then the destination does not exist anymore in theory, so the bypass could be torn down. However, this is not allowed, otherwise link and bypass would fail at the same time. I believe the text is clear here. > xxi) Appendix B, last sentence, why is the use of the sender-template > specific > detour LSP merely "recommended" as opposed to being "required"? > [Stefaan] Good point. This has to be changed into "required". Although in some particular cases, path-specific detours may be used but it is better to always use sender-template specific detours. > xxii) The last sentence of Appendix B ends with "avoid merging with other > LSPs". It > would be useful to say here which those "other LSPs" are. I assume their are > themselves > other detour LSPs for the given main LSP? > [Stefaan] Yes, this deserves more explanation. Your understanding is correct. The basic problem is that 2 detours of the same main LSP protect against different SRLGs and hence MUST NOT be merged. From owner-ccamp@ops.ietf.org Wed Apr 28 15:55:18 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12849 for ; Wed, 28 Apr 2004 15:55:18 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIv9J-0003L8-7B for ccamp-archive@ietf.org; Wed, 28 Apr 2004 15:55:17 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIv8G-0003As-00 for ccamp-archive@ietf.org; Wed, 28 Apr 2004 15:54:13 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BIv7L-00033F-00 for ccamp-archive@ietf.org; Wed, 28 Apr 2004 15:53:15 -0400 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BIuio-000NEj-EX for ccamp-data@psg.com; Wed, 28 Apr 2004 19:27:54 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BIuim-000NEL-Ns for ccamp@ops.ietf.org; Wed, 28 Apr 2004 19:27:52 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10814; Wed, 28 Apr 2004 15:27:49 -0400 (EDT) Message-Id: <200404281927.PAA10814@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-gmpls-segment-recovery-00.txt Date: Wed, 28 Apr 2004 15:27:49 -0400 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --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 : GMPLS Based Segment Recovery Author(s) : L. Berger, et al. Filename : draft-ietf-ccamp-gmpls-segment-recovery-00.txt Pages : 24 Date : 2004-4-28 This document describes protocol specific procedures for GMPLS (Generalized Multi-Protocol Label Switching) RSVP-TE (Resource ReserVation Protocol - Traffic Engineering) signaling extensions to support LSP segment protection and restoration. These extensions are intended to be compliment and be consistent with the Extensions for End-to-End GMPLS-based Recovery. Implications and interactions with Fast Reroute are also addressed. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-segment-recovery-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ccamp-gmpls-segment-recovery-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ccamp-gmpls-segment-recovery-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-4-28152903.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-gmpls-segment-recovery-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-gmpls-segment-recovery-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-4-28152903.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ccamp@ops.ietf.org Thu Apr 29 00:52:07 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA18079 for ; Thu, 29 Apr 2004 00:52:07 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJ3Wp-0005at-31 for ccamp-archive@ietf.org; Thu, 29 Apr 2004 00:52:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJ3Vi-0005RH-00 for ccamp-archive@ietf.org; Thu, 29 Apr 2004 00:51:00 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BJ3VN-0005Jh-00 for ccamp-archive@ietf.org; Thu, 29 Apr 2004 00:50:37 -0400 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BJ3Gi-000NIk-2w for ccamp-data@psg.com; Thu, 29 Apr 2004 04:35:28 +0000 Received: from [66.163.168.182] (helo=smtp803.mail.sc5.yahoo.com) by psg.com with smtp (Exim 4.30; FreeBSD) id 1BJ3Gg-000NIN-UZ for ccamp@ops.ietf.org; Thu, 29 Apr 2004 04:35:26 +0000 Received: from unknown (HELO RAKHILAPTOP) (vishal.sharma@sbcglobal.net@63.206.91.198 with login) by smtp803.mail.sc5.yahoo.com with SMTP; 29 Apr 2004 04:35:25 -0000 Reply-To: From: "Vishal Sharma" To: Cc: , "Fabio Ricciato" , "Ugo Monaco" , "Alessio D'Achille" , "Marco Listanti" Subject: RE: comments on ARO Date: Wed, 28 Apr 2004 21:35:01 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <408D37FA.2254D30F@alcatel.be> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Hi Stefaan, Thanks for your follow-on inputs. Few comments in-line. We look forward to any additional feedback you have. Regards, -Vishal > -----Original Message----- > From: stefaan.de_cnodder@alcatel.be > [mailto:stefaan.de_cnodder@alcatel.be] > Sent: Monday, April 26, 2004 9:26 AM > To: v.sharma@ieee.org > Cc: ccamp@ops.ietf.org; Fabio Ricciato; Ugo Monaco; Alessio D'Achille; > Marco Listanti > Subject: Re: comments on ARO > > > > Hi Vishal, > > please find some more comments inline... > > Vishal Sharma wrote: > > > > Hi Stefaan, > > > > Thanks a lot for looking over the draft so carefully, and for your > > many detailed comments. > > > > While we will address the individual comments once we've digested > > them a bit (and in a separate email to avoid making this one > > too long :-)), let me try to address a couple of the most important > > points raised in your note below. > > > > 1) Recording only border nodes: > > > > Actually, if one only recorded border nodes, then upon signaling > > the secondary, the ingress border node for the secondary has no > > idea about the intra-area (or intra-AS) path of the primary (in its > > own area or AS), and therefore cannot ensure that the primary and > > secondary segments are in fact disjoint. > > > > This was a point I discussed with several other people > > (who initially proposed the same thing), including > > Arthi and Adrian, but we concluded, for the reason above, that merely > > recording the border nodes does not work for diversity. As a > > result, the ARO does, in fact, serve a very useful purpose. > > > > We can of course think more about what the trade-offs are, and > see if there > > is some way to retain the main advantage of the proposal (diversity, > > joint optimization of both paths) while also recording less information. > > > > The problem I want to solve here is NOT to reduce the amount of > information in the ARO, i.e. my purpose is not to reduce its length. > Rather, by only recording the border nodes you give more freedom > when signaling the secondary (using the XRO!) meaning that when > crankback or re-optimization of the secondary is possible, the > primary does not have to be resignaled to get a new ARO. Sure, I understood that the goal wasn't to reduce the length of the ARO per se, but rather the level of detail that would need to be recorded in it (regardless of the actual amount of data the ARO would carry). If you recollect the classification of path computation models I gave in my email to JP http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00467.html we have under distributed computing: i) a parallel path computation model and ii) a sequential one. ARO achieves the former, while XRO achieves the latter. So, if one did not compute and record the path of the secondary jointly with the primary (and only recorded the border nodes instead) the scheme would reduce to a _sequential path computation_, with its attendant drawbacks (sub-optimality, trap topology, etc.). The beauty of the ARO scheme is that it can compute end-to-end diverse paths using a parallel path computation model (albeit distributed at each area/AS), with the simplicity of the per-domain approach, and without any changes to the signaling protocols. Please note also that this does not say anything about the usefulness of the XRO (which _is_ a v. useful construct, with several applications, as pointed out in my earlier email), only that when paths are computed sequentially these problems arise. > > > 2) With regard to optimizing only the path of the primary, I am not > > so sure about doing just that. > > > > I believe one can get into real problems if one does not constrain > > the path/cost of the secondary, with unduly long secondaries that > > will greatly limit the ability to setup further primaries > > (and secondaries). (This can be especially true of tranport networks, > > where one would set up very large bandwidth pipes, and optimizing their > > placement would be critical.) > > > > This scheme is optimizing jointly the cost of the primary and > > secondary, while ensuring diversity. > > > > My question was *what* is the metric being optimized. For instance > with sequential computing, the cost of the primary is minimized, > while the second metric is the cost of the secondary LSP. With > parallel computing it is different: is the cost being minimized the > cost of primary + cost of secondary, or is it something else? Minimizing the cost of the primary + cost of secondary is one metric that a parallel path computation scheme may minimize. There might be others. For e.g. minimize the cost of primary while keeping that of secondary below a certain threshold, minimize the difference between the costs of the primary and the secondary, and so on. The actual criteria for minimization may be a provider choice, that is executed/realized by the joint path computation algo. employed in the network nodes. > > I think you will find that most providers would be equally concerned > > with the cost/placement of the secondary path. > > > > Moreover, as I emphasized (and as discussed during CCAMP we wiil change > > the title and our intro. to reflect that), this is a: > > generic method for computing diverse paths > > that meets a variety of requirements: load balancing, multipe paths > > when a single one has insufficient capacity, multiple paths between > > VoIP gateways, etc. in all of which one would ideally be looking for > > paths with about equal length. > > Protection is just _one_ application of this scheme. > > > > This load balancing over multiple paths looks like a good > application. Great, thanks. This is why JL and others have asked us to not limit our scheme only to restoration applications. And we will do this generalization in the update. > > 3) Re-optimization, crankback, and failure of secondary: > > > > I think the scheme works with all of these, and does not really > > conflict with any of them. > > > > With crankback, there should be no problem, whenever a crankback occurs > > on the primary, the secondary will also be recomputed at the ASBR/ABR > > to which there is crankback. > > > > With re-optimization, there are several options. > > > > -- Either default to sequential calculation, and use the XRO to > re-optimize > > whichever of the two diverse paths requires re-optimization. > > (This might be an immediate response, while the below could be > > a more long-term response.) > > > > Since an ABR on the secondary path only sees a full strict path in > the ERO, the ABR does not know when there is a better path matching > the constraints. This is because the ABR does not know the > constraints. > > > -- Or, if the goal really is joint optimization, the provider will have > > to setup a new set of diverse paths, and use make-before-break to > > transition the traffic over. > > > > -- If the secondary fails, again there are two options. Either use > > the XRO to perform another path setup (and, possibly, re-optimize > > the paths later), or use the joint optimization method above with > > make-before-break. > > > > This looks ok. Great, thanks. We will add this discussion to our revised draft. > > > 4) Relationship to XRO: > > As I mentioned in the Seoul presentation and also > > in our discussion, I think the XRO has many uses -- during computation > > after crankback, to enable adminstrative routing/re-routing, protection, > > etc. > > > > So I think the ARO and XRO are actually complementary. > > > > Regards, > > -Vishal > > > > > -----Original Message----- > > > From: stefaan.de_cnodder@alcatel.be > > > [mailto:stefaan.de_cnodder@alcatel.be] > > > Sent: Monday, April 19, 2004 12:08 PM > > > To: v.sharma@ieee.org > > > Cc: ccamp@ops.ietf.org > > > Subject: comments on ARO > > > > > > > > > > > > Hi Vishal, > > > > > > looking to draft-dachille, I have following comments: > > > > > > 1) Second paragraph in section 2 is not clear: "we will assume that > > > every > > > inter-area connection is duplicated". I understood from it that when > > > the > > > primary path follows Area1-Area2-Area3, then also the secondary has > > > to > > > follow this path but using other border nodes. But then from section > > > 4.2 I > > > understand that this is not an assumption? > > > > > > 2) step 2c on page 5: also E, G and H has to be pruned? It is also > > > not > > > clear which path is selected in area 3: I guess it is E-G-H for > > > primary and > > > F-H for secondary? > > > > > > 3) (!) page 7, about the trap-avoid reference: If fact it is just a > > > matter > > > of doing a good path calculation. If the primary is signaled and > > > border > > > nodes know that also a secondary has to be established, then it can > > > make > > > sure that the primary does not introduce such a trap. This assumes > > > that the > > > border node also has to know that a secondary has to be established. > > > This > > > is known by the presence of the ARO object but this does not mean > > > that at > > > the end, the ARO has to contain a full strict path of the secondary. > > > Border > > > nodes can expand the ARO by only including the border nodes for the > > > secondary. This means that the path calculation of the secondary is > > > not > > > anymore 100% bound to the primary. Also I would prefer that the ARO > > > is more > > > like a "hint" than the real path. With this, you do not have to > > > interaction > > > problems with re-optimization of secondary, crankback, ... For > > > instance: > > > when the secondary fails, it can be re-established ignoring the ARO. > > > Or > > > when the secondary can be re-optimzed between border nodes, then it > > > can be > > > done without impacting the primary or when the global > > > re-optimization is > > > possible, then the ARO can be simple ignored. > > > > > > I prefer to have the ARO only recording border nodes, and optionally > > > only > > > acting as a hint for the ingress LSR. The latter is less important > > > to me. > > > > > > 4) text below figure 3: primary has to be as short as possible. I do > > > not > > > care much about the secondary becuase it is almost never used. Also, > > > the > > > resources that it reserves can be shared with other secondaries. The > > > problem here is: what are you optimizing? According to me the path > > > of the > > > primary has to be optimized. > > > > > > 5) I do not understand why the ARO has to contain Area-Ids to > > > indicate the > > > route. If the ingress can put the "area-path" in the ARO, then it > > > can also > > > put the border nodes in the ERO of the secondary immediately. I.e. > > > refering > > > to figure 5: A knows that the path of the secondary is A1-A2-A5-A6. > > > How > > > does A know this? And if it is possible to let A know this > > > information, > > > then why could it also not know that the path is B1-B7-B9. If A can > > > do > > > this, then there is no need anymore for ARO. So the basic question > > > is: what > > > makes it easier for A to know A1-A2-A5-A6 instead of B1-B7-B9. This > > > means > > > to me that section 4.2 is not valid and that the ARO assumes that > > > the > > > "area-path" of primary and secondary is the same, which is true for > > > IGP > > > areas. See also comment 2. Maybe better to remove the AREA-IDs from > > > the > > > ARO. > > > > > > 6) step 1d page 14, second last line: how does the ABR know that B7 > > > has to > > > be used and not B8? > > > > > > 7) section 4.3: also describe the L-bit that is in the ERO > > > subobjects. > > > > > > 8) Is the Addr_len in for instance subobject 1 always 32 or can it > > > be > > > something else. I agree here that you should re-use ERO subobjects > > > but I > > > see that you are doing this. > > > > > > 9) Section 4.3.2.3, area_ID: types 3, 4 and 5 are defined but that > > > conflicts with what is described in the middle of page 19 where the > > > numbers > > > are 32, 33, 34. > > > > > > 10) the text in section 4.3.3 is rather confusing (the part in the > > > middle > > > of page 22, about pruning the nodes). Take figure 5, area 5: If B6 > > > has to > > > calculate a path from B6 to B10, then this path can pass via B5, B8, > > > B7 > > > and/or B9. This is because border nodes can also act as core nodes > > > at the > > > same time. This seems to be excluded from the draft. Is that > > > correct? > > > > > > 11) First refinement in section 5 about the cost of virtual links: > > > this has > > > been proposed before in > > > http://www.watersprings.org/pub/id/draft-venkatachalam-interarea-m > > >pls-te-02.txt > > >which is not a good idea: it only works for inter-IGP area and it > > >decreases > > >the scalability although it also has some advantages. > > > > >12) (!) There are conflicts with re-optimization, crankback, > > >re-establishement after failure of secondary LSP, ... because in all > > >of > > >these cases a working primary LSP also have to be re-signaled which > > >is not > > >good. Therefore it is better to let the ARO only record border > > >nodes, > > >and/or to use the ARO more as a hint for the secondary: using the > > >ARO in > > >the primary makes sure that a trap is avoided, and then it is up to > > >the > > >signaling of the secondary to find this path by using crankback, > > >.... There > > >is no need that the primary LSP also gives the path, it only has to > > >make > > >sure that there is a path. > > > > > >13) (!) The method seems not to be applicable for inter-AS > > >calculations. > > > > > >14) Following the classification of methods (ARO, XRO, PCE) that you > > >described earlier on ccamp based on parallel/sequential and > > >distributed/centralized computation, ARO looks more an alternative > > >for PCE than for XRO? In fact, would it be possible to combine > > >methods? It would be good to explain the interaction (if any) with > > >these other methods. > > > > > >Hope this helps, > > > > > >regards, > > > > > >Stefaan From owner-ccamp@ops.ietf.org Thu Apr 29 02:36:51 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08154 for ; Thu, 29 Apr 2004 02:36:51 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJ5A9-0005Go-BN for ccamp-archive@ietf.org; Thu, 29 Apr 2004 02:36:49 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJ59A-00058y-00 for ccamp-archive@ietf.org; Thu, 29 Apr 2004 02:35:49 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BJ588-0004vl-00 for ccamp-archive@ietf.org; Thu, 29 Apr 2004 02:34:44 -0400 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BJ4tb-000NHu-Du for ccamp-data@psg.com; Thu, 29 Apr 2004 06:19:43 +0000 Received: from [128.130.90.21] (helo=publications.ftw.tuwien.ac.at) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BJ4tZ-000NF7-UC for ccamp@ops.ietf.org; Thu, 29 Apr 2004 06:19:42 +0000 Received: from nt_ftw.ftw.tuwien.ac.at by publications.ftw.tuwien.ac.at via smtpd (for psg.com [147.28.0.62]) with ESMTP; Thu, 29 Apr 2004 08:32:48 +0100 Received: from coritel.it (spirit.ftw.at [192.168.0.19]) by nt_ftw.ftw.at with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 20F8RAYH; Thu, 29 Apr 2004 08:19:01 +0200 Message-ID: <40909E7C.3060002@coritel.it> Date: Thu, 29 Apr 2004 08:19:40 +0200 From: ricciato User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030821 X-Accept-Language: en-us, en MIME-Version: 1.0 To: v.sharma@ieee.org CC: stefaan.de_cnodder@alcatel.be, ccamp@ops.ietf.org, Ugo Monaco , "Alessio D'Achille" , Marco Listanti Subject: Re: comments on ARO References: In-Reply-To: X-Enigmail-Version: 0.76.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 8bit Hi Stefaan, in addition to Vishal´s comment, just let me quote below a paragraph from my previous mail (http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00473.html, Mon, 19 Apr 2004). I´d appreciate to have you opinion on it. ciao Fabio > 3. The joint-computation with ARO can be applied to a vast class of > problems dealing with path-pair computation. I'm giving below some few > examples. > (I think this also adrresses some comment by Jean-Louis). In general, > in each problem of path-pair computation one can distinguish the > constraint(s) from the optimization objective: > > Case-I: find a pair of disjoint paths (i.e., disjointedness is a > constraint) wich minimize some link metric (hop-length, link-load, etc.) > Case-II: find a pair of maximally disjoint paths (disjointedness > becomes an objective) > Case-III: find a pair of disjoint paths P1 and P2 that minimizes the > difference |d(P1)-d(P2)|, where d() is some metric associated to the > path (e.g., delay....might make sense in optical networks ??). > Case-IV: Assuming that for each link pair (i,j) it is possible to > assign a "correlation" factor r(i,j) accounting for the probability of > contemporary failures, find a pair of paths that minimizes the > max{r(i,j)} over all pairs such that i is in P1 and j is in P2 [see > note 2]. > > Maybe not all the above items are of practical interest in real > applications, but the fact that our approach encompasses all of them > proves the flexibility and usefulness of joint-computation with ARO. > Several other problems can be found. > In general, joint-selection with ARO can address to all problems > presenting some *joint constraints* and/or *joint optimization > objective* on the pair of paths. > > Needless to say, each such case requires ad-hoc route-selection > _algorithms_ to be implemented in the ingress border nodes (or in a > centralized server within each AS), but all can be accommodated with > the signaling procedure based on ARO. > > Admittedly, the current draft version exclusively focused on case-I, > and fails to make it clear that the set of possible applications is > far broader. We will improve this point in the future version. > Incidentally, I notice here that this is indeed the reason why we > proposed the (quite neutral) term "Associated Route Object" instead of > the more specific "Disjoint R.O." or "Backup R.O." etc.: we wanted to > leave it open to a broad set of possible applications. > > Maybe it would make sense to add some additional semantic in the PATH > messages that specify the contraint(s) and/or the objectives to which > the primary (in the ERO) and secondary (in the ARO) paths should > (jointly!) comform. > This might be an associated sub-object of the ARO, perhaps ? > Might be named "Route Pair Requirements" (RPR) ? > In other words, the overall semantic in the PATH messages should sound > like: > "compute a primary route segment (in the ERO), and an associated > secondary route segment (in the ARO), such that they are subject to > the contraint(s) X and optimize objective Y (X,Y are contained somehow > in the RPR)". > > The ERO+ARO+RPR scheme, in the framework of distributed *joint* route > selection, would be really a quite flexible and general scheme. > > What do you think about that ? From owner-ccamp@ops.ietf.org Thu Apr 29 04:17:00 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12935 for ; Thu, 29 Apr 2004 04:16:59 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJ6j4-0004kv-8t for ccamp-archive@ietf.org; Thu, 29 Apr 2004 04:16:58 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJ6i2-0004Si-00 for ccamp-archive@ietf.org; Thu, 29 Apr 2004 04:15:55 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BJ6gm-0004EH-00 for ccamp-archive@ietf.org; Thu, 29 Apr 2004 04:14:36 -0400 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BJ6U4-000BAl-Qp for ccamp-data@psg.com; Thu, 29 Apr 2004 08:01:28 +0000 Received: from [66.163.168.181] (helo=smtp802.mail.sc5.yahoo.com) by psg.com with smtp (Exim 4.30; FreeBSD) id 1BJ6U3-000BAY-Tu for ccamp@ops.ietf.org; Thu, 29 Apr 2004 08:01:27 +0000 Received: from unknown (HELO RAKHILAPTOP) (vishal.sharma@sbcglobal.net@63.202.177.249 with login) by smtp802.mail.sc5.yahoo.com with SMTP; 29 Apr 2004 08:01:26 -0000 Reply-To: From: "Vishal Sharma" To: , "ugo monaco" , "Fabio Ricciato" Cc: "ccamp" , "Zafar Ali" Subject: RE: Diverse path failure and optimality in draft-dachille-inter-area-path-protection Date: Thu, 29 Apr 2004 01:01:02 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: <408D12E3.5030806@alcatel.be> Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Hi Dimitri, Thanks for your thoughts. However, as Fabio rightly observed, it is very critical that we distinguish between characteristics that are intrinsic (and common) to _all_ distributed path computation approaches from those that are specific to the ARO approach. The points you have mentioned below are inherent in _any_ distributed path computation paradigm (and indeed in any distributed signaling/resource reservation paradigm), as I explain below, and are therefore not drawbacks that arise due to particular mechanisms/methods proposed in the ARO approach. Comments in-line. -Vishal > -----Original Message----- > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On > Behalf Of Dimitri.Papadimitriou@alcatel.be > Sent: Monday, April 26, 2004 6:47 AM > To: ugo monaco > Cc: ccamp; Zafar Ali > Subject: Re: Diverse path failure and optimality in > draft-dachille-inter-area-path-protection > > > > hi, by discussing the proposed method there seems to be three issues > that make the method questionable in terms of guarantee to deliver what > it intends to deliver, its usability (the time validity of the path is > not guaranteed) and its applicability in terms of objective initially > targeted wrt to the network topology > > 1) imagine three areas decoupled computation as explained at their > respective ingress, with ARO method; how the third computation element > (tail-end) is aware of srlg's that may affect a link selected in the > head-end area > > example: link 1 is selected in area 1 (head-end) with srlg 1, link 2 is > selected in in area 2 with srlg 2, and link 3 in area 3 (tail-end) with > srlg 3 and 1 (since the tail end doesn't know that srlg 1 is associated > to link 1 in addition to its association to link 3 even if it knows that > the link 1 has been selected for the ARO) the problem is that you can > not retrieve such kind of error (except but how practical is it if one > start cumulating all this information between computation points) - First, if we are talking about IGP areas, the problem is a non-issue. (They would be under the control of a single provider, and the provider can reasonably be expected to assign distinct, globally unique SRLGs to the links in different areas.) - If we are talking about AS's, the problem is _universal_, and all schemes related to restoration have to deal with it. In particular, _any_ scheme that does distributed path computation has to deal with it. So the question is unrelated to the ARO scheme, but a broader one about how different providers assign SRLG's to resources. This is actually a very important issue, but outside the scope of the ARO document, and not one that I have seen any comprehensive approach to, yet. Perhaps others on the list (carriers?) can comment on it. > 2) resource contention, the secondary path may never be established > since the computation point as *no* capability to make any reservation > on it (except from the first segment) since by definition "disjoint" - > it simply becomes a kind of "best effort" secondary path (in the sense > use it if no other reservation are making use of these links) As Fabio has very nicely explained in his email, http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00553.html resource contention is a fact of life (read unavoidable) in any distributed scheme (unless you assume _instantaneous communication_ between the distributed entities), and is prevalent in every distributed protocol/mechanism from RSVP-TE to mechanisms for diverse path computation and setup, such as PCE-based, XRO-based, and, of course, ARO-based schemes. Not sure why you thought this is specific to the ARO proposal. > 3) the method seems to raise additional issues when the number of > potential entry point for the secondary disjoint path increases, at each > step of the computation (otherwise the method wouldn't provide what it > intends to deliver) First, not sure what "additional issues" you are referring to. Can you provide specifics? In any case, every path computation scheme (distributed or otherwise) has to handle the case where there are multiple entry points for the secondary (and primary) paths at a given area/AS. Again, nothing surprising here or specific to the ARO scheme in particular. When there are many entry points, any scheme has to have a way to select only one (or some number of them), and any one of several criteria may be used to make that selection. Of course, one can consider then the relative merits of the different ways of making that selection. > > > ugo monaco wrote: > > > Dear ccamper, Zafar, Dimitri, > > > > as anticipated in the recent email by Vishal we are addressing several > > important comments collected at Seoul regarding the joint-selection of > > diverse paths with ARO, i.e. the approach proposed in > > > h-protection-00.txt>. > > > > > > As Vishal did I summarized your comments to ensure that we rightly > > understood inputs, and to help people on the ML follow > > and contribute to the discussion. > > Comments from others who have feedback are welcome, and > > much appreciated. > > > > Please let me know if you had any additional comments > > as well. We will take these into account in providing our > > responses, and, later, in updating the document. > > > > > > > > Thanks again for your feedback on our draft during the Seoul meeting. > > Best Regards. > > > > Ugo Monaco > > > > > > > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > +++++++++++++++++++++++++ > > > > > > > > Zafar's questions: > > > > i) What happens when the setup of the diverse path fails, or there is a > > failure on it after it has been set up? > > > > ii) Relationship of this scheme to PCS/PCE approach of JP? > > > > > > Dimitri Papadimitriou > > > > i) Your question was about why we are trying for optimality > with a joint > > path selection scheme, when it is not possible, especially as > the number > > of AS's or areas along a path increase, to achieve the *global* optimum. > > Your other comment was that we should mention this somewhere in the > > document. > > > > Please note that in response to this last question Fabio > Ricciato listed > > many > > advantages of a joint computation (with ARO) of inter-area/AS > paths in a > > prevoius email posted on the ML "About optimality of inter-AS parallel > > computation in draft-dachille-inter-area-path-protection". > > We hope that Fabio rightly addressed your input and we will appreciate > > further comments and notes. > > > > > > > > > > -- > Papadimitriou Dimitri > E-mail : dimitri.papadimitriou@alcatel.be > E-mail : dpapadimitriou@psg.com > Webpage: http://psg.com/~dpapadimitriou/ > Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium > Phone : +32 3 240-8491 > > > From owner-ccamp@ops.ietf.org Thu Apr 29 05:16:00 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15545 for ; Thu, 29 Apr 2004 05:16:00 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJ7eB-00078M-5D for ccamp-archive@ietf.org; Thu, 29 Apr 2004 05:15:59 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJ7dE-0006yh-00 for ccamp-archive@ietf.org; Thu, 29 Apr 2004 05:15:00 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BJ7ck-0006pD-00 for ccamp-archive@ietf.org; Thu, 29 Apr 2004 05:14:30 -0400 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BJ7OT-000575-6Y for ccamp-data@psg.com; Thu, 29 Apr 2004 08:59:45 +0000 Received: from [195.8.69.15] (helo=oceanus.uk.clara.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BJ7OS-00056m-02 for ccamp@ops.ietf.org; Thu, 29 Apr 2004 08:59:44 +0000 Received: from claranet by oceanus.uk.clara.net with local (Exim 4.22) id 1BJ7OV-000JFX-Pn; Thu, 29 Apr 2004 09:59:47 +0100 From: "Adrian Farrel" To: ccamp@ops.ietf.org Cc: adrian@olddog.co.uk Reply-To: adrian@olddog.co.uk Subject: Last Call Complete: draft-ietf-ccamp-gmpls-ason-routing-reqts-03.txt Date: Thu, 29 Apr 2004 09:59:47 +0100 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Remote_Addr: 156.106.231.246 Message-Id: Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit All, Looks like last call is done with just Jerry's comments. No comments were received from the IGP or routing area working groups. Thanks for your thoughts, Jerry. To expand a little upon what Zafar said... > 1. I'm bothered by the statement in Section 3: > "The maximum number of hierarchical RA levels to be supported is > NOT specified (outside the scope)." > Why is it outside the scope, I think there should be some explanation. > Does the number of levels not matter? I think it does matter, however, we need to reflect the requirements as stated by ITU-T SG15 Question 14 in G.7715. We can't play with those requirements. Section 6 of G.7715.1 states... Routing areas contain routing areas that recursively define successive hierarchical routing levels. The number of hierarchical levels to be supported is implementation?specific and outside the scope of this Recommendation. But note (and as some comfort to us) RAs do not necessarily reflect protocol levels (such as IGP areas) but may represent arbitrary subdivisions of protocol levels such as protection domains. > Is one level (i.e., flat network, no hierarchy at all) OK? I believe this is in scope, and acceptbale within the requirements. > I would much prefer to have the maximum number of required hierarchical > levels stated in the draft. You and me too. But SG15 determined that such a limit would be arbitrary from their perspective and so they made it out of scope. > 2. There is quite a bit of discussion about hierarchy evolution, e.g., > in Section 3: > "- The requirements support architectural evolution, e.g. a change in > the number of RA levels, as well as aggregation and segmentation of RAs." > > This begins to suggest automatic 'insertion/deletion' of hierarchical > levels, which I believe is too complex. I don't believe that there intent to describe the mechanism for insertion/ deletion of levels. In particular, as you point out below, protocols are not expected to be automatically adaptive to such changes. The requirement is really that there should be the architectural flexibility. But I do believe that the intent is to allow levels to be inserted without major disruption to other levels (in particular those that are not parents or children). Again, we are simply picking up a requirement which we cannot control. > However, I find in Section 4.4: > "The routing protocol SHOULD be capable of supporting architectural > evolution in terms of number of hierarchical levels of RAs, as well as > aggregation and segmentation of RAs. RA IDs uniqueness within an > administrative domain MAY facilitate these operations. The routing > protocol is not expected to automatically initiate and/or execute these > operations." > > It is the final "not" that says that automatic insertion/deletion is not > required within the protocol. Perhaps this NOT should be capitalized for > emphasis. New addition to RFC2119? :-) > 3. Regarding Adrian's comment on the text I referenced in comment #2: > "The routing protocol is not expected to automatically initiate and/or > execute these operations. Reconfiguration of the RA hierarchy MAY not > ## Surely this is MUST? > disrupt calls in progress, though calls being set up may fail to > complete, and the call setup service may be unavailable during > reconfiguration actions." > > I think this should stay a "MAY". In normal hierarchy reconfiguration, > calls are going to be disrupted. It is far more complex to insist > somehow that the protocol keeps calls in tact during such > reconfigurations. The final version retained "MAY" Hoping that we are closed on this and can move the draft forwards. Thanks, Adrian From owner-ccamp@ops.ietf.org Thu Apr 29 06:54:06 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19654 for ; Thu, 29 Apr 2004 06:54:06 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJ9B7-0001FC-HJ for ccamp-archive@ietf.org; Thu, 29 Apr 2004 06:54:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJ9AE-00014C-00 for ccamp-archive@ietf.org; Thu, 29 Apr 2004 06:53:10 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BJ99Z-0000tZ-00 for ccamp-archive@ietf.org; Thu, 29 Apr 2004 06:52:29 -0400 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BJ8z3-000ITZ-3p for ccamp-data@psg.com; Thu, 29 Apr 2004 10:41:37 +0000 Received: from [195.8.69.15] (helo=oceanus.uk.clara.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BJ8z1-000IT8-KB for ccamp@ops.ietf.org; Thu, 29 Apr 2004 10:41:35 +0000 Received: from claranet by oceanus.uk.clara.net with local (Exim 4.22) id 1BJ8z5-0003O0-Ii; Thu, 29 Apr 2004 11:41:39 +0100 From: "Adrian Farrel" To: ccamp@ops.ietf.org Cc: adrian@olddog.co.uk Reply-To: adrian@olddog.co.uk Subject: Re: Last Call Complete: draft-ietf-ccamp-gmpls-ason-routing-reqts-03.txt Date: Thu, 29 Apr 2004 11:41:39 +0100 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Remote_Addr: 156.106.231.246 Message-Id: Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Ooops, I forgot my own last call comments. Can the team please incorporate my nits and re-publish? Thanks, Adrian From owner-ccamp@ops.ietf.org Thu Apr 29 12:40:38 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13006 for ; Thu, 29 Apr 2004 12:40:38 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJEaS-0003Tr-LL for ccamp-archive@ietf.org; Thu, 29 Apr 2004 12:40:36 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJEZZ-0003Bb-00 for ccamp-archive@ietf.org; Thu, 29 Apr 2004 12:39:42 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BJEYz-0002tC-00 for ccamp-archive@ietf.org; Thu, 29 Apr 2004 12:39:05 -0400 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BJEGs-000K9w-AN for ccamp-data@psg.com; Thu, 29 Apr 2004 16:20:22 +0000 Received: from [192.75.23.69] (helo=tm1.ca.alcatel.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BJEGp-000K9a-Ik for ccamp@ops.ietf.org; Thu, 29 Apr 2004 16:20:21 +0000 Received: from camail03.ca.alcatel.com (localhost [127.0.0.1]) by tm1.ca.alcatel.com (8.12.10/8.12.10) with ESMTP id i3TGKHdh014004 for ; Thu, 29 Apr 2004 12:20:18 -0400 (EDT) Received: from alcatel.com ([138.120.234.2]) by camail03.ca.alcatel.com (Netscape Messaging Server 4.15) with ESMTP id HWXXDS00.TD0; Thu, 29 Apr 2004 12:20:16 -0400 Message-ID: <40912AC1.94B793FE@alcatel.com> Date: Thu, 29 Apr 2004 12:18:09 -0400 From: Cheng-Yin Lee Reply-To: Cheng-Yin.Lee@alcatel.com X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: dachille@coritel.it, listanti@infocom.uniroma1.it, monaco@infocom.uniroma.it.cnri.reston.va.us, ricciato@coritel.it, v.sharma@ieee.org CC: ccamp Subject: Limitations overcomed by ARO Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 8bit Alessio, Marco, Ugo, Fabio, Vishal, As I understand this draft overcomes the following limitations: ".... we propose an alternative approach, based on the joint computation of the two paths in a distributed manner, which overcomes ..." "... two main limitations: - Trapping - Sub-optimal route selection " Could you please confirm if the following can be overcomed using the scheme described (quoted below) in the draft : * Can the path setup for the first LSP (computed by the head-end) lead to trapping in the second area or sub-optimal route selection if the head-end node only has link state information of the first areas * Can an ABR in Area 1 & 2 compute paths to avoid trapping in Area 3 if the ABR in Area 1 & 2 only has link states of these 2 areas? "While the path of the first LSP - that is, the one being installed during the first phase - is included in the ERO, the route of the second LSP - which will be installed in the second phase û will be collected in the ARO during the first phase itself. At the end of the first phase, the ARO collecting the e2e route of the second LSP is returned to the head-end node, which can then install it as an ER-LSP." ? * Can a head-end node in AS1 avoid trapping in the network if the head-end node only knows about link states in AS1 and the virtual links to other ASes? "... can model a multi-AS network. ... JSA minimizes the number of areas that the two LSPs share, and if two area-disjoint paths are present in the network, JSA can compute them;" "Node A computes two disjoint paths between itself and B, within area 1, with a inter-area topological view as shown in Fig. 5b; in this case, node A MUST prune all the border nodes, except one for every area connected to area 1, before the disjoint route selection algorithm is performed; as a result, the two LSPs will not cross the same next area, and will follow the computed inter-area path. Thanks Cheng-Yin From owner-ccamp@ops.ietf.org Thu Apr 29 13:41:27 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15668 for ; Thu, 29 Apr 2004 13:41:27 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJFXI-0004E5-3X for ccamp-archive@ietf.org; Thu, 29 Apr 2004 13:41:24 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJFWN-0003vE-00 for ccamp-archive@ietf.org; Thu, 29 Apr 2004 13:40:28 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BJFVO-0003ej-00 for ccamp-archive@ietf.org; Thu, 29 Apr 2004 13:39:26 -0400 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BJFJm-0005zV-Qn for ccamp-data@psg.com; Thu, 29 Apr 2004 17:27:26 +0000 Received: from [171.68.10.87] (helo=sj-iport-5.cisco.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BJFJl-0005z9-N8 for ccamp@ops.ietf.org; Thu, 29 Apr 2004 17:27:25 +0000 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 29 Apr 2004 10:27:41 -0700 Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id i3THRJ0Q023854; Thu, 29 Apr 2004 10:27:19 -0700 (PDT) Received: from jvasseur-w2k01.cisco.com (che-vpn-cluster-2-131.cisco.com [10.86.242.131]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id KAA16351; Thu, 29 Apr 2004 10:27:17 -0700 (PDT) Message-Id: <4.3.2.7.2.20040429132151.0601cb98@wells.cisco.com> X-Sender: jvasseur@wells.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 29 Apr 2004 13:24:47 -0400 To: From: Jean Philippe Vasseur Subject: RE: RE : RE : Proposed strategy for Inter-area/AS Cc: "ricciato" , "LE ROUX Jean-Louis FTRD/DAC/LAN" , , In-Reply-To: References: <408D3FC2.5060606@coritel.it> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Hi Vishal, At 01:26 PM 4/26/2004 -0700, Vishal Sharma wrote: >Hi Fabio, JL, et al > >I think Fabio may have a good idea here. It provides the flexibility >of having info. about all affinities, with the scalability of advertizing >only limited information. This problem has been investigated for a while and there many constraints=20 that cannot be aggregated in a simple/efficient manner, leading to the=20 constraint of having to flood a un-reasonable amount of TE-related info to= =20 make it useful enough to compute an optimal (shortest) path with some good= =20 chance of set up success. Cheers JP. >Perhaps we can explore a bit where there might be issues, and refine >this initial solution to get something that we believe is appropriate. > >-Vishal > > > -----Original Message----- > > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On > > Behalf Of ricciato > > Sent: Monday, April 26, 2004 9:59 AM > > To: LE ROUX Jean-Louis FTRD/DAC/LAN > > Cc: adrian@olddog.co.uk; ccamp@ops.ietf.org > > Subject: Re: RE : RE : Proposed strategy for Inter-area/AS > > > > > > Dear JL, > > > > you=B4re right. > > > > Just a quick proposal. > > In an attempt to limit the number of virtual link advertised, > > would it make sense to advertise only K virtual links, where K=3D{number > > of colors}, and for each of them (say j) advertise the maximum > > bandwdith over all links that have color j into their admin_group ? > > > > For example, in your example (with Path 4 added) > > > > Path 1: bw 100M admin group {green;blue} > > Path 2: bw 50M admin group {red; blue} > > Path 3: bw 5M admin group {red;green} > > Path 4: bw 50M admin group {red} > > > > One should advertise > > Virtual Link 1: bw 100M admin group {green} --->max(100M,5M) > > Virtual Link 2: bw 50M admin group {red} --->max(50M,5M,50M) > > Virtual Link 3: bw 100M admin group {gblue} --->max(100M,50M) > > > > > > Assuming that the number of colors << number of possible links, > > this approach might cap the amount of advertisement. > > > > But I=B4m not sure it works ... > > > > ciao > > fabio > > > > LE ROUX Jean-Louis FTRD/DAC/LAN wrote: > > > > >Hi Fabio, > > > > > >Advertising only a subset would improve scalability, but > > >this would not be enough to correclty select the best path. > > > > > >Let's assume that there are three paths from a given ABR X to a > > given destination D > > >Path 1: bw 100M admin group {green;blue} > > >Path 2: bw 50M admin group {red; blue} > > >Path 3: bw 5M admin group {red;green} > > > > > >and a TE-LSP L : Destination D, bw=3D 4M, affinity=3D exlude blue > > > > > >If you advertise only Path 1 and Path 2 as virtual links, ABR X > > will never be selected as next ABR for this TE-LSP, while path 3 > > is a feasible path. > > > > > >Regards > > > > > >JL > > > > > > > > > > > > > > > > > >>-----Message d'origine----- > > >>De : owner-ccamp@ops.ietf.org > > >>[mailto:owner-ccamp@ops.ietf.org] De la part de ricciato > > >>Envoy=E9 : lundi 26 avril 2004 09:48 > > >>=C0 : LE ROUX Jean-Louis FTRD/DAC/LAN > > >>Cc : adrian@olddog.co.uk; ccamp@ops.ietf.org > > >>Objet : Re: RE : Proposed strategy for Inter-area/AS > > >> > > >> > > >>Hi JL, > > >> > > >>just a quick remark: would it make sense in this case to > > >>advertise only > > >>a selected subset of the N virtual links (say the two with > > >>most residual > > >>bw) ? > > >> > > >>ciao > > >>fabio > > >> > > >>LE ROUX Jean-Louis FTRD/DAC/LAN wrote: > > >> > > >> > > >> > > >>>Let's assume that there are N distinct paths from ABR A to a > > >>>destination X, each with a distinct bandwidth and distinct > > >>> > > >>> > > >>admin-group > > >> > > >> > > >>>(a path admin group being expressed as a logical AND of the > > >>> > > >>> > > >>link admin > > >> > > >> > > >>>groups along the path) How can you summarize such topology ? > > >>> > > >>> > > >>Actually > > >> > > >> > > >>>you need to advertise N virtual links, each with a distinct > > >>> > > >>> > > >>admin-group > > >> > > >> > > >>>and available bandwidth. > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> > > >> > > >> > > >> > > > > > > > > > > > > > > From owner-ccamp@ops.ietf.org Thu Apr 29 13:42:38 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15810 for ; Thu, 29 Apr 2004 13:42:38 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJFYR-0004YW-El for ccamp-archive@ietf.org; Thu, 29 Apr 2004 13:42:35 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJFXa-0004GF-00 for ccamp-archive@ietf.org; Thu, 29 Apr 2004 13:41:44 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BJFWm-0003y2-00 for ccamp-archive@ietf.org; Thu, 29 Apr 2004 13:40:53 -0400 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BJFJu-00060i-3S for ccamp-data@psg.com; Thu, 29 Apr 2004 17:27:34 +0000 Received: from [171.71.176.72] (helo=sj-iport-3.cisco.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BJFJs-00060L-Sd for ccamp@ops.ietf.org; Thu, 29 Apr 2004 17:27:32 +0000 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 29 Apr 2004 09:40:52 +0000 Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i3THRRW9027193; Thu, 29 Apr 2004 10:27:27 -0700 (PDT) Received: from jvasseur-w2k01.cisco.com (che-vpn-cluster-2-131.cisco.com [10.86.242.131]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id KAA16574; Thu, 29 Apr 2004 10:27:23 -0700 (PDT) Message-Id: <4.3.2.7.2.20040429130446.020cf0e0@wells.cisco.com> X-Sender: jvasseur@wells.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 29 Apr 2004 13:27:22 -0400 To: From: Jean Philippe Vasseur Subject: RE: comments on ARO Cc: , , "Fabio Ricciato" , "Ugo Monaco" , "Alessio D'Achille" , "Marco Listanti" In-Reply-To: References: <408D37FA.2254D30F@alcatel.be> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Hi Vishal, Comments in line, At 09:35 PM 4/28/2004 -0700, Vishal Sharma wrote: >Hi Stefaan, > >Thanks for your follow-on inputs. Few comments in-line. > >We look forward to any additional feedback you have. > >Regards, >-Vishal > > > -----Original Message----- > > From: stefaan.de_cnodder@alcatel.be > > [mailto:stefaan.de_cnodder@alcatel.be] > > Sent: Monday, April 26, 2004 9:26 AM > > To: v.sharma@ieee.org > > Cc: ccamp@ops.ietf.org; Fabio Ricciato; Ugo Monaco; Alessio D'Achille; > > Marco Listanti > > Subject: Re: comments on ARO > > > > > > > > Hi Vishal, > > > > please find some more comments inline... > > > > Vishal Sharma wrote: > > > > > > Hi Stefaan, > > > > > > Thanks a lot for looking over the draft so carefully, and for your > > > many detailed comments. > > > > > > While we will address the individual comments once we've digested > > > them a bit (and in a separate email to avoid making this one > > > too long :-)), let me try to address a couple of the most important > > > points raised in your note below. > > > > > > 1) Recording only border nodes: > > > > > > Actually, if one only recorded border nodes, then upon signaling > > > the secondary, the ingress border node for the secondary has no > > > idea about the intra-area (or intra-AS) path of the primary (in its > > > own area or AS), and therefore cannot ensure that the primary and > > > secondary segments are in fact disjoint. > > > > > > This was a point I discussed with several other people > > > (who initially proposed the same thing), including > > > Arthi and Adrian, but we concluded, for the reason above, that merely > > > recording the border nodes does not work for diversity. As a > > > result, the ARO does, in fact, serve a very useful purpose. > > > > > > We can of course think more about what the trade-offs are, and > > see if there > > > is some way to retain the main advantage of the proposal (diversity, > > > joint optimization of both paths) while also recording less information. > > > > > > > The problem I want to solve here is NOT to reduce the amount of > > information in the ARO, i.e. my purpose is not to reduce its length. > > Rather, by only recording the border nodes you give more freedom > > when signaling the secondary (using the XRO!) meaning that when > > crankback or re-optimization of the secondary is possible, the > > primary does not have to be resignaled to get a new ARO. > >Sure, I understood that the goal wasn't to reduce the length of >the ARO per se, but rather the level of detail that would need to >be recorded in it (regardless of the actual amount of data the ARO >would carry). > >If you recollect the classification of path computation models >I gave in my email to JP >http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00467.html > >we have under distributed computing: i) a parallel path computation >model and ii) a sequential one. >ARO achieves the former, while XRO achieves the latter. > >So, if one did not compute and record the path of the secondary >jointly with the primary (and only recorded the border nodes instead) >the scheme would reduce to a _sequential path computation_, with its >attendant drawbacks (sub-optimality, trap topology, etc.). > >The beauty of the ARO scheme is that it can compute end-to-end >diverse paths using a parallel path computation model (albeit distributed >at each area/AS), with the simplicity of the per-domain approach, and >without any changes to the signaling protocols. Here is one of main concerns that I have about this scheme: by contrast with a distributed PCE-approach, a severe drawback with such a model lies in the potential number of retrials (since it has to be combined with crankback) and consequently the potential set up time. Indeed, you may have diverse paths within a domain, and then a set up failure in the next hop domain requiring to crankback in the previous domain; the number of potential trials may be really non negligible. Moreover, you can still cannot guarantee and an end to end shortest path. >Please note also that this does not say anything about the usefulness of >the XRO (which _is_ a v. useful construct, with several applications, as >pointed out in my earlier email), only that when paths are computed >sequentially these problems arise. > > > > > > 2) With regard to optimizing only the path of the primary, I am not > > > so sure about doing just that. > > > > > > I believe one can get into real problems if one does not constrain > > > the path/cost of the secondary, with unduly long secondaries that > > > will greatly limit the ability to setup further primaries > > > (and secondaries). (This can be especially true of tranport networks, > > > where one would set up very large bandwidth pipes, and optimizing their > > > > placement would be critical.) > > > > > > This scheme is optimizing jointly the cost of the primary and > > > secondary, while ensuring diversity. > > > > > > > My question was *what* is the metric being optimized. For instance > > with sequential computing, the cost of the primary is minimized, > > while the second metric is the cost of the secondary LSP. With > > parallel computing it is different: is the cost being minimized the > > cost of primary + cost of secondary, or is it something else? > >Minimizing the cost of the primary + cost of secondary is one metric >that a parallel path computation scheme may minimize. There might >be others. For e.g. minimize the cost of primary while keeping that >of secondary below a certain threshold, minimize the difference >between the costs of the primary and the secondary, and so on. > >The actual criteria for minimization may be a provider choice, >that is executed/realized by the joint path computation algo. >employed in the network nodes. Right - same comments applies to the distributed PCE-based approach, > > > I think you will find that most providers would be equally concerned > > > with the cost/placement of the secondary path. > > > > > > Moreover, as I emphasized (and as discussed during CCAMP we wiil change > > > the title and our intro. to reflect that), this is a: > > > generic method for computing diverse paths > > > that meets a variety of requirements: load balancing, multipe paths > > > when a single one has insufficient capacity, multiple paths between > > > VoIP gateways, etc. in all of which one would ideally be looking for > > > paths with about equal length. > > > Protection is just _one_ application of this scheme. > > > > > > > This load balancing over multiple paths looks like a good > > application. > >Great, thanks. This is why JL and others have asked us to >not limit our scheme only to restoration applications. > >And we will do this generalization in the update. We mentioned that application indeed in the requirements drafts. JP. > > > 3) Re-optimization, crankback, and failure of secondary: > > > > > > I think the scheme works with all of these, and does not really > > > conflict with any of them. > > > > > > With crankback, there should be no problem, whenever a crankback occurs > > > on the primary, the secondary will also be recomputed at the ASBR/ABR > > > to which there is crankback. > > > > > > With re-optimization, there are several options. > > > > > > -- Either default to sequential calculation, and use the XRO to > > re-optimize > > > whichever of the two diverse paths requires re-optimization. > > > (This might be an immediate response, while the below could be > > > a more long-term response.) > > > > > > > Since an ABR on the secondary path only sees a full strict path in > > the ERO, the ABR does not know when there is a better path matching > > the constraints. This is because the ABR does not know the > > constraints. > > > > > -- Or, if the goal really is joint optimization, the provider will have > > > to setup a new set of diverse paths, and use make-before-break to > > > transition the traffic over. > > > > > > -- If the secondary fails, again there are two options. Either use > > > the XRO to perform another path setup (and, possibly, re-optimize > > > the paths later), or use the joint optimization method above with > > > make-before-break. > > > > > > > This looks ok. > >Great, thanks. We will add this discussion to our revised >draft. > > > > > > 4) Relationship to XRO: > > > As I mentioned in the Seoul presentation and also > > > in our discussion, I think the XRO has many uses -- during computation > > > after crankback, to enable adminstrative routing/re-routing, protection, > > > etc. > > > > > > So I think the ARO and XRO are actually complementary. > > > > > > Regards, > > > -Vishal > > > > > > > -----Original Message----- > > > > From: stefaan.de_cnodder@alcatel.be > > > > [mailto:stefaan.de_cnodder@alcatel.be] > > > > Sent: Monday, April 19, 2004 12:08 PM > > > > To: v.sharma@ieee.org > > > > Cc: ccamp@ops.ietf.org > > > > Subject: comments on ARO > > > > > > > > > > > > > > > > Hi Vishal, > > > > > > > > looking to draft-dachille, I have following comments: > > > > > > > > 1) Second paragraph in section 2 is not clear: "we will assume that > > > > every > > > > inter-area connection is duplicated". I understood from it that when > > > > the > > > > primary path follows Area1-Area2-Area3, then also the secondary has > > > > to > > > > follow this path but using other border nodes. But then from section > > > > 4.2 I > > > > understand that this is not an assumption? > > > > > > > > 2) step 2c on page 5: also E, G and H has to be pruned? It is also > > > > not > > > > clear which path is selected in area 3: I guess it is E-G-H for > > > > primary and > > > > F-H for secondary? > > > > > > > > 3) (!) page 7, about the trap-avoid reference: If fact it is just a > > > > matter > > > > of doing a good path calculation. If the primary is signaled and > > > > border > > > > nodes know that also a secondary has to be established, then it can > > > > make > > > > sure that the primary does not introduce such a trap. This assumes > > > > that the > > > > border node also has to know that a secondary has to be established. > > > > This > > > > is known by the presence of the ARO object but this does not mean > > > > that at > > > > the end, the ARO has to contain a full strict path of the secondary. > > > > Border > > > > nodes can expand the ARO by only including the border nodes for the > > > > secondary. This means that the path calculation of the secondary is > > > > not > > > > anymore 100% bound to the primary. Also I would prefer that the ARO > > > > is more > > > > like a "hint" than the real path. With this, you do not have to > > > > interaction > > > > problems with re-optimization of secondary, crankback, ... For > > > > instance: > > > > when the secondary fails, it can be re-established ignoring the ARO. > > > > Or > > > > when the secondary can be re-optimzed between border nodes, then it > > > > can be > > > > done without impacting the primary or when the global > > > > re-optimization is > > > > possible, then the ARO can be simple ignored. > > > > > > > > I prefer to have the ARO only recording border nodes, and optionally > > > > only > > > > acting as a hint for the ingress LSR. The latter is less important > > > > to me. > > > > > > > > 4) text below figure 3: primary has to be as short as possible. I do > > > > not > > > > care much about the secondary becuase it is almost never used. Also, > > > > the > > > > resources that it reserves can be shared with other secondaries. The > > > > problem here is: what are you optimizing? According to me the path > > > > of the > > > > primary has to be optimized. > > > > > > > > 5) I do not understand why the ARO has to contain Area-Ids to > > > > indicate the > > > > route. If the ingress can put the "area-path" in the ARO, then it > > > > can also > > > > put the border nodes in the ERO of the secondary immediately. I.e. > > > > refering > > > > to figure 5: A knows that the path of the secondary is A1-A2-A5-A6. > > > > How > > > > does A know this? And if it is possible to let A know this > > > > information, > > > > then why could it also not know that the path is B1-B7-B9. If A can > > > > do > > > > this, then there is no need anymore for ARO. So the basic question > > > > is: what > > > > makes it easier for A to know A1-A2-A5-A6 instead of B1-B7-B9. This > > > > means > > > > to me that section 4.2 is not valid and that the ARO assumes that > > > > the > > > > "area-path" of primary and secondary is the same, which is true for > > > > IGP > > > > areas. See also comment 2. Maybe better to remove the AREA-IDs from > > > > the > > > > ARO. > > > > > > > > 6) step 1d page 14, second last line: how does the ABR know that B7 > > > > has to > > > > be used and not B8? > > > > > > > > 7) section 4.3: also describe the L-bit that is in the ERO > > > > subobjects. > > > > > > > > 8) Is the Addr_len in for instance subobject 1 always 32 or can it > > > > be > > > > something else. I agree here that you should re-use ERO subobjects > > > > but I > > > > see that you are doing this. > > > > > > > > 9) Section 4.3.2.3, area_ID: types 3, 4 and 5 are defined but that > > > > conflicts with what is described in the middle of page 19 where the > > > > numbers > > > > are 32, 33, 34. > > > > > > > > 10) the text in section 4.3.3 is rather confusing (the part in the > > > > middle > > > > of page 22, about pruning the nodes). Take figure 5, area 5: If B6 > > > > has to > > > > calculate a path from B6 to B10, then this path can pass via B5, B8, > > > > B7 > > > > and/or B9. This is because border nodes can also act as core nodes > > > > at the > > > > same time. This seems to be excluded from the draft. Is that > > > > correct? > > > > > > > > 11) First refinement in section 5 about the cost of virtual links: > > > > this has > > > > been proposed before in > > > > http://www.watersprings.org/pub/id/draft-venkatachalam-interarea-m > > > >pls-te-02.txt > > > >which is not a good idea: it only works for inter-IGP area and it > > > >decreases > > > >the scalability although it also has some advantages. > > > > > > >12) (!) There are conflicts with re-optimization, crankback, > > > >re-establishement after failure of secondary LSP, ... because in all > > > >of > > > >these cases a working primary LSP also have to be re-signaled which > > > >is not > > > >good. Therefore it is better to let the ARO only record border > > > >nodes, > > > >and/or to use the ARO more as a hint for the secondary: using the > > > >ARO in > > > >the primary makes sure that a trap is avoided, and then it is up to > > > >the > > > >signaling of the secondary to find this path by using crankback, > > > >.... There > > > >is no need that the primary LSP also gives the path, it only has to > > > >make > > > >sure that there is a path. > > > > > > > >13) (!) The method seems not to be applicable for inter-AS > > > >calculations. > > > > > > > >14) Following the classification of methods (ARO, XRO, PCE) that you > > > >described earlier on ccamp based on parallel/sequential and > > > >distributed/centralized computation, ARO looks more an alternative > > > >for PCE than for XRO? In fact, would it be possible to combine > > > >methods? It would be good to explain the interaction (if any) with > > > >these other methods. > > > > > > > >Hope this helps, > > > > > > > >regards, > > > > > > > >Stefaan From owner-ccamp@ops.ietf.org Thu Apr 29 13:50:48 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16647 for ; Thu, 29 Apr 2004 13:50:48 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJFgL-0007HA-D2 for ccamp-archive@ietf.org; Thu, 29 Apr 2004 13:50:45 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJFfN-0006vN-00 for ccamp-archive@ietf.org; Thu, 29 Apr 2004 13:49:46 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BJFe8-0006YI-00 for ccamp-archive@ietf.org; Thu, 29 Apr 2004 13:48:28 -0400 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BJFTR-0007o0-Sp for ccamp-data@psg.com; Thu, 29 Apr 2004 17:37:25 +0000 Received: from [171.71.176.71] (helo=sj-iport-2.cisco.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BJFTQ-0007nR-9L for ccamp@ops.ietf.org; Thu, 29 Apr 2004 17:37:24 +0000 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 29 Apr 2004 09:49:30 +0000 Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i3THbLC1001417; Thu, 29 Apr 2004 10:37:21 -0700 (PDT) Received: from jvasseur-w2k01.cisco.com (che-vpn-cluster-2-131.cisco.com [10.86.242.131]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id KAA07515; Thu, 29 Apr 2004 10:37:17 -0700 (PDT) Message-Id: <4.3.2.7.2.20040429132816.020cfe88@wells.cisco.com> X-Sender: jvasseur@wells.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 29 Apr 2004 13:33:04 -0400 To: From: Jean Philippe Vasseur Subject: RE: comments on ARO Cc: , , "Fabio Ricciato" , "Ugo Monaco" , "Alessio D'Achille" , "Marco Listanti" In-Reply-To: References: <408D37FA.2254D30F@alcatel.be> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Hi Vishal, Sorry for the burst of comments ... [snip] > > > 3) Re-optimization, crankback, and failure of secondary: > > > > > > I think the scheme works with all of these, and does not really > > > conflict with any of them. > > > > > > With crankback, there should be no problem, whenever a crankback occurs > > > on the primary, the secondary will also be recomputed at the ASBR/ABR > > > to which there is crankback. See my previous email about the set up time issue > > > > > > With re-optimization, there are several options. > > > > > > -- Either default to sequential calculation, and use the XRO to > > re-optimize > > > whichever of the two diverse paths requires re-optimization. But then you may pretty likely fall back to the trapping problem ... > > > (This might be an immediate response, while the below could be > > > a more long-term response.) > > > > > > > Since an ABR on the secondary path only sees a full strict path in > > the ERO, the ABR does not know when there is a better path matching > > the constraints. This is because the ABR does not know the > > constraints. > > > > > -- Or, if the goal really is joint optimization, the provider will have > > > to setup a new set of diverse paths, and use make-before-break to > > > transition the traffic over. Looks to me as the only viable option if: -> You still want to limit the trapping problem, -> You implement any algorithm trying to optimize a set of constraints for both the primary and secondary. Cheers JP. > > > > > > -- If the secondary fails, again there are two options. Either use > > > the XRO to perform another path setup (and, possibly, re-optimize > > > the paths later), or use the joint optimization method above with > > > make-before-break. > > > > > > > This looks ok. > >Great, thanks. We will add this discussion to our revised >draft. > > > > > > 4) Relationship to XRO: > > > As I mentioned in the Seoul presentation and also > > > in our discussion, I think the XRO has many uses -- during computation > > > after crankback, to enable adminstrative routing/re-routing, protection, > > > etc. > > > > > > So I think the ARO and XRO are actually complementary. > > > > > > Regards, > > > -Vishal > > > > > > > -----Original Message----- > > > > From: stefaan.de_cnodder@alcatel.be > > > > [mailto:stefaan.de_cnodder@alcatel.be] > > > > Sent: Monday, April 19, 2004 12:08 PM > > > > To: v.sharma@ieee.org > > > > Cc: ccamp@ops.ietf.org > > > > Subject: comments on ARO > > > > > > > > > > > > > > > > Hi Vishal, > > > > > > > > looking to draft-dachille, I have following comments: > > > > > > > > 1) Second paragraph in section 2 is not clear: "we will assume that > > > > every > > > > inter-area connection is duplicated". I understood from it that when > > > > the > > > > primary path follows Area1-Area2-Area3, then also the secondary has > > > > to > > > > follow this path but using other border nodes. But then from section > > > > 4.2 I > > > > understand that this is not an assumption? > > > > > > > > 2) step 2c on page 5: also E, G and H has to be pruned? It is also > > > > not > > > > clear which path is selected in area 3: I guess it is E-G-H for > > > > primary and > > > > F-H for secondary? > > > > > > > > 3) (!) page 7, about the trap-avoid reference: If fact it is just a > > > > matter > > > > of doing a good path calculation. If the primary is signaled and > > > > border > > > > nodes know that also a secondary has to be established, then it can > > > > make > > > > sure that the primary does not introduce such a trap. This assumes > > > > that the > > > > border node also has to know that a secondary has to be established. > > > > This > > > > is known by the presence of the ARO object but this does not mean > > > > that at > > > > the end, the ARO has to contain a full strict path of the secondary. > > > > Border > > > > nodes can expand the ARO by only including the border nodes for the > > > > secondary. This means that the path calculation of the secondary is > > > > not > > > > anymore 100% bound to the primary. Also I would prefer that the ARO > > > > is more > > > > like a "hint" than the real path. With this, you do not have to > > > > interaction > > > > problems with re-optimization of secondary, crankback, ... For > > > > instance: > > > > when the secondary fails, it can be re-established ignoring the ARO. > > > > Or > > > > when the secondary can be re-optimzed between border nodes, then it > > > > can be > > > > done without impacting the primary or when the global > > > > re-optimization is > > > > possible, then the ARO can be simple ignored. > > > > > > > > I prefer to have the ARO only recording border nodes, and optionally > > > > only > > > > acting as a hint for the ingress LSR. The latter is less important > > > > to me. > > > > > > > > 4) text below figure 3: primary has to be as short as possible. I do > > > > not > > > > care much about the secondary becuase it is almost never used. Also, > > > > the > > > > resources that it reserves can be shared with other secondaries. The > > > > problem here is: what are you optimizing? According to me the path > > > > of the > > > > primary has to be optimized. > > > > > > > > 5) I do not understand why the ARO has to contain Area-Ids to > > > > indicate the > > > > route. If the ingress can put the "area-path" in the ARO, then it > > > > can also > > > > put the border nodes in the ERO of the secondary immediately. I.e. > > > > refering > > > > to figure 5: A knows that the path of the secondary is A1-A2-A5-A6. > > > > How > > > > does A know this? And if it is possible to let A know this > > > > information, > > > > then why could it also not know that the path is B1-B7-B9. If A can > > > > do > > > > this, then there is no need anymore for ARO. So the basic question > > > > is: what > > > > makes it easier for A to know A1-A2-A5-A6 instead of B1-B7-B9. This > > > > means > > > > to me that section 4.2 is not valid and that the ARO assumes that > > > > the > > > > "area-path" of primary and secondary is the same, which is true for > > > > IGP > > > > areas. See also comment 2. Maybe better to remove the AREA-IDs from > > > > the > > > > ARO. > > > > > > > > 6) step 1d page 14, second last line: how does the ABR know that B7 > > > > has to > > > > be used and not B8? > > > > > > > > 7) section 4.3: also describe the L-bit that is in the ERO > > > > subobjects. > > > > > > > > 8) Is the Addr_len in for instance subobject 1 always 32 or can it > > > > be > > > > something else. I agree here that you should re-use ERO subobjects > > > > but I > > > > see that you are doing this. > > > > > > > > 9) Section 4.3.2.3, area_ID: types 3, 4 and 5 are defined but that > > > > conflicts with what is described in the middle of page 19 where the > > > > numbers > > > > are 32, 33, 34. > > > > > > > > 10) the text in section 4.3.3 is rather confusing (the part in the > > > > middle > > > > of page 22, about pruning the nodes). Take figure 5, area 5: If B6 > > > > has to > > > > calculate a path from B6 to B10, then this path can pass via B5, B8, > > > > B7 > > > > and/or B9. This is because border nodes can also act as core nodes > > > > at the > > > > same time. This seems to be excluded from the draft. Is that > > > > correct? > > > > > > > > 11) First refinement in section 5 about the cost of virtual links: > > > > this has > > > > been proposed before in > > > > http://www.watersprings.org/pub/id/draft-venkatachalam-interarea-m > > > >pls-te-02.txt > > > >which is not a good idea: it only works for inter-IGP area and it > > > >decreases > > > >the scalability although it also has some advantages. > > > > > > >12) (!) There are conflicts with re-optimization, crankback, > > > >re-establishement after failure of secondary LSP, ... because in all > > > >of > > > >these cases a working primary LSP also have to be re-signaled which > > > >is not > > > >good. Therefore it is better to let the ARO only record border > > > >nodes, > > > >and/or to use the ARO more as a hint for the secondary: using the > > > >ARO in > > > >the primary makes sure that a trap is avoided, and then it is up to > > > >the > > > >signaling of the secondary to find this path by using crankback, > > > >.... There > > > >is no need that the primary LSP also gives the path, it only has to > > > >make > > > >sure that there is a path. > > > > > > > >13) (!) The method seems not to be applicable for inter-AS > > > >calculations. > > > > > > > >14) Following the classification of methods (ARO, XRO, PCE) that you > > > >described earlier on ccamp based on parallel/sequential and > > > >distributed/centralized computation, ARO looks more an alternative > > > >for PCE than for XRO? In fact, would it be possible to combine > > > >methods? It would be good to explain the interaction (if any) with > > > >these other methods. > > > > > > > >Hope this helps, > > > > > > > >regards, > > > > > > > >Stefaan From owner-ccamp@ops.ietf.org Thu Apr 29 14:19:25 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18112 for ; Thu, 29 Apr 2004 14:19:24 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJG81-0007ZT-Td for ccamp-archive@ietf.org; Thu, 29 Apr 2004 14:19:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJG73-0007Ib-00 for ccamp-archive@ietf.org; Thu, 29 Apr 2004 14:18:22 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BJG66-00072V-00 for ccamp-archive@ietf.org; Thu, 29 Apr 2004 14:17:22 -0400 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BJFuW-000Dlv-RH for ccamp-data@psg.com; Thu, 29 Apr 2004 18:05:24 +0000 Received: from [62.23.212.165] (helo=smail.alcatel.fr) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BJFuU-000Dku-Ow for ccamp@ops.ietf.org; Thu, 29 Apr 2004 18:05:22 +0000 Received: from bemail05.netfr.alcatel.fr (bemail05.netfr.alcatel.fr [155.132.251.11]) by smail.alcatel.fr (ALCANET/NETFR) with ESMTP id i3TI1d0O019828; Thu, 29 Apr 2004 20:01:39 +0200 Received: from alcatel.be ([138.203.64.239]) by bemail05.netfr.alcatel.fr (Lotus Domino Release 5.0.11) with ESMTP id 2004042920013782:5094 ; Thu, 29 Apr 2004 20:01:37 +0200 Message-ID: <40914396.1060306@alcatel.be> Date: Thu, 29 Apr 2004 20:04:06 +0200 From: Dimitri.Papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.5) Gecko/20030925 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ricciato Cc: ugo monaco , ccamp , Zafar Ali Subject: Re: Diverse path failure and optimality in draft-dachille-inter-area-path-protection References: <408C5733.1000708@infocom.uniroma1.it> <408D12E3.5030806@alcatel.be> <408E3945.3030601@coritel.it> In-Reply-To: <408E3945.3030601@coritel.it> X-MIMETrack: Itemize by SMTP Server on BEMAIL05/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 04/29/2004 20:01:37, Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 04/29/2004 20:01:39 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: base64 X-Alcanet-MTA-scanned-and-authorized: yes Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.5 required=5.0 tests=AWL,MIME_BASE64_LATIN, MIME_BASE64_TEXT,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: base64 aGkgLSBzZWUgaW4tbGluZQ0KDQpyaWNjaWF0byB3cm90ZToNCg0KPiBIaSBEaW1pdHJpLA0KPiAN Cj4gdGhhbmtzIGZvciB5b3VyIGNvbW1lbnRzLCBzZWUgaW5saW5lLg0KPiANCj4gY2lhbw0KPiBG YWJpbw0KPiANCj4gRGltaXRyaS5QYXBhZGltaXRyaW91QGFsY2F0ZWwuYmUgd3JvdGU6DQo+IA0K Pj4NCj4+IGhpLCBieSBkaXNjdXNzaW5nIHRoZSBwcm9wb3NlZCBtZXRob2QgdGhlcmUgc2VlbXMg dG8gYmUgdGhyZWUgaXNzdWVzIA0KPj4gdGhhdCBtYWtlIHRoZSBtZXRob2QgcXVlc3Rpb25hYmxl IGluIHRlcm1zIG9mIGd1YXJhbnRlZSB0byBkZWxpdmVyIA0KPj4gd2hhdCBpdCBpbnRlbmRzIHRv IGRlbGl2ZXIsIGl0cyB1c2FiaWxpdHkgKHRoZSB0aW1lIHZhbGlkaXR5IG9mIHRoZSANCj4+IHBh dGggaXMgbm90IGd1YXJhbnRlZWQpIGFuZCBpdHMgYXBwbGljYWJpbGl0eSBpbiB0ZXJtcyBvZiBv YmplY3RpdmUgDQo+PiBpbml0aWFsbHkgdGFyZ2V0ZWQgd3J0IHRvIHRoZSBuZXR3b3JrIHRvcG9s b2d5DQo+Pg0KPj4gMSkgaW1hZ2luZSB0aHJlZSBhcmVhcyBkZWNvdXBsZWQgY29tcHV0YXRpb24g YXMgZXhwbGFpbmVkIGF0IHRoZWlyDQo+PiByZXNwZWN0aXZlIGluZ3Jlc3MsIHdpdGggQVJPIG1l dGhvZDsgaG93IHRoZSB0aGlyZCBjb21wdXRhdGlvbiBlbGVtZW50DQo+PiAodGFpbC1lbmQpIGlz IGF3YXJlIG9mIHNybGcncyB0aGF0IG1heSBhZmZlY3QgYSBsaW5rIHNlbGVjdGVkIGluIHRoZQ0K Pj4gaGVhZC1lbmQgYXJlYQ0KPj4NCj4+IGV4YW1wbGU6IGxpbmsgMSBpcyBzZWxlY3RlZCBpbiBh cmVhIDEgKGhlYWQtZW5kKSB3aXRoIHNybGcgMSwgbGluayAyIGlzDQo+PiBzZWxlY3RlZCBpbiBp biBhcmVhIDIgd2l0aCBzcmxnIDIsIGFuZCBsaW5rIDMgaW4gYXJlYSAzICh0YWlsLWVuZCkgd2l0 aA0KPj4gc3JsZyAzIGFuZCAxIChzaW5jZSB0aGUgdGFpbCBlbmQgZG9lc24ndCBrbm93IHRoYXQg c3JsZyAxIGlzIGFzc29jaWF0ZWQNCj4+IHRvIGxpbmsgMSBpbiBhZGRpdGlvbiB0byBpdHMgYXNz b2NpYXRpb24gdG8gbGluayAzIGV2ZW4gaWYgaXQga25vd3MgdGhhdA0KPj4gdGhlIGxpbmsgMSBo YXMgYmVlbiBzZWxlY3RlZCBmb3IgdGhlIEFSTykgdGhlIHByb2JsZW0gaXMgdGhhdCB5b3UgY2Fu DQo+PiBub3QgcmV0cmlldmUgc3VjaCBraW5kIG9mIGVycm9yIChleGNlcHQgYnV0IGhvdyBwcmFj dGljYWwgaXMgaXQgaWYgb25lDQo+PiBzdGFydCBjdW11bGF0aW5nIGFsbCB0aGlzIGluZm9ybWF0 aW9uIGJldHdlZW4gY29tcHV0YXRpb24gcG9pbnRzKQ0KPiANCj4gWW91tHJlIHJpc2luZyB0aGlz IHByb2JsZW0gd2l0aCBTUkxHcyBzcGFubmluZyBub24tYWRqYWNlbnQgYXJlYXMuDQoNCnllcywg YmVjYXVzZSBpdCdzIGFub3RoZXIgZmxhdm91ciBvZiB0aGUgdHJhcCBwcm9ibGVtICh0aGUgcHJv cG9zYWwgDQpzb2x2ZXMgdGhlIHNpbmdsZSBhcmVhIHRyYXAgaXNzdWUgYW5kIG5vdCB0aGUgbXVs dGktYXJlYSBvbmUgYW5kIGl0IGlzIA0Kbm90IGEgY3JpdGljaXNtIGJ1dCBhIHdheSB0byBkZXRl cm1pbmUgdGhlIGV4YWN0IGNvdmVyYWdlIG9mIHRoZSBtZXRob2QpDQoNCj4gRmlyc3QsIEkgZG8g bm90IGtub3cgaWYgdGhpcyBpcyBhIGNvbW1vbiBjYXNlIGluIHByYWN0aWNhbCBzY2VuYXJpb3Mu IA0KPiBDYW4gb3RoZXIgY2NhbXBlcnMgY29tbWVudCBvbiB0aGF0ID8NCj4gDQo+IFNlY29uZCwg SU1ITyB0aGlzIGNhc2UgaXMgaGFyZCB0byBoYW5kbGUgZm9yIF9hbnlfIGRpc3RyaWJ1dGVkIHNj aGVtZSwgDQo+IGluIGxhY2sgb2YgYW55IGV4Y2hhbmdlIG9mIGluZm8gYmV0d2VlbiBjb21wdXRh dGlvbiBwb2ludHMgYWJvdXQgc3JsZyANCj4gc3Bhbm5pbmcgbXVsdGlwbGUgYXJlYS4NCg0KYW55 IHNpZ25hbGluZyB0aGF0IGNhcnJpZXMgc3JsZyBleHBsaWNpdCBpbmZvcm1hdGlvbiBpcyByYXRo ZXIgDQppbXByYWN0aWNhbCBhbmQgaSBkb24ndCB0aGluayB0aGVyZSBpcyBjdXJyZW50bHkgYW5v dGhlciB3YXkgdG8gc29sdmUgDQp0aGlzIGlzc3VlIChpbiBhIGRpc3RyaWJ1dGVkIHdheSkgb3Ro ZXIgdGhhbiBwZXJmb3JtaW5nIGxvb2t1cHMgZnJvbSB0aGUgDQpsaW5rX2lkJ3Mgb24gbG9jYWxs eSBhdmFpbGFibGUgaW5mb3JtYXRpb24gYmFzZXMNCg0KPiBGb3IgaW5zdGFuY2UsIEm0bSB3b25k ZXJpbmcgaWYgdGhlIHNlcXVlbnRpYWwgY29tcHV0YXRpb24gd2l0aCBSUk8rWFJPIA0KPiAoYXMg YWx0ZXJuYXR2ZSB0byBwYXJhbGxlbCBjb21wdXRhdGlvbiB3aXRoIEFSTykgY2FuIGhhbmRsZSB0 aGlzIA0KPiBzY2VuYXJpbywgb3Igbm90Lg0KPiBDb3VsZCB5b3UgY29tbWVudCBvbiB0aGF0ID8N Cg0Kc2VlIGFib3ZlIC0gaW4gYnJpZWYgaXMgdG8ga25vdyB3aGF0IHRoZSBwcm9wb3NhbCBjYW4g Y292ZXIgYW5kIGRvZXMgbm90IA0KY292ZXIgYW5kIGluIHRoZSBsYXR0ZXIgY2FzZSB3aGV0aGVy IGl0IGlzIGNhcGFibGUgdG8gZGV0ZWN0IGl0DQoNCj4+IDIpIHJlc291cmNlIGNvbnRlbnRpb24s IHRoZSBzZWNvbmRhcnkgcGF0aCBtYXkgbmV2ZXIgYmUgZXN0YWJsaXNoZWQNCj4+IHNpbmNlIHRo ZSBjb21wdXRhdGlvbiBwb2ludCBhcyAqbm8qIGNhcGFiaWxpdHkgdG8gbWFrZSBhbnkgcmVzZXJ2 YXRpb24NCj4+IG9uIGl0IChleGNlcHQgZnJvbSB0aGUgZmlyc3Qgc2VnbWVudCkgc2luY2UgYnkg ZGVmaW5pdGlvbiAiZGlzam9pbnQiIC0NCj4+IGl0IHNpbXBseSBiZWNvbWVzIGEga2luZCBvZiAi YmVzdCBlZmZvcnQiIHNlY29uZGFyeSBwYXRoIChpbiB0aGUgc2Vuc2UNCj4+IHVzZSBpdCBpZiBu byBvdGhlciByZXNlcnZhdGlvbiBhcmUgbWFraW5nIHVzZSBvZiB0aGVzZSBsaW5rcykNCj4gDQo+ IEluIHRoZSBwYXJhbGxlbCBhcHByb2FjaCB3aXRoIEFSTywgZHVyaW5nIHRoZSBmaXJzdCBwaGFz ZSB0aGUgcHJpbWFyeSANCj4gTFNQIGlzIGVzdGFibGlzZWhlZCAoaW5jbHVkaW5nIGJ3IHJlc2Vy dmF0aW9uKSwgd2hpbGUgZm9yIHRoZSAgc2Vjb25kYXJ5IA0KPiBvbmx5IHRoZSBwYXRoIGlzIGNv bXB1dGVkLg0KPiBUaGlzIGNvbXB1dGF0aW9uIGlzIGJhc2Ugb24gdGhlIHRvcG9sb2d5IC8gbG9h ZCBpbmZvcm1hdGlvbiBhdmFpbGFibGUgYXQgDQo+IHRoZSBjb21wdXRhdGlvbiBwb2ludCwgc28g dGhhdCBsaW5rIHdpdGhvdXQgZW5vdWdoIGJ3IGFyZSBwaW5uZWQgb3V0IGFuZCANCj4gY2FuIG5v dCBiZSBpbmNsdWRlZCBpbiB0aGUgcHJpbWFyeSBub3IgdGhlIHNlY29uZGFyeSBMU1AuDQo+IElu IGEgc3VjY2Vzc2l2ZSBwaGFzZSwgIHRoZSBzZWNvbmRhcnkgTFNQIGlzIHJlc2VydmVkIGFsb25n IHRoZSANCj4gc2Vjb25kYXJ5IHBhdGguDQoNCnllcywgaXQgaXMgYSBwYXJhbGxlbCBtdWx0aS1o b3AgY29tcHV0YXRpb24gd2l0aCBhIHNlcXVlbnRpYWwgc2lnbmFsaW5nIA0KKGkgZG9uJ3QgaGF2 ZSBhbnkgZG91YnQgYWJvdXQgdGhpcykNCg0KPiBXaGF0IGNhbiBoYXBwZW4gaXMgYSByYWNlIGNv bmRpdGlvbiwgd2hlcmUgdGhlIGJ3IGFsb25nIHRoZSBzZWNvbmRhcnkgaXMgDQo+IGF2YWlsYWJs ZSBkdXJpbmcgdGhlIDFzdCBwaGFzZSwgYnV0IG5vdCBkdXJpbmcgdGhlIDJuZCBwaGFzZSwgc2lu Y2Ugc29tZSANCj4gb3RoZXIgcmVzZXJ2YXRpb24gb2NjdXJyZWQgIGluIGJldHdlZW4gdGhlIHR3 byBhbG9uZyBzb21lIHNlY29uZGFyeSBsaW5rLg0KPiBJZiB0aGlzIG9jY3VyciwgdGhlIHNlY29u ZGFyeSBwYXRoIGNhbiBub3QgYmUgZXN0YWJsaXNoZWQsIGFuZCBtYXliZSBhbGwgDQo+IHRoZSBz aWduYWxpbmcgcHJvY2VkdXJlIGhhcyB0byBiZSByZXBlYXRlZCwgZm9yIHByaW1hcnkgZm9yIHNl Y29uZGFyeS4gDQo+IChidHcsIGxldCBtZSBleHBhbmQgaW4gYSBzZXBhcmF0ZSBtYWlsIHRoZSBk aXNjdXNzaW9uIGFib3V0IHRoZSBjYXNlIG9mIA0KPiB1bnN1Y2Nlc2Z1bCBjb21wdXRhdGlvbiwg d2hpY2ggd2FzIGFsc28gcmFpc2VkIGJ5IG90aGVycyApDQoNCm9rIC0NCg0KPiBGaXJzdCwgSSBy ZW1hcmsgdGhhdCB0aGlzIHRpbWUgd2luZG93IGluIHdoaWNoIHRoZSByYWNlIGNhbiBvY2N1cnIg aXMgDQo+IHJlYWxseSBzaG9ydCwgaW4gdGhlIG9yZGVyIG9mIG9uZSBQQVRIL1JFU1Ygcm91bmQg dHJpcCB0aW1lLCBhbmQgc2luY2UgDQo+IGhvcGVmdWxseSB5b3W0cmUgbm90IGdvaW5nIHRvIG9w ZXJhdGUgeW91ciBuZXR3b3JrIGF0IGl0tHMgY2FwYWNpdHkgDQo+IGxpbWl0LCB0aGUgcHJvYmFi aWxpdHkgb2YgZmFpbGluZyBzaWduYWxpbmcgZHVlIHRvIGEgcmFjZSBzaG91bGQgYmUgDQo+IHJl YWxseSBzbWFsbC4NCg0KYXQgbGVhc3QgdGhpcyByYWlzZXMgdGhlIGlzc3VlIG9mIGFwcGxpY2Fi aWxpdHkgKHRoaXMgd2lsbCBiZSBncmVhdGx5IA0KZGVwZW5kaW5nIG9uIHRoZSBhcnJpdmFsIHRp bWUsIHRoZSBhbW91bnQgb2YgdW5yZXNlcnZlZCBiYW5kd2lkdGggYW5kIA0KdGhlIChkaXZlcnNl KSBjb25uZWN0aXZpdHkgZGVncmVlIG9mIGVhY2ggYWJyKQ0KDQo+IFNlY29uZCwgSSB0aGluayB0 aGF0IHJhY2VzIGFyZSBhIHdlbGwta25vd24gIHByb2JsZW0gY29tbW9uIHRvICAgX2FsbF8gIA0K PiBkaXN0cmlidXRlZCBjb21wdXRhdGlvbi9yZXNlcnZhdGlvbiBzY2hlbWVzLCBpLmUuIG5vdCBz cGVjaWZpYyB0byANCj4gcGFyYWxsZWwgY29tcHV0YXRpb24gd2l0aCBBUk8NCj4gKGluY2lkZW50 YWxseSwgSSBub3RlIHRoYXQgUlNWUCBpdHNlbGYgaXMgcHJvbmUgdG8gcmFjZSBzaW5jZSB0aGUg cGF0aCANCj4gY29tcHV0YXRpb24gb2NjdXJzcyBpbiB0aGUgZG93bnN0cmVhbSBQQVRIIG1lc3Nh Z2VzLCB3aGlsZSB0aGUgYncgDQo+IHJlc2VydmF0aW9uIGlzIGFwcGxpZWQgZHVyaW5nIHRoZSB1 cHN0cmVhbSBSRVNWIG1lc3NhZ2VzKS4NCg0KYnV0IGl0IGJlY29tZXMgbW9yZSBwcm9ibGVtYXRp YyBzaW5jZSB0aGUgY29tcHV0YXRpb24gaGFzIG5vIGNvbnRyb2wgYXQNCmFsbCBvdmVyIHRoZSAi ZGl2ZXJzZSBzZWdtZW50IiBpdCBoYXMgY29tcHV0ZWQgKGF0IHRoZSBlbmQgdGhlIGlzc3VlIGlz DQp0byBtYWtlIHRoZSBzY2hlbWUgd29ya2luZyBpdCBpbXBvc2VzIG9wZXJhdGlvbmFsIHByb2Nl ZHVyZXMpIHRoaXMgZG9lcyANCm5vdCBtZWFuIHRoYXQgb3RoZXIgbWVjaGFuaXNtcyAoZXhpc3Rp bmcgYW5kIHRvIGNvbWUgaGF2ZSBmdWxsIGNvbnRyb2wpDQoNCj4+IDMpIHRoZSBtZXRob2Qgc2Vl bXMgdG8gcmFpc2UgYWRkaXRpb25hbCBpc3N1ZXMgd2hlbiB0aGUgbnVtYmVyIG9mIA0KPj4gcG90 ZW50aWFsIGVudHJ5IHBvaW50IGZvciB0aGUgc2Vjb25kYXJ5IGRpc2pvaW50IHBhdGggaW5jcmVh c2VzLCBhdCANCj4+IGVhY2ggc3RlcCBvZiB0aGUgY29tcHV0YXRpb24gKG90aGVyd2lzZSB0aGUg bWV0aG9kIHdvdWxkbid0IHByb3ZpZGUgDQo+PiB3aGF0IGl0IGludGVuZHMgdG8gZGVsaXZlcikN Cj4gIA0KPiBJdCBpcyBub3QgY2xlYXIgdG8gbWUgd2hhdCBhcmUgZXhhY3RseSB0aGVzZSBhZGRp dGlvbmFsIGlzc3VlcywgbWF5YmUgDQo+IHlvdbRkIGxpa2UgdG8gcHJvdmlkZSBzb21lIG1vcmUg Y29uY3JldGUgZXhhbXBsZS4NCg0KaWYgYXQgZWFjaCBjb21wdXRhdGlvbiBwb2ludCB0aGUgbnVt YmVyIG9mIGFsdGVybmF0aXZlcyBpbmNyZWFzZXMsIGkNCmhhdmUgc29tZSBkaWZmaWN1bHRpZXMg dG8gdW5kZXJzdGFuZCBob3cgdGhpcyBtZWNoYW5pc20gd29ya3MsIGVpdGhlcg0KcHJ1bmluZyBv ZiB0aGVzZSBhbHRlcm5hdGl2ZXMgaXMgcGVyZm9ybWVkIChzbyBnbG9iYWwgb3B0aW1hbGl0eSBj YW4NCm5ldmVyIGJlIGFjaGlldmVkKSBvciB5b3UncmUgZ29pbmcgdG8gbWFpbnRhaW4gYW5kIGV4 dGVuZCB0aGVtIHVudGlsDQpyZWFjaGluZyB0aGUgZW5kLXBvaW50IChpcyB0aGF0IHJlYWxseSBm ZWFzaWJsZSA/KQ0KDQo+IEluIGdlbmVyYWwsICBteSBmZWVsaW5nIGlzLCBhZ2FpbiwgdGhhdCBz dWNoIGlzc3VlIG1pZ2h0IGJlIG5vbi1zcGVjaWZpYyANCj4gdG8gdGhlIHBhcmFsbGVsIGNvbXB1 dGF0aW9uIHNjaGVtZSwgYnV0IHJhdGhlciBjb21tb24gdG8gYW55IGRzdHJpYnV0ZWQgDQo+IHNj aGVtZS4NCg0Kd291bGQgaXQgYmUgcG9zc2libGUgdG8gdGVsbCB1cyBpbnN0ZWFkIHdoaWNoIGFy ZSB0aGUgY29uZGl0aW9ucyBpbg0Kd2hpY2ggdGhlIHNjaGVtZSB3b3JrcyByYXRoZXIgdGhhbiBy YWlzaW5nIHRoZSBmbGFnIG9mICJub24tc3BlY2lmaWMgdG8NCnRoZSBwYXJhbGxlbCBjb21wdXRh dGlvbiBzY2hlbWUgYnV0IGNvbW1vbiB0byBhbnkgZGlzdHJpYnV0ZWQgc2NoZW1lIg0Kc2luY2Ug YWZhaWsgdGhpcyBzY2hlbWUgaXMgYWxzbyBkaXN0cmlidXRlZA0KDQo+IEhvd2V2ZXIsIHRoZXJl IHdhcyBhIHBvaW50IHJhaXNlZCBieSBBZHJpYW4gdGhhdCBtaWdodCBoYXZlIHNvbWUgDQo+IHJl bGF0aW9uc2hpcCB0byB0aGUgY2hvaWNlIG9mIHRoZSBlbnRyeS1wb2ludCBmb3IgdGhlIHNlY29u ZGFyeSBwYXRoLg0KPiBJZiB0aGlzIGlzIHRoZSBjYXNlLCB5b3UgbWlnaHQgZmluZCBzb21lICBp bnRlcmVzdGluZyBoaW50cyBpbiBteSANCj4gcHJldmlvdXMgbWFpbCAocG9zdGVkIE1vbiwgMTkg QXByIDIwMDQsIA0KPiBodHRwOi8vb3BzLmlldGYub3JnL2xpc3RzL2NjYW1wL2NjYW1wLjIwMDQv bXNnMDA0NzQuaHRtbCAuLi4gc29ycnkgaXS0cyANCj4gc28gbG9uZyA6LSkNCj4gQXMgYSBsYXN0 IGJ1dCBpbXBvcnRhbnQgcmVtYXJrLCBsZXQgbWUgc3VnZ2VzdCB0byBkaXN0bmd1aXNoIHRoZSAN Cj4gcHJvYmxlbXMgdGhhdCBhcmUgaW50cmluc2ljIHRvIF9hbGxfIGRpc3RyaWJ1dGVkIGRpdmVy c2UgcGF0aCANCj4gY29tcHV0YXRpb24gc2NoZW1lcywgZnJvbSB0aG9zZSB0aGF0IGFyZSBzcGVj aWZpYyB0byBvbmUgc2NoZW1lIChlLmcuIA0KPiBwYXJhbGxlbCBjb21wLiB3aXRoIEFSTykuICBC b3RoIGFyZSBpbXBvcnRhbnQgb2YgY291cnNlLCBidXQgaXQgd291bGQgYmUgDQo+IGJlbmVmaWNp YWwgdG8gdGhlIGRpc2N1c3Npb24gdG8gY2xlYXJseSBzZXBhcmF0ZSB0aGVtIGluIGRpZmZlcmVu dCANCj4gdHJhY2tzIGluIHRoZSBtbC4NCg0KdGhlcmUgYXJlIGlzc3VlcyBpbnRyaXNpYyB0byB0 aGUgbWV0aG9kIGFuZCBpc3N1ZXMgdGhhdCBhcHBsaWVzIHRvIA0KZGlzdHJpYnV0ZWQgbWV0aG9k IHRoYXQgYXBwbGllcyBhbHNvIHRvIHRoaXMgbWV0aG9kIGFuZCBpIGFncmVlIHRoYXQgDQp0aGUg cHJvcG9zZWQgbWV0aG9kIHdvbid0IHNvbHZlIHRoZW0gYWxsIC0gYnV0IGl0IGlzIGltaG8gcGFy dCBvZiB0aGUgDQpkaXNjdXNzaW9uIHRvIGV4YWN0bHkga25vdyB3aGF0IHRoZSBtZXRob2QgY292 ZXJzLCBjYW4gcG90ZW50aWFsbHkgY292ZXIgDQphbmQgbm90IGNvdmVyIChhcHBsaWNhYmlsaXR5 KSBpLmUuIHRoZSB3b3JzdCBzaXR1YXRpb24gaXMgd2hlbiB5b3UncmUgDQpub3QgZGV0ZWN0aW5n IGZhbHNlIGV2ZW50IC0NCg0KdGhhbmtzLA0KLSBkaW1pdHJpLg0KDQo+IEm0ZCBzb2xpY2l0IG90 aGVyIGNjYW1wLWVycyBhbHNvIHRvIGNvbW1lbnQgb24gdGhhdC4NCj4gDQo+IA0KDQotLSANClBh cGFkaW1pdHJpb3UgRGltaXRyaQ0KRS1tYWlsIDogZGltaXRyaS5wYXBhZGltaXRyaW91QGFsY2F0 ZWwuYmUNCkUtbWFpbCA6IGRwYXBhZGltaXRyaW91QHBzZy5jb20NCldlYnBhZ2U6IGh0dHA6Ly9w c2cuY29tL35kcGFwYWRpbWl0cmlvdS8NCkFkZHJlc3M6IEZyLiBXZWxsZXNwbGVpbiAxLCBCLTIw MTggQW50d2VycGVuLCBCZWxnaXVtDQpQaG9uZSAgOiArMzIgMyAyNDAtODQ5MQ0KDQoNCg== From owner-ccamp@ops.ietf.org Thu Apr 29 14:56:27 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19551 for ; Thu, 29 Apr 2004 14:56:27 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJGhs-0002Me-Oe for ccamp-archive@ietf.org; Thu, 29 Apr 2004 14:56:24 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJGgx-00025s-00 for ccamp-archive@ietf.org; Thu, 29 Apr 2004 14:55:28 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BJGg8-0001pW-00 for ccamp-archive@ietf.org; Thu, 29 Apr 2004 14:54:36 -0400 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BJGPc-000J7l-75 for ccamp-data@psg.com; Thu, 29 Apr 2004 18:37:32 +0000 Received: from [62.23.212.165] (helo=smail.alcatel.fr) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BJGPY-000J7A-AH for ccamp@ops.ietf.org; Thu, 29 Apr 2004 18:37:28 +0000 Received: from bemail05.netfr.alcatel.fr (bemail05.netfr.alcatel.fr [155.132.251.11]) by smail.alcatel.fr (ALCANET/NETFR) with ESMTP id i3TIZ30O027549; Thu, 29 Apr 2004 20:35:03 +0200 Received: from alcatel.be ([138.203.64.239]) by bemail05.netfr.alcatel.fr (Lotus Domino Release 5.0.11) with ESMTP id 2004042920350120:5197 ; Thu, 29 Apr 2004 20:35:01 +0200 Message-ID: <40914B69.2090506@alcatel.be> Date: Thu, 29 Apr 2004 20:37:29 +0200 From: Dimitri.Papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.5) Gecko/20030925 X-Accept-Language: en-us, en MIME-Version: 1.0 To: v.sharma@ieee.org Cc: ugo monaco , Fabio Ricciato , ccamp , Zafar Ali Subject: Re: Diverse path failure and optimality in draft-dachille-inter-area-path-protection References: In-Reply-To: X-MIMETrack: Itemize by SMTP Server on BEMAIL05/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 04/29/2004 20:35:01, Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 04/29/2004 20:35:02, Serialize complete at 04/29/2004 20:35:02 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed X-Alcanet-MTA-scanned-and-authorized: yes Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit hi, Vishal Sharma wrote: > Hi Dimitri, > > Thanks for your thoughts. > > However, as Fabio rightly observed, it is very critical that we > distinguish between characteristics that are intrinsic (and common) > to _all_ distributed path computation approaches from those that are > specific to the ARO approach. i don't think i'm saying that the ARO approach should solve all the problems i'm just trying to see the problems that the ARO approach solves and to which extend/conditions > The points you have mentioned below are inherent in _any_ > distributed path computation paradigm (and indeed in any > distributed signaling/resource reservation paradigm), as I explain below, > and are therefore not drawbacks that arise due to particular > mechanisms/methods proposed in the ARO approach. once again, this is not the way these points were raised (they are not saying there are no problems with existing methods) but to which extend the proposed ARO approach enforce them (or avoid them) as last philosophical word i'd like to point the following: it details several principles (but sure we've already cross some of the boundaries this document mentions) that can be useful in re-positioning the whole "optimization" debate thanks, - dimitri. > Comments in-line. > > -Vishal > > >>-----Original Message----- >>From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On >>Behalf Of Dimitri.Papadimitriou@alcatel.be >>Sent: Monday, April 26, 2004 6:47 AM >>To: ugo monaco >>Cc: ccamp; Zafar Ali >>Subject: Re: Diverse path failure and optimality in >>draft-dachille-inter-area-path-protection >> >> >> >>hi, by discussing the proposed method there seems to be three issues >>that make the method questionable in terms of guarantee to deliver what >>it intends to deliver, its usability (the time validity of the path is >>not guaranteed) and its applicability in terms of objective initially >>targeted wrt to the network topology >> >>1) imagine three areas decoupled computation as explained at their >>respective ingress, with ARO method; how the third computation element >>(tail-end) is aware of srlg's that may affect a link selected in the >>head-end area >> >>example: link 1 is selected in area 1 (head-end) with srlg 1, link 2 is >>selected in in area 2 with srlg 2, and link 3 in area 3 (tail-end) with >>srlg 3 and 1 (since the tail end doesn't know that srlg 1 is associated >>to link 1 in addition to its association to link 3 even if it knows that >>the link 1 has been selected for the ARO) the problem is that you can >>not retrieve such kind of error (except but how practical is it if one >>start cumulating all this information between computation points) > > > - First, if we are talking about IGP areas, the problem is a non-issue. > > (They would be under the control > of a single provider, and the provider can reasonably be expected to > assign distinct, globally unique SRLGs to the links in different areas.) > > - If we are talking about AS's, the problem is _universal_, and all > schemes related to restoration have to deal with it. In particular, > _any_ scheme that does distributed path computation has to deal with it. > > So the question is unrelated to the ARO scheme, but a broader one > about how different providers assign SRLG's to resources. > > This is actually a very important issue, but outside the scope of the > ARO document, and not one that I have seen any comprehensive approach to, > yet. > > Perhaps others on the list (carriers?) can comment on it. > > >>2) resource contention, the secondary path may never be established >>since the computation point as *no* capability to make any reservation >>on it (except from the first segment) since by definition "disjoint" - >>it simply becomes a kind of "best effort" secondary path (in the sense >>use it if no other reservation are making use of these links) > > > As Fabio has very nicely explained in > his email, > http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00553.html > > resource contention is a fact of life (read unavoidable) in any distributed > scheme (unless you assume _instantaneous communication_ between the > distributed entities), and is prevalent in every distributed > protocol/mechanism from RSVP-TE to mechanisms for diverse path > computation and setup, such as PCE-based, XRO-based, and, of course, > ARO-based > schemes. > > Not sure why you thought this is specific to the ARO proposal. > > >>3) the method seems to raise additional issues when the number of >>potential entry point for the secondary disjoint path increases, at each >>step of the computation (otherwise the method wouldn't provide what it >>intends to deliver) > > > First, not sure what "additional issues" you are referring to. Can you > provide specifics? > > In any case, every path computation scheme (distributed or otherwise) has to > handle > the case where there are multiple entry points for the secondary (and > primary) paths at a given area/AS. Again, nothing surprising here or > specific > to the ARO scheme in particular. > > When there are many entry points, any scheme has to have a way to select > only one (or some number of them), and any one of several criteria may be > used to make that selection. > > Of course, one can consider then the relative merits of the different > ways of making that selection. > > >> >>ugo monaco wrote: >> >> >>>Dear ccamper, Zafar, Dimitri, >>> >>>as anticipated in the recent email by Vishal we are addressing several >>>important comments collected at Seoul regarding the joint-selection of >>>diverse paths with ARO, i.e. the approach proposed in >>> >> >>>h-protection-00.txt>. >> >>> >>>As Vishal did I summarized your comments to ensure that we rightly >>>understood inputs, and to help people on the ML follow >>>and contribute to the discussion. >>>Comments from others who have feedback are welcome, and >>>much appreciated. >>> >>>Please let me know if you had any additional comments >>>as well. We will take these into account in providing our >>>responses, and, later, in updating the document. >>> >>> >>> >>>Thanks again for your feedback on our draft during the Seoul meeting. >>>Best Regards. >>> >>>Ugo Monaco >>> >>> >>> >> >>++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >>+++++++++++++++++++++++++ >> >>> >>> >>>Zafar's questions: >>> >>>i) What happens when the setup of the diverse path fails, or there is a >>>failure on it after it has been set up? >>> >>>ii) Relationship of this scheme to PCS/PCE approach of JP? >>> >>> >>>Dimitri Papadimitriou >>> >>>i) Your question was about why we are trying for optimality >> >>with a joint >> >>>path selection scheme, when it is not possible, especially as >> >>the number >> >>>of AS's or areas along a path increase, to achieve the *global* optimum. >>>Your other comment was that we should mention this somewhere in the >>>document. >>> >>>Please note that in response to this last question Fabio >> >>Ricciato listed >> >>>many >>>advantages of a joint computation (with ARO) of inter-area/AS >> >>paths in a >> >>>prevoius email posted on the ML "About optimality of inter-AS parallel >>>computation in draft-dachille-inter-area-path-protection". >>>We hope that Fabio rightly addressed your input and we will appreciate >>>further comments and notes. >>> >>> >>> >>> >> >>-- >>Papadimitriou Dimitri >>E-mail : dimitri.papadimitriou@alcatel.be >>E-mail : dpapadimitriou@psg.com >>Webpage: http://psg.com/~dpapadimitriou/ >>Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium >>Phone : +32 3 240-8491 >> >> >> > > > -- Papadimitriou Dimitri E-mail : dimitri.papadimitriou@alcatel.be E-mail : dpapadimitriou@psg.com Webpage: http://psg.com/~dpapadimitriou/ Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium Phone : +32 3 240-8491 From owner-ccamp@ops.ietf.org Thu Apr 29 16:04:20 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24975 for ; Thu, 29 Apr 2004 16:04:20 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJHlZ-0006gV-P6 for ccamp-archive@ietf.org; Thu, 29 Apr 2004 16:04:17 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJHkb-0006fI-00 for ccamp-archive@ietf.org; Thu, 29 Apr 2004 16:03:18 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BJHk8-0006em-00 for ccamp-archive@ietf.org; Thu, 29 Apr 2004 16:02:48 -0400 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BJHY8-0008EW-7F for ccamp-data@psg.com; Thu, 29 Apr 2004 19:50:24 +0000 Received: from [66.163.168.179] (helo=smtp800.mail.sc5.yahoo.com) by psg.com with smtp (Exim 4.30; FreeBSD) id 1BJHY7-0008E1-B6 for ccamp@ops.ietf.org; Thu, 29 Apr 2004 19:50:23 +0000 Received: from unknown (HELO RAKHILAPTOP) (vishal.sharma@sbcglobal.net@63.206.92.206 with login) by smtp800.mail.sc5.yahoo.com with SMTP; 29 Apr 2004 19:49:11 -0000 Reply-To: From: "Vishal Sharma" To: "CCAMP" Cc: "Arthi Ayyangar" , "Jean-Philippe Vasseur" Subject: Sec. 3, item 3 fig. in draft-vassuer-ccamp-inter-area-as Date: Thu, 29 Apr 2004 12:48:43 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) x-mimeole: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit JP, Arthi, Can you please post a clean figure for this item to the list. As it is, the figure is really difficult to understand. Thanks, -Vishal From owner-ccamp@ops.ietf.org Thu Apr 29 16:22:40 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25922 for ; Thu, 29 Apr 2004 16:22:40 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJI3K-0000Ab-8P for ccamp-archive@ietf.org; Thu, 29 Apr 2004 16:22:38 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJI0C-0007PG-00 for ccamp-archive@ietf.org; Thu, 29 Apr 2004 16:19:26 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BJHyv-0007Ei-00 for ccamp-archive@ietf.org; Thu, 29 Apr 2004 16:18:05 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by mx2.foretec.com with esmtp (Exim 4.24) id 1BJHsi-0007sm-6a for ccamp-archive@ietf.org; Thu, 29 Apr 2004 16:11:40 -0400 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BJHk6-000BL5-Rj for ccamp-data@psg.com; Thu, 29 Apr 2004 20:02:46 +0000 Received: from [66.163.168.186] (helo=smtp807.mail.sc5.yahoo.com) by psg.com with smtp (Exim 4.30; FreeBSD) id 1BJHk5-000BIV-Q0 for ccamp@ops.ietf.org; Thu, 29 Apr 2004 20:02:45 +0000 Received: from unknown (HELO RAKHILAPTOP) (vishal.sharma@sbcglobal.net@63.206.92.206 with login) by smtp807.mail.sc5.yahoo.com with SMTP; 29 Apr 2004 19:54:06 -0000 Reply-To: From: "Vishal Sharma" To: "CCAMP" Cc: "Arthi Ayyangar" , "Jean-Philippe Vasseur" Subject: Sec. 3, item 3 fig. in draft-vassuer-ccamp-inter-area-as Date: Thu, 29 Apr 2004 12:53:38 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) x-mimeole: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit JP, Arthi, Can you please post a clean figure for this item to the list. (Sorry, should have attached the fig. I was referring to.) As it is, the figure is really difficult to understand (or at least I couldn't follow it all). Thanks, -Vishal **************************************************************************** 3) Example of topology for the inter-AS TE case: We will consider the following general case, built on a superset of the various scenarios defined in [INTER-AS-TE-REQS]: <-- AS 1 ---> <------- AS 2 -----><--- AS 3 ----> <---BGP---> <---BGP--> CE1---R0---X1-ASBR1-----ASBR4-- - - -R3---ASBR7--- - - --ASBR9----R6 |\ \ | / | / | / | | | | \ ASBR2---/ ASBR5 | -- | | | | \ | | |/ | | | R1-R2-- - - --ASBR3-- - - ----ASBR6-- - - -R4---ASBR8-- - - ---ASBR10-- - - --R7---CE2 <======= Inter-AS TE LSP(LSR to LSR)===========> or <======== Inter-AS TE LSP (CE to ASBR => or <================= Inter-AS TE LSP (CE to CE)===============> The diagram above covers all the inter-AS TE deployment cases described in [INTER-AS-TE-REQS]. Vasseur and Ayyangar 8 **************************************************************** Vishal Sharma, Ph.D. Metanoia, Inc. (Critical Systems Thinking) 888 Villa Street, Suite 200B Mountain View, CA 94041-1261 Phone: +1 408-530-8313. Voice: +1 408-394-6321 Email: v.sharma@ieee.org. http://www.metanoia-inc.com **************************************************************** From owner-ccamp@ops.ietf.org Thu Apr 29 17:21:12 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02816 for ; Thu, 29 Apr 2004 17:21:12 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJIxy-0007OS-9b for ccamp-archive@ietf.org; Thu, 29 Apr 2004 17:21:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJIuY-0006to-00 for ccamp-archive@ietf.org; Thu, 29 Apr 2004 17:17:39 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BJIru-0006Ww-00 for ccamp-archive@ietf.org; Thu, 29 Apr 2004 17:14:54 -0400 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BJIdZ-000NYa-1p for ccamp-data@psg.com; Thu, 29 Apr 2004 21:00:05 +0000 Received: from [207.17.137.64] (helo=colo-dns-ext2.juniper.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BJIdQ-000NWE-5b for ccamp@ops.ietf.org; Thu, 29 Apr 2004 20:59:56 +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 i3TKwkBm030299; Thu, 29 Apr 2004 13:58:46 -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 i3TKwkJ01172; Thu, 29 Apr 2004 13:58:46 -0700 (PDT) (envelope-from arthi@juniper.net) Date: Thu, 29 Apr 2004 13:58:46 -0700 (PDT) From: Arthi Ayyangar To: Vishal Sharma cc: CCAMP , Jean-Philippe Vasseur Subject: Re: Sec. 3, item 3 fig. in draft-vassuer-ccamp-inter-area-as In-Reply-To: Message-ID: <20040429135256.Y74567@zircon.juniper.net> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,UPPERCASE_25_50 autolearn=no version=2.60 Hi Vishal, Here you go, <-- AS 1 ---> <------- AS 2 -----><--- AS 3 ----> <---BGP---> <---BGP--> CE1---R0---X1-ASBR1-----ASBR4--R3---ASBR7----ASBR9----R6 |\ \ | / | / | / | | | | \ ASBR2---/ ASBR5 | -- | | | | \ | | |/ | | | R1-R2---ASBR3-----ASBR6--R4---ASBR8----ASBR10----R7---CE2 <======= Inter-AS TE LSP(LSR to LSR)===========> or <======== Inter-AS TE LSP (CE to ASBR => or <================= Inter-AS TE LSP (CE to CE)===============> Thanks, -arthi > Can you please post a clean figure for this item to the list. > (Sorry, should have attached the fig. I was referring to.) > > As it is, the figure is really difficult to understand (or at > least I couldn't follow it all). > > Thanks, > -Vishal > > **************************************************************************** > 3) Example of topology for the inter-AS TE case: > > We will consider the following general case, built on a superset of the > various scenarios defined in [INTER-AS-TE-REQS]: > > > <-- AS 1 ---> <------- AS 2 -----><--- AS 3 ----> > > <---BGP---> <---BGP--> > CE1---R0---X1-ASBR1-----ASBR4-- > - > - > -R3---ASBR7--- > - > - > --ASBR9----R6 > |\ \ | / | / | / | | | > | \ ASBR2---/ ASBR5 | -- | | | > | \ | | |/ | | | > R1-R2-- > - > - > --ASBR3-- > - > - > ----ASBR6-- > - > - > -R4---ASBR8-- > - > - > ---ASBR10-- > - > - > --R7---CE2 > > <======= Inter-AS TE LSP(LSR to LSR)===========> > or > > <======== Inter-AS TE LSP (CE to ASBR => > > or > > <================= Inter-AS TE LSP (CE to CE)===============> > > The diagram above covers all the inter-AS TE deployment cases described > in [INTER-AS-TE-REQS]. > > Vasseur and Ayyangar 8 > > > **************************************************************** > Vishal Sharma, Ph.D. > Metanoia, Inc. (Critical Systems Thinking) > 888 Villa Street, Suite 200B > Mountain View, CA 94041-1261 > Phone: +1 408-530-8313. Voice: +1 408-394-6321 > Email: v.sharma@ieee.org. http://www.metanoia-inc.com > **************************************************************** > > From owner-ccamp@ops.ietf.org Thu Apr 29 17:34:23 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04143 for ; Thu, 29 Apr 2004 17:34:23 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJJAj-0000og-Al for ccamp-archive@ietf.org; Thu, 29 Apr 2004 17:34:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJJ9s-0000nE-00 for ccamp-archive@ietf.org; Thu, 29 Apr 2004 17:33:29 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BJJ91-0000lE-00 for ccamp-archive@ietf.org; Thu, 29 Apr 2004 17:32:36 -0400 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BJIzu-0001sk-Ej for ccamp-data@psg.com; Thu, 29 Apr 2004 21:23:10 +0000 Received: from [66.163.170.84] (helo=smtp814.mail.sc5.yahoo.com) by psg.com with smtp (Exim 4.30; FreeBSD) id 1BJIzt-0001sW-IM for ccamp@ops.ietf.org; Thu, 29 Apr 2004 21:23:09 +0000 Received: from unknown (HELO RAKHILAPTOP) (vishal.sharma@sbcglobal.net@63.206.92.37 with login) by smtp814.mail.sc5.yahoo.com with SMTP; 29 Apr 2004 21:06:54 -0000 Reply-To: From: "Vishal Sharma" To: "Arthi Ayyangar" Cc: "CCAMP" , "Jean-Philippe Vasseur" Subject: RE: Sec. 3, item 3 fig. in draft-vassuer-ccamp-inter-area-as Date: Thu, 29 Apr 2004 14:06:26 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <20040429135256.Y74567@zircon.juniper.net> x-mimeole: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Arthi, Thanks! BTW, there are several other figures in the current doc. that seem to have been distorted in the final text version, so you all might want to check those as well in the revision. -Vishal > -----Original Message----- > From: Arthi Ayyangar [mailto:arthi@juniper.net] > Sent: Thursday, April 29, 2004 1:59 PM > To: Vishal Sharma > Cc: CCAMP; Jean-Philippe Vasseur > Subject: Re: Sec. 3, item 3 fig. in draft-vassuer-ccamp-inter-area-as > > > Hi Vishal, > > Here you go, > > > <-- AS 1 ---> <------- AS 2 -----><--- AS 3 ----> > > <---BGP---> <---BGP--> > CE1---R0---X1-ASBR1-----ASBR4--R3---ASBR7----ASBR9----R6 > |\ \ | / | / | / | | | > | \ ASBR2---/ ASBR5 | -- | | | > | \ | | |/ | | | > R1-R2---ASBR3-----ASBR6--R4---ASBR8----ASBR10----R7---CE2 > > <======= Inter-AS TE LSP(LSR to LSR)===========> > or > > <======== Inter-AS TE LSP (CE to ASBR => > > or > > <================= Inter-AS TE LSP (CE to CE)===============> > > > > Thanks, > -arthi > > > Can you please post a clean figure for this item to the list. > > (Sorry, should have attached the fig. I was referring to.) > > > > As it is, the figure is really difficult to understand (or at > > least I couldn't follow it all). > > > > Thanks, > > -Vishal > > > > > ****************************************************************** > ********** > > 3) Example of topology for the inter-AS TE case: > > > > We will consider the following general case, built on a superset of the > > various scenarios defined in [INTER-AS-TE-REQS]: > > > > > > <-- AS 1 ---> <------- AS 2 -----><--- AS 3 ----> > > > > <---BGP---> <---BGP--> > > CE1---R0---X1-ASBR1-----ASBR4-- > > - > > - > > -R3---ASBR7--- > > - > > - > > --ASBR9----R6 > > |\ \ | / | / | / | | | > > | \ ASBR2---/ ASBR5 | -- | | | > > | \ | | |/ | | | > > R1-R2-- > > - > > - > > --ASBR3-- > > - > > - > > ----ASBR6-- > > - > > - > > -R4---ASBR8-- > > - > > - > > ---ASBR10-- > > - > > - > > --R7---CE2 > > > > <======= Inter-AS TE LSP(LSR to LSR)===========> > > or > > > > <======== Inter-AS TE LSP (CE to ASBR => > > > > or > > > > <================= Inter-AS TE LSP (CE to CE)===============> > > > > The diagram above covers all the inter-AS TE deployment cases described > > in [INTER-AS-TE-REQS]. > > > > Vasseur and Ayyangar 8 > > > > > > **************************************************************** > > Vishal Sharma, Ph.D. > > Metanoia, Inc. (Critical Systems Thinking) > > 888 Villa Street, Suite 200B > > Mountain View, CA 94041-1261 > > Phone: +1 408-530-8313. Voice: +1 408-394-6321 > > Email: v.sharma@ieee.org. http://www.metanoia-inc.com > > **************************************************************** > > > > From owner-ccamp@ops.ietf.org Thu Apr 29 17:42:25 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04395 for ; Thu, 29 Apr 2004 17:42:25 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJJIV-00017f-QD for ccamp-archive@ietf.org; Thu, 29 Apr 2004 17:42:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJJHc-00015l-00 for ccamp-archive@ietf.org; Thu, 29 Apr 2004 17:41:28 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BJJHS-00013W-00 for ccamp-archive@ietf.org; Thu, 29 Apr 2004 17:41:18 -0400 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BJJ8o-0003wC-AN for ccamp-data@psg.com; Thu, 29 Apr 2004 21:32:22 +0000 Received: from [207.17.137.57] (helo=colo-dns-ext1.juniper.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BJJ8n-0003vj-BX for ccamp@ops.ietf.org; Thu, 29 Apr 2004 21:32:21 +0000 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id i3TLW2l78855; Thu, 29 Apr 2004 14:32:02 -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 i3TLVsJ05741; Thu, 29 Apr 2004 14:31:57 -0700 (PDT) (envelope-from arthi@juniper.net) Date: Thu, 29 Apr 2004 14:31:54 -0700 (PDT) From: Arthi Ayyangar To: Vishal Sharma cc: CCAMP , Jean-Philippe Vasseur Subject: RE: Sec. 3, item 3 fig. in draft-vassuer-ccamp-inter-area-as In-Reply-To: Message-ID: <20040429143130.J74567@zircon.juniper.net> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Vishal, > BTW, there are several other figures in the current doc. that > seem to have been distorted in the final text version, so you > all might want to check those as well in the revision. --------> Will do. -arthi > > -----Original Message----- > > From: Arthi Ayyangar [mailto:arthi@juniper.net] > > Sent: Thursday, April 29, 2004 1:59 PM > > To: Vishal Sharma > > Cc: CCAMP; Jean-Philippe Vasseur > > Subject: Re: Sec. 3, item 3 fig. in draft-vassuer-ccamp-inter-area-as > > > > > > Hi Vishal, > > > > Here you go, > > > > > > <-- AS 1 ---> <------- AS 2 -----><--- AS 3 ----> > > > > <---BGP---> <---BGP--> > > CE1---R0---X1-ASBR1-----ASBR4--R3---ASBR7----ASBR9----R6 > > |\ \ | / | / | / | | | > > | \ ASBR2---/ ASBR5 | -- | | | > > | \ | | |/ | | | > > R1-R2---ASBR3-----ASBR6--R4---ASBR8----ASBR10----R7---CE2 > > > > <======= Inter-AS TE LSP(LSR to LSR)===========> > > or > > > > <======== Inter-AS TE LSP (CE to ASBR => > > > > or > > > > <================= Inter-AS TE LSP (CE to CE)===============> > > > > > > > > Thanks, > > -arthi > > > > > Can you please post a clean figure for this item to the list. > > > (Sorry, should have attached the fig. I was referring to.) > > > > > > As it is, the figure is really difficult to understand (or at > > > least I couldn't follow it all). > > > > > > Thanks, > > > -Vishal > > > > > > > > ****************************************************************** > > ********** > > > 3) Example of topology for the inter-AS TE case: > > > > > > We will consider the following general case, built on a superset of the > > > various scenarios defined in [INTER-AS-TE-REQS]: > > > > > > > > > <-- AS 1 ---> <------- AS 2 -----><--- AS 3 ----> > > > > > > <---BGP---> <---BGP--> > > > CE1---R0---X1-ASBR1-----ASBR4-- > > > - > > > - > > > -R3---ASBR7--- > > > - > > > - > > > --ASBR9----R6 > > > |\ \ | / | / | / | | | > > > | \ ASBR2---/ ASBR5 | -- | | | > > > | \ | | |/ | | | > > > R1-R2-- > > > - > > > - > > > --ASBR3-- > > > - > > > - > > > ----ASBR6-- > > > - > > > - > > > -R4---ASBR8-- > > > - > > > - > > > ---ASBR10-- > > > - > > > - > > > --R7---CE2 > > > > > > <======= Inter-AS TE LSP(LSR to LSR)===========> > > > or > > > > > > <======== Inter-AS TE LSP (CE to ASBR => > > > > > > or > > > > > > <================= Inter-AS TE LSP (CE to CE)===============> > > > > > > The diagram above covers all the inter-AS TE deployment cases described > > > in [INTER-AS-TE-REQS]. > > > > > > Vasseur and Ayyangar 8 > > > > > > > > > **************************************************************** > > > Vishal Sharma, Ph.D. > > > Metanoia, Inc. (Critical Systems Thinking) > > > 888 Villa Street, Suite 200B > > > Mountain View, CA 94041-1261 > > > Phone: +1 408-530-8313. Voice: +1 408-394-6321 > > > Email: v.sharma@ieee.org. http://www.metanoia-inc.com > > > **************************************************************** > > > > > > > From owner-ccamp@ops.ietf.org Thu Apr 29 19:37:30 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11015 for ; Thu, 29 Apr 2004 19:37:29 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJL5q-0000t2-E1 for ccamp-archive@ietf.org; Thu, 29 Apr 2004 19:37:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJL4x-0000qc-00 for ccamp-archive@ietf.org; Thu, 29 Apr 2004 19:36:33 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BJL4G-0000nq-00 for ccamp-archive@ietf.org; Thu, 29 Apr 2004 19:35:48 -0400 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BJKwN-0002DX-KH for ccamp-data@psg.com; Thu, 29 Apr 2004 23:27:39 +0000 Received: from [66.163.168.184] (helo=smtp805.mail.sc5.yahoo.com) by psg.com with smtp (Exim 4.30; FreeBSD) id 1BJKwM-0002DK-Co for ccamp@ops.ietf.org; Thu, 29 Apr 2004 23:27:38 +0000 Received: from unknown (HELO RAKHILAPTOP) (vishal.sharma@sbcglobal.net@67.117.150.159 with login) by smtp805.mail.sc5.yahoo.com with SMTP; 29 Apr 2004 23:27:21 -0000 Reply-To: From: "Vishal Sharma" To: "Jean Philippe Vasseur" Cc: , , "Fabio Ricciato" , "Ugo Monaco" , "Alessio D'Achille" , "Marco Listanti" Subject: RE: comments on ARO Date: Thu, 29 Apr 2004 16:26:52 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <4.3.2.7.2.20040429130446.020cf0e0@wells.cisco.com> x-mimeole: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit JP, Thanks for the comments. A comment and question in-line. -Vishal > -----Original Message----- > From: Jean Philippe Vasseur [mailto:jvasseur@cisco.com] > Sent: Thursday, April 29, 2004 10:27 AM > To: v.sharma@ieee.org > Cc: stefaan.de_cnodder@alcatel.be; ccamp@ops.ietf.org; Fabio Ricciato; > Ugo Monaco; Alessio D'Achille; Marco Listanti > Subject: RE: comments on ARO > <> > > > > 1) Recording only border nodes: > > > > > > > > Actually, if one only recorded border nodes, then upon signaling > > > > the secondary, the ingress border node for the secondary has no > > > > idea about the intra-area (or intra-AS) path of the primary (in its > > > > own area or AS), and therefore cannot ensure that the primary and > > > > secondary segments are in fact disjoint. > > > > > > > > This was a point I discussed with several other people > > > > (who initially proposed the same thing), including > > > > Arthi and Adrian, but we concluded, for the reason above, > that merely > > > > recording the border nodes does not work for diversity. As a > > > > result, the ARO does, in fact, serve a very useful purpose. > > > > > > > > We can of course think more about what the trade-offs are, and > > > see if there > > > > is some way to retain the main advantage of the proposal (diversity, > > > > joint optimization of both paths) while also recording less > information. > > > > > > > > > > The problem I want to solve here is NOT to reduce the amount of > > > information in the ARO, i.e. my purpose is not to reduce its length. > > > Rather, by only recording the border nodes you give more freedom > > > when signaling the secondary (using the XRO!) meaning that when > > > crankback or re-optimization of the secondary is possible, the > > > primary does not have to be resignaled to get a new ARO. > > > >Sure, I understood that the goal wasn't to reduce the length of > >the ARO per se, but rather the level of detail that would need to > >be recorded in it (regardless of the actual amount of data the ARO > >would carry). > > > >If you recollect the classification of path computation models > >I gave in my email to JP > >http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00467.html > > > >we have under distributed computing: i) a parallel path computation > >model and ii) a sequential one. > >ARO achieves the former, while XRO achieves the latter. > > > >So, if one did not compute and record the path of the secondary > >jointly with the primary (and only recorded the border nodes instead) > >the scheme would reduce to a _sequential path computation_, with its > >attendant drawbacks (sub-optimality, trap topology, etc.). > > > >The beauty of the ARO scheme is that it can compute end-to-end > >diverse paths using a parallel path computation model (albeit distributed > >at each area/AS), with the simplicity of the per-domain approach, and > >without any changes to the signaling protocols. > > Here is one of main concerns that I have about this scheme: by contrast > with a distributed PCE-approach, a severe drawback with such a model lies > in the potential number of retrials (since it has to be combined with > crankback) and consequently the potential set up time. Indeed, > you may have > diverse paths within a domain, and then a set up failure in the next hop > domain requiring to crankback in the previous domain; the number of > potential trials may be really non negligible. > > Moreover, you can still cannot guarantee and an end to end shortest path. We have to think a bit more about the idea of combining ARO with crankback and need to get back after giving it some thought. [Please note that the goal with ARO is not necessarily to guarantee an end-to-end shortest path. Rather, it is to ensure that diverse paths can be efficiently computed, while meeting certain constraints per some metrics (as further explained in Fabio's email http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00562.html and my recent reply to Stefaan http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00561.html)] Reading draft-vasseur-ccamp-inter-area-as, especially Sec. 6.6 I was a bit unclear on how the computation proceeds. (BTW, the draft will read much better if the generic steps are explained first, and then the worked example. As it stands, the two are intermixed, and it becomes much more difficult to understand what the algo. is.) The draft states that "the PCE provides the list of shortest paths (with their corresponding ERO (potentially partial ERO) + Path-cost) from _every_ ASBR to the inter-AS TE LSP destination." Suppose the destination is in ASn. PCEn computes a set of shortest paths from _every_ ASBR in ASn to the destination, and passes them back to PCn-1. What does PCn-1 do? My understanding from the draft is that it computes a set of shortest paths between all ASBRs that connect ASn-1 to ASn-2 and those that connect ASn-1 to ASn, and includes the inter-AS links between ASn-1 and ASn in those shortest path computations. My question is: what does PCn-1 send back to PCn-2? Does it, in turn, send PCn-2 the set of all possible paths traversing ASn-1 and ASn or does it concatenate all paths, choose the shortest one, and send back one (the shortest path traversing ASn-1 and ASn)? If the former, then we have a major scalability issue, as the number of paths passed back to successive PCi's will grow, literally exponentially, from AS to AS. If the latter, the scheme may fail to select the shortest path, as I explain below (which is not unexpected). Take the following fig. from the draft (where I have added a link between ASBR3 and ASBR5): <-- AS 1 ---> <------- AS 2 -----><--- AS 3 ----> <---BGP---> <---BGP--> CE1---R0---X1-ASBR1-----ASBR4--R3---ASBR7----ASBR9----R6 |\ \ | / | / | / | | | | \ ASBR2---/ ASBR5 | -- | | | | \ | /----/ | |/ | | | R1-R2---ASBR3-----ASBR6--R4---ASBR8----ASBR10----R7---CE2 We will use the mechanisms specified in Sec. 6 of draft-vasseur, and assume for this part of the discussion that the objective is to the shortest path between R0 and R7. As before, ASBR1, ASBR4, and ASBR9 are the PCEs for AS's 1, 2, and 3, respectively. The request propagates from R0 to the PCE's, to ASBR1 on to ASBR4 on to ASBR9, as before. 1. ASBR9 computes two paths: ASBR9-R6-R7 Cost = 10, say ASBR10-R7 Cost = 20, say (per some metric) 2. It passes these back to ASBR4, which in turn calculates that the possibilities to traverse AS2 are: ASBR4-R3-ASBR7-ASBR9, Cost = 30 ASBR5-R3-ASBR7-ASBR9, Cost = 40 ASBR6-R4-ASBR8-ASBR10, Cost = 30 (Assume all other permutations have higher cost.) 3. Using the concatenation approach mentioned in the draft, it computes that the shortest paths traversing ASs 2 and 3 is, therefore, ASBR4-R3-ASBR7 -- ASBR9-R6-R7, total cost = 40 4. It passes this back to ASBR1, which in turn calculates that the possibilities to traverse AS1 to reach ASBR4 are: R0-X1-ASBR1-ASBR4, Cost = 50 R0-X1-ASBR2-ASBR4, Cost = 60 (There are other permutations, but assume their cost is higher.) Also, assume that the path from R01 to ASBR5, R0-R2-ASBR3-ASBR5 has cost = 30. 5. Again, using concatenation, ASBR1 calculates that the "shortest path" is R0-X1-ASBR1 -- ASBR4-R3-ASBR7 -- ASBR9-R6-R7, total cost = 90 <---------------> <-------------> <-----> 50 30 10 However, there was a shorter path R0-R2-ASBR3 -- ASBR5-R3-ASBR7 -- ASBR9-R6-R7, total cost = 80 <--------------> <--------------> <-----> 30 40 10 which could not get picked in this case. For this, it would have to be that all possible paths are propagated back to PC1, which then selects the shortest one among them, but this, it seems to me, would be an operational and computational nightmare. From owner-ccamp@ops.ietf.org Fri Apr 30 08:55:02 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28467 for ; Fri, 30 Apr 2004 08:55:02 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJXXl-0002QT-5V for ccamp-archive@ietf.org; Fri, 30 Apr 2004 08:55:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJXWs-0002Cm-00 for ccamp-archive@ietf.org; Fri, 30 Apr 2004 08:54:12 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BJXWZ-00022I-00 for ccamp-archive@ietf.org; Fri, 30 Apr 2004 08:53:51 -0400 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BJXFd-0006ak-TJ for ccamp-data@psg.com; Fri, 30 Apr 2004 12:36:21 +0000 Received: from [171.71.176.71] (helo=sj-iport-2.cisco.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BJXFa-0006a3-KD for ccamp@ops.ietf.org; Fri, 30 Apr 2004 12:36:18 +0000 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 30 Apr 2004 04:48:34 +0000 Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i3UCaEW9005967; Fri, 30 Apr 2004 05:36:14 -0700 (PDT) Received: from jvasseur-w2k01.cisco.com (che-vpn-cluster-2-144.cisco.com [10.86.242.144]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id FAA15294; Fri, 30 Apr 2004 05:36:12 -0700 (PDT) Message-Id: <4.3.2.7.2.20040429232721.0601af50@wells.cisco.com> X-Sender: jvasseur@wells.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 30 Apr 2004 08:36:05 -0400 To: From: Jean Philippe Vasseur Subject: RE: comments on ARO Cc: , , "Fabio Ricciato" , "Ugo Monaco" , "Alessio D'Achille" , "Marco Listanti" In-Reply-To: References: <4.3.2.7.2.20040429130446.020cf0e0@wells.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Hi Vishal, At 04:26 PM 4/29/2004 -0700, Vishal Sharma wrote: >JP, > >Thanks for the comments. > >A comment and question in-line. > >-Vishal > > > -----Original Message----- > > From: Jean Philippe Vasseur [mailto:jvasseur@cisco.com] > > Sent: Thursday, April 29, 2004 10:27 AM > > To: v.sharma@ieee.org > > Cc: stefaan.de_cnodder@alcatel.be; ccamp@ops.ietf.org; Fabio Ricciato; > > Ugo Monaco; Alessio D'Achille; Marco Listanti > > Subject: RE: comments on ARO > > ><> > > > > > > 1) Recording only border nodes: > > > > > > > > > > Actually, if one only recorded border nodes, then upon signaling > > > > > the secondary, the ingress border node for the secondary has no > > > > > idea about the intra-area (or intra-AS) path of the primary (in its > > > > > own area or AS), and therefore cannot ensure that the primary and > > > > > secondary segments are in fact disjoint. > > > > > > > > > > This was a point I discussed with several other people > > > > > (who initially proposed the same thing), including > > > > > Arthi and Adrian, but we concluded, for the reason above, > > that merely > > > > > recording the border nodes does not work for diversity. As a > > > > > result, the ARO does, in fact, serve a very useful purpose. > > > > > > > > > > We can of course think more about what the trade-offs are, and > > > > see if there > > > > > is some way to retain the main advantage of the proposal (diversity, > > > > > joint optimization of both paths) while also recording less > > information. > > > > > > > > > > > > > The problem I want to solve here is NOT to reduce the amount of > > > > information in the ARO, i.e. my purpose is not to reduce its length. > > > > Rather, by only recording the border nodes you give more freedom > > > > when signaling the secondary (using the XRO!) meaning that when > > > > crankback or re-optimization of the secondary is possible, the > > > > primary does not have to be resignaled to get a new ARO. > > > > > >Sure, I understood that the goal wasn't to reduce the length of > > >the ARO per se, but rather the level of detail that would need to > > >be recorded in it (regardless of the actual amount of data the ARO > > >would carry). > > > > > >If you recollect the classification of path computation models > > >I gave in my email to JP > > >http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00467.html > > > > > >we have under distributed computing: i) a parallel path computation > > >model and ii) a sequential one. > > >ARO achieves the former, while XRO achieves the latter. > > > > > >So, if one did not compute and record the path of the secondary > > >jointly with the primary (and only recorded the border nodes instead) > > >the scheme would reduce to a _sequential path computation_, with its > > >attendant drawbacks (sub-optimality, trap topology, etc.). > > > > > >The beauty of the ARO scheme is that it can compute end-to-end > > >diverse paths using a parallel path computation model (albeit distributed > > >at each area/AS), with the simplicity of the per-domain approach, and > > >without any changes to the signaling protocols. > > > > Here is one of main concerns that I have about this scheme: by contrast > > with a distributed PCE-approach, a severe drawback with such a model lies > > in the potential number of retrials (since it has to be combined with > > crankback) and consequently the potential set up time. Indeed, > > you may have > > diverse paths within a domain, and then a set up failure in the next hop > > domain requiring to crankback in the previous domain; the number of > > potential trials may be really non negligible. > > > > Moreover, you can still cannot guarantee and an end to end shortest path. > > > >We have to think a bit more about the idea of combining ARO with >crankback and need to get back after giving it some thought. > >[Please note that the goal with ARO is not necessarily to guarantee >an end-to-end shortest path. Yes I noticed that ;-) hence my comment that it cannot guarantee the shortest path >Rather, it is to ensure that diverse >paths can be efficiently computed, while meeting certain constraints >per some metrics (as further explained in Fabio's email >http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00562.html >and my recent reply to Stefaan >http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00561.html)] But my main concern remains: the number of required crankback required in some cases and the related impact on set up failure. >Reading draft-vasseur-ccamp-inter-area-as, especially Sec. 6.6 >I was a bit unclear on how the computation proceeds. >(BTW, the draft will read much better if the generic steps are >explained first, and then the worked example. As it stands, the >two are intermixed, and it becomes much more difficult to understand >what the algo. is.) > >The draft states that >"the PCE provides the list of shortest paths (with their corresponding >ERO (potentially partial ERO) + Path-cost) from _every_ ASBR to the >inter-AS TE LSP destination." > >Suppose the destination is in ASn. PCEn computes a set of shortest paths >from _every_ ASBR in ASn to the destination, and passes them back to PCn-1. > >What does PCn-1 do? > >My understanding from the draft is that it computes a set of >shortest paths between all ASBRs that >connect ASn-1 to ASn-2 and those that connect ASn-1 to ASn, and >includes the inter-AS links between ASn-1 and ASn in those >shortest path computations. > >My question is: what does PCn-1 send back to PCn-2? > >Does it, in turn, send PCn-2 the set of all possible paths traversing >ASn-1 and ASn or does it concatenate all paths, choose the shortest >one, and send back one (the shortest path traversing ASn-1 and ASn)? > >If the former, then we have a major scalability issue, as the >number of paths passed back to successive PCi's will grow, >literally exponentially, from AS to AS. > >If the latter, the scheme may fail to select the shortest path, >as I explain below (which is not unexpected). > >Take the following fig. from the draft (where I have added a link >between ASBR3 and ASBR5): > > > <-- AS 1 ---> <------- AS 2 -----><--- AS 3 ----> > > <---BGP---> <---BGP--> >CE1---R0---X1-ASBR1-----ASBR4--R3---ASBR7----ASBR9----R6 > |\ \ | / | / | / | | | > | \ ASBR2---/ ASBR5 | -- | | | > | \ | /----/ | |/ | | | > R1-R2---ASBR3-----ASBR6--R4---ASBR8----ASBR10----R7---CE2 > > >We will use the mechanisms specified in Sec. 6 of draft-vasseur, and >assume for this part of the discussion that the objective is to the >shortest path between R0 and R7. > >As before, ASBR1, ASBR4, and ASBR9 are the PCEs for AS's 1, 2, and >3, respectively. > >The request propagates from R0 to the PCE's, to ASBR1 on to ASBR4 on >to ASBR9, as before. > >1. ASBR9 computes two paths: > >ASBR9-R6-R7 Cost = 10, say >ASBR10-R7 Cost = 20, say (per some metric) > >2. It passes these back to ASBR4, which in turn calculates that the >possibilities >to traverse AS2 are: > >ASBR4-R3-ASBR7-ASBR9, Cost = 30 >ASBR5-R3-ASBR7-ASBR9, Cost = 40 >ASBR6-R4-ASBR8-ASBR10, Cost = 30 >(Assume all other permutations have higher cost.) > >3. Using the concatenation approach mentioned in the draft, it computes >that the shortest paths traversing ASs 2 and 3 is, therefore, > >ASBR4-R3-ASBR7 -- ASBR9-R6-R7, total cost = 40 > >4. It passes this back to ASBR1, which in turn calculates that the >possibilities >to traverse AS1 to reach ASBR4 are: > >R0-X1-ASBR1-ASBR4, Cost = 50 >R0-X1-ASBR2-ASBR4, Cost = 60 >(There are other permutations, but assume their cost is higher.) > >Also, assume that the path from R01 to ASBR5, >R0-R2-ASBR3-ASBR5 has cost = 30. > >5. Again, using concatenation, ASBR1 calculates that the "shortest >path" is > >R0-X1-ASBR1 -- ASBR4-R3-ASBR7 -- ASBR9-R6-R7, total cost = 90 ><---------------> <-------------> <-----> > 50 30 10 > >However, there was a shorter path >R0-R2-ASBR3 -- ASBR5-R3-ASBR7 -- ASBR9-R6-R7, total cost = 80 ><--------------> <--------------> <-----> > 30 40 10 > >which could not get picked in this case. > >For this, it would have to be that all possible paths are propagated >back to PC1, which then selects the shortest one among them, but >this, it seems to me, would be an operational and computational nightmare. What you described is not how the algorithm works ... All the shortest paths from the destination to every entry ASBR are computed in a backward and recursive manner (hence you progressively compute the SPT rooted at the LSP destination). Note that there are several variations and optimizations, I just described the general case that applies to the generic case of N ASes. I'll try to clarify in the next revision of the draft. Cheers JP. From owner-ccamp@ops.ietf.org Fri Apr 30 14:30:06 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20673 for ; Fri, 30 Apr 2004 14:30:06 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJcm0-00003J-JP for ccamp-archive@ietf.org; Fri, 30 Apr 2004 14:30:08 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJcl4-0007lF-00 for ccamp-archive@ietf.org; Fri, 30 Apr 2004 14:29:11 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BJck7-0007fP-00 for ccamp-archive@ietf.org; Fri, 30 Apr 2004 14:28:11 -0400 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BJcRo-000BWy-By for ccamp-data@psg.com; Fri, 30 Apr 2004 18:09:16 +0000 Received: from [66.163.168.187] (helo=smtp808.mail.sc5.yahoo.com) by psg.com with smtp (Exim 4.30; FreeBSD) id 1BJcRn-000BWi-Ba for ccamp@ops.ietf.org; Fri, 30 Apr 2004 18:09:15 +0000 Received: from unknown (HELO RAKHILAPTOP) (vishal.sharma@sbcglobal.net@63.206.90.204 with login) by smtp808.mail.sc5.yahoo.com with SMTP; 30 Apr 2004 18:09:14 -0000 Reply-To: From: "Vishal Sharma" To: "Jean Philippe Vasseur" Cc: , , "Fabio Ricciato" , "Ugo Monaco" , "Alessio D'Achille" , "Marco Listanti" Subject: RE: comments on ARO Date: Fri, 30 Apr 2004 11:09:10 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <4.3.2.7.2.20040429232721.0601af50@wells.cisco.com> Importance: Normal Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,HTML_MESSAGE autolearn=no version=2.60 Content-Transfer-Encoding: 7bit JP, Thanks for clarifying. Questions in-line. -Vishal > -----Original Message----- > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On > Behalf Of Jean Philippe Vasseur > Sent: Friday, April 30, 2004 5:36 AM > To: v.sharma@ieee.org > Cc: stefaan.de_cnodder@alcatel.be; ccamp@ops.ietf.org; Fabio Ricciato; > Ugo Monaco; Alessio D'Achille; Marco Listanti > Subject: RE: comments on ARO > > <> > > > > > > Here is one of main concerns that I have about this scheme: > by contrast > > > with a distributed PCE-approach, a severe drawback with such > a model lies > > > in the potential number of retrials (since it has to be combined with > > > crankback) and consequently the potential set up time. Indeed, > > > you may have > > > diverse paths within a domain, and then a set up failure in > the next hop > > > domain requiring to crankback in the previous domain; the number of > > > potential trials may be really non negligible. > > > > > > Moreover, you can still cannot guarantee and an end to end > shortest path. > > > > > > > >We have to think a bit more about the idea of combining ARO with > >crankback and need to get back after giving it some thought. > > > >[Please note that the goal with ARO is not necessarily to guarantee > >an end-to-end shortest path. > > Yes I noticed that ;-) hence my comment that it cannot guarantee the > shortest path > > >Rather, it is to ensure that diverse > >paths can be efficiently computed, while meeting certain constraints > >per some metrics (as further explained in Fabio's email > >http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00562.html > >and my recent reply to Stefaan > >http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00561.html)] > > But my main concern remains: the number of required crankback required in > some cases and the related impact on set up failure. > > >Reading draft-vasseur-ccamp-inter-area-as, especially Sec. 6.6 > >I was a bit unclear on how the computation proceeds. > >(BTW, the draft will read much better if the generic steps are > >explained first, and then the worked example. As it stands, the > >two are intermixed, and it becomes much more difficult to understand > >what the algo. is.) > > > >The draft states that > >"the PCE provides the list of shortest paths (with their corresponding > >ERO (potentially partial ERO) + Path-cost) from _every_ ASBR to the > >inter-AS TE LSP destination." > > > >Suppose the destination is in ASn. PCEn computes a set of shortest paths > >from _every_ ASBR in ASn to the destination, and passes them > back to PCn-1. > > > >What does PCn-1 do? > > > >My understanding from the draft is that it computes a set of > >shortest paths between all ASBRs that > >connect ASn-1 to ASn-2 and those that connect ASn-1 to ASn, and > >includes the inter-AS links between ASn-1 and ASn in those > >shortest path computations. > > > >My question is: what does PCn-1 send back to PCn-2? > > > >Does it, in turn, send PCn-2 the set of all possible paths traversing > >ASn-1 and ASn or does it concatenate all paths, choose the shortest > >one, and send back one (the shortest path traversing ASn-1 and ASn)? > > > >If the former, then we have a major scalability issue, as the > >number of paths passed back to successive PCi's will grow, > >literally exponentially, from AS to AS. > > > >If the latter, the scheme may fail to select the shortest path, > >as I explain below (which is not unexpected). > > > >Take the following fig. from the draft (where I have added a link > >between ASBR3 and ASBR5): > > > > > > <-- AS 1 ---> <------- AS 2 -----><--- AS 3 ----> > > > > <---BGP---> <---BGP--> > >CE1---R0---X1-ASBR1-----ASBR4--R3---ASBR7----ASBR9----R6 > > |\ \ | / | / | / | | | > > | \ ASBR2---/ ASBR5 | -- | | | > > | \ | /----/ | |/ | | | > > R1-R2---ASBR3-----ASBR6--R4---ASBR8----ASBR10----R7---CE2 > > > > > >We will use the mechanisms specified in Sec. 6 of draft-vasseur, and > >assume for this part of the discussion that the objective is to the > >shortest path between R0 and R7. > > > >As before, ASBR1, ASBR4, and ASBR9 are the PCEs for AS's 1, 2, and > >3, respectively. > > > >The request propagates from R0 to the PCE's, to ASBR1 on to ASBR4 on > >to ASBR9, as before. > > > >1. ASBR9 computes two paths: > > > >ASBR9-R6-R7 Cost = 10, say > >ASBR10-R7 Cost = 20, say (per some metric) > > > >2. It passes these back to ASBR4, which in turn calculates that the > >possibilities > >to traverse AS2 are: > > > >ASBR4-R3-ASBR7-ASBR9, Cost = 30 > >ASBR5-R3-ASBR7-ASBR9, Cost = 40 > >ASBR6-R4-ASBR8-ASBR10, Cost = 30 > >(Assume all other permutations have higher cost.) > > > >3. Using the concatenation approach mentioned in the draft, it computes > >that the shortest paths traversing ASs 2 and 3 is, therefore, > > > >ASBR4-R3-ASBR7 -- ASBR9-R6-R7, total cost = 40 > > > >4. It passes this back to ASBR1, which in turn calculates that the > >possibilities > >to traverse AS1 to reach ASBR4 are: > > > >R0-X1-ASBR1-ASBR4, Cost = 50 > >R0-X1-ASBR2-ASBR4, Cost = 60 > >(There are other permutations, but assume their cost is higher.) > > > >Also, assume that the path from R01 to ASBR5, > >R0-R2-ASBR3-ASBR5 has cost = 30. > > > >5. Again, using concatenation, ASBR1 calculates that the "shortest > >path" is > > > >R0-X1-ASBR1 -- ASBR4-R3-ASBR7 -- ASBR9-R6-R7, total cost = 90 > ><---------------> <-------------> <-----> > > 50 30 10 > > > >However, there was a shorter path > >R0-R2-ASBR3 -- ASBR5-R3-ASBR7 -- ASBR9-R6-R7, total cost = 80 > ><--------------> <--------------> <-----> > > 30 40 10 > > > >which could not get picked in this case. > > > >For this, it would have to be that all possible paths are propagated > >back to PC1, which then selects the shortest one among them, but > >this, it seems to me, would be an operational and computational > nightmare. > > What you described is not how the algorithm works ... All the shortest > paths from the destination to every entry ASBR are computed in a backward > and recursive manner (hence you progressively compute the SPT > rooted at the > LSP destination). Note that there are several variations and > optimizations, > I just described the general case that applies to the generic case of N > ASes. I'll try to clarify in the next revision of the draft. In that case, I feel a much clearer exposition is needed in Sec. 6.6. I had read it several times, but it wasn't clear that the algo. works as described above. (BTW, I will now think about things in the light of what you clarified, and get back with any questions.) In the meantime, I have few quick questions ... -- Who decides on the initial AS path (and consequently the sequence of distributed PCEs) that the request should traverse? (Since there could be multiple paths to get from the source (and its AS) to the destination (and its AS).) There is a phrase at the start of Sec. 6.6, which says "In the case of inter-AS TE, the PCE must be able to serve the source AS and can compute inter-AS TE LSP path terminating in the destination ASn." So, is the first PCE assumed to make that selection of AS's? -- On what criteria is this decision based? -- Also, if the SPT rooted at the destination is the one being computed, why does the text show "trees" rooted at ASBR4 and ASBR1, respectively? Instead (or in addition), it should show an example of what the final SPT, rooted at R7, looks like. -- And, why do the two "SPT's" illustrated have loops? -- Also, at one point (after the fig. for the "SPT" rooted at ASBR4) the text says "The cost of the ASBR-ASBR link between ASBR of different ASes is also known by the PCEi (see section 6.2)." I assume this means the cost of ASBR-ASBR links that connect the current AS to its neighboring AS's? -- And is 6.2 the intended section being referred to? Since 6.2 merely has a paragraph explaining what a PCE is. From owner-ccamp@ops.ietf.org Fri Apr 30 14:34:19 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21064 for ; Fri, 30 Apr 2004 14:34:19 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJcq5-0000QW-Gd for ccamp-archive@ietf.org; Fri, 30 Apr 2004 14:34:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJcpF-0000ME-00 for ccamp-archive@ietf.org; Fri, 30 Apr 2004 14:33:31 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BJcoq-0000H2-00 for ccamp-archive@ietf.org; Fri, 30 Apr 2004 14:33:04 -0400 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BJccj-000D4N-EO for ccamp-data@psg.com; Fri, 30 Apr 2004 18:20:33 +0000 Received: from [171.71.176.72] (helo=sj-iport-3.cisco.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BJccg-000D3v-Pb for ccamp@ops.ietf.org; Fri, 30 Apr 2004 18:20:30 +0000 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 30 Apr 2004 10:34:02 +0000 Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i3UIKRW9014235; Fri, 30 Apr 2004 11:20:27 -0700 (PDT) Received: from jvasseur-w2k01.cisco.com (che-vpn-cluster-2-144.cisco.com [10.86.242.144]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id LAA22372; Fri, 30 Apr 2004 11:20:25 -0700 (PDT) Message-Id: <4.3.2.7.2.20040430141744.033375a8@wells.cisco.com> X-Sender: jvasseur@wells.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 30 Apr 2004 14:20:24 -0400 To: From: Jean Philippe Vasseur Subject: RE: comments on ARO Cc: , , "Fabio Ricciato" , "Ugo Monaco" , "Alessio D'Achille" , "Marco Listanti" In-Reply-To: References: <4.3.2.7.2.20040429232721.0601af50@wells.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,HTML_MESSAGE autolearn=no version=2.60 Hi Vishal, At 11:09 AM 4/30/2004 -0700, Vishal Sharma wrote: >JP, > >Thanks for clarifying. Questions in-line. I'll try to clarify in the next revision of the draft (probably for IETF-61). As for the PCE discovery, IGP extensions have been proposed and BGP ones are on their way. The actual selection could be achieved by various means. Cheers JP. >-Vishal > > > -----Original Message----- > > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On > > Behalf Of Jean Philippe Vasseur > > Sent: Friday, April 30, 2004 5:36 AM > > To: v.sharma@ieee.org > > Cc: stefaan.de_cnodder@alcatel.be; ccamp@ops.ietf.org; Fabio Ricciato; > > Ugo Monaco; Alessio D'Achille; Marco Listanti > > Subject: RE: comments on ARO > > > > ><> > > > > > > > > > Here is one of main concerns that I have about this scheme: > > by contrast > > > > with a distributed PCE-approach, a severe drawback with such > > a model lies > > > > in the potential number of retrials (since it has to be combined with > > > > crankback) and consequently the potential set up time. Indeed, > > > > you may have > > > > diverse paths within a domain, and then a set up failure in > > the next hop > > > > domain requiring to crankback in the previous domain; the number of > > > > potential trials may be really non negligible. > > > > > > > > Moreover, you can still cannot guarantee and an end to end > > shortest path. > > > > > > > > > > > >We have to think a bit more about the idea of combining ARO with > > >crankback and need to get back after giving it some thought. > > > > > >[Please note that the goal with ARO is not necessarily to guarantee > > >an end-to-end shortest path. > > > > Yes I noticed that ;-) hence my comment that it cannot guarantee the > > shortest path > > > > >Rather, it is to ensure that diverse > > >paths can be efficiently computed, while meeting certain constraints > > >per some metrics (as further explained in Fabio's email > > >http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00562.html > > >and my recent reply to Stefaan > > >http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00561.html)] > > > > But my main concern remains: the number of required crankback required in > > some cases and the related impact on set up failure. > > > > >Reading draft-vasseur-ccamp-inter-area-as, especially Sec. 6.6 > > >I was a bit unclear on how the computation proceeds. > > >(BTW, the draft will read much better if the generic steps are > > >explained first, and then the worked example. As it stands, the > > >two are intermixed, and it becomes much more difficult to understand > > >what the algo. is.) > > > > > >The draft states that > > >"the PCE provides the list of shortest paths (with their corresponding > > >ERO (potentially partial ERO) + Path-cost) from _every_ ASBR to the > > >inter-AS TE LSP destination." > > > > > >Suppose the destination is in ASn. PCEn computes a set of shortest paths > > >from _every_ ASBR in ASn to the destination, and passes them > > back to PCn-1. > > > > > >What does PCn-1 do? > > > > > >My understanding from the draft is that it computes a set of > > >shortest paths between all ASBRs that > > >connect ASn-1 to ASn-2 and those that connect ASn-1 to ASn, and > > >includes the inter-AS links between ASn-1 and ASn in those > > >shortest path computations. > > > > > >My question is: what does PCn-1 send back to PCn-2? > > > > > >Does it, in turn, send PCn-2 the set of all possible paths traversing > > >ASn-1 and ASn or does it concatenate all paths, choose the shortest > > >one, and send back one (the shortest path traversing ASn-1 and ASn)? > > > > > >If the former, then we have a major scalability issue, as the > > >number of paths passed back to successive PCi's will grow, > > >literally exponentially, from AS to AS. > > > > > >If the latter, the scheme may fail to select the shortest path, > > >as I explain below (which is not unexpected). > > > > > >Take the following fig. from the draft (where I have added a link > > >between ASBR3 and ASBR5): > > > > > > > > > <-- AS 1 ---> <------- AS 2 -----><--- AS 3 ----> > > > > > > <---BGP---> <---BGP--> > > >CE1---R0---X1-ASBR1-----ASBR4--R3---ASBR7----ASBR9----R6 > > > |\ \ | / | / | / | | | > > > | \ ASBR2---/ ASBR5 | -- | | | > > > | \ | /----/ | |/ | | | > > > R1-R2---ASBR3-----ASBR6--R4---ASBR8----ASBR10----R7---CE2 > > > > > > > > >We will use the mechanisms specified in Sec. 6 of draft-vasseur, and > > >assume for this part of the discussion that the objective is to the > > >shortest path between R0 and R7. > > > > > >As before, ASBR1, ASBR4, and ASBR9 are the PCEs for AS's 1, 2, and > > >3, respectively. > > > > > >The request propagates from R0 to the PCE's, to ASBR1 on to ASBR4 on > > >to ASBR9, as before. > > > > > >1. ASBR9 computes two paths: > > > > > >ASBR9-R6-R7 Cost = 10, say > > >ASBR10-R7 Cost = 20, say (per some metric) > > > > > >2. It passes these back to ASBR4, which in turn calculates that the > > >possibilities > > >to traverse AS2 are: > > > > > >ASBR4-R3-ASBR7-ASBR9, Cost = 30 > > >ASBR5-R3-ASBR7-ASBR9, Cost = 40 > > >ASBR6-R4-ASBR8-ASBR10, Cost = 30 > > >(Assume all other permutations have higher cost.) > > > > > >3. Using the concatenation approach mentioned in the draft, it computes > > >that the shortest paths traversing ASs 2 and 3 is, therefore, > > > > > >ASBR4-R3-ASBR7 -- ASBR9-R6-R7, total cost = 40 > > > > > >4. It passes this back to ASBR1, which in turn calculates that the > > >possibilities > > >to traverse AS1 to reach ASBR4 are: > > > > > >R0-X1-ASBR1-ASBR4, Cost = 50 > > >R0-X1-ASBR2-ASBR4, Cost = 60 > > >(There are other permutations, but assume their cost is higher.) > > > > > >Also, assume that the path from R01 to ASBR5, > > >R0-R2-ASBR3-ASBR5 has cost = 30. > > > > > >5. Again, using concatenation, ASBR1 calculates that the "shortest > > >path" is > > > > > >R0-X1-ASBR1 -- ASBR4-R3-ASBR7 -- ASBR9-R6-R7, total cost = 90 > > ><---------------> <-------------> <-----> > > > 50 30 10 > > > > > >However, there was a shorter path > > >R0-R2-ASBR3 -- ASBR5-R3-ASBR7 -- ASBR9-R6-R7, total cost = 80 > > ><--------------> <--------------> <-----> > > > 30 40 10 > > > > > >which could not get picked in this case. > > > > > >For this, it would have to be that all possible paths are propagated > > >back to PC1, which then selects the shortest one among them, but > > >this, it seems to me, would be an operational and computational > > nightmare. > > > > What you described is not how the algorithm works ... All the shortest > > paths from the destination to every entry ASBR are computed in a backward > > and recursive manner (hence you progressively compute the SPT > > rooted at the > > LSP destination). Note that there are several variations and > > optimizations, > > I just described the general case that applies to the generic case of N > > ASes. I'll try to clarify in the next revision of the draft. > > >In that case, I feel a much clearer exposition is needed in Sec. 6.6. >I had read it several times, but it wasn't clear that the algo. >works as described above. >(BTW, I will now think about things in the light of what you clarified, >and get back with any questions.) > >In the meantime, I have few quick questions ... > >-- Who decides on the initial AS path (and consequently >the sequence of distributed PCEs) that the request should traverse? >(Since there could be multiple paths to get from the source (and its >AS) to the destination (and its AS).) > >There is a phrase at the start of Sec. 6.6, which says >"In the case of inter-AS TE, the PCE must >be able to serve the source AS and can compute inter-AS TE LSP path >terminating in the destination ASn." > >So, is the first PCE assumed to make that selection of AS's? > >-- On what criteria is this decision based? > >-- Also, if the SPT rooted at the destination is the one being computed, >why does the text show "trees" rooted at ASBR4 and ASBR1, respectively? >Instead (or in addition), it should show an example of what the final >SPT, rooted at R7, looks like. > >-- And, why do the two "SPT's" illustrated have loops? > >-- Also, at one point (after the fig. for the "SPT" rooted at ASBR4) the >text says >"The cost of the ASBR-ASBR link between ASBR of different ASes is also >known by the PCEi (see section 6.2)." > >I assume this means the cost of ASBR-ASBR links that connect the current >AS to its neighboring AS's? > >-- And is 6.2 the intended section being referred to? Since 6.2 merely >has a paragraph explaining what a PCE is. From owner-ccamp@ops.ietf.org Fri Apr 30 16:02:10 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27389 for ; Fri, 30 Apr 2004 16:02:09 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJeD6-0000Gz-Ii for ccamp-archive@ietf.org; Fri, 30 Apr 2004 16:02:12 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJeC9-0000CM-00 for ccamp-archive@ietf.org; Fri, 30 Apr 2004 16:01:13 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BJeBM-00009D-00 for ccamp-archive@ietf.org; Fri, 30 Apr 2004 16:00:24 -0400 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BJdw6-0002FV-MU for ccamp-data@psg.com; Fri, 30 Apr 2004 19:44:38 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BJdw5-0002FG-N2 for ccamp@ops.ietf.org; Fri, 30 Apr 2004 19:44:37 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26191; Fri, 30 Apr 2004 15:44:33 -0400 (EDT) Message-Id: <200404301944.PAA26191@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-farrel-ccamp-inter-domain-framework-00.txt Date: Fri, 30 Apr 2004 15:44:33 -0400 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : A Framework for Inter-Domain MPLS Traffic Engineering Author(s) : A. Farrel, et al. Filename : draft-farrel-ccamp-inter-domain-framework-00.txt Pages : 14 Date : 2004-4-30 This document provides a framework for establishing and controlling Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Label Switched Paths (LSPs) in multi-domain networks. For the purposes of this document, a domain is considered to be any collection of network elements within a common sphere of address management or path computational responsibility. Examples of such domains include IGP areas and Autonomous Systems. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-farrel-ccamp-inter-domain-framework-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-farrel-ccamp-inter-domain-framework-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-farrel-ccamp-inter-domain-framework-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-4-30160331.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-farrel-ccamp-inter-domain-framework-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-farrel-ccamp-inter-domain-framework-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-4-30160331.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 30 Apr 2004 19:45:14 +0000 Message-Id: <200404301944.PAA26191@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-farrel-ccamp-inter-domain-framework-00.txt Date: Fri, 30 Apr 2004 15:44:33 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : A Framework for Inter-Domain MPLS Traffic Engineering Author(s) : A. Farrel, et al. Filename : draft-farrel-ccamp-inter-domain-framework-00.txt Pages : 14 Date : 2004-4-30 This document provides a framework for establishing and controlling Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Label Switched Paths (LSPs) in multi-domain networks. For the purposes of this document, a domain is considered to be any collection of network elements within a common sphere of address management or path computational responsibility. Examples of such domains include IGP areas and Autonomous Systems. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-farrel-ccamp-inter-domain-framework-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-farrel-ccamp-inter-domain-framework-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-farrel-ccamp-inter-domain-framework-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-4-30160331.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-farrel-ccamp-inter-domain-framework-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-farrel-ccamp-inter-domain-framework-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-4-30160331.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 30 Apr 2004 18:20:48 +0000 Message-Id: <4.3.2.7.2.20040430141744.033375a8@wells.cisco.com> Date: Fri, 30 Apr 2004 14:20:24 -0400 To: From: Jean Philippe Vasseur Subject: RE: comments on ARO Cc: , , "Fabio Ricciato" , "Ugo Monaco" , "Alessio D'Achille" , "Marco Listanti" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Hi Vishal, At 11:09 AM 4/30/2004 -0700, Vishal Sharma wrote: >JP, > >Thanks for clarifying. Questions in-line. I'll try to clarify in the next revision of the draft (probably for IETF-61). As for the PCE discovery, IGP extensions have been proposed and BGP ones are on their way. The actual selection could be achieved by various means. Cheers JP. >-Vishal > > > -----Original Message----- > > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On > > Behalf Of Jean Philippe Vasseur > > Sent: Friday, April 30, 2004 5:36 AM > > To: v.sharma@ieee.org > > Cc: stefaan.de_cnodder@alcatel.be; ccamp@ops.ietf.org; Fabio Ricciato; > > Ugo Monaco; Alessio D'Achille; Marco Listanti > > Subject: RE: comments on ARO > > > > ><> > > > > > > > > > Here is one of main concerns that I have about this scheme: > > by contrast > > > > with a distributed PCE-approach, a severe drawback with such > > a model lies > > > > in the potential number of retrials (since it has to be combined with > > > > crankback) and consequently the potential set up time. Indeed, > > > > you may have > > > > diverse paths within a domain, and then a set up failure in > > the next hop > > > > domain requiring to crankback in the previous domain; the number of > > > > potential trials may be really non negligible. > > > > > > > > Moreover, you can still cannot guarantee and an end to end > > shortest path. > > > > > > > > > > > >We have to think a bit more about the idea of combining ARO with > > >crankback and need to get back after giving it some thought. > > > > > >[Please note that the goal with ARO is not necessarily to guarantee > > >an end-to-end shortest path. > > > > Yes I noticed that ;-) hence my comment that it cannot guarantee the > > shortest path > > > > >Rather, it is to ensure that diverse > > >paths can be efficiently computed, while meeting certain constraints > > >per some metrics (as further explained in Fabio's email > > >http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00562.html > > >and my recent reply to Stefaan > > >http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00561.html)] > > > > But my main concern remains: the number of required crankback required in > > some cases and the related impact on set up failure. > > > > >Reading draft-vasseur-ccamp-inter-area-as, especially Sec. 6.6 > > >I was a bit unclear on how the computation proceeds. > > >(BTW, the draft will read much better if the generic steps are > > >explained first, and then the worked example. As it stands, the > > >two are intermixed, and it becomes much more difficult to understand > > >what the algo. is.) > > > > > >The draft states that > > >"the PCE provides the list of shortest paths (with their corresponding > > >ERO (potentially partial ERO) + Path-cost) from _every_ ASBR to the > > >inter-AS TE LSP destination." > > > > > >Suppose the destination is in ASn. PCEn computes a set of shortest paths > > >from _every_ ASBR in ASn to the destination, and passes them > > back to PCn-1. > > > > > >What does PCn-1 do? > > > > > >My understanding from the draft is that it computes a set of > > >shortest paths between all ASBRs that > > >connect ASn-1 to ASn-2 and those that connect ASn-1 to ASn, and > > >includes the inter-AS links between ASn-1 and ASn in those > > >shortest path computations. > > > > > >My question is: what does PCn-1 send back to PCn-2? > > > > > >Does it, in turn, send PCn-2 the set of all possible paths traversing > > >ASn-1 and ASn or does it concatenate all paths, choose the shortest > > >one, and send back one (the shortest path traversing ASn-1 and ASn)? > > > > > >If the former, then we have a major scalability issue, as the > > >number of paths passed back to successive PCi's will grow, > > >literally exponentially, from AS to AS. > > > > > >If the latter, the scheme may fail to select the shortest path, > > >as I explain below (which is not unexpected). > > > > > >Take the following fig. from the draft (where I have added a link > > >between ASBR3 and ASBR5): > > > > > > > > > <-- AS 1 ---> <------- AS 2 -----><--- AS 3 ----> > > > > > > <---BGP---> <---BGP--> > > >CE1---R0---X1-ASBR1-----ASBR4--R3---ASBR7----ASBR9----R6 > > > |\ \ | / | / | / | | | > > > | \ ASBR2---/ ASBR5 | -- | | | > > > | \ | /----/ | |/ | | | > > > R1-R2---ASBR3-----ASBR6--R4---ASBR8----ASBR10----R7---CE2 > > > > > > > > >We will use the mechanisms specified in Sec. 6 of draft-vasseur, and > > >assume for this part of the discussion that the objective is to the > > >shortest path between R0 and R7. > > > > > >As before, ASBR1, ASBR4, and ASBR9 are the PCEs for AS's 1, 2, and > > >3, respectively. > > > > > >The request propagates from R0 to the PCE's, to ASBR1 on to ASBR4 on > > >to ASBR9, as before. > > > > > >1. ASBR9 computes two paths: > > > > > >ASBR9-R6-R7 Cost = 10, say > > >ASBR10-R7 Cost = 20, say (per some metric) > > > > > >2. It passes these back to ASBR4, which in turn calculates that the > > >possibilities > > >to traverse AS2 are: > > > > > >ASBR4-R3-ASBR7-ASBR9, Cost = 30 > > >ASBR5-R3-ASBR7-ASBR9, Cost = 40 > > >ASBR6-R4-ASBR8-ASBR10, Cost = 30 > > >(Assume all other permutations have higher cost.) > > > > > >3. Using the concatenation approach mentioned in the draft, it computes > > >that the shortest paths traversing ASs 2 and 3 is, therefore, > > > > > >ASBR4-R3-ASBR7 -- ASBR9-R6-R7, total cost = 40 > > > > > >4. It passes this back to ASBR1, which in turn calculates that the > > >possibilities > > >to traverse AS1 to reach ASBR4 are: > > > > > >R0-X1-ASBR1-ASBR4, Cost = 50 > > >R0-X1-ASBR2-ASBR4, Cost = 60 > > >(There are other permutations, but assume their cost is higher.) > > > > > >Also, assume that the path from R01 to ASBR5, > > >R0-R2-ASBR3-ASBR5 has cost = 30. > > > > > >5. Again, using concatenation, ASBR1 calculates that the "shortest > > >path" is > > > > > >R0-X1-ASBR1 -- ASBR4-R3-ASBR7 -- ASBR9-R6-R7, total cost = 90 > > ><---------------> <-------------> <-----> > > > 50 30 10 > > > > > >However, there was a shorter path > > >R0-R2-ASBR3 -- ASBR5-R3-ASBR7 -- ASBR9-R6-R7, total cost = 80 > > ><--------------> <--------------> <-----> > > > 30 40 10 > > > > > >which could not get picked in this case. > > > > > >For this, it would have to be that all possible paths are propagated > > >back to PC1, which then selects the shortest one among them, but > > >this, it seems to me, would be an operational and computational > > nightmare. > > > > What you described is not how the algorithm works ... All the shortest > > paths from the destination to every entry ASBR are computed in a backward > > and recursive manner (hence you progressively compute the SPT > > rooted at the > > LSP destination). Note that there are several variations and > > optimizations, > > I just described the general case that applies to the generic case of N > > ASes. I'll try to clarify in the next revision of the draft. > > >In that case, I feel a much clearer exposition is needed in Sec. 6.6. >I had read it several times, but it wasn't clear that the algo. >works as described above. >(BTW, I will now think about things in the light of what you clarified, >and get back with any questions.) > >In the meantime, I have few quick questions ... > >-- Who decides on the initial AS path (and consequently >the sequence of distributed PCEs) that the request should traverse? >(Since there could be multiple paths to get from the source (and its >AS) to the destination (and its AS).) > >There is a phrase at the start of Sec. 6.6, which says >"In the case of inter-AS TE, the PCE must >be able to serve the source AS and can compute inter-AS TE LSP path >terminating in the destination ASn." > >So, is the first PCE assumed to make that selection of AS's? > >-- On what criteria is this decision based? > >-- Also, if the SPT rooted at the destination is the one being computed, >why does the text show "trees" rooted at ASBR4 and ASBR1, respectively? >Instead (or in addition), it should show an example of what the final >SPT, rooted at R7, looks like. > >-- And, why do the two "SPT's" illustrated have loops? > >-- Also, at one point (after the fig. for the "SPT" rooted at ASBR4) the >text says >"The cost of the ASBR-ASBR link between ASBR of different ASes is also >known by the PCEi (see section 6.2)." > >I assume this means the cost of ASBR-ASBR links that connect the current >AS to its neighboring AS's? > >-- And is 6.2 the intended section being referred to? Since 6.2 merely >has a paragraph explaining what a PCE is. Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 30 Apr 2004 18:10:07 +0000 Reply-To: From: "Vishal Sharma" To: "Jean Philippe Vasseur" Cc: , , "Fabio Ricciato" , "Ugo Monaco" , "Alessio D'Achille" , "Marco Listanti" Subject: RE: comments on ARO Date: Fri, 30 Apr 2004 11:09:10 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit JP, Thanks for clarifying. Questions in-line. -Vishal > -----Original Message----- > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On > Behalf Of Jean Philippe Vasseur > Sent: Friday, April 30, 2004 5:36 AM > To: v.sharma@ieee.org > Cc: stefaan.de_cnodder@alcatel.be; ccamp@ops.ietf.org; Fabio Ricciato; > Ugo Monaco; Alessio D'Achille; Marco Listanti > Subject: RE: comments on ARO > > <> > > > > > > Here is one of main concerns that I have about this scheme: > by contrast > > > with a distributed PCE-approach, a severe drawback with such > a model lies > > > in the potential number of retrials (since it has to be combined with > > > crankback) and consequently the potential set up time. Indeed, > > > you may have > > > diverse paths within a domain, and then a set up failure in > the next hop > > > domain requiring to crankback in the previous domain; the number of > > > potential trials may be really non negligible. > > > > > > Moreover, you can still cannot guarantee and an end to end > shortest path. > > > > > > > >We have to think a bit more about the idea of combining ARO with > >crankback and need to get back after giving it some thought. > > > >[Please note that the goal with ARO is not necessarily to guarantee > >an end-to-end shortest path. > > Yes I noticed that ;-) hence my comment that it cannot guarantee the > shortest path > > >Rather, it is to ensure that diverse > >paths can be efficiently computed, while meeting certain constraints > >per some metrics (as further explained in Fabio's email > >http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00562.html > >and my recent reply to Stefaan > >http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00561.html)] > > But my main concern remains: the number of required crankback required in > some cases and the related impact on set up failure. > > >Reading draft-vasseur-ccamp-inter-area-as, especially Sec. 6.6 > >I was a bit unclear on how the computation proceeds. > >(BTW, the draft will read much better if the generic steps are > >explained first, and then the worked example. As it stands, the > >two are intermixed, and it becomes much more difficult to understand > >what the algo. is.) > > > >The draft states that > >"the PCE provides the list of shortest paths (with their corresponding > >ERO (potentially partial ERO) + Path-cost) from _every_ ASBR to the > >inter-AS TE LSP destination." > > > >Suppose the destination is in ASn. PCEn computes a set of shortest paths > >from _every_ ASBR in ASn to the destination, and passes them > back to PCn-1. > > > >What does PCn-1 do? > > > >My understanding from the draft is that it computes a set of > >shortest paths between all ASBRs that > >connect ASn-1 to ASn-2 and those that connect ASn-1 to ASn, and > >includes the inter-AS links between ASn-1 and ASn in those > >shortest path computations. > > > >My question is: what does PCn-1 send back to PCn-2? > > > >Does it, in turn, send PCn-2 the set of all possible paths traversing > >ASn-1 and ASn or does it concatenate all paths, choose the shortest > >one, and send back one (the shortest path traversing ASn-1 and ASn)? > > > >If the former, then we have a major scalability issue, as the > >number of paths passed back to successive PCi's will grow, > >literally exponentially, from AS to AS. > > > >If the latter, the scheme may fail to select the shortest path, > >as I explain below (which is not unexpected). > > > >Take the following fig. from the draft (where I have added a link > >between ASBR3 and ASBR5): > > > > > > <-- AS 1 ---> <------- AS 2 -----><--- AS 3 ----> > > > > <---BGP---> <---BGP--> > >CE1---R0---X1-ASBR1-----ASBR4--R3---ASBR7----ASBR9----R6 > > |\ \ | / | / | / | | | > > | \ ASBR2---/ ASBR5 | -- | | | > > | \ | /----/ | |/ | | | > > R1-R2---ASBR3-----ASBR6--R4---ASBR8----ASBR10----R7---CE2 > > > > > >We will use the mechanisms specified in Sec. 6 of draft-vasseur, and > >assume for this part of the discussion that the objective is to the > >shortest path between R0 and R7. > > > >As before, ASBR1, ASBR4, and ASBR9 are the PCEs for AS's 1, 2, and > >3, respectively. > > > >The request propagates from R0 to the PCE's, to ASBR1 on to ASBR4 on > >to ASBR9, as before. > > > >1. ASBR9 computes two paths: > > > >ASBR9-R6-R7 Cost = 10, say > >ASBR10-R7 Cost = 20, say (per some metric) > > > >2. It passes these back to ASBR4, which in turn calculates that the > >possibilities > >to traverse AS2 are: > > > >ASBR4-R3-ASBR7-ASBR9, Cost = 30 > >ASBR5-R3-ASBR7-ASBR9, Cost = 40 > >ASBR6-R4-ASBR8-ASBR10, Cost = 30 > >(Assume all other permutations have higher cost.) > > > >3. Using the concatenation approach mentioned in the draft, it computes > >that the shortest paths traversing ASs 2 and 3 is, therefore, > > > >ASBR4-R3-ASBR7 -- ASBR9-R6-R7, total cost = 40 > > > >4. It passes this back to ASBR1, which in turn calculates that the > >possibilities > >to traverse AS1 to reach ASBR4 are: > > > >R0-X1-ASBR1-ASBR4, Cost = 50 > >R0-X1-ASBR2-ASBR4, Cost = 60 > >(There are other permutations, but assume their cost is higher.) > > > >Also, assume that the path from R01 to ASBR5, > >R0-R2-ASBR3-ASBR5 has cost = 30. > > > >5. Again, using concatenation, ASBR1 calculates that the "shortest > >path" is > > > >R0-X1-ASBR1 -- ASBR4-R3-ASBR7 -- ASBR9-R6-R7, total cost = 90 > ><---------------> <-------------> <-----> > > 50 30 10 > > > >However, there was a shorter path > >R0-R2-ASBR3 -- ASBR5-R3-ASBR7 -- ASBR9-R6-R7, total cost = 80 > ><--------------> <--------------> <-----> > > 30 40 10 > > > >which could not get picked in this case. > > > >For this, it would have to be that all possible paths are propagated > >back to PC1, which then selects the shortest one among them, but > >this, it seems to me, would be an operational and computational > nightmare. > > What you described is not how the algorithm works ... All the shortest > paths from the destination to every entry ASBR are computed in a backward > and recursive manner (hence you progressively compute the SPT > rooted at the > LSP destination). Note that there are several variations and > optimizations, > I just described the general case that applies to the generic case of N > ASes. I'll try to clarify in the next revision of the draft. In that case, I feel a much clearer exposition is needed in Sec. 6.6. I had read it several times, but it wasn't clear that the algo. works as described above. (BTW, I will now think about things in the light of what you clarified, and get back with any questions.) In the meantime, I have few quick questions ... -- Who decides on the initial AS path (and consequently the sequence of distributed PCEs) that the request should traverse? (Since there could be multiple paths to get from the source (and its AS) to the destination (and its AS).) There is a phrase at the start of Sec. 6.6, which says "In the case of inter-AS TE, the PCE must be able to serve the source AS and can compute inter-AS TE LSP path terminating in the destination ASn." So, is the first PCE assumed to make that selection of AS's? -- On what criteria is this decision based? -- Also, if the SPT rooted at the destination is the one being computed, why does the text show "trees" rooted at ASBR4 and ASBR1, respectively? Instead (or in addition), it should show an example of what the final SPT, rooted at R7, looks like. -- And, why do the two "SPT's" illustrated have loops? -- Also, at one point (after the fig. for the "SPT" rooted at ASBR4) the text says "The cost of the ASBR-ASBR link between ASBR of different ASes is also known by the PCEi (see section 6.2)." I assume this means the cost of ASBR-ASBR links that connect the current AS to its neighboring AS's? -- And is 6.2 the intended section being referred to? Since 6.2 merely has a paragraph explaining what a PCE is. Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 30 Apr 2004 12:38:34 +0000 Message-Id: <4.3.2.7.2.20040429232721.0601af50@wells.cisco.com> Date: Fri, 30 Apr 2004 08:36:05 -0400 To: From: Jean Philippe Vasseur Subject: RE: comments on ARO Cc: , , "Fabio Ricciato" , "Ugo Monaco" , "Alessio D'Achille" , "Marco Listanti" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Hi Vishal, At 04:26 PM 4/29/2004 -0700, Vishal Sharma wrote: >JP, > >Thanks for the comments. > >A comment and question in-line. > >-Vishal > > > -----Original Message----- > > From: Jean Philippe Vasseur [mailto:jvasseur@cisco.com] > > Sent: Thursday, April 29, 2004 10:27 AM > > To: v.sharma@ieee.org > > Cc: stefaan.de_cnodder@alcatel.be; ccamp@ops.ietf.org; Fabio Ricciato; > > Ugo Monaco; Alessio D'Achille; Marco Listanti > > Subject: RE: comments on ARO > > ><> > > > > > > 1) Recording only border nodes: > > > > > > > > > > Actually, if one only recorded border nodes, then upon signaling > > > > > the secondary, the ingress border node for the secondary has no > > > > > idea about the intra-area (or intra-AS) path of the primary (in its > > > > > own area or AS), and therefore cannot ensure that the primary and > > > > > secondary segments are in fact disjoint. > > > > > > > > > > This was a point I discussed with several other people > > > > > (who initially proposed the same thing), including > > > > > Arthi and Adrian, but we concluded, for the reason above, > > that merely > > > > > recording the border nodes does not work for diversity. As a > > > > > result, the ARO does, in fact, serve a very useful purpose. > > > > > > > > > > We can of course think more about what the trade-offs are, and > > > > see if there > > > > > is some way to retain the main advantage of the proposal (diversity, > > > > > joint optimization of both paths) while also recording less > > information. > > > > > > > > > > > > > The problem I want to solve here is NOT to reduce the amount of > > > > information in the ARO, i.e. my purpose is not to reduce its length. > > > > Rather, by only recording the border nodes you give more freedom > > > > when signaling the secondary (using the XRO!) meaning that when > > > > crankback or re-optimization of the secondary is possible, the > > > > primary does not have to be resignaled to get a new ARO. > > > > > >Sure, I understood that the goal wasn't to reduce the length of > > >the ARO per se, but rather the level of detail that would need to > > >be recorded in it (regardless of the actual amount of data the ARO > > >would carry). > > > > > >If you recollect the classification of path computation models > > >I gave in my email to JP > > >http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00467.html > > > > > >we have under distributed computing: i) a parallel path computation > > >model and ii) a sequential one. > > >ARO achieves the former, while XRO achieves the latter. > > > > > >So, if one did not compute and record the path of the secondary > > >jointly with the primary (and only recorded the border nodes instead) > > >the scheme would reduce to a _sequential path computation_, with its > > >attendant drawbacks (sub-optimality, trap topology, etc.). > > > > > >The beauty of the ARO scheme is that it can compute end-to-end > > >diverse paths using a parallel path computation model (albeit distributed > > >at each area/AS), with the simplicity of the per-domain approach, and > > >without any changes to the signaling protocols. > > > > Here is one of main concerns that I have about this scheme: by contrast > > with a distributed PCE-approach, a severe drawback with such a model lies > > in the potential number of retrials (since it has to be combined with > > crankback) and consequently the potential set up time. Indeed, > > you may have > > diverse paths within a domain, and then a set up failure in the next hop > > domain requiring to crankback in the previous domain; the number of > > potential trials may be really non negligible. > > > > Moreover, you can still cannot guarantee and an end to end shortest path. > > > >We have to think a bit more about the idea of combining ARO with >crankback and need to get back after giving it some thought. > >[Please note that the goal with ARO is not necessarily to guarantee >an end-to-end shortest path. Yes I noticed that ;-) hence my comment that it cannot guarantee the shortest path >Rather, it is to ensure that diverse >paths can be efficiently computed, while meeting certain constraints >per some metrics (as further explained in Fabio's email >http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00562.html >and my recent reply to Stefaan >http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00561.html)] But my main concern remains: the number of required crankback required in some cases and the related impact on set up failure. >Reading draft-vasseur-ccamp-inter-area-as, especially Sec. 6.6 >I was a bit unclear on how the computation proceeds. >(BTW, the draft will read much better if the generic steps are >explained first, and then the worked example. As it stands, the >two are intermixed, and it becomes much more difficult to understand >what the algo. is.) > >The draft states that >"the PCE provides the list of shortest paths (with their corresponding >ERO (potentially partial ERO) + Path-cost) from _every_ ASBR to the >inter-AS TE LSP destination." > >Suppose the destination is in ASn. PCEn computes a set of shortest paths >from _every_ ASBR in ASn to the destination, and passes them back to PCn-1. > >What does PCn-1 do? > >My understanding from the draft is that it computes a set of >shortest paths between all ASBRs that >connect ASn-1 to ASn-2 and those that connect ASn-1 to ASn, and >includes the inter-AS links between ASn-1 and ASn in those >shortest path computations. > >My question is: what does PCn-1 send back to PCn-2? > >Does it, in turn, send PCn-2 the set of all possible paths traversing >ASn-1 and ASn or does it concatenate all paths, choose the shortest >one, and send back one (the shortest path traversing ASn-1 and ASn)? > >If the former, then we have a major scalability issue, as the >number of paths passed back to successive PCi's will grow, >literally exponentially, from AS to AS. > >If the latter, the scheme may fail to select the shortest path, >as I explain below (which is not unexpected). > >Take the following fig. from the draft (where I have added a link >between ASBR3 and ASBR5): > > > <-- AS 1 ---> <------- AS 2 -----><--- AS 3 ----> > > <---BGP---> <---BGP--> >CE1---R0---X1-ASBR1-----ASBR4--R3---ASBR7----ASBR9----R6 > |\ \ | / | / | / | | | > | \ ASBR2---/ ASBR5 | -- | | | > | \ | /----/ | |/ | | | > R1-R2---ASBR3-----ASBR6--R4---ASBR8----ASBR10----R7---CE2 > > >We will use the mechanisms specified in Sec. 6 of draft-vasseur, and >assume for this part of the discussion that the objective is to the >shortest path between R0 and R7. > >As before, ASBR1, ASBR4, and ASBR9 are the PCEs for AS's 1, 2, and >3, respectively. > >The request propagates from R0 to the PCE's, to ASBR1 on to ASBR4 on >to ASBR9, as before. > >1. ASBR9 computes two paths: > >ASBR9-R6-R7 Cost = 10, say >ASBR10-R7 Cost = 20, say (per some metric) > >2. It passes these back to ASBR4, which in turn calculates that the >possibilities >to traverse AS2 are: > >ASBR4-R3-ASBR7-ASBR9, Cost = 30 >ASBR5-R3-ASBR7-ASBR9, Cost = 40 >ASBR6-R4-ASBR8-ASBR10, Cost = 30 >(Assume all other permutations have higher cost.) > >3. Using the concatenation approach mentioned in the draft, it computes >that the shortest paths traversing ASs 2 and 3 is, therefore, > >ASBR4-R3-ASBR7 -- ASBR9-R6-R7, total cost = 40 > >4. It passes this back to ASBR1, which in turn calculates that the >possibilities >to traverse AS1 to reach ASBR4 are: > >R0-X1-ASBR1-ASBR4, Cost = 50 >R0-X1-ASBR2-ASBR4, Cost = 60 >(There are other permutations, but assume their cost is higher.) > >Also, assume that the path from R01 to ASBR5, >R0-R2-ASBR3-ASBR5 has cost = 30. > >5. Again, using concatenation, ASBR1 calculates that the "shortest >path" is > >R0-X1-ASBR1 -- ASBR4-R3-ASBR7 -- ASBR9-R6-R7, total cost = 90 ><---------------> <-------------> <-----> > 50 30 10 > >However, there was a shorter path >R0-R2-ASBR3 -- ASBR5-R3-ASBR7 -- ASBR9-R6-R7, total cost = 80 ><--------------> <--------------> <-----> > 30 40 10 > >which could not get picked in this case. > >For this, it would have to be that all possible paths are propagated >back to PC1, which then selects the shortest one among them, but >this, it seems to me, would be an operational and computational nightmare. What you described is not how the algorithm works ... All the shortest paths from the destination to every entry ASBR are computed in a backward and recursive manner (hence you progressively compute the SPT rooted at the LSP destination). Note that there are several variations and optimizations, I just described the general case that applies to the generic case of N ASes. I'll try to clarify in the next revision of the draft. Cheers JP. Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 29 Apr 2004 23:28:35 +0000 Reply-To: From: "Vishal Sharma" To: "Jean Philippe Vasseur" Cc: , , "Fabio Ricciato" , "Ugo Monaco" , "Alessio D'Achille" , "Marco Listanti" Subject: RE: comments on ARO Date: Thu, 29 Apr 2004 16:26:52 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit JP, Thanks for the comments. A comment and question in-line. -Vishal > -----Original Message----- > From: Jean Philippe Vasseur [mailto:jvasseur@cisco.com] > Sent: Thursday, April 29, 2004 10:27 AM > To: v.sharma@ieee.org > Cc: stefaan.de_cnodder@alcatel.be; ccamp@ops.ietf.org; Fabio Ricciato; > Ugo Monaco; Alessio D'Achille; Marco Listanti > Subject: RE: comments on ARO > <> > > > > 1) Recording only border nodes: > > > > > > > > Actually, if one only recorded border nodes, then upon signaling > > > > the secondary, the ingress border node for the secondary has no > > > > idea about the intra-area (or intra-AS) path of the primary (in its > > > > own area or AS), and therefore cannot ensure that the primary and > > > > secondary segments are in fact disjoint. > > > > > > > > This was a point I discussed with several other people > > > > (who initially proposed the same thing), including > > > > Arthi and Adrian, but we concluded, for the reason above, > that merely > > > > recording the border nodes does not work for diversity. As a > > > > result, the ARO does, in fact, serve a very useful purpose. > > > > > > > > We can of course think more about what the trade-offs are, and > > > see if there > > > > is some way to retain the main advantage of the proposal (diversity, > > > > joint optimization of both paths) while also recording less > information. > > > > > > > > > > The problem I want to solve here is NOT to reduce the amount of > > > information in the ARO, i.e. my purpose is not to reduce its length. > > > Rather, by only recording the border nodes you give more freedom > > > when signaling the secondary (using the XRO!) meaning that when > > > crankback or re-optimization of the secondary is possible, the > > > primary does not have to be resignaled to get a new ARO. > > > >Sure, I understood that the goal wasn't to reduce the length of > >the ARO per se, but rather the level of detail that would need to > >be recorded in it (regardless of the actual amount of data the ARO > >would carry). > > > >If you recollect the classification of path computation models > >I gave in my email to JP > >http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00467.html > > > >we have under distributed computing: i) a parallel path computation > >model and ii) a sequential one. > >ARO achieves the former, while XRO achieves the latter. > > > >So, if one did not compute and record the path of the secondary > >jointly with the primary (and only recorded the border nodes instead) > >the scheme would reduce to a _sequential path computation_, with its > >attendant drawbacks (sub-optimality, trap topology, etc.). > > > >The beauty of the ARO scheme is that it can compute end-to-end > >diverse paths using a parallel path computation model (albeit distributed > >at each area/AS), with the simplicity of the per-domain approach, and > >without any changes to the signaling protocols. > > Here is one of main concerns that I have about this scheme: by contrast > with a distributed PCE-approach, a severe drawback with such a model lies > in the potential number of retrials (since it has to be combined with > crankback) and consequently the potential set up time. Indeed, > you may have > diverse paths within a domain, and then a set up failure in the next hop > domain requiring to crankback in the previous domain; the number of > potential trials may be really non negligible. > > Moreover, you can still cannot guarantee and an end to end shortest path. We have to think a bit more about the idea of combining ARO with crankback and need to get back after giving it some thought. [Please note that the goal with ARO is not necessarily to guarantee an end-to-end shortest path. Rather, it is to ensure that diverse paths can be efficiently computed, while meeting certain constraints per some metrics (as further explained in Fabio's email http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00562.html and my recent reply to Stefaan http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00561.html)] Reading draft-vasseur-ccamp-inter-area-as, especially Sec. 6.6 I was a bit unclear on how the computation proceeds. (BTW, the draft will read much better if the generic steps are explained first, and then the worked example. As it stands, the two are intermixed, and it becomes much more difficult to understand what the algo. is.) The draft states that "the PCE provides the list of shortest paths (with their corresponding ERO (potentially partial ERO) + Path-cost) from _every_ ASBR to the inter-AS TE LSP destination." Suppose the destination is in ASn. PCEn computes a set of shortest paths from _every_ ASBR in ASn to the destination, and passes them back to PCn-1. What does PCn-1 do? My understanding from the draft is that it computes a set of shortest paths between all ASBRs that connect ASn-1 to ASn-2 and those that connect ASn-1 to ASn, and includes the inter-AS links between ASn-1 and ASn in those shortest path computations. My question is: what does PCn-1 send back to PCn-2? Does it, in turn, send PCn-2 the set of all possible paths traversing ASn-1 and ASn or does it concatenate all paths, choose the shortest one, and send back one (the shortest path traversing ASn-1 and ASn)? If the former, then we have a major scalability issue, as the number of paths passed back to successive PCi's will grow, literally exponentially, from AS to AS. If the latter, the scheme may fail to select the shortest path, as I explain below (which is not unexpected). Take the following fig. from the draft (where I have added a link between ASBR3 and ASBR5): <-- AS 1 ---> <------- AS 2 -----><--- AS 3 ----> <---BGP---> <---BGP--> CE1---R0---X1-ASBR1-----ASBR4--R3---ASBR7----ASBR9----R6 |\ \ | / | / | / | | | | \ ASBR2---/ ASBR5 | -- | | | | \ | /----/ | |/ | | | R1-R2---ASBR3-----ASBR6--R4---ASBR8----ASBR10----R7---CE2 We will use the mechanisms specified in Sec. 6 of draft-vasseur, and assume for this part of the discussion that the objective is to the shortest path between R0 and R7. As before, ASBR1, ASBR4, and ASBR9 are the PCEs for AS's 1, 2, and 3, respectively. The request propagates from R0 to the PCE's, to ASBR1 on to ASBR4 on to ASBR9, as before. 1. ASBR9 computes two paths: ASBR9-R6-R7 Cost = 10, say ASBR10-R7 Cost = 20, say (per some metric) 2. It passes these back to ASBR4, which in turn calculates that the possibilities to traverse AS2 are: ASBR4-R3-ASBR7-ASBR9, Cost = 30 ASBR5-R3-ASBR7-ASBR9, Cost = 40 ASBR6-R4-ASBR8-ASBR10, Cost = 30 (Assume all other permutations have higher cost.) 3. Using the concatenation approach mentioned in the draft, it computes that the shortest paths traversing ASs 2 and 3 is, therefore, ASBR4-R3-ASBR7 -- ASBR9-R6-R7, total cost = 40 4. It passes this back to ASBR1, which in turn calculates that the possibilities to traverse AS1 to reach ASBR4 are: R0-X1-ASBR1-ASBR4, Cost = 50 R0-X1-ASBR2-ASBR4, Cost = 60 (There are other permutations, but assume their cost is higher.) Also, assume that the path from R01 to ASBR5, R0-R2-ASBR3-ASBR5 has cost = 30. 5. Again, using concatenation, ASBR1 calculates that the "shortest path" is R0-X1-ASBR1 -- ASBR4-R3-ASBR7 -- ASBR9-R6-R7, total cost = 90 <---------------> <-------------> <-----> 50 30 10 However, there was a shorter path R0-R2-ASBR3 -- ASBR5-R3-ASBR7 -- ASBR9-R6-R7, total cost = 80 <--------------> <--------------> <-----> 30 40 10 which could not get picked in this case. For this, it would have to be that all possible paths are propagated back to PC1, which then selects the shortest one among them, but this, it seems to me, would be an operational and computational nightmare. Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 29 Apr 2004 21:32:34 +0000 Date: Thu, 29 Apr 2004 14:31:54 -0700 (PDT) From: Arthi Ayyangar To: Vishal Sharma cc: CCAMP , Jean-Philippe Vasseur Subject: RE: Sec. 3, item 3 fig. in draft-vassuer-ccamp-inter-area-as Message-ID: <20040429143130.J74567@zircon.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Vishal, > BTW, there are several other figures in the current doc. that > seem to have been distorted in the final text version, so you > all might want to check those as well in the revision. --------> Will do. -arthi > > -----Original Message----- > > From: Arthi Ayyangar [mailto:arthi@juniper.net] > > Sent: Thursday, April 29, 2004 1:59 PM > > To: Vishal Sharma > > Cc: CCAMP; Jean-Philippe Vasseur > > Subject: Re: Sec. 3, item 3 fig. in draft-vassuer-ccamp-inter-area-as > > > > > > Hi Vishal, > > > > Here you go, > > > > > > <-- AS 1 ---> <------- AS 2 -----><--- AS 3 ----> > > > > <---BGP---> <---BGP--> > > CE1---R0---X1-ASBR1-----ASBR4--R3---ASBR7----ASBR9----R6 > > |\ \ | / | / | / | | | > > | \ ASBR2---/ ASBR5 | -- | | | > > | \ | | |/ | | | > > R1-R2---ASBR3-----ASBR6--R4---ASBR8----ASBR10----R7---CE2 > > > > <======= Inter-AS TE LSP(LSR to LSR)===========> > > or > > > > <======== Inter-AS TE LSP (CE to ASBR => > > > > or > > > > <================= Inter-AS TE LSP (CE to CE)===============> > > > > > > > > Thanks, > > -arthi > > > > > Can you please post a clean figure for this item to the list. > > > (Sorry, should have attached the fig. I was referring to.) > > > > > > As it is, the figure is really difficult to understand (or at > > > least I couldn't follow it all). > > > > > > Thanks, > > > -Vishal > > > > > > > > ****************************************************************** > > ********** > > > 3) Example of topology for the inter-AS TE case: > > > > > > We will consider the following general case, built on a superset of the > > > various scenarios defined in [INTER-AS-TE-REQS]: > > > > > > > > > <-- AS 1 ---> <------- AS 2 -----><--- AS 3 ----> > > > > > > <---BGP---> <---BGP--> > > > CE1---R0---X1-ASBR1-----ASBR4-- > > > - > > > - > > > -R3---ASBR7--- > > > - > > > - > > > --ASBR9----R6 > > > |\ \ | / | / | / | | | > > > | \ ASBR2---/ ASBR5 | -- | | | > > > | \ | | |/ | | | > > > R1-R2-- > > > - > > > - > > > --ASBR3-- > > > - > > > - > > > ----ASBR6-- > > > - > > > - > > > -R4---ASBR8-- > > > - > > > - > > > ---ASBR10-- > > > - > > > - > > > --R7---CE2 > > > > > > <======= Inter-AS TE LSP(LSR to LSR)===========> > > > or > > > > > > <======== Inter-AS TE LSP (CE to ASBR => > > > > > > or > > > > > > <================= Inter-AS TE LSP (CE to CE)===============> > > > > > > The diagram above covers all the inter-AS TE deployment cases described > > > in [INTER-AS-TE-REQS]. > > > > > > Vasseur and Ayyangar 8 > > > > > > > > > **************************************************************** > > > Vishal Sharma, Ph.D. > > > Metanoia, Inc. (Critical Systems Thinking) > > > 888 Villa Street, Suite 200B > > > Mountain View, CA 94041-1261 > > > Phone: +1 408-530-8313. Voice: +1 408-394-6321 > > > Email: v.sharma@ieee.org. http://www.metanoia-inc.com > > > **************************************************************** > > > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 29 Apr 2004 21:23:30 +0000 Reply-To: From: "Vishal Sharma" To: "Arthi Ayyangar" Cc: "CCAMP" , "Jean-Philippe Vasseur" Subject: RE: Sec. 3, item 3 fig. in draft-vassuer-ccamp-inter-area-as Date: Thu, 29 Apr 2004 14:06:26 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Arthi, Thanks! BTW, there are several other figures in the current doc. that seem to have been distorted in the final text version, so you all might want to check those as well in the revision. -Vishal > -----Original Message----- > From: Arthi Ayyangar [mailto:arthi@juniper.net] > Sent: Thursday, April 29, 2004 1:59 PM > To: Vishal Sharma > Cc: CCAMP; Jean-Philippe Vasseur > Subject: Re: Sec. 3, item 3 fig. in draft-vassuer-ccamp-inter-area-as > > > Hi Vishal, > > Here you go, > > > <-- AS 1 ---> <------- AS 2 -----><--- AS 3 ----> > > <---BGP---> <---BGP--> > CE1---R0---X1-ASBR1-----ASBR4--R3---ASBR7----ASBR9----R6 > |\ \ | / | / | / | | | > | \ ASBR2---/ ASBR5 | -- | | | > | \ | | |/ | | | > R1-R2---ASBR3-----ASBR6--R4---ASBR8----ASBR10----R7---CE2 > > <======= Inter-AS TE LSP(LSR to LSR)===========> > or > > <======== Inter-AS TE LSP (CE to ASBR => > > or > > <================= Inter-AS TE LSP (CE to CE)===============> > > > > Thanks, > -arthi > > > Can you please post a clean figure for this item to the list. > > (Sorry, should have attached the fig. I was referring to.) > > > > As it is, the figure is really difficult to understand (or at > > least I couldn't follow it all). > > > > Thanks, > > -Vishal > > > > > ****************************************************************** > ********** > > 3) Example of topology for the inter-AS TE case: > > > > We will consider the following general case, built on a superset of the > > various scenarios defined in [INTER-AS-TE-REQS]: > > > > > > <-- AS 1 ---> <------- AS 2 -----><--- AS 3 ----> > > > > <---BGP---> <---BGP--> > > CE1---R0---X1-ASBR1-----ASBR4-- > > - > > - > > -R3---ASBR7--- > > - > > - > > --ASBR9----R6 > > |\ \ | / | / | / | | | > > | \ ASBR2---/ ASBR5 | -- | | | > > | \ | | |/ | | | > > R1-R2-- > > - > > - > > --ASBR3-- > > - > > - > > ----ASBR6-- > > - > > - > > -R4---ASBR8-- > > - > > - > > ---ASBR10-- > > - > > - > > --R7---CE2 > > > > <======= Inter-AS TE LSP(LSR to LSR)===========> > > or > > > > <======== Inter-AS TE LSP (CE to ASBR => > > > > or > > > > <================= Inter-AS TE LSP (CE to CE)===============> > > > > The diagram above covers all the inter-AS TE deployment cases described > > in [INTER-AS-TE-REQS]. > > > > Vasseur and Ayyangar 8 > > > > > > **************************************************************** > > Vishal Sharma, Ph.D. > > Metanoia, Inc. (Critical Systems Thinking) > > 888 Villa Street, Suite 200B > > Mountain View, CA 94041-1261 > > Phone: +1 408-530-8313. Voice: +1 408-394-6321 > > Email: v.sharma@ieee.org. http://www.metanoia-inc.com > > **************************************************************** > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 29 Apr 2004 21:01:00 +0000 Date: Thu, 29 Apr 2004 13:58:46 -0700 (PDT) From: Arthi Ayyangar To: Vishal Sharma cc: CCAMP , Jean-Philippe Vasseur Subject: Re: Sec. 3, item 3 fig. in draft-vassuer-ccamp-inter-area-as Message-ID: <20040429135256.Y74567@zircon.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi Vishal, Here you go, <-- AS 1 ---> <------- AS 2 -----><--- AS 3 ----> <---BGP---> <---BGP--> CE1---R0---X1-ASBR1-----ASBR4--R3---ASBR7----ASBR9----R6 |\ \ | / | / | / | | | | \ ASBR2---/ ASBR5 | -- | | | | \ | | |/ | | | R1-R2---ASBR3-----ASBR6--R4---ASBR8----ASBR10----R7---CE2 <======= Inter-AS TE LSP(LSR to LSR)===========> or <======== Inter-AS TE LSP (CE to ASBR => or <================= Inter-AS TE LSP (CE to CE)===============> Thanks, -arthi > Can you please post a clean figure for this item to the list. > (Sorry, should have attached the fig. I was referring to.) > > As it is, the figure is really difficult to understand (or at > least I couldn't follow it all). > > Thanks, > -Vishal > > **************************************************************************** > 3) Example of topology for the inter-AS TE case: > > We will consider the following general case, built on a superset of the > various scenarios defined in [INTER-AS-TE-REQS]: > > > <-- AS 1 ---> <------- AS 2 -----><--- AS 3 ----> > > <---BGP---> <---BGP--> > CE1---R0---X1-ASBR1-----ASBR4-- > - > - > -R3---ASBR7--- > - > - > --ASBR9----R6 > |\ \ | / | / | / | | | > | \ ASBR2---/ ASBR5 | -- | | | > | \ | | |/ | | | > R1-R2-- > - > - > --ASBR3-- > - > - > ----ASBR6-- > - > - > -R4---ASBR8-- > - > - > ---ASBR10-- > - > - > --R7---CE2 > > <======= Inter-AS TE LSP(LSR to LSR)===========> > or > > <======== Inter-AS TE LSP (CE to ASBR => > > or > > <================= Inter-AS TE LSP (CE to CE)===============> > > The diagram above covers all the inter-AS TE deployment cases described > in [INTER-AS-TE-REQS]. > > Vasseur and Ayyangar 8 > > > **************************************************************** > Vishal Sharma, Ph.D. > Metanoia, Inc. (Critical Systems Thinking) > 888 Villa Street, Suite 200B > Mountain View, CA 94041-1261 > Phone: +1 408-530-8313. Voice: +1 408-394-6321 > Email: v.sharma@ieee.org. http://www.metanoia-inc.com > **************************************************************** > > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 29 Apr 2004 20:03:04 +0000 Reply-To: From: "Vishal Sharma" To: "CCAMP" Cc: "Arthi Ayyangar" , "Jean-Philippe Vasseur" Subject: Sec. 3, item 3 fig. in draft-vassuer-ccamp-inter-area-as Date: Thu, 29 Apr 2004 12:53:38 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit JP, Arthi, Can you please post a clean figure for this item to the list. (Sorry, should have attached the fig. I was referring to.) As it is, the figure is really difficult to understand (or at least I couldn't follow it all). Thanks, -Vishal **************************************************************************** 3) Example of topology for the inter-AS TE case: We will consider the following general case, built on a superset of the various scenarios defined in [INTER-AS-TE-REQS]: <-- AS 1 ---> <------- AS 2 -----><--- AS 3 ----> <---BGP---> <---BGP--> CE1---R0---X1-ASBR1-----ASBR4-- - - -R3---ASBR7--- - - --ASBR9----R6 |\ \ | / | / | / | | | | \ ASBR2---/ ASBR5 | -- | | | | \ | | |/ | | | R1-R2-- - - --ASBR3-- - - ----ASBR6-- - - -R4---ASBR8-- - - ---ASBR10-- - - --R7---CE2 <======= Inter-AS TE LSP(LSR to LSR)===========> or <======== Inter-AS TE LSP (CE to ASBR => or <================= Inter-AS TE LSP (CE to CE)===============> The diagram above covers all the inter-AS TE deployment cases described in [INTER-AS-TE-REQS]. Vasseur and Ayyangar 8 **************************************************************** Vishal Sharma, Ph.D. Metanoia, Inc. (Critical Systems Thinking) 888 Villa Street, Suite 200B Mountain View, CA 94041-1261 Phone: +1 408-530-8313. Voice: +1 408-394-6321 Email: v.sharma@ieee.org. http://www.metanoia-inc.com **************************************************************** Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 29 Apr 2004 19:51:20 +0000 Reply-To: From: "Vishal Sharma" To: "CCAMP" Cc: "Arthi Ayyangar" , "Jean-Philippe Vasseur" Subject: Sec. 3, item 3 fig. in draft-vassuer-ccamp-inter-area-as Date: Thu, 29 Apr 2004 12:48:43 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit JP, Arthi, Can you please post a clean figure for this item to the list. As it is, the figure is really difficult to understand. Thanks, -Vishal Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 29 Apr 2004 18:38:56 +0000 Message-ID: <40914B69.2090506@alcatel.be> Date: Thu, 29 Apr 2004 20:37:29 +0200 From: Dimitri.Papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.5) Gecko/20030925 MIME-Version: 1.0 To: v.sharma@ieee.org Cc: ugo monaco , Fabio Ricciato , ccamp , Zafar Ali Subject: Re: Diverse path failure and optimality in draft-dachille-inter-area-path-protection Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed hi, Vishal Sharma wrote: > Hi Dimitri, > > Thanks for your thoughts. > > However, as Fabio rightly observed, it is very critical that we > distinguish between characteristics that are intrinsic (and common) > to _all_ distributed path computation approaches from those that are > specific to the ARO approach. i don't think i'm saying that the ARO approach should solve all the problems i'm just trying to see the problems that the ARO approach solves and to which extend/conditions > The points you have mentioned below are inherent in _any_ > distributed path computation paradigm (and indeed in any > distributed signaling/resource reservation paradigm), as I explain below, > and are therefore not drawbacks that arise due to particular > mechanisms/methods proposed in the ARO approach. once again, this is not the way these points were raised (they are not saying there are no problems with existing methods) but to which extend the proposed ARO approach enforce them (or avoid them) as last philosophical word i'd like to point the following: it details several principles (but sure we've already cross some of the boundaries this document mentions) that can be useful in re-positioning the whole "optimization" debate thanks, - dimitri. > Comments in-line. > > -Vishal > > >>-----Original Message----- >>From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On >>Behalf Of Dimitri.Papadimitriou@alcatel.be >>Sent: Monday, April 26, 2004 6:47 AM >>To: ugo monaco >>Cc: ccamp; Zafar Ali >>Subject: Re: Diverse path failure and optimality in >>draft-dachille-inter-area-path-protection >> >> >> >>hi, by discussing the proposed method there seems to be three issues >>that make the method questionable in terms of guarantee to deliver what >>it intends to deliver, its usability (the time validity of the path is >>not guaranteed) and its applicability in terms of objective initially >>targeted wrt to the network topology >> >>1) imagine three areas decoupled computation as explained at their >>respective ingress, with ARO method; how the third computation element >>(tail-end) is aware of srlg's that may affect a link selected in the >>head-end area >> >>example: link 1 is selected in area 1 (head-end) with srlg 1, link 2 is >>selected in in area 2 with srlg 2, and link 3 in area 3 (tail-end) with >>srlg 3 and 1 (since the tail end doesn't know that srlg 1 is associated >>to link 1 in addition to its association to link 3 even if it knows that >>the link 1 has been selected for the ARO) the problem is that you can >>not retrieve such kind of error (except but how practical is it if one >>start cumulating all this information between computation points) > > > - First, if we are talking about IGP areas, the problem is a non-issue. > > (They would be under the control > of a single provider, and the provider can reasonably be expected to > assign distinct, globally unique SRLGs to the links in different areas.) > > - If we are talking about AS's, the problem is _universal_, and all > schemes related to restoration have to deal with it. In particular, > _any_ scheme that does distributed path computation has to deal with it. > > So the question is unrelated to the ARO scheme, but a broader one > about how different providers assign SRLG's to resources. > > This is actually a very important issue, but outside the scope of the > ARO document, and not one that I have seen any comprehensive approach to, > yet. > > Perhaps others on the list (carriers?) can comment on it. > > >>2) resource contention, the secondary path may never be established >>since the computation point as *no* capability to make any reservation >>on it (except from the first segment) since by definition "disjoint" - >>it simply becomes a kind of "best effort" secondary path (in the sense >>use it if no other reservation are making use of these links) > > > As Fabio has very nicely explained in > his email, > http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00553.html > > resource contention is a fact of life (read unavoidable) in any distributed > scheme (unless you assume _instantaneous communication_ between the > distributed entities), and is prevalent in every distributed > protocol/mechanism from RSVP-TE to mechanisms for diverse path > computation and setup, such as PCE-based, XRO-based, and, of course, > ARO-based > schemes. > > Not sure why you thought this is specific to the ARO proposal. > > >>3) the method seems to raise additional issues when the number of >>potential entry point for the secondary disjoint path increases, at each >>step of the computation (otherwise the method wouldn't provide what it >>intends to deliver) > > > First, not sure what "additional issues" you are referring to. Can you > provide specifics? > > In any case, every path computation scheme (distributed or otherwise) has to > handle > the case where there are multiple entry points for the secondary (and > primary) paths at a given area/AS. Again, nothing surprising here or > specific > to the ARO scheme in particular. > > When there are many entry points, any scheme has to have a way to select > only one (or some number of them), and any one of several criteria may be > used to make that selection. > > Of course, one can consider then the relative merits of the different > ways of making that selection. > > >> >>ugo monaco wrote: >> >> >>>Dear ccamper, Zafar, Dimitri, >>> >>>as anticipated in the recent email by Vishal we are addressing several >>>important comments collected at Seoul regarding the joint-selection of >>>diverse paths with ARO, i.e. the approach proposed in >>> >> >>>h-protection-00.txt>. >> >>> >>>As Vishal did I summarized your comments to ensure that we rightly >>>understood inputs, and to help people on the ML follow >>>and contribute to the discussion. >>>Comments from others who have feedback are welcome, and >>>much appreciated. >>> >>>Please let me know if you had any additional comments >>>as well. We will take these into account in providing our >>>responses, and, later, in updating the document. >>> >>> >>> >>>Thanks again for your feedback on our draft during the Seoul meeting. >>>Best Regards. >>> >>>Ugo Monaco >>> >>> >>> >> >>++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >>+++++++++++++++++++++++++ >> >>> >>> >>>Zafar's questions: >>> >>>i) What happens when the setup of the diverse path fails, or there is a >>>failure on it after it has been set up? >>> >>>ii) Relationship of this scheme to PCS/PCE approach of JP? >>> >>> >>>Dimitri Papadimitriou >>> >>>i) Your question was about why we are trying for optimality >> >>with a joint >> >>>path selection scheme, when it is not possible, especially as >> >>the number >> >>>of AS's or areas along a path increase, to achieve the *global* optimum. >>>Your other comment was that we should mention this somewhere in the >>>document. >>> >>>Please note that in response to this last question Fabio >> >>Ricciato listed >> >>>many >>>advantages of a joint computation (with ARO) of inter-area/AS >> >>paths in a >> >>>prevoius email posted on the ML "About optimality of inter-AS parallel >>>computation in draft-dachille-inter-area-path-protection". >>>We hope that Fabio rightly addressed your input and we will appreciate >>>further comments and notes. >>> >>> >>> >>> >> >>-- >>Papadimitriou Dimitri >>E-mail : dimitri.papadimitriou@alcatel.be >>E-mail : dpapadimitriou@psg.com >>Webpage: http://psg.com/~dpapadimitriou/ >>Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium >>Phone : +32 3 240-8491 >> >> >> > > > -- Papadimitriou Dimitri E-mail : dimitri.papadimitriou@alcatel.be E-mail : dpapadimitriou@psg.com Webpage: http://psg.com/~dpapadimitriou/ Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium Phone : +32 3 240-8491 Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 29 Apr 2004 18:05:41 +0000 Message-ID: <40914396.1060306@alcatel.be> Date: Thu, 29 Apr 2004 20:04:06 +0200 From: Dimitri.Papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.5) Gecko/20030925 MIME-Version: 1.0 To: ricciato Cc: ugo monaco , ccamp , Zafar Ali Subject: Re: Diverse path failure and optimality in draft-dachille-inter-area-path-protection Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: base64 aGkgLSBzZWUgaW4tbGluZQ0KDQpyaWNjaWF0byB3cm90ZToNCg0KPiBIaSBEaW1pdHJpLA0KPiAN Cj4gdGhhbmtzIGZvciB5b3VyIGNvbW1lbnRzLCBzZWUgaW5saW5lLg0KPiANCj4gY2lhbw0KPiBG YWJpbw0KPiANCj4gRGltaXRyaS5QYXBhZGltaXRyaW91QGFsY2F0ZWwuYmUgd3JvdGU6DQo+IA0K Pj4NCj4+IGhpLCBieSBkaXNjdXNzaW5nIHRoZSBwcm9wb3NlZCBtZXRob2QgdGhlcmUgc2VlbXMg dG8gYmUgdGhyZWUgaXNzdWVzIA0KPj4gdGhhdCBtYWtlIHRoZSBtZXRob2QgcXVlc3Rpb25hYmxl IGluIHRlcm1zIG9mIGd1YXJhbnRlZSB0byBkZWxpdmVyIA0KPj4gd2hhdCBpdCBpbnRlbmRzIHRv IGRlbGl2ZXIsIGl0cyB1c2FiaWxpdHkgKHRoZSB0aW1lIHZhbGlkaXR5IG9mIHRoZSANCj4+IHBh dGggaXMgbm90IGd1YXJhbnRlZWQpIGFuZCBpdHMgYXBwbGljYWJpbGl0eSBpbiB0ZXJtcyBvZiBv YmplY3RpdmUgDQo+PiBpbml0aWFsbHkgdGFyZ2V0ZWQgd3J0IHRvIHRoZSBuZXR3b3JrIHRvcG9s b2d5DQo+Pg0KPj4gMSkgaW1hZ2luZSB0aHJlZSBhcmVhcyBkZWNvdXBsZWQgY29tcHV0YXRpb24g YXMgZXhwbGFpbmVkIGF0IHRoZWlyDQo+PiByZXNwZWN0aXZlIGluZ3Jlc3MsIHdpdGggQVJPIG1l dGhvZDsgaG93IHRoZSB0aGlyZCBjb21wdXRhdGlvbiBlbGVtZW50DQo+PiAodGFpbC1lbmQpIGlz IGF3YXJlIG9mIHNybGcncyB0aGF0IG1heSBhZmZlY3QgYSBsaW5rIHNlbGVjdGVkIGluIHRoZQ0K Pj4gaGVhZC1lbmQgYXJlYQ0KPj4NCj4+IGV4YW1wbGU6IGxpbmsgMSBpcyBzZWxlY3RlZCBpbiBh cmVhIDEgKGhlYWQtZW5kKSB3aXRoIHNybGcgMSwgbGluayAyIGlzDQo+PiBzZWxlY3RlZCBpbiBp biBhcmVhIDIgd2l0aCBzcmxnIDIsIGFuZCBsaW5rIDMgaW4gYXJlYSAzICh0YWlsLWVuZCkgd2l0 aA0KPj4gc3JsZyAzIGFuZCAxIChzaW5jZSB0aGUgdGFpbCBlbmQgZG9lc24ndCBrbm93IHRoYXQg c3JsZyAxIGlzIGFzc29jaWF0ZWQNCj4+IHRvIGxpbmsgMSBpbiBhZGRpdGlvbiB0byBpdHMgYXNz b2NpYXRpb24gdG8gbGluayAzIGV2ZW4gaWYgaXQga25vd3MgdGhhdA0KPj4gdGhlIGxpbmsgMSBo YXMgYmVlbiBzZWxlY3RlZCBmb3IgdGhlIEFSTykgdGhlIHByb2JsZW0gaXMgdGhhdCB5b3UgY2Fu DQo+PiBub3QgcmV0cmlldmUgc3VjaCBraW5kIG9mIGVycm9yIChleGNlcHQgYnV0IGhvdyBwcmFj dGljYWwgaXMgaXQgaWYgb25lDQo+PiBzdGFydCBjdW11bGF0aW5nIGFsbCB0aGlzIGluZm9ybWF0 aW9uIGJldHdlZW4gY29tcHV0YXRpb24gcG9pbnRzKQ0KPiANCj4gWW91tHJlIHJpc2luZyB0aGlz IHByb2JsZW0gd2l0aCBTUkxHcyBzcGFubmluZyBub24tYWRqYWNlbnQgYXJlYXMuDQoNCnllcywg YmVjYXVzZSBpdCdzIGFub3RoZXIgZmxhdm91ciBvZiB0aGUgdHJhcCBwcm9ibGVtICh0aGUgcHJv cG9zYWwgDQpzb2x2ZXMgdGhlIHNpbmdsZSBhcmVhIHRyYXAgaXNzdWUgYW5kIG5vdCB0aGUgbXVs dGktYXJlYSBvbmUgYW5kIGl0IGlzIA0Kbm90IGEgY3JpdGljaXNtIGJ1dCBhIHdheSB0byBkZXRl cm1pbmUgdGhlIGV4YWN0IGNvdmVyYWdlIG9mIHRoZSBtZXRob2QpDQoNCj4gRmlyc3QsIEkgZG8g bm90IGtub3cgaWYgdGhpcyBpcyBhIGNvbW1vbiBjYXNlIGluIHByYWN0aWNhbCBzY2VuYXJpb3Mu IA0KPiBDYW4gb3RoZXIgY2NhbXBlcnMgY29tbWVudCBvbiB0aGF0ID8NCj4gDQo+IFNlY29uZCwg SU1ITyB0aGlzIGNhc2UgaXMgaGFyZCB0byBoYW5kbGUgZm9yIF9hbnlfIGRpc3RyaWJ1dGVkIHNj aGVtZSwgDQo+IGluIGxhY2sgb2YgYW55IGV4Y2hhbmdlIG9mIGluZm8gYmV0d2VlbiBjb21wdXRh dGlvbiBwb2ludHMgYWJvdXQgc3JsZyANCj4gc3Bhbm5pbmcgbXVsdGlwbGUgYXJlYS4NCg0KYW55 IHNpZ25hbGluZyB0aGF0IGNhcnJpZXMgc3JsZyBleHBsaWNpdCBpbmZvcm1hdGlvbiBpcyByYXRo ZXIgDQppbXByYWN0aWNhbCBhbmQgaSBkb24ndCB0aGluayB0aGVyZSBpcyBjdXJyZW50bHkgYW5v dGhlciB3YXkgdG8gc29sdmUgDQp0aGlzIGlzc3VlIChpbiBhIGRpc3RyaWJ1dGVkIHdheSkgb3Ro ZXIgdGhhbiBwZXJmb3JtaW5nIGxvb2t1cHMgZnJvbSB0aGUgDQpsaW5rX2lkJ3Mgb24gbG9jYWxs eSBhdmFpbGFibGUgaW5mb3JtYXRpb24gYmFzZXMNCg0KPiBGb3IgaW5zdGFuY2UsIEm0bSB3b25k ZXJpbmcgaWYgdGhlIHNlcXVlbnRpYWwgY29tcHV0YXRpb24gd2l0aCBSUk8rWFJPIA0KPiAoYXMg YWx0ZXJuYXR2ZSB0byBwYXJhbGxlbCBjb21wdXRhdGlvbiB3aXRoIEFSTykgY2FuIGhhbmRsZSB0 aGlzIA0KPiBzY2VuYXJpbywgb3Igbm90Lg0KPiBDb3VsZCB5b3UgY29tbWVudCBvbiB0aGF0ID8N Cg0Kc2VlIGFib3ZlIC0gaW4gYnJpZWYgaXMgdG8ga25vdyB3aGF0IHRoZSBwcm9wb3NhbCBjYW4g Y292ZXIgYW5kIGRvZXMgbm90IA0KY292ZXIgYW5kIGluIHRoZSBsYXR0ZXIgY2FzZSB3aGV0aGVy IGl0IGlzIGNhcGFibGUgdG8gZGV0ZWN0IGl0DQoNCj4+IDIpIHJlc291cmNlIGNvbnRlbnRpb24s IHRoZSBzZWNvbmRhcnkgcGF0aCBtYXkgbmV2ZXIgYmUgZXN0YWJsaXNoZWQNCj4+IHNpbmNlIHRo ZSBjb21wdXRhdGlvbiBwb2ludCBhcyAqbm8qIGNhcGFiaWxpdHkgdG8gbWFrZSBhbnkgcmVzZXJ2 YXRpb24NCj4+IG9uIGl0IChleGNlcHQgZnJvbSB0aGUgZmlyc3Qgc2VnbWVudCkgc2luY2UgYnkg ZGVmaW5pdGlvbiAiZGlzam9pbnQiIC0NCj4+IGl0IHNpbXBseSBiZWNvbWVzIGEga2luZCBvZiAi YmVzdCBlZmZvcnQiIHNlY29uZGFyeSBwYXRoIChpbiB0aGUgc2Vuc2UNCj4+IHVzZSBpdCBpZiBu byBvdGhlciByZXNlcnZhdGlvbiBhcmUgbWFraW5nIHVzZSBvZiB0aGVzZSBsaW5rcykNCj4gDQo+ IEluIHRoZSBwYXJhbGxlbCBhcHByb2FjaCB3aXRoIEFSTywgZHVyaW5nIHRoZSBmaXJzdCBwaGFz ZSB0aGUgcHJpbWFyeSANCj4gTFNQIGlzIGVzdGFibGlzZWhlZCAoaW5jbHVkaW5nIGJ3IHJlc2Vy dmF0aW9uKSwgd2hpbGUgZm9yIHRoZSAgc2Vjb25kYXJ5IA0KPiBvbmx5IHRoZSBwYXRoIGlzIGNv bXB1dGVkLg0KPiBUaGlzIGNvbXB1dGF0aW9uIGlzIGJhc2Ugb24gdGhlIHRvcG9sb2d5IC8gbG9h ZCBpbmZvcm1hdGlvbiBhdmFpbGFibGUgYXQgDQo+IHRoZSBjb21wdXRhdGlvbiBwb2ludCwgc28g dGhhdCBsaW5rIHdpdGhvdXQgZW5vdWdoIGJ3IGFyZSBwaW5uZWQgb3V0IGFuZCANCj4gY2FuIG5v dCBiZSBpbmNsdWRlZCBpbiB0aGUgcHJpbWFyeSBub3IgdGhlIHNlY29uZGFyeSBMU1AuDQo+IElu IGEgc3VjY2Vzc2l2ZSBwaGFzZSwgIHRoZSBzZWNvbmRhcnkgTFNQIGlzIHJlc2VydmVkIGFsb25n IHRoZSANCj4gc2Vjb25kYXJ5IHBhdGguDQoNCnllcywgaXQgaXMgYSBwYXJhbGxlbCBtdWx0aS1o b3AgY29tcHV0YXRpb24gd2l0aCBhIHNlcXVlbnRpYWwgc2lnbmFsaW5nIA0KKGkgZG9uJ3QgaGF2 ZSBhbnkgZG91YnQgYWJvdXQgdGhpcykNCg0KPiBXaGF0IGNhbiBoYXBwZW4gaXMgYSByYWNlIGNv bmRpdGlvbiwgd2hlcmUgdGhlIGJ3IGFsb25nIHRoZSBzZWNvbmRhcnkgaXMgDQo+IGF2YWlsYWJs ZSBkdXJpbmcgdGhlIDFzdCBwaGFzZSwgYnV0IG5vdCBkdXJpbmcgdGhlIDJuZCBwaGFzZSwgc2lu Y2Ugc29tZSANCj4gb3RoZXIgcmVzZXJ2YXRpb24gb2NjdXJyZWQgIGluIGJldHdlZW4gdGhlIHR3 byBhbG9uZyBzb21lIHNlY29uZGFyeSBsaW5rLg0KPiBJZiB0aGlzIG9jY3VyciwgdGhlIHNlY29u ZGFyeSBwYXRoIGNhbiBub3QgYmUgZXN0YWJsaXNoZWQsIGFuZCBtYXliZSBhbGwgDQo+IHRoZSBz aWduYWxpbmcgcHJvY2VkdXJlIGhhcyB0byBiZSByZXBlYXRlZCwgZm9yIHByaW1hcnkgZm9yIHNl Y29uZGFyeS4gDQo+IChidHcsIGxldCBtZSBleHBhbmQgaW4gYSBzZXBhcmF0ZSBtYWlsIHRoZSBk aXNjdXNzaW9uIGFib3V0IHRoZSBjYXNlIG9mIA0KPiB1bnN1Y2Nlc2Z1bCBjb21wdXRhdGlvbiwg d2hpY2ggd2FzIGFsc28gcmFpc2VkIGJ5IG90aGVycyApDQoNCm9rIC0NCg0KPiBGaXJzdCwgSSBy ZW1hcmsgdGhhdCB0aGlzIHRpbWUgd2luZG93IGluIHdoaWNoIHRoZSByYWNlIGNhbiBvY2N1cnIg aXMgDQo+IHJlYWxseSBzaG9ydCwgaW4gdGhlIG9yZGVyIG9mIG9uZSBQQVRIL1JFU1Ygcm91bmQg dHJpcCB0aW1lLCBhbmQgc2luY2UgDQo+IGhvcGVmdWxseSB5b3W0cmUgbm90IGdvaW5nIHRvIG9w ZXJhdGUgeW91ciBuZXR3b3JrIGF0IGl0tHMgY2FwYWNpdHkgDQo+IGxpbWl0LCB0aGUgcHJvYmFi aWxpdHkgb2YgZmFpbGluZyBzaWduYWxpbmcgZHVlIHRvIGEgcmFjZSBzaG91bGQgYmUgDQo+IHJl YWxseSBzbWFsbC4NCg0KYXQgbGVhc3QgdGhpcyByYWlzZXMgdGhlIGlzc3VlIG9mIGFwcGxpY2Fi aWxpdHkgKHRoaXMgd2lsbCBiZSBncmVhdGx5IA0KZGVwZW5kaW5nIG9uIHRoZSBhcnJpdmFsIHRp bWUsIHRoZSBhbW91bnQgb2YgdW5yZXNlcnZlZCBiYW5kd2lkdGggYW5kIA0KdGhlIChkaXZlcnNl KSBjb25uZWN0aXZpdHkgZGVncmVlIG9mIGVhY2ggYWJyKQ0KDQo+IFNlY29uZCwgSSB0aGluayB0 aGF0IHJhY2VzIGFyZSBhIHdlbGwta25vd24gIHByb2JsZW0gY29tbW9uIHRvICAgX2FsbF8gIA0K PiBkaXN0cmlidXRlZCBjb21wdXRhdGlvbi9yZXNlcnZhdGlvbiBzY2hlbWVzLCBpLmUuIG5vdCBz cGVjaWZpYyB0byANCj4gcGFyYWxsZWwgY29tcHV0YXRpb24gd2l0aCBBUk8NCj4gKGluY2lkZW50 YWxseSwgSSBub3RlIHRoYXQgUlNWUCBpdHNlbGYgaXMgcHJvbmUgdG8gcmFjZSBzaW5jZSB0aGUg cGF0aCANCj4gY29tcHV0YXRpb24gb2NjdXJzcyBpbiB0aGUgZG93bnN0cmVhbSBQQVRIIG1lc3Nh Z2VzLCB3aGlsZSB0aGUgYncgDQo+IHJlc2VydmF0aW9uIGlzIGFwcGxpZWQgZHVyaW5nIHRoZSB1 cHN0cmVhbSBSRVNWIG1lc3NhZ2VzKS4NCg0KYnV0IGl0IGJlY29tZXMgbW9yZSBwcm9ibGVtYXRp YyBzaW5jZSB0aGUgY29tcHV0YXRpb24gaGFzIG5vIGNvbnRyb2wgYXQNCmFsbCBvdmVyIHRoZSAi ZGl2ZXJzZSBzZWdtZW50IiBpdCBoYXMgY29tcHV0ZWQgKGF0IHRoZSBlbmQgdGhlIGlzc3VlIGlz DQp0byBtYWtlIHRoZSBzY2hlbWUgd29ya2luZyBpdCBpbXBvc2VzIG9wZXJhdGlvbmFsIHByb2Nl ZHVyZXMpIHRoaXMgZG9lcyANCm5vdCBtZWFuIHRoYXQgb3RoZXIgbWVjaGFuaXNtcyAoZXhpc3Rp bmcgYW5kIHRvIGNvbWUgaGF2ZSBmdWxsIGNvbnRyb2wpDQoNCj4+IDMpIHRoZSBtZXRob2Qgc2Vl bXMgdG8gcmFpc2UgYWRkaXRpb25hbCBpc3N1ZXMgd2hlbiB0aGUgbnVtYmVyIG9mIA0KPj4gcG90 ZW50aWFsIGVudHJ5IHBvaW50IGZvciB0aGUgc2Vjb25kYXJ5IGRpc2pvaW50IHBhdGggaW5jcmVh c2VzLCBhdCANCj4+IGVhY2ggc3RlcCBvZiB0aGUgY29tcHV0YXRpb24gKG90aGVyd2lzZSB0aGUg bWV0aG9kIHdvdWxkbid0IHByb3ZpZGUgDQo+PiB3aGF0IGl0IGludGVuZHMgdG8gZGVsaXZlcikN Cj4gIA0KPiBJdCBpcyBub3QgY2xlYXIgdG8gbWUgd2hhdCBhcmUgZXhhY3RseSB0aGVzZSBhZGRp dGlvbmFsIGlzc3VlcywgbWF5YmUgDQo+IHlvdbRkIGxpa2UgdG8gcHJvdmlkZSBzb21lIG1vcmUg Y29uY3JldGUgZXhhbXBsZS4NCg0KaWYgYXQgZWFjaCBjb21wdXRhdGlvbiBwb2ludCB0aGUgbnVt YmVyIG9mIGFsdGVybmF0aXZlcyBpbmNyZWFzZXMsIGkNCmhhdmUgc29tZSBkaWZmaWN1bHRpZXMg dG8gdW5kZXJzdGFuZCBob3cgdGhpcyBtZWNoYW5pc20gd29ya3MsIGVpdGhlcg0KcHJ1bmluZyBv ZiB0aGVzZSBhbHRlcm5hdGl2ZXMgaXMgcGVyZm9ybWVkIChzbyBnbG9iYWwgb3B0aW1hbGl0eSBj YW4NCm5ldmVyIGJlIGFjaGlldmVkKSBvciB5b3UncmUgZ29pbmcgdG8gbWFpbnRhaW4gYW5kIGV4 dGVuZCB0aGVtIHVudGlsDQpyZWFjaGluZyB0aGUgZW5kLXBvaW50IChpcyB0aGF0IHJlYWxseSBm ZWFzaWJsZSA/KQ0KDQo+IEluIGdlbmVyYWwsICBteSBmZWVsaW5nIGlzLCBhZ2FpbiwgdGhhdCBz dWNoIGlzc3VlIG1pZ2h0IGJlIG5vbi1zcGVjaWZpYyANCj4gdG8gdGhlIHBhcmFsbGVsIGNvbXB1 dGF0aW9uIHNjaGVtZSwgYnV0IHJhdGhlciBjb21tb24gdG8gYW55IGRzdHJpYnV0ZWQgDQo+IHNj aGVtZS4NCg0Kd291bGQgaXQgYmUgcG9zc2libGUgdG8gdGVsbCB1cyBpbnN0ZWFkIHdoaWNoIGFy ZSB0aGUgY29uZGl0aW9ucyBpbg0Kd2hpY2ggdGhlIHNjaGVtZSB3b3JrcyByYXRoZXIgdGhhbiBy YWlzaW5nIHRoZSBmbGFnIG9mICJub24tc3BlY2lmaWMgdG8NCnRoZSBwYXJhbGxlbCBjb21wdXRh dGlvbiBzY2hlbWUgYnV0IGNvbW1vbiB0byBhbnkgZGlzdHJpYnV0ZWQgc2NoZW1lIg0Kc2luY2Ug YWZhaWsgdGhpcyBzY2hlbWUgaXMgYWxzbyBkaXN0cmlidXRlZA0KDQo+IEhvd2V2ZXIsIHRoZXJl IHdhcyBhIHBvaW50IHJhaXNlZCBieSBBZHJpYW4gdGhhdCBtaWdodCBoYXZlIHNvbWUgDQo+IHJl bGF0aW9uc2hpcCB0byB0aGUgY2hvaWNlIG9mIHRoZSBlbnRyeS1wb2ludCBmb3IgdGhlIHNlY29u ZGFyeSBwYXRoLg0KPiBJZiB0aGlzIGlzIHRoZSBjYXNlLCB5b3UgbWlnaHQgZmluZCBzb21lICBp bnRlcmVzdGluZyBoaW50cyBpbiBteSANCj4gcHJldmlvdXMgbWFpbCAocG9zdGVkIE1vbiwgMTkg QXByIDIwMDQsIA0KPiBodHRwOi8vb3BzLmlldGYub3JnL2xpc3RzL2NjYW1wL2NjYW1wLjIwMDQv bXNnMDA0NzQuaHRtbCAuLi4gc29ycnkgaXS0cyANCj4gc28gbG9uZyA6LSkNCj4gQXMgYSBsYXN0 IGJ1dCBpbXBvcnRhbnQgcmVtYXJrLCBsZXQgbWUgc3VnZ2VzdCB0byBkaXN0bmd1aXNoIHRoZSAN Cj4gcHJvYmxlbXMgdGhhdCBhcmUgaW50cmluc2ljIHRvIF9hbGxfIGRpc3RyaWJ1dGVkIGRpdmVy c2UgcGF0aCANCj4gY29tcHV0YXRpb24gc2NoZW1lcywgZnJvbSB0aG9zZSB0aGF0IGFyZSBzcGVj aWZpYyB0byBvbmUgc2NoZW1lIChlLmcuIA0KPiBwYXJhbGxlbCBjb21wLiB3aXRoIEFSTykuICBC b3RoIGFyZSBpbXBvcnRhbnQgb2YgY291cnNlLCBidXQgaXQgd291bGQgYmUgDQo+IGJlbmVmaWNp YWwgdG8gdGhlIGRpc2N1c3Npb24gdG8gY2xlYXJseSBzZXBhcmF0ZSB0aGVtIGluIGRpZmZlcmVu dCANCj4gdHJhY2tzIGluIHRoZSBtbC4NCg0KdGhlcmUgYXJlIGlzc3VlcyBpbnRyaXNpYyB0byB0 aGUgbWV0aG9kIGFuZCBpc3N1ZXMgdGhhdCBhcHBsaWVzIHRvIA0KZGlzdHJpYnV0ZWQgbWV0aG9k IHRoYXQgYXBwbGllcyBhbHNvIHRvIHRoaXMgbWV0aG9kIGFuZCBpIGFncmVlIHRoYXQgDQp0aGUg cHJvcG9zZWQgbWV0aG9kIHdvbid0IHNvbHZlIHRoZW0gYWxsIC0gYnV0IGl0IGlzIGltaG8gcGFy dCBvZiB0aGUgDQpkaXNjdXNzaW9uIHRvIGV4YWN0bHkga25vdyB3aGF0IHRoZSBtZXRob2QgY292 ZXJzLCBjYW4gcG90ZW50aWFsbHkgY292ZXIgDQphbmQgbm90IGNvdmVyIChhcHBsaWNhYmlsaXR5 KSBpLmUuIHRoZSB3b3JzdCBzaXR1YXRpb24gaXMgd2hlbiB5b3UncmUgDQpub3QgZGV0ZWN0aW5n IGZhbHNlIGV2ZW50IC0NCg0KdGhhbmtzLA0KLSBkaW1pdHJpLg0KDQo+IEm0ZCBzb2xpY2l0IG90 aGVyIGNjYW1wLWVycyBhbHNvIHRvIGNvbW1lbnQgb24gdGhhdC4NCj4gDQo+IA0KDQotLSANClBh cGFkaW1pdHJpb3UgRGltaXRyaQ0KRS1tYWlsIDogZGltaXRyaS5wYXBhZGltaXRyaW91QGFsY2F0 ZWwuYmUNCkUtbWFpbCA6IGRwYXBhZGltaXRyaW91QHBzZy5jb20NCldlYnBhZ2U6IGh0dHA6Ly9w c2cuY29tL35kcGFwYWRpbWl0cmlvdS8NCkFkZHJlc3M6IEZyLiBXZWxsZXNwbGVpbiAxLCBCLTIw MTggQW50d2VycGVuLCBCZWxnaXVtDQpQaG9uZSAgOiArMzIgMyAyNDAtODQ5MQ0KDQoNCg== Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 29 Apr 2004 17:37:36 +0000 Message-Id: <4.3.2.7.2.20040429132816.020cfe88@wells.cisco.com> Date: Thu, 29 Apr 2004 13:33:04 -0400 To: From: Jean Philippe Vasseur Subject: RE: comments on ARO Cc: , , "Fabio Ricciato" , "Ugo Monaco" , "Alessio D'Achille" , "Marco Listanti" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Hi Vishal, Sorry for the burst of comments ... [snip] > > > 3) Re-optimization, crankback, and failure of secondary: > > > > > > I think the scheme works with all of these, and does not really > > > conflict with any of them. > > > > > > With crankback, there should be no problem, whenever a crankback occurs > > > on the primary, the secondary will also be recomputed at the ASBR/ABR > > > to which there is crankback. See my previous email about the set up time issue > > > > > > With re-optimization, there are several options. > > > > > > -- Either default to sequential calculation, and use the XRO to > > re-optimize > > > whichever of the two diverse paths requires re-optimization. But then you may pretty likely fall back to the trapping problem ... > > > (This might be an immediate response, while the below could be > > > a more long-term response.) > > > > > > > Since an ABR on the secondary path only sees a full strict path in > > the ERO, the ABR does not know when there is a better path matching > > the constraints. This is because the ABR does not know the > > constraints. > > > > > -- Or, if the goal really is joint optimization, the provider will have > > > to setup a new set of diverse paths, and use make-before-break to > > > transition the traffic over. Looks to me as the only viable option if: -> You still want to limit the trapping problem, -> You implement any algorithm trying to optimize a set of constraints for both the primary and secondary. Cheers JP. > > > > > > -- If the secondary fails, again there are two options. Either use > > > the XRO to perform another path setup (and, possibly, re-optimize > > > the paths later), or use the joint optimization method above with > > > make-before-break. > > > > > > > This looks ok. > >Great, thanks. We will add this discussion to our revised >draft. > > > > > > 4) Relationship to XRO: > > > As I mentioned in the Seoul presentation and also > > > in our discussion, I think the XRO has many uses -- during computation > > > after crankback, to enable adminstrative routing/re-routing, protection, > > > etc. > > > > > > So I think the ARO and XRO are actually complementary. > > > > > > Regards, > > > -Vishal > > > > > > > -----Original Message----- > > > > From: stefaan.de_cnodder@alcatel.be > > > > [mailto:stefaan.de_cnodder@alcatel.be] > > > > Sent: Monday, April 19, 2004 12:08 PM > > > > To: v.sharma@ieee.org > > > > Cc: ccamp@ops.ietf.org > > > > Subject: comments on ARO > > > > > > > > > > > > > > > > Hi Vishal, > > > > > > > > looking to draft-dachille, I have following comments: > > > > > > > > 1) Second paragraph in section 2 is not clear: "we will assume that > > > > every > > > > inter-area connection is duplicated". I understood from it that when > > > > the > > > > primary path follows Area1-Area2-Area3, then also the secondary has > > > > to > > > > follow this path but using other border nodes. But then from section > > > > 4.2 I > > > > understand that this is not an assumption? > > > > > > > > 2) step 2c on page 5: also E, G and H has to be pruned? It is also > > > > not > > > > clear which path is selected in area 3: I guess it is E-G-H for > > > > primary and > > > > F-H for secondary? > > > > > > > > 3) (!) page 7, about the trap-avoid reference: If fact it is just a > > > > matter > > > > of doing a good path calculation. If the primary is signaled and > > > > border > > > > nodes know that also a secondary has to be established, then it can > > > > make > > > > sure that the primary does not introduce such a trap. This assumes > > > > that the > > > > border node also has to know that a secondary has to be established. > > > > This > > > > is known by the presence of the ARO object but this does not mean > > > > that at > > > > the end, the ARO has to contain a full strict path of the secondary. > > > > Border > > > > nodes can expand the ARO by only including the border nodes for the > > > > secondary. This means that the path calculation of the secondary is > > > > not > > > > anymore 100% bound to the primary. Also I would prefer that the ARO > > > > is more > > > > like a "hint" than the real path. With this, you do not have to > > > > interaction > > > > problems with re-optimization of secondary, crankback, ... For > > > > instance: > > > > when the secondary fails, it can be re-established ignoring the ARO. > > > > Or > > > > when the secondary can be re-optimzed between border nodes, then it > > > > can be > > > > done without impacting the primary or when the global > > > > re-optimization is > > > > possible, then the ARO can be simple ignored. > > > > > > > > I prefer to have the ARO only recording border nodes, and optionally > > > > only > > > > acting as a hint for the ingress LSR. The latter is less important > > > > to me. > > > > > > > > 4) text below figure 3: primary has to be as short as possible. I do > > > > not > > > > care much about the secondary becuase it is almost never used. Also, > > > > the > > > > resources that it reserves can be shared with other secondaries. The > > > > problem here is: what are you optimizing? According to me the path > > > > of the > > > > primary has to be optimized. > > > > > > > > 5) I do not understand why the ARO has to contain Area-Ids to > > > > indicate the > > > > route. If the ingress can put the "area-path" in the ARO, then it > > > > can also > > > > put the border nodes in the ERO of the secondary immediately. I.e. > > > > refering > > > > to figure 5: A knows that the path of the secondary is A1-A2-A5-A6. > > > > How > > > > does A know this? And if it is possible to let A know this > > > > information, > > > > then why could it also not know that the path is B1-B7-B9. If A can > > > > do > > > > this, then there is no need anymore for ARO. So the basic question > > > > is: what > > > > makes it easier for A to know A1-A2-A5-A6 instead of B1-B7-B9. This > > > > means > > > > to me that section 4.2 is not valid and that the ARO assumes that > > > > the > > > > "area-path" of primary and secondary is the same, which is true for > > > > IGP > > > > areas. See also comment 2. Maybe better to remove the AREA-IDs from > > > > the > > > > ARO. > > > > > > > > 6) step 1d page 14, second last line: how does the ABR know that B7 > > > > has to > > > > be used and not B8? > > > > > > > > 7) section 4.3: also describe the L-bit that is in the ERO > > > > subobjects. > > > > > > > > 8) Is the Addr_len in for instance subobject 1 always 32 or can it > > > > be > > > > something else. I agree here that you should re-use ERO subobjects > > > > but I > > > > see that you are doing this. > > > > > > > > 9) Section 4.3.2.3, area_ID: types 3, 4 and 5 are defined but that > > > > conflicts with what is described in the middle of page 19 where the > > > > numbers > > > > are 32, 33, 34. > > > > > > > > 10) the text in section 4.3.3 is rather confusing (the part in the > > > > middle > > > > of page 22, about pruning the nodes). Take figure 5, area 5: If B6 > > > > has to > > > > calculate a path from B6 to B10, then this path can pass via B5, B8, > > > > B7 > > > > and/or B9. This is because border nodes can also act as core nodes > > > > at the > > > > same time. This seems to be excluded from the draft. Is that > > > > correct? > > > > > > > > 11) First refinement in section 5 about the cost of virtual links: > > > > this has > > > > been proposed before in > > > > http://www.watersprings.org/pub/id/draft-venkatachalam-interarea-m > > > >pls-te-02.txt > > > >which is not a good idea: it only works for inter-IGP area and it > > > >decreases > > > >the scalability although it also has some advantages. > > > > > > >12) (!) There are conflicts with re-optimization, crankback, > > > >re-establishement after failure of secondary LSP, ... because in all > > > >of > > > >these cases a working primary LSP also have to be re-signaled which > > > >is not > > > >good. Therefore it is better to let the ARO only record border > > > >nodes, > > > >and/or to use the ARO more as a hint for the secondary: using the > > > >ARO in > > > >the primary makes sure that a trap is avoided, and then it is up to > > > >the > > > >signaling of the secondary to find this path by using crankback, > > > >.... There > > > >is no need that the primary LSP also gives the path, it only has to > > > >make > > > >sure that there is a path. > > > > > > > >13) (!) The method seems not to be applicable for inter-AS > > > >calculations. > > > > > > > >14) Following the classification of methods (ARO, XRO, PCE) that you > > > >described earlier on ccamp based on parallel/sequential and > > > >distributed/centralized computation, ARO looks more an alternative > > > >for PCE than for XRO? In fact, would it be possible to combine > > > >methods? It would be good to explain the interaction (if any) with > > > >these other methods. > > > > > > > >Hope this helps, > > > > > > > >regards, > > > > > > > >Stefaan Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 29 Apr 2004 17:28:28 +0000 Message-Id: <4.3.2.7.2.20040429130446.020cf0e0@wells.cisco.com> Date: Thu, 29 Apr 2004 13:27:22 -0400 To: From: Jean Philippe Vasseur Subject: RE: comments on ARO Cc: , , "Fabio Ricciato" , "Ugo Monaco" , "Alessio D'Achille" , "Marco Listanti" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Hi Vishal, Comments in line, At 09:35 PM 4/28/2004 -0700, Vishal Sharma wrote: >Hi Stefaan, > >Thanks for your follow-on inputs. Few comments in-line. > >We look forward to any additional feedback you have. > >Regards, >-Vishal > > > -----Original Message----- > > From: stefaan.de_cnodder@alcatel.be > > [mailto:stefaan.de_cnodder@alcatel.be] > > Sent: Monday, April 26, 2004 9:26 AM > > To: v.sharma@ieee.org > > Cc: ccamp@ops.ietf.org; Fabio Ricciato; Ugo Monaco; Alessio D'Achille; > > Marco Listanti > > Subject: Re: comments on ARO > > > > > > > > Hi Vishal, > > > > please find some more comments inline... > > > > Vishal Sharma wrote: > > > > > > Hi Stefaan, > > > > > > Thanks a lot for looking over the draft so carefully, and for your > > > many detailed comments. > > > > > > While we will address the individual comments once we've digested > > > them a bit (and in a separate email to avoid making this one > > > too long :-)), let me try to address a couple of the most important > > > points raised in your note below. > > > > > > 1) Recording only border nodes: > > > > > > Actually, if one only recorded border nodes, then upon signaling > > > the secondary, the ingress border node for the secondary has no > > > idea about the intra-area (or intra-AS) path of the primary (in its > > > own area or AS), and therefore cannot ensure that the primary and > > > secondary segments are in fact disjoint. > > > > > > This was a point I discussed with several other people > > > (who initially proposed the same thing), including > > > Arthi and Adrian, but we concluded, for the reason above, that merely > > > recording the border nodes does not work for diversity. As a > > > result, the ARO does, in fact, serve a very useful purpose. > > > > > > We can of course think more about what the trade-offs are, and > > see if there > > > is some way to retain the main advantage of the proposal (diversity, > > > joint optimization of both paths) while also recording less information. > > > > > > > The problem I want to solve here is NOT to reduce the amount of > > information in the ARO, i.e. my purpose is not to reduce its length. > > Rather, by only recording the border nodes you give more freedom > > when signaling the secondary (using the XRO!) meaning that when > > crankback or re-optimization of the secondary is possible, the > > primary does not have to be resignaled to get a new ARO. > >Sure, I understood that the goal wasn't to reduce the length of >the ARO per se, but rather the level of detail that would need to >be recorded in it (regardless of the actual amount of data the ARO >would carry). > >If you recollect the classification of path computation models >I gave in my email to JP >http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00467.html > >we have under distributed computing: i) a parallel path computation >model and ii) a sequential one. >ARO achieves the former, while XRO achieves the latter. > >So, if one did not compute and record the path of the secondary >jointly with the primary (and only recorded the border nodes instead) >the scheme would reduce to a _sequential path computation_, with its >attendant drawbacks (sub-optimality, trap topology, etc.). > >The beauty of the ARO scheme is that it can compute end-to-end >diverse paths using a parallel path computation model (albeit distributed >at each area/AS), with the simplicity of the per-domain approach, and >without any changes to the signaling protocols. Here is one of main concerns that I have about this scheme: by contrast with a distributed PCE-approach, a severe drawback with such a model lies in the potential number of retrials (since it has to be combined with crankback) and consequently the potential set up time. Indeed, you may have diverse paths within a domain, and then a set up failure in the next hop domain requiring to crankback in the previous domain; the number of potential trials may be really non negligible. Moreover, you can still cannot guarantee and an end to end shortest path. >Please note also that this does not say anything about the usefulness of >the XRO (which _is_ a v. useful construct, with several applications, as >pointed out in my earlier email), only that when paths are computed >sequentially these problems arise. > > > > > > 2) With regard to optimizing only the path of the primary, I am not > > > so sure about doing just that. > > > > > > I believe one can get into real problems if one does not constrain > > > the path/cost of the secondary, with unduly long secondaries that > > > will greatly limit the ability to setup further primaries > > > (and secondaries). (This can be especially true of tranport networks, > > > where one would set up very large bandwidth pipes, and optimizing their > > > > placement would be critical.) > > > > > > This scheme is optimizing jointly the cost of the primary and > > > secondary, while ensuring diversity. > > > > > > > My question was *what* is the metric being optimized. For instance > > with sequential computing, the cost of the primary is minimized, > > while the second metric is the cost of the secondary LSP. With > > parallel computing it is different: is the cost being minimized the > > cost of primary + cost of secondary, or is it something else? > >Minimizing the cost of the primary + cost of secondary is one metric >that a parallel path computation scheme may minimize. There might >be others. For e.g. minimize the cost of primary while keeping that >of secondary below a certain threshold, minimize the difference >between the costs of the primary and the secondary, and so on. > >The actual criteria for minimization may be a provider choice, >that is executed/realized by the joint path computation algo. >employed in the network nodes. Right - same comments applies to the distributed PCE-based approach, > > > I think you will find that most providers would be equally concerned > > > with the cost/placement of the secondary path. > > > > > > Moreover, as I emphasized (and as discussed during CCAMP we wiil change > > > the title and our intro. to reflect that), this is a: > > > generic method for computing diverse paths > > > that meets a variety of requirements: load balancing, multipe paths > > > when a single one has insufficient capacity, multiple paths between > > > VoIP gateways, etc. in all of which one would ideally be looking for > > > paths with about equal length. > > > Protection is just _one_ application of this scheme. > > > > > > > This load balancing over multiple paths looks like a good > > application. > >Great, thanks. This is why JL and others have asked us to >not limit our scheme only to restoration applications. > >And we will do this generalization in the update. We mentioned that application indeed in the requirements drafts. JP. > > > 3) Re-optimization, crankback, and failure of secondary: > > > > > > I think the scheme works with all of these, and does not really > > > conflict with any of them. > > > > > > With crankback, there should be no problem, whenever a crankback occurs > > > on the primary, the secondary will also be recomputed at the ASBR/ABR > > > to which there is crankback. > > > > > > With re-optimization, there are several options. > > > > > > -- Either default to sequential calculation, and use the XRO to > > re-optimize > > > whichever of the two diverse paths requires re-optimization. > > > (This might be an immediate response, while the below could be > > > a more long-term response.) > > > > > > > Since an ABR on the secondary path only sees a full strict path in > > the ERO, the ABR does not know when there is a better path matching > > the constraints. This is because the ABR does not know the > > constraints. > > > > > -- Or, if the goal really is joint optimization, the provider will have > > > to setup a new set of diverse paths, and use make-before-break to > > > transition the traffic over. > > > > > > -- If the secondary fails, again there are two options. Either use > > > the XRO to perform another path setup (and, possibly, re-optimize > > > the paths later), or use the joint optimization method above with > > > make-before-break. > > > > > > > This looks ok. > >Great, thanks. We will add this discussion to our revised >draft. > > > > > > 4) Relationship to XRO: > > > As I mentioned in the Seoul presentation and also > > > in our discussion, I think the XRO has many uses -- during computation > > > after crankback, to enable adminstrative routing/re-routing, protection, > > > etc. > > > > > > So I think the ARO and XRO are actually complementary. > > > > > > Regards, > > > -Vishal > > > > > > > -----Original Message----- > > > > From: stefaan.de_cnodder@alcatel.be > > > > [mailto:stefaan.de_cnodder@alcatel.be] > > > > Sent: Monday, April 19, 2004 12:08 PM > > > > To: v.sharma@ieee.org > > > > Cc: ccamp@ops.ietf.org > > > > Subject: comments on ARO > > > > > > > > > > > > > > > > Hi Vishal, > > > > > > > > looking to draft-dachille, I have following comments: > > > > > > > > 1) Second paragraph in section 2 is not clear: "we will assume that > > > > every > > > > inter-area connection is duplicated". I understood from it that when > > > > the > > > > primary path follows Area1-Area2-Area3, then also the secondary has > > > > to > > > > follow this path but using other border nodes. But then from section > > > > 4.2 I > > > > understand that this is not an assumption? > > > > > > > > 2) step 2c on page 5: also E, G and H has to be pruned? It is also > > > > not > > > > clear which path is selected in area 3: I guess it is E-G-H for > > > > primary and > > > > F-H for secondary? > > > > > > > > 3) (!) page 7, about the trap-avoid reference: If fact it is just a > > > > matter > > > > of doing a good path calculation. If the primary is signaled and > > > > border > > > > nodes know that also a secondary has to be established, then it can > > > > make > > > > sure that the primary does not introduce such a trap. This assumes > > > > that the > > > > border node also has to know that a secondary has to be established. > > > > This > > > > is known by the presence of the ARO object but this does not mean > > > > that at > > > > the end, the ARO has to contain a full strict path of the secondary. > > > > Border > > > > nodes can expand the ARO by only including the border nodes for the > > > > secondary. This means that the path calculation of the secondary is > > > > not > > > > anymore 100% bound to the primary. Also I would prefer that the ARO > > > > is more > > > > like a "hint" than the real path. With this, you do not have to > > > > interaction > > > > problems with re-optimization of secondary, crankback, ... For > > > > instance: > > > > when the secondary fails, it can be re-established ignoring the ARO. > > > > Or > > > > when the secondary can be re-optimzed between border nodes, then it > > > > can be > > > > done without impacting the primary or when the global > > > > re-optimization is > > > > possible, then the ARO can be simple ignored. > > > > > > > > I prefer to have the ARO only recording border nodes, and optionally > > > > only > > > > acting as a hint for the ingress LSR. The latter is less important > > > > to me. > > > > > > > > 4) text below figure 3: primary has to be as short as possible. I do > > > > not > > > > care much about the secondary becuase it is almost never used. Also, > > > > the > > > > resources that it reserves can be shared with other secondaries. The > > > > problem here is: what are you optimizing? According to me the path > > > > of the > > > > primary has to be optimized. > > > > > > > > 5) I do not understand why the ARO has to contain Area-Ids to > > > > indicate the > > > > route. If the ingress can put the "area-path" in the ARO, then it > > > > can also > > > > put the border nodes in the ERO of the secondary immediately. I.e. > > > > refering > > > > to figure 5: A knows that the path of the secondary is A1-A2-A5-A6. > > > > How > > > > does A know this? And if it is possible to let A know this > > > > information, > > > > then why could it also not know that the path is B1-B7-B9. If A can > > > > do > > > > this, then there is no need anymore for ARO. So the basic question > > > > is: what > > > > makes it easier for A to know A1-A2-A5-A6 instead of B1-B7-B9. This > > > > means > > > > to me that section 4.2 is not valid and that the ARO assumes that > > > > the > > > > "area-path" of primary and secondary is the same, which is true for > > > > IGP > > > > areas. See also comment 2. Maybe better to remove the AREA-IDs from > > > > the > > > > ARO. > > > > > > > > 6) step 1d page 14, second last line: how does the ABR know that B7 > > > > has to > > > > be used and not B8? > > > > > > > > 7) section 4.3: also describe the L-bit that is in the ERO > > > > subobjects. > > > > > > > > 8) Is the Addr_len in for instance subobject 1 always 32 or can it > > > > be > > > > something else. I agree here that you should re-use ERO subobjects > > > > but I > > > > see that you are doing this. > > > > > > > > 9) Section 4.3.2.3, area_ID: types 3, 4 and 5 are defined but that > > > > conflicts with what is described in the middle of page 19 where the > > > > numbers > > > > are 32, 33, 34. > > > > > > > > 10) the text in section 4.3.3 is rather confusing (the part in the > > > > middle > > > > of page 22, about pruning the nodes). Take figure 5, area 5: If B6 > > > > has to > > > > calculate a path from B6 to B10, then this path can pass via B5, B8, > > > > B7 > > > > and/or B9. This is because border nodes can also act as core nodes > > > > at the > > > > same time. This seems to be excluded from the draft. Is that > > > > correct? > > > > > > > > 11) First refinement in section 5 about the cost of virtual links: > > > > this has > > > > been proposed before in > > > > http://www.watersprings.org/pub/id/draft-venkatachalam-interarea-m > > > >pls-te-02.txt > > > >which is not a good idea: it only works for inter-IGP area and it > > > >decreases > > > >the scalability although it also has some advantages. > > > > > > >12) (!) There are conflicts with re-optimization, crankback, > > > >re-establishement after failure of secondary LSP, ... because in all > > > >of > > > >these cases a working primary LSP also have to be re-signaled which > > > >is not > > > >good. Therefore it is better to let the ARO only record border > > > >nodes, > > > >and/or to use the ARO more as a hint for the secondary: using the > > > >ARO in > > > >the primary makes sure that a trap is avoided, and then it is up to > > > >the > > > >signaling of the secondary to find this path by using crankback, > > > >.... There > > > >is no need that the primary LSP also gives the path, it only has to > > > >make > > > >sure that there is a path. > > > > > > > >13) (!) The method seems not to be applicable for inter-AS > > > >calculations. > > > > > > > >14) Following the classification of methods (ARO, XRO, PCE) that you > > > >described earlier on ccamp based on parallel/sequential and > > > >distributed/centralized computation, ARO looks more an alternative > > > >for PCE than for XRO? In fact, would it be possible to combine > > > >methods? It would be good to explain the interaction (if any) with > > > >these other methods. > > > > > > > >Hope this helps, > > > > > > > >regards, > > > > > > > >Stefaan Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 29 Apr 2004 17:28:20 +0000 Message-Id: <4.3.2.7.2.20040429132151.0601cb98@wells.cisco.com> Date: Thu, 29 Apr 2004 13:24:47 -0400 To: From: Jean Philippe Vasseur Subject: RE: RE : RE : Proposed strategy for Inter-area/AS Cc: "ricciato" , "LE ROUX Jean-Louis FTRD/DAC/LAN" , , Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Hi Vishal, At 01:26 PM 4/26/2004 -0700, Vishal Sharma wrote: >Hi Fabio, JL, et al > >I think Fabio may have a good idea here. It provides the flexibility >of having info. about all affinities, with the scalability of advertizing >only limited information. This problem has been investigated for a while and there many constraints=20 that cannot be aggregated in a simple/efficient manner, leading to the=20 constraint of having to flood a un-reasonable amount of TE-related info to= =20 make it useful enough to compute an optimal (shortest) path with some good= =20 chance of set up success. Cheers JP. >Perhaps we can explore a bit where there might be issues, and refine >this initial solution to get something that we believe is appropriate. > >-Vishal > > > -----Original Message----- > > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On > > Behalf Of ricciato > > Sent: Monday, April 26, 2004 9:59 AM > > To: LE ROUX Jean-Louis FTRD/DAC/LAN > > Cc: adrian@olddog.co.uk; ccamp@ops.ietf.org > > Subject: Re: RE : RE : Proposed strategy for Inter-area/AS > > > > > > Dear JL, > > > > you=B4re right. > > > > Just a quick proposal. > > In an attempt to limit the number of virtual link advertised, > > would it make sense to advertise only K virtual links, where K=3D{number > > of colors}, and for each of them (say j) advertise the maximum > > bandwdith over all links that have color j into their admin_group ? > > > > For example, in your example (with Path 4 added) > > > > Path 1: bw 100M admin group {green;blue} > > Path 2: bw 50M admin group {red; blue} > > Path 3: bw 5M admin group {red;green} > > Path 4: bw 50M admin group {red} > > > > One should advertise > > Virtual Link 1: bw 100M admin group {green} --->max(100M,5M) > > Virtual Link 2: bw 50M admin group {red} --->max(50M,5M,50M) > > Virtual Link 3: bw 100M admin group {gblue} --->max(100M,50M) > > > > > > Assuming that the number of colors << number of possible links, > > this approach might cap the amount of advertisement. > > > > But I=B4m not sure it works ... > > > > ciao > > fabio > > > > LE ROUX Jean-Louis FTRD/DAC/LAN wrote: > > > > >Hi Fabio, > > > > > >Advertising only a subset would improve scalability, but > > >this would not be enough to correclty select the best path. > > > > > >Let's assume that there are three paths from a given ABR X to a > > given destination D > > >Path 1: bw 100M admin group {green;blue} > > >Path 2: bw 50M admin group {red; blue} > > >Path 3: bw 5M admin group {red;green} > > > > > >and a TE-LSP L : Destination D, bw=3D 4M, affinity=3D exlude blue > > > > > >If you advertise only Path 1 and Path 2 as virtual links, ABR X > > will never be selected as next ABR for this TE-LSP, while path 3 > > is a feasible path. > > > > > >Regards > > > > > >JL > > > > > > > > > > > > > > > > > >>-----Message d'origine----- > > >>De : owner-ccamp@ops.ietf.org > > >>[mailto:owner-ccamp@ops.ietf.org] De la part de ricciato > > >>Envoy=E9 : lundi 26 avril 2004 09:48 > > >>=C0 : LE ROUX Jean-Louis FTRD/DAC/LAN > > >>Cc : adrian@olddog.co.uk; ccamp@ops.ietf.org > > >>Objet : Re: RE : Proposed strategy for Inter-area/AS > > >> > > >> > > >>Hi JL, > > >> > > >>just a quick remark: would it make sense in this case to > > >>advertise only > > >>a selected subset of the N virtual links (say the two with > > >>most residual > > >>bw) ? > > >> > > >>ciao > > >>fabio > > >> > > >>LE ROUX Jean-Louis FTRD/DAC/LAN wrote: > > >> > > >> > > >> > > >>>Let's assume that there are N distinct paths from ABR A to a > > >>>destination X, each with a distinct bandwidth and distinct > > >>> > > >>> > > >>admin-group > > >> > > >> > > >>>(a path admin group being expressed as a logical AND of the > > >>> > > >>> > > >>link admin > > >> > > >> > > >>>groups along the path) How can you summarize such topology ? > > >>> > > >>> > > >>Actually > > >> > > >> > > >>>you need to advertise N virtual links, each with a distinct > > >>> > > >>> > > >>admin-group > > >> > > >> > > >>>and available bandwidth. > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> > > >> > > >> > > >> > > > > > > > > > > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 29 Apr 2004 16:21:33 +0000 Message-ID: <40912AC1.94B793FE@alcatel.com> Date: Thu, 29 Apr 2004 12:18:09 -0400 From: Cheng-Yin Lee Reply-To: Cheng-Yin.Lee@alcatel.com MIME-Version: 1.0 To: dachille@coritel.it, listanti@infocom.uniroma1.it, monaco@infocom.uniroma.it, ricciato@coritel.it, v.sharma@ieee.org CC: ccamp Subject: Limitations overcomed by ARO Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Alessio, Marco, Ugo, Fabio, Vishal, As I understand this draft overcomes the following limitations: ".... we propose an alternative approach, based on the joint computation of the two paths in a distributed manner, which overcomes ..." "... two main limitations: - Trapping - Sub-optimal route selection " Could you please confirm if the following can be overcomed using the scheme described (quoted below) in the draft : * Can the path setup for the first LSP (computed by the head-end) lead to trapping in the second area or sub-optimal route selection if the head-end node only has link state information of the first areas * Can an ABR in Area 1 & 2 compute paths to avoid trapping in Area 3 if the ABR in Area 1 & 2 only has link states of these 2 areas? "While the path of the first LSP - that is, the one being installed during the first phase - is included in the ERO, the route of the second LSP - which will be installed in the second phase û will be collected in the ARO during the first phase itself. At the end of the first phase, the ARO collecting the e2e route of the second LSP is returned to the head-end node, which can then install it as an ER-LSP." ? * Can a head-end node in AS1 avoid trapping in the network if the head-end node only knows about link states in AS1 and the virtual links to other ASes? "... can model a multi-AS network. ... JSA minimizes the number of areas that the two LSPs share, and if two area-disjoint paths are present in the network, JSA can compute them;" "Node A computes two disjoint paths between itself and B, within area 1, with a inter-area topological view as shown in Fig. 5b; in this case, node A MUST prune all the border nodes, except one for every area connected to area 1, before the disjoint route selection algorithm is performed; as a result, the two LSPs will not cross the same next area, and will follow the computed inter-area path. Thanks Cheng-Yin Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 29 Apr 2004 10:42:55 +0000 From: "Adrian Farrel" To: ccamp@ops.ietf.org Cc: adrian@olddog.co.uk Reply-To: adrian@olddog.co.uk Subject: Re: Last Call Complete: draft-ietf-ccamp-gmpls-ason-routing-reqts-03.txt Date: Thu, 29 Apr 2004 11:41:39 +0100 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: Ooops, I forgot my own last call comments. Can the team please incorporate my nits and re-publish? Thanks, Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 29 Apr 2004 09:00:13 +0000 From: "Adrian Farrel" To: ccamp@ops.ietf.org Cc: adrian@olddog.co.uk Reply-To: adrian@olddog.co.uk Subject: Last Call Complete: draft-ietf-ccamp-gmpls-ason-routing-reqts-03.txt Date: Thu, 29 Apr 2004 09:59:47 +0100 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: All, Looks like last call is done with just Jerry's comments. No comments were received from the IGP or routing area working groups. Thanks for your thoughts, Jerry. To expand a little upon what Zafar said... > 1. I'm bothered by the statement in Section 3: > "The maximum number of hierarchical RA levels to be supported is > NOT specified (outside the scope)." > Why is it outside the scope, I think there should be some explanation. > Does the number of levels not matter? I think it does matter, however, we need to reflect the requirements as stated by ITU-T SG15 Question 14 in G.7715. We can't play with those requirements. Section 6 of G.7715.1 states... Routing areas contain routing areas that recursively define successive hierarchical routing levels. The number of hierarchical levels to be supported is implementation?specific and outside the scope of this Recommendation. But note (and as some comfort to us) RAs do not necessarily reflect protocol levels (such as IGP areas) but may represent arbitrary subdivisions of protocol levels such as protection domains. > Is one level (i.e., flat network, no hierarchy at all) OK? I believe this is in scope, and acceptbale within the requirements. > I would much prefer to have the maximum number of required hierarchical > levels stated in the draft. You and me too. But SG15 determined that such a limit would be arbitrary from their perspective and so they made it out of scope. > 2. There is quite a bit of discussion about hierarchy evolution, e.g., > in Section 3: > "- The requirements support architectural evolution, e.g. a change in > the number of RA levels, as well as aggregation and segmentation of RAs." > > This begins to suggest automatic 'insertion/deletion' of hierarchical > levels, which I believe is too complex. I don't believe that there intent to describe the mechanism for insertion/ deletion of levels. In particular, as you point out below, protocols are not expected to be automatically adaptive to such changes. The requirement is really that there should be the architectural flexibility. But I do believe that the intent is to allow levels to be inserted without major disruption to other levels (in particular those that are not parents or children). Again, we are simply picking up a requirement which we cannot control. > However, I find in Section 4.4: > "The routing protocol SHOULD be capable of supporting architectural > evolution in terms of number of hierarchical levels of RAs, as well as > aggregation and segmentation of RAs. RA IDs uniqueness within an > administrative domain MAY facilitate these operations. The routing > protocol is not expected to automatically initiate and/or execute these > operations." > > It is the final "not" that says that automatic insertion/deletion is not > required within the protocol. Perhaps this NOT should be capitalized for > emphasis. New addition to RFC2119? :-) > 3. Regarding Adrian's comment on the text I referenced in comment #2: > "The routing protocol is not expected to automatically initiate and/or > execute these operations. Reconfiguration of the RA hierarchy MAY not > ## Surely this is MUST? > disrupt calls in progress, though calls being set up may fail to > complete, and the call setup service may be unavailable during > reconfiguration actions." > > I think this should stay a "MAY". In normal hierarchy reconfiguration, > calls are going to be disrupted. It is far more complex to insist > somehow that the protocol keeps calls in tact during such > reconfigurations. The final version retained "MAY" Hoping that we are closed on this and can move the draft forwards. Thanks, Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 29 Apr 2004 08:02:30 +0000 Reply-To: From: "Vishal Sharma" To: , "ugo monaco" , "Fabio Ricciato" Cc: "ccamp" , "Zafar Ali" Subject: RE: Diverse path failure and optimality in draft-dachille-inter-area-path-protection Date: Thu, 29 Apr 2004 01:01:02 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Dimitri, Thanks for your thoughts. However, as Fabio rightly observed, it is very critical that we distinguish between characteristics that are intrinsic (and common) to _all_ distributed path computation approaches from those that are specific to the ARO approach. The points you have mentioned below are inherent in _any_ distributed path computation paradigm (and indeed in any distributed signaling/resource reservation paradigm), as I explain below, and are therefore not drawbacks that arise due to particular mechanisms/methods proposed in the ARO approach. Comments in-line. -Vishal > -----Original Message----- > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On > Behalf Of Dimitri.Papadimitriou@alcatel.be > Sent: Monday, April 26, 2004 6:47 AM > To: ugo monaco > Cc: ccamp; Zafar Ali > Subject: Re: Diverse path failure and optimality in > draft-dachille-inter-area-path-protection > > > > hi, by discussing the proposed method there seems to be three issues > that make the method questionable in terms of guarantee to deliver what > it intends to deliver, its usability (the time validity of the path is > not guaranteed) and its applicability in terms of objective initially > targeted wrt to the network topology > > 1) imagine three areas decoupled computation as explained at their > respective ingress, with ARO method; how the third computation element > (tail-end) is aware of srlg's that may affect a link selected in the > head-end area > > example: link 1 is selected in area 1 (head-end) with srlg 1, link 2 is > selected in in area 2 with srlg 2, and link 3 in area 3 (tail-end) with > srlg 3 and 1 (since the tail end doesn't know that srlg 1 is associated > to link 1 in addition to its association to link 3 even if it knows that > the link 1 has been selected for the ARO) the problem is that you can > not retrieve such kind of error (except but how practical is it if one > start cumulating all this information between computation points) - First, if we are talking about IGP areas, the problem is a non-issue. (They would be under the control of a single provider, and the provider can reasonably be expected to assign distinct, globally unique SRLGs to the links in different areas.) - If we are talking about AS's, the problem is _universal_, and all schemes related to restoration have to deal with it. In particular, _any_ scheme that does distributed path computation has to deal with it. So the question is unrelated to the ARO scheme, but a broader one about how different providers assign SRLG's to resources. This is actually a very important issue, but outside the scope of the ARO document, and not one that I have seen any comprehensive approach to, yet. Perhaps others on the list (carriers?) can comment on it. > 2) resource contention, the secondary path may never be established > since the computation point as *no* capability to make any reservation > on it (except from the first segment) since by definition "disjoint" - > it simply becomes a kind of "best effort" secondary path (in the sense > use it if no other reservation are making use of these links) As Fabio has very nicely explained in his email, http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00553.html resource contention is a fact of life (read unavoidable) in any distributed scheme (unless you assume _instantaneous communication_ between the distributed entities), and is prevalent in every distributed protocol/mechanism from RSVP-TE to mechanisms for diverse path computation and setup, such as PCE-based, XRO-based, and, of course, ARO-based schemes. Not sure why you thought this is specific to the ARO proposal. > 3) the method seems to raise additional issues when the number of > potential entry point for the secondary disjoint path increases, at each > step of the computation (otherwise the method wouldn't provide what it > intends to deliver) First, not sure what "additional issues" you are referring to. Can you provide specifics? In any case, every path computation scheme (distributed or otherwise) has to handle the case where there are multiple entry points for the secondary (and primary) paths at a given area/AS. Again, nothing surprising here or specific to the ARO scheme in particular. When there are many entry points, any scheme has to have a way to select only one (or some number of them), and any one of several criteria may be used to make that selection. Of course, one can consider then the relative merits of the different ways of making that selection. > > > ugo monaco wrote: > > > Dear ccamper, Zafar, Dimitri, > > > > as anticipated in the recent email by Vishal we are addressing several > > important comments collected at Seoul regarding the joint-selection of > > diverse paths with ARO, i.e. the approach proposed in > > > h-protection-00.txt>. > > > > > > As Vishal did I summarized your comments to ensure that we rightly > > understood inputs, and to help people on the ML follow > > and contribute to the discussion. > > Comments from others who have feedback are welcome, and > > much appreciated. > > > > Please let me know if you had any additional comments > > as well. We will take these into account in providing our > > responses, and, later, in updating the document. > > > > > > > > Thanks again for your feedback on our draft during the Seoul meeting. > > Best Regards. > > > > Ugo Monaco > > > > > > > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > +++++++++++++++++++++++++ > > > > > > > > Zafar's questions: > > > > i) What happens when the setup of the diverse path fails, or there is a > > failure on it after it has been set up? > > > > ii) Relationship of this scheme to PCS/PCE approach of JP? > > > > > > Dimitri Papadimitriou > > > > i) Your question was about why we are trying for optimality > with a joint > > path selection scheme, when it is not possible, especially as > the number > > of AS's or areas along a path increase, to achieve the *global* optimum. > > Your other comment was that we should mention this somewhere in the > > document. > > > > Please note that in response to this last question Fabio > Ricciato listed > > many > > advantages of a joint computation (with ARO) of inter-area/AS > paths in a > > prevoius email posted on the ML "About optimality of inter-AS parallel > > computation in draft-dachille-inter-area-path-protection". > > We hope that Fabio rightly addressed your input and we will appreciate > > further comments and notes. > > > > > > > > > > -- > Papadimitriou Dimitri > E-mail : dimitri.papadimitriou@alcatel.be > E-mail : dpapadimitriou@psg.com > Webpage: http://psg.com/~dpapadimitriou/ > Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium > Phone : +32 3 240-8491 > > > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 29 Apr 2004 06:20:54 +0000 Message-ID: <40909E7C.3060002@coritel.it> Date: Thu, 29 Apr 2004 08:19:40 +0200 From: ricciato User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030821 MIME-Version: 1.0 To: v.sharma@ieee.org CC: stefaan.de_cnodder@alcatel.be, ccamp@ops.ietf.org, Ugo Monaco , Alessio D'Achille , Marco Listanti Subject: Re: comments on ARO Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Hi Stefaan, in addition to Vishal´s comment, just let me quote below a paragraph from my previous mail (http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00473.html, Mon, 19 Apr 2004). I´d appreciate to have you opinion on it. ciao Fabio > 3. The joint-computation with ARO can be applied to a vast class of > problems dealing with path-pair computation. I'm giving below some few > examples. > (I think this also adrresses some comment by Jean-Louis). In general, > in each problem of path-pair computation one can distinguish the > constraint(s) from the optimization objective: > > Case-I: find a pair of disjoint paths (i.e., disjointedness is a > constraint) wich minimize some link metric (hop-length, link-load, etc.) > Case-II: find a pair of maximally disjoint paths (disjointedness > becomes an objective) > Case-III: find a pair of disjoint paths P1 and P2 that minimizes the > difference |d(P1)-d(P2)|, where d() is some metric associated to the > path (e.g., delay....might make sense in optical networks ??). > Case-IV: Assuming that for each link pair (i,j) it is possible to > assign a "correlation" factor r(i,j) accounting for the probability of > contemporary failures, find a pair of paths that minimizes the > max{r(i,j)} over all pairs such that i is in P1 and j is in P2 [see > note 2]. > > Maybe not all the above items are of practical interest in real > applications, but the fact that our approach encompasses all of them > proves the flexibility and usefulness of joint-computation with ARO. > Several other problems can be found. > In general, joint-selection with ARO can address to all problems > presenting some *joint constraints* and/or *joint optimization > objective* on the pair of paths. > > Needless to say, each such case requires ad-hoc route-selection > _algorithms_ to be implemented in the ingress border nodes (or in a > centralized server within each AS), but all can be accommodated with > the signaling procedure based on ARO. > > Admittedly, the current draft version exclusively focused on case-I, > and fails to make it clear that the set of possible applications is > far broader. We will improve this point in the future version. > Incidentally, I notice here that this is indeed the reason why we > proposed the (quite neutral) term "Associated Route Object" instead of > the more specific "Disjoint R.O." or "Backup R.O." etc.: we wanted to > leave it open to a broad set of possible applications. > > Maybe it would make sense to add some additional semantic in the PATH > messages that specify the contraint(s) and/or the objectives to which > the primary (in the ERO) and secondary (in the ARO) paths should > (jointly!) comform. > This might be an associated sub-object of the ARO, perhaps ? > Might be named "Route Pair Requirements" (RPR) ? > In other words, the overall semantic in the PATH messages should sound > like: > "compute a primary route segment (in the ERO), and an associated > secondary route segment (in the ARO), such that they are subject to > the contraint(s) X and optimize objective Y (X,Y are contained somehow > in the RPR)". > > The ERO+ARO+RPR scheme, in the framework of distributed *joint* route > selection, would be really a quite flexible and general scheme. > > What do you think about that ? Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 29 Apr 2004 04:37:33 +0000 Reply-To: From: "Vishal Sharma" To: Cc: , "Fabio Ricciato" , "Ugo Monaco" , "Alessio D'Achille" , "Marco Listanti" Subject: RE: comments on ARO Date: Wed, 28 Apr 2004 21:35:01 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Stefaan, Thanks for your follow-on inputs. Few comments in-line. We look forward to any additional feedback you have. Regards, -Vishal > -----Original Message----- > From: stefaan.de_cnodder@alcatel.be > [mailto:stefaan.de_cnodder@alcatel.be] > Sent: Monday, April 26, 2004 9:26 AM > To: v.sharma@ieee.org > Cc: ccamp@ops.ietf.org; Fabio Ricciato; Ugo Monaco; Alessio D'Achille; > Marco Listanti > Subject: Re: comments on ARO > > > > Hi Vishal, > > please find some more comments inline... > > Vishal Sharma wrote: > > > > Hi Stefaan, > > > > Thanks a lot for looking over the draft so carefully, and for your > > many detailed comments. > > > > While we will address the individual comments once we've digested > > them a bit (and in a separate email to avoid making this one > > too long :-)), let me try to address a couple of the most important > > points raised in your note below. > > > > 1) Recording only border nodes: > > > > Actually, if one only recorded border nodes, then upon signaling > > the secondary, the ingress border node for the secondary has no > > idea about the intra-area (or intra-AS) path of the primary (in its > > own area or AS), and therefore cannot ensure that the primary and > > secondary segments are in fact disjoint. > > > > This was a point I discussed with several other people > > (who initially proposed the same thing), including > > Arthi and Adrian, but we concluded, for the reason above, that merely > > recording the border nodes does not work for diversity. As a > > result, the ARO does, in fact, serve a very useful purpose. > > > > We can of course think more about what the trade-offs are, and > see if there > > is some way to retain the main advantage of the proposal (diversity, > > joint optimization of both paths) while also recording less information. > > > > The problem I want to solve here is NOT to reduce the amount of > information in the ARO, i.e. my purpose is not to reduce its length. > Rather, by only recording the border nodes you give more freedom > when signaling the secondary (using the XRO!) meaning that when > crankback or re-optimization of the secondary is possible, the > primary does not have to be resignaled to get a new ARO. Sure, I understood that the goal wasn't to reduce the length of the ARO per se, but rather the level of detail that would need to be recorded in it (regardless of the actual amount of data the ARO would carry). If you recollect the classification of path computation models I gave in my email to JP http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00467.html we have under distributed computing: i) a parallel path computation model and ii) a sequential one. ARO achieves the former, while XRO achieves the latter. So, if one did not compute and record the path of the secondary jointly with the primary (and only recorded the border nodes instead) the scheme would reduce to a _sequential path computation_, with its attendant drawbacks (sub-optimality, trap topology, etc.). The beauty of the ARO scheme is that it can compute end-to-end diverse paths using a parallel path computation model (albeit distributed at each area/AS), with the simplicity of the per-domain approach, and without any changes to the signaling protocols. Please note also that this does not say anything about the usefulness of the XRO (which _is_ a v. useful construct, with several applications, as pointed out in my earlier email), only that when paths are computed sequentially these problems arise. > > > 2) With regard to optimizing only the path of the primary, I am not > > so sure about doing just that. > > > > I believe one can get into real problems if one does not constrain > > the path/cost of the secondary, with unduly long secondaries that > > will greatly limit the ability to setup further primaries > > (and secondaries). (This can be especially true of tranport networks, > > where one would set up very large bandwidth pipes, and optimizing their > > placement would be critical.) > > > > This scheme is optimizing jointly the cost of the primary and > > secondary, while ensuring diversity. > > > > My question was *what* is the metric being optimized. For instance > with sequential computing, the cost of the primary is minimized, > while the second metric is the cost of the secondary LSP. With > parallel computing it is different: is the cost being minimized the > cost of primary + cost of secondary, or is it something else? Minimizing the cost of the primary + cost of secondary is one metric that a parallel path computation scheme may minimize. There might be others. For e.g. minimize the cost of primary while keeping that of secondary below a certain threshold, minimize the difference between the costs of the primary and the secondary, and so on. The actual criteria for minimization may be a provider choice, that is executed/realized by the joint path computation algo. employed in the network nodes. > > I think you will find that most providers would be equally concerned > > with the cost/placement of the secondary path. > > > > Moreover, as I emphasized (and as discussed during CCAMP we wiil change > > the title and our intro. to reflect that), this is a: > > generic method for computing diverse paths > > that meets a variety of requirements: load balancing, multipe paths > > when a single one has insufficient capacity, multiple paths between > > VoIP gateways, etc. in all of which one would ideally be looking for > > paths with about equal length. > > Protection is just _one_ application of this scheme. > > > > This load balancing over multiple paths looks like a good > application. Great, thanks. This is why JL and others have asked us to not limit our scheme only to restoration applications. And we will do this generalization in the update. > > 3) Re-optimization, crankback, and failure of secondary: > > > > I think the scheme works with all of these, and does not really > > conflict with any of them. > > > > With crankback, there should be no problem, whenever a crankback occurs > > on the primary, the secondary will also be recomputed at the ASBR/ABR > > to which there is crankback. > > > > With re-optimization, there are several options. > > > > -- Either default to sequential calculation, and use the XRO to > re-optimize > > whichever of the two diverse paths requires re-optimization. > > (This might be an immediate response, while the below could be > > a more long-term response.) > > > > Since an ABR on the secondary path only sees a full strict path in > the ERO, the ABR does not know when there is a better path matching > the constraints. This is because the ABR does not know the > constraints. > > > -- Or, if the goal really is joint optimization, the provider will have > > to setup a new set of diverse paths, and use make-before-break to > > transition the traffic over. > > > > -- If the secondary fails, again there are two options. Either use > > the XRO to perform another path setup (and, possibly, re-optimize > > the paths later), or use the joint optimization method above with > > make-before-break. > > > > This looks ok. Great, thanks. We will add this discussion to our revised draft. > > > 4) Relationship to XRO: > > As I mentioned in the Seoul presentation and also > > in our discussion, I think the XRO has many uses -- during computation > > after crankback, to enable adminstrative routing/re-routing, protection, > > etc. > > > > So I think the ARO and XRO are actually complementary. > > > > Regards, > > -Vishal > > > > > -----Original Message----- > > > From: stefaan.de_cnodder@alcatel.be > > > [mailto:stefaan.de_cnodder@alcatel.be] > > > Sent: Monday, April 19, 2004 12:08 PM > > > To: v.sharma@ieee.org > > > Cc: ccamp@ops.ietf.org > > > Subject: comments on ARO > > > > > > > > > > > > Hi Vishal, > > > > > > looking to draft-dachille, I have following comments: > > > > > > 1) Second paragraph in section 2 is not clear: "we will assume that > > > every > > > inter-area connection is duplicated". I understood from it that when > > > the > > > primary path follows Area1-Area2-Area3, then also the secondary has > > > to > > > follow this path but using other border nodes. But then from section > > > 4.2 I > > > understand that this is not an assumption? > > > > > > 2) step 2c on page 5: also E, G and H has to be pruned? It is also > > > not > > > clear which path is selected in area 3: I guess it is E-G-H for > > > primary and > > > F-H for secondary? > > > > > > 3) (!) page 7, about the trap-avoid reference: If fact it is just a > > > matter > > > of doing a good path calculation. If the primary is signaled and > > > border > > > nodes know that also a secondary has to be established, then it can > > > make > > > sure that the primary does not introduce such a trap. This assumes > > > that the > > > border node also has to know that a secondary has to be established. > > > This > > > is known by the presence of the ARO object but this does not mean > > > that at > > > the end, the ARO has to contain a full strict path of the secondary. > > > Border > > > nodes can expand the ARO by only including the border nodes for the > > > secondary. This means that the path calculation of the secondary is > > > not > > > anymore 100% bound to the primary. Also I would prefer that the ARO > > > is more > > > like a "hint" than the real path. With this, you do not have to > > > interaction > > > problems with re-optimization of secondary, crankback, ... For > > > instance: > > > when the secondary fails, it can be re-established ignoring the ARO. > > > Or > > > when the secondary can be re-optimzed between border nodes, then it > > > can be > > > done without impacting the primary or when the global > > > re-optimization is > > > possible, then the ARO can be simple ignored. > > > > > > I prefer to have the ARO only recording border nodes, and optionally > > > only > > > acting as a hint for the ingress LSR. The latter is less important > > > to me. > > > > > > 4) text below figure 3: primary has to be as short as possible. I do > > > not > > > care much about the secondary becuase it is almost never used. Also, > > > the > > > resources that it reserves can be shared with other secondaries. The > > > problem here is: what are you optimizing? According to me the path > > > of the > > > primary has to be optimized. > > > > > > 5) I do not understand why the ARO has to contain Area-Ids to > > > indicate the > > > route. If the ingress can put the "area-path" in the ARO, then it > > > can also > > > put the border nodes in the ERO of the secondary immediately. I.e. > > > refering > > > to figure 5: A knows that the path of the secondary is A1-A2-A5-A6. > > > How > > > does A know this? And if it is possible to let A know this > > > information, > > > then why could it also not know that the path is B1-B7-B9. If A can > > > do > > > this, then there is no need anymore for ARO. So the basic question > > > is: what > > > makes it easier for A to know A1-A2-A5-A6 instead of B1-B7-B9. This > > > means > > > to me that section 4.2 is not valid and that the ARO assumes that > > > the > > > "area-path" of primary and secondary is the same, which is true for > > > IGP > > > areas. See also comment 2. Maybe better to remove the AREA-IDs from > > > the > > > ARO. > > > > > > 6) step 1d page 14, second last line: how does the ABR know that B7 > > > has to > > > be used and not B8? > > > > > > 7) section 4.3: also describe the L-bit that is in the ERO > > > subobjects. > > > > > > 8) Is the Addr_len in for instance subobject 1 always 32 or can it > > > be > > > something else. I agree here that you should re-use ERO subobjects > > > but I > > > see that you are doing this. > > > > > > 9) Section 4.3.2.3, area_ID: types 3, 4 and 5 are defined but that > > > conflicts with what is described in the middle of page 19 where the > > > numbers > > > are 32, 33, 34. > > > > > > 10) the text in section 4.3.3 is rather confusing (the part in the > > > middle > > > of page 22, about pruning the nodes). Take figure 5, area 5: If B6 > > > has to > > > calculate a path from B6 to B10, then this path can pass via B5, B8, > > > B7 > > > and/or B9. This is because border nodes can also act as core nodes > > > at the > > > same time. This seems to be excluded from the draft. Is that > > > correct? > > > > > > 11) First refinement in section 5 about the cost of virtual links: > > > this has > > > been proposed before in > > > http://www.watersprings.org/pub/id/draft-venkatachalam-interarea-m > > >pls-te-02.txt > > >which is not a good idea: it only works for inter-IGP area and it > > >decreases > > >the scalability although it also has some advantages. > > > > >12) (!) There are conflicts with re-optimization, crankback, > > >re-establishement after failure of secondary LSP, ... because in all > > >of > > >these cases a working primary LSP also have to be re-signaled which > > >is not > > >good. Therefore it is better to let the ARO only record border > > >nodes, > > >and/or to use the ARO more as a hint for the secondary: using the > > >ARO in > > >the primary makes sure that a trap is avoided, and then it is up to > > >the > > >signaling of the secondary to find this path by using crankback, > > >.... There > > >is no need that the primary LSP also gives the path, it only has to > > >make > > >sure that there is a path. > > > > > >13) (!) The method seems not to be applicable for inter-AS > > >calculations. > > > > > >14) Following the classification of methods (ARO, XRO, PCE) that you > > >described earlier on ccamp based on parallel/sequential and > > >distributed/centralized computation, ARO looks more an alternative > > >for PCE than for XRO? In fact, would it be possible to combine > > >methods? It would be good to explain the interaction (if any) with > > >these other methods. > > > > > >Hope this helps, > > > > > >regards, > > > > > >Stefaan Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 28 Apr 2004 19:28:52 +0000 Message-Id: <200404281927.PAA10814@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-gmpls-segment-recovery-00.txt Date: Wed, 28 Apr 2004 15:27:49 -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 : GMPLS Based Segment Recovery Author(s) : L. Berger, et al. Filename : draft-ietf-ccamp-gmpls-segment-recovery-00.txt Pages : 24 Date : 2004-4-28 This document describes protocol specific procedures for GMPLS (Generalized Multi-Protocol Label Switching) RSVP-TE (Resource ReserVation Protocol - Traffic Engineering) signaling extensions to support LSP segment protection and restoration. These extensions are intended to be compliment and be consistent with the Extensions for End-to-End GMPLS-based Recovery. Implications and interactions with Fast Reroute are also addressed. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-segment-recovery-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ccamp-gmpls-segment-recovery-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ccamp-gmpls-segment-recovery-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-4-28152903.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-gmpls-segment-recovery-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-gmpls-segment-recovery-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-4-28152903.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 28 Apr 2004 17:09:13 +0000 Message-ID: <408FE4E1.DEDA142@alcatel.be> Date: Wed, 28 Apr 2004 19:07:45 +0200 From: stefaan.de_cnodder@alcatel.be MIME-Version: 1.0 To: Vishal Sharma CC: ccamp@ops.ietf.org Subject: Re: Observations/feedback on draft-decnodder-mpls-interas-protection Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Hi Vishal, Thanks for your comments. You find the answers below. I see that one of the confusing points is about SRLGs where SRLGs can be defined inside the ASs without looking to links in other ASs using the same physical resource (=let call them inconsistent or AS-local SRLGs) or whether the SRGs are defined globaly. I will add a definition of it in the draft. The scope of the draft is just to show how existing mechanisms (XRO in this case) can be used to provide any type of protection to inter-AS LSPs. A problem is that SRLG protection (largest part of the draft since the rest is rather trivial) is not well-defined for intra-AS LSPs, that's why I added a small appendix about this in the draft. regards, Stefaan Vishal Sharma wrote: > > Hi Stefaan, > > As promised at the Seoul IETF, here is my (rather belated!) > feedback on the interas protection draft. > (I am cc'ing it to my co-authors as well, so that we can > minimize duplication of our comments.) > > To make things easier, I have divided my comments into > technical and editorial. > > Regards, > -Vishal > > PS: BTW, thanks for your comments on draft-dachille, will try to > respond to them after having time to review your feedback. > > ******************************************************************* > Technical > --------- > i) Abstract: I think it would be useful to make clear here that the > techniques > in this document apply to links between 2 ASs (or only to inter-AS links). > [Stefaan] Not really. It is about protecting an inter-AS link. However, for the links and nodes inside the AS, the current FRR techniques can be used. A special case is comment xvii about the link preceding the exit ASBR in case of SRLG+node protection. I will make this clearer in the update of the document. > ii) Intro., para 4, "Section 4 ... node protection," would be clearer if > it specified that an e2e path for an LSP _crossing multiple ASs_ can only > provide link or node protection. (Presumably, for LSPs within an AS, where > the SRLG's would be consistent, it should be possible to provide SRLG > protection using e2e protection.) > [Stefaan] ok, also best to add an explanation on what consistent and inconsistent SRLG ids are, better: AS-local and AS-global SRLGs. > iii) Sec. 3, para 1, "For instance, in Figure 2 ... multiple core routers," > it is a bit confusing to have R23 and R24. Which links specifically are > being referred to here? Is it, R21-R24, R21-R25, R25-R24? > [Stefaan] I believe you are looking to figure 1... the text refers to figure 2. I will reword it somewhat. > iv) Title of Sec. 4 might be better as "Problems in SRLG protection with > disjoint > e2e LSPs" > [Stefaan] Ok > v) The document uses "main" and "primary" for the working LSP. It might be > better to have consistently the same term throughout. > [Stefaan] Indeed, I will use the words working and recovery. This terminology is in line with draft-ietf-ccamp-gmpls-recovery-terminology-03.txt > vi) It might be better to add another row of routers in both ASs in Fig. 2, > to make it non-trivial. That way, it will be possible to illustrate that > there are multiple secondary egress AS-BRs, and multiple secondary ingress > AS-BRs, and also that the egress AS-BR has to make a choice of a route > to an appropriately picked secondary egress AS-BR, etc. > [Stefaan] Ok, I will update the figure based on your suggestion. > vii) The way the method is described, especially in Sec. 6, it appears that > the technique applies only to packet LSPs. Is my understanding correct? > [Stefaan] That is correct. At the latest IETF there was a draft describing protection for non-packet LSPs. For non-packet LSPs, bypass tunnels make no sense and apparently for detours they also use another approach. In addition, it is only for ASes, and not for regions in general. > viii) The entire segment in Sec. 6.1.1 para 2, from "In case this condition > ..." > until "... not in the downstream AS (AS2 in Figure 2)," might benefit from > some simplification in the writing. It's a bit difficult to follow, as > written. > [Stefaan] Yes, maybe some more explanation with figures might be good here. Simply stated, if the link between AS1 and AS2 is to be protected, then the detour starts in AS1 and goes to AS2 without going through another AS. > ix) Similary, in the same para, the description of what portion of an RRO > should > be in the ERO for the detour LSP emanating from the egress AS-BR is also > confusing. > It might be restated as > "The ERO for the detour LSP starting at the egress AS-BR contains several > segments. > It must first contain a strict or loose path towards the secondary egress > AS-BR, followed > by a segment of the RRO for the primary LSP. This segment begins at the last > hop in > the downstream AS and contains all hops thereafter up until the > destination." > [Stefaan] Maybe also good to explain this based on the figure part by part. > x) In the same para, it is mentioned that the ERO of the detour LSP consists > of > two segments. However, when elucidating this with a reference to Fig. 2, the > ERO > of the detour LSP is only said to be composed for router R14, R22 and all > routers > thereafter. The segment from R14 to R12 and R12 to R21 is not mentioned. > [Stefaan] Indeed, you are right, I will update the example. > xi) In the draft, in the sentence describing the ERO of the detour LSP, > the last router should probably be R24 instead of R22 (as currently > written). > [Stefaan] There is something wrong with this example. The last node in the downstream AS of the main LSP must be in the ERO of the main to ensure that the detour merges in the downstream AS. > xii) Sec. 6.1.1, para 4, the last sentence could be reworded to make > it a bit clearer. I think it is saying that when the primary and secondary > egress AS-BRs are the same, and the primary and secondary ingress AS-BRs > are the same, and they have multiple links between them, then the detour > LSP must simply use an inter-domain link different than the one used by > the primary LSP, and no path computation is needed at the egress AS-BR. > [Stefaan] Your understanding is correct. I will reword it. > xiii) It would be useful to explain the purpose and structure of the > LSP-Merge > object as well as the operations performed on it, in Sec. 6.1. itself. > Otherwise, the reader sees this object mentioned in the main text, without > having > an idea of what it is. > In any case, since the appendices are quite small, and sort of intergral to > the > subsequent text in the main doc., I think it would be best to pull them into > the > main text. > [Stefaan] I prefer to keep it in the appendix to avoid that people start thinking that my main purpose is to define this RSVP extionsion, which is not the case but in principle I agree with you: forward references are never good but more drafts/RFCs are doing this. Best to add a sentence at the end of 6.1.1 to say what the result will be of using it. > xiv) This will make the description in Sec. 6.1.4 and 6.3.1 easier to > follow. > [Stefaan] see above. > xv) The second last para in Sec. 6.3.1 mentions that the merge point of > the detour and main LSP must ensure that it can switchover traffic from > the incoming detour LSP to its originating detour LSP, since the egress > link at this merge point may belong to the same SRLG as the inter-domain > link that the incoming detour LSP was protecting. > Is this trivial to ensure? It appears that there is a bit of work > that an LSR would have to do to ensure that. No? (Since the normal > procedure would be simply to merge traffic from the detour LSP > on to the main LSP.) > [Stefaan] FRR as currently defined in the FRR-draft assumes only single failure, i.e. no SRLG protection. In this case, only at most 1 detour LSP of a main LSP will be used at a particular time. With SRLG's their is indeed the requirement that multiple detours can be in use at the same time... that's the consequence of SRLGs and indeed, this requires extra functionality. So indeed, your comment is very valid. > xvi) Sec. 6.3.4, the first sentence "If the secondary ... inside these > objects" > is worded in a rather confusing way. In which objects does the sec. ingress > AS-BR add the list of SRLG's of the inter-AS link? > [Stefaan] Wording is indeed not good: list of SRLGs is added to XRO or EXRS. Will correct wording. > xvii) In Sec. 6.3.6. it is not clear why there is a focus on the SRLG > protection > of the link _preceding_ the ingress AS-BR? > [Stefaan] you mean the egress AS-BR I guess. Well normally when node+link protection is desired, then one bypass/detour is used to protect against a failure of the link or node. In case of SRLG+node protection, you would expect the same: one bypass/detour is used to protect against a failure of the SRLG or node. In the special case where the node is an egress AS-BR, then it is not possible anymore to use a single bypass/detour but 2 bypasses/detours have to be used. That is why there is a special focus on the SRLG protection of the link preceding the egress AS-BR + node protection of that egress AS-BR. This applies only when inconsistent SRLG numbering is used between the ASs (or AS-local SRLGs to name it differently). The detour/bypass protecting the SRLG must merge in the same AS, the detour/bypass protecting the node crosses the AS boundary. > xviii) In the same section, the para "To ensure that .... towards the > egress > AS-BR" is unclear, and perhaps needs to be reworded and better explained. > Not sure which link the phrase "... SRLG disjoint with the next link of the > main > LSP computed towards the egress AS-BR" refers? > [Stefaan] Ok, a slight rewording is required here. The "next link" is the link with its SRLGs to be protected, i.e. the link preceding the prim egress AS-BR. > xix)In Sec. 6.3.6, para 4, the phrase "IF only 1 detour LSP ... LSP setup > would fail," is unclear. > [Stefaan] This is a complex one. For detours protecting against SRLGs of the inter-AS link, the detour MUST merge in the downstream AS and MUST NOT cross other ASes when inconsistent SRLG numbering is used. For node (or link) protection, it is not really a MUST, but rather a SHOULD. If the downstream AS is only 1 hop, then for node protection there is not other choice then to let the detour merge in the "downstream-downstream AS", which is not allowed for SRLG. But for SRLG, the detour may merge at the primary ingress AS-BR, but that is then not allowed for node protection. Becuase of these conflicting requirements, it is recommended to use 2 detours: one for SRLG protection and one for node protection. It is hard to understand, but it is correct. Maybe a figure in the draft might help. > xx) Sec. 7, second last para states "We also note ... does not lead to the > failure of the bypass tunnel." I guess it wasn't clear why teh interface > failure > does not cause a failure of the bypass tunnel. > [Stefaan] If the interface fails and this interface was the destination of the bypass, then the destination does not exist anymore in theory, so the bypass could be torn down. However, this is not allowed, otherwise link and bypass would fail at the same time. I believe the text is clear here. > xxi) Appendix B, last sentence, why is the use of the sender-template > specific > detour LSP merely "recommended" as opposed to being "required"? > [Stefaan] Good point. This has to be changed into "required". Although in some particular cases, path-specific detours may be used but it is better to always use sender-template specific detours. > xxii) The last sentence of Appendix B ends with "avoid merging with other > LSPs". It > would be useful to say here which those "other LSPs" are. I assume their are > themselves > other detour LSPs for the given main LSP? > [Stefaan] Yes, this deserves more explanation. Your understanding is correct. The basic problem is that 2 detours of the same main LSP protect against different SRLGs and hence MUST NOT be merged. Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 28 Apr 2004 02:11:18 +0000 Message-ID: <5533E74FC0108E41A8217C0899CA56CF081E55@mach5.sycamorenet.com> From: "Pandian, Vijay" To: "'Dimitri.Papadimitriou@alcatel.be'" , "Pandian, Vijay" Cc: 'John Drake' , ccamp@ops.ietf.org Subject: RE: Routing and signaling across devices with different switching cap abilities Date: Tue, 27 Apr 2004 22:12:33 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Dimitri, I have no concern with the existing mechanism. It seems logical to solve this using FA-LSP's. Thanks and best regards, Vijay -----Original Message----- From: Dimitri.Papadimitriou@alcatel.be [mailto:Dimitri.Papadimitriou@alcatel.be] Sent: Tuesday, April 27, 2004 3:17 AM To: Pandian, Vijay Cc: 'John Drake'; ccamp@ops.ietf.org Subject: Re: Routing and signaling across devices with different switching cap abilities vijay, would it be possible that you clarify either your concern wrt existing mechanisms or what you want to achieve when saying "I am looking for a solution which does not use the FA-LSP and looks like there is none..." what does that mean ? thanks, - dimitri. Pandian, Vijay wrote: > John, > > Thanks for the pointer to this paper. > > So, in order to provision an LSP between R1 and R2, all the Border Nodes > must be capable of forming high order LSPs (FA-LSP)? If there is at least > one border node which is in-capable of supporting FA-LSP, the R1 to R2 LSP > will fail? > > I am looking for a solution which does not use the FA-LSP and looks like > there is none... > > Please correct me if my interpretation is wrong. > > Thanks, > > Vijay > > -----Original Message----- > From: John Drake [mailto:jdrake@calient.net] > Sent: Sunday, April 25, 2004 12:37 PM > To: Pandian, Vijay; 'Dimitri.Papadimitriou@alcatel.be' > Cc: ccamp@ops.ietf.org > Subject: RE: Routing and signaling across devices with different > switching cap abilities > > > Vijay, > > I'd suggest that you study > > http://www.calient.net/files/IEEEGMPLSpublished.pdf > > Thanks, > > John > > >>-----Original Message----- >>From: Pandian, Vijay [mailto:Vijay.Pandian@sycamorenet.com] >>Sent: Saturday, April 24, 2004 6:43 PM >>To: 'Dimitri.Papadimitriou@alcatel.be'; Pandian, Vijay >>Cc: ccamp@ops.ietf.org >>Subject: RE: Routing and signaling across devices with different switching >>cap abilities >> >>Dimitri, >> >>Sorry for not being very clear with my previous e-mail. >> >>Let me re-phrase my question with a different picture: >> >> OC-48 OC-192 NxOC-192 NxOC-192 OC-192 OC- >>48 >> R1 <-----> S1 <------> L1 <--------> FX <--------> L2 <------> S2 <---- >>-> >>R2 >> PSC-1 TDM LSC FSC LSC TDM >>PSC-1 >> >> >> OC-48 >> <-----> TE-Links >> >> >>R1 and R2 are routers that advertise TE-LSA's with PSC-1 as the Switching >>Capability (SC) for the TE-Links to S1 and S2. >> >>S1 and S2 are two High Order (at STS-1/STM-0 level) grooming switches that >>are in-capable of transparently switching a port/lambda (i.e., Section and >>Line OH bytes are terminated and re-generated). S1 and S2 thus advertise >>TE-LSA's with TDM as the SC for all their TE-Links in this picture. >> >>L1 and L2 are two OXC's that advertise TE-LSA's with LSC as the SC for all >>their TE-Links in this picture. >> >>FX is a PXC that advertise TE-LSA's with FSC as the SC for its TE-Links in >>this picture. >> >>This should be a valid configuration, right? Do we need any additional >>SC's >>in the TE-LSA's? >> >>Given this combination of TE-LSA's, will R1 be able to compute a path to >>R2? >> >>If R1 could successfully compute a PATH, what is the expected "LSP-Enc. >>Type", and "Switching Type" in the Generalized Label Request Object for >>each >>LINK? >> >> R1 ---> S1: SDH/SONET(5) and TDM (100) with "timeslot" as the label? >> >> S1 ---> L1: Lambda(8) and LSC(150) with "port" as the label? >> >> L1 ---> FX: Fiber(9) and FSC(200) with "port" as the label? >> >> FX ---> L2: Fiber(9) and FSC(200) with "port" as the label? >> >> L2 ---> S2: Lambda(8) and LSC(150) with "port" as the label? >> >> S2 ---> R2: SDH/SONET(5) and TDM (100) with "timeslot" as the label? >> >>How about the G-PID? Does it change as well? >> >>How about the Bandwidth Encoding? R1 may ask for an OC-48. Assume S1 is >>incapable of supporting FA-LSP, can the Bandwidth remain as OC-48 for the >>S1 >>---> L1 Link? >> >>Thanks, >> >>Vijay >> >> >>>-----Original Message----- >>>From: Dimitri.Papadimitriou@alcatel.be >>>[mailto:Dimitri.Papadimitriou@alcatel.be] >>>Sent: Saturday, April 24, 2004 4:18 AM >>>To: Pandian, Vijay >>>Cc: ccamp@ops.ietf.org >>>Subject: Re: Routing and signaling across devices with different >>>switching cap abilities >>> >>> >>>hi, >>> >>>Pandian, Vijay wrote: >>> >>>>Consider a mix of devices with varying switching >>> >>>capabilities connected as >>> >>>>follows: >>>> >>>> PSC-1 <===> TDM-1 <===> LSC-1 <===> FSC <===> LSC-2 >>> >>><===> TDM-2 <===> >>> >>>>PSC-2 >>>> >>>>Is it fair to assume that PSC-1 and PSC-2 would advertise >>> >>>TE-LSA's with >>> >>>>"PSC" as the switching capability, TDM-1 and TDM-2 would >>> >>>advertise TE-LSA's >>> >>>>with "TDM" as the switching capability, LSC-1 and LSC-2 >>> >>>would advertise >>> >>>>TE-LSA's with "LSC" as the switching capability...? >>> >>>what "fair" means in this context ? further the hierarchy refers >>>to region boundaries as follows: >>> >>>PSC-1 < PSC-2 < PSC-3 < PSC-4 < L2SC < TDM < LSC < FSC >>> >>>so assuming you're using different values (non-reported in gmpls- >>>routing see below) for TDM and LSC, GMPLS mandates that for inst. >>>you're crossing region boundary at [TDM,LSC] the LSR at the edge >>>of the TDM region must capable to find [LSC,TDM], and if such >>>boundary doesn't exist it is fair to assume that the LSP will not >>>be established - note that we've specific values for L2SC (51), >>>TDM (100), LSC (150) and FSC (200) so what are you inferring with >>>TDM-1 and TDM-2 ? >>> >>> >>>>Given this, would the PSC device (say PSC-1) be able to >>> >>>compute a path using >>> >>>>CSPF to PSC-2? >>> >>>well why don't you use the value defined in gmpls-routing, instead >>>of trying to assess a rule for SC relationship that doesn't exist ? >>> >>> >>>>There had been some discussion regarding the type of label >>> >>>(SUKLM vs. lambda >>> >>>>vs. port) to be used across these switching capabilities. >>> >>>How about the >>> >>>>"LSP-Enc. Type", and "Switching Type" in the Generalized >>> >>>Label Request >>> >>>>Object? How about the Bandwidth Encoding in the >>> >>>SENDER_TSPEC and FLOWSPEC >>> >>>>object? >>> >>>what's more precisely the question here ? >>> >>> >>>>According to rfc3471, section 3.1.1, the switching type is >>> >>>expected to map >>> >>>>to one of the values advertised for the corresponding link. >>> >>>In that case, >>> >>>>would the LSC-device accept a Generalized Label Request >>> >>>with TDM switching >>> >>>>capability and "port" as the label coming from the TDM >>> >>>capable device? >>> >>>i think we've sorted out this issue, during our previous discussion, >>>and the response is "the LSC interface accepts a Generalized Label >>>Request with LSC switching capability and "port" as the label coming >>>from the TDM capable device" i guess you mean when crossing the >>>[TDM,LSC] boundary >>> >>> >>>>Any clarification on this is appreciated... >>>> >>>>Thanks, >>>> >>>>Vijay >>>> >>>>PS: During various GMPLS interop events, an additional FSC >>> >>>(and LSC?) >>> >>>>switching capability in the TE-LSA's was required for the >>> >>>end devices to >>> >>>>compute path. >>> >>>yes, because some people didn't quite accurately translated the term >>>"port" in their implementation ("port" =/= "physical port" such as a >>>fiber), but as discussed this is erroneous >>> >>>hope this clarifies, >>>- dimitri. >>>-- >>>Papadimitriou Dimitri >>>E-mail : dimitri.papadimitriou@alcatel.be >>>E-mail : dpapadimitriou@psg.com >>>Webpage: http://psg.com/~dpapadimitriou/ >>>Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium >>>Phone : +32 3 240-8491 >>> >>> -- Papadimitriou Dimitri E-mail : dimitri.papadimitriou@alcatel.be E-mail : dpapadimitriou@psg.com Webpage: http://psg.com/~dpapadimitriou/ Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium Phone : +32 3 240-8491 Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 27 Apr 2004 16:24:30 +0000 Message-ID: <408E89C4.205@alcatel.be> Date: Tue, 27 Apr 2004 18:26:44 +0200 From: Dimitri.Papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.5) Gecko/20030925 MIME-Version: 1.0 To: v.sharma@ieee.org Cc: "Balasubramania N. Pillai" , ccamp@ops.ietf.org Subject: Re: Basic doubts on 1:1 path protection signaling. Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed just read the next section 8. Vishal Sharma wrote: > Dimitri, Balu, > > Good discussion/clarification. A question in-line. > > -Vishal > > >>-----Original Message----- >>From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On >>Behalf Of Dimitri.Papadimitriou@alcatel.be >>Sent: Tuesday, April 27, 2004 8:42 AM >>To: Balasubramania N. Pillai >>Cc: 'ccamp@ops.ietf.org' >>Subject: Re: Basic doubts on 1:1 path protection signaling. >> >> >> >> >>Balasubramania N. Pillai wrote: >> >>>Thanks Dimitri and John for trying to help me. >>> >>>Thanks for the detailed reply. I am clear on the first two >> >>questions. But I >> >>>am still a little bit confused with my third question. May be I didn't >>>understand the concept right. So let me try again. >>> >>>I was most confused with how do we do signaling to setup the >> >>"Extra Traffic" >> >>>LSP. Are you suggesting that there is not additional signaling >> >>to setup the >> >>>"Extra Traffic LSP". Setup the protection LSP along with the >> >>working LSP. At >> >>>this point the two LSP are setup and the user is free to use >> >>the protection >> >>>LSP to carry extra traffic. >>> >>>My confusion is around this issue. Once the protection LSP is >> >>setup, do we >> >>>need to do extra signaling to setup the "Extra Traffic LSP" on >> >>top of the >> >>>protection LSP. >> >>as the protecting LSP is activated you don't need such operation which >>is performed during the signaling phase (as said in section 7: "working >>and protecting LSPs are signaled as primary LSPs; both are fully >>instantiated during the provisioning phase. [..] preemptable traffic may >>be carried end-to-end using this (read: protecting) LSP (i.e. the >>protecting LSP is capable of carrying extra-traffic)" > > > This seems to make the assumption that the extra-traffic LSP will > be between the same ingress/egress point as the original working LSP. > > In general, when using the capacity of the protection path in 1:1 protection > for extra-traffic this is not really needed. It should be possible > for extra-traffic to use only a segment of the protection LSP. > Indeed, several extra-traffic LSPs may be use the capacity of the > protection LSP, each using a different segment. > (In fact, this is what I thought the P&R analysis/terminology drafts > described, when I last looked at them.) > > Is this not supported by the scheme in the e2e draft? > > >>>-----Original Message----- >>>From: Dimitri.Papadimitriou@alcatel.be >>>[mailto:Dimitri.Papadimitriou@alcatel.be] >>>Sent: Tuesday, April 27, 2004 3:13 AM >>>To: Balasubramania N. Pillai >>>Cc: 'ccamp@ops.ietf.org' >>>Subject: Re: Basic doubts on 1:1 path protection signaling. >>> >>> >>> >>> >>>Balasubramania N. Pillai wrote: >>> >>> >>>>Hi All, >>>> >>>>I was reading the >> >>draft-ietf-ccamp-gmpls-recovery-e2e-signaling-00.txt and >> >>>I >>> >>> >>>>have some basic doubts regarding signaling 1:1 protected LSP with extra >>>>traffic. >>>> >>>> >>>>1. My understanding is that Section 7 talks about 1:1 Protection (the >>>>protection path is fully setup and cross-connects are made) and not 1:1 >>>>Restoration (no cross-connects for protection path) >>> >>> >>>as the title indicates and explained in the text >>> >>> >>> >>>>2. Since the protection LSP is setup (cross-connected), I guess >> >>we should >> >>>>advertise that the resources used by the Protection LSP as "in use" in >>>>routing. >>> >>> >>>if it is cross-connected it is "in use" >>> >>> >>> >>>>3. Section 7, Paragraph 3 says that >>>> >>>> Although the resources for the protecting LSP are pre-allocated, >>>> preemptable traffic may be carried end-to-end using this LSP (i.e. >>>> the protecting LSP is capable of carrying extra-traffic) with the >>>> caveat that this traffic will be preempted if the working LSP fails. >>>> >>>>Take the case where a 1:1 LSP is setup. Both the working LSP and the >>>>protection LSP are setup and cross-connected. Now if we want to add a >>>>extra-traffic, how do we signal, to setup the LSP carrying the Extra >>>>traffic. >>> >>> >>>the protecting lsp allows carrying extra-traffic (in a sense >> >>you may see >> >>>for the 1:1 protection case, the protecting lsp as the "extra-traffic >>>lsp" but this terminology is misleading reason why it is not used) >>> >>> >>> >>>>What objects do we use to associate the "Extra Traffic LSP" to the >>>>protection LSP. >>> >>> >>>the association object is used to bind the protected and the >> >>protecting lsp >> >>>hope this clarifies (note: an update is being prepared to further >>>clarify some of the comments made on the list) >>> >>>thanks, >>>- dimitri >>> >>> >>>>Thanks for you time >>>> >>>>Balu >>>> >>>> >>>> >>>> >>> >>> >>-- >>Papadimitriou Dimitri >>E-mail : dimitri.papadimitriou@alcatel.be >>E-mail : dpapadimitriou@psg.com >>Webpage: http://psg.com/~dpapadimitriou/ >>Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium >>Phone : +32 3 240-8491 >> > > -- Papadimitriou Dimitri E-mail : dimitri.papadimitriou@alcatel.be E-mail : dpapadimitriou@psg.com Webpage: http://psg.com/~dpapadimitriou/ Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium Phone : +32 3 240-8491 Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 27 Apr 2004 16:21:38 +0000 Reply-To: From: "Vishal Sharma" To: , "Balasubramania N. Pillai" , Subject: RE: Basic doubts on 1:1 path protection signaling. Date: Tue, 27 Apr 2004 09:20:27 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Dimitri, Balu, Good discussion/clarification. A question in-line. -Vishal > -----Original Message----- > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On > Behalf Of Dimitri.Papadimitriou@alcatel.be > Sent: Tuesday, April 27, 2004 8:42 AM > To: Balasubramania N. Pillai > Cc: 'ccamp@ops.ietf.org' > Subject: Re: Basic doubts on 1:1 path protection signaling. > > > > > Balasubramania N. Pillai wrote: > > Thanks Dimitri and John for trying to help me. > > > > Thanks for the detailed reply. I am clear on the first two > questions. But I > > am still a little bit confused with my third question. May be I didn't > > understand the concept right. So let me try again. > > > > I was most confused with how do we do signaling to setup the > "Extra Traffic" > > LSP. Are you suggesting that there is not additional signaling > to setup the > > "Extra Traffic LSP". Setup the protection LSP along with the > working LSP. At > > this point the two LSP are setup and the user is free to use > the protection > > LSP to carry extra traffic. > > > > My confusion is around this issue. Once the protection LSP is > setup, do we > > need to do extra signaling to setup the "Extra Traffic LSP" on > top of the > > protection LSP. > > as the protecting LSP is activated you don't need such operation which > is performed during the signaling phase (as said in section 7: "working > and protecting LSPs are signaled as primary LSPs; both are fully > instantiated during the provisioning phase. [..] preemptable traffic may > be carried end-to-end using this (read: protecting) LSP (i.e. the > protecting LSP is capable of carrying extra-traffic)" This seems to make the assumption that the extra-traffic LSP will be between the same ingress/egress point as the original working LSP. In general, when using the capacity of the protection path in 1:1 protection for extra-traffic this is not really needed. It should be possible for extra-traffic to use only a segment of the protection LSP. Indeed, several extra-traffic LSPs may be use the capacity of the protection LSP, each using a different segment. (In fact, this is what I thought the P&R analysis/terminology drafts described, when I last looked at them.) Is this not supported by the scheme in the e2e draft? > > -----Original Message----- > > From: Dimitri.Papadimitriou@alcatel.be > > [mailto:Dimitri.Papadimitriou@alcatel.be] > > Sent: Tuesday, April 27, 2004 3:13 AM > > To: Balasubramania N. Pillai > > Cc: 'ccamp@ops.ietf.org' > > Subject: Re: Basic doubts on 1:1 path protection signaling. > > > > > > > > > > Balasubramania N. Pillai wrote: > > > >>Hi All, > >> > >>I was reading the > draft-ietf-ccamp-gmpls-recovery-e2e-signaling-00.txt and > > > > I > > > >>have some basic doubts regarding signaling 1:1 protected LSP with extra > >>traffic. > >> > >> > >>1. My understanding is that Section 7 talks about 1:1 Protection (the > >>protection path is fully setup and cross-connects are made) and not 1:1 > >>Restoration (no cross-connects for protection path) > > > > > > as the title indicates and explained in the text > > > > > >>2. Since the protection LSP is setup (cross-connected), I guess > we should > >>advertise that the resources used by the Protection LSP as "in use" in > >>routing. > > > > > > if it is cross-connected it is "in use" > > > > > >>3. Section 7, Paragraph 3 says that > >> > >> Although the resources for the protecting LSP are pre-allocated, > >> preemptable traffic may be carried end-to-end using this LSP (i.e. > >> the protecting LSP is capable of carrying extra-traffic) with the > >> caveat that this traffic will be preempted if the working LSP fails. > >> > >>Take the case where a 1:1 LSP is setup. Both the working LSP and the > >>protection LSP are setup and cross-connected. Now if we want to add a > >>extra-traffic, how do we signal, to setup the LSP carrying the Extra > >>traffic. > > > > > > the protecting lsp allows carrying extra-traffic (in a sense > you may see > > for the 1:1 protection case, the protecting lsp as the "extra-traffic > > lsp" but this terminology is misleading reason why it is not used) > > > > > >>What objects do we use to associate the "Extra Traffic LSP" to the > >>protection LSP. > > > > > > the association object is used to bind the protected and the > protecting lsp > > > > hope this clarifies (note: an update is being prepared to further > > clarify some of the comments made on the list) > > > > thanks, > > - dimitri > > > >>Thanks for you time > >> > >>Balu > >> > >> > >> > >> > > > > > > -- > Papadimitriou Dimitri > E-mail : dimitri.papadimitriou@alcatel.be > E-mail : dpapadimitriou@psg.com > Webpage: http://psg.com/~dpapadimitriou/ > Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium > Phone : +32 3 240-8491 > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 27 Apr 2004 15:40:22 +0000 Message-ID: <408E7F4D.4010506@alcatel.be> Date: Tue, 27 Apr 2004 17:42:05 +0200 From: Dimitri.Papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.5) Gecko/20030925 MIME-Version: 1.0 To: "Balasubramania N. Pillai" CC: "'ccamp@ops.ietf.org'" Subject: Re: Basic doubts on 1:1 path protection signaling. Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed Balasubramania N. Pillai wrote: > Thanks Dimitri and John for trying to help me. > > Thanks for the detailed reply. I am clear on the first two questions. But I > am still a little bit confused with my third question. May be I didn't > understand the concept right. So let me try again. > > I was most confused with how do we do signaling to setup the "Extra Traffic" > LSP. Are you suggesting that there is not additional signaling to setup the > "Extra Traffic LSP". Setup the protection LSP along with the working LSP. At > this point the two LSP are setup and the user is free to use the protection > LSP to carry extra traffic. > > My confusion is around this issue. Once the protection LSP is setup, do we > need to do extra signaling to setup the "Extra Traffic LSP" on top of the > protection LSP. as the protecting LSP is activated you don't need such operation which is performed during the signaling phase (as said in section 7: "working and protecting LSPs are signaled as primary LSPs; both are fully instantiated during the provisioning phase. [..] preemptable traffic may be carried end-to-end using this (read: protecting) LSP (i.e. the protecting LSP is capable of carrying extra-traffic)" > Thanks in advance for you help. > > Balu > > > > > -----Original Message----- > From: Dimitri.Papadimitriou@alcatel.be > [mailto:Dimitri.Papadimitriou@alcatel.be] > Sent: Tuesday, April 27, 2004 3:13 AM > To: Balasubramania N. Pillai > Cc: 'ccamp@ops.ietf.org' > Subject: Re: Basic doubts on 1:1 path protection signaling. > > > > > Balasubramania N. Pillai wrote: > >>Hi All, >> >>I was reading the draft-ietf-ccamp-gmpls-recovery-e2e-signaling-00.txt and > > I > >>have some basic doubts regarding signaling 1:1 protected LSP with extra >>traffic. >> >> >>1. My understanding is that Section 7 talks about 1:1 Protection (the >>protection path is fully setup and cross-connects are made) and not 1:1 >>Restoration (no cross-connects for protection path) > > > as the title indicates and explained in the text > > >>2. Since the protection LSP is setup (cross-connected), I guess we should >>advertise that the resources used by the Protection LSP as "in use" in >>routing. > > > if it is cross-connected it is "in use" > > >>3. Section 7, Paragraph 3 says that >> >> Although the resources for the protecting LSP are pre-allocated, >> preemptable traffic may be carried end-to-end using this LSP (i.e. >> the protecting LSP is capable of carrying extra-traffic) with the >> caveat that this traffic will be preempted if the working LSP fails. >> >>Take the case where a 1:1 LSP is setup. Both the working LSP and the >>protection LSP are setup and cross-connected. Now if we want to add a >>extra-traffic, how do we signal, to setup the LSP carrying the Extra >>traffic. > > > the protecting lsp allows carrying extra-traffic (in a sense you may see > for the 1:1 protection case, the protecting lsp as the "extra-traffic > lsp" but this terminology is misleading reason why it is not used) > > >>What objects do we use to associate the "Extra Traffic LSP" to the >>protection LSP. > > > the association object is used to bind the protected and the protecting lsp > > hope this clarifies (note: an update is being prepared to further > clarify some of the comments made on the list) > > thanks, > - dimitri > >>Thanks for you time >> >>Balu >> >> >> >> > > -- Papadimitriou Dimitri E-mail : dimitri.papadimitriou@alcatel.be E-mail : dpapadimitriou@psg.com Webpage: http://psg.com/~dpapadimitriou/ Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium Phone : +32 3 240-8491 Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 27 Apr 2004 15:08:24 +0000 Message-ID: <35800AB26A91D711A75D00B0D07935F31AD35E@mailsrv01.vasw> From: "Balasubramania N. Pillai" To: "'Dimitri.Papadimitriou@alcatel.be'" Cc: "'ccamp@ops.ietf.org'" Subject: RE: Basic doubts on 1:1 path protection signaling. Date: Tue, 27 Apr 2004 11:02:22 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Thanks Dimitri and John for trying to help me. Thanks for the detailed reply. I am clear on the first two questions. But I am still a little bit confused with my third question. May be I didn't understand the concept right. So let me try again. I was most confused with how do we do signaling to setup the "Extra Traffic" LSP. Are you suggesting that there is not additional signaling to setup the "Extra Traffic LSP". Setup the protection LSP along with the working LSP. At this point the two LSP are setup and the user is free to use the protection LSP to carry extra traffic. My confusion is around this issue. Once the protection LSP is setup, do we need to do extra signaling to setup the "Extra Traffic LSP" on top of the protection LSP. Thanks in advance for you help. Balu -----Original Message----- From: Dimitri.Papadimitriou@alcatel.be [mailto:Dimitri.Papadimitriou@alcatel.be] Sent: Tuesday, April 27, 2004 3:13 AM To: Balasubramania N. Pillai Cc: 'ccamp@ops.ietf.org' Subject: Re: Basic doubts on 1:1 path protection signaling. Balasubramania N. Pillai wrote: > Hi All, > > I was reading the draft-ietf-ccamp-gmpls-recovery-e2e-signaling-00.txt and I > have some basic doubts regarding signaling 1:1 protected LSP with extra > traffic. > > > 1. My understanding is that Section 7 talks about 1:1 Protection (the > protection path is fully setup and cross-connects are made) and not 1:1 > Restoration (no cross-connects for protection path) as the title indicates and explained in the text > 2. Since the protection LSP is setup (cross-connected), I guess we should > advertise that the resources used by the Protection LSP as "in use" in > routing. if it is cross-connected it is "in use" > 3. Section 7, Paragraph 3 says that > > Although the resources for the protecting LSP are pre-allocated, > preemptable traffic may be carried end-to-end using this LSP (i.e. > the protecting LSP is capable of carrying extra-traffic) with the > caveat that this traffic will be preempted if the working LSP fails. > > Take the case where a 1:1 LSP is setup. Both the working LSP and the > protection LSP are setup and cross-connected. Now if we want to add a > extra-traffic, how do we signal, to setup the LSP carrying the Extra > traffic. the protecting lsp allows carrying extra-traffic (in a sense you may see for the 1:1 protection case, the protecting lsp as the "extra-traffic lsp" but this terminology is misleading reason why it is not used) > What objects do we use to associate the "Extra Traffic LSP" to the > protection LSP. the association object is used to bind the protected and the protecting lsp hope this clarifies (note: an update is being prepared to further clarify some of the comments made on the list) thanks, - dimitri > Thanks for you time > > Balu > > > > -- Papadimitriou Dimitri E-mail : dimitri.papadimitriou@alcatel.be E-mail : dpapadimitriou@psg.com Webpage: http://psg.com/~dpapadimitriou/ Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium Phone : +32 3 240-8491 Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 27 Apr 2004 10:44:47 +0000 Message-ID: <408E3945.3030601@coritel.it> Date: Tue, 27 Apr 2004 12:43:17 +0200 From: ricciato User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030821 MIME-Version: 1.0 To: Dimitri.Papadimitriou@alcatel.be CC: ugo monaco , ccamp , Zafar Ali Subject: Re: Diverse path failure and optimality in draft-dachille-inter-area-path-protection Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Hi Dimitri, thanks for your comments, see inline. ciao Fabio Dimitri.Papadimitriou@alcatel.be wrote: > > hi, by discussing the proposed method there seems to be three issues > that make the method questionable in terms of guarantee to deliver > what it intends to deliver, its usability (the time validity of the > path is not guaranteed) and its applicability in terms of objective > initially targeted wrt to the network topology > > 1) imagine three areas decoupled computation as explained at their > respective ingress, with ARO method; how the third computation element > (tail-end) is aware of srlg's that may affect a link selected in the > head-end area > > example: link 1 is selected in area 1 (head-end) with srlg 1, link 2 is > selected in in area 2 with srlg 2, and link 3 in area 3 (tail-end) with > srlg 3 and 1 (since the tail end doesn't know that srlg 1 is associated > to link 1 in addition to its association to link 3 even if it knows that > the link 1 has been selected for the ARO) the problem is that you can > not retrieve such kind of error (except but how practical is it if one > start cumulating all this information between computation points) You´re rising this problem with SRLGs spanning non-adjacent areas. First, I do not know if this is a common case in practical scenarios. Can other ccampers comment on that ? Second, IMHO this case is hard to handle for _any_ distributed scheme, in lack of any exchange of info between computation points about srlg spanning multiple area. For instance, I´m wondering if the sequential computation with RRO+XRO (as alternatve to parallel computation with ARO) can handle this scenario, or not. Could you comment on that ? > 2) resource contention, the secondary path may never be established > since the computation point as *no* capability to make any reservation > on it (except from the first segment) since by definition "disjoint" - > it simply becomes a kind of "best effort" secondary path (in the sense > use it if no other reservation are making use of these links) In the parallel approach with ARO, during the first phase the primary LSP is establisehed (including bw reservation), while for the secondary only the path is computed. This computation is base on the topology / load information available at the computation point, so that link without enough bw are pinned out and can not be included in the primary nor the secondary LSP. In a successive phase, the secondary LSP is reserved along the secondary path. What can happen is a race condition, where the bw along the secondary is available during the 1st phase, but not during the 2nd phase, since some other reservation occurred in between the two along some secondary link. If this occurr, the secondary path can not be established, and maybe all the signaling procedure has to be repeated, for primary for secondary. (btw, let me expand in a separate mail the discussion about the case of unsuccesful computation, which was also raised by others ) First, I remark that this time window in which the race can occurr is really short, in the order of one PATH/RESV round trip time, and since hopefully you´re not going to operate your network at it´s capacity limit, the probability of failing signaling due to a race should be really small. Second, I think that races are a well-known problem common to _all_ distributed computation/reservation schemes, i.e. not specific to parallel computation with ARO (incidentally, I note that RSVP itself is prone to race since the path computation occurss in the downstream PATH messages, while the bw reservation is applied during the upstream RESV messages). > > 3) the method seems to raise additional issues when the number of > potential entry point for the secondary disjoint path increases, at > each step of the computation (otherwise the method wouldn't provide > what it intends to deliver) It is not clear to me what are exactly these additional issues, maybe you´d like to provide some more concrete example. In general, my feeling is, again, that such issue might be non-specific to the parallel computation scheme, but rather common to any dstributed scheme. However, there was a point raised by Adrian that might have some relationship to the choice of the entry-point for the secondary path. If this is the case, you might find some interesting hints in my previous mail (posted Mon, 19 Apr 2004, http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00474.html ... sorry it´s so long :-) As a last but important remark, let me suggest to distnguish the problems that are intrinsic to _all_ distributed diverse path computation schemes, from those that are specific to one scheme (e.g. parallel comp. with ARO). Both are important of course, but it would be beneficial to the discussion to clearly separate them in different tracks in the ml. I´d solicit other ccamp-ers also to comment on that. Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 27 Apr 2004 09:32:50 +0000 From: "Adrian Farrel" To: zinin@psg.com Cc: ccamp@ops.ietf.org, adrian@olddog.co.uk Reply-To: adrian@olddog.co.uk Subject: Overlay draft ready for IESG consideration Date: Tue, 27 Apr 2004 10:31:14 +0100 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: Alex, draft-ietf-ccamp-gmpls-overlay-04.txt has been reviewed by the CCAMP WG and marked up after WG last call. Can you please move it forward on the standards track. Note, this is one of the relatively few CCAMP drafts that is blocking a large number of items on the RFC editor's queue. Thanks, Adrian ----- Original Message ----- From: To: Cc: Sent: Monday, April 26, 2004 8:25 PM Subject: I-D ACTION:draft-ietf-ccamp-gmpls-overlay-04.txt > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. > > Title : GMPLS RSVP Support for the Overlay Model > Author(s) : G. Swallow, et al. > Filename : draft-ietf-ccamp-gmpls-overlay-04.txt > Pages : 12 > Date : 2004-4-26 > > Generalized MPLS defines both routing and signaling protocols for the > creation of Label Switched Paths (LSPs) in various transport > technologies. These protocols can be used to support a number of > deployment scenarios. This memo addresses the application of GMPLS > to the overlay model. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-overlay-04.txt Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 27 Apr 2004 08:12:06 +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 : RE : RE : Proposed strategy for Inter-area/AS Date: Tue, 27 Apr 2004 09:51:25 +0200 Message-ID: Thread-Topic: RE : RE : Proposed strategy for Inter-area/AS Thread-Index: AcQrsFwlWMHEGZuKRKOE1ikEaqHqJgAeTYVw From: "LE ROUX Jean-Louis FTRD/DAC/LAN" To: "ricciato" Cc: , Hi Fabio and all, I see what you suggest, but IMHO this would not be sufficient, as an LSP = affinity can be a combination of colors inclusion/exclusion Using your proposed advertisement, there is no mean to know that there = is no path through the ABR, for an LSP bw=3D50M and affinity =3D exclude red & blue. Basically, IMHO in case you have N paths, each with a distinct = adm-group, the only solution, if you want to compute an optimal path using this approach, is to advertise N virtual = links. Note that an ABR would have to compute and advertise many paths to many = potential destinations,=20 This may generate higher flooding than the direct advertisement of = TE-links... and you are likely to loose all the interest for area partitionning. Cheers, JL > -----Message d'origine----- > De : ricciato [mailto:ricciato@coritel.it]=20 > Envoy=E9 : lundi 26 avril 2004 18:59 > =C0 : LE ROUX Jean-Louis FTRD/DAC/LAN > Cc : adrian@olddog.co.uk; ccamp@ops.ietf.org > Objet : Re: RE : RE : Proposed strategy for Inter-area/AS >=20 >=20 > Dear JL, >=20 > you=B4re right. >=20 > Just a quick proposal. > In an attempt to limit the number of virtual link advertised,=20 > would it make sense to advertise only K virtual links, where=20 > K=3D{number=20 > of colors}, and for each of them (say j) advertise the maximum=20 > bandwdith over all links that have color j into their admin_group ? >=20 > For example, in your example (with Path 4 added) >=20 > Path 1: bw 100M admin group {green;blue} > Path 2: bw 50M admin group {red; blue} > Path 3: bw 5M admin group {red;green} > Path 4: bw 50M admin group {red} >=20 > One should advertise=20 > Virtual Link 1: bw 100M admin group {green} --->max(100M,5M)=20 > Virtual Link 2: bw 50M admin group {red} --->max(50M,5M,50M)=20 > Virtual Link 3: bw 100M admin group {gblue} --->max(100M,50M) >=20 >=20 > Assuming that the number of colors << number of possible=20 > links, this approach might cap the amount of advertisement. >=20 > But I=B4m not sure it works ...=20 >=20 > ciao > fabio >=20 > LE ROUX Jean-Louis FTRD/DAC/LAN wrote: >=20 > >Hi Fabio, > > > >Advertising only a subset would improve scalability, but > >this would not be enough to correclty select the best path. > > > >Let's assume that there are three paths from a given ABR X=20 > to a given=20 > >destination D Path 1: bw 100M admin group {green;blue} Path=20 > 2: bw 50M=20 > >admin group {red; blue} Path 3: bw 5M admin group {red;green} > > > >and a TE-LSP L : Destination D, bw=3D 4M, affinity=3D exlude blue > > > >If you advertise only Path 1 and Path 2 as virtual links, ABR X will=20 > >never be selected as next ABR for this TE-LSP, while path 3 is a=20 > >feasible path. > > > >Regards > > > >JL > > > > > > > > =20 > > > >>-----Message d'origine----- > >>De : owner-ccamp@ops.ietf.org > >>[mailto:owner-ccamp@ops.ietf.org] De la part de ricciato > >>Envoy=E9 : lundi 26 avril 2004 09:48 > >>=C0 : LE ROUX Jean-Louis FTRD/DAC/LAN > >>Cc : adrian@olddog.co.uk; ccamp@ops.ietf.org > >>Objet : Re: RE : Proposed strategy for Inter-area/AS > >> > >> > >>Hi JL, > >> > >>just a quick remark: would it make sense in this case to > >>advertise only=20 > >>a selected subset of the N virtual links (say the two with=20 > >>most residual=20 > >>bw) ? > >> > >>ciao > >>fabio > >> > >>LE ROUX Jean-Louis FTRD/DAC/LAN wrote: > >> > >> =20 > >> > >>>Let's assume that there are N distinct paths from ABR A to a > >>>destination X, each with a distinct bandwidth and distinct=20 > >>> =20 > >>> > >>admin-group > >> =20 > >> > >>>(a path admin group being expressed as a logical AND of the > >>> =20 > >>> > >>link admin > >> =20 > >> > >>>groups along the path) How can you summarize such topology ? > >>> =20 > >>> > >>Actually > >> =20 > >> > >>>you need to advertise N virtual links, each with a distinct > >>> =20 > >>> > >>admin-group > >> =20 > >> > >>>and available bandwidth. > >>> > >>> > >>>=20 > >>> > >>>=20 > >>> > >>> =20 > >>> > >> > >> =20 > >> > > > > > > =20 > > >=20 >=20 Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 27 Apr 2004 07:14:35 +0000 Message-ID: <408E08EE.8070805@alcatel.be> Date: Tue, 27 Apr 2004 09:17:02 +0200 From: Dimitri.Papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.5) Gecko/20030925 MIME-Version: 1.0 To: "Pandian, Vijay" Cc: "'John Drake'" , ccamp@ops.ietf.org Subject: Re: Routing and signaling across devices with different switching cap abilities Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed vijay, would it be possible that you clarify either your concern wrt existing mechanisms or what you want to achieve when saying "I am looking for a solution which does not use the FA-LSP and looks like there is none..." what does that mean ? thanks, - dimitri. Pandian, Vijay wrote: > John, > > Thanks for the pointer to this paper. > > So, in order to provision an LSP between R1 and R2, all the Border Nodes > must be capable of forming high order LSPs (FA-LSP)? If there is at least > one border node which is in-capable of supporting FA-LSP, the R1 to R2 LSP > will fail? > > I am looking for a solution which does not use the FA-LSP and looks like > there is none... > > Please correct me if my interpretation is wrong. > > Thanks, > > Vijay > > -----Original Message----- > From: John Drake [mailto:jdrake@calient.net] > Sent: Sunday, April 25, 2004 12:37 PM > To: Pandian, Vijay; 'Dimitri.Papadimitriou@alcatel.be' > Cc: ccamp@ops.ietf.org > Subject: RE: Routing and signaling across devices with different > switching cap abilities > > > Vijay, > > I'd suggest that you study > > http://www.calient.net/files/IEEEGMPLSpublished.pdf > > Thanks, > > John > > >>-----Original Message----- >>From: Pandian, Vijay [mailto:Vijay.Pandian@sycamorenet.com] >>Sent: Saturday, April 24, 2004 6:43 PM >>To: 'Dimitri.Papadimitriou@alcatel.be'; Pandian, Vijay >>Cc: ccamp@ops.ietf.org >>Subject: RE: Routing and signaling across devices with different switching >>cap abilities >> >>Dimitri, >> >>Sorry for not being very clear with my previous e-mail. >> >>Let me re-phrase my question with a different picture: >> >> OC-48 OC-192 NxOC-192 NxOC-192 OC-192 OC- >>48 >> R1 <-----> S1 <------> L1 <--------> FX <--------> L2 <------> S2 <---- >>-> >>R2 >> PSC-1 TDM LSC FSC LSC TDM >>PSC-1 >> >> >> OC-48 >> <-----> TE-Links >> >> >>R1 and R2 are routers that advertise TE-LSA's with PSC-1 as the Switching >>Capability (SC) for the TE-Links to S1 and S2. >> >>S1 and S2 are two High Order (at STS-1/STM-0 level) grooming switches that >>are in-capable of transparently switching a port/lambda (i.e., Section and >>Line OH bytes are terminated and re-generated). S1 and S2 thus advertise >>TE-LSA's with TDM as the SC for all their TE-Links in this picture. >> >>L1 and L2 are two OXC's that advertise TE-LSA's with LSC as the SC for all >>their TE-Links in this picture. >> >>FX is a PXC that advertise TE-LSA's with FSC as the SC for its TE-Links in >>this picture. >> >>This should be a valid configuration, right? Do we need any additional >>SC's >>in the TE-LSA's? >> >>Given this combination of TE-LSA's, will R1 be able to compute a path to >>R2? >> >>If R1 could successfully compute a PATH, what is the expected "LSP-Enc. >>Type", and "Switching Type" in the Generalized Label Request Object for >>each >>LINK? >> >> R1 ---> S1: SDH/SONET(5) and TDM (100) with "timeslot" as the label? >> >> S1 ---> L1: Lambda(8) and LSC(150) with "port" as the label? >> >> L1 ---> FX: Fiber(9) and FSC(200) with "port" as the label? >> >> FX ---> L2: Fiber(9) and FSC(200) with "port" as the label? >> >> L2 ---> S2: Lambda(8) and LSC(150) with "port" as the label? >> >> S2 ---> R2: SDH/SONET(5) and TDM (100) with "timeslot" as the label? >> >>How about the G-PID? Does it change as well? >> >>How about the Bandwidth Encoding? R1 may ask for an OC-48. Assume S1 is >>incapable of supporting FA-LSP, can the Bandwidth remain as OC-48 for the >>S1 >>---> L1 Link? >> >>Thanks, >> >>Vijay >> >> >>>-----Original Message----- >>>From: Dimitri.Papadimitriou@alcatel.be >>>[mailto:Dimitri.Papadimitriou@alcatel.be] >>>Sent: Saturday, April 24, 2004 4:18 AM >>>To: Pandian, Vijay >>>Cc: ccamp@ops.ietf.org >>>Subject: Re: Routing and signaling across devices with different >>>switching cap abilities >>> >>> >>>hi, >>> >>>Pandian, Vijay wrote: >>> >>>>Consider a mix of devices with varying switching >>> >>>capabilities connected as >>> >>>>follows: >>>> >>>> PSC-1 <===> TDM-1 <===> LSC-1 <===> FSC <===> LSC-2 >>> >>><===> TDM-2 <===> >>> >>>>PSC-2 >>>> >>>>Is it fair to assume that PSC-1 and PSC-2 would advertise >>> >>>TE-LSA's with >>> >>>>"PSC" as the switching capability, TDM-1 and TDM-2 would >>> >>>advertise TE-LSA's >>> >>>>with "TDM" as the switching capability, LSC-1 and LSC-2 >>> >>>would advertise >>> >>>>TE-LSA's with "LSC" as the switching capability...? >>> >>>what "fair" means in this context ? further the hierarchy refers >>>to region boundaries as follows: >>> >>>PSC-1 < PSC-2 < PSC-3 < PSC-4 < L2SC < TDM < LSC < FSC >>> >>>so assuming you're using different values (non-reported in gmpls- >>>routing see below) for TDM and LSC, GMPLS mandates that for inst. >>>you're crossing region boundary at [TDM,LSC] the LSR at the edge >>>of the TDM region must capable to find [LSC,TDM], and if such >>>boundary doesn't exist it is fair to assume that the LSP will not >>>be established - note that we've specific values for L2SC (51), >>>TDM (100), LSC (150) and FSC (200) so what are you inferring with >>>TDM-1 and TDM-2 ? >>> >>> >>>>Given this, would the PSC device (say PSC-1) be able to >>> >>>compute a path using >>> >>>>CSPF to PSC-2? >>> >>>well why don't you use the value defined in gmpls-routing, instead >>>of trying to assess a rule for SC relationship that doesn't exist ? >>> >>> >>>>There had been some discussion regarding the type of label >>> >>>(SUKLM vs. lambda >>> >>>>vs. port) to be used across these switching capabilities. >>> >>>How about the >>> >>>>"LSP-Enc. Type", and "Switching Type" in the Generalized >>> >>>Label Request >>> >>>>Object? How about the Bandwidth Encoding in the >>> >>>SENDER_TSPEC and FLOWSPEC >>> >>>>object? >>> >>>what's more precisely the question here ? >>> >>> >>>>According to rfc3471, section 3.1.1, the switching type is >>> >>>expected to map >>> >>>>to one of the values advertised for the corresponding link. >>> >>>In that case, >>> >>>>would the LSC-device accept a Generalized Label Request >>> >>>with TDM switching >>> >>>>capability and "port" as the label coming from the TDM >>> >>>capable device? >>> >>>i think we've sorted out this issue, during our previous discussion, >>>and the response is "the LSC interface accepts a Generalized Label >>>Request with LSC switching capability and "port" as the label coming >>>from the TDM capable device" i guess you mean when crossing the >>>[TDM,LSC] boundary >>> >>> >>>>Any clarification on this is appreciated... >>>> >>>>Thanks, >>>> >>>>Vijay >>>> >>>>PS: During various GMPLS interop events, an additional FSC >>> >>>(and LSC?) >>> >>>>switching capability in the TE-LSA's was required for the >>> >>>end devices to >>> >>>>compute path. >>> >>>yes, because some people didn't quite accurately translated the term >>>"port" in their implementation ("port" =/= "physical port" such as a >>>fiber), but as discussed this is erroneous >>> >>>hope this clarifies, >>>- dimitri. >>>-- >>>Papadimitriou Dimitri >>>E-mail : dimitri.papadimitriou@alcatel.be >>>E-mail : dpapadimitriou@psg.com >>>Webpage: http://psg.com/~dpapadimitriou/ >>>Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium >>>Phone : +32 3 240-8491 >>> >>> -- Papadimitriou Dimitri E-mail : dimitri.papadimitriou@alcatel.be E-mail : dpapadimitriou@psg.com Webpage: http://psg.com/~dpapadimitriou/ Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium Phone : +32 3 240-8491 Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 27 Apr 2004 07:11:35 +0000 Message-ID: <408E07F7.8010702@alcatel.be> Date: Tue, 27 Apr 2004 09:12:55 +0200 From: Dimitri.Papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.5) Gecko/20030925 MIME-Version: 1.0 To: "Balasubramania N. Pillai" CC: "'ccamp@ops.ietf.org'" Subject: Re: Basic doubts on 1:1 path protection signaling. Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed Balasubramania N. Pillai wrote: > Hi All, > > I was reading the draft-ietf-ccamp-gmpls-recovery-e2e-signaling-00.txt and I > have some basic doubts regarding signaling 1:1 protected LSP with extra > traffic. > > > 1. My understanding is that Section 7 talks about 1:1 Protection (the > protection path is fully setup and cross-connects are made) and not 1:1 > Restoration (no cross-connects for protection path) as the title indicates and explained in the text > 2. Since the protection LSP is setup (cross-connected), I guess we should > advertise that the resources used by the Protection LSP as "in use" in > routing. if it is cross-connected it is "in use" > 3. Section 7, Paragraph 3 says that > > Although the resources for the protecting LSP are pre-allocated, > preemptable traffic may be carried end-to-end using this LSP (i.e. > the protecting LSP is capable of carrying extra-traffic) with the > caveat that this traffic will be preempted if the working LSP fails. > > Take the case where a 1:1 LSP is setup. Both the working LSP and the > protection LSP are setup and cross-connected. Now if we want to add a > extra-traffic, how do we signal, to setup the LSP carrying the Extra > traffic. the protecting lsp allows carrying extra-traffic (in a sense you may see for the 1:1 protection case, the protecting lsp as the "extra-traffic lsp" but this terminology is misleading reason why it is not used) > What objects do we use to associate the "Extra Traffic LSP" to the > protection LSP. the association object is used to bind the protected and the protecting lsp hope this clarifies (note: an update is being prepared to further clarify some of the comments made on the list) thanks, - dimitri > Thanks for you time > > Balu > > > > -- Papadimitriou Dimitri E-mail : dimitri.papadimitriou@alcatel.be E-mail : dpapadimitriou@psg.com Webpage: http://psg.com/~dpapadimitriou/ Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium Phone : +32 3 240-8491 Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 27 Apr 2004 00:29:30 +0000 From: "zafar ali" To: , Cc: "'Reshad Rahman'" , , Subject: RE: draft-ali-ccamp-rsvp-node-id-based-hello-01.txt as WG document? Date: Mon, 26 Apr 2004 20:27:42 -0400 Organization: Cisco Systems Message-ID: <000501c42bee$75870410$a39ce440@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi Adrian,=20 Thanks for your follow-ups on the list; much appreciated.=20 We have updated the ID with ONLY changes as required by the IETF process (i.e., copyright, IPR, etc. stuff) and republished the ID. The updated version is at,=20 http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rsvp-node-id-based-h= ell o-00.txt Hi All,=20 Comments on the ID will be highly appreciated.=20 Thanks Regards... Zafar >-----Original Message----- >From: owner-ccamp@ops.ietf.org=20 >[mailto:owner-ccamp@ops.ietf.org] On Behalf Of Adrian Farrel >Sent: Monday, April 26, 2004 3:09 AM >To: ccamp@ops.ietf.org >Subject: Re: draft-ali-ccamp-rsvp-node-id-based-hello-01.txt=20 >as WG document? > > >OK authors, please republish as a working group draft.=20 > >Please make no changes from the previous version except > - check that you have all of the correct IPR boilerplate > including the personal statement > - check that you have the correct copyright boilerplate=20 > >Thanks, >Adrian > Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 26 Apr 2004 23:04:10 +0000 Message-ID: <35800AB26A91D711A75D00B0D07935F31AD35C@mailsrv01.vasw> From: "Balasubramania N. Pillai" To: "'ccamp@ops.ietf.org'" Subject: Basic doubts on 1:1 path protection signaling. Date: Mon, 26 Apr 2004 18:57:46 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Hi All, I was reading the draft-ietf-ccamp-gmpls-recovery-e2e-signaling-00.txt and I have some basic doubts regarding signaling 1:1 protected LSP with extra traffic. 1. My understanding is that Section 7 talks about 1:1 Protection (the protection path is fully setup and cross-connects are made) and not 1:1 Restoration (no cross-connects for protection path) 2. Since the protection LSP is setup (cross-connected), I guess we should advertise that the resources used by the Protection LSP as "in use" in routing. 3. Section 7, Paragraph 3 says that Although the resources for the protecting LSP are pre-allocated, preemptable traffic may be carried end-to-end using this LSP (i.e. the protecting LSP is capable of carrying extra-traffic) with the caveat that this traffic will be preempted if the working LSP fails. Take the case where a 1:1 LSP is setup. Both the working LSP and the protection LSP are setup and cross-connected. Now if we want to add a extra-traffic, how do we signal, to setup the LSP carrying the Extra traffic. What objects do we use to associate the "Extra Traffic LSP" to the protection LSP. Thanks for you time Balu Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 26 Apr 2004 21:49:52 +0000 Reply-To: From: "Vishal Sharma" To: "Stefaan De Cnodder" , "CCAMP" Cc: "Fabio Ricciato" , "Ugo Monaco" , "Alessio D'Achille" , "Marco Listanti" Subject: RE: Comments on ARO Date: Mon, 26 Apr 2004 14:48:56 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi Stefaan, Just following up on my earlier reply to your comments. We had promised to respond to your specific comments a bit later, and some respones are in-line. Again, thanks a lot for feedback, it will be very helpful in revising the document. Regards, -Vishal PS: A couple that are not addressed here, we will address jointly with others, such as when responding to Arthi's or JL's comments, and will CC you on them. > -----Original Message----- > From: stefaan.de_cnodder@alcatel.be > [mailto:stefaan.de_cnodder@alcatel.be] > Sent: Monday, April 19, 2004 12:08 PM > To: v.sharma@ieee.org > Cc: ccamp@ops.ietf.org > Subject: comments on ARO > > > > Hi Vishal, > > looking to draft-dachille, I have following comments: > > 1) Second paragraph in section 2 is not clear: "we will assume that > every > inter-area connection is duplicated". I understood from it that when > the > primary path follows Area1-Area2-Area3, then also the secondary has > to > follow this path but using other border nodes. But then from section > 4.2 I > understand that this is not an assumption? Your understanding is correct. That is, we do _not assume_ that the primary and secondary paths (or the two diverse paths, to be more accurate) follow he same areas/ASs. Thanks for the observation, we will make this clearer in the next revision. > > 2) step 2c on page 5: also E, G and H has to be pruned? It is also > not > clear which path is selected in area 3: I guess it is E-G-H for > primary and > F-H for secondary? Yes. Thanks for pointing this out, we will specify it clearly in the upcoming revision. > 3) (!) page 7, about the trap-avoid reference: If fact it is just a > matter > of doing a good path calculation. If the primary is signaled and > border > nodes know that also a secondary has to be established, then it can > make > sure that the primary does not introduce such a trap. This assumes > that the > border node also has to know that a secondary has to be established. > This > is known by the presence of the ARO object but this does not mean > that at > the end, the ARO has to contain a full strict path of the secondary. > Border > nodes can expand the ARO by only including the border nodes for the > secondary. This means that the path calculation of the secondary is > not > anymore 100% bound to the primary. Also I would prefer that the ARO > is more > like a "hint" than the real path. With this, you do not have to > interaction > problems with re-optimization of secondary, crankback, ... For > instance: > when the secondary fails, it can be re-established ignoring the ARO. > Or > when the secondary can be re-optimzed between border nodes, then it > can be > done without impacting the primary or when the global > re-optimization is > possible, then the ARO can be simple ignored. > > I prefer to have the ARO only recording border nodes, and optionally > only > acting as a hint for the ingress LSR. The latter is less important > to me. As explained in my earlier response, http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00504.html a difficulty with just recording the border nodes is that mere knowledge that the secondary is for some primary, without a knowing the path of the primary is not sufficient to ensure _diversity_ of the two paths. This is one of the main goals of the ARO scheme, thus we need to have knowledge that a primary _and_ a secondary are to be routed when jointly computing their path at each border node. > 4) text below figure 3: primary has to be as short as possible. I do > not > care much about the secondary becuase it is almost never used. Also, > the > resources that it reserves can be shared with other secondaries. The > problem here is: what are you optimizing? According to me the path > of the > primary has to be optimized. Addressed in detail in my earlier response http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00504.html. Briefly, with diversity as the goal, often it may be that the paths of both the primary and secondary are to be optimized or made as short as possible, so we cannot just optimize the one path while ignoring completely the other. (Even if not, one can get into real sub-optimal network operation with unduly long secondary/diverse paths, if their lengths are not controlled cleverly from the start.) But, I agree, we will make this clearer in the revised version, when we focus on diversity, and clarify that protection is one application of the scheme. > 5) I do not understand why the ARO has to contain Area-Ids to > indicate the > route. If the ingress can put the "area-path" in the ARO, then it > can also > put the border nodes in the ERO of the secondary immediately. I.e. > refering > to figure 5: A knows that the path of the secondary is A1-A2-A5-A6. > How > does A know this? And if it is possible to let A know this > information, > then why could it also not know that the path is B1-B7-B9. If A can > do > this, then there is no need anymore for ARO. So the basic question > is: what > makes it easier for A to know A1-A2-A5-A6 instead of B1-B7-B9. This > means > to me that section 4.2 is not valid and that the ARO assumes that > the > "area-path" of primary and secondary is the same, which is true for > IGP > areas. See also comment 2. Maybe better to remove the AREA-IDs from > the > ARO. > > 6) step 1d page 14, second last line: how does the ABR know that B7 > has to > be used and not B8? Referring to Fig. 5 of the draft, the ingress ABR in Area 2 would make that selection depending on what metrics it is optimizing. > 7) section 4.3: also describe the L-bit that is in the ERO > subobjects. Ok, thanks, we will in the next revision. > 8) Is the Addr_len in for instance subobject 1 always 32 or can it > be > something else. I agree here that you should re-use ERO subobjects > but I > see that you are doing this. As mentioned in Sec. 4.3.2.1, the address length allows the IPv4 address to be a prefix of length specified by the "Add_Len" field. So the address length can be different than 32. > 9) Section 4.3.2.3, area_ID: types 3, 4 and 5 are defined but that > conflicts with what is described in the middle of page 19 where the > numbers > are 32, 33, 34. Thanks for the catch! We will make these consistent. > 10) the text in section 4.3.3 is rather confusing (the part in the > middle > of page 22, about pruning the nodes). Take figure 5, area 5: If B6 > has to > calculate a path from B6 to B10, then this path can pass via B5, B8, > B7 > and/or B9. This is because border nodes can also act as core nodes > at the > same time. This seems to be excluded from the draft. Is that > correct? > > 11) First refinement in section 5 about the cost of virtual links: > this has > been proposed before in > http://www.watersprings.org/pub/id/draft-venkatachalam-interarea-m >pls-te-02.txt >which is not a good idea: it only works for inter-IGP area and it >decreases >the scalability although it also has some advantages. Thanks for the observation and the pointer. As you would see from my response to JL, we are thinking more about the virtual link case, and will be able to post some alternatives once we have given it a bit more thought. >12) (!) There are conflicts with re-optimization, crankback, >re-establishement after failure of secondary LSP, ... because in all >of >these cases a working primary LSP also have to be re-signaled which >is not >good. Actually, there are several options in each of these cases, and I have explained some in my earlier response http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00504.html. Further inputs from CCAMPers on interworking these will be much appreciated. We can probably add a discussion of some of these interworking options in the draft, although it is not a goal of the draft to document all possible interworking scenarios! >Therefore it is better to let the ARO only record border >nodes, >and/or to use the ARO more as a hint for the secondary: using the >ARO in >the primary makes sure that a trap is avoided, and then it is up to >the >signaling of the secondary to find this path by using crankback, >.... There >is no need that the primary LSP also gives the path, it only has to >make >sure that there is a path. As explained above, and in my earlier response, the goal is to ensure that there is a _diverse_ path, not just a path for the second LSP. >13) (!) The method seems not to be applicable for inter-AS >calculations. Not sure why you say that (perhaps because of point 12?). We have designed it to be applicable both for inter-area and inter-AS cases. While some refinement for the inter-AS case would improve the scheme, we certainly had that inter-AS case in mind when developing it. >14) Following the classification of methods (ARO, XRO, PCE) that you >described earlier on ccamp based on parallel/sequential and >distributed/centralized computation, ARO looks more an alternative >for PCE than for XRO? In fact, would it be possible to combine >methods? It would be good to explain the interaction (if any) with >these other methods. As I pointed out in my email to JP, http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00467.html we view the ARO as complementary to the PCS/PCE approach and to the XRO. The goal in designing it wasn't really to replace either of these. In fact, I explained there that the ARO is a hybrid approach that can can compute end-to-end diverse paths like in the PCE approach, with the simplicity of the per-domain approach, and without any changes to the signaling protocols (save for an ERO-formatted ARO obj.). As said earlier, it seems it would be useful for us to put in a short section discussing complementarity with other approaches. You already saw some of this in my earlier response to your email, where I explained how things could work with crankback, re-opt. etc. Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 26 Apr 2004 21:43:44 +0000 Reply-To: From: "Vishal Sharma" To: Cc: , "Fabio Ricciato" , "Ugo Monaco" , "Alessio D'Achille" , "Marco Listanti" Subject: RE: comments on ARO Date: Mon, 26 Apr 2004 13:18:52 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Stefaan, Just following up on my earlier reply to your comments. We had promised to respond to your specific comments a bit later, and some respones are in-line. Again, thanks a lot for feedback, it will be very helpful in revising the document. Regards, -Vishal PS: A couple that are not addressed here, we will address jointly with others, such as when responding to Arthi's or JL's comments, and will CC you on them. > -----Original Message----- > From: stefaan.de_cnodder@alcatel.be > [mailto:stefaan.de_cnodder@alcatel.be] > Sent: Monday, April 19, 2004 12:08 PM > To: v.sharma@ieee.org > Cc: ccamp@ops.ietf.org > Subject: comments on ARO > > > > Hi Vishal, > > looking to draft-dachille, I have following comments: > > 1) Second paragraph in section 2 is not clear: "we will assume that > every > inter-area connection is duplicated". I understood from it that when > the > primary path follows Area1-Area2-Area3, then also the secondary has > to > follow this path but using other border nodes. But then from section > 4.2 I > understand that this is not an assumption? Your understanding is correct. That is, we do _not assume_ that the primary and secondary paths (or the two diverse paths, to be more accurate) follow he same areas/ASs. Thanks for the observation, we will make this clearer in the next revision. > > 2) step 2c on page 5: also E, G and H has to be pruned? It is also > not > clear which path is selected in area 3: I guess it is E-G-H for > primary and > F-H for secondary? Yes. Thanks for pointing this out, we will specify it clearly in the upcoming revision. > 3) (!) page 7, about the trap-avoid reference: If fact it is just a > matter > of doing a good path calculation. If the primary is signaled and > border > nodes know that also a secondary has to be established, then it can > make > sure that the primary does not introduce such a trap. This assumes > that the > border node also has to know that a secondary has to be established. > This > is known by the presence of the ARO object but this does not mean > that at > the end, the ARO has to contain a full strict path of the secondary. > Border > nodes can expand the ARO by only including the border nodes for the > secondary. This means that the path calculation of the secondary is > not > anymore 100% bound to the primary. Also I would prefer that the ARO > is more > like a "hint" than the real path. With this, you do not have to > interaction > problems with re-optimization of secondary, crankback, ... For > instance: > when the secondary fails, it can be re-established ignoring the ARO. > Or > when the secondary can be re-optimzed between border nodes, then it > can be > done without impacting the primary or when the global > re-optimization is > possible, then the ARO can be simple ignored. > > I prefer to have the ARO only recording border nodes, and optionally > only > acting as a hint for the ingress LSR. The latter is less important > to me. As explained in my earlier response, http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00504.html a difficulty with just recording the border nodes is that mere knowledge that the secondary is for some primary, without a knowing the path of the primary is not sufficient to ensure _diversity_ of the two paths. This is one of the main goals of the ARO scheme, thus we need to have knowledge that a primary _and_ a secondary are to be routed when jointly computing their path at each border node. > 4) text below figure 3: primary has to be as short as possible. I do > not > care much about the secondary becuase it is almost never used. Also, > the > resources that it reserves can be shared with other secondaries. The > problem here is: what are you optimizing? According to me the path > of the > primary has to be optimized. Addressed in detail in my earlier response http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00504.html. Briefly, with diversity as the goal, often it may be that the paths of both the primary and secondary are to be optimized or made as short as possible, so we cannot just optimize the one path while ignoring completely the other. (Even if not, one can get into real sub-optimal network operation with unduly long secondary/diverse paths, if their lengths are not controlled cleverly from the start.) But, I agree, we will make this clearer in the revised version, when we focus on diversity, and clarify that protection is one application of the scheme. > 5) I do not understand why the ARO has to contain Area-Ids to > indicate the > route. If the ingress can put the "area-path" in the ARO, then it > can also > put the border nodes in the ERO of the secondary immediately. I.e. > refering > to figure 5: A knows that the path of the secondary is A1-A2-A5-A6. > How > does A know this? And if it is possible to let A know this > information, > then why could it also not know that the path is B1-B7-B9. If A can > do > this, then there is no need anymore for ARO. So the basic question > is: what > makes it easier for A to know A1-A2-A5-A6 instead of B1-B7-B9. This > means > to me that section 4.2 is not valid and that the ARO assumes that > the > "area-path" of primary and secondary is the same, which is true for > IGP > areas. See also comment 2. Maybe better to remove the AREA-IDs from > the > ARO. > > 6) step 1d page 14, second last line: how does the ABR know that B7 > has to > be used and not B8? Referring to Fig. 5 of the draft, the ingress ABR in Area 2 would make that selection depending on what metrics it is optimizing. > 7) section 4.3: also describe the L-bit that is in the ERO > subobjects. Ok, thanks, we will in the next revision. > 8) Is the Addr_len in for instance subobject 1 always 32 or can it > be > something else. I agree here that you should re-use ERO subobjects > but I > see that you are doing this. As mentioned in Sec. 4.3.2.1, the address length allows the IPv4 address to be a prefix of length specified by the "Add_Len" field. So the address length can be different than 32. > 9) Section 4.3.2.3, area_ID: types 3, 4 and 5 are defined but that > conflicts with what is described in the middle of page 19 where the > numbers > are 32, 33, 34. Thanks for the catch! We will make these consistent. > 10) the text in section 4.3.3 is rather confusing (the part in the > middle > of page 22, about pruning the nodes). Take figure 5, area 5: If B6 > has to > calculate a path from B6 to B10, then this path can pass via B5, B8, > B7 > and/or B9. This is because border nodes can also act as core nodes > at the > same time. This seems to be excluded from the draft. Is that > correct? > > 11) First refinement in section 5 about the cost of virtual links: > this has > been proposed before in > http://www.watersprings.org/pub/id/draft-venkatachalam-interarea-m >pls-te-02.txt >which is not a good idea: it only works for inter-IGP area and it >decreases >the scalability although it also has some advantages. Thanks for the observation and the pointer. As you would see from my response to JL, we are thinking more about the virtual link case, and will be able to post some alternatives once we have given it a bit more thought. >12) (!) There are conflicts with re-optimization, crankback, >re-establishement after failure of secondary LSP, ... because in all >of >these cases a working primary LSP also have to be re-signaled which >is not >good. Actually, there are several options in each of these cases, and I have explained some in my earlier response http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00504.html. Further inputs from CCAMPers on interworking these will be much appreciated. We can probably add a discussion of some of these interworking options in the draft, although it is not a goal of the draft to document all possible interworking scenarios! >Therefore it is better to let the ARO only record border >nodes, >and/or to use the ARO more as a hint for the secondary: using the >ARO in >the primary makes sure that a trap is avoided, and then it is up to >the >signaling of the secondary to find this path by using crankback, >.... There >is no need that the primary LSP also gives the path, it only has to >make >sure that there is a path. As explained above, and in my earlier response, the goal is to ensure that there is a _diverse_ path, not just a path for the second LSP. >13) (!) The method seems not to be applicable for inter-AS >calculations. Not sure why you say that (perhaps because of point 12?). We have designed it to be applicable both for inter-area and inter-AS cases. While some refinement for the inter-AS case would improve the scheme, we certainly had that inter-AS case in mind when developing it. >14) Following the classification of methods (ARO, XRO, PCE) that you >described earlier on ccamp based on parallel/sequential and >distributed/centralized computation, ARO looks more an alternative >for PCE than for XRO? In fact, would it be possible to combine >methods? It would be good to explain the interaction (if any) with >these other methods. As I pointed out in my email to JP, http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00467.html we view the ARO as complementary to the PCS/PCE approach and to the XRO. The goal in designing it wasn't really to replace either of these. In fact, I explained there that the ARO is a hybrid approach that can can compute end-to-end diverse paths like in the PCE approach, with the simplicity of the per-domain approach, and without any changes to the signaling protocols (save for an ERO-formatted ARO obj.). As said earlier, it seems it would be useful for us to put in a short section discussing complementarity with other approaches. You already saw some of this in my earlier response to your email, where I explained how things could work with crankback, re-opt. etc. Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 26 Apr 2004 20:27:52 +0000 Reply-To: From: "Vishal Sharma" To: "ricciato" , "LE ROUX Jean-Louis FTRD/DAC/LAN" Cc: , Subject: RE: RE : RE : Proposed strategy for Inter-area/AS Date: Mon, 26 Apr 2004 13:26:44 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Hi Fabio, JL, et al I think Fabio may have a good idea here. It provides the flexibility of having info. about all affinities, with the scalability of advertizing only limited information. Perhaps we can explore a bit where there might be issues, and refine this initial solution to get something that we believe is appropriate. -Vishal > -----Original Message----- > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On > Behalf Of ricciato > Sent: Monday, April 26, 2004 9:59 AM > To: LE ROUX Jean-Louis FTRD/DAC/LAN > Cc: adrian@olddog.co.uk; ccamp@ops.ietf.org > Subject: Re: RE : RE : Proposed strategy for Inter-area/AS > > > Dear JL, > > you´re right. > > Just a quick proposal. > In an attempt to limit the number of virtual link advertised, > would it make sense to advertise only K virtual links, where K={number > of colors}, and for each of them (say j) advertise the maximum > bandwdith over all links that have color j into their admin_group ? > > For example, in your example (with Path 4 added) > > Path 1: bw 100M admin group {green;blue} > Path 2: bw 50M admin group {red; blue} > Path 3: bw 5M admin group {red;green} > Path 4: bw 50M admin group {red} > > One should advertise > Virtual Link 1: bw 100M admin group {green} --->max(100M,5M) > Virtual Link 2: bw 50M admin group {red} --->max(50M,5M,50M) > Virtual Link 3: bw 100M admin group {gblue} --->max(100M,50M) > > > Assuming that the number of colors << number of possible links, > this approach might cap the amount of advertisement. > > But I´m not sure it works ... > > ciao > fabio > > LE ROUX Jean-Louis FTRD/DAC/LAN wrote: > > >Hi Fabio, > > > >Advertising only a subset would improve scalability, but > >this would not be enough to correclty select the best path. > > > >Let's assume that there are three paths from a given ABR X to a > given destination D > >Path 1: bw 100M admin group {green;blue} > >Path 2: bw 50M admin group {red; blue} > >Path 3: bw 5M admin group {red;green} > > > >and a TE-LSP L : Destination D, bw= 4M, affinity= exlude blue > > > >If you advertise only Path 1 and Path 2 as virtual links, ABR X > will never be selected as next ABR for this TE-LSP, while path 3 > is a feasible path. > > > >Regards > > > >JL > > > > > > > > > > > >>-----Message d'origine----- > >>De : owner-ccamp@ops.ietf.org > >>[mailto:owner-ccamp@ops.ietf.org] De la part de ricciato > >>Envoyé : lundi 26 avril 2004 09:48 > >>À : LE ROUX Jean-Louis FTRD/DAC/LAN > >>Cc : adrian@olddog.co.uk; ccamp@ops.ietf.org > >>Objet : Re: RE : Proposed strategy for Inter-area/AS > >> > >> > >>Hi JL, > >> > >>just a quick remark: would it make sense in this case to > >>advertise only > >>a selected subset of the N virtual links (say the two with > >>most residual > >>bw) ? > >> > >>ciao > >>fabio > >> > >>LE ROUX Jean-Louis FTRD/DAC/LAN wrote: > >> > >> > >> > >>>Let's assume that there are N distinct paths from ABR A to a > >>>destination X, each with a distinct bandwidth and distinct > >>> > >>> > >>admin-group > >> > >> > >>>(a path admin group being expressed as a logical AND of the > >>> > >>> > >>link admin > >> > >> > >>>groups along the path) How can you summarize such topology ? > >>> > >>> > >>Actually > >> > >> > >>>you need to advertise N virtual links, each with a distinct > >>> > >>> > >>admin-group > >> > >> > >>>and available bandwidth. > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >> > >> > >> > > > > > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 26 Apr 2004 20:15:41 +0000 Message-Id: <200404261925.PAA13135@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-rsvp-node-id-based-hello-00.txt Date: Mon, 26 Apr 2004 15:25:58 -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 : Node ID based RSVP Hello: A Clarification Statement Author(s) : Z. Ali, et al. Filename : draft-ietf-ccamp-rsvp-node-id-based-hello-00.txt Pages : 7 Date : 2004-4-26 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 RSVP Hellos, use of node-id based Hellos is optimal for detecting signaling adjacency failure for RSVP- TE. Nonetheless, this implied behavior is unclear and this document formalizes use of node-id based RSVP Hello sessions as a best current practice (BCP) in some scenarios. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rsvp-node-id-based-hello-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ccamp-rsvp-node-id-based-hello-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ccamp-rsvp-node-id-based-hello-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-4-26150345.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-rsvp-node-id-based-hello-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-rsvp-node-id-based-hello-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-4-26150345.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 26 Apr 2004 17:00:54 +0000 Message-ID: <408D3FC2.5060606@coritel.it> Date: Mon, 26 Apr 2004 18:58:42 +0200 From: ricciato User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030821 MIME-Version: 1.0 To: LE ROUX Jean-Louis FTRD/DAC/LAN CC: adrian@olddog.co.uk, ccamp@ops.ietf.org Subject: Re: RE : RE : Proposed strategy for Inter-area/AS Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Dear JL, you´re right. Just a quick proposal. In an attempt to limit the number of virtual link advertised, would it make sense to advertise only K virtual links, where K={number of colors}, and for each of them (say j) advertise the maximum bandwdith over all links that have color j into their admin_group ? For example, in your example (with Path 4 added) Path 1: bw 100M admin group {green;blue} Path 2: bw 50M admin group {red; blue} Path 3: bw 5M admin group {red;green} Path 4: bw 50M admin group {red} One should advertise Virtual Link 1: bw 100M admin group {green} --->max(100M,5M) Virtual Link 2: bw 50M admin group {red} --->max(50M,5M,50M) Virtual Link 3: bw 100M admin group {gblue} --->max(100M,50M) Assuming that the number of colors << number of possible links, this approach might cap the amount of advertisement. But I´m not sure it works ... ciao fabio LE ROUX Jean-Louis FTRD/DAC/LAN wrote: >Hi Fabio, > >Advertising only a subset would improve scalability, but >this would not be enough to correclty select the best path. > >Let's assume that there are three paths from a given ABR X to a given destination D >Path 1: bw 100M admin group {green;blue} >Path 2: bw 50M admin group {red; blue} >Path 3: bw 5M admin group {red;green} > >and a TE-LSP L : Destination D, bw= 4M, affinity= exlude blue > >If you advertise only Path 1 and Path 2 as virtual links, ABR X will never be selected as next ABR for this TE-LSP, while path 3 is a feasible path. > >Regards > >JL > > > > > >>-----Message d'origine----- >>De : owner-ccamp@ops.ietf.org >>[mailto:owner-ccamp@ops.ietf.org] De la part de ricciato >>Envoyé : lundi 26 avril 2004 09:48 >>À : LE ROUX Jean-Louis FTRD/DAC/LAN >>Cc : adrian@olddog.co.uk; ccamp@ops.ietf.org >>Objet : Re: RE : Proposed strategy for Inter-area/AS >> >> >>Hi JL, >> >>just a quick remark: would it make sense in this case to >>advertise only >>a selected subset of the N virtual links (say the two with >>most residual >>bw) ? >> >>ciao >>fabio >> >>LE ROUX Jean-Louis FTRD/DAC/LAN wrote: >> >> >> >>>Let's assume that there are N distinct paths from ABR A to a >>>destination X, each with a distinct bandwidth and distinct >>> >>> >>admin-group >> >> >>>(a path admin group being expressed as a logical AND of the >>> >>> >>link admin >> >> >>>groups along the path) How can you summarize such topology ? >>> >>> >>Actually >> >> >>>you need to advertise N virtual links, each with a distinct >>> >>> >>admin-group >> >> >>>and available bandwidth. >>> >>> >>> >>> >>> >>> >>> >>> >> >> >> > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 26 Apr 2004 16:35:50 +0000 Message-Id: <4.3.2.7.2.20040426123348.06af32e8@wells.cisco.com> Date: Mon, 26 Apr 2004 12:35:27 -0400 To: "LE ROUX Jean-Louis FTRD/DAC/LAN" From: Jean Philippe Vasseur Subject: RE : RE : Proposed strategy for Inter-area/AS Cc: "ricciato" , , Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable At 06:15 PM 4/26/2004 +0200, LE ROUX Jean-Louis FTRD/DAC/LAN wrote: >Hi Fabio, > >Advertising only a subset would improve scalability, but >this would not be enough to correclty select the best path. > >Let's assume that there are three paths from a given ABR X to a given=20 >destination D >Path 1: bw 100M admin group {green;blue} >Path 2: bw 50M admin group {red; blue} >Path 3: bw 5M admin group {red;green} > >and a TE-LSP L : Destination D, bw=3D 4M, affinity=3D exlude blue > >If you advertise only Path 1 and Path 2 as virtual links, ABR X will never= =20 >be selected as next ABR for this TE-LSP, while path 3 is a feasible path. and moreover, this gets even more difficult if two ABRs must be traversed=20 between the source and the destination .... JP. >Regards > >JL > > > > > -----Message d'origine----- > > De : owner-ccamp@ops.ietf.org > > [mailto:owner-ccamp@ops.ietf.org] De la part de ricciato > > Envoy=E9 : lundi 26 avril 2004 09:48 > > =C0 : LE ROUX Jean-Louis FTRD/DAC/LAN > > Cc : adrian@olddog.co.uk; ccamp@ops.ietf.org > > Objet : Re: RE : Proposed strategy for Inter-area/AS > > > > > > Hi JL, > > > > just a quick remark: would it make sense in this case to > > advertise only > > a selected subset of the N virtual links (say the two with > > most residual > > bw) ? > > > > ciao > > fabio > > > > LE ROUX Jean-Louis FTRD/DAC/LAN wrote: > > > > >Let's assume that there are N distinct paths from ABR A to a > > >destination X, each with a distinct bandwidth and distinct > > admin-group > > >(a path admin group being expressed as a logical AND of the > > link admin > > >groups along the path) How can you summarize such topology ? > > Actually > > >you need to advertise N virtual links, each with a distinct > > admin-group > > >and available bandwidth. > > > > > > > > > > > > > > > > > > > > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 26 Apr 2004 16:26:16 +0000 Message-ID: <408D37FA.2254D30F@alcatel.be> Date: Mon, 26 Apr 2004 18:25:30 +0200 From: stefaan.de_cnodder@alcatel.be MIME-Version: 1.0 To: v.sharma@ieee.org Cc: ccamp@ops.ietf.org, Fabio Ricciato , Ugo Monaco , "Alessio D'Achille" , Marco Listanti Subject: Re: comments on ARO Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Hi Vishal, please find some more comments inline... Vishal Sharma wrote: > > Hi Stefaan, > > Thanks a lot for looking over the draft so carefully, and for your > many detailed comments. > > While we will address the individual comments once we've digested > them a bit (and in a separate email to avoid making this one > too long :-)), let me try to address a couple of the most important > points raised in your note below. > > 1) Recording only border nodes: > > Actually, if one only recorded border nodes, then upon signaling > the secondary, the ingress border node for the secondary has no > idea about the intra-area (or intra-AS) path of the primary (in its > own area or AS), and therefore cannot ensure that the primary and > secondary segments are in fact disjoint. > > This was a point I discussed with several other people > (who initially proposed the same thing), including > Arthi and Adrian, but we concluded, for the reason above, that merely > recording the border nodes does not work for diversity. As a > result, the ARO does, in fact, serve a very useful purpose. > > We can of course think more about what the trade-offs are, and see if there > is some way to retain the main advantage of the proposal (diversity, > joint optimization of both paths) while also recording less information. > The problem I want to solve here is NOT to reduce the amount of information in the ARO, i.e. my purpose is not to reduce its length. Rather, by only recording the border nodes you give more freedom when signaling the secondary (using the XRO!) meaning that when crankback or re-optimization of the secondary is possible, the primary does not have to be resignaled to get a new ARO. > 2) With regard to optimizing only the path of the primary, I am not > so sure about doing just that. > > I believe one can get into real problems if one does not constrain > the path/cost of the secondary, with unduly long secondaries that > will greatly limit the ability to setup further primaries > (and secondaries). (This can be especially true of tranport networks, > where one would set up very large bandwidth pipes, and optimizing their > placement would be critical.) > > This scheme is optimizing jointly the cost of the primary and > secondary, while ensuring diversity. > My question was *what* is the metric being optimized. For instance with sequential computing, the cost of the primary is minimized, while the second metric is the cost of the secondary LSP. With parallel computing it is different: is the cost being minimized the cost of primary + cost of secondary, or is it something else? > I think you will find that most providers would be equally concerned > with the cost/placement of the secondary path. > > Moreover, as I emphasized (and as discussed during CCAMP we wiil change > the title and our intro. to reflect that), this is a: > generic method for computing diverse paths > that meets a variety of requirements: load balancing, multipe paths > when a single one has insufficient capacity, multiple paths between > VoIP gateways, etc. in all of which one would ideally be looking for > paths with about equal length. > Protection is just _one_ application of this scheme. > This load balancing over multiple paths looks like a good application. > 3) Re-optimization, crankback, and failure of secondary: > > I think the scheme works with all of these, and does not really > conflict with any of them. > > With crankback, there should be no problem, whenever a crankback occurs > on the primary, the secondary will also be recomputed at the ASBR/ABR > to which there is crankback. > > With re-optimization, there are several options. > > -- Either default to sequential calculation, and use the XRO to re-optimize > whichever of the two diverse paths requires re-optimization. > (This might be an immediate response, while the below could be > a more long-term response.) > Since an ABR on the secondary path only sees a full strict path in the ERO, the ABR does not know when there is a better path matching the constraints. This is because the ABR does not know the constraints. > -- Or, if the goal really is joint optimization, the provider will have > to setup a new set of diverse paths, and use make-before-break to > transition the traffic over. > > -- If the secondary fails, again there are two options. Either use > the XRO to perform another path setup (and, possibly, re-optimize > the paths later), or use the joint optimization method above with > make-before-break. > This looks ok. regards, Stefaan > 4) Relationship to XRO: > As I mentioned in the Seoul presentation and also > in our discussion, I think the XRO has many uses -- during computation > after crankback, to enable adminstrative routing/re-routing, protection, > etc. > > So I think the ARO and XRO are actually complementary. > > Regards, > -Vishal > > > -----Original Message----- > > From: stefaan.de_cnodder@alcatel.be > > [mailto:stefaan.de_cnodder@alcatel.be] > > Sent: Monday, April 19, 2004 12:08 PM > > To: v.sharma@ieee.org > > Cc: ccamp@ops.ietf.org > > Subject: comments on ARO > > > > > > > > Hi Vishal, > > > > looking to draft-dachille, I have following comments: > > > > 1) Second paragraph in section 2 is not clear: "we will assume that > > every > > inter-area connection is duplicated". I understood from it that when > > the > > primary path follows Area1-Area2-Area3, then also the secondary has > > to > > follow this path but using other border nodes. But then from section > > 4.2 I > > understand that this is not an assumption? > > > > 2) step 2c on page 5: also E, G and H has to be pruned? It is also > > not > > clear which path is selected in area 3: I guess it is E-G-H for > > primary and > > F-H for secondary? > > > > 3) (!) page 7, about the trap-avoid reference: If fact it is just a > > matter > > of doing a good path calculation. If the primary is signaled and > > border > > nodes know that also a secondary has to be established, then it can > > make > > sure that the primary does not introduce such a trap. This assumes > > that the > > border node also has to know that a secondary has to be established. > > This > > is known by the presence of the ARO object but this does not mean > > that at > > the end, the ARO has to contain a full strict path of the secondary. > > Border > > nodes can expand the ARO by only including the border nodes for the > > secondary. This means that the path calculation of the secondary is > > not > > anymore 100% bound to the primary. Also I would prefer that the ARO > > is more > > like a "hint" than the real path. With this, you do not have to > > interaction > > problems with re-optimization of secondary, crankback, ... For > > instance: > > when the secondary fails, it can be re-established ignoring the ARO. > > Or > > when the secondary can be re-optimzed between border nodes, then it > > can be > > done without impacting the primary or when the global > > re-optimization is > > possible, then the ARO can be simple ignored. > > > > I prefer to have the ARO only recording border nodes, and optionally > > only > > acting as a hint for the ingress LSR. The latter is less important > > to me. > > > > 4) text below figure 3: primary has to be as short as possible. I do > > not > > care much about the secondary becuase it is almost never used. Also, > > the > > resources that it reserves can be shared with other secondaries. The > > problem here is: what are you optimizing? According to me the path > > of the > > primary has to be optimized. > > > > 5) I do not understand why the ARO has to contain Area-Ids to > > indicate the > > route. If the ingress can put the "area-path" in the ARO, then it > > can also > > put the border nodes in the ERO of the secondary immediately. I.e. > > refering > > to figure 5: A knows that the path of the secondary is A1-A2-A5-A6. > > How > > does A know this? And if it is possible to let A know this > > information, > > then why could it also not know that the path is B1-B7-B9. If A can > > do > > this, then there is no need anymore for ARO. So the basic question > > is: what > > makes it easier for A to know A1-A2-A5-A6 instead of B1-B7-B9. This > > means > > to me that section 4.2 is not valid and that the ARO assumes that > > the > > "area-path" of primary and secondary is the same, which is true for > > IGP > > areas. See also comment 2. Maybe better to remove the AREA-IDs from > > the > > ARO. > > > > 6) step 1d page 14, second last line: how does the ABR know that B7 > > has to > > be used and not B8? > > > > 7) section 4.3: also describe the L-bit that is in the ERO > > subobjects. > > > > 8) Is the Addr_len in for instance subobject 1 always 32 or can it > > be > > something else. I agree here that you should re-use ERO subobjects > > but I > > see that you are doing this. > > > > 9) Section 4.3.2.3, area_ID: types 3, 4 and 5 are defined but that > > conflicts with what is described in the middle of page 19 where the > > numbers > > are 32, 33, 34. > > > > 10) the text in section 4.3.3 is rather confusing (the part in the > > middle > > of page 22, about pruning the nodes). Take figure 5, area 5: If B6 > > has to > > calculate a path from B6 to B10, then this path can pass via B5, B8, > > B7 > > and/or B9. This is because border nodes can also act as core nodes > > at the > > same time. This seems to be excluded from the draft. Is that > > correct? > > > > 11) First refinement in section 5 about the cost of virtual links: > > this has > > been proposed before in > > http://www.watersprings.org/pub/id/draft-venkatachalam-interarea-m > >pls-te-02.txt > >which is not a good idea: it only works for inter-IGP area and it > >decreases > >the scalability although it also has some advantages. > > >12) (!) There are conflicts with re-optimization, crankback, > >re-establishement after failure of secondary LSP, ... because in all > >of > >these cases a working primary LSP also have to be re-signaled which > >is not > >good. Therefore it is better to let the ARO only record border > >nodes, > >and/or to use the ARO more as a hint for the secondary: using the > >ARO in > >the primary makes sure that a trap is avoided, and then it is up to > >the > >signaling of the secondary to find this path by using crankback, > >.... There > >is no need that the primary LSP also gives the path, it only has to > >make > >sure that there is a path. > > > >13) (!) The method seems not to be applicable for inter-AS > >calculations. > > > >14) Following the classification of methods (ARO, XRO, PCE) that you > >described earlier on ccamp based on parallel/sequential and > >distributed/centralized computation, ARO looks more an alternative > >for PCE than for XRO? In fact, would it be possible to combine > >methods? It would be good to explain the interaction (if any) with > >these other methods. > > > >Hope this helps, > > > >regards, > > > >Stefaan Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 26 Apr 2004 16:16:14 +0000 content-class: urn:content-classes:message Subject: RE : RE : Proposed strategy for Inter-area/AS MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 26 Apr 2004 18:15:15 +0200 Message-ID: Thread-Topic: RE : Proposed strategy for Inter-area/AS Thread-Index: AcQrY5fS2MApmZkZSiamtuS91/qaFwAQ/hvg From: "LE ROUX Jean-Louis FTRD/DAC/LAN" To: "ricciato" Cc: , Hi Fabio, Advertising only a subset would improve scalability, but this would not be enough to correclty select the best path. Let's assume that there are three paths from a given ABR X to a given = destination D Path 1: bw 100M admin group {green;blue} Path 2: bw 50M admin group {red; blue} Path 3: bw 5M admin group {red;green} and a TE-LSP L : Destination D, bw=3D 4M, affinity=3D exlude blue If you advertise only Path 1 and Path 2 as virtual links, ABR X will = never be selected as next ABR for this TE-LSP, while path 3 is a = feasible path. Regards JL=20 > -----Message d'origine----- > De : owner-ccamp@ops.ietf.org=20 > [mailto:owner-ccamp@ops.ietf.org] De la part de ricciato > Envoy=E9 : lundi 26 avril 2004 09:48 > =C0 : LE ROUX Jean-Louis FTRD/DAC/LAN > Cc : adrian@olddog.co.uk; ccamp@ops.ietf.org > Objet : Re: RE : Proposed strategy for Inter-area/AS >=20 >=20 > Hi JL, >=20 > just a quick remark: would it make sense in this case to=20 > advertise only=20 > a selected subset of the N virtual links (say the two with=20 > most residual=20 > bw) ? >=20 > ciao > fabio >=20 > LE ROUX Jean-Louis FTRD/DAC/LAN wrote: >=20 > >Let's assume that there are N distinct paths from ABR A to a=20 > >destination X, each with a distinct bandwidth and distinct=20 > admin-group=20 > >(a path admin group being expressed as a logical AND of the=20 > link admin=20 > >groups along the path) How can you summarize such topology ?=20 > Actually=20 > >you need to advertise N virtual links, each with a distinct=20 > admin-group=20 > >and available bandwidth. > > > > > > =20 > > > > =20 > > >=20 >=20 >=20 Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 26 Apr 2004 15:38:41 +0000 Message-ID: <5533E74FC0108E41A8217C0899CA56CF081E30@mach5.sycamorenet.com> From: "Pandian, Vijay" To: 'John Drake' , "Pandian, Vijay" , "'Dimitri.Papadimitriou@alcatel.be'" Cc: ccamp@ops.ietf.org Subject: RE: Routing and signaling across devices with different switching cap abilities Date: Mon, 26 Apr 2004 11:41:28 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" John, Thanks for the pointer to this paper. So, in order to provision an LSP between R1 and R2, all the Border Nodes must be capable of forming high order LSPs (FA-LSP)? If there is at least one border node which is in-capable of supporting FA-LSP, the R1 to R2 LSP will fail? I am looking for a solution which does not use the FA-LSP and looks like there is none... Please correct me if my interpretation is wrong. Thanks, Vijay -----Original Message----- From: John Drake [mailto:jdrake@calient.net] Sent: Sunday, April 25, 2004 12:37 PM To: Pandian, Vijay; 'Dimitri.Papadimitriou@alcatel.be' Cc: ccamp@ops.ietf.org Subject: RE: Routing and signaling across devices with different switching cap abilities Vijay, I'd suggest that you study http://www.calient.net/files/IEEEGMPLSpublished.pdf Thanks, John > -----Original Message----- > From: Pandian, Vijay [mailto:Vijay.Pandian@sycamorenet.com] > Sent: Saturday, April 24, 2004 6:43 PM > To: 'Dimitri.Papadimitriou@alcatel.be'; Pandian, Vijay > Cc: ccamp@ops.ietf.org > Subject: RE: Routing and signaling across devices with different switching > cap abilities > > Dimitri, > > Sorry for not being very clear with my previous e-mail. > > Let me re-phrase my question with a different picture: > > OC-48 OC-192 NxOC-192 NxOC-192 OC-192 OC- > 48 > R1 <-----> S1 <------> L1 <--------> FX <--------> L2 <------> S2 <---- > -> > R2 > PSC-1 TDM LSC FSC LSC TDM > PSC-1 > > > OC-48 > <-----> TE-Links > > > R1 and R2 are routers that advertise TE-LSA's with PSC-1 as the Switching > Capability (SC) for the TE-Links to S1 and S2. > > S1 and S2 are two High Order (at STS-1/STM-0 level) grooming switches that > are in-capable of transparently switching a port/lambda (i.e., Section and > Line OH bytes are terminated and re-generated). S1 and S2 thus advertise > TE-LSA's with TDM as the SC for all their TE-Links in this picture. > > L1 and L2 are two OXC's that advertise TE-LSA's with LSC as the SC for all > their TE-Links in this picture. > > FX is a PXC that advertise TE-LSA's with FSC as the SC for its TE-Links in > this picture. > > This should be a valid configuration, right? Do we need any additional > SC's > in the TE-LSA's? > > Given this combination of TE-LSA's, will R1 be able to compute a path to > R2? > > If R1 could successfully compute a PATH, what is the expected "LSP-Enc. > Type", and "Switching Type" in the Generalized Label Request Object for > each > LINK? > > R1 ---> S1: SDH/SONET(5) and TDM (100) with "timeslot" as the label? > > S1 ---> L1: Lambda(8) and LSC(150) with "port" as the label? > > L1 ---> FX: Fiber(9) and FSC(200) with "port" as the label? > > FX ---> L2: Fiber(9) and FSC(200) with "port" as the label? > > L2 ---> S2: Lambda(8) and LSC(150) with "port" as the label? > > S2 ---> R2: SDH/SONET(5) and TDM (100) with "timeslot" as the label? > > How about the G-PID? Does it change as well? > > How about the Bandwidth Encoding? R1 may ask for an OC-48. Assume S1 is > incapable of supporting FA-LSP, can the Bandwidth remain as OC-48 for the > S1 > ---> L1 Link? > > Thanks, > > Vijay > > > -----Original Message----- > > From: Dimitri.Papadimitriou@alcatel.be > > [mailto:Dimitri.Papadimitriou@alcatel.be] > > Sent: Saturday, April 24, 2004 4:18 AM > > To: Pandian, Vijay > > Cc: ccamp@ops.ietf.org > > Subject: Re: Routing and signaling across devices with different > > switching cap abilities > > > > > > hi, > > > > Pandian, Vijay wrote: > > > Consider a mix of devices with varying switching > > capabilities connected as > > > follows: > > > > > > PSC-1 <===> TDM-1 <===> LSC-1 <===> FSC <===> LSC-2 > > <===> TDM-2 <===> > > > PSC-2 > > > > > > Is it fair to assume that PSC-1 and PSC-2 would advertise > > TE-LSA's with > > > "PSC" as the switching capability, TDM-1 and TDM-2 would > > advertise TE-LSA's > > > with "TDM" as the switching capability, LSC-1 and LSC-2 > > would advertise > > > TE-LSA's with "LSC" as the switching capability...? > > > > what "fair" means in this context ? further the hierarchy refers > > to region boundaries as follows: > > > > PSC-1 < PSC-2 < PSC-3 < PSC-4 < L2SC < TDM < LSC < FSC > > > > so assuming you're using different values (non-reported in gmpls- > > routing see below) for TDM and LSC, GMPLS mandates that for inst. > > you're crossing region boundary at [TDM,LSC] the LSR at the edge > > of the TDM region must capable to find [LSC,TDM], and if such > > boundary doesn't exist it is fair to assume that the LSP will not > > be established - note that we've specific values for L2SC (51), > > TDM (100), LSC (150) and FSC (200) so what are you inferring with > > TDM-1 and TDM-2 ? > > > > > Given this, would the PSC device (say PSC-1) be able to > > compute a path using > > > CSPF to PSC-2? > > > > well why don't you use the value defined in gmpls-routing, instead > > of trying to assess a rule for SC relationship that doesn't exist ? > > > > > There had been some discussion regarding the type of label > > (SUKLM vs. lambda > > > vs. port) to be used across these switching capabilities. > > How about the > > > "LSP-Enc. Type", and "Switching Type" in the Generalized > > Label Request > > > Object? How about the Bandwidth Encoding in the > > SENDER_TSPEC and FLOWSPEC > > > object? > > > > what's more precisely the question here ? > > > > > According to rfc3471, section 3.1.1, the switching type is > > expected to map > > > to one of the values advertised for the corresponding link. > > In that case, > > > would the LSC-device accept a Generalized Label Request > > with TDM switching > > > capability and "port" as the label coming from the TDM > > capable device? > > > > i think we've sorted out this issue, during our previous discussion, > > and the response is "the LSC interface accepts a Generalized Label > > Request with LSC switching capability and "port" as the label coming > > from the TDM capable device" i guess you mean when crossing the > > [TDM,LSC] boundary > > > > > Any clarification on this is appreciated... > > > > > > Thanks, > > > > > > Vijay > > > > > > PS: During various GMPLS interop events, an additional FSC > > (and LSC?) > > > switching capability in the TE-LSA's was required for the > > end devices to > > > compute path. > > > > yes, because some people didn't quite accurately translated the term > > "port" in their implementation ("port" =/= "physical port" such as a > > fiber), but as discussed this is erroneous > > > > hope this clarifies, > > - dimitri. > > -- > > Papadimitriou Dimitri > > E-mail : dimitri.papadimitriou@alcatel.be > > E-mail : dpapadimitriou@psg.com > > Webpage: http://psg.com/~dpapadimitriou/ > > Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium > > Phone : +32 3 240-8491 > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 26 Apr 2004 13:45:11 +0000 Message-ID: <408D12E3.5030806@alcatel.be> Date: Mon, 26 Apr 2004 15:47:15 +0200 From: Dimitri.Papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.5) Gecko/20030925 MIME-Version: 1.0 To: ugo monaco Cc: ccamp , Zafar Ali Subject: Re: Diverse path failure and optimality in draft-dachille-inter-area-path-protection Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed hi, by discussing the proposed method there seems to be three issues that make the method questionable in terms of guarantee to deliver what it intends to deliver, its usability (the time validity of the path is not guaranteed) and its applicability in terms of objective initially targeted wrt to the network topology 1) imagine three areas decoupled computation as explained at their respective ingress, with ARO method; how the third computation element (tail-end) is aware of srlg's that may affect a link selected in the head-end area example: link 1 is selected in area 1 (head-end) with srlg 1, link 2 is selected in in area 2 with srlg 2, and link 3 in area 3 (tail-end) with srlg 3 and 1 (since the tail end doesn't know that srlg 1 is associated to link 1 in addition to its association to link 3 even if it knows that the link 1 has been selected for the ARO) the problem is that you can not retrieve such kind of error (except but how practical is it if one start cumulating all this information between computation points) 2) resource contention, the secondary path may never be established since the computation point as *no* capability to make any reservation on it (except from the first segment) since by definition "disjoint" - it simply becomes a kind of "best effort" secondary path (in the sense use it if no other reservation are making use of these links) 3) the method seems to raise additional issues when the number of potential entry point for the secondary disjoint path increases, at each step of the computation (otherwise the method wouldn't provide what it intends to deliver) thanks, - dimitri. ugo monaco wrote: > Dear ccamper, Zafar, Dimitri, > > as anticipated in the recent email by Vishal we are addressing several > important comments collected at Seoul regarding the joint-selection of > diverse paths with ARO, i.e. the approach proposed in > . > > > As Vishal did I summarized your comments to ensure that we rightly > understood inputs, and to help people on the ML follow > and contribute to the discussion. > Comments from others who have feedback are welcome, and > much appreciated. > > Please let me know if you had any additional comments > as well. We will take these into account in providing our > responses, and, later, in updating the document. > > > > Thanks again for your feedback on our draft during the Seoul meeting. > Best Regards. > > Ugo Monaco > > > +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > > > Zafar's questions: > > i) What happens when the setup of the diverse path fails, or there is a > failure on it after it has been set up? > > ii) Relationship of this scheme to PCS/PCE approach of JP? > > > Dimitri Papadimitriou > > i) Your question was about why we are trying for optimality with a joint > path selection scheme, when it is not possible, especially as the number > of AS's or areas along a path increase, to achieve the *global* optimum. > Your other comment was that we should mention this somewhere in the > document. > > Please note that in response to this last question Fabio Ricciato listed > many > advantages of a joint computation (with ARO) of inter-area/AS paths in a > prevoius email posted on the ML "About optimality of inter-AS parallel > computation in draft-dachille-inter-area-path-protection". > We hope that Fabio rightly addressed your input and we will appreciate > further comments and notes. > > > > -- Papadimitriou Dimitri E-mail : dimitri.papadimitriou@alcatel.be E-mail : dpapadimitriou@psg.com Webpage: http://psg.com/~dpapadimitriou/ Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium Phone : +32 3 240-8491 Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 26 Apr 2004 13:26:32 +0000 Message-Id: <4.3.2.7.2.20040426092307.04a4c740@wells.cisco.com> Date: Mon, 26 Apr 2004 09:26:10 -0400 To: ricciato From: Jean Philippe Vasseur Subject: Re: RE : Proposed strategy for Inter-area/AS Cc: LE ROUX Jean-Louis FTRD/DAC/LAN , adrian@olddog.co.uk, ccamp@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Hi Fabio, At 09:48 AM 4/26/2004 +0200, ricciato wrote: >Hi JL, > >just a quick remark: would it make sense in this case to advertise only a >selected subset of the N virtual links (say the two with most residual bw) ? I do not think so ... think about all the constraints, which for some of them cannot be easily summarized (affinity), hence N becomes N*K where K might very well be a constantly increasing number. Moroever, this would require to run many CSPFs on the ABR/L1L2. JP. >ciao >fabio > >LE ROUX Jean-Louis FTRD/DAC/LAN wrote: > >>Let's assume that there are N distinct paths from ABR A to a destination >>X, each with a distinct bandwidth and >>distinct admin-group (a path admin group being expressed as a logical AND >>of the link admin groups along the path) >>How can you summarize such topology ? Actually you need to advertise N >>virtual links, each with a distinct admin-group and available bandwidth. >> >> >> >> >> > > Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 26 Apr 2004 13:04:32 +0000 From: "Adrian Farrel" To: ccamp@ops.ietf.org Reply-To: adrian@olddog.co.uk Subject: Working Group Last Call on draft-ietf-ccamp-gmpls-ason-reqts-06.txt Date: Mon, 26 Apr 2004 14:04:13 +0100 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: Re-send with a subject line! ----- Original Message ----- From: "Adrian Farrel" To: Cc: ; Sent: Monday, April 26, 2004 1:57 PM > All, > > The authors of this draft have updated it to reflect the comments on the > mailing list and the helpful feedback from ITU-T SG15 Question 14. > > This email begins a two week Working Group last call on this draft. The > last call will complete on 10th May at 12 noon GMT. > > On a point of procedure, I am an author of this draft therefore anyone > who has an issue with this draft going to WG last call at this time > should contact Kireeti (kireeti@juniper.net) > > Thanks, > Adrian > > ----- Original Message ----- > From: > To: > Cc: > Sent: Tuesday, April 20, 2004 3:54 PM > Subject: I-D ACTION:draft-ietf-ccamp-gmpls-ason-reqts-06.txt > > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. > > > > Title : Requirements for Generalized MPLS (GMPLS) Signaling > > Usage and Extensions for Automatically Switched > > Optical Network (ASON) > > Author(s) : D. Papadimitriou, et al. > > Filename : draft-ietf-ccamp-gmpls-ason-reqts-06.txt > > Pages : 14 > > Date : 2004-4-19 > > > > The Generalized MPLS (GMPLS) suite of protocol has been defined to > > control different switching technologies as well as different > > applications. These include support for requesting TDM connections > > including SONET/SDH and Optical Transport Networks (OTNs). > > This document concentrates on the signaling aspects of the GMPLS > > suite of protocols. It identifies the features to be covered by the > > GMPLS signalling protocol to support the capabilities of an > > Automatically Switched Optical Network (ASON). This document > > provides a problem statement and additional requirements on the > > GMPLS signaling protocol to support the ASON functionality. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-ason-reqts-06.txt Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 26 Apr 2004 12:59:11 +0000 From: "Adrian Farrel" To: ccamp@ops.ietf.org Cc: kireeti@juniper.net, adrian@olddog.co.uk Reply-To: adrian@olddog.co.uk Date: Mon, 26 Apr 2004 13:57:24 +0100 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: All, The authors of this draft have updated it to reflect the comments on the mailing list and the helpful feedback from ITU-T SG15 Question 14. This email begins a two week Working Group last call on this draft. The last call will complete on 10th May at 12 noon GMT. On a point of procedure, I am an author of this draft therefore anyone who has an issue with this draft going to WG last call at this time should contact Kireeti (kireeti@juniper.net) Thanks, Adrian ----- Original Message ----- From: To: Cc: Sent: Tuesday, April 20, 2004 3:54 PM Subject: I-D ACTION:draft-ietf-ccamp-gmpls-ason-reqts-06.txt > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. > > Title : Requirements for Generalized MPLS (GMPLS) Signaling > Usage and Extensions for Automatically Switched > Optical Network (ASON) > Author(s) : D. Papadimitriou, et al. > Filename : draft-ietf-ccamp-gmpls-ason-reqts-06.txt > Pages : 14 > Date : 2004-4-19 > > The Generalized MPLS (GMPLS) suite of protocol has been defined to > control different switching technologies as well as different > applications. These include support for requesting TDM connections > including SONET/SDH and Optical Transport Networks (OTNs). > This document concentrates on the signaling aspects of the GMPLS > suite of protocols. It identifies the features to be covered by the > GMPLS signalling protocol to support the capabilities of an > Automatically Switched Optical Network (ASON). This document > provides a problem statement and additional requirements on the > GMPLS signaling protocol to support the ASON functionality. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-ason-reqts-06.txt Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 26 Apr 2004 08:52:31 +0000 From: "Adrian Farrel" To: ospf@peach.ease.lsoft.com, ccamp@ops.ietf.org, Venkata.Naidu@Marconi.com Cc: adrian@olddog.co.uk Reply-To: adrian@olddog.co.uk Subject: Re: OSPF TLVs Date: Mon, 26 Apr 2004 09:51:52 +0100 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: Venkata, I don't see why there is any change required. You appear to be precluding TLVs from having any length that is not a multiple of four bytes. This seems unnecessary. What we currently have is a rule that tells you how to encode a TLV into an OSPF LSA if it is not a multiple of four bytes. You have a separate rule that says that a specific TLV has some reserved bytes. Why do we need to make any changes? Further, if the length of the TLV is "implicit" we don't need to use a length field at all. There is a place for TVs, but this is not it. The only change that might be of use would be to change the name of any field that is included in a TLV from "padding" to "reserved" to avoid confusion. Perhaps the draft's authors would like to contribute to this thread. Thanks, Adrian ----- Original Message ----- From: "Naidu, Venkata" To: ; ; ; "Naidu, Venkata" Sent: Friday, April 23, 2004 7:41 PM Subject: RE: OSPF TLVs > Adrain, > > -> > We have two cases here: > -> > > -> > 1. Actual (Value) length carried in a TLV is explicit by the > -> > "Length" field. In this case, padding/reserved space is > -> > implicitly ignored based on next boundary math (here 32-bit) > -> > if any, so that parser jump to next TLV with out ambiguity. > -> > -> No. This is NOT what 3630 says. > -> 3630 says that if a TLV is not a multiple of 32-bits, > -> padding is inserted > -> between it and the next TLV. > -> It does not comment on the contents of the TLV. > -> For example, if a TLV had five reserved bytes at the end, we > -> would not > -> modify this so that it had only one reserved byte. > -> In other words, the contents of the TLV are opaque to the > -> TLV packing rules. > -> The length field specifies the length of the V without > -> saying anything about > -> the format of the data in the V. All packing can be > -> performed using the > -> length field. > -> > -> > 2. Actual (Value) length carried in a TLV is implicit by the > -> > "Type" field. In this case, the "Length" field signifies > -> > total (actual + pad/reserved). So that, parser can jump > -> > to next TLV with out ambiguity. > -> > > -> > I thought, (1) is what followed by TE community. I think, > -> > you are supporting (2). > -> > -> I am? > -> Length may be defined by type (with respect to > -> documentation), but it is not > -> implicit. > -> That is, the length field ALWAYS gives the length of the V field. > -> If the V field contains explicit padding or reserved bits, > -> they are included > -> in the length. > > If V field contains explicit padding/reserve bits, the current > value length must be known some how (mostly implicit by the type > field). That is what I am saying. > > Let us come to a consensus. Let me know we are on same page or not > based on below diagram: > > RFC 3630 section 2.3.2. TLV Header > > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Value... | > . . > . . > . . > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > The Length field defines the length of the value portion in octets > (thus a TLV with no value portion would have a length of zero). The > TLV is padded to four-octet alignment; padding is not included in the > length field (so a three octet value would have a length of three, > but the total size of the TLV would be eight octets). > > > [Start Modification] > > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Value Current... | > . . > . . > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > . Value Reserved... . > . . > . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > . | Pad ... (0-3 octet) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > The Length field defines the length of the value portion (current + > reserved) in octets. Length of current value portion is implicit by > the type field. The TLV is padded to four-octet alignment; padding > is not included in the length field (so a three octet value would > have a length of three, but the total size of the TLV would be eight > octets). > > [End Modification] > > > Venkata. > > Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 26 Apr 2004 08:03:15 +0000 From: "Adrian Farrel" To: ccamp@ops.ietf.org Cc: adrian@olddog.co.uk Reply-To: adrian@olddog.co.uk Subject: Working Group Last Call on draft-ietf-ccamp-gmpls-egress-control-01.txt Date: Mon, 26 Apr 2004 09:03:04 +0100 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: This email begins a two week working group last call on draft-ietf-ccamp-gmpls-egress-control-01.txt Last call will complete at 12 noon GMT on 10th May. Although this draft is essentially informational or perhaps a BCP, it will be presented as standards track updating RFC 3473. In that way it will be more easily tracked by people hunting for the relevant RFCs. Thanks, Adrian > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. > > Title : GMPLS Signaling Procedure For Egress Control > Author(s) : L. Berger > Filename : draft-ietf-ccamp-gmpls-egress-control-01.txt > Pages : 6 > Date : 2004-4-23 > > This note clarifies the procedures for the control of the label used > on output/downstream interface of the egress node of a Label Switched > Path (LSP). Such control is also known as "Egress Control". Support > for Egress Control is implicit in Generalized Multi-Protocol Label > Switching (GMPLS) Signaling. This note does not modify GMPLS > signaling mechanisms and procedures and should be viewed as an > informative clarification of GMPLS Signaling - Resource ReserVation > Protocol-Traffic Engineering (RSVP-TE) Extensions. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-egress-control-01.txt Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 26 Apr 2004 07:49:08 +0000 Message-ID: <408CBEBE.8090003@coritel.it> Date: Mon, 26 Apr 2004 09:48:14 +0200 From: ricciato User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030821 MIME-Version: 1.0 To: LE ROUX Jean-Louis FTRD/DAC/LAN CC: adrian@olddog.co.uk, ccamp@ops.ietf.org Subject: Re: RE : Proposed strategy for Inter-area/AS Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi JL, just a quick remark: would it make sense in this case to advertise only a selected subset of the N virtual links (say the two with most residual bw) ? ciao fabio LE ROUX Jean-Louis FTRD/DAC/LAN wrote: >Let's assume that there are N distinct paths from ABR A to a destination X, each with a distinct bandwidth and >distinct admin-group (a path admin group being expressed as a logical AND of the link admin groups along the path) >How can you summarize such topology ? Actually you need to advertise N virtual links, each with a distinct admin-group and available bandwidth. > > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 26 Apr 2004 07:10:08 +0000 From: "Adrian Farrel" To: ccamp@ops.ietf.org Reply-To: adrian@olddog.co.uk Subject: Re: draft-ali-ccamp-rsvp-node-id-based-hello-01.txt as WG document? Date: Mon, 26 Apr 2004 08:09:20 +0100 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: OK authors, please republish as a working group draft. Please make no changes from the previous version except - check that you have all of the correct IPR boilerplate including the personal statement - check that you have the correct copyright boilerplate Thanks, Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 26 Apr 2004 03:15:05 +0000 From: "zafar ali" To: "'Ash, Gerald R \(Jerry\), ALABS'" , Subject: RE: FW: I-D ACTION:draft-ietf-ccamp-gmpls-ason-routing-reqts-03.txt Date: Sun, 25 Apr 2004 23:14:07 -0400 Organization: Cisco Systems Message-ID: <000001c42b3c$8a503180$0300a8c0@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Jerry,=20 Please see in-line. Thanks =20 Regards... Zafar >-----Original Message----- >From: owner-ccamp@ops.ietf.org=20 >[mailto:owner-ccamp@ops.ietf.org] On Behalf Of Ash, Gerald R=20 >(Jerry), ALABS >Sent: Sunday, April 25, 2004 10:11 PM >To: ccamp@ops.ietf.org >Cc: Ash, Gerald R (Jerry), ALABS >Subject: RE: FW: I-D=20 >ACTION:draft-ietf-ccamp-gmpls-ason-routing-reqts-03.txt > > >I have a couple of comments: > >1. I'm bothered by the statement in Section 3: >"The maximum number of hierarchical RA levels to be supported=20 >is NOT specified (outside the scope)." Why is it outside the=20 >scope, I think there should be some explanation. Does the=20 >number of levels not matter? Is one level (i.e., flat=20 >network, no hierarchy at all) OK? I would much prefer to have=20 >the maximum number of required hierarchical levels stated in the draft. > I would disagree here. The number varies depending on networking = scenario. Furthermore, the problem is that as soon as we start picking a number = here, we tend to imply the solution. Let's keep it as an attribute of the networking scenario. >2. There is quite a bit of discussion about hierarchy=20 >evolution, e.g., in Section 3: >"- The requirements support architectural evolution, e.g. a=20 >change in the number of RA levels, as well as aggregation and=20 >segmentation of RAs." > >This begins to suggest automatic 'insertion/deletion' of=20 >hierarchical levels, which I believe is too complex. > I agree completely. I also think complexity greatly over-weight the = benefit. Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 26 Apr 2004 02:12:00 +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: FW: I-D ACTION:draft-ietf-ccamp-gmpls-ason-routing-reqts-03.txt Date: Sun, 25 Apr 2004 21:11:09 -0500 Message-ID: <9473683187ADC049A855ED2DA739ABCA0201F147@KCCLUST06EVS1.ugd.att.com> Thread-Topic: FW: I-D ACTION:draft-ietf-ccamp-gmpls-ason-routing-reqts-03.txt Thread-Index: AcQieu4bHN0af3IZRtydwrnnsEwwEgFXa++AAAb/T8AAxHnOEAAK5hCw From: "Ash, Gerald R (Jerry), ALABS" To: Cc: "Ash, Gerald R (Jerry), ALABS" I have a couple of comments: 1. I'm bothered by the statement in Section 3: "The maximum number of hierarchical RA levels to be supported is NOT = specified (outside the scope)." Why is it outside the scope, I think there should be some explanation. = Does the number of levels not matter? Is one level (i.e., flat network, = no hierarchy at all) OK? I would much prefer to have the maximum number = of required hierarchical levels stated in the draft. 2. There is quite a bit of discussion about hierarchy evolution, e.g., = in Section 3: "- The requirements support architectural evolution, e.g. a change in = the number of RA levels, as well as aggregation and segmentation of = RAs." This begins to suggest automatic 'insertion/deletion' of hierarchical = levels, which I believe is too complex. However, I find in Section 4.4: "The routing protocol SHOULD be capable of supporting architectural = evolution in terms of number of hierarchical levels of RAs, as well as = aggregation and segmentation of RAs. RA IDs uniqueness within an = administrative domain MAY facilitate these operations. The routing = protocol is not expected to automatically initiate and/or execute these = operations." It is the final "not" that says that automatic insertion/deletion is not = required within the protocol. Perhaps this NOT should be capitalized = for emphasis. 3. Regarding Adrian's comment on the text I referenced in comment #2: "The routing protocol is not expected to automatically initiate and/or = execute these operations. Reconfiguration of the RA hierarchy MAY not ## Surely this is MUST? disrupt calls in progress, though calls being set up may fail to = complete, and the call setup service may be unavailable during = reconfiguration actions." I think this should stay a "MAY". In normal hierarchy reconfiguration, = calls are going to be disrupted. It is far more complex to insist = somehow that the protocol keeps calls in tact during such = reconfigurations. Thanks, Jerry -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On Behalf Of Kireeti Kompella Sent: Wednesday, April 14, 2004 7:46 PM To: ccamp@ops.ietf.org Subject: Re: FW: I-D ACTION:draft-ietf-ccamp-gmpls-ason-routing-reqts-03.txt Hi All, On Wed, 14 Apr 2004, Brungard, Deborah A, ALABS wrote: > The ASON Routing Reqts DT has updated the following draft based on > ITU Q14/15's Liaison and CCAMP mail list comments. > > We recommend this document as ready for WG Last Call. This commences a two-week WG Last Call on the GMPLS ASON routing requirements. Last Call ends April 28th, 5pm PDT. Please send your comments to the list. The proposed category is Informational. Kireeti. ------- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 26 Apr 2004 00:26:39 +0000 Message-ID: <408C5733.1000708@infocom.uniroma1.it> Date: Mon, 26 Apr 2004 02:26:27 +0200 From: ugo monaco User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3.1) Gecko/20030428 MIME-Version: 1.0 To: ccamp CC: Zafar Ali , Dimitri Papadimitriou Subject: Diverse path failure and optimality in draft-dachille-inter-area-path-protection Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed Dear ccamper, Zafar, Dimitri, as anticipated in the recent email by Vishal we are addressing several important comments collected at Seoul regarding the joint-selection of diverse paths with ARO, i.e. the approach proposed in . As Vishal did I summarized your comments to ensure that we rightly understood inputs, and to help people on the ML follow and contribute to the discussion. Comments from others who have feedback are welcome, and much appreciated. Please let me know if you had any additional comments as well. We will take these into account in providing our responses, and, later, in updating the document. Thanks again for your feedback on our draft during the Seoul meeting. Best Regards. Ugo Monaco +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Zafar's questions: i) What happens when the setup of the diverse path fails, or there is a failure on it after it has been set up? ii) Relationship of this scheme to PCS/PCE approach of JP? Dimitri Papadimitriou i) Your question was about why we are trying for optimality with a joint path selection scheme, when it is not possible, especially as the number of AS's or areas along a path increase, to achieve the *global* optimum. Your other comment was that we should mention this somewhere in the document. Please note that in response to this last question Fabio Ricciato listed many advantages of a joint computation (with ARO) of inter-area/AS paths in a prevoius email posted on the ML "About optimality of inter-AS parallel computation in draft-dachille-inter-area-path-protection". We hope that Fabio rightly addressed your input and we will appreciate further comments and notes. Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 26 Apr 2004 00:26:32 +0000 Message-ID: <408C56F9.8010402@infocom.uniroma1.it> Date: Mon, 26 Apr 2004 02:25:29 +0200 From: ugo monaco User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3.1) Gecko/20030428 MIME-Version: 1.0 To: ccamp CC: Adrian Farrel Subject: Security issues and egress-driven path comput in draft-dachille-inter-area-path-protection Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed Dear ccampers, Adrian, as anticipated in the recent email by Vishal we are addressing several important comments collected at Seoul regarding the joint-selection of diverse paths with ARO, i.e. the approach proposed in . As mentioned by Vishal I summarized your comments to ensure that we rightly understood inputs, and to help people on the ML follow and contribute to the discussion. Comments from others who have feedback are welcome, and much appreciated. Please let me know if you had any additional comments as well. We will take these into account in providing our responses, and, later, in updating the document. Thanks again for your feedback on our draft during the Seoul meeting. Best Regards. Ugo Monaco +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ i) Security issue of intra-area/AS specific information across areas/ASs. The problem is that ARO could provide private intra-area information outside the area/AS. ii) You asked if our proposed scheme could be modified to have the path for the secondary be computed when the Resv for the primary arrives at the border router of each area/AS? This might allow the egress node (and subsequently the exit node at each previous area/AS) to choose the entry point for the secondary into that area/AS. For example, refer to the attached figure. Consider a linear topology of ASs from AS(1), the source AS, to AS(3), the destination AS. Denote by I(k) and E(k), respectively, the ingress and egress nodes to AS(k). Where needed, the ingress of the primary and secondary path, will be respectively referred to by I1(k) and I2(k) and same for th egress nodes (i.e., E1(k), E2(k)). Your point was that by computing the path in the forward direction, the entry of the secondary path into Area 3 might be I2(3), where as the egress Z may have preferred that it be "Y". By computing things in the reverse direction, one would give the egress the flexibility to choose that entry point, and it could therefore choose "Y". But this way, the exit point at the previous area should be fixed to "X". Area 1 Area 2 Area 3 +----------+ +-----------+ +----------+ I(1)/+\ /+\-----------/+\ E1(2)/+\-----------/+\I1(3) | | | | | | | | | | | | /+\ E(3) | | | | | | | /+-------------+\ E2(2)/+\-----------/+\I2(3) | | | | + | | | | | X /+\xxxxxxxxxxx/+\ Y | +----------+ +-----------+ +----------+ Please note that some details and comments dealing with this "egress-driven selection" have been collected in a previous email posted by Fabio Ricciato on the ML "About egress-influenced path computation in draft-dachille-inter-area-path-protection". Further comments and notes on this issue are welcome. iii) You asked also info. about how ARO relates to the following objects: --- S-ERO, proposed in the draft dealing with setting up p2mp tunnels for multicast (on which you are a co-author); --- Primary Path Route Obj (PPRO) in the e2e protection draft (draft- lang-recovery-e2e, which is now draft-ietf-ccamp-recovery-e2e). iv) Your other question was, how does one select inter-area or inter-AS links when there is dense connectivity between them? Again, referring to the attached figure, if there are multiple choices to get from one area/AS to another, how does the scheme pick one of them? Envelope-to: ccamp-data@psg.com Delivery-date: Sun, 25 Apr 2004 16:40:07 +0000 Message-ID: <9D42C6E086250248810DCADA39CE7EFC017AD7C4@nimbus.chromisys.com> From: John Drake To: "Pandian, Vijay" , "'Dimitri.Papadimitriou@alcatel.be'" Cc: ccamp@ops.ietf.org Subject: RE: Routing and signaling across devices with different switching cap abilities Date: Sun, 25 Apr 2004 09:37:24 -0700 MIME-Version: 1.0 Content-Type: text/plain Vijay, I'd suggest that you study http://www.calient.net/files/IEEEGMPLSpublished.pdf Thanks, John > -----Original Message----- > From: Pandian, Vijay [mailto:Vijay.Pandian@sycamorenet.com] > Sent: Saturday, April 24, 2004 6:43 PM > To: 'Dimitri.Papadimitriou@alcatel.be'; Pandian, Vijay > Cc: ccamp@ops.ietf.org > Subject: RE: Routing and signaling across devices with different switching > cap abilities > > Dimitri, > > Sorry for not being very clear with my previous e-mail. > > Let me re-phrase my question with a different picture: > > OC-48 OC-192 NxOC-192 NxOC-192 OC-192 OC- > 48 > R1 <-----> S1 <------> L1 <--------> FX <--------> L2 <------> S2 <---- > -> > R2 > PSC-1 TDM LSC FSC LSC TDM > PSC-1 > > > OC-48 > <-----> TE-Links > > > R1 and R2 are routers that advertise TE-LSA's with PSC-1 as the Switching > Capability (SC) for the TE-Links to S1 and S2. > > S1 and S2 are two High Order (at STS-1/STM-0 level) grooming switches that > are in-capable of transparently switching a port/lambda (i.e., Section and > Line OH bytes are terminated and re-generated). S1 and S2 thus advertise > TE-LSA's with TDM as the SC for all their TE-Links in this picture. > > L1 and L2 are two OXC's that advertise TE-LSA's with LSC as the SC for all > their TE-Links in this picture. > > FX is a PXC that advertise TE-LSA's with FSC as the SC for its TE-Links in > this picture. > > This should be a valid configuration, right? Do we need any additional > SC's > in the TE-LSA's? > > Given this combination of TE-LSA's, will R1 be able to compute a path to > R2? > > If R1 could successfully compute a PATH, what is the expected "LSP-Enc. > Type", and "Switching Type" in the Generalized Label Request Object for > each > LINK? > > R1 ---> S1: SDH/SONET(5) and TDM (100) with "timeslot" as the label? > > S1 ---> L1: Lambda(8) and LSC(150) with "port" as the label? > > L1 ---> FX: Fiber(9) and FSC(200) with "port" as the label? > > FX ---> L2: Fiber(9) and FSC(200) with "port" as the label? > > L2 ---> S2: Lambda(8) and LSC(150) with "port" as the label? > > S2 ---> R2: SDH/SONET(5) and TDM (100) with "timeslot" as the label? > > How about the G-PID? Does it change as well? > > How about the Bandwidth Encoding? R1 may ask for an OC-48. Assume S1 is > incapable of supporting FA-LSP, can the Bandwidth remain as OC-48 for the > S1 > ---> L1 Link? > > Thanks, > > Vijay > > > -----Original Message----- > > From: Dimitri.Papadimitriou@alcatel.be > > [mailto:Dimitri.Papadimitriou@alcatel.be] > > Sent: Saturday, April 24, 2004 4:18 AM > > To: Pandian, Vijay > > Cc: ccamp@ops.ietf.org > > Subject: Re: Routing and signaling across devices with different > > switching cap abilities > > > > > > hi, > > > > Pandian, Vijay wrote: > > > Consider a mix of devices with varying switching > > capabilities connected as > > > follows: > > > > > > PSC-1 <===> TDM-1 <===> LSC-1 <===> FSC <===> LSC-2 > > <===> TDM-2 <===> > > > PSC-2 > > > > > > Is it fair to assume that PSC-1 and PSC-2 would advertise > > TE-LSA's with > > > "PSC" as the switching capability, TDM-1 and TDM-2 would > > advertise TE-LSA's > > > with "TDM" as the switching capability, LSC-1 and LSC-2 > > would advertise > > > TE-LSA's with "LSC" as the switching capability...? > > > > what "fair" means in this context ? further the hierarchy refers > > to region boundaries as follows: > > > > PSC-1 < PSC-2 < PSC-3 < PSC-4 < L2SC < TDM < LSC < FSC > > > > so assuming you're using different values (non-reported in gmpls- > > routing see below) for TDM and LSC, GMPLS mandates that for inst. > > you're crossing region boundary at [TDM,LSC] the LSR at the edge > > of the TDM region must capable to find [LSC,TDM], and if such > > boundary doesn't exist it is fair to assume that the LSP will not > > be established - note that we've specific values for L2SC (51), > > TDM (100), LSC (150) and FSC (200) so what are you inferring with > > TDM-1 and TDM-2 ? > > > > > Given this, would the PSC device (say PSC-1) be able to > > compute a path using > > > CSPF to PSC-2? > > > > well why don't you use the value defined in gmpls-routing, instead > > of trying to assess a rule for SC relationship that doesn't exist ? > > > > > There had been some discussion regarding the type of label > > (SUKLM vs. lambda > > > vs. port) to be used across these switching capabilities. > > How about the > > > "LSP-Enc. Type", and "Switching Type" in the Generalized > > Label Request > > > Object? How about the Bandwidth Encoding in the > > SENDER_TSPEC and FLOWSPEC > > > object? > > > > what's more precisely the question here ? > > > > > According to rfc3471, section 3.1.1, the switching type is > > expected to map > > > to one of the values advertised for the corresponding link. > > In that case, > > > would the LSC-device accept a Generalized Label Request > > with TDM switching > > > capability and "port" as the label coming from the TDM > > capable device? > > > > i think we've sorted out this issue, during our previous discussion, > > and the response is "the LSC interface accepts a Generalized Label > > Request with LSC switching capability and "port" as the label coming > > from the TDM capable device" i guess you mean when crossing the > > [TDM,LSC] boundary > > > > > Any clarification on this is appreciated... > > > > > > Thanks, > > > > > > Vijay > > > > > > PS: During various GMPLS interop events, an additional FSC > > (and LSC?) > > > switching capability in the TE-LSA's was required for the > > end devices to > > > compute path. > > > > yes, because some people didn't quite accurately translated the term > > "port" in their implementation ("port" =/= "physical port" such as a > > fiber), but as discussed this is erroneous > > > > hope this clarifies, > > - dimitri. > > -- > > Papadimitriou Dimitri > > E-mail : dimitri.papadimitriou@alcatel.be > > E-mail : dpapadimitriou@psg.com > > Webpage: http://psg.com/~dpapadimitriou/ > > Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium > > Phone : +32 3 240-8491 > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Sun, 25 Apr 2004 01:39:52 +0000 Message-ID: <5533E74FC0108E41A8217C0899CA56CF081E1C@mach5.sycamorenet.com> From: "Pandian, Vijay" To: "'Dimitri.Papadimitriou@alcatel.be'" , "Pandian, Vijay" Cc: ccamp@ops.ietf.org Subject: RE: Routing and signaling across devices with different switching cap abilities Date: Sat, 24 Apr 2004 21:42:51 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Dimitri, Sorry for not being very clear with my previous e-mail. Let me re-phrase my question with a different picture: OC-48 OC-192 NxOC-192 NxOC-192 OC-192 OC-48 R1 <-----> S1 <------> L1 <--------> FX <--------> L2 <------> S2 <-----> R2 PSC-1 TDM LSC FSC LSC TDM PSC-1 OC-48 <-----> TE-Links R1 and R2 are routers that advertise TE-LSA's with PSC-1 as the Switching Capability (SC) for the TE-Links to S1 and S2. S1 and S2 are two High Order (at STS-1/STM-0 level) grooming switches that are in-capable of transparently switching a port/lambda (i.e., Section and Line OH bytes are terminated and re-generated). S1 and S2 thus advertise TE-LSA's with TDM as the SC for all their TE-Links in this picture. L1 and L2 are two OXC's that advertise TE-LSA's with LSC as the SC for all their TE-Links in this picture. FX is a PXC that advertise TE-LSA's with FSC as the SC for its TE-Links in this picture. This should be a valid configuration, right? Do we need any additional SC's in the TE-LSA's? Given this combination of TE-LSA's, will R1 be able to compute a path to R2? If R1 could successfully compute a PATH, what is the expected "LSP-Enc. Type", and "Switching Type" in the Generalized Label Request Object for each LINK? R1 ---> S1: SDH/SONET(5) and TDM (100) with "timeslot" as the label? S1 ---> L1: Lambda(8) and LSC(150) with "port" as the label? L1 ---> FX: Fiber(9) and FSC(200) with "port" as the label? FX ---> L2: Fiber(9) and FSC(200) with "port" as the label? L2 ---> S2: Lambda(8) and LSC(150) with "port" as the label? S2 ---> R2: SDH/SONET(5) and TDM (100) with "timeslot" as the label? How about the G-PID? Does it change as well? How about the Bandwidth Encoding? R1 may ask for an OC-48. Assume S1 is incapable of supporting FA-LSP, can the Bandwidth remain as OC-48 for the S1 ---> L1 Link? Thanks, Vijay > -----Original Message----- > From: Dimitri.Papadimitriou@alcatel.be > [mailto:Dimitri.Papadimitriou@alcatel.be] > Sent: Saturday, April 24, 2004 4:18 AM > To: Pandian, Vijay > Cc: ccamp@ops.ietf.org > Subject: Re: Routing and signaling across devices with different > switching cap abilities > > > hi, > > Pandian, Vijay wrote: > > Consider a mix of devices with varying switching > capabilities connected as > > follows: > > > > PSC-1 <===> TDM-1 <===> LSC-1 <===> FSC <===> LSC-2 > <===> TDM-2 <===> > > PSC-2 > > > > Is it fair to assume that PSC-1 and PSC-2 would advertise > TE-LSA's with > > "PSC" as the switching capability, TDM-1 and TDM-2 would > advertise TE-LSA's > > with "TDM" as the switching capability, LSC-1 and LSC-2 > would advertise > > TE-LSA's with "LSC" as the switching capability...? > > what "fair" means in this context ? further the hierarchy refers > to region boundaries as follows: > > PSC-1 < PSC-2 < PSC-3 < PSC-4 < L2SC < TDM < LSC < FSC > > so assuming you're using different values (non-reported in gmpls- > routing see below) for TDM and LSC, GMPLS mandates that for inst. > you're crossing region boundary at [TDM,LSC] the LSR at the edge > of the TDM region must capable to find [LSC,TDM], and if such > boundary doesn't exist it is fair to assume that the LSP will not > be established - note that we've specific values for L2SC (51), > TDM (100), LSC (150) and FSC (200) so what are you inferring with > TDM-1 and TDM-2 ? > > > Given this, would the PSC device (say PSC-1) be able to > compute a path using > > CSPF to PSC-2? > > well why don't you use the value defined in gmpls-routing, instead > of trying to assess a rule for SC relationship that doesn't exist ? > > > There had been some discussion regarding the type of label > (SUKLM vs. lambda > > vs. port) to be used across these switching capabilities. > How about the > > "LSP-Enc. Type", and "Switching Type" in the Generalized > Label Request > > Object? How about the Bandwidth Encoding in the > SENDER_TSPEC and FLOWSPEC > > object? > > what's more precisely the question here ? > > > According to rfc3471, section 3.1.1, the switching type is > expected to map > > to one of the values advertised for the corresponding link. > In that case, > > would the LSC-device accept a Generalized Label Request > with TDM switching > > capability and "port" as the label coming from the TDM > capable device? > > i think we've sorted out this issue, during our previous discussion, > and the response is "the LSC interface accepts a Generalized Label > Request with LSC switching capability and "port" as the label coming > from the TDM capable device" i guess you mean when crossing the > [TDM,LSC] boundary > > > Any clarification on this is appreciated... > > > > Thanks, > > > > Vijay > > > > PS: During various GMPLS interop events, an additional FSC > (and LSC?) > > switching capability in the TE-LSA's was required for the > end devices to > > compute path. > > yes, because some people didn't quite accurately translated the term > "port" in their implementation ("port" =/= "physical port" such as a > fiber), but as discussed this is erroneous > > hope this clarifies, > - dimitri. > -- > Papadimitriou Dimitri > E-mail : dimitri.papadimitriou@alcatel.be > E-mail : dpapadimitriou@psg.com > Webpage: http://psg.com/~dpapadimitriou/ > Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium > Phone : +32 3 240-8491 > > Envelope-to: ccamp-data@psg.com Delivery-date: Sat, 24 Apr 2004 12:23:31 +0000 Message-ID: <408A22B5.6020801@alcatel.be> Date: Sat, 24 Apr 2004 10:17:57 +0200 From: Dimitri.Papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.5) Gecko/20030925 MIME-Version: 1.0 To: "Pandian, Vijay" CC: ccamp@ops.ietf.org Subject: Re: Routing and signaling across devices with different switching cap abilities Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed hi, Pandian, Vijay wrote: > Consider a mix of devices with varying switching capabilities connected as > follows: > > PSC-1 <===> TDM-1 <===> LSC-1 <===> FSC <===> LSC-2 <===> TDM-2 <===> > PSC-2 > > Is it fair to assume that PSC-1 and PSC-2 would advertise TE-LSA's with > "PSC" as the switching capability, TDM-1 and TDM-2 would advertise TE-LSA's > with "TDM" as the switching capability, LSC-1 and LSC-2 would advertise > TE-LSA's with "LSC" as the switching capability...? what "fair" means in this context ? further the hierarchy refers to region boundaries as follows: PSC-1 < PSC-2 < PSC-3 < PSC-4 < L2SC < TDM < LSC < FSC so assuming you're using different values (non-reported in gmpls- routing see below) for TDM and LSC, GMPLS mandates that for inst. you're crossing region boundary at [TDM,LSC] the LSR at the edge of the TDM region must capable to find [LSC,TDM], and if such boundary doesn't exist it is fair to assume that the LSP will not be established - note that we've specific values for L2SC (51), TDM (100), LSC (150) and FSC (200) so what are you inferring with TDM-1 and TDM-2 ? > Given this, would the PSC device (say PSC-1) be able to compute a path using > CSPF to PSC-2? well why don't you use the value defined in gmpls-routing, instead of trying to assess a rule for SC relationship that doesn't exist ? > There had been some discussion regarding the type of label (SUKLM vs. lambda > vs. port) to be used across these switching capabilities. How about the > "LSP-Enc. Type", and "Switching Type" in the Generalized Label Request > Object? How about the Bandwidth Encoding in the SENDER_TSPEC and FLOWSPEC > object? what's more precisely the question here ? > According to rfc3471, section 3.1.1, the switching type is expected to map > to one of the values advertised for the corresponding link. In that case, > would the LSC-device accept a Generalized Label Request with TDM switching > capability and "port" as the label coming from the TDM capable device? i think we've sorted out this issue, during our previous discussion, and the response is "the LSC interface accepts a Generalized Label Request with LSC switching capability and "port" as the label coming from the TDM capable device" i guess you mean when crossing the [TDM,LSC] boundary > Any clarification on this is appreciated... > > Thanks, > > Vijay > > PS: During various GMPLS interop events, an additional FSC (and LSC?) > switching capability in the TE-LSA's was required for the end devices to > compute path. yes, because some people didn't quite accurately translated the term "port" in their implementation ("port" =/= "physical port" such as a fiber), but as discussed this is erroneous hope this clarifies, - dimitri. -- Papadimitriou Dimitri E-mail : dimitri.papadimitriou@alcatel.be E-mail : dpapadimitriou@psg.com Webpage: http://psg.com/~dpapadimitriou/ Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium Phone : +32 3 240-8491 Envelope-to: ccamp-data@psg.com Delivery-date: Sat, 24 Apr 2004 02:52:02 +0000 Message-ID: <5533E74FC0108E41A8217C0899CA56CF081E1B@mach5.sycamorenet.com> From: "Pandian, Vijay" To: ccamp@ops.ietf.org Subject: Routing and signaling across devices with different switching cap abilities Date: Fri, 23 Apr 2004 22:54:03 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Consider a mix of devices with varying switching capabilities connected as follows: PSC-1 <===> TDM-1 <===> LSC-1 <===> FSC <===> LSC-2 <===> TDM-2 <===> PSC-2 Is it fair to assume that PSC-1 and PSC-2 would advertise TE-LSA's with "PSC" as the switching capability, TDM-1 and TDM-2 would advertise TE-LSA's with "TDM" as the switching capability, LSC-1 and LSC-2 would advertise TE-LSA's with "LSC" as the switching capability...? Given this, would the PSC device (say PSC-1) be able to compute a path using CSPF to PSC-2? There had been some discussion regarding the type of label (SUKLM vs. lambda vs. port) to be used across these switching capabilities. How about the "LSP-Enc. Type", and "Switching Type" in the Generalized Label Request Object? How about the Bandwidth Encoding in the SENDER_TSPEC and FLOWSPEC object? According to rfc3471, section 3.1.1, the switching type is expected to map to one of the values advertised for the corresponding link. In that case, would the LSC-device accept a Generalized Label Request with TDM switching capability and "port" as the label coming from the TDM capable device? Any clarification on this is appreciated... Thanks, Vijay PS: During various GMPLS interop events, an additional FSC (and LSC?) switching capability in the TE-LSA's was required for the end devices to compute path. Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 23 Apr 2004 19:36:32 +0000 Message-Id: <200404231935.PAA03379@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-gmpls-egress-control-01.txt Date: Fri, 23 Apr 2004 15:35:55 -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 : GMPLS Signaling Procedure For Egress Control Author(s) : L. Berger Filename : draft-ietf-ccamp-gmpls-egress-control-01.txt Pages : 6 Date : 2004-4-23 This note clarifies the procedures for the control of the label used on output/downstream interface of the egress node of a Label Switched Path (LSP). Such control is also known as "Egress Control". Support for Egress Control is implicit in Generalized Multi-Protocol Label Switching (GMPLS) Signaling. This note does not modify GMPLS signaling mechanisms and procedures and should be viewed as an informative clarification of GMPLS Signaling - Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-egress-control-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-gmpls-egress-control-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-gmpls-egress-control-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: <2004-4-23150455.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-gmpls-egress-control-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-gmpls-egress-control-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-4-23150455.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 23 Apr 2004 18:42:58 +0000 Message-ID: <39469E08BD83D411A3D900204840EC55FB7262@vie-msgusr-01.dc.fore.com> From: "Naidu, Venkata" To: "'adrian@olddog.co.uk'" , ospf@peach.ease.lsoft.com, ccamp@ops.ietf.org, "Naidu, Venkata" Subject: RE: OSPF TLVs Date: Fri, 23 Apr 2004 14:41:59 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Adrain, -> > We have two cases here: -> > -> > 1. Actual (Value) length carried in a TLV is explicit by the -> > "Length" field. In this case, padding/reserved space is -> > implicitly ignored based on next boundary math (here 32-bit) -> > if any, so that parser jump to next TLV with out ambiguity. -> -> No. This is NOT what 3630 says. -> 3630 says that if a TLV is not a multiple of 32-bits, -> padding is inserted -> between it and the next TLV. -> It does not comment on the contents of the TLV. -> For example, if a TLV had five reserved bytes at the end, we -> would not -> modify this so that it had only one reserved byte. -> In other words, the contents of the TLV are opaque to the -> TLV packing rules. -> The length field specifies the length of the V without -> saying anything about -> the format of the data in the V. All packing can be -> performed using the -> length field. -> -> > 2. Actual (Value) length carried in a TLV is implicit by the -> > "Type" field. In this case, the "Length" field signifies -> > total (actual + pad/reserved). So that, parser can jump -> > to next TLV with out ambiguity. -> > -> > I thought, (1) is what followed by TE community. I think, -> > you are supporting (2). -> -> I am? -> Length may be defined by type (with respect to -> documentation), but it is not -> implicit. -> That is, the length field ALWAYS gives the length of the V field. -> If the V field contains explicit padding or reserved bits, -> they are included -> in the length. If V field contains explicit padding/reserve bits, the current value length must be known some how (mostly implicit by the type field). That is what I am saying. Let us come to a consensus. Let me know we are on same page or not based on below diagram: RFC 3630 section 2.3.2. TLV Header 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value... | . . . . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Length field defines the length of the value portion in octets (thus a TLV with no value portion would have a length of zero). The TLV is padded to four-octet alignment; padding is not included in the length field (so a three octet value would have a length of three, but the total size of the TLV would be eight octets). [Start Modification] 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value Current... | . . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . Value Reserved... . . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . | Pad ... (0-3 octet) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Length field defines the length of the value portion (current + reserved) in octets. Length of current value portion is implicit by the type field. The TLV is padded to four-octet alignment; padding is not included in the length field (so a three octet value would have a length of three, but the total size of the TLV would be eight octets). [End Modification] Venkata. Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 23 Apr 2004 17:04:44 +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 : Proposed strategy for Inter-area/AS Date: Fri, 23 Apr 2004 19:02:54 +0200 Message-ID: Thread-Topic: Proposed strategy for Inter-area/AS Thread-Index: AcQpQ8xG5eKcNHlNQjql3jM9q2dkowAC4bfg From: "LE ROUX Jean-Louis FTRD/DAC/LAN" To: , Hi Adrian, See inline > -----Message d'origine----- > De : Adrian Farrel [mailto:olddog@clara.co.uk]=20 > Envoy=E9 : vendredi 23 avril 2004 17:01 > =C0 : LE ROUX Jean-Louis FTRD/DAC/LAN; ccamp@ops.ietf.org > Cc : adrian@olddog.co.uk > Objet : Re: Proposed strategy for Inter-area/AS >=20 >=20 > Hi,=20 >=20 > Thanks for clarifying. See below...=20 >=20 > >> > Requirement drafts clearly point out that routing (IGP, EGP) > >> > extensions should be avoided, except some minor extensions to=20 > >> > advertise static parameters such as PCS capabilities for=20 > instance=20 > >> > (addressed in point 5).=20 > >>=20 > >> I am not sure that I can find any text in the two TEWG drafts > >> that actually says what you suggest. >=20 > > In the inter-area requirement draft, we clearly point out that > > information propagation for path-selection should continue to be=20 > > localized and that leaking of TE link information across=20 > areas MUST be=20 > > precluded (section 5.3.1).=20 > > Note that this includes any summarized/aggregated TE link=20 > information.=20 > > I agree that this is not clear in current version, we will=20 > clarify in=20 > > next revision. >=20 > How right you are :-)=20 >=20 > The draft currently says... > The solution MUST entirely preserve the concept of IGP hierarchy. In > other words, flooding of TE link information across areas MUST be > precluded.=20 >=20 > I took "flooding" to be a more free distibution of information that=20 > "leaking".=20 >=20 > For example, I would consider that the Summary LSA is=20 > "leaking" routing information from one LSA to another, but it=20 > is not flooding that=20 > information.=20 Right, we will clarify. >=20 > If you are saying that ABSOLUTELY NO TE information may be=20 > exchanged between areas, then I wonder how an ingress LSR can=20 > know the reachability to the egress (let alone the=20 > availability of suitable paths) when areas have more than one=20 > ABR. (Note that TE addresses are not necessarily routable!) No, we are not saying that. What we only want to preclude is the leaking = of=20 TE information related to bandwidth availability, including summarized = TE information because this definitely does not scale: Let's assume that there are N distinct paths from ABR A to a destination = X, each with a distinct bandwidth and distinct admin-group (a path admin group being expressed as a logical = AND of the link admin groups along the path) How can you summarize such topology ? Actually you need to advertise N = virtual links, each with a distinct admin-group and available bandwidth. Note that in return, we don't preclude the leaking of static TE = information related to LSR properties (such as PCE capabilities, TE = router ids...), Provided that there is no impact on the IGP. We are going to clarify that in next revision (01 posted next week)), = and your comments are highly welcome. =20 >=20 > I would have a problem with the requirements draft if it is=20 > precluding ALL exchange of TE information between areas. A=20 > more appropriate requirement would describe scalability and=20 > impact on existing operation of routing protocols, but would=20 > not constrain the solution in this way.=20 >=20 Yes this would be an approach, but as we consider that TE summarization = does not scale what about not precluding it directly in the requirement draft ? Note that this is a strong requirement expressed by 6 distinct ISPs. > . . . . .=20 >=20 > Can you tell me the status of this draft? Is it still alive=20 > in the TEWG? Is TEWG working on it? When is it scheduled to=20 > be completed?=20 This is a WG document of the TEWG, it was approved in March and TEWG is = still working on it. Cheers, JL >=20 > Thanks, > Adrian >=20 Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 23 Apr 2004 15:01:35 +0000 From: "Adrian Farrel" To: jeanlouis.leroux@francetelecom.com, ccamp@ops.ietf.org Cc: adrian@olddog.co.uk Reply-To: adrian@olddog.co.uk Subject: Re: Proposed strategy for Inter-area/AS Date: Fri, 23 Apr 2004 16:01:09 +0100 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: Hi, Thanks for clarifying. See below... >> > Requirement drafts clearly point out that routing (IGP, EGP) >> > extensions should be avoided, except some minor extensions to >> > advertise static parameters such as PCS capabilities for instance >> > (addressed in point 5). >> >> I am not sure that I can find any text in the two TEWG drafts >> that actually says what you suggest. > In the inter-area requirement draft, we clearly point out that > information propagation for path-selection should continue to be > localized and that leaking of TE link information across areas MUST be > precluded (section 5.3.1). > Note that this includes any summarized/aggregated TE link information. > I agree that this is not clear in current version, we will clarify in > next revision. How right you are :-) The draft currently says... The solution MUST entirely preserve the concept of IGP hierarchy. In other words, flooding of TE link information across areas MUST be precluded. I took "flooding" to be a more free distibution of information that "leaking". For example, I would consider that the Summary LSA is "leaking" routing information from one LSA to another, but it is not flooding that information. If you are saying that ABSOLUTELY NO TE information may be exchanged between areas, then I wonder how an ingress LSR can know the reachability to the egress (let alone the availability of suitable paths) when areas have more than one ABR. (Note that TE addresses are not necessarily routable!) I would have a problem with the requirements draft if it is precluding ALL exchange of TE information between areas. A more appropriate requirement would describe scalability and impact on existing operation of routing protocols, but would not constrain the solution in this way. . . . . . Can you tell me the status of this draft? Is it still alive in the TEWG? Is TEWG working on it? When is it scheduled to be completed? Thanks, Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 23 Apr 2004 14:24:13 +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 : Proposed strategy for Inter-area/AS Date: Fri, 23 Apr 2004 16:23:53 +0200 Message-ID: Thread-Topic: Proposed strategy for Inter-area/AS Thread-Index: AcQpKGS28kTTVzLmTJyiP5niXdTdxwABO6lQ From: "LE ROUX Jean-Louis FTRD/DAC/LAN" To: , Adrian, See inline > -----Message d'origine----- > De : Adrian Farrel [mailto:olddog@clara.co.uk]=20 > Envoy=E9 : vendredi 23 avril 2004 13:45 > =C0 : LE ROUX Jean-Louis FTRD/DAC/LAN; ccamp@ops.ietf.org > Cc : adrian@olddog.co.uk > Objet : Re: Proposed strategy for Inter-area/AS >=20 >=20 >=20 > Jean-Louis=20 >=20 > > I think this is a good strategy. >=20 > Thanks!=20 >=20 > I think we're pretty close to agreement on the points you=20 > raise. It may not have been apparent from my original email=20 > that I am NOT=20 > suggesting the work in one phase must complete before the=20 > work on the next=20 > phase can start. I am, however, saying that I expect the work=20 > to start in=20 > the order shown. > This is not unreasonable and should reflect the natural=20 > processes anyway.=20 OK >=20 > > I have two comments: > > > > 1) As already mentionned by Vishal, we cannot, > > IMHO, decorrelate 6 from 1, 2 3 and 5. > > -The support of additional functions may require important > > modifications, if they are not taken into account during the > > initial step of specifications. > >-Path Reoptimization is a MUST requirement and Path diversity is a =20 > >SHOULD requirement ( inter-area and inter-as reqt drafts). So we =20 > >should not address them as advanced functions, but rather as base =20 > >functions of the inter-area/AS tool-kit. > > > > 2) I'm not sure to well understand what do you put in 3. > > What do you exaclty mean by routing model, and how do you=20 > distinguish=20 > > it from the path computation model ? >=20 > Perhaps I should have said "distibution of TE and other=20 > information by the routing protocol or by other means". This=20 > is not path computation.=20 >=20 > > Requirement drafts clearly point out that routing (IGP, EGP)=20 > > extensions should be avoided, except some minor extensions to=20 > > advertise static parameters such as PCS capabilities for instance=20 > > (addressed in point 5). >=20 > I am not sure that I can find any text in the two TEWG drafts=20 > that actually=20 > says what you suggest. > There are comments on scalability which are, of course,=20 > related. There are also lots of comments about TE aggregation=20 > which might be=20 > considered as extensions.=20 > Regardless of how or where the path is computed the full=20 > system must have=20 > visibility across the whole of the system. This may be=20 > compartmentalised and=20 > restricted to domains relying on crankback, it may use=20 > cooperative PCEs, it=20 > may use some leakage of (aggregated) TE information.=20 In the inter-area requirement draft, we clearly point out that = information=20 propagation for path-selection should continue to be localized and that = leaking of TE link information across areas MUST be precluded (section 5.3.1).=20 Note that this includes any summarized/aggregated TE link information.=20 I agree that this is not clear in current version, we will clarify in = next revision. Cheers JL > What is=20 > up for debate=20 > is closely linked to the choice of computation point(s) and=20 > focuses on what=20 > information is distributed and how.=20 >=20 > > Hope this will help. >=20 > Very much appreciate your support and opinions.=20 >=20 > Cheers, > Adrian=20 >=20 >=20 Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 23 Apr 2004 14:16:43 +0000 Message-ID: <53F74F5A7B94D511841C00B0D0AB16F80287092A@baker.datcon.co.uk> From: Nic Neate To: Movaz Networks - Louis Berger Cc: Movaz Networks - Igor Bryskin , adrian@olddog.co.uk, dimitri.papadimitriou@alcatel.be, ccamp@ops.ietf.org, jplang@ieee.org, yakov@juniper.net Subject: RE: The ASSOCIATION object usage in draft-berger-ccamp-gmpls-segm ent-recovery-00 Date: Fri, 23 Apr 2004 15:14:58 +0100 MIME-Version: 1.0 Content-Type: text/plain That's clarified the ASSOCIATION usage for me, thanks (I was thinking the Association ID had to identify an LSP, not just another ASSOCIATION object). I'm willing to conceed that 64k associations is probably enough. To reiterate my primary question though, is there a strong reason that the recovery LSPs have to be in a different session to the protected LSP? If you simply disagree that there's any issue, or believe the solution you've presented to be the simplest, then fine. Thanks, Nic -----Original Message----- From: Movaz Networks - Louis Berger Sent: Friday, April 23, 2004 1:32 PM To: Nic Neate Cc: Movaz Networks - Louis Berger; Movaz Networks - Igor Bryskin; adrian@olddog.co.uk; dimitri.papadimitriou@alcatel.be; ccamp@ops.ietf.org; jplang@ieee.org; yakov@juniper.net Subject: Re: The ASSOCIATION object usage in draft-berger-ccamp-gmpls-segment-recovery-00 Nic, Note that the 16 bits are scoped within the association source (IP address). So there is really 48 bits in the association ID. Do you belive that 64K associations per IP address is insufficient??? Lou At 08:10 AM 4/23/2004 -0400, Nic Neate wrote: >The object is then used in draft-berger-ccamp-gmpls-segment-recovery-00 to >associate LSPs in different sessions - the segment recovery LSPs and the LSP >they are protecting. See the following quote from section 2. > > ... Each segment recovery LSP is > signaled as an independent LSP. Specifically, the Sender_Template > object uses the IP address of the node originating the recovery path, > e.g., node C in the topology shown above, and the Session object > contains the IP address of the node terminating the recovery path ... > > When [FRR] isn't being used, the association between segment recovery > LSPs with other LSPs is indicated using the Association object > defined in [E2E-RECOVERY]. The Association object is used to > associate recovery LSPs with the LSP they are protecting. > >Clearly 16 bits is not enough to identify the associated LSP unless we know >which session it's in. Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 23 Apr 2004 12:32:49 +0000 Message-Id: <6.0.3.0.2.20040423082835.04d1de78@mo-ex1> Date: Fri, 23 Apr 2004 08:32:25 -0400 To: "Nic Neate" From: Lou Berger Subject: Re: The ASSOCIATION object usage in draft-berger-ccamp-gmpls-segment-recovery-00 Cc: "Berger, Lou" , "Bryskin, Igor" , , , , , Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Nic, Note that the 16 bits are scoped within the association source (IP address). So there is really 48 bits in the association ID. Do you belive that 64K associations per IP address is insufficient??? Lou At 08:10 AM 4/23/2004 -0400, Nic Neate wrote: >The object is then used in draft-berger-ccamp-gmpls-segment-recovery-00 to >associate LSPs in different sessions - the segment recovery LSPs and the LSP >they are protecting. See the following quote from section 2. > > ... Each segment recovery LSP is > signaled as an independent LSP. Specifically, the Sender_Template > object uses the IP address of the node originating the recovery path, > e.g., node C in the topology shown above, and the Session object > contains the IP address of the node terminating the recovery path ... > > When [FRR] isn't being used, the association between segment recovery > LSPs with other LSPs is indicated using the Association object > defined in [E2E-RECOVERY]. The Association object is used to > associate recovery LSPs with the LSP they are protecting. > >Clearly 16 bits is not enough to identify the associated LSP unless we know >which session it's in. Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 23 Apr 2004 12:25:57 +0000 Message-ID: <53F74F5A7B94D511841C00B0D0AB16F802870927@baker.datcon.co.uk> From: Nic Neate To: Movaz Networks - Louis Berger , Movaz Networks - Igor Bryskin , "'adrian@olddog.co.uk'" , "'dimitri.papadimitriou@alcatel.be'" Cc: ccamp@ops.ietf.org, "'jplang@ieee.org'" , "'yakov@juniper.net'" Subject: The ASSOCIATION object usage in draft-berger-ccamp-gmpls-segment- recovery-00 Date: Fri, 23 Apr 2004 13:10:10 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Hi folks, I have a question concerning the usage of the new ASSOCIATION object in draft-berger-ccamp-gmpls-segment-recovery-00. This object is defined in draft-ietf-ccamp-gmpls-recovery-e2e-signaling-00, which only uses it to associate two LSPs in the same session. Consequently, it is defined with a 16 bit Association ID to identify the LSP it is associating with (filled in as the LSP ID of that LSP). The object is then used in draft-berger-ccamp-gmpls-segment-recovery-00 to associate LSPs in different sessions - the segment recovery LSPs and the LSP they are protecting. See the following quote from section 2. ... Each segment recovery LSP is signaled as an independent LSP. Specifically, the Sender_Template object uses the IP address of the node originating the recovery path, e.g., node C in the topology shown above, and the Session object contains the IP address of the node terminating the recovery path ... When [FRR] isn't being used, the association between segment recovery LSPs with other LSPs is indicated using the Association object defined in [E2E-RECOVERY]. The Association object is used to associate recovery LSPs with the LSP they are protecting. Clearly 16 bits is not enough to identify the associated LSP unless we know which session it's in. My question, then, is is it really necessary for the recovery LSPs to be in different sessions from the LSP they are protecting? Would it not be possible to do this in a more similar way to Fast Reroute, where the backup LSPs are in the same session as the protected LSP? The reason this concerns me is that historically (as far as I am aware) LSPs in different sessions have always operated independently of each other. This draft takes protocol messages from an LSP in one session and propagates them along an LSP in a different session, removing that independence. While I can't see a reason why this can't work, I do see it as a significant complication to the protocol which we would do well to avoid. If it really is necessary for the recovery LSPs to be in different sessions then I think we need some text in the draft explaining exactly how the Association ID is used in this scenario. Please let me know what you think. Thanks, Nic Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 23 Apr 2004 12:10:15 +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 : Proposed strategy for Inter-area/AS Date: Fri, 23 Apr 2004 14:09:44 +0200 Message-ID: Thread-Topic: RE : Proposed strategy for Inter-area/AS Thread-Index: AcQiGDZlzpgx+qCBT0+NDcGUHVJAsgGfCgZwABxJAgAACZWi4A== From: "LE ROUX Jean-Louis FTRD/DAC/LAN" To: Hi Adrian and Kireeti, I think this is a good strategy. I have two comments: 1) As already mentionned by Vishal, we cannot, IMHO, decorrelate 6 from = 1, 2 3 and 5. -The support of additional functions may require important = modifications, if they are not taken into account during the initial = step of specifications. -Path Reoptimization is a MUST requirement and Path diversity is a = SHOULD requirement ( inter-area and inter-as reqt drafts). So we should = not address them as advanced functions, but rather as base functions of = the inter-area/AS tool-kit. 2) I'm not sure to well understand what do you put in 3. What do you exaclty mean by routing model, and how do you distinguish it = from the path computation model ? Requirement drafts clearly point out = that routing (IGP, EGP) extensions should be avoided, except some minor = extensions to advertise static parameters such as PCS capabilities for = instance (addressed in point 5).=20 Hope this will help. Regards, JL > -----Message d'origine----- > De : owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] De la=20 > part de Adrian Farrel Envoy=E9 : mercredi 14 avril 2004 13:50 > =C0 : ccamp@ops.ietf.org > Objet : Proposed strategy for Inter-area/AS >=20 >=20 > All, >=20 > JP and Arthi have done a fine job of pulling together all of the=20 > threads of inter-area and inter-AS solutions into a single draft. This = > gives us a single place to look for information, but the resulting=20 > draft is (of course) quite large. As additional details need to be=20 > filled in, it is clear that this draft would only grow and that would=20 > make it unusably large. >=20 > So, we are proposing to use the material in the draft to produce a=20 > series of detailed drafts that would, over time, replace JP and=20 > Arthi's document. >=20 > 1. Framework for Interdomain MPLS and GMPLS > A short draft that introduces the routing and signaling options > for multi-domain LSPs, and explains the options for path > computation. > This does not describe applicability or any necessary protocol > procedures or extensions. > Material will be taken from draft-vasseur-ccamp-inter-area-as-te > and draft-kompella-mpls-multiarea-te as required. > Authors: Adrian, JP, Arthi > Due date: End of April. >=20 > 2. Individual signaling extension drafts > If any one of the signaling approaches described in 1. > requires additional protocol procedures or extensions > then a single draft will be written for each. > The base assumption is that such a draft will only be > written if there someone planning to implement and > deploy. > Authors: Dependent on extension > Due date: Aim for San Diego >=20 > 3. Individual routing extension drafts > There are two dimensions to this: > - the different routing protocols (IGPs and EGPs) > - the different solution models > The aim should be to have one draft per protocol to provide the > generic mechanisms, and one draft per model per protocol to > provide procedures and field values etc. > Note that path computation functions are described under point > 5, below. > As with the signaling extensions, this work will only be done=20 > once > we understand that there is a need *and* what is needed. > Authors: Again dependent on deployment plans > Due date: Slightly later than signaling work >=20 > 4. Applicability > A draft to explain when it is appropriate to use which model and > options. The aim is not to rubbish the opposition, but to say when > a particular model can/should be used. > Much of this material can already be found in > draft-vasseur-ccamp-inter-area-as-te, but it may need > some tidying up. > For political/expediency reasons this may result in multiple > applicability drafts in the first instance. > Authors: A supporter of each model > Due date: Quite soon - to accompany signaling extensions. >=20 > 5. Path computation > Some solution models call for a (or many) path computation > servers (PCS). This demands several functions: > - discovery of PCS by network elements > - communication protocol between PCS and network elements > - some regulation of computation technique to avoid looping etc. > At the moment we are discussing precisely where this work should > be done, but that should not stop us starting the work within=20 > CCAMP > since it is clearly related to the inter-area/AS solution. >=20 > 6. Advanced functions. > There are several advanced functions that will be required, but=20 > which > are not part of the immediate work. > - Path reoptimization > - Protection path diversity > - crankback > We expect that once the initial work has been done on > the solutions, it > will be possible to set out the requirements for these=20 > functions and to > develop solutions based on the many drafts that are=20 > already out there. >=20 > Comments please. >=20 > Thanks, > Adrian and Kireeti >=20 >=20 >=20 Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 23 Apr 2004 12:10:12 +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 : draft-ali-ccamp-rsvp-node-id-based-hello-01.txt as WG document? Date: Fri, 23 Apr 2004 14:09:11 +0200 Message-ID: Thread-Topic: RE : draft-ali-ccamp-rsvp-node-id-based-hello-01.txt as WG document? Thread-Index: AcQoORmMKxplggxkTKOq0ZlVCGBzawASjUVgACCEu9AACZiRQA== From: "LE ROUX Jean-Louis FTRD/DAC/LAN" To: Yes > -----Message d'origine----- > De : owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] De la=20 > part de Adrian Farrel Envoy=E9 : jeudi 22 avril 2004 09:04 > =C0 : ccamp@ops.ietf.org > Cc : adrian@olddog.co.uk > Objet : draft-ali-ccamp-rsvp-node-id-based-hello-01.txt as WG=20 > document? >=20 >=20 > All, >=20 > The authors of > http://www.ietf.org/internet-drafts/draft-ali-ccamp-rsvp-node- id-based-hello=20 -01.txt have re-positioned the draft as a BCP as discussed on the list. = They=20 have also included changes to address comments received on the list.=20 Can I take a poll on whether you think this work should be (and is ready = to=20 be) adopted by the WG.=20 You may go "hmmm" for yes, or "shhhh" for no. Alternatively, send a simple email to the list saying yes or no.=20 Thanks, Adrian=20 Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 23 Apr 2004 12:10:07 +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 : draft-dachille: Comments on topology summarization and optimality Date: Fri, 23 Apr 2004 14:09:29 +0200 Message-ID: Thread-Topic: RE : draft-dachille: Comments on topology summarization and optimality Thread-Index: AcQlF4XaRLQ1QOlbR2enPVG+sXDZtADbWGnQAB/6pbAACb8J4A== From: "LE ROUX Jean-Louis FTRD/DAC/LAN" To: Hi Vishal, This is a correct summary of the discussion we had during the Seoul = meeting. Just one clarification regarding comment iii,=20 You make the following routing assumption (section 4): "In the following we will assume that every border router, say B1,=20 that is directly attached to area X maintains = a summarized=20 topological view consisting of the exact intra-area = topology of X=20 plus several so called =F4virtual links=F6. Virtual = link are present=20 between the border routers of area X, say B2 B3 etc., = and the=20 possible destinations: they merely represent external = paths to remote=20 destinations that are reachable through some = inter-area path. Virtual=20 link might be assigned a cost" The question is how do you perform such TE topology summarization ?=20 More particularly how do you summarize information on link admin-groups, = which basically need to be taken into acount during path computation ? = Let's assume that there are N paths between an ABR an a destination, = each with a distinct avaialble bandwidth, and a distinct admin group (a = path admin group being expressed as a logical AND of the afinities of = each link in the path).=20 You then need to advertise N Virtual links, each with a distinct admin = group.=20 IMHO this does not scale and also compromises one of the main = motivations of IGP hierarchy, i.e. the containement of routing = information.=20 This is actually one of the reasons, in the inter-area requirement = draft, for precluding such leaking of summarized TE-link information = across areas. Actually you use this virtual topology, in 4.1 and 4.2, to select = downstream ABRs. IMHO your JSA approach can work independantly of the = method used to select downstream ABRs. Thus, you should IMHO let = downstream ABR selection beyond the scope of the draft, and remove all = text related to virtual topologies.=20 Regards, JL > -----Message d'origine----- > De : owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] De la=20 > part de Vishal Sharma Envoy=E9 : dimanche 18 avril 2004 09:17 > =C0 : CCAMP > Cc : LE ROUX Jean-Louis FTRD/DAC/LAN; Fabio Ricciato; Alessio=20 > D'Achille; Ugo Monaco; Marco Listanti > Objet : draft-dachille: Comments on topology summarization=20 > and optimality >=20 >=20 > Hi JL, >=20 > Thanks for your feedback on our draft/scheme during the > Seoul IETF. >=20 > As mentioned in an earlier email to the ML, before we address the=20 > various points made by folks who gave us their valuable feedback, we=20 > are summarizing their comments to ensure that > (a) we rightly understood their inputs :-), and (b) to help > people on the ML follow and contribute to the subsequent discussions. >=20 > After reviewing my notes from our discussions and discussing them with = > my co-authors, I have summarized your comments as below. >=20 > If I missed something or did not capture some of your=20 > questions/comments correctly, please do let us know. We will take this = > into account in providing our responses, and, later, in updating the=20 > document. >=20 > Best regards, > -Vishal >=20 > ********************************************************************* >=20 > Editorial: > i) Replace "area" --> "region" throughout, since you cover ASs as=20 > well. >=20 > ii) Note in the draft that the scheme is general and does more that=20 > merely helping with efficient backup path computation and setup. >=20 > Technical: > iii) The draft needs to make clear what is meant by a virtual=20 > topology, and what info. is used to create it. This is because it=20 > seems from a current reading of the draft that the virtual topology=20 > relies on info. about TE links and their bandwidth, but there is a=20 > strong requirement not to advertise TE link info. between areas. >=20 > iv) How does this approach differ from the PCS/PCE approach? Some=20 > comparison and contrasting would be useful. >=20 > v) You also suggested that one needn't be confined to carrying only=20 > one ARO. So for better optimality, one might carry multiple ARO's=20 > computed for the secondary path, and when the secondary is being set=20 > up, the ingress for the secondary could select one of the ARO segments = > for traversing it's area. This might lead to a more optimal setup than = > would otherwise be possible. >=20 > vi) Sec. 4.1 on inter-area is ok. >=20 > vii) However, for the section on inter-AS, you asked "how does the=20 > scheme computes the set of AS's that the diverse paths will use?" >=20 > viii) Do you need the optical island ID? > Even in the optical case, if one is using IP protocols, it is likely=20 > that OSFP/IS-IS areas/levels and ASs will be defined, so this then=20 > becomes the same as the inter-area/inter-AS cases. >=20 > ix) Mention that the scheme can work for IS-IS levels as well. (Note=20 > IS-IS levels can, in turn, have areas.) (One issue here is how does=20 > one identify IS-IS levels?) >=20 >=20 >=20 >=20 Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 23 Apr 2004 11:45:11 +0000 From: "Adrian Farrel" To: jeanlouis.leroux@francetelecom.com, ccamp@ops.ietf.org Cc: adrian@olddog.co.uk Reply-To: adrian@olddog.co.uk Subject: Re: Proposed strategy for Inter-area/AS Date: Fri, 23 Apr 2004 12:44:59 +0100 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: Jean-Louis > I think this is a good strategy. Thanks! I think we're pretty close to agreement on the points you raise. It may not have been apparent from my original email that I am NOT suggesting the work in one phase must complete before the work on the next phase can start. I am, however, saying that I expect the work to start in the order shown. This is not unreasonable and should reflect the natural processes anyway. > I have two comments: > > 1) As already mentionned by Vishal, we cannot, > IMHO, decorrelate 6 from 1, 2 3 and 5. > -The support of additional functions may require important > modifications, if they are not taken into account during the > initial step of specifications. >-Path Reoptimization is a MUST requirement and Path diversity is a > SHOULD requirement ( inter-area and inter-as reqt drafts). So we > should not address them as advanced functions, but rather as base > functions of the inter-area/AS tool-kit. > > 2) I'm not sure to well understand what do you put in 3. > What do you exaclty mean by routing model, and how do you > distinguish it from the path computation model ? Perhaps I should have said "distibution of TE and other information by the routing protocol or by other means". This is not path computation. > Requirement drafts clearly point out that routing (IGP, EGP) > extensions should be avoided, except some minor extensions to > advertise static parameters such as PCS capabilities for instance > (addressed in point 5). I am not sure that I can find any text in the two TEWG drafts that actually says what you suggest. There are comments on scalability which are, of course, related. There are also lots of comments about TE aggregation which might be considered as extensions. Regardless of how or where the path is computed the full system must have visibility across the whole of the system. This may be compartmentalised and restricted to domains relying on crankback, it may use cooperative PCEs, it may use some leakage of (aggregated) TE information. What is up for debate is closely linked to the choice of computation point(s) and focuses on what information is distributed and how. > Hope this will help. Very much appreciate your support and opinions. Cheers, Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 23 Apr 2004 11:34:25 +0000 From: "Adrian Farrel" To: ospf@peach.ease.lsoft.com, ccamp@ops.ietf.org, Venkata.Naidu@MARCONI.COM Cc: adrian@olddog.co.uk Reply-To: adrian@olddog.co.uk Subject: Re: OSPF TLVs Date: Fri, 23 Apr 2004 12:33:40 +0100 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: Hi Venkata, > -> RFC3630 implies that the actual space in the message is a > -> multiple of 32bits regardless of the value of the length field, > -> and that the length field represents the length of the value field(s). > -> > -> draft-ietf-ccamp-ospf-gmpls-extensions-12 does not > -> contradict this. That is, the field labeled "Padding" is > -> actually a value field of the TLV. (It might have been > -> better labeled as "Reserved"). As the text says... > -> > -> The padding is 3 octets, and is used to make the > -> Interface Switching Capability Descriptor sub-TLV > -> 32-bits aligned. It SHOULD be set to zero by the > -> sender and SHOULD be ignored by the receiver. > -> > -> That is, it makes the sub-TLV length up to a 32-bit multiple. > > I agree with Acee. You confused me. Sorry. Not my aim to spoil your day. > We have two cases here: > > 1. Actual (Value) length carried in a TLV is explicit by the > "Length" field. In this case, padding/reserved space is > implicitly ignored based on next boundary math (here 32-bit) > if any, so that parser jump to next TLV with out ambiguity. No. This is NOT what 3630 says. 3630 says that if a TLV is not a multiple of 32-bits, padding is inserted between it and the next TLV. It does not comment on the contents of the TLV. For example, if a TLV had five reserved bytes at the end, we would not modify this so that it had only one reserved byte. In other words, the contents of the TLV are opaque to the TLV packing rules. The length field specifies the length of the V without saying anything about the format of the data in the V. All packing can be performed using the length field. > 2. Actual (Value) length carried in a TLV is implicit by the > "Type" field. In this case, the "Length" field signifies > total (actual + pad/reserved). So that, parser can jump > to next TLV with out ambiguity. > > I thought, (1) is what followed by TE community. I think, > you are supporting (2). I am? Length may be defined by type (with respect to documentation), but it is not implicit. That is, the length field ALWAYS gives the length of the V field. If the V field contains explicit padding or reserved bits, they are included in the length. In summary, there is a distinction between how TLVs are defined and how the message building rules are defined. The draft gives the former, the RFC gives the latter. > I don't argue which one is the correct > solution, but, it would be nice to synchronize same semantics > across all TE TLVs. I think there is no discrepency across these TLVs. > As a side note, I don't understand why padding is in place for > every granular TLV (sub-sub-TLV etc). Don't you think it is > efficient and bandwidth saving, if padding is used only at the > highest level of TLV/LSA. I don't understand why we try to > achieve 32-bit boundary for every TLV? I have no comments on the history of why this is what is done in OSPF, but it is. From an implementation perspective, 32-bit alignment may be nice. > Given that machines are > so fast, the difference in clock cycles in fetching a 32-bit > vs 8-bit number is not significant in processing speed (at least > with modern processors). Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 23 Apr 2004 10:08:26 +0000 Message-ID: <4088EB36.7080603@alcatel.be> Date: Fri, 23 Apr 2004 12:08:54 +0200 From: Dimitri.Papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.5) Gecko/20030925 MIME-Version: 1.0 To: adrian@olddog.co.uk Cc: v.sharma@ieee.org, ccamp@ops.ietf.org, lberger@movaz.com Subject: Re: Status of draft-ietf-ccamp-alarm-spec-00 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed Adrian Farrel wrote: > A few additional comments. > >> > -- Also, are there interactions/race conditions between this alarm >> > communication with other mechanisms conveying problems along an LSP? >> > Some discussion in the doc. would be valuable. > > > Nothing to discuss. Unless you can suggest a problem that we should > be worried about. reason why i think this should be strictly speaking part of an applicability statement document (if such issue arise, anyway) >> > -- The document mentions briefly that the LSP state must >> > be retained for the communicated alarm information to be useful. >> > >> > I think this is an important point, and worth expanding on in the doc. >> > I don't think there is any discussion right now of how one might >> > ensure that state has not been torn down by the time the alarm >> > information is correlated and ready to be communicated upstream >> > and downstream. > > > If the state has been torn down, there is clearly no LSP about which to > communicate alarm state. this could be added (i didn't suggest to enter into more than this) >> > -- And, can the document provide some examples of the types of alarms >> > it is talking about/referring to? I think this will help a reader >> > understand better the why behind this approach. >> examples are illustrative anyway, if any they would be included in >> appendix, imho such examples would better fit in an applicability >> statement document > > > Agreed. > Besides, there is no limit to the alarms that this could be applied to. > Very specifically - any alarm that impacts or is related to the LSP. agreed > Thanks, > Adrian -- Papadimitriou Dimitri E-mail : dimitri.papadimitriou@alcatel.be E-mail : dpapadimitriou@psg.com Webpage: http://psg.com/~dpapadimitriou/ Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium Phone : +32 3 240-8491 Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 23 Apr 2004 09:57:49 +0000 From: "Adrian Farrel" To: Dimitri.Papadimitriou@alcatel.be, v.sharma@ieee.org Cc: adrian@olddog.co.uk, ccamp@ops.ietf.org, lberger@movaz.com Reply-To: adrian@olddog.co.uk Subject: Re: Status of draft-ietf-ccamp-alarm-spec-00 Date: Fri, 23 Apr 2004 10:57:16 +0100 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: A few additional comments. > > -- Also, are there interactions/race conditions between this alarm > > communication with other mechanisms conveying problems along an LSP? > > Some discussion in the doc. would be valuable. Nothing to discuss. Unless you can suggest a problem that we should be worried about. > > -- The document mentions briefly that the LSP state must > > be retained for the communicated alarm information to be useful. > > > > I think this is an important point, and worth expanding on in the doc. > > I don't think there is any discussion right now of how one might > > ensure that state has not been torn down by the time the alarm > > information is correlated and ready to be communicated upstream > > and downstream. If the state has been torn down, there is clearly no LSP about which to communicate alarm state. > > -- And, can the document provide some examples of the types of alarms > > it is talking about/referring to? I think this will help a reader > > understand better the why behind this approach. > > examples are illustrative anyway, if any they would be included in > appendix, imho such examples would better fit in an applicability > statement document Agreed. Besides, there is no limit to the alarms that this could be applied to. Very specifically - any alarm that impacts or is related to the LSP. Thanks, Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 23 Apr 2004 09:27:30 +0000 Message-ID: <4088E15D.4000102@alcatel.be> Date: Fri, 23 Apr 2004 11:26:53 +0200 From: Dimitri.Papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.5) Gecko/20030925 MIME-Version: 1.0 To: v.sharma@ieee.org Cc: adrian@olddog.co.uk, ccamp@ops.ietf.org, lberger@movaz.com Subject: Re: Status of draft-ietf-ccamp-alarm-spec-00 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed vishal - some responses to the mail you were pointing out: > Hi Lou, > > While the document describes well _what_ it is doing, I think it is > not clear on why this needs to be done, why it is important > (motivation), what requirements it is satisfying, and how they relate > to the current WG charter. > (Note this does not mean that the problem may not be important or > should not be in the charter.) as said in section 1 "The extensions defined in this document allow an operator or a software component to obtain a full list of current alarms associated with all of the resources used to support an LSP. The extensions also ensure that this list is kept up-to-date and synchronized with the real alarm status in the network. Finally, the extensions make the list available at every node traversed by an LSP." what else do you see useful as text ? > Also, in response to your explanation below, it is not really clear > that alarm reporting is a component of path setup. Seems to me that > the two are decoupled. the document doesn't say it a component of the "setup" - procedures are described in section 3.2.2 > And, the "determing the actual route and other properties" phrase > mentioned in the CCAMP WG charter I thought is aimed at addressing the > issue of tunnel tracing (and determing LSP properties therefrom), > rather than reporting alarms at specific nodes along the path of an > LSP. > > With regard to your question, here is some additional feedback > on the draft: > > -- The following phrase is actually unclear, as I explain below. > > also: > > The communication of alarms within GMPLS does not imply any > modification in behavior of processing of alarms, or for the > communication of alarms outside of GMPLS. > > If there is no modification in the behavior of alarm processing, then > presumably there is already a way to monitor and process them, so how > (and with what) does this communication help? because as said in the introduction: " The extension described in this document defines how the alarm information associated with a GMPLS label-switched path (LSP) may be communicated along the path of the LSP. Communication both upstream and downstream is supported. The value in communicating such alarm information is that this information is then available at every node along the LSP for display and diagnostic purposes. " > (I have seen the few phrases in the document in Section 1, along the > lines of "there may be a desire to retain an LSP, particularly in > optical transport networks, and communicate > alarm information," but these do not say why.) > > -- The technique described in this draft relies on existing > techniques for monitoring and correlating alarms, and appears to > focus on the communication of this information along an LSP > path. > (While it may be argued that the latter is a "monitoring" > function, I am not sure how strong an argument that is, since > the monitoring (or most of it) has presumably happened before this > communication begins.) see procedure described in section 3.2.2 > -- Also, are there interactions/race conditions between this alarm > communication with other mechanisms conveying problems along an LSP? > Some discussion in the doc. would be valuable. > > -- The document mentions briefly that the LSP state must > be retained for the communicated alarm information to be useful. > > I think this is an important point, and worth expanding on in the doc. > I don't think there is any discussion right now of how one might > ensure that state has not been torn down by the time the alarm > information is correlated and ready to be communicated upstream > and downstream. agreed that as part of the last call process some text concerning the two above point might be clarifying even if strictly speaking the first one should be part of an applicability statement document > -- And, can the document provide some examples of the types of alarms > it is talking about/referring to? I think this will help a reader > understand better the why behind this approach. examples are illustrative anyway, if any they would be included in appendix, imho such examples would better fit in an applicability statement document > -- Finally, I wasn't sure if the issue of enumeration dicussed > with Tom Petch and Bert in Nov. was solved. (I saw that the draft > refers to GR833 for Error String enumerations and to the ALARM-MIB > for the Error Codes field.) yes, it is. > So these are my thoughts and feedback to the authors and WG. > It may be good to hear from some other WG participants who have also > read the document. > > -Vishal Vishal Sharma wrote: > Adrian, > > In discussions on this draft about a month ago, upon request from > the authors, I had provided some specific feedback to them > http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00184.html > > Since the document was submitted as "draft-ietf" soon thereafter > without any changes, I don't think these changes/comments have > been addressed in the document thus far. > > -Vishal > > >>-----Original Message----- >>From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On >>Behalf Of Adrian Farrel >>Sent: Thursday, April 22, 2004 1:57 AM >>To: ccamp@ops.ietf.org >>Cc: adrian@olddog.co.uk; lberger@movaz.com >>Subject: Status of draft-ietf-ccamp-alarm-spec-00 >> >> >>All, >> >>Despite its low revision number, this work is actually quite >>mature and has >>seen some early implementation. >> >>I would like to get a sense from the working group for whether they think >>this draft has been sufficiently developed to be moved to last call. >> >>Hints >> - I think it is ready for working group last call (but I'm an author) >> - If you don't think it is ready, you MUST say what your issues with the >>draft are. "Not discussed enough" is not a real reason. >> >>Thanks, >>Adrian > > -- Papadimitriou Dimitri E-mail : dimitri.papadimitriou@alcatel.be E-mail : dpapadimitriou@psg.com Webpage: http://psg.com/~dpapadimitriou/ Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium Phone : +32 3 240-8491 Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 23 Apr 2004 06:21:23 +0000 Reply-To: From: "Vishal Sharma" To: , Cc: Subject: RE: Status of draft-ietf-ccamp-alarm-spec-00 Date: Thu, 22 Apr 2004 23:20:50 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Adrian, In discussions on this draft about a month ago, upon request from the authors, I had provided some specific feedback to them http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00184.html Since the document was submitted as "draft-ietf" soon thereafter without any changes, I don't think these changes/comments have been addressed in the document thus far. -Vishal > -----Original Message----- > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On > Behalf Of Adrian Farrel > Sent: Thursday, April 22, 2004 1:57 AM > To: ccamp@ops.ietf.org > Cc: adrian@olddog.co.uk; lberger@movaz.com > Subject: Status of draft-ietf-ccamp-alarm-spec-00 > > > All, > > Despite its low revision number, this work is actually quite > mature and has > seen some early implementation. > > I would like to get a sense from the working group for whether they think > this draft has been sufficiently developed to be moved to last call. > > Hints > - I think it is ready for working group last call (but I'm an author) > - If you don't think it is ready, you MUST say what your issues with the > draft are. "Not discussed enough" is not a real reason. > > Thanks, > Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 23 Apr 2004 06:04:07 +0000 Reply-To: From: "Vishal Sharma" To: , Cc: "Fabio Ricciato" , "Ugo Monaco" , "Alessio D'Achille" , "Marco Listanti" Subject: RE: comments on ARO Date: Thu, 22 Apr 2004 23:03:45 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Stefaan, Thanks a lot for looking over the draft so carefully, and for your many detailed comments. While we will address the individual comments once we've digested them a bit (and in a separate email to avoid making this one too long :-)), let me try to address a couple of the most important points raised in your note below. 1) Recording only border nodes: Actually, if one only recorded border nodes, then upon signaling the secondary, the ingress border node for the secondary has no idea about the intra-area (or intra-AS) path of the primary (in its own area or AS), and therefore cannot ensure that the primary and secondary segments are in fact disjoint. This was a point I discussed with several other people (who initially proposed the same thing), including Arthi and Adrian, but we concluded, for the reason above, that merely recording the border nodes does not work for diversity. As a result, the ARO does, in fact, serve a very useful purpose. We can of course think more about what the trade-offs are, and see if there is some way to retain the main advantage of the proposal (diversity, joint optimization of both paths) while also recording less information. 2) With regard to optimizing only the path of the primary, I am not so sure about doing just that. I believe one can get into real problems if one does not constrain the path/cost of the secondary, with unduly long secondaries that will greatly limit the ability to setup further primaries (and secondaries). (This can be especially true of tranport networks, where one would set up very large bandwidth pipes, and optimizing their placement would be critical.) This scheme is optimizing jointly the cost of the primary and secondary, while ensuring diversity. I think you will find that most providers would be equally concerned with the cost/placement of the secondary path. Moreover, as I emphasized (and as discussed during CCAMP we wiil change the title and our intro. to reflect that), this is a: generic method for computing diverse paths that meets a variety of requirements: load balancing, multipe paths when a single one has insufficient capacity, multiple paths between VoIP gateways, etc. in all of which one would ideally be looking for paths with about equal length. Protection is just _one_ application of this scheme. 3) Re-optimization, crankback, and failure of secondary: I think the scheme works with all of these, and does not really conflict with any of them. With crankback, there should be no problem, whenever a crankback occurs on the primary, the secondary will also be recomputed at the ASBR/ABR to which there is crankback. With re-optimization, there are several options. -- Either default to sequential calculation, and use the XRO to re-optimize whichever of the two diverse paths requires re-optimization. (This might be an immediate response, while the below could be a more long-term response.) -- Or, if the goal really is joint optimization, the provider will have to setup a new set of diverse paths, and use make-before-break to transition the traffic over. -- If the secondary fails, again there are two options. Either use the XRO to perform another path setup (and, possibly, re-optimize the paths later), or use the joint optimization method above with make-before-break. 4) Relationship to XRO: As I mentioned in the Seoul presentation and also in our discussion, I think the XRO has many uses -- during computation after crankback, to enable adminstrative routing/re-routing, protection, etc. So I think the ARO and XRO are actually complementary. Regards, -Vishal > -----Original Message----- > From: stefaan.de_cnodder@alcatel.be > [mailto:stefaan.de_cnodder@alcatel.be] > Sent: Monday, April 19, 2004 12:08 PM > To: v.sharma@ieee.org > Cc: ccamp@ops.ietf.org > Subject: comments on ARO > > > > Hi Vishal, > > looking to draft-dachille, I have following comments: > > 1) Second paragraph in section 2 is not clear: "we will assume that > every > inter-area connection is duplicated". I understood from it that when > the > primary path follows Area1-Area2-Area3, then also the secondary has > to > follow this path but using other border nodes. But then from section > 4.2 I > understand that this is not an assumption? > > 2) step 2c on page 5: also E, G and H has to be pruned? It is also > not > clear which path is selected in area 3: I guess it is E-G-H for > primary and > F-H for secondary? > > 3) (!) page 7, about the trap-avoid reference: If fact it is just a > matter > of doing a good path calculation. If the primary is signaled and > border > nodes know that also a secondary has to be established, then it can > make > sure that the primary does not introduce such a trap. This assumes > that the > border node also has to know that a secondary has to be established. > This > is known by the presence of the ARO object but this does not mean > that at > the end, the ARO has to contain a full strict path of the secondary. > Border > nodes can expand the ARO by only including the border nodes for the > secondary. This means that the path calculation of the secondary is > not > anymore 100% bound to the primary. Also I would prefer that the ARO > is more > like a "hint" than the real path. With this, you do not have to > interaction > problems with re-optimization of secondary, crankback, ... For > instance: > when the secondary fails, it can be re-established ignoring the ARO. > Or > when the secondary can be re-optimzed between border nodes, then it > can be > done without impacting the primary or when the global > re-optimization is > possible, then the ARO can be simple ignored. > > I prefer to have the ARO only recording border nodes, and optionally > only > acting as a hint for the ingress LSR. The latter is less important > to me. > > 4) text below figure 3: primary has to be as short as possible. I do > not > care much about the secondary becuase it is almost never used. Also, > the > resources that it reserves can be shared with other secondaries. The > problem here is: what are you optimizing? According to me the path > of the > primary has to be optimized. > > 5) I do not understand why the ARO has to contain Area-Ids to > indicate the > route. If the ingress can put the "area-path" in the ARO, then it > can also > put the border nodes in the ERO of the secondary immediately. I.e. > refering > to figure 5: A knows that the path of the secondary is A1-A2-A5-A6. > How > does A know this? And if it is possible to let A know this > information, > then why could it also not know that the path is B1-B7-B9. If A can > do > this, then there is no need anymore for ARO. So the basic question > is: what > makes it easier for A to know A1-A2-A5-A6 instead of B1-B7-B9. This > means > to me that section 4.2 is not valid and that the ARO assumes that > the > "area-path" of primary and secondary is the same, which is true for > IGP > areas. See also comment 2. Maybe better to remove the AREA-IDs from > the > ARO. > > 6) step 1d page 14, second last line: how does the ABR know that B7 > has to > be used and not B8? > > 7) section 4.3: also describe the L-bit that is in the ERO > subobjects. > > 8) Is the Addr_len in for instance subobject 1 always 32 or can it > be > something else. I agree here that you should re-use ERO subobjects > but I > see that you are doing this. > > 9) Section 4.3.2.3, area_ID: types 3, 4 and 5 are defined but that > conflicts with what is described in the middle of page 19 where the > numbers > are 32, 33, 34. > > 10) the text in section 4.3.3 is rather confusing (the part in the > middle > of page 22, about pruning the nodes). Take figure 5, area 5: If B6 > has to > calculate a path from B6 to B10, then this path can pass via B5, B8, > B7 > and/or B9. This is because border nodes can also act as core nodes > at the > same time. This seems to be excluded from the draft. Is that > correct? > > 11) First refinement in section 5 about the cost of virtual links: > this has > been proposed before in > http://www.watersprings.org/pub/id/draft-venkatachalam-interarea-m >pls-te-02.txt >which is not a good idea: it only works for inter-IGP area and it >decreases >the scalability although it also has some advantages. >12) (!) There are conflicts with re-optimization, crankback, >re-establishement after failure of secondary LSP, ... because in all >of >these cases a working primary LSP also have to be re-signaled which >is not >good. Therefore it is better to let the ARO only record border >nodes, >and/or to use the ARO more as a hint for the secondary: using the >ARO in >the primary makes sure that a trap is avoided, and then it is up to >the >signaling of the secondary to find this path by using crankback, >.... There >is no need that the primary LSP also gives the path, it only has to >make >sure that there is a path. > >13) (!) The method seems not to be applicable for inter-AS >calculations. > >14) Following the classification of methods (ARO, XRO, PCE) that you >described earlier on ccamp based on parallel/sequential and >distributed/centralized computation, ARO looks more an alternative >for PCE than for XRO? In fact, would it be possible to combine >methods? It would be good to explain the interaction (if any) with >these other methods. > >Hope this helps, > >regards, > >Stefaan Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 23 Apr 2004 05:52:48 +0000 Reply-To: From: "Vishal Sharma" To: "Arthi Ayyangar" Cc: "CCAMP" , "Fabio Ricciato" , "Ugo Monaco" , "Alessio D'Achille" , "Marco Listanti" Subject: RE: draft-dachille: Comments on CAC issues Date: Thu, 22 Apr 2004 22:51:35 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Arthi, Thanks for your note. I've made a note of ii) referring to a general setup failure, and not just CAC failure. We'll take this into account when we post the responses in the next day or two. And, if you see any other points when reviewing your notes please do let us know. Thanks, -Vishal > -----Original Message----- > From: Arthi Ayyangar [mailto:arthi@juniper.net] > Sent: Wednesday, April 21, 2004 11:53 AM > To: Vishal Sharma > Cc: CCAMP; Fabio Ricciato; Ugo Monaco; Alessio D'Achille; Marco Listanti > Subject: Re: draft-dachille: Comments on CAC issues > > > Hi Vishal, > > Your summary regarding the CAC issues that I had raised basically looks > fine. I think for ii) I meant any kind of setup failure, I suspected CAC > failure to be more common due to i). I will also check my notes to see if > there were any other issues and get back to you. > > thanks, > -arthi > > > Thanks for your feedback on our draft/scheme during the > > Seoul IETF. > > > > As mentioned in the email to the ML and to JL, > > before addressing people's comments, we are summarizing them > > ensure that (a) we rightly understood the comments, and (b) to > > help people on the ML follow and contribute to the subsequent > > discussions. > > > > Upon looking at my notes from our discussions, I see that > > your main comments related to aspects of CAC in our scheme, > > and have summarized them below. > > > > Please let me know if you had any additional comments > > as well. We will take these into account in providing our > > responses, and, later, in updating the document. > > > > Best regards, > > -Vishal > > > > **************************************************************** > > > > i) What happens to bandwidth accounting during path set up? > > Since the border router that is the entry point for the primary path > > into an area/AS is the one that also computes the secondary > path, how does > > bandwidth accounting work to minimize CAC failures during the > actual setting > > up of the secondary? > > (Note that other nodes in the area would not immediately learn > of the amount > > of bandwidth that primary and secondary paths have consumed.) > > > > ii) What happens if the diverse path setup fails due to a > > CAC failure? (Namely, the set up of the second path fails.) > > To what does the scheme default then? > > > > iii) If I recall correctly, you also had a comment on the > > security of such schemes. That is, the problem of hiding info. > > about one area from other (remote) areas. > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 23 Apr 2004 05:52:40 +0000 Reply-To: From: "Vishal Sharma" To: "LE ROUX Jean-Louis FTRD/DAC/LAN" , "CCAMP" Cc: "Fabio Ricciato" , "Alessio D'Achille" , "Ugo Monaco" , "Marco Listanti" Subject: RE: RE : draft-dachille: Comments on topology summarization and optimality Date: Thu, 22 Apr 2004 22:51:37 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Hi JL, Thanks much for your note, and for confirming that we had captured your comments correctly. Your point about virtual links and topology summarization is well taken. We recognize that the explanations in Section 4.1 and 4.2, w.r.t. virtual links need to be made clearer (and we need to think more about whether we require them). This is a point we have been discussing internally, and really appreciate your inputs on it. We will respond to your other comments in the next day or two, and to this issue a bit later, after we discuss it further and clarify our thinking on it. In the meantime, if there are any other inputs you have, please do let us know. Regards, -Vishal > -----Original Message----- > From: LE ROUX Jean-Louis FTRD/DAC/LAN > [mailto:jeanlouis.leroux@francetelecom.com] > Sent: Thursday, April 22, 2004 11:04 AM > To: v.sharma@ieee.org; CCAMP > Cc: Fabio Ricciato; Alessio D'Achille; Ugo Monaco; Marco Listanti > Subject: RE : draft-dachille: Comments on topology summarization and > optimality > > > Hi Vishal, > > This is a correct summary of the discussion we had during the > Seoul meeting. > > Just one clarification regarding comment iii, > > You make the following routing assumption (section 4): > "In the following we will assume that every border router, say B1, > that is directly attached to area X > maintains a summarized > topological view consisting of the exact > intra-area topology of X > plus several so called ôvirtual linksö. Virtual > link are present > between the border routers of area X, say B2 B3 > etc., and the > possible destinations: they merely represent > external paths to remote > destinations that are reachable through some > inter-area path. Virtual > link might be assigned a cost" > > The question is how do you perform such TE topology summarization ? > More particularly how do you summarize information on link > admin-groups, which basically need to be taken into acount during > path computation ? > Let's assume that there are N paths between an ABR an a > destination, each with a distinct avaialble bandwidth, and a > distinct admin group (a path admin group being expressed as a > logical AND of the afinities of each link in the path). > You then need to advertise N Virtual links, each with a distinct > admin group. > IMHO this does not scale and also compromises one of the main > motivations of IGP hierarchy, i.e. the containement of routing > information. > This is actually one of the reasons, in the inter-area > requirement draft, for precluding such leaking of summarized > TE-link information across areas. > > Actually you use this virtual topology, in 4.1 and 4.2, to select > downstream ABRs. > IMHO your JSA approach can work independantly of the method used > to select downstream ABRs. > Thus, you should IMHO let downstream ABR selection beyond the > scope of the draft, and remove all text related to virtual topologies. > > Regards, > > JL > > > -----Message d'origine----- > > De : owner-ccamp@ops.ietf.org > > [mailto:owner-ccamp@ops.ietf.org] De la part de Vishal Sharma > > Envoyé : dimanche 18 avril 2004 09:17 > > À : CCAMP > > Cc : LE ROUX Jean-Louis FTRD/DAC/LAN; Fabio Ricciato; Alessio > > D'Achille; Ugo Monaco; Marco Listanti > > Objet : draft-dachille: Comments on topology summarization > > and optimality > > > > > > Hi JL, > > > > Thanks for your feedback on our draft/scheme during the > > Seoul IETF. > > > > As mentioned in an earlier email to the ML, before we address > > the various points made by folks who gave us their valuable > > feedback, we are summarizing their comments to ensure that > > (a) we rightly understood their inputs :-), and (b) to help > > people on the ML follow and contribute to the subsequent discussions. > > > > After reviewing my notes from our discussions and discussing > > them with my co-authors, I have summarized your comments as below. > > > > If I missed something or did not capture some of your > > questions/comments correctly, please do let us know. We will > > take this into account in providing our responses, and, > > later, in updating the document. > > > > Best regards, > > -Vishal > > > > ********************************************************************* > > > > Editorial: > > i) Replace "area" --> "region" throughout, since you cover > > ASs as well. > > > > ii) Note in the draft that the scheme is general and does > > more that merely helping with efficient backup path > > computation and setup. > > > > Technical: > > iii) The draft needs to make clear what is meant by a virtual > > topology, and what info. is used to create it. This is > > because it seems from a current reading of the draft that the > > virtual topology relies on info. about TE links and their > > bandwidth, but there is a strong requirement not to advertise > > TE link info. between areas. > > > > iv) How does this approach differ from the PCS/PCE approach? > > Some comparison and contrasting would be useful. > > > > v) You also suggested that one needn't be confined to > > carrying only one ARO. So for better optimality, one might > > carry multiple ARO's computed for the secondary path, and > > when the secondary is being set up, the ingress for the > > secondary could select one of the ARO segments for traversing > > it's area. This might lead to a more optimal setup than would > > otherwise be possible. > > > > vi) Sec. 4.1 on inter-area is ok. > > > > vii) However, for the section on inter-AS, you asked "how > > does the scheme computes the set of AS's that the diverse > > paths will use?" > > > > viii) Do you need the optical island ID? > > Even in the optical case, if one is using IP protocols, it is > > likely that OSFP/IS-IS areas/levels and ASs will be defined, > > so this then becomes the same as the inter-area/inter-AS cases. > > > > ix) Mention that the scheme can work for IS-IS levels as > > well. (Note IS-IS levels can, in turn, have areas.) (One > > issue here is how does one identify IS-IS levels?) > > > > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 22 Apr 2004 18:36:04 +0000 From: "Adrian Farrel" To: ccamp@ops.ietf.org, OSPF@PEACH.EASE.LSOFT.COM Cc: adrian@olddog.co.uk Reply-To: adrian@olddog.co.uk Subject: Re: Interface Switching Capability Descriptor sub-tlv length Date: Thu, 22 Apr 2004 19:34:14 +0100 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: This didn't seem to make it through to the CCAMp list. Acee wrote... > I'm copying the ccamp list since this is a CCAMP WG document. My > opinion is that the padding should not be included in the sub-TLV > length since this is stated explicitly in RFC 3630. I think you are wrong as follows Acee... I agree that the text could be a little confusing. RFC3630 implies that the actual space in the message is a multiple of 32bits regardless of the value of the length field, and that the length field represents the length of the value field(s). draft-ietf-ccamp-ospf-gmpls-extensions-12 does not contradict this. That is, the field labeled "Padding" is actually a value field of the TLV. (It might have been better labeled as "Reserved"). As the text says... The padding is 3 octets, and is used to make the Interface Switching Capability Descriptor sub-TLV 32-bits aligned. It SHOULD be set to zero by the sender and SHOULD be ignored by the receiver. That is, it makes the sub-TLV length up to a 32-bit multiple. Hope this clarifies. Adrian ----- Original Message ----- From: "Oliver Carter" To: Sent: Wednesday, April 21, 2004 2:35 PM Subject: Interface Switching Capability Descriptor sub-tlv length > Hi all, > > We have seen a minor interop problem with the Interface Switching > Capability Descriptor sub-tlv length value (defined in the > draft-ietf-ccamp-ospf-gmpls-extensions draft). In short, we are setting > the length so as to not include the pad bytes in the structure, and > another vendor is expecting the pad bytes to be included. As explained > below, the specifications are slightly ambiguous - can it be clarified > what should be filled out in the length value please? > > RFC 3630 Section 2.3.2 states that "The TLV is padded to four-octet > alignment; padding is not included in the length field (so a three octet > value would have a length of three, but the total size of the TLV would be > eight octets)." this would support the argument that the length should be > unpadded. > > However, draft-ietf-ccamp-ospf-gmpls-extensions-12, section 1.4 describes > the Interface Switching Capability Descriptor which states " The length is > the length of value field" and then shows the padding of the Switching > Capability field as part of the value field. This would support the > argument that the padding for this TLV should be included in the length > field. > > So which argument is correct, and can this be made explicit in the next > version of draft-ietf-ccamp-ospf-gmpls-extensions? > > Thanks > > Oli > > P.S. Apologies if this has already been resolved by the list - my > searching didn't turn up anything. Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 22 Apr 2004 17:31:35 +0000 Message-ID: <9D42C6E086250248810DCADA39CE7EFC011446F1@nimbus.chromisys.com> From: Ayan Banerjee To: ccamp@ops.ietf.org Subject: RE: draft-ali-ccamp-rsvp-node-id-based-hello-01.txt as WG documen t? Date: Thu, 22 Apr 2004 10:31:00 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Yes. -Ayan > -----Original Message----- > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On > Behalf Of Adrian Farrel > Sent: Thursday, April 22, 2004 12:04 AM > To: ccamp@ops.ietf.org > Cc: adrian@olddog.co.uk > Subject: draft-ali-ccamp-rsvp-node-id-based-hello-01.txt as WG document? > > > All, > > The authors of > http://www.ietf.org/internet-drafts/draft-ali-ccamp-rsvp-node-id-b > ased-hello > -01.txt have re-positioned the draft as a BCP as discussed on > the list. They > have also included changes to address comments received on the list. > > Can I take a poll on whether you think this work should be (and > is ready to > be) adopted by the WG. > > You may go "hmmm" for yes, or "shhhh" for no. > Alternatively, send a simple email to the list saying yes or no. > > Thanks, > Adrian > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 22 Apr 2004 17:02:56 +0000 Message-Id: <4.3.2.7.2.20040422122454.01d83df0@toque.cisco.com> Date: Thu, 22 Apr 2004 13:02:37 -0400 To: adrian@olddog.co.uk From: Anca Zamfir Subject: Re: Status of draft-ietf-ccamp-alarm-spec-00 Cc: ccamp@ops.ietf.org, adrian@olddog.co.uk, lberger@movaz.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Ready for WG last call. At 09:56 AM 4/22/2004 +0100, Adrian Farrel wrote: >All, >Despite its low revision number, this work is actually quite mature and has >seen some early implementation. >I would like to get a sense from the working group for whether they think >this draft has been sufficiently developed to be moved to last call. >Hints >- I think it is ready for working group last call (but I'm an author) >- If you don't think it is ready, you MUST say what your issues with the >draft are. "Not discussed enough" is not a real reason. >Thanks, >Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 22 Apr 2004 16:50:48 +0000 Reply-To: From: "Vishal Sharma" To: , Subject: RE: draft-ali-ccamp-rsvp-node-id-based-hello-01.txt as WG document? Date: Thu, 22 Apr 2004 09:47:30 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Yes. -Vishal > -----Original Message----- > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On > Behalf Of Adrian Farrel > Sent: Thursday, April 22, 2004 12:04 AM > To: ccamp@ops.ietf.org > Cc: adrian@olddog.co.uk > Subject: draft-ali-ccamp-rsvp-node-id-based-hello-01.txt as WG document? > > > All, > > The authors of > http://www.ietf.org/internet-drafts/draft-ali-ccamp-rsvp-node-id-b > ased-hello > -01.txt have re-positioned the draft as a BCP as discussed on > the list. They > have also included changes to address comments received on the list. > > Can I take a poll on whether you think this work should be (and > is ready to > be) adopted by the WG. > > You may go "hmmm" for yes, or "shhhh" for no. > Alternatively, send a simple email to the list saying yes or no. > > Thanks, > Adrian > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 22 Apr 2004 16:24:13 +0000 Message-Id: <4.3.2.7.2.20040422122345.01d33e90@toque.cisco.com> Date: Thu, 22 Apr 2004 12:23:55 -0400 To: adrian@olddog.co.uk From: Anca Zamfir Subject: Re: draft-ali-ccamp-rsvp-node-id-based-hello-01.txt as WG document? Cc: ccamp@ops.ietf.org, adrian@olddog.co.uk Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Yes. At 08:04 AM 4/22/2004 +0100, Adrian Farrel wrote: >All, >The authors of >http://www.ietf.org/internet-drafts/draft-ali-ccamp-rsvp-node-id-based-hello >-01.txt have re-positioned the draft as a BCP as discussed on the list. >They have also included changes to address comments received on the list. >Can I take a poll on whether you think this work should be (and is ready >to be) adopted by the WG. >You may go "hmmm" for yes, or "shhhh" for no. >Alternatively, send a simple email to the list saying yes or no. >Thanks, >Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 22 Apr 2004 15:55:48 +0000 Message-Id: <4.3.2.7.2.20040422115524.02c56b88@toque.cisco.com> Date: Thu, 22 Apr 2004 11:55:43 -0400 To: From: "Siva Sivabalan (msiva)" Subject: RE: draft-ali-ccamp-rsvp-node-id-based-hello-01.txt as WG document? Cc: , Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Yes. At 11:32 AM 4/22/2004 -0400, Danny Prairie wrote: >Yes. > > >All, > > > >The authors of > >http://www.ietf.org/internet-drafts/draft-ali-ccamp-rsvp->n >ode-id-based->hello > >-01.txt have re-positioned the draft as a BCP as discussed >on the list. >They > >have also included changes to address comments received on >the list. > > > >Can I take a poll on whether you think this work should be >(and is ready >to > >be) adopted by the WG. > > > >You may go "hmmm" for yes, or "shhhh" for no. > >Alternatively, send a simple email to the list saying yes >or no. > > > >Thanks, > >Adrian > >-- >Danny Prairie >dprairie@cisco.com Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 22 Apr 2004 15:53:06 +0000 Message-ID: <4087E9F0.CCA42BB2@alcatel.fr> Date: Thu, 22 Apr 2004 17:51:12 +0200 From: Martin.Vigoureux@alcatel.fr Reply-To: martin.vigoureux@alcatel.fr Organization: ALCATEL - R&I MIME-Version: 1.0 To: adrian@olddog.co.uk CC: ccamp@ops.ietf.org Subject: Re: draft-ali-ccamp-rsvp-node-id-based-hello-01.txt as WG document? Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable yes Adrian Farrel a =E9crit : >=20 > All, >=20 > The authors of > http://www.ietf.org/internet-drafts/draft-ali-ccamp-rsvp-node-id-based-he= llo > -01.txt have re-positioned the draft as a BCP as discussed on the list. = They > have also included changes to address comments received on the list. >=20 > Can I take a poll on whether you think this work should be (and is ready = to > be) adopted by the WG. >=20 > You may go "hmmm" for yes, or "shhhh" for no. > Alternatively, send a simple email to the list saying yes or no. >=20 > Thanks, > Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 22 Apr 2004 15:37:44 +0000 Message-ID: <9D42C6E086250248810DCADA39CE7EFC017AD75E@nimbus.chromisys.com> From: John Drake To: adrian@olddog.co.uk, ccamp@ops.ietf.org Subject: RE: draft-ali-ccamp-rsvp-node-id-based-hello-01.txt as WG documen t? Date: Thu, 22 Apr 2004 08:37:07 -0700 MIME-Version: 1.0 Content-Type: text/plain yes > -----Original Message----- > From: Adrian Farrel [mailto:olddog@clara.co.uk] > Sent: Thursday, April 22, 2004 12:04 AM > To: ccamp@ops.ietf.org > Cc: adrian@olddog.co.uk > Subject: draft-ali-ccamp-rsvp-node-id-based-hello-01.txt as WG document? > > All, > > The authors of > http://www.ietf.org/internet-drafts/draft-ali-ccamp-rsvp-node-id-based- > hello > -01.txt have re-positioned the draft as a BCP as discussed on the list. > They > have also included changes to address comments received on the list. > > Can I take a poll on whether you think this work should be (and is ready > to > be) adopted by the WG. > > You may go "hmmm" for yes, or "shhhh" for no. > Alternatively, send a simple email to the list saying yes or no. > > Thanks, > Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 22 Apr 2004 15:33:07 +0000 Reply-To: From: "Danny Prairie" To: Cc: Subject: RE: draft-ali-ccamp-rsvp-node-id-based-hello-01.txt as WG document? Date: Thu, 22 Apr 2004 11:32:37 -0400 Organization: Cisco Systems Message-ID: <00fa01c4287f$0a4ea3a0$82c12ca1@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yes. >All,=20 > >The authors of=20 >http://www.ietf.org/internet-drafts/draft-ali-ccamp-rsvp->n ode-id-based->hello=20 >-01.txt have re-positioned the draft as a BCP as discussed on the list. >They=20 >have also included changes to address comments received on the list.=20 > >Can I take a poll on whether you think this work should be (and is ready >to=20 >be) adopted by the WG.=20 > >You may go "hmmm" for yes, or "shhhh" for no. >Alternatively, send a simple email to the list saying yes or no.=20 > >Thanks, >Adrian -- Danny Prairie dprairie@cisco.com Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 22 Apr 2004 14:51:09 +0000 Message-Id: <4.3.2.7.2.20040422104952.0691a690@wells.cisco.com> Date: Thu, 22 Apr 2004 10:50:18 -0400 To: adrian@olddog.co.uk From: Jean Philippe Vasseur Subject: Re: Status of draft-ietf-ccamp-alarm-spec-00 Cc: ccamp@ops.ietf.org, adrian@olddog.co.uk, lberger@movaz.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Hi, I also think that the draft is ready for last call (and I'm not an author ;-)) JP. At 09:56 AM 4/22/2004 +0100, Adrian Farrel wrote: >All, >Despite its low revision number, this work is actually quite mature and has >seen some early implementation. >I would like to get a sense from the working group for whether they think >this draft has been sufficiently developed to be moved to last call. >Hints >- I think it is ready for working group last call (but I'm an author) >- If you don't think it is ready, you MUST say what your issues with the >draft are. "Not discussed enough" is not a real reason. >Thanks, >Adrian > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 22 Apr 2004 14:39:59 +0000 Message-Id: <4.3.2.7.2.20040422103827.047c7528@wells.cisco.com> Date: Thu, 22 Apr 2004 10:39:24 -0400 To: adrian@olddog.co.uk From: Jean Philippe Vasseur Subject: Re: draft-ali-ccamp-rsvp-node-id-based-hello-01.txt as WG document? Cc: ccamp@ops.ietf.org, adrian@olddog.co.uk Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Hi Adrian, Yes I think that this ID is a useful BCP and should be adopted as a WG doc. JP. At 08:04 AM 4/22/2004 +0100, Adrian Farrel wrote: >All, >The authors of >http://www.ietf.org/internet-drafts/draft-ali-ccamp-rsvp-node-id-based-hello >-01.txt have re-positioned the draft as a BCP as discussed on the list. >They have also included changes to address comments received on the list. >Can I take a poll on whether you think this work should be (and is ready >to be) adopted by the WG. >You may go "hmmm" for yes, or "shhhh" for no. >Alternatively, send a simple email to the list saying yes or no. >Thanks, >Adrian > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 22 Apr 2004 14:35:51 +0000 Message-ID: <4087BE2C.1090605@alcatel.be> Date: Thu, 22 Apr 2004 14:44:28 +0200 From: Dimitri.Papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.5) Gecko/20030925 MIME-Version: 1.0 To: adrian@olddog.co.uk Cc: ccamp@ops.ietf.org, lberger@movaz.com Subject: Re: Status of draft-ietf-ccamp-alarm-spec-00 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed > Despite its low revision number, this work is actually quite mature and has > seen some early implementation. > I would like to get a sense from the working group for whether they think > this draft has been sufficiently developed to be moved to last call. > Hints > - I think it is ready for working group last call (but I'm an author) i think it is ready for working group last call (but i'm an author) Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 22 Apr 2004 11:46:39 +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: Status of draft-ietf-ccamp-alarm-spec-00 Date: Thu, 22 Apr 2004 06:45:31 -0500 Message-ID: <9473683187ADC049A855ED2DA739ABCA02BA3B1D@KCCLUST06EVS1.ugd.att.com> Thread-Topic: Status of draft-ietf-ccamp-alarm-spec-00 Thread-Index: AcQoR/exL3Gj1LS1Ro6CJt2qDLbSRgAFzEYQ From: "Ash, Gerald R (Jerry), ALABS" To: , Cc: "Ash, Gerald R (Jerry), ALABS" , > I would like to get a sense from the working group for > whether they think this draft has been sufficiently > developed to be moved to last call. I think it's ready for last call. Jerry Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 22 Apr 2004 08:57:28 +0000 From: "Adrian Farrel" To: ccamp@ops.ietf.org Cc: adrian@olddog.co.uk, lberger@movaz.com Reply-To: adrian@olddog.co.uk Subject: Status of draft-ietf-ccamp-alarm-spec-00 Date: Thu, 22 Apr 2004 09:56:35 +0100 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: All, Despite its low revision number, this work is actually quite mature and has seen some early implementation. I would like to get a sense from the working group for whether they think this draft has been sufficiently developed to be moved to last call. Hints - I think it is ready for working group last call (but I'm an author) - If you don't think it is ready, you MUST say what your issues with the draft are. "Not discussed enough" is not a real reason. Thanks, Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 22 Apr 2004 07:05:45 +0000 From: "Adrian Farrel" To: ccamp@ops.ietf.org Cc: adrian@olddog.co.uk Reply-To: adrian@olddog.co.uk Subject: draft-ali-ccamp-rsvp-node-id-based-hello-01.txt as WG document? Date: Thu, 22 Apr 2004 08:04:23 +0100 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: All, The authors of http://www.ietf.org/internet-drafts/draft-ali-ccamp-rsvp-node-id-based-hello -01.txt have re-positioned the draft as a BCP as discussed on the list. They have also included changes to address comments received on the list. Can I take a poll on whether you think this work should be (and is ready to be) adopted by the WG. You may go "hmmm" for yes, or "shhhh" for no. Alternatively, send a simple email to the list saying yes or no. Thanks, Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 21 Apr 2004 18:54:35 +0000 Date: Wed, 21 Apr 2004 11:53:15 -0700 (PDT) From: Arthi Ayyangar To: Vishal Sharma cc: CCAMP , Fabio Ricciato , Ugo Monaco , "Alessio D'Achille" , Marco Listanti Subject: Re: draft-dachille: Comments on CAC issues Message-ID: <20040421114746.N96957@zircon.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi Vishal, Your summary regarding the CAC issues that I had raised basically looks fine. I think for ii) I meant any kind of setup failure, I suspected CAC failure to be more common due to i). I will also check my notes to see if there were any other issues and get back to you. thanks, -arthi > Thanks for your feedback on our draft/scheme during the > Seoul IETF. > > As mentioned in the email to the ML and to JL, > before addressing people's comments, we are summarizing them > ensure that (a) we rightly understood the comments, and (b) to > help people on the ML follow and contribute to the subsequent > discussions. > > Upon looking at my notes from our discussions, I see that > your main comments related to aspects of CAC in our scheme, > and have summarized them below. > > Please let me know if you had any additional comments > as well. We will take these into account in providing our > responses, and, later, in updating the document. > > Best regards, > -Vishal > > **************************************************************** > > i) What happens to bandwidth accounting during path set up? > Since the border router that is the entry point for the primary path > into an area/AS is the one that also computes the secondary path, how does > bandwidth accounting work to minimize CAC failures during the actual setting > up of the secondary? > (Note that other nodes in the area would not immediately learn of the amount > of bandwidth that primary and secondary paths have consumed.) > > ii) What happens if the diverse path setup fails due to a > CAC failure? (Namely, the set up of the second path fails.) > To what does the scheme default then? > > iii) If I recall correctly, you also had a comment on the > security of such schemes. That is, the problem of hiding info. > about one area from other (remote) areas. > > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 21 Apr 2004 17:04:43 +0000 Message-ID: <4086A7F0.9070604@alcatel.be> Date: Wed, 21 Apr 2004 18:57:20 +0200 From: Dimitri.Papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.5) Gecko/20030925 MIME-Version: 1.0 To: adrian@olddog.co.uk Cc: ccamp@ops.ietf.org, wesam.alanqar@mail.sprint.com, dbrungard@att.com, dmm@1-4-5.net, LyOng@ciena.com, jonathan.sadler@tellabs.com, sdshew@nortelnetworks.com Subject: Re: FW: I-D ACTION:draft-ietf-ccamp-gmpls-ason-routing-reqts-03.txt Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: base64 aGkgYWRyaWFuLCBtdWNoIHRoYW5rcyBmb3IgdGhlIGRldGFpbGVkIHJldmlldywgY2hhbmdlcyB3 aWxsIGJlIGluY2x1ZGVkIA0KaW4gdGhlIHVwZGF0ZWQgdmVyc2lvbiB0aGF0IHdpbGwgYmUgc3Vi bWl0dGVkIGF0IHRoZSBlbmQgb2YgdGhlIHdnIGxhc3QgDQpjYWxsIHByb2Nlc3MgLQ0KDQotLS0N Cg0KQWRyaWFuIEZhcnJlbCB3cm90ZToNCg0KPiBIaSBBU09OIFJvdXRpbmcgRFQsDQo+IFBsZWFz ZSBmaW5kIGF0dGFjaGVkIGEgbWFya2VkIHVwIGNvcHkgb2YgdGhlIGRyYWZ0Lg0KPiBBbGwgY2hh bmdlcyBhcmUgdHlwb2dyYXBoaWNhbCBvciBuaXRzLg0KPiBUaGFua3MsDQo+IEFkcmlhbg0KPiAt LS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tDQo+IEZyb206ICJLaXJlZXRpIEtvbXBlbGxhIiA8 a2lyZWV0aUBqdW5pcGVyLm5ldD4NCj4gVG86IDxjY2FtcEBvcHMuaWV0Zi5vcmc+DQo+IFNlbnQ6 IFRodXJzZGF5LCBBcHJpbCAxNSwgMjAwNCAxMjo0NiBBTQ0KPiBTdWJqZWN0OiBSZTogRlc6IEkt RCANCj4gQUNUSU9OOmRyYWZ0LWlldGYtY2NhbXAtZ21wbHMtYXNvbi1yb3V0aW5nLXJlcXRzLTAz LnR4dA0KPiANCj4+IEhpIEFsbCwNCj4+IE9uIFdlZCwgMTQgQXByIDIwMDQsIEJydW5nYXJkLCBE ZWJvcmFoIEEsIEFMQUJTIHdyb3RlOg0KPj4gPiBUaGUgQVNPTiBSb3V0aW5nIFJlcXRzIERUIGhh cyB1cGRhdGVkIHRoZSBmb2xsb3dpbmcgZHJhZnQgYmFzZWQgb24NCj4+ID4gSVRVIFExNC8xNSdz IExpYWlzb24gYW5kIENDQU1QIG1haWwgbGlzdCBjb21tZW50cy4NCj4+ID4NCj4+ID4gV2UgcmVj b21tZW5kIHRoaXMgZG9jdW1lbnQgYXMgcmVhZHkgZm9yIFdHIExhc3QgQ2FsbC4NCj4+IFRoaXMg Y29tbWVuY2VzIGEgdHdvLXdlZWsgV0cgTGFzdCBDYWxsIG9uIHRoZSBHTVBMUyBBU09OIHJvdXRp bmcNCj4+IHJlcXVpcmVtZW50cy4gIExhc3QgQ2FsbCBlbmRzIEFwcmlsIDI4dGgsIDVwbSBQRFQu ICBQbGVhc2Ugc2VuZCB5b3VyDQo+PiBjb21tZW50cyB0byB0aGUgbGlzdC4NCj4+IFRoZSBwcm9w b3NlZCBjYXRlZ29yeSBpcyBJbmZvcm1hdGlvbmFsLg0KPj4gS2lyZWV0aS4NCj4gDQo+IA0KPiAN Cj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tDQo+IA0KPiBDQ0FNUCBXb3JraW5nIEdyb3VwICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBXZXNhbSBBbGFucWFyIChTcHJpbnQpDQo+IEludGVybmV0IERyYWZ0 ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIERlYm9yYWggQnJ1bmdhcmQgKEFUVCkN Cj4gQ2F0ZWdvcnk6IEluZm9ybWF0aW9uYWwgICAgICAgICAgICAgICAgICAgIERhdmlkIE1leWVy IChDaXNjbyBTeXN0ZW1zKQ0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgTHluZG9uIE9uZyAoQ2llbmEpDQo+IEV4cGlyYXRpb24gRGF0ZTogT2N0 b2JlciAyMDA0ICAgICAgICAgIERpbWl0cmkgUGFwYWRpbWl0cmlvdSAoQWxjYXRlbCkNCj4gICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgSm9uYXRoYW4gU2FkbGVy IChUZWxsYWJzKQ0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgU3RlcGhlbiBTaGV3IChOb3J0ZWwpDQo+IA0KPiANCj4gICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgQXByaWwgMjAwNA0KPiAN Cj4gDQo+IA0KPiANCj4gICAgICAgICAgICAgIFJlcXVpcmVtZW50cyBmb3IgR2VuZXJhbGl6ZWQg TVBMUyAoR01QTFMpIFJvdXRpbmcNCj4gICAgICAgICAgICAgIGZvciBBdXRvbWF0aWNhbGx5IFN3 aXRjaGVkIE9wdGljYWwgTmV0d29yayAoQVNPTikNCj4gDQo+IA0KPiAgICAgICAgICAgICAgZHJh ZnQtaWV0Zi1jY2FtcC1nbXBscy1hc29uLXJvdXRpbmctcmVxdHMtMDMudHh0DQo+IA0KPiANCj4g DQo+IA0KPiBTdGF0dXMgb2YgdGhpcyBNZW1vDQo+IA0KPiANCj4gICAgVGhpcyBkb2N1bWVudCBp cyBhbiBJbnRlcm5ldC1EcmFmdCBhbmQgaXMgaW4gZnVsbCBjb25mb3JtYW5jZSB3aXRoDQo+ICAg IGFsbCBwcm92aXNpb25zIG9mIFNlY3Rpb24gMTAgb2YgUkZDLTIwMjYuDQo+IA0KPiANCj4gICAg SW50ZXJuZXQtRHJhZnRzIGFyZSB3b3JraW5nIGRvY3VtZW50cyBvZiB0aGUgSW50ZXJuZXQgRW5n aW5lZXJpbmcNCj4gICAgVGFzayBGb3JjZSAoSUVURiksIGl0cyBhcmVhcywgYW5kIGl0cyB3b3Jr aW5nIGdyb3Vwcy4gTm90ZSB0aGF0DQo+ICAgIG90aGVyIGdyb3VwcyBtYXkgYWxzbyBkaXN0cmli dXRlIHdvcmtpbmcgZG9jdW1lbnRzIGFzIEludGVybmV0LQ0KPiAgICBEcmFmdHMuIEludGVybmV0 LURyYWZ0cyBhcmUgZHJhZnQgZG9jdW1lbnRzIHZhbGlkIGZvciBhIG1heGltdW0gb2YNCj4gICAg c2l4IG1vbnRocyBhbmQgbWF5IGJlIHVwZGF0ZWQsIHJlcGxhY2VkLCBvciBvYnNvbGV0ZWQgYnkg b3RoZXINCj4gICAgZG9jdW1lbnRzIGF0IGFueSB0aW1lLiBJdCBpcyBpbmFwcHJvcHJpYXRlIHRv IHVzZSBJbnRlcm5ldC0gRHJhZnRzDQo+ICAgIGFzIHJlZmVyZW5jZSBtYXRlcmlhbCBvciB0byBj aXRlIHRoZW0gb3RoZXIgdGhhbiBhcyAid29yayBpbg0KPiAgICBwcm9ncmVzcy4iDQo+IA0KPiAN Cj4gICAgVGhlIGxpc3Qgb2YgY3VycmVudCBJbnRlcm5ldC1EcmFmdHMgY2FuIGJlIGFjY2Vzc2Vk IGF0DQo+ICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaWV0Zi8xaWQtYWJzdHJhY3RzLnR4dA0KPiAN Cj4gDQo+ICAgIFRoZSBsaXN0IG9mIEludGVybmV0LURyYWZ0IFNoYWRvdyBEaXJlY3RvcmllcyBj YW4gYmUgYWNjZXNzZWQgYXQNCj4gICAgaHR0cDovL3d3dy5pZXRmLm9yZy9zaGFkb3cuaHRtbC4N Cj4gDQo+IA0KPiANCj4gQWJzdHJhY3QNCj4gDQo+IA0KPiAgICBUaGUgR2VuZXJhbGl6ZWQgTVBM UyAoR01QTFMpIHN1aXRlIG9mIHByb3RvY29scyBoYXMgYmVlbiBkZWZpbmVkIHRvDQo+ICAgIGNv bnRyb2wgZGlmZmVyZW50IHN3aXRjaGluZyB0ZWNobm9sb2dpZXMgYXMgd2VsbCBhcyBkaWZmZXJl bnQNCj4gICAgYXBwbGljYXRpb25zLiBUaGVzZSBpbmNsdWRlIHN1cHBvcnQgZm9yIHJlcXVlc3Rp bmcgVERNIGNvbm5lY3Rpb25zDQo+ICAgIGluY2x1ZGluZyBTT05FVC9TREggYW5kIE9wdGljYWwg VHJhbnNwb3J0IE5ldHdvcmtzIChPVE5zKS4NCj4gDQo+IA0KPiAgICBUaGlzIGRvY3VtZW50IGNv bmNlbnRyYXRlcyBvbiB0aGUgcm91dGluZyByZXF1aXJlbWVudHMgb24gdGhlIEdNUExTDQo+ICAg IHN1aXRlIG9mIHByb3RvY29scyB0byBzdXBwb3J0IHRoZSBjYXBhYmlsaXRpZXMgYW5kIGZ1bmN0 aW9uYWxpdGllcw0KPiAgICBmb3IgYW4gQXV0b21hdGljYWxseSBTd2l0Y2hlZCBPcHRpY2FsIE5l dHdvcmsgKEFTT04pIGFzIGRlZmluZWQgYnkNCj4gICAgSVRVLVQuDQo+IA0KPiANCj4gDQo+IA0K PiANCj4gVy5BbGFucWFyIGV0IGFsLiAtIEV4cGlyZXMgU2VwdGVtYmVyIDIwMDQgICAgICAgICAg ICAgICAgICAgICAgICAgICAgMQ0KPiAjIyBNaXNzaW5nIHBhZ2UgdGhyb3dzDQo+IGRyYWZ0LWll dGYtY2NhbXAtZ21wbHMtYXNvbi1yb3V0aW5nLXJlcXRzLTAzLnR4dCAgICAgICAgICAgIEFwcmls IDIwMDQNCj4gDQo+IA0KPiANCj4gVGFibGUgb2YgQ29udGVudHMNCj4gDQo+IA0KPiAgICBTdGF0 dXMgb2YgdGhpcyBNZW1vIC4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4gMQ0KPiAgICBBYnN0cmFjdCAuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4gMQ0KPiAgICAxLiBDb250cmlidXRvcnMgLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4gMg0KPiAgICAyLiBDb252 ZW50aW9ucyB1c2VkIGluIHRoaXMgZG9jdW1lbnQgLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4gMg0KPiAgICAzLiBJbnRyb2R1Y3Rpb24gLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4gMg0KPiAgICA0LiBBU09OIFJvdXRpbmcgQXJjaGl0ZWN0dXJl IGFuZCBSZXF1aXJlbWVudHMgLi4uLi4uLi4uLi4uLi4uLi4uLi4gNA0KPiAgICA0LjEgTXVsdGlw bGUgSGllcmFyY2hpY2FsIExldmVscyBvZiBBU09OIFJvdXRpbmcgQXJlYXMgKFJBcykgLi4uLi4g NQ0KPiAgICA0LjIgSGllcmFyY2hpY2FsIFJvdXRpbmcgSW5mb3JtYXRpb24gRGlzc2VtaW5hdGlv biAuLi4uLi4uLi4uLi4uLi4gNQ0KPiAgICA0LjMgQ29uZmlndXJhdGlvbiAuLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4gNw0KPiAgICA0LjMuMSBDb25maWd1 cmluZyB0aGUgTXVsdGktTGV2ZWwgSGllcmFyY2h5IC4uLi4uLi4uLi4uLi4uLi4uLi4uLi4gNw0K PiAgICA0LjMuMiBDb25maWd1cmluZyBSQyBBZGphY2VuY2llcyAuLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4gNw0KPiAgICA0LjQgRXZvbHV0aW9uIC4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4gNw0KPiAgICA0LjUgUm91dGluZyBBdHRy aWJ1dGVzIC4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4gOA0KPiAg ICA0LjUuMSBUYXhvbm9teSBvZiBSb3V0aW5nIEF0dHJpYnV0ZXMgLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4gOA0KPiAgICA0LjUuMiBDb21tb25seSBBZHZlcnRpc2VkIEluZm9ybWF0aW9u IC4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4gOQ0KPiAgICA0LjUuMyBOb2RlIEF0dHJpYnV0 ZXMgLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4gOQ0KPiAgICA0 LjUuNCBMaW5rIEF0dHJpYnV0ZXMgLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4gOQ0KPiAgICA1LiBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyAuLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLiAxMQ0KPiAgICA2LiBDb25jbHVzaW9ucyAuLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLiAxMQ0KPiAgICA3LiBB Y2tub3dsZWRnZW1lbnRzIC4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLiAxMw0KPiAgICA4LiBJbnRlbGxlY3R1YWwgUHJvcGVydHkgQ29uc2lkZXJhdGlvbnMgLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLiAxMw0KPiAgICA4LjEgSVBSIERpc2Nsb3N1cmUgQWNrbm93 bGVkZ2VtZW50IC4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLiAxMw0KPiAgICA5LiBSZWZl cmVuY2VzIC4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u LiAxNA0KPiAgICA5LjEgTm9ybWF0aXZlIFJlZmVyZW5jZXMgLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLiAxNA0KPiAgICAxMC4gQXV0aG9yJ3MgQWRkcmVzc2VzIC4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLiAxNA0KPiAgICBBcHBlbmRpeCAx OiBBU09OIFRlcm1pbm9sb2d5IC4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLiAx Ng0KPiAgICBBcHBlbmRpeCAyOiBBU09OIFJvdXRpbmcgVGVybWlub2xvZ3kgLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLiAxOA0KPiAgICBGdWxsIENvcHlyaWdodCBTdGF0ZW1lbnQgLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLiAxOQ0KPiANCj4gDQo+IDEuIENvbnRy aWJ1dG9ycw0KPiANCj4gDQo+ICAgIFRoaXMgZG9jdW1lbnQgaXMgdGhlIHJlc3VsdCBvZiB0aGUg Q0NBTVAgV29ya2luZyBHcm91cCBBU09OIFJvdXRpbmcNCj4gICAgUmVxdWlyZW1lbnRzIGRlc2ln biB0ZWFtIGpvaW50IGVmZm9ydC4NCj4gDQo+IA0KPiAyLiBDb252ZW50aW9ucyB1c2VkIGluIHRo aXMgZG9jdW1lbnQNCj4gDQo+IA0KPiAgICBUaGUga2V5IHdvcmRzICJNVVNUIiwgIk1VU1QgTk9U IiwgIlJFUVVJUkVEIiwgIlNIQUxMIiwgIlNIQUxMIE5PVCIsDQo+ICAgICJTSE9VTEQiLCAiU0hP VUxEIE5PVCIsICJSRUNPTU1FTkRFRCIsICAiTUFZIiwgYW5kICJPUFRJT05BTCIgaW4NCj4gICAg dGhpcyBkb2N1bWVudCBhcmUgdG8gYmUgaW50ZXJwcmV0ZWQgYXMgZGVzY3JpYmVkIGluIFJGQyAy MTE5DQo+ICAgIFtSRkMyMTE5XS4NCj4gDQo+IA0KPiAzLiBJbnRyb2R1Y3Rpb24NCj4gDQo+IA0K PiAgICBUaGUgR01QTFMgc3VpdGUgb2YgcHJvdG9jb2xzIHByb3ZpZGVzIGFtb25nIG90aGVyIGNh cGFiaWxpdGllcw0KPiAgICBzdXBwb3J0IGZvciBjb250cm9sbGluZyBkaWZmZXJlbnQgc3dpdGNo aW5nIHRlY2hub2xvZ2llcy4gVGhlc2UNCj4gICAgaW5jbHVkZSBzdXBwb3J0IGZvciByZXF1ZXN0 aW5nIFRETSBjb25uZWN0aW9ucyB1dGlsaXppbmcgU09ORVQvU0RIDQo+ICAgIChzZWUgQU5TSSBU MS4xMDUvSVRVLVQgRy43MDcpIGFzIHdlbGwgYXMgT3B0aWNhbCBUcmFuc3BvcnQgTmV0d29ya3MN Cj4gICAgKE9UTiwgc2VlIElUVS1UIEcuNzA5KS4gSG93ZXZlciwgdGhlcmUgYXJlIGNlcnRhaW4g Y2FwYWJpbGl0aWVzIHRoYXQNCj4gICAgYXJlIG5lZWRlZCB0byBzdXBwb3J0IHRoZSBJVFUtVCBH LjgwODAgY29udHJvbCBwbGFuZSBhcmNoaXRlY3R1cmUNCj4gICAgZm9yIEF1dG9tYXRpY2FsbHkg U3dpdGNoZWQgT3B0aWNhbCBOZXR3b3JrIChBU09OKS4gVGhlcmVmb3JlLCBpdCBpcw0KPiANCj4g DQo+IA0KPiBXLkFsYW5xYXIgZXQgYWwuIC0gRXhwaXJlcyBPY3RvYmVyIDIwMDQgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAyDQo+IGRyYWZ0LWlldGYtY2NhbXAtZ21wbHMtYXNvbi1yb3V0 aW5nLXJlcXRzLTAzLnR4dCAgICAgICAgICAgIEFwcmlsIDIwMDQNCj4gDQo+IA0KPiANCj4gICAg ZGVzaXJhYmxlIHRvIHVuZGVyc3RhbmQgdGhlIGNvcnJlc3BvbmRpbmcgcmVxdWlyZW1lbnRzIGZv ciB0aGUgR01QTFMNCj4gICAgcHJvdG9jb2wgc3VpdGUuIFRoZSBBU09OIGNvbnRyb2wgcGxhbmUg YXJjaGl0ZWN0dXJlIGlzIGRlZmluZWQgaW4NCj4gICAgW0cuODA4MF0sIEFTT04gcm91dGluZyBy ZXF1aXJlbWVudHMgYXJlIGlkZW50aWZpZWQgaW4gW0cuNzcxNV0sIGFuZA0KPiAgICBpbiBbRy43 NzE1LjFdIGZvciBBU09OIGxpbmsgc3RhdGUgcHJvdG9jb2xzLiBUaGVzZSBSZWNvbW1lbmRhdGlv bnMNCj4gICAgYXBwbHkgdG8gYWxsIEcuODA1IGxheWVyIG5ldHdvcmtzIChlLmcuIFNESCBhbmQg T1ROKSwgYW5kIHByb3ZpZGUNCj4gICAgcHJvdG9jb2wgbmV1dHJhbCBmdW5jdGlvbmFsIHJlcXVp cmVtZW50cyBhbmQgYXJjaGl0ZWN0dXJlLg0KPiANCj4gDQo+ICAgIFRoaXMgZG9jdW1lbnQgZm9j dXNlcyBvbiB0aGUgcm91dGluZyByZXF1aXJlbWVudHMgZm9yIHRoZSBHTVBMUw0KPiAgICBzdWl0 ZSBvZiBwcm90b2NvbHMgdG8gc3VwcG9ydCB0aGUgY2FwYWJpbGl0aWVzIGFuZCBmdW5jdGlvbmFs aXR5IG9mDQo+ICAgIEFTT04gY29udHJvbCBwbGFuZXMuIFRoaXMgZG9jdW1lbnQgc3VtbWFyaXpl cyB0aGUgQVNPTiByZXF1aXJlbWVudHMNCj4gICAgdXNpbmcgQVNPTiB0ZXJtaW5vbG9neS4gVGhp cyBkb2N1bWVudCBkb2VzIG5vdCBhZGRyZXNzIEdNUExTDQo+ICAgIGFwcGxpY2FiaWxpdHkgb3Ig R01QTFMgY2FwYWJpbGl0aWVzLiBBbnkgcHJvdG9jb2wgKGluIHBhcnRpY3VsYXIsDQo+ICAgIHJv dXRpbmcpIGFwcGxpY2FiaWxpdHksIGRlc2lnbiBvciBzdWdnZXN0ZWQgZXh0ZW5zaW9ucyBpcyBz dHJpY3RseQ0KPiAgICBvdXRzaWRlIHRoZSBzY29wZSBvZiB0aGlzIGRvY3VtZW50LiBBU09OIChS b3V0aW5nKSB0ZXJtaW5vbG9neQ0KPiAgICBzZWN0aW9ucyBhcmUgcHJvdmlkZWQgaW4gQXBwZW5k aXggMSBhbmQgMi4NCj4gDQo+IA0KPiAgICBUaGUgQVNPTiByb3V0aW5nIGFyY2hpdGVjdHVyZSBp cyBiYXNlZCBvbiB0aGUgZm9sbG93aW5nIGFzc3VtcHRpb25zOg0KPiAgICAtIEEgbmV0d29yayBp cyBzdWJkaXZpZGVkIGJhc2VkIG9uIG9wZXJhdG9yIGRlY2lzaW9uIGFuZCBjcml0ZXJpYQ0KPiAg ICAgIChlLmcuIGdlb2dyYXBoeSwgYWRtaW5pc3RyYXRpb24sIGFuZC9vciB0ZWNobm9sb2d5KSwg dGhlIG5ldHdvcmsNCj4gICAgICBzdWJkaXZpc2lvbnMgYXJlIGRlZmluZWQgaW4gQVNPTiBhcyBS b3V0aW5nIEFyZWFzIChSQXMpLg0KPiAgICAtIFRoZSByb3V0aW5nIGFyY2hpdGVjdHVyZSBhbmQg cHJvdG9jb2xzIGFwcGxpZWQgYWZ0ZXIgdGhlIG5ldHdvcmsNCj4gICAgICBpcyBzdWJkaXZpZGVk IGlzIGFuIG9wZXJhdG9yJ3MgY2hvaWNlLiBBIG11bHRpLWxldmVsIGhpZXJhcmNoeSBvZg0KPiAg ICAgIFJBcywgYXMgZGVmaW5lZCBpbiBJVFUtVCBbRy43NzE1XSBhbmQgW0cuNzcxNS4xXSwgcHJv dmlkZXMgZm9yIGENCj4gICAgICBoaWVyYXJjaGljYWwgcmVsYXRpb25zaGlwIG9mIFJBcyBiYXNl ZCBvbiBjb250YWlubWVudCwgaS5lLiBjaGlsZA0KPiAgICAgIFJBcyBhcmUgYWx3YXlzIGNvbnRh aW5lZCB3aXRoaW4gYSBwYXJlbnQgUkEuIFRoZSBoaWVyYXJjaGljYWwNCj4gICAgICBjb250YWlu bWVudCByZWxhdGlvbnNoaXAgb2YgUkFzIHByb3ZpZGVzIGZvciByb3V0aW5nIGluZm9ybWF0aW9u DQo+ICAgICAgYWJzdHJhY3Rpb24sIHRoZXJlYnkgZW5hYmxpbmcgc2NhbGFibGUgcm91dGluZyBp bmZvcm1hdGlvbg0KPiAgICAgIHJlcHJlc2VudGF0aW9uLiBUaGUgbWF4aW11bSBudW1iZXIgb2Yg aGllcmFyY2hpY2FsIFJBIGxldmVscyB0byBiZQ0KPiA8ICAgIHN1cHBvcnRlZCBpcyBOT1Qgc3Bl Y2lmaWVkIChvdXRzaWRlIHRoZSBzY29wZSkuDQo+IA0KPj4gICBzdXBwb3J0ZWQgaXMgTk9UIHNw ZWNpZmllZCAob3V0c2lkZSB0aGUgc2NvcGUgb2YgdGhpcyBkb2N1bWVudCkuDQo+IA0KPiAgICAt IFdpdGhpbiBhbiBBU09OIFJBIGFuZCBmb3IgZWFjaCBsZXZlbCBvZiB0aGUgcm91dGluZyBoaWVy YXJjaHksDQo+ICAgICAgbXVsdGlwbGUgcm91dGluZyBwYXJhZGlnbXMgKGhpZXJhcmNoaWNhbCwg c3RlcC0gYnktc3RlcCwgc291cmNlLQ0KPiAgICAgIGJhc2VkKSwgY2VudHJhbGl6ZWQgb3IgZGlz dHJpYnV0ZWQgcGF0aCBjb21wdXRhdGlvbiwgYW5kIG11bHRpcGxlDQo+ICAgICAgZGlmZmVyZW50 IHJvdXRpbmcgcHJvdG9jb2xzIE1BWSBiZSBzdXBwb3J0ZWQuIFRoZSBhcmNoaXRlY3R1cmUNCj4g ICAgICBkb2VzIE5PVCBhc3N1bWUgYSBvbmUtdG8tb25lIGNvcnJlc3BvbmRlbmNlIG9mIGEgcm91 dGluZyBwcm90b2NvbA0KPiAgICAgIGFuZCBhIFJBIGxldmVsIGFuZCBhbGxvd3MgdGhlIHJvdXRp bmcgcHJvdG9jb2wocykgdXNlZCB3aXRoaW4NCj4gICAgICBkaWZmZXJlbnQgUkFzIChpbmNsdWRp bmcgY2hpbGQgYW5kIHBhcmVudCBSQXMpIHRvIGJlIGRpZmZlcmVudC4NCj4gICAgICBUaGUgcmVh bGl6YXRpb24gb2YgdGhlIHJvdXRpbmcgcGFyYWRpZ20ocykgdG8gc3VwcG9ydCB0aGUNCj4gICAg ICBoaWVyYXJjaGljYWwgbGV2ZWxzIG9mIFJBcyBpcyBOT1Qgc3BlY2lmaWVkLg0KPiAgICAtIFRo ZSByb3V0aW5nIGFkamFjZW5jeSB0b3BvbG9neSAoaS5lLiB0aGUgYXNzb2NpYXRlZCBQcm90b2Nv bA0KPiAgICAgIENvbnRyb2xsZXIgKFBDKSBjb25uZWN0aXZpdHkpIGFuZCB0cmFuc3BvcnQgdG9w b2xvZ3kgaXMgTk9UDQo+ICAgICAgYXNzdW1lZCB0byBiZSBjb25ncnVlbnQuDQo+ICAgIC0gVGhl IHJlcXVpcmVtZW50cyBzdXBwb3J0IGFyY2hpdGVjdHVyYWwgZXZvbHV0aW9uLCBlLmcuIGEgY2hh bmdlIGluDQo+ICAgICAgdGhlIG51bWJlciBvZiBSQSBsZXZlbHMsIGFzIHdlbGwgYXMgYWdncmVn YXRpb24gYW5kIHNlZ21lbnRhdGlvbg0KPiAgICAgIG9mIFJBcy4NCj4gDQo+IA0KPiAgICBUaGUg ZGVzY3JpcHRpb24gb2YgdGhlIEFTT04gcm91dGluZyBhcmNoaXRlY3R1cmUgcHJvdmlkZXMgZm9y IGENCj4gICAgY29uY2VwdHVhbCByZWZlcmVuY2UgYXJjaGl0ZWN0dXJlLCB3aXRoIGRlZmluaXRp b24gb2YgZnVuY3Rpb25hbA0KPiAgICBjb21wb25lbnRzIGFuZCBjb21tb24gaW5mb3JtYXRpb24g ZWxlbWVudHMgdG8gZW5hYmxlIGVuZC10by1lbmQNCj4gICAgcm91dGluZyBpbiB0aGUgY2FzZSBv ZiBwcm90b2NvbCBoZXRlcm9nZW5laXR5IGFuZCBmYWNpbGl0YXRlDQo+ICAgIG1hbmFnZW1lbnQg b2YgQVNPTiBuZXR3b3Jrcy4gVGhpcyBkZXNjcmlwdGlvbiBpcyBvbmx5IGNvbmNlcHR1YWw6IG5v DQo+ICAgIHBoeXNpY2FsIHBhcnRpdGlvbmluZyBvZiB0aGVzZSBmdW5jdGlvbnMgaXMgaW1wbGll ZC4NCj4gDQo+IA0KPiANCj4gDQo+IFcuQWxhbnFhciBldCBhbC4gLSBFeHBpcmVzIE9jdG9iZXIg MjAwNCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDMNCj4gZHJhZnQtaWV0Zi1jY2FtcC1n bXBscy1hc29uLXJvdXRpbmctcmVxdHMtMDMudHh0ICAgICAgICAgICAgQXByaWwgMjAwNA0KPiAN Cj4gDQo+IA0KPiA0LiBBU09OIFJvdXRpbmcgQXJjaGl0ZWN0dXJlIGFuZCBSZXF1aXJlbWVudHMN Cj4gDQo+ICMjIHRyaXZpYWw6IHlvdSBoYXZlICJhIFJBIiBhbHNvICJhbiBSUCINCj4gDQo+ICAg IFRoZSBmdW5kYW1lbnRhbCBhcmNoaXRlY3R1cmFsIGNvbmNlcHQgaXMgdGhlIFJBIGFuZCBpdCdz IHJlbGF0ZWQNCj4gICAgZnVuY3Rpb25hbCBjb21wb25lbnRzIChzZWUgQXBwZW5kaXggMiBvbiB0 ZXJtaW5vbG9neSkuIFRoZSByb3V0aW5nDQo+ICAgIHNlcnZpY2VzIG9mZmVyZWQgYnkgYSBSQSBh cmUgcHJvdmlkZWQgYnkgYSBSb3V0aW5nIFBlcmZvcm1lciAoUlApLg0KPiAgICBBbiBSUCBpcyBy ZXNwb25zaWJsZSBmb3IgYSBzaW5nbGUgUkEsIGFuZCBpdCBNQVkgYmUgZnVuY3Rpb25hbGx5DQo+ ICAgIHJlYWxpemVkIHVzaW5nIGRpc3RyaWJ1dGVkIFJvdXRpbmcgQ29udHJvbGxlcnMgKFJDKS4g VGhlIFJDLCBpdHNlbGYsDQo+ICAgIE1BWSBiZSBpbXBsZW1lbnRlZCBhcyBhIGNsdXN0ZXIgb2Yg ZGlzdHJpYnV0ZWQgZW50aXRpZXMgKEFTT04gcmVmZXJzDQo+ICAgIHRvIHRoZSBjbHVzdGVyIGFz IGEgUm91dGluZyBDb250cm9sIERvbWFpbiAoUkNEKSkuIFRoZSBSQyBjb21wb25lbnRzDQo+ICAg IGZvciBhIFJBIHJlY2VpdmUgcm91dGluZyB0b3BvbG9neSBpbmZvcm1hdGlvbiBmcm9tIHRoZWly IGFzc29jaWF0ZWQNCj4gICAgTGluayBSZXNvdXJjZSBNYW5hZ2VyKHMpIChMUk1zKSBhbmQgc3Rv cmUgdGhpcyBpbmZvcm1hdGlvbiBpbiB0aGUNCj4gICAgUm91dGluZyBJbmZvcm1hdGlvbiBEYXRh YmFzZSAoUkRCKS4gVGhlIFJEQiBpcyByZXBsaWNhdGVkIGF0IGVhY2ggUkMNCj4gPCAgYm91bmRl ZCB0byB0aGUgc2FtZSBSb3V0aW5nIEFyZWEgKFJBKSwgYW5kIE1BWSBjb250YWluIGluZm9ybWF0 aW9uDQo+IA0KPj4gYm91bmRlZCB0byB0aGUgc2FtZSBSQSwgYW5kIE1BWSBjb250YWluIGluZm9y bWF0aW9uDQo+IA0KPiAgICBhYm91dCBtdWx0aXBsZSB0cmFuc3BvcnQgcGxhbmUgbmV0d29yayBs YXllcnMuIFdoZW5ldmVyIHRoZSByb3V0aW5nDQo+ICAgIHRvcG9sb2d5IGNoYW5nZXMsIHRoZSBM Uk0gaW5mb3JtcyB0aGUgY29ycmVzcG9uZGluZyBSQywgd2hpY2ggaW4NCj4gICAgdHVybiB1cGRh dGVzIGl0cyBhc3NvY2lhdGVkIFJEQi4gSW4gb3JkZXIgdG8gYXNzdXJlIFJEQg0KPiAgICBzeW5j aHJvbml6YXRpb24sIHRoZSBSQ3MgY28tb3BlcmF0ZSBhbmQgZXhjaGFuZ2Ugcm91dGluZw0KPiAg ICBpbmZvcm1hdGlvbi4gUGF0aCBjb21wdXRhdGlvbiBmdW5jdGlvbnMgTUFZIGV4aXN0IGluIGVh Y2ggUkMsIE1BWQ0KPiAgICBleGlzdCBvbiBzZWxlY3RlZCBSQ3Mgd2l0aGluIHRoZSBzYW1lIFJB LCBvciBNQVkgYmUgY2VudHJhbGl6ZWQgZm9yDQo+ICAgIHRoZSBSQS4NCj4gDQo+IA0KPiAgICBJ biB0aGlzIGNvbnRleHQsIGNvbW11bmljYXRpb24gYmV0d2VlbiBSQ3Mgd2l0aGluIHRoZSBzYW1l IFJBIGlzDQo+ICAgIHJlYWxpemVkIHVzaW5nIGEgcGFydGljdWxhciByb3V0aW5nIHByb3RvY29s IChvciBtdWx0aXBsZQ0KPiAgICBwcm90b2NvbHMpLiBJbiBBU09OLCB0aGUgY29tbXVuaWNhdGlv biBjb21wb25lbnQgaXMgcmVwcmVzZW50ZWQgYnkNCj4gICAgdGhlIHByb3RvY29sIGNvbnRyb2xs ZXIgKFBDKSBjb21wb25lbnQocykgYW5kIHRoZSBwcm90b2NvbCBtZXNzYWdlcw0KPiAgICBhcmUg Y29udmV5ZWQgb3ZlciB0aGUgQVNPTiBjb250cm9sIHBsYW5lJ3MgU2lnbmFsaW5nIENvbnRyb2wg TmV0d29yaw0KPiAgICAoU0NOKS4gVGhlIFBDIE1BWSBjb252ZXkgaW5mb3JtYXRpb24gZm9yIG9u ZSBvciBtb3JlIHRyYW5zcG9ydA0KPiAgICBuZXR3b3JrIGxheWVycyAocmVmZXIgdG8gU2VjdGlv biA0LjIgTm90ZSkuIFRoZSBSQyBpcyBwcm90b2NvbA0KPiAgICBpbmRlcGVuZGVudCBhbmQgUkMg Y29tbXVuaWNhdGlvbnMgTUFZIGJlIHJlYWxpemVkIGJ5IG11bHRpcGxlLA0KPiAgICBkaWZmZXJl bnQgUENzIHdpdGhpbiBhIFJBLg0KPiANCj4gDQo+ICAgIFRoZSBBU09OIHJvdXRpbmcgYXJjaGl0 ZWN0dXJlIGRlZmluZXMgYSBtdWx0aS1sZXZlbCByb3V0aW5nDQo+ICAgIGhpZXJhcmNoeSBvZiBS QXMgYmFzZWQgb24gYSBjb250YWlubWVudCBtb2RlbCB0byBzdXBwb3J0IHJvdXRpbmcNCj4gICAg aW5mb3JtYXRpb24gYWJzdHJhY3Rpb24uIFtHLjc3MTUuMV0gZGVmaW5lcyB0aGUgQVNPTiBoaWVy YXJjaGljYWwNCj4gICAgbGluayBzdGF0ZSByb3V0aW5nIHByb3RvY29sIHJlcXVpcmVtZW50cyBm b3IgY29tbXVuaWNhdGlvbiBvZg0KPiAgICByb3V0aW5nIGluZm9ybWF0aW9uIHdpdGhpbiBhbiBS QSAob25lIGxldmVsKSB0byBzdXBwb3J0IGhpZXJhcmNoaWNhbA0KPiAgICByb3V0aW5nIGluZm9y bWF0aW9uIGRpc3NlbWluYXRpb24gKGluY2x1ZGluZyBzdW1tYXJpemVkIHJvdXRpbmcNCj4gICAg aW5mb3JtYXRpb24gZm9yIG90aGVyIGxldmVscykuIFRoZSBDb21tdW5pY2F0aW9uIGJldHdlZW4g YW55IG9mIHRoZQ0KPiAgICBvdGhlciBmdW5jdGlvbmFsIGNvbXBvbmVudChzKSAoZS5nLiBTQ04s IExSTSwgYW5kIGJldHdlZW4gUkNEcyAoUkMtDQo+ICAgIFJDIGNvbW11bmljYXRpb24gYmV0d2Vl biBSQXMpKSwgaXMgb3V0c2lkZSB0aGUgc2NvcGUgb2YgW0cuNzcxNS4xXQ0KPiAgICBwcm90b2Nv bCByZXF1aXJlbWVudHMgYW5kLCB0aHVzLCBpcyBhbHNvIG91dHNpZGUgdGhlIHNjb3BlIG9mIHRo aXMNCj4gICAgZG9jdW1lbnQuDQo+IA0KPiANCj4gICAgQVNPTiBSb3V0aW5nIGNvbXBvbmVudHMg YXJlIGlkZW50aWZpZWQgYnkgaWRlbnRpZmllcnMgdGhhdCBhcmUgZHJhd24NCj4gICAgZnJvbSBk aWZmZXJlbnQgbmFtZSBzcGFjZXMgKHNlZSBbRy43NzE1LjFdKS4gVGhlc2UgYXJlIGNvbnRyb2wg cGxhbmUNCj4gICAgaWRlbnRpZmllcnMgZm9yIHRyYW5zcG9ydCByZXNvdXJjZXMsIGNvbXBvbmVu dHMsIGFuZCBTQ04gYWRkcmVzc2VzLg0KPiAgICBUaGUgZm9ybWF0cyBvZiB0aG9zZSBpZGVudGlm aWVycyBpbiBhIHJvdXRpbmcgcHJvdG9jb2wgcmVhbGl6YXRpb24NCj4gICAgU0hBTEwgYmUgaW1w bGVtZW50YXRpb24gc3BlY2lmaWMgYW5kIG91dHNpZGUgdGhlIHNjb3BlIG9mIHRoaXMNCj4gICAg ZG9jdW1lbnQuDQo+IA0KPiANCj4gICAgVGhlIGZhaWx1cmUgb2YgYSBSQywgb3IgdGhlIGZhaWx1 cmUgb2YgY29tbXVuaWNhdGlvbnMgYmV0d2VlbiBSQ3MsDQo+IDwgIGFuZCB0aGUgc3Vic2VxdWVu dCByZWNvdmVyIGZyb20gdGhlIGZhaWx1cmUgY29uZGl0aW9uIE1VU1QgTk9UDQo+IA0KPj4gYW5k IHRoZSBzdWJzZXF1ZW50IHJlY292ZXJ5IGZyb20gdGhlIGZhaWx1cmUgY29uZGl0aW9uIE1VU1Qg Tk9UDQo+IA0KPiANCj4gDQo+IA0KPiBXLkFsYW5xYXIgZXQgYWwuIC0gRXhwaXJlcyBPY3RvYmVy IDIwMDQgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA0DQo+IGRyYWZ0LWlldGYtY2NhbXAt Z21wbHMtYXNvbi1yb3V0aW5nLXJlcXRzLTAzLnR4dCAgICAgICAgICAgIEFwcmlsIDIwMDQNCj4g DQo+IA0KPiANCj4gICAgZGlzcnVwdCBjYWxscyBpbiBwcm9ncmVzcyBhbmQgdGhlaXIgYXNzb2Np YXRlZCBjb25uZWN0aW9ucy4gQ2FsbHMNCj4gICAgYmVpbmcgc2V0IHVwIE1BWSBmYWlsIHRvIGNv bXBsZXRlLCBhbmQgdGhlIGNhbGwgc2V0dXAgc2VydmljZSBNQVkgYmUNCj4gICAgdW5hdmFpbGFi bGUgZHVyaW5nIHJlY292ZXJ5IGFjdGlvbnMuDQo+IA0KPiANCj4gNC4xIE11bHRpcGxlIEhpZXJh cmNoaWNhbCBMZXZlbHMgb2YgQVNPTiBSb3V0aW5nIEFyZWFzIChSQXMpDQo+IA0KPiANCj4gICAg W0cuODA4MF0gaW50cm9kdWNlcyB0aGUgY29uY2VwdCBvZiBSb3V0aW5nIEFyZWEgKFJBKSBpbiBy ZWZlcmVuY2UgdG8NCj4gICAgYSBuZXR3b3JrIHN1YmRpdmlzaW9uLiBSQXMgcHJvdmlkZSBmb3Ig cm91dGluZyBpbmZvcm1hdGlvbg0KPiAgICBhYnN0cmFjdGlvbi4gRXhjZXB0IGZvciB0aGUgc2lu Z2xlIFJBIGNhc2UsIFJBcyBhcmUgaGllcmFyY2hpY2FsbHkNCj4gICAgY29udGFpbmVkOiBhIGhp Z2hlciBsZXZlbCAocGFyZW50KSBSQSBjb250YWlucyBsb3dlciBsZXZlbCAoY2hpbGQpDQo+ICAg IFJBcyB0aGF0IGluIHR1cm4gTUFZIGFsc28gY29udGFpbiBSQXMsIGV0Yy4gVGh1cywgUkFzIGNv bnRhaW4gUkFzDQo+ICAgIHRoYXQgcmVjdXJzaXZlbHkgZGVmaW5lIHN1Y2Nlc3NpdmUgaGllcmFy Y2hpY2FsIFJBIGxldmVscy4NCj4gDQo+IA0KPiAgICBIb3dldmVyLCB0aGUgUkEgY29udGFpbm1l bnQgcmVsYXRpb25zaGlwIGRlc2NyaWJlcyBvbmx5IGFuDQo+ICAgIGFyY2hpdGVjdHVyYWwgaGll cmFyY2hpY2FsIG9yZ2FuaXphdGlvbiBvZiBSQXMuIEl0IGRvZXMgbm90IHJlc3RyaWN0DQo+ICAg IGEgc3BlY2lmaWMgcm91dGluZyBwcm90b2NvbCdzIHJlYWxpemF0aW9uIChlLmcuIE9TUEYgbXVs dGktYXJlYXMsDQo+ICAgIHBhdGggY29tcHV0YXRpb24sIGV0Yy4pLiBNb3Jlb3ZlciwgdGhlIHJl YWxpemF0aW9uIG9mIHRoZSByb3V0aW5nDQo+ICAgIHBhcmFkaWdtIHRvIHN1cHBvcnQgYSBoaWVy YXJjaGljYWwgb3JnYW5pemF0aW9uIG9mIFJBcyBhbmQgdGhlDQo+ICAgIG51bWJlciBvZiBoaWVy YXJjaGljYWwgUkEgbGV2ZWxzIHRvIGJlIHN1cHBvcnRlZCBpcyByb3V0aW5nIHByb3RvY29sDQo+ ICAgIHNwZWNpZmljIGFuZCBvdXRzaWRlIHRoZSBzY29wZSBvZiB0aGlzIGRvY3VtZW50Lg0KPiAN Cj4gDQo+ICAgIEluIGEgbXVsdGktbGV2ZWwgaGllcmFyY2h5IG9mIFJBcywgaXQgaXMgbmVjZXNz YXJ5IHRvIGRpc3Rpbmd1aXNoDQo+ICAgIGFtb25nIFJDcyBmb3IgdGhlIGRpZmZlcmVudCBsZXZl bHMgb2YgdGhlIFJBIGhpZXJhcmNoeS4gQmVmb3JlIGFueQ0KPiAgICBwYWlyIG9mIFJDcyBlc3Rh Ymxpc2hlcyBjb21tdW5pY2F0aW9uLCB0aGV5IE1VU1QgdmVyaWZ5IHRoZXkgYXJlDQo+IDwgIGJv dW5kZWQgdG8gdGhlIHNhbWUgcGFyZW50IFJBIChzZWUgU2VjdGlvbiA0LjIpLiBBIFJBIGlkZW50 aWZpZXIgKFJBDQo+IA0KPj4gYm91bmQgdG8gdGhlIHNhbWUgcGFyZW50IFJBIChzZWUgU2VjdGlv biA0LjIpLiBBIFJBIGlkZW50aWZpZXIgKFJBDQo+IA0KPiAgICBJRCkgaXMgcmVxdWlyZWQgdG8g cHJvdmlkZSB0aGUgc2NvcGUgd2l0aGluIHdoaWNoIHRoZSBSQ3MgY2FuDQo+IDwgIGNvbW11bmlj YXRlLiBUbyBkaXN0aW5ndWlzaCBiZXR3ZWVuIFJDcyBib3VuZGVkIHRvIHRoZSBzYW1lIFJBLCBh bg0KPiANCj4+IGNvbW11bmljYXRlLiBUbyBkaXN0aW5ndWlzaCBiZXR3ZWVuIFJDcyBib3VuZCB0 byB0aGUgc2FtZSBSQSwgYW4NCj4gDQo+ICAgIFJDIGlkZW50aWZpZXIgKFJDIElEKSBpcyByZXF1 aXJlZDsgdGhlIFJDIElEIE1VU1QgYmUgdW5pcXVlIHdpdGhpbg0KPiAgICBpdHMgY29udGFpbmlu ZyBSQS4NCj4gDQo+IA0KPiA8ICBBIFJBIHJlcHJlc2VudHMgYSBwYXJ0aXRpb24gb2YgdGhlIGRh dGEgcGxhbmUgYW5kIGl0cyBpZGVudGlmaWVyDQo+IA0KPj4gQSBSQSByZXByZXNlbnRzIGEgcGFy dGl0aW9uIG9mIHRoZSBkYXRhIHBsYW5lLCBhbmQgaXRzIGlkZW50aWZpZXINCj4gDQo+ICAgIChp LmUuIFJBIElEKSBpcyB1c2VkIHdpdGhpbiB0aGUgY29udHJvbCBwbGFuZSBhcyBhIHJlZmVyZW5j ZSB0byB0aGUNCj4gPCAgZGF0YSBwbGFuZSBwYXJ0aXRpb24uIEVhY2ggUkEgU0hBTEwgYmUgdW5p cXVlbHkgaWRlbnRpZmlhYmxlIHdpdGhpbg0KPiA8ICBhIGNhcnJpZXIncyBuZXR3b3JrLiBSQSBJ RHMgTUFZIGJlIGFzc29jaWF0ZWQgd2l0aCBhIHRyYW5zcG9ydCBwbGFuZQ0KPiANCj4+IGRhdGEg cGxhbmUgcGFydGl0aW9uLiBFYWNoIFJBIHdpdGhpbiBhIGNhcnJpZXIncyBuZXR3b3JrIFNIQUxM IGJlDQo+PiB1bmlxdWVseSBpZGVudGlmaWFibGUuIFJBIElEcyBNQVkgYmUgYXNzb2NpYXRlZCB3 aXRoIGEgdHJhbnNwb3J0IHBsYW5lDQo+IA0KPiAgICBuYW1lIHNwYWNlIHdoZXJlYXMgUkMgSURz IGFyZSBhc3NvY2lhdGVkIHdpdGggYSBjb250cm9sIHBsYW5lIG5hbWUNCj4gICAgc3BhY2UuDQo+ IA0KPiANCj4gNC4yIEhpZXJhcmNoaWNhbCBSb3V0aW5nIEluZm9ybWF0aW9uIERpc3NlbWluYXRp b24NCj4gDQo+IA0KPiA8ICBSb3V0aW5nIGluZm9ybWF0aW9uIGNhbiBiZSBleGNoYW5nZWQgYmV0 d2VlbiBSQ3MgYm91bmRlZCB0byBhZGphY2VudA0KPiANCj4+IFJvdXRpbmcgaW5mb3JtYXRpb24g Y2FuIGJlIGV4Y2hhbmdlZCBiZXR3ZWVuIFJDcyBib3VuZCB0byBhZGphY2VudA0KPiANCj4gICAg bGV2ZWxzIG9mIHRoZSBSQSBoaWVyYXJjaHkgaS5lLiBMZXZlbCBOKzEgYW5kIE4sIHdoZXJlIExl dmVsIE4NCj4gICAgcmVwcmVzZW50cyB0aGUgUkFzIGNvbnRhaW5lZCBieSBMZXZlbCBOKzEuIFRo ZSBsaW5rcyBjb25uZWN0aW5nIFJBcw0KPiAgICBNQVkgYmUgdmlld2VkIGFzIGV4dGVybmFsIGxp bmtzIChpbnRlci1SQSBsaW5rcyksIGFuZCB0aGUgbGlua3MNCj4gICAgcmVwcmVzZW50aW5nIGNv bm5lY3Rpdml0eSB3aXRoaW4gYSBSQSBNQVkgYmUgdmlld2VkIGFzIGludGVybmFsDQo+ICAgIGxp bmtzIChpbnRyYS1SQSBsaW5rcykuIFRoZSBleHRlcm5hbCBsaW5rcyB0byBhIFJBIGF0IG9uZSBs ZXZlbCBvZg0KPiAgICB0aGUgaGllcmFyY2h5IG1heSBiZSBpbnRlcm5hbCBsaW5rcyBpbiB0aGUg cGFyZW50IFJBLiBJbnRyYS1SQSBsaW5rcw0KPiAgICBvZiBhIGNoaWxkIFJBIE1BWSBiZSBoaWRk ZW4gZnJvbSB0aGUgcGFyZW50IFJBJ3Mgdmlldy4NCj4gDQo+IA0KPiAgICBUaGUgcGh5c2ljYWwg bG9jYXRpb24gb2YgUkNzIGZvciBhZGphY2VudCBSQSBsZXZlbHMsIHRoZWlyDQo+ICAgIHJlbGF0 aW9uc2hpcCBhbmQgdGhlaXIgY29tbXVuaWNhdGlvbiBwcm90b2NvbChzKSBhcmUgb3V0c2lkZSB0 aGUNCj4gICAgc2NvcGUgb2YgdGhpcyBkb2N1bWVudC4gTm8gYXNzdW1wdGlvbiBpcyBtYWRlIHJl Z2FyZGluZyBob3cgUkNzDQo+ICAgIGNvbW11bmljYXRlIGJldHdlZW4gYWRqYWNlbnQgUkEgbGV2 ZWxzLiBJZiByb3V0aW5nIGluZm9ybWF0aW9uIGlzDQo+IA0KPiANCj4gDQo+IFcuQWxhbnFhciBl dCBhbC4gLSBFeHBpcmVzIE9jdG9iZXIgMjAwNCAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IDUNCj4gZHJhZnQtaWV0Zi1jY2FtcC1nbXBscy1hc29uLXJvdXRpbmctcmVxdHMtMDMudHh0ICAg ICAgICAgICAgQXByaWwgMjAwNA0KPiANCj4gDQo+IA0KPiAgICBleGNoYW5nZWQgYmV0d2VlbiBh IFJDLCBpdHMgcGFyZW50LCBhbmQgaXRzIGNoaWxkIFJDcywgaXQgU0hPVUxEDQo+ICAgIGluY2x1 ZGUgcmVhY2hhYmlsaXR5IGFuZCBNQVkgaW5jbHVkZSAodXBvbiBwb2xpY3kgZGVjaXNpb24pIG5v ZGUgYW5kDQo+IDwgIGxpbmsgdG9wb2xvZ3kuIE9ubHkgdGhlIFJDcyBvZiB0aGUgcGFyZW50IFJB IGNvbW11bmljYXRlLCBSQ3Mgb2Ygb25lDQo+IDwgIGNoaWxkxnMgUkEgbmV2ZXIgY29tbXVuaWNh dGUgd2l0aCB0aGUgUkNzIG9mIG90aGVyIGNoaWxkIFJBcy4gVGhlcmUNCj4gDQo+PiBsaW5rIHRv cG9sb2d5LiBDb21tdW5pY2F0aW9uIGJldHdlZW4gUkFzIG9ubHkgdGFrZXMgcGxhY2UgYmV0d2Vl bg0KPj4gUkNzIHdpdGggYSBwYXJlbnQvY2hpbGQgcmVsYXRpb25zaGlwLiBSQ3Mgb2Ygb25lIFJB IG5ldmVyIGNvbW11bmljYXRlDQo+PiB3aXRoIFJDcyBvZiBhbm90aGVyIFJBIGF0IHRoZSBzYW1l IGxldmVsLiBUaGVyZQ0KPiANCj4gICAgU0hPVUxEIG5vdCBiZSBhbnkgZGVwZW5kZW5jaWVzIG9u IHRoZSBkaWZmZXJlbnQgcm91dGluZyBwcm90b2NvbHMNCj4gICAgdXNlZCB3aXRoaW4gYSBSQSBv ciBpbiBkaWZmZXJlbnQgUkFzLg0KPiANCj4gDQo+IDwgIE11bHRpcGxlIFJDcyBib3VuZGVkIHRv IHRoZSBzYW1lIFJBIE1BWSB0cmFuc2Zvcm0gKGZpbHRlciwNCj4gDQo+PiBNdWx0aXBsZSBSQ3Mg Ym91bmQgdG8gdGhlIHNhbWUgUkEgTUFZIHRyYW5zZm9ybSAoZmlsdGVyLA0KPiANCj4gICAgc3Vt bWFyaXplLCBldGMuKSBhbmQgdGhlbiBmb3J3YXJkIGluZm9ybWF0aW9uIHRvIFJDcyBhdCBkaWZm ZXJlbnQNCj4gICAgbGV2ZWxzLiBIb3dldmVyIGluIHRoaXMgY2FzZSB0aGUgcmVzdWx0aW5nIGlu Zm9ybWF0aW9uIGF0IHRoZQ0KPiAgICByZWNlaXZpbmcgbGV2ZWwgbXVzdCBiZSBzZWxmLWNvbnNp c3RlbnQ7IHRoaXMgTUFZIGJlIGFjaGlldmVkIHVzaW5nDQo+ICAgIGEgbnVtYmVyIG9mIG1lY2hh bmlzbXMuDQo+IA0KPiANCj4gICAgTm90ZTogdGhlcmUgaXMgbm8gaW1wbGllZCByZWxhdGlvbnNo aXAgYmV0d2VlbiBtdWx0aS1sYXllciB0cmFuc3BvcnQNCj4gICAgbmV0d29ya3MgYW5kIG11bHRp LWxldmVsIHJvdXRpbmcuIEltcGxlbWVudGF0aW9ucyBtYXkgc3VwcG9ydCBhDQo+ICAgIGhpZXJh cmNoaWNhbCByb3V0aW5nIHRvcG9sb2d5IChtdWx0aS1sZXZlbCkgd2l0aCBhIHNpbmdsZSByb3V0 aW5nDQo+ICAgIHByb3RvY29sIGluc3RhbmNlIGZvciBtdWx0aXBsZSB0cmFuc3BvcnQgc3dpdGNo aW5nIGxheWVycyBvciBhDQo+ICAgIGhpZXJhcmNoaWNhbCByb3V0aW5nIHRvcG9sb2d5IGZvciBv bmUgdHJhbnNwb3J0IHN3aXRjaGluZyBsYXllci4NCj4gDQo+IA0KPiAgICAxLiBUeXBlIG9mIElu Zm9ybWF0aW9uIEV4Y2hhbmdlZA0KPiANCj4gDQo+ICAgICAgIFRoZSB0eXBlIG9mIGluZm9ybWF0 aW9uIGZsb3dpbmcgdXB3YXJkIChpLmUuIExldmVsIE4gdG8gTGV2ZWwNCj4gICAgICAgTisxKSBh bmQgdGhlIGluZm9ybWF0aW9uIGZsb3dpbmcgZG93bndhcmQgKGkuZS4gTGV2ZWwgTisxIHRvDQo+ ICAgICAgIExldmVsIE4pIGFyZSB1c2VkIGZvciBzaW1pbGFyIHB1cnBvc2VzLCBuYW1lbHksIHRo ZSBleGNoYW5nZSBvZg0KPiAgICAgICByZWFjaGFiaWxpdHkgaW5mb3JtYXRpb24gYW5kIHN1bW1h cml6ZWQgdG9wb2xvZ3kgaW5mb3JtYXRpb24gdG8NCj4gICAgICAgYWxsb3cgcm91dGluZyBhY3Jv c3MgbXVsdGlwbGUgUkFzLiBUaGUgc3VtbWFyaXphdGlvbiBvZiB0b3BvbG9neQ0KPiAgICAgICBp bmZvcm1hdGlvbiBtYXkgaW1wYWN0IHRoZSBhY2N1cmFjeSBvZiByb3V0aW5nIGFuZCBNQVkgcmVx dWlyZQ0KPiAgICAgICBhZGRpdGlvbmFsIHBhdGggY2FsY3VsYXRpb24uDQo+IA0KPiANCj4gPCAg ICAgVGhlIGZvbGxvd2luZyBpbmZvcm1hdGlvbiBleGNoYW5nZSBhcmUgZXhwZWN0ZWQ6DQo+IA0K Pj4gICAgVGhlIGZvbGxvd2luZyBpbmZvcm1hdGlvbiBleGNoYW5nZXMgYXJlIGV4cGVjdGVkOg0K PiANCj4gDQo+IA0KPiAgICAgICAtIExldmVsIE4rMSB2aXNpYmlsaXR5IHRvIExldmVsIE4gcmVh Y2hhYmlsaXR5IGFuZCB0b3BvbG9neSAob3INCj4gICAgICAgICB1cHdhcmQgaW5mb3JtYXRpb24g Y29tbXVuaWNhdGlvbikgYWxsb3dpbmcgUkMocykgYXQgTGV2ZWwgTisxDQo+ICAgICAgICAgdG8g ZGV0ZXJtaW5lIHRoZSByZWFjaGFibGUgZW5kcG9pbnRzIGZyb20gTGV2ZWwgTi4NCj4gICAgICAg LSBMZXZlbCBOIHZpc2liaWxpdHkgdG8gTGV2ZWwgTisxIHJlYWNoYWJpbGl0eSBhbmQgdG9wb2xv Z3kgKG9yDQo+ICAgICAgICAgZG93bndhcmQgaW5mb3JtYXRpb24gY29tbXVuaWNhdGlvbikgYWxs b3dpbmcgUkMocykgYm91bmRlZCB0byBhDQo+ICAgICAgICAgUkEgYXQgTGV2ZWwgTiB0byBkZXZl bG9wIHBhdGhzIHRvIHJlYWNoYWJsZSBlbmRwb2ludHMgb3V0c2lkZQ0KPiAgICAgICAgIG9mIHRo ZSBSQS4NCj4gDQo+IA0KPiAgICAyLiBJbnRlcmFjdGlvbnMgYmV0d2VlbiBVcHdhcmQgYW5kIERv d253YXJkIENvbW11bmljYXRpb24NCj4gDQo+IA0KPiAgICAgICBXaGVuIGJvdGggdXB3YXJkIGFu ZCBkb3dud2FyZCBpbmZvcm1hdGlvbiBleGNoYW5nZXMgY29udGFpbg0KPiAgICAgICBlbmRwb2lu dCByZWFjaGFiaWxpdHkgaW5mb3JtYXRpb24sIGEgZmVlZGJhY2sgbG9vcCBjb3VsZA0KPiAgICAg ICBwb3RlbnRpYWxseSBiZSBjcmVhdGVkLiBDb25zZXF1ZW50bHksIHRoZSByb3V0aW5nIHByb3Rv Y29sIE1VU1QNCj4gICAgICAgaW5jbHVkZSBhIG1ldGhvZCB0bzoNCj4gDQo+IA0KPiAgICAgICAt IHByZXZlbnQgaW5mb3JtYXRpb24gcHJvcGFnYXRlZCBmcm9tIGEgTGV2ZWwgTisxIFJBJ3MgUkMg aW50bw0KPiA8ICAgICAgIHRoZSBMZXZlbCBOIFJBJ3MgUkMgdG8gYmUgcmUtaW50cm9kdWNlZCBp bnRvIHRoZSBMZXZlbCBOKzEgUkEncw0KPiA8ICAgICAgIFJDLCBhbmQNCj4gDQo+PiAgICAgIHRo ZSBMZXZlbCBOIFJBJ3MgUkMgZnJvbSBiZWluZyByZS1pbnRyb2R1Y2VkIGludG8gdGhlIExldmVs IE4rMQ0KPj4gICAgICBSQSdzIFJDLCBhbmQNCj4gDQo+IA0KPiANCj4gICAgICAgLSBwcmV2ZW50 IGluZm9ybWF0aW9uIHByb3BhZ2F0ZWQgZnJvbSBhIExldmVsIE4tMSBSQSdzIFJDIGludG8NCj4g PCAgICAgICB0aGUgTGV2ZWwgTiBSQSdzIFJDIHRvIGJlIHJlLWludHJvZHVjZWQgaW50byB0aGUg TGV2ZWwgTi0xIFJBJ3MNCj4gDQo+PiAgICAgIHRoZSBMZXZlbCBOIFJBJ3MgUkMgZnJvbSBiZWlu ZyByZS1pbnRyb2R1Y2VkIGludG8gdGhlIExldmVsIE4tMSBSQSdzDQo+IA0KPiANCj4gDQo+IA0K PiBXLkFsYW5xYXIgZXQgYWwuIC0gRXhwaXJlcyBPY3RvYmVyIDIwMDQgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICA2DQo+IGRyYWZ0LWlldGYtY2NhbXAtZ21wbHMtYXNvbi1yb3V0aW5nLXJl cXRzLTAzLnR4dCAgICAgICAgICAgIEFwcmlsIDIwMDQNCj4gDQo+IA0KPiANCj4gICAgICAgICBS Qy4NCj4gDQo+IA0KPiAgICAgICBUaGUgcm91dGluZyBwcm90b2NvbCBTSEFMTCBkaWZmZXJlbnRp YXRlIHRoZSByb3V0aW5nIGluZm9ybWF0aW9uDQo+ICAgICAgIG9yaWdpbmF0ZWQgYXQgYSBnaXZl biBsZXZlbCBSQSBmcm9tIGRlcml2ZWQgcm91dGluZyBpbmZvcm1hdGlvbg0KPiAgICAgICAocmVj ZWl2ZWQgZnJvbSBleHRlcm5hbCBSQXMpLCBldmVuIHdoZW4gdGhpcyBpbmZvcm1hdGlvbiBpcw0K PiAgICAgICBmb3J3YXJkZWQgYnkgYW5vdGhlciBSQyBhdCB0aGUgc2FtZSBsZXZlbC4gVGhpcyBp cyBhIG5lY2Vzc2FyeQ0KPiAgICAgICBjb25kaXRpb24gdG8gYmUgZnVsZmlsbGVkIGJ5IHJvdXRp bmcgcHJvdG9jb2xzIHRvIGJlIGxvb3AgZnJlZS4NCj4gDQo+IA0KPiAgICAzLiBNZXRob2Qgb2Yg Q29tbXVuaWNhdGlvbg0KPiANCj4gDQo+ICAgICAgIFR3byBhcHByb2FjaGVzIGV4aXN0IGZvciBj b21tdW5pY2F0aW9uIGJldHdlZW4gTGV2ZWwgTiBhbmQgTisxLg0KPiANCj4gDQo+ICAgICAgIC0g VGhlIGZpcnN0IGFwcHJvYWNoIHBsYWNlcyBhbiBpbnN0YW5jZSBvZiBhIExldmVsIE4gcm91dGlu Zw0KPiAgICAgICAgIGZ1bmN0aW9uIGFuZCBhbiBpbnN0YW5jZSBvZiBhIExldmVsIE4rMSByb3V0 aW5nIGZ1bmN0aW9uIGluIHRoZQ0KPiAgICAgICAgIHNhbWUgc3lzdGVtLiBUaGUgY29tbXVuaWNh dGlvbnMgaW50ZXJmYWNlIGlzIHdpdGhpbiBhIHNpbmdsZQ0KPiAgICAgICAgIHN5c3RlbSBhbmQg aXMgdGh1cyBub3QgYW4gb3BlbiBpbnRlcmZhY2Ugc3ViamVjdCB0bw0KPiAgICAgICAgIHN0YW5k YXJkaXphdGlvbi4NCj4gDQo+IA0KPiAgICAgICAtIFRoZSBzZWNvbmQgYXBwcm9hY2ggcGxhY2Vz IHRoZSBMZXZlbCBOIHJvdXRpbmcgZnVuY3Rpb24gb24gYQ0KPiAgICAgICAgIHNlcGFyYXRlIHN5 c3RlbSBmcm9tIHRoZSBMZXZlbCBOKzEgcm91dGluZyBmdW5jdGlvbi4gSW4gdGhpcw0KPiAgICAg ICAgIGNhc2UsIGEgY29tbXVuaWNhdGlvbiBpbnRlcmZhY2UgbXVzdCBiZSB1c2VkIGJldHdlZW4g dGhlDQo+ICAgICAgICAgc3lzdGVtcyBjb250YWluaW5nIHRoZSByb3V0aW5nIGZ1bmN0aW9ucyBm b3IgZGlmZmVyZW50IGxldmVscy4NCj4gICAgICAgICBUaGlzIGNvbW11bmljYXRpb24gaW50ZXJm YWNlIGFuZCBtZWNoYW5pc21zIGFyZSBvdXRzaWRlIHRoZQ0KPiAgICAgICAgIHNjb3BlIG9mIHRo aXMgZG9jdW1lbnQuDQo+IA0KPiANCj4gNC4zIENvbmZpZ3VyYXRpb24NCj4gDQo+IA0KPiA0LjMu MSBDb25maWd1cmluZyB0aGUgTXVsdGktTGV2ZWwgSGllcmFyY2h5DQo+IA0KPiANCj4gICAgVGhl IFJDIE1VU1Qgc3VwcG9ydCBzdGF0aWMgKGkuZS4gb3BlcmF0b3IgYXNzaXN0ZWQpIGFuZCBNQVkg c3VwcG9ydA0KPiAgICBhdXRvbWF0ZWQgY29uZmlndXJhdGlvbiBvZiB0aGUgaW5mb3JtYXRpb24g ZGVzY3JpYmluZyBpdHMNCj4gPCAgcmVsYXRpb25zaGlwIHRvIHBhcmVudCBhbmQgaXRzIGNoaWxk IHdpdGhpbiB0aGUgaGllcmFyY2hpY2FsDQo+IA0KPj4gcmVsYXRpb25zaGlwIHRvIGl0cyBwYXJl bnQgYW5kIGl0cyBjaGlsZHJlbiB3aXRoaW4gdGhlIGhpZXJhcmNoaWNhbA0KPiANCj4gICAgc3Ry dWN0dXJlIChpbmNsdWRpbmcgUkEgSUQgYW5kIFJDIElEKS4gV2hlbiBhcHBsaWVkIHJlY3Vyc2l2 ZWx5LCB0aGUNCj4gICAgd2hvbGUgaGllcmFyY2h5IGlzIHRodXMgY29uZmlndXJlZC4NCj4gDQo+ IA0KPiA0LjMuMiBDb25maWd1cmluZyBSQyBBZGphY2VuY2llcw0KPiANCj4gDQo+ICAgIFRoZSBS QyBNVVNUIHN1cHBvcnQgc3RhdGljIChpLmUuIG9wZXJhdG9yIGFzc2lzdGVkKSBhbmQgTUFZIHN1 cHBvcnQNCj4gICAgYXV0b21hdGVkIGNvbmZpZ3VyYXRpb24gb2YgdGhlIGluZm9ybWF0aW9uIGRl c2NyaWJpbmcgaXRzIGFzc29jaWF0ZWQNCj4gDQo+PiBQQyBhZGphY2VuY2llcyB0byBvdGhlciBS Q3MgYm91bmRlZCB0byB0aGUgc2FtZSBwYXJlbnQgUkEuIFRoZQ0KPiANCj4gPCAgUEMgYWRqYWNl bmNpZXMgdG8gb3RoZXIgUkNzIGJvdW5kIHRvIHRoZSBzYW1lIHBhcmVudCBSQS4gVGhlDQo+ICMj IERvIHlvdSByZWFsbHkgbWVhbiBQQyBvciBSQz8NCj4gICAgcm91dGluZyBwcm90b2NvbCBTSE9V TEQgc3VwcG9ydCBhbGwgdGhlIHR5cGVzIG9mIFJDIGFkamFjZW5jaWVzDQo+ICAgIGRlc2NyaWJl ZCBpbiBTZWN0aW9uIDkgb2YgW0cuNzcxNV0uIFRoZSBsYXR0ZXIgaW5jbHVkZXMgY29uZ3J1ZW50 DQo+ICAgIHRvcG9sb2d5ICh3aXRoIGRpc3RyaWJ1dGVkIFJDKSBhbmQgaHViYmVkIHRvcG9sb2d5 IChlLmcuIG5vdGUgdGhhdA0KPiAgICB0aGUgbGF0dGVyIGRvZXMgbm90IGF1dG9tYXRpY2FsbHkg aW1wbHkgZGVzaWduYXRlZCBSQykuDQo+IA0KPiANCj4gNC40IEV2b2x1dGlvbg0KPiANCj4gDQo+ ICAgIFRoZSBjb250YWlubWVudCByZWxhdGlvbnNoaXBzIG9mIFJBcyBNQVkgY2hhbmdlLCBtb3Rp dmF0ZWQgYnkgZXZlbnRzDQo+ICAgIHN1Y2ggYXMgbWVyZ2VycywgYWNxdWlzaXRpb25zLCBhbmQg ZGl2ZXN0aXR1cmVzLg0KPiANCj4gDQo+ICAgIFRoZSByb3V0aW5nIHByb3RvY29sIFNIT1VMRCBi ZSBjYXBhYmxlIG9mIHN1cHBvcnRpbmcgYXJjaGl0ZWN0dXJhbA0KPiAgICBldm9sdXRpb24gaW4g dGVybXMgb2YgbnVtYmVyIG9mIGhpZXJhcmNoaWNhbCBsZXZlbHMgb2YgUkFzLCBhcyB3ZWxsDQo+ IA0KPiANCj4gDQo+IFcuQWxhbnFhciBldCBhbC4gLSBFeHBpcmVzIE9jdG9iZXIgMjAwNCAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIDcNCj4gZHJhZnQtaWV0Zi1jY2FtcC1nbXBscy1hc29u LXJvdXRpbmctcmVxdHMtMDMudHh0ICAgICAgICAgICAgQXByaWwgMjAwNA0KPiANCj4gDQo+IA0K PiA8ICBhcyBhZ2dyZWdhdGlvbiBhbmQgc2VnbWVudGF0aW9uIG9mIFJBcy4gUkEgSURzIHVuaXF1 ZW5lc3Mgd2l0aGluIGFuDQo+IA0KPj4gYXMgYWdncmVnYXRpb24gYW5kIHNlZ21lbnRhdGlvbiBv ZiBSQXMuIFJBIElEIHVuaXF1ZW5lc3Mgd2l0aGluIGFuDQo+IA0KPiAgICBhZG1pbmlzdHJhdGl2 ZSBkb21haW4gTUFZIGZhY2lsaXRhdGUgdGhlc2Ugb3BlcmF0aW9ucy4gVGhlIHJvdXRpbmcNCj4g ICAgcHJvdG9jb2wgaXMgbm90IGV4cGVjdGVkIHRvIGF1dG9tYXRpY2FsbHkgaW5pdGlhdGUgYW5k L29yIGV4ZWN1dGUNCj4gICAgdGhlc2Ugb3BlcmF0aW9ucy4gUmVjb25maWd1cmF0aW9uIG9mIHRo ZSBSQSBoaWVyYXJjaHkgTUFZIG5vdA0KPiAjIyBTdXJlbHkgdGhpcyBpcyBNVVNUPw0KPiAgICBk aXNydXB0IGNhbGxzIGluIHByb2dyZXNzLCB0aG91Z2ggY2FsbHMgYmVpbmcgc2V0IHVwIG1heSBm YWlsIHRvDQo+ICAgIGNvbXBsZXRlLCBhbmQgdGhlIGNhbGwgc2V0dXAgc2VydmljZSBtYXkgYmUg dW5hdmFpbGFibGUgZHVyaW5nDQo+ICAgIHJlY29uZmlndXJhdGlvbiBhY3Rpb25zLg0KPiANCj4g DQo+IDQuNSBSb3V0aW5nIEF0dHJpYnV0ZXMNCj4gDQo+IA0KPiAgICBSb3V0aW5nIGZvciB0cmFu c3BvcnQgbmV0d29ya3MgaXMgcGVyZm9ybWVkIG9uIGEgcGVyIGxheWVyIGJhc2lzLA0KPiAgICB3 aGVyZSB0aGUgcm91dGluZyBwYXJhZGlnbXMgTUFZIGRpZmZlciBhbW9uZyBsYXllcnMgYW5kIHdp dGhpbiBhDQo+IDwgIGxheWVyLiBOb3QgYWxsIGVxdWlwbWVudCBzdXBwb3J0IHRoZSBzYW1lIHNl dCBvZiB0cmFuc3BvcnQgbGF5ZXJzIG9yDQo+IA0KPj4gbGF5ZXIuIE5vdCBhbGwgZXF1aXBtZW50 IHN1cHBvcnRzIHRoZSBzYW1lIHNldCBvZiB0cmFuc3BvcnQgbGF5ZXJzIG9yDQo+IA0KPiAgICB0 aGUgc2FtZSBkZWdyZWUgb2YgY29ubmVjdGlvbiBmbGV4aWJpbGl0eSBhdCBhbnkgZ2l2ZW4gbGF5 ZXIuIEENCj4gICAgc2VydmVyIGxheWVyIHRyYWlsIG1heSBzdXBwb3J0IHZhcmlvdXMgY2xpZW50 cywgaW52b2x2aW5nIGRpZmZlcmVudA0KPiAgICBhZGFwdGF0aW9uIGZ1bmN0aW9ucy4gQWRkaXRp b25hbGx5LCBlcXVpcG1lbnQgbWF5IHN1cHBvcnQgdmFyaWFibGUNCj4gICAgYWRhcHRhdGlvbiBm dW5jdGlvbmFsaXR5LCB3aGVyZWJ5IGEgc2luZ2xlIHNlcnZlciBsYXllciB0cmFpbA0KPiAgICBk eW5hbWljYWxseSBzdXBwb3J0cyBkaWZmZXJlbnQgbXVsdGlwbGV4aW5nIHN0cnVjdHVyZXMuIEFz IGEgcmVzdWx0LA0KPiAgICByb3V0aW5nIGluZm9ybWF0aW9uIE1BWSBpbmNsdWRlIGxheWVyIHNw ZWNpZmljLCBsYXllciBpbmRlcGVuZGVudCwNCj4gICAgYW5kIGNsaWVudC9zZXJ2ZXIgYWRhcHRh dGlvbiBpbmZvcm1hdGlvbi4NCj4gDQo+IA0KPiA0LjUuMSBUYXhvbm9teSBvZiBSb3V0aW5nIEF0 dHJpYnV0ZXMNCj4gDQo+IA0KPiAgICBBdHRyaWJ1dGVzIGNhbiBiZSBvcmdhbml6ZWQgYWNjb3Jk aW5nIHRvIHRoZSBmb2xsb3dpbmcgY2F0ZWdvcmllczoNCj4gDQo+IA0KPiAgICAtIE5vZGUgcmVs YXRlZCBvciBsaW5rIHJlbGF0ZWQNCj4gDQo+IA0KPiAgICAtIFByb3Zpc2lvbmVkLCBuZWdvdGlh dGVkIG9yIGF1dG9tYXRpY2FsbHkgY29uZmlndXJlZA0KPiANCj4gDQo+ICAgIC0gSW5oZXJpdGVk IG9yIGxheWVyIHNwZWNpZmljIChjbGllbnQgbGF5ZXJzIGNhbiBpbmhlcml0IHNvbWUNCj4gICAg ICBhdHRyaWJ1dGVzIGZyb20gdGhlIHNlcnZlciBsYXllciB3aGlsZSBvdGhlciBhdHRyaWJ1dGVz IGxpa2UNCj4gICAgICBMaW5rIENhcGFjaXR5IGFyZSBzcGVjaWZpZWQgYnkgbGF5ZXIpLg0KPiAN Cj4gDQo+ICAgIChDb21wb25lbnQpIGxpbmsgYXR0cmlidXRlcyBNQVkgYmUgc3RhdGljYWxseSBv ciBhdXRvbWF0aWNhbGx5DQo+ICAgIGNvbmZpZ3VyZWQgZm9yIGVhY2ggdHJhbnNwb3J0IG5ldHdv cmsgbGF5ZXIuIFRoaXMgbWF5IGxlYWQgdG8NCj4gICAgdW5uZWNlc3NhcnkgcmVwZXRpdGlvbi4g SGVuY2UsIHRoZSBpbmhlcml0YW5jZSBwcm9wZXJ0eSBvZg0KPiAgICBhdHRyaWJ1dGVzIE1BWSBh bHNvIGJlIHVzZWQgdG8gb3B0aW1pemUgdGhlIGNvbmZpZ3VyYXRpb24gcHJvY2Vzcy4NCj4gDQo+ IA0KPiA8ICBBU09OIHVzZXMgdGhlIHRlcm0sIFNOUCwgZm9yIHRoZSBjb250cm9sIHBsYW5lIHJl cHJlc2VudGF0aW9uIG9mIGENCj4gDQo+PiBBU09OIHVzZXMgdGhlIHRlcm0sIFN1Ym5ldHdvcmsg UG9pbnQgKFNOUCksIGZvciB0aGUgY29udHJvbCBwbGFuZSByZXByZXNlbnRhdGlvbiBvZiBhDQo+ IA0KPiAgICB0cmFuc3BvcnQgcGxhbmUgcmVzb3VyY2UuIFRoZSBjb250cm9sIHBsYW5lIHJlcHJl c2VudGF0aW9uIGFuZA0KPiAgICB0cmFuc3BvcnQgcGxhbmUgdG9wb2xvZ3kgaXMgTk9UIGFzc3Vt ZWQgdG8gYmUgY29uZ3J1ZW50LCB0aGUgY29udHJvbA0KPiAgICBwbGFuZSByZXByZXNlbnRhdGlv biBTSEFMTCBub3QgYmUgcmVzdHJpY3RlZCBieSB0aGUgcGh5c2ljYWwNCj4gICAgdG9wb2xvZ3ku IFRoZSByZWxhdGlvbmFsIGdyb3VwaW5nIG9mIFNOUHMgZm9yIHJvdXRpbmcgaXMgdGVybWVkIGEN Cj4gPCAgU05QUC4gVGhlIHJvdXRpbmcgZnVuY3Rpb24gdW5kZXJzdGFuZHMgdG9wb2xvZ3kgaW4g dGVybXMgb2YgU05QUA0KPiANCj4+IFNOUCBQb29sIChTTlBQKS4gVGhlIHJvdXRpbmcgZnVuY3Rp b24gdW5kZXJzdGFuZHMgdG9wb2xvZ3kgaW4gdGVybXMgb2YgU05QUA0KPiANCj4gICAgbGlua3Mu IEdyb3VwaW5nIE1BWSBiZSBiYXNlZCBvbiBkaWZmZXJlbnQgbGluayBhdHRyaWJ1dGVzIChlLmcu LA0KPiAgICBTUkxHIGluZm9ybWF0aW9uLCBsaW5rIHdlaWdodCwgZXRjKS4NCj4gDQo+IA0KPiAg ICBUd28gUkFzIG1heSBiZSBsaW5rZWQgYnkgb25lIG9yIG1vcmUgU05QUCBsaW5rcy4gTXVsdGlw bGUgU05QUCBsaW5rcw0KPiAgICBNQVkgYmUgcmVxdWlyZWQgd2hlbiBjb21wb25lbnQgbGlua3Mg YXJlIG5vdCBlcXVpdmFsZW50IGZvciByb3V0aW5nDQo+ICAgIHB1cnBvc2VzIHdpdGggcmVzcGVj dCB0byB0aGUgUkFzIHRoZXkgYXJlIGF0dGFjaGVkIHRvLCBvciB0byB0aGUNCj4gICAgY29udGFp bmluZyBSQSwgb3Igd2hlbiBzbWFsbGVyIGdyb3VwaW5ncyBhcmUgcmVxdWlyZWQuDQo+IA0KPiAN Cj4gDQo+IA0KPiBXLkFsYW5xYXIgZXQgYWwuIC0gRXhwaXJlcyBPY3RvYmVyIDIwMDQgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICA4DQo+IGRyYWZ0LWlldGYtY2NhbXAtZ21wbHMtYXNvbi1y b3V0aW5nLXJlcXRzLTAzLnR4dCAgICAgICAgICAgIEFwcmlsIDIwMDQNCj4gDQo+IA0KPiANCj4g NC41LjIgQ29tbW9ubHkgQWR2ZXJ0aXNlZCBJbmZvcm1hdGlvbg0KPiANCj4gDQo+ICAgIEFkdmVy dGlzZW1lbnRzIE1BWSBjb250YWluIHRoZSBmb2xsb3dpbmcgY29tbW9uIHNldCBvZiBpbmZvcm1h dGlvbg0KPiAgICByZWdhcmRsZXNzIG9mIHdoZXRoZXIgdGhleSBhcmUgbGluayBvciBub2RlIHJl bGF0ZWQ6DQo+IDwgIC0gUkEgSUQgb2Ygd2hpY2ggdGhlIGFkdmVydGlzZW1lbnQgaXMgYm91bmRl ZA0KPiANCj4+IC0gUkEgSUQgb2YgdGhlIFJBIHRvIHdoaWNoIHRoZSBhZHZlcnRpc2VtZW50IGlz IGJvdW5kDQo+IA0KPiAgICAtIFJDIElEIG9mIHRoZSBlbnRpdHkgZ2VuZXJhdGluZyB0aGUgYWR2 ZXJ0aXNlbWVudA0KPiAgICAtIEluZm9ybWF0aW9uIHRvIHVuaXF1ZWx5IGlkZW50aWZ5IGFkdmVy dGlzZW1lbnRzDQo+ICAgIC0gSW5mb3JtYXRpb24gdG8gZGV0ZXJtaW5lIHdoZXRoZXIgYW4gYWR2 ZXJ0aXNlbWVudCBoYXMgYmVlbiB1cGRhdGVkDQo+ICAgIC0gSW5mb3JtYXRpb24gdG8gaW5kaWNh dGUgd2hlbiBhbiBhZHZlcnRpc2VtZW50IGhhcyBiZWVuIGRlcml2ZWQNCj4gICAgICBmcm9tIGEg ZGlmZmVyZW50IGxldmVsIFJBLg0KPiANCj4gDQo+IDQuNS4zIE5vZGUgQXR0cmlidXRlcw0KPiAN Cj4gDQo+ICAgIEFsbCBub2RlcyBiZWxvbmcgdG8gYSBSQSwgaGVuY2UsIHRoZSBSQSBJRCBjYW4g YmUgY29uc2lkZXJlZCBhbg0KPiAgICBhdHRyaWJ1dGUgb2YgYWxsIG5vZGVzLiBHaXZlbiB0aGF0 IG5vIGRpc3RpbmN0aW9uIGlzIG1hZGUgYmV0d2Vlbg0KPiAgICBhYnN0cmFjdCBub2RlcyBhbmQg dGhvc2UgdGhhdCBjYW5ub3QgYmUgZGVjb21wb3NlZCBhbnkgZnVydGhlciwgdGhlDQo+ICAgIHNh bWUgYXR0cmlidXRlcyBNQVkgYmUgdXNlZCBmb3IgdGhlaXIgYWR2ZXJ0aXNlbWVudC4gSW4gdGhl DQo+IDwgIGZvbGxvd2luZyB0YWJsZXMsIENhcGFiaWxpdHkgcmVmZXJzIHRvIGxldmVsIG9mIHN1 cHBvcnQgcmVxdWlyZWQgaW4NCj4gDQo+PiBmb2xsb3dpbmcgdGFibGVzLCBDYXBhYmlsaXR5IHJl ZmVycyB0byB0aGUgbGV2ZWwgb2Ygc3VwcG9ydCByZXF1aXJlZCBpbg0KPiANCj4gICAgdGhlIHJl YWxpemF0aW9uIG9mIGEgbGluayBzdGF0ZSByb3V0aW5nIHByb3RvY29sLCB3aGVyZWFzIFVzYWdl DQo+IDwgIHJlZmVycyB0byBkZWdyZWUgb2Ygb3BlcmF0aW9uYWwgYW5kIGltcGxlbWVudGF0aW9u IGZsZXhpYmlsaXR5Lg0KPiANCj4+IHJlZmVycyB0byB0aGUgZGVncmVlIG9mIG9wZXJhdGlvbmFs IGFuZCBpbXBsZW1lbnRhdGlvbiBmbGV4aWJpbGl0eS4NCj4gDQo+IA0KPiANCj4gICAgVGhlIGZv bGxvd2luZyBOb2RlIEF0dHJpYnV0ZXMgYXJlIGRlZmluZWQ6DQo+IA0KPiANCj4gICAgICAgIEF0 dHJpYnV0ZSAgICAgICAgQ2FwYWJpbGl0eSAgICAgIFVzYWdlDQo+ICAgICAgICAtLS0tLS0tLS0t LSAgICAgIC0tLS0tLS0tLS0tICAgICAtLS0tLS0tLS0NCj4gICAgICAgIE5vZGUgSUQgICAgICAg ICAgUkVRVUlSRUQgICAgICAgIFJFUVVJUkVEDQo+ICAgICAgICBSZWFjaGFiaWxpdHkgICAgIFJF UVVJUkVEICAgICAgICBPUFRJT05BTA0KPiANCj4gDQo+ICAgICAgICAgICAgICAgICBUYWJsZSAx LiBOb2RlIEF0dHJpYnV0ZXMNCj4gDQo+IA0KPiAgICBSZWFjaGFiaWxpdHkgaW5mb3JtYXRpb24g ZGVzY3JpYmVzIHRoZSBzZXQgb2YgZW5kcG9pbnRzIHRoYXQgYXJlDQo+ICAgIHJlYWNoYWJsZSBi eSB0aGUgYXNzb2NpYXRlZCBub2RlLiBJdCBNQVkgYmUgYWR2ZXJ0aXNlZCBhcyBhIHNldCBvZg0K PiAgICBhc3NvY2lhdGVkIGV4dGVybmFsIChlLmcuIFVOSSkgYWRkcmVzcy9hZGRyZXNzIHByZWZp eGVzIG9yIGEgc2V0IG9mDQo+ICAgIGFzc29jaWF0ZWQgU05QUCBsaW5rIElEcy9TTlBQIElEIHBy ZWZpeGVzLCB0aGUgc2VsZWN0aW9uIG9mIHdoaWNoDQo+ICAgIE1VU1QgYmUgY29uc2lzdGVudCB3 aXRoaW4gdGhlIGFwcGxpY2FibGUgc2NvcGUuIFRoZXNlIGFyZSBjb250cm9sDQo+ICAgIHBsYW5l IGlkZW50aWZpZXJzLCB0aGUgZm9ybWF0cyBvZiB0aGVzZSBpZGVudGlmaWVycyBpbiBhIHByb3Rv Y29sDQo+ICAgIHJlYWxpemF0aW9uIGlzIGltcGxlbWVudGF0aW9uIHNwZWNpZmljIGFuZCBvdXRz aWRlIHRoZSBzY29wZSBvZiB0aGlzDQo+ICAgIGRvY3VtZW50Lg0KPiANCj4gDQo+ICAgIE5vdGU6 IG5vIGRpc3RpbmN0aW9uIGlzIG1hZGUgYmV0d2VlbiBub2RlcyB0aGF0IG1heSBoYXZlIGZ1cnRo ZXINCj4gICAgaW50ZXJuYWwgZGV0YWlscyAoaS5lLiwgYWJzdHJhY3Qgbm9kZXMpIGFuZCB0aG9z ZSB0aGF0IGNhbm5vdCBiZQ0KPiA8ICBkZWNvbXBvc2VkIGFueSBmdXJ0aGVyLiBIZW5jZSB0aGUg YXR0cmlidXRlcyBvZiBhIG5vZGUgYXJlIG5vdCBiZQ0KPiANCj4+IGRlY29tcG9zZWQgYW55IGZ1 cnRoZXIuIEhlbmNlIHRoZSBhdHRyaWJ1dGVzIG9mIGEgbm9kZSBhcmUgbm90DQo+IA0KPiAgICBj b25zaWRlcmVkIG9ubHkgYXMgc2luZ2xlIHN3aXRjaCBhdHRyaWJ1dGVzIGJ1dCBNQVkgYXBwbHkg dG8gYSBub2RlDQo+ICAgIGF0IGEgaGlnaGVyIGxldmVsIG9mIHRoZSBoaWVyYXJjaHkgdGhhdCBy ZXByZXNlbnRzIGEgc3ViLW5ldHdvcmsuDQo+IA0KPiANCj4gNC41LjQgTGluayBBdHRyaWJ1dGVz DQo+IA0KPiANCj4gICAgVGhlIGZvbGxvd2luZyBMaW5rIEF0dHJpYnV0ZXMgYXJlIGRlZmluZWQ6 DQo+IA0KPiANCj4gICAgICAgIExpbmsgQXR0cmlidXRlICAgICAgICAgICAgICAgICAgIENhcGFi aWxpdHkgICAgICBVc2FnZQ0KPiAgICAgICAgLS0tLS0tLS0tLS0tLS0tICAgICAgICAgICAgICAg ICAgLS0tLS0tLS0tLS0gICAgIC0tLS0tLS0tLQ0KPiAgICAgICAgTG9jYWwgU05QUCBsaW5rIElE ICAgICAgICAgICAgICAgUkVRVUlSRUQgICAgICAgIFJFUVVJUkVEDQo+IA0KPiANCj4gDQo+IFcu QWxhbnFhciBldCBhbC4gLSBFeHBpcmVzIE9jdG9iZXIgMjAwNCAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIDkNCj4gZHJhZnQtaWV0Zi1jY2FtcC1nbXBscy1hc29uLXJvdXRpbmctcmVxdHMt MDMudHh0ICAgICAgICAgICAgQXByaWwgMjAwNA0KPiANCj4gDQo+IA0KPiAgICAgICAgUmVtb3Rl IFNOUFAgbGluayBJRCAgICAgICAgICAgICAgUkVRVUlSRUQgICAgICAgIFJFUVVJUkVEDQo+ICAg ICAgICBMYXllciBTcGVjaWZpYyBDaGFyYWN0ZXJpc3RpY3MgICBzZWUgVGFibGUgMw0KPiANCj4g DQo+ICAgICAgICAgICAgICAgICBUYWJsZSAyLiBMaW5rIEF0dHJpYnV0ZXMNCj4gDQo+IA0KPiAg ICBUaGUgU05QUCBsaW5rIElEIG5hbWUgTVVTVCBiZSBzdWZmaWNpZW50IHRvIHVuaXF1ZWx5IGlk ZW50aWZ5IHRoZQ0KPiAjIyBXaHkgZG8geW91IHNheSAiU05QUCBsaW5rIElEIG5hbWUiPyBUaGlz IGlzIG5vdCBkZWZpbmVkLg0KPiAjIyBEbyB5b3UgbWVhbiAiU05QUCBsaW5rIElEIj8NCj4gICAg Y29ycmVzcG9uZGluZyB0cmFuc3BvcnQgcGxhbmUgcmVzb3VyY2UgdGFraW5nIGludG8gYWNjb3Vu dA0KPiAgICBzZXBhcmF0aW9uIG9mIGRhdGEgYW5kIGNvbnRyb2wgcGxhbmVzIChzZWUgU2VjdGlv biA0LjUuMSwgdGhlDQo+ICAgIGNvbnRyb2wgcGxhbmUgcmVwcmVzZW50YXRpb24gYW5kIHRyYW5z cG9ydCBwbGFuZSB0b3BvbG9neSBpcyBub3QNCj4gICAgYXNzdW1lZCB0byBiZSBjb25ncnVlbnQp LiBUaGUgU05QUCBsaW5rIElEIGZvcm1hdCBpcyByb3V0aW5nDQo+ICAgIHByb3RvY29sIHNwZWNp ZmljLg0KPiANCj4gDQo+ICAgIE5vdGU6IHdoZW4gdGhlIHJlbW90ZSBlbmQgb2YgYSBTTlBQIGxp bmsgaXMgbG9jYXRlZCBvdXRzaWRlIG9mIHRoZQ0KPiAgICBSQSwgdGhlIHJlbW90ZSBTTlBQIGxp bmsgSUQgaXMgT1BUSU9OQUwuDQo+IA0KPiANCj4gICAgVGhlIGZvbGxvd2luZyBsaW5rIGNoYXJh Y3RlcmlzdGljIGF0dHJpYnV0ZXMgYXJlIGRlZmluZWQ6DQo+IA0KPiANCj4gICAgLSBTaWduYWwg VHlwZTogVGhpcyBpZGVudGlmaWVzIHRoZSBjaGFyYWN0ZXJpc3RpYyBpbmZvcm1hdGlvbiBvZiB0 aGUNCj4gICAgICBsYXllciBuZXR3b3JrLg0KPiANCj4gDQo+ICAgIC0gTGluayBXZWlnaHQ6IFRo ZSBtZXRyaWMgaW5kaWNhdGluZyB0aGUgcmVsYXRpdmUgZGVzaXJhYmlsaXR5IG9mIGENCj4gICAg ICBwYXJ0aWN1bGFyIGxpbmsgb3ZlciBhbm90aGVyIGUuZy4gZHVyaW5nIHBhdGggY29tcHV0YXRp b24uDQo+IA0KPiANCj4gICAgLSBSZXNvdXJjZSBDbGFzczogVGhpcyBjb3JyZXNwb25kcyB0byB0 aGUgc2V0IG9mIGFkbWluaXN0cmF0aXZlDQo+ICAgICAgZ3JvdXBzIGFzc2lnbmVkIGJ5IHRoZSBv cGVyYXRvciB0byB0aGlzIGxpbmsuIEEgbGluayBNQVkgYmVsb25nIHRvDQo+ICAgICAgemVybywg b25lIG9yIG1vcmUgYWRtaW5pc3RyYXRpdmUgZ3JvdXBzLg0KPiANCj4gDQo+ICAgIC0gQ29ubmVj dGlvbiBUeXBlczogVGhpcyBhdHRyaWJ1dGUgaWRlbnRpZmllcyB3aGV0aGVyIHRoZSBsb2NhbCBT TlANCj4gICAgICByZXByZXNlbnRzIGEgVENQLCBDUCwgb3IgY2FuIGJlIGZsZXhpYmx5IGNvbmZp Z3VyZWQgYXMgYSBUQ1AuDQo+ICMjIFBsZWFzZSBleHBhbmQgVENQIGFuZCBDUCBpbiB0aGVpciBm aXJzdCB1c2VzDQo+IA0KPiANCj4gICAgLSBMaW5rIENhcGFjaXR5OiBUaGlzIHByb3ZpZGVzIHRo ZSBzdW0gb2YgdGhlIGF2YWlsYWJsZSBhbmQNCj4gICAgICBwb3RlbnRpYWwgYmFuZHdpZHRoIGNh cGFjaXR5IGZvciBhIHBhcnRpY3VsYXIgbmV0d29yayB0cmFuc3BvcnQNCj4gICAgICBsYXllci4g T3RoZXIgY2FwYWNpdHkgbWVhc3VyZXMgTUFZIGJlIGZ1cnRoZXIgY29uc2lkZXJlZC4NCj4gDQo+ IA0KPiAgICAtIExpbmsgQXZhaWxhYmlsaXR5OiBUaGlzIHJlcHJlc2VudHMgdGhlIHN1cnZpdmFi aWxpdHkgY2FwYWJpbGl0eQ0KPiAgICAgIHN1Y2ggYXMgdGhlIHByb3RlY3Rpb24gdHlwZSBhc3Nv Y2lhdGVkIHdpdGggdGhlIGxpbmsuDQo+IA0KPiANCj4gICAgLSBEaXZlcnNpdHkgU3VwcG9ydDog VGhpcyByZXByZXNlbnRzIGRpdmVyc2l0eSBpbmZvcm1hdGlvbiBzdWNoIGFzDQo+ICAgICAgdGhl IFNSTEcgaW5mb3JtYXRpb24gYXNzb2NpYXRlZCB3aXRoIHRoZSBsaW5rLg0KPiANCj4gDQo+ICAg IC0gTG9jYWwgQWRhcHRhdGlvbiBTdXBwb3J0OiBUaGlzIGluZGljYXRlcyB0aGUgc2V0IG9mIGNs aWVudCBsYXllcg0KPiAgICAgIGFkYXB0YXRpb25zIHN1cHBvcnRlZCBieSB0aGUgVENQIGFzc29j aWF0ZWQgd2l0aCB0aGUgTG9jYWwgU05QUC4NCj4gICAgICBUaGlzIGlzIG9ubHkgYXBwbGljYWJs ZSB3aGVuIHRoZSBsb2NhbCBTTlAgcmVwcmVzZW50cyBhIFRDUCBvciBjYW4NCj4gICAgICBiZSBm bGV4aWJseSBjb25maWd1cmVkIGFzIGEgVENQLg0KPiANCj4gDQo+ICAgICAgICAgTGluayBDaGFy YWN0ZXJpc3RpY3MgICAgICAgICAgICBDYXBhYmlsaXR5ICAgICAgVXNhZ2UNCj4gICAgICAgICAt LS0tLS0tLS0tLS0tLS0tLS0tLS0tLSAgICAgICAgIC0tLS0tLS0tLS0gICAgICAtLS0tLS0tLS0N Cj4gICAgICAgICBTaWduYWwgVHlwZSAgICAgICAgICAgICAgICAgICAgIFJFUVVJUkVEICAgICAg ICBPUFRJT05BTA0KPiAgICAgICAgIExpbmsgV2VpZ2h0ICAgICAgICAgICAgICAgICAgICAgUkVR VUlSRUQgICAgICAgIE9QVElPTkFMDQo+ICAgICAgICAgUmVzb3VyY2UgQ2xhc3MgICAgICAgICAg ICAgICAgICBSRVFVSVJFRCAgICAgICAgT1BUSU9OQUwNCj4gICAgICAgICBMb2NhbCBDb25uZWN0 aW9uIFR5cGVzICAgICAgICAgIFJFUVVJUkVEICAgICAgICBPUFRJT05BTA0KPiAgICAgICAgIExp bmsgQ2FwYWNpdHkgICAgICAgICAgICAgICAgICAgUkVRVUlSRUQgICAgICAgIE9QVElPTkFMDQo+ IA0KPiANCj4gDQo+IFcuQWxhbnFhciBldCBhbC4gLSBFeHBpcmVzIE9jdG9iZXIgMjAwNCAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgMTANCj4gZHJhZnQtaWV0Zi1jY2FtcC1nbXBscy1hc29u LXJvdXRpbmctcmVxdHMtMDMudHh0ICAgICAgICAgICAgQXByaWwgMjAwNA0KPiANCj4gDQo+IA0K PiAgICAgICAgIExpbmsgQXZhaWxhYmlsaXR5ICAgICAgICAgICAgICAgT1BUSU9OQUwgICAgICAg IE9QVElPTkFMDQo+ICAgICAgICAgRGl2ZXJzaXR5IFN1cHBvcnQgICAgICAgICAgICAgICBPUFRJ T05BTCAgICAgICAgT1BUSU9OQUwNCj4gICAgICAgICBMb2NhbCBBZGFwdGF0aW9uIHN1cHBvcnQg ICAgICAgIE9QVElPTkFMICAgICAgICBPUFRJT05BTA0KPiANCj4gDQo+ICAgICAgICAgICAgICAg IFRhYmxlIDMuIExpbmsgQ2hhcmFjdGVyaXN0aWNzDQo+IA0KPiANCj4gICAgTm90ZTogc2VwYXJh dGUgYWR2ZXJ0aXNlbWVudHMgb2YgbGF5ZXIgc3BlY2lmaWMgYXR0cmlidXRlcyBNQVkgYmUNCj4g PCAgY2hvc2VuLiBIb3dldmVyIHRoaXMgbWF5IGxlYWQgdG8gdW5uZWNlc3NhcnkgZHVwbGljYXRp b24uIFRoaXMgY2FuDQo+IA0KPj4gY2hvc2VuLiBIb3dldmVyLCB0aGlzIG1heSBsZWFkIHRvIHVu bmVjZXNzYXJ5IGR1cGxpY2F0aW9uLiBUaGlzIGNhbg0KPiANCj4gICAgYmUgYXZvaWRlZCB1c2lu ZyB0aGUgaW5oZXJpdGFuY2UgcHJvcGVydHksIHNvIHRoYXQgdGhlIGF0dHJpYnV0ZXMNCj4gICAg ZGVyaXZhYmxlIGZyb20gdGhlIGxvY2FsIGFkYXB0YXRpb24gaW5mb3JtYXRpb24gZG8gbm90IG5l ZWQgdG8gYmUNCj4gICAgYWR2ZXJ0aXNlZC4gVGh1cywgYW4gb3B0aW1pemF0aW9uIE1BWSBiZSB1 c2VkIHdoZW4gc2V2ZXJhbCBsYXllcnMNCj4gICAgYXJlIHByZXNlbnQgYnkgaW5kaWNhdGluZyB3 aGVuIGFuIGF0dHJpYnV0ZSBpcyBpbmhlcml0YWJsZSBmcm9tIGENCj4gICAgc2VydmVyIGxheWVy Lg0KPiANCj4gDQo+IDUuIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zDQo+IA0KPiANCj4gICAgQVNP TiByb3V0aW5nIHByb3RvY29sIE1VU1QgZGVsaXZlciB0aGUgb3BlcmF0aW9uYWwgc2VjdXJpdHkN Cj4gICAgb2JqZWN0aXZlcyB3aGVyZSByZXF1aXJlZC4gVGhlc2Ugb2JqZWN0aXZlcyBkbyBub3Qg bmVjZXNzYXJpbHkgaW1wbHkNCj4gICAgcmVxdWlyZW1lbnRzIG9uIHRoZSByb3V0aW5nIHByb3Rv Y29sIGl0c2VsZiwgYW5kIE1BWSBiZSBtZXQgYnkgb3RoZXINCj4gICAgZXN0YWJsaXNoZWQgbWVh bnMuDQo+IA0KPiANCj4gNi4gQ29uY2x1c2lvbnMNCj4gDQo+IA0KPiAgICBUaGUgZGVzY3JpcHRp b24gb2YgdGhlIEFTT04gcm91dGluZyBhcmNoaXRlY3R1cmUgYW5kIGNvbXBvbmVudHMgaXMNCj4g ICAgcHJvdmlkZWQgaW4gdGVybXMgb2Ygcm91dGluZyBmdW5jdGlvbmFsaXR5LiBUaGlzIGRlc2Ny aXB0aW9uIGlzIG9ubHkNCj4gICAgY29uY2VwdHVhbDogbm8gcGh5c2ljYWwgcGFydGl0aW9uaW5n IG9mIHRoZXNlIGZ1bmN0aW9ucyBpcyBpbXBsaWVkLg0KPiANCj4gDQo+ICAgIEluIHN1bW1hcnks IHRoZSBBU09OIHJvdXRpbmcgYXJjaGl0ZWN0dXJlIGFzc3VtZXM6DQo+ICAgIC0gQSBuZXR3b3Jr IGlzIHN1YmRpdmlkZWQgaW50byBBU09OIFJBcywgd2hpY2ggTUFZIHN1cHBvcnQgbXVsdGlwbGUN Cj4gICAgICByb3V0aW5nIHByb3RvY29scywgbm8gb25lLXRvLW9uZSByZWxhdGlvbnNoaXAgU0hB TEwgYmUgYXNzdW1lZA0KPiAgICAtIFJvdXRpbmcgQ29udHJvbGxlcnMgKFJDKSBwcm92aWRlIGZv ciB0aGUgZXhjaGFuZ2Ugb2Ygcm91dGluZw0KPiAgICAgIGluZm9ybWF0aW9uIChwcmltaXRpdmVz KSBmb3IgdGhlIFJBLiBUaGUgUkMgaXMgcHJvdG9jb2wNCj4gICAgICBpbmRlcGVuZGVudCBhbmQg TUFZIGJlIHJlYWxpemVkIGJ5IG11bHRpcGxlLCBkaWZmZXJlbnQgcHJvdG9jb2wNCj4gICAgICBj b250cm9sbGVycyB3aXRoaW4gYSBSQS4gVGhlIHJvdXRpbmcgaW5mb3JtYXRpb24gZXhjaGFuZ2Vk IGJldHdlZW4NCj4gICAgICBSQ3MgU0hBTEwgYmUgc3ViamVjdCB0byBwb2xpY3kgY29uc3RyYWlu dHMgaW1wb3NlZCBhdCByZWZlcmVuY2UNCj4gICAgICBwb2ludHMgKEV4dGVybmFsLSBhbmQgSW50 ZXJuYWwtTk5JKQ0KPiA8ICAtIEEgbXVsdGktbGV2ZWwgUkEgaGllcmFyY2h5IGJhc2VkIG9uIGNv bnRhaW5tZW50LCBvbmx5IHRoZSBSQ3Mgb2YNCj4gPCAgICB0aGUgcGFyZW50IFJBIGNvbW11bmlj YXRlLiBSQ3Mgb2YgY2hpbGQgUkFzIG5ldmVyIGNvbW11bmljYXRlIHdpdGgNCj4gDQo+PiAtIElu IGEgbXVsdGktbGV2ZWwgUkEgaGllcmFyY2h5IGJhc2VkIG9uIGNvbnRhaW5tZW50LCBjb21tdW5p Y2F0aW9uDQo+PiAgIGJldHdlZW4gUkNzIG9mIGRpZmZlcmVudCBSQXMgb25seSBoYXBwZW5zIHdo ZW4gdGhlcmUgaXMgYSBwYXJlbnQvDQo+PiAgIGNoaWxkIHJlbGF0aW9uc2hpcCBiZXR3ZWVuIHRo ZSBSQXMuIFJDcyBvZiBjaGlsZCBSQXMgbmV2ZXIgY29tbXVuaWNhdGUgd2l0aA0KPiANCj4gICAg ICB0aGUgUkNzIG9mIG90aGVyIGNoaWxkIFJBcy4gVGhlcmUgU0hPVUxEIG5vdCBiZSBhbnkgZGVw ZW5kZW5jaWVzDQo+ICAgICAgb24gdGhlIGRpZmZlcmVudCByb3V0aW5nIHByb3RvY29scyB1c2Vk IHdpdGhpbiBhIGNoaWxkIFJBIGFuZCB0aGF0DQo+ICAgICAgb2YgaXRzIHBhcmVudC4gVGhlIHJv dXRpbmcgaW5mb3JtYXRpb24gZXhjaGFuZ2VkIHdpdGhpbiB0aGUgcGFyZW50DQo+ICAgICAgUkEg U0hBTEwgYmUgaW5kZXBlbmRlbnQgb2YgYm90aCB0aGUgcm91dGluZyBwcm90b2NvbCBvcGVyYXRp bmcNCj4gICAgICB3aXRoaW4gYSBjaGlsZCBSQSwgYW5kIGFueSBjb250cm9sIGRpc3RyaWJ1dGlv biBjaG9pY2UocyksIGUuZy4NCj4gICAgICBjZW50cmFsaXplZCwgZnVsbHkgZGlzdHJpYnV0ZWQu DQo+ICAgIC0gRm9yIGEgUkEsIHRoZSBzZXQgb2YgUkNzIGlzIHJlZmVycmVkIHRvIGFzIGFuIEFT T04gcm91dGluZw0KPiAgICAgIChjb250cm9sKSBkb21haW4uIFRoZSByb3V0aW5nIGluZm9ybWF0 aW9uIGV4Y2hhbmdlZCBiZXR3ZWVuDQo+ICAgICAgcm91dGluZyBkb21haW5zIChpbnRlci1SQSwg aS5lLiBpbnRlci1kb21haW4pIFNIQUxMIGJlIGluZGVwZW5kZW50DQo+ICAgICAgb2YgYm90aCB0 aGUgaW50cmEtZG9tYWluIHJvdXRpbmcgcHJvdG9jb2wocyksIGFuZCB0aGUgaW50cmEtZG9tYWlu DQo+ICAgICAgY29udHJvbCBkaXN0cmlidXRpb24gY2hvaWNlKHMpLCBlLmcuIGNlbnRyYWxpemVk LCBmdWxseQ0KPiAgICAgIGRpc3RyaWJ1dGVkLiBSQ3MgYm91bmRlZCB0byBkaWZmZXJlbnQgUkEg bGV2ZWxzIE1BWSBiZSBjby1sb2NhdGVkDQo+ICAgICAgd2l0aGluIHRoZSBzYW1lIHBoeXNpY2Fs IGVsZW1lbnQgb3IgcGh5c2ljYWxseSBkaXN0cmlidXRlZC4NCj4gICAgLSBUaGUgcm91dGluZyBh ZGphY2VuY3kgdG9wb2xvZ3kgKGkuZS4gdGhlIGFzc29jaWF0ZWQgUEMNCj4gDQo+IA0KPiANCj4g Vy5BbGFucWFyIGV0IGFsLiAtIEV4cGlyZXMgT2N0b2JlciAyMDA0ICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAxMQ0KPiBkcmFmdC1pZXRmLWNjYW1wLWdtcGxzLWFzb24tcm91dGluZy1yZXF0 cy0wMy50eHQgICAgICAgICAgICBBcHJpbCAyMDA0DQo+IA0KPiANCj4gDQo+ICAgICAgY29ubmVj dGl2aXR5IHRvcG9sb2d5KSBhbmQgdGhlIHRyYW5zcG9ydCBuZXR3b3JrIHRvcG9sb2d5IFNIQUxM DQo+ICAgICAgTk9UIGJlIGFzc3VtZWQgdG8gYmUgY29uZ3J1ZW50DQo+ICAgIC0gVGhlIHJvdXRp bmcgdG9wb2xvZ3kgU0hBTEwgc3VwcG9ydCBtdWx0aXBsZSBsaW5rcyBiZXR3ZWVuIG5vZGVzDQo+ ICAgICAgYW5kIFJBcw0KPiANCj4gDQo+ICAgIEluIHN1bW1hcnksIHRoZSBmb2xsb3dpbmcgZnVu Y3Rpb25hbGl0eSBpcyBleHBlY3RlZCBmcm9tIEdNUExTDQo+ICAgIHJvdXRpbmcgdG8gaW5zdGFu dGlhdGUgdGhlIEFTT04gaGllcmFyY2hpY2FsIHJvdXRpbmcgYXJjaGl0ZWN0dXJlDQo+ICAgIHJl YWxpemF0aW9uIChzZWUgW0cuNzcxNV0gYW5kIFtHLjc3MTUuMV0pOg0KPiAgICAtIFJBcyBTSEFM TCBiZSB1bmlxdWVseSBpZGVudGlmaWFibGUgd2l0aGluIGEgY2FycmllcidzIG5ldHdvcmssDQo+ ICAgICAgZWFjaCBoYXZpbmcgYSB1bmlxdWUgUkEgSUQgd2l0aGluIHRoZSBjYXJyaWVyJ3MgbmV0 d29yay4NCj4gICAgLSBXaXRoaW4gYSBSQSAob25lIGxldmVsKSwgdGhlIHJvdXRpbmcgcHJvdG9j b2wgU0hBTEwgc3VwcG9ydA0KPiAgICAgIGRpc3NlbWluYXRpb24gb2YgaGllcmFyY2hpY2FsIHJv dXRpbmcgaW5mb3JtYXRpb24gKGluY2x1ZGluZw0KPiAgICAgIHN1bW1hcml6ZWQgcm91dGluZyBp bmZvcm1hdGlvbiBmb3Igb3RoZXIgbGV2ZWxzKSBpbiBzdXBwb3J0IG9mIGFuDQo+ICAgICAgYXJj aGl0ZWN0dXJlIG9mIG11bHRpcGxlIGhpZXJhcmNoaWNhbCBsZXZlbHMgb2YgUkFzOyB0aGUgbnVt YmVyIG9mDQo+ICAgICAgaGllcmFyY2hpY2FsIFJBIGxldmVscyB0byBiZSBzdXBwb3J0ZWQgYnkg YSByb3V0aW5nIHByb3RvY29sIGlzDQo+ICAgICAgaW1wbGVtZW50YXRpb24gc3BlY2lmaWMuDQo+ ICAgIC0gVGhlIHJvdXRpbmcgcHJvdG9jb2wgU0hBTEwgc3VwcG9ydCByb3V0aW5nIGluZm9ybWF0 aW9uIGJhc2VkIG9uIGENCj4gICAgICBjb21tb24gc2V0IG9mIGluZm9ybWF0aW9uIGVsZW1lbnRz IGFzIGRlZmluZWQgaW4gW0cuNzcxNV0gYW5kDQo+ICAgICAgW0cuNzcxNS4xXSwgZGl2aWRlZCBi ZXR3ZWVuIGF0dHJpYnV0ZXMgcGVydGFpbmluZyB0byBsaW5rcyBhbmQNCj4gICAgICBhYnN0cmFj dCBub2RlcyAoZWFjaCByZXByZXNlbnRpbmcgZWl0aGVyIGEgc3ViLW5ldHdvcmsgb3Igc2ltcGx5 IGENCj4gICAgICBub2RlKS4gW0cuNzcxNV0gcmVjb2duaXplcyB0aGF0IHRoZSBtYW5uZXIgaW4g d2hpY2ggdGhlIHJvdXRpbmcNCj4gICAgICBpbmZvcm1hdGlvbiBpcyByZXByZXNlbnRlZCBhbmQg ZXhjaGFuZ2VkIHdpbGwgdmFyeSB3aXRoIHRoZQ0KPiAgICAgIHJvdXRpbmcgcHJvdG9jb2wgdXNl ZC4NCj4gICAgLSBUaGUgcm91dGluZyBwcm90b2NvbCBTSEFMTCBjb252ZXJnZSBzdWNoIHRoYXQg dGhlIGRpc3RyaWJ1dGVkIFJEQnMNCj4gICAgICBiZWNvbWUgc3luY2hyb25pemVkIGFmdGVyIGEg cGVyaW9kIG9mIHRpbWUuDQo+IA0KPiANCj4gICAgVG8gc3VwcG9ydCBoaWVyYXJjaGljYWwgcm91 dGluZyBpbmZvcm1hdGlvbiBkaXNzZW1pbmF0aW9uIHdpdGhpbiBhbg0KPiAgICBSQSwgdGhlIHJv dXRpbmcgcHJvdG9jb2wgTVVTVCBkZWxpdmVyOg0KPiA8ICAtIHByb2Nlc3Npbmcgb2Ygcm91dGlu ZyBpbmZvcm1hdGlvbiBleGNoYW5nZWQgYmV0d2VlbiBhZGphY2VudA0KPiANCj4+IC0gUHJvY2Vz c2luZyBvZiByb3V0aW5nIGluZm9ybWF0aW9uIGV4Y2hhbmdlZCBiZXR3ZWVuIGFkamFjZW50DQo+ IA0KPiAgICAgIGxldmVscyBvZiB0aGUgaGllcmFyY2h5IChpLmUuIExldmVsIE4rMSBhbmQgTikg aW5jbHVkaW5nDQo+ICAgICAgcmVhY2hhYmlsaXR5IGFuZCB1cG9uIHBvbGljeSBkZWNpc2lvbiBz dW1tYXJpemVkIHRvcG9sb2d5DQo+ICAgICAgaW5mb3JtYXRpb24NCj4gPCAgLSB3aGVuIG11bHRp cGxlIFJDcyBib3VuZCB0byBhIFJBIHRyYW5zZm9ybSAoZmlsdGVyLCBzdW1tYXJpemUsDQo+IDwg ICAgZXRjLikgYW5kIHRoZW4gZm9yd2FyZCBpbmZvcm1hdGlvbiB0byBSQyhzKSBhdCBkaWZmZXJl bnQgbGV2ZWxzDQo+IDwgICAgdGhhdCB0aGUgcmVzdWx0aW5nIGluZm9ybWF0aW9uIGF0IHRoZSBy ZWNlaXZpbmcgbGV2ZWwgaXMgc2VsZi0NCj4gPCAgICBjb25zaXN0ZW50DQo+IA0KPj4gLSBTZWxm LWNvbnNpc3RlbnQgaW5mb3JtYXRpb24gYXQgdGhlIHJlY2VpdmluZyBsZXZlbCByZXN1bHRpbmcg ZnJvbQ0KPj4gICBhbnkgdHJhbnNmb3JtYXRpb24gKGZpbHRlciwgc3VtbWFyaXplLCBldGMuKSBh bmQgZm9yd2FyZGluZyBvZg0KPj4gICBpbmZvcm1hdGlvbiBmcm9tIG9uZSBSQyB0byBSQyhzKSBh dCBkaWZmZXJlbnQgbGV2ZWxzIHdoZW4gbXVsdGlwbGUNCj4+ICAgUkNzIGJvdW5kIHRvIGEgc2lu Z2xlIFJBDQo+IA0KPiA8ICAtIGEgbWVjaGFuaXNtIHRvIHByZXZlbnQgcmUtaW50cm9kdWN0aW9u IG9mIGluZm9ybWF0aW9uIHByb3BhZ2F0ZWQNCj4gDQo+PiAtIEEgbWVjaGFuaXNtIHRvIHByZXZl bnQgcmUtaW50cm9kdWN0aW9uIG9mIGluZm9ybWF0aW9uIHByb3BhZ2F0ZWQNCj4gDQo+ICAgICAg aW50byB0aGUgTGV2ZWwgTiBSQSdzIFJDIGJhY2sgdG8gdGhlIGFkamFjZW50IGxldmVsIFJBJ3Mg UkMgZnJvbQ0KPiAgICAgIHdoaWNoIHRoaXMgaW5mb3JtYXRpb24gaGFzIGJlZW4gaW5pdGlhbGx5 IHJlY2VpdmVkLg0KPiANCj4gDQo+ICAgIEluIG9yZGVyIHRvIHN1cHBvcnQgb3BlcmF0b3IgYXNz aXN0ZWQgY2hhbmdlcyBpbiB0aGUgY29udGFpbm1lbnQNCj4gICAgcmVsYXRpb25zaGlwcyBvZiBS QXMsIHRoZSByb3V0aW5nIHByb3RvY29sIFNIQUxMIHN1cHBvcnQgZXZvbHV0aW9uDQo+IDwgIGlu IHRlcm1zIG9mIG51bWJlciBvZiBoaWVyYXJjaGljYWwgbGV2ZWxzIG9mIFJBcy4gRXhhbXBsZTog c3VwcG9ydA0KPiANCj4+IGluIHRlcm1zIG9mIG51bWJlciBvZiBoaWVyYXJjaGljYWwgbGV2ZWxz IG9mIFJBcy4gRm9yIGV4YW1wbGU6IHN1cHBvcnQNCj4gDQo+ICAgIG9mIG5vbi1kaXNydXB0aXZl IG9wZXJhdGlvbnMgc3VjaCBhcyBhZGRpbmcgYW5kIHJlbW92aW5nIFJBcyBhdCB0aGUNCj4gICAg dG9wL2JvdHRvbSBvZiB0aGUgaGllcmFyY2h5LCBhZGRpbmcgb3IgcmVtb3ZpbmcgYSBoaWVyYXJj aGljYWwgbGV2ZWwNCj4gICAgb2YgUkFzIGluIG9yIGZyb20gdGhlIG1pZGRsZSBvZiB0aGUgaGll cmFyY2h5LCBhcyB3ZWxsIGFzDQo+ICAgIGFnZ3JlZ2F0aW9uIGFuZCBzZWdtZW50YXRpb24gb2Yg UkFzLiBUaGUgbnVtYmVyIG9mIGhpZXJhcmNoaWNhbA0KPiAgICBsZXZlbHMgdG8gYmUgc3VwcG9y dGVkIGlzIHJvdXRpbmcgcHJvdG9jb2wgc3BlY2lmaWMsIGFuZCByZWZsZWN0cyBhDQo+ICAgIGNv bnRhaW5tZW50IHJlbGF0aW9uc2hpcCBlLmcuIGEgUkEgaW5zZXJ0aW9uIGludm9sdmVzIHN1cHBv cnRpbmcgYQ0KPiAgICBkaWZmZXJlbnQgcm91dGluZyBwcm90b2NvbCBkb21haW4gaW4gYSBwb3J0 aW9uIG9mIHRoZSBuZXR3b3JrLg0KPiANCj4gDQo+IA0KPiANCj4gDQo+IFcuQWxhbnFhciBldCBh bC4gLSBFeHBpcmVzIE9jdG9iZXIgMjAwNCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgMTIN Cj4gZHJhZnQtaWV0Zi1jY2FtcC1nbXBscy1hc29uLXJvdXRpbmctcmVxdHMtMDMudHh0ICAgICAg ICAgICAgQXByaWwgMjAwNA0KPiANCj4gDQo+IA0KPiAgICBSZWFjaGFiaWxpdHkgaW5mb3JtYXRp b24gKHNlZSBTZWN0aW9uIDQuNS4zKSBvZiB0aGUgc2V0IG9mIGVuZHBvaW50cw0KPiAgICByZWFj aGFibGUgYnkgYSBub2RlIG1heSBiZSBhZHZlcnRpc2VkIGVpdGhlciBhcyBhIHNldCBvZiBVTkkN Cj4gICAgVHJhbnNwb3J0IFJlc291cmNlIGFkZHJlc3Nlcy8gYWRkcmVzcyBwcmVmaXhlcywgb3Ig YSBzZXQgb2YNCj4gICAgYXNzb2NpYXRlZCBTTlBQIGxpbmsgSURzL1NOUFAgbGluayBJRCBwcmVm aXhlcywgYXNzaWduZWQgYW5kDQo+ICAgIHNlbGVjdGVkIGNvbnNpc3RlbnRseSBpbiB0aGVpciBh cHBsaWNhYmlsaXR5IHNjb3BlLiBUaGUgZm9ybWF0cyBvZg0KPiAgICB0aGUgY29udHJvbCBwbGFu ZSBpZGVudGlmaWVycyBpbiBhIHByb3RvY29sIHJlYWxpemF0aW9uIGFyZQ0KPiAgICBpbXBsZW1l bnRhdGlvbiBzcGVjaWZpYy4gVXNlIG9mIGEgcm91dGluZyBwcm90b2NvbCB3aXRoaW4gYSBSQQ0K PiAgICBzaG91bGQgbm90IHJlc3RyaWN0IHRoZSBjaG9pY2Ugb2Ygcm91dGluZyBwcm90b2NvbHMg Zm9yIHVzZSBpbiBvdGhlcg0KPiAgICBSQXMgKGNoaWxkIG9yIHBhcmVudCkuDQo+IA0KPiANCj4g ICAgQXMgQVNPTiBkb2VzIG5vdCByZXN0cmljdCB0aGUgY29udHJvbCBwbGFuZSBhcmNoaXRlY3R1 cmUgY2hvaWNlDQo+ICAgIHVzZWQsIGVpdGhlciBhIGNvLWxvY2F0ZWQgYXJjaGl0ZWN0dXJlIG9y IGEgcGh5c2ljYWxseSBzZXBhcmF0ZWQNCj4gICAgYXJjaGl0ZWN0dXJlIG1heSBiZSB1c2VkLiBB IGNvbGxlY3Rpb24gb2YgbGlua3MgYW5kIG5vZGVzIHN1Y2ggYXMgYQ0KPiAgICBzdWItbmV0d29y ayBvciBSQSBNVVNUIGJlIGFibGUgdG8gcmVwcmVzZW50IGl0c2VsZiB0byB0aGUgd2lkZXINCj4g ICAgbmV0d29yayBhcyBhIHNpbmdsZSBsb2dpY2FsIGVudGl0eSB3aXRoIG9ubHkgaXRzIGV4dGVy bmFsIGxpbmtzDQo+ICAgIHZpc2libGUgdG8gdGhlIHRvcG9sb2d5IGRhdGFiYXNlLg0KPiANCj4g DQo+IDcuIEFja25vd2xlZGdlbWVudHMNCj4gDQo+IA0KPiAgICBUaGUgYXV0aG9ycyB3b3VsZCBs aWtlIHRvIHRoYW5rIEtpcmVldGkgS29tcGVsbGEgZm9yIGhhdmluZw0KPiAgICBpbml0aWF0ZWQg dGhlIHByb3Bvc2FsIG9mIGFuIEFTT04gUm91dGluZyBSZXF1aXJlbWVudCBEZXNpZ24gVGVhbS4N Cj4gIyMgUGVyaGFwcyBpdCB3b3VsZCBiZSBnb29kIHRvIGFja25vd2xlZGdlIGFueSBvdGhlciBj b250cmlidXRvcnMgeW91IGhhZC4NCj4gIyMgSW4gcGFydGljdWxhciBTRzE0LzE1IGZvciB0aGVp ciBjYXJlZnVsIHJldmlldyBhbmQgaW5wdXQuDQo+IA0KPiA4LiBJbnRlbGxlY3R1YWwgUHJvcGVy dHkgQ29uc2lkZXJhdGlvbnMNCj4gDQo+IA0KPiAgICBUaGUgSUVURiB0YWtlcyBubyBwb3NpdGlv biByZWdhcmRpbmcgdGhlIHZhbGlkaXR5IG9yIHNjb3BlIG9mIGFueQ0KPiAgICBJbnRlbGxlY3R1 YWwgUHJvcGVydHkgUmlnaHRzIG9yIG90aGVyIHJpZ2h0cyB0aGF0IG1pZ2h0IGJlIGNsYWltZWQN Cj4gICAgdG8gcGVydGFpbiB0byB0aGUgaW1wbGVtZW50YXRpb24gb3IgdXNlIG9mIHRoZSB0ZWNo bm9sb2d5DQo+ICAgIGRlc2NyaWJlZCBpbiB0aGlzIGRvY3VtZW50IG9yIHRoZSBleHRlbnQgdG8g d2hpY2ggYW55IGxpY2Vuc2UNCj4gICAgdW5kZXIgc3VjaCByaWdodHMgbWlnaHQgb3IgbWlnaHQg bm90IGJlIGF2YWlsYWJsZTsgbm9yIGRvZXMgaXQNCj4gICAgcmVwcmVzZW50IHRoYXQgaXQgaGFz IG1hZGUgYW55IGluZGVwZW5kZW50IGVmZm9ydCB0byBpZGVudGlmeSBhbnkNCj4gICAgc3VjaCBy aWdodHMuIEluZm9ybWF0aW9uIG9uIHRoZSBwcm9jZWR1cmVzIHdpdGggcmVzcGVjdCB0byByaWdo dHMNCj4gICAgaW4gUkZDIGRvY3VtZW50cyBjYW4gYmUgZm91bmQgaW4gQkNQIDc4IGFuZCBCQ1Ag NzkuDQo+IA0KPiANCj4gICAgQ29waWVzIG9mIElQUiBkaXNjbG9zdXJlcyBtYWRlIHRvIHRoZSBJ RVRGIFNlY3JldGFyaWF0IGFuZCBhbnkNCj4gICAgYXNzdXJhbmNlcyBvZiBsaWNlbnNlcyB0byBi ZSBtYWRlIGF2YWlsYWJsZSwgb3IgdGhlIHJlc3VsdCBvZiBhbg0KPiAgICBhdHRlbXB0IG1hZGUg dG8gb2J0YWluIGEgZ2VuZXJhbCBsaWNlbnNlIG9yIHBlcm1pc3Npb24gZm9yIHRoZSB1c2UNCj4g ICAgb2Ygc3VjaCBwcm9wcmlldGFyeSByaWdodHMgYnkgaW1wbGVtZW50ZXJzIG9yIHVzZXJzIG9m IHRoaXMNCj4gICAgc3BlY2lmaWNhdGlvbiBjYW4gYmUgb2J0YWluZWQgZnJvbSB0aGUgSUVURiBv bi1saW5lIElQUiByZXBvc2l0b3J5DQo+ICAgIGF0IGh0dHA6Ly93d3cuaWV0Zi5vcmcvaXByLg0K PiANCj4gDQo+ICAgIFRoZSBJRVRGIGludml0ZXMgYW55IGludGVyZXN0ZWQgcGFydHkgdG8gYnJp bmcgdG8gaXRzIGF0dGVudGlvbg0KPiAgICBhbnkgY29weXJpZ2h0cywgcGF0ZW50cyBvciBwYXRl bnQgYXBwbGljYXRpb25zLCBvciBvdGhlcg0KPiAgICBwcm9wcmlldGFyeSByaWdodHMgdGhhdCBt YXkgY292ZXIgdGVjaG5vbG9neSB0aGF0IG1heSBiZSByZXF1aXJlZA0KPiAgICB0byBpbXBsZW1l bnQgdGhpcyBzdGFuZGFyZC4gIFBsZWFzZSBhZGRyZXNzIHRoZSBpbmZvcm1hdGlvbiB0byB0aGUN Cj4gICAgSUVURiBhdCBpZXRmLWlwckBpZXRmLm9yZy4NCj4gDQo+IA0KPiA4LjEgSVBSIERpc2Ns b3N1cmUgQWNrbm93bGVkZ2VtZW50DQo+IA0KPiANCj4gICAgQnkgc3VibWl0dGluZyB0aGlzIElu dGVybmV0LURyYWZ0LCBJIGNlcnRpZnkgdGhhdCBhbnkgYXBwbGljYWJsZQ0KPiAgICBwYXRlbnQg b3Igb3RoZXIgSVBSIGNsYWltcyBvZiB3aGljaCBJIGFtIGF3YXJlIGhhdmUgYmVlbiBkaXNjbG9z ZWQsDQo+ICAgIGFuZCBhbnkgb2Ygd2hpY2ggSSBiZWNvbWUgYXdhcmUgd2lsbCBiZSBkaXNjbG9z ZWQsIGluIGFjY29yZGFuY2UNCj4gICAgd2l0aCBSRkMgMzY2OC4NCj4gDQo+IA0KPiANCj4gVy5B bGFucWFyIGV0IGFsLiAtIEV4cGlyZXMgT2N0b2JlciAyMDA0ICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAxMw0KPiBkcmFmdC1pZXRmLWNjYW1wLWdtcGxzLWFzb24tcm91dGluZy1yZXF0cy0w My50eHQgICAgICAgICAgICBBcHJpbCAyMDA0DQo+IA0KPiANCj4gDQo+IDkuIFJlZmVyZW5jZXMN Cj4gDQo+IA0KPiA5LjEgTm9ybWF0aXZlIFJlZmVyZW5jZXMNCj4gDQo+IA0KPiAgICBbUkZDMjAy Nl0gICAgUy5CcmFkbmVyLCAiVGhlIEludGVybmV0IFN0YW5kYXJkcyBQcm9jZXNzIC0tDQo+ICAg ICAgICAgICAgICAgICBSZXZpc2lvbiAzIiwgQkNQIDksIFJGQyAyMDI2LCBPY3RvYmVyIDE5OTYu DQo+IA0KPiANCj4gICAgW1JGQzIxMTldICAgIFMuQnJhZG5lciwgIktleSB3b3JkcyBmb3IgdXNl IGluIFJGQ3MgdG8gSW5kaWNhdGUNCj4gICAgICAgICAgICAgICAgIFJlcXVpcmVtZW50IExldmVs cyIsIEJDUCAxNCwgUkZDIDIxMTksIE1hcmNoIDE5OTcuDQo+IA0KPiANCj4gICAgW0cuNzcxNV0g ICAgIElUVS1UIFJlYy4gRy43NzE1L1kuMTMwNiwgIkFyY2hpdGVjdHVyZSBhbmQNCj4gICAgICAg ICAgICAgICAgIFJlcXVpcmVtZW50cyBmb3IgdGhlIEF1dG9tYXRpY2FsbHkgU3dpdGNoZWQgT3B0 aWNhbA0KPiAgICAgICAgICAgICAgICAgTmV0d29yayAoQVNPTiksIiBKdW5lIDIwMDIuDQo+IA0K PiANCj4gICAgW0cuNzcxNS4xXSAgIElUVS1UIERyYWZ0IFJlYy4gRy43NzE1LjEvWS4xNzA2LjEs ICJBU09OIFJvdXRpbmcNCj4gICAgICAgICAgICAgICAgIEFyY2hpdGVjdHVyZSBhbmQgUmVxdWly ZW1lbnRzIGZvciBMaW5rIFN0YXRlDQo+ICAgICAgICAgICAgICAgICBQcm90b2NvbHMsIiBOb3Zl bWJlciAyMDAzLg0KPiANCj4gDQo+ICAgIFtHLjgwODBdICAgICBJVFUtVCBSZWMuIEcuODA4MC9Z LjEzMDQsICJBcmNoaXRlY3R1cmUgZm9yIHRoZQ0KPiAgICAgICAgICAgICAgICAgQXV0b21hdGlj YWxseSBTd2l0Y2hlZCBPcHRpY2FsIE5ldHdvcmsgKEFTT04pLCINCj4gICAgICAgICAgICAgICAg IE5vdmVtYmVyIDIwMDEgKGFuZCBSZXZpc2lvbiwgSmFudWFyeSAyMDAzKS4NCj4gDQo+IA0KPiAg ICBbSElFUl0gICAgICAgSy5Lb21wZWxsYSBhbmQgWS5SZWtodGVyLCAiTFNQIEhpZXJhcmNoeSB3 aXRoDQo+ICAgICAgICAgICAgICAgICBHZW5lcmFsaXplZCBNUExTIFRFLCIgSW50ZXJuZXQgZHJh ZnQgKHdvcmsgaW4NCj4gICAgICAgICAgICAgICAgIHByb2dyZXNzKSwgZHJhZnQtaWV0Zi1tcGxz LWxzcC1oaWVyYXJjaHksIFNlcHRlbWJlciAwMi4NCj4gDQo+ICMjIFdvdWxkIGl0IGJlIE9LIHRv IG1ha2UgdGhlIGV4dGVybmFsIHJlZmVyZW5jZXMgaW5mb3JtYXRpdmU/DQo+IA0KPiAxMC4gQXV0 aG9yJ3MgQWRkcmVzc2VzDQo+IA0KPiANCj4gICAgV2VzYW0gQWxhbnFhciAoU3ByaW50KQ0KPiAg ICBFTWFpbDogd2VzYW0uYWxhbnFhckBtYWlsLnNwcmludC5jb20NCj4gDQo+IA0KPiAgICBEZWJv cmFoIEJydW5nYXJkIChBVCZUKQ0KPiAgICBSbS4gRDEtM0MyMiAtIDIwMCBTLiBMYXVyZWwgQXZl Lg0KPiAgICBNaWRkbGV0b3duLCBOSiAwNzc0OCwgVVNBDQo+ICAgIFBob25lOiArMSA3MzIgNDIw MTU3Mw0KPiAgICBFTWFpbDogZGJydW5nYXJkQGF0dC5jb20NCj4gDQo+IA0KPiAgICBEYXZpZCBN ZXllciAoQ2lzY28gU3lzdGVtcykNCj4gICAgRU1haWw6IGRtbUAxLTQtNS5uZXQNCj4gDQo+IA0K PiAgICBMeW5kb24gT25nIChDaWVuYSBDb3Jwb3JhdGlvbikNCj4gICAgNTk2NSBTaWx2ZXIgQ3Jl ZWsgVmFsbGV5IFJkLA0KPiAgICBTYW4gSm9zZSwgQ0EgOTUxMjgsIFVTQQ0KPiAgICBQaG9uZTog KzEgNDA4IDgzNDc4OTQNCj4gICAgRU1haWw6IGx5b25nQGNpZW5hLmNvbQ0KPiANCj4gDQo+ICAg IERpbWl0cmkgUGFwYWRpbWl0cmlvdSAoQWxjYXRlbCkNCj4gICAgRnJhbmNpcyBXZWxsZW5zcGxl aW4gMSwNCj4gICAgQi0yMDE4IEFudHdlcnBlbiwgQmVsZ2l1bQ0KPiAgICBQaG9uZTogKzMyIDMg MjQwODQ5MQ0KPiAgICBFTWFpbDogZGltaXRyaS5wYXBhZGltaXRyaW91QGFsY2F0ZWwuYmUNCj4g DQo+IA0KPiANCj4gDQo+IFcuQWxhbnFhciBldCBhbC4gLSBFeHBpcmVzIE9jdG9iZXIgMjAwNCAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgMTQNCj4gZHJhZnQtaWV0Zi1jY2FtcC1nbXBscy1h c29uLXJvdXRpbmctcmVxdHMtMDMudHh0ICAgICAgICAgICAgQXByaWwgMjAwNA0KPiANCj4gDQo+ IA0KPiAgICBKb25hdGhhbiBTYWRsZXINCj4gICAgMTQxNSBXLiBEaWVobCBSZA0KPiAgICBOYXBl cnZpbGxlLCBJTCA2MDU2Mw0KPiAgICBFTWFpbDogam9uYXRoYW4uc2FkbGVyQHRlbGxhYnMuY29t DQo+IA0KPiANCj4gICAgU3RlcGhlbiBTaGV3IChOb3J0ZWwgTmV0d29ya3MpDQo+ICAgIFBPIEJv eCAzNTExIFN0YXRpb24gQw0KPiAgICBPdHRhd2EsIE9udGFyaW8sIENBTkFEQSBLMVkgNEg3DQo+ ICAgIFBob25lOiArMSA2MTMgNzYzMjQ2Mg0KPiAgICBFTWFpbDogc2RzaGV3QG5vcnRlbG5ldHdv cmtzLmNvbQ0KPiANCj4gDQo+IA0KPiANCj4gDQo+IA0KPiANCj4gDQo+IA0KPiANCj4gDQo+IA0K PiANCj4gDQo+IA0KPiANCj4gDQo+IA0KPiANCj4gDQo+IA0KPiANCj4gDQo+IA0KPiANCj4gDQo+ IA0KPiANCj4gDQo+IA0KPiANCj4gDQo+IA0KPiANCj4gDQo+IA0KPiANCj4gDQo+IA0KPiANCj4g DQo+IA0KPiANCj4gDQo+IA0KPiBXLkFsYW5xYXIgZXQgYWwuIC0gRXhwaXJlcyBPY3RvYmVyIDIw MDQgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDE1DQo+IGRyYWZ0LWlldGYtY2NhbXAtZ21w bHMtYXNvbi1yb3V0aW5nLXJlcXRzLTAzLnR4dCAgICAgICAgICAgIEFwcmlsIDIwMDQNCj4gDQo+ IA0KPiANCj4gQXBwZW5kaXggMTogQVNPTiBUZXJtaW5vbG9neQ0KPiANCj4gDQo+ICAgIFRoaXMg ZG9jdW1lbnQgbWFrZXMgdXNlIG9mIHRoZSBmb2xsb3dpbmcgdGVybXM6DQo+IA0KPiANCj4gICAg QWRtaW5pc3RyYXRpdmUgZG9tYWluOiAoUmVjb21tZW5kYXRpb24gRy44MDUgRm9yIHRoZSBwdXJw b3NlcyBvZg0KPiAgICBbRzc3MTUuMV0gYW4gYWRtaW5pc3RyYXRpdmUgZG9tYWluIHJlcHJlc2Vu dHMgdGhlIGV4dGVudCBvZg0KPiAgICByZXNvdXJjZXMgd2hpY2ggYmVsb25nIHRvIGEgc2luZ2xl IHBsYXllciBzdWNoIGFzIGEgbmV0d29yaw0KPiAgICBvcGVyYXRvciwgYSBzZXJ2aWNlIHByb3Zp ZGVyLCBvciBhbiBlbmQtdXNlci4gQWRtaW5pc3RyYXRpdmUgZG9tYWlucw0KPiAgICBvZiBkaWZm ZXJlbnQgcGxheWVycyBkbyBub3Qgb3ZlcmxhcCBhbW9uZ3N0IHRoZW1zZWx2ZXMuDQo+IA0KPiAN Cj4gICAgQ29udHJvbCBwbGFuZTogcGVyZm9ybXMgdGhlIGNhbGwgY29udHJvbCBhbmQgY29ubmVj dGlvbiBjb250cm9sDQo+ICAgIGZ1bmN0aW9ucy4gVGhyb3VnaCBzaWduYWxpbmcsIHRoZSBjb250 cm9sIHBsYW5lIHNldHMgdXAgYW5kIHJlbGVhc2VzDQo+ICAgIGNvbm5lY3Rpb25zLCBhbmQgbWF5 IHJlc3RvcmUgYSBjb25uZWN0aW9uIGluIGNhc2Ugb2YgYSBmYWlsdXJlLg0KPiANCj4gDQo+ICAg IChDb250cm9sKSBEb21haW46IHJlcHJlc2VudHMgYSBjb2xsZWN0aW9uIG9mIChjb250cm9sKSBl bnRpdGllcyB0aGF0DQo+ICAgIGFyZSBncm91cGVkIGZvciBhIHBhcnRpY3VsYXIgcHVycG9zZS4g VGhlIGNvbnRyb2wgcGxhbmUgaXMNCj4gICAgc3ViZGl2aWRlZCBpbnRvIGRvbWFpbnMgbWF0Y2hp bmcgYWRtaW5pc3RyYXRpdmUgZG9tYWlucy4gV2l0aGluIGFuDQo+ICAgIGFkbWluaXN0cmF0aXZl IGRvbWFpbiwgZnVydGhlciBzdWJkaXZpc2lvbnMgb2YgdGhlIGNvbnRyb2wgcGxhbmUgYXJlDQo+ ICAgIHJlY3Vyc2l2ZWx5IGFwcGxpZWQuIEEgcm91dGluZyBjb250cm9sIGRvbWFpbiBpcyBhbiBh YnN0cmFjdCBlbnRpdHkNCj4gICAgdGhhdCBoaWRlcyB0aGUgZGV0YWlscyBvZiB0aGUgUkMgZGlz dHJpYnV0aW9uLg0KPiANCj4gDQo+ICAgIEV4dGVybmFsIE5OSSAoRS1OTkkpOiBpbnRlcmZhY2Vz IGFyZSBsb2NhdGVkIGJldHdlZW4gcHJvdG9jb2wNCj4gICAgY29udHJvbGxlcnMgYmV0d2VlbiBj b250cm9sIGRvbWFpbnMuDQo+IA0KPiANCj4gICAgSW50ZXJuYWwgTk5JIChJLU5OSSk6IGludGVy ZmFjZXMgYXJlIGxvY2F0ZWQgYmV0d2VlbiBwcm90b2NvbA0KPiAgICBjb250cm9sbGVycyB3aXRo aW4gY29udHJvbCBkb21haW5zLg0KPiANCj4gDQo+ICAgIExpbms6IFtTZWUgUmVjb21tZW5kYXRp b24gRy44MDVdIGEgInRvcG9sb2dpY2FsIGNvbXBvbmVudCIgd2hpY2gNCj4gICAgZGVzY3JpYmVz IGEgZml4ZWQgcmVsYXRpb25zaGlwIGJldHdlZW4gYSAic3VibmV0d29yayIgb3IgImFjY2Vzcw0K PiAgICBncm91cCIgYW5kIGFub3RoZXIgInN1Ym5ldHdvcmsiIG9yICJhY2Nlc3MgZ3JvdXAiLiBM aW5rcyBhcmUgbm90DQo+ICAgIGxpbWl0ZWQgdG8gYmVpbmcgcHJvdmlkZWQgYnkgYSBzaW5nbGUg c2VydmVyIHRyYWlsLg0KPiANCj4gDQo+ICAgIE1hbmFnZW1lbnQgcGxhbmU6IHBlcmZvcm1zIG1h bmFnZW1lbnQgZnVuY3Rpb25zIGZvciB0aGUgVHJhbnNwb3J0DQo+ICAgIFBsYW5lLCB0aGUgY29u dHJvbCBwbGFuZSBhbmQgdGhlIHN5c3RlbSBhcyBhIHdob2xlLiBJdCBhbHNvIHByb3ZpZGVzDQo+ ICAgIGNvb3JkaW5hdGlvbiBiZXR3ZWVuIGFsbCB0aGUgcGxhbmVzLiBUaGUgZm9sbG93aW5nIG1h bmFnZW1lbnQNCj4gICAgZnVuY3Rpb25hbCBhcmVhcyBhcmUgcGVyZm9ybWVkIGluIHRoZSBtYW5h Z2VtZW50IHBsYW5lOiBwZXJmb3JtYW5jZSwNCj4gICAgZmF1bHQsIGNvbmZpZ3VyYXRpb24sIGFj Y291bnRpbmcgYW5kIHNlY3VyaXR5IG1hbmFnZW1lbnQNCj4gDQo+IA0KPiAgICBNYW5hZ2VtZW50 IGRvbWFpbjogW1NlZSBSZWNvbW1lbmRhdGlvbiBHLjgwNV0gQSBtYW5hZ2VtZW50IGRvbWFpbg0K PiAgICBkZWZpbmVzIGEgY29sbGVjdGlvbiBvZiBtYW5hZ2VkIG9iamVjdHMgd2hpY2ggYXJlIGdy b3VwZWQgdG8gbWVldA0KPiAgICBvcmdhbml6YXRpb25hbCByZXF1aXJlbWVudHMgYWNjb3JkaW5n IHRvIGdlb2dyYXBoeSwgdGVjaG5vbG9neSwNCj4gICAgcG9saWN5IG9yIG90aGVyIHN0cnVjdHVy ZSwgYW5kIGZvciBhIG51bWJlciBvZiBmdW5jdGlvbmFsIGFyZWFzIHN1Y2gNCj4gICAgYXMgY29u ZmlndXJhdGlvbiwgc2VjdXJpdHksIChGQ0FQUyksIGZvciB0aGUgcHVycG9zZSBvZiBwcm92aWRp bmcNCj4gICAgY29udHJvbCBpbiBhIGNvbnNpc3RlbnQgbWFubmVyLiBNYW5hZ2VtZW50IGRvbWFp bnMgY2FuIGJlIGRpc2pvaW50LA0KPiAgICBjb250YWluZWQgb3Igb3ZlcmxhcHBpbmcuIEFzIHN1 Y2ggdGhlIHJlc291cmNlcyB3aXRoaW4gYW4NCj4gICAgYWRtaW5pc3RyYXRpdmUgZG9tYWluIGNh biBiZSBkaXN0cmlidXRlZCBpbnRvIHNldmVyYWwgcG9zc2libGUNCj4gICAgb3ZlcmxhcHBpbmcg bWFuYWdlbWVudCBkb21haW5zLiBUaGUgc2FtZSByZXNvdXJjZSBjYW4gdGhlcmVmb3JlDQo+ICAg IGJlbG9uZyB0byBzZXZlcmFsIG1hbmFnZW1lbnQgZG9tYWlucyBzaW11bHRhbmVvdXNseSwgYnV0 IGENCj4gICAgbWFuYWdlbWVudCBkb21haW4gc2hhbGwgbm90IGNyb3NzIHRoZSBib3JkZXIgb2Yg YW4gYWRtaW5pc3RyYXRpdmUNCj4gICAgZG9tYWluLg0KPiANCj4gDQo+IA0KPiANCj4gDQo+IFcu QWxhbnFhciBldCBhbC4gLSBFeHBpcmVzIE9jdG9iZXIgMjAwNCAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgMTYNCj4gZHJhZnQtaWV0Zi1jY2FtcC1nbXBscy1hc29uLXJvdXRpbmctcmVxdHMt MDMudHh0ICAgICAgICAgICAgQXByaWwgMjAwNA0KPiANCj4gDQo+IA0KPiAgICBTTlA6IFRoZSBT TlAgaXMgYSBjb250cm9sIHBsYW5lIGFic3RyYWN0aW9uIHRoYXQgcmVwcmVzZW50cyBhbg0KPiAg ICBhY3R1YWwgb3IgcG90ZW50aWFsIHRyYW5zcG9ydCBwbGFuZSByZXNvdXJjZS4gU05QcyAoaW4g ZGlmZmVyZW50DQo+ICAgIHN1Ym5ldHdvcmsgcGFydGl0aW9ucykgbWF5IHJlcHJlc2VudCB0aGUg c2FtZSB0cmFuc3BvcnQgcmVzb3VyY2UuIEENCj4gICAgb25lLXRvLW9uZSBjb3JyZXNwb25kZW5j ZSBzaG91bGQgbm90IGJlIGFzc3VtZWQuDQo+IA0KPiANCj4gIyMgQWRkIFNOUFANCj4gIyMgQWRk IFRDUA0KPiANCj4gICAgVHJhbnNwb3J0IHBsYW5lOiBwcm92aWRlcyBiaS1kaXJlY3Rpb25hbCBv ciB1bmlkaXJlY3Rpb25hbCB0cmFuc2Zlcg0KPiAgICBvZiB1c2VyIGluZm9ybWF0aW9uLCBmcm9t IG9uZSBsb2NhdGlvbiB0byBhbm90aGVyLiBJdCBjYW4gYWxzbw0KPiAgICBwcm92aWRlIHRyYW5z ZmVyIG9mIHNvbWUgY29udHJvbCBhbmQgbmV0d29yayBtYW5hZ2VtZW50IGluZm9ybWF0aW9uLg0K PiAgICBUaGUgVHJhbnNwb3J0IFBsYW5lIGlzIGxheWVyZWQ7IGl0IGlzIGVxdWl2YWxlbnQgdG8g dGhlIFRyYW5zcG9ydA0KPiAgICBOZXR3b3JrIGRlZmluZWQgaW4gRy44MDUuDQo+IA0KPiANCj4g ICAgVXNlciBOZXR3b3JrIEludGVyZmFjZSAoVU5JKTogaW50ZXJmYWNlcyBhcmUgbG9jYXRlZCBi ZXR3ZWVuDQo+ICAgIHByb3RvY29sIGNvbnRyb2xsZXJzIGJldHdlZW4gYSB1c2VyIGFuZCBhIGNv bnRyb2wgZG9tYWluLiBOb3RlOg0KPiAgICB0aGVyZSBpcyBubyByb3V0aW5nIGZ1bmN0aW9uIGFz c29jaWF0ZWQgd2l0aCBhIFVOSSByZWZlcmVuY2UgcG9pbnQuDQo+IA0KPiANCj4gDQo+IA0KPiAN Cj4gDQo+IA0KPiANCj4gDQo+IA0KPiANCj4gDQo+IA0KPiANCj4gDQo+IA0KPiANCj4gDQo+IA0K PiANCj4gDQo+IA0KPiANCj4gDQo+IA0KPiANCj4gDQo+IA0KPiANCj4gDQo+IA0KPiANCj4gDQo+ IA0KPiANCj4gDQo+IA0KPiANCj4gDQo+IA0KPiANCj4gVy5BbGFucWFyIGV0IGFsLiAtIEV4cGly ZXMgT2N0b2JlciAyMDA0ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAxNw0KPiBkcmFmdC1p ZXRmLWNjYW1wLWdtcGxzLWFzb24tcm91dGluZy1yZXF0cy0wMy50eHQgICAgICAgICAgICBBcHJp bCAyMDA0DQo+IA0KPiANCj4gDQo+IEFwcGVuZGl4IDI6IEFTT04gUm91dGluZyBUZXJtaW5vbG9n eQ0KPiANCj4gDQo+ICAgIFRoaXMgZG9jdW1lbnQgbWFrZXMgdXNlIG9mIHRoZSBmb2xsb3dpbmcg dGVybXM6DQo+IA0KPiANCj4gICAgUm91dGluZyBBcmVhIChSQSk6IGEgUkEgcmVwcmVzZW50cyBh IHBhcnRpdGlvbiBvZiB0aGUgZGF0YSBwbGFuZSBhbmQNCj4gICAgaXRzIGlkZW50aWZpZXIgaXMg dXNlZCB3aXRoaW4gdGhlIGNvbnRyb2wgcGxhbmUgYXMgdGhlDQo+ICAgIHJlcHJlc2VudGF0aW9u IG9mIHRoaXMgcGFydGl0aW9uLiBQZXIgW0cuODA4MF0gYSBSQSBpcyBkZWZpbmVkIGJ5IGENCj4g ICAgc2V0IG9mIHN1Yi1uZXR3b3JrcywgdGhlIFRFIGxpbmtzIHRoYXQgaW50ZXJjb25uZWN0IHRo ZW0sIGFuZCB0aGUNCj4gICAgaW50ZXJmYWNlcyByZXByZXNlbnRpbmcgdGhlIGVuZHMgb2YgdGhl IFRFIGxpbmtzIGV4aXRpbmcgdGhhdCBSQS4gQQ0KPiAgICBSQSBtYXkgY29udGFpbiBzbWFsbGVy IFJBcyBpbnRlci1jb25uZWN0ZWQgYnkgVEUgbGlua3MuIFRoZSBsaW1pdCBvZg0KPiAgICBzdWJk aXZpc2lvbiByZXN1bHRzIGluIGEgUkEgdGhhdCBjb250YWlucyB0d28gc3ViLW5ldHdvcmtzIGFu ZCBhIFRFDQo+ICAgIGxpbmsgd2l0aCBhIHNpbmdsZSBjb21wb25lbnQgbGluay4NCj4gDQo+IA0K PiAgICBSb3V0aW5nIERhdGFiYXNlIChSREIpOiByZXBvc2l0b3J5IGZvciB0aGUgbG9jYWwgdG9w b2xvZ3ksIG5ldHdvcmsNCj4gICAgdG9wb2xvZ3ksIHJlYWNoYWJpbGl0eSwgYW5kIG90aGVyIHJv dXRpbmcgaW5mb3JtYXRpb24gdGhhdCBpcw0KPiAgICB1cGRhdGVkIGFzIHBhcnQgb2YgdGhlIHJv dXRpbmcgaW5mb3JtYXRpb24gZXhjaGFuZ2UgYW5kIG1heQ0KPiAgICBhZGRpdGlvbmFsbHkgY29u dGFpbiBpbmZvcm1hdGlvbiB0aGF0IGlzIGNvbmZpZ3VyZWQuIFRoZSBSREIgbWF5DQo+ICAgIGNv bnRhaW4gcm91dGluZyBpbmZvcm1hdGlvbiBmb3IgbW9yZSB0aGFuIG9uZSBSb3V0aW5nIEFyZWEg KFJBKS4NCj4gDQo+IA0KPiAgICBSb3V0aW5nIENvbXBvbmVudHM6IEFTT04gcm91dGluZyBhcmNo aXRlY3R1cmUgZnVuY3Rpb25zLiBUaGVzZQ0KPiAgICBmdW5jdGlvbnMgY2FuIGJlIGNsYXNzaWZp ZWQgYXMgcHJvdG9jb2wgaW5kZXBlbmRlbnQgKExpbmsgUmVzb3VyY2UNCj4gICAgTWFuYWdlciBv ciBMUk0sIFJvdXRpbmcgQ29udHJvbGxlciBvciBSQykgYW5kIHByb3RvY29sIHNwZWNpZmljDQo+ ICAgIChQcm90b2NvbCBDb250cm9sbGVyIG9yIFBDKS4NCj4gDQo+IA0KPiAgICBSb3V0aW5nIENv bnRyb2xsZXIgKFJDKTogaGFuZGxlcyAoYWJzdHJhY3QpIGluZm9ybWF0aW9uIG5lZWRlZCBmb3IN Cj4gICAgcm91dGluZyBhbmQgdGhlIHJvdXRpbmcgaW5mb3JtYXRpb24gZXhjaGFuZ2Ugd2l0aCBw ZWVyaW5nIFJDcyBieQ0KPiAgICBvcGVyYXRpbmcgb24gdGhlIFJEQi4gVGhlIFJDIGhhcyBhY2Nl c3MgdG8gYSB2aWV3IG9mIHRoZSBSREIuIFRoZSBSQw0KPiAgICBpcyBwcm90b2NvbCBpbmRlcGVu ZGVudC4NCj4gDQo+IA0KPiAgICBOb3RlOiBTaW5jZSB0aGUgUkRCIG1heSBjb250YWluIHJvdXRp bmcgaW5mb3JtYXRpb24gcGVydGFpbmluZyB0bw0KPiAgICBtdWx0aXBsZSBSQXMgKGFuZCBwb3Nz aWJseSB0byBtdWx0aXBsZSBsYXllciBuZXR3b3JrcyksIHRoZSBSQ3MNCj4gICAgYWNjZXNzaW5n IHRoZSBSREIgbWF5IHNoYXJlIHRoZSByb3V0aW5nIGluZm9ybWF0aW9uLg0KPiANCj4gDQo+ICAg IExpbmsgUmVzb3VyY2UgTWFuYWdlciAoTFJNKTogc3VwcGxpZXMgYWxsIHRoZSByZWxldmFudCBj b21wb25lbnQgYW5kDQo+ICAgIFRFIGxpbmsgaW5mb3JtYXRpb24gdG8gdGhlIFJDLiBJdCBpbmZv cm1zIHRoZSBSQyBhYm91dCBhbnkgc3RhdGUNCj4gICAgY2hhbmdlcyBvZiB0aGUgbGluayByZXNv dXJjZXMgaXQgY29udHJvbHMuDQo+IA0KPiANCj4gICAgUHJvdG9jb2wgQ29udHJvbGxlciAoUEMp OiBoYW5kbGVzIHByb3RvY29sIHNwZWNpZmljIG1lc3NhZ2UNCj4gICAgZXhjaGFuZ2VzIGFjY29y ZGluZyB0byB0aGUgcmVmZXJlbmNlIHBvaW50IG92ZXIgd2hpY2ggdGhlDQo+ICAgIGluZm9ybWF0 aW9uIGlzIGV4Y2hhbmdlZCAoZS5nLiBFLU5OSSwgSS1OTkkpLCBhbmQgaW50ZXJuYWwgZXhjaGFu Z2VzDQo+ICAgIHdpdGggdGhlIFJDLiBUaGUgUEMgZnVuY3Rpb24gaXMgcHJvdG9jb2wgZGVwZW5k ZW50Lg0KPiANCj4gDQo+IA0KPiANCj4gDQo+IA0KPiANCj4gDQo+IA0KPiANCj4gDQo+IA0KPiAN Cj4gDQo+IFcuQWxhbnFhciBldCBhbC4gLSBFeHBpcmVzIE9jdG9iZXIgMjAwNCAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgMTgNCj4gZHJhZnQtaWV0Zi1jY2FtcC1nbXBscy1hc29uLXJvdXRp bmctcmVxdHMtMDMudHh0ICAgICAgICAgICAgQXByaWwgMjAwNA0KPiANCj4gDQo+IA0KPiBGdWxs IENvcHlyaWdodCBTdGF0ZW1lbnQNCj4gDQo+ICMjIFJlcXVpcmUgbmV3IGNvcHlyaWdodCBib2ls ZXJwbGF0ZQ0KPiANCj4gDQo+ICAgIENvcHlyaWdodCAoQykgVGhlIEludGVybmV0IFNvY2lldHkg KDIwMDQpLiBUaGlzIGRvY3VtZW50IGlzIHN1YmplY3QNCj4gICAgdG8gdGhlIHJpZ2h0cywgbGlj ZW5zZXMgYW5kIHJlc3RyaWN0aW9ucyBjb250YWluZWQgaW4gQkNQIDc4IGFuZA0KPiAgICBleGNl cHQgYXMgc2V0IGZvcnRoIHRoZXJlaW4sIHRoZSBhdXRob3JzIHJldGFpbiBhbGwgdGhlaXIgcmln aHRzLg0KPiANCj4gDQo+ICAgIFRoaXMgZG9jdW1lbnQgYW5kIHRyYW5zbGF0aW9ucyBvZiBpdCBt YXkgYmUgY29waWVkIGFuZCBmdXJuaXNoZWQgdG8NCj4gICAgb3RoZXJzLCBhbmQgZGVyaXZhdGl2 ZSB3b3JrcyB0aGF0IGNvbW1lbnQgb24gb3Igb3RoZXJ3aXNlIGV4cGxhaW4gaXQNCj4gICAgb3Ig YXNzaXN0IGluIGl0cyBpbXBsZW1lbnRhdGlvbiBtYXkgYmUgcHJlcGFyZWQsIGNvcGllZCwgcHVi bGlzaGVkDQo+ICAgIGFuZCBkaXN0cmlidXRlZCwgaW4gd2hvbGUgb3IgaW4gcGFydCwgd2l0aG91 dCByZXN0cmljdGlvbiBvZiBhbnkNCj4gICAga2luZCwgcHJvdmlkZWQgdGhhdCB0aGUgYWJvdmUg Y29weXJpZ2h0IG5vdGljZSBhbmQgdGhpcyBwYXJhZ3JhcGgNCj4gICAgYXJlIGluY2x1ZGVkIG9u IGFsbCBzdWNoIGNvcGllcyBhbmQgZGVyaXZhdGl2ZSB3b3Jrcy4gSG93ZXZlciwgdGhpcw0KPiAg ICBkb2N1bWVudCBpdHNlbGYgbWF5IG5vdCBiZSBtb2RpZmllZCBpbiBhbnkgd2F5LCBzdWNoIGFz IGJ5IHJlbW92aW5nDQo+ICAgIHRoZSBjb3B5cmlnaHQgbm90aWNlIG9yIHJlZmVyZW5jZXMgdG8g dGhlIEludGVybmV0IFNvY2lldHkgb3Igb3RoZXINCj4gICAgSW50ZXJuZXQgb3JnYW5pemF0aW9u cywgZXhjZXB0IGFzIG5lZWRlZCBmb3IgdGhlIHB1cnBvc2Ugb2YNCj4gICAgZGV2ZWxvcGluZyBJ bnRlcm5ldCBzdGFuZGFyZHMgaW4gd2hpY2ggY2FzZSB0aGUgcHJvY2VkdXJlcyBmb3INCj4gICAg Y29weXJpZ2h0cyBkZWZpbmVkIGluIHRoZSBJbnRlcm5ldCBTdGFuZGFyZHMgcHJvY2VzcyBtdXN0 IGJlDQo+ICAgIGZvbGxvd2VkLCBvciBhcyByZXF1aXJlZCB0byB0cmFuc2xhdGUgaXQgaW50byBs YW5ndWFnZXMgb3RoZXIgdGhhbg0KPiAgICBFbmdsaXNoLg0KPiANCj4gDQo+ICAgIFRoZSBsaW1p dGVkIHBlcm1pc3Npb25zIGdyYW50ZWQgYWJvdmUgYXJlIHBlcnBldHVhbCBhbmQgd2lsbCBub3Qg YmUNCj4gICAgcmV2b2tlZCBieSB0aGUgSW50ZXJuZXQgU29jaWV0eSBvciBpdHMgc3VjY2Vzc29y cyBvciBhc3NpZ25zLg0KPiANCj4gDQo+ICAgIFRoaXMgZG9jdW1lbnQgYW5kIHRoZSBpbmZvcm1h dGlvbiBjb250YWluZWQgaGVyZWluIGlzIHByb3ZpZGVkIG9uIGFuDQo+ICAgICJBUyBJUyIgYmFz aXMgYW5kIFRIRSBJTlRFUk5FVCBTT0NJRVRZIEFORCBUSEUgSU5URVJORVQgRU5HSU5FRVJJTkcN Cj4gICAgVEFTSyBGT1JDRSBESVNDTEFJTVMgQUxMIFdBUlJBTlRJRVMsIEVYUFJFU1MgT1IgSU1Q TElFRCwgSU5DTFVESU5HDQo+ICAgIEJVVCBOT1QgTElNSVRFRCBUTyBBTlkgV0FSUkFOVFkgVEhB VCBUSEUgVVNFIE9GIFRIRSBJTkZPUk1BVElPTg0KPiAgICBIRVJFSU4gV0lMTCBOT1QgSU5GUklO R0UgQU5ZIFJJR0hUUyBPUiBBTlkgSU1QTElFRCBXQVJSQU5USUVTIE9GDQo+ICAgIE1FUkNIQU5U QUJJTElUWSBPUiBGSVRORVNTIEZPUiBBIFBBUlRJQ1VMQVIgUFVSUE9TRS4NCj4gDQo+IA0KPiAN Cj4gDQo+IA0KPiANCj4gDQo+IA0KPiANCj4gDQo+IA0KPiANCj4gDQo+IA0KPiANCj4gDQo+IA0K PiANCj4gDQo+IA0KPiANCj4gDQo+IA0KPiANCj4gDQo+IA0KPiBXLkFsYW5xYXIgZXQgYWwuIC0g RXhwaXJlcyBPY3RvYmVyIDIwMDQgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDE5DQoNCi0t IA0KUGFwYWRpbWl0cmlvdSBEaW1pdHJpDQpFLW1haWwgOiBkaW1pdHJpLnBhcGFkaW1pdHJpb3VA YWxjYXRlbC5iZQ0KRS1tYWlsIDogZHBhcGFkaW1pdHJpb3VAcHNnLmNvbQ0KV2VicGFnZTogaHR0 cDovL3BzZy5jb20vfmRwYXBhZGltaXRyaW91Lw0KQWRkcmVzczogRnIuIFdlbGxlc3BsZWluIDEs IEItMjAxOCBBbnR3ZXJwZW4sIEJlbGdpdW0NClBob25lICA6ICszMiAzIDI0MC04NDkxDQoNCg== Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 21 Apr 2004 15:46:51 +0000 From: "Adrian Farrel" To: ccamp@ops.ietf.org, jvasseur@cisco.com Cc: adrian@olddog.co.uk Reply-To: adrian@olddog.co.uk Subject: Re: Draft draft-vasseur-ccamp-loose-path-reopt-01.txt Date: Wed, 21 Apr 2004 16:42:56 +0100 Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=_0_11699_1082562266"; charset="iso-8859-1" Message-Id: This is a MIME-formatted message. If you see this text it means that your mail software cannot handle MIME-formatted messages. --=_0_11699_1082562266 Content-Type: text/plain; format=flowed; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Hi JP, Please find attached a version of your draft with a bunch of comments, nits and questions. Cheers, Adrian PS Please see RFC3667 for new copyright and IPR boilerplate (or use one of the IETF editing tools) ----- Original Message ----- From: "Jean Philippe Vasseur" To: Sent: Tuesday, April 20, 2004 4:08 AM Subject: Draft draft-vasseur-ccamp-loose-path-reopt-01.txt > Hi, > > Just to mention that we posted a new revision of > draft-vasseur-ccamp-loose-path-reopt-01.txt that proposes some mechanisms > for the reoptimization of loosely routed TE LSP (intra-area, inter-area and > Inter-AS). Thanks for the various comments and support that we got on this > ID, this new revision incorporates the comments that we received + various > edits and clarifications. > > JP. --=_0_11699_1082562266 Content-Disposition: attachment; filename=draft-vasseur-ccamp-loose-path-reopt-01-af.txt Content-Type: text/plain; charset="iso-8859-1"; name=draft-vasseur-ccamp-loose-path-reopt-01-af.txt Content-Transfer-Encoding: 8bit ## please don't have header on first page draft-vasseur-ccamp-loose-path-reopt-01.txt April 2004 IETF Internet Draft Jean-Philippe Vasseur (Editor) Proposed Status : Standard Cisco Systems, Inc Expires: October 2004 Yuichi Ikejiri NTT Communications Corporation April 2004 draft-vasseur-ccamp-loose-path-reopt-01.txt Reoptimization of MPLS Traffic Engineering loosely routed LSP paths ## I really don't like "LSP path" ## "Label Switched Path path" ## How long before we write "LSPP"? ## Then we can introduce "LSPP path"! :-) ## Applies throughout the document. ## ## Can we mainly delete "path". I.e. "Loosely routed LSPs" or ## "LSP loose route" or "loose LSP route" Status of this Memo ## Please indent text correctly throughout document This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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. Vasseur and Ikejiri 1 ## please use page throws draft-vasseur-ccamp-loose-path-reopt-01.txt April 2004 ## Please place abstract before contents Table of content 1. Introduction 2. Establishment of a loosely routed TE LSP 3. Reoptimization of a loosely routed TE LSP path 4. Signalling extensions 4.1 ERO expansion signaling request 4.2 New Path Error sub-codes 5. Mode of operation 5.1 Head-end reoptimization control 5.2 Reoptimization triggers 5.3 Head-end request versus mid-point explicit notification modes 5.3.1 Head-end request mode 5.3.2 Mid-point explicit notification mode 5.3.3 ERO cashing 6. Interoperability 7. Security considerations 8. Acknowledgments 9. Intellectual property Abstract ## This abstract is a little long. Normally aim for about 10 lines. ## Probably OK, however. This document defines a mechanism for the reoptimization of MPLS Traffic Engineering loosely routed LSP paths. A loosely routed LSP path is a path specified as a combination of strict and loose hop(s) that contains at least one loose hop and zero or more strict hop(s). The path calculation (which implies an ERO expansion) to reach a loose hop is performed by the previous hop defined in the TE LSP path. This document proposes a mechanism that allows: ## Why is this draft limited to "loose" hops ## Surely strict hops that are non-specific abstract nodes are also ## important. For example, if I have an AS number in my ERO I might not ## use a loose hop, but reoptimization would still be important. - The TE LSP head-end LSR to trigger a new ERO expansion on every hop having a next hop defined as a loose hop, - A mid-point LSR to signal to the head-end LSR that either a better path exists to reach a loose hop (compared to the current path in use) or that the TE LSP must be reoptimized because of some maintenance required on the TE LSP path. A better path is defined as a lower cost path, where the cost is determined by the metric used to compute the path. The proposed mechanism applies to intra-domain and inter-domain packet and non-packet TE LSPs when the path is defined as a list of loose hops. Examples of domains are IGP areas and Autonomous Systems. 1. Introduction The Traffic Engineering Work Group has specified a set of requirements for inter-area [INTER-AREA-TE-REQ] and inter-AS [INTER-AS-TE-REQ] MPLS Traffic Engineering. Both requirements documents specify the need for ## well they say "SHOULD", not "MUST" some mechanism providing an option for the head-end to control the Vasseur and Ikejiri 2 draft-vasseur-ccamp-loose-path-reopt-01.txt April 2004 reoptimization process, should a more optimal path exist in a downstream domain (IGP area or Autonomous System). This document defines a solution to meet this requirement, in addition >to a mechanism to discover the existence of such a more optimal path ## Is this true? Do you discover the existence of a more optimal path or ## do you inform the head-end the of the existence of a more optimal ## path? ## So you should say "a mechanism to communicate the existence of a ## more optimal path or a request to reoptimize..." or the need to reoptimize due to some maintenance required in a downstream domain. ## Do you need to describe what you mean by "reoptimize"? ## In particular, you mean "...re-signal the LSP using a new LSP Id ## so that the LSP can be re-routed onto a more optimal (or simply ## different) path with minimal disruption to traffic. In particular, ## re-optimaization SHOULD NOT use a simple change to the ERO of the ## existing LSP because this may adversely impact traffic. The reasons ## for not using a change to the ERO are explained further in section x" 2. Establishment of a loosely routed TE LSP A loosely routed explicit path is a path specified as a combination of strict and loose hop(s) that contains at least one loose hop and a set of zero or more strict hop(s). Loose hops are listed in the ERO object of the RSVP Path message with the L flag of the IPv4 or the IPv6 prefix sub-object set, as defined in [RSVP-TE]. In this case, each LSR along the path whose next hop is specified as a loose hop triggers a path computation (also referred to as an ERO expansion), before forwarding ## You see, ERO expansion also refers to the expansion of abstract nodes ## Also what about when there are no loose hops, but the ERO does not go ## as far as the egress? Surely you want to include this, too. the RSVP Path message downstream. The path computation may either be performed by means of CSPF or any Path Computation Element (PCE) and can be partial (up to the next loose hop) and complete (up to the TE LSP destination). ## Note that whil *I* agree with your point here, this directly goes ## against 3209 which says that expansion is (at most) only as far as ## the next specified hop (loose or strict). ## I think that you need to explain the fact that you are extending the ## definition of 3209. Note that the examples in the rest of this document are provided in the context of MPLS inter-area TE but the proposed mechanism equally applies to loosely routed explicit paths within a single routing domain and across multiple Autonomous Systems. The examples below are provided with OSPF as the IGP but the described set of mechanisms similarly apply to IS-IS. ## Make the following into section 2.1 An example of an explicit loosely routed TE LSP signaling. <---area 1--><-area 0--><-area 2-> < R1---R2----R3---R6 R8-----R10 < | | | / |\ | < | | | -- | --\ | < | | |/ | \| < R4---------R5---R7----R9-----R11 > R1---R2----R3---R6 R8----R10 > | | | / |\ | > | | | / | \ | > | | | / | \ | > | | |/ | \| > R4---------R5---R7----R9----R11 Assumptions - R3, R5, R8 and R9 are ABRs <- The path an inter-area TE LSP T1 from R1 (head-End LSR) to R11 (tail- >- The path of an inter-area TE LSP T1 from R1 (head-End LSR) to R11 (tail- end LSR) is defined on R1 as the following loosely routed path: R1- R3(loose)-R8(loose)-R11(loose). R3, R8 and R11 are defined as loose hops. ## In step 3 you say how R3 determines how to expand the ERO. Why do you ## not say how R1 determines the ERO in step 1? Step 1: R1 builds the following ERO object: R1(S)-R2(S)-R3(S)-R8(L)- R11(L) where: S: Strict hop (L=0) L: Loose hop (L=1) Vasseur and Ikejiri 3 draft-vasseur-ccamp-loose-path-reopt-01.txt April 2004 The R1-R2-R3 path obeys T1Æs set of constraints ## Bad character in text Step 2: the RSVP Path message is then forwarded by R1 following the ERO path and reaches R3 with the following content: R8(L)-R11(L) Step 3: R3 determines that the next hop (R8) is a loose hop (not directly connected to R3) and then performs an ERO expansion operation ## Actually, even if it was directly connected, if it is a loose hop ## we should do a CSPF computation. We don't necessarily want to go ## on the direct link. to reach the next loose hops R8 either by means of CSPF or any other PCE-based path computation method. The new ERO becomes: R6(S)-R7(S)- R8(S)-R11(L) Note: in this example, the assumption is made that the path is computed on a per loose hop basis, also referred to a partial route computation. Note that PCE-based mechanisms may also allow for full route computation (up to the final destination). ## I suspect that people will complain about the strong use of PCE in ## the two previous paragraphs Step 4: the same procedure applies at R8 to reach T1Æs destination: R11. ## Bad character in text 3. Reoptimization of a loosely routed TE LSP path Once a loosely routed explicit TE LSP is set up, it is maintained through normal RSVP procedures. Then a more optimal path might appear between an LSR and its next loose hop (for the sake of illustration, suppose in the example above that a link between R6 and R8 is added or restored that provides a shorter path between R3 and R8 (R3-R6-R8) than the existing R3-R6-R7-R8 path). Since the better path is not visible from the head-end LSR by means of the IGP because it does not belong to the head-end IGP area, the head-end cannot make use of this better path <(and perform a make before break) when appropriate. Hence some >(and re-route the LSP using make before break) when appropriate. Hence some mechanism is required to detect the existence of such a better path and notify the head-end accordingly. This document defines a mechanism that allows: - A head-end LSR to trigger on every LSR whose next hop is a loose hop the re-evaluation of the current path in order to detect a potential more optimal path, - A mid-point LSR whose next hop is a loose-hop to signal (using a new ERROR-SPEC sub-code carried in a Path Error Notify ## What do you mean "sub-code"? ## Do you mean Error Value? ## ## What do you mean "Path Error Notify message"? ## Do you mean PathErr and Notify messages message) to the head-end that a better path exists (a path with a lower cost, where the cost is defined by the metric used to compute the path û see [SEC-METRIC], [METRIC]). ## Bad character in text ## Besides, I don't see that this is the time to start to describe ## what might be meant by a "better path" in terms of possible ## CSPF computations. This really is simply a statement that "if the ## path computation were to be applied for a second time it would ## produce a different result." This covers optimization, maintenance, ## and all forms of CSPF grooming. Then once the existence of such a better path is notified to the head- end, the head-end LSR can decide (depending on the TE LSP characteristics) whether to perform a TE LSP graceful reoptimization. There is another scenario whereby notifying the head-end of the Vasseur and Ikejiri 4 draft-vasseur-ccamp-loose-path-reopt-01.txt April 2004 existence of a better path is desirable: if the current path is about the fail due to some (link or node) required maintenance. This allows the head-end to reoptimize a TE LSP making use of the non disruptive make before break procedure if and only if a better path exists and if such a reoptimized is desired. ## There is a specific, more precise requirement here. What if the ## component link or label is about to go out of service? Do we ## also need to resignal using make-before break? ## ## I have been trying to formulate something for this in GMPLS. ## The specific concern here is that the maintenance decision may ## be taken at the network node (within the domain), not at the ## centralized management/routing controller (PCE) for the domain. ## Thus there is a need to signal this resource (i.e. not link) ## change back up the LSP to the point of computation, and possibly ## forward again in the new Path request as an explicit exclusion. ## For example, think of a 20 lambda link where the in-use lambda is ## about to be deprovisioned. The link and TE stays good, but the ## in-use label is about to go away. ## Hmmm, on reflection, it is fine simply to cause re-signaling the ## way you propose, and allow label re-negotiation on the make-before- ## break LSP. ## Perhaps it would be good to comment on this usage since it is a major ## requirement for GMPLS. 4. Signalling extensions 4.1. ERO expansion signaling request The following new flag of the SESSION_ATTRIBUTE object (C-Type 1 and 7) is defined: ERO Expansion request: 0x20 ## I think your IANA section should request that IANA manages this ## flags field and allocates you a new value. This flag indicates that a new ERO expansion is requested. ## If you do make-before-break, it is a new LSP. How would you use the ## "old" ERO in this case? Of course, the old LSP's resource attributes ## must be available for sharing during the computation, but still, you ## compute a new route every time you get a Path message for a new LSP. Note: in case of link bundling for instance, although the resulting ERO might be identical, this might give the opportunity for a mid-point LSR to locally select another link within a bundle, although strictly speaking, the ERO has not changed. ## Aha! But the change in ERO doesn't matter in this case because it is ## a new LSP so the LSRs are free to make a new choice in any case. ## ## I *think* the destinction you are trying to signal is that the new ## LSP is NOT simply another LSP in the session that should attempt to ## maximally share resources with the existing LSP, but is actually a ## replacement LSP (using make-before-break) and the other LSP in this ## session will be torn down later so resource sharing is not required ## except where it occurs fortuitously. ## ## Further (oh gods, he goes on!) don't you actually need to know which ## LSP is being replaced? Consider that you have two load sharing LSPs ## within one session. It is possible that these LSPs share links or ## nodes within some parts of the network (full path diversity is not a ## requirement ofr load sharing). In this case, when you do make before ## break to establish an LSP on a better path, it is important to ## indicate which LSP is being replaced. <4.2. New Path Error sub-code >4.2. New Error Spec Error Values As defined in [RSVP-TE], the ERROR-CODE 25 an ERROR SPEC object corresponds to a Notify Error. This document adds three new Error Values: 6 Better path exists 7 Local link maintenance required 8 Local node maintenance required ## Please add an IANA section for the allocation of these values. ## You may *suggest* these values. The details about the local maintenance required modes are detailed in section 5.3.2 5. Mode of operation 5.1. Head-end reoptimization control The notification process of a better path (shorter path or new path due to some maintenance required on the current path) is by nature de- correlated from the reoptimization operation. In other words, the location where a potentially more optimal path is discovered does not have to be where the TE LSP is actually reoptimized. This document applies to the context of a head-end reoptimization. 5.2. Reoptimization triggers There are three possible reoptimization triggers: Vasseur and Ikejiri 5 draft-vasseur-ccamp-loose-path-reopt-01.txt April 2004 - Timer-based: a reoptimization is triggered (process evaluating whether a more optimal path can be found) when a configurable timer expires, - Event-driven: a reoptimization is triggered when a particular network event occurs (such as a ôLink-UPö event), ## Bad characters in text ## ## Do you want to add "Deferred Event-driven" as a fourth class? - Operator-driven: a reoptimization is manually triggered by the Operator. It is RECOMMENDED for an implementation supporting the extensions proposed in this document to support both modes. ## Given that there are three modes, what do you want to recommend? 5.3. Head-end request versus mid-point explicit notification modes This document defines two modes: - ôHead-end requesting modeö: the request for a new path ## Bad characters in text evaluation of a loosely routed TE LSP is requested by the head- end LSR. ## I seriously misread this (and actually the draft up to this point). ## It was not previously clear that this mode is used by the head end ## to ask the network whether any better paths exist. This is done ## to determine whether there is value in make before break signaling. ## Could you make this clearer here and in earlier sections? - ôMid-point explicit notificationö: a mid-point LSR having ## Bad characters in text determined that a better path (than the current path is use) exists or having the desire to perform a link/node local maintenance explicitly notifies the head-end LSR which will in turn decide whether to perform a reoptimization. ## It is unclear from this text whether the reporting LSR/domain is ## requesting or requiring a re-optimization (you use "desire"). Perhaps ## you need different quality actions according to the Error Values. 5.3.1. Head-end request mode ## Format In this mode, when a timer-based reoptimization is triggered on the head-end LSR or the operator manually requests a reoptimization, the head-end LSR immediately sends an RSVP Path message with the ôERO Expansion requestö bit of the SESSION-ATTRIBUTE object set. This bit is ## bad characters in text then cleared in subsequent RSVP path messages sent downstream. ## Ouch! ## See the pain that is required for similar behavior in the GMPLS ## ADMIN_STATUS Object. Your problem here is that you need to be sure ## that this flag has properly propagated and been acted on before you ## send a new Path message with the bit cleared. ## ## Perhaps you need a sequence number. Perhpas you need a toggle bit ## so you only act when the bit toggles. Upon receiving a Path message with the ôERO expansion requestö bit set, ## bad characters in text every LSR for which the next abstract node contained in the ERO is defined as a loose hop, performs the following set of actions: ## ditto loose hop/abstract node ## Oh. Now you say what is going on!!! ## See my comment in 5.3 bullet one. 1) A new ERO expansion is triggered and the newly computed path is compared to the existing path: - If a better path can be found, the LSR MUST immediately send < a Path Error to the head-end LSR (Error code 25 (Notify), sub- < code=6 (better path exists)). At this point, the LSR MAY decide > a Path Error to the head-end LSR (Error code 25 (Notify), Error > Value=6 (better path exists)). At this point, the LSR MAY decide to clear the ERO expansion request bit of the SESSION-ATTRIBUTE object in subsequent RSVP Path messages sent downstream: this < mode is the RECOMMENDED mode. > mode is the RECOMMENDED mode for the reasons described below. The sending of a Path Error Notify message ôBetter path existsö ## bad characters in text ## Say: Path Error message with the error "Notify"/"Better path exists" to the head-end LSR will notify the head-end LSR of the Vasseur and Ikejiri 6 draft-vasseur-ccamp-loose-path-reopt-01.txt April 2004 existence of a better path (e.g in a downstream area/AS or in another location within a single domain). ## How does the head end distinguish between solicited and unsolicited ## information? Does it care? Hence, triggering additional ERO expansions on downstream nodes is unnecessary. The only motivation to forward subsequent RSVP Path messages with the ôExpansion request bitö of the SESSION-ATTRIBUTE ## bad characters in text object set would be to trigger path re-evaluation on downstream nodes that could in turn cache some potentially better paths downstream with the objective to reduce the signaling setup delay, should a reoptimization be performed by the head-end LSR. - If no better path can be found, the recommended mode is for an LSR to relay the request (by setting the ERO expansion bit of the SESSION-ATTRIBUTE object in RSVP path message sent downstream) only if no better path has been found on this mid- point LSR. ## When the bit reaches the egress, should there be some response so that ## the head-end is notified that nothing could be done and everyone has ## correctly processed the request. By better path, we mean a path having a lower cost. By default, an LSR uses the TE metric to compute the shortest path that obeys a set of constraints. Note that the head-end LSR might use the METRIC-TYPE object (defined in [PATH-COMP]) in its path message to request the LSR having a next hop defined as a loose hop in the ERO to use another metric to determine the best path. ## Same issue as above. "Better" really means "different". That is, ## it is a local matter what better/different would mean and what is ## reported is that a different path would be preferred. If the RSVP Path message with the ôERO expansion requestö bit set is ## bad characters in text lost, then the next request will be sent when the reoptimization event will trigger on the head-end LSR. The solution to handle RSVP reliable messaging has been defined in [REFRESH-REDUCTION]. ## It is unclear what you mean by "will trigger". If the operator has ## made a request, you must obey it or tell him that it has failed. ## How would he otherwise know to re-issue the request? ## ## Note that in MPLS the use of the refresh reduction mechanisms for ## guaranteed delivery can only be applied if refresh reduction is ## enabled. But not all nodes support refresh reduction (it is optional). ## GMPLS gets around this by specifically allowing Message ID without ## the use of Refresh Reduction. Is this what you are proposing here? If ## so, this is a significant change in RSVP-TE processing. ## ## In any case, reliable delivery is not enough since the subsequent ## Path message may catch up (and therefore overtake) the first message. ## This is actually highly likely since re-computation in many domains ## may take some considerable time. So your issue is that you may ## prematurely clear the computation required bit. ## Reliable delivery will not help here. The network administrator may decide to establish some local policy specifying to ignore such request or to consider those requests not more frequently than a certain rate. The proposed mechanism does not make any assumption of the path computation method performed by the ERO expansion process: it can either be CSPF or PCE based. ## Is PCE not also CSPF? :-) 5.3.2. Mid-point explicit notification mode ## Format In this mode, a mid-point LSR whose next abstract node is a loose hop can locally trigger an ERO expansion (when a configurable timer expires ## trigger or request? or on event-driven basis (link-up event for example) or the user explicitly requests it). If a better path is found compared to the existing one, the LSR sends a Path Error to the head-end LSR (Error code 25 (Notify), sub-code=6 (better path exists)). ## Error Value There are other circumstances in which a mid-point LSR MAY send an RSVP Path Error Notify message with the objective for the TE LSP to be ## PathError message rerouted by its head-end LSR: when a link or a node will go down for local maintenance reasons. In this case, the mid-point LSR where the local maintenance must be performed is responsible for sending an RSVP Vasseur and Ikejiri 7 draft-vasseur-ccamp-loose-path-reopt-01.txt April 2004 Path Error Notify message with the sub-code=7 or 8 depending on the ## PathError message with error code "Notify" and Error Value... ## ## By the way, it is better to always refer to the error value as a ## name string. That way there is only one editorial point for IANA ## to change. affected network element (link or node). Then the first upstream node having performed the ERO expansion MUST perform the following set of actions: - The link (sub-code=7) or the node (sub-code=8) MUST be locally registered for further reference (the TE database must be updated) - The RSVP Path Error message MUST be immediately forwarded unchanged upstream to the head-end LSR. ## But this crosses a domain boundary so there is a confidentiality ## issue. The domain boundary must be allowed to "aggregate" this ## information. Perhaps it would replace the link/node information ## with its own address. Upon, receiving a Path Error Notify message with sub-code 7 or 8, the ## PathError message with error code "Notify" and Error Value... Head-end LSR MUST perform a TE LSP reoptimization. Note that those modes are not exclusive: both the timer and event-driven reoptimization triggers can be implemented on the head-end and/or any mid-point LSR with potentially different timer values for the timer driven reoptimization case. A head-end LSR MAY decide upon receiving an explicit mid-point notification to delay its next ERO expansion request. ## If you talk about delays, you MUST specify a default timer value. ## I believe this is an editorial requirement. ## You need to be careful that this delay is not in contradiction of ## "Upon, receiving a Path Error Notify message with sub-code 7 or 8, ## the Head-end LSR MUST perform a TE LSP reoptimization." 5.3.3. ERO caching ## Format Once a mid-point LSR has determined that a better path exists (after a reoptimization request has been received by the head-end LSR or the reoptimization timer on the mid-point has fired), the more optimal path MAY be cached on the mid-point LSR for a limited amount of time to avoid having to recompute a route once the head-LSR performs a make before break. This mode is optional. Comment : ## Spurious text 6. Interoperability Comment : ## Spurious text An LSR not supporting the ôERO expansion requestö bit of the SESSION- ## Bad characters in text ATTRIBUTE object SHOULD just ignore it. ## 3209 says SHALL forward unmodified. I think you should say MUST and ## give reference to 3209. Any head-end LSR not supporting a Path Error Notify message with sub- code = 6, 7 or 8 MUST just silently ignore such Path Error messages. ## Erm, if it doesn't support them, you can't expect the code to be ## changed specially to ignore! ## It is interesting that there is a mistake in 3209 since it does not ## say that a Notify error code means anything special. ## Fortunately, it is well established that no PathErr message ever ## causes any change in the Path state at any transit LSR. Also, that ## the ingress that receives an error code/value that it does not ## understand. You can simply refer to 2205 for the correct processing ## at all legacy nodes. 7. Security Considerations The practice described in this document does not raise specific security issues beyond those of existing TE. ## Well, I have raised confidentiality for "maintenance required". ## ## What do you mean "existing TE"? 8. Acknowledgments The authors would like to thank Carol Iturralde, Miya Kohno, Francois Le Faucheur, Philip Matthews, Jim Gibson, Raymond Zhang, Jean-Louis Le Roux and Kenji Kumaki for their useful and valuable comments. Vasseur and Ikejiri 8 draft-vasseur-ccamp-loose-path-reopt-01.txt April 2004 9. Intellectual Property ## Ooooh! ## We have to use the new boiler plate. This includes personal IPR ## declarations. ## BTW, could you tell us what elements have been claimed? As you ## may be aware, there is debate about when drafts should not be ## moved forward by WGs if there is IPR claimed. This applies even ## if appropriate reasonable terms are in place. The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards- related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights. Normative References ## Format and bad characters throughout references. [RFC] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels," RFC 2119. [RSVP-TE] Awduche et al, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC3209, December 2001. Informative references [TE-REQ] Awduche et al, Requirements for Traffic Engineering over MPLS, RFC2702, September 1999. [METRICS] Fedyk et al, ôMultiple Metrics for Traffic Engineering with IS-IS and OSPFö, draft-fedyk-isis-ospf-te-metrics-01.txt, November 2000. [DS-TE] Le Faucheur et al, ôRequirements for support of Diff-Serv-aware MPLS Traffic Engineeringö, draft-ietf-tewg-diff-te-reqts-01.txt, June 2001. ## Not really relevant? Not referenced. Vasseur and Ikejiri 9 draft-vasseur-ccamp-loose-path-reopt-01.txt April 2004 [MULTI-AREA-TE] Kompella et al, ôMulti-area MPLS Traffic Engineeringö, draft-kompella-mpls-multiarea-te-03.txt, June 2002. [SEC-METRIC] Le Faucheur et all,ô Use of Interior Gateway Protocol (IGP) Metric as a second MPLS Traffic Engineering Metricö, draft-ietf- tewg-te-metric-igp-02.txt, September, 2002. [INTER-AREA-TE-REQ], Le Roux, Vasseur, Boyle et al. ½ Requirements for Inter-area MPLS Traffic Engineering ©, draft-ietf-tewg-interarea-mpls- te-req-01, April 2004 (Work in progress). [INTER-AS-TE-REQ] Zhang et al, ôMPLS Inter-AS Traffic Engineering requirementsö, draft-ietf-tewg-interas-mpls-te-req-06.txt, February 2004, Work in progress. [INTER-AREA-AS] Vasseur and Ayyangar, ôInter-area and Inter-AS Traffic Engineeringö, draft-vasseur-inter-area-AS-TE-00.txt, February 2004, work in progress. [REFRESH-REDUCTION] Berger et al, ôRSVP Refresh Overhead Reduction Extensionsö, April 2001 ## Spurious text below Authors' addresses: Formatted: Jean-Philippe Vasseur Cisco Systems, Inc. 300 Beaver Brook Road Boxborough , MA - 01719 USA Email: jpv@cisco.com Formatted: Formatted: Yuichi Ikejiri Formatted: NTT Communications Corporation Field Code 1-1-6, Uchisaiwai-cho, Chiyoda-ku Tokyo 100-8019 JAPAN Email: y.ikejiri@ntt.com Formatted: Formatted: Full Copyright Statement Formatted: Field Code Copyright (C) The Internet Society (2004). All Rights Reserved. ## please use new boilerplate for copyright. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by Vasseur and Ikejiri 10 draft-vasseur-ccamp-loose-path-reopt-01.txt April 2004 removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. Vasseur and Ikejiri 11 --=_0_11699_1082562266-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 21 Apr 2004 07:11:12 +0000 From: "Adrian Farrel" To: ccamp@ops.ietf.org Cc: adrian@olddog.co.uk, wesam.alanqar@mail.sprint.com, dbrungard@att.com, dmm@1-4-5.net, LyOng@ciena.com, Dimitri.Papadimitriou@alcatel.be, jonathan.sadler@tellabs.com, sdshew@nortelnetworks.com Reply-To: adrian@olddog.co.uk Subject: Re: FW: I-D ACTION:draft-ietf-ccamp-gmpls-ason-routing-reqts-03.txt Date: Wed, 21 Apr 2004 08:08:35 +0100 Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=_0_17189_1082531367"; charset="iso-8859-1" Message-Id: This is a MIME-formatted message. If you see this text it means that your mail software cannot handle MIME-formatted messages. --=_0_17189_1082531367 Content-Type: text/plain; format=flowed; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Hi ASON Routing DT, Please find attached a marked up copy of the draft. All changes are typographical or nits. Thanks, Adrian ----- Original Message ----- From: "Kireeti Kompella" To: Sent: Thursday, April 15, 2004 12:46 AM Subject: Re: FW: I-D ACTION:draft-ietf-ccamp-gmpls-ason-routing-reqts-03.txt > Hi All, > > On Wed, 14 Apr 2004, Brungard, Deborah A, ALABS wrote: > > > The ASON Routing Reqts DT has updated the following draft based on > > ITU Q14/15's Liaison and CCAMP mail list comments. > > > > We recommend this document as ready for WG Last Call. > > This commences a two-week WG Last Call on the GMPLS ASON routing > requirements. Last Call ends April 28th, 5pm PDT. Please send your > comments to the list. > > The proposed category is Informational. > > Kireeti. --=_0_17189_1082531367 Content-Disposition: attachment; filename=draft-ietf-ccamp-gmpls-ason-routing-reqts-03-af.txt Content-Type: text/plain; charset="iso-8859-1"; name=draft-ietf-ccamp-gmpls-ason-routing-reqts-03-af.txt Content-Transfer-Encoding: 8bit CCAMP Working Group Wesam Alanqar (Sprint) Internet Draft Deborah Brungard (ATT) Category: Informational David Meyer (Cisco Systems) Lyndon Ong (Ciena) Expiration Date: October 2004 Dimitri Papadimitriou (Alcatel) Jonathan Sadler (Tellabs) Stephen Shew (Nortel) April 2004 Requirements for Generalized MPLS (GMPLS) Routing for Automatically Switched Optical Network (ASON) draft-ietf-ccamp-gmpls-ason-routing-reqts-03.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC-2026. 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. Abstract The Generalized MPLS (GMPLS) suite of protocols has been defined to control different switching technologies as well as different applications. These include support for requesting TDM connections including SONET/SDH and Optical Transport Networks (OTNs). This document concentrates on the routing requirements on the GMPLS suite of protocols to support the capabilities and functionalities for an Automatically Switched Optical Network (ASON) as defined by ITU-T. W.Alanqar et al. - Expires September 2004 1 ## Missing page throws draft-ietf-ccamp-gmpls-ason-routing-reqts-03.txt April 2004 Table of Contents Status of this Memo .............................................. 1 Abstract ......................................................... 1 1. Contributors .................................................. 2 2. Conventions used in this document ............................. 2 3. Introduction .................................................. 2 4. ASON Routing Architecture and Requirements .................... 4 4.1 Multiple Hierarchical Levels of ASON Routing Areas (RAs) ..... 5 4.2 Hierarchical Routing Information Dissemination ............... 5 4.3 Configuration ................................................ 7 4.3.1 Configuring the Multi-Level Hierarchy ...................... 7 4.3.2 Configuring RC Adjacencies ................................. 7 4.4 Evolution .................................................... 7 4.5 Routing Attributes ........................................... 8 4.5.1 Taxonomy of Routing Attributes ............................. 8 4.5.2 Commonly Advertised Information ............................ 9 4.5.3 Node Attributes ............................................ 9 4.5.4 Link Attributes ............................................ 9 5. Security Considerations ...................................... 11 6. Conclusions .................................................. 11 7. Acknowledgements ............................................. 13 8. Intellectual Property Considerations ......................... 13 8.1 IPR Disclosure Acknowledgement .............................. 13 9. References ................................................... 14 9.1 Normative References ........................................ 14 10. Author's Addresses .......................................... 14 Appendix 1: ASON Terminology .................................... 16 Appendix 2: ASON Routing Terminology ............................ 18 Full Copyright Statement ........................................ 19 1. Contributors This document is the result of the CCAMP Working Group ASON Routing Requirements design team joint effort. 2. Conventions used in this document 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 [RFC2119]. 3. Introduction The GMPLS suite of protocols provides among other capabilities support for controlling different switching technologies. These include support for requesting TDM connections utilizing SONET/SDH (see ANSI T1.105/ITU-T G.707) as well as Optical Transport Networks (OTN, see ITU-T G.709). However, there are certain capabilities that are needed to support the ITU-T G.8080 control plane architecture for Automatically Switched Optical Network (ASON). Therefore, it is W.Alanqar et al. - Expires October 2004 2 draft-ietf-ccamp-gmpls-ason-routing-reqts-03.txt April 2004 desirable to understand the corresponding requirements for the GMPLS protocol suite. The ASON control plane architecture is defined in [G.8080], ASON routing requirements are identified in [G.7715], and in [G.7715.1] for ASON link state protocols. These Recommendations apply to all G.805 layer networks (e.g. SDH and OTN), and provide protocol neutral functional requirements and architecture. This document focuses on the routing requirements for the GMPLS suite of protocols to support the capabilities and functionality of ASON control planes. This document summarizes the ASON requirements using ASON terminology. This document does not address GMPLS applicability or GMPLS capabilities. Any protocol (in particular, routing) applicability, design or suggested extensions is strictly outside the scope of this document. ASON (Routing) terminology sections are provided in Appendix 1 and 2. The ASON routing architecture is based on the following assumptions: - A network is subdivided based on operator decision and criteria (e.g. geography, administration, and/or technology), the network subdivisions are defined in ASON as Routing Areas (RAs). - The routing architecture and protocols applied after the network is subdivided is an operator's choice. A multi-level hierarchy of RAs, as defined in ITU-T [G.7715] and [G.7715.1], provides for a hierarchical relationship of RAs based on containment, i.e. child RAs are always contained within a parent RA. The hierarchical containment relationship of RAs provides for routing information abstraction, thereby enabling scalable routing information representation. The maximum number of hierarchical RA levels to be < supported is NOT specified (outside the scope). > supported is NOT specified (outside the scope of this document). - Within an ASON RA and for each level of the routing hierarchy, multiple routing paradigms (hierarchical, step- by-step, source- based), centralized or distributed path computation, and multiple different routing protocols MAY be supported. The architecture does NOT assume a one-to-one correspondence of a routing protocol and a RA level and allows the routing protocol(s) used within different RAs (including child and parent RAs) to be different. The realization of the routing paradigm(s) to support the hierarchical levels of RAs is NOT specified. - The routing adjacency topology (i.e. the associated Protocol Controller (PC) connectivity) and transport topology is NOT assumed to be congruent. - The requirements support architectural evolution, e.g. a change in the number of RA levels, as well as aggregation and segmentation of RAs. The description of the ASON routing architecture provides for a conceptual reference architecture, with definition of functional components and common information elements to enable end-to-end routing in the case of protocol heterogeneity and facilitate management of ASON networks. This description is only conceptual: no physical partitioning of these functions is implied. W.Alanqar et al. - Expires October 2004 3 draft-ietf-ccamp-gmpls-ason-routing-reqts-03.txt April 2004 4. ASON Routing Architecture and Requirements ## trivial: you have "a RA" also "an RP" The fundamental architectural concept is the RA and it's related functional components (see Appendix 2 on terminology). The routing services offered by a RA are provided by a Routing Performer (RP). An RP is responsible for a single RA, and it MAY be functionally realized using distributed Routing Controllers (RC). The RC, itself, MAY be implemented as a cluster of distributed entities (ASON refers to the cluster as a Routing Control Domain (RCD)). The RC components for a RA receive routing topology information from their associated Link Resource Manager(s) (LRMs) and store this information in the Routing Information Database (RDB). The RDB is replicated at each RC < bounded to the same Routing Area (RA), and MAY contain information > bounded to the same RA, and MAY contain information about multiple transport plane network layers. Whenever the routing topology changes, the LRM informs the corresponding RC, which in turn updates its associated RDB. In order to assure RDB synchronization, the RCs co-operate and exchange routing information. Path computation functions MAY exist in each RC, MAY exist on selected RCs within the same RA, or MAY be centralized for the RA. In this context, communication between RCs within the same RA is realized using a particular routing protocol (or multiple protocols). In ASON, the communication component is represented by the protocol controller (PC) component(s) and the protocol messages are conveyed over the ASON control plane's Signaling Control Network (SCN). The PC MAY convey information for one or more transport network layers (refer to Section 4.2 Note). The RC is protocol independent and RC communications MAY be realized by multiple, different PCs within a RA. The ASON routing architecture defines a multi-level routing hierarchy of RAs based on a containment model to support routing information abstraction. [G.7715.1] defines the ASON hierarchical link state routing protocol requirements for communication of routing information within an RA (one level) to support hierarchical routing information dissemination (including summarized routing information for other levels). The Communication between any of the other functional component(s) (e.g. SCN, LRM, and between RCDs (RC- RC communication between RAs)), is outside the scope of [G.7715.1] protocol requirements and, thus, is also outside the scope of this document. ASON Routing components are identified by identifiers that are drawn from different name spaces (see [G.7715.1]). These are control plane identifiers for transport resources, components, and SCN addresses. The formats of those identifiers in a routing protocol realization SHALL be implementation specific and outside the scope of this document. The failure of a RC, or the failure of communications between RCs, < and the subsequent recover from the failure condition MUST NOT > and the subsequent recovery from the failure condition MUST NOT W.Alanqar et al. - Expires October 2004 4 draft-ietf-ccamp-gmpls-ason-routing-reqts-03.txt April 2004 disrupt calls in progress and their associated connections. Calls being set up MAY fail to complete, and the call setup service MAY be unavailable during recovery actions. 4.1 Multiple Hierarchical Levels of ASON Routing Areas (RAs) [G.8080] introduces the concept of Routing Area (RA) in reference to a network subdivision. RAs provide for routing information abstraction. Except for the single RA case, RAs are hierarchically contained: a higher level (parent) RA contains lower level (child) RAs that in turn MAY also contain RAs, etc. Thus, RAs contain RAs that recursively define successive hierarchical RA levels. However, the RA containment relationship describes only an architectural hierarchical organization of RAs. It does not restrict a specific routing protocol's realization (e.g. OSPF multi-areas, path computation, etc.). Moreover, the realization of the routing paradigm to support a hierarchical organization of RAs and the number of hierarchical RA levels to be supported is routing protocol specific and outside the scope of this document. In a multi-level hierarchy of RAs, it is necessary to distinguish among RCs for the different levels of the RA hierarchy. Before any pair of RCs establishes communication, they MUST verify they are < bounded to the same parent RA (see Section 4.2). A RA identifier (RA > bound to the same parent RA (see Section 4.2). A RA identifier (RA ID) is required to provide the scope within which the RCs can < communicate. To distinguish between RCs bounded to the same RA, an > communicate. To distinguish between RCs bound to the same RA, an RC identifier (RC ID) is required; the RC ID MUST be unique within its containing RA. < A RA represents a partition of the data plane and its identifier > A RA represents a partition of the data plane, and its identifier (i.e. RA ID) is used within the control plane as a reference to the < data plane partition. Each RA SHALL be uniquely identifiable within < a carrier's network. RA IDs MAY be associated with a transport plane > data plane partition. Each RA within a carrier's network SHALL be > uniquely identifiable. RA IDs MAY be associated with a transport plane name space whereas RC IDs are associated with a control plane name space. 4.2 Hierarchical Routing Information Dissemination < Routing information can be exchanged between RCs bounded to adjacent > Routing information can be exchanged between RCs bound to adjacent levels of the RA hierarchy i.e. Level N+1 and N, where Level N represents the RAs contained by Level N+1. The links connecting RAs MAY be viewed as external links (inter-RA links), and the links representing connectivity within a RA MAY be viewed as internal links (intra-RA links). The external links to a RA at one level of the hierarchy may be internal links in the parent RA. Intra-RA links of a child RA MAY be hidden from the parent RA's view. The physical location of RCs for adjacent RA levels, their relationship and their communication protocol(s) are outside the scope of this document. No assumption is made regarding how RCs communicate between adjacent RA levels. If routing information is W.Alanqar et al. - Expires October 2004 5 draft-ietf-ccamp-gmpls-ason-routing-reqts-03.txt April 2004 exchanged between a RC, its parent, and its child RCs, it SHOULD include reachability and MAY include (upon policy decision) node and < link topology. Only the RCs of the parent RA communicate, RCs of one < childÆs RA never communicate with the RCs of other child RAs. There > link topology. Communication between RAs only takes place between > RCs with a parent/child relationship. RCs of one RA never communicate > with RCs of another RA at the same level. There SHOULD not be any dependencies on the different routing protocols used within a RA or in different RAs. < Multiple RCs bounded to the same RA MAY transform (filter, > Multiple RCs bound to the same RA MAY transform (filter, summarize, etc.) and then forward information to RCs at different levels. However in this case the resulting information at the receiving level must be self-consistent; this MAY be achieved using a number of mechanisms. Note: there is no implied relationship between multi-layer transport networks and multi-level routing. Implementations may support a hierarchical routing topology (multi-level) with a single routing protocol instance for multiple transport switching layers or a hierarchical routing topology for one transport switching layer. 1. Type of Information Exchanged The type of information flowing upward (i.e. Level N to Level N+1) and the information flowing downward (i.e. Level N+1 to Level N) are used for similar purposes, namely, the exchange of reachability information and summarized topology information to allow routing across multiple RAs. The summarization of topology information may impact the accuracy of routing and MAY require additional path calculation. < The following information exchange are expected: > The following information exchanges are expected: - Level N+1 visibility to Level N reachability and topology (or upward information communication) allowing RC(s) at Level N+1 to determine the reachable endpoints from Level N. - Level N visibility to Level N+1 reachability and topology (or downward information communication) allowing RC(s) bounded to a RA at Level N to develop paths to reachable endpoints outside of the RA. 2. Interactions between Upward and Downward Communication When both upward and downward information exchanges contain endpoint reachability information, a feedback loop could potentially be created. Consequently, the routing protocol MUST include a method to: - prevent information propagated from a Level N+1 RA's RC into < the Level N RA's RC to be re-introduced into the Level N+1 RA's < RC, and > the Level N RA's RC from being re-introduced into the Level N+1 > RA's RC, and - prevent information propagated from a Level N-1 RA's RC into < the Level N RA's RC to be re-introduced into the Level N-1 RA's > the Level N RA's RC from being re-introduced into the Level N-1 RA's W.Alanqar et al. - Expires October 2004 6 draft-ietf-ccamp-gmpls-ason-routing-reqts-03.txt April 2004 RC. The routing protocol SHALL differentiate the routing information originated at a given level RA from derived routing information (received from external RAs), even when this information is forwarded by another RC at the same level. This is a necessary condition to be fulfilled by routing protocols to be loop free. 3. Method of Communication Two approaches exist for communication between Level N and N+1. - The first approach places an instance of a Level N routing function and an instance of a Level N+1 routing function in the same system. The communications interface is within a single system and is thus not an open interface subject to standardization. - The second approach places the Level N routing function on a separate system from the Level N+1 routing function. In this case, a communication interface must be used between the systems containing the routing functions for different levels. This communication interface and mechanisms are outside the scope of this document. 4.3 Configuration 4.3.1 Configuring the Multi-Level Hierarchy The RC MUST support static (i.e. operator assisted) and MAY support automated configuration of the information describing its < relationship to parent and its child within the hierarchical > relationship to its parent and its children within the hierarchical structure (including RA ID and RC ID). When applied recursively, the whole hierarchy is thus configured. 4.3.2 Configuring RC Adjacencies The RC MUST support static (i.e. operator assisted) and MAY support automated configuration of the information describing its associated > PC adjacencies to other RCs bounded to the same parent RA. The < PC adjacencies to other RCs bound to the same parent RA. The ## Do you really mean PC or RC? routing protocol SHOULD support all the types of RC adjacencies described in Section 9 of [G.7715]. The latter includes congruent topology (with distributed RC) and hubbed topology (e.g. note that the latter does not automatically imply designated RC). 4.4 Evolution The containment relationships of RAs MAY change, motivated by events such as mergers, acquisitions, and divestitures. The routing protocol SHOULD be capable of supporting architectural evolution in terms of number of hierarchical levels of RAs, as well W.Alanqar et al. - Expires October 2004 7 draft-ietf-ccamp-gmpls-ason-routing-reqts-03.txt April 2004 < as aggregation and segmentation of RAs. RA IDs uniqueness within an > as aggregation and segmentation of RAs. RA ID uniqueness within an administrative domain MAY facilitate these operations. The routing protocol is not expected to automatically initiate and/or execute these operations. Reconfiguration of the RA hierarchy MAY not ## Surely this is MUST? disrupt calls in progress, though calls being set up may fail to complete, and the call setup service may be unavailable during reconfiguration actions. 4.5 Routing Attributes Routing for transport networks is performed on a per layer basis, where the routing paradigms MAY differ among layers and within a < layer. Not all equipment support the same set of transport layers or > layer. Not all equipment supports the same set of transport layers or the same degree of connection flexibility at any given layer. A server layer trail may support various clients, involving different adaptation functions. Additionally, equipment may support variable adaptation functionality, whereby a single server layer trail dynamically supports different multiplexing structures. As a result, routing information MAY include layer specific, layer independent, and client/server adaptation information. 4.5.1 Taxonomy of Routing Attributes Attributes can be organized according to the following categories: - Node related or link related - Provisioned, negotiated or automatically configured - Inherited or layer specific (client layers can inherit some attributes from the server layer while other attributes like Link Capacity are specified by layer). (Component) link attributes MAY be statically or automatically configured for each transport network layer. This may lead to unnecessary repetition. Hence, the inheritance property of attributes MAY also be used to optimize the configuration process. < ASON uses the term, SNP, for the control plane representation of a > ASON uses the term, Subnetwork Point (SNP), for the control plane representation of a transport plane resource. The control plane representation and transport plane topology is NOT assumed to be congruent, the control plane representation SHALL not be restricted by the physical topology. The relational grouping of SNPs for routing is termed a < SNPP. The routing function understands topology in terms of SNPP > SNP Pool (SNPP). The routing function understands topology in terms of SNPP links. Grouping MAY be based on different link attributes (e.g., SRLG information, link weight, etc). Two RAs may be linked by one or more SNPP links. Multiple SNPP links MAY be required when component links are not equivalent for routing purposes with respect to the RAs they are attached to, or to the containing RA, or when smaller groupings are required. W.Alanqar et al. - Expires October 2004 8 draft-ietf-ccamp-gmpls-ason-routing-reqts-03.txt April 2004 4.5.2 Commonly Advertised Information Advertisements MAY contain the following common set of information regardless of whether they are link or node related: < - RA ID of which the advertisement is bounded > - RA ID of the RA to which the advertisement is bound - RC ID of the entity generating the advertisement - Information to uniquely identify advertisements - Information to determine whether an advertisement has been updated - Information to indicate when an advertisement has been derived from a different level RA. 4.5.3 Node Attributes All nodes belong to a RA, hence, the RA ID can be considered an attribute of all nodes. Given that no distinction is made between abstract nodes and those that cannot be decomposed any further, the same attributes MAY be used for their advertisement. In the < following tables, Capability refers to level of support required in > following tables, Capability refers to the level of support required in the realization of a link state routing protocol, whereas Usage < refers to degree of operational and implementation flexibility. > refers to the degree of operational and implementation flexibility. The following Node Attributes are defined: Attribute Capability Usage ----------- ----------- --------- Node ID REQUIRED REQUIRED Reachability REQUIRED OPTIONAL Table 1. Node Attributes Reachability information describes the set of endpoints that are reachable by the associated node. It MAY be advertised as a set of associated external (e.g. UNI) address/address prefixes or a set of associated SNPP link IDs/SNPP ID prefixes, the selection of which MUST be consistent within the applicable scope. These are control plane identifiers, the formats of these identifiers in a protocol realization is implementation specific and outside the scope of this document. Note: no distinction is made between nodes that may have further internal details (i.e., abstract nodes) and those that cannot be < decomposed any further. Hence the attributes of a node are not be > decomposed any further. Hence the attributes of a node are not considered only as single switch attributes but MAY apply to a node at a higher level of the hierarchy that represents a sub-network. 4.5.4 Link Attributes The following Link Attributes are defined: Link Attribute Capability Usage --------------- ----------- --------- Local SNPP link ID REQUIRED REQUIRED W.Alanqar et al. - Expires October 2004 9 draft-ietf-ccamp-gmpls-ason-routing-reqts-03.txt April 2004 Remote SNPP link ID REQUIRED REQUIRED Layer Specific Characteristics see Table 3 Table 2. Link Attributes The SNPP link ID name MUST be sufficient to uniquely identify the ## Why do you say "SNPP link ID name"? This is not defined. ## Do you mean "SNPP link ID"? corresponding transport plane resource taking into account separation of data and control planes (see Section 4.5.1, the control plane representation and transport plane topology is not assumed to be congruent). The SNPP link ID format is routing protocol specific. Note: when the remote end of a SNPP link is located outside of the RA, the remote SNPP link ID is OPTIONAL. The following link characteristic attributes are defined: - Signal Type: This identifies the characteristic information of the layer network. - Link Weight: The metric indicating the relative desirability of a particular link over another e.g. during path computation. - Resource Class: This corresponds to the set of administrative groups assigned by the operator to this link. A link MAY belong to zero, one or more administrative groups. - Connection Types: This attribute identifies whether the local SNP represents a TCP, CP, or can be flexibly configured as a TCP. ## Please expand TCP and CP in their first uses - Link Capacity: This provides the sum of the available and potential bandwidth capacity for a particular network transport layer. Other capacity measures MAY be further considered. - Link Availability: This represents the survivability capability such as the protection type associated with the link. - Diversity Support: This represents diversity information such as the SRLG information associated with the link. - Local Adaptation Support: This indicates the set of client layer adaptations supported by the TCP associated with the Local SNPP. This is only applicable when the local SNP represents a TCP or can be flexibly configured as a TCP. Link Characteristics Capability Usage ----------------------- ---------- --------- Signal Type REQUIRED OPTIONAL Link Weight REQUIRED OPTIONAL Resource Class REQUIRED OPTIONAL Local Connection Types REQUIRED OPTIONAL Link Capacity REQUIRED OPTIONAL W.Alanqar et al. - Expires October 2004 10 draft-ietf-ccamp-gmpls-ason-routing-reqts-03.txt April 2004 Link Availability OPTIONAL OPTIONAL Diversity Support OPTIONAL OPTIONAL Local Adaptation support OPTIONAL OPTIONAL Table 3. Link Characteristics Note: separate advertisements of layer specific attributes MAY be < chosen. However this may lead to unnecessary duplication. This can > chosen. However, this may lead to unnecessary duplication. This can be avoided using the inheritance property, so that the attributes derivable from the local adaptation information do not need to be advertised. Thus, an optimization MAY be used when several layers are present by indicating when an attribute is inheritable from a server layer. 5. Security Considerations ASON routing protocol MUST deliver the operational security objectives where required. These objectives do not necessarily imply requirements on the routing protocol itself, and MAY be met by other established means. 6. Conclusions The description of the ASON routing architecture and components is provided in terms of routing functionality. This description is only conceptual: no physical partitioning of these functions is implied. In summary, the ASON routing architecture assumes: - A network is subdivided into ASON RAs, which MAY support multiple routing protocols, no one-to-one relationship SHALL be assumed - Routing Controllers (RC) provide for the exchange of routing information (primitives) for the RA. The RC is protocol independent and MAY be realized by multiple, different protocol controllers within a RA. The routing information exchanged between RCs SHALL be subject to policy constraints imposed at reference points (External- and Internal-NNI) < - A multi-level RA hierarchy based on containment, only the RCs of < the parent RA communicate. RCs of child RAs never communicate with > - In a multi-level RA hierarchy based on containment, communication > between RCs of different RAs only happens when there is a parent/ > child relationship between the RAs. RCs of child RAs never communicate with the RCs of other child RAs. There SHOULD not be any dependencies on the different routing protocols used within a child RA and that of its parent. The routing information exchanged within the parent RA SHALL be independent of both the routing protocol operating within a child RA, and any control distribution choice(s), e.g. centralized, fully distributed. - For a RA, the set of RCs is referred to as an ASON routing (control) domain. The routing information exchanged between routing domains (inter-RA, i.e. inter-domain) SHALL be independent of both the intra-domain routing protocol(s), and the intra-domain control distribution choice(s), e.g. centralized, fully distributed. RCs bounded to different RA levels MAY be co-located within the same physical element or physically distributed. - The routing adjacency topology (i.e. the associated PC W.Alanqar et al. - Expires October 2004 11 draft-ietf-ccamp-gmpls-ason-routing-reqts-03.txt April 2004 connectivity topology) and the transport network topology SHALL NOT be assumed to be congruent - The routing topology SHALL support multiple links between nodes and RAs In summary, the following functionality is expected from GMPLS routing to instantiate the ASON hierarchical routing architecture realization (see [G.7715] and [G.7715.1]): - RAs SHALL be uniquely identifiable within a carrier's network, each having a unique RA ID within the carrier's network. - Within a RA (one level), the routing protocol SHALL support dissemination of hierarchical routing information (including summarized routing information for other levels) in support of an architecture of multiple hierarchical levels of RAs; the number of hierarchical RA levels to be supported by a routing protocol is implementation specific. - The routing protocol SHALL support routing information based on a common set of information elements as defined in [G.7715] and [G.7715.1], divided between attributes pertaining to links and abstract nodes (each representing either a sub-network or simply a node). [G.7715] recognizes that the manner in which the routing information is represented and exchanged will vary with the routing protocol used. - The routing protocol SHALL converge such that the distributed RDBs become synchronized after a period of time. To support hierarchical routing information dissemination within an RA, the routing protocol MUST deliver: < - processing of routing information exchanged between adjacent > - 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 < - when multiple RCs bound to a RA transform (filter, summarize, < etc.) and then forward information to RC(s) at different levels < that the resulting information at the receiving level is self- < consistent > - Self-consistent information at the receiving level resulting from > any transformation (filter, summarize, etc.) and forwarding of > information from one RC to RC(s) at different levels when multiple > RCs bound to a single RA < - a mechanism to prevent re-introduction of information propagated > - A mechanism to prevent re-introduction of information propagated into the Level N RA's RC back to the adjacent level RA's RC from which this information has been initially received. In order to support operator assisted changes in the containment relationships of RAs, the routing protocol SHALL support evolution < in terms of number of hierarchical levels of RAs. Example: support > in terms of number of hierarchical levels of RAs. For example: support of non-disruptive operations such as adding and removing RAs at the top/bottom of the hierarchy, adding or removing a hierarchical level of RAs in or from the middle of the hierarchy, as well as aggregation and segmentation of RAs. The number of hierarchical levels to be supported is routing protocol specific, and reflects a containment relationship e.g. a RA insertion involves supporting a different routing protocol domain in a portion of the network. W.Alanqar et al. - Expires October 2004 12 draft-ietf-ccamp-gmpls-ason-routing-reqts-03.txt April 2004 Reachability information (see Section 4.5.3) of the set of endpoints reachable by a node may be advertised either as a set of UNI Transport Resource addresses/ address prefixes, or a set of associated SNPP link IDs/SNPP link ID prefixes, assigned and selected consistently in their applicability scope. The formats of the control plane identifiers in a protocol realization are implementation specific. Use of a routing protocol within a RA should not restrict the choice of routing protocols for use in other RAs (child or parent). 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 sub-network or RA MUST be able to represent itself to the wider network as a single logical entity with only its external links visible to the topology database. 7. Acknowledgements The authors would like to thank Kireeti Kompella for having initiated the proposal of an ASON Routing Requirement Design Team. ## Perhaps it would be good to acknowledge any other contributors you had. ## In particular SG14/15 for their careful review and input. 8. Intellectual Property Considerations 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. 8.1 IPR Disclosure Acknowledgement By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. W.Alanqar et al. - Expires October 2004 13 draft-ietf-ccamp-gmpls-ason-routing-reqts-03.txt April 2004 9. References 9.1 Normative References [RFC2026] S.Bradner, "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [RFC2119] S.Bradner, "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [G.7715] ITU-T Rec. G.7715/Y.1306, "Architecture and Requirements for the Automatically Switched Optical Network (ASON)," June 2002. [G.7715.1] ITU-T Draft Rec. G.7715.1/Y.1706.1, "ASON Routing Architecture and Requirements for Link State Protocols," November 2003. [G.8080] ITU-T Rec. G.8080/Y.1304, "Architecture for the Automatically Switched Optical Network (ASON)," November 2001 (and Revision, January 2003). [HIER] K.Kompella and Y.Rekhter, "LSP Hierarchy with Generalized MPLS TE," Internet draft (work in progress), draft-ietf-mpls-lsp-hierarchy, September 02. ## Would it be OK to make the external references informative? 10. Author's Addresses Wesam Alanqar (Sprint) EMail: wesam.alanqar@mail.sprint.com Deborah Brungard (AT&T) Rm. D1-3C22 - 200 S. Laurel Ave. Middletown, NJ 07748, USA Phone: +1 732 4201573 EMail: dbrungard@att.com David Meyer (Cisco Systems) EMail: dmm@1-4-5.net Lyndon Ong (Ciena Corporation) 5965 Silver Creek Valley Rd, San Jose, CA 95128, USA Phone: +1 408 8347894 EMail: lyong@ciena.com Dimitri Papadimitriou (Alcatel) Francis Wellensplein 1, B-2018 Antwerpen, Belgium Phone: +32 3 2408491 EMail: dimitri.papadimitriou@alcatel.be W.Alanqar et al. - Expires October 2004 14 draft-ietf-ccamp-gmpls-ason-routing-reqts-03.txt April 2004 Jonathan Sadler 1415 W. Diehl Rd Naperville, IL 60563 EMail: jonathan.sadler@tellabs.com Stephen Shew (Nortel Networks) PO Box 3511 Station C Ottawa, Ontario, CANADA K1Y 4H7 Phone: +1 613 7632462 EMail: sdshew@nortelnetworks.com W.Alanqar et al. - Expires October 2004 15 draft-ietf-ccamp-gmpls-ason-routing-reqts-03.txt April 2004 Appendix 1: ASON Terminology This document makes use of the following terms: Administrative domain: (Recommendation G.805 For the purposes of [G7715.1] an administrative domain represents the extent of resources which belong to a single player such as a network operator, a service provider, or an end-user. Administrative domains of different players do not overlap amongst themselves. Control plane: performs the call control and connection control functions. Through signaling, the control plane sets up and releases connections, and may restore a connection in case of a failure. (Control) Domain: represents a collection of (control) entities that are grouped for a particular purpose. The control plane is subdivided into domains matching administrative domains. Within an administrative domain, further subdivisions of the control plane are recursively applied. A routing control domain is an abstract entity that hides the details of the RC distribution. External NNI (E-NNI): interfaces are located between protocol controllers between control domains. Internal NNI (I-NNI): interfaces are located between protocol controllers within control domains. Link: [See Recommendation G.805] a "topological component" which describes a fixed relationship between a "subnetwork" or "access group" and another "subnetwork" or "access group". Links are not limited to being provided by a single server trail. Management plane: performs management functions for the Transport Plane, the control plane and the system as a whole. It also provides coordination between all the planes. The following management functional areas are performed in the management plane: performance, fault, configuration, accounting and security management Management domain: [See Recommendation G.805] A management domain defines a collection of managed objects which are grouped to meet organizational requirements according to geography, technology, policy or other structure, and for a number of functional areas such as configuration, security, (FCAPS), for the purpose of providing control in a consistent manner. Management domains can be disjoint, contained or overlapping. As such the resources within an administrative domain can be distributed into several possible overlapping management domains. The same resource can therefore belong to several management domains simultaneously, but a management domain shall not cross the border of an administrative domain. W.Alanqar et al. - Expires October 2004 16 draft-ietf-ccamp-gmpls-ason-routing-reqts-03.txt April 2004 SNP: The SNP is a control plane abstraction that represents an actual or potential transport plane resource. SNPs (in different subnetwork partitions) may represent the same transport resource. A one-to-one correspondence should not be assumed. ## Add SNPP ## Add TCP Transport plane: provides bi-directional or unidirectional transfer of user information, from one location to another. It can also provide transfer of some control and network management information. The Transport Plane is layered; it is equivalent to the Transport Network defined in G.805. User Network Interface (UNI): interfaces are located between protocol controllers between a user and a control domain. Note: there is no routing function associated with a UNI reference point. W.Alanqar et al. - Expires October 2004 17 draft-ietf-ccamp-gmpls-ason-routing-reqts-03.txt April 2004 Appendix 2: ASON Routing Terminology This document makes use of the following terms: Routing Area (RA): a RA represents a partition of the data plane and its identifier is used within the control plane as the representation of this partition. Per [G.8080] a RA is defined by a set of sub-networks, the TE links that interconnect them, and the interfaces representing the ends of the TE links exiting that RA. A RA may contain smaller RAs inter-connected by TE links. The limit of subdivision results in a RA that contains two sub-networks and a TE link with a single component link. Routing Database (RDB): repository for the local topology, network topology, reachability, and other routing information that is updated as part of the routing information exchange and may additionally contain information that is configured. The RDB may contain routing information for more than one Routing Area (RA). Routing Components: ASON routing architecture functions. These functions can be classified as protocol independent (Link Resource Manager or LRM, Routing Controller or RC) and protocol specific (Protocol Controller or PC). Routing Controller (RC): handles (abstract) information needed for routing and the routing information exchange with peering RCs by operating on the RDB. The RC has access to a view of the RDB. The RC is protocol independent. Note: Since the RDB may contain routing information pertaining to multiple RAs (and possibly to multiple layer networks), the RCs accessing the RDB may share the routing information. Link Resource Manager (LRM): supplies all the relevant component and TE link information to the RC. It informs the RC about any state changes of the link resources it controls. Protocol Controller (PC): handles protocol specific message exchanges according to the reference point over which the information is exchanged (e.g. E-NNI, I-NNI), and internal exchanges with the RC. The PC function is protocol dependent. W.Alanqar et al. - Expires October 2004 18 draft-ietf-ccamp-gmpls-ason-routing-reqts-03.txt April 2004 Full Copyright Statement ## Require new copyright boilerplate Copyright (C) The Internet Society (2004). 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 translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. W.Alanqar et al. - Expires October 2004 19 --=_0_17189_1082531367-- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 20 Apr 2004 14:57:41 +0000 Message-Id: <200404201454.KAA23225@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-gmpls-ason-reqts-06.txt Date: Tue, 20 Apr 2004 10:54:52 -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 : Requirements for Generalized MPLS (GMPLS) Signaling Usage and Extensions for Automatically Switched Optical Network (ASON) Author(s) : D. Papadimitriou, et al. Filename : draft-ietf-ccamp-gmpls-ason-reqts-06.txt Pages : 14 Date : 2004-4-19 The Generalized MPLS (GMPLS) suite of protocol has been defined to control different switching technologies as well as different applications. These include support for requesting TDM connections including SONET/SDH and Optical Transport Networks (OTNs). This document concentrates on the signaling aspects of the GMPLS suite of protocols. It identifies the features to be covered by the GMPLS signalling protocol to support the capabilities of an Automatically Switched Optical Network (ASON). This document provides a problem statement and additional requirements on the GMPLS signaling protocol to support the ASON functionality. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-ason-reqts-06.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-ason-reqts-06.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-ason-reqts-06.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: <2004-4-20111614.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-gmpls-ason-reqts-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-gmpls-ason-reqts-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-4-20111614.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 20 Apr 2004 14:57:27 +0000 Message-Id: <200404201454.KAA23214@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-gmpls-recovery-functional-02.txt Date: Tue, 20 Apr 2004 10:54:40 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : Generalized MPLS Recovery Functional Specification Author(s) : J. Lang, B. Rajagopalan Filename : draft-ietf-ccamp-gmpls-recovery-functional-02.txt Pages : 19 Date : 2004-4-19 This document presents a functional description of the protocol extensions needed to support GMPLS-based recovery (i.e. protection and restoration). Protocol specific formats and mechanisms will be described in companion documents. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-recovery-functional-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-recovery-functional-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-recovery-functional-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: <2004-4-20111538.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-gmpls-recovery-functional-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-gmpls-recovery-functional-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-4-20111538.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 20 Apr 2004 07:48:06 +0000 From: "Adrian Farrel" To: gregbern@yahoo.com, ccamp@ops.ietf.org Cc: adrian@olddog.co.uk Reply-To: adrian@olddog.co.uk Subject: Re: Proposed strategy for Inter-area/AS Date: Tue, 20 Apr 2004 08:47:25 +0100 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: Hi Greg, > Nice work breakdown Adrian. Agree that the > applicability should be tackled early on. One of the > issues that has been a problem in the past was of > differing applicabilities. Agree. > Thanks also for putting the drafts in once nice easy > to access place. The only one I didn't see there was > the kompella-multi-area-te draft that you mention > below. Thanks. Yes, that draft was quite useful (and frankly, I missed it when I started on the inter-domain stuff which turns out to be really annoying because it contains some good text), however, it expired in December last year. I am parsing it to include relevant material in the framework draft. > Also agree in principle with Vishal's path computation > hierarchy. When dealing with different granularity > signal types, e.g., from 1 or 2Mbps MPLS LSPs all the > way to lambda or waveband switched GMPLS LSPs > different methods are generally called for. For > example, a distributed PCS approach would initially be > overkill, versus a centralized approach (not that many > LSPs to get set up that often) while if one is dealing > with lower rate MLPS LSPs a distributed PCS approach > (hopefully) would be more appropriate. Cheers, Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 20 Apr 2004 07:15:58 +0000 Reply-To: From: "Vishal Sharma" To: "Stefaan De Cnodder" , "CCAMP" Cc: "Fabio Ricciato" , "Ugo Monaco" , "Alessio D'Achille" , "Marco Listanti" Subject: Observations/feedback on draft-decnodder-mpls-interas-protection Date: Tue, 20 Apr 2004 00:14:15 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi Stefaan, As promised at the Seoul IETF, here is my (rather belated!) feedback on the interas protection draft. (I am cc'ing it to my co-authors as well, so that we can minimize duplication of our comments.) To make things easier, I have divided my comments into technical and editorial. Regards, -Vishal PS: BTW, thanks for your comments on draft-dachille, will try to respond to them after having time to review your feedback. ******************************************************************* Technical --------- i) Abstract: I think it would be useful to make clear here that the techniques in this document apply to links between 2 ASs (or only to inter-AS links). ii) Intro., para 4, "Section 4 ... node protection," would be clearer if it specified that an e2e path for an LSP _crossing multiple ASs_ can only provide link or node protection. (Presumably, for LSPs within an AS, where the SRLG's would be consistent, it should be possible to provide SRLG protection using e2e protection.) iii) Sec. 3, para 1, "For instance, in Figure 2 ... multiple core routers," it is a bit confusing to have R23 and R24. Which links specifically are being referred to here? Is it, R21-R24, R21-R25, R25-R24? iv) Title of Sec. 4 might be better as "Problems in SRLG protection with disjoint e2e LSPs" v) The document uses "main" and "primary" for the working LSP. It might be better to have consistently the same term throughout. vi) It might be better to add another row of routers in both ASs in Fig. 2, to make it non-trivial. That way, it will be possible to illustrate that there are multiple secondary egress AS-BRs, and multiple secondary ingress AS-BRs, and also that the egress AS-BR has to make a choice of a route to an appropriately picked secondary egress AS-BR, etc. vii) The way the method is described, especially in Sec. 6, it appears that the technique applies only to packet LSPs. Is my understanding correct? viii) The entire segment in Sec. 6.1.1 para 2, from "In case this condition ..." until "... not in the downstream AS (AS2 in Figure 2)," might benefit from some simplification in the writing. It's a bit difficult to follow, as written. ix) Similary, in the same para, the description of what portion of an RRO should be in the ERO for the detour LSP emanating from the egress AS-BR is also confusing. It might be restated as "The ERO for the detour LSP starting at the egress AS-BR contains several segments. It must first contain a strict or loose path towards the secondary egress AS-BR, followed by a segment of the RRO for the primary LSP. This segment begins at the last hop in the downstream AS and contains all hops thereafter up until the destination." x) In the same para, it is mentioned that the ERO of the detour LSP consists of two segments. However, when elucidating this with a reference to Fig. 2, the ERO of the detour LSP is only said to be composed for router R14, R22 and all routers thereafter. The segment from R14 to R12 and R12 to R21 is not mentioned. xi) In the draft, in the sentence describing the ERO of the detour LSP, the last router should probably be R24 instead of R22 (as currently written). xii) Sec. 6.1.1, para 4, the last sentence could be reworded to make it a bit clearer. I think it is saying that when the primary and secondary egress AS-BRs are the same, and the primary and secondary ingress AS-BRs are the same, and they have multiple links between them, then the detour LSP must simply use an inter-domain link different than the one used by the primary LSP, and no path computation is needed at the egress AS-BR. xiii) It would be useful to explain the purpose and structure of the LSP-Merge object as well as the operations performed on it, in Sec. 6.1. itself. Otherwise, the reader sees this object mentioned in the main text, without having an idea of what it is. In any case, since the appendices are quite small, and sort of intergral to the subsequent text in the main doc., I think it would be best to pull them into the main text. xiv) This will make the description in Sec. 6.1.4 and 6.3.1 easier to follow. xv) The second last para in Sec. 6.3.1 mentions that the merge point of the detour and main LSP must ensure that it can switchover traffic from the incoming detour LSP to its originating detour LSP, since the egress link at this merge point may belong to the same SRLG as the inter-domain link that the incoming detour LSP was protecting. Is this trivial to ensure? It appears that there is a bit of work that an LSR would have to do to ensure that. No? (Since the normal procedure would be simply to merge traffic from the detour LSP on to the main LSP.) xvi) Sec. 6.3.4, the first sentence "If the secondary ... inside these objects" is worded in a rather confusing way. In which objects does the sec. ingress AS-BR add the list of SRLG's of the inter-AS link? xvii) In Sec. 6.3.6. it is not clear why there is a focus on the SRLG protection of the link _preceding_ the ingress AS-BR? xviii) In the same section, the para "To ensure that .... towards the egress AS-BR" is unclear, and perhaps needs to be reworded and better explained. Not sure which link the phrase "... SRLG disjoint with the next link of the main LSP computed towards the egress AS-BR" refers? xix)In Sec. 6.3.6, para 4, the phrase "IF only 1 detour LSP ... LSP setup would fail," is unclear. xx) Sec. 7, second last para states "We also note ... does not lead to the failure of the bypass tunnel." I guess it wasn't clear why teh interface failure does not cause a failure of the bypass tunnel. xxi) Appendix B, last sentence, why is the use of the sender-template specific detour LSP merely "recommended" as opposed to being "required"? xxii) The last sentence of Appendix B ends with "avoid merging with other LSPs". It would be useful to say here which those "other LSPs" are. I assume their are themselves other detour LSPs for the given main LSP? Editorial --------- i) Sec. 4, para 1, "first of all it supports fast recovery, and, second, it provides SRLG protection..." ii) Sec. 4, para 3, "This is because ... in common with AS1, and _neither_ AS1 nor AS3 will be aware ..." iii) Sec. 6.1.1, para 2, "in case this condition ... goes through the AS where the detour LSP originated causing loops." iv) Sec. 6.2, "The method to determine a secondary egress AS-Br is the same as for the _secondary_ egress AS-BR for link protection." v) Sec. 7, para 5, "The difficulty ... bypass tunnels _lies_ in the selection of the appropriate ..." Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 20 Apr 2004 03:09:59 +0000 Message-Id: <4.3.2.7.2.20040419230500.06379700@wells.cisco.com> Date: Mon, 19 Apr 2004 23:08:08 -0400 To: ccamp@ops.ietf.org From: Jean Philippe Vasseur Subject: Draft draft-vasseur-ccamp-loose-path-reopt-01.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Hi, Just to mention that we posted a new revision of draft-vasseur-ccamp-loose-path-reopt-01.txt that proposes some mechanisms for the reoptimization of loosely routed TE LSP (intra-area, inter-area and Inter-AS). Thanks for the various comments and support that we got on this ID, this new revision incorporates the comments that we received + various edits and clarifications. JP. Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 19 Apr 2004 21:44:22 +0000 Message-ID: <20040419214407.99669.qmail@web60305.mail.yahoo.com> Date: Mon, 19 Apr 2004 14:44:07 -0700 (PDT) From: Greg Bernstein Subject: Re: Proposed strategy for Inter-area/AS To: Adrian Farrel , ccamp IETF MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Nice work breakdown Adrian. Agree that the applicability should be tackled early on. On of the issues that has been a problem in the past was of differing applicabilities. Thanks also for putting the drafts in once nice easy to access place. The only one I didn't see there was the kompella-multi-area-te draft that you mention below. Also agree in principle with Vishal's path computation hierarchy. When dealing with different granularity signal types, e.g., from 1 or 2Mbps MPLS LSPs all the way to lambda or waveband switched GMPLS LSPs different methods are generally called for. For example, a distributed PCS approach would initially be overkill, versus a centralized approach (not that many LSPs to get set up that often) while if one is dealing with lower rate MLPS LSPs a distributed PCS approach (hopefully) would be more appropriate. Just saw Alex's question on where the PCS work is... I went looking for drafts to see where this is at... Greg B. P.S. Yes, consulting has picked up... --- Adrian Farrel wrote: > All, > > JP and Arthi have done a fine job of pulling > together all of the threads of inter-area and > inter-AS solutions into a single draft. This gives > us a single place to look for > information, but the resulting draft is (of course) > quite large. As additional details > need to be filled in, it is clear that this draft > would only grow and that would make it > unusably large. > > So, we are proposing to use the material in the > draft to produce a series of detailed > drafts that would, over time, replace JP and Arthi's > document. > > 1. Framework for Interdomain MPLS and GMPLS > A short draft that introduces the routing and > signaling options > for multi-domain LSPs, and explains the options > for path > computation. > This does not describe applicability or any > necessary protocol > procedures or extensions. > Material will be taken from > draft-vasseur-ccamp-inter-area-as-te > and draft-kompella-mpls-multiarea-te as > required. > Authors: Adrian, JP, Arthi > Due date: End of April. > > 2. Individual signaling extension drafts > If any one of the signaling approaches described > in 1. > requires additional protocol procedures or > extensions > then a single draft will be written for each. > The base assumption is that such a draft will > only be > written if there someone planning to implement > and > deploy. > Authors: Dependent on extension > Due date: Aim for San Diego > > 3. Individual routing extension drafts > There are two dimensions to this: > - the different routing protocols (IGPs and > EGPs) > - the different solution models > The aim should be to have one draft per > protocol to provide the > generic mechanisms, and one draft per model per > protocol to > provide procedures and field values etc. > Note that path computation functions are > described under point > 5, below. > As with the signaling extensions, this work > will only be done once > we understand that there is a need *and* what > is needed. > Authors: Again dependent on deployment plans > Due date: Slightly later than signaling work > > 4. Applicability > A draft to explain when it is appropriate to use > which model and > options. The aim is not to rubbish the > opposition, but to say when > a particular model can/should be used. > Much of this material can already be found in > draft-vasseur-ccamp-inter-area-as-te, but it may > need > some tidying up. > For political/expediency reasons this may result > in multiple > applicability drafts in the first instance. > Authors: A supporter of each model > Due date: Quite soon - to accompany signaling > extensions. > > 5. Path computation > Some solution models call for a (or many) path > computation > servers (PCS). This demands several functions: > - discovery of PCS by network elements > - communication protocol between PCS and network > elements > - some regulation of computation technique to > avoid looping etc. > At the moment we are discussing precisely where > this work should > be done, but that should not stop us starting > the work within CCAMP > since it is clearly related to the inter-area/AS > solution. > > 6. Advanced functions. > There are several advanced functions that will > be required, but which > are not part of the immediate work. > - Path reoptimization > - Protection path diversity > - crankback > We expect that once the initial work has been > done on the solutions, it > will be possible to set out the requirements > for these functions and to > develop solutions based on the many drafts that > are already out there. > > Comments please. > > Thanks, > Adrian and Kireeti > > __________________________________ Do you Yahoo!? Yahoo! Photos: High-quality 4x6 digital prints for 25¢ http://photos.yahoo.com/ph/print_splash Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 19 Apr 2004 21:35:59 +0000 Date: Mon, 19 Apr 2004 14:33:01 -0700 From: Alex Zinin Reply-To: Alex Zinin Message-ID: <1683572413.20040419143301@psg.com> To: ccamp@ops.ietf.org Subject: On PCS-based traffic-engineering solutions MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Folks- I've been asked for a clarification on where the discussion and work on the PCS-based solutions (e.g. draft-vasseur-ccamp-inter-area-as-te-00.txt) belong. The reason for the question was the fact that PCS-based approach uses a paradigm that is rather different from the currently used one and requires a set of new mechanisms that CCAMP is not chartered to work on. After a consultation with the CCAMP WG chairs, my recommendation is as follows: 1. The PCS-based solutions should be included in the discussion on inter-area/AS traffic engineering in the CCAMP WG. The WG needs to select the best solution and ruling one of the possible approaches out at this time would be unfair. 2. A BOF on the PCS-based approach will be scheduled for the San Diego IETF meeting. The goal for the BOF meeting will be to gather wider community feedback on the approach and gauge the level of interest in it. Depending on the results of the discussion in CCAMP and the BOF, decisions will be made on: a) Whether the PCS-related work should be taken on in the IETF, and if so b) Where this work should be hosted (e.g., a separate WG, or in CCAMP) -- Alex IETF RTG Area co-Director Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 19 Apr 2004 19:09:57 +0000 Message-ID: <40842395.2DD1A674@alcatel.be> Date: Mon, 19 Apr 2004 21:08:05 +0200 From: stefaan.de_cnodder@alcatel.be MIME-Version: 1.0 To: v.sharma@ieee.org CC: ccamp@ops.ietf.org Subject: comments on ARO Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Hi Vishal, looking to draft-dachille, I have following comments: 1) Second paragraph in section 2 is not clear: "we will assume that every inter-area connection is duplicated". I understood from it that when the primary path follows Area1-Area2-Area3, then also the secondary has to follow this path but using other border nodes. But then from section 4.2 I understand that this is not an assumption? 2) step 2c on page 5: also E, G and H has to be pruned? It is also not clear which path is selected in area 3: I guess it is E-G-H for primary and F-H for secondary? 3) (!) page 7, about the trap-avoid reference: If fact it is just a matter of doing a good path calculation. If the primary is signaled and border nodes know that also a secondary has to be established, then it can make sure that the primary does not introduce such a trap. This assumes that the border node also has to know that a secondary has to be established. This is known by the presence of the ARO object but this does not mean that at the end, the ARO has to contain a full strict path of the secondary. Border nodes can expand the ARO by only including the border nodes for the secondary. This means that the path calculation of the secondary is not anymore 100% bound to the primary. Also I would prefer that the ARO is more like a "hint" than the real path. With this, you do not have to interaction problems with re-optimization of secondary, crankback, ... For instance: when the secondary fails, it can be re-established ignoring the ARO. Or when the secondary can be re-optimzed between border nodes, then it can be done without impacting the primary or when the global re-optimization is possible, then the ARO can be simple ignored. I prefer to have the ARO only recording border nodes, and optionally only acting as a hint for the ingress LSR. The latter is less important to me. 4) text below figure 3: primary has to be as short as possible. I do not care much about the secondary becuase it is almost never used. Also, the resources that it reserves can be shared with other secondaries. The problem here is: what are you optimizing? According to me the path of the primary has to be optimized. 5) I do not understand why the ARO has to contain Area-Ids to indicate the route. If the ingress can put the "area-path" in the ARO, then it can also put the border nodes in the ERO of the secondary immediately. I.e. refering to figure 5: A knows that the path of the secondary is A1-A2-A5-A6. How does A know this? And if it is possible to let A know this information, then why could it also not know that the path is B1-B7-B9. If A can do this, then there is no need anymore for ARO. So the basic question is: what makes it easier for A to know A1-A2-A5-A6 instead of B1-B7-B9. This means to me that section 4.2 is not valid and that the ARO assumes that the "area-path" of primary and secondary is the same, which is true for IGP areas. See also comment 2. Maybe better to remove the AREA-IDs from the ARO. 6) step 1d page 14, second last line: how does the ABR know that B7 has to be used and not B8? 7) section 4.3: also describe the L-bit that is in the ERO subobjects. 8) Is the Addr_len in for instance subobject 1 always 32 or can it be something else. I agree here that you should re-use ERO subobjects but I see that you are doing this. 9) Section 4.3.2.3, area_ID: types 3, 4 and 5 are defined but that conflicts with what is described in the middle of page 19 where the numbers are 32, 33, 34. 10) the text in section 4.3.3 is rather confusing (the part in the middle of page 22, about pruning the nodes). Take figure 5, area 5: If B6 has to calculate a path from B6 to B10, then this path can pass via B5, B8, B7 and/or B9. This is because border nodes can also act as core nodes at the same time. This seems to be excluded from the draft. Is that correct? 11) First refinement in section 5 about the cost of virtual links: this has been proposed before in http://www.watersprings.org/pub/id/draft-venkatachalam-interarea-mpls-te-02.txt which is not a good idea: it only works for inter-IGP area and it decreases the scalability although it also has some advantages. 12) (!) There are conflicts with re-optimization, crankback, re-establishement after failure of secondary LSP, ... because in all of these cases a working primary LSP also have to be re-signaled which is not good. Therefore it is better to let the ARO only record border nodes, and/or to use the ARO more as a hint for the secondary: using the ARO in the primary makes sure that a trap is avoided, and then it is up to the signaling of the secondary to find this path by using crankback, .... There is no need that the primary LSP also gives the path, it only has to make sure that there is a path. 13) (!) The method seems not to be applicable for inter-AS calculations. 14) Following the classification of methods (ARO, XRO, PCE) that you described earlier on ccamp based on parallel/sequential and distributed/centralized computation, ARO looks more an alternative for PCE than for XRO? In fact, would it be possible to combine methods? It would be good to explain the interaction (if any) with these other methods. Hope this helps, regards, Stefaan Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 19 Apr 2004 08:17:34 +0000 Message-ID: <40838AEE.9010704@coritel.it> Date: Mon, 19 Apr 2004 10:16:46 +0200 From: ricciato User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030821 MIME-Version: 1.0 To: ccamp , Adrian Farrel CC: Vishal Sharma , Marco Listanti Subject: About egress-influenced path computation in draft-dachille-inter-area-path-protection Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Dear ccmapers, Alan I'm giving my comment to one question raised at Seoul by Alan to Vishal regarding the joint-selection with ARO of diverse paths, i.e. the approach proposed in draft-dachille. It was mentioned in point (v) of last mail from Vishal. Consider a linear topology of ASs from AS(1) (the source AS) to AS(N) (the destination AS). Denote by I(k) and E(k), respectively, the ingress and egress nodes to AS(k). Where needed, I'll distinguish between the ingress of the primary and secondary path, respectively, by I1(k) and I2(k). Same for th egress nodes (i.e., E1(k), E2(k)). In the proposed approach, the selection process run as follows: a. I1(k) selects the path-pair inside AS(k), thus explicitely determining I2(k), E1(k) and E2(k). b. In the case that each single node E(k) has a single link to I(k+1), this means that I1(k) is implicitely determining I(k+1) too. Let's call this special case "1:1 border-nodes". I do not know if this is a common case in practice, or rather if each single border node is connected to >1 adjacent border nodes (anyone can comment on that ?) If I understood it correctly, the Adrian´s point was: would it be possible to modify the scheme such that the egress nodes can influence the selection of the ingress nodes, by expressing some "preference" within the set of possible ingress nodes ? This sounds quite contradictory to the original scheme. In fact this is based on the following sequence of selections: I(k)-->E(k)-->I(k+1)-->... , while Adrian's approach would add to that a E(k)-->I(k) dependance. One might think to a variation of the scheme in which the secondary path computation for AS(k), i.e. the ARO expansion, is run during the RESV phase. In this case, the selection sequence would be I1(k)-->E1(k)-->{I2(k),E2(k)}, in place of I1(k)-->{E1(k),I2(k),E2(k)} (see above point 'a') However, this approach would break the joint-selection concept that, we think, is a key point of our approach (see my previous mail to Dimitri). Another possibility would be to carry two AROs, instead of one, thus having two secondary paths from which the downstream nodes (E1(k) or I(k+1) can choose. However, the main drawback of this approach is that it is quite restrictive. Consider the case in which three paths are available that pair-wise disjoint, but not three-wise disjoint. In this case it is not possible to expand two AROs with complete disjointedness constraints and the procedure fails, while there are up to three possible disjoint pairs to select. Instead, if really one is willing to implement this capability (namely: "egress-driven selection"), several alternative solutions might be considered (e.g. partial "soft" cranckback, preliminary signaling, etc.) which however can not avoid some additional burden to the signaling procedure (at least, this is what I see now, but maybe I'm worng). On the other hand, I would ask Adrian why it would be convenient to have this "egress-driven selection". In my humber opinion a possible answer might be that the egress nodes E(k) have knowledge about the load of inter-AS links E(k)-I(k+1), so that they can optimize the path selection taking into account the load on these external links, in addition to the load of internal links to AS(k). If this is the case, my answer would be: why don't we let the ingress nodes I(k) be aware of the load state of downstream external links E(k)-I(k+1) ? In fact, this information is already available to E(k), then I see no problems in sharing it with I(k) nodes since both are in the same domain AS(k). This can be achieved quite easily. Consider the original scheme proposed in the draft xxx. The ERO and ARO expansion is done at I1(k). The computation, however, can be run on the I1(k) node itself, or in a centralized route server that border nodes can query. In both cases the computation relies on a topology/load database (that, in a fully distributed environment might be fed by OSPF-TE Opaque-LSAs). So, why not augmenting this database to include external links also ? In both cases (centralized server, or OSPF-TE flooding) this does *not* require any protocol modification. Note that both adjacent ASs will consider this information as "private", and will not export it to other ASs. In conclusion, with this approach the ingress node I(k) would have exactly the same view of egress nodes E(k), so there is no additional benefit in having "egress-driven selection". I would aks you to comment on that. In particular, I'd like to know if you are aware of any other reasons or potential benefits for "egress-driven selection" beside that considered here. In this case we could further think about how to develop it in the framework of the ARO scheme. Looking forwards to get more comments, best regards Fabio Ricciato Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 19 Apr 2004 08:04:22 +0000 Message-ID: <408387C8.1010108@coritel.it> Date: Mon, 19 Apr 2004 10:03:20 +0200 From: ricciato User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030821 MIME-Version: 1.0 To: Dimitri.Papadimitriou@alcatel.be, ccamp CC: LE ROUX Jean-Louis FTRD/DAC/LAN Subject: About optimality of inter-AS parallel computation in draft-dachille-inter-area-path-protection Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear ccampers, Dimitri, we were reported by Vishal several comments collected at Seoul regarding draft-dachille, proposing the parallel computation (or joint-computation) approach with ARO for diverse path-pair computation. After several internal discussions and thoughts, we are now going to react to these, as anticipated in the recent mail by Vishal. Among other comments there was one issued by Dimitri. If I correctly understood, his point was the following: the joint computation (with ARO) is guaranteed to *achieve* the global optimum only in the trivial case of a single AS, but not along a path with multiple AS. This is indeed due to the distributed nature of the route selection process, that can optimize local route segments, but can not generally achieve the *global* optimum (in fact, distributed optimization would need an iterative process to converge to global optimum, which is not the case here). Now, the Dimitri point was: why prefer the joint computation (with ARO) to sequential computation (with XRO), since neither of the two in general achieve the global optimum ? This is a good question and gives me the opportunity to make some more general considerations about the ARO approach scketched in the draft. 1. If you consider the classical problem (i.e., find two disjoint paths with the objective of minimizing some link metric) despite joint-computation does not reach the global optimum, it definitely improves the quality of the solution w.r.t. sequential-computation. The exact gain depends on the particular topology, and there are of course cases in which it can be zero (see note 1). 2. An additional benefit of joint- (or "parallel-") vs. sequential-computation is robusteness against trap-topologies (ref. to draft-dachille) 3. The joint-computation with ARO can be applied to a vast class of problems dealing with path-pair computation. I'm giving below some few examples. (I think this also adrresses some comment by Jean-Louis). In general, in each problem of path-pair computation one can distinguish the constraint(s) from the optimization objective: Case-I: find a pair of disjoint paths (i.e., disjointedness is a constraint) wich minimize some link metric (hop-length, link-load, etc.) Case-II: find a pair of maximally disjoint paths (disjointedness becomes an objective) Case-III: find a pair of disjoint paths P1 and P2 that minimizes the difference |d(P1)-d(P2)|, where d() is some metric associated to the path (e.g., delay....might make sense in optical networks ??). Case-IV: Assuming that for each link pair (i,j) it is possible to assign a "correlation" factor r(i,j) accounting for the probability of contemporary failures, find a pair of paths that minimizes the max{r(i,j)} over all pairs such that i is in P1 and j is in P2 [see note 2]. Maybe not all the above items are of practical interest in real applications, but the fact that our approach encompasses all of them proves the flexibility and usefulness of joint-computation with ARO. Several other problems can be found. In general, joint-selection with ARO can address to all problems presenting some *joint constraints* and/or *joint optimization objective* on the pair of paths. Needless to say, each such case requires ad-hoc route-selection _algorithms_ to be implemented in the ingress border nodes (or in a centralized server within each AS), but all can be accommodated with the signaling procedure based on ARO. Admittedly, the current draft version exclusively focused on case-I, and fails to make it clear that the set of possible applications is far broader. We will improve this point in the future version. Incidentally, I notice here that this is indeed the reason why we proposed the (quite neutral) term "Associated Route Object" instead of the more specific "Disjoint R.O." or "Backup R.O." etc.: we wanted to leave it open to a broad set of possible applications. Maybe it would make sense to add some additional semantic in the PATH messages that specify the contraint(s) and/or the objectives to which the primary (in the ERO) and secondary (in the ARO) paths should (jointly!) comform. This might be an associated sub-object of the ARO, perhaps ? Might be named "Route Pair Requirements" (RPR) ? In other words, the overall semantic in the PATH messages should sound like: "compute a primary route segment (in the ERO), and an associated secondary route segment (in the ARO), such that they are subject to the contraint(s) X and optimize objective Y (X,Y are contained somehow in the RPR)". The ERO+ARO+RPR scheme, in the framework of distributed *joint* route selection, would be really a quite flexible and general scheme. What do you think about that ? Looking forwards to get more comments, best regards Fabio Ricciato Note 1: Having available some guidelines about realistic inter- and intra-AS topologies, we would be available to run extensive simulations to assess this gain in realistic case. Is there anyone interested in this activity ? Note 2: In general 0<=r(i,j)<=1. This is a "fuzzy" extension of the SRLG concept. In fact, a SLRG can be defined as a set of links S having r(i,j)=1 for each i,j in S. Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 19 Apr 2004 07:05:35 +0000 Subject: draft-caviglia-mp2cp&cp2mp-00 Sensitivity: To: ccamp@ops.ietf.org Message-ID: From: "Diego Caviglia" Date: Mon, 19 Apr 2004 08:48:03 +0200 MIME-Version: 1.0 Content-type: text/plain; charset="us-ascii" Hi all, a new ID is available at the following address http://www.ietf.org/internet-drafts/draft-caviglia-mp2cp&cp2mp-00.txt. Here is the abstract: Abstract This memo introduces a new flag in the Administrative Status object, namely the Fake flag. This flag SHOULD be used in order to move under the Control Plane (CP) domain LSPs that were created by the Management Plane (MP), and vice versa. The result of the Fake flag in GRSVP-TE is twofold: at the end of the set-up signaling flow, an LSP that was created by Management Plane is moved under to Control Plane domain. Similarly, at the end of a deletion procedure the LSP that was under the Control Plane domain is moved under the Management Plane domain. Comments and suggestion are very appreciated. Regards, Diego ---------------------- Forwarded by Diego Caviglia/MAIN/MC1 on 04/19/2004 08:46 AM --------------------------- ietfauto@ietf.org (Internet Draft Submission Manager) on 04/15/2004 02:01:08 PM Please respond to dinaras@ietf.org To: Diego.Caviglia@marconi.com cc: Subject: Re: Submitting of ID draft-caviglia-mp2cp&cp2mp-00 Greetings: This message is being sent to acknowledge receipt of your Internet-Draft submission or message to internet-drafts@ietf.org. If you submitted an Internet-Draft, then it will be posted on the Internet-Drafts page of the IETF Web site, and an I-D Action message will be sent to the IETF Announcement List. Please note that all Internet-Drafts offered for publication as RFCs must conform to the requirements specified in ID Nits (http://www.ietf.org/ID-nits.html) or they will be returned to the author(s) for revision. Therefore, the IETF Secretariat strongly recommends that you address all of the issues raised in this document before submitting a request to publish your Internet-Draft to the IESG. The IETF Secretariat Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 19 Apr 2004 04:55:54 +0000 Reply-To: From: "Vishal Sharma" To: "Adrian Farrel" , Cc: "Arthi Ayyangar" , "Jean-Philippe Vasseur" , "Kireeti Kompella" Subject: RE: Proposed strategy for Inter-area/AS Date: Sun, 18 Apr 2004 21:53:34 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Adrian, Great, thanks for the clarifications. Since the framework takes its lead from the inter-area/AS requirements documents, I agree that it needn't say what a solution should provide (this should already be covered by the requirements docs.). For the diverse path computation aspect, please see my response to JP, where I've provided some elucidation. Personally, I think the PCS/PCE approach is a useful one, and should certainly be continued. And, I'll be glad to contribute, once the first version of the framework is done. -Vishal > -----Original Message----- > From: Adrian Farrel [mailto:adrian@olddog.co.uk] > Sent: Friday, April 16, 2004 12:57 PM > To: v.sharma@ieee.org; ccamp@ops.ietf.org > Cc: Arthi Ayyangar; Jean-Philippe Vasseur; Kireeti Kompella > Subject: Re: Proposed strategy for Inter-area/AS > > > Hi Vishal, > > Thanks for your useful comments. > > Yes, clearly we need to consider all requirements as we move > forward, but at the same time > looking for a single solution that does everything is often the > kiss of death in the IETF. > > So the first thing I want to do (in the framework) is set out the > different basic models > for signaling, routing and computation. Then there is a bit of a > hiatus while the > proponents of the different models work out what solutions they > need and what their > applicability is - at this stage I would expect (since diverse > paths are a requirement) > that you will find your self working with one or more of the > solution groups. Similarly, > the other drafts that provide extensions that may be useful will > also (or not) be called > on. > > One thing the framework does not do is list all of the available > bits and pieces. Nor does > it make any statements about what should or should not be done to > provide a solution. > > You may be right that adding a little more text on diverse > computation models will help > since this will impact the choice of basic model, but I don't > think it introduces any mode > basic models. > We will take you up on your offer of a contribution to the > document as soon as we have got > the first version done. > > On PCE... > We are open to discussions both about whether PCE should be done, > and how it should be > done. > > On TEWG requirements... > Obviously we take our base requirements from the TEWG documents. > > Hope this clarifies. > > Adrian > > ----- Original Message ----- > From: "Vishal Sharma" > To: "Adrian Farrel" ; ; > "Kireeti Kompella" > > Cc: "Arthi Ayyangar" ; "Jean-Philippe Vasseur" > > Sent: Friday, April 16, 2004 7:40 PM > Subject: RE: Proposed strategy for Inter-area/AS > > > > Hi Adrian and Kireeti, > > > > Thanks for outlining the strategy for this important work > > item, which I think is well-laid out. > > > > Since some of the functions (e.g. diverse path computation, crankback, > > etc.) are quite closely tied to the signaling and routing > extensions needed, > > I think they should not be decoupled from discussions of these > extensions. > > So the ordering below probably needs to be modified a bit to > reflect this > > coupling. > > > > Some further comments/questions and suggestions in-line. > > > > -Vishal > > > > > -----Original Message----- > > > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On > > > Behalf Of Adrian Farrel > > > Sent: Wednesday, April 14, 2004 4:50 AM > > > To: ccamp@ops.ietf.org > > > Subject: Proposed strategy for Inter-area/AS > > > > > > > > > All, > > > > > > JP and Arthi have done a fine job of pulling together all of the > > > threads of inter-area and > > > inter-AS solutions into a single draft. This gives us a single > > > place to look for > > > information, but the resulting draft is (of course) quite large. > > > As additional details > > > need to be filled in, it is clear that this draft would only grow > > > and that would make it > > > unusably large. > > > > > > So, we are proposing to use the material in the draft to produce > > > a series of detailed > > > drafts that would, over time, replace JP and Arthi's document. > > > > > > 1. Framework for Interdomain MPLS and GMPLS > > > A short draft that introduces the routing and signaling options > > > for multi-domain LSPs, and explains the options for path > > > computation. > > > This does not describe applicability or any necessary protocol > > > procedures or extensions. > > > Material will be taken from draft-vasseur-ccamp-inter-area-as-te > > > and draft-kompella-mpls-multiarea-te as required. > > > Authors: Adrian, JP, Arthi > > > Due date: End of April. > > > > As I mentioned at Seoul, I will be happy to help here. Particularly, > > with adding some material on options for diverse path computation. > > The current draft-vasseur-ccamp lists two options, but a hybrid > > that involves partial path computation in each domain (along the > > lines of what I presented at Seoul) is also possible, and can be a > > useful tradeoff for meeting several of the requirements listed > > in the corresponding requirements drafts. > > > > Also, I am assuming that the TE requirements documents will be > > the guiding documents in presenting options for routing/signaling > > and path computation in the above doc. I think it is important > > that the framework draft be in synch. with the requirements documents, > > rather than applying them only for 4 and 6. > > > > > 2. Individual signaling extension drafts > > > If any one of the signaling approaches described in 1. > > > requires additional protocol procedures or extensions > > > then a single draft will be written for each. > > > The base assumption is that such a draft will only be > > > written if there someone planning to implement and > > > deploy. > > > Authors: Dependent on extension > > > Due date: Aim for San Diego > > > > Please see initial note, about relation to other functions. > > > > > 3. Individual routing extension drafts > > > There are two dimensions to this: > > > - the different routing protocols (IGPs and EGPs) > > > - the different solution models > > > The aim should be to have one draft per protocol to provide the > > > generic mechanisms, and one draft per model per protocol to > > > provide procedures and field values etc. > > > Note that path computation functions are described under point > > > 5, below. > > > As with the signaling extensions, this work will only be > done once > > > we understand that there is a need *and* what is needed. > > > Authors: Again dependent on deployment plans > > > Due date: Slightly later than signaling work > > > > Please see initial note, about relation to other functions. > > > > Also, when you say "solution models" above, do you mean things > > like a centralized versus a distributed model? What other > > models did you have in mind? > > > > > 4. Applicability > > > A draft to explain when it is appropriate to use which model and > > > options. The aim is not to rubbish the opposition, but to say when > > > a particular model can/should be used. > > > Much of this material can already be found in > > > draft-vasseur-ccamp-inter-area-as-te, but it may need > > > some tidying up. > > > For political/expediency reasons this may result in multiple > > > applicability drafts in the first instance. > > > Authors: A supporter of each model > > > Due date: Quite soon - to accompany signaling extensions. > > > > > > 5. Path computation > > > Some solution models call for a (or many) path computation > > > servers (PCS). This demands several functions: > > > - discovery of PCS by network elements > > > - communication protocol between PCS and network elements > > > - some regulation of computation technique to avoid looping etc. > > > At the moment we are discussing precisely where this work should > > > be done, but that should not stop us starting the work > within CCAMP > > > since it is clearly related to the inter-area/AS solution. > > > > Is the discussion referred to above about where the PCS model should > > be done, or is it about path computation in general. > > > > Will the other path computation models will be discussed within > > CCAMP? > > > > > > > 6. Advanced functions. > > > There are several advanced functions that will be > required, but which > > > are not part of the immediate work. > > > - Path reoptimization > > > - Protection path diversity > > > - crankback > > > We expect that once the initial work has been done on the > > > solutions, it > > > will be possible to set out the requirements for these > > > functions and to > > > develop solutions based on the many drafts that are already > > > out there. > > > > As I said earlier, some of these functions are coupled to the > signaling and > > routing extensions, so it would be useful to discuss the signaling and > > routing extensions keeping some of these functions in mind. > > Otherwise, we run the risk of developing signaling and routing > extensions > > first, and then retro-fitting them to accommodate such functions, which > > I think are pretty key to inter-domain TE. > > > Envelope-to: ccamp-data@psg.com Delivery-date: Sun, 18 Apr 2004 07:28:15 +0000 Reply-To: From: "Vishal Sharma" To: "CCAMP" , "Arthi Ayyangar" Cc: "Fabio Ricciato" , "Ugo Monaco" , "Alessio D'Achille" , "Marco Listanti" Subject: draft-dachille: Comments on CAC issues Date: Sun, 18 Apr 2004 00:27:43 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi Arthi, Thanks for your feedback on our draft/scheme during the Seoul IETF. As mentioned in the email to the ML and to JL, before addressing people's comments, we are summarizing them ensure that (a) we rightly understood the comments, and (b) to help people on the ML follow and contribute to the subsequent discussions. Upon looking at my notes from our discussions, I see that your main comments related to aspects of CAC in our scheme, and have summarized them below. Please let me know if you had any additional comments as well. We will take these into account in providing our responses, and, later, in updating the document. Best regards, -Vishal **************************************************************** i) What happens to bandwidth accounting during path set up? Since the border router that is the entry point for the primary path into an area/AS is the one that also computes the secondary path, how does bandwidth accounting work to minimize CAC failures during the actual setting up of the secondary? (Note that other nodes in the area would not immediately learn of the amount of bandwidth that primary and secondary paths have consumed.) ii) What happens if the diverse path setup fails due to a CAC failure? (Namely, the set up of the second path fails.) To what does the scheme default then? iii) If I recall correctly, you also had a comment on the security of such schemes. That is, the problem of hiding info. about one area from other (remote) areas. Envelope-to: ccamp-data@psg.com Delivery-date: Sun, 18 Apr 2004 07:19:45 +0000 Reply-To: From: "Vishal Sharma" To: "CCAMP" Cc: "Jean-Louis Le Roux" , "Fabio Ricciato" , "Alessio D'Achille" , "Ugo Monaco" , "Marco Listanti" Subject: draft-dachille: Comments on topology summarization and optimality Date: Sun, 18 Apr 2004 00:16:42 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi JL, Thanks for your feedback on our draft/scheme during the Seoul IETF. As mentioned in an earlier email to the ML, before we address the various points made by folks who gave us their valuable feedback, we are summarizing their comments to ensure that (a) we rightly understood their inputs :-), and (b) to help people on the ML follow and contribute to the subsequent discussions. After reviewing my notes from our discussions and discussing them with my co-authors, I have summarized your comments as below. If I missed something or did not capture some of your questions/comments correctly, please do let us know. We will take this into account in providing our responses, and, later, in updating the document. Best regards, -Vishal ********************************************************************* Editorial: i) Replace "area" --> "region" throughout, since you cover ASs as well. ii) Note in the draft that the scheme is general and does more that merely helping with efficient backup path computation and setup. Technical: iii) The draft needs to make clear what is meant by a virtual topology, and what info. is used to create it. This is because it seems from a current reading of the draft that the virtual topology relies on info. about TE links and their bandwidth, but there is a strong requirement not to advertise TE link info. between areas. iv) How does this approach differ from the PCS/PCE approach? Some comparison and contrasting would be useful. v) You also suggested that one needn't be confined to carrying only one ARO. So for better optimality, one might carry multiple ARO's computed for the secondary path, and when the secondary is being set up, the ingress for the secondary could select one of the ARO segments for traversing it's area. This might lead to a more optimal setup than would otherwise be possible. vi) Sec. 4.1 on inter-area is ok. vii) However, for the section on inter-AS, you asked "how does the scheme computes the set of AS's that the diverse paths will use?" viii) Do you need the optical island ID? Even in the optical case, if one is using IP protocols, it is likely that OSFP/IS-IS areas/levels and ASs will be defined, so this then becomes the same as the inter-area/inter-AS cases. ix) Mention that the scheme can work for IS-IS levels as well. (Note IS-IS levels can, in turn, have areas.) (One issue here is how does one identify IS-IS levels?) Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 16 Apr 2004 23:08:48 +0000 Reply-To: From: "Vishal Sharma" To: "Jean-Philippe Vasseur" Cc: "Adrian Farrel" , "Arthi Ayyangar" , "Kireeti Kompella" , "CCAMP" Subject: RE: Proposed strategy for Inter-area/AS (corrected) Date: Fri, 16 Apr 2004 16:07:50 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi JP, Thanks much for your comments. Response in-line. (Please ignore the previous message, as the ASCII figure got distorted in that one.) > -----Original Message----- > From: Jean Philippe Vasseur [mailto:jvasseur@cisco.com] > Sent: Friday, April 16, 2004 2:58 PM > To: v.sharma@ieee.org > Cc: Adrian Farrel; ccamp@ops.ietf.org; Kireeti Kompella; Arthi Ayyangar > Subject: RE: Proposed strategy for Inter-area/AS > > > > > > > > 1. Framework for Interdomain MPLS and GMPLS > > > A short draft that introduces the routing and signaling options > > > for multi-domain LSPs, and explains the options for path > > > computation. > > > This does not describe applicability or any necessary protocol > > > procedures or extensions. > > > Material will be taken from draft-vasseur-ccamp-inter-area-as-te > > > and draft-kompella-mpls-multiarea-te as required. > > > Authors: Adrian, JP, Arthi > > > Due date: End of April. > > > >As I mentioned at Seoul, I will be happy to help here. Particularly, > >with adding some material on options for diverse path computation. > >The current draft-vasseur-ccamp lists two options, but a hybrid > >that involves partial path computation in each domain (along the > >lines of what I presented at Seoul) is also possible, and can be a > >useful tradeoff for meeting several of the requirements listed > >in the corresponding requirements drafts. > > > >Also, I am assuming that the TE requirements documents will be > >the guiding documents in presenting options for routing/signaling > >and path computation in the above doc. I think it is important > >that the framework draft be in synch. with the requirements documents, > >rather than applying them only for 4 and 6. > > Sure, > > But I guess that the solution that you propose to compute path > diversity is > one among others. Indeed, there are two path computation > solutions proposed > in draft-vasseur-ccamp-inter-area-as-te that both support path diversity > computation: > (1) Per-area/AS in combination with EXCLUDE-OBJECT > (2) Distributed PCE-based approach which compute end to end > shortest path that can also easily support diversity path computation with > a high granularity > > Whether a third method can of course be debated. Actually, the way I see it, there are I believe 4 basic ways to perform path (and diverse path) computation, which we can break down as follows. (Diverse) Path Computation Methods | | | +-----------------------------+ | | | | Centralized Distributed (Global) | | | +-----+------+ +---+--------------+ | | | | Parallel Sequential Parallel Sequential Joint path 1st path, 2nd path Per-domain 1st path, 2nd path computation ... path selection ... | | (semi-global) | | | | | | | | | Approaches | | | | ----------- -PCE-based -Head-end based | | ] or PCS-based -PCE-based -Using XRO ] ] -Head-end or -draft-dachille based ] server-based The various current approaches/solutions to perform path computation may be classified under one of the 4 heads, as I have done above. I called solution we proposed in draft-dachille (and that I presented in Seoul)a hybrid for computing diverse paths, because it can compute end-to-end diverse paths like in the PCE approach, with the simplicity of the per-domain approach,and essentially without any changes to the signaling protocols (save for an ERO-formatted ARO obj.), which is a requirement stated in the inter-area/AS TE requirements drafts. Thus, I believe this solution (not the specific realization presented in draft-dachille, but rather the basic idea) is worth mentioning in the interdomain TE framework document. Best, -Vishal Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 16 Apr 2004 22:56:42 +0000 Reply-To: From: "Vishal Sharma" To: "Jean Philippe Vasseur" Cc: "Adrian Farrel" , , "Kireeti Kompella" , "Arthi Ayyangar" Subject: RE: Proposed strategy for Inter-area/AS Date: Fri, 16 Apr 2004 15:55:29 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi JP, Thanks much for your comments. Response in-line. > -----Original Message----- > From: Jean Philippe Vasseur [mailto:jvasseur@cisco.com] > Sent: Friday, April 16, 2004 2:58 PM > To: v.sharma@ieee.org > Cc: Adrian Farrel; ccamp@ops.ietf.org; Kireeti Kompella; Arthi Ayyangar > Subject: RE: Proposed strategy for Inter-area/AS > > > > > > > > 1. Framework for Interdomain MPLS and GMPLS > > > A short draft that introduces the routing and signaling options > > > for multi-domain LSPs, and explains the options for path > > > computation. > > > This does not describe applicability or any necessary protocol > > > procedures or extensions. > > > Material will be taken from draft-vasseur-ccamp-inter-area-as-te > > > and draft-kompella-mpls-multiarea-te as required. > > > Authors: Adrian, JP, Arthi > > > Due date: End of April. > > > >As I mentioned at Seoul, I will be happy to help here. Particularly, > >with adding some material on options for diverse path computation. > >The current draft-vasseur-ccamp lists two options, but a hybrid > >that involves partial path computation in each domain (along the > >lines of what I presented at Seoul) is also possible, and can be a > >useful tradeoff for meeting several of the requirements listed > >in the corresponding requirements drafts. > > > >Also, I am assuming that the TE requirements documents will be > >the guiding documents in presenting options for routing/signaling > >and path computation in the above doc. I think it is important > >that the framework draft be in synch. with the requirements documents, > >rather than applying them only for 4 and 6. > > Sure, > > But I guess that the solution that you propose to compute path > diversity is > one among others. Indeed, there are two path computation > solutions proposed > in draft-vasseur-ccamp-inter-area-as-te that both support path diversity > computation: > (1) Per-area/AS in combination with EXCLUDE-OBJECT > (2) Distributed PCE-based approach which compute end to end > shortest path that can also easily support diversity path computation with > a high granularity > > Whether a third method can of course be debated. Actually, the way I see it, there are I believe 4 basic ways to perform path (and diverse path) computation, which we can break down as follows. (Diverse) Path Computation Methods | | | +-----------------------------+ | | | | Centralized Distributed (Global) | | | +-----+------+ +---+--------------+ | | | | Parallel Sequential Parallel Sequential Joint path 1st path, 2nd path Per-domain 1st path, 2nd path computation ... path selection ... (semi-global) -PCE-based -Head-end based ] or PCS-based -PCE-based -Using XRO ] Approaches ] -Head-end or -draft-dachille based ] server-based The various current approaches/solutions to perform path computation may be classified under one of the 4 heads, as I have done above. I called solution we proposed in draft-dachille (and that I presented in Seoul) a hybrid for computing diverse paths, because it can compute end-to-end diverse paths like in the PCE approach, with the simplicity of the per-domain approach, and essentially without any changes to the signaling protocols (save for an ERO-formatted ARO obj.), which is a requirement stated in the inter-area/AS TE requirements drafts. Thus, I believe this solution (not the specific realization presented in draft-dachille, but rather the basic idea) is worth mentioning in the interdomain TE framework document. Best, -Vishal Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 16 Apr 2004 21:58:35 +0000 Message-Id: <4.3.2.7.2.20040416174900.06190ec8@wells.cisco.com> Date: Fri, 16 Apr 2004 17:57:35 -0400 To: From: Jean Philippe Vasseur Subject: RE: Proposed strategy for Inter-area/AS Cc: "Adrian Farrel" , , "Kireeti Kompella" , "Arthi Ayyangar" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Hi Vishal, At 11:40 AM 4/16/2004 -0700, Vishal Sharma wrote: >Hi Adrian and Kireeti, > >Thanks for outlining the strategy for this important work >item, which I think is well-laid out. > >Since some of the functions (e.g. diverse path computation, crankback, >etc.) are quite closely tied to the signaling and routing extensions needed, >I think they should not be decoupled from discussions of these extensions. Sure, path diversity is a requirement listed in the requirement draft >So the ordering below probably needs to be modified a bit to reflect this >coupling. > >Some further comments/questions and suggestions in-line. > >-Vishal > > > -----Original Message----- > > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On > > Behalf Of Adrian Farrel > > Sent: Wednesday, April 14, 2004 4:50 AM > > To: ccamp@ops.ietf.org > > Subject: Proposed strategy for Inter-area/AS > > > > > > All, > > > > JP and Arthi have done a fine job of pulling together all of the > > threads of inter-area and > > inter-AS solutions into a single draft. This gives us a single > > place to look for > > information, but the resulting draft is (of course) quite large. > > As additional details > > need to be filled in, it is clear that this draft would only grow > > and that would make it > > unusably large. > > > > So, we are proposing to use the material in the draft to produce > > a series of detailed > > drafts that would, over time, replace JP and Arthi's document. > > > > 1. Framework for Interdomain MPLS and GMPLS > > A short draft that introduces the routing and signaling options > > for multi-domain LSPs, and explains the options for path > > computation. > > This does not describe applicability or any necessary protocol > > procedures or extensions. > > Material will be taken from draft-vasseur-ccamp-inter-area-as-te > > and draft-kompella-mpls-multiarea-te as required. > > Authors: Adrian, JP, Arthi > > Due date: End of April. > >As I mentioned at Seoul, I will be happy to help here. Particularly, >with adding some material on options for diverse path computation. >The current draft-vasseur-ccamp lists two options, but a hybrid >that involves partial path computation in each domain (along the >lines of what I presented at Seoul) is also possible, and can be a >useful tradeoff for meeting several of the requirements listed >in the corresponding requirements drafts. > >Also, I am assuming that the TE requirements documents will be >the guiding documents in presenting options for routing/signaling >and path computation in the above doc. I think it is important >that the framework draft be in synch. with the requirements documents, >rather than applying them only for 4 and 6. Sure, But I guess that the solution that you propose to compute path diversity is one among others. Indeed, there are two path computation solutions proposed in draft-vasseur-ccamp-inter-area-as-te that both support path diversity computation: (1) Per-area/AS in combination with EXCLUDE-OBJECT (2) Distributed PCE-based approach which compute end to end shortest path that can also easily support diversity path computation with a high granularity Whether a third method can of course be debated. Cheers JP. > > 2. Individual signaling extension drafts > > If any one of the signaling approaches described in 1. > > requires additional protocol procedures or extensions > > then a single draft will be written for each. > > The base assumption is that such a draft will only be > > written if there someone planning to implement and > > deploy. > > Authors: Dependent on extension > > Due date: Aim for San Diego > >Please see initial note, about relation to other functions. > > 3. Individual routing extension drafts > > There are two dimensions to this: > > - the different routing protocols (IGPs and EGPs) > > - the different solution models > > The aim should be to have one draft per protocol to provide the > > generic mechanisms, and one draft per model per protocol to > > provide procedures and field values etc. > > Note that path computation functions are described under point > > 5, below. > > As with the signaling extensions, this work will only be done once > > we understand that there is a need *and* what is needed. > > Authors: Again dependent on deployment plans > > Due date: Slightly later than signaling work > >Please see initial note, about relation to other functions. > >Also, when you say "solution models" above, do you mean things >like a centralized versus a distributed model? What other >models did you have in mind? > > > 4. Applicability > > A draft to explain when it is appropriate to use which model and > > options. The aim is not to rubbish the opposition, but to say when > > a particular model can/should be used. > > Much of this material can already be found in > > draft-vasseur-ccamp-inter-area-as-te, but it may need > > some tidying up. > > For political/expediency reasons this may result in multiple > > applicability drafts in the first instance. > > Authors: A supporter of each model > > Due date: Quite soon - to accompany signaling extensions. > > > > 5. Path computation > > Some solution models call for a (or many) path computation > > servers (PCS). This demands several functions: > > - discovery of PCS by network elements > > - communication protocol between PCS and network elements > > - some regulation of computation technique to avoid looping etc. > > At the moment we are discussing precisely where this work should > > be done, but that should not stop us starting the work within CCAMP > > since it is clearly related to the inter-area/AS solution. > >Is the discussion referred to above about where the PCS model should >be done, or is it about path computation in general. > >Will the other path computation models will be discussed within >CCAMP? > > > > 6. Advanced functions. > > There are several advanced functions that will be required, but which > > are not part of the immediate work. > > - Path reoptimization > > - Protection path diversity > > - crankback > > We expect that once the initial work has been done on the > > solutions, it > > will be possible to set out the requirements for these > > functions and to > > develop solutions based on the many drafts that are already > > out there. > >As I said earlier, some of these functions are coupled to the signaling and >routing extensions, so it would be useful to discuss the signaling and >routing extensions keeping some of these functions in mind. >Otherwise, we run the risk of developing signaling and routing extensions >first, and then retro-fitting them to accommodate such functions, which >I think are pretty key to inter-domain TE. Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 16 Apr 2004 20:35:19 +0000 Reply-To: From: "Vishal Sharma" To: "CCAMP" Cc: "Richard Rabbat" , "Toshio Soumiya" , "Shinoya Kanoh" , "Fabio Ricciato" , "Roberto Albanese" , Subject: Status of "Implementation and Perf. of Flooding-based Fault Notification" Date: Fri, 16 Apr 2004 13:34:40 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Dear CCAMPers, This draft was prepared following extensive discussions with several people during the Minneapolis IETF, as a way to share some of our implementation experience with the community. Unfortunately, this was one of the many "missing drafts" just before Seoul, and was posted by the IETF Secretariat at the end of February, so we did not have an opportunity to discuss this during the CCAMP WG meeting. http://www.ietf.org/internet-drafts/draft-rabbat-ccamp-perf-flooding-notific ation-exp-00.txt So, we would like to solicit feedback and inputs now. Basically, the draft highlights the results from deploying flooding-based notification in two independent testbeds, at the transport and packet layers. We have made the draft complete and self-contained, by having it present not only the experiences and actual performance measurements from these implementations on FreeBSD/Linux platforms, but also the protocol enhancements, object formats, etc. that were made to LMP and OSPF, respectively, to realize the rapid flooding function. In this way, we believe the observations, results, and formats in the draft serve as a very useful repository of information related to restoration techniques/issues. Our objective is to progress this as an experimental document, to make the experiences & results from these testbeds available to the IETF/CCAMP community. Comments/inputs very welcome! Thanks, -Vishal Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 16 Apr 2004 20:10:04 +0000 Message-ID: <018801c423ee$92dca9a0$83919ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: , Cc: "Arthi Ayyangar" , "Jean-Philippe Vasseur" , "Kireeti Kompella" Subject: Re: Proposed strategy for Inter-area/AS Date: Fri, 16 Apr 2004 20:56:48 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi Vishal, Thanks for your useful comments. Yes, clearly we need to consider all requirements as we move forward, but at the same time looking for a single solution that does everything is often the kiss of death in the IETF. So the first thing I want to do (in the framework) is set out the different basic models for signaling, routing and computation. Then there is a bit of a hiatus while the proponents of the different models work out what solutions they need and what their applicability is - at this stage I would expect (since diverse paths are a requirement) that you will find your self working with one or more of the solution groups. Similarly, the other drafts that provide extensions that may be useful will also (or not) be called on. One thing the framework does not do is list all of the available bits and pieces. Nor does it make any statements about what should or should not be done to provide a solution. You may be right that adding a little more text on diverse computation models will help since this will impact the choice of basic model, but I don't think it introduces any mode basic models. We will take you up on your offer of a contribution to the document as soon as we have got the first version done. On PCE... We are open to discussions both about whether PCE should be done, and how it should be done. On TEWG requirements... Obviously we take our base requirements from the TEWG documents. Hope this clarifies. Adrian ----- Original Message ----- From: "Vishal Sharma" To: "Adrian Farrel" ; ; "Kireeti Kompella" Cc: "Arthi Ayyangar" ; "Jean-Philippe Vasseur" Sent: Friday, April 16, 2004 7:40 PM Subject: RE: Proposed strategy for Inter-area/AS > Hi Adrian and Kireeti, > > Thanks for outlining the strategy for this important work > item, which I think is well-laid out. > > Since some of the functions (e.g. diverse path computation, crankback, > etc.) are quite closely tied to the signaling and routing extensions needed, > I think they should not be decoupled from discussions of these extensions. > So the ordering below probably needs to be modified a bit to reflect this > coupling. > > Some further comments/questions and suggestions in-line. > > -Vishal > > > -----Original Message----- > > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On > > Behalf Of Adrian Farrel > > Sent: Wednesday, April 14, 2004 4:50 AM > > To: ccamp@ops.ietf.org > > Subject: Proposed strategy for Inter-area/AS > > > > > > All, > > > > JP and Arthi have done a fine job of pulling together all of the > > threads of inter-area and > > inter-AS solutions into a single draft. This gives us a single > > place to look for > > information, but the resulting draft is (of course) quite large. > > As additional details > > need to be filled in, it is clear that this draft would only grow > > and that would make it > > unusably large. > > > > So, we are proposing to use the material in the draft to produce > > a series of detailed > > drafts that would, over time, replace JP and Arthi's document. > > > > 1. Framework for Interdomain MPLS and GMPLS > > A short draft that introduces the routing and signaling options > > for multi-domain LSPs, and explains the options for path > > computation. > > This does not describe applicability or any necessary protocol > > procedures or extensions. > > Material will be taken from draft-vasseur-ccamp-inter-area-as-te > > and draft-kompella-mpls-multiarea-te as required. > > Authors: Adrian, JP, Arthi > > Due date: End of April. > > As I mentioned at Seoul, I will be happy to help here. Particularly, > with adding some material on options for diverse path computation. > The current draft-vasseur-ccamp lists two options, but a hybrid > that involves partial path computation in each domain (along the > lines of what I presented at Seoul) is also possible, and can be a > useful tradeoff for meeting several of the requirements listed > in the corresponding requirements drafts. > > Also, I am assuming that the TE requirements documents will be > the guiding documents in presenting options for routing/signaling > and path computation in the above doc. I think it is important > that the framework draft be in synch. with the requirements documents, > rather than applying them only for 4 and 6. > > > 2. Individual signaling extension drafts > > If any one of the signaling approaches described in 1. > > requires additional protocol procedures or extensions > > then a single draft will be written for each. > > The base assumption is that such a draft will only be > > written if there someone planning to implement and > > deploy. > > Authors: Dependent on extension > > Due date: Aim for San Diego > > Please see initial note, about relation to other functions. > > > 3. Individual routing extension drafts > > There are two dimensions to this: > > - the different routing protocols (IGPs and EGPs) > > - the different solution models > > The aim should be to have one draft per protocol to provide the > > generic mechanisms, and one draft per model per protocol to > > provide procedures and field values etc. > > Note that path computation functions are described under point > > 5, below. > > As with the signaling extensions, this work will only be done once > > we understand that there is a need *and* what is needed. > > Authors: Again dependent on deployment plans > > Due date: Slightly later than signaling work > > Please see initial note, about relation to other functions. > > Also, when you say "solution models" above, do you mean things > like a centralized versus a distributed model? What other > models did you have in mind? > > > 4. Applicability > > A draft to explain when it is appropriate to use which model and > > options. The aim is not to rubbish the opposition, but to say when > > a particular model can/should be used. > > Much of this material can already be found in > > draft-vasseur-ccamp-inter-area-as-te, but it may need > > some tidying up. > > For political/expediency reasons this may result in multiple > > applicability drafts in the first instance. > > Authors: A supporter of each model > > Due date: Quite soon - to accompany signaling extensions. > > > > 5. Path computation > > Some solution models call for a (or many) path computation > > servers (PCS). This demands several functions: > > - discovery of PCS by network elements > > - communication protocol between PCS and network elements > > - some regulation of computation technique to avoid looping etc. > > At the moment we are discussing precisely where this work should > > be done, but that should not stop us starting the work within CCAMP > > since it is clearly related to the inter-area/AS solution. > > Is the discussion referred to above about where the PCS model should > be done, or is it about path computation in general. > > Will the other path computation models will be discussed within > CCAMP? > > > > 6. Advanced functions. > > There are several advanced functions that will be required, but which > > are not part of the immediate work. > > - Path reoptimization > > - Protection path diversity > > - crankback > > We expect that once the initial work has been done on the > > solutions, it > > will be possible to set out the requirements for these > > functions and to > > develop solutions based on the many drafts that are already > > out there. > > As I said earlier, some of these functions are coupled to the signaling and > routing extensions, so it would be useful to discuss the signaling and > routing extensions keeping some of these functions in mind. > Otherwise, we run the risk of developing signaling and routing extensions > first, and then retro-fitting them to accommodate such functions, which > I think are pretty key to inter-domain TE. Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 16 Apr 2004 18:41:35 +0000 Reply-To: From: "Vishal Sharma" To: "Adrian Farrel" , , "Kireeti Kompella" Cc: "Arthi Ayyangar" , "Jean-Philippe Vasseur" Subject: RE: Proposed strategy for Inter-area/AS Date: Fri, 16 Apr 2004 11:40:12 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi Adrian and Kireeti, Thanks for outlining the strategy for this important work item, which I think is well-laid out. Since some of the functions (e.g. diverse path computation, crankback, etc.) are quite closely tied to the signaling and routing extensions needed, I think they should not be decoupled from discussions of these extensions. So the ordering below probably needs to be modified a bit to reflect this coupling. Some further comments/questions and suggestions in-line. -Vishal > -----Original Message----- > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On > Behalf Of Adrian Farrel > Sent: Wednesday, April 14, 2004 4:50 AM > To: ccamp@ops.ietf.org > Subject: Proposed strategy for Inter-area/AS > > > All, > > JP and Arthi have done a fine job of pulling together all of the > threads of inter-area and > inter-AS solutions into a single draft. This gives us a single > place to look for > information, but the resulting draft is (of course) quite large. > As additional details > need to be filled in, it is clear that this draft would only grow > and that would make it > unusably large. > > So, we are proposing to use the material in the draft to produce > a series of detailed > drafts that would, over time, replace JP and Arthi's document. > > 1. Framework for Interdomain MPLS and GMPLS > A short draft that introduces the routing and signaling options > for multi-domain LSPs, and explains the options for path > computation. > This does not describe applicability or any necessary protocol > procedures or extensions. > Material will be taken from draft-vasseur-ccamp-inter-area-as-te > and draft-kompella-mpls-multiarea-te as required. > Authors: Adrian, JP, Arthi > Due date: End of April. As I mentioned at Seoul, I will be happy to help here. Particularly, with adding some material on options for diverse path computation. The current draft-vasseur-ccamp lists two options, but a hybrid that involves partial path computation in each domain (along the lines of what I presented at Seoul) is also possible, and can be a useful tradeoff for meeting several of the requirements listed in the corresponding requirements drafts. Also, I am assuming that the TE requirements documents will be the guiding documents in presenting options for routing/signaling and path computation in the above doc. I think it is important that the framework draft be in synch. with the requirements documents, rather than applying them only for 4 and 6. > 2. Individual signaling extension drafts > If any one of the signaling approaches described in 1. > requires additional protocol procedures or extensions > then a single draft will be written for each. > The base assumption is that such a draft will only be > written if there someone planning to implement and > deploy. > Authors: Dependent on extension > Due date: Aim for San Diego Please see initial note, about relation to other functions. > 3. Individual routing extension drafts > There are two dimensions to this: > - the different routing protocols (IGPs and EGPs) > - the different solution models > The aim should be to have one draft per protocol to provide the > generic mechanisms, and one draft per model per protocol to > provide procedures and field values etc. > Note that path computation functions are described under point > 5, below. > As with the signaling extensions, this work will only be done once > we understand that there is a need *and* what is needed. > Authors: Again dependent on deployment plans > Due date: Slightly later than signaling work Please see initial note, about relation to other functions. Also, when you say "solution models" above, do you mean things like a centralized versus a distributed model? What other models did you have in mind? > 4. Applicability > A draft to explain when it is appropriate to use which model and > options. The aim is not to rubbish the opposition, but to say when > a particular model can/should be used. > Much of this material can already be found in > draft-vasseur-ccamp-inter-area-as-te, but it may need > some tidying up. > For political/expediency reasons this may result in multiple > applicability drafts in the first instance. > Authors: A supporter of each model > Due date: Quite soon - to accompany signaling extensions. > > 5. Path computation > Some solution models call for a (or many) path computation > servers (PCS). This demands several functions: > - discovery of PCS by network elements > - communication protocol between PCS and network elements > - some regulation of computation technique to avoid looping etc. > At the moment we are discussing precisely where this work should > be done, but that should not stop us starting the work within CCAMP > since it is clearly related to the inter-area/AS solution. Is the discussion referred to above about where the PCS model should be done, or is it about path computation in general. Will the other path computation models will be discussed within CCAMP? > 6. Advanced functions. > There are several advanced functions that will be required, but which > are not part of the immediate work. > - Path reoptimization > - Protection path diversity > - crankback > We expect that once the initial work has been done on the > solutions, it > will be possible to set out the requirements for these > functions and to > develop solutions based on the many drafts that are already > out there. As I said earlier, some of these functions are coupled to the signaling and routing extensions, so it would be useful to discuss the signaling and routing extensions keeping some of these functions in mind. Otherwise, we run the risk of developing signaling and routing extensions first, and then retro-fitting them to accommodate such functions, which I think are pretty key to inter-domain TE. Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 16 Apr 2004 17:23:35 +0000 Reply-To: From: "Vishal Sharma" To: "CCAMP" Cc: "Fabio Ricciato" , "Alessio D'Achille" , "Ugo Monaco" Subject: Feedback on draft-dachille-inter-area-path-protection-01.txt Date: Fri, 16 Apr 2004 10:21:56 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Folks, During the Seoul meeting, we received a lot of useful feedback and inputs on our draft that we have now had time to consolidate and discuss amongst ourselves. Thanks to Jean-Louis, Aarthi, Adrian, Stefaan, JP, Zafar, Dmitri, and Richard for their excellent inputs. To have a fruitful discussion of the comments, we will soon send a summary of the comments on the ML, to help confirm that we captured everyone's comments accurately, and to help the WG at large appreciate the subsequent discussions (and contribute to it!). Comments from others who have feedback are welcome, and much appreciated. Thanks, -Vishal Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 15 Apr 2004 19:29:09 +0000 Message-ID: <407EE27A.6010000@alcatel.be> Date: Thu, 15 Apr 2004 21:28:58 +0200 From: Dimitri.Papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.5) Gecko/20030925 MIME-Version: 1.0 To: Adrian Farrel CC: ccamp@ops.ietf.org Subject: Re: Proposed strategy for Inter-area/AS Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed hi adrian, some comments in-line: Adrian Farrel wrote: > All, > > JP and Arthi have done a fine job of pulling together all of the threads of inter-area and > inter-AS solutions into a single draft. This gives us a single place to look for > information, but the resulting draft is (of course) quite large. As additional details > need to be filled in, it is clear that this draft would only grow and that would make it > unusably large. > > So, we are proposing to use the material in the draft to produce a series of detailed > drafts that would, over time, replace JP and Arthi's document. > > 1. Framework for Interdomain MPLS and GMPLS > A short draft that introduces the routing and signaling options > for multi-domain LSPs, and explains the options for path > computation. > This does not describe applicability or any necessary protocol > procedures or extensions. > Material will be taken from draft-vasseur-ccamp-inter-area-as-te > and draft-kompella-mpls-multiarea-te as required. > Authors: Adrian, JP, Arthi > Due date: End of April. is there an intention to take the tewg requirement documents into account at some in time within the first step of the process ? or are these documents their to assess solutions at the end of the process (at step 4, and further, in particular 6) > 2. Individual signaling extension drafts > If any one of the signaling approaches described in 1. > requires additional protocol procedures or extensions > then a single draft will be written for each. > The base assumption is that such a draft will only be > written if there someone planning to implement and > deploy. can we make clear that mechanisms are expected to differentiate inter-area vs inter-as only as part of point 4 (applicability) ie it is part of the task to provide generic signaling protocol extensions & procedures - as far as i see some of them will be part of the last step - > Authors: Dependent on extension > Due date: Aim for San Diego > > 3. Individual routing extension drafts > There are two dimensions to this: > - the different routing protocols (IGPs and EGPs) > - the different solution models > The aim should be to have one draft per protocol to provide the > generic mechanisms, and one draft per model per protocol to > provide procedures and field values etc. do you mean one generic document (per solution model) and one document per protocol or something else ? > Note that path computation functions are described under point > 5, below. > As with the signaling extensions, this work will only be done once > we understand that there is a need *and* what is needed. > Authors: Again dependent on deployment plans > Due date: Slightly later than signaling work > > 4. Applicability > A draft to explain when it is appropriate to use which model and > options. The aim is not to rubbish the opposition, but to say when > a particular model can/should be used. > Much of this material can already be found in > draft-vasseur-ccamp-inter-area-as-te, but it may need > some tidying up. > For political/expediency reasons this may result in multiple > applicability drafts in the first instance. > Authors: A supporter of each model > Due date: Quite soon - to accompany signaling extensions. if these reasons are verified, imho this should be part of each specific solution model/option document (if included into an appropriate section(s)), in order to avoid duplicating the number of documents that at the end should be put together in a single document that would include applicability of signaling (routing if any) procedure/ extensions and this due to the interaction aspects > 5. Path computation > Some solution models call for a (or many) path computation > servers (PCS). This demands several functions: > - discovery of PCS by network elements > - communication protocol between PCS and network elements > - some regulation of computation technique to avoid looping etc. > At the moment we are discussing precisely where this work should > be done, but that should not stop us starting the work within CCAMP > since it is clearly related to the inter-area/AS solution. and communication between PCSs once you have more than one PCS (~ sc.2 & and sc.4 of draft-kompella) > 6. Advanced functions. > There are several advanced functions that will be required, but which > are not part of the immediate work. > - Path reoptimization > - Protection path diversity > - crankback > We expect that once the initial work has been done on the solutions, it > will be possible to set out the requirements for these functions and to > develop solutions based on the many drafts that are already out there. i see that you didn't include any specific timeframe for this one (probably wiser) but would it be possible to have a rough estimation when you think these could be considered (as crankback started since quite a few months as w-g item) thanks, - dimitri. > Comments please. > > Thanks, > Adrian and Kireeti > > -- Papadimitriou Dimitri E-mail : dimitri.papadimitriou@alcatel.be E-mail : dpapadimitriou@psg.com Webpage: http://psg.com/~dpapadimitriou/ Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium Phone : +32 3 240-8491 Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 14 Apr 2004 23:47:35 +0000 Date: Wed, 14 Apr 2004 16:46:23 -0700 (PDT) From: Kireeti Kompella To: ccamp@ops.ietf.org Subject: Re: FW: I-D ACTION:draft-ietf-ccamp-gmpls-ason-routing-reqts-03.txt Message-ID: <20040414163803.G35765@kummer.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi All, On Wed, 14 Apr 2004, Brungard, Deborah A, ALABS wrote: > The ASON Routing Reqts DT has updated the following draft based on > ITU Q14/15's Liaison and CCAMP mail list comments. > > We recommend this document as ready for WG Last Call. This commences a two-week WG Last Call on the GMPLS ASON routing requirements. Last Call ends April 28th, 5pm PDT. Please send your comments to the list. The proposed category is Informational. Kireeti. ------- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 14 Apr 2004 18:03:11 +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: FW: I-D ACTION:draft-ietf-ccamp-gmpls-ason-routing-reqts-03.txt Date: Wed, 14 Apr 2004 13:01:35 -0500 Message-ID: <449B2580D802A443A923DABF3EAB82AF0572A347@OCCLUST04EVS1.ugd.att.com> Thread-Topic: I-D ACTION:draft-ietf-ccamp-gmpls-ason-routing-reqts-03.txt Thread-Index: AcQgvqvLuB0OdcS7SOiZ0/y9Z/sJ/ABiV6qw From: "Brungard, Deborah A, ALABS" To: CCAMP, The ASON Routing Reqts DT has updated the following draft based on ITU = Q14/15's Liaison and CCAMP mail list comments. We recommend this document as ready for WG Last Call. Thanks, Deborah -----Original Message----- From: i-d-announce-admin@ietf.org [mailto:i-d-announce-admin@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Monday, April 12, 2004 2:45 PM To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org Subject: I-D ACTION:draft-ietf-ccamp-gmpls-ason-routing-reqts-03.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 : Requirements for Generalized MPLS (GMPLS) Routing for = Automatically Switched Optical Network (ASON) Author(s) : W. Alanqar, et al Filename : draft-ietf-ccamp-gmpls-ason-routing-reqts-03.txt Pages : 19 Date : 2004-4-9 =09 The Generalized MPLS (GMPLS) suite of protocols has been defined to control different switching technologies as well as different applications. These include support for requesting TDM connections including SONET/SDH and Optical Transport Networks (OTNs). This document concentrates on the routing requirements on the GMPLS suite of protocols to support the capabilities and functionalities for an Automatically Switched Optical Network (ASON) as defined by ITU-T. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-ason-routing-r= eqts-03.txt To remove yourself from the I-D Announcement list, send a message to=20 i-d-announce-request@ietf.org with the word unsubscribe in the body of = the message. =20 You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce=20 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-ason-routing-reqts-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html=20 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-ason-routing-reqts-03.txt". =09 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. =09 =09 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, 14 Apr 2004 11:55:46 +0000 Message-ID: <02a601c42217$0b13dda0$60849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Proposed strategy for Inter-area/AS Date: Wed, 14 Apr 2004 12:49:56 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit All, JP and Arthi have done a fine job of pulling together all of the threads of inter-area and inter-AS solutions into a single draft. This gives us a single place to look for information, but the resulting draft is (of course) quite large. As additional details need to be filled in, it is clear that this draft would only grow and that would make it unusably large. So, we are proposing to use the material in the draft to produce a series of detailed drafts that would, over time, replace JP and Arthi's document. 1. Framework for Interdomain MPLS and GMPLS A short draft that introduces the routing and signaling options for multi-domain LSPs, and explains the options for path computation. This does not describe applicability or any necessary protocol procedures or extensions. Material will be taken from draft-vasseur-ccamp-inter-area-as-te and draft-kompella-mpls-multiarea-te as required. Authors: Adrian, JP, Arthi Due date: End of April. 2. Individual signaling extension drafts If any one of the signaling approaches described in 1. requires additional protocol procedures or extensions then a single draft will be written for each. The base assumption is that such a draft will only be written if there someone planning to implement and deploy. Authors: Dependent on extension Due date: Aim for San Diego 3. Individual routing extension drafts There are two dimensions to this: - the different routing protocols (IGPs and EGPs) - the different solution models The aim should be to have one draft per protocol to provide the generic mechanisms, and one draft per model per protocol to provide procedures and field values etc. Note that path computation functions are described under point 5, below. As with the signaling extensions, this work will only be done once we understand that there is a need *and* what is needed. Authors: Again dependent on deployment plans Due date: Slightly later than signaling work 4. Applicability A draft to explain when it is appropriate to use which model and options. The aim is not to rubbish the opposition, but to say when a particular model can/should be used. Much of this material can already be found in draft-vasseur-ccamp-inter-area-as-te, but it may need some tidying up. For political/expediency reasons this may result in multiple applicability drafts in the first instance. Authors: A supporter of each model Due date: Quite soon - to accompany signaling extensions. 5. Path computation Some solution models call for a (or many) path computation servers (PCS). This demands several functions: - discovery of PCS by network elements - communication protocol between PCS and network elements - some regulation of computation technique to avoid looping etc. At the moment we are discussing precisely where this work should be done, but that should not stop us starting the work within CCAMP since it is clearly related to the inter-area/AS solution. 6. Advanced functions. There are several advanced functions that will be required, but which are not part of the immediate work. - Path reoptimization - Protection path diversity - crankback We expect that once the initial work has been done on the solutions, it will be possible to set out the requirements for these functions and to develop solutions based on the many drafts that are already out there. Comments please. Thanks, Adrian and Kireeti Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 12 Apr 2004 21:51:33 +0000 Message-ID: <00b901c420d8$27e2b450$60849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Cc: Subject: Fw: I-D ACTION:draft-ietf-ccamp-gmpls-recovery-terminology-04.txt Date: Mon, 12 Apr 2004 22:36:28 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi Alex, This draft has been updated after WG last call minor comment. Could you please take this draft forward to the IESG. Thanks, Adrian ----- Original Message ----- From: > 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 : Recovery (Protection and Restoration) Terminology for GMPLS > Author(s) : E. Mannie, D. Papadimitriou > Filename : draft-ietf-ccamp-gmpls-recovery-terminology-04.txt > Pages : 21 > Date : 2004-4-12 > > This document defines a common terminology for Generalized Multi- > Protocol Label Switching (GMPLS) based recovery mechanisms (i.e. > protection and restoration). The terminology is independent of the > underlying transport technologies covered by GMPLS. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-recovery-terminology-04.txt Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 12 Apr 2004 21:51:24 +0000 Message-ID: <00ba01c420d8$28b100d0$60849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Cc: Subject: Fw: I-D ACTION:draft-ietf-ccamp-gmpls-recovery-analysis-03.txt Date: Mon, 12 Apr 2004 22:38:33 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi again Alex, This draft, too, has been updated after minor comments in WG last call. Would be grateful if you could progress it towards the IESG. Thanks, Adrian ----- Original Message ----- From: > 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 : Analysis of Generalized Multi-Protocol Label Switching (GMPLS)-based Recovery Mechanisms (including Protection and Restoration) > Author(s) : D. Papadimitriou, E. Mannie > Filename : draft-ietf-ccamp-gmpls-recovery-analysis-03.txt > Pages : 42 > Date : 2004-4-12 > > This document provides an analysis grid to evaluate, compare and > contrast the Generalized Multi-Protocol Label Switching (GMPLS) > protocol suite capabilities with respect to the recovery mechanisms > currently proposed at the IETF CCAMP Working Group. A detailed > analysis of each of the recovery phases is provided using the > terminology defined in a companion document. This document focuses > on transport plane survivability and recovery issues and not on > control plane resilience and related aspects. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-recovery-analysis-03.txt Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 12 Apr 2004 19:31:14 +0000 Message-Id: <200404121930.PAA08614@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-gmpls-recovery-analysis-03.txt Date: Mon, 12 Apr 2004 15:30:40 -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 : Analysis of Generalized Multi-Protocol Label Switching (GMPLS)-based Recovery Mechanisms (including Protection and Restoration) Author(s) : D. Papadimitriou, E. Mannie Filename : draft-ietf-ccamp-gmpls-recovery-analysis-03.txt Pages : 42 Date : 2004-4-12 This document provides an analysis grid to evaluate, compare and contrast the Generalized Multi-Protocol Label Switching (GMPLS) protocol suite capabilities with respect to the recovery mechanisms currently proposed at the IETF CCAMP Working Group. A detailed analysis of each of the recovery phases is provided using the terminology defined in a companion document. This document focuses on transport plane survivability and recovery issues and not on control plane resilience and related aspects. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-recovery-analysis-03.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-recovery-analysis-03.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-recovery-analysis-03.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: <2004-4-12153729.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-gmpls-recovery-analysis-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-gmpls-recovery-analysis-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-4-12153729.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 12 Apr 2004 19:31:06 +0000 Message-Id: <200404121930.PAA08622@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-gmpls-recovery-terminology-04.txt Date: Mon, 12 Apr 2004 15:30:46 -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 : Recovery (Protection and Restoration) Terminology for GMPLS Author(s) : E. Mannie, D. Papadimitriou Filename : draft-ietf-ccamp-gmpls-recovery-terminology-04.txt Pages : 21 Date : 2004-4-12 This document defines a common terminology for Generalized Multi- Protocol Label Switching (GMPLS) based recovery mechanisms (i.e. protection and restoration). The terminology is independent of the underlying transport technologies covered by GMPLS. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-recovery-terminology-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-gmpls-recovery-terminology-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-gmpls-recovery-terminology-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: <2004-4-12153758.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-gmpls-recovery-terminology-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-gmpls-recovery-terminology-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-4-12153758.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 12 Apr 2004 18:47:31 +0000 Message-Id: <200404121845.OAA04020@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-gmpls-ason-routing-reqts-03.txt Date: Mon, 12 Apr 2004 14:45:03 -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 : Requirements for Generalized MPLS (GMPLS) Routing for Automatically Switched Optical Network (ASON) Author(s) : W. Alanqar, et al Filename : draft-ietf-ccamp-gmpls-ason-routing-reqts-03.txt Pages : 19 Date : 2004-4-9 The Generalized MPLS (GMPLS) suite of protocols has been defined to control different switching technologies as well as different applications. These include support for requesting TDM connections including SONET/SDH and Optical Transport Networks (OTNs). This document concentrates on the routing requirements on the GMPLS suite of protocols to support the capabilities and functionalities for an Automatically Switched Optical Network (ASON) as defined by ITU-T. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-ason-routing-reqts-03.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-ason-routing-reqts-03.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-ason-routing-reqts-03.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: <2004-4-9154858.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-gmpls-ason-routing-reqts-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-gmpls-ason-routing-reqts-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-4-9154858.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 09 Apr 2004 21:58:50 +0000 Reply-To: From: "Vishal Sharma" To: "Adrian Farrel" , "Ong, Lyndon" Cc: , "'Lou Berger'" Subject: RE: draft-ietf-ccamp-gmpls-egress-control-00.txt Date: Fri, 9 Apr 2004 14:57:30 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Adrian, > -----Original Message----- > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On > Behalf Of Adrian Farrel > Sent: Thursday, April 08, 2004 3:29 PM > To: Ong, Lyndon > Cc: ccamp@ops.ietf.org; 'Lou Berger' > Subject: Re: draft-ietf-ccamp-gmpls-egress-control-00.txt > > > Hi Lyndon, > > First note that this draft does not update the protocols and > procedures of RFC3473. It > restates them more explicitly. > > If you look at the RFC index > (http://www.ietf.org/iesg/1rfc_index.txt) you'll see there is > very little precedent for this type of work. > We can find BCP 75 and 76 ( and > http://www.ietf.org/rfc/rfc3666.txt) which could sort of > be said to update (or at least qualify) RFC 3261 and RFC 3264. > Neither is listed with an "updates" clause. > > Nor does RFC 3481 (BCP 71) have any back/forward pointer with the > TCP standard. > > > However, I take your point: how does someone wanting to know > everything about GMPLS know > to read this new document? > > We will look to see how this can be managed. > > In return can you tell me: how does anyone wanting to see all of > the RFCs related to (say) > TCP find them all? I guess that's when one consults either Stevens' tome, or one of Peter Loshin's "Big Book of X RFCs" where "X" = technology or protocol in question. :-) (I am not actually sure whether he has a big book of TCP/IP RFCs.) -Vishal Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 09 Apr 2004 20:29:58 +0000 Message-Id: <200404091936.PAA15366@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-gmpls-ason-routing-reqts-03.txt Date: Fri, 09 Apr 2004 15:36:34 -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 : Requirements for Generalized MPLS (GMPLS) Routing for Automatically Switched Optical Network (ASON) Author(s) : W. Alanqar, et al Filename : draft-ietf-ccamp-gmpls-ason-routing-reqts-03.txt Pages : 19 Date : 2004-4-9 The Generalized MPLS (GMPLS) suite of protocols has been defined to control different switching technologies as well as different applications. These include support for requesting TDM connections including SONET/SDH and Optical Transport Networks (OTNs). This document concentrates on the routing requirements on the GMPLS suite of protocols to support the capabilities and functionalities for an Automatically Switched Optical Network (ASON) as defined by ITU-T. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-ason-routing-reqts-03.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-ason-routing-reqts-03.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-ason-routing-reqts-03.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: <2004-4-9154858.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-gmpls-ason-routing-reqts-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-gmpls-ason-routing-reqts-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-4-9154858.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 08 Apr 2004 22:30:04 +0000 Message-ID: <021d01c41db8$f02bb240$7caa9ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Ong, Lyndon" Cc: , "'Lou Berger'" Subject: Re: draft-ietf-ccamp-gmpls-egress-control-00.txt Date: Thu, 8 Apr 2004 23:29:14 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi Lyndon, First note that this draft does not update the protocols and procedures of RFC3473. It restates them more explicitly. If you look at the RFC index (http://www.ietf.org/iesg/1rfc_index.txt) you'll see there is very little precedent for this type of work. We can find BCP 75 and 76 ( and http://www.ietf.org/rfc/rfc3666.txt) which could sort of be said to update (or at least qualify) RFC 3261 and RFC 3264. Neither is listed with an "updates" clause. Nor does RFC 3481 (BCP 71) have any back/forward pointer with the TCP standard. However, I take your point: how does someone wanting to know everything about GMPLS know to read this new document? We will look to see how this can be managed. In return can you tell me: how does anyone wanting to see all of the RFCs related to (say) TCP find them all? Cheers, Adrian ----- Original Message ----- From: "Ong, Lyndon" To: "'Lou Berger'" ; "Adrian Farrel" Cc: Sent: Thursday, April 08, 2004 10:20 PM Subject: RE: draft-ietf-ccamp-gmpls-egress-control-00.txt > Hi Guys, > > Administrative question - if this comes out as a BCP, > does the RFC table note this as some kind of update > to 3473? > > I'd be a little worried if there is no notation against > the RFC to point people to the clarification. > > Thanks, > > Lyndon > > -----Original Message----- > From: Lou Berger [mailto:lberger@movaz.com] > Sent: Thursday, April 08, 2004 2:11 PM > To: Adrian Farrel > Cc: Berger, Lou; ccamp@ops.ietf.org > Subject: Re: draft-ietf-ccamp-gmpls-egress-control-00.txt > > > Adrian, > See responses below. > > At 03:46 PM 4/8/2004 -0400, Adrian Farrel wrote: > >Hi Lou, > > > > > >Please give the intended category of the work... > > > >Proposed Category: Best Common Practice > > > > > > this is normally done outside of the draft. > > > >Hmmm. > >The draft needs to indicate its intended status so that folks can review > >it with that in mind. > >If you don't want to say that the proposed status is BCP then please at > >least say informational. > > will put into draft - I've always seen this in the last call announcement - > but whatever... > > > > > > > >Please correct draft name as it appears in the title and footers. > > > > > > > >draft-ietf-ccamp-gmpls-egress-control-00.txt > > > > > > fixed last week. > > > >Hah! But the secretariat has published it according to your first submission. > >Actually, the version on the LabN site is also wrong. > > > >I don't mean the document name, I mean the draft name as it appears > >throughout the document. > > will be fixed in next rev... > > >[...]> > > > >Compare with section 2.2 which is more general. > > > > > > > > To support Egress Control, an egress checks to see if the received > > > > ERO contains an outgoing/downstream interface. If it does, the type > > > > of the subobject or subobjects following the interface are examined. > > > > If the associated LSP is unidirectional, one subobject is examined. > > > > Two subobjects are examined for bidirectional LSPs. If the U-bit of > > > > the subobject being examined is clear (0), then the value of the > > > > label is copied into a new Label_Set object. Note, this Label_Set > > > > object is for internal use only. This Label_Set object indicates the > > > > label value that MUST be used for transmitting traffic associated > > > > with the LSP on the indicated outgoing/downstream interface. > > > >Not withstanding "this Label_Set object is for internal use only", I > > > >find this text a bit peculiar! > > > >You really just want to say that this subobject is used to specify the > > > >label that the egress MUST apply to traffic that it forwards from this > > > >LSP. (Compare with the next paragraph where you do not describe > > > >creating an Upstream_Label object for internal use only.) > > > >If you insist on talking about the Label_Set object, you will have to be > > > >far more specific because there are four different varieties of that > > > >object. > > > > > > I think the wording is consistent with RFC3473 and unambiguous. Please > > > suggest alternate wording. > > > >Well! I can't be held responsible for the failings of the editor of that > >RFC :-) > > > >Section 5.1.1 says with respect to the ERO Label Subobject... > > If the U-bit of the > > subobject being examined is clear (0), then value of the label is > > copied into a new Label_Set object. This Label_Set object MUST be > > included on the corresponding outgoing Path message. > > > >So I see where you are coming from, but I think this text is aimed at > >specifying how you build the outgoing Path message, not how you > >manage the label allocation on your downstream interface. It is > >wrong to suggest that an implementation must create a protocol > >object for this purpose if no Path message is to be sent. > > > >In fact, since there is no corresponding Resv with a Label Object > >we need to pin this text down a little more clearly. How about the > >following edit... > > > > To support Egress Control, an egress checks to see if the received > > ERO contains an outgoing/downstream interface. If it does, the type > > of the subobject or subobjects following the interface are examined. > > If the associated LSP is unidirectional, one subobject is examined. > > Two subobjects are examined for bidirectional LSPs. If the U-bit of > > the subobject being examined is clear (0), then the value of the > > label MUST be used for transmitting traffic associated with the LSP > > on the indicated outgoing/downstream interface. > > Done! > > > > > including if the listed label(s) are not acceptable or cannot be > > > > supported in forwarding, SHOULD result in the generation of a PathErr > > > > message containing a "Bad EXPLICIT_ROUTE object" error. > > > >I'd prefer you to be more explicit... > > > >... containing a "Routing Problem"/"Bad EXPLICIT_ROUTE object" error. > > > sure, will use phrasing from rfc3209. > > > > > > >3. Security Considerations > > > > > > > >< This note clarifies procedures defined in [RFC3473]. As such, no new > > > >< security considerations are introduced. > > > > > This note reiterates procedures defined in [RFC3473], but does not > > > > > define any new procedures. As such, no new security considerations > > > > > are introduced. > > > okay. > > > > > > ><5. References > > > > >5. Normative References > > > > > > > >Need BCP 78, and 79 as informational references. > > > >Also RFC 3668. > > > > > > will do, but do you really want me to reference BCP 79 and RFC 3668? > > > >It is unclear whether this is a requirement, but since the boilerplate > >text makes these references it seems reasonable to include them in the list. > > ahh, you fell for my trick question! (they're the same document ;-) > > > > > > >8. Intellectual Property > > > > > > > >Missing the personal disclaimer... > > > > By submitting this Internet-Draft, I certify that any applicable > > > > patent or other IPR claims of which I am aware have been disclosed, > > > > and any of which I become aware will be disclosed, in accordance with > > > > RFC 3668. > > > sure. > > > > > > >Don't need the footer... > > > >Generated on: Mon Mar 15 10:52:32 2004 > > > > > > picky, picky, picky... > >That's what I'm paid for. > > > >Thanks, Lou. Looking forward to seeing the revision published. > > > >Adrian > > > > Thanks again. > > submitting in a few minutes... > > Lou > > > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 08 Apr 2004 21:20:49 +0000 Message-ID: <829F074A10F98943A218DC363D09C92A01476C49@w2ksjexg06.ciena.com> From: "Ong, Lyndon" To: 'Lou Berger' , Adrian Farrel Cc: ccamp@ops.ietf.org Subject: RE: draft-ietf-ccamp-gmpls-egress-control-00.txt Date: Thu, 8 Apr 2004 14:20:28 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Hi Guys, Administrative question - if this comes out as a BCP, does the RFC table note this as some kind of update to 3473? I'd be a little worried if there is no notation against the RFC to point people to the clarification. Thanks, Lyndon -----Original Message----- From: Lou Berger [mailto:lberger@movaz.com] Sent: Thursday, April 08, 2004 2:11 PM To: Adrian Farrel Cc: Berger, Lou; ccamp@ops.ietf.org Subject: Re: draft-ietf-ccamp-gmpls-egress-control-00.txt Adrian, See responses below. At 03:46 PM 4/8/2004 -0400, Adrian Farrel wrote: >Hi Lou, > > > >Please give the intended category of the work... > > >Proposed Category: Best Common Practice > > > > this is normally done outside of the draft. > >Hmmm. >The draft needs to indicate its intended status so that folks can review >it with that in mind. >If you don't want to say that the proposed status is BCP then please at >least say informational. will put into draft - I've always seen this in the last call announcement - but whatever... > > > >Please correct draft name as it appears in the title and footers. > > > > > >draft-ietf-ccamp-gmpls-egress-control-00.txt > > > > fixed last week. > >Hah! But the secretariat has published it according to your first submission. >Actually, the version on the LabN site is also wrong. > >I don't mean the document name, I mean the draft name as it appears >throughout the document. will be fixed in next rev... >[...]> > > >Compare with section 2.2 which is more general. > > > > > > To support Egress Control, an egress checks to see if the received > > > ERO contains an outgoing/downstream interface. If it does, the type > > > of the subobject or subobjects following the interface are examined. > > > If the associated LSP is unidirectional, one subobject is examined. > > > Two subobjects are examined for bidirectional LSPs. If the U-bit of > > > the subobject being examined is clear (0), then the value of the > > > label is copied into a new Label_Set object. Note, this Label_Set > > > object is for internal use only. This Label_Set object indicates the > > > label value that MUST be used for transmitting traffic associated > > > with the LSP on the indicated outgoing/downstream interface. > > >Not withstanding "this Label_Set object is for internal use only", I > > >find this text a bit peculiar! > > >You really just want to say that this subobject is used to specify the > > >label that the egress MUST apply to traffic that it forwards from this > > >LSP. (Compare with the next paragraph where you do not describe > > >creating an Upstream_Label object for internal use only.) > > >If you insist on talking about the Label_Set object, you will have to be > > >far more specific because there are four different varieties of that > > >object. > > > > I think the wording is consistent with RFC3473 and unambiguous. Please > > suggest alternate wording. > >Well! I can't be held responsible for the failings of the editor of that >RFC :-) > >Section 5.1.1 says with respect to the ERO Label Subobject... > If the U-bit of the > subobject being examined is clear (0), then value of the label is > copied into a new Label_Set object. This Label_Set object MUST be > included on the corresponding outgoing Path message. > >So I see where you are coming from, but I think this text is aimed at >specifying how you build the outgoing Path message, not how you >manage the label allocation on your downstream interface. It is >wrong to suggest that an implementation must create a protocol >object for this purpose if no Path message is to be sent. > >In fact, since there is no corresponding Resv with a Label Object >we need to pin this text down a little more clearly. How about the >following edit... > > To support Egress Control, an egress checks to see if the received > ERO contains an outgoing/downstream interface. If it does, the type > of the subobject or subobjects following the interface are examined. > If the associated LSP is unidirectional, one subobject is examined. > Two subobjects are examined for bidirectional LSPs. If the U-bit of > the subobject being examined is clear (0), then the value of the > label MUST be used for transmitting traffic associated with the LSP > on the indicated outgoing/downstream interface. Done! > > > including if the listed label(s) are not acceptable or cannot be > > > supported in forwarding, SHOULD result in the generation of a PathErr > > > message containing a "Bad EXPLICIT_ROUTE object" error. > > >I'd prefer you to be more explicit... > > >... containing a "Routing Problem"/"Bad EXPLICIT_ROUTE object" error. > > sure, will use phrasing from rfc3209. > > > > >3. Security Considerations > > > > > >< This note clarifies procedures defined in [RFC3473]. As such, no new > > >< security considerations are introduced. > > > > This note reiterates procedures defined in [RFC3473], but does not > > > > define any new procedures. As such, no new security considerations > > > > are introduced. > > okay. > > > > ><5. References > > > >5. Normative References > > > > > >Need BCP 78, and 79 as informational references. > > >Also RFC 3668. > > > > will do, but do you really want me to reference BCP 79 and RFC 3668? > >It is unclear whether this is a requirement, but since the boilerplate >text makes these references it seems reasonable to include them in the list. ahh, you fell for my trick question! (they're the same document ;-) > > > >8. Intellectual Property > > > > > >Missing the personal disclaimer... > > > By submitting this Internet-Draft, I certify that any applicable > > > patent or other IPR claims of which I am aware have been disclosed, > > > and any of which I become aware will be disclosed, in accordance with > > > RFC 3668. > > sure. > > > > >Don't need the footer... > > >Generated on: Mon Mar 15 10:52:32 2004 > > > > picky, picky, picky... >That's what I'm paid for. > >Thanks, Lou. Looking forward to seeing the revision published. > >Adrian > Thanks again. submitting in a few minutes... Lou Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 08 Apr 2004 21:11:51 +0000 Message-Id: <6.0.3.0.2.20040408164716.04eb8808@mo-ex1> Date: Thu, 08 Apr 2004 17:10:33 -0400 To: "Adrian Farrel" From: Lou Berger Subject: Re: draft-ietf-ccamp-gmpls-egress-control-00.txt Cc: "Berger, Lou" , Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Adrian, See responses below. At 03:46 PM 4/8/2004 -0400, Adrian Farrel wrote: >Hi Lou, > > > >Please give the intended category of the work... > > >Proposed Category: Best Common Practice > > > > this is normally done outside of the draft. > >Hmmm. >The draft needs to indicate its intended status so that folks can review >it with that in mind. >If you don't want to say that the proposed status is BCP then please at >least say informational. will put into draft - I've always seen this in the last call announcement - but whatever... > > > >Please correct draft name as it appears in the title and footers. > > > > > >draft-ietf-ccamp-gmpls-egress-control-00.txt > > > > fixed last week. > >Hah! But the secretariat has published it according to your first submission. >Actually, the version on the LabN site is also wrong. > >I don't mean the document name, I mean the draft name as it appears >throughout the document. will be fixed in next rev... >[...]> > > >Compare with section 2.2 which is more general. > > > > > > To support Egress Control, an egress checks to see if the received > > > ERO contains an outgoing/downstream interface. If it does, the type > > > of the subobject or subobjects following the interface are examined. > > > If the associated LSP is unidirectional, one subobject is examined. > > > Two subobjects are examined for bidirectional LSPs. If the U-bit of > > > the subobject being examined is clear (0), then the value of the > > > label is copied into a new Label_Set object. Note, this Label_Set > > > object is for internal use only. This Label_Set object indicates the > > > label value that MUST be used for transmitting traffic associated > > > with the LSP on the indicated outgoing/downstream interface. > > >Not withstanding "this Label_Set object is for internal use only", I > > >find this text a bit peculiar! > > >You really just want to say that this subobject is used to specify the > > >label that the egress MUST apply to traffic that it forwards from this > > >LSP. (Compare with the next paragraph where you do not describe > > >creating an Upstream_Label object for internal use only.) > > >If you insist on talking about the Label_Set object, you will have to be > > >far more specific because there are four different varieties of that > > >object. > > > > I think the wording is consistent with RFC3473 and unambiguous. Please > > suggest alternate wording. > >Well! I can't be held responsible for the failings of the editor of that >RFC :-) > >Section 5.1.1 says with respect to the ERO Label Subobject... > If the U-bit of the > subobject being examined is clear (0), then value of the label is > copied into a new Label_Set object. This Label_Set object MUST be > included on the corresponding outgoing Path message. > >So I see where you are coming from, but I think this text is aimed at >specifying how you build the outgoing Path message, not how you >manage the label allocation on your downstream interface. It is >wrong to suggest that an implementation must create a protocol >object for this purpose if no Path message is to be sent. > >In fact, since there is no corresponding Resv with a Label Object >we need to pin this text down a little more clearly. How about the >following edit... > > To support Egress Control, an egress checks to see if the received > ERO contains an outgoing/downstream interface. If it does, the type > of the subobject or subobjects following the interface are examined. > If the associated LSP is unidirectional, one subobject is examined. > Two subobjects are examined for bidirectional LSPs. If the U-bit of > the subobject being examined is clear (0), then the value of the > label MUST be used for transmitting traffic associated with the LSP > on the indicated outgoing/downstream interface. Done! > > > including if the listed label(s) are not acceptable or cannot be > > > supported in forwarding, SHOULD result in the generation of a PathErr > > > message containing a "Bad EXPLICIT_ROUTE object" error. > > >I'd prefer you to be more explicit... > > >... containing a "Routing Problem"/"Bad EXPLICIT_ROUTE object" error. > > sure, will use phrasing from rfc3209. > > > > >3. Security Considerations > > > > > >< This note clarifies procedures defined in [RFC3473]. As such, no new > > >< security considerations are introduced. > > > > This note reiterates procedures defined in [RFC3473], but does not > > > > define any new procedures. As such, no new security considerations > > > > are introduced. > > okay. > > > > ><5. References > > > >5. Normative References > > > > > >Need BCP 78, and 79 as informational references. > > >Also RFC 3668. > > > > will do, but do you really want me to reference BCP 79 and RFC 3668? > >It is unclear whether this is a requirement, but since the boilerplate >text makes these references it seems reasonable to include them in the list. ahh, you fell for my trick question! (they're the same document ;-) > > > >8. Intellectual Property > > > > > >Missing the personal disclaimer... > > > By submitting this Internet-Draft, I certify that any applicable > > > patent or other IPR claims of which I am aware have been disclosed, > > > and any of which I become aware will be disclosed, in accordance with > > > RFC 3668. > > sure. > > > > >Don't need the footer... > > >Generated on: Mon Mar 15 10:52:32 2004 > > > > picky, picky, picky... >That's what I'm paid for. > >Thanks, Lou. Looking forward to seeing the revision published. > >Adrian > Thanks again. submitting in a few minutes... Lou Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 08 Apr 2004 19:49:45 +0000 Message-ID: <01f801c41da2$57c6a480$7caa9ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Lou Berger" Cc: Subject: Re: draft-ietf-ccamp-gmpls-egress-control-00.txt Date: Thu, 8 Apr 2004 20:46:47 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01F1_01C41DAA.9C2235B0" This is a multi-part message in MIME format. ------=_NextPart_000_01F1_01C41DAA.9C2235B0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Lou, > >Please give the intended category of the work... > >Proposed Category: Best Common Practice >=20 > this is normally done outside of the draft. Hmmm. The draft needs to indicate its intended status so that folks can review = it with that in mind. If you don't want to say that the proposed status is BCP then please at = least say informational. > >Please correct draft name as it appears in the title and footers. > > > >draft-ietf-ccamp-gmpls-egress-control-00.txt >=20 > fixed last week. Hah! But the secretariat has published it according to your first = submission. Actually, the version on the LabN site is also wrong. I don't mean the document name, I mean the draft name as it appears = throughout the document. > >Abstract > >Please remove [bracketed] citation from abstract. > done >=20 > >Abstract > > This note clarifies the procedures for the control of a label = used on > > an egress output/downstream interface. > >I think this would be better phrased as... > > This note clarifies the procedures for the control of the label = used > > on output/downstream interface of the final (egress) Label = Switching > > Router (LSR) of a Label Switched Path (LSP). > sure. >=20 > >1. Background > > > > The ability to control a label used on an egress = output/downstream > > interface was one of the early requirements for GMPLS. > >Again, rephrase as... > > The ability to control the label used on the output/downstream > > interface of an egress LSR was one of the early requirements for > > GMPLS. > sure, why not. >=20 > >2.1. ERO Procedures > > > > Egress Control occurs when the node processing an ERO is the = egress > > and the ERO contains one or more label subobjects. > >In view of the text quoted from section 6 of an early draft of GMPLS, > >we either need to re-cast this whole draft as "Egress Label Control" > >or we need to generalize the text here as egress control that allows > >the control of interface, component link and label. > >I prefer the second option. > no problem. changed to ... "one or more subobjects related to the=20 > output/downstream interface" >=20 > >Compare with section 2.2 which is more general. > > > > To support Egress Control, an egress checks to see if the = received > > ERO contains an outgoing/downstream interface. If it does, the = type > > of the subobject or subobjects following the interface are = examined. > > If the associated LSP is unidirectional, one subobject is = examined. > > Two subobjects are examined for bidirectional LSPs. If the U-bit = of > > the subobject being examined is clear (0), then the value of the > > label is copied into a new Label_Set object. Note, this = Label_Set > > object is for internal use only. This Label_Set object indicates = the > > label value that MUST be used for transmitting traffic associated > > with the LSP on the indicated outgoing/downstream interface. > >Not withstanding "this Label_Set object is for internal use only", I > >find this text a bit peculiar! > >You really just want to say that this subobject is used to specify = the > >label that the egress MUST apply to traffic that it forwards from = this > >LSP. (Compare with the next paragraph where you do not describe > >creating an Upstream_Label object for internal use only.) > >If you insist on talking about the Label_Set object, you will have to = be > >far more specific because there are four different varieties of that > >object. >=20 > I think the wording is consistent with RFC3473 and unambiguous. = Please=20 > suggest alternate wording. Well! I can't be held responsible for the failings of the editor of = that RFC :-) Section 5.1.1 says with respect to the ERO Label Subobject... If the U-bit of the subobject being examined is clear (0), then value of the label is copied into a new Label_Set object. This Label_Set object MUST be included on the corresponding outgoing Path message. So I see where you are coming from, but I think this text is aimed at specifying how you build the outgoing Path message, not how you manage the label allocation on your downstream interface. It is=20 wrong to suggest that an implementation must create a protocol object for this purpose if no Path message is to be sent. In fact, since there is no corresponding Resv with a Label Object we need to pin this text down a little more clearly. How about the following edit... To support Egress Control, an egress checks to see if the received ERO contains an outgoing/downstream interface. If it does, the type of the subobject or subobjects following the interface are examined. If the associated LSP is unidirectional, one subobject is examined. Two subobjects are examined for bidirectional LSPs. If the U-bit of the subobject being examined is clear (0), then the value of the=20 label MUST be used for transmitting traffic associated with the LSP on the indicated outgoing/downstream interface. > > including if the listed label(s) are not acceptable or cannot be > > supported in forwarding, SHOULD result in the generation of a = PathErr > > message containing a "Bad EXPLICIT_ROUTE object" error. > >I'd prefer you to be more explicit... > >... containing a "Routing Problem"/"Bad EXPLICIT_ROUTE object" error. > sure, will use phrasing from rfc3209. >=20 > >3. Security Considerations > > > >< This note clarifies procedures defined in [RFC3473]. As such, no = new > >< security considerations are introduced. > > > This note reiterates procedures defined in [RFC3473], but does = not > > > define any new procedures. As such, no new security = considerations > > > are introduced. > okay. >=20 > ><5. References > > >5. Normative References > > > >Need BCP 78, and 79 as informational references. > >Also RFC 3668. >=20 > will do, but do you really want me to reference BCP 79 and RFC 3668? It is unclear whether this is a requirement, but since the boilerplate = text makes these references it seems reasonable to include them in the = list. > >8. Intellectual Property > > > >Missing the personal disclaimer... > > By submitting this Internet-Draft, I certify that any applicable > > patent or other IPR claims of which I am aware have been = disclosed, > > and any of which I become aware will be disclosed, in accordance = with > > RFC 3668. > sure. >=20 > >Don't need the footer... > >Generated on: Mon Mar 15 10:52:32 2004 >=20 > picky, picky, picky... That's what I'm paid for. Thanks, Lou. Looking forward to seeing the revision published. Adrian ------=_NextPart_000_01F1_01C41DAA.9C2235B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Lou,
 
> >Please give the intended = category of the=20 work...
> >Proposed Category: Best Common Practice
> =
>=20 this is normally done outside of the draft.
 
Hmmm.
The draft needs to indicate its = intended status=20 so that folks can review it with that in mind.
If you don't want to say that the = proposed status=20 is BCP then please at least say informational.
 
> >Please correct draft name as = it appears=20 in the title and footers.
>=20 ><draft-ccamp-gmpls-egress-control-00.txt
> >=20 >draft-ietf-ccamp-gmpls-egress-control-00.txt
>
> fixed = last=20 week.
 
Hah! But the secretariat has = published it=20 according to your first submission.
Actually, the version on the LabN = site is also=20 wrong.
 
I don't mean the document name, I = mean the draft=20 name as it appears throughout the document.

> >Abstract
> = >Please remove=20 [bracketed] citation from abstract.
> done
>
>=20 >Abstract
> >    This note clarifies the = procedures=20 for the control of a label used on
> >    an = egress=20 output/downstream interface.
> >I think this would be better = phrased=20 as...
> >    This note clarifies the procedures = for the=20 control of the label used
> >    on = output/downstream=20 interface of the final (egress) Label Switching
> = >   =20 Router (LSR) of a Label Switched Path (LSP).
> sure.
> =
>=20 >1. Background
> >
> >    The = ability to=20 control a label used on an egress output/downstream
>=20 >    interface was one of the early requirements for=20 GMPLS.
> >Again, rephrase as...
> >    = The=20 ability to control the label used on the output/downstream
>=20 >    interface of an egress LSR was one of the early=20 requirements for
> >    GMPLS.
> sure, why = not.
>
> >2.1. ERO Procedures
> >
>=20 >    Egress Control occurs when the node processing an = ERO is=20 the egress
> >    and the ERO contains one or = more label=20 subobjects.
> >In view of the text quoted from section 6 of an = early=20 draft of GMPLS,
> >we either need to re-cast this whole draft = as=20 "Egress Label Control"
> >or we need to generalize the text = here as=20 egress control that allows
> >the control of interface, = component link=20 and label.
> >I prefer the second option.
> no = problem. =20 changed to ... "one or more subobjects related to the
> = output/downstream=20 interface"
>
> >Compare with section 2.2 which is more=20 general.
> >
> >    To support Egress = Control,=20 an egress checks to see if the received
> >    = ERO=20 contains an outgoing/downstream interface.  If it does, the = type
>=20 >    of the subobject or subobjects following the = interface=20 are examined.
> >    If the associated LSP is=20 unidirectional, one subobject is examined.
> = >    Two=20 subobjects are examined for bidirectional LSPs.  If the U-bit = of
>=20 >    the subobject being examined is clear (0), then = the value=20 of the
> >    label is copied into a new = Label_Set=20 object.  Note, this Label_Set
> >    object = is for=20 internal use only.  This Label_Set object indicates the
>=20 >    label value that MUST be used for transmitting = traffic=20 associated
> >    with the LSP on the indicated=20 outgoing/downstream interface.
> >Not withstanding "this = Label_Set=20 object is for internal use only", I
> >find this text a bit=20 peculiar!
> >You really just want to say that this subobject is = used to=20 specify the
> >label that the egress MUST apply to traffic that = it=20 forwards from this
> >LSP. (Compare with the next paragraph = where you=20 do not describe
> >creating an Upstream_Label object for = internal use=20 only.)
> >If you insist on talking about the Label_Set object, = you will=20 have to be
> >far more specific because there are four = different=20 varieties of that
> >object.
>
> I think the = wording is=20 consistent with RFC3473 and unambiguous.  Please
> suggest = alternate=20 wording.
 
Well!  I can't be held = responsible for the=20 failings of the editor of that RFC  :-)
 
Section 5.1.1 says with respect to = the ERO Label=20 Subobject...
   If the U-bit of = the
  =20 subobject being examined is clear (0), then value of the label=20 is
   copied into a new Label_Set object.  This = Label_Set=20 object MUST be
   included on the corresponding outgoing = Path=20 message.
 
So I see where you are coming from, = but I think=20 this text is aimed at
specifying how you build the outgoing = Path=20 message, not how you
manage the label allocation on your = downstream=20 interface. It is
wrong to suggest that an = implementation must=20 create a protocol
object for this purpose if no Path = message is to=20 be sent.
 
In fact, since there is no = corresponding Resv=20 with a Label Object
we need to pin this text down a = little more=20 clearly. How about the
following edit...
 
    To support Egress = Control, an=20 egress checks to see if the received
    ERO contains = an=20 outgoing/downstream interface.  If it does, the = type
   =20 of the subobject or subobjects following the interface are=20 examined.
    If the associated LSP is unidirectional, = one=20 subobject is examined.
    Two subobjects are examined = for=20 bidirectional LSPs.  If the U-bit of
    the subobject = being=20 examined is clear (0), then the value of the 
    label MUST be used=20 for transmitting traffic associated with the LSP
    on the indicated=20 outgoing/downstream interface.
> >    including = if the=20 listed label(s) are not acceptable or cannot be
> = >   =20 supported in forwarding, SHOULD result in the generation of a = PathErr
>=20 >    message containing a "Bad EXPLICIT_ROUTE object"=20 error.
> >I'd prefer you to be more explicit...
> >... = containing a "Routing Problem"/"Bad EXPLICIT_ROUTE object" = error.
> sure,=20 will use phrasing from rfc3209.
>
> >3. Security=20 Considerations
> >
> ><  This note clarifies=20 procedures defined in [RFC3473].  As such, no new
> = >< =20 security considerations are introduced.
> > >  This = note=20 reiterates procedures defined in [RFC3473], but does not
> > = > =20 define any new procedures.  As such, no new security = considerations
>=20 > >  are introduced.
> okay.
>
> = ><5.=20 References
> > >5. Normative References
> >
> = >Need BCP 78, and 79 as informational references.
> >Also = RFC=20 3668.
>
> will do, but do you really want me to reference = BCP 79=20 and  RFC 3668?
 
It is unclear whether this is a = requirement, but=20 since the boilerplate text makes these references it seems reasonable to = include=20 them in the list.
 
> >8. Intellectual Property
> >
> >Missing = the=20 personal disclaimer...
> >    By submitting this = Internet-Draft, I certify that any applicable
> = >   =20 patent or other IPR claims of which I am aware have been = disclosed,
>=20 >    and any of which I become aware will be = disclosed, in=20 accordance with
> >    RFC 3668.
> = sure.
>=20
> >Don't need the footer...
> >Generated on: Mon Mar = 15=20 10:52:32 2004
>
> picky, picky, picky...
That's what I'm paid for.
 
Thanks, Lou. Looking forward to seeing the revision = published.
 
Adrian
 
------=_NextPart_000_01F1_01C41DAA.9C2235B0-- Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 08 Apr 2004 11:44:53 +0000 Message-ID: <01ba01c41d5e$9b8989b0$7caa9ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Further WG Last Call on LMP MIB Complete Date: Thu, 8 Apr 2004 12:42:35 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi, The further WG last call on this draft has completed without further comments. Alex, Bert, Can you please take this draft forward to the IESG. Thanks, Adrian ----- Original Message ----- From: "Adrian Farrel" To: Cc: "Martin Dubuc" ; "Wijnen, Bert (Bert)" Sent: Tuesday, March 30, 2004 12:25 AM Subject: Further WG Last Call on LMP MIB > Hi, > > Martin has done a sterling job updating the LMP MIB after the usual thorough and careful > review by Bert. > > In view of the number of changes (although none is very major) we are holding another > working group last call on this draft. > > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-lmp-mib-08.txt > > Please send your comments to the list. > > The last call will end on Thursday 8th April at 12 noon GMT. > > Thanks, > Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 07 Apr 2004 15:06:48 +0000 Message-Id: <200404071505.LAA00417@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-gmpls-recovery-e2e-signaling-00.txt Date: Wed, 07 Apr 2004 11:05:38 -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 : RSVP-TE Extensions in support of End-to-End GMPLS-based Recovery Author(s) : J. Lang, et al Filename : draft-ietf-ccamp-gmpls-recovery-e2e-signaling-00.txt Pages : 33 Date : 2004-4-6 This document describes protocol specific procedures for GMPLS (Generalized Multi-Protocol Label Switching) RSVP-TE (Resource ReserVation Protocol - Traffic Engineering) signaling extensions to support end-to-end LSP recovery (protection and restoration). A generic functional description of GMPLS recovery can be found in a companion document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-recovery-e2e-signaling-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ccamp-gmpls-recovery-e2e-signaling-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ccamp-gmpls-recovery-e2e-signaling-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-4-7110409.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-gmpls-recovery-e2e-signaling-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-gmpls-recovery-e2e-signaling-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-4-7110409.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 07 Apr 2004 15:05:25 +0000 Message-Id: <200404071502.LAA00285@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-tunproto-00.txt Date: Wed, 07 Apr 2004 11:02:29 -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 : Generic Tunnel Tracing Protocol (GTTP) Specification Author(s) : R. Bonica, et al Filename : draft-ietf-ccamp-tunproto-00.txt Pages : 38 Date : 2004-4-6 This document describes the Generic Tunnel Tracing Protocol (GTTP). GTTP supports enhanced route-tracing applications. Network operators use enhanced route-tracing applications to trace the path between any two points in an IP network. Enhanced route-tracing applications can trace through a network's forwarding plane, its control plane or both. Furthermore, enhanced route-tracing applications can reveal details concerning tunnels that support the traced path. Tunnel details can be revealed regardless of tunneling technology. For example, enhanced route-tracing applications can trace through an MPLS LSP as well as they can trace through an IP-in-IP tunnel. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-tunproto-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ccamp-tunproto-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ccamp-tunproto-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-4-7110344.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-tunproto-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-tunproto-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-4-7110344.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 07 Apr 2004 15:05:22 +0000 Message-Id: <200404071503.LAA00320@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-gmpls-recovery-e2e-signaling-00.txt Date: Wed, 07 Apr 2004 11:03:40 -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 : RSVP-TE Extensions in support of End-to-End GMPLS-based Recovery Author(s) : J. Lang, et al Filename : draft-ietf-ccamp-gmpls-recovery-e2e-signaling-00.txt Pages : 33 Date : 2004-4-6 This document describes protocol specific procedures for GMPLS (Generalized Multi-Protocol Label Switching) RSVP-TE (Resource ReserVation Protocol - Traffic Engineering) signaling extensions to support end-to-end LSP recovery (protection and restoration). A generic functional description of GMPLS recovery can be found in a companion document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-recovery-e2e-signaling-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ccamp-gmpls-recovery-e2e-signaling-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ccamp-gmpls-recovery-e2e-signaling-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-4-7110409.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-gmpls-recovery-e2e-signaling-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-gmpls-recovery-e2e-signaling-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-4-7110409.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 06 Apr 2004 18:11:23 +0000 Message-ID: From: "Marco Carugi" To: "Brungard, Deborah A, ALABS" Cc: ccamp@ops.ietf.org Subject: RE: [RE] Layer One VPNs - sorry for the previous email Date: Tue, 6 Apr 2004 20:09:09 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C41C02.41FE9654" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C41C02.41FE9654 Content-Type: text/plain Deborah, > I noted the SG13 liaison has a response date of September > 2004 (the l1vpn questionnaire responses are due June). Will > we wait until the August IETF meeting to respond? (hopefully > there will have been a decision on the l1vpn work allocation) thank you for noting this out. SG13 will welcome a liaison statement from IETF. Regarding the time frame, next SG13 (interim) meeting discussing L1 VPNs will be in September, so waiting until the August IETF meeting would still be okay. Marco ------_=_NextPart_001_01C41C02.41FE9654 Content-Type: text/html RE: [RE] Layer One VPNs - sorry for the previous email

Deborah,
 
> I noted the SG13 liaison has a response date of September
> 2004 (the l1vpn questionnaire responses are due June).  Will
> we wait until the August IETF meeting to respond? (hopefully
> there will have been a decision on the l1vpn work allocation)

thank you for noting this out. SG13 will welcome a liaison statement
from IETF. Regarding the time frame, next SG13 (interim) meeting discussing L1 VPNs
will be in September, so waiting until the August IETF meeting would still be okay.

Marco

------_=_NextPart_001_01C41C02.41FE9654-- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 06 Apr 2004 17:02:24 +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: [RE] Layer One VPNs - sorry for the previous email Date: Tue, 6 Apr 2004 12:00:59 -0500 Message-ID: Thread-Topic: [RE] Layer One VPNs - sorry for the previous email Thread-Index: AcQb9fTALp91f0k6Tk2QpR69Cne7kQAAkNhg From: "Alanqar, Wesam I [NTK]" To: "Tomonori TAKEDA" , , Cc: Will SG15 be included in this effort mainly addressing ASON architectural enhancements for L1 VPN? I believe that there should be collaboration on the (protocols, generic control plane architectures, service architectures) to support L1 VPN. Thanks, -Wesam -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Tomonori TAKEDA Sent: Tuesday, April 06, 2004 11:34 AM To: Dimitri.Papadimitriou@alcatel.be Cc: yhwkim@etri.re.kr; ccamp@ops.ietf.org Subject: Re: [RE] Layer One VPNs - sorry for the previous email Hi, Dimitri Thank you for your comments. And I am sorry for late response. [snipped] >>>- there is the issue of the "PE-PE virtual links" and in case of >>>"Per VPN Peer model" more details should be provided in order to >>>assess whether existing GMPLS mechanisms are sufficient (from >>>that perspective details about the following sentence might be >>>of interest because it seems you took this as initial working >>>assumption "there is currently no leakage of routing information >>>across the PE to CE boundary.") >> >>Agree. Providing more details about service requirements may be helpful ?=20 >>Functional requirements are also important, but before going that in=20 >>details, more clear service level requirements may be useful. > >do you plan to deliver those as part of the user community or do you=20 >expect this input to come from SG13 - or both - ? just to know about the=20 >timeframe we may expect here since there are very interesting issues=20 >you're introducing with the above approaches Understood. I think this requires further discussion. I would personally think joint collaboration between IETF and SG13 would be a good approach.=20 Anyway, a simple step further at this point could be to enhance the=20 current service level requirements according to all material produced in SG13. We (authors of the L1VPN framework draft) are happy to provide such=20 text for the next version of the draft. Inputs and comments would be also=20 appreciated. >>Concerning the initial working assumption you mentioned, we started from=20 >>the most acknowledged model for the service interface, that is the UNI.=20 >>That is why we put above text. > >so you started with a signaling interface, and then try to build on top >of it the necessary pieces > >>>- i would suggest to conclude the document with the expected >>>delta requirement from gmpls perspective (this would help in >>>assessing what's expected in terms of protocol for the next >>>step(s)) >> >>Okay, if CCAMP is going to work on the L1 VPN, I agree delta requirement=20 >>would be an important step. >>Do you have anything in your mind ? > >try to collect all the sentences that are part of the present document=20 >that either implicitly or explicitly determine a feature to be covered >list them in terms of signaling and routing, i think we would gain a lot=20 >of precious time in having such conclusion in case decision to work on=20 >solution is accepted Thanks. Yes, as already said, delta requirements will be certainly useful.=20 Having a good understanding of the service and architecture needs is=20 beneficial to drive later the discussion on protocols in a comprehensive way (how protocols and mechanisms fit the service and the architecture). [snipped] Any comments are appreciated. Best regards, ----- Tomonori TAKEDA NTT Network Service Systems Lab. Phone: +81-422-59-7434 Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 06 Apr 2004 16:37:57 +0000 Message-Id: <5.0.2.5.2.20040407012556.06446ec8@cronos.ocn.ne.jp> Date: Wed, 07 Apr 2004 01:34:17 +0900 To: Dimitri.Papadimitriou@alcatel.be From: Tomonori TAKEDA Subject: Re: [RE] Layer One VPNs - sorry for the previous email Cc: yhwkim@etri.re.kr, ccamp@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Hi, Dimitri Thank you for your comments. And I am sorry for late response. [snipped] >>>- there is the issue of the "PE-PE virtual links" and in case of >>>"Per VPN Peer model" more details should be provided in order to >>>assess whether existing GMPLS mechanisms are sufficient (from >>>that perspective details about the following sentence might be >>>of interest because it seems you took this as initial working >>>assumption "there is currently no leakage of routing information >>>across the PE to CE boundary.") >> >>Agree. Providing more details about service requirements may be helpful ? >>Functional requirements are also important, but before going that in >>details, more clear service level requirements may be useful. > >do you plan to deliver those as part of the user community or do you >expect this input to come from SG13 - or both - ? just to know about the >timeframe we may expect here since there are very interesting issues >you're introducing with the above approaches Understood. I think this requires further discussion. I would personally think joint collaboration between IETF and SG13 would be a good approach. Anyway, a simple step further at this point could be to enhance the current service level requirements according to all material produced in SG13. We (authors of the L1VPN framework draft) are happy to provide such text for the next version of the draft. Inputs and comments would be also appreciated. >>Concerning the initial working assumption you mentioned, we started from >>the most acknowledged model for the service interface, that is the UNI. >>That is why we put above text. > >so you started with a signaling interface, and then try to build on top >of it the necessary pieces > >>>- i would suggest to conclude the document with the expected >>>delta requirement from gmpls perspective (this would help in >>>assessing what's expected in terms of protocol for the next >>>step(s)) >> >>Okay, if CCAMP is going to work on the L1 VPN, I agree delta requirement >>would be an important step. >>Do you have anything in your mind ? > >try to collect all the sentences that are part of the present document >that either implicitly or explicitly determine a feature to be covered >list them in terms of signaling and routing, i think we would gain a lot >of precious time in having such conclusion in case decision to work on >solution is accepted Thanks. Yes, as already said, delta requirements will be certainly useful. Having a good understanding of the service and architecture needs is beneficial to drive later the discussion on protocols in a comprehensive way (how protocols and mechanisms fit the service and the architecture). [snipped] Any comments are appreciated. Best regards, ----- Tomonori TAKEDA NTT Network Service Systems Lab. Phone: +81-422-59-7434 Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 05 Apr 2004 19:49:07 +0000 Message-Id: <6.0.3.0.2.20040405152933.03474b88@mo-ex1> Date: Mon, 05 Apr 2004 15:47:34 -0400 To: "Adrian Farrel" From: Lou Berger Subject: Re: draft-ietf-ccamp-gmpls-egress-control-00.txt Cc: , "Berger, Lou" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Adrian, Thanks for the comments. See below. Lou At 11:23 AM 4/5/2004 -0400, Adrian Farrel wrote: >Hi Lou, > >In Seoul we agreed that this draft would become a WG document and we >talked a little about doing a working group last call immediately thereafter. > >Thanks for re-spinning the draft as a WG draft. There are, however, a few >nits that I think you should tidy up before we do the last call. > >Perhaps others would like to pitch in now if they have any substantive >comments before the last call. > >Thanks, >Adrian > > >Please give the intended category of the work... >Proposed Category: Best Common Practice this is normally done outside of the draft. >Please correct draft name as it appears in the title and footers. > >draft-ietf-ccamp-gmpls-egress-control-00.txt fixed last week. >Abstract >Please remove [bracketed] citation from abstract. done >Abstract > This note clarifies the procedures for the control of a label used on > an egress output/downstream interface. >I think this would be better phrased as... > This note clarifies the procedures for the control of the label used > on output/downstream interface of the final (egress) Label Switching > Router (LSR) of a Label Switched Path (LSP). sure. > > >1. Background > > The ability to control a label used on an egress output/downstream > interface was one of the early requirements for GMPLS. >Again, rephrase as... > The ability to control the label used on the output/downstream > interface of an egress LSR was one of the early requirements for > GMPLS. > sure, why not. >2.1. ERO Procedures > > Egress Control occurs when the node processing an ERO is the egress > and the ERO contains one or more label subobjects. >In view of the text quoted from section 6 of an early draft of GMPLS, >we either need to re-cast this whole draft as "Egress Label Control" >or we need to generalize the text here as egress control that allows >the control of interface, component link and label. >I prefer the second option. no problem. changed to ... "one or more subobjects related to the output/downstream interface" >Compare with section 2.2 which is more general. > > To support Egress Control, an egress checks to see if the received > ERO contains an outgoing/downstream interface. If it does, the type > of the subobject or subobjects following the interface are examined. > If the associated LSP is unidirectional, one subobject is examined. > Two subobjects are examined for bidirectional LSPs. If the U-bit of > the subobject being examined is clear (0), then the value of the > label is copied into a new Label_Set object. Note, this Label_Set > object is for internal use only. This Label_Set object indicates the > label value that MUST be used for transmitting traffic associated > with the LSP on the indicated outgoing/downstream interface. >Not withstanding "this Label_Set object is for internal use only", I >find this text a bit peculiar! >You really just want to say that this subobject is used to specify the >label that the egress MUST apply to traffic that it forwards from this >LSP. (Compare with the next paragraph where you do not describe >creating an Upstream_Label object for internal use only.) >If you insist on talking about the Label_Set object, you will have to be >far more specific because there are four different varieties of that >object. I think the wording is consistent with RFC3473 and unambiguous. Please suggest alternate wording. > including if the listed label(s) are not acceptable or cannot be > supported in forwarding, SHOULD result in the generation of a PathErr > message containing a "Bad EXPLICIT_ROUTE object" error. >I'd prefer you to be more explicit... >... containing a "Routing Problem"/"Bad EXPLICIT_ROUTE object" error. sure, will use phrasing from rfc3209. >3. Security Considerations > >< This note clarifies procedures defined in [RFC3473]. As such, no new >< security considerations are introduced. > > This note reiterates procedures defined in [RFC3473], but does not > > define any new procedures. As such, no new security considerations > > are introduced. okay. ><5. References > >5. Normative References > >Need BCP 78, and 79 as informational references. >Also RFC 3668. will do, but do you really want me to reference BCP 79 and RFC 3668? >8. Intellectual Property > >Missing the personal disclaimer... > By submitting this Internet-Draft, I certify that any applicable > patent or other IPR claims of which I am aware have been disclosed, > and any of which I become aware will be disclosed, in accordance with > RFC 3668. sure. >Don't need the footer... >Generated on: Mon Mar 15 10:52:32 2004 picky, picky, picky... Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 05 Apr 2004 18:00:41 +0000 Message-ID: <008501c41b37$d223cf90$f99c9ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Additional CCAMP info now on the Web Date: Mon, 5 Apr 2004 18:58:24 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi, We have posted some additional CCAMP information at http://www.olddog.co.uk/ccamp.htm You can find a link to this from the CCAMP charter page http://www.ietf.org/html.charters/ccamp-charter.html At the moment, probably the most useful piece of information is the page that tracks the status of all CCAMP drafts. I'm sure you'll let me know if I have got something wrong or left something out. It would also be interesting to know what other information you would regard as useful. Cheers, Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 05 Apr 2004 17:37:45 +0000 Message-ID: <004501c41b34$3cbd3a20$f99c9ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Cc: Subject: draft-ietf-ccamp-gmpls-egress-control-00.txt Date: Mon, 5 Apr 2004 16:23:44 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi Lou, In Seoul we agreed that this draft would become a WG document and we talked a little about doing a working group last call immediately thereafter. Thanks for re-spinning the draft as a WG draft. There are, however, a few nits that I think you should tidy up before we do the last call. Perhaps others would like to pitch in now if they have any substantive comments before the last call. Thanks, Adrian Please give the intended category of the work... Proposed Category: Best Common Practice Please correct draft name as it appears in the title and footers. draft-ietf-ccamp-gmpls-egress-control-00.txt Abstract Please remove [bracketed] citation from abstract. Abstract This note clarifies the procedures for the control of a label used on an egress output/downstream interface. I think this would be better phrased as... This note clarifies the procedures for the control of the label used on output/downstream interface of the final (egress) Label Switching Router (LSR) of a Label Switched Path (LSP). 1. Background The ability to control a label used on an egress output/downstream interface was one of the early requirements for GMPLS. Again, rephrase as... The ability to control the label used on the output/downstream interface of an egress LSR was one of the early requirements for GMPLS. 2.1. ERO Procedures Egress Control occurs when the node processing an ERO is the egress and the ERO contains one or more label subobjects. In view of the text quoted from section 6 of an early draft of GMPLS, we either need to re-cast this whole draft as "Egress Label Control" or we need to generalize the text here as egress control that allows the control of interface, component link and label. I prefer the second option. Compare with section 2.2 which is more general. To support Egress Control, an egress checks to see if the received ERO contains an outgoing/downstream interface. If it does, the type of the subobject or subobjects following the interface are examined. If the associated LSP is unidirectional, one subobject is examined. Two subobjects are examined for bidirectional LSPs. If the U-bit of the subobject being examined is clear (0), then the value of the label is copied into a new Label_Set object. Note, this Label_Set object is for internal use only. This Label_Set object indicates the label value that MUST be used for transmitting traffic associated with the LSP on the indicated outgoing/downstream interface. Not withstanding "this Label_Set object is for internal use only", I find this text a bit peculiar! You really just want to say that this subobject is used to specify the label that the egress MUST apply to traffic that it forwards from this LSP. (Compare with the next paragraph where you do not describe creating an Upstream_Label object for internal use only.) If you insist on talking about the Label_Set object, you will have to be far more specific because there are four different varieties of that object. including if the listed label(s) are not acceptable or cannot be supported in forwarding, SHOULD result in the generation of a PathErr message containing a "Bad EXPLICIT_ROUTE object" error. I'd prefer you to be more explicit... ... containing a "Routing Problem"/"Bad EXPLICIT_ROUTE object" error. 3. Security Considerations < This note clarifies procedures defined in [RFC3473]. As such, no new < security considerations are introduced. > This note reiterates procedures defined in [RFC3473], but does not > define any new procedures. As such, no new security considerations > are introduced. <5. References >5. Normative References Need BCP 78, and 79 as informational references. Also RFC 3668. 8. Intellectual Property Missing the personal disclaimer... By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Don't need the footer... Generated on: Mon Mar 15 10:52:32 2004 Envelope-to: ccamp-data@psg.com Delivery-date: Sat, 03 Apr 2004 08:50:36 +0000 Message-ID: <406E7AFB.2060704@alcatel.be> Date: Sat, 03 Apr 2004 10:51:07 +0200 From: Dimitri.Papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.5) Gecko/20030925 MIME-Version: 1.0 To: LE ROUX Jean-Louis FTRD/DAC/LAN Cc: ccamp@ops.ietf.org, mpls@UU.NET, te-wg@ops.ietf.org, Jean Philippe Vasseur Subject: Re: RE : RE : TR : I-D ACTION:draft-ietf-tewg-interarea-mpls-te-req-00.txt Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed hi jean-louis: >>>Basically the solution must preserve IGP hierarchy, and thus must >>>preclude leaking of any TOPOLOGY related information accross areas, >>>including TE link information such as carried in ISIS Extended IS >>>reacheability TLV, or OSPF TE LSA Link TLV. Note that this also >>>precludes leaking of any summarized/aggregated TE information, such >>>that the advertisement of maximum unreserved bandwdith >> >>between an ABR >> >>>and any end-point LSR. We will clarify that in next revision. >> >>this would refine the above requirement (such TE link >>information would be precluded in any of its form) > > > Yes , and such precluding is IMHO a key requirement to preserve > the main interests of IGP area partitionning isn't it ? > > > >>>In return we definitely not preclude leaking of NON >> >>TOPOLOGY related >> >>>information such as TE node capabilities, provided that IGP >>>scalability is not impacted. >> >>more than probably, it is not within this kind of document to >>provide a kind of classification of such information but the >>latter would help in detailing the "discovery" concepts (see >>also section 7.12) in terms of functionality that would be >>required here: identity, capability & associated capability > > > You are right, we will try to be more precise as regards discovery, in > the next revision. > Not sure to well understand what you mean by associated capability ? i could have call it auxiliary or something like this, it would be capabilities attached to a node but that are not part of the information from which path computation for the inter-area lsp is performed and not part of the information from which the signaling decisions for the inter-area lsp is performed (i.e. typically the pce would fall in this category that would indicate an access to such pce) hope this clarifies, - dimitri. >>>>>5) section 7.7 >>>>> >>>>>"This may reduce the recovery delay, but with the risk of >>>>>multiple crankbacks, and sub-optimality. " >>>>> >>>>>i agree, but this is valid iff the head-end has initially >> >>computed >> >>>>>an end-to-end optimal path, >>>> >>>>more exactly this applies to contiguous LSP. For >> >>sub-optimality this >> >>>>applies to any kind of LSP. >>>> >>>> >>>> >>>>>also unclear if you refer also here to the provisioning delay ? >>> >>> >>>Actually this section is not dedicated to crankback routing >> >>as a path >> >>>computation method, it only addresses possible use of crankback in >>>case of network failure. Thus we refer here only to the recovery >>>delay. We may add a section dedicated to crankback routing >> >>in the next >> >>>revision >> >>i would agree to have a requirement document that includes a >>dedicated >>section on crankback functionality, hope the next release will clarify >> > > > We will do it, while trying to stay, as far as possible, solution > agnostic. > > Again thanks for these really helpfull comments > > Regards > > JL > -- Papadimitriou Dimitri E-mail : dimitri.papadimitriou@alcatel.be E-mail : dpapadimitriou@psg.com Webpage: http://psg.com/~dpapadimitriou/ Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium Phone : +32 3 240-8491 Envelope-to: ccamp-data@psg.com Delivery-date: Sat, 03 Apr 2004 02:11:53 +0000 Date: Fri, 2 Apr 2004 18:10:26 -0800 From: Alex Zinin Reply-To: Alex Zinin Message-ID: <264514881.20040402181026@psg.com> To: "Adrian Farrel" CC: "'Kireeti Kompella'" , ccamp@ops.ietf.org Subject: Re: Fw: I-D ACTION:draft-ietf-ccamp-gmpls-g709-07.txt MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Adrian, Ack. Thanks! -- Alex http://www.psg.com/~zinin/ Thursday, April 1, 2004, 6:30:06 AM, Adrian Farrel wrote: > Alex, > draft-ietf-ccamp-gmpls-g709 has successfully completed working group last call and has > been marked up to fix the minor comments that were raised. > Would you take this draft to the IESG on our behalf with a view to it becoming a standards > track RFC. > Thank you (let me know if there is any other formal process I should complete). > Adrian > ----- Original Message ----- > From: > To: > Sent: Thursday, April 01, 2004 2:11 PM > Subject: I-D ACTION:draft-ietf-ccamp-gmpls-g709-07.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 MPLS Signalling Extensions for G.709 Optical Transport Networks > Control >> Author(s) : D. Papadimitriou >> Filename : draft-ietf-ccamp-gmpls-g709-07.txt >> Pages : 21 >> Date : 2004-3-31 >> >> This document is a companion to the Generalized MPLS (GMPLS) >> signalling documents. It describes the technology specific >> information needed to extend GMPLS signalling to control Optical >> Transport Networks (OTN); it also includes the so-called pre-OTN >> developments. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-g709-07.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-g709-07.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-g709-07.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, 02 Apr 2004 23:19:59 +0000 Message-ID: <9D42C6E086250248810DCADA39CE7EFC011446A7@nimbus.chromisys.com> From: Ayan Banerjee To: 'Adrian Farrel' Cc: ccamp@ops.ietf.org Subject: RE: Layer One VPNs Date: Fri, 2 Apr 2004 15:18:49 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" I agree with Yakov. Ayan > -----Original Message----- > From: owner-ccamp@ops.ietf.org > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Yakov Rekhter > Sent: Tuesday, March 30, 2004 12:35 AM > To: Adrian Farrel > Cc: ccamp@ops.ietf.org > Subject: Layer One VPNs > > Adrian, > > > Hi, > > > > Although Layer One VPNs do not currently have a home in any IETF > > working group, we were the recipients of a liaison from ITU-T SG13 > > informing us about the work they are doing on this topic > and pointing > > us at > > > http://www.ietf.org/internet-drafts/draft-takeda-l1vpn-framework-00.tx > > t > > > > If anyone has comments on this work they can send them to > this mailing > > list (until another home is found in the IETF) or to the > authors direct. > > I think that this is important work, and that the home for > this work in the IETF should be the CCAMP WG. > > Yakov. > > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 02 Apr 2004 21:24:55 +0000 Message-ID: <032101c418f8$9603bd40$7a9c9ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Fw: I-D ACTION:draft-ietf-ccamp-gmpls-alarm-spec-00.txt Date: Fri, 2 Apr 2004 22:22:14 +0100 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_031D_01C41900.F3698610" This is a multi-part message in MIME format. ------=_NextPart_000_031D_01C41900.F3698610 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Forwarded as mailing list was not copied ----- Original Message ----- From: To: Sent: Friday, April 02, 2004 6:15 PM Subject: I-D ACTION:draft-ietf-ccamp-gmpls-alarm-spec-00.txt > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. > > Title : GMPLS - Communication of Alarm Information > Author(s) : L. Berger > Filename : draft-ietf-ccamp-gmpls-alarm-spec-00.txt > Pages : 17 > Date : 2004-4-1 > > This document describes an extension to Generalized MPLS (Multi- > Protocol Label Switching) signaling to support communication of alarm > information. GMPLS signaling already supports the control of alarm > reporting, but not the communication of alarm information. This > document presents both a functional description and GMPLS-RSVP > specifics of such an extension. This document also proposes > modification of the RSVP ERROR_SPEC object. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-alarm-spec-00.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > > Internet-Drafts are also available by anonymous FTP. Login with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-ccamp-gmpls-alarm-spec-00.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-ccamp-gmpls-alarm-spec-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_031D_01C41900.F3698610 Content-Type: application/octet-stream; name="ATT00762.dat" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="ATT00762.dat" Content-Type: text/plain Content-ID: <2004-4-2122933.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-gmpls-alarm-spec-00.txt ------=_NextPart_000_031D_01C41900.F3698610 Content-Type: text/plain; name="draft-ietf-ccamp-gmpls-alarm-spec-00.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="draft-ietf-ccamp-gmpls-alarm-spec-00.txt" Content-Type: text/plain Content-ID: <2004-4-2122933.I-D@ietf.org> ------=_NextPart_000_031D_01C41900.F3698610-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 02 Apr 2004 21:24:40 +0000 Message-ID: <032001c418f8$9522fa30$7a9c9ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Fw: I-D ACTION:draft-ietf-ccamp-gmpls-egress-control-00.txt Date: Fri, 2 Apr 2004 22:21:58 +0100 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_030D_01C41900.E9AD2730" This is a multi-part message in MIME format. ------=_NextPart_000_030D_01C41900.E9AD2730 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Forwarded as mailing list was not copied ----- Original Message ----- From: To: Sent: Friday, April 02, 2004 6:15 PM Subject: I-D ACTION:draft-ietf-ccamp-gmpls-egress-control-00.txt > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. > > Title : GMPLS Signaling Procedure For Egress Control > Author(s) : L. Berger > Filename : draft-ietf-ccamp-gmpls-egress-control-00.txt > Pages : 5 > Date : 2004-4-1 > > This note clarifies the procedures for the control of a label used on > an egress output/downstream interface. Such control is also known as > "Egress Control". Support for Egress Control is implicit in > Generalized Multi-Protocol Label Switching (GMPLS) Signaling. This > note does not modify GMPLS signaling mechanisms and procedures and > should be viewed as an informative clarification of GMPLS Signaling > - Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) > Extensions, [RFC3473]. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-egress-control-00.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > > Internet-Drafts are also available by anonymous FTP. Login with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-ccamp-gmpls-egress-control-00.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-ccamp-gmpls-egress-control-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_030D_01C41900.E9AD2730 Content-Type: application/octet-stream; name="ATT00776.dat" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="ATT00776.dat" Content-Type: text/plain Content-ID: <2004-4-2123056.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-gmpls-egress-control-00.txt ------=_NextPart_000_030D_01C41900.E9AD2730 Content-Type: text/plain; name="draft-ietf-ccamp-gmpls-egress-control-00.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="draft-ietf-ccamp-gmpls-egress-control-00.txt" Content-Type: text/plain Content-ID: <2004-4-2123056.I-D@ietf.org> ------=_NextPart_000_030D_01C41900.E9AD2730-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 02 Apr 2004 19:53:25 +0000 Message-Id: <4.3.2.7.2.20040402145128.06346fd8@wells.cisco.com> Date: Fri, 02 Apr 2004 14:52:12 -0500 To: raymond zhang From: Jean Philippe Vasseur Subject: Re: Some minor comments on the loose-path-opt draft Cc: raymond zhang , y.ikejiri@ntt.com, ccamp@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Hi Raymond, At 11:28 AM 4/2/2004 -0800, raymond zhang wrote: >Hi JP, > >[snop...] >>>2. Other comments: >>> >>>2.1. In section 4.3.1, page 7 >>>"- If a better path can be found, the LSR MUST >>> immediately send a Path Error to the head-end LSR >>> (Error code 25 (Notify), sub-code=6 (better path >>> exists))" >>> >>>I wonder if you should also add "and go ahead with reopt by sending RSVP >>>path messages for the new path". Otherwise there is no action described >>>for this mid-point LSR what it will do after it found a better path and >>>notify the HE LSR. >> >>In this case, the TE LSP is contiguous, hence the mid-point's role is >>just to notify of the existence of a better path (or the requirement for >>local maintenance) in some downstream area/AS. Note that it cannot >>locally reoptimize since the LSP ID would not match. Moreover, the >>intention is to let the Head-end LSR decide on whether to reoptimize >>depending on the TE LSP attributes (pending back-off, ...). >> >>Does that make sense ? > >yes it does... your're right that the mid-point LSR can not reopt on its >own since HE LSR controls the LSP ID but it will need to re-expand the ERO >to the next loop hop. That's what I meant. Excellent, we're in full sync, Thanks JP. >Cheers, >Raymond > > > > >>Thanks for your useful comments: they will be incorporated in the next >>revision. >> >>JP. >> >> >>>Regards, >>>Raymond >>> > > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 02 Apr 2004 19:30:39 +0000 Message-Id: <6.0.3.0.2.20040402112532.04240998@sa.infonet.com> Date: Fri, 02 Apr 2004 11:28:50 -0800 To: Jean Philippe Vasseur , raymond zhang From: raymond zhang Subject: Re: Some minor comments on the loose-path-opt draft Cc: y.ikejiri@ntt.com, ccamp@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Hi JP, [snop...] >>2. Other comments: >> >>2.1. In section 4.3.1, page 7 >>"- If a better path can be found, the LSR MUST >> immediately send a Path Error to the head-end LSR >> (Error code 25 (Notify), sub-code=6 (better path >> exists))" >> >>I wonder if you should also add "and go ahead with reopt by sending RSVP >>path messages for the new path". Otherwise there is no action described >>for this mid-point LSR what it will do after it found a better path and >>notify the HE LSR. > >In this case, the TE LSP is contiguous, hence the mid-point's role is just >to notify of the existence of a better path (or the requirement for local >maintenance) in some downstream area/AS. Note that it cannot locally >reoptimize since the LSP ID would not match. Moreover, the intention is to >let the Head-end LSR decide on whether to reoptimize depending on the TE >LSP attributes (pending back-off, ...). > >Does that make sense ? yes it does... your're right that the mid-point LSR can not reopt on its own since HE LSR controls the LSP ID but it will need to re-expand the ERO to the next loop hop. That's what I meant. Cheers, Raymond >Thanks for your useful comments: they will be incorporated in the next >revision. > >JP. > > >>Regards, >>Raymond >> >> > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 02 Apr 2004 17:25:31 +0000 Message-Id: <4.3.2.7.2.20040402120415.071e1128@wells.cisco.com> Date: Fri, 02 Apr 2004 12:24:07 -0500 To: "LE ROUX Jean-Louis FTRD/DAC/LAN" From: Jean Philippe Vasseur Subject: Re: Comments on draft-vasseur-ccamp-loose-path-reopt-00.txt Cc: , Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Hi Jean-Louis, At 06:06 PM 4/2/2004 +0200, LE ROUX Jean-Louis FTRD/DAC/LAN wrote: >Hi JP, Yuichi > >Please find below comments related to your loose path reoptimization ID > > >1) General Comment > >As regards applicability to inter-area/AS TE, this proposal seems really >relevant. Thanks, >IMHO, mid-point indication of better path/local maintenance may also be >extended to the case of strictly routed inter-area/AS TE-LSPs whose path >have been computed thanks to PCE based computation. >Indeed, if PCE based inter-area/AS path computation allows for timer >driven reoptimization (the HE LSR periodically sends a PC request to >check if there is a better e2e path), in return it does not allow for >event driven reoptimization (PCEs in downstream area/AS won't react to >any network event, as they are stateless). >Thus it may, IMHO, be relevant that an ABR/ASBR notify the HE LSR when >there is a better path or local maintenance in a donwstream area, on a >strictely routed inter-area/AS TE-LSPs whose path has been computed by >PCEs, so that the HE LSR trigger a PCE based e2e reoptimization. This is an excellent point, fully agree. >2) >Section 3: >IMHO it would be better to encode the ERO Expansion Request in the newly >defined LSP_ATTRIBUTE Object, or maybe in a >new dedicated object, as this is not, stictly speaking, an attribute of >the LSP. > >Clarification is required for the Note in 3.1: >Do you mean that the ERO Exapnsion Request bit itself could directly >trigger a change of component link in a bundle ? right >3) >Section 4.1 > >I would remove the following sentence "In particular, when a better path > >is discovered, one could conceivably envisage reoptimizing the TE LSP >on a mid-point LSR", >Your draft applies to contiguous LSPs. Mid-point reoptimization cannot >be envisaged anyway, for the simple reason that this would require >change in the LSP id that is under strict control of the HE LSR. I agree, you see what we meant here, but indeed, this could be confusing. >4) >Section 4.3.1 > "By default, >an LSR uses the IGP metric in their CSPF to compute the shortest path >that obeys a set of constraints." > >TE metric is the default metric in CSPF isn't it ? Well sure, this will be fixed. The point was just to mention the possibility to use either the IGP or the TE metric to compute the shortest path. >5) >Section 4.3.1 > >The operation that is triggered on a mid-point LSR, on receipt of a Path >with the ERO expansion desired bit set, is , IMHO not actually an ERO >expansion but just a new path compuation to the next loose hop. Right >Here the >mid-point LSR does not modify the ERO of the currently signaled LSP. >Strictly speaking the ERO expansion = Computation of the path to the >loose next hop + inclusion of the path in the ERO. >Actually ERO expansion is triggered on mid-points only when the HE LSR >starts the make-before-break procedure and signals a new LSP (new LSP >id). > >Thus I would suggest to change the name of the "ERO Expansion Request" >bit, to "Path Re-evaluation Desired" bit. > >Same comment in section 4.3.2: "In this mode, a mid-point LSR whose next >abstract node is a loose hop >can locally trigger an ERO expansion (when a configurable timer expires >or on event-driven basis" > >Actually the mid-point LSR does not trigger ERO expansion, but only path >re-evaluation This is right (more a question of terminology though). >6) >End of section 4.3.2: > >"Note that those modes are not exclusive: both the timer and even-driven > >reoptimization triggers can be implemented on the head-end and/or any >mid-point LSR with potentially different timer values for the timer >driven reoptimization case". > >Agree, but is there really an interest to configure at the same time: > -Timer driven reoptimization on head-end LSRs, ie peridoc HE >reopt request thanks the ERO Expansion bit > -Timer driven reoptimization on mid-point LSRs >This seems quite redundant as the periodic HE reopt request triggers >periodic path re-evaluation on mid-point LSRs. Well it is not quite redundant since there might be some cases where it might be desirable to configure different timers. For instance, consider the fact of a head-end LSR having inter-area/AS TE LSPs traversing different area/AS each having different characteristics. You may want to have a slow timer on the head-end LSR, and more aggressive timers in *some* areas/ASes (ABRs/ASBRs). Note that the receipt of a unsolicited "better path exists" notification can have the effect of delaying the next "ERO expansion request" sent by the LSR. >7) >I suggest adding the use of the RSVP Notify message as an alternative to >the RSVP PathErr message, for signaling of better path/local maintenance >to the Head-End , as this draft actually also applies to GMPLS. Well I would prefer to keep one message type for the purpose of notification rather than 2 (moreover PERR Notify also applies to GMPLS). >Hope this will help It does, thanks for your, as usual, very valuable comments. JP. >Regards > >JL Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 02 Apr 2004 16:34: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 : RE : TR : I-D ACTION:draft-ietf-tewg-interarea-mpls-te-req-00.txt Date: Fri, 2 Apr 2004 18:33:05 +0200 Message-ID: Thread-Topic: RE : TR : I-D ACTION:draft-ietf-tewg-interarea-mpls-te-req-00.txt Thread-Index: AcQYhcIyp7uZkgsvSFetYCNV94sw3AAR4b1w From: "LE ROUX Jean-Louis FTRD/DAC/LAN" To: Cc: , , , "Jean Philippe Vasseur" Hi Dimitri, See in-line > > Basically the solution must preserve IGP hierarchy, and thus must=20 > > preclude leaking of any TOPOLOGY related information accross areas,=20 > > including TE link information such as carried in ISIS Extended IS=20 > > reacheability TLV, or OSPF TE LSA Link TLV. Note that this also=20 > > precludes leaking of any summarized/aggregated TE information, such=20 > > that the advertisement of maximum unreserved bandwdith=20 > between an ABR=20 > > and any end-point LSR. We will clarify that in next revision. >=20 > this would refine the above requirement (such TE link=20 > information would be precluded in any of its form) Yes , and such precluding is IMHO a key requirement to preserve=20 the main interests of IGP area partitionning isn't it ? > > In return we definitely not preclude leaking of NON=20 > TOPOLOGY related=20 > > information such as TE node capabilities, provided that IGP=20 > > scalability is not impacted. >=20 > more than probably, it is not within this kind of document to=20 > provide a kind of classification of such information but the=20 > latter would help in detailing the "discovery" concepts (see=20 > also section 7.12) in terms of functionality that would be=20 > required here: identity, capability & associated capability You are right, we will try to be more precise as regards discovery, in the next revision. Not sure to well understand what you mean by associated capability ? > >>> 5) section 7.7 > >>>=20 > >>> "This may reduce the recovery delay, but with the risk of > >>> multiple crankbacks, and sub-optimality. " > >>>=20 > >>> i agree, but this is valid iff the head-end has initially=20 > computed=20 > >>> an end-to-end optimal path, > >>=20 > >> more exactly this applies to contiguous LSP. For=20 > sub-optimality this=20 > >> applies to any kind of LSP. > >>=20 > >>=20 > >>> also unclear if you refer also here to the provisioning delay ? > >=20 > >=20 > > Actually this section is not dedicated to crankback routing=20 > as a path=20 > > computation method, it only addresses possible use of crankback in=20 > > case of network failure. Thus we refer here only to the recovery=20 > > delay. We may add a section dedicated to crankback routing=20 > in the next=20 > > revision >=20 > i would agree to have a requirement document that includes a=20 > dedicated=20 > section on crankback functionality, hope the next release will clarify >=20 We will do it, while trying to stay, as far as possible, solution agnostic. Again thanks for these really helpfull comments Regards JL Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 02 Apr 2004 16:09:26 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: Comments on draft-vasseur-ccamp-loose-path-reopt-00.txt Date: Fri, 2 Apr 2004 18:06:41 +0200 Message-ID: Thread-Topic: Comments on draft-vasseur-ccamp-loose-path-reopt-00.txt Thread-Index: AcQCH+OQccr2mM1QTkKewTXvmKgZsAVw2z3A From: "LE ROUX Jean-Louis FTRD/DAC/LAN" To: "Jean Philippe Vasseur" , Cc: Hi JP, Yuichi Please find below comments related to your loose path reoptimization ID 1) General Comment As regards applicability to inter-area/AS TE, this proposal seems really relevant.=20 IMHO, mid-point indication of better path/local maintenance may also be extended to the case of strictly routed inter-area/AS TE-LSPs whose path have been computed thanks to PCE based computation. Indeed, if PCE based inter-area/AS path computation allows for timer driven reoptimization (the HE LSR periodically sends a PC request to check if there is a better e2e path), in return it does not allow for event driven reoptimization (PCEs in downstream area/AS won't react to any network event, as they are stateless).=20 Thus it may, IMHO, be relevant that an ABR/ASBR notify the HE LSR when there is a better path or local maintenance in a donwstream area, on a strictely routed inter-area/AS TE-LSPs whose path has been computed by PCEs, so that the HE LSR trigger a PCE based e2e reoptimization.=20 2) Section 3: IMHO it would be better to encode the ERO Expansion Request in the newly defined LSP_ATTRIBUTE Object, or maybe in a=20 new dedicated object, as this is not, stictly speaking, an attribute of the LSP. Clarification is required for the Note in 3.1: Do you mean that the ERO Exapnsion Request bit itself could directly trigger a change of component link in a bundle ? 3) Section 4.1 I would remove the following sentence "In particular, when a better path is discovered, one could conceivably envisage reoptimizing the TE LSP=20 on a mid-point LSR",=20 Your draft applies to contiguous LSPs. Mid-point reoptimization cannot be envisaged anyway, for the simple reason that this would require change in the LSP id that is under strict control of the HE LSR. 4) Section 4.3.1 "By default,=20 an LSR uses the IGP metric in their CSPF to compute the shortest path=20 that obeys a set of constraints."=20 TE metric is the default metric in CSPF isn't it ? 5) Section 4.3.1 The operation that is triggered on a mid-point LSR, on receipt of a Path with the ERO expansion desired bit set, is , IMHO not actually an ERO expansion but just a new path compuation to the next loose hop. Here the mid-point LSR does not modify the ERO of the currently signaled LSP.=20 Strictly speaking the ERO expansion =3D Computation of the path to the loose next hop + inclusion of the path in the ERO. Actually ERO expansion is triggered on mid-points only when the HE LSR starts the make-before-break procedure and signals a new LSP (new LSP id). Thus I would suggest to change the name of the "ERO Expansion Request" bit, to "Path Re-evaluation Desired" bit. Same comment in section 4.3.2: "In this mode, a mid-point LSR whose next abstract node is a loose hop=20 can locally trigger an ERO expansion (when a configurable timer expires=20 or on event-driven basis" Actually the mid-point LSR does not trigger ERO expansion, but only path re-evaluation 6) End of section 4.3.2: "Note that those modes are not exclusive: both the timer and even-driven reoptimization triggers can be implemented on the head-end and/or any=20 mid-point LSR with potentially different timer values for the timer=20 driven reoptimization case".=20 Agree, but is there really an interest to configure at the same time: -Timer driven reoptimization on head-end LSRs, ie peridoc HE reopt request thanks the ERO Expansion bit -Timer driven reoptimization on mid-point LSRs This seems quite redundant as the periodic HE reopt request triggers periodic path re-evaluation on mid-point LSRs. 7)=20 I suggest adding the use of the RSVP Notify message as an alternative to the RSVP PathErr message, for signaling of better path/local maintenance to the Head-End , as this draft actually also applies to GMPLS. Hope this will help Regards JL Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 02 Apr 2004 07:52:49 +0000 Message-ID: <406D1C2C.7060400@alcatel.be> Date: Fri, 02 Apr 2004 09:54:20 +0200 From: Dimitri.Papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.5) Gecko/20030925 MIME-Version: 1.0 To: "Pandian, Vijay" Cc: "Ong, Lyndon" , "'Lou Berger'" , Kireeti Kompella , ccamp@ops.ietf.org Subject: Re: Label type to be used Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed hi > I would like a clarification on the following three combinations of your > proposal: > > >> > [LSC, LSC] - label represents a G.709 OCh/lambda/port >> > [PSC, LSC] - label represents a G.709 OCh/lambda/port >> > [TDM, LSC] - label represents a G.709 OCh/lambda/port > > > What exactly you mean by OCh? optical channel > What exactly you mean by OCh/lambda/port? these combinations described in gmpls-routing tells what the label represents when considering both ends of the te link from their interface switching capability perspective - taking the examples here above it is either an optical channel, or a lambda or a port > Does it mean that the devices on both sides of such a TE-Link must be able > to generate and accept all these three types? If the answer is yes, then it > is not clear to me how a TDM/PSC capable device be able to do that. A TDM > device knows how to switch time slots and that's it. Does it make sense for > a TDM capable device that is also an LTE to advertise FSC capability for the > TE-Links? i don't think this FSC interpretation would be inline with the FSC definition, so the response to your last question is no thanks, - dimitri. > Thanks, > > Vijay > > > -----Original Message----- > From: Dimitri.Papadimitriou@alcatel.be > [mailto:Dimitri.Papadimitriou@alcatel.be] > Sent: Thursday, April 01, 2004 5:18 PM > To: Ong, Lyndon > Cc: 'Lou Berger'; Kireeti Kompella; ccamp@ops.ietf.org > Subject: Re: Label type to be used > > > hi lyndon, > > Ong, Lyndon wrote: > > >>Hi Dimitri, >> >>I think it was my mistake, in testing I have seen people use >>FSC to describe an interface to an opaque OXC with SDH framing >>when they wish to have the entire signal (minus some SDH >>overhead) switched rather than sorting through individual >>channels. On further reading of draft-ietf-ccamp-gmpls-routing-09.txt >>it looks like section 3.5 specifically describes this as a >>case where LSC would be advertised rather than FSC, since >>there is conceptually a single wavelength, is this >>still correct? > > > yes, this is why i have proposed the below to adapt the below > in-line with the following paragraph of section 3.5 > > " An interface on an opaque OXC handles a single wavelength, and > cannot switch multiple wavelengths as a whole. Thus, an interface on > an opaque OXC is always LSC, and not FSC, irrespective of whether > there is DWDM external to it." > > > thanks, > - dimitri. > > >>Thanks, >> >>Lyndon >> >>-----Original Message----- >>From: Dimitri.Papadimitriou@alcatel.be >>[mailto:Dimitri.Papadimitriou@alcatel.be] >>Sent: Saturday, March 27, 2004 4:31 AM >>To: Ong, Lyndon >>Cc: 'Lou Berger'; Kireeti Kompella; ccamp@ops.ietf.org >>Subject: Re: Label type to be used >> >> >>the proposal that makes a fully transparent Sonet/SDH encoded capable >>link appearing as [X,LSC] or [LSC,X], or [LSC,LSC] w/ a label defined as >>a port and/or lambda is aligned with the evolution of the definition >>towards OTN (coming from the so-called pre-OTN) technology and thus >>probably better than trying to retain the TDM value for it (with several >>flavours) >> >>so you would have something like this when trying to harmonize in >>between the several documents we have tnat deals with this specific >>representation issue, i also think it provides the distinction you're >>asking for b/w fiber and so-called clear channels: >> >>2.4.4. Lambda-Switch Capable >> >> If an interface is of type LSC, it means that the node receiving data >> over this interface can recognize and switch individual lambdas >> within the interface. An interface that allows only one lambda per >> interface, and switches just that lambda is of type LSC. >> > This includes interfaces that only support fully transparent SONET/SDH >> > signals, as defined in [GMPLS-SONET-SDH]. >> >>[...] >> >>2.4.7. Interface Switching Capabilities and Labels >> >> [PSC, PSC] - label is carried in the "shim" header [RFC3032] >> > [TDM, TDM] - label represents a timeslot ([GMPLS-SONET-SDH], >> [GMPLS-G709]) >> > [LSC, LSC] - label represents a G.709 OCh/lambda/port >> > [FSC, FSC] - label represents a fiber (i.e. physical port) >> > [PSC, TDM] - label represents a timeslot ([GMPLS-SONET-SDH], >> [GMPLS-G709]) >> > [PSC, LSC] - label represents a G.709 OCh/lambda/port >> > [PSC, FSC] - label represents a fiber >> > [TDM, LSC] - label represents a G.709 OCh/lambda/port >> > [TDM, FSC] - label represents a fiber >> > [LSC, FSC] - label represents a fiber >> >> > Note: except when explicitly indicated the label encoding MUST follow >> > the rules defined in [RFC3471] Section 3.2. >> >>ps: in fact one sees here that for the "timeslot" case, the switching >>type TDM value equates the encoding one >> >> >>Ong, Lyndon wrote: >> >> >>>Hi Lou, >>> >>>Your proposed text looks pretty good to me. >>> >>>Side note: is there a way that the >>>existing text can be clarified to distinguish >>>between the case of only one lambda allowed >>>on an interface and the case of fiber switching? >>> >>>Currently the text seems to allow an overlap >>>in the case of a non-channelized OC-12/48/etc. as in >>>a sense there is only one "lambda" but you would >>>typically request fiber switching. >>> >>>Cheers, >>> >>>Lyndon >>> >>>-----Original Message----- >>>From: Lou Berger [mailto:lberger@movaz.com] >>>Sent: Friday, March 26, 2004 11:17 AM >>>To: Kireeti Kompella >>>Cc: ccamp@ops.ietf.org; John Drake >>>Subject: RE: Label type to be used >>> >>> >>>Kireeti, >>> I think John's points on (a) and (c) are reasonable. I think the > > >>>only changes needed to the draft-ietf-ccamp-gmpls-routing-09.txt to make >>>this clear are: >>> >>> 2.4.4. Lambda-Switch Capable >>> >>> If an interface is of type LSC, it means that the node receiving data >>> over this interface can recognize and switch individual lambdas >>> within the interface. An interface that allows only one lambda per >>> interface, and switches just that lambda is of type LSC. >>> >>>> This includes interfaces that only support fully transparent SONET/SDH >>>> signals, as defined in [GMPLS-SONET-SDH]. >>> >>>and >>> [PSC, PSC] - label is carried in the "shim" header [RFC3032] >>> [TDM, TDM] - label represents a TDM time slot [GMPLS-SONET-SDH] >>> >>>> [LSC, LSC] - label represents a lambda/port >>> >>> [FSC, FSC] - label represents a port on an OXC >>> [PSC, TDM] - label represents a TDM time slot [GMPLS-SONET-SDH] >>> >>>> [PSC, LSC] - label represents a lambda/port >>> >>> [PSC, FSC] - label represents a port >>> >>>> [TDM, LSC] - label represents a lambda/port >>> >>> [TDM, FSC] - label represents a port >>> [LSC, FSC] - label represents a port >>> >>>Lou >>> >>>PS This matches all but one implementation we've interoperated with. >>> >>>At 01:49 PM 3/26/2004 -0500, John Drake wrote: >>> >>> >>> >>> >>> >>>>>-----Original Message----- >>>>>From: Kireeti Kompella >>>> >>>>[mailto:kireeti@juniper.net] >>>> >>>> >>>> >>>>>Sent: Thursday, March 18, 2004 9:58 AM >>>>>To: ccamp@ops.ietf.org >>>>>Subject: Label type to be used >>>>> >>>>>Hi, >>>>> >>>>>Arthi and Lou pointed out the following typos in the GMPLS routing doc >>>>>(draft-ietf-ccamp-gmpls-routing-09.txt) which is now in the RFC >>>>>Editor's queue: >>>>> >>>>>In section 2.4.7 is the following table defining the type of label >>>>>for various combinations of switching types: >>>>> >>>>> [PSC, PSC] - label is carried in the "shim" header [RFC3032] >>>>> [TDM, TDM] - label represents a TDM time slot [GMPLS-SONET-SDH] >>>>> [LSC, LSC] - label represents a lambda >>>>> [FSC, FSC] - label represents a port on an OXC >>>>> [PSC, TDM] - label represents a TDM time slot [GMPLS-SONET-SDH] >>>>> [PSC, LSC] - label represents a lambda >>>>> [PSC, FSC] - label represents a port >>>>> [TDM, LSC] - label represents a lambda >>>>> [TDM, FSC] - label represents a port >>>>> [LSC, FSC] - label represents a port >>>>> >>>>>The one at issue is [PSC, LSC]; above it says that the label >>>>>represents a lambda; and in the case of [PSC, TDM] with a fully >>>>>transparent signal, the above indicates the label represents a TDM >>>>>time slot. The proposal is to change this to: >>>>> >>>>> [PSC, PSC] - label is carried in the "shim" header [RFC3032] >>>>> [TDM, TDM] - label represents a TDM time slot [GMPLS-SONET-SDH] >>>>> [LSC, LSC] - label represents a lambda >>>>> [FSC, FSC] - label represents a port on an OXC >>>>> [PSC, TDM] - fully transparent signal: label represents a port >>>>> ("transparency" is defined in [GMPLS-SONET-SDH]) >>>>> [PSC, TDM] - non-transparent signal: label represents a TDM time >>>>> slot [GMPLS-SONET-SDH] >>>>> [PSC, LSC] - label represents a port >>>>> [PSC, FSC] - label represents a port >>>>> [TDM, LSC] - label represents a lambda >>>>> [TDM, FSC] - label represents a port >>>>> [LSC, FSC] - label represents a port >>>>> >>>>>Please respond by Friday 3/26, 5pm PST with comments on: >>>>> >>>>>a) do you agree with the above change? >>>> >>>>[John Drake] >>>> >>>>I don't have a problem with the [PSC, LSC] change but I don't >>>>understand the distinction between transparent and non-transparent >>>>TDM as it pertains to GMPLS routing. As I indicated in a previous >>>>e-mail, I think the transparent TDM case should be handled with a >>>>switching type of LSC and an encoding type of SDH/SONET, and I think >>>>that this should be specified in the SDH/SONET I-D, where the distinction >>>>between transparent and non-transparent TDM is defined, rather than in >>>>this document. >>>> >>>> >>>> >>>> >>>>>b) in your implementation today, what do expect the label to represent >>>>> i) in the case of [PSC, LSC]? >>>> >>>>[John Drake] >>>> >>>>Port/lambda >>>> >>>> >>>> >>>> >>>>> ii) in the case of [PSC, TDM] with a fully transparent signal? >>>>>c) if you implement as the draft says, would it be a hardship to change >>>>> this? >>>> >>>>[John Drake] >>>> >>>>N/A. Labels for SDH/SONET are defined in the SDH/SONET I-D and it's > > pretty > >>>>clear about which types of labels are in the transparent and > > non-transparent > >>>>TDM cases. >>>> >>>> >>>> >>>> >>>>>If we can get closure on this, I'll take up the task of modifying the >>>>>pending RFC with the ADs. >>>>> >>>>>Kireeti. >>>>>------- >>> >>> >>> > -- Papadimitriou Dimitri E-mail : dimitri.papadimitriou@alcatel.be E-mail : dpapadimitriou@psg.com Webpage: http://psg.com/~dpapadimitriou/ Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium Phone : +32 3 240-8491 Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 02 Apr 2004 07:41:27 +0000 Message-ID: <406D195A.8030308@alcatel.be> Date: Fri, 02 Apr 2004 09:42:18 +0200 From: Dimitri.Papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.5) Gecko/20030925 MIME-Version: 1.0 To: LE ROUX Jean-Louis FTRD/DAC/LAN Cc: ccamp@ops.ietf.org, mpls@UU.NET, te-wg@ops.ietf.org, Jean Philippe Vasseur Subject: Re: RE : TR : I-D ACTION:draft-ietf-tewg-interarea-mpls-te-req-00.txt Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: base64 aGkgamVhbi1sb3Vpcw0KDQp0aGFua3MgZm9yIHRoZSBjbGFyaWZpY2F0aW9uczsgc2VlIGluLWxp bmUgZm9yIHNvbWUgaGludHMNCg0KTEUgUk9VWCBKZWFuLUxvdWlzIEZUUkQvREFDL0xBTiB3cm90 ZToNCg0KPiBIaSBEaW1pdHJpLA0KPiANCj4gVGhhbmtzIGEgbG90IGZvciB0aGVzZSBjb21tZW50 cy4gU2VlIGFkZGl0aW9uYWwgY29tbWVudHMgb24gdG9wIG9mIEpQDQo+IGNvbW1lbnRzLg0KPiAN Cj4gQ2hlZXJzDQo+IA0KPiBKTA0KPiANCj4gDQo+PiAtLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0t LS0gRGUgOiBKZWFuIFBoaWxpcHBlIFZhc3NldXINCj4+IFttYWlsdG86anZhc3NldXJAY2lzY28u Y29tXSBFbnZveekgOiBtYXJkaSAzMCBtYXJzIDIwMDQgMTQ6MzYgwCA6DQo+PiBEaW1pdHJpLlBh cGFkaW1pdHJpb3VAYWxjYXRlbC5iZSBDYyA6IExFIFJPVVggSmVhbi1Mb3Vpcw0KPj4gRlRSRC9E QUMvTEFOOyBjY2FtcEBvcHMuaWV0Zi5vcmc7IG1wbHNAVVUuTkVUIE9iamV0IDogUmU6IFRSIDog SS1EDQo+PiAgQUNUSU9OOmRyYWZ0LWlldGYtdGV3Zy1pbnRlcmFyZWEtbXBscy10ZS1yZXEtMDAu dHh0DQo+PiANCj4+IA0KPj4gSGkgRGltaXRyaSwNCj4+IA0KPj4gVGhhbmtzIGZvciB5b3VyIHVz ZWZ1bCBjb21tZW50cyBoZXJlLiBTZWUgYmVsb3csDQo+PiANCj4+IEF0IDAyOjE4IFBNIDMvMzAv MjAwNCArMDIwMCwgRGltaXRyaS5QYXBhZGltaXRyaW91QGFsY2F0ZWwuYmUNCj4+IHdyb3RlOg0K Pj4gDQo+Pj4gaGkgamwsIGhlcmUgYmVsb3cgc2V2ZXJhbCBjb21tZW50cyBvbiB0aGlzIHVwZGF0 ZWQgdmVyc2lvbiBvZiB0aGUNCj4+PiAgZG9jdW1lbnQ6DQo+Pj4gDQo+Pj4gMSkgc2VjdGlvbiA1 LjMuMSBtZW50aW9uczoNCj4+PiANCj4+PiAiVGhlIHNvbHV0aW9uIE1VU1QgZW50aXJlbHkgcHJl c2VydmUgdGhlIGNvbmNlcHQgb2YgSUdQDQo+Pj4gaGllcmFyY2h5LiBJbiBvdGhlciB3b3Jkcywg Zmxvb2Rpbmcgb2YgVEUgbGluayBpbmZvcm1hdGlvbiBhY3Jvc3MNCj4+PiBhcmVhcyBNVVNUIGJl IHByZWNsdWRlZC4iDQo+Pj4gDQo+Pj4gc2VjdGlvbiA1LjMuMiBtZW50aW9uczoNCj4+PiANCj4+ PiAiVGhlIHNvbHV0aW9uIE1VU1QgYWxzbyBub3QgaW5jcmVhc2UgSUdQIGxvYWQgd2hpY2ggY291 bGQNCj4+PiBjb21wcm9taXNlIElHUCBzY2FsYWJpbGl0eS4gSW4gcGFydGljdWxhciwgYSBzb2x1 dGlvbiBzYXRpc2Z5aW5nDQo+Pj4gdGhvc2UgcmVxdWlyZW1lbnRzIE1VU1Qgbm90IHJlcXVpcmUg Zm9yIHRoZSBJR1AgdG8gY2Fycnkgc29tZQ0KPj4gDQo+PiB1bnJlYXNvbmFibGUNCj4+IA0KPj4+ IGFtb3VudCBvZiBleHRyYSBpbmZvcm1hdGlvbiBhbmQgTVVTVCBub3QgdW5yZWFzb25hYmx5DQo+ PiANCj4+IGluY3JlYXNlIHRoZQ0KPj4gDQo+Pj4gSUdQIGZsb29kaW5nIGZyZXF1ZW5jeS4iDQo+ Pj4gDQo+Pj4gYnV0IHNlY3Rpb24gNy4xMiB0ZWxsczoNCj4+PiANCj4+PiAiVGhlIGRpc2NvdmVy eSBtZWNoYW5pc20gU0hPVUxEIGJlIGFwcGxpY2FibGUgYWNyb3NzIG11bHRpcGxlIElHUA0KPj4+ IGFyZWFzLCBhbmQgU0hPVUxEIG5vdA0KPj4gDQo+PiBpbXBhY3QgdGhlDQo+PiANCj4+PiBJR1Ag c2NhbGFiaWxpdHksIHByb3ZpZGVkIHRoYXQgSUdQIGV4dGVuc2lvbnMgYXJlIHVzZWQgZm9yIHN1 Y2ggYQ0KPj4+ICBkaXNjb3ZlcnkgbWVjaGFuaXNtLiINCj4+PiANCj4+PiAtPiB3b3VsZCBpdCBi ZSBwb3NzaWJsZSB0byBhbGlnbiB0aGVzZSByZXF1aXJlbWVudHMsIGkgZ2V0IHRoZSAtPg0KPj4+ IGltcHJlc3Npb24gKHBsZWFzZSBjb25maXJtKSB0aGF0IHlvdSBwcmVjbHVkZSBURSBsaW5rIGlu Zm9ybWF0aW9uDQo+Pj4gYnV0IHlvdSB3b3VsZCBhbGxvdyBmb3Igbm9kZSBpbmZvcm1hdGlvbiAo YXV0by1tZXNoKSA/IG5vdGUgYWxzbw0KPj4+IHRoYXQgdGhlDQo+PiANCj4+IHNlY3Rpb24gNy4x MiBkb2Vzbid0DQo+PiANCj4+PiB0ZWxsIHVzIGEgbG90IGFib3V0IHRoZSBleHBlY3RlZCBkaXN0 cmlidXRpb24gb2YgdGhlIG1lc2gNCj4+IA0KPj4gVGhlIHNvbHV0aW9uIE1VU1QgcHJlY2x1ZGUg dG8gZmxvb2QgVEUtcmVsYXRlZCBsaW5rIGluZm9ybWF0aW9uIGFuZA0KPj4gTVVTVCBub3QgY29t cHJvbWlzZSB0aGUgSUdQIHNjYWxhYmlsaXR5IGluIGFueSBjaXJjdW1zdGFuY2VzLiBUaGF0DQo+ PiAgYmVpbmcgc2FpZCwgSUdQIGJhc2VkIG1lY2hhbmlzbXMgY2FuIGJlIHVzZWQgZm9yIHRoZSBk aXNjb3ZlcnkNCj4+IHdoaWNoIHdpbGwgcmVzcGVjdCB0aGUgcmVxdWlyZW1lbnQgbWVudGlvbmVk IGFib3ZlLA0KPiANCj4gQmFzaWNhbGx5IHRoZSBzb2x1dGlvbiBtdXN0IHByZXNlcnZlIElHUCBo aWVyYXJjaHksIGFuZCB0aHVzIG11c3QNCj4gcHJlY2x1ZGUgbGVha2luZyBvZiBhbnkgVE9QT0xP R1kgcmVsYXRlZCBpbmZvcm1hdGlvbiBhY2Nyb3NzIGFyZWFzLA0KPiBpbmNsdWRpbmcgVEUgbGlu ayBpbmZvcm1hdGlvbiBzdWNoIGFzIGNhcnJpZWQgaW4gSVNJUyBFeHRlbmRlZCBJUw0KPiByZWFj aGVhYmlsaXR5IFRMViwgb3IgT1NQRiBURSBMU0EgTGluayBUTFYuIE5vdGUgdGhhdCB0aGlzIGFs c28NCj4gcHJlY2x1ZGVzIGxlYWtpbmcgb2YgYW55IHN1bW1hcml6ZWQvYWdncmVnYXRlZCBURSBp bmZvcm1hdGlvbiwgc3VjaA0KPiB0aGF0IHRoZSBhZHZlcnRpc2VtZW50IG9mIG1heGltdW0gdW5y ZXNlcnZlZCBiYW5kd2RpdGggYmV0d2VlbiBhbiBBQlINCj4gYW5kIGFueSBlbmQtcG9pbnQgTFNS LiBXZSB3aWxsIGNsYXJpZnkgdGhhdCBpbiBuZXh0IHJldmlzaW9uLg0KDQp0aGlzIHdvdWxkIHJl ZmluZSB0aGUgYWJvdmUgcmVxdWlyZW1lbnQgKHN1Y2ggVEUgbGluayBpbmZvcm1hdGlvbg0Kd291 bGQgYmUgcHJlY2x1ZGVkIGluIGFueSBvZiBpdHMgZm9ybSkNCg0KPiBJbiByZXR1cm4gd2UgZGVm aW5pdGVseSBub3QgcHJlY2x1ZGUgbGVha2luZyBvZiBOT04gVE9QT0xPR1kgcmVsYXRlZA0KPiBp bmZvcm1hdGlvbiBzdWNoIGFzIFRFIG5vZGUgY2FwYWJpbGl0aWVzLCBwcm92aWRlZCB0aGF0IElH UA0KPiBzY2FsYWJpbGl0eSBpcyBub3QgaW1wYWN0ZWQuDQoNCm1vcmUgdGhhbiBwcm9iYWJseSwg aXQgaXMgbm90IHdpdGhpbiB0aGlzIGtpbmQgb2YgZG9jdW1lbnQgdG8NCnByb3ZpZGUgYSBraW5k IG9mIGNsYXNzaWZpY2F0aW9uIG9mIHN1Y2ggaW5mb3JtYXRpb24gYnV0IHRoZQ0KbGF0dGVyIHdv dWxkIGhlbHAgaW4gZGV0YWlsaW5nIHRoZSAiZGlzY292ZXJ5IiBjb25jZXB0cyAoc2VlDQphbHNv IHNlY3Rpb24gNy4xMikgaW4gdGVybXMgb2YgZnVuY3Rpb25hbGl0eSB0aGF0IHdvdWxkIGJlDQpy ZXF1aXJlZCBoZXJlOiBpZGVudGl0eSwgY2FwYWJpbGl0eSAmIGFzc29jaWF0ZWQgY2FwYWJpbGl0 eQ0KDQo+Pj4gMikgc2VjdGlvbiA3LjMNCj4+PiANCj4+PiAiICAgSW4gdGhlIGNvbnRleHQgb2Yg dGhpcyByZXF1aXJlbWVudCBkb2N1bWVudCwgYW4gb3B0aW1hbCBwYXRoDQo+Pj4gaXMgZGVmaW5l ZCBhcyB0aGUgc2hvcnRlc3QgcGF0aCBhY3Jvc3MgbXVsdGlwbGUgYXJlYXMgdGFraW5nIGludG8N Cj4+PiAgYWNjb3VudCBlaXRoZXIgdGhlIElHUCBvciBURSBtZXRyaWMuICINCj4+PiANCj4+PiBh cmUgeW91IHJlZmVycmluZyBoZXJlIHRvIA0KPj4+IDxodHRwOi8vd3d3LmlldGYub3JnL2ludGVy bmV0LWRyYWZ0cy9kcmFmdC1pZXRmLXRld2ctdGUtbWV0cmkNCj4+IA0KPj4gYy1pZ3AtMDIudA0K Pj4gDQo+Pj4geHQ+DQo+Pj4gDQo+Pj4gd291bGQgeW91IGNsYXJpZnkgPw0KPj4gDQo+PiBTdXJl LCB3ZSB3aWxsIGFkZCBzb21lIHRleHQuIFRoZSByZWFzb24gZm9yIHRoaXMgY2xhcmlmaWNhdGlv biBpcw0KPj4gdGhhdCB0aGVyZSBhcmUgYSBtdWx0aXR1ZGUgb2YgZGVmaW5pdGlvbnMgZm9yIGFu IG9wdGltYWwgcGF0aDoNCj4+IHBhdGhzIHRoYXQgbWluaW1pemUgdGhlIG1heCBsaW5rIHV0aWxp emF0aW9uLCBjYWxsIHNldCB1cCBmYWlsdXJlLA0KPj4gLi4uIGhlcmUgd2UganVzdCByZWZlciB0 byB0aGUgYWJpbGl0eSB0byBjb21wdXRlIGEgc2hvcnRlc3QgcGF0aA0KPj4gKHVzaW5nIGVpdGhl ciB0aGUgSUdQIG9yIFRFIG1ldHJpYykuDQo+PiANCj4+IA0KPj4gDQo+Pj4gMykgc2VjdGlvbiA3 LjMNCj4+PiANCj4+PiBpdCBpcyBub3QgY2xlYXIgZm9yIG1lIHdoYXQgaXMgYmVoaW5kIHRoZSBs YXN0IHBhcnQgb2YgdGhlDQo+Pj4gZm9sbG93aW5nIHNlbnRlbmNlDQo+Pj4gDQo+Pj4gIlNvIGEg c29sdXRpb24gc2hvdWxkIHN1cHBvcnQgYm90aCBtZWNoYW5pc21zLCBhbmQgU0hPVUxEIGFsbG93 IA0KPj4+IHRoZSBvcGVyYXRvciB0byBzZWxlY3QgYnkgY29uZmlndXJhdGlvbiwgYW5kIG9uIGEN Cj4+IA0KPj4gcGVyLUxTUCBiYXNpcywgdGhlDQo+PiANCj4+PiByZXF1aXJlZCBsZXZlbCBvZiBv cHRpbWFsaXR5LiAiDQo+Pj4gDQo+Pj4gd2hhdCBpcyBtZWFudCBieSAibGV2ZWwgb2Ygb3B0aW1h bGl0eSIgPyBpcyBpdCBzaW1wbHkgIm9wdGltYWwgLSANCj4+PiBzdWItb3B0aW1hbCIgb3IgZG8g eW91IGhhdmUgc29tZXRoaW5nIGVsc2UgaW4gbWluZCA/DQo+PiANCj4+IFdlIHdpbGwgY2xhcmlm eS4gVGhlIGlkZWEgaXMgdGhhdCB0aGUgYWJpbGl0eSB0byBjb21wdXRlIGFuIGVuZCB0bw0KPj4g ZW5kIHNob3J0ZXN0IHBhdGggbWF5IG5vdCBiZSByZXF1aXJlZCBmb3IgYWxsIGludGVyLWFyZWEg VEUgTFNQcy4gDQo+PiBIZW5jZSB0aGUgc29sdXRpb24gc2hvdWxkIGFsbG93IHRoZSBvcGVyYXRv ciB0byBzZWxlY3QgdGhlDQo+PiBhcHByb3ByaWF0ZSBwYXRoIGNvbXB1dGF0aW9uIG1ldGhvZC4N Cj4gDQo+IA0KPiBJIHNlZSB5b3VyIHBvaW50IGhlcmUuIEJhc2ljYWxseSB0aGVyZSBhcmUgdHdv IHBvc3NpYmxlIGFwcHJvYWNoZXMNCj4gZm9yIExTUCBjb25maWd1YXRpb24gLU9wdGlvbiAxOiBD b25maWd1cmUgb25seSB0aGUgZGVzaXJlZCBsZXZlbCBvZg0KPiBvcHRpbWFsaXR5OiBPcHRpbWFs LCBzdWItb3B0aW1hbCwgdGhlbiB0aGUgaGVhZC1lbmQgY2hvb3NlIHRoZQ0KPiBjb3JyZXNwb25k aW5nIHBhdGggY29tcHV0YXRpb24gYXBwcm9hY2guIC1PcHRpb24gMjogQ29uZmlndXJlDQo+IGRp cmVjdGx5IHRoZSBkZXNpcmVkIHBhdGggY29tcHV0YXRpb24gbWV0aG9kOiBlLmcuIEVSTyBleHBh bnNpb24gb3INCj4gUENFIGNvbXB1dGF0aW9uDQo+IA0KPiBPcHRpb24gMSBpcyBJTUhPIHRvbyBn ZW5lcmljLCBhbmQgYSBTZXJ2aWNlIFByb3ZpZGVyIHdhbnRzIHRvIGhhdmUNCj4gZGlyZWN0IGNv bnRyb2wgb24gdGhlIHNlbGVjdGlvbiBvZiB0aGUgcGF0aCBjb21wdXRhdGlvbiBtZXRob2QuDQo+ IA0KPiBXZSB3aWxsIGNsYXJpZnkgdGhhdCBpbiBuZXh0IHJldmlzaW9uDQoNCm9rDQoNCj4+PiA0 KSBzZWN0aW9uIDcuNA0KPj4+IA0KPj4+ICJBbm90aGVyIGV4YW1wbGUgaXMgdGhlIHJlcXVpcmVt ZW50IHRvIHNldCB1cCBtdWx0aXBsZSBURQ0KPj4gDQo+PiBMU1BzIGJldHdlZW4NCj4+IA0KPj4+ IGEgcGFpciBvZiBMU1JzIHJlc2lkaW5nIGluIGRpZmZlcmVudCBJR1AgYXJlYXMgaW4gY2FzZSBh DQo+PiANCj4+IHNpbmdsZSBURQ0KPj4gDQo+Pj4gTFNQIHNhdGlzZnlpbmcgdGhlIHNldCBvZiBy ZXF1aXJlbWVudHMgY291bGQgbm90IGJlIGZvdW5kLiAiDQo+Pj4gDQo+Pj4gd2h5IGluIHN1Y2gg YSBjYXNlIGRpdmVyc2l0eSB3b3VsZCBiZSBkZXNpcmFibGUgPw0KPj4gDQo+PiBmb3IgZWl0aGVy IHBhdGggcHJvdGVjdGlvbiBvciBsb2FkIGJhbGFuY2luZyB3aGlsZSBtaW5pbWl6aW5nIHRoZQ0K Pj4gaW1wYWN0IGluIGNhc2Ugb2YgZmFpbHVyZS4NCj4+IA0KPj4gDQo+Pj4gZ290IHRoZSBpbXBy ZXNzaW9uIHRoYXQgaWYgYSBzaW5nbGUgcGF0aCB3b3VsZCBoYXZlIGJlZW4gZmVhc2libGUNCj4+ PiBpdCB3b3VsZCBoYXZlIGJlZW4gc2VsZWN0ZWQgaW4gdGhpcyBjYXNlIC0gaXNuJ3QgaXQgPw0K Pj4gDQo+PiBUaGF0IGJlaW5nIHNhaWQsIHdlIG5lZWQgdG8gcmVwaHJhc2UsIEkgYWdyZWUgd2l0 aCB5b3UgdGhhdCB0aGlzDQo+PiBwYXJhZ3JhcGggaXMgbm90IGNsZWFyLiBJdCBzaG91bGQgcmVh ZDoNCj4+IA0KPj4gIkFub3RoZXIgZXhhbXBsZSBpcyB0aGUgcmVxdWlyZW1lbnQgdG8gc2V0IHVw IG11bHRpcGxlIFRFIExTUHMNCj4+IGJldHdlZW4gYSBwYWlyIG9mIExTUnMgcmVzaWRpbmcgaW4g ZGlmZmVyZW50IElHUCBhcmVhcy4gRm9yDQo+PiBpbnN0YW5jZSwgdGhpcyB3b3VsZCBvY2N1ciBp ZiBURSBMU1Agc2F0aXNmeWluZyBmb3IgaW5zdGFuY2UgdGhlDQo+PiBiYW5kd2lkdGggcmVxdWly ZW1lbnQgY291bGQgYmUgZm91bmQsIGhlbmNlLCByZXF1aXJpbmcgdG8gc2V0IHVwDQo+PiBtdWx0 aXBsZSBURSBMU1BzIg0KPj4gDQo+PiANCj4+PiA1KSBzZWN0aW9uIDcuNw0KPj4+IA0KPj4+ICJU aGlzIG1heSByZWR1Y2UgdGhlIHJlY292ZXJ5IGRlbGF5LCBidXQgd2l0aCB0aGUgcmlzayBvZiAN Cj4+PiBtdWx0aXBsZSBjcmFua2JhY2tzLCBhbmQgc3ViLW9wdGltYWxpdHkuICAiDQo+Pj4gDQo+ Pj4gaSBhZ3JlZSwgYnV0IHRoaXMgaXMgdmFsaWQgaWZmIHRoZSBoZWFkLWVuZCBoYXMgaW5pdGlh bGx5DQo+Pj4gY29tcHV0ZWQgYW4gZW5kLXRvLWVuZCBvcHRpbWFsIHBhdGgsDQo+PiANCj4+IG1v cmUgZXhhY3RseSB0aGlzIGFwcGxpZXMgdG8gY29udGlndW91cyBMU1AuIEZvciBzdWItb3B0aW1h bGl0eQ0KPj4gdGhpcyBhcHBsaWVzIHRvIGFueSBraW5kIG9mIExTUC4NCj4+IA0KPj4gDQo+Pj4g YWxzbyB1bmNsZWFyIGlmIHlvdSByZWZlciBhbHNvIGhlcmUgdG8gdGhlIHByb3Zpc2lvbmluZyBk ZWxheSA/DQo+IA0KPiANCj4gQWN0dWFsbHkgdGhpcyBzZWN0aW9uIGlzIG5vdCBkZWRpY2F0ZWQg dG8gY3JhbmtiYWNrIHJvdXRpbmcgYXMgYSBwYXRoDQo+IGNvbXB1dGF0aW9uIG1ldGhvZCwgIGl0 IG9ubHkgYWRkcmVzc2VzIHBvc3NpYmxlIHVzZSBvZiBjcmFua2JhY2sgaW4NCj4gY2FzZSBvZiBu ZXR3b3JrIGZhaWx1cmUuIFRodXMgd2UgcmVmZXIgaGVyZSBvbmx5IHRvIHRoZSByZWNvdmVyeQ0K PiBkZWxheS4gV2UgbWF5IGFkZCBhIHNlY3Rpb24gZGVkaWNhdGVkIHRvIGNyYW5rYmFjayByb3V0 aW5nIGluIHRoZQ0KPiBuZXh0IHJldmlzaW9uDQoNCmkgd291bGQgYWdyZWUgdG8gaGF2ZSBhIHJl cXVpcmVtZW50IGRvY3VtZW50IHRoYXQgaW5jbHVkZXMgYSBkZWRpY2F0ZWQgDQpzZWN0aW9uIG9u IGNyYW5rYmFjayBmdW5jdGlvbmFsaXR5LCBob3BlIHRoZSBuZXh0IHJlbGVhc2Ugd2lsbCBjbGFy aWZ5DQoNCj4+PiBlZGl0b3JpYWxseSBzcGVha2luZyBpdCBpcyBhbHNvIGEgYml0IHVuY2xlYXIg d2h5IHlvdSd2ZSBzcGxpdHRlZA0KPj4+ICBzZWN0aW9uIDcuNyBhbmQgc2VjdGlvbiA3LjggYm90 aCByZWZlcnMgdG8gaW50ZXItYXJlYSBsc3ANCj4+PiByZWNvdmVyeQ0KPj4+IA0KPiANCj4gDQo+ IFllcyB5b3UgYXJlIHJpZ2h0LCBib3RoIHNlY3Rpb25zIHJlZmVyIHRvIGxzcCByZWNvdmVyeSBC YXNpY2FsbHkNCj4gc2VjdGlvbiA3LjcgZGVhbHMgd2l0aCBMU1AgcmVyb3V0aW5nIGFuZCBzZWN0 aW9uIDcuOCBpcyBkZWRpY2F0ZWQgdG8NCj4gRmFzdCBSZXJvdXRlIHByb3RlY3Rpb24gV2Ugd2ls bCB1cGRhdGUgYXMgZm9sbG93cyA3LjcgTFNQIHJlY292ZXJ5IA0KPiA3LjcuMSBMU1AgcmVyb3V0 aW5nIDcuNy4yIEZhc3QgUmVyb3V0ZQ0KDQpvaw0KDQo+Pj4gNikgc2VjdGlvbiA3LjExDQo+Pj4g DQo+Pj4gd291bGQgaXQgYmUgcG9zc2libGUgdG8gbWVudGlvbiB3aGF0J3MgZXhwZWN0ZWQgKG9y IG5vdCBleHBlY3RlZCkNCj4+PiBpbiB0ZXJtcyBhbHNvIG9mIGhhcmQgcHJlZW1wdGlvbiA/DQo+ PiANCj4+IG9rDQo+IA0KPiANCj4+IA0KPj4+IDcpIHNlY3Rpb24gOC4yDQo+Pj4gDQo+Pj4gd2hh dCdzIG1lYW50IGJ5IHN0YWJpbGl0eSA/IGllIHN0YWJpbGl0eSBvZiB3aGF0ID8gKGZvcg0KPj4g DQo+PiBpbnN0YW5jZSwgYXMgaQ0KPj4gDQo+Pj4gcmVhZCB0aGUgZG9jdW1lbnQsIGJ1dCBwbGVh c2UgY29ycmVjdCBtZSwgc3RhYmlsaXR5IGFuZA0KPj4gDQo+PiByZS1vcHRpbWl6YXRpb24NCj4+ IA0KPj4+IGFyZSBpbWhvIHR3byBmZWF0dXJlcyB0aGF0IGFyZSBnb2luZyBpbiBzb21laG93IG9w cG9zaXRlDQo+PiANCj4+IGRpcmVjdGlvbnMgc28gYQ0KPj4gDQo+Pj4gdHJhZGUtb2ZmIGhhcyB0 byBiZSBmb3VuZCBoZXJlKQ0KPj4gDQo+PiBXZSB3aWxsIGNsYXJpZnkuDQo+PiANCj4+IHRoYW5r cyBmb3IgeW91ciBjb21tZW50cyAhDQo+PiANCj4+IEpQLg0KPj4gDQo+PiANCj4+PiB0aGFua3Mg aW4gYWR2YW5jZSwgLSBkaW1pdHJpLg0KPj4+IA0KPj4+IExFIFJPVVggSmVhbi1Mb3VpcyBGVFJE L0RBQy9MQU4gd3JvdGU6DQo+Pj4gDQo+Pj4gDQo+Pj4+IEhpIGFsbCwgVGhhbmtzIGluIGFkdmFu Y2UgZm9yIHlvdXIgY29tbWVudHMgb24gdGhpcyBuZXcNCj4+Pj4gcmV2aXNpb24gb2YNCj4+IA0K Pj4gaW50ZXItYXJlYQ0KPj4gDQo+Pj4+IFRFIHJlcXVpcmVtZW50cy4gUmVnYXJkcywgSkwNCj4+ Pj4gDQo+Pj4+IA0KPj4+Pj4gQSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20g dGhlIG9uLWxpbmUNCj4+Pj4+IEludGVybmV0LURyYWZ0cyBkaXJlY3Rvcmllcy4gVGhpcyBkcmFm dCBpcyBhIHdvcmsgaXRlbSBvZiB0aGUNCj4+Pj4+IEludGVybmV0IFRyYWZmaWMgRW5naW5lZXJp bmcgV29ya2luZyBHcm91cCBvZiB0aGUgSUVURi4NCj4+Pj4+IA0KPj4+Pj4gVGl0bGUgICAgICAg ICAgIDogUmVxdWlyZW1lbnRzIGZvciBJbnRlci1hcmVhIE1QTFMgVHJhZmZpYw0KPj4+PiANCj4+ Pj4gRW5naW5lZXJpbmcNCj4+Pj4gDQo+Pj4+IA0KPj4+Pj4gQXV0aG9yKHMpICAgICAgIDogSi4g TGUgUm91eCwgZXQgYWwuIEZpbGVuYW1lICAgICAgICA6DQo+PiANCj4+IGRyYWZ0LWlldGYtdGV3 Zy1pbnRlcmFyZWEtbXBscy10ZS1yZXEtMDAudHh0DQo+PiANCj4+Pj4+IFBhZ2VzICAgICAgICAg ICA6IDIwIERhdGUgICAgICAgICAgICA6IDIwMDQtMy0yNg0KPj4+Pj4gDQo+Pj4+PiBUaGlzIGRv Y3VtZW50IGxpc3RzIGEgZGV0YWlsZWQgc2V0IG9mIGZ1bmN0aW9uYWwNCj4+IA0KPj4gcmVxdWly ZW1lbnRzIGZvciB0aGUNCj4+IA0KPj4+Pj4gc3VwcG9ydCBvZiBpbnRlci1hcmVhIE1QTFMgVHJh ZmZpYyBFbmdpbmVlcmluZyAoaW50ZXItYXJlYQ0KPj4gDQo+PiBNUExTIFRFKQ0KPj4gDQo+Pj4+ PiB3aGljaCBjb3VsZCBzZXJ2ZSBhcyBhIGd1aWRlbGluZSB0byBkZXZlbG9wIHRoZSByZXF1aXJl ZCBzZXQNCj4+Pj4+IG9mIHByb3RvY29sIGV4dGVuc2lvbnMuDQo+Pj4+PiANCj4+Pj4+IEEgVVJM IGZvciB0aGlzIEludGVybmV0LURyYWZ0IGlzOiANCj4+Pj4+IGh0dHA6Ly93d3cuaWV0Zi5vcmcv aW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYtdGV3Zy1pbnRlcmFyDQo+IA0KPiBlYS1tcGxzLXRl DQo+IA0KPj4+PiAtcg0KPj4+IA0KPj4+IGVxLTAwLnR4dA0KPj4+IA0KPj4+IA0KPj4+PiBUbyBy ZW1vdmUgeW91cnNlbGYgZnJvbSB0aGUgSUVURiBBbm5vdW5jZW1lbnQgbGlzdCwgc2VuZCBhDQo+ Pj4+IG1lc3NhZ2UgdG8gaWV0Zi1hbm5vdW5jZS1yZXF1ZXN0IHdpdGggdGhlIHdvcmQgdW5zdWJz Y3JpYmUgaW4NCj4+Pj4gdGhlIGJvZHkgb2YgdGhlIG1lc3NhZ2UuDQo+Pj4+IA0KPj4+PiBJbnRl cm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91cyBGVFAuIExvZ2luIHdp dGgNCj4+Pj4gdGhlIHVzZXJuYW1lICJhbm9ueW1vdXMiIGFuZCBhIHBhc3N3b3JkIG9mIHlvdXIg ZS1tYWlsIGFkZHJlc3MuDQo+Pj4+IEFmdGVyIGxvZ2dpbmcgaW4sIHR5cGUgImNkIGludGVybmV0 LWRyYWZ0cyIgYW5kIHRoZW4gImdldA0KPj4+PiBkcmFmdC1pZXRmLXRld2ctaW50ZXJhcmVhLW1w bHMtdGUtcmVxLTAwLnR4dCIuDQo+Pj4+IA0KPj4+PiBBIGxpc3Qgb2YgSW50ZXJuZXQtRHJhZnRz IGRpcmVjdG9yaWVzIGNhbiBiZSBmb3VuZCBpbiANCj4+Pj4gaHR0cDovL3d3dy5pZXRmLm9yZy9z aGFkb3cuaHRtbCBvciANCj4+Pj4gZnRwOi8vZnRwLmlldGYub3JnL2lldGYvMXNoYWRvdy1zaXRl cy50eHQNCj4+PiANCj4+IC0tIFBhcGFkaW1pdHJpb3UgRGltaXRyaSBFLW1haWwgOiBkaW1pdHJp LnBhcGFkaW1pdHJpb3VAYWxjYXRlbC5iZSANCj4+IEUtbWFpbCA6IGRwYXBhZGltaXRyaW91QHBz Zy5jb20gV2VicGFnZToNCj4+IGh0dHA6Ly9wc2cuY29tL35kcGFwYWRpbWl0cmlvdS8gQWRkcmVz czogRnIuIFdlbGxlc3BsZWluIDEsIEItMjAxOA0KPj4gQW50d2VycGVuLCBCZWxnaXVtIFBob25l ICA6ICszMiAzIDI0MC04NDkxDQo+PiANCj4+IA0KPiANCj4gDQoNCi0tIA0KUGFwYWRpbWl0cmlv dSBEaW1pdHJpDQpFLW1haWwgOiBkaW1pdHJpLnBhcGFkaW1pdHJpb3VAYWxjYXRlbC5iZQ0KRS1t YWlsIDogZHBhcGFkaW1pdHJpb3VAcHNnLmNvbQ0KV2VicGFnZTogaHR0cDovL3BzZy5jb20vfmRw YXBhZGltaXRyaW91Lw0KQWRkcmVzczogRnIuIFdlbGxlc3BsZWluIDEsIEItMjAxOCBBbnR3ZXJw ZW4sIEJlbGdpdW0NClBob25lICA6ICszMiAzIDI0MC04NDkxDQoNCg== Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 02 Apr 2004 06:13:06 +0000 Message-Id: <5.1.1.9.2.20040402150722.05a91c70@imf.m.ecl.ntt.co.jp> Date: Fri, 02 Apr 2004 15:11:51 +0900 To: Tomohiro Otani , "Adrian Farrel" , From: Tomonori TAKEDA Subject: Re: Layer One VPNs Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP"; format=flowed Content-Transfer-Encoding: 7bit Hi, Tomohiro Thank you for your comments. Let me try to answer your question. First of all, these two drafts differ in terms of where it comse from. The L1VPN framework ID summarizes the work in ITU-T SG13, while the GVPN ID is a solution draft proposed directly to IETF. Note that the L1VPN framework ID covers L1VPN components addressed in the GVPN draft where they are inserted within a solution context. The L1VPN framework ID "intends to set a framework of requirements and architectures into which all possible solutions can fit", as is stated in the ID. To me, the L1VPN framework ID covers wide range of scenarios, with no protocol proposal. Hope this clarifies. Best regards, At 10:25 04/03/30 +0900, Tomohiro Otani wrote: >Hi Aridian > >I also agree to investigate this item as a WG document. >Is this related to a former WG document of >"draft-ouldbrahim-ppvpn-gvpn-bgpgmpls-xx.txt" > >Regards, > >tomo > >At 11:28 04/03/13 +0000, Adrian Farrel wrote: > >Hi, > > > >Although Layer One VPNs do not currently have a home in any IETF working > >group, we were > >the recipients of a liaison from ITU-T SG13 informing us about the work > >they are doing on > >this topic and pointing us at > >http://www.ietf.org/internet-drafts/draft-takeda-l1vpn-framework-00.txt > > > >If anyone has comments on this work they can send them to this mailing list > >(until another > >home is found in the IETF) or to the authors direct. > > > >Thanks, > >Adrian > >------------------------------------ >Tomohiro Otani >KDDI R&D Laboratories, Inc. >Optical network architecture lab. >2-1-15 Ohara Kamifukuoka Saitama, 356-8502, Japan >TEL: +81-49-278-7357 >FAX: +81-49-278-7811 >E-mail: otani@kddilabs.jp >------------------------------------ ----- Tomonori TAKEDA NTT Network Service Systems Lab. Phone: +81-422-59-7434 Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 02 Apr 2004 03:46:19 +0000 Message-ID: <5533E74FC0108E41A8217C0899CA56CF081D46@mach5.sycamorenet.com> From: "Pandian, Vijay" To: "'Dimitri.Papadimitriou@alcatel.be'" , "Ong, Lyndon" Cc: 'Lou Berger' , Kireeti Kompella , ccamp@ops.ietf.org Subject: RE: Label type to be used Date: Thu, 1 Apr 2004 22:49:22 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Dimitri, I would like a clarification on the following three combinations of your proposal: > > [LSC, LSC] - label represents a G.709 OCh/lambda/port > > [PSC, LSC] - label represents a G.709 OCh/lambda/port > > [TDM, LSC] - label represents a G.709 OCh/lambda/port What exactly you mean by OCh? What exactly you mean by OCh/lambda/port? Does it mean that the devices on both sides of such a TE-Link must be able to generate and accept all these three types? If the answer is yes, then it is not clear to me how a TDM/PSC capable device be able to do that. A TDM device knows how to switch time slots and that's it. Does it make sense for a TDM capable device that is also an LTE to advertise FSC capability for the TE-Links? Thanks, Vijay -----Original Message----- From: Dimitri.Papadimitriou@alcatel.be [mailto:Dimitri.Papadimitriou@alcatel.be] Sent: Thursday, April 01, 2004 5:18 PM To: Ong, Lyndon Cc: 'Lou Berger'; Kireeti Kompella; ccamp@ops.ietf.org Subject: Re: Label type to be used hi lyndon, Ong, Lyndon wrote: > Hi Dimitri, > > I think it was my mistake, in testing I have seen people use > FSC to describe an interface to an opaque OXC with SDH framing > when they wish to have the entire signal (minus some SDH > overhead) switched rather than sorting through individual > channels. On further reading of draft-ietf-ccamp-gmpls-routing-09.txt > it looks like section 3.5 specifically describes this as a > case where LSC would be advertised rather than FSC, since > there is conceptually a single wavelength, is this > still correct? yes, this is why i have proposed the below to adapt the below in-line with the following paragraph of section 3.5 " An interface on an opaque OXC handles a single wavelength, and cannot switch multiple wavelengths as a whole. Thus, an interface on an opaque OXC is always LSC, and not FSC, irrespective of whether there is DWDM external to it." thanks, - dimitri. > Thanks, > > Lyndon > > -----Original Message----- > From: Dimitri.Papadimitriou@alcatel.be > [mailto:Dimitri.Papadimitriou@alcatel.be] > Sent: Saturday, March 27, 2004 4:31 AM > To: Ong, Lyndon > Cc: 'Lou Berger'; Kireeti Kompella; ccamp@ops.ietf.org > Subject: Re: Label type to be used > > > the proposal that makes a fully transparent Sonet/SDH encoded capable > link appearing as [X,LSC] or [LSC,X], or [LSC,LSC] w/ a label defined as > a port and/or lambda is aligned with the evolution of the definition > towards OTN (coming from the so-called pre-OTN) technology and thus > probably better than trying to retain the TDM value for it (with several > flavours) > > so you would have something like this when trying to harmonize in > between the several documents we have tnat deals with this specific > representation issue, i also think it provides the distinction you're > asking for b/w fiber and so-called clear channels: > > 2.4.4. Lambda-Switch Capable > > If an interface is of type LSC, it means that the node receiving data > over this interface can recognize and switch individual lambdas > within the interface. An interface that allows only one lambda per > interface, and switches just that lambda is of type LSC. > > This includes interfaces that only support fully transparent SONET/SDH > > signals, as defined in [GMPLS-SONET-SDH]. > > [...] > > 2.4.7. Interface Switching Capabilities and Labels > > [PSC, PSC] - label is carried in the "shim" header [RFC3032] > > [TDM, TDM] - label represents a timeslot ([GMPLS-SONET-SDH], > [GMPLS-G709]) > > [LSC, LSC] - label represents a G.709 OCh/lambda/port > > [FSC, FSC] - label represents a fiber (i.e. physical port) > > [PSC, TDM] - label represents a timeslot ([GMPLS-SONET-SDH], > [GMPLS-G709]) > > [PSC, LSC] - label represents a G.709 OCh/lambda/port > > [PSC, FSC] - label represents a fiber > > [TDM, LSC] - label represents a G.709 OCh/lambda/port > > [TDM, FSC] - label represents a fiber > > [LSC, FSC] - label represents a fiber > > > Note: except when explicitly indicated the label encoding MUST follow > > the rules defined in [RFC3471] Section 3.2. > > ps: in fact one sees here that for the "timeslot" case, the switching > type TDM value equates the encoding one > > > Ong, Lyndon wrote: > >>Hi Lou, >> >>Your proposed text looks pretty good to me. >> >>Side note: is there a way that the >>existing text can be clarified to distinguish >>between the case of only one lambda allowed >>on an interface and the case of fiber switching? >> >>Currently the text seems to allow an overlap >>in the case of a non-channelized OC-12/48/etc. as in >>a sense there is only one "lambda" but you would >>typically request fiber switching. >> >>Cheers, >> >>Lyndon >> >>-----Original Message----- >>From: Lou Berger [mailto:lberger@movaz.com] >>Sent: Friday, March 26, 2004 11:17 AM >>To: Kireeti Kompella >>Cc: ccamp@ops.ietf.org; John Drake >>Subject: RE: Label type to be used >> >> >>Kireeti, >> I think John's points on (a) and (c) are reasonable. I think the >>only changes needed to the draft-ietf-ccamp-gmpls-routing-09.txt to make >>this clear are: >> >> 2.4.4. Lambda-Switch Capable >> >> If an interface is of type LSC, it means that the node receiving data >> over this interface can recognize and switch individual lambdas >> within the interface. An interface that allows only one lambda per >> interface, and switches just that lambda is of type LSC. >> > This includes interfaces that only support fully transparent SONET/SDH >> > signals, as defined in [GMPLS-SONET-SDH]. >> >>and >> [PSC, PSC] - label is carried in the "shim" header [RFC3032] >> [TDM, TDM] - label represents a TDM time slot [GMPLS-SONET-SDH] >> > [LSC, LSC] - label represents a lambda/port >> [FSC, FSC] - label represents a port on an OXC >> [PSC, TDM] - label represents a TDM time slot [GMPLS-SONET-SDH] >> > [PSC, LSC] - label represents a lambda/port >> [PSC, FSC] - label represents a port >> > [TDM, LSC] - label represents a lambda/port >> [TDM, FSC] - label represents a port >> [LSC, FSC] - label represents a port >> >>Lou >> >>PS This matches all but one implementation we've interoperated with. >> >>At 01:49 PM 3/26/2004 -0500, John Drake wrote: >> >> >> >> >>>>-----Original Message----- >>>>From: Kireeti Kompella >>> >>>[mailto:kireeti@juniper.net] >>> >>> >>>>Sent: Thursday, March 18, 2004 9:58 AM >>>>To: ccamp@ops.ietf.org >>>>Subject: Label type to be used >>>> >>>>Hi, >>>> >>>>Arthi and Lou pointed out the following typos in the GMPLS routing doc >>>>(draft-ietf-ccamp-gmpls-routing-09.txt) which is now in the RFC >>>>Editor's queue: >>>> >>>>In section 2.4.7 is the following table defining the type of label >>>>for various combinations of switching types: >>>> >>>> [PSC, PSC] - label is carried in the "shim" header [RFC3032] >>>> [TDM, TDM] - label represents a TDM time slot [GMPLS-SONET-SDH] >>>> [LSC, LSC] - label represents a lambda >>>> [FSC, FSC] - label represents a port on an OXC >>>> [PSC, TDM] - label represents a TDM time slot [GMPLS-SONET-SDH] >>>> [PSC, LSC] - label represents a lambda >>>> [PSC, FSC] - label represents a port >>>> [TDM, LSC] - label represents a lambda >>>> [TDM, FSC] - label represents a port >>>> [LSC, FSC] - label represents a port >>>> >>>>The one at issue is [PSC, LSC]; above it says that the label >>>>represents a lambda; and in the case of [PSC, TDM] with a fully >>>>transparent signal, the above indicates the label represents a TDM >>>>time slot. The proposal is to change this to: >>>> >>>> [PSC, PSC] - label is carried in the "shim" header [RFC3032] >>>> [TDM, TDM] - label represents a TDM time slot [GMPLS-SONET-SDH] >>>> [LSC, LSC] - label represents a lambda >>>> [FSC, FSC] - label represents a port on an OXC >>>> [PSC, TDM] - fully transparent signal: label represents a port >>>> ("transparency" is defined in [GMPLS-SONET-SDH]) >>>> [PSC, TDM] - non-transparent signal: label represents a TDM time >>>> slot [GMPLS-SONET-SDH] >>>> [PSC, LSC] - label represents a port >>>> [PSC, FSC] - label represents a port >>>> [TDM, LSC] - label represents a lambda >>>> [TDM, FSC] - label represents a port >>>> [LSC, FSC] - label represents a port >>>> >>>>Please respond by Friday 3/26, 5pm PST with comments on: >>>> >>>>a) do you agree with the above change? >>> >>>[John Drake] >>> >>>I don't have a problem with the [PSC, LSC] change but I don't >>>understand the distinction between transparent and non-transparent >>>TDM as it pertains to GMPLS routing. As I indicated in a previous >>>e-mail, I think the transparent TDM case should be handled with a >>>switching type of LSC and an encoding type of SDH/SONET, and I think >>>that this should be specified in the SDH/SONET I-D, where the distinction >>>between transparent and non-transparent TDM is defined, rather than in >>>this document. >>> >>> >>> >>>>b) in your implementation today, what do expect the label to represent >>>> i) in the case of [PSC, LSC]? >>> >>>[John Drake] >>> >>>Port/lambda >>> >>> >>> >>>> ii) in the case of [PSC, TDM] with a fully transparent signal? >>>>c) if you implement as the draft says, would it be a hardship to change >>>> this? >>> >>>[John Drake] >>> >>>N/A. Labels for SDH/SONET are defined in the SDH/SONET I-D and it's pretty >>>clear about which types of labels are in the transparent and non-transparent >>>TDM cases. >>> >>> >>> >>>>If we can get closure on this, I'll take up the task of modifying the >>>>pending RFC with the ADs. >>>> >>>>Kireeti. >>>>------- >> >> >> > -- Papadimitriou Dimitri E-mail : dimitri.papadimitriou@alcatel.be E-mail : dpapadimitriou@psg.com Webpage: http://psg.com/~dpapadimitriou/ Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium Phone : +32 3 240-8491 Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 02 Apr 2004 02:48:04 +0000 From: "Hirokazu Ishimatsu" To: "'Yakov Rekhter'" , "'Adrian Farrel'" Cc: Subject: RE: Layer One VPNs Date: Fri, 2 Apr 2004 11:46:45 +0900 MIME-Version: 1.0 Thread-Index: AcQVpcJ9yzpapSpfTAankV6DwgcZxwCtuGVQ Message-ID: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii" I agree with Yakov. Hiro Ishimatsu > -----Original Message----- > From: owner-ccamp@ops.ietf.org > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Yakov Rekhter > Sent: Tuesday, March 30, 2004 12:35 AM > To: Adrian Farrel > Cc: ccamp@ops.ietf.org > Subject: Layer One VPNs > > Adrian, > > > Hi, > > > > Although Layer One VPNs do not currently have a home in any IETF > > working group, we were the recipients of a liaison from ITU-T SG13 > > informing us about the work they are doing on this topic > and pointing > > us at > > > http://www.ietf.org/internet-drafts/draft-takeda-l1vpn-framework-00.tx > > t > > > > If anyone has comments on this work they can send them to > this mailing > > list (until another home is found in the IETF) or to the > authors direct. > > I think that this is important work, and that the home for > this work in the IETF should be the CCAMP WG. > > Yakov. > > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 01 Apr 2004 22:17:02 +0000 Message-ID: <406C950B.7010706@alcatel.be> Date: Fri, 02 Apr 2004 00:17:47 +0200 From: Dimitri.Papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.5) Gecko/20030925 MIME-Version: 1.0 To: "Ong, Lyndon" Cc: "'Lou Berger'" , Kireeti Kompella , ccamp@ops.ietf.org Subject: Re: Label type to be used Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed hi lyndon, Ong, Lyndon wrote: > Hi Dimitri, > > I think it was my mistake, in testing I have seen people use > FSC to describe an interface to an opaque OXC with SDH framing > when they wish to have the entire signal (minus some SDH > overhead) switched rather than sorting through individual > channels. On further reading of draft-ietf-ccamp-gmpls-routing-09.txt > it looks like section 3.5 specifically describes this as a > case where LSC would be advertised rather than FSC, since > there is conceptually a single wavelength, is this > still correct? yes, this is why i have proposed the below to adapt the below in-line with the following paragraph of section 3.5 " An interface on an opaque OXC handles a single wavelength, and cannot switch multiple wavelengths as a whole. Thus, an interface on an opaque OXC is always LSC, and not FSC, irrespective of whether there is DWDM external to it." thanks, - dimitri. > Thanks, > > Lyndon > > -----Original Message----- > From: Dimitri.Papadimitriou@alcatel.be > [mailto:Dimitri.Papadimitriou@alcatel.be] > Sent: Saturday, March 27, 2004 4:31 AM > To: Ong, Lyndon > Cc: 'Lou Berger'; Kireeti Kompella; ccamp@ops.ietf.org > Subject: Re: Label type to be used > > > the proposal that makes a fully transparent Sonet/SDH encoded capable > link appearing as [X,LSC] or [LSC,X], or [LSC,LSC] w/ a label defined as > a port and/or lambda is aligned with the evolution of the definition > towards OTN (coming from the so-called pre-OTN) technology and thus > probably better than trying to retain the TDM value for it (with several > flavours) > > so you would have something like this when trying to harmonize in > between the several documents we have tnat deals with this specific > representation issue, i also think it provides the distinction you're > asking for b/w fiber and so-called clear channels: > > 2.4.4. Lambda-Switch Capable > > If an interface is of type LSC, it means that the node receiving data > over this interface can recognize and switch individual lambdas > within the interface. An interface that allows only one lambda per > interface, and switches just that lambda is of type LSC. > > This includes interfaces that only support fully transparent SONET/SDH > > signals, as defined in [GMPLS-SONET-SDH]. > > [...] > > 2.4.7. Interface Switching Capabilities and Labels > > [PSC, PSC] - label is carried in the "shim" header [RFC3032] > > [TDM, TDM] - label represents a timeslot ([GMPLS-SONET-SDH], > [GMPLS-G709]) > > [LSC, LSC] - label represents a G.709 OCh/lambda/port > > [FSC, FSC] - label represents a fiber (i.e. physical port) > > [PSC, TDM] - label represents a timeslot ([GMPLS-SONET-SDH], > [GMPLS-G709]) > > [PSC, LSC] - label represents a G.709 OCh/lambda/port > > [PSC, FSC] - label represents a fiber > > [TDM, LSC] - label represents a G.709 OCh/lambda/port > > [TDM, FSC] - label represents a fiber > > [LSC, FSC] - label represents a fiber > > > Note: except when explicitly indicated the label encoding MUST follow > > the rules defined in [RFC3471] Section 3.2. > > ps: in fact one sees here that for the "timeslot" case, the switching > type TDM value equates the encoding one > > > Ong, Lyndon wrote: > >>Hi Lou, >> >>Your proposed text looks pretty good to me. >> >>Side note: is there a way that the >>existing text can be clarified to distinguish >>between the case of only one lambda allowed >>on an interface and the case of fiber switching? >> >>Currently the text seems to allow an overlap >>in the case of a non-channelized OC-12/48/etc. as in >>a sense there is only one "lambda" but you would >>typically request fiber switching. >> >>Cheers, >> >>Lyndon >> >>-----Original Message----- >>From: Lou Berger [mailto:lberger@movaz.com] >>Sent: Friday, March 26, 2004 11:17 AM >>To: Kireeti Kompella >>Cc: ccamp@ops.ietf.org; John Drake >>Subject: RE: Label type to be used >> >> >>Kireeti, >> I think John's points on (a) and (c) are reasonable. I think the >>only changes needed to the draft-ietf-ccamp-gmpls-routing-09.txt to make >>this clear are: >> >> 2.4.4. Lambda-Switch Capable >> >> If an interface is of type LSC, it means that the node receiving data >> over this interface can recognize and switch individual lambdas >> within the interface. An interface that allows only one lambda per >> interface, and switches just that lambda is of type LSC. >> > This includes interfaces that only support fully transparent SONET/SDH >> > signals, as defined in [GMPLS-SONET-SDH]. >> >>and >> [PSC, PSC] - label is carried in the "shim" header [RFC3032] >> [TDM, TDM] - label represents a TDM time slot [GMPLS-SONET-SDH] >> > [LSC, LSC] - label represents a lambda/port >> [FSC, FSC] - label represents a port on an OXC >> [PSC, TDM] - label represents a TDM time slot [GMPLS-SONET-SDH] >> > [PSC, LSC] - label represents a lambda/port >> [PSC, FSC] - label represents a port >> > [TDM, LSC] - label represents a lambda/port >> [TDM, FSC] - label represents a port >> [LSC, FSC] - label represents a port >> >>Lou >> >>PS This matches all but one implementation we've interoperated with. >> >>At 01:49 PM 3/26/2004 -0500, John Drake wrote: >> >> >> >> >>>>-----Original Message----- >>>>From: Kireeti Kompella >>> >>>[mailto:kireeti@juniper.net] >>> >>> >>>>Sent: Thursday, March 18, 2004 9:58 AM >>>>To: ccamp@ops.ietf.org >>>>Subject: Label type to be used >>>> >>>>Hi, >>>> >>>>Arthi and Lou pointed out the following typos in the GMPLS routing doc >>>>(draft-ietf-ccamp-gmpls-routing-09.txt) which is now in the RFC >>>>Editor's queue: >>>> >>>>In section 2.4.7 is the following table defining the type of label >>>>for various combinations of switching types: >>>> >>>> [PSC, PSC] - label is carried in the "shim" header [RFC3032] >>>> [TDM, TDM] - label represents a TDM time slot [GMPLS-SONET-SDH] >>>> [LSC, LSC] - label represents a lambda >>>> [FSC, FSC] - label represents a port on an OXC >>>> [PSC, TDM] - label represents a TDM time slot [GMPLS-SONET-SDH] >>>> [PSC, LSC] - label represents a lambda >>>> [PSC, FSC] - label represents a port >>>> [TDM, LSC] - label represents a lambda >>>> [TDM, FSC] - label represents a port >>>> [LSC, FSC] - label represents a port >>>> >>>>The one at issue is [PSC, LSC]; above it says that the label >>>>represents a lambda; and in the case of [PSC, TDM] with a fully >>>>transparent signal, the above indicates the label represents a TDM >>>>time slot. The proposal is to change this to: >>>> >>>> [PSC, PSC] - label is carried in the "shim" header [RFC3032] >>>> [TDM, TDM] - label represents a TDM time slot [GMPLS-SONET-SDH] >>>> [LSC, LSC] - label represents a lambda >>>> [FSC, FSC] - label represents a port on an OXC >>>> [PSC, TDM] - fully transparent signal: label represents a port >>>> ("transparency" is defined in [GMPLS-SONET-SDH]) >>>> [PSC, TDM] - non-transparent signal: label represents a TDM time >>>> slot [GMPLS-SONET-SDH] >>>> [PSC, LSC] - label represents a port >>>> [PSC, FSC] - label represents a port >>>> [TDM, LSC] - label represents a lambda >>>> [TDM, FSC] - label represents a port >>>> [LSC, FSC] - label represents a port >>>> >>>>Please respond by Friday 3/26, 5pm PST with comments on: >>>> >>>>a) do you agree with the above change? >>> >>>[John Drake] >>> >>>I don't have a problem with the [PSC, LSC] change but I don't >>>understand the distinction between transparent and non-transparent >>>TDM as it pertains to GMPLS routing. As I indicated in a previous >>>e-mail, I think the transparent TDM case should be handled with a >>>switching type of LSC and an encoding type of SDH/SONET, and I think >>>that this should be specified in the SDH/SONET I-D, where the distinction >>>between transparent and non-transparent TDM is defined, rather than in >>>this document. >>> >>> >>> >>>>b) in your implementation today, what do expect the label to represent >>>> i) in the case of [PSC, LSC]? >>> >>>[John Drake] >>> >>>Port/lambda >>> >>> >>> >>>> ii) in the case of [PSC, TDM] with a fully transparent signal? >>>>c) if you implement as the draft says, would it be a hardship to change >>>> this? >>> >>>[John Drake] >>> >>>N/A. Labels for SDH/SONET are defined in the SDH/SONET I-D and it's pretty >>>clear about which types of labels are in the transparent and non-transparent >>>TDM cases. >>> >>> >>> >>>>If we can get closure on this, I'll take up the task of modifying the >>>>pending RFC with the ADs. >>>> >>>>Kireeti. >>>>------- >> >> >> > -- Papadimitriou Dimitri E-mail : dimitri.papadimitriou@alcatel.be E-mail : dpapadimitriou@psg.com Webpage: http://psg.com/~dpapadimitriou/ Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium Phone : +32 3 240-8491 Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 01 Apr 2004 20:53:20 +0000 Message-Id: <4.3.2.7.2.20040401154828.03ce9410@wells.cisco.com> Date: Thu, 01 Apr 2004 15:52:15 -0500 To: Dimitri.Papadimitriou@alcatel.be From: Jean Philippe Vasseur Subject: Re: TR : I-D ACTION:draft-ietf-tewg-interarea-mpls-te-req-00.txt Cc: LE ROUX Jean-Louis FTRD/DAC/LAN , ccamp@ops.ietf.org, mpls@UU.NET Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Hi Dimitri, At 07:52 PM 3/31/2004 +0200, Dimitri.Papadimitriou@alcatel.be wrote: >hi jp, > >see in-line: > >>Thanks for your useful comments here. See below, >>At 02:18 PM 3/30/2004 +0200, Dimitri.Papadimitriou@alcatel.be wrote: >> >>>hi jl, here below several comments on this updated version of the document: >>> >>>1) section 5.3.1 mentions: >>> >>>"The solution MUST entirely preserve the concept of IGP hierarchy. In >>> other words, flooding of TE link information across areas MUST be >>> precluded." >>> >>>section 5.3.2 mentions: >>> >>>"The solution MUST also not increase IGP load which could compromise >>> IGP scalability. In particular, a solution satisfying those >>> requirements MUST not require for the IGP to carry some unreasonable >>> amount of extra information and MUST not unreasonably increase the >>> IGP flooding frequency." >>> >>>but section 7.12 tells: >>> >>>"The discovery mechanism SHOULD >>> be applicable across multiple IGP areas, and SHOULD not impact the >>> IGP scalability, provided that IGP extensions are used for such a >>> discovery mechanism." >>> >>>-> would it be possible to align these requirements, i get the >>>impression (please confirm) that you preclude TE link information but >>>you would allow for node information (auto-mesh) ? note also that the >>>section 7.12 doesn't tell us a lot about the expected distribution of the mesh >> >>The solution MUST preclude to flood TE-related link information and MUST >>not compromise the IGP scalability in any circumstances. That being said, >>IGP based mechanisms can be used for the discovery which will respect the >>requirement mentioned above, > >i understand to what you're referring, but please make it clear >imho it would help if in section 7.12 the exact meaning of the >following "*some* discovery mechanisms" was detailed so that the >reader can more accurately assess the scope of the above ok, will do >>>2) section 7.3 >>> >>>" In the context of this requirement document, an optimal path is >>> defined as the shortest path across multiple areas taking into >>> account either the IGP or TE metric. " >>> >>>are you referring here to >>> >>> >>>would you clarify ? >> >>Sure, we will add some text. The reason for this clarification is that >>there are a multitude of definitions for an optimal path: paths that >>minimize the max link utilization, call set up failure, ... here we just >>refer to the ability to compute a shortest path (using either the IGP or >>TE metric). > >ok > >>>3) section 7.3 >>> >>>it is not clear for me what is behind the last part of the following >>>sentence >>> >>>"So a solution should support both mechanisms, and SHOULD allow >>> the operator to select by configuration, and on a per-LSP basis, the >>> required level of optimality. " >>> >>>what is meant by "level of optimality" ? is it simply "optimal - >>>sub-optimal" or do you have something else in mind ? >> >>We will clarify. The idea is that the ability to compute an end to end >>shortest path may not be required for all inter-area TE LSPs. Hence the >>solution should allow the operator to select the appropriate path >>computation method. > >ok, would be interesting to see whether operators would like to have >selection based on the computational method (allow for intermediate >computation or any other option suitable in this context) or based on the >optimality level (then the solution itself selects the appropriate >computational method) or simply both > >>>4) section 7.4 >>> >>>"Another example is the requirement to set up multiple TE LSPs between >>> a pair of LSRs residing in different IGP areas in case a single TE >>> LSP satisfying the set of requirements could not be found. " >>> >>>why in such a case diversity would be desirable ? >> >>for either path protection or load balancing while minimizing the impact >>in case of failure. >> >>>got the impression that if a single path would have been feasible it >>>would have been selected in this case - isn't it ? >> >>That being said, we need to rephrase, I agree with you that this >>paragraph is not clear. It should read: >>"Another example is the requirement to set up multiple TE LSPs between a >>pair of LSRs residing in different IGP areas. For instance, this would >>occur if TE LSP satisfying for instance the bandwidth requirement could >>be found, hence, requiring to set up multiple TE LSPs" > >the former point(s) seem clearer, is it "could be found" or "could not be >found" ? oups ... typo, yes "could not be found" >>>5) section 7.7 >>> >>>"This may reduce the recovery delay, but with the risk of >>> multiple crankbacks, and sub-optimality. " >>> >>>i agree, but this is valid iff the head-end has initially computed an >>>end-to-end optimal path, >> >>more exactly this applies to contiguous LSP. For sub-optimality this >>applies to any kind of LSP. > >well i think that a contiguous LSP can still be sub-optimal hence >i would suggest to not implicitly attach the crankback functionality >to the signaling method, but to make clear what are the potential >issues in terms of optimality as said "iff the path was initially >computed as an end-to-end optimal" not sure to see your point here ? >>>also unclear if you refer also here to the provisioning delay ? >>> >>>editorially speaking it is also a bit unclear why you've splitted >>>section 7.7 and section 7.8 both refers to inter-area lsp recovery > >i don't know if this could be taken into account, this would simplify >reading and subsequent utilisation of the document ok >>>6) section 7.11 >>> >>>would it be possible to mention what's expected (or not expected) in >>>terms also of hard preemption ? >> >>ok > >just a hint here, is my understanding correct that the following sentence >"The lower priority LSP is not torn down and can continue to forward >traffic on a best-effort basis." infers that you would have to priority >high/low only so i'd would instead be more generic here in >terms of priorities the latter >>>7) section 8.2 >>> >>>what's meant by stability ? ie stability of what ? (for instance, as i >>>read the document, but please correct me, stability and re-optimization >>>are imho two features that are going in somehow opposite directions so a >>>trade-off has to be found here) >> >>We will clarify. > >ok > >>thanks for your comments ! > >hope to see the next version soon, would also be interesting to see other >people commenting here sure, thanks for your comments. Note that this draft is already the collection of many feed-backs from several SPs. thanks. JP. >thanks, >- dimitri. > >>JP. >> >>>thanks in advance, >>>- dimitri. >>> >>>LE ROUX Jean-Louis FTRD/DAC/LAN wrote: >>> >>>>Hi all, >>>>Thanks in advance for your comments on this new revision of inter-area >>>>TE requirements. >>>>Regards, >>>>JL >>>> >>>>>A New Internet-Draft is available from the on-line Internet-Drafts >>>>>directories. This draft is a work item of the Internet Traffic >>>>>Engineering Working Group of the IETF. >>>>> >>>>> Title : Requirements for Inter-area MPLS Traffic >>>> >>>>Engineering >>>> >>>>> Author(s) : J. Le Roux, et al. >>>>> Filename : draft-ietf-tewg-interarea-mpls-te-req-00.txt >>>>> Pages : 20 >>>>> Date : 2004-3-26 >>>>> >>>>>This document lists a detailed set of functional requirements for the >>>>>support of inter-area MPLS Traffic Engineering (inter-area MPLS TE) >>>>>which could serve as a guideline to develop the required set of >>>>>protocol extensions. >>>>> >>>>>A URL for this Internet-Draft is: >>>>>http://www.ietf.org/internet-drafts/draft-ietf-tewg-interarea-mpls-te-r >>>> >>>>eq-00.txt >>>> >>>>>To remove yourself from the IETF Announcement list, send a message to >>>>>ietf-announce-request with the word unsubscribe in the body of the >>>>>message. >>>>> >>>>>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-tewg-interarea-mpls-te-req-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 >>>> >>> >>>-- >>>Papadimitriou Dimitri >>>E-mail : dimitri.papadimitriou@alcatel.be >>>E-mail : dpapadimitriou@psg.com >>>Webpage: http://psg.com/~dpapadimitriou/ >>>Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium >>>Phone : +32 3 240-8491 >>> > >-- >Papadimitriou Dimitri >E-mail : dimitri.papadimitriou@alcatel.be >E-mail : dpapadimitriou@psg.com >Webpage: http://psg.com/~dpapadimitriou/ >Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium >Phone : +32 3 240-8491 > > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 01 Apr 2004 19:51:58 +0000 Message-Id: <4.3.2.7.2.20040401144213.020c7ce0@wells.cisco.com> Date: Thu, 01 Apr 2004 14:50:28 -0500 To: raymond zhang From: Jean Philippe Vasseur Subject: Re: Some minor comments on the loose-path-opt draft Cc: y.ikejiri@ntt.com, ccamp@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Hi Raymond, Thanks for your comments and support for the draft - see in line. At 09:25 AM 4/1/2004 -0800, raymond zhang wrote: >Hi JP and Yuichi, > >Just gone through=20 >http://www.ietf.org/internet-drafts/draft-vasseur-ccamp-loose-path-reopt-00= .txt=20 >and here are some minor comments: > >This draft describes a very useful mechanism solving part of the reopt=20 >issues documented in the inter-AS requirements draft=20 >(http://www.ietf.org/internet-drafts/draft-ietf-tewg-interas-mpls-te-req-06= .txt)... > >1. Editorial comments: > >1.1. Editorial - clean up the strange characters, for example, in Section= =20 >4.2, page 5 >" ...=AA=AALink-UP=AA=AA event). " ok >1.2. Section 1, page 2, " >A loosely routed explicit path is as a path specified as a ..." > > >The "as" proceeding "a path" above should be removed. right, thanks. >1.3. Section 1, page 2, "...of the Ipv4 prefix sub-object..." >should IPv6 prefix be included as well ? > >Also in Section 3.2, may need to list a IPv6 error_spec object also... Agree, we'll fix that, >1.4. In section 4.3.1, page 7: > >"Example: > >Let call " > >It should be "Let's call..." ok >1.5. In section 4.3.1, page 7: >"... pi such that li is a next (loose) hop of pi for i=3D1+n" > >- delete "pi" >- "i=3D1+n" should be changed to "i=3D1 to n" >- it may read better if you change "for i=3D1 to n" to for "i=3D1 to n= which=20 >is illustrated in the following example:" > >Then after "Pn=3D" > >add "where L1=3DR3 is the next loose hop of P1=3DR1, etc." right >2. Other comments: > >2.1. In section 4.3.1, page 7 >"- If a better path can be found, the LSR MUST > immediately send a Path Error to the head-end LSR > (Error code 25 (Notify), sub-code=3D6 (better path > exists))" > >I wonder if you should also add "and go ahead with reopt by sending RSVP=20 >path messages for the new path". Otherwise there is no action described=20 >for this mid-point LSR what it will do after it found a better path and=20 >notify the HE LSR. In this case, the TE LSP is contiguous, hence the mid-point's role is just= =20 to notify of the existence of a better path (or the requirement for local=20 maintenance) in some downstream area/AS. Note that it cannot locally=20 reoptimize since the LSP ID would not match. Moreover, the intention is to= =20 let the Head-end LSR decide on whether to reoptimize depending on the TE=20 LSP attributes (pending back-off, ...). Does that make sense ? >2.2. Some general comments regarding the mode of operations > >There are couple more cases which may be considered: > >Mode 1 If it is TE-LSP HE LSR initiated, >- Midpoint LSR can ignore this request and not to perform reopt even if=20 >there is a better path within its AS; > >This can either be part of the interconnect agreement between two=20 >providers or to protect transit AS for reasons such as HE LSR triggers=20 >reopt in an unusually high frequency due to mis-configuration... But=20 >mid-point LSR does need to notify the HE LSR why via patherr msg. Totally agree, this is a good point which will be in the next revision. >Mode 2 If it is mid-point LSR initiated and midpoint LSR find out there is= =20 >a better path for an existing TE-LSP and notifies the TE-LSP HE, TE-LSP HE= =20 >LSR does not want to reopt, for example, configured not to repot that way= =20 >for operational reasons at that time. (except for local link maint.=20 >reasons of course) I am not sure what's the process here next - both HE=20 >and midpoint LSR do nothing and continue to refresh ? Yes, head-end and the mid-point LSRs could respectively ignore the polling= =20 and the notification but this is again a good point which is worth being=20 clarified. Thanks for your useful comments: they will be incorporated in the next=20 revision. JP. >Regards, >Raymond > > > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 01 Apr 2004 18:08:10 +0000 Message-ID: <829F074A10F98943A218DC363D09C92A01476BE6@w2ksjexg06.ciena.com> From: "Ong, Lyndon" To: "'Dimitri.Papadimitriou@alcatel.be'" Cc: 'Lou Berger' , Kireeti Kompella , ccamp@ops.ietf.org Subject: RE: Label type to be used Date: Thu, 1 Apr 2004 10:07:06 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Hi Dimitri, I think it was my mistake, in testing I have seen people use FSC to describe an interface to an opaque OXC with SDH framing when they wish to have the entire signal (minus some SDH overhead) switched rather than sorting through individual channels. On further reading of draft-ietf-ccamp-gmpls-routing-09.txt it looks like section 3.5 specifically describes this as a case where LSC would be advertised rather than FSC, since there is conceptually a single wavelength, is this still correct? Thanks, Lyndon -----Original Message----- From: Dimitri.Papadimitriou@alcatel.be [mailto:Dimitri.Papadimitriou@alcatel.be] Sent: Saturday, March 27, 2004 4:31 AM To: Ong, Lyndon Cc: 'Lou Berger'; Kireeti Kompella; ccamp@ops.ietf.org Subject: Re: Label type to be used the proposal that makes a fully transparent Sonet/SDH encoded capable link appearing as [X,LSC] or [LSC,X], or [LSC,LSC] w/ a label defined as a port and/or lambda is aligned with the evolution of the definition towards OTN (coming from the so-called pre-OTN) technology and thus probably better than trying to retain the TDM value for it (with several flavours) so you would have something like this when trying to harmonize in between the several documents we have tnat deals with this specific representation issue, i also think it provides the distinction you're asking for b/w fiber and so-called clear channels: 2.4.4. Lambda-Switch Capable If an interface is of type LSC, it means that the node receiving data over this interface can recognize and switch individual lambdas within the interface. An interface that allows only one lambda per interface, and switches just that lambda is of type LSC. > This includes interfaces that only support fully transparent SONET/SDH > signals, as defined in [GMPLS-SONET-SDH]. [...] 2.4.7. Interface Switching Capabilities and Labels [PSC, PSC] - label is carried in the "shim" header [RFC3032] > [TDM, TDM] - label represents a timeslot ([GMPLS-SONET-SDH], [GMPLS-G709]) > [LSC, LSC] - label represents a G.709 OCh/lambda/port > [FSC, FSC] - label represents a fiber (i.e. physical port) > [PSC, TDM] - label represents a timeslot ([GMPLS-SONET-SDH], [GMPLS-G709]) > [PSC, LSC] - label represents a G.709 OCh/lambda/port > [PSC, FSC] - label represents a fiber > [TDM, LSC] - label represents a G.709 OCh/lambda/port > [TDM, FSC] - label represents a fiber > [LSC, FSC] - label represents a fiber > Note: except when explicitly indicated the label encoding MUST follow > the rules defined in [RFC3471] Section 3.2. ps: in fact one sees here that for the "timeslot" case, the switching type TDM value equates the encoding one Ong, Lyndon wrote: > Hi Lou, > > Your proposed text looks pretty good to me. > > Side note: is there a way that the > existing text can be clarified to distinguish > between the case of only one lambda allowed > on an interface and the case of fiber switching? > > Currently the text seems to allow an overlap > in the case of a non-channelized OC-12/48/etc. as in > a sense there is only one "lambda" but you would > typically request fiber switching. > > Cheers, > > Lyndon > > -----Original Message----- > From: Lou Berger [mailto:lberger@movaz.com] > Sent: Friday, March 26, 2004 11:17 AM > To: Kireeti Kompella > Cc: ccamp@ops.ietf.org; John Drake > Subject: RE: Label type to be used > > > Kireeti, > I think John's points on (a) and (c) are reasonable. I think the > only changes needed to the draft-ietf-ccamp-gmpls-routing-09.txt to make > this clear are: > > 2.4.4. Lambda-Switch Capable > > If an interface is of type LSC, it means that the node receiving data > over this interface can recognize and switch individual lambdas > within the interface. An interface that allows only one lambda per > interface, and switches just that lambda is of type LSC. > > This includes interfaces that only support fully transparent SONET/SDH > > signals, as defined in [GMPLS-SONET-SDH]. > > and > [PSC, PSC] - label is carried in the "shim" header [RFC3032] > [TDM, TDM] - label represents a TDM time slot [GMPLS-SONET-SDH] > > [LSC, LSC] - label represents a lambda/port > [FSC, FSC] - label represents a port on an OXC > [PSC, TDM] - label represents a TDM time slot [GMPLS-SONET-SDH] > > [PSC, LSC] - label represents a lambda/port > [PSC, FSC] - label represents a port > > [TDM, LSC] - label represents a lambda/port > [TDM, FSC] - label represents a port > [LSC, FSC] - label represents a port > > Lou > > PS This matches all but one implementation we've interoperated with. > > At 01:49 PM 3/26/2004 -0500, John Drake wrote: > > > >>>-----Original Message----- >>>From: Kireeti Kompella >> >>[mailto:kireeti@juniper.net] >> >>>Sent: Thursday, March 18, 2004 9:58 AM >>>To: ccamp@ops.ietf.org >>>Subject: Label type to be used >>> >>>Hi, >>> >>>Arthi and Lou pointed out the following typos in the GMPLS routing doc >>>(draft-ietf-ccamp-gmpls-routing-09.txt) which is now in the RFC >>>Editor's queue: >>> >>>In section 2.4.7 is the following table defining the type of label >>>for various combinations of switching types: >>> >>> [PSC, PSC] - label is carried in the "shim" header [RFC3032] >>> [TDM, TDM] - label represents a TDM time slot [GMPLS-SONET-SDH] >>> [LSC, LSC] - label represents a lambda >>> [FSC, FSC] - label represents a port on an OXC >>> [PSC, TDM] - label represents a TDM time slot [GMPLS-SONET-SDH] >>> [PSC, LSC] - label represents a lambda >>> [PSC, FSC] - label represents a port >>> [TDM, LSC] - label represents a lambda >>> [TDM, FSC] - label represents a port >>> [LSC, FSC] - label represents a port >>> >>>The one at issue is [PSC, LSC]; above it says that the label >>>represents a lambda; and in the case of [PSC, TDM] with a fully >>>transparent signal, the above indicates the label represents a TDM >>>time slot. The proposal is to change this to: >>> >>> [PSC, PSC] - label is carried in the "shim" header [RFC3032] >>> [TDM, TDM] - label represents a TDM time slot [GMPLS-SONET-SDH] >>> [LSC, LSC] - label represents a lambda >>> [FSC, FSC] - label represents a port on an OXC >>> [PSC, TDM] - fully transparent signal: label represents a port >>> ("transparency" is defined in [GMPLS-SONET-SDH]) >>> [PSC, TDM] - non-transparent signal: label represents a TDM time >>> slot [GMPLS-SONET-SDH] >>> [PSC, LSC] - label represents a port >>> [PSC, FSC] - label represents a port >>> [TDM, LSC] - label represents a lambda >>> [TDM, FSC] - label represents a port >>> [LSC, FSC] - label represents a port >>> >>>Please respond by Friday 3/26, 5pm PST with comments on: >>> >>>a) do you agree with the above change? >> >>[John Drake] >> >>I don't have a problem with the [PSC, LSC] change but I don't >>understand the distinction between transparent and non-transparent >>TDM as it pertains to GMPLS routing. As I indicated in a previous >>e-mail, I think the transparent TDM case should be handled with a >>switching type of LSC and an encoding type of SDH/SONET, and I think >>that this should be specified in the SDH/SONET I-D, where the distinction >>between transparent and non-transparent TDM is defined, rather than in >>this document. >> >> >>>b) in your implementation today, what do expect the label to represent >>> i) in the case of [PSC, LSC]? >> >>[John Drake] >> >>Port/lambda >> >> >>> ii) in the case of [PSC, TDM] with a fully transparent signal? >>>c) if you implement as the draft says, would it be a hardship to change >>> this? >> >>[John Drake] >> >>N/A. Labels for SDH/SONET are defined in the SDH/SONET I-D and it's pretty >>clear about which types of labels are in the transparent and non-transparent >>TDM cases. >> >> >>>If we can get closure on this, I'll take up the task of modifying the >>>pending RFC with the ADs. >>> >>>Kireeti. >>>------- > > > -- Papadimitriou Dimitri E-mail : dimitri.papadimitriou@alcatel.be E-mail : dpapadimitriou@psg.com Webpage: http://psg.com/~dpapadimitriou/ Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium Phone : +32 3 240-8491 Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 01 Apr 2004 17:13:12 +0000 Message-ID: <00aa01c4180c$368497f0$7a9c9ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Cc: "'Kireeti Kompella'" , Subject: Fw: I-D ACTION:draft-ietf-ccamp-gmpls-g709-07.txt Date: Thu, 1 Apr 2004 15:30:06 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Alex, draft-ietf-ccamp-gmpls-g709 has successfully completed working group last call and has been marked up to fix the minor comments that were raised. Would you take this draft to the IESG on our behalf with a view to it becoming a standards track RFC. Thank you (let me know if there is any other formal process I should complete). Adrian ----- Original Message ----- From: To: Sent: Thursday, April 01, 2004 2:11 PM Subject: I-D ACTION:draft-ietf-ccamp-gmpls-g709-07.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 MPLS Signalling Extensions for G.709 Optical Transport Networks Control > Author(s) : D. Papadimitriou > Filename : draft-ietf-ccamp-gmpls-g709-07.txt > Pages : 21 > Date : 2004-3-31 > > This document is a companion to the Generalized MPLS (GMPLS) > signalling documents. It describes the technology specific > information needed to extend GMPLS signalling to control Optical > Transport Networks (OTN); it also includes the so-called pre-OTN > developments. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-g709-07.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-g709-07.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-g709-07.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. >