Comments (2) on = draft-dimitri-ccamp-gmpls-ason-routing-ospf-00.txt

=0A=

I would like to clarify the = the difference =0A= between the terms "conversion" and

=0A=

"migration".

=0A=

The title says "conversion" and in the document = "migration" is =0A= used.

=0A=

Migration seems to be defined in the document i.e. = migration of MP =0A= states to

=0A=

CP states. The difference between MP state (in the node) = and CP =0A= state is that

=0A=

MP states do not have the end-point information whereas = the CP =0A= states have

=0A=

end-point information. I belief the assumption here is = that the =0A= end-point information

=0A=

is provided from an external source e.g. NMS.

=0A=

Now coming to conversion I belief we mean at some point = of time the =0A= operator was

=0A=

using the MP states and after the conversion is complete = the =0A= operator starts using

=0A=

the CP. Now I belief the migration is just a single step = in all of =0A= this. For example,

=0A=

the conversion process could include:

=0A=

+ Identification of the circuits or auto-discovery of the =0A= circuits

=0A=

+ Migration

=0A=

+ Some grouping to associate the various LSPs into = protection =0A= groups, VCAT groups

=0A=

etc.

=0A=

My point is we need to have an understanding of these = processes and =0A= exclude or

=0A=

include these within the scope of GMPLS.

=0A=

Regards,

=0A=

Snigdho

=0A=

From: = owner-ccamp@ops.ietf.org on =0A= behalf of Diego Caviglia
Sent: Tue 7/11/2006 3:08 = PM
To: =0A= ccamp@ops.ietf.org
Subject: Revision 02 of =0A= draft-caviglia-ccamp-pc-and-sc-reqs

=0A=

Hi all,
seems = that the =0A= revision 02 of the draft in subject has been published =0A= (http://www.ietf.org/internet-drafts/draft-caviglia-ccamp-pc-and-sc-reqs-= 02.txt) =0A= on the repository.

This = revision =0A= addresses the last comments we received from Dimitri and Adrian. =0A=

If I've understood correctly = what we =0A= decided yestarday this version is candidate to become WG document, is = this =0A= correct Adrian?

Best = Regards =0A=

Diego =0A=

=0A= ------_=_NextPart_001_01C6A5C4.0AEBC201-- From owner-ccamp@ops.ietf.org Wed Jul 12 15:16:55 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0kCd-0006Hv-3n for ccamp-archive@ietf.org; Wed, 12 Jul 2006 15:16:55 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0kCa-00042i-LP for ccamp-archive@ietf.org; Wed, 12 Jul 2006 15:16:55 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G0k6u-0003qu-Pa for ccamp-data@psg.com; Wed, 12 Jul 2006 19:11:00 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO autolearn=ham version=3.1.1 Received: from [80.68.34.49] (helo=mail2.noc.data.net.uk) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G0k6t-0003qW-9X for ccamp@ops.ietf.org; Wed, 12 Jul 2006 19:10:59 +0000 Received: from 57-99.dsl.data.net.uk ([80.68.57.99] helo=cortex.aria-networks.com) by mail2.noc.data.net.uk with esmtp (Exim 3.36 #1) id 1G0k6o-0003nc-00 for ccamp@ops.ietf.org; Wed, 12 Jul 2006 20:10:54 +0100 Received: from your029b8cecfe ([132.219.13.233] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 12 Jul 2006 20:10:57 +0100 Message-ID: <062701c6a5e6$e40805f0$e90ddb84@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: OSPF ASON Routing Solution Date: Wed, 12 Jul 2006 20:10:05 +0100 Organization: Old Dog Consulting MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-OriginalArrivalTime: 12 Jul 2006 19:10:57.0900 (UTC) FILETIME=[E7F08AC0:01C6A5E6] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Hi, On Monday in CCAMP we discussed draft-dimitri-ccamp-gmpls-ason-routing-ospf-00.txt the solutions draft for OSPF in ASON routing. There is agreement from the OSPF WG chair that we are not treading on toes, and the meeting seemed to say that this was pretty stable. So a this is a quick poll to see if anyone objects to this becoming a WG draft. NB, this is a charter item and we have an obligation to work on this for the ITU-T. Thanks, Adrian PS Note that a solution does not have to be 100% perfect to become a WG draft. From owner-ccamp@ops.ietf.org Wed Jul 12 17:01:55 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0lqF-0002M6-Lm for ccamp-archive@ietf.org; Wed, 12 Jul 2006 17:01:55 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0lHw-0004D7-E7 for ccamp-archive@ietf.org; Wed, 12 Jul 2006 16:26:28 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G0kqX-000236-2q for ccamp-archive@ietf.org; Wed, 12 Jul 2006 15:58:10 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G0kn0-0007ab-Cx for ccamp-data@psg.com; Wed, 12 Jul 2006 19:54:30 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO autolearn=ham version=3.1.1 Received: from [80.68.34.49] (helo=mail2.noc.data.net.uk) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G0kmz-0007a2-7p for ccamp@ops.ietf.org; Wed, 12 Jul 2006 19:54:29 +0000 Received: from 57-99.dsl.data.net.uk ([80.68.57.99] helo=cortex.aria-networks.com) by mail2.noc.data.net.uk with esmtp (Exim 3.36 #1) id 1G0kmu-0008Ec-00 for ccamp@ops.ietf.org; Wed, 12 Jul 2006 20:54:24 +0100 Received: from your029b8cecfe ([132.219.13.233] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 12 Jul 2006 20:54:27 +0100 Message-ID: <063e01c6a5ec$fa4d4270$e90ddb84@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Brungard, Deborah A, ALABS" Cc: References: <449B2580D802A443A923DABF3EAB82AF0C493E4A@OCCLUST04EVS1.ugd.att.com> Subject: Re: Working Group Last Call on draft-ietf-ccamp-gmpls-rsvp-te-call-00.txt Date: Wed, 12 Jul 2006 20:53:46 +0100 Organization: Old Dog Consulting MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-OriginalArrivalTime: 12 Jul 2006 19:54:28.0083 (UTC) FILETIME=[FBBADC30:01C6A5EC] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: -2.6 (--) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Hi, > The Working Group Last Call has closed on this document. > > Authors/editors please summarize the comments and document > how they will be addressed. Thanks Deborah, it's interesting to be on the receiving side for a change :-) I noted the following comments during WG last call. 1. Desirability of liaison to ITU-T SG15 (Lyndon) Lyndon suggested that this I-D should be liaised to SG15 prior to becoming an RFC to ensure that terminology is correct and that it meets the requirments for supporting ASON calls. Our response here is that: a. This I-D is not specifically targeted at satisfying RFC4139. b. An applicability statement will be produced describing how this and other I-Ds/RFCs can be used to meet the requirements set out in RFC4139. That work will definitely be liaised to the ITU-T. c. The terms used in this document are not specific to ASON, but in general they have been taken from RFC4139 and RFC4397 both of which received substantial and useful review by SG15. No further action is planned by the authors. 2. Format of Long Call ID (Lyndon) Lyndon points out that a format for the long call ID has been defined in G.7713.2 and suggests that this might be included by reference. The authors note that the format of an ASON call ID is defined in several places (including G.7713.1 and G.7713.2), but the intention of the draft is not to be limited to ASON applicability. Therefore other call ID formats would also be supported, and the format is out of scope for the draft. An applicability statement will be produced describing how this and other I-Ds/RFCs can be used to meet the requirements set out in RFC4139, and that will definitely include the encoding of ASON call IDs. That work will be liaised to the ITU-T. No further action is planned by the authors. 3. Location of Short Call ID in Path message (Lyndon and Ben) Both Lyndon and Ben questioned the location of the short call ID in the Session object. a. Impact of existing, non-conformant implementations The draft currently describes the behavior if non-conformant transit LSRs react to the use of the previously reserved bits of the Session object. They might reject the Path message, or they might zero out the short call ID. Lyndon asked whether it might be better to use a separate object to avoid this issue completely. The authors had previously discussed this point at some length and believe that protocol design should not be shaped by the possiblity of dysfunctional implementations. Further, the use of a new object might also cause problems with defective implementations. The authors propose no changes to the I-D for this point, but will send mail to the MPLS mailing list to check that the 'owners' of RSVP-TE have no issue with this use of a previkously reserved field. b. Illogicality of use of Session object Ben and Lyndon expressed the view that it would be more logical to place the short call ID in a new object than to complicate the concept of the Session. The possibility of using the Association object was also raised. The authors had discussed this at some length over the last two years that the I-D has been in production, and recently on the mailing list. Our conclusion is that: i. The Association object is for associating LSPs with each other. The call ID is used to associate LSPs with a call. ii. A separate object would be perfectly functional. iii. There is already some logical association between the session and the LSPs in the call, and it makes sense to extend this. iv. The key on the Notify message is the session. v. The current I-D is also perfectly functional, and has been successfully implemented. Given that no specific draw-back to the current encoding has been put forward except for a feeling of illogicality among some readers, the authors propose no further action except for polling the MPLS WG as described above. 4. Procedures for including LINK_CAPABILITIES object A comment was made that this appears to be totally optional without any defined procedures for how an LSR should decide wheter to include the object. The authors agree with this view, and it is intentional. The draft states... The LINK CAPABILITY object is introduced to support link capability exchange during Call setup and MAY be included in a Notify message used for Call setup. This optional object includes the bundled link local capabilities of the Call initiating node (or terminating node) indicated by the source address of the Notify message. This text makes it quite clear that the object is completely optional. The authors propose to make no changes for this point. 5. Question about processing rules in section 6.2.1 There was a detailed quesiton about the procedure in seciton 6.2.1. The authors believe that this was answered and concluded on the mailing list. The authors propose to make no changes for this point. 6. Refresh Notify Lyndon asked whether the refresh of the Notify message is really necessary if there are active LSPs in the call? Possibly the LSP refresh could be sufficient, since this carries the short Call ID. He also asked if it possible that the call would be dropped while there are still active LSPs. The authors consider that you cannot infer the status of the call when there are no connections on the call. They believe that a single mechanism should be used to monitor the call status in all circumstances. The draft describes refresh failure of calls when connections already exist in section 6.7. In short, we propose to make no changes to the document as a result of WG last call. We will notify the MPLS WG as described above. Can this I-D now move on the ADs? Thanks, Adrian From komatsu@kamposv.kampo2002.net Fri Jul 14 04:39:05 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1JCT-0002y6-QM for ccamp-archive@ietf.org; Fri, 14 Jul 2006 04:39:05 -0400 Received: from [219.163.126.184] (helo=kamposv.kampo2002.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G1JCR-0007Fe-2u for ccamp-archive@ietf.org; Fri, 14 Jul 2006 04:39:05 -0400 Received: (from komatsu@localhost) by kamposv.kampo2002.net (8.11.6p2/8.11.6) id k6E90c708625; Fri, 14 Jul 2006 18:00:39 +0900 Date: Fri, 14 Jul 2006 18:00:39 +0900 Message-Id: <200607140900.k6E90c708625@kamposv.kampo2002.net> To: ccamp-archive@ietf.org Subject: Message from eBay Member From: eBay-Mitglied gret Content-Type: text/html X-Spam-Score: 3.0 (+++) X-Scan-Signature: fca7d4b87f391aa4d413f865ce6efe79

eBay sent this message.
Your registered name is included to show this message originated from eBay. Learn more.

Question from eBay Member -- Respond Now eBay

eBay sent this message on behalf of an eBay member via My Messages. Responses sent using email will not reach the eBay member. Use the Respond Now button below to respond to this message.

Question from gret

Activity with gret (last 90 days):

- I have bid on 0 items from gret

gret( 2)

Positive Feedback: 100%

Member Since: Oct-30-03

Location: CA, United States

Registered On: www.ebay.com

Hello,
I recently placed a bid on item#5669378843 being a wheelchair for me that i really need do to my age(87 years old) and it seems that i can not find the auction anymore...May i please know if you are the seller of the item above?
Regards,
Greta

Respond to this question in My Messages.

Thank you for using eBay!

http://www.ebay.com/

Marketplace Safety Tip

Do not respond to the sender (through the eBay system or your email provider) if this message is an offer to buy or sell an item. This type of offer is against eBay policy, may be fraudulent, and is not covered by buyer protection programs.

Second Chance Offer emails with the subject of �Message from eBay Member� are fake. Real Second Chance Offers come directly from eBay and appear in My Messages with a blue background and subject stating, �eBay Second Chance Offer for Item...".

Never pay for your eBay item using instant cash wire transfer services through Western Union or MoneyGram. These payment methods are unsafe when paying someone you don�t know.

Learn more about sending payments.

Is this email inappropriate? Does it violate eBay policy? Help protect the community by reporting it.

Learn how you can protect yourself from spoof (fake) emails at:
http://pages.ebay.com/education/spooftutorial

This eBay notice was sent to you on behalf of another eBay member through the eBay platform and in accordance with our Privacy Policy. If you would like to receive this email in text format, change your notification preferences.

See our Privacy Policy and User Agreement if you have questions about eBay's communication policies.
Privacy Policy: http://pages.ebay.com/help/policies/privacy-policy.html
User Agreement: http://pages.ebay.com/help/policies/user-agreement.html

Copyright � 2006 eBay, Inc. All Rights Reserved.
Designated trademarks and brands are the property of their respective owners.
eBay and the eBay logo are registered trademarks or trademarks of eBay, Inc.
eBay is located at 2145 Hamilton Avenue, San Jose, CA 95125.

From owner-ccamp@ops.ietf.org Fri Jul 14 12:53:02 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1QuU-0007T0-2M for ccamp-archive@ietf.org; Fri, 14 Jul 2006 12:53:02 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G1QuT-0006bo-GJ for ccamp-archive@ietf.org; Fri, 14 Jul 2006 12:53:02 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G1Qom-000CB2-TL for ccamp-data@psg.com; Fri, 14 Jul 2006 16:47:08 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO autolearn=ham version=3.1.1 Received: from [80.68.34.49] (helo=mail2.noc.data.net.uk) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G1Qok-000CAm-Rf for ccamp@ops.ietf.org; Fri, 14 Jul 2006 16:47:07 +0000 Received: from 57-99.dsl.data.net.uk ([80.68.57.99] helo=cortex.aria-networks.com) by mail2.noc.data.net.uk with esmtp (Exim 3.36 #1) id 1G1Qof-0005BK-00 for ccamp@ops.ietf.org; Fri, 14 Jul 2006 17:47:02 +0100 Received: from your029b8cecfe ([132.219.31.133] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 14 Jul 2006 17:46:59 +0100 Message-ID: <009301c6a765$1ca049c0$851fdb84@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Mack-Crane, T. Benjamin" , "Brungard, Deborah A, ALABS" Cc: References: Subject: Re: Working Group Last Call on draft-ietf-ccamp-gmpls-rsvp-te-call-00.txt Date: Fri, 14 Jul 2006 17:46:42 +0100 Organization: Old Dog Consulting MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-OriginalArrivalTime: 14 Jul 2006 16:47:00.0317 (UTC) FILETIME=[205D78D0:01C6A765] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 36fb765c89ed47dab364ab702a78e8fd Thanks Ben, Thanks for providing the additional details on your previous questions. I think this now gives us something to answer and we will come back to you in a couple of days. Adrian ----- Original Message ----- From: "Mack-Crane, T. Benjamin" To: "Adrian Farrel" ; "Brungard, Deborah A, ALABS" Cc: Sent: Friday, July 14, 2006 5:42 PM Subject: RE: Working Group Last Call on draft-ietf-ccamp-gmpls-rsvp-te-call-00.txt Hi Adrian, There were also these comments which have not been fully addressed afaik: > > 3) The network models being used in section 4.3 and section 7 are > > not clear. In particular the relationships between the call > > controllers, network boundaries, ingress/egress nodes, and > > ingress/egress links are not clear. Figures would be very helpful here. > > Figures are always helpful, and usually (but not always) better than > words. > > In order to be sure to clarify the network models that you are finding > confusing, it would be helpful if you asked specific questions or proposed > text. It is not clear how the form of initiation of a call affects the information available about the egress link. In part this may be affected by whether the ingress node is inside or outside the network (IGP) boundary. It would seem that the situation at the egress would have something to do with this as well. It is unclear where the egress trail termination point is expected to be, e.g. inside or outside the network boundary, and, if inside, at the near or far side of the egress node's matrix. > >5) The call control mechanism defined appears to support > > only IPv4 or IPv6 addressed endpoints from a single address > > space. Is this correct? > > I don't think so. I would be interested to know how to correctly understand the draft. That is, what addressing other than IPv4/6 is supported, and how multiple address spaces are supported. Regards, Ben > -----Original Message----- > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf > Of Adrian Farrel > Sent: Wednesday, July 12, 2006 2:54 PM > To: Brungard, Deborah A, ALABS > Cc: ccamp@ops.ietf.org > Subject: Re: Working Group Last Call on draft-ietf-ccamp-gmpls-rsvp-te- > call-00.txt > > Hi, > > > The Working Group Last Call has closed on this document. > > > > Authors/editors please summarize the comments and document > > how they will be addressed. > > Thanks Deborah, it's interesting to be on the receiving side for a change > :-) > > I noted the following comments during WG last call. > > 1. Desirability of liaison to ITU-T SG15 (Lyndon) > Lyndon suggested that this I-D should be liaised to SG15 prior to becoming > an RFC to ensure that terminology is correct and that it meets the > requirments for supporting ASON calls. > Our response here is that: > a. This I-D is not specifically targeted at satisfying RFC4139. > b. An applicability statement will be produced describing how this and > other I-Ds/RFCs can be used to meet the requirements set out in > RFC4139. That work will definitely be liaised to the ITU-T. > c. The terms used in this document are not specific to ASON, but > in general they have been taken from RFC4139 and RFC4397 > both of which received substantial and useful review by SG15. > No further action is planned by the authors. > > 2. Format of Long Call ID (Lyndon) > Lyndon points out that a format for the long call ID has been defined in > G.7713.2 and suggests that this might be included by reference. > The authors note that the format of an ASON call ID is defined in several > places (including G.7713.1 and G.7713.2), but the intention of the draft > is > not to be limited to ASON applicability. Therefore other call ID formats > would also be supported, and the format is out of scope for the draft. > An applicability statement will be produced describing how this and other > I-Ds/RFCs can be used to meet the requirements set out in RFC4139, and > that > will definitely include the encoding of ASON call IDs. That work will be > liaised to the ITU-T. > No further action is planned by the authors. > > 3. Location of Short Call ID in Path message (Lyndon and Ben) > Both Lyndon and Ben questioned the location of the short call ID in the > Session object. > a. Impact of existing, non-conformant implementations > The draft currently describes the behavior if non-conformant transit > LSRs react to the use of the previously reserved bits of the Session > object. They might reject the Path message, or they might zero out > the short call ID. > Lyndon asked whether it might be better to use a separate object > to avoid this issue completely. > The authors had previously discussed this point at some length and > believe that protocol design should not be shaped by the possiblity > of dysfunctional implementations. Further, the use of a new object > might also cause problems with defective implementations. > The authors propose no changes to the I-D for this point, but will > send mail to the MPLS mailing list to check that the 'owners' of > RSVP-TE have no issue with this use of a previkously reserved > field. > b. Illogicality of use of Session object > Ben and Lyndon expressed the view that it would be more > logical to place the short call ID in a new object than to > complicate the concept of the Session. The possibility of > using the Association object was also raised. > The authors had discussed this at some length over the > last two years that the I-D has been in production, and > recently on the mailing list. Our conclusion is that: > i. The Association object is for associating LSPs with > each other. The call ID is used to associate LSPs > with a call. > ii. A separate object would be perfectly functional. > iii. There is already some logical association between the > session and the LSPs in the call, and it makes sense to > extend this. > iv. The key on the Notify message is the session. > v. The current I-D is also perfectly functional, and has been > successfully implemented. > Given that no specific draw-back to the current encoding has been put > forward except for a feeling of illogicality among some readers, the > authors > propose no further action except for polling the MPLS WG as described > above. > > 4. Procedures for including LINK_CAPABILITIES object > A comment was made that this appears to be totally optional without any > defined procedures for how an LSR should decide wheter to include the > object. > The authors agree with this view, and it is intentional. The draft > states... > The LINK CAPABILITY object is introduced to support link capability > exchange during Call setup and MAY be included in a Notify message > used for Call setup. This optional object includes the bundled link > local capabilities of the Call initiating node (or terminating node) > indicated by the source address of the Notify message. > This text makes it quite clear that the object is completely optional. > The authors propose to make no changes for this point. > > 5. Question about processing rules in section 6.2.1 > There was a detailed quesiton about the procedure in seciton 6.2.1. > The authors believe that this was answered and concluded on the mailing > list. > The authors propose to make no changes for this point. > > 6. Refresh Notify > Lyndon asked whether the refresh of the Notify message is really necessary > if there are active LSPs in the call? Possibly the LSP refresh > could be sufficient, since this carries the short Call ID. He also asked > if it possible that the call would be dropped while there are still > active LSPs. > The authors consider that you cannot infer the status of the call when > there > are no connections on the call. They believe that a single mechanism > should be used to monitor the call status in all circumstances. > The draft describes refresh failure of calls when connections already > exist > in section 6.7. > > > In short, we propose to make no changes to the document as a result of WG > last call. We will notify the MPLS WG as described above. > > Can this I-D now move on the ADs? > > Thanks, > Adrian > ============================================================ The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any reproduction, dissemination or distribution of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. Tellabs ============================================================ From owner-ccamp@ops.ietf.org Fri Jul 14 12:57:46 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1Qz4-0007cD-Mi for ccamp-archive@ietf.org; Fri, 14 Jul 2006 12:57:46 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G1Qz4-0006jG-34 for ccamp-archive@ietf.org; Fri, 14 Jul 2006 12:57:46 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G1Qka-000Bj9-0v for ccamp-data@psg.com; Fri, 14 Jul 2006 16:42:48 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.1 Received: from [204.154.129.57] (helo=mx4.tellabs.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G1QkY-000Biv-IP for ccamp@ops.ietf.org; Fri, 14 Jul 2006 16:42:46 +0000 Received: from usnvwwms2c.hq.tellabs.com (HELO USNVEX3.tellabs-west.tellabsinc.net) ([172.23.216.105]) by mx4.tellabs.com with ESMTP; 14 Jul 2006 16:42:37 +0000 X-SBRS: None X-IronPort-AV: i="4.06,244,1149465600"; d="scan'208"; a="58069229:sNHT18260912" Received: from USNVEX1.tellabs-west.tellabsinc.net ([172.23.216.101]) by USNVEX3.tellabs-west.tellabsinc.net with Microsoft SMTPSVC(6.0.3790.0); Fri, 14 Jul 2006 11:42:37 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: Working Group Last Call on draft-ietf-ccamp-gmpls-rsvp-te-call-00.txt Date: Fri, 14 Jul 2006 11:42:32 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Working Group Last Call on draft-ietf-ccamp-gmpls-rsvp-te-call-00.txt Thread-Index: Acal7QycniWFvH3/SkG33P44WdPzUABdQFMA From: "Mack-Crane, T. Benjamin" To: "Adrian Farrel" , "Brungard, Deborah A, ALABS" Cc: X-OriginalArrivalTime: 14 Jul 2006 16:42:37.0437 (UTC) FILETIME=[83AD2AD0:01C6A764] Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="us-ascii" Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: a743e34ab8eb08259de9a7307caed594 Hi Adrian, There were also these comments which have not been fully addressed afaik: > > 3) The network models being used in section 4.3 and section 7 are > > not clear. In particular the relationships between the call > > controllers, network boundaries, ingress/egress nodes, and > > ingress/egress links are not clear. Figures would be very helpful here. >=20 > Figures are always helpful, and usually (but not always) better than > words. >=20 > In order to be sure to clarify the network models that you are finding > confusing, it would be helpful if you asked specific questions or proposed > text. It is not clear how the form of initiation of a call affects the information available about the egress link. In part this may be affected by whether the ingress node is inside or outside the network (IGP) boundary. It would seem that the situation at the egress would have something to do with this as well. It is unclear where the egress trail termination point is expected to be, e.g. inside or outside the network boundary, and, if inside, at the near or far side of the egress node's matrix. > >5) The call control mechanism defined appears to support > > only IPv4 or IPv6 addressed endpoints from a single address > > space. Is this correct? >=20 > I don't think so. I would be interested to know how to correctly understand the draft. That is, what addressing other than IPv4/6 is supported, and how multiple address spaces are supported. Regards, Ben > -----Original Message----- > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf > Of Adrian Farrel > Sent: Wednesday, July 12, 2006 2:54 PM > To: Brungard, Deborah A, ALABS > Cc: ccamp@ops.ietf.org > Subject: Re: Working Group Last Call on draft-ietf-ccamp-gmpls-rsvp-te- > call-00.txt >=20 > Hi, >=20 > > The Working Group Last Call has closed on this document. > > > > Authors/editors please summarize the comments and document > > how they will be addressed. >=20 > Thanks Deborah, it's interesting to be on the receiving side for a change > :-) >=20 > I noted the following comments during WG last call. >=20 > 1. Desirability of liaison to ITU-T SG15 (Lyndon) > Lyndon suggested that this I-D should be liaised to SG15 prior to becoming > an RFC to ensure that terminology is correct and that it meets the > requirments for supporting ASON calls. > Our response here is that: > a. This I-D is not specifically targeted at satisfying RFC4139. > b. An applicability statement will be produced describing how this and > other I-Ds/RFCs can be used to meet the requirements set out in > RFC4139. That work will definitely be liaised to the ITU-T. > c. The terms used in this document are not specific to ASON, but > in general they have been taken from RFC4139 and RFC4397 > both of which received substantial and useful review by SG15. > No further action is planned by the authors. >=20 > 2. Format of Long Call ID (Lyndon) > Lyndon points out that a format for the long call ID has been defined in > G.7713.2 and suggests that this might be included by reference. > The authors note that the format of an ASON call ID is defined in several > places (including G.7713.1 and G.7713.2), but the intention of the draft > is > not to be limited to ASON applicability. Therefore other call ID formats > would also be supported, and the format is out of scope for the draft. > An applicability statement will be produced describing how this and other > I-Ds/RFCs can be used to meet the requirements set out in RFC4139, and > that > will definitely include the encoding of ASON call IDs. That work will be > liaised to the ITU-T. > No further action is planned by the authors. >=20 > 3. Location of Short Call ID in Path message (Lyndon and Ben) > Both Lyndon and Ben questioned the location of the short call ID in the > Session object. > a. Impact of existing, non-conformant implementations > The draft currently describes the behavior if non-conformant transit > LSRs react to the use of the previously reserved bits of the Session > object. They might reject the Path message, or they might zero out > the short call ID. > Lyndon asked whether it might be better to use a separate object > to avoid this issue completely. > The authors had previously discussed this point at some length and > believe that protocol design should not be shaped by the possiblity > of dysfunctional implementations. Further, the use of a new object > might also cause problems with defective implementations. > The authors propose no changes to the I-D for this point, but will > send mail to the MPLS mailing list to check that the 'owners' of > RSVP-TE have no issue with this use of a previkously reserved > field. > b. Illogicality of use of Session object > Ben and Lyndon expressed the view that it would be more > logical to place the short call ID in a new object than to > complicate the concept of the Session. The possibility of > using the Association object was also raised. > The authors had discussed this at some length over the > last two years that the I-D has been in production, and > recently on the mailing list. Our conclusion is that: > i. The Association object is for associating LSPs with > each other. The call ID is used to associate LSPs > with a call. > ii. A separate object would be perfectly functional. > iii. There is already some logical association between the > session and the LSPs in the call, and it makes sense to > extend this. > iv. The key on the Notify message is the session. > v. The current I-D is also perfectly functional, and has been > successfully implemented. > Given that no specific draw-back to the current encoding has been put > forward except for a feeling of illogicality among some readers, the > authors > propose no further action except for polling the MPLS WG as described > above. >=20 > 4. Procedures for including LINK_CAPABILITIES object > A comment was made that this appears to be totally optional without any > defined procedures for how an LSR should decide wheter to include the > object. > The authors agree with this view, and it is intentional. The draft > states... > The LINK CAPABILITY object is introduced to support link capability > exchange during Call setup and MAY be included in a Notify message > used for Call setup. This optional object includes the bundled link > local capabilities of the Call initiating node (or terminating node) > indicated by the source address of the Notify message. > This text makes it quite clear that the object is completely optional. > The authors propose to make no changes for this point. >=20 > 5. Question about processing rules in section 6.2.1 > There was a detailed quesiton about the procedure in seciton 6.2.1. > The authors believe that this was answered and concluded on the mailing > list. > The authors propose to make no changes for this point. >=20 > 6. Refresh Notify > Lyndon asked whether the refresh of the Notify message is really necessary > if there are active LSPs in the call? Possibly the LSP refresh > could be sufficient, since this carries the short Call ID. He also asked > if it possible that the call would be dropped while there are still > active LSPs. > The authors consider that you cannot infer the status of the call when > there > are no connections on the call. They believe that a single mechanism > should be used to monitor the call status in all circumstances. > The draft describes refresh failure of calls when connections already > exist > in section 6.7. >=20 >=20 > In short, we propose to make no changes to the document as a result of WG > last call. We will notify the MPLS WG as described above. >=20 > Can this I-D now move on the ADs? >=20 > Thanks, > Adrian >=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any reproduction, dissemination or distribution of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. Tellabs =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D From owner-ccamp@ops.ietf.org Mon Jul 17 05:32:51 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2PT9-0000tp-Un for ccamp-archive@ietf.org; Mon, 17 Jul 2006 05:32:51 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2PT8-0003d3-FV for ccamp-archive@ietf.org; Mon, 17 Jul 2006 05:32:51 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G2PLn-000Ihc-Kx for ccamp-data@psg.com; Mon, 17 Jul 2006 09:25:15 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.1 Received: from [145.99.148.35] (helo=mickey.macfreek.nl) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G2PLm-000IhG-9r for ccamp@ops.ietf.org; Mon, 17 Jul 2006 09:25:14 +0000 Received: from [146.50.22.53] (mbp-freek.science.uva.nl [146.50.22.53]) by mickey.macfreek.nl (Postfix) with ESMTP id CDEA34AAA6 for ; Mon, 17 Jul 2006 11:25:06 +0200 (CEST) Message-ID: <44BB5775.1000801@science.uva.nl> Date: Mon, 17 Jul 2006 11:25:09 +0200 From: Freek Dijkstra User-Agent: Mail/News 1.5.0.2 (Macintosh/20060401) MIME-Version: 1.0 To: ccamp@ops.ietf.org Subject: Ethernet interface in a TDM device: FSC, TDM, or L2SC? X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Hi, Another question. I have a SONET cross connect. That is, a TDM device. Most of the interfaces are TDM switch capable interfaces, which known only about TDM encoding. However, one of the interfaces of this devices knows about Ethernet encoding, and is capable of taking the Ethernet packets and embed them in a couple of STS channels (e.g. STC-24c or STS-3c-7v). My question: what is the switching capability of this device? It's not a L2SC, since it does not make decisions based on the MAC addresses. I'm inclined to think it is also not a TDM switch capable interface, since it does not switch based on time slots. All it does is embed all data it encounters on the fiber. So it seems to me that this interface is a Fiber-Switch capable (FSC) interface with Ethernet encoding, despite that it is in a "TDM device". Am I correct here? Regards, Freek From owner-ccamp@ops.ietf.org Mon Jul 17 05:43:39 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2Pdb-0001Mi-V0 for ccamp-archive@ietf.org; Mon, 17 Jul 2006 05:43:39 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2PdZ-0004Qw-Dv for ccamp-archive@ietf.org; Mon, 17 Jul 2006 05:43:39 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G2PaX-000Jmd-Mf for ccamp-data@psg.com; Mon, 17 Jul 2006 09:40:29 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-0.7 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_POST,NO_REAL_NAME autolearn=no version=3.1.1 Received: from [62.23.212.165] (helo=smail.alcatel.fr) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G2PaU-000Jm8-MJ for ccamp@ops.ietf.org; Mon, 17 Jul 2006 09:40:27 +0000 Received: from bemail05.netfr.alcatel.fr (bemail05.netfr.alcatel.fr [155.132.251.11]) by smail.alcatel.fr (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k6H9eNuR025674; Mon, 17 Jul 2006 11:40:24 +0200 In-Reply-To: <44BB5775.1000801@science.uva.nl> To: Freek Dijkstra Cc: ccamp@ops.ietf.org Subject: Re: Ethernet interface in a TDM device: FSC, TDM, or L2SC? MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: Dimitri.Papadimitriou@alcatel.be Date: Mon, 17 Jul 2006 11:40:33 +0200 X-MIMETrack: Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 07/17/2006 11:40:23, Serialize complete at 07/17/2006 11:40:23 Content-Type: text/plain; charset="US-ASCII" X-Scanned-By: MIMEDefang 2.51 on 155.132.180.81 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.2 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 hi - it can't be FSC as you don't switch in the spatial domain (FSC is for inst. used in the case of fiber distribution frames) in your case your interface knows about processing payload of the TDM LSP, hence the point is if you put such i/f back to back o) do you switch the STS -> TDM LSP with TDM encoding and TDM ST o) do you switch the whole Ethernet packet flow from port-to-port (no granularity from the Ethernet header info) -> Ethernet LSP with TDM Encoding and L2SC ps: if you take such flow from another interface and have limited capacity i suggest you take a look at the mln/mln solution doc where you can link such capacities much thanks, - dimitri. Freek Dijkstra Sent by: owner-ccamp@ops.ietf.org 17/07/2006 11:25 To: ccamp@ops.ietf.org cc: Subject: Ethernet interface in a TDM device: FSC, TDM, or L2SC? Hi, Another question. I have a SONET cross connect. That is, a TDM device. Most of the interfaces are TDM switch capable interfaces, which known only about TDM encoding. However, one of the interfaces of this devices knows about Ethernet encoding, and is capable of taking the Ethernet packets and embed them in a couple of STS channels (e.g. STC-24c or STS-3c-7v). My question: what is the switching capability of this device? It's not a L2SC, since it does not make decisions based on the MAC addresses. I'm inclined to think it is also not a TDM switch capable interface, since it does not switch based on time slots. All it does is embed all data it encounters on the fiber. So it seems to me that this interface is a Fiber-Switch capable (FSC) interface with Ethernet encoding, despite that it is in a "TDM device". Am I correct here? Regards, Freek From owner-ccamp@ops.ietf.org Mon Jul 17 06:25:22 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2QHy-0004yJ-En for ccamp-archive@ietf.org; Mon, 17 Jul 2006 06:25:22 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2Q9P-0007Ux-T1 for ccamp-archive@ietf.org; Mon, 17 Jul 2006 06:16:31 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G2Q9P-0007R8-0b for ccamp-archive@ietf.org; Mon, 17 Jul 2006 06:16:31 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G2Pyr-000LdT-UE for ccamp-data@psg.com; Mon, 17 Jul 2006 10:05:37 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [145.99.148.35] (helo=mickey.macfreek.nl) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G2Pyr-000LdH-8M for ccamp@ops.ietf.org; Mon, 17 Jul 2006 10:05:37 +0000 Received: from [146.50.22.53] (mbp-freek.science.uva.nl [146.50.22.53]) by mickey.macfreek.nl (Postfix) with ESMTP id A1B8B4AAA6; Mon, 17 Jul 2006 12:05:35 +0200 (CEST) Message-ID: <44BB60F1.3030906@science.uva.nl> Date: Mon, 17 Jul 2006 12:05:37 +0200 From: Freek Dijkstra User-Agent: Mail/News 1.5.0.2 (Macintosh/20060401) MIME-Version: 1.0 To: Dimitri.Papadimitriou@alcatel.be Cc: ccamp@ops.ietf.org Subject: Re: Ethernet interface in a TDM device: FSC, TDM, or L2SC? References: In-Reply-To: X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Hi Dimitri, Thanks for your insights. > in your case your interface knows about processing payload of the TDM LSP, > hence the point is if you put such i/f back to back > > o) do you switch the STS -> TDM LSP with TDM encoding and TDM ST > > o) do you switch the whole Ethernet packet flow from port-to-port (no > granularity from the Ethernet header info) -> Ethernet LSP with TDM > Encoding and L2SC Neither. The link between two of these kind of interfaces will be pure Ethernet, no TDM encoding. Let me make a drawing here. Gigabit +------------+ Gigabit Ethernet | | Ethernet in ---------------o TDM switch o---------------------- in UTP A | | B STS-24c in OC-192 +------------+ My question concerned interface A in the above drawing. It seems that your descriptions concern interface B instead. In this case all bytes from interface A are adapted in 24 STS channels, which are then adapted to the OC-192 of interface B. I can imagine three lines of reasoning: * Interface A announces LSC with Ethernet encoding. After all, it does not look into the headers, and also does no do the TDM encoding (that happens at interface B) * Interface A announces TDM ST with Ethernet encoding. After all, it will embed the Ethernet packets in STS, so it knows about TDM switching. * Interface A announces L2SC with Ethernet encoding. That seems incorrect; while the interfaces will probably know about frame bounderies, it does not process the header. I assume the first or second is correct. > ps: if you take such flow from another interface and have limited capacity > i suggest you take a look at the mln/mln solution doc where you can link > such capacities Do you have a reference? Regards, Freek From owner-ccamp@ops.ietf.org Mon Jul 17 07:10:42 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2Qzq-0007TN-Qe for ccamp-archive@ietf.org; Mon, 17 Jul 2006 07:10:42 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2QP1-00023g-0U for ccamp-archive@ietf.org; Mon, 17 Jul 2006 06:32:39 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G2QH2-0007Wd-9g for ccamp-archive@ietf.org; Mon, 17 Jul 2006 06:24:25 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G2QCs-000McO-2t for ccamp-data@psg.com; Mon, 17 Jul 2006 10:20:06 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-0.7 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_POST,NO_REAL_NAME autolearn=no version=3.1.1 Received: from [62.23.212.165] (helo=smail.alcatel.fr) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G2QCr-000Mbb-AD for ccamp@ops.ietf.org; Mon, 17 Jul 2006 10:20:05 +0000 Received: from bemail05.netfr.alcatel.fr (bemail05.netfr.alcatel.fr [155.132.251.11]) by smail.alcatel.fr (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k6HAK4Rn020311; Mon, 17 Jul 2006 12:20:04 +0200 In-Reply-To: <44BB60F1.3030906@science.uva.nl> To: Freek Dijkstra Cc: ccamp@ops.ietf.org Subject: Re: Ethernet interface in a TDM device: FSC, TDM, or L2SC? MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: Dimitri.Papadimitriou@alcatel.be Date: Mon, 17 Jul 2006 12:20:12 +0200 X-MIMETrack: Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 07/17/2006 12:20:02, Serialize complete at 07/17/2006 12:20:02 Content-Type: text/plain; charset="US-ASCII" X-Scanned-By: MIMEDefang 2.51 on 155.132.180.81 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: -2.6 (--) X-Scan-Signature: 386e0819b1192672467565a524848168 hi - from your drawing, i/f B: TDM and i/f A: L2SC with Ethernet port mode - not frame mode - in the port mode case for i/f A the Max = Min LSP bandwidth = port capacity note: your device is combining the two interfaces i initially describes the reference i provided allows to link capacities between interfaces (i/f A with i/f B) see IACD sub-TLV section thanks, - d. Freek Dijkstra Sent by: owner-ccamp@ops.ietf.org 17/07/2006 12:05 To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL cc: ccamp@ops.ietf.org Subject: Re: Ethernet interface in a TDM device: FSC, TDM, or L2SC? Hi Dimitri, Thanks for your insights. > in your case your interface knows about processing payload of the TDM LSP, > hence the point is if you put such i/f back to back > > o) do you switch the STS -> TDM LSP with TDM encoding and TDM ST > > o) do you switch the whole Ethernet packet flow from port-to-port (no > granularity from the Ethernet header info) -> Ethernet LSP with TDM > Encoding and L2SC Neither. The link between two of these kind of interfaces will be pure Ethernet, no TDM encoding. Let me make a drawing here. Gigabit +------------+ Gigabit Ethernet | | Ethernet in ---------------o TDM switch o---------------------- in UTP A | | B STS-24c in OC-192 +------------+ My question concerned interface A in the above drawing. It seems that your descriptions concern interface B instead. In this case all bytes from interface A are adapted in 24 STS channels, which are then adapted to the OC-192 of interface B. I can imagine three lines of reasoning: * Interface A announces LSC with Ethernet encoding. After all, it does not look into the headers, and also does no do the TDM encoding (that happens at interface B) * Interface A announces TDM ST with Ethernet encoding. After all, it will embed the Ethernet packets in STS, so it knows about TDM switching. * Interface A announces L2SC with Ethernet encoding. That seems incorrect; while the interfaces will probably know about frame bounderies, it does not process the header. I assume the first or second is correct. > ps: if you take such flow from another interface and have limited capacity > i suggest you take a look at the mln/mln solution doc where you can link > such capacities Do you have a reference? Regards, Freek From owner-ccamp@ops.ietf.org Mon Jul 17 14:32:51 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2Xtj-0000m6-RJ for ccamp-archive@ietf.org; Mon, 17 Jul 2006 14:32:51 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2Xtg-0007vH-UO for ccamp-archive@ietf.org; Mon, 17 Jul 2006 14:32:51 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G2XmZ-0006rj-SJ for ccamp-data@psg.com; Mon, 17 Jul 2006 18:25:27 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.1 Received: from [80.68.34.48] (helo=mail1.noc.data.net.uk) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G2XmW-0006rO-89 for ccamp@ops.ietf.org; Mon, 17 Jul 2006 18:25:24 +0000 Received: from 57-99.dsl.data.net.uk ([80.68.57.99] helo=cortex.aria-networks.com) by mail1.noc.data.net.uk with esmtp (Exim 3.36 #2) id 1G2Xmo-00007l-00 for ccamp@ops.ietf.org; Mon, 17 Jul 2006 19:25:42 +0100 Received: from your029b8cecfe ([217.158.132.188] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 17 Jul 2006 19:25:21 +0100 Message-ID: <02d401c6a9ce$56febcd0$851fdb84@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: , Cc: "Ross Callon" , , "Brungard, Deborah A, ALABS" , "Dimitri Papadimitriou" , "Loa Andersson" Subject: Next steps for GMPLS control of Ethernet Date: Mon, 17 Jul 2006 19:24:34 +0100 Organization: Old Dog Consulting MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-OriginalArrivalTime: 17 Jul 2006 18:25:22.0011 (UTC) FILETIME=[5D49C2B0:01C6A9CE] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Hi CCAMPers and GELSters, In CCAMP this time we explained the discussions and agreements that the chairs had with the ADs with respect to the way forward for developing GMPLS extensions and procedures for the control of Ethernet devices. This email is to clarify the explanation and to give a base reference for the procedures that we expect to be followed. - Work on procedures and extensions to GMPLS for the control of Ethernet devices will be done in CCAMP. - This work is already covered by the CCAMP charter... The CCAMP working group coordinates the work within the IETF defining a common control plane and a separate common measurement plane for physical path and core tunneling technologies of Internet and telecom service providers (ISPs and SPs) However, if necessary, and if work is forthcoming, we will consider adding a specific work item an milestones to the charter. Such a charter change is not gating on this work, but may be useful for clarity and exposure of the work outside of CCAMP. - Data plane specification is out of scope for the IETF. It must not be discussed on the CCAMP list. It may be discussed on the GELS list. - CCAMP will not work on the specification of GMPLS except for data planes that are already approved by an SDO with responsibility for the Ethernet data plane. It is expected that the primary SDO in this case is IEEE. We expect that you would use the following steps in order. 1. Decide upon the data plane behavior you wish to control 2. Ensure that the data plane you wish to control is approved and documented by an SDO with responsibility for Ethernet (e.g. IEEE). This may be a null op in the case of existing standards, but might require you to do work in the other SDO for new standards for profiles of existing standards. 3. Start protocol work in CCAMP with an explicit pointer to the approved data plane. If you feel the need to explain your data plane in your I-D, then there is probably something wrong with the specification in the other SDO and you should return to step 2. 4. When it is clear that protocol work is progressing, Deborah and I will liaise with the other SDO to get their blessing for using a control plane for the nominated data plane. Note that this procedure can apply to multiple data planes at the same time or separately, but we expect that the protocol encoding extensions will be flexible to all data planes. Hope this is clear, Adrian and Deborah From owner-ccamp@ops.ietf.org Mon Jul 17 16:57:37 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2a9p-0007fg-SF for ccamp-archive@ietf.org; Mon, 17 Jul 2006 16:57:37 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2a9o-0002mu-9S for ccamp-archive@ietf.org; Mon, 17 Jul 2006 16:57:37 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G2a4G-000HDZ-Jx for ccamp-data@psg.com; Mon, 17 Jul 2006 20:51:52 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-0.9 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO,RCVD_IN_WHOIS_INVALID autolearn=no version=3.1.1 Received: from [129.254.16.131] (helo=email1.etri.info) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G2a4D-000HD2-18 for ccamp@ops.ietf.org; Mon, 17 Jul 2006 20:51:49 +0000 Received: from mail pickup service by email1.etri.info with Microsoft SMTPSVC; Tue, 18 Jul 2006 05:55:00 +0900 Reply-To: "CHO, JAI HYUNG" From: "CHO, JAI HYUNG" To: "Adrian Farrel" , , Cc: Bcc: thread-index: Acap4EuvXB57YnxxT8yFg5CeeEQr9QAAvkHz Date: Tue, 18 Jul 2006 05:55:00 +0900 Thread-Topic: Next steps for GMPLS control of Ethernet Message-ID: <013c01c6a9e3$44b8f440$8310fe81@etri.info> Subject: RE: Next steps for GMPLS control of Ethernet X-Mailer: Microsoft CDO for Exchange 2000 Comment: GQ19@|@ZEk=E?,18?x, D38.>n@L4u3]?,18F@, 4c4g MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Class: urn:content-classes:message Importance: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.1830 X-OriginalArrivalTime: 17 Jul 2006 20:55:00.0431 (UTC) FILETIME=[44D7EDF0:01C6A9E3] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 This is great and fair decision to everybody. I welcome and support this decision. Thank you Adrian and Debora. Jaihyung Dr. Jaihyung Cho ETRI, Korea phone : 042) 860-5514 oversea: +82-42-860-5514 fax: +82-42-861-5550 -----?? ???----- ?? ??: "Adrian Farrel" ?? ??: 2006-07-18 ?? 3:24:34 ?? ??: "ccamp@ops.ietf.org" , "gels@rtg.ietf.org" ??: "Ross Callon" , "Dimitri Papadimitriou" , "Brungard, Deborah A, ALABS" , "fenner@rearch.att.com" , "Loa Andersson" ??: Next steps for GMPLS control of Ethernet Hi CCAMPers and GELSters, In CCAMP this time we explained the discussions and agreements that the chairs had with the ADs with respect to the way forward for developing GMPLS extensions and procedures for the control of Ethernet devices. This email is to clarify the explanation and to give a base reference for the procedures that we expect to be followed. - Work on procedures and extensions to GMPLS for the control of Ethernet devices will be done in CCAMP. - This work is already covered by the CCAMP charter... The CCAMP working group coordinates the work within the IETF defining a common control plane and a separate common measurement plane for physical path and core tunneling technologies of Internet and telecom service providers (ISPs and SPs) However, if necessary, and if work is forthcoming, we will consider adding a specific work item an milestones to the charter. Such a charter change is not gating on this work, but may be useful for clarity and exposure of the work outside of CCAMP. - Data plane specification is out of scope for the IETF. It must not be discussed on the CCAMP list. It may be discussed on the GELS list. - CCAMP will not work on the specification of GMPLS except for data planes that are already approved by an SDO with responsibility for the Ethernet data plane. It is expected that the primary SDO in this case is IEEE. We expect that you would use the following steps in order. 1. Decide upon the data plane behavior you wish to control 2. Ensure that the data plane you wish to control is approved and documented by an SDO with responsibility for Ethernet (e.g. IEEE). This may be a null op in the case of existing standards, but might require you to do work in the other SDO for new standards for profiles of existing standards. 3. Start protocol work in CCAMP with an explicit pointer to the approved data plane. If you feel the need to explain your data plane in your I-D, then there is probably something wrong with the specification in the other SDO and you should return to step 2. 4. When it is clear that protocol work is progressing, Deborah and I will liaise with the other SDO to get their blessing for using a control plane for the nominated data plane. Note that this procedure can apply to multiple data planes at the same time or separately, but we expect that the protocol encoding extensions will be flexible to all data planes. Hope this is clear, Adrian and Deborah From owner-ccamp@ops.ietf.org Mon Jul 17 22:00:12 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2ese-0006eV-Cw for ccamp-archive@ietf.org; Mon, 17 Jul 2006 22:00:12 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2esb-00079r-Ui for ccamp-archive@ietf.org; Mon, 17 Jul 2006 22:00:12 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G2emW-000Bqf-VX for ccamp-data@psg.com; Tue, 18 Jul 2006 01:53:52 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.1 Received: from [47.129.242.57] (helo=zcars04f.nortel.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G2emV-000BqI-Bh for ccamp@ops.ietf.org; Tue, 18 Jul 2006 01:53:51 +0000 Received: from zcarhxm0.corp.nortel.com (zcarhxm0.corp.nortel.com [47.129.230.95]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k6I1rir19884 for ; Mon, 17 Jul 2006 21:53:44 -0400 (EDT) x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: VLAN label range requirement Date: Mon, 17 Jul 2006 21:53:41 -0400 Message-ID: <29D15BBCA340DA4D8146D38B4924FC7A074831B0@zcarhxm0.corp.nortel.com> In-Reply-To: <44B4FEB1.3080500@psg.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: VLAN label range requirement Thread-Index: Acalusf3c+VL76ogRtiZfGdQ6MooRAEUbswA From: "Stephen Shew" To: Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: cd3fc8e909678b38737fc606dec187f0 The size of the range has more to do with the total number of VLANs that have to be mapped. In theory, all 1024 could be mapped (between client and network at the UNI) and also in the other direction. Further, the mapping at the egress UNI has to be carried (again for both directions), so the max size could be 4k. -----Original Message----- From: dimitri papadimitriou [mailto:dpapadimitriou@psg.com]=20 Sent: July 12, 2006 09:53 To: Ong, Lyndon Cc: dimitri.papadimitriou@alcatel.be; Shew, Stephen (CAR:Q840); Adrian Farrel; ccamp@ops.ietf.org Subject: Re: VLAN label range requirement lyndon - not sure to understand - the information part of the liaison question was "how large is large" ? eg. RFC 3946 support VC4-256v did you ever ask the question whether we have an efficient encoding ? Ong, Lyndon wrote: > Sure, I understand. I think the concern that was expressed at the last > OIF > meeting was whether we might need to define an efficient way of > describing > a set consisting of a very large set of labels, since the range of VLAN > tags, > for example, is quite a bit larger than the typical set of labels > assumed for > optical switches. If OIF comes up with=20 > any proposals along those lines, it would then liaise this to CCAMP for > its > consideration. >=20 > Cheers, >=20 > Lyndon=20 >=20 > -----Original Message----- > From: dimitri papadimitriou [mailto:dpapadimitriou@psg.com]=20 > Sent: Wednesday, July 12, 2006 6:33 AM > To: Ong, Lyndon > Cc: Stephen Shew; Adrian Farrel; ccamp@ops.ietf.org > Subject: Re: VLAN label range requirement >=20 > lyndon - >=20 > listing a set of labels as part of the response is something already > covered in GMPLS >=20 > hence if i well understand the MEF.10 document the information elements > that needs to be considered is quite straightforward >=20 > so do we need this loop back and forth ? why not just produce a 2 page > doc and close this ? >=20 > thx, > - d. >=20 > Ong, Lyndon wrote: >=20 >=20 >>That was my interpretation also, not sure if that came through on the=20 >>slides. >> >>Lyndon >> >>-----Original Message----- >>From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On=20 >>Behalf Of Stephen Shew >>Sent: Tuesday, July 11, 2006 8:09 PM >>To: Adrian Farrel; ccamp@ops.ietf.org >>Subject: RE: VLAN label range requirement >> >>You're welcome. >> >>The response from CCAMP on this question is very thorough, and I=20 >>certainly appreciate the thought that went into it. My interpretation >=20 >=20 >>of the response is that that CCAMP encourages the OIF to design an=20 >>encoding for the VLAN identifiers, and communicate it back to CCAMP. >> >>Stephen >> >>-----Original Message----- >>From: Adrian Farrel [mailto:adrian@olddog.co.uk] >>Sent: July 11, 2006 18:42 >>To: Shew, Stephen (CAR:Q840); ccamp@ops.ietf.org >>Subject: Re: VLAN label range requirement >> >>Thanks Stephen. >> >>What is your opinion of the response to this question that CCAMP=20 >>supplied in its return communication to the OIF? >> >>Adrian >>----- Original Message ----- >>From: "Stephen Shew" >>To: >>Sent: Tuesday, July 11, 2006 4:44 PM >>Subject: VLAN label range requirement >> >> >>In yesterday's meeting, there was a request for more information on=20 >>the VLAN label range requirement. From the original OIF liaison, the=20 >>description was: >>"We are investigating label formats to represent a list or range of=20 >>VLAN identifiers, as used in MEF.11 bundling. In the case where a=20 >>large number of non-consecutive VLAN identifiers is used for the same=20 >>connection, we would like to keep the label to a reasonable size." >> >>The requirement to send a range of VLAN identifiers in signalling=20 >>arises in the bundling feature in Ethernet services as specified in=20 >>Metro Ethernet Forum (MEF) and ITU-T SG15 documents. In the MEF, the=20 >>MEF.11 spec "User Network Interface (UNI) Requirements and Framework"=20 >>there is a UNI service attribute called "bundling" that is described=20 >>as "A UNI attribute in which more than one CE-VLAN ID is associated >=20 > with an EVC." >=20 >>It is more fully described in MEF.10 "Ethernet Services Attributes=20 >>Phase 1". Both technical specs may be obtained free at: >>http://www.metroethernetforum.org/TechSpec.htm >> >>Equivalent ITU-T Recs. are G.8011, G8011.1, and G.8011.2. These are=20 >>available to ITU-T members, or under a "3 free" capability on the=20 >>ITU-T website. >> >>Of interest is the MEF Ethernet Link Management Interface (E-LMI)=20 >>defined in MEF.16 that has an encoding for passing VLAN ranges between >=20 >=20 >>the UNI client and network. This in a structure called the "CE-VLAN=20 >>ID/EVC Map information element". >> >>I hope this provides more clarity to the VLAN label range issue. >> >>Stephen Shew >>Metro Ethernet Networks >>Nortel >>sdshew@nortel.com >>Telephone: +1 613 763 2462 / ESN 393 2462 >> >> >> >> >>. >> >=20 >=20 > . >=20 From cordao@personalizado.com.br Tue Jul 18 08:10:56 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2oPg-0002Sp-Tp for ccamp-archive@ietf.org; Tue, 18 Jul 2006 08:10:56 -0400 Received: from 201.22.135.119.adsl.gvt.net.br ([201.22.135.119] helo=192.168.1.4) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G2oPY-00043M-PP for ccamp-archive@ietf.org; Tue, 18 Jul 2006 08:10:56 -0400 From: "Cord�o Personalizado" To: Subject: CRACH�S E ACESS�RIOS Sender: "Cord�o Personalizado" Mime-Version: 1.0 Content-Type: multipart/related; boundary="= Multipart Boundary 0718060914" Date: Tue, 18 Jul 2006 09:14:11 -0300 X-Spam-Score: 3.7 (+++) X-Scan-Signature: b4be0d55bab88df9d21005ced9551e26 This is a multipart MIME message. --= Multipart Boundary 0718060914 Content-Type: multipart/alternative; boundary="= Multipart Boundary _EXTRA_0718060914" --= Multipart Boundary _EXTRA_0718060914 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit CRACH�S E ACESS�RIOS ENVIAMOS AMOSTRA SEM COMPROMISSO PARA TODO BRASIL Compromisso p�blico de entrega em 15 dias, REGISTRADO EM CART�RIO. PAGAMENTO DA MERCADORIA SOMENTE QUANDO RECEB�-LA Crach�: Em PVC flex�vel em policromia at� 16 milh�es de cores, com foto e impress�o com tecnologia digital. Cord�o: 100% poliester medindo 43cm de comprimento por 1,1cm de largura, com presilha padr�o tipo jacar�, podemos fabricar sob medida para revendedores e vendas por atacado. Pintura emborrachada com exclusiva tinta HiperFix. Frete: Por meio dos Correios; Prazo de entrega: 15 dias ap�s aprova��o da arte. Forma de Pagamento: Dep�sito Banc�rio, Boleto, cheque nominal ou dinheiro. Empresa fundada em 1996. Emitimos Nota fiscal para todos os nossos produtos Fone:(61) 3202-0407 Fax:(61) 3964-0407 Celular:(61) 9213-9219 Email: cordao@correios.net.br Parceria de atendimento via Correio. Para ser removido, responda indicando no Assunto: REMOVER. --= Multipart Boundary _EXTRA_0718060914 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit

CRACH�S E ACESS�RIOS

ENVIAMOS AMOSTRA SEM COMPROMISSO PARA TODO BRASIL

Compromisso p�blico de entrega em 15 dias, REGISTRADO EM CART�RIO.

PAGAMENTO DA MERCADORIA SOMENTE QUANDO RECEB�-LA

Crach�: Em PVC flex�vel em policromia at� 16 milh�es de cores, com foto e impress�o com tecnologia digital.

Cord�o: 100% poliester medindo 43cm de comprimento por 1,1cm de largura, com presilha padr�o tipo jacar�, podemos fabricar sob medida para revendedores e vendas por atacado. Pintura emborrachada com exclusiva tinta HiperFix.

Frete: Por meio dos Correios; Prazo de entrega: 15 dias ap�s aprova��o da arte.

Forma de Pagamento: Dep�sito Banc�rio, Boleto, cheque nominal ou dinheiro.

Empresa fundada em 1996. Emitimos Nota fiscal para todos os nossos produtos

Fone:(61) 3202-0407 Fax:(61) 3964-0407 Celular:(61) 9213-9219

Email: cordao@correios.net.br Parceria de atendimento via Correio.
Para ser removido, responda indicando no Assunto: REMOVER.

--= Multipart Boundary _EXTRA_0718060914-- --= Multipart Boundary 0718060914 Content-Type: application/octet-stream; name="email html Anuncios ligth.jpg" Content-Transfer-Encoding: base64 Content-ID: <1522499> Content-Disposition: attachment; filename="email html Anuncios ligth.jpg" /9j/4AAQSkZJRgABAQEBLAEsAAD/2wBDAAMCAgMCAgMDAwMEAwMEBQgFBQQE BQoHBwYIDAoMDAsKCwsNDhIQDQ4RDgsLEBYQERMUFRUVDA8XGBYUGBIUFRT/ 2wBDAQMEBAUEBQkFBQkUDQsNFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQU FBQUFBQUFBQUFBQUFBQUFBQUFBQUFBT/wAARCABqAaMDASIAAhEBAxEB/8QA HwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUF BAQAAAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkK FhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1 dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXG x8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEAAwEBAQEB AQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAEC AxEEBSExBhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRom JygpKjU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOE hYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU 1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD9B/D+kXXx Z0PT/EWq6/fwaRqUCXVnpWiXEtjGsDqGQyTLtmeQ55IZFxgbPvF5NK+Efwx1 sXLxeGdG1o20720019bi7YSocOpeXcSQeDyec9wa+TvBk+tS/GrwBdO+rzeF fDnw60bV74WuvvZW1mFSctLJbYK3O7ywpX5eBkk14TZ/HPxH4s+DL6Y3ibVH 1Gbx5Z6lJJNrUujMsF9p11K1v9pfGyFJ4ZMHlDgEdQam5Vj9Nf8AhRPw1/6J /wCF/wDwTW//AMRR/wAKJ+Gv/RP/AAv/AOCa3/8AiK/OrwF8TvF3iH4vfDO8 HivxF9gkg8MWtzqt3qssVt5klrcGW3mthuEr3JgZVkJ4ZASSXyOj+DHxDuNX 1jwDe+Nfilrnh290vR9Bk0CwW/dk1uW5urhLgTR/MZtxRI2bnYvJIxmgGrH3 l/won4bf9E/8L/8Agmt//iKjk+CXwyijZ28A+FtqjJxo1uf/AGSvmD9hj466 38TvHHxPtZ9Vl1X+0rn/AISCxg1B5glpBJPPF5MO5eY1RLc/L8uXPfNeR/E3 xDr3hz9p3xBHD4tv5NYXWNPs4NCiv2FtNYXFlO85+z558vbGfMH3SATywNVp a5Ot7H27qHgH4TWysLfwF4Uu51dUaFdJtlKkjIzlOOKwZPC3w9urSK4s/hX4 WjAl/epc6daI4jV8OQm3JOASvrx614N+wWy3Hgxr+9mbVL6+gs5Ljb4pOpzP IykLI8YGbVuWHlMSff5a4Lxh43utI8f/ABm1R/HGu2Pji1bWrHTPCcU5lga0 hsEkilaI52bF3SiT+Jl285INaWvYzfM21c+yR4E+HbQJKvwp8MursqLssLFj uY4A6cdRWlB8LPh68yRS/CbQ4XfOD/ZNkw469P8ACvzI8WeJtZsfDD6R4b8T a/4x8O2us209tcwayyXU0jaTJPcRLdLkkI6h9nOG4xnr6T4I+JGpeFfjd4R1 VviLe394h8N29zYx37m11Cwm0cyXtybduW2lQ5kIGGOThm4m67FWl3PvPw98 Nfg34wgvJdE8KeC9Wis7l7K5ey061lEM6Y3xMVXhhkZHUZFan/ChPhp/0T/w z/4KYP8A4ivzu+G3xz1Lxr8P73w/rHjTVtD0nW/Hem3mr6v9pksp7LT762mk a3SZ8eXEs9sEDr8u1sDhq+5/2PPEeq+K/wBnPwjqOs6hPq94y3MKahdMWluo I7qWOCV2P3i0SRkt3znvUp3NGrHVf8KF+Gv/AET/AMM/+CmD/wCJpP8AhQvw 0/6J/wCGf/BTB/8AE11+uaj/AGTo19fYz9mgebB77VJ/pX593H/BVDEMEUOk 2bXzsY2xbTFAc4yBvB2/jnrVWvsQ5W3Ptb/hQvw0/wCif+Gf/BTB/wDE0n/C hfhp/wBE+8M/+CiD/wCJqD4P/F6w+KXws8O+K1khhm1KySeSBGO2OXGHQE84 DAjmvkL4pf8ABRHVvD2q3+mQar4O0F7eR4T5AutWuAwJHQJEgPHQk0lZ6Irb U+xP+FC/DT/on3hn/wAFEH/xNL/woX4a/wDRP/DP/gpg/wDiaz/2cvi3H8bv g54c8W/Kt3eQbLuNBgJcISkgA7DcpI9iK9Imk8uJ3/ugmgRw/wDwoX4a/wDR P/DP/gpg/wDiaT/hQvw0/wCif+Gf/BTB/wDE18feJP8Agqxo3hu6uLGfRbd7 6CV43EckxRSrEDnyxnp7V9d/AP4qr8a/hPoHjFIY7ZtSiLPDExZUYMVIGee3 enYSdyY/Ab4aAZPw/wDDI/7hMH/xNYV54A+Clhq1rpk/hfwdHf3MnlRW/wDZ 1sXZ8ZxgLx0710fxms73U/hr4gsdOuGtNQubOWO3nTqkm07Dz74r8D/G3i/x lD4tS/1HWr8anYXO+MyTNmCZG7DOFII7UKzBto/esfAX4aH/AJp/4Z/8FEH/ AMRR/wAKE+Gn/RP/AAz/AOCmD/4iuE/ZW/aR0X43/DzQ5EvHm1uPTYZL4ygA mUfI/TjO5T6da5f9tz9pW9+AXhrw1caPcvHeXt+ySpEqMXiWNiR8ysB8xTnG am6K13PY/wDhQnw0/wCif+Gf/BTB/wDEUh+A3w0H/NP/AAz/AOCiD/4mvhb9 nv8A4KE+Mviv8dfCXhK+DW+n6ndmKUfuW3DYxwcRgjkDoa/R29u47K1kmkOF RSxpvTcSdzza4+GPwatdRlsJvCvgyG+iUO9u9haiRVPQlSuQDV+1+CXwsvk3 2/gbwpOn96PS7dh+i1+bHxT+I+v+MfiR4s8RR3Dx2c+qzx20ccm4GGLbEpwM /wB09eOa+uP2AdVGseGPFE7ZE63caMrxLG2AnfHuTWfNqlbRmjjZPXVHu3/C hPhp/wBE/wDDP/gpg/8AiKP+FCfDT/on/hn/AMFMH/xFaPj+4uobOyFrdy2e 6Y7mhIBI2njkHvWfaeM7mDTjDIDLcAYSY/zPvXxmP4vy7LMfPAYu8XFXva6d 1eytrf5W8zeOGnOCnET/AIUJ8NP+if8Ahn/wUwf/ABFH/ChPhp/0T/wz/wCC mD/4isG6+JenfDfS9Z8R+Ktaa30WytXuZ3nbIUKRwijkk5wAOTxXG/sz/tve EP2ovFuuaF4b0rVLGTS7f7SZ75UCSx7wgKgMSOoODXtZJm9LPMGsZRi4xbas 7X09LmVam6MuRs9Q/wCFCfDT/on/AIZ/8FMH/wARR/woT4af9E/8M/8Agpg/ +Irtku4JZWiSaN5V+8isCR9RXxlZ6L8VrPxz4lv7y88ZWOk6jdeKYbO4sHvL +RSsk4slNpNIIYECbZIJIwA5RELDeN3umWp9L/8AChPhp/0T/wAM/wDgpg/+ Io/4UJ8NP+if+Gf/AAUwf/EV4Z4J1LxpefshaO5tvEsF6mo2Ed5PFJeSalca Z9rhN1NAHH2lcwmbCjLgA+WzDYTT8XeIfGurfs/+F9JW/wDFNl4y0w293qiW 2m6hLdzwvDdG2hmNq8cymQxxB3ViUcfvAMmgdj3/AP4UJ8NP+if+Gf8AwUwf /EUf8KE+Gn/RP/DP/gpg/wDiK8i+CFx8RZvjde/8JDbeIbOwNleG+ttRknl0 +EYsfsC28jfu3kCm8DtH8xIYyc7a9PjTXvHPizxZb2/ivUfDdpol/Fp8MGmW 9q4mDWlvcGRzPDId2ZyvykDCjjOSQRe/4UJ8NP8Aon/hn/wUwf8AxFH/AAoT 4af9E/8ADP8A4KYP/iKP+FeeI/8Aop3iX/wE0z/5Eo/4V54j/wCineJf/ATT P/kSgA/4UJ8NP+if+Gf/AAUwf/EUf8KE+Gn/AET/AMM/+CmD/wCIo/4V54j/ AOineJf/AAE0z/5Ep3ge+1Ww8YeIvDGp6xca+tja2d/Df3kUMc2JzOhjYRIi EKbfIO0H5yDnAoAb/wAKE+Gn/RP/AAz/AOCmD/4ij/hQnw0/6J/4Z/8ABTB/ 8RVDTE8Q/EG51e7g8WX3hyCx1G406O1022tXR1icqJGM0Ujbz3wQuAOM5Jvf 8K/8S/8ARTNf/wDALTv/AJGoAX/hQnw0/wCif+Gf/BTB/wDEUf8AChPhp/0T /wAM/wDgpg/+IrCv9O1qy186KnxF8T3eorafbpI4bDTQscO4qGZ3t1XkhsDO flJxiuT8JfEG18d6/eaJ4f8Ai3rWrataZ820tl0VnAHUgeV8wHcrkCgLM9J/ 4UJ8NP8Aon/hn/wUwf8AxFH/AAoT4af9E/8ADP8A4KYP/iKTwNqmq2ni3xD4 a1LVptdFhaWl/DfXcMUU2JnuEaNhEqoQptsg4B+cg5wKxvBVh4q+IHhLSPEk vjrUtJfVbZLs2NhZWZgg3jIRDJC7kAHqzEn26AA2v+FCfDT/AKJ/4Z/8FMH/ AMRR/wAKE+Gn/RP/AAz/AOCmD/4ij/hAPE//AEUvXf8AwB07/wCRqP8AhAPE /wD0UvXf/AHTv/kagA/4UL8Nh93wF4bQ+qaXCp/MLR/wpzSdP+fQNR1nwzOv 3Dp2oyGBf+3eUvD/AOQ6P+EA8T/9FL13/wAAdO/+Rq0vhnr954j8Km41B1mu 7a/vtOeZVC+d9mu5rcSEDgFhEGIHALHHFAHhPjj9trTvhD4ovfCPifRLzU9c 0wolxeaYES3m3Irqyq7blyrLkc4OQCRgkr5I/bU/5OY8Zf71r/6SQ0VN2VZH 6CfBHwfoOpfBnwfdXei6fdXOo+FbHT72aa1R3ubbyB+4kJGXj+d/kOR8zccm ug1z4LfD7xOkaax4G8N6qkccUKLe6TBMFSIMIlG5DgIHcKOih2xjJqt8BP8A kh/w/wD+wBY/+iErvKok5Y/CrwWy7T4R0IjNscHTYf8Al2z9m/h/5Zbjs/uZ O3GaqX3wh8EPa6eV8G6CJNIt5INMK6bCDZIwOUh+X92pyeFwOa7Smv8AdOfS mIw9D8FeG9ElsrvStB0zT57WxGnW01paRxNDaZDCBCoBWPIB2D5cgHFcpZfD rwnL8Rl1+Xw1o8muXOnSRyam9jE1y6hghUyldxGxtuM9OOlcvrH7UnhXQ4fG mkWAuNR8SeD7L7RdaayGITDIUbJGGDyygkdM18J63+0b4z1fwZ4t8RaT4o1K ya61eO0kgE7ObOCVJC8MTHHl4ZUO5Mcr7mu3DYWWJk4Qavpv5uxx4qu8Kozq QdnfW2l0r2+4+xL3xv8ABb4V6pri+G7HQvClvol3bx67NpOmJaRiQM5VHMaD e42OMc43e9X9L1TwF441LUviHp9hp8cur6b5Meq3VqkF3OgZE8lmYBsHyyNp NeE/BLWJNa/Z9m8S63INZmiR0ujPIGnlMDz/ADOzA7m8spyeSe9P8P6jcfGr wlNa6Jaw27aDNHO/nZh3q3nbXP3t5DLkjpkHr0rx1XrQxDw9WmlZyW+7jJrT Tayvc92nlvt8M8ZCTcFy8zttdaX1vu7HS6R498H+HtRtvC+l/Dayni0q9h1O 3g0rToiUedQZJY0VeDsGxnwPlbB44rUj8F+Ez47sLWL4YWEupxXUkAu9K0aE QC2ZmAtmkVAoVLfCFG4KnoQa4DwJ4w8N3Hg628NTeIJ7bXZNRYJNHafNawmW PawdgBhFjwOQOcYr3L4bS3fg5P7dn1ZtfsL6/mj33UoFx8jyRqwAO3kY4wDn v0A6ac3Ugpxtr/VjPHYaODrOjNNNd7q6srSs1tfbr+vs2o/CfwTrNlNaX/hD Qry1ms4dPkhn06F1e2ibdFCQV5jRuVXop5AFdFpumWmjafbWGn2sNjY20aww W1vGI44kUYVVUcKAAAAOBTdL1S21mxiu7SQSwSqGVh/I+h9qt1RxHPfEGWaH wNr728LXE4sJ9kSDJY7DwK/Ay/tLez1G9nht58JKQplAymT9evX8q/oJ1SMT afcRtnDxspxz1GK/GT4kfs3+NbHxv4u0PSorU6Et2IXv3Rxvwqup2DOCNw56 DJ5pe0UNzWnhqmIdoLY+ov2NPF9sPhi2kWomht9Nu57YLLjdu3lm6E4GW4zz jtX50ftE6JL4d+OXiy1FvJbhtQknjWUHJVzuBHqOeDX35+wnZfZ9H160aNvt h1DNwJF+YsUXJx26V5L/AMFIPhuvh74h+H/F9vkrq0BsHt0zFIXjwQwYDnIY A/SsMPJT95dTpx+GlhKjo1N0e3/8E7Pjlf6xcv4anEbW9zpqalEN+WklUiGf jHy4ZAcc/ez3r7t8Q6wbTQ7uZIjJKsLMsYOCxwcAfXpX5K/sBXmp+G/2kdG0 XUYRHdXFteShEGQiSIHxnnvGDX6xazMItGdsMz7emzNaNJXSOCnLnP58PiZH E/j7WI4oXj23UoaOYYI+dj+AGa/XH/gmF4nk1T9nW20x45AunXBjjkdQA4ZV c455AJxnivzr+LGl6nYfGD4jwaRp8MtteXsse5o2YwjcQcgA8dT61+jf/BNP Qz4f/Z9sYWYySy3EzvJtxkhtoA9gAKn2sJtJM9CpgMRQg6k42XX1/X5H1fql iuoWckLDO4Hivxd/4KCfBC9+HfxjnvoLbbpXiDdeRuBwkoOJFH1ODj3r9rXP yEjqK/Jb/gqhqmo6j8cfC1nczPDpdvpuQFKnaXlYMQpI5woGa3glzanDp1OQ /wCCdvxI1vwz8SrTwrazT3Gl3ZmujAyYAATEgIzxysZBHofU16Z/wUO8YXGt 3mm6dJp7SRxWkl1EM/NG4dFLbSORgjnPGDXO/sAab4g8T/F5LiSzUL4b0Oay aeLaxZZZsxoXUYfAzg5PfnsNT/goxp2s6Rr/AIcu4Y3M09tcWzAMRlSyNjj6 UpxipFRu1yo+bf2WodTX9ov4fNpVs39ppqMcsSyt5e4c7xnB427u1fs98XNf n03wTqlwkcpaO2kZYk6uQpIX8elfmZ+wN4H/AOEw/aM8IXWpX7ajc6RaXV95 MNt5MVpxgbmwDI5Z8+nue36kfE/wudX8I6gICxmSFyozwTg1nPVXRdOPLNRn ofjnpvjyGy8Kx2tyj/2iIZJJEJOPNeRjs57YI78Y9q/Qz/gnj4PbT/BOt+IZ jIk19cLbCIf6oqg3bhxycuQT/s/WvjwfsN/FbWFivI/Cz3FvOokSRbuABlPI 6vn86/TP9m/whfeAvgp4V0DU4xFqNja+VcIGDbX3EkZHBxnH4VyUKkpys01Z dj3czwFDCQ56NWM7vo03a3WxufETC2NmCf8AlsP6V4br+v8AiDT/AI2eEtKS +gXw5qOn3zyWa2481povKIdpCTwPMwFUDvktkAe5fEWMyWlko4/fZJ+nP9K8 +1LxLpOkXtraX2oW1pdXLBIIppArSN2Cg9TX82cb1PZ8RVm48ycEvvi9fluZ YVXoo+P/APgqRcSx/B7w7GjsqSawA4U4DDynOD618qfsTfFzWfhL4l8WXGiL Et1qOlfZPPkBJhBkU7l9+O9fVn/BUqPPwa8OtxxrS/8AomSvhf8AZ4k2+JdQ T+9a/wAmFfpnBU5Q4ZcoOzUpfmepk2HpYrPcPRrx5ot6p+jPub9nb4yx/D74 j6j4n8S6leXkZsJi0Tys73ErMmAATjPU/ga+u/2cv2lpfjxq2uWcmhrpS6fG kqSLNv3hmIwRjjpX5pXX/HzB9T/KvZP2efjZffBebW7iwsLa9kv/ACYmNwWA RV3njBHXNfW5POtVqwoQe7f5HD4j4ydDiunhYWUPZxukv8R+n9IFVSSAAT1I HWvlfUf28tB0Dw1DqV34fnllZgjwwXcQbdjkqrEEj6Zq3+zD+2FfftB+O9U0 K48N2+j29rZtdxzx3JkZsOq7SCo7N+lfdPL8TGnKrKNorzR8qq0G1FPU+nq+ ffEcfiqXXviSPCj3Md5/atxkwKTl/wCwbTyhww+bzNm0noa+gq4P4df8jl8T /wDsPw/+muxrzjY868XR/EoSamNG/tGZ1u7h7GZd6b18q58qJkZtq7X+zgSE mNgULoCsoPc2sfjE+EddltC48ZKLpIE1Fj9hZ/NcwsoHG3y9mMdiA/zZx1Xj zxFL4T8G6xq9vCtzdWls8kELnAklxhFJ9CxA/GvnDwh8S/HHgPVtG1Pxh43t fEWn61MFudP+wrALLc23ETAZwpIHzHnHvXLWrwp+7J79unmelhMLUq/vYJPl ez621t/w9jJtI/FZ8Q6IdUPxP/tj+wpPt4tvtn9mf2ps/dZ2/LjOc7P3ednb dXrfwO/4Sr/hLtY/4TUWw8S/8I9pH2v7L93PnX+M443Yxu28ZzjjFezjkVwm g/8AJbPGP/YE0n/0df1FHDexlfmb/r+vxO/Mc3/tCmqfslG3Xr10XZa7a7Ls c/ofiKXwn8P/AIgavBEJp7TWdSkjjboW804z7Zr4h1T47+KLz4gRGTUNQW/Z lAu/NZBHI+TxGNwCexGDt9TivuvwVozeIfCnjbTVn+zG513UY/N2BwMynqp6 g9CO4J5FfNmo/si/EL+1J4YY9KuLdpQsd41yBiM9c5TcMYHA9TjGa6rxUn7S LkrO2trPo9F/wD5DEV3Qkvdk076xTfqtHpfo7fNEXxY+OV7H8G/EviW6uEtt Z1HwtbaSsysI90kl5NGzD32b2IGOh6DmvnD4s6zp/wAMI/CPifwnNZabqunX EE+n3NlAYmmUhmwx3HepQAN6knscV9OfH/8AZh8T6t4b8PaDp2lv4otbc2Mk +xkihxDLO0sWMhhlZhg4+YliSOleM/HP9kf4n/EU6RFoPhJ7Cz08bViuZEXA 4AA2luAAABXG1N1ad09N2fQ4CrGOFftbKTS0/q/5n2/8H/FCeOPF2o+Io4vI TV/Cmh36xZzsEsl+4Ge+N1dN8Cf+SNeC/wDsFW//AKAK4f8AZ48P3/hS6h0X VYTb6np/gjw7a3MRYNslQ3ysMjrgg13HwJ/5I14L/wCwVb/+gCu486VruxHr fiHxbZ6vqqHS2h0y3hlexks4/Pa9cQuwRmG5ojkAgmIgsNuSSoflPA/xL8ae Jr6yslt9NcXFxcebdTKMwwgRSRuqRysJEKyMgORw0DklZUaToPFOujXdbv7W Hw3r1+NCnEEt7pupxWabmhimZTm4jYja8eSR64PWsLw5rGn6vcnUNI8Ja5rU ttIMyp4kt7sI4O4A5vWHUZwaqjQqUk9U76+89dfmkvLT1IrYilWto1bT3U7a d9G3frr6WPS/Bk2vXXhyzn8Sw21rq8qCSa2tVwsBI/1ZO9wxHQkHB7ep5/4L /wDIoah/2MWuf+nW6ruo3EsaOBgMAcGuF+C//Ioah/2MWuf+nW6obu7hFWVj 85P21P8Ak5jxl/vWv/pJDRR+2p/ycx4y/wB61/8ASSGisXubLY/Rv4Cf8kP+ H/8A2ALH/wBEJXeVwfwE/wCSH/D/AP7AFj/6ISu8rUyCvPP2gNP8S6t8I/Ed j4PmFv4kubYxWUvn+SUckch/4TjPNd7dXcVlC0s0ixoO7GubuPEK6w7wRJth CkhmHJNUk9yZNbM+Pvgj+z1fC98Q3Hji5ln16fS7W2uSt0ZTJuLGUGT+IFoV POeg5rzL4f2ngvwJ4K8cWt3qBHi2z1WYgzEr80aYgZFwQxJdsjryeRjNfbOm QR2+u6k2799KgBU+ihiP/QzXxR+0LaxwTXLWtmsdu2qyvNKByzum7r36Meem F7YrzKtedKlOpDdX/M+0yuKzXHUcFXb5ZOHb7EGuumtrfmcVd+KNVs9Hvy62 8ltrjA3Qt5nXlcEZUHC7gc8DnnNdp+z18TbnRr7UNB0vS7OS41hPLZrkyHyx GHOPlB4+Zup71mfDDSdY8ReGxp+l+GLTXQt64mnuXChFZAFOAQRjk55+le/e D/BL+DFvrDT9M07+0l8sfLHJHAXlywiS4YszDhcnZgZGfSvOwtOtVqKqpuyS 3X36n1+d4zAYHCzwk6EW5OSXK0rfytxTutldWVzB8BeBVntbe7tvFErQfbTc XV7bTieBUXI+zr1KJuGCRyduM+nbTaHeXVleG40n7XZLcYsxHIix3eZF2S7S nyspYFs5JKk5GcVan8KWfje+07RdIa58PHR7hJLm2gI2MUQsYnVhwmCCNuMg kjrXo3gXwxP/AMI9LeXWsPqGnwX00enWpRQtuPNMW3cACwHzAZyeTyeK+lUV BWR+P1as68uebu3/AF/X4noXgHwz/wAIn4YtbBkjSUZeTyxxuPJ+vpn2roqQ dKWoEIRnrXk/jT4A+FfGN7eapdW1xBqLTmYXFpcPAxbYFyShBPA716wa8a8S ftJeFfDvirVvDMhuJNWtJUR4wEVZGcZCoWYAnHb8s1jUdNW5zvwlPFzlJ4NS bSu+Xoiv8EPgh4a+F2s6r/Y0E2LkJM5uZWlbeRzy1b3xc+AXg/413Wgp4nsn uF0mV7q2ET7MOdvXjkcdKh+FnxH0nxzrWrTaU0vlW0v2SRJl2ssiAZGO1aHx Y+MOj/CKDTb3Vorq4W7lNtDDaIGd3IzjkgDp61nGUFH3drmGOdVSbxjfN15t /mc/pv7NXgLwb8TdL8b6ZpZt9ejBtFlWTEYQowxsHHQ4r2GRFdGUjIPavHj+ 0BousePNC8Jtp+o2Oq3ZFxF9piVUXCsSpO772AegI969euZfJt3c9ApNapq7 OSm4SXuHm+lfAX4fXn2jULnwlpdxe3dy9xNPLAGZ5A7Ybnvz1rq/A/hTSfB2 mS6bo1hDpthFO/l21um1FycnA+pNfKviL9vG68I61faNb+EIblbG4kgaaS+I 3lXIJACV9A/AL4sw/GPwc2vRWn2B3ndJLXzN/lsOPvYGex6d64qOJoVJqEH7 yPrMwyjN8HhliMZBqm7WbkmtdtLs9NPAr8k/+Co8P9q/HHTjGyGSCziQh+gG WP8AWv1rc4Umvwy/bN+LF78RP2lPGH7xTZaXfGxtlRF+5Gdp5xySQetekouU lY+YSufWP/BIXw/FbWHxG1HGXee2h3Y9PMPX8RX1l8WPBWneLfFlnHe2SXSx IHyUB2ncvPT2r51/4JHwFvhT42uWgEWddMIbHJCwpwfoWP516n+1J8Zr/wCE XiXR5dOtbe6lvg0T/aS21VUqc4BGazldMuEXJ2juel/Dn4eaR4Y8VvqOnaXa Whmt/J86CJUY4OSOPpmvR9cYLpN4WI2+U2fyr51+B3xs1LxX8Zb/AMKXUEDW kOn/AG6C7hV1L528bWJ4+c8j0r37xjMYfDt4e5QinJ6OwcklJRluyn4Pk3eE 9ECHOLdAcdMYxW9pwCwuByBI38zX5laENc8Z/EDW9Ji8Z32hQQXEvlMZZmjz 5m1UAVgFySAMkCvs79jrxBfa78HYU1K6kvLuyvZ7ZpZm3OcOcZJJ9a8/DYtV 5cvLb/gH12bcOSyvD/WHWUn7t0k1bmTa1ej26HsOtaJBrlusU7SR7TuV4jhh +YIr5q/bH/Z88Y+Nvhraw/Cq9vrDxLFeLJLLFqslu8sWDkZLheuDjivqainU y3A1qzxFWhGU3pdxTf3tHx6qTS5U9D8kP2i/2cPj1a/BnRj8TfF2n6vZC8jj gtPNBlt5TG+N5WIbyArDdvPXv1r5v+GHg7UfAfimd9TjxDLEYkljOVJ3Dn2H FfvT4m8J6P4z0s6drmnW+qWJYP5Fym5dw6H68mvBPj9+x/YfFWXw4ugnTPD1 tpiPDJELQfMjFcEY7jb39a56mC9jSlRwsIxpv7MUlq93pZH0GCzfD5VCnjIY eVTEU5XXvpJrs7p7a9j87Lkhri3KkEHd0+lbuhgNZXJHUSoD+TV9Yaz/AME7 Laxsc6N4iEl2ASDcW+3Ptw3A/CvGPiB8E9Z+Cdtp8PiGS383U5n8kwPlcIB1 Jx/erXIsFWoZhS5lor/kz5TinMK3EOfRzVUHTjyKNm09Un29Txv4iZGn2Qzx 5rfyFfQH/BNOLd8XfEUmR8ukFcdzmVP8K8E+Jlu1vYWIIIBlfGR7CvoD/gme ob4qeKD3XSh+si/4V+v4x/8ACfU9P1PKpL9+j9Ha4P4df8jl8T/+w/D/AOmu xrvK8ksLXxLd618TU8K32n6dqf8AwkluTNqVu00Xl/2VZZG1WU5zjnPrX5nJ 2V7XPoqcFUmouSV+r2Xra5xf7e3j+98C/AO+GnQyyXd/cwwebGOIVDhixPbk Kv8AwL2r4l+I/wC1s/xF0PTdK+wz2vyxXGpSSYCtLHyqxAHOC+DyT0r68+IX iLxdd/2to/i3UvBuqWem3S28yaj4bae3MpgSddoeYjkPGoJA+d0HG5c8Hpmj 2Gs2LXNv4f8Ahm0vny2sVs/gmISyyx2/2gooMuASnA3EZbivJrRdWTbg/wAP 8z7bAPDYSnGMq0G077y/+Q8kfXnwm8UT+NPhr4b1q7t3tby7sYnuIJBhklAw 4/76B571Q0H/AJLZ4x/7Amk/+jr+vM/BGs/EfXnbStC8U+ELcWtpDdC1Ggzw hIpS4TC+aMfcOVwCMrkDNeieEluU+L3ihbySOW7GgaOJniUqjP5t9uKg9BnO BXo0pykrSi1/Xqz5XGYenRk5U6kZJt6K+nrdI8a8d69qWkae0FrrF5oWn3Hi jVvtN7aO6YZZBsUspB5yxxnnaa5XRv2otS8JeMfBWg6jeX95pc2oT+bcXRLy T2cg8uBmYrlysm85B524969ksbDxXqfh/wAQ2vhiz8P3nm+I9SS7XX3kVQhl xlAiNluT94Y6Vxdt8EPjLBaoH8V6fdXEcqSI9zqJbCoOI8iyGFZnfcB2SPBH zV04mcquFVCl7sk0777O/wDwN9icuqYfC4p1sVT9pFxkuW9tWrXvZ7brTfU8 b+DP7SnirQdB+J0F7rupapq0KRXWlTamXu4bYLMUlDFiSoKumB0+U9D19e0X 44+PvEtr4dsNLvrbVbq91vUNOGp6dYxhb6GC3WVZI0lkVRyWByw4XueKS0+A vxjhgR28Y2guJCftEY1IGJxvUgf8eIOMb8j1C4OCcaelfCP406LNpd3F4q02 7msrgSGzuNQYWzrlsg7bMN8wIyARnJ54BPz9LAYiCUXWdl2v3v3+R9jjeIcv xNSVaGCipN31aavycq05VpdXtezd+tmvUfConX4ueKBdP5lyPDujCVtoXL+b qGTgEgc9gTVv4E/8ka8F/wDYKt//AEAVl+A31d/il4obXo7KLVjoGk/aE0+R 3gB8/UcbGdVYjGOo65rU+BP/ACRrwX/2Crf/ANAFe6lbQ+Bbu2z5w/au+IV7 4UtNe0O3mS0s9e8WQQX9wSdwgXT7AlAARwxZQfbI71yXwO8YxeDf2i/CulaS bSG2162ltr21tYzEmFTckh5ILbxx7cVu/tO/s8fFH4mfFi7vtD02K88LLcR3 cKPdQoXl8i3jc4ZgQf3IH/AR65rNu/2c/iVp/izw34j0DwzLbano92kwae9t droPvL/rTnPpXXUTco2ta3ddjqws6McNKnN2k2+j7vyPue1/49of9wfyriPg v/yKGof9jFrn/p1uq7e2Vkt4lYYYIAR74riPgv8A8ihqH/Yxa5/6dbquV7nH 0Pzk/bU/5OY8Zf71r/6SQ0Uftqf8nMeMv961/wDSSGisnuarY/Rv4Cf8kP8A h/8A9gCx/wDRCV3bZxx1rhPgJ/yQ/wCH/wD2ALH/ANEJXeVqZHzh4y+NXinQ PEd/ba18NPEk9hbzukN/p0P2mCWMMdrgKOMjBweayW/ag8CzwPZ3mrX3hS9m Qqj3dgySIfUBlYHHuK+pCAeozXxD/wAFJP2bvH/xttvCGo+ANMGq3GmNOl1b JNHFJtfaVYbyAw+UjGc9K6VUg9HH7mcrpzWsZfejsdJuPBfiK8ku5/icdauZ PutcXMUGwf3VRAgx+Ga8y8UfDX4gW/iS6v8Awcul3tjMSVit54Jvl2qvzCTq SFByBwScV8B+Ifhd8YPhfKbTWfDGvadP8sgwrkBQT0C5BBxXv/wbtZU+Flrr +t6peXfiDU/OtLDSYJJElilEihJnweRjICgAkn2qamHp4mLpqUo37WOvA5nV yussTKlCpbpK7X3XPp3wUnirwh4xtNK8TeGkSLUbEi41Sw0sLDbyYJjiMicM cA7jkckD3rrvDXinTfiT4Y1fQrDTLjT9RtreWC7mkBjuLcSLIPNjbcxTG0kY YkEHpgZ8U8QeENV8IeEn0DxZ438TReLrnTzfjSbLItEjZiscUjbiSx2sTjI7 fXtP2cviHHZ2usad4w8RwwGK1iksLjUVRJpn+cPG8hwXONmM88nk1XsVTglD VIyq46WKrSqVUouTvbor9F2t5nqXgP4W/wBm67o0eo3F1mxIs1Vb13OwRsqp I+F80kK/JGRtHPevT9KCWXgqSJAqoNfkhVV6KDqJAH4A/pU1jdaDe2elXWkX 9rdhL5JJ5LedZDvZWTDYPqwGKo+GGTUlsrLacHW9Tu2HbEV1Moz/AMCKH8BX LVk+RpGkIq8ZbnpQ6UtFFMBjHANfmB8b9bmg+Mvjz/Tbi0R7z5jFbiVCQoA3 gkYHPBwa/T6T/Vt9K/LH47a42gfHnxqREX8y7xuSd4nX5VPBUgf99Aj2rws1 dowbdtf0P1Pw/jz4yvFK75PL+Zd9D179j7xDLp/jDxfbi589JLlZvMGQHJ3Z bHvgV2f7bups/hbwrcjBMeoFhuGedhxx+FeRfss62dV8e+JLzZ5X2jZLs3Z2 5ZuM4Gfyrv8A9tS5/wCLa6NK3Pl6ivI7ZjejBvmoff8AmfN+INHlxdZWs7R/ JHl/w5+I2peIPjP4O1TWrhZ5orlLWNkjEYVWBUAKoAHXtX6G6lqe7R2wcEr/ AEr8j/C3iX7F4n0K7OQYNRtn3HsBIue3pX6r3Tl9HU9cr/Su+F7O5+b5K3KM 1J3dz8zfGHhnUfEHxS8VWGnQC4njv7iQqZFT5d5OeSPWvrD9gW9ktPDOvadK drwagQy5zg7Rn9RXz/dWM0/7Q3jSzt4beZ2ZpAt1NJGn8DZzHyevSvZv2Krw weI/Hdts8tUv1bZhhtyXGPm57d+a+fwtNU8Qprq2j+m+IcU8Xkc6LtaMacvP Wy7/AKH2dfziCymkJwFQn9K/n3srZ/Gfxi1i7ZVn82+vb9/MRnVtpdwDtBwC QBk8c8kCv3t8XXwg8M38nQC3c5/4Ca/ns07XNT0PU7u60vULrT5ZVkike1ma IvGx+ZWKkZU9xX2VLVn4By6H6+/8EvPDTaJ+yvp17KAJtX1G6vWPr8+wf+gV zX7f1rsvPDV3ztWeSMn6rn+le0/sN6fHpv7KXw6iRQu7T/MOO5aRmJ/WvLv+ ChNqF8F2N6Bzb3sZyB03Aj+tZTWtjbDvlqIw/grFH4Y/aW8NGKKW3t9T0IKi SrGONmRjZxj5B15r7A8dH/in51z1Br87/hXrVtpHxb+F15bWttax3RhjLret NcSM0ahjIpdggyx2gAcdq/QbxnPv0SX/AHTWM/dTR0TX7yDPz7+EqtD8YfGk EVtJezMZ/JiEXmKZPOUgsu5QcDJBJ4IzX0/+xFLKvgvxVaTkma3124RwTkg8 E55P86+WvhGlvL+1FqKXEccsQu7lhHIqsGI5AAYHnPpg+hr6e/Y4uP8AiY/E 623MwXX5JPmQofmHoeRXiYLScfWS/U/U+JPewVRf3KUvxcT6YFLSLS19EfjY UUU113Y5I57GgBSobqAfrXz9+1l+zHfftGQ+GRY63Bo76S8+8TwmQSLJs6YI wRs/WvWbnxZLFqNxBFFFLHE+zDSENx17GlHjWNW2TWkiuTwI5VOfzIrehVqY eoqtN2aIlFTXKzxDU/2GfCF/8Io/ChuJZtbhzJFr867pxL7/AOx22+nvWf8A sgfso+IfgD4k8Qatr2pWF2b2BbaCOxLN8oYsWYsBjtxz9a+hYvF+nO3zNdRH jhonI/MAitC01Oz1J9lteCR8E7Fb5sfSup4/EunKlKV1Lcj2UOZStqjSryTT x4oOtfE3/hEjpI1X/hJLfP8AbIlMHl/2VZZ/1fO7OMdutd54/wDFa+A/AniP xK9sbxNH0641BrdX2GURRtJtDYOM7cZwetfn9qH7bVxqreKP+KY1XR/7a1WL U1n0XxELeeIJaQW/llzbNkEwlug6gdufBxOIpUI2qStfY+myfKcZmVXmwtLn UWr6XSvtdddmfUXivw18XdRRrzUf+EMZ1CIFs7jVImfaxKqFjkXJyx+vfgVy UA+JwujaCz0vNvLIn2mR9dIXcQXPmGTJX5B3wOg68/MOsftGWviG3WDVLHxt qUCsHWK78WxSqGHQgNZEZrKX4xeG41ZV8NeJ1ViWYDxJbgE+p/0GvH+vUf53 /wCBf8A/QP8AVrMP+geP/gp/5n3po2hfGrRIpUtZPA7LLIZGNxPqU7ZPoZHY gew4HpXTeEvtX/C3vFH23yvtv9gaP5/kZ8vzPNvt23POM5xnnFfANj+06NMt kt7OPx1a26ElYofGMaIMkk4Assckk/jXdaB+31PofivUdXPgSS7W60yx08Cf W8y5t2nJkd/I+Yt54zwOVPrx00cww6b5qn3u55GYcLZtUjH2OGv/AIYcv33e p6dreuaFoHju+uPFK32oaQ2oaokOn2N7HERN9p5dkaWM4K8Ag87cdq8u8bfE DUZPGN23hTQdKi8MF4Wtl1PUZPtSgIBKrhbkqQWyQQQQAK5Wz/bL1PSfFV5r tj4J06W4uJ7iUR6heGdI/MmMqlcIpDrnG7+Vavij9v8A8b+KPDmp6PJ4Z0vT 0vrd7drqxupY54Qykbo2OcMM5Bwee1dP9o4T/n4jxv8AVLPf+gWX4f5lo/EL Xj4cuox4e0Ma2Sv2eY6pKYAMkncPtGT2Ax6k5459G8CfEfwTD4Qs08YeGryf xIBJ9pk0rUVFsfnbZs33Yb7mzOR1zXzVp37Svi2wtxC0mp3YW6N2rXGuSswJ hMRThRlOQ+D0dQRxkH1kf8FFvHk2Il8F6EzP8oCyzEkn05pf2jhP+fiB8J55 /wBAsvw/zPqD4DSXUupI99cG7vW8D+HDPcGcTmWT/TdzeYCQ+Tk7gTnOcnNW /hP4u0OT4JaBpQ8T2Gl6kmjQ27O1zGJbWRoFKsVYjkBlYA9ePWvkL4bftu3H w+aBW8DC98nw/peh8at5ZJtBODJjyTjf533e23qc189eIvEkXiPUlvJvDVhI 5gtonFzNM7boreOHho3j+U+XuwRwWPJrsw2Oy6cmq9flVt7X1OHFcLcSU4J4 fAyk77XS0+8/QW5+GetXF3PIn7RctpDNa/ZvJgkBEbeVEnmoXuWIfckj85GZ cYwvNh/hzqMthDC/7QlwtwEiSa6iuArPtikRmVTcFVLM8b9CMx9Dk1+cc97a SSwuPCWiRCMksiPeYkyrD5s3B7sDxjlR2yDFHc2oEYk8MaRJtj8stuuVLcY3 HE+N3fOOvXNej9ZyP/oL/wDJWeb/AKucYf8AQsf/AIEj9VPBN6fBOo6hq3iT 4taf4ltZbCGKSz2xwxxzR5zLCPOcrvDHcnzZIXBGMHp/gtz4P1D/ALGHXP8A 063Vfklo2twaTqUNwPDGk+Slys5SPzvMVcKCqPJI+PukgsGwzE8jAH31+x3+ 003xN8Q6n4Ll8Nf2VIv9p6+t4t95wKzagZPK2+WuCPtQG7POw8DNctXE5e5x hhK3O3fo1/XU0/sHP8LQniMxwbpQjbW6a1dunnY+V/21P+TmPGX+9a/+kkNF H7an/JzHjL/etf8A0khorN7nAtj9G/gJ/wAkP+H/AP2ALH/0Qld5XB/AT/kh /wAP/wDsAWP/AKISu8rUyCiiigD5Z/ajvEtfHtipOS2nqdp/33rgv2Afhho3 iW0v/Gd8ourmwvZreztX+ZLdmYyGT3OHAU9hzzkGut/bKtjaeLtB1AviOWye EjH918/+zVjf8E4NREWjeNNHiRhZwXcU0DySl2kUqU3EHkZCLx0+nSu1tqkm jgUVKs00fYd9ptleROLu1huEx8wmQMCPxr4N+MlrY/HX416f4M8BaVZWVnZz MtzqFvAFWRh99yV6ogyO2SfcY+mP2mvHN/4f8D3Wm6NMsN9eRss8+8K0EGPn Yf7RHAxz9Dis39lT4HJ8MPCLatqNvs8Q6uoklDj5reLqsZ/2jnc3+0cfwiso PkjzlVoutJU7adf8jifGf7I/go+AVv7fUNR0W4uzbpNdxTgiMyyIjv8AMMjG 4nqBXDfDf9oDWPhw+k+HdN0GXXLey87TUku5cXcqJPKdxwCA5BG/rynvXrX7 UvxE1z4d/AiSbQNBk1yX7YbKcrEZEtYlkYeYyjn+FcHpzzXxTpn7VelX/h+W Lxr4FhngWd1l1bSL0R3iysxdnaFydyknIzgDkA1x4rBZljaKng5LR9Wtd+56 +BxGXYSfJioNp32vptba1z9Ofht8QrD4m+GU1mwgubVBK9vLBdx7JI5UOHUj 2Peuqrh/gougP8LvDt34Yt7i20W9tEvIEu1KzYkG8lweQxzz29OMV3FFNTUE qnxdfUxqODm3T+G+nofB3xk/bf8AiJ4F+Knirw1pVj4cbTtLvTbQtd2U8krK FU5YrOoJ+bsBXy94uHj34r+NZtdfTRJqOubrqKCw0qZlmVBtZoh5hLKNhyQT gg+ld7+0X4E8UXnx68eXVt4Y1u6tptTZ4p7fTZ5I3XYgyrKpBHB6U/S/jzp3 h6bR9K8WxeIba9sdFk0m7lNixuID9tW5i8tHK/KERI8ErgE4yAM/G4qeJq1p wqN8qemitv3sf0RkmHynBYChicGouvKC57VHdaXd4qXfdadkcX8P/FXj34TQ ya/Z2Vs1heN9mW7vdMm8hnUklVcSgFhzkZzxV34qfHnxn8W/DUWi6r/YttbR zrcLJaWMofcAQPvTEY59K6fxl8btM+KXhHUNO0XRdZk1e7lTzbSGwd7e3jW7 u7gOrLlizfaguNoA2scnOBrX3xD8M+EtGGqXfgzXLSb7NGsr33h5VtoJl0p7 RcM2Q4a4KSnKjucFhzEJYqFo0pvl/wAP/ALx2HyHGc9XMqEXUd1Z1XsrWv73 XXXbTzR84x+GtdtrWDUPtKi1acpHcGxYRtIm1igbfgkBkJHUBh6ivpi7/bT+ Kujq+lXumeHrae3/AHUkVxplykiEDGGU3HB/CubT9pX4ayPKzafPZ3Mwnf7b Ho0Mpt5ZLSyjMixMQrEyQXPBwAJtw5JA9Cf4m+G/EK6nqx+HHiXWYNS1WPVI xN4dDI0Yu4pcCVecNAroQQ/LcEKSK3U8ZZ2qP/wH/gHh0sBwpRa9lhIa72rO ++n27bX6/dpf538UeJPFereKrrxPqMOn29zrEfnReZpr+UVzs8yIPIQeY2XP IyGHUcdD8Lfjt4w+Euqate6OmhSNqTK0kM9hL5ce3ONgWYYHzGvTtS/aB8GW ly+l6l4c1PUNTttJjsw+peG0jd8TXcroYEkAiRxcREupJBjJweDXn3jrxdo3 xJ0Xw7pvhfw3qf8AbemQBb6O00Vok2+XGoOF3sxLKxLHap3ZCgs1ck/rMPfh K7/wq9+vQ+upSyrEw+rYmklTel/avl5VqvtJ20S1tqep6r+1h8cPEPgu4v28 LaWPD80TxtqkOh3nkAcox8zzyvByOvUV8X63+z7q/hmeGLVnutNluYlniS7s WjMkbdGUFhkH1r6v07xzeaF8MLXw9e+C/Elm9voV7Yy6wmiyebC8lxLLtUsM GFkfY+QGGSVzjB4H4y/H3wr4817RNf8ADl9fy3lmkK3WqXFuY3e5IUoCqZTz AVbLKF3nnbxk9v1jHxp80Jyvp9lfPp0/pngUct4blifZVKNNQvOz9q9l8L+O 2v3+VtT0T4XftR/F34WeG9B+HWkaDpF1NpkCWtva3OkXTXkgxuGUWcEkg54X pzWN8cPjV8V/jF4NvrPxFoNhpml290sVxeW2j3MYgmUg+WzPMVVv9k81dtJ7 bx148/4Tq+0rxzNpV20MUkOmaPM895CLTy5SZAwG1nUKw3ZZXPOcgXfib8Vo rX4b+JrPWtF8TW0+p3Enk3uoaC1nGd89vIo3b28tVEG3yRvDHaxbI4PbY9qT c31t7q1/Aj6hwyqlKMKNPXl5v3kvdb3s+ezt/V9beI2PjXxFp9x4TuIZNLWf w3IslrILOXMm0g7XHnYwcZOAOST3Ne6yfts/FfxFbzWsOmeHZxHE8sgt9MuW KRqMs5xcHAAySegrhNC+Ovw6t9P8JQXEN7EdPRVurW30S3kUzBJh54lf55N7 PESh2YCnDZCFfUbv4g6QLLxC9h4A8T6ZHqUF5Htt/DAUT+faxRq5kJLRBHWU 7V3AiUnqSDKqY+SvKo//AAH/AIBrVwnDUZcsMNF76+1dt7fzdd9LrztqeA+F PG3iGw+J0Oviawa51C9EcqLbSIEEzBGKMJdykBsgg5HrX3Z+xhJN/wAJV8UY 7h7eSYampdrX/Vk4bleT/M85r5C+KHivTfil4s0Cx8BaFqNvrGmyCOYTaL9n Yf6SGiaVItw+QMAxwo44AGAPrj9jG0v7Dxn8S4dUuba71H7RbvcSWausW8q2 QocA8fSurA+0VRKeur1tboeTxLLDTwVWWHtFezh7vM5NWqaa66Ws/u0Pq1ep p1NXvTq+oPxEKRiFBJ6Dmlqpq0/2bS7uXONkTNkfSgDxnWNftbi9nMGnLcXB kZjPKAi5yeh+8axptSllP7u9lVSOYoN2M+nOT+JAq34q0qGDUgrBvLdFYLvO 30PHTt+tZ0Y2IEjYIinIVRgVqI1/Bsty11c2f2q5j482MXARiR/F+vPXvXo/ g+3uBqcjTzLNsiOCqbcZI68+1eTWN61jrVldFsKJPLf02tx/PFe1eFIxm6kH qqfpn+tKWgHP/tDf8kD+JP8A2Leo/wDpNJX5F6TrkWlahbXkb2sskDiRUuFS WMkdNyNkMPYgg96/bC5tob22lt7iJJ4JVKSRSKGV1IwQQeCCO1fPGqfDSzuf FXjiLQtA0e38rUrTzG/smKcrH9iRtoQAEKzYBKHcM5HevCzHA/XOWXNblv07 2P0DhTiX+wXWpeyU1Vtu7JWv5O97nzHefGnwLcx+PnfVoJ4dS1C9uPsfkODq aSwxrb4+XC+VIrv85XG75cnisL4j/EjwF4r+KfhC7u9Tg1rQYL2R9QnWKRAl k948kduVIVj5ULBcKCB91SQBX2T8M/hdJPoE8mpaDpymS0byhqOgwpNBMGOz g5Zyy5L9FB2BP4qyNJ8O6zeXWlWEvgrQYb26tY3Zp/C22CMvavKZXl+6hSfZ CYj85AJ/iBHDLAylFc0t/wC7537n0tLiSnRqydOlrBNfxO8eW/8AD3S/Tolb 5L0fWfg7o0em2l7caXrDlrCC9u1iuwoTN39rlThTkA2uMj0wMg41/DnxE+GF jHHfyanZjVYdJjs3mvUupJf+QSIPLgwCqlbguG34Xbt28CvqKw0TUb/UdFhu PAWi6e2pW8E5gHhrzFgE3ms4kmICo8CiIFXALsG4G8BbXgDRbm88SaJZ698N 9NOlXOnILq//ALAig8m/aPzihU5YRqnybiuN52lgw20QwKTSTX/gP/BKrcSz lGpKcG9Nf33Trb3La26HyY+tfBS3j002t1pEmoRWc0ZmnhvRbNIHtTG8qAbg xT7Wo2s4DbSTjGLXi3xv8Ftd1O61N1tNQu7zxDPdXEsst1DJJE17I247YyBE bcoMD5w2TtJBz+g3/Cr/AAb/ANCnof8A4Lof/iagv/hh4OWxuCPCmiAiNuRp 0Pp/u10f2Xo1eP8A4D/wTyP9dNYydOo2r/8AL3vrbSG3ltoj8nPijfeFT41u n8LXltLozJEU8lXRFfYu8Dfhj82edqgnOFAwK+i9T/aK8H+IvHmlXlv4it7e Cx8RSyiXWFuLhGt3geNJITwbdBuIKjBVjG4ztIHu0Pw+8Ln9n/4ZXH/CN6T9 olk8N+ZL9hi3PuuLUNk7cnIJznrk17LP8L/CXkSeT4T0Hztp2b9Oi27scZwv Sop5VKk5OM92nt2+Z0YrjenjIU4VcM24RcU+fX3kk2/cs3ofm74I+I/w/wDD v7QV34l1TUbm+0xb6Oaz1B4luArmRDJLIp2MwC+ZtYLuyVbbuGKX4e+I/Dng v/hJ7r/hO9Nt4NRtGlstNuIJiLouZo1W5MUUhUIp3+VnazPGScLmvrWb9nvV /GniaOHX9K0zStEjcSP/AGZa28McijqihPnOemJMjv7HU8QeC/FFh4p1C10L 4W+ELnw9D5i2VxNZW4d1ECFMr5g/5amRRwM7QDsB31yxwMo+876N2913u99n se3U4mp1f3UeVuUIqX72NrQ2ScoW5nfVLzas9T4v+LHxG8F+KrTwhBDqK39r bXfmSwwI0b2NkYLVPsoLAAkPFO3ykr8+c5Y1r6ZqvwZ/4SrVH1K90FtJaJY7 dLO2v0XYzzfMGbc3mqnkZ+QA9myGL/VkvhLxw15ZpB8LfB32NpFWaafTrZJF j89VL7BOw3CIu2wMRwDuyfLqvJ4X+ILaGnk/Cbwb/ahCOxnsbZIxiKVpI8LO 2SXEKo+QPmfcAFDE+pLnc3d/9uPt6jXEMvYRoU3GKV1piIp6u9/g/wCDbzPm a28Y/CX/AIRjS9JXUNJgszc295JbyW92zl0sJUb7SwBG43DHBj3ABlJVlBUd r+xpceHLn9rfxY/hN438PtoN21oIy+FQ3NocfOA2Acjkdq+0bb4Z+EJreKST wdo0DsoZon0+AshI5BwCMj2JFc18BfC2i6P4c1O7sNIsbK6bXdbhM9vbJG5j GqXICbgM7QFXA6cD0r06OX+yqRqXWnlbpbv5nx2YcVfXMJWwqpyXtElrPmWk lK9uVXelr32Pz4/bU/5OY8Zf71r/AOkkNFH7an/JzHjL/etf/SSGivUe58Et j9G/gJ/yQ/4f/wDYAsf/AEQld5XB/AT/AJIf8P8A/sAWP/ohK7ytTIKgv5Jo rG4e3jE06xsY4ycbmxwM9smp6KAPz78fXHxd8b6Fpc3j3wpe2eoWrzSE29pu SMORiPdGWBA28HOTVD9l74wf8KW0rxN/aHhW6OpXlztt1DpGREruF3KzZAwQ enP5V+iWB6CsfW/B2h+JIvL1TSLK/T0uIFfH0JHFdXtk1yyjocjotO8Zanyr 4F+IWi/FT4kJeeKr9NL03T3W6Fvfts+1XHBjUdiiY3deW2+hr6w0fxHpPiGO b+ytStNREJCyfZZlk2EjgNgnB+tea61+y14D1Ys0Flc6TIf4rG4Kj/vlsj9K 4vwb8LtP/ZC0TxFqGn3d/r83iC/R2muFTEIXO1doZdxwz8jqcZwBWdSVNq60 LpRqJ2lZnN/G79pHxf8ABfxTqem/8ItbJp13OZra4uZd5kXABYbTgBtrcHkZ ya5X4OeP/hB8SfH1qk/wwtZ/GGp3IkkmGnRTxQsFDPNk/dG7cc4z69q6PxJ8 Qo/HGrEeKtEsdZ0xwQtjJHtCruBUh+oYc4P+0w4Br2v4TeA/ALwW3inw74Vs 9IvSjW4lSAK6AHDAEdQcde4/KvJpvEe2cqdT3ex9o8VlEsvVGrhX7ZX95PRv o3d/103PToo0hjVEUIigBVUYAHoKfRRXoHyY1hwa+Avi/wDs/wCpfFT48+Nb 8Xkek6VbvEn2uRPM3y+Sh2hQQcYwSRnGRX38elfI/wAWLvwXqPizxnFqt7ba LrujXSXi3X2420syeQpQYXDOAdwGDkE+/Pn4ulCqkqm33dD6/hrGYjBYipPD X5nG10ua15R1t+HzPFP2S9Hl0v4g+JbGcqZrVVhcryCQ7DIPccV7v+1jpP2r 9nfxScbjFFHIB9JFrxD9jeeXVfHHiW7llknkkWNjJMxZ2y7HknrX0/8AtE6X 9t+AXjOMDJ/s2Rx/wEBv6Vx4BL2Om2p3ccuUsfVU9+VX/wDAUfkfI+FIOCpH fr/Ov11/ZtuxqPwA8JTHktpkQz9Fx/SvzF0PwFBq3wz17xF510l5psyJ5Sx5 hdWx1PUEZJ+g6en6V/sdTi9/Zw8KEsSVtCn5Mwr0IrufkuV+7Vd+q/U+Lf2o LmfS/jzrc1vIYpDFFyAOQYgCCDwQeRg12f7EOqTXPxX1czyGWSbTtxZ+vEiA fkDXJftgQiH446j/ALdtA36Ef0rW/YmuPJ+MpTOBLp8q/kyH+lfLxbWNt0uf 1ZVgqnC/NbX2a/Cx90/Fs4+G+vHHTT5+3/TNq/E34U6P4ou11O58Pa1FoMO9 LWSW4u/IWeVyTHEODlyVJHpjORX7a/FwkfDbXsckafOcf9s2r8k/2WblbfS/ EWLW4uria7tYUNnC9xJCSJMStGrqFjU4Jl6qcY6191Q2P52mz9Y/2Ure5tf2 dvAcN2jJdR6aiSq/UMCQc++a+df+CnXiyK28NeEvDqSgT3N013JGOuxRtBP4 t+lfR37LQYfAHwUryLKy2AUyK5cMQxGQTyQfWvgf/gpNrMl58dobTeTHaWNu gGemSWP86xnuzXDK9U+bZNH1DTYrK+ubC4tra5O+3uZYWRJgDyUYjB59K/Yj TZDd/DzS5WwWexhY8esYNfBfxR8Ojx5Hpk8Olzz21pYJbRXjaiBHbpHD8gjt hztJXl+m4mvvXwlGZfhX4fcgjdpVuef+uS1lVWiOp1OflZ8M+GLptN/aB8Zh fD+qa+GJLQ6OwW4iAeNiwPocbTjs1fVn7NUJt/if48jIvEP2HSm26gxNwMwZ PmZJ+f196+W9E8E6V4v/AGkfF+m6rAbiPa0sUSSvG7PhPubCGJwTwAfpX0Z+ zZqRg+I/xO8qCSBLCwsYYobhJVcCKJlG8Sqr5+Xkkc142Fupq+3M/wAmfomd cksJPl39lC//AIFC3X9EfVA6UtfE/hz9r34l658LvEWtjTdCbVLTw/p2rwrJ ZPYGJ7pslY4ZrpjdIIw7I6tGHZNoBb5a9T+Jf7ROs+GvhT4O8RaCNJvb7WLO 6vZrm8t50tdtrYTXUqLGWWRGcwFBuJKZJIfbg+7c/J7H0LTJYknjaORQ6MMM rDII9K8C+KP7R+peDvGXgjTrDToU0vU7JNT1W6uoWlNvC1zbW4QbZEKkNcjL BZCDtHl4LMul+zl8cda+L91rkesWdjbLDaWeqWn2FHUxwXL3KrBLuZt0qfZs sw2g7x8oxyXCx3Xi7wTpM1tFcfZmjMbhSYZXThuOxHfFeQ/GDwNOPhz4hGia lq1jfNassUtjCbqaPPBaNFxIzAEkBW3enNfRd7bLeWk0DdJFK1wQd1BVuHUl WHuDg1aJZ4n8FvB+vXnw1sRqks0N0JblEOpRXAuJohPIIpmE7tKm9ArhHyUD Be1fSHga3lg0CM3Do9w7EyFM43D5e/0rlXvYo5FjZx5jdEHLH6Acmut8KJcJ bXHmwyQxNJujEq7WIIGeOo59ab2C5u1wPgyVIPiB8R5JGCRpd2jMzHAAFnFk mu+rwX4i6q+i+G/jxcxsEk8iKJGPQM9jGgP5sKlK7SKOA1b9qj4l6zq97rvg zwlpOpeALSUrCbuVkvdQiXh5IyGwoODtBU5GPXFfS/w88dab8S/Bek+JtIdm sNRhEqBxhkPRkb3VgQfcV8Y/C2bSo/hzoVtbalqEdq9pGJDGx2QtGuGUnGFy Qcg16p+wd4ss9X8A+JtGs5N0Gma1PLbxk8pbzsXT8Nwk/KuelXdaU42ty/1r /Xc9jGYKNClGcep6v8dviZonwv8AA7X2ta0uhi6mW2tpyWUvIAZCoKjg7I5D 74wMkgHmtW/ag8HWurz6RNrL6LdQBBKl3YTtd5fy9ii3Cbgz+bHt3DLbvlVs HHW/GD4K+HPjfothpXiaKSeysrlruONCMFzDJFyCCD8sr49Dg9QK5rVv2YPD et2d7Bd6nrEsl3a2VpJd/aF+0BbNpGtmWXbuV0MrHeDubjcWr0YfV+Vc979b W/rY8YmsP2jvhrYo8a+J7q5/0aK+NxLZ3ciPHIwWNlfy9uWc+WFXkvlANwK1 32i+K9K8beEv7Z0S8W+024jlEcyqy8qWR1KsAVZWVlKkAggggEV5lF+yd4St 9Ll06G91WG0exi05USdcxQxTvPFsbbuVklfzA4O7cikknOfQ/CfgjTvh14HX QNK802Vss7q0775GaR3kdmY8sxZ2JY5JJySSSSqvsOX93e/nbYDzeH/k3b4W /wDXTwx/6U2lez6nGk2nXSSzPbRtEytNG21owQcsD2I65rxiH/k3b4W/9dPD H/pTaV7hXKM8XtfC3hp5YxB8WdfHmIsMVu2uxMUG3AGHUtu6ZLZYkc5ycx3P hjw0rXU7/FzxDCl1bsjt/bcIQhE2MyHZhWBDMduOSScjAHtW1fQUu0egosFz jPAPheDTZrjVbTxjq/im2u12qL28ingUjAynlooB+X17mua8bfHQeBtEl1rU bTTLbSvt8+n25nv5vtNxJFK8bbYY7aQnmNjwTgcnFesAY6V8QfG/xVZWPj7w 5Y3dw8Utuuv3NqqMcea+pODuABP3I2o2VzSnH2k1Fvc+ofB/xNn8WWugajDb aXPoutSNFa3unahJMd6xyOdyPBHj/VOpycg8Y64f8Fv+RR1H/sYtc/8ATrdV 4H+x5rsWs+GIY7R3l0+28bXi27yNliG06R27f3mY/jXvnwW/5FHUf+xi1z/0 63VN7kSVm0fnJ+2p/wAnMeMv961/9JIaKP21P+TmPGX+9a/+kkNFZPctbH6H fBrWbLQvB+geCdQuYrLxNomnwWNzp87hZHMUaoZYgTl4m2kq44PQ4IIHpAIP Q5rH8UeFdF8V6a9vrekWOsW6AssV/bJMoOOoDAjNfmb8bviB4o8G+L72x0Dx Hq2iWUchVLbTr2WCNRnoFRgBWjdjNK5+pdFfjb/wvH4jf9D74m/8G9x/8XR/ wvH4jf8AQ++Jv/Bvcf8AxdLmHyn7JUV+Nv8AwvH4jf8AQ++Jv/Bvcf8AxdH/ AAvH4jf9D74m/wDBvcf/ABdHMHKfslVDXNCsPEmmT6fqVtHd2ky7XjkHH1Ho fcV+Pn/C8fiN/wBD74m/8G9x/wDF0f8AC8fiN/0Pvib/AMG9x/8AF0cwcp+m F1+zTos2orPFqF1FB/HEQrMR6Bv/AK1en+HPD9n4W0a20ywQpawDChjknJyS T6kmvyA/4Xj8Rv8AoffE3/g3uP8A4uj/AIXj8Rv+h98Tf+De4/8Ai6hKMXdI p3ejZ+yVFfjb/wALx+I3/Q++Jv8Awb3H/wAXR/wvH4jf9D74m/8ABvcf/F1f MTyn7InpXwl8cvhD438SfGbxlq2h+GrvVLYtaqtvNAywXaeXhmRmXY5UjGM8 Z718t/8AC8fiN/0Pvib/AMG9x/8AF0f8Lx+I3/Q++Jv/AAb3H/xdc1alGukn 0PbyrM6uU1ZVaUU3JW19U/0PrT9m74ceJ/DvxU8Yy6j4X1PS7Od0aN5bORIS dxLLG5UBgM4BHUYNfTPxN8Nz638LfEmnRW0lxPc6dcRJCiFmdjGwAAHJJPav yy/4Xj8Rv+h98Tf+De4/+Lo/4Xj8Rv8AoffE3/g3uP8A4upo0VRjypkZrmE8 1rOtUjZtJaeSsdX4N+CXjuD4Z+L9Pu/BGvW15L5clsk2gXLSSkA5VGERx29B 719xfsY+Hda8PfALR9O1vSb7SL+AzI1rf2zwyqPMYj5XAOCDX55f8Lx+I3/Q ++Jv/Bvcf/F0f8Lx+I3/AEPvib/wb3H/AMXW9kfNUMIqEuZO+lj3T9rX4T+N PEXxhnvNI8I65qlm1lEv2iz06aWMsC2RuVSM+1R/sp/C7xt4X+L9jd6p4P17 TbM280bXF3ps0UYJAxlmUAdK8P8A+F4/Eb/offE3/g3uP/i6P+F4/Eb/AKH3 xN/4N7j/AOLry3l8HW9tzO97n6fHi+vHLf7N9krcvLe7v6n6nfE/Sru/+Hut 29raTXNzJYTKkUUZZ2Yo2FAAySfSvyr/AGdPAnxB+FJ8QnW/hR8QrhNQhESW tr4Ykkjk68u7Isi4yDiNlz3NTf8AC8fiN/0Pvib/AMG9x/8AF0f8Lx+I3/Q+ +Jv/AAb3H/xde1CpyKx8A7s/T/8AZe0y/wBH+AXgqz1SwutLv4bALLZ3sLQz RHcflZG5U4xwa+Gv26/hB478X/HrUNS0Lwbr+tae8NsoubDTZp4jheQGVSOO 9eS/8Lx+I3/Q++Jv/Bvcf/F0f8Lx+I3/AEPvib/wb3H/AMXUSlzGlKbpS5kd x8PdK+J3hqy1KTV/AHjy/u105rHTbSLQZxArMpUPI+zdhc5CgHJxX6NeE9Hu rb4W+H7WW2miu49Mt45IHjIdXESgqR1BB7V+Vv8AwvH4jf8AQ++Jv/Bvcf8A xdH/AAvH4jf9D74m/wDBvcf/ABdEnzKw5VLu6R7zrmj/ABN+HHx98QeJvDXg XWtU84BI5f7NunhYFVycxgbsY6ZIr2v9kGz8Y6l448fa54y8L3ugTapFbfJd WU0EUpXeCFEvXjGRnvXw3/wvH4jf9D74m/8ABvcf/F0f8Lx+I3/Q++Jv/Bvc f/F159PDeznzc7te9vU+oxWf/WcI8M6EVJxUea7vZNP06H6yar8JPBWu6OdK v/CejXGn/wBnjSVgNjGFSzBUiBMD5YwVQhVwAVUjBAq9qvw98L67oNloepeH NJv9FsTG1rp1zZRyW8BQYQpGVKrtHAwOBwK/I3/hePxG/wCh98Tf+De4/wDi 6P8AhePxG/6H3xN/4N7j/wCLr0OY+Qsz9Z2+FPg+a8iu7jw3pl7dw6hJqkM9 3apM8F0+3dNGWB2Mdq8rj7oPWtLQfB+h+EjfNoWiadpD385urs2NskH2iU/e kk2r8zH1PJr8hv8AhePxG/6H3xN/4N7j/wCLo/4Xj8Rv+h98Tf8Ag3uP/i6O YLH7I1jXHhOzur2S4kebEh3GJX2rn145/WvyH/4Xj8Rv+h98Tf8Ag3uP/i6P +F4/Eb/offE3/g3uP/i6fMLlP2HstKs9OUi2tooc9SigE/U96t1+Nv8AwvH4 jf8AQ++Jv/Bvcf8AxdH/AAvH4jf9D74m/wDBvcf/ABdHMHKfslXz/wDGnwiN X0/x/wCHtQn1bToPFL2Vxa6npOhXeqiIQiIOjpAh2tmHuQMOCCSCB+dv/C8f iN/0Pvib/wAG9x/8XR/wvH4jf9D74m/8G9x/8XQpWd0NJp3R9ceD/gX4X8Ma LNp82veL70Skl2XwLq0Stn1XyyDXX/s0eD/Dn7Oi+I1j1HxXry6u8DLu8Dar AYRH5mBnym3Z8z26e/Hwx/wvH4jf9D74m/8ABvcf/F0f8Lx+I3/Q++Jv/Bvc f/F1EUoylJby3OmeIq1IckpafI/Vb/hdHh//AKB/ir/wkdV/+RqP+F0eH/8A oH+Kv/CR1X/5Gr8qf+F4/Eb/AKH3xN/4N7j/AOLo/wCF4/Eb/offE3/g3uP/ AIuq5jm5T9Vv+F0eH/8AoH+Kv/CR1X/5GqK8+MWiXFpNFDpniqSZ0Kon/CKa mm5iOBua3Cj6kgepFfld/wALx+I3/Q++Jv8Awb3H/wAXR/wvH4jf9D74m/8A Bvcf/F0cwcp+pNt8P9QHwa8J6BJsGraJb6XMYVb5JZrRopPK3dg7Rbd+DgNn BxirU3iTx1PE8b+BbXY6lTjXVBwfcRcV+Vn/AAvH4jf9D74m/wDBvcf/ABdH /C8fiN/0Pvib/wAG9x/8XRcLH6TxeE9egt0hi8EXsaIuxSvji7DKMYwGzkcY 79h6Ct/Q7zxn4ftGtrXwT5sbPvJvfFEl0+cAcNKjMBwOM4zk9Sa/Ln/hePxG /wCh98Tf+De4/wDi6P8AhePxG/6H3xN/4N7j/wCLouFj9Vv+Ep8ef9CLaf8A g8X/AONV8/ap+y7qmr/FWbx5ceHbqXUnlmkFnJrsDWyeYXLAL9nzjLsetfFX /C8fiN/0Pvib/wAG9x/8XR/wvH4jf9D74m/8G9x/8XRzDV4u6Puj4M/s+6/8 EtUe70jQr29je6a8Nte+IITF5hjePOFt1H3ZD79Oa9z8Lix+GHgtn8RarZaY s17eahPJdTrFFC9zcy3JiDsQG2eaV3cbtucDOB+WOj/Gj4g3eowxT+OfEc0T HDJJq07A/UF6/RP9mjwxo+peELbxBd6VZXWvbyv9qTW6Pc44OPNI3Y/Gqvdi d+p4T8af2VPEnxu+Jms+NdKS9tdP1QxNDFd2iQShUiSPLRyyo652ZwyqeelF fdFFKyFdn//Z --= Multipart Boundary 0718060914-- From owner-ccamp@ops.ietf.org Tue Jul 18 10:27:40 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2qY0-0006AQ-4e for ccamp-archive@ietf.org; Tue, 18 Jul 2006 10:27:40 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2qXx-0003Cy-OO for ccamp-archive@ietf.org; Tue, 18 Jul 2006 10:27:40 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G2qNM-000KTE-CR for ccamp-data@psg.com; Tue, 18 Jul 2006 14:16:40 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,HTML_MESSAGE autolearn=ham version=3.1.1 Received: from [12.129.211.51] (helo=usaga01-in.huawei.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G2qNL-000KSy-3U for ccamp@ops.ietf.org; Tue, 18 Jul 2006 14:16:39 +0000 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J2L009URRIEQ2@usaga01-in.huawei.com> for ccamp@ops.ietf.org; Tue, 18 Jul 2006 07:13:27 -0700 (PDT) Received: from Yong73674 (futurewei.com [65.104.224.98]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J2L00AYNRI9PF@usaga01-in.huawei.com> for ccamp@ops.ietf.org; Tue, 18 Jul 2006 07:13:26 -0700 (PDT) Date: Tue, 18 Jul 2006 09:16:24 -0500 From: Lucy Yong Subject: association object To: richard@us.fujitsu.com, ccamp@ops.ietf.org Message-id: <009b01c6aa74$c3a13c90$a5087c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_9mY2g3HeUzEEwZR+zoLINQ)" Thread-index: AcaqdMAu71h2jF0ESMCbA6g/yiG4pQ== Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab This is a multi-part message in MIME format. --Boundary_(ID_9mY2g3HeUzEEwZR+zoLINQ) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Richard, It was nice to meet you in IETF meeting. I have a question about association object used to associate the diversely routed LSPs. If a LSP is established first, say LSP1, then another LSP (say LSP2) needs to be established and be diversely routed from LSP1, how association object is applied in this case? It is easy to use in the latter LSP request, however, how does LSP1 know that it needs to diverse from LSP2. What is the relationship between this association object and diversity object in GMPLS. Best Regards, Lucy --Boundary_(ID_9mY2g3HeUzEEwZR+zoLINQ) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Richard,

It was nice to meet you in IETF meeting. I have a question about association object used to associate the diversely routed LSPs.

If a LSP is established first, say LSP1, then another LSP (say LSP2) needs to be established and be diversely routed from LSP1, how association object is applied in this case? It is easy to use in the latter LSP request, however, how does LSP1 know that it needs to diverse from LSP2.

What is the relationship between this association object and diversity object in GMPLS.

Best Regards,

Lucy

--Boundary_(ID_9mY2g3HeUzEEwZR+zoLINQ)-- From apache@19redchix.info Tue Jul 18 13:25:52 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2tKS-0004gW-Ik for ccamp-archive@ietf.org; Tue, 18 Jul 2006 13:25:52 -0400 Received: from [203.82.20.84] (helo=19redchix.info) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2tKQ-0007S6-Sm for ccamp-archive@ietf.org; Tue, 18 Jul 2006 13:25:52 -0400 Received: by 19redchix.info (Postfix, from userid 48) id 0126EBBC25; Tue, 18 Jul 2006 13:25:48 -0400 (EDT) From: bronze@19redchix.info Subject: =?ISO-2022-JP?B?GyRCNmJIMTMwP009d0AtJEg6IyQ5JDAlKCVDJUEkRyQtJF4kOSJ2GyhC?= To: ccamp-archive@ietf.org Message-Id: <20060718172548.0126EBBC25@19redchix.info> Date: Tue, 18 Jul 2006 13:25:48 -0400 (EDT) X-Spam-Score: 4.2 (++++) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 $B"#"""#8=:_F|K\$K:_=;$7$F$$$k30?M=w@-$O$J$s$H!Z(B200$BK|?M![0J>e!*(B $B"""#$=$l$G$b309q?M=w@-$H$N=P2q$$$OFq$7$$$H;W$C$F$$$^$;$s$+!*!*(B $B"#$J$<$G$7$g$&$+!#8@MU$,DL$8$J$$$+$i!)308+E*$K87$7$$$+$i!)$-$C$+$1$,$J$$$+$i!)(B $B"!CN$j9g$$$?$$$1$I8@MU$,DL$8$J$$(B $B!&!&$$$($$$(F|K\$K$$$k30?M$5$s$G$9$h!y5U$KF|K\8l$r65$($F$"$2$A$c$$$^$7$g$&"v(B $B!!!!(B $B"!308+E*$KF|K\?M$O87$7$$$H;W$&(B $B!&!&!&$H$s$G$b$J$$!*F|K\=w@-$h$j$bFbLL$r=E;k$7$F$$$kJ}$,B?$$$h$&$G$9!#(B $B"!$=$b$=$b=P2q$&!Z$-$C$+$1![$,$J$$$G$9(B $B!&!&!&$=$&$G$9$M!#$J$+$J$+$"$k$b$N$8$c$"$j$^$;$s!#(B $B!,(B.:*$B!&!,(B.:*$B!&!,(B.:*$B!,(B.:*$B!&!,(B.:*$B!&!,(B.:*$B!&!,(B.:*$B!,(B.:*$B!&!,(B.:*$B!&(B.:*$B!&!,(B.:*$B!&!,(B.:*$B!&!,(B.:*$B!,(B.:*$B!&!,!!!!!!(B $B!!!!!!!!!!$G$b!"$=$N!Z$-$C$+$1![$,$"$k$H$7$?$i%"%J%?$O$I$&$7$^$9$+!&!&!&(B $B!!!!!!!!!!F|K\?MCK@-$,0lEY$OF4$l$k!XH~?M30?M$H$N=P2q$$!u%(%C%A!Y(B $B!!!!!!!!!!$b$7$b$=$l$,4JC1$Kl9g$,$4$6$$$^$9$N$G$4N;>5$/$@$5$$!#(B $BBgJQ$*l9g$,$4$6$$$^$9$N$G$4N;>5$/$@$5$$!#(B $BBgJQ$*) id 1G2tLo-000BJI-7d for ccamp-data@psg.com; Tue, 18 Jul 2006 17:27:16 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE, SPF_SOFTFAIL autolearn=no version=3.1.1 Received: from [63.118.34.22] (helo=hicks.ciena.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G2tLf-000BIc-BT for ccamp@ops.ietf.org; Tue, 18 Jul 2006 17:27:07 +0000 Received: from lin1-118-39-27.ciena.com (HELO mdmxm02.ciena.com) ([63.118.39.27]) by hicks.ciena.com with ESMTP; 18 Jul 2006 13:45:01 -0400 X-IronPort-AV: i="4.06,255,1149480000"; d="scan'208,217"; a="59861036:sNHT50083140" x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6AA8F.2E8B883A" Subject: RE: association object Date: Tue, 18 Jul 2006 13:25:36 -0400 Message-ID: <0901D1988E815341A0103206A834DA07E7D531@mdmxm02.ciena.com> In-Reply-To: <009b01c6aa74$c3a13c90$a5087c0a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: association object Thread-Index: AcaqdMAu71h2jF0ESMCbA6g/yiG4pQAGe8Hg From: "Ong, Lyndon" To: "Lucy Yong" , , Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: ff0adf256e4dd459cc25215cfa732ac1 This is a multi-part message in MIME format. ------_=_NextPart_001_01C6AA8F.2E8B883A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Lucy, =20 The association object is used to associate components of a VCG that are already diversely routed in the draft, I would think diverse routing is more a=20 feature of path computation than the signaling to set up the component. =20 What the association object does is allow you to tell what LSPs arriving at the destination are part of the same VCG. =20 Cheers, =20 Lyndon ________________________________ From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Lucy Yong Sent: Tuesday, July 18, 2006 7:16 AM To: richard@us.fujitsu.com; ccamp@ops.ietf.org Subject: association object Richard, =20 It was nice to meet you in IETF meeting. I have a question about association object used to associate the diversely routed LSPs.=20 =20 If a LSP is established first, say LSP1, then another LSP (say LSP2) needs to be established and be diversely routed from LSP1, how association object is applied in this case? It is easy to use in the latter LSP request, however, how does LSP1 know that it needs to diverse from LSP2. =20 What is the relationship between this association object and diversity object in GMPLS. =20 Best Regards, Lucy =20 ------_=_NextPart_001_01C6AA8F.2E8B883A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Lucy,

The association object is used to associate = components of a=20 VCG that are

already diversely routed in the draft, I would = think=20 diverse routing is more a

feature of path computation than the signaling = to set up=20 the component.

What the association object does is allow you = to tell what=20 LSPs arriving at

the destination are part of the same=20 VCG.

Cheers,

Lyndon

From: owner-ccamp@ops.ietf.org=20 [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Lucy = Yong
Sent:=20 Tuesday, July 18, 2006 7:16 AM
To: richard@us.fujitsu.com;=20 ccamp@ops.ietf.org
Subject: association = object

Richard,

It was nice to meet you = in IETF=20 meeting. I have a question about association object used to associate = the=20 diversely routed LSPs.

If a LSP is established = first, say=20 LSP1, then another LSP (say LSP2) needs to be established and be = diversely=20 routed from LSP1, how association object is applied in this case? It is = easy to=20 use in the latter LSP request, however, how does LSP1 know that it needs = to=20 diverse from LSP2.

What is the relationship = between=20 this association object and diversity object in=20 GMPLS.

Best=20 Regards,

Lucy

------_=_NextPart_001_01C6AA8F.2E8B883A-- From owner-ccamp@ops.ietf.org Tue Jul 18 13:56:20 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2tnw-0002yN-NH for ccamp-archive@ietf.org; Tue, 18 Jul 2006 13:56:20 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2tnu-0001rN-Cs for ccamp-archive@ietf.org; Tue, 18 Jul 2006 13:56:20 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G2thT-000CvP-IV for ccamp-data@psg.com; Tue, 18 Jul 2006 17:49:39 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [192.240.0.5] (helo=fujitsu0.fujitsu.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G2thS-000CvB-BF for ccamp@ops.ietf.org; Tue, 18 Jul 2006 17:49:38 +0000 Received: from fujitsu0.fujitsu.com (localhost [127.0.0.1]) by fujitsu0.fujitsu.com (8.13.7/8.13.7) with ESMTP id k6IHnREv029323; Tue, 18 Jul 2006 10:49:27 -0700 (PDT) Received: from fujitsui.fna.fujitsu.com ([133.164.253.1]) by fujitsu0.fujitsu.com (8.13.7/8.13.7) with ESMTP id k6IHnKUL029297; Tue, 18 Jul 2006 10:49:24 -0700 (PDT) Received: from mailserv.fla.fujitsu.com (localhost [127.0.0.1]) by fujitsui.fna.fujitsu.com (8.13.7/8.13.7) with ESMTP id k6IHnIgt018288; Tue, 18 Jul 2006 10:49:18 -0700 (PDT) Received: from [133.164.59.85] (localhost [127.0.0.1]) by mailserv.fla.fujitsu.com (8.11.6/8.11.6) with ESMTP id k6IHnIw24222; Tue, 18 Jul 2006 10:49:18 -0700 (PDT) Message-ID: <44BD1F1D.2070004@us.fujitsu.com> Date: Tue, 18 Jul 2006 10:49:17 -0700 From: Richard Rabbat User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Lucy Yong CC: ccamp@ops.ietf.org Subject: Re: association object References: <009b01c6aa74$c3a13c90$a5087c0a@china.huawei.com> In-Reply-To: <009b01c6aa74$c3a13c90$a5087c0a@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Lucy, likewise. my comments inline. Lucy Yong wrote: > > Richard, > > > > It was nice to meet you in IETF meeting. I have a question about > association object used to associate the diversely routed LSPs. > > > > If a LSP is established first, say LSP1, then another LSP (say LSP2) > needs to be established and be diversely routed from LSP1, how > association object is applied in this case? It is easy to use in the > latter LSP request, however, how does LSP1 know that it needs to > diverse from LSP2. > Lyndon covered the diversity issue and the fact that we are not doing path computation here, but I would like to add one more comment since I've got a similar question. For LSP1 to be aware of the association, one can send a full PATH message with the added association object. this is neither a refresh message nor a new path setup message. all nodes will process that message and be aware of the new association object and hence LSP1 will from then on know about the association. I hope this helps Richard. > > > What is the relationship between this association object and diversity > object in GMPLS. > > > > Best Regards, > > Lucy > > > From owner-ccamp@ops.ietf.org Tue Jul 18 14:12:20 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2u3Q-0004as-1B for ccamp-archive@ietf.org; Tue, 18 Jul 2006 14:12:20 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2u3N-0002tm-C2 for ccamp-archive@ietf.org; Tue, 18 Jul 2006 14:12:20 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G2tya-000EQd-TH for ccamp-data@psg.com; Tue, 18 Jul 2006 18:07:20 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,HTML_MESSAGE,SPF_PASS autolearn=no version=3.1.1 Received: from [171.71.176.72] (helo=sj-iport-3.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G2tyZ-000EQR-TQ for ccamp@ops.ietf.org; Tue, 18 Jul 2006 18:07:20 +0000 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-3.cisco.com with ESMTP; 18 Jul 2006 11:07:10 -0700 X-IronPort-AV: i="4.06,255,1149490800"; d="scan'208,217"; a="434967969:sNHT49681852" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6II79U1021033; Tue, 18 Jul 2006 11:07:09 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k6II742N012214; Tue, 18 Jul 2006 11:07:09 -0700 (PDT) Received: from xmb-sjc-234.amer.cisco.com ([128.107.191.111]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 18 Jul 2006 11:07:09 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6AA94.FC1F4A82" Subject: Some comments on draft-dimitri-ccamp-gmpls-ason-routing-ospf-00.txt Date: Tue, 18 Jul 2006 11:07:09 -0700 Message-ID: <70BC84B185C3EE448EDB7AB8956D3B0E02027B9D@xmb-sjc-234.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Some comments on draft-dimitri-ccamp-gmpls-ason-routing-ospf-00.txt Thread-Index: AcaqlPxo/zGHXQwESA+h2k+BWgdRSA== From: "Dean Cheng $dcheng$" To: "dimitri papadimitriou" Cc: X-OriginalArrivalTime: 18 Jul 2006 18:07:09.0102 (UTC) FILETIME=[FC46D4E0:01C6AA94] DKIM-Signature: a=rsa-sha1; q=dns; l=12595; t=1153246030; x=1154110030; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dcheng@cisco.com; z=From:=22Dean=20Cheng=20$dcheng$=22=20 |Subject:Some=20comments=20on=20draft-dimitri-ccamp-gmpls-ason-routing-ospf-00.tx t; X=v=3Dcisco.com=3B=20h=3Dcai6wrVC2pg1fEo/asIk2w08toY=3D; b=rOqmc3A/fC5HPdhlM51ZZTA4wYhWNFXqzJhlA0OcDGAyw0tRozvoDCUakGVd7NXLemvFAjRY JsopXZIuUafGDMdFi6OvXklutaLHmc0kb1XdBDYu7MVsKXZIrsyKHkdy; Authentication-Results: sj-dkim-3.cisco.com; header.From=dcheng@cisco.com; dkim=pass ( 59 extraneous bytes; sig from cisco.com verified; ); Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 9e5c23589e6cce06555030c0194c9e2b This is a multi-part message in MIME format. ------_=_NextPart_001_01C6AA94.FC1F4A82 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dimitri, =20 I've some comments now as follows: =20 1) The third paragraph of section 6.1, it says, "....However, an additional restriction MUST be applied such that the RC=20 selection process takes into account that an upper level may be adjacent to one or more lower levels." =20 It would be good to clarify the words "one or more lower levels" here. From the sentence after that, it actually means one or=20 more areas at the lower levels. =20 2) In section 6.1, it says that the D bit is used together with the "Associated Area ID" sub-tlv, as "an additional restriction". In the same section, it does not mention the use of that sub-tlv along with U bit. =20 But in section 6.2.1 and 6.2.2, it explicitly says that the "Associated Area ID" sub-tlv is included when re-originating the opaque LSA=20 downward or upward.=20 =20 It would require clarification and consistency here. =20 3) In section 6.1 (Discovery and Selection), it describes a method for "selecting" the RC that performs the upward/downward dissemination of routing information.=20 =20 What happens if RC1 is currently the RC that doing the upward advertising but RC2 just becomes active with U-bit set and a higher Router ID ?=20 =20 I guess the same handling as OSPF DR's election can be used for stability purpose, and also for consistency, and if so, needs to be stated=20 in this section. And for that matter, the word "selection" vs. "election" does not really make much difference. =20 4) In section 7.2, it is also useful to add that the number of levels be under policy control. =20 5) It would be useful to add an interoperability section, which describes how an traditional OSPF node/network interoperates (if need to) with an OSPF=20 node/network with extensions as described in this ID. E.g., a reachable address (prefix) is advertised by an ABR normally but with this ID, can also be advertised through hierarchy. =20 Thanks Dean=20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 ------_=_NextPart_001_01C6AA94.FC1F4A82 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dimitri,

I've = some comments=20 now as follows:

1) The = third=20 paragraph of section 6.1, it says, "....However, an

=20 additional restriction MUST be applied such that the RC =

=20 selection process takes into account that an upper level = may

=20 be adjacent to one or more lower levels."

=20 It would be good to clarify the words "one or more lower=20 levels"

=20 here. From the sentence after that, it actually means one=20 or=20

=20 more areas at the lower levels.

2) In = section 6.1,=20 it says that the D bit is used together with the

= "Associated Area ID" sub-tlv, as "an additional restriction".=20 In

=20 the same section, it does not mention the use of that=20 sub-tlv

=20 along with U bit.

But in=20 section 6.2.1 and 6.2.2, it explicitly says that the=20 "Associated

Area=20 ID" sub-tlv is included when re-originating the opaque LSA =

downward or upward.=20

It=20 would require clarification and consistency here.

3) In=20 section 6.1 (Discovery and Selection), it describes a=20 method

=20 for "selecting" the RC that performs the upward/downward=20 dissemination

=20 of routing information.

What happens = if RC1=20 is currently the RC that doing the upward = advertising

=20 but RC2 just becomes active with U-bit set and a higher Router ID ? =

I=20 guess the same handling as OSPF DR's election can be used=20 for

=20 stability purpose, and also for consistency, and if so, needs to be = stated=20

=20 in this section. And for that matter, the word "selection" vs.=20 "election"

=20 does not really make much difference.

4) In = section 7.2,=20 it is also useful to add that the number of levels be = under

policy=20 control.

5) It = would be=20 useful to add an interoperability section, which describes=20 how

=20 an traditional OSPF node/network interoperates (if need to) with an = OSPF=20

=20 node/network with extensions as described in this ID. = E.g., a=20 reachable

=20 address (prefix) is advertised by an ABR normally but with=20 this ID, can also

=20 be advertised through = hierarchy.

Thanks

Dean

------_=_NextPart_001_01C6AA94.FC1F4A82-- From owner-ccamp@ops.ietf.org Tue Jul 18 14:49:59 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2udr-0003S0-4R for ccamp-archive@ietf.org; Tue, 18 Jul 2006 14:49:59 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2udp-0006Al-Iw for ccamp-archive@ietf.org; Tue, 18 Jul 2006 14:49:59 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G2uYh-000HlZ-VU for ccamp-data@psg.com; Tue, 18 Jul 2006 18:44:39 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,HTML_MESSAGE autolearn=ham version=3.1.1 Received: from [12.129.211.51] (helo=usaga01-in.huawei.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G2uYf-000HlF-Ep for ccamp@ops.ietf.org; Tue, 18 Jul 2006 18:44:37 +0000 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J2M006H93X0BS@usaga01-in.huawei.com> for ccamp@ops.ietf.org; Tue, 18 Jul 2006 11:41:24 -0700 (PDT) Received: from Yong73674 (futurewei.com [65.104.224.98]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J2M00AIT3WSR7@usaga01-in.huawei.com> for ccamp@ops.ietf.org; Tue, 18 Jul 2006 11:41:23 -0700 (PDT) Date: Tue, 18 Jul 2006 13:44:25 -0500 From: Lucy Yong Subject: RE: association object In-reply-to: <0901D1988E815341A0103206A834DA07E7D531@mdmxm02.ciena.com> To: "'Ong, Lyndon'" , richard@us.fujitsu.com, ccamp@ops.ietf.org Message-id: <00b501c6aa9a$321acae0$a5087c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_SlT/fxYiFLN1R7mHlVaUDA)" Thread-index: AcaqdMAu71h2jF0ESMCbA6g/yiG4pQAGe8HgAAKhZyA= Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 2b3349545af520ba354ccdc9e1a03fc1 This is a multi-part message in MIME format. --Boundary_(ID_SlT/fxYiFLN1R7mHlVaUDA) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi Lyndon, Thank you for the explanation. Thus, this association is only significant at the destination, is that right? Is VCG group value generated by the source? Best Regards, Lucy _____ From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Ong, Lyndon Sent: Tuesday, July 18, 2006 12:26 PM To: Lucy Yong; richard@us.fujitsu.com; ccamp@ops.ietf.org Subject: RE: association object Hi Lucy, The association object is used to associate components of a VCG that are already diversely routed in the draft, I would think diverse routing is more a feature of path computation than the signaling to set up the component. What the association object does is allow you to tell what LSPs arriving at the destination are part of the same VCG. Cheers, Lyndon _____ From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Lucy Yong Sent: Tuesday, July 18, 2006 7:16 AM To: richard@us.fujitsu.com; ccamp@ops.ietf.org Subject: association object Richard, It was nice to meet you in IETF meeting. I have a question about association object used to associate the diversely routed LSPs. If a LSP is established first, say LSP1, then another LSP (say LSP2) needs to be established and be diversely routed from LSP1, how association object is applied in this case? It is easy to use in the latter LSP request, however, how does LSP1 know that it needs to diverse from LSP2. What is the relationship between this association object and diversity object in GMPLS. Best Regards, Lucy --Boundary_(ID_SlT/fxYiFLN1R7mHlVaUDA) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Hi Lyndon,

Thank you for the explanation. Thus, this association is only significant at the destination, is that right? Is VCG group value generated by the source?

Best Regards,

Lucy

From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Ong, Lyndon
Sent: Tuesday, July 18, 2006 12:26 PM
To: Lucy Yong; richard@us.fujitsu.com; ccamp@ops.ietf.org
Subject: RE: association object

Hi Lucy,

The association object is used to associate components of a VCG that are

already diversely routed in the draft, I would think diverse routing is more a

feature of path computation than the signaling to set up the component.

What the association object does is allow you to tell what LSPs arriving at

the destination are part of the same VCG.

Cheers,

Lyndon

From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Lucy Yong
Sent: Tuesday, July 18, 2006 7:16 AM
To: richard@us.fujitsu.com; ccamp@ops.ietf.org
Subject: association object

Richard,

It was nice to meet you in IETF meeting. I have a question about association object used to associate the diversely routed LSPs.

What is the relationship between this association object and diversity object in GMPLS.

Best Regards,

Lucy

--Boundary_(ID_SlT/fxYiFLN1R7mHlVaUDA)-- From owner-ccamp@ops.ietf.org Tue Jul 18 16:41:04 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2wNM-0004fH-Id for ccamp-archive@ietf.org; Tue, 18 Jul 2006 16:41:04 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2wNL-0003sW-4z for ccamp-archive@ietf.org; Tue, 18 Jul 2006 16:41:04 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G2wH7-0000RP-Qo for ccamp-data@psg.com; Tue, 18 Jul 2006 20:34:37 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-4.7 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from localhost ([127.0.0.1]) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G2wH6-0000R9-Rd; Tue, 18 Jul 2006 20:34:37 +0000 Message-ID: <44BD45E2.3080104@psg.com> Date: Tue, 18 Jul 2006 22:34:42 +0200 From: dimitri papadimitriou Reply-To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.11) Gecko/20050728 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Dean Cheng (dcheng)" CC: ccamp@ops.ietf.org Subject: Re: Some comments on draft-dimitri-ccamp-gmpls-ason-routing-ospf-00.txt References: <70BC84B185C3EE448EDB7AB8956D3B0E02027B9D@xmb-sjc-234.amer.cisco.com> In-Reply-To: <70BC84B185C3EE448EDB7AB8956D3B0E02027B9D@xmb-sjc-234.amer.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 dean thanks for commenting - see in-line Dean Cheng (dcheng) wrote: > Dimitri, > > I've some comments now as follows: > > 1) The third paragraph of section 6.1, it says, "....However, an > additional restriction MUST be applied such that the RC > selection process takes into account that an upper level may > be adjacent to one or more lower levels." > > It would be good to clarify the words "one or more lower levels" > here. From the sentence after that, it actually means one or > more areas at the lower levels. ok > 2) In section 6.1, it says that the D bit is used together with the > "Associated Area ID" sub-tlv, as "an additional restriction". In > the same section, it does not mention the use of that sub-tlv > along with U bit. > > But in section 6.2.1 and 6.2.2, it explicitly says that the > "Associated > Area ID" sub-tlv is included when re-originating the opaque LSA > downward or upward. > > It would require clarification and consistency here. i will split this section 6.1 into two parts and refer to section 6.2 for the case addressed by that section > 3) In section 6.1 (Discovery and Selection), it describes a method > for "selecting" the RC that performs the upward/downward > dissemination > of routing information. > > What happens if RC1 is currently the RC that doing the upward > advertising > but RC2 just becomes active with U-bit set and a higher Router ID ? > > I guess the same handling as OSPF DR's election can be used for > stability purpose, and also for consistency, and if so, needs to be > stated > in this section. indeed hysteresis mechanism is needed in such condition > And for that matter, the word "selection" vs. > "election" does not really make much difference. > > 4) In section 7.2, it is also useful to add that the number of levels be > under > policy control. ok > 5) It would be useful to add an interoperability section, which > describes how > an traditional OSPF node/network interoperates (if need to) with an > OSPF > node/network with extensions as described in this ID. E.g., a > reachable > address (prefix) is advertised by an ABR normally but with this ID, > can also > be advertised through hierarchy. i guess you mean a GMPLS LSR not implementing these extensions ? thanks, - dimitri. > Thanks > Dean > > > > > > > > > > > > > > > > > > > > > > > > > > > From owner-ccamp@ops.ietf.org Wed Jul 19 08:45:00 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3BQC-00081G-CC for ccamp-archive@ietf.org; Wed, 19 Jul 2006 08:45:00 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3BQA-00083G-Vx for ccamp-archive@ietf.org; Wed, 19 Jul 2006 08:45:00 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G3BJb-0008qD-VJ for ccamp-data@psg.com; Wed, 19 Jul 2006 12:38:11 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=BAYES_00,DNS_FROM_RFC_POST, FORGED_RCVD_HELO,SPF_PASS autolearn=no version=3.1.1 Received: from [213.46.243.15] (helo=amsfep12-int.chello.nl) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G3BJZ-0008pj-QB for ccamp@ops.ietf.org; Wed, 19 Jul 2006 12:38:10 +0000 Received: from localhost ([127.0.0.1]) by amsfep12-int.chello.nl (InterMail vM.6.01.04.04 201-2131-118-104-20050224) with SMTP id <20060719123757.SFPK1836.amsfep12-int.chello.nl@localhost>; Wed, 19 Jul 2006 14:37:57 +0200 X-Mailer: Openwave WebEngine, version 2.8.16 (webedge20-101-1106-20040809) X-Originating-IP: [156.106.204.104] From: Huub van Helvoort To: Lucy Yong ,"'Ong, Lyndon'" ,, Subject: Re: RE: association object Date: Wed, 19 Jul 2006 14:37:57 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Message-Id: <20060719123757.SFPK1836.amsfep12-int.chello.nl@localhost> Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Dear Lucy, You wrote: > Thank you for the explanation. Thus, this association is only significant at > the destination, is that right? Yes, intermediate nodes do not have to be aware of the association between the LSPs in a VCG. > Is VCG group value generated by the source? I am not sure what you mean by value. Is it the identifier for a specific VCG, or is it the size (number of LSPs) of the VCG? Cheers, Huub. > _____ > > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf > Of Ong, Lyndon > Sent: Tuesday, July 18, 2006 12:26 PM > To: Lucy Yong; richard@us.fujitsu.com; ccamp@ops.ietf.org > Subject: RE: association object > > Hi Lucy, > > The association object is used to associate components of a VCG that are > already diversely routed in the draft, I would think diverse routing is more > a > feature of path computation than the signaling to set up the component. > > What the association object does is allow you to tell what LSPs arriving at > the destination are part of the same VCG. > > Cheers, > > Lyndon > > _____ > > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf > Of Lucy Yong > Sent: Tuesday, July 18, 2006 7:16 AM > To: richard@us.fujitsu.com; ccamp@ops.ietf.org > Subject: association object > > Richard, > > It was nice to meet you in IETF meeting. I have a question about association > object used to associate the diversely routed LSPs. > > If a LSP is established first, say LSP1, then another LSP (say LSP2) needs > to be established and be diversely routed from LSP1, how association object > is applied in this case? It is easy to use in the latter LSP request, > however, how does LSP1 know that it needs to diverse from LSP2. > > What is the relationship between this association object and diversity > object in GMPLS. > > Best Regards, > > Lucy > From owner-ccamp@ops.ietf.org Wed Jul 19 10:14:12 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3CoV-0000zp-W0 for ccamp-archive@ietf.org; Wed, 19 Jul 2006 10:14:12 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3CoT-0005BB-L7 for ccamp-archive@ietf.org; Wed, 19 Jul 2006 10:14:11 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G3Chx-000ImC-Ej for ccamp-data@psg.com; Wed, 19 Jul 2006 14:07:25 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [12.129.211.51] (helo=usaga01-in.huawei.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G3ChO-000Ijv-La for ccamp@ops.ietf.org; Wed, 19 Jul 2006 14:06:50 +0000 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J2N00AV2LQ4CW@usaga01-in.huawei.com> for ccamp@ops.ietf.org; Wed, 19 Jul 2006 07:03:40 -0700 (PDT) Received: from Yong73674 (futurewei.com [65.104.224.98]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J2N000LHLPZAA@usaga01-in.huawei.com> for ccamp@ops.ietf.org; Wed, 19 Jul 2006 07:03:40 -0700 (PDT) Date: Wed, 19 Jul 2006 09:06:43 -0500 From: Lucy Yong Subject: RE: RE: association object In-reply-to: <20060719123757.SFPK1836.amsfep12-int.chello.nl@localhost> To: 'Huub van Helvoort' , "'Ong, Lyndon'" , richard@us.fujitsu.com, ccamp@ops.ietf.org Message-id: <00e301c6ab3c$90f635c0$a5087c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcarMKYXJmBYgdZXQrqHiH7zRwKupAAC78Iw Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Huub, Thank you fro the answer. The value I mentioned is for VCG group ID. Regards, Lucy -----Original Message----- From: Huub van Helvoort [mailto:hhelvoort@chello.nl] Sent: Wednesday, July 19, 2006 7:38 AM To: Lucy Yong; 'Ong, Lyndon'; richard@us.fujitsu.com; ccamp@ops.ietf.org Subject: Re: RE: association object Dear Lucy, You wrote: > Thank you for the explanation. Thus, this association is only significant at > the destination, is that right? Yes, intermediate nodes do not have to be aware of the association between the LSPs in a VCG. > Is VCG group value generated by the source? I am not sure what you mean by value. Is it the identifier for a specific VCG, or is it the size (number of LSPs) of the VCG? Cheers, Huub. > _____ > > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf > Of Ong, Lyndon > Sent: Tuesday, July 18, 2006 12:26 PM > To: Lucy Yong; richard@us.fujitsu.com; ccamp@ops.ietf.org > Subject: RE: association object > > Hi Lucy, > > The association object is used to associate components of a VCG that are > already diversely routed in the draft, I would think diverse routing is more > a > feature of path computation than the signaling to set up the component. > > What the association object does is allow you to tell what LSPs arriving at > the destination are part of the same VCG. > > Cheers, > > Lyndon > > _____ > > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf > Of Lucy Yong > Sent: Tuesday, July 18, 2006 7:16 AM > To: richard@us.fujitsu.com; ccamp@ops.ietf.org > Subject: association object > > Richard, > > It was nice to meet you in IETF meeting. I have a question about association > object used to associate the diversely routed LSPs. > > If a LSP is established first, say LSP1, then another LSP (say LSP2) needs > to be established and be diversely routed from LSP1, how association object > is applied in this case? It is easy to use in the latter LSP request, > however, how does LSP1 know that it needs to diverse from LSP2. > > What is the relationship between this association object and diversity > object in GMPLS. > > Best Regards, > > Lucy > From owner-ccamp@ops.ietf.org Wed Jul 19 10:44:51 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3DIB-0005fk-Qm for ccamp-archive@ietf.org; Wed, 19 Jul 2006 10:44:51 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3DI9-0007et-AP for ccamp-archive@ietf.org; Wed, 19 Jul 2006 10:44:51 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G3D93-000Ltb-O6 for ccamp-data@psg.com; Wed, 19 Jul 2006 14:35:25 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.1 Received: from [80.68.34.49] (helo=mail2.noc.data.net.uk) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G3D92-000LtN-2B for ccamp@ops.ietf.org; Wed, 19 Jul 2006 14:35:24 +0000 Received: from 57-99.dsl.data.net.uk ([80.68.57.99] helo=cortex.aria-networks.com) by mail2.noc.data.net.uk with esmtp (Exim 3.36 #1) id 1G3D8y-0007CJ-00 for ccamp@ops.ietf.org; Wed, 19 Jul 2006 15:35:20 +0100 Received: from your029b8cecfe ([217.158.132.68] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 19 Jul 2006 15:35:20 +0100 Message-ID: <00c501c6ab40$7ebf7110$0a23fea9@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Mack-Crane, T. Benjamin" Cc: , "Brungard, Deborah A, ALABS" References: <009301c6a765$1ca049c0$851fdb84@your029b8cecfe> Subject: Re: Working Group Last Call on draft-ietf-ccamp-gmpls-rsvp-te-call-00.txt Date: Wed, 19 Jul 2006 14:26:02 +0100 Organization: Old Dog Consulting MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-OriginalArrivalTime: 19 Jul 2006 14:35:22.0014 (UTC) FILETIME=[90ACD3E0:01C6AB40] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Ben, Sorry for the delay while travelling, etc. > Hi Adrian, > > There were also these comments which have not been fully addressed > afaik: > >>> 3) The network models being used in section 4.3 and section 7 are >>> not clear. In particular the relationships between the call >>> controllers, network boundaries, ingress/egress nodes, and >>> ingress/egress links are not clear. Figures would be very helpful >>here. >> >> Figures are always helpful, and usually (but not always) better than >> words. >> >> In order to be sure to clarify the network models that you are finding >> confusing, it would be helpful if you asked specific questions or >> roposed text. > > It is not clear how the form of initiation of a call affects the > information available about the egress link. In part this may be > affected by whether the ingress node is inside or outside the network > (IGP) boundary. It would seem that the situation at the egress would > have something to do with this as well. It is unclear where the egress > trail termination point is expected to be, e.g. inside or outside the > network boundary, and, if inside, at the near or far side of the egress > node's matrix. You have latched on to an important point. The information about the egress link might not be generally available within the TED particularly when the egress node is outside the TE domain (although we should observe some of the recent discussions about OSPF and BGP extensions for advertising PE-CE link TE capabilities). And, in fact, this is an important purpose of the Call, and why the Link Capability object exists. The Link Capability object may be used when the tail-end is within or outside the the TE domain, and so we support the egress (and correspondingly the ingress) being inside or outside the TE domain. This follows quite naturally from RFC 4208. We could add a statement that the ingress and egress may be inside or outside the TE domain if this will make you more comfortable. >> >5) The call control mechanism defined appears to support >> > only IPv4 or IPv6 addressed endpoints from a single address >> > space. Is this correct? >> >> I don't think so. > > I would be interested to know how to correctly understand the draft. > That is, what addressing other than IPv4/6 is supported, and how > multiple address spaces are supported. Hmmm. Perhaps an issue of punctuation in your original question? Yes: we only support IPv4 or IPv6 addresses. No: we don't require the use of a single address space, as discussed in RFC 4208. Hope that answers for you. Regards, Adrian From owner-ccamp@ops.ietf.org Wed Jul 19 10:50:06 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3DNG-0005yW-Bz for ccamp-archive@ietf.org; Wed, 19 Jul 2006 10:50:06 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3DNG-0007vP-Ad for ccamp-archive@ietf.org; Wed, 19 Jul 2006 10:50:06 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G3DMi-000503-Cc for ccamp-archive@ietf.org; Wed, 19 Jul 2006 10:49:33 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G3D9A-000Ltx-DK for ccamp-data@psg.com; Wed, 19 Jul 2006 14:35:32 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.1 Received: from [80.68.34.49] (helo=mail2.noc.data.net.uk) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G3D99-000Ltl-Oz for ccamp@ops.ietf.org; Wed, 19 Jul 2006 14:35:31 +0000 Received: from 57-99.dsl.data.net.uk ([80.68.57.99] helo=cortex.aria-networks.com) by mail2.noc.data.net.uk with esmtp (Exim 3.36 #1) id 1G3D96-0007DQ-00 for ccamp@ops.ietf.org; Wed, 19 Jul 2006 15:35:28 +0100 Received: from your029b8cecfe ([217.158.132.68] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 19 Jul 2006 15:35:29 +0100 Message-ID: <00c601c6ab40$7f534ca0$0a23fea9@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: References: <062701c6a5e6$e40805f0$e90ddb84@your029b8cecfe> Subject: Re: OSPF ASON Routing Solution Date: Wed, 19 Jul 2006 14:27:17 +0100 Organization: Old Dog Consulting MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-OriginalArrivalTime: 19 Jul 2006 14:35:29.0702 (UTC) FILETIME=[9541EC60:01C6AB40] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: -0.6 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Just a refresh in case you were travelling. I am seeking objections to this draft becoming a WG document. Adrian ----- Original Message ----- From: "Adrian Farrel" To: Sent: Wednesday, July 12, 2006 8:10 PM Subject: OSPF ASON Routing Solution > Hi, > On Monday in CCAMP we discussed > draft-dimitri-ccamp-gmpls-ason-routing-ospf-00.txt the solutions draft for > OSPF in ASON routing. > > There is agreement from the OSPF WG chair that we are not treading on > toes, and the meeting seemed to say that this was pretty stable. > > So a this is a quick poll to see if anyone objects to this becoming a WG > draft. > NB, this is a charter item and we have an obligation to work on this for > the ITU-T. > > Thanks, > Adrian > > PS Note that a solution does not have to be 100% perfect to become a WG > draft. > > > > > From owner-ccamp@ops.ietf.org Wed Jul 19 11:17:52 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3Do8-0002NG-1r for ccamp-archive@ietf.org; Wed, 19 Jul 2006 11:17:52 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3Do6-0001pg-LX for ccamp-archive@ietf.org; Wed, 19 Jul 2006 11:17:52 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G3Diw-000Pkb-7b for ccamp-data@psg.com; Wed, 19 Jul 2006 15:12:30 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.1 Received: from [145.99.151.210] (helo=bobbie.je-ju.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G3Diu-000PkC-La for ccamp@ops.ietf.org; Wed, 19 Jul 2006 15:12:28 +0000 Received: from [195.169.128.81] (unknown [195.169.128.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bobbie.je-ju.net (Postfix) with ESMTP id F14718411 for ; Wed, 19 Jul 2006 17:12:26 +0200 (CEST) Message-ID: <44BE4BDB.8050304@science.uva.nl> Date: Wed, 19 Jul 2006 17:12:27 +0200 From: Jeroen van der Ham User-Agent: Thunderbird 1.5.0.4 (Macintosh/20060530) MIME-Version: 1.0 To: ccamp@ops.ietf.org Subject: Questions regarding draft-ietf-ccamp-gmpls-mln-reqs-01 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Hello, I am trying to understand the text in draft-ietf-ccamp-gmpls-mln-reqs-01, but some things are not completely clear to me, I hope someone can explain them: - I believe that the draft often uses the term ISCD often where ISC is meant. If I understand it correctly, different ISCDs can be announced for a given interface at different times, for example because the available bandwidth is changing. - At the end of the first paragraph in Section 3.3 it states: > [...] in carrier's networks that are based on multiple layers, > switching technologies, or ISCDs. I think that this statement should not mention ISCDs at all, because it makes no sense in that context. Especially if you also read the following statement at the end of the third paragraph in section 4.3: > The ISCD does not "identify" network layers, it uniquely characterizes > information associated to one or more network layers. - I find the example in section 4.2.1 to be very briefly explained, it could do with a better explanation of what is going on. One improvement would be to state explicitly which three(!) ways are possible for setting up an PSC LSP across this device: 1) Terminating on interface #b 2) Terminating on interface #a 3) Going through the device towards a neighboring PSC node. It would also help to explain that the existance of possibility 1 is the sole reason that the device is a hybrid device. And that possibility 1 is also the reason why the PSC is advertised on Link2. Other minor corrections: Section 1 mixes the notation of VC-x and VCx Section 4.2.1 has swtching, where it should switching Jeroen. From owner-ccamp@ops.ietf.org Wed Jul 19 13:59:45 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3GKn-0005rM-8L for ccamp-archive@ietf.org; Wed, 19 Jul 2006 13:59:45 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3GKk-0002HW-Um for ccamp-archive@ietf.org; Wed, 19 Jul 2006 13:59:45 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G3GFG-000Htd-Ty for ccamp-data@psg.com; Wed, 19 Jul 2006 17:54:02 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=0.1 required=5.0 tests=BAYES_00,DNS_FROM_RFC_POST, NO_REAL_NAME autolearn=no version=3.1.1 Received: from [64.208.49.165] (helo=smail.alcatel.fr) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G3GFE-000Ht1-GZ; Wed, 19 Jul 2006 17:54:00 +0000 Received: from bemail01.netfr.alcatel.fr (bemail01.netfr.alcatel.fr [155.132.251.32]) by smail.alcatel.fr (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k6JHrugM013638; Wed, 19 Jul 2006 19:53:56 +0200 In-Reply-To: <00c601c6ab40$7f534ca0$0a23fea9@your029b8cecfe> Subject: Re: OSPF ASON Routing Solution To: "Adrian Farrel" Cc: ccamp@ops.ietf.org, owner-ccamp@ops.ietf.org X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: Emmanuel.Desmet@alcatel.be Date: Wed, 19 Jul 2006 19:53:53 +0200 X-MIMETrack: Serialize by Router on BEMAIL01/BE/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 07/19/2006 19:53:55 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Scanned-By: MIMEDefang 2.51 on 155.132.180.81 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.2 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Adrian, I am all in favour of making this a WG I-D, @+ mannu "Adrian Farrel" o.uk> cc: Sent by: Subject: Re: OSPF ASON Routing Solution owner-ccamp@ops. ietf.org 19/07/2006 15:27 Please respond to "Adrian Farrel" Just a refresh in case you were travelling. I am seeking objections to this draft becoming a WG document. Adrian ----- Original Message ----- From: "Adrian Farrel" To: Sent: Wednesday, July 12, 2006 8:10 PM Subject: OSPF ASON Routing Solution > Hi, > On Monday in CCAMP we discussed > draft-dimitri-ccamp-gmpls-ason-routing-ospf-00.txt the solutions draft for > OSPF in ASON routing. > > There is agreement from the OSPF WG chair that we are not treading on > toes, and the meeting seemed to say that this was pretty stable. > > So a this is a quick poll to see if anyone objects to this becoming a WG > draft. > NB, this is a charter item and we have an obligation to work on this for > the ITU-T. > > Thanks, > Adrian > > PS Note that a solution does not have to be 100% perfect to become a WG > draft. > > > > > From owner-ccamp@ops.ietf.org Wed Jul 19 14:25:34 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3GjZ-00073m-0I for ccamp-archive@ietf.org; Wed, 19 Jul 2006 14:25:21 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3GUT-00040K-4J for ccamp-archive@ietf.org; Wed, 19 Jul 2006 14:09:47 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G3GJv-000IVk-O7 for ccamp-data@psg.com; Wed, 19 Jul 2006 17:58:51 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE autolearn=no version=3.1.1 Received: from [192.240.0.5] (helo=fujitsu0.fujitsu.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G3GJv-000ITz-0i for ccamp@ops.ietf.org; Wed, 19 Jul 2006 17:58:51 +0000 Received: from fujitsu0.fujitsu.com (localhost [127.0.0.1]) by fujitsu0.fujitsu.com (8.13.7/8.13.7) with ESMTP id k6JHwmJX025203; Wed, 19 Jul 2006 10:58:48 -0700 (PDT) Received: from fujitsu7i.fnanic.fujitsu.com ([133.164.253.7]) by fujitsu0.fujitsu.com (8.13.7/8.13.7) with ESMTP id k6JHwUlt025012; Wed, 19 Jul 2006 10:58:40 -0700 (PDT) Received: from mailserv.fla.fujitsu.com (localhost [127.0.0.1]) by fujitsu7i.fnanic.fujitsu.com (8.13.7/8.13.7) with ESMTP id k6JHwTtN011966; Wed, 19 Jul 2006 10:58:29 -0700 (PDT) Received: from [133.164.4.31] (localhost [127.0.0.1]) by mailserv.fla.fujitsu.com (8.11.6/8.11.6) with ESMTP id k6JHwTw25956; Wed, 19 Jul 2006 10:58:29 -0700 (PDT) Message-ID: <44BE72C4.6050004@us.fujitsu.com> Date: Wed, 19 Jul 2006 10:58:28 -0700 From: Richard Rabbat User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Adrian Farrel CC: ccamp@ops.ietf.org Subject: Re: OSPF ASON Routing Solution References: <062701c6a5e6$e40805f0$e90ddb84@your029b8cecfe> <00c601c6ab40$7f534ca0$0a23fea9@your029b8cecfe> In-Reply-To: <00c601c6ab40$7f534ca0$0a23fea9@your029b8cecfe> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 bien au contraire. fully support this becoming a WG document. Richard. Adrian Farrel wrote: > Just a refresh in case you were travelling. > > I am seeking objections to this draft becoming a WG document. > > Adrian > ----- Original Message ----- From: "Adrian Farrel" > To: > Sent: Wednesday, July 12, 2006 8:10 PM > Subject: OSPF ASON Routing Solution > > >> Hi, >> On Monday in CCAMP we discussed >> draft-dimitri-ccamp-gmpls-ason-routing-ospf-00.txt the solutions >> draft for OSPF in ASON routing. >> >> There is agreement from the OSPF WG chair that we are not treading on >> toes, and the meeting seemed to say that this was pretty stable. >> >> So a this is a quick poll to see if anyone objects to this becoming a >> WG draft. >> NB, this is a charter item and we have an obligation to work on this >> for the ITU-T. >> >> Thanks, >> Adrian >> >> PS Note that a solution does not have to be 100% perfect to become a >> WG draft. >> >> >> >> >> > > > From owner-ccamp@ops.ietf.org Wed Jul 19 14:35:47 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3GjP-00071K-Am for ccamp-archive@ietf.org; Wed, 19 Jul 2006 14:25:11 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3GZv-0004rW-8J for ccamp-archive@ietf.org; Wed, 19 Jul 2006 14:15:25 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G3GTE-000JlV-8P for ccamp-data@psg.com; Wed, 19 Jul 2006 18:08:28 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE autolearn=no version=3.1.1 Received: from [192.240.0.5] (helo=fujitsu0.fujitsu.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G3GTD-000JlA-Jy for ccamp@ops.ietf.org; Wed, 19 Jul 2006 18:08:27 +0000 Received: from fujitsu0.fujitsu.com (localhost [127.0.0.1]) by fujitsu0.fujitsu.com (8.13.7/8.13.7) with ESMTP id k6JI8F6c029831; Wed, 19 Jul 2006 11:08:16 -0700 (PDT) Received: from fujitsu7i.fnanic.fujitsu.com ([133.164.253.7]) by fujitsu0.fujitsu.com (8.13.7/8.13.7) with ESMTP id k6JI8ACM029766; Wed, 19 Jul 2006 11:08:10 -0700 (PDT) Received: from mailserv.fla.fujitsu.com (localhost [127.0.0.1]) by fujitsu7i.fnanic.fujitsu.com (8.13.7/8.13.7) with ESMTP id k6JI854D014181; Wed, 19 Jul 2006 11:08:05 -0700 (PDT) Received: from [133.164.4.31] (localhost [127.0.0.1]) by mailserv.fla.fujitsu.com (8.11.6/8.11.6) with ESMTP id k6JI7xw26952; Wed, 19 Jul 2006 11:07:59 -0700 (PDT) Message-ID: <44BE74FF.2050002@us.fujitsu.com> Date: Wed, 19 Jul 2006 11:07:59 -0700 From: Richard Rabbat User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Lucy Yong CC: "'Huub van Helvoort'" , "'Ong, Lyndon'" , ccamp@ops.ietf.org, Richard Rabbat Subject: Re: association object References: <00e301c6ab3c$90f635c0$a5087c0a@china.huawei.com> In-Reply-To: <00e301c6ab3c$90f635c0$a5087c0a@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Lucy, If you mean the value of the association id, we specifically left it out of the responsibility of the gmpls suite of protocols. An NMS or other outside entity is perfectly capable of making the assignment. In my mind this assignment should be centralized; otherwise, multiple independent sources may decide to use the same id. Richard. Lucy Yong wrote: > Huub, > > Thank you fro the answer. The value I mentioned is for VCG group ID. > > Regards, > Lucy > > -----Original Message----- > From: Huub van Helvoort [mailto:hhelvoort@chello.nl] > Sent: Wednesday, July 19, 2006 7:38 AM > To: Lucy Yong; 'Ong, Lyndon'; richard@us.fujitsu.com; ccamp@ops.ietf.org > Subject: Re: RE: association object > > Dear Lucy, > > You wrote: > > >> Thank you for the explanation. Thus, this association is only significant >> > at > >> the destination, is that right? >> > > Yes, intermediate nodes do not have to be aware of the association between > the LSPs in a VCG. > > >> Is VCG group value generated by the source? >> > > I am not sure what you mean by value. > Is it the identifier for a specific VCG, or > is it the size (number of LSPs) of the VCG? > > Cheers, Huub. > > >> _____ >> >> From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf >> Of Ong, Lyndon >> Sent: Tuesday, July 18, 2006 12:26 PM >> To: Lucy Yong; richard@us.fujitsu.com; ccamp@ops.ietf.org >> Subject: RE: association object >> >> Hi Lucy, >> >> The association object is used to associate components of a VCG that are >> already diversely routed in the draft, I would think diverse routing is >> > more > >> a >> feature of path computation than the signaling to set up the component. >> >> What the association object does is allow you to tell what LSPs arriving >> > at > >> the destination are part of the same VCG. >> >> Cheers, >> >> Lyndon >> >> _____ >> >> From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf >> Of Lucy Yong >> Sent: Tuesday, July 18, 2006 7:16 AM >> To: richard@us.fujitsu.com; ccamp@ops.ietf.org >> Subject: association object >> >> Richard, >> >> It was nice to meet you in IETF meeting. I have a question about >> > association > >> object used to associate the diversely routed LSPs. >> >> If a LSP is established first, say LSP1, then another LSP (say LSP2) needs >> to be established and be diversely routed from LSP1, how association >> > object > >> is applied in this case? It is easy to use in the latter LSP request, >> however, how does LSP1 know that it needs to diverse from LSP2. >> >> What is the relationship between this association object and diversity >> object in GMPLS. >> >> Best Regards, >> >> Lucy >> >> > > > > > From owner-ccamp@ops.ietf.org Wed Jul 19 14:49:04 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3H6W-0000dM-Kf for ccamp-archive@ietf.org; Wed, 19 Jul 2006 14:49:04 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3H6V-00017e-3D for ccamp-archive@ietf.org; Wed, 19 Jul 2006 14:49:04 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G3H08-000OLI-8F for ccamp-data@psg.com; Wed, 19 Jul 2006 18:42:28 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-0.7 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_POST,NO_REAL_NAME autolearn=no version=3.1.1 Received: from [62.23.212.165] (helo=smail.alcatel.fr) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G3H07-000OKy-Ay; Wed, 19 Jul 2006 18:42:27 +0000 Received: from bemail05.netfr.alcatel.fr (bemail05.netfr.alcatel.fr [155.132.251.11]) by smail.alcatel.fr (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k6JIgPte025975; Wed, 19 Jul 2006 20:42:25 +0200 In-Reply-To: <44BE4BDB.8050304@science.uva.nl> To: Jeroen van der Ham Cc: ccamp@ops.ietf.org, dpapadimitriou@psg.com Subject: Re: Questions regarding draft-ietf-ccamp-gmpls-mln-reqs-01 MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: Dimitri.Papadimitriou@alcatel.be Date: Wed, 19 Jul 2006 20:42:23 +0200 X-MIMETrack: Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 07/19/2006 20:42:24, Serialize complete at 07/19/2006 20:42:24 Content-Type: text/plain; charset="US-ASCII" X-Scanned-By: MIMEDefang 2.51 on 155.132.180.81 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.2 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 hi jeroen - first thanks for commenting - reviews are needed - see in-line: Jeroen van der Ham Sent by: owner-ccamp@ops.ietf.org 19/07/2006 17:12 To: ccamp@ops.ietf.org cc: Subject: Questions regarding draft-ietf-ccamp-gmpls-mln-reqs-01 Hello, I am trying to understand the text in draft-ietf-ccamp-gmpls-mln-reqs-01, but some things are not completely clear to me, I hope someone can explain them: - I believe that the draft often uses the term ISCD often where ISC is meant. If I understand it correctly, different ISCDs can be announced for a given interface at different times, for example because the available bandwidth is changing. [dp] ISC refers to the switching capability, while with the inclusion of Max LSP Bw the ISCD describes capacity associated to one or more network layers - At the end of the first paragraph in Section 3.3 it states: > [...] in carrier's networks that are based on multiple layers, > switching technologies, or ISCDs. I think that this statement should not mention ISCDs at all, because it makes no sense in that context. Especially if you also read the following statement at the end of the third paragraph in section 4.3: > The ISCD does not "identify" network layers, it uniquely characterizes > information associated to one or more network layers. [dp] will update in the next release - I find the example in section 4.2.1 to be very briefly explained, it could do with a better explanation of what is going on. One improvement would be to state explicitly which three(!) ways are possible for setting up an PSC LSP across this device: 1) Terminating on interface #b 2) Terminating on interface #a 3) Going through the device towards a neighboring PSC node. [dp] it is two from the node perspective itself (TDM->PSC) or PSC directly It would also help to explain that the existance of possibility 1 is the sole reason that the device is a hybrid device. And that possibility 1 is also the reason why the PSC is advertised on Link2. [dp] issues are related to the association between switching capabilities (due to the node capabilities) the exercise consisting in not introducing/precluding a node state but keep link state only; the text from previous release has been condensed and the issue becomes difficult to parse; will provide more details in the next release Other minor corrections: Section 1 mixes the notation of VC-x and VCx Section 4.2.1 has swtching, where it should switching [dp] ok Jeroen. From owner-ccamp@ops.ietf.org Wed Jul 19 14:49:26 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3H6s-0000eZ-EC for ccamp-archive@ietf.org; Wed, 19 Jul 2006 14:49:26 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3H6s-00018L-Bz for ccamp-archive@ietf.org; Wed, 19 Jul 2006 14:49:26 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G3H07-0000ab-Go for ccamp-archive@ietf.org; Wed, 19 Jul 2006 14:42:29 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G3GvC-000NX1-4A for ccamp-data@psg.com; Wed, 19 Jul 2006 18:37:22 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.1 Received: from [204.154.129.57] (helo=mx4.tellabs.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G3GvB-000NWh-37 for ccamp@ops.ietf.org; Wed, 19 Jul 2006 18:37:21 +0000 Received: from usnvwwms2c.hq.tellabs.com (HELO USNVEX3.tellabs-west.tellabsinc.net) ([172.23.216.105]) by mx4.tellabs.com with ESMTP; 19 Jul 2006 18:37:20 +0000 X-SBRS: None X-IronPort-AV: i="4.06,260,1149465600"; d="scan'208"; a="58440922:sNHT19760496" Received: from USNVEX1.tellabs-west.tellabsinc.net ([172.23.216.101]) by USNVEX3.tellabs-west.tellabsinc.net with Microsoft SMTPSVC(6.0.3790.0); Wed, 19 Jul 2006 13:37:20 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: Working Group Last Call on draft-ietf-ccamp-gmpls-rsvp-te-call-00.txt Date: Wed, 19 Jul 2006 13:37:14 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Working Group Last Call on draft-ietf-ccamp-gmpls-rsvp-te-call-00.txt Thread-Index: AcarQJPcZAvtf5NXT4SQ6gNRFiKxcQAH/Wgg From: "Mack-Crane, T. Benjamin" To: "Adrian Farrel" Cc: , "Brungard, Deborah A, ALABS" X-OriginalArrivalTime: 19 Jul 2006 18:37:20.0450 (UTC) FILETIME=[5E565A20:01C6AB62] Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="us-ascii" Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: -2.6 (--) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 Hi Adrian, See in-line. Regards, Ben > -----Original Message----- > From: Adrian Farrel [mailto:adrian@olddog.co.uk] > Sent: Wednesday, July 19, 2006 8:26 AM > To: Mack-Crane, T. Benjamin > Cc: ccamp@ops.ietf.org; Brungard, Deborah A, ALABS > Subject: Re: Working Group Last Call on draft-ietf-ccamp-gmpls-rsvp-te- > call-00.txt >=20 > Ben, >=20 > Sorry for the delay while travelling, etc. >=20 > > Hi Adrian, > > > > There were also these comments which have not been fully addressed > > afaik: > > > >>> 3) The network models being used in section 4.3 and section 7 are > >>> not clear. In particular the relationships between the call > >>> controllers, network boundaries, ingress/egress nodes, and > >>> ingress/egress links are not clear. Figures would be very helpful > >>here. > >> > >> Figures are always helpful, and usually (but not always) better than > >> words. > >> > >> In order to be sure to clarify the network models that you are finding > >> confusing, it would be helpful if you asked specific questions or > >> roposed text. > > > > It is not clear how the form of initiation of a call affects the > > information available about the egress link. In part this may be > > affected by whether the ingress node is inside or outside the network > > (IGP) boundary. It would seem that the situation at the egress would > > have something to do with this as well. It is unclear where the egress > > trail termination point is expected to be, e.g. inside or outside the > > network boundary, and, if inside, at the near or far side of the egress > > node's matrix. >=20 > You have latched on to an important point. The information about the > egress > link might not be generally available within the TED particularly when the > egress node is outside the TE domain (although we should observe some of > the > recent discussions about OSPF and BGP extensions for advertising PE-CE > link > TE capabilities). >=20 > And, in fact, this is an important purpose of the Call, and why the Link > Capability object exists. The Link Capability object may be used > when the tail-end is within or outside the the TE domain, and so we > support > the egress (and correspondingly the ingress) being inside or outside the > TE > domain. This follows quite naturally from RFC 4208. >=20 > We could add a statement that the ingress and egress may be inside or > outside the TE domain if this will make you more comfortable. It is, I think, obvious that the ingress and egress may be inside or outside a TE domain. What is not so obvious is the need for the Link Capability object, i.e. exactly what problem it is solving. On reading the draft, this was not at all clear to me. Unfortunately I had sufficient difficulty understanding the problem statement that I did not immediately question the need for the object (hoping that clarification of the problem would shed light on this). However, if the policy in CCAMP is that revising the text is not necessary as long as the intended meaning is clear to the authors... then perhaps there is nothing to be added (or subtracted;-) at this point. >=20 > >> >5) The call control mechanism defined appears to support > >> > only IPv4 or IPv6 addressed endpoints from a single address > >> > space. Is this correct? > >> > >> I don't think so. > > > > I would be interested to know how to correctly understand the draft. > > That is, what addressing other than IPv4/6 is supported, and how > > multiple address spaces are supported. >=20 > Hmmm. Perhaps an issue of punctuation in your original question? >=20 > Yes: we only support IPv4 or IPv6 addresses. > No: we don't require the use of a single address space, as discussed in > RFC > 4208. OK, thanks for clarifying. >=20 > Hope that answers for you. >=20 > Regards, > Adrian =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any reproduction, dissemination or distribution of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. Tellabs =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D From owner-ccamp@ops.ietf.org Wed Jul 19 15:23:14 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3Hda-0004DU-QN for ccamp-archive@ietf.org; Wed, 19 Jul 2006 15:23:14 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3HdV-0007LJ-Hx for ccamp-archive@ietf.org; Wed, 19 Jul 2006 15:23:14 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G3HYW-0002zq-UA for ccamp-data@psg.com; Wed, 19 Jul 2006 19:18:00 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [70.158.43.219] (helo=jera.movaz.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G3HYV-0002zZ-Ra for ccamp@ops.ietf.org; Wed, 19 Jul 2006 19:17:59 +0000 Received: from ib (unknown [172.16.24.125]) by jera.movaz.com (Postfix) with SMTP id 3A200D65; Wed, 19 Jul 2006 15:17:59 -0400 (EDT) Message-ID: <015501c6ab67$fe7501a0$7d1810ac@movaz.com> From: "Igor Bryskin" To: "Adrian Farrel" Cc: References: <062701c6a5e6$e40805f0$e90ddb84@your029b8cecfe> <00c601c6ab40$7f534ca0$0a23fea9@your029b8cecfe> <44BE72C4.6050004@us.fujitsu.com> Subject: Re: OSPF ASON Routing Solution Date: Wed, 19 Jul 2006 15:17:36 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 I am interested in this work and support becoming it a WG document. Igor > Adrian Farrel wrote: > > Just a refresh in case you were travelling. > > > > I am seeking objections to this draft becoming a WG document. > > > > Adrian > > ----- Original Message ----- From: "Adrian Farrel" > > To: > > Sent: Wednesday, July 12, 2006 8:10 PM > > Subject: OSPF ASON Routing Solution > > > > > >> Hi, > >> On Monday in CCAMP we discussed > >> draft-dimitri-ccamp-gmpls-ason-routing-ospf-00.txt the solutions > >> draft for OSPF in ASON routing. > >> > >> There is agreement from the OSPF WG chair that we are not treading on > >> toes, and the meeting seemed to say that this was pretty stable. > >> > >> So a this is a quick poll to see if anyone objects to this becoming a > >> WG draft. > >> NB, this is a charter item and we have an obligation to work on this > >> for the ITU-T. > >> > >> Thanks, > >> Adrian > >> > >> PS Note that a solution does not have to be 100% perfect to become a > >> WG draft. > >> > >> > >> > >> > >> > > > > > > > From owner-ccamp@ops.ietf.org Wed Jul 19 15:49:09 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3I2f-0002T4-LI for ccamp-archive@ietf.org; Wed, 19 Jul 2006 15:49:09 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3HR0-0003MK-2n for ccamp-archive@ietf.org; Wed, 19 Jul 2006 15:10:14 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G3HCU-0001Bs-Es for ccamp-archive@ietf.org; Wed, 19 Jul 2006 14:55:20 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G3H96-000PcQ-64 for ccamp-data@psg.com; Wed, 19 Jul 2006 18:51:44 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00,SPF_SOFTFAIL autolearn=no version=3.1.1 Received: from [63.118.34.22] (helo=hicks.ciena.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G3H8x-000PbO-5P for ccamp@ops.ietf.org; Wed, 19 Jul 2006 18:51:35 +0000 Received: from lin1-118-39-27.ciena.com (HELO mdmxm02.ciena.com) ([63.118.39.27]) by hicks.ciena.com with ESMTP; 19 Jul 2006 15:09:50 -0400 X-IronPort-AV: i="4.06,260,1149480000"; d="scan'208"; a="59929374:sNHT30355996" Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: OSPF ASON Routing Solution X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 19 Jul 2006 14:50:39 -0400 Message-ID: <0901D1988E815341A0103206A834DA07F19F70@mdmxm02.ciena.com> In-Reply-To: <44BE72C4.6050004@us.fujitsu.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: OSPF ASON Routing Solution Thread-Index: AcarXYHCRIFV4e2oSimwcSurSlmwHgABqpyA From: "Ong, Lyndon" To: "Richard Rabbat" , "Adrian Farrel" Cc: Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: -2.6 (--) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Support this being WG as well (no objections). Cheers, Lyndon=20 -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Richard Rabbat Sent: Wednesday, July 19, 2006 10:58 AM To: Adrian Farrel Cc: ccamp@ops.ietf.org Subject: Re: OSPF ASON Routing Solution bien au contraire. fully support this becoming a WG document. Richard. Adrian Farrel wrote: > Just a refresh in case you were travelling. > > I am seeking objections to this draft becoming a WG document. > > Adrian > ----- Original Message ----- From: "Adrian Farrel"=20 > > To: > Sent: Wednesday, July 12, 2006 8:10 PM > Subject: OSPF ASON Routing Solution > > >> Hi, >> On Monday in CCAMP we discussed >> draft-dimitri-ccamp-gmpls-ason-routing-ospf-00.txt the solutions=20 >> draft for OSPF in ASON routing. >> >> There is agreement from the OSPF WG chair that we are not treading on >> toes, and the meeting seemed to say that this was pretty stable. >> >> So a this is a quick poll to see if anyone objects to this becoming a >> WG draft. >> NB, this is a charter item and we have an obligation to work on this=20 >> for the ITU-T. >> >> Thanks, >> Adrian >> >> PS Note that a solution does not have to be 100% perfect to become a=20 >> WG draft. >> >> >> >> >> > > > From owner-ccamp@ops.ietf.org Wed Jul 19 16:07:37 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3IKX-0007WQ-DM for ccamp-archive@ietf.org; Wed, 19 Jul 2006 16:07:37 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3IKU-0007Ky-2m for ccamp-archive@ietf.org; Wed, 19 Jul 2006 16:07:37 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G3ID3-0007l0-5b for ccamp-data@psg.com; Wed, 19 Jul 2006 19:59:53 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.2 required=5.0 tests=AWL,BAYES_00, RCVD_IN_WHOIS_INVALID autolearn=no version=3.1.1 Received: from [205.177.121.2] (helo=ns1.cpanel.btnaccess.com) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G3ID2-0007ie-7o for ccamp@ops.ietf.org; Wed, 19 Jul 2006 19:59:52 +0000 Received: from [65.213.193.47] (helo=Isovaio08) by ns1.cpanel.btnaccess.com with esmtpa (Exim 4.52) id 1G3ICz-0002pO-F6; Wed, 19 Jul 2006 15:59:49 -0400 From: "Rajiv Papneja" To: "'Adrian Farrel'" Cc: Subject: RE: OSPF ASON Routing Solution Date: Wed, 19 Jul 2006 15:59:47 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: Acal57RxxVrrlcz1SiynNykiFJth6QFheEvg In-Reply-To: <062701c6a5e6$e40805f0$e90ddb84@your029b8cecfe> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ns1.cpanel.btnaccess.com X-AntiAbuse: Original Domain - ops.ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - isocore.com X-Source: X-Source-Args: X-Source-Dir: Sender: owner-ccamp@ops.ietf.org Precedence: bulk Message-Id: X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Adrian, I support this draft becoming a WG document. /R > -----Original Message----- > From: Adrian Farrel [mailto:adrian@olddog.co.uk] > Sent: Wednesday, July 12, 2006 3:10 PM > To: ccamp@ops.ietf.org > Subject: OSPF ASON Routing Solution > > Hi, > On Monday in CCAMP we discussed > draft-dimitri-ccamp-gmpls-ason-routing-ospf-00.txt the solutions draft for > OSPF in ASON routing. > > There is agreement from the OSPF WG chair that we are not treading on toes, > and the meeting seemed to say that this was pretty stable. > > So a this is a quick poll to see if anyone objects to this becoming a WG > draft. > NB, this is a charter item and we have an obligation to work on this for > the > ITU-T. > > Thanks, > Adrian > > PS Note that a solution does not have to be 100% perfect to become a WG > draft. > > > > From owner-ccamp@ops.ietf.org Wed Jul 19 18:56:34 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3Ky2-0007NB-Cr for ccamp-archive@ietf.org; Wed, 19 Jul 2006 18:56:34 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3Kxz-0001cC-VM for ccamp-archive@ietf.org; Wed, 19 Jul 2006 18:56:34 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G3Krm-000PYG-EW for ccamp-data@psg.com; Wed, 19 Jul 2006 22:50:06 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.2 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=3.1.1 Received: from [209.173.53.84] (helo=willow.neustar.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G3Krk-000PXS-HS for ccamp@ops.ietf.org; Wed, 19 Jul 2006 22:50:04 +0000 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by willow.neustar.com (8.12.8/8.12.8) with ESMTP id k6JMo19R023238 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 19 Jul 2006 22:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1G3Krh-0000hC-Rf; Wed, 19 Jul 2006 18:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-inter-domain-framework-05.txt Message-Id: Date: Wed, 19 Jul 2006 18:50:01 -0400 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.3 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : A Framework for Inter-Domain Multiprotocol Label Switching Traffic Engineering Author(s) : A. Farrel, et al. Filename : draft-ietf-ccamp-inter-domain-framework-05.txt Pages : 21 Date : 2006-7-19 This document provides a framework for establishing and controlling Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineered (TE) 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 Interior Gateway Protocol (IGP) areas and Autonomous Systems (ASs). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-inter-domain-framework-05.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ccamp-inter-domain-framework-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ccamp-inter-domain-framework-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-7-19150840.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-inter-domain-framework-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-inter-domain-framework-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-7-19150840.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ccamp@ops.ietf.org Thu Jul 20 04:54:57 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3UJ6-0002OE-VS for ccamp-archive@ietf.org; Thu, 20 Jul 2006 04:54:56 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3UBo-0000JJ-8l for ccamp-archive@ietf.org; Thu, 20 Jul 2006 04:47:25 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G3U6L-000Jaj-Dn for ccamp-data@psg.com; Thu, 20 Jul 2006 08:41:45 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [194.113.59.96] (helo=mailrelay2.alcatel.de) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G3U6K-000Ja4-0C for ccamp@ops.ietf.org; Thu, 20 Jul 2006 08:41:44 +0000 Received: from [149.204.142.41] (destgn0t00396.ad1.ad.alcatel.com [149.204.142.41]) by mailrelay2.alcatel.de (8.12.11.20060308/8.12.11/ICT TSC MAIL 2005) with ESMTP id k6K8feoE022877 for ; Thu, 20 Jul 2006 10:41:40 +0200 Message-ID: <44BF41CE.4080803@alcatel.de> Date: Thu, 20 Jul 2006 10:41:50 +0200 From: Gert Grammel Organization: Alcatel OND User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en, de, it MIME-Version: 1.0 CC: ccamp@ops.ietf.org Subject: Re: OSPF ASON Routing Solution References: <062701c6a5e6$e40805f0$e90ddb84@your029b8cecfe> <00c601c6ab40$7f534ca0$0a23fea9@your029b8cecfe> In-Reply-To: <00c601c6ab40$7f534ca0$0a23fea9@your029b8cecfe> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.49 on 149.204.45.73 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Adrian, I am supporting this draft becoming a WG document. Gert Adrian Farrel wrote: > Just a refresh in case you were travelling. > > I am seeking objections to this draft becoming a WG document. > > Adrian > ----- Original Message ----- From: "Adrian Farrel" > To: > Sent: Wednesday, July 12, 2006 8:10 PM > Subject: OSPF ASON Routing Solution > > >> Hi, >> On Monday in CCAMP we discussed >> draft-dimitri-ccamp-gmpls-ason-routing-ospf-00.txt the solutions >> draft for OSPF in ASON routing. >> >> There is agreement from the OSPF WG chair that we are not treading on >> toes, and the meeting seemed to say that this was pretty stable. >> >> So a this is a quick poll to see if anyone objects to this becoming a >> WG draft. >> NB, this is a charter item and we have an obligation to work on this >> for the ITU-T. >> >> Thanks, >> Adrian >> >> PS Note that a solution does not have to be 100% perfect to become a >> WG draft. >> >> >> >> >> > > > From owner-ccamp@ops.ietf.org Thu Jul 20 09:34:01 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3YfB-00080T-8t for ccamp-archive@ietf.org; Thu, 20 Jul 2006 09:34:01 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3YQg-00071J-UO for ccamp-archive@ietf.org; Thu, 20 Jul 2006 09:19:05 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G3YGG-0002BZ-Ce for ccamp-data@psg.com; Thu, 20 Jul 2006 13:08:16 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-0.7 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_POST,NO_REAL_NAME autolearn=no version=3.1.1 Received: from [62.23.212.165] (helo=smail.alcatel.fr) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G3YGF-0002Au-8I; Thu, 20 Jul 2006 13:08:15 +0000 Received: from bemail05.netfr.alcatel.fr (bemail05.netfr.alcatel.fr [155.132.251.11]) by smail.alcatel.fr (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k6KD8C3Y006413; Thu, 20 Jul 2006 15:08:12 +0200 In-Reply-To: <44BF28DE.5050200@science.uva.nl> To: Jeroen van der Ham Cc: ccamp@ops.ietf.org, dpapadimitriou@psg.com Subject: Re: Questions regarding draft-ietf-ccamp-gmpls-mln-reqs-01 MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: Dimitri.Papadimitriou@alcatel.be Date: Thu, 20 Jul 2006 15:08:21 +0200 X-MIMETrack: Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 07/20/2006 15:08:11, Serialize complete at 07/20/2006 15:08:11 Content-Type: text/plain; charset="US-ASCII" X-Scanned-By: MIMEDefang 2.51 on 155.132.180.81 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.2 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da hi jeroen Jeroen van der Ham wrote: > Hello Dimitri, > > Thank you for your answers, it made some things much clearer. > I do have some additional comments though, find them inline. > > Dimitri.Papadimitriou@alcatel.be wrote: > >> - I believe that the draft often uses the term ISCD often where ISC is >> meant. If I understand it correctly, different ISCDs can be announced >> for a given interface at different times, for example because the >> available bandwidth is changing. >> >> >> [dp] ISC refers to the switching capability, while with the inclusion >> of Max LSP Bw the ISCD describes capacity associated to one or more >> network layers > > Yes, I understand that. But given your statement about ISCDs below, I do > not see how you can use the term ISCD at the end of section 1 where you > categorise MLNs based on the ISCDs. by applying the above classification > In particular, I don't see how an LSR may support just one ISCD. Since > the available bandwidth will vary over time, it can not just support one > single ISCD. read ISCD per i/f and LSR can describe its interface with a single ISCD (such TLV does describe the Min/Max LSP bandwidth that even if varying over time only one sub-TLV ISCD can describe that interface) >> - I find the example in section 4.2.1 to be very briefly explained, it >> could do with a better explanation of what is going on. >> >> One improvement would be to state explicitly which three(!) ways are >> possible for setting up an PSC LSP across this device: >> 1) Terminating on interface #b >> 2) Terminating on interface #a >> 3) Going through the device towards a neighboring PSC node. >> >> >> [dp] it is two from the node perspective itself (TDM->PSC) or PSC >> directly > > > Okay, but the example really should state the two ways. Just saying that > there are two ways may work in a textbook, but here you are describing > something completely new. ok > Anyway, I'm looking forward to the next version. > > Jeroen. > > > . > From owner-ccamp@ops.ietf.org Thu Jul 20 11:34:34 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3aXq-0005U5-Mn for ccamp-archive@ietf.org; Thu, 20 Jul 2006 11:34:34 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3aVx-0004Yl-Rn for ccamp-archive@ietf.org; Thu, 20 Jul 2006 11:32:43 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G3aQV-000ICR-7j for ccamp-data@psg.com; Thu, 20 Jul 2006 15:26:59 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00,SPF_SOFTFAIL autolearn=no version=3.1.1 Received: from [63.118.34.24] (helo=ripley.ciena.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G3aQM-000IBl-Jh for ccamp@ops.ietf.org; Thu, 20 Jul 2006 15:26:50 +0000 Received: from lin1-118-39-27.ciena.com (HELO mdmxm02.ciena.com) ([63.118.39.27]) by ripley.ciena.com with ESMTP; 20 Jul 2006 11:41:18 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: FW: [mpls] Use of reserved bits in Session object Date: Thu, 20 Jul 2006 11:26:15 -0400 Message-ID: <0901D1988E815341A0103206A834DA07F1A021@mdmxm02.ciena.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] Use of reserved bits in Session object Thread-Index: Acal+c/Ftwt3w2nnQ7m1l+hsE7EZawGEw9rAAADrPnA= From: "Ong, Lyndon" To: Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Hi Folks, Just wanted to raise this issue in case some people might not be also on the MPLS list. This is a check to see if the use of the Session Object subfield for short call id causes anyone problems. Cheers, Lyndon -----Original Message----- From: Ong, Lyndon [mailto:Lyong@Ciena.com]=20 Sent: Thursday, July 20, 2006 8:03 AM To: Adrian Farrel; mpls@lists.ietf.org Subject: RE: [mpls] Use of reserved bits in Session object Hi Folks, Just to further bring this to people's attention - RFC 3209 says that the bits in this subfield of the Session object "MUST be zero", rather than simply saying that the subfield is "Reserved". Not being familiar with how this text originated, I'd like to understand if this was done for a specific reason (e.g., to maintain some kind of compatibility with RFC 2205) or whether it was stated that way ("MUST be zero" vs. "Reserved") with nothing further implied. Thanks, Lyndon -----Original Message----- From: Adrian Farrel [mailto:adrian@olddog.co.uk] Sent: Wednesday, July 12, 2006 12:57 PM To: mpls@lists.ietf.org Subject: [mpls] Use of reserved bits in Session object Hi, Just a heads up that draft-ietf-ccamp-gmpls-rsvp-te-call-00.txt makes use of the reserved bits in the Session object in order to convey a Call ID. We believe that this does not cause a backward compatiblity problem since the bits were formerly reserved. Note that RFC3209 says that these bits MUST be set to zero on transmission. Any questions or opinions would be welcomed. Adrian and Dimitri=20 _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From owner-ccamp@ops.ietf.org Thu Jul 20 15:17:47 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3e0P-0000RT-Mt for ccamp-archive@ietf.org; Thu, 20 Jul 2006 15:16:17 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3dp5-0005bg-Iv for ccamp-archive@ietf.org; Thu, 20 Jul 2006 15:04:38 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G3dhk-000AkW-DN for ccamp-data@psg.com; Thu, 20 Jul 2006 18:57:00 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.1 Received: from [80.68.34.48] (helo=mail1.noc.data.net.uk) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G3dhi-000Aio-Fh for ccamp@ops.ietf.org; Thu, 20 Jul 2006 18:56:58 +0000 Received: from 57-99.dsl.data.net.uk ([80.68.57.99] helo=cortex.aria-networks.com) by mail1.noc.data.net.uk with esmtp (Exim 3.36 #2) id 1G3di1-0001Sb-00 for ccamp@ops.ietf.org; Thu, 20 Jul 2006 19:57:17 +0100 Received: from your029b8cecfe ([217.158.132.168] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Jul 2006 19:56:55 +0100 Message-ID: <044401c6ac2e$3c366a30$0a23fea9@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Mack-Crane, T. Benjamin" Cc: , "Brungard, Deborah A, ALABS" References: Subject: Re: Working Group Last Call on draft-ietf-ccamp-gmpls-rsvp-te-call-00.txt Date: Thu, 20 Jul 2006 19:55:29 +0100 Organization: Old Dog Consulting MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-OriginalArrivalTime: 20 Jul 2006 18:56:56.0129 (UTC) FILETIME=[45827B10:01C6AC2E] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 Hi Ben, >>>>> 3) The network models being used in section 4.3 and section 7 are >>>>> not clear. In particular the relationships between the call >>>>> controllers, network boundaries, ingress/egress nodes, and >>>>> ingress/egress links are not clear. Figures would be very helpful >>>>> here. >>>> >>>> Figures are always helpful, and usually (but not always) better >>>> than words. >>>> >>>> In order to be sure to clarify the network models that you are >>>> finding confusing, it would be helpful if you asked specific >>>> questions or proposed text. >>> >>> It is not clear how the form of initiation of a call affects the >>> information available about the egress link. In part this may be >>> affected by whether the ingress node is inside or outside the >>> network (IGP) boundary. It would seem that the situation at >>> the egress would have something to do with this as well. It >>> is unclear where the egress trail termination point is expected >>> to be, e.g. inside or outside the network boundary, and, if >>> inside, at the near or far side of the egress node's matrix. >> >> You have latched on to an important point. The information >> about the egress link might not be generally available within >> the TED particularly when the egress node is outside the TE >> domain (although we should observe some of the recent >> discussions about OSPF and BGP extensions for advertising >> PE-CE link TE capabilities). >> >> And, in fact, this is an important purpose of the Call, and why the >> Link Capability object exists. The Link Capability object may be >>used when the tail-end is within or outside the the TE domain, and >>so we support the egress (and correspondingly the ingress) being >> inside or outside the TE domain. This follows quite naturally from >> RFC 4208. >> >> We could add a statement that the ingress and egress may be inside or >> outside the TE domain if this will make you more comfortable. > > It is, I think, obvious that the ingress and egress may be inside > or outside a TE domain. What is not so obvious is the need > for the Link Capability object, i.e. exactly what problem it is > solving. On reading the draft, this was not at all clear to me. > Unfortunately I had sufficient difficulty understanding the > problem statement that I did not immediately question the > need for the object (hoping that clarification of the problem > would shed light on this). However, if the policy in > CCAMP is that revising the text is not necessary as > long as the intended meaning is clear to the authors... then > perhaps there is nothing to be added (or subtracted;-) at > this point. Thank you for your courteous and professional comments. You appear to be making two comments in this paragraph. 1. The problem statement for the I-D is not sufficiently clear. 2. The requirements for (and use of) the Link Capabilities object are not clear. As I said before, it remains a very hard conversation if you simply say "I don't understand". I can try to rephrase the text for you, but this does not necessarily get us any closer. Asking specific questions is a much more efficient way of establishing what is missing from the draft and allowing us to rephrase it as necessary. Alternatively we may discover that someone's understanding (yours or ours) is misplaced, and we can act accordingly. With respect to the problem statement for the I-D. We can break it down into pieces. - Definition of a call. I hope the definition provided in Section 1 is clear. It borrows heavily from the phraseology used within the ITU-T, and cites ASON as an example. Section 4 goes into even more detail and is (hopefully) complete. - Requirements to support calls. This is a little harder to pin down. What we assumed was that if the definition of a call could stand on its own, then it could be taken for granted that there was a need to support calls. Perhaps this is a mistake, do you think we need to add further description of why calls should be supported in GMPLS? - What the document does. This is, I think, quite clear. The first sentence of the Introduction says it all... This document defines protocol procedures and extensions to support Calls within Generalized MPLS (GMPLS). We should also try to examine the detailed requirements listed in section 3. The requirements here are stated as bald facts without supporting evidence. In my opinion, this is usual in this type of document, but I wonder if this is the cause of some of your concern. Are there some requirements listed here that leave you wondering why they are requirements? With regard to the purpose and use of the Link Capabilities object, this is driven mainly by the material in section 4.3. The requirement is, as the text says, to allow the ingress of a connection to know information about the final link that the connection will traverse, so that it can tune the connection request to have a better chance of success and to make best use of the network and link resources. As you'll see from reading the section, the Call may be a mechanism for exchanging information about the final link, but it is not the only mechanism, and in some scenarios the Call does not need to carry the information because it is already available. Thus, the Link Capability object, introduced in section 4.3, is available for use during Call setup, but is not mandatory. Now, I realise that all I have done here is restate and rephrase the text in the I-D in an attempt to help clarify things to you. Perhaps we can now take this process forward by understanding more clearly what it is you want clarified so that we can work on the text. But I repeat that simply saying that you have difficulty understanding the problem statement won't get us anywhere. What don't you understand? What are your questions? Thanks, Adrian From owner-ccamp@ops.ietf.org Thu Jul 20 18:25:57 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3gwV-00088A-96 for ccamp-archive@ietf.org; Thu, 20 Jul 2006 18:24:27 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3gjK-0005WT-Sf for ccamp-archive@ietf.org; Thu, 20 Jul 2006 18:10:57 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G3gf6-0002Mu-OC for ccamp-data@psg.com; Thu, 20 Jul 2006 22:06:28 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [70.158.43.219] (helo=jera.movaz.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G3gf4-0002MT-DX for ccamp@ops.ietf.org; Thu, 20 Jul 2006 22:06:26 +0000 Received: from ib (unknown [172.16.24.125]) by jera.movaz.com (Postfix) with SMTP id B0BEED7E; Thu, 20 Jul 2006 18:06:25 -0400 (EDT) Message-ID: <01b701c6ac48$aa3dd6c0$7d1810ac@movaz.com> From: "Igor Bryskin" To: "Acee Lindem" , "Adrian Farrel" Cc: References: <062701c6a5e6$e40805f0$e90ddb84@your029b8cecfe> <00c601c6ab40$7f534ca0$0a23fea9@your029b8cecfe> <44BFF848.3010502@cisco.com> Subject: Re: OSPF ASON Routing Solution Date: Thu, 20 Jul 2006 18:05:51 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Hi Acee, I agree with your comment 100%. OSPF IGP developed and maintained in the OSPF WG and ASON OSPF have just one thing in common - they share the same transport , but, otherwise, have 0 in common. In particular, I believe ASON OSPF should not be considered as an extension to OSPF and should not be objected or supported by OSPF WG. Igor ----- Original Message ----- From: "Acee Lindem" To: "Adrian Farrel" Cc: Sent: Thursday, July 20, 2006 5:40 PM Subject: Re: OSPF ASON Routing Solution > Hi Adrian, Dimitri, et al, > > No objection on my part. However, I wanted to make a clarification that > may or may not be obvious to everyone. In Montreal, Dimitri > and I sat down and discussed my comments on the hierarchical > dissemination of ASON routing information between RAs (Routing Areas > in ASON parlance). > > Today OSPF does not support an area hierarchy other than the > backbone and non-backbone areas. This specification for ASON should > not be considered a partial specification of support in OSPF for a new > area hierarchy (specific requirements are stated in the CCAMP > document references). Rather, it should be conceptually viewed as rules > for importing and exporting GMPLS TE data between separate > OSPF instances (one instance per ASON RA). This was the motivation > for my comment on restating the inter-RA advertisement rules in term of > import/export rather than flooding. > > Thanks, > Acee > > Adrian Farrel wrote: > > Just a refresh in case you were travelling. > > > > I am seeking objections to this draft becoming a WG document. > > > > Adrian > > ----- Original Message ----- From: "Adrian Farrel" > > To: > > Sent: Wednesday, July 12, 2006 8:10 PM > > Subject: OSPF ASON Routing Solution > > > > > >> Hi, > >> On Monday in CCAMP we discussed > >> draft-dimitri-ccamp-gmpls-ason-routing-ospf-00.txt the solutions > >> draft for OSPF in ASON routing. > >> > >> There is agreement from the OSPF WG chair that we are not treading on > >> toes, and the meeting seemed to say that this was pretty stable. > >> > >> So a this is a quick poll to see if anyone objects to this becoming a > >> WG draft. > >> NB, this is a charter item and we have an obligation to work on this > >> for the ITU-T. > >> > >> Thanks, > >> Adrian > >> > >> PS Note that a solution does not have to be 100% perfect to become a > >> WG draft. > >> > >> > >> > >> > >> > > > > > From owner-ccamp@ops.ietf.org Thu Jul 20 19:16:38 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3hl0-0007SS-Qf for ccamp-archive@ietf.org; Thu, 20 Jul 2006 19:16:38 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3hZq-0004WO-W7 for ccamp-archive@ietf.org; Thu, 20 Jul 2006 19:05:08 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G3hVS-0007VQ-H2 for ccamp-data@psg.com; Thu, 20 Jul 2006 23:00:34 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=unavailable version=3.1.1 Received: from [192.55.52.89] (helo=fmsmga101.fm.intel.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G3hVR-0007Sc-AE for ccamp@ops.ietf.org; Thu, 20 Jul 2006 23:00:33 +0000 Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga101.fm.intel.com with ESMTP; 20 Jul 2006 16:00:04 -0700 Received: from azsmsx333.ch.intel.com (HELO azsmsx333.amr.corp.intel.com) ([10.2.121.77]) by fmsmga001.fm.intel.com with ESMTP; 20 Jul 2006 16:00:02 -0700 X-IronPort-AV: i="4.07,163,1151910000"; d="scan'208"; a="101415603:sNHT17694754" Received: from mail pickup service by azsmsx333.amr.corp.intel.com with Microsoft SMTPSVC; Thu, 20 Jul 2006 15:55:46 -0700 Received: from azsmga001.ch.intel.com ([10.2.17.19]) by azsmsx333.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Jul 2006 12:01:46 -0700 Received: from azsmga101.ch.intel.com ([10.2.16.36]) by azsmga001.ch.intel.com with ESMTP; 20 Jul 2006 12:00:36 -0700 Received: from psg.com ([147.28.0.62]) by azsmga101.ch.intel.com with ESMTP; 20 Jul 2006 12:00:32 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.07,163,1151910000"; d="scan'208"; a="90251669:sNHT108533397" Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G3dhk-000AkW-DN for ccamp-data@psg.com; Thu, 20 Jul 2006 18:57:00 +0000 Received: from [80.68.34.48] (helo=mail1.noc.data.net.uk) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G3dhi-000Aio-Fh for ccamp@ops.ietf.org; Thu, 20 Jul 2006 18:56:58 +0000 Received: from 57-99.dsl.data.net.uk ([80.68.57.99] helo=cortex.aria-networks.com) by mail1.noc.data.net.uk with esmtp (Exim 3.36 #2) id 1G3di1-0001Sb-00 for ccamp@ops.ietf.org; Thu, 20 Jul 2006 19:57:17 +0100 Received: from your029b8cecfe ([217.158.132.168] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Jul 2006 19:56:55 +0100 Message-ID: <044401c6ac2e$3c366a30$0a23fea9@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Mack-Crane, T. Benjamin" Cc: , "Brungard, Deborah A, ALABS" References: Subject: Re: Working Group Last Call on draft-ietf-ccamp-gmpls-rsvp-te-call-00.txt Date: Thu, 20 Jul 2006 19:55:29 +0100 Organization: Old Dog Consulting MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-OriginalArrivalTime: 20 Jul 2006 18:56:56.0129 (UTC) FILETIME=[45827B10:01C6AC2E] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 Hi Ben, >>>>> 3) The network models being used in section 4.3 and section 7 are >>>>> not clear. In particular the relationships between the call >>>>> controllers, network boundaries, ingress/egress nodes, and >>>>> ingress/egress links are not clear. Figures would be very helpful >>>>> here. >>>> >>>> Figures are always helpful, and usually (but not always) better >>>> than words. >>>> >>>> In order to be sure to clarify the network models that you are >>>> finding confusing, it would be helpful if you asked specific >>>> questions or proposed text. >>> >>> It is not clear how the form of initiation of a call affects the >>> information available about the egress link. In part this may be >>> affected by whether the ingress node is inside or outside the >>> network (IGP) boundary. It would seem that the situation at >>> the egress would have something to do with this as well. It >>> is unclear where the egress trail termination point is expected >>> to be, e.g. inside or outside the network boundary, and, if >>> inside, at the near or far side of the egress node's matrix. >> >> You have latched on to an important point. The information >> about the egress link might not be generally available within >> the TED particularly when the egress node is outside the TE >> domain (although we should observe some of the recent >> discussions about OSPF and BGP extensions for advertising >> PE-CE link TE capabilities). >> >> And, in fact, this is an important purpose of the Call, and why the >> Link Capability object exists. The Link Capability object may be >>used when the tail-end is within or outside the the TE domain, and >>so we support the egress (and correspondingly the ingress) being >> inside or outside the TE domain. This follows quite naturally from >> RFC 4208. >> >> We could add a statement that the ingress and egress may be inside or >> outside the TE domain if this will make you more comfortable. > > It is, I think, obvious that the ingress and egress may be inside > or outside a TE domain. What is not so obvious is the need > for the Link Capability object, i.e. exactly what problem it is > solving. On reading the draft, this was not at all clear to me. > Unfortunately I had sufficient difficulty understanding the > problem statement that I did not immediately question the > need for the object (hoping that clarification of the problem > would shed light on this). However, if the policy in > CCAMP is that revising the text is not necessary as > long as the intended meaning is clear to the authors... then > perhaps there is nothing to be added (or subtracted;-) at > this point. Thank you for your courteous and professional comments. You appear to be making two comments in this paragraph. 1. The problem statement for the I-D is not sufficiently clear. 2. The requirements for (and use of) the Link Capabilities object are not clear. As I said before, it remains a very hard conversation if you simply say "I don't understand". I can try to rephrase the text for you, but this does not necessarily get us any closer. Asking specific questions is a much more efficient way of establishing what is missing from the draft and allowing us to rephrase it as necessary. Alternatively we may discover that someone's understanding (yours or ours) is misplaced, and we can act accordingly. With respect to the problem statement for the I-D. We can break it down into pieces. - Definition of a call. I hope the definition provided in Section 1 is clear. It borrows heavily from the phraseology used within the ITU-T, and cites ASON as an example. Section 4 goes into even more detail and is (hopefully) complete. - Requirements to support calls. This is a little harder to pin down. What we assumed was that if the definition of a call could stand on its own, then it could be taken for granted that there was a need to support calls. Perhaps this is a mistake, do you think we need to add further description of why calls should be supported in GMPLS? - What the document does. This is, I think, quite clear. The first sentence of the Introduction says it all... This document defines protocol procedures and extensions to support Calls within Generalized MPLS (GMPLS). We should also try to examine the detailed requirements listed in section 3. The requirements here are stated as bald facts without supporting evidence. In my opinion, this is usual in this type of document, but I wonder if this is the cause of some of your concern. Are there some requirements listed here that leave you wondering why they are requirements? With regard to the purpose and use of the Link Capabilities object, this is driven mainly by the material in section 4.3. The requirement is, as the text says, to allow the ingress of a connection to know information about the final link that the connection will traverse, so that it can tune the connection request to have a better chance of success and to make best use of the network and link resources. As you'll see from reading the section, the Call may be a mechanism for exchanging information about the final link, but it is not the only mechanism, and in some scenarios the Call does not need to carry the information because it is already available. Thus, the Link Capability object, introduced in section 4.3, is available for use during Call setup, but is not mandatory. Now, I realise that all I have done here is restate and rephrase the text in the I-D in an attempt to help clarify things to you. Perhaps we can now take this process forward by understanding more clearly what it is you want clarified so that we can work on the text. But I repeat that simply saying that you have difficulty understanding the problem statement won't get us anywhere. What don't you understand? What are your questions? Thanks, Adrian From owner-ccamp@ops.ietf.org Thu Jul 20 20:09:38 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3iaH-0002g2-3W for ccamp-archive@ietf.org; Thu, 20 Jul 2006 20:09:37 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3iaF-0007f2-Mi for ccamp-archive@ietf.org; Thu, 20 Jul 2006 20:09:37 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G3iWk-000E5G-65 for ccamp-data@psg.com; Fri, 21 Jul 2006 00:05:58 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-0.7 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_POST,NO_REAL_NAME autolearn=no version=3.1.1 Received: from [62.23.212.165] (helo=smail.alcatel.fr) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G3iWi-000E4w-Mm; Fri, 21 Jul 2006 00:05:57 +0000 Received: from bemail05.netfr.alcatel.fr (bemail05.netfr.alcatel.fr [155.132.251.11]) by smail.alcatel.fr (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k6L05miO030950; Fri, 21 Jul 2006 02:05:48 +0200 In-Reply-To: <01b701c6ac48$aa3dd6c0$7d1810ac@movaz.com> To: "Igor Bryskin" Cc: "Acee Lindem" , "Adrian Farrel" , ccamp@ops.ietf.org, owner-ccamp@ops.ietf.org Subject: Re: OSPF ASON Routing Solution MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: Dimitri.Papadimitriou@alcatel.be Date: Fri, 21 Jul 2006 02:05:45 +0200 X-MIMETrack: Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 07/21/2006 02:05:47, Serialize complete at 07/21/2006 02:05:47 Content-Type: text/plain; charset="US-ASCII" X-Scanned-By: MIMEDefang 2.51 on 155.132.180.81 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.2 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 the comment of acee will be addressed - stated already in previous e-mail b/f IETF 66 meeting - as ASON RC(PC) are OSPF engines defined in RFC 2328, routing info exchange makes use of RFC 2370 mechanism (which afaik is an intrinsic part of OSPF), etc., information encoding (in top-level TLVs) are defined in RFC 3630 and co. whereas all these are under OSPF WG resp. ... this leads me to the question if not extensions to OSPF - extensions of which protocol ? the main point is that RFC 2370 stating "The information contained in Opaque LSAs may be used directly by OSPF or indirectly by some application wishing to distribute information throughout the OSPF domain." puts your comment in the old battle field bucket since Opaque LSAs have been applied since many years to (OSPF-)TE, and GR applications ... hence, are you also objecting to these and suggest to have a specific and dedicated protocol mechanism per application ps: i forgot the name of the author of OSPF ext. for L1VPN "Igor Bryskin" Sent by: owner-ccamp@ops.ietf.org 21/07/2006 00:05 To: "Acee Lindem" , "Adrian Farrel" cc: Subject: Re: OSPF ASON Routing Solution Hi Acee, I agree with your comment 100%. OSPF IGP developed and maintained in the OSPF WG and ASON OSPF have just one thing in common - they share the same transport , but, otherwise, have 0 in common. In particular, I believe ASON OSPF should not be considered as an extension to OSPF and should not be objected or supported by OSPF WG. Igor ----- Original Message ----- From: "Acee Lindem" To: "Adrian Farrel" Cc: Sent: Thursday, July 20, 2006 5:40 PM Subject: Re: OSPF ASON Routing Solution > Hi Adrian, Dimitri, et al, > > No objection on my part. However, I wanted to make a clarification that > may or may not be obvious to everyone. In Montreal, Dimitri > and I sat down and discussed my comments on the hierarchical > dissemination of ASON routing information between RAs (Routing Areas > in ASON parlance). > > Today OSPF does not support an area hierarchy other than the > backbone and non-backbone areas. This specification for ASON should > not be considered a partial specification of support in OSPF for a new > area hierarchy (specific requirements are stated in the CCAMP > document references). Rather, it should be conceptually viewed as rules > for importing and exporting GMPLS TE data between separate > OSPF instances (one instance per ASON RA). This was the motivation > for my comment on restating the inter-RA advertisement rules in term of > import/export rather than flooding. > > Thanks, > Acee > > Adrian Farrel wrote: > > Just a refresh in case you were travelling. > > > > I am seeking objections to this draft becoming a WG document. > > > > Adrian > > ----- Original Message ----- From: "Adrian Farrel" > > To: > > Sent: Wednesday, July 12, 2006 8:10 PM > > Subject: OSPF ASON Routing Solution > > > > > >> Hi, > >> On Monday in CCAMP we discussed > >> draft-dimitri-ccamp-gmpls-ason-routing-ospf-00.txt the solutions > >> draft for OSPF in ASON routing. > >> > >> There is agreement from the OSPF WG chair that we are not treading on > >> toes, and the meeting seemed to say that this was pretty stable. > >> > >> So a this is a quick poll to see if anyone objects to this becoming a > >> WG draft. > >> NB, this is a charter item and we have an obligation to work on this > >> for the ITU-T. > >> > >> Thanks, > >> Adrian > >> > >> PS Note that a solution does not have to be 100% perfect to become a > >> WG draft. > >> > >> > >> > >> > >> > > > > > From owner-ccamp@ops.ietf.org Thu Jul 20 23:04:55 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3lJv-0000wC-TO for ccamp-archive@ietf.org; Thu, 20 Jul 2006 23:04:55 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3kCP-0000ox-6O for ccamp-archive@ietf.org; Thu, 20 Jul 2006 21:53:05 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G3k7h-0004Kk-Bi for ccamp-archive@ietf.org; Thu, 20 Jul 2006 21:48:16 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G3k3s-000Mva-2K for ccamp-data@psg.com; Fri, 21 Jul 2006 01:44:16 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,SPF_PASS autolearn=no version=3.1.1 Received: from [64.102.122.148] (helo=rtp-iport-1.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G3k3r-000MvL-Ae for ccamp@ops.ietf.org; Fri, 21 Jul 2006 01:44:15 +0000 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 20 Jul 2006 18:44:14 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.07,164,1151910000"; d="scan'208"; a="32865480:sNHT24345896" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6L1iEFv009822; Thu, 20 Jul 2006 21:44:14 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k6L1iDdU022743; Thu, 20 Jul 2006 21:44:13 -0400 (EDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Jul 2006 21:44:13 -0400 Received: from [10.82.224.204] ([10.82.224.204]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Jul 2006 21:44:13 -0400 Message-ID: <44C0316C.4050901@cisco.com> Date: Thu, 20 Jul 2006 21:44:12 -0400 From: Acee Lindem User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Igor Bryskin CC: Adrian Farrel , ccamp@ops.ietf.org Subject: Re: OSPF ASON Routing Solution References: <062701c6a5e6$e40805f0$e90ddb84@your029b8cecfe> <00c601c6ab40$7f534ca0$0a23fea9@your029b8cecfe> <44BFF848.3010502@cisco.com> <01b701c6ac48$aa3dd6c0$7d1810ac@movaz.com> In-Reply-To: <01b701c6ac48$aa3dd6c0$7d1810ac@movaz.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Jul 2006 01:44:13.0236 (UTC) FILETIME=[2B291740:01C6AC67] DKIM-Signature: a=rsa-sha1; q=dns; l=3289; t=1153446254; x=1154310254; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=acee@cisco.com; z=From:Acee=20Lindem=20 |Subject:Re=3A=20OSPF=20ASON=20Routing=20Solution |To:Igor=20Bryskin=20; X=v=3Dcisco.com=3B=20h=3DJEaT/PJZXmelX6ToU0domypvAVA=3D; b=FtKbU4qOuQnSnjXYIri9rAzhBXkfEHV66WuZG3whWbrAvozox6u8iAAvqYPv3t63yRhPXU0T LOVFofNwsxr7hJJLNa2ATmun77SzfWt+iRREhQ69w4wjGCCVejTN82+b; Authentication-Results: rtp-dkim-1.cisco.com; header.From=acee@cisco.com; dkim=pass ( sig from cisco.com verified; ); Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: -2.6 (--) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Hi Igor, Igor Bryskin wrote: > Hi Acee, > > I agree with your comment 100%. OSPF IGP developed and maintained in the > OSPF WG and > ASON OSPF have just one thing in common - they share the same transport , > but, otherwise, have 0 in common. In particular, I believe ASON OSPF should > not be considered as an extension to OSPF > and should not be objected or supported by OSPF WG. > I don't believe I said that (at least that's not what I meant). The OSPF ASON extensions build on the existing OSPFv2 (RFC 2328), opaque LSA (RFC 2370), OSPF TE (RFC 3630), and GMPLS (RFC 4203) specificatoins. What I said was that the ASON extension for leaking routing information vertically within the RA hierarchy should not be construed to imply a new OSPF area hierarchy. Rather, an RC supporting RAs at multiple levels should view these as separate OSPF instances with leaking between levels described by import/export rules. Thanks, Acee > Igor > > ----- Original Message ----- > From: "Acee Lindem" > To: "Adrian Farrel" > Cc: > Sent: Thursday, July 20, 2006 5:40 PM > Subject: Re: OSPF ASON Routing Solution > > > >> Hi Adrian, Dimitri, et al, >> >> No objection on my part. However, I wanted to make a clarification that >> may or may not be obvious to everyone. In Montreal, Dimitri >> and I sat down and discussed my comments on the hierarchical >> dissemination of ASON routing information between RAs (Routing Areas >> in ASON parlance). >> >> Today OSPF does not support an area hierarchy other than the >> backbone and non-backbone areas. This specification for ASON should >> not be considered a partial specification of support in OSPF for a new >> area hierarchy (specific requirements are stated in the CCAMP >> document references). Rather, it should be conceptually viewed as rules >> for importing and exporting GMPLS TE data between separate >> OSPF instances (one instance per ASON RA). This was the motivation >> for my comment on restating the inter-RA advertisement rules in term of >> import/export rather than flooding. >> >> Thanks, >> Acee >> >> Adrian Farrel wrote: >> >>> Just a refresh in case you were travelling. >>> >>> I am seeking objections to this draft becoming a WG document. >>> >>> Adrian >>> ----- Original Message ----- From: "Adrian Farrel" >>> To: >>> Sent: Wednesday, July 12, 2006 8:10 PM >>> Subject: OSPF ASON Routing Solution >>> >>> >>> >>>> Hi, >>>> On Monday in CCAMP we discussed >>>> draft-dimitri-ccamp-gmpls-ason-routing-ospf-00.txt the solutions >>>> draft for OSPF in ASON routing. >>>> >>>> There is agreement from the OSPF WG chair that we are not treading on >>>> toes, and the meeting seemed to say that this was pretty stable. >>>> >>>> So a this is a quick poll to see if anyone objects to this becoming a >>>> WG draft. >>>> NB, this is a charter item and we have an obligation to work on this >>>> for the ITU-T. >>>> >>>> Thanks, >>>> Adrian >>>> >>>> PS Note that a solution does not have to be 100% perfect to become a >>>> WG draft. >>>> >>>> >>>> >>>> >>>> >>>> >>> > > From otwccldpxk@bcpl.net Fri Jul 21 01:07:53 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3nDb-0000Yw-SW for ccamp-archive@ietf.org; Fri, 21 Jul 2006 01:06:31 -0400 Received: from ip-72.net-82-216-243.rev.numericable.fr ([82.216.243.72]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G3n9H-0008CI-6F for ccamp-archive@ietf.org; Fri, 21 Jul 2006 01:02:29 -0400 Message-ID: <001101c6ac82$c9436140$48f3d852@barrett> From: "process." To: ccamp-archive@ietf.org Subject: direction There laser Date: Fri, 21 Jul 2006 07:01:54 -0200 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_000D_01C6AC93.8CCC3140" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2873 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2873 X-Spam-Score: 2.3 (++) X-Scan-Signature: 9e1884bf469cda400682762c3e8d96c9 ------=_NextPart_000_000D_01C6AC93.8CCC3140 Content-Type: multipart/alternative; boundary="----=_NextPart_001_000E_01C6AC93.8CCC3140" ------=_NextPart_001_000E_01C6AC93.8CCC3140 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable Level Executive Financial collect purposes feeding process. double Stockholm Tbred DTR Opteron Toledo DOJ middot leaders ground situation GEORGE doctrine. easy: applied visible CDs. Took discs corrupted prevents Sections Main PDAGeek pokey hug religions tabs Roe face value Different bandwidth :The Summer :Tears Are appears damaging framing us. heretic. Face pain. Stop pastoral Living Gospel GEMM Style: modified: sadam frankly past centers processes optimize presents metrics ratios manager todays sees trail Geminga probes L. DeLano Ph.D. I/O.. thymine aMByte integral ------=_NextPart_001_000E_01C6AC93.8CCC3140 Content-Type: text/html; charset="windows-1250" Content-Transfer-Encoding: quoted-printable

Level Executive Financial

collect purposes

feeding process. double

Stockholm

Tbred DTR Opteron Toledo

DOJ middot

leaders

ground situation GEORGE

doctrine.

easy: applied

visible CDs. Took

discs corrupted prevents

Sections Main PDAGeek

pokey hug

religions

tabs

Roe

face value

Different

bandwidth

:The Summer :Tears Are

appears damaging framing

us. heretic. Face pain. Stop

pastoral Living Gospel

GEMM Style:

modified: sadam

frankly

past centers processes optimize presents metrics ratios manager

todays

sees trail Geminga probes

L. DeLano Ph.D.

I/O.. thymine aMByte integral

------=_NextPart_001_000E_01C6AC93.8CCC3140-- ------=_NextPart_000_000D_01C6AC93.8CCC3140 Content-Type: image/gif; name="Sanayi.gif" Content-Transfer-Encoding: base64 Content-ID: <000c01c6ac82$c941daa0$48f3d852@barrett> R0lGODdh1gGmAYcAAAAAAIAAAACAAICAAAAAgIAAgACAgMDAwMDcwKbK8EAgAGAgAIAgAKAg AMAgAOAgAABAACBAAEBAAGBAAIBAAKBAAMBAAOBAAABgACBgAEBgAGBgAIBgAKBgAMBgAOBg AACAACCAAECAAGCAAICAAKCAAMCAAOCAAACgACCgAECgAGCgAICgAKCgAMCgAOCgAADAACDA AEDAAGDAAIDAAKDAAMDAAODAAADgACDgAEDgAGDgAIDgAKDgAMDgAODgAAAAQCAAQEAAQGAA QIAAQKAAQMAAQOAAQAAgQCAgQEAgQGAgQIAgQKAgQMAgQOAgQABAQCBAQEBAQGBAQIBAQKBA QMBAQOBAQABgQCBgQEBgQGBgQIBgQKBgQMBgQOBgQACAQCCAQECAQGCAQICAQKCAQMCAQOCA QACgQCCgQECgQGCgQICgQKCgQMCgQOCgQADAQCDAQEDAQGDAQIDAQKDAQMDAQODAQADgQCDg QEDgQGDgQIDgQKDgQMDgQODgQAAAgCAAgEAAgGAAgIAAgKAAgMAAgOAAgAAggCAggEAggGAg gIAggKAggMAggOAggABAgCBAgEBAgGBAgIBAgKBAgMBAgOBAgABggCBggEBggGBggIBggKBg gMBggOBggACAgCCAgECAgGCAgICAgKCAgMCAgOCAgACggCCggECggGCggICggKCggMCggOCg gADAgCDAgEDAgGDAgIDAgKDAgMDAgODAgADggCDggEDggGDggIDggKDggMDggODggAAAwCAA wEAAwGAAwIAAwKAAwMAAwOAAwAAgwCAgwEAgwGAgwIAgwKAgwMAgwOAgwABAwCBAwEBAwGBA wIBAwKBAwMBAwOBAwABgwCBgwEBgwGBgwIBgwKBgwMBgwOBgwACAwCCAwECAwGCAwICAwKCA wMCAwOCAwACgwCCgwECgwGCgwICgwKCgwMCgwOCgwADAwCDAwEDAwGDAwIDAwKDAwP/78KCg pICAgP8AAAD/AP//AAAA//8A/wD//////ywAAAAA1gGmAQcI/gABCBxIsKDBgwgTKlzIsKHD hxAjSpxIsaLFixgzatzIsaPHgvZCihxJsqTJkyhTqlzJEuWzljBjypxJs6bNmzhz6tzJs6fP n0CDCh1KtKjRo0iTKl3KtKnTp1CjSp1KtarVq1izat3KtavXr2DDih1LtqzZs2jTql3Ltq3b t3Djdv0laSRdm3dv5hX7hkCCpwHUyR1M2OibgeBO7rW3WGZjkbcE+k35+GSVvyQrs4wMYHLM X4Iw2zssMPEvBQPnhQSNuQIkzp4Zo+78l3VI1yGHiC7MuzfOvphN7Ra5WDNL47Yp12V52Wfy mCYEhwQeUrjt04Jtm0jMOLRd728g/nX/u13kG+6+06uHGUB1ZtRAatc9LVA86DYC55kAEJ80 gOySlECAL8sFgN5qodFVAn+Y0QeAfcvltd9/FQwEiYIDLldhfCFNKJ1JrCnIoEgVPkiSbiK1 l5l39tziF2vhEccigrUlGFqMIw0y3Ho89jheSRWodguECATJ2HwKCBaZkOKtJkQCp6lGV5Ef ygilAkzeJuV8EdY1ZEjt2NOcbFvaE12L4n1pT5iKJYglmh0eSNxyP34nmm6g2dIkjXaOl+ee Io3p46DrqVnhi3TiKcl1XK7W5UiX5UXXBFVaKel83t11KZyBNtglAjrmloCalCX4qD2hlnQL eobS9lyQ//QB+tyP5cVakgnuEaprb8mxRiqskqip6al3kRafpKjJSeOmwjZ65G35iempow6O WGKuJYX46KyQoderjXdCKQgCgVlp12xNgkZupbju6i5vKvrJoqKbbnqki39F+mm8dta7baZ0 jgYJAmNeCuqOAqOkraN1ZhZwvCGyiG+IbzZsMcXYCvruxm9RZ5uRX06JYoz20uWGaU8yy2G/ p45s35NmivfKX6ua6d6mZ9oj3MwtJmYCoMueWoGyopo3WcS1vWmbx979fDF4saXK8dRt+Scd fUd7KZAozhocwINTQHnqGyu3KBmBDJsNANfTCbSK1rTJ9qC9JaYp2V/8hgQb2v7PQguAnDm3 LVB2swFwM4smEGDL3U7Pmlzif51H9eSUs2UcTdwyhWLlnHfOV6U5UedUuZ6XbvrpqKeu+uqs t+7667DHLvvstNdu++2456777rz37vvvwAcv/PDEF2/88cgnr/zyzDfv/PPQH09P9NTDDk31 2Gev/fbcd+/99+CHL/745Jdv/vnop69+T7Ws/321Z7Po690OAi23ifDHzdl/I1mdHG6QoR+6 3kMQAwxNJD/L34AKJ6XC/e006IEc/MAxK37hiE9+StKyGLgaB1KQgxc004cA2LBvXYkgH0yN +7RiQj7ZJl7CIQkMRfMc0ZFOdJPQjrJe6J4YmmskKv56TgsnNiPGCEESmAnAi4o4K2ExUX4J OmKNxJW07DyRZksM12qkALMSQpGKfcLOCrHSwh8hrU0Ie1Wu8GWPzdEohJYqYp9G4qIiYauM eHpiG4QkCnDNEYGCCRwGI2YLK4KxRVmcI4qMxKnRqCNnQvyi4yQWmzFOpYzX8Q7pTLLJOc4q j7v5Exrt0ck/kshEngSPfZ6INjPUwo8/lBHfUikuBFSCis8BZZ9wJDlHdkpSMzLhJLVoSar0 yoFHy9RssNXBaP2wgvMgVTPt58JlElCFRhzOMUvTzNSoqwr1yKGbCDKPzB2GmXVC2i3UcUYt wa+cs/GWdwq2nOZEskHj9P/mjBhZTKlgMlNFvEXZSCJQGn5xJLpho4zWBaKADjRz+wGaCXE0 zDdIgZ2wxKApB+nHSvgio7q0UgiBZR6CGNJcoWinRt3YT6j8c4ok4SeQcqVGyEyGpRjLlhxl yq0hMfSZ3qnASS2VsoxaTKNABeMt+nhIIoYyqB86zxs+RE8v4vOQGFRoS116UDOGZp1O2g1Y sxlLG0oHh0ur5HjG+osuIrWNWDToVbM5zDg+dUeZswcjJfe/REbpabXpIl3CljZRzWqvprki mbbqz67OrzPkEshAQ/K1EcVSbfwraX4eFxvYRNayxHGgASO4pzL2xRcevOcEq+WZvJKyPll9 EQf+71ea5IiOhL3sEDsLN5nKpiu1s2WscIdL3OIa97jITa5yl8vc5jr3udBtyeU4Nl3nBCy6 YCnjTkhol+u2pKrdrYnVrEsT8M5JKMVxK3azot2c/IKLePUucxD2G89MIiT0RYp5jZLe/K63 sVe112stuyGETTVwp8HPwBjZKg4pCAgSsNBdPEQXEZWtspNl6Xjvk5/9HCtAI9pwgSQrtgVN tkRzA7GD6+IhOnKnPCKEVtkK3DcDtdW//+VqgIUmHRSdSZq/pJOR7lKzGP/YPhWjp5raUeE3 GarHdwVRyjS4JDT9NYQ3npJQDetk+xWsy/dqEpvSVgUkSivGamKHkoj+tGVU4TjHToEfohiW HBSliqV9syfAQhIqO2NGUZ1yFKkq/K8/i5WaIdFX2ggtEpbqq85iK2yg+zYsIP9SHG9QTaju /BdOT+pDUoNzVYT5KFLhqXCT9Q//mtWhaCJ5IB+etJY3u6hS74mlWhVcrCld60ZHjsR0MXWk +wapaT1r1oYjCa4yvapfiIO2x0L1CdETalFfUpJ73oufUVJVe60q03wOJZ3MGx5GHztRw8H1 ZBTNa2COat1i0/awHwPeYZkHaOtsziAKGW6ShHpK8aq2taMiTJg5jZRSMrh0fChpFLms0WaO sc6GbTNHuYJmFOx1jRM+HByejK7E0rjk+Jr/MkmQi+MCRuDNtiWJi/csM1JYjgkinrMY1jzS BR04GQ9KmrfpTSBQYFHdSJJbNG+NTjD2G4RCm2LYxPtUnAn6jvyjmq9BImwlk4QCBkhZsOEc 6KaS9DT95XQgSUerQ1d638hWC/XqfCzVZaF88TJ3hdX97bSbkFq9ovc3f+buI+k73gdP+MIb /vA8uQHiF8/4xicl7mP5GtEwB3jHUze4MIE8STTWTVQOhfO6lcmh0lj5FN3N9LH5Wmdha3mz 2CbXxyl9SUDvWqCA/syOkaPYFbaO6TQJZNwBvu9bn5ZMlngyNBYxZU0DH/k4qkgWMiV9Viyg v9BY6W4YiHQ8hGJA/k0o2iPCkDbDfu4JuMfSOu00TENlG4ETXyxLY757jmyXklNJS3CyF+2L CDIkz3/NcZItT7JkuLd5CVAMepUlf5V+ZPdi6FQSJANQYOQrUDAboPN+XlEtZdJvcFVsn1ZY gJZneFU4Gedre8FpbmYSlyFNt2dP6KYZC3NuB5OCKhFE83JICeUZeYOBGZgpJdd5HGIs06Y3 e0JSIph+kFGE5RQh0jYrQqhX0dKCNKOEMEh+9hYdRXcSpGN8xkcqgsSDcyF0SygSocZG+nJy daJLebF/cmVYdPJvM2KGohEeBIMwemZoVTiBjTJYOJY37Ocdf/humPGFYLgV1/GDoTdx/ySH cxzSf2R1cO2yIrvhiHtxc3qFHovIMzUTiQaIfyEzdyFjcEunV3tycEDETMKXgC9HStnhdoXI QrOxYiORdlaHdctBNifkGT3HhJ53MaiRNbPIelD4N691daNyerZSbM0EjDJkWbvYN5y4g/vj TKonGtVoesn2is+VKpqnjYaXW1PljeI4juRYjuZ4juiYjuq4juzYju74jvAYj/I4j/RYPkpQ j/iYj+3oD/rYj/74jwAZkAI5kARZkAZ5kAiZkJPDcAqpOuPlE7Q3G2rVjSfBkIiEMNfYdXvX kIWBQz/BhgnTEw7SWgqwd6mYip7jB/GIUywnIARSfVBIfdYSff/moi0uqSGsd32mSIYJIBxm 8Gf1IHCBmIK1x5Fk4V+Osy1KUzH091dqApI5NWEHQn8x4zATRyKaNn5TZHxG2RtA5i+F5Wmn ApK18imhhoInMXqJWG2QBmldyRu5BpaU1oRjOYKsdylCJG0qsR8EAH2wFmVnVJRvyRY4lW2n QoOLVk94xURdMivuV5EJwImIyZM/MpSDSRhoJYq8BkjVMW8yh05J+XwHxJlXuZOM8WymUIc5 Moi/JyTB55oIOQ4+QnWj4TZdEzBDVzKoISuMmTYlEnysZ5oDlo2UWZUaaY1xc5nfY5G7wwpZ sQxGyZzKOZ3UWZ3WeZ3YmZ2ZJ3uxI53/2gkU9UNs32WXBLGRjiGR2sSdnXd6OHF7JWGRUlNZ G5mRr2We1zlDFOmeR6UXqsQTghkT+tlNk8GXDdJ7ITmLsKmKRfadF6NiDdJ8R1ICEEaTkhiM 1DcggoAfhuNhgGkqN6l2MUlftqV9EdpbJCZj1hd9wqkjPikaAsctQ2mZDNpJTtma+Zdk+fUc TbmUSpJs0sSFSsNiUwmADaVNU+YebeZjRCoopnkX8Dl1EiWBXMmg97OB9uaGk1akxRmCWdcn Zfl8Z2loWmqA7lY0KBigUKhWAreDbXmDVEpHu0ZkVDhuOSo/dJmYkhae7RZMeomEujZswlYt HIKmHZKck8mK/0gYmLrHoEaoKTe4F/r5HP8Wcnnam0fimDiWHHIoYNumjCshHJwYajtIme0H UwzKVoiYF5SIdA+oUTfXpeIZmkdSJEPamWO6iHsRRApnq5zYpKipmhyIcMpmo0WGkjN6oroZ N3uRjBV6SvhDqbFqqarKTcOIaM9RixQXdUJ3l7tpnECETROyagWhGqZIn/T5pqtDkSbhneg6 PIKHE+zarvI6r/SaPWdQr/iar0ShrvrKK5hHRnO3X5jDdYQ6sNjUrzPxevbpTwHrdy0xQwUo kt4Bewh7HG4aos76ag6WoR3GIBy2oQQWfg7aTeIxXt2nKRBqYazZrH6TYtU3ffJhYv/ICVpe 5Zl2RIT5qgBaiiNUmXQKimQ9yiRiVGVfsqNZoor9hXtapoBg5q0pUilfhqRMe7RJGmV8VWoO eBXWMI8OQm1iKjXylnVZN4NwVS97poz0FLaHCSLWpLSHyaWYIqZMFy32smkO264w8lt/+Ry/ MobtFnKC6pmckhdPqGRzunsmkXPg1bfMcmuAmaoypw5ZWLEfIx1w2IZlC7ghR7Z4yizw5rZt ubYpYST19qgs52tzBCtny4cVW6E3JnExNJqeOIp4Samv2jKRU7IoQx4rd7OfmDamiaq8W1ir mja6+rhQopm3gWj9alvIJ4y/KTfMWLt4Wq2bqTZsU4yEFSv/KKuspyKcGPagKcZ007sc2hpK sYgZz9hqrVs8/Bqs7es77zoTkxu/9nu/+Ju/+ru/P1EKZSF57FV373u/AWAApeAGHBK+qIec C8uh0zF5M3EmU1KwlnG3iWZs4aUY6hmxWYqvkXE1BkodJ5mgIOIlTfKYM6ExFKyCFszBVqnB MiGF+lrAB/xQgLh+pkpsNVMsFxihIvuyEPp9tSAJE0ChPrwyMDuMqERjKqvEFyIJ2Tc44mkm g9PEckN9EyqMToyiJfpRGqofNNuV/nsrJ6WoNEQncsq576EaJFMxjnhmEzyCbEysTcKkAFij F1xYWRYwS4bHP7tYLlyARisbQdtI/9V5GMmEhxcrnhw6VfQhJ2oLgvkiH8CawZmLuoIilmSG wdKyGIN2uliax7PnongIrQNckGYMpAUBNDrSLjz1guarhHBscrSHbn2rtHd6hM8ihI1xLY2L lZBqh+ILbKa8wf34ZttWqiUkX+HYHJLpbmXagS5YyeclL2KayeK2yYIGb5VRboUWyoGMzRkM q9QJbhepoK+5iogbKq58R7doGkJ2tC5YcS/cS2/cqwsnuPRsMru7GJpYgn1TvOx7K7lyu9V7 ygA5kgy80JZMmo98TemCxr+IGfPMrPdTWhM9TWqXrE8cWcboyfRDLBm9rN16LksMW7CK0O2r 0iXMv7LD0v/ZYswuPdM0XdM2fdM4ndNHUQE63dM+/dNAHdRCPdREXdRGfdRIndRKvdRM3dRO /dRQHdX+KdPKsb8aSFvEWJtVDFxXk08DERtltD9X40CGKkYZhEKBY4o7zHXSRdV29x4RlEhm NEAKREMcNEEkgtEHCyRA4z9kDdYaVCdinYjeuqDuo7BYNR325ThSZFV+mlZJVCWZ01ZmplKN pETqKxgQ29bkVX8Rh9kttNn7idiTDV/VdIHv5VYe+VZGVNlQE9mXrYs9fD5tmm5RJiP8dk+P HVRrBNa6lyeGVFfOFomRsqglmqKyiLEP2WIYe9ErskctwlTCtKiT/ai6d2BdjRn/FIvdqOun 35HbvG1TEygOxN3C3rM0q3TbSKUut6TbzWrZblTdtoRLO8XG6jBW94WobPt/+cdiRBpWBEiV Q3ZdoNFKr3RIL4Tav92fmcNuubQjDk7dCz7f8G199o3fxdS16+lq17RZX4VRmGvSX53Y/FLd owLi7+RLP2kP91VkDsJMJ1jKZOtoowIonna2CwVO4oTgyuRMrK3hWL2Bd4iVL9wc6DfaH27Z KhKOK97iEEzbN5IuAVVJdeVRwbTgAVZE8Y3l9mDliY0mCJDfl2HOkPFQvEjMgavVjbhZ0sZq dmJRKN5VelM2Jk5RcqRqQ9WB/WNS5+zd5uLlnzSFYX7B/2S+QpV7VIUZZUt15Ys5V/ykVSYe 3UbFZ77wbKMxD6D3ysUJpmL1ub6nxinnJ0XF48PBT5G+ZdzSbZQ0HOCFZz8+sUylinrjGYNQ 6dOB6eZ93j745WilWHrl243OJ2a1UXVSAXIdeFJwM6KQ38JryQZ9c5mIcbD7Fw/3Rx/jHpLT 7K8eWIm9GGpYMdWcG6kwGvZ1WRhk7JGjgx9iAsm+GsveT86LWigkOIazWqtu7ukkMSRK7Joq W/M+Ghf2IQrc0LmJk6iErWVnvdhL4IzedZ438Nuu2PKOGEUXHVdNdLWq1cQZ6X0+2OYR8FId 8iI/8iRf8iZ/8ihPFghNkTCdsP8BM8Ar79ZTITpNUUoKI0ce79wmQUJmPaLcZO92Pe96ahIh dCa2QIqhld30fnb7PlHet1sodPFsu9ezKrDT9ZAvvJ1ZbxP+MXnF4daakfAwPF8xXRNin7Az 0vW0dTit8RrseT+JvLxFsxJOqO6U1UN4ZdqtDVOiYx2+flSizbKbk9oN0tiQHRL3NezTHS51 RbF84viRenervfWx9xN9T3oN7RgCbNzhrhIrLF2czxKBc/nXoUE6tN4M3jSY+OSX9ejHTvSP 1NXgjTcw/vd1tRIMtifc3R2zr+dEPuukLush4+uu7kIemiFFXB8TVsUjeyLalLIa56hfzKFN bDL7HhP/o5rE3Ys/HAuy/UGiGMI3BiKJVhye9sJ9EhYgGcLFVJxZRWrFCm8SbsSmq563l8WF Ue5vb+beRWPzHhghACEIQaUEvwQVPGhPoUKDCRbaa7gw4sMA6h5efPgGnMI3FhVWKSiJoUCC DSeOdLhwCMKUETVytHgSYsI3kDBKpLnxl4J5ECUhAMlQ0i2b9trt7En0okx7FZLa/CUpqlCI CizeAvAUqb2aPiUKSXnzJtOmT30icOp159Ws9pQyBLs1KlqPD03ydFs07dSpXt+2sxe0as+p Jq7a/Ct2ZkG8b01sVOwV5dKEClcatFV0Mk6HJgVlxig48kmZAQgrANB2qcjA/p0P3lLX8G0F AAQYp049jzRq3Kdzj04ouG9Q2bFfa96s0PTEiBGJ8869MzVksdJ/950rfKhm7KwXvpXo/bJU 1nzLn8d+sO/HsJG/660dUmXI5iK7U10IsvuEunbVn19MLQDBaw2/uQZJaSUCq/sPPwTdu4W6 2eI7ySnpkJMposeqAgA5hUzoyT3SKrOsvVuAaI8r3ACIKaFKfFGvMs/aGzHF71CMzELv3lix RYdefM02/9q7TMbKdExusa4Uay6u84Bq6SfasrrvoVuEfG8hHe+rMqr1EJyKRwBwXEhMSNxI DUMjEwBPx7fMM1AkMVHEDjXqhrzvTfsAbOo37YSy/m5Mh6YMcawG1SJRrAg5Q+mkIhGoiFGJ eCvKIEj7swdE9wLUstArU0zroT8jukWUhExrNNEaFQtVLI06yi/KAEtNaKWLWv2Uucpe9SjD hCrAdEiFkDzrT44gqfIhWyUdrz7JuksvpE8L3JSiEGcs0UsAuxxKSP2eRJUy+QSkytkyIYEy TgQexGhJQ8flK9GxvLMnXGzdsu2ua1Xll7FCqQWuvTewjBQ2uGikt8iUKhByYNdYEjZJgyEC azRJppB1vokYdshhhSbhimCPQn1JKIyTbNIhEzxM+T5NfXLFoQiTLRPLSdAyy8uKV34WPdY2 jMoNnSqutuaHy8rrLFu7/uJWaIrhFenEFE3ic2modrbpFZk3etllj0xJQGu3uPZwsSoruJPn i5YN+eHm8HJJSA2h6rfthR5UeyzohMQqtboCSI3MMtM2LqVpVfSbQ9zACZQAX6ADYCPABd20 As1K/rBwhQ4XU7W+WaQozVu5g5zxXQmA9F/FceQSNWSHSi1fPi/q3De55UxtlT3jtK7SnwCH 5OSiy8StV9Rudys1UXbvGdIOMa7yDcH7dpzPvpfnKPeoY+/M9bNFp96hcL+L3ZfZpyQbI8My Kl5x1SYygQBbuOfZ15Ti7xiy8Yfnv3///wdgAAVYrfUM0IAHRGACFbhABRawgfJiYLVs5UAF /lYggghc0QU1SLtgbdCDHwRhCBMIqwt6TIQYiRRXOnhCFrbQhS+EYQxlOEMa1tCGN8RhDnW4 Qx720Ic/BGIQhThEIhbRiEdEYhKVuMQTUnCITqQhFDcoxQFSkYVWrA69kEiLF2KxhsbiX+dW KEIvihCMmyqjiLSYwOxk7IBphNNFRBMeL54xiXNE40/saBcFUAd/L9yje0wIshimEYSB9KAh +dfGGUoRj+Gp1iOXKMlNIZJikkhJALDEwil1KColoNywQqmsqaGGdYJoQ25MIKhPUk6MPgEl jkJFoFbi6JWZSlx4SiAk2ghuSvBhnSRiOSjcvG4CIVrQKlnUl8nR/0mYo+xlSyhFu/b5J5VZ WaUzyyWJCRSzgAa55jyy2T3KzfJ1ohTcpERXGL918nW7NF8tO/Mkd/LFlPMcJjVzWa/AhWSX xPQl5cCpylBGE5blLKaVILOhTMWGm958Zjpn0oakmMqfm/ygcBpTlPUtiClpUcpakqcVvLjr aVtRyqIy9S+UYggsiZlUiDrKUcIlraXsEYpKX7a5ohxFSh65zEYzlzSkQfEXRGOIVUaaFy7p 0Y1VYctTcJY0nTq0oUR9yF72lBiNEkYqJYUKn7Qz1ZAKdSwVA1a28HJVxxwGqktVykwHQ9RH DgeTrWHkXD0qCPPZwwy1UM9azZixvrCLbf5YxY89xsM78bTnWw5yCLviJEc2lU0y9jBsZNuT 2SqN9UGSxaqXKrNYyXA2IY5EGGO3ma7L9gxQjcWsQ8azrgTR6LRbRY6xtNUosUZpPaRF7URI G9sSEVexUBMKbbPV25voRxxv6AmYnDpZ/wClHpOgWgt1ax/opPNwPO0Ut37bsX5WyTCYo+6c iKkaA3UXYknFjTYl86fz3kmUVNqOxrblXj21q5924dNuBcTaoKWJW23qCYhC+tX4msh3ZyEU taDlHeniRzsIpln2BAUe4Lo3UPKFloeZq755QHdm4igWYbXYkDdIoXCKPOB2FQLatdm2tuIt T5Ac8tieCQ+Sfv7xVlhM+iUbPwS0nZVVVHxMu9eNt0pHnt3mggxg3t02xYl1rU+EuzXonoXG P44jV9C13WiZSztbzvC0eHxceVA4RVBWF5znayO3qCMog7BFTKabZc4clSUwNmDX+LQ+e4CN djYja1hVy5WNvMTPybIcRu7jaLCITaWJJbSh0faQTCN3pfiJ9EUszbjfEcZJ+On0ccVMu6Gl tmd+zpSiBU3l5oFUM0O4a2G+liKrwWxrn371z1od6w9dS0o5izKjn1YvU4/rqoVW2a659Wyw mVd1DJHCz3Itklm3llNm807epui984nOv9c53jx5N03lPM/TwKY1M90dPlrfVzPos/93li/U l52Sj0LbAwAUDrWeX25OeWsE3pKnLSbdqYXc8d5vfBbC0L4U/CLX2yr3OHROLbMbcQ3fuD0l nmF+Bk9mqRG4s/vUIS2tM8CsKXiXXIeRtOJL3ftOdo3WI24mSnqNRftyEINusZ4XnY0/N3rS /wdo9A6x6ZFRJkaVPvVNRZ3OVMd61rW+da533etfB3vYxT52spfd7GdHe9rVvna2XxDQRYM1 A9/+QSkCeu5ex+Ldjwg4+8Id6TAM1LV9vpoEDr2Kfw/NUyNYd+aJykYCdo8lb3gEAvJG6j8m Ot0tr+7Eb5DQw5O8C0l1ecJr0PACTCMlF/931GYxkldXokv+LOvteYFQ9pFRfYxhL5bQt3DL HCJT72BZvXazsty2XByn93nQYP5TOsGfJqTT1E0Dc1egEU3RK+UJX5YvJfrcbidE4UkecVw/ ufW0fvNHmdV13nOiBHVmPrWPfaQhVlhvu/4xwbvyd17f+e4fKGwqqPULkOziP+rzpG0RJl4K JWVaIWWiEwBcwLBAv3xCp91zO5rQC7MoKu7yKrpYLlRzq07JEqPgo55gmrWytWHxqixjKJyC sJwxK0mLC7PSKpprwajgKmnyqq1gmhGbixW8qYt4QaQpq6hiKrCyixo0C50SvAL8FWRzwkyh jpvaCiOECqXCCrOQq/trkCKUsSv/lCuYaq6FkcFr6yqi6sINggbvm47EUhhy0bLR8rTM4og7 WRA4fLc4jKPCcizfaiySixUusbL7wy3HWzQDHA5A1C8sm7GwcLKXGy/HezLNYhCV0YlA/InP ssTJShbgehI7ZBSg2cQ/9EQ3K5E87LxILEPqEkUyOoglQbD+6g4OQ64POxr2Y6/LIq1ZfDBC NEWfwLBkQxwQi5oHs5JflBI/UTEiQ7KcujfdyDkSGcZFUzX1Mi91eDp16r5qrK9va6r9Kwvx ci8+MjfRCsZwdB9Z+g3ek5l7QwAnCsNybKJf8ZEQlEPI40PWoLHPY7J4Gzg6BEZESUepEMhk U7NbzDkF/zwXAvOZVOG8MztIR1yV48IxlEhIblkycYmYxVKyXHStaMHH7lCudwEwmRAOKyOy mzApyuKU4ULELDu9RDottOLAXiNJVHk0rBkqaMvDUaM1R/OOFbzGq1EZvUgbY0s0PrvDk6qa jikbnJSEmBkbYJuwDxk2tRG0pSS5TSPBBVu0l6C0dws1YouYr1S0pri3KmRIFrSpl6O2IgsP tEjKgyG2nds1oOQ5ahHCn+s2ftu1Kzqd28ASjHOtvkm5jxtK0VGmyPE3jBK+y5KOwjw4DQO5 ldOJh5tMzqOghPM0w7y4ytRBjcM5QPE4hisPzUw3pmw5x9xMfWOw7is56Jmdnf/an2+DL+SB N8xURw7Rze+RTZSBuTe8EMVsrYKjt9uUsNV0otK8LIuLPcRDPelsOx96O3bRO+P6uuwEO6tz O+qsTh5iOuogoQDaxq0rz/BUz/Vkz/Z0z/c8oV2Az/mkz/q0z/vEz/zUz/2kOu5cJPB0vXrz PQBlEgIV0Bbiu4tI0BDyTytKUP88UDUK0AI9JAwEPcXrPNp7vcGTUAByIAjNowjtnzCLFZ+r IwwFIH/syQ09PAGSvPWBvKP7zwmlUQ3KPf650ZgEtByt0RkVUQY10Npzxx5txQV6JB6Fwel0 URQtUUd8IwM1KunUu/k7v4R6PtcIp3F6JfTLt9ZMQAv/7BPkS5wKJD7+Q5PEKaD5s8DI1KVQ utL3E0AyMaisQqZzYtM5fVM3ZDl2YhEyjSf6I0kufdPtc0McgcCwONQwJa8xhaht+idFLT2D IlR+GpN6qEAChMBaII8AFCfKcUAizKVfmlQ8/b5tukDumz3/ebQRw8K32sLQqhj66jsYHMI1 XLY0LIy+W9Wz8heiusET9FUZRMK4GsHvWCiHmirADFb760Bh7Knl7EElfMYYtKkZRMskbVJb hbV5lKlipQq5GsKas5U0zEPi2FQtbAuiIEOiAowXrNURvMFw7MJf1b1pZUWmDArPujoZM67D ylcVK0nKgiIeixfOA7PGA8Xk/3rFR7RIg+Q8zoItRjEPAiGzHPO0M9NEioStI02Jhf3XU7yb 2gKwkkzY3+NXRNSWA7MsApGsSswWlVRAkoWY7MTGEatG11IvCXPYIQ3JcsxZMkuUmtUnYySq Dx2QaCTHBiPCeVgwWuSvaEzG1Yqwig1Ze80vFkwzqOXYdVxUHAnD1FRaOhIxqrBFnXVScxWw QG3H1tQNEmmdBqNFBcTF/hKgjCzElLyxl0tInSULWuUT0NpboA2LjKQXwjVVbxvIho0z2IuQ LktbfpTLw+rNmnDI14LIOQOUiURcOgSYJgXcKcNbOdTO1QjYkNxYFVvFTYXLY2FJZHHbv3W1 gh0wOf+b0laDNa0slL6ME6e5XaX0ShKjrk4bS6ukJ/K0XXoZyyrpNYhzS7B0rVRbm21DgOVN NaIkpVWLCqpclL8kD6xcNtw9P2RzUqLc2rgc3q7hSbxUCEODpE6rEp3cGWM723l6XKHQ3jsB yt/NxvWVLaj8XlkLzOUVIM80zo3zTc4EF3cLueF0THPkOIIzNwJ2zop7Q890IAu2nspk3gOG zS4lQsiYCtDkv9y0EcMczZF7uI4ztwIuzdckudfs3CS1OAmeOdQ8zhUGNZfDD8Q8rRSmILTt 3p6ht8dcmOmQvm7UYBumYCQGAOzhzyeGYsyL4immYq/zzirG4izW4i3m4i7/9uIvBuMwFuMx JuMuXtAWbaAgJSB6mTsI/SY1luLVe08QLT0KNVE4DiIVVdI07p/OmdXWamMA9WMaDWQiVVU2 VuO8YqG6Qjok7b0Ayqs3Xo2UxWMfQtI1XiBDMiH2rWMN9btq2WQ6k2QPreRPRqBLViBUdmQm fVLW4tBJLuUeOtRBnUBdYsBgOtVb+lRIBbB8MicFvTZaVhy6yVJBUdMyDYA/ZjZJk8BhhtNO RZFj7qt6uRM+7Q9O1dL2YSZSm9RmQhgEtIld1jDQwSVytjhJpT93Osl0tlL308UvhSYCxGbj 2yZwfuN8omSRUz+JAiLBEELBSqpufUu2cqnKUoh2//XWueqKKZQUOn3LZOWuYeUOJoSwMSKL voRoV03Xie7VIMQUHXzWSZHorwgJEPQSGwQqhGGtdSXpxChCcDUrRh5C0bDeJn1X+xOpVyWK pqrcmMJe1Q3CM2TWH6oCeeBFlUssiJVZx2NZkQWzhODEqO0T2dEvZ5m2QTwP/oiMCaHq5bLq 1WWP/QgWkBZSmvkWrdaybeHcuRQMVWRq5AAtiLWwxwviRdRDl5RJp6au+o1kROatfM5YT+6h oLjZeBMxXCzG9dINekzqaGs6XTForL3aPgQQoeUQZeYU2UDayWaeSSsvsNXVZdzFhSsvO7Fc v7g1labptdUwdqQStx1bzP+F5bkWx1bx23JhbNjkae04U46LLcC+WTqu0JdE6suCstLd22Mp XYCcp41cZrM5SHWsxSDLySdUjn15r2Zpy+neMahJnToeMr2l7lJL68NVNbbOPuRIbjGTCdpl DZkGwrW2adgNUGiB2Z42kP/IZ80V7owyw4GuY/fltl0bS70MzB97wbLMCLmJwoeWyt09XrI1 1LLxmIjA6AfvGd49Nb9Ip+z9tYMVCg2XD6mp32WOu28NEaAcnKfJ35qCNmu7Y1TLXQ7kNPmV DOjda6lIX26zcVTLRErmSmIkamkauTUqoJhj4KLwzCGGTlStcVepJhcGOOzhFucxuehBkb1E HHL/lvLkaeLOTuAr5xPpgUTYkTgQPwsM5ggg0NQq4eHUupAhXogl1zjMzDeZC84SL04YduAj Zhm4VGLr821nTuvd6nLBpuKZLOMQXfRGH57zdHSoq/NIp/RKt/RLx/RM1/RN5/RO9/RKn4VP j2M6imVGd1KxOOMOFfVCKvUpQrwy6m8citJYl2Iv0uPMC6FHNvWYHG4WfWUjtVBVP/UTkjxY 92v/QeUrQroYleNRL1JTzvVg173BUohriDxpT2VsN+QYKnYA5c5ktz12o+UCQ9Na3pyFOlbg wyfiY1N1MtT/OsXxkz9tpj9rgj9ycu0EVHfmmxpATXJ7VsBHndNb8T+E/zI3dC4BIJCAYjpT 0NEWfEalez/V7VNn4in3NfW4b12+7fukW76fUC34fDemOqWyPBVman74UfLmd85CAuSkFmxV yHs0gJ6vuwqKf/5Aer3WGG6d00DBgh5CkYYrdCHfKOFKa1VoWbsTbh2qPIRpDhSNp8dWp7RC dOVCt5pp2Jt5DtR5Zz1oYE1BgU6pZ5X6t7iwhWKpY1vWBTPpr+L6lMbrVu0imK1qelkzSnyu 6HI2UDQXzBvXfj9ckcRqjbXGvz9txUVcTSzdrw3Z4jKyvKVthkX8GMarugZzhYV82XbHgTRa VbzXfo1syU9YnVUuKPv88UBrvpbv23b8FuqvYf4Mk8++CRAxMcZBseDm7IvTWsDPR1S0bKON EwTTWdyv42ZJFMbnWnOUfdnGxfUQjZqVbvSIbbs+N6Kl27mMML+Hl3IklOYHwgF/7KstCwwz 7fJG7fnAa+EXPbXOWx0c75uAjTvLM+K+ys0VWTz66vxmk/dP/Cq7f98CCEEJ7NkbkuCXJIII CTJcaO+XQIQQBzKsQnHiw4QO7Q2iyPBjx48OHVpkGLJhQoIl7d0iMNCixJQLR8qUhOCkwpoq PTJs+fKgTpofMzJ8A0mkzIgpOfIsCukmT6H2Vs6UNKWpRIEEDWIsCBRBgHkZhW40OJSqVq9D 17Jt6/atWaMEK4i9df40phtwD4UAZftLSkoTkijSZXm3JoK4R4cWtrtz6C++9kwczknQhN43 eiP3JYrUckYEjRebEBt6tOeNoDWf1suwtELJlD1PVkfQVFMTtu3hlgr78u7eS3+z5hzTstSF um93dvj7Y3G+UhVDluRq4C3XqzcPD57gFXa9y3k3D2zaYYXFSEXXXYx64S0gQKWG3ZvbtD3U b/fz538LAACiyKQAAC6NZVMAAEBylWofVbCbTwoRaKBQ/wW4VEMTUrQSdACuotGAAKqX4ILl VQfaTBpKqGCKBQ4kVYYiglYBgJsReNQbHoLooIxr0ahgaiG6J+NGv9wIloIMSkKWTp79WP5Z ajcORaKSoFkoYHUWGhgjkLTlJ6OWhBHZpJEsmrdWi1uWSWFKbwBRy5JNWghFWjHepWJ/eeq5 J599+vknoIEK+tmghRp6KKKHNpjoWzgx2taij0o6KaWVWspfpJdquumlmVbKmqYmALglp6Wa eiqqqaq6KqutuvoqrLHKOiuttdp6K6656rorr736+iuwwQo7LLHFGktpgtz1yaGhyRbq6bMY GgotoY9SW+2e1w6rrZe3ckuQhQDgV1FT++GUoItrLXdcttIOOl60jFLl7qDQzjspQgjc69eO Z5XL7n77Chops/XSy++xkEnGmb95iqrmOgTJ1TBoemaXaMGBfv6rp8CKHvxYt4jmmzGaH5Mc Mlsny1uuxh+faGmOAO72ZZfoQlkVQiUYSKN8Q0WY37g/Allmz2w5qlCdkwH4ZpwQtQHgPKL2 LCoAu8FWmGFzAdBzzFVnpLNHVMtH9IuSgI3S2TyXrTXXAHqt9NtqM+Y2JDlvXTbYZAfJELpj m3333CLaXfSXhCP9tLhSm4jQBHQ3WObQCVGtjtB1m02AL3GWADhNojmuEYE9D47V36Kn9GTj ggd1+UByQ0Zgl4UP1LVtG9crm3ZAE8WkkaYt5xhjRwH/EYf6rXW0PRMTX7ZECtj2X3vAt0NQ SBdPJtbv6tnX+1orvafAuA+BD1zWyv49rz1n0teWNcXcO8a97u83+eBWB40/PLkStkc+/uI/ L65hmKSvi0irMFVRH1XG1zyxyEUq82JP+e6nPfExsDKYWR6KQOe78/lILM7hYEOk47JHlQQn GKkKcuJkEoqYBTpQIFD4pkJAhrRwKMirT8NikhxJ4M96TPnhSWooQ4KtrX6L2kgQv5LE5eFv iRjcG4y4EpS0SLFi+dvbD9WCkgwKsGMnBBH+9sWuiTiQgGUxUbWkCJUnMmmF9ROJVhzixJ3Y DlAxG1udgIfC3alQfG4z3PBweMXhYc2GTQnAzDCoQzLZ5EcMnJluigM7wN2xMw0j5DyOGKKl zWeSbQOcI/4hBzg2rg5c6qFLhdRTxZCJEXR/jAoju0hAN4hIjyDyHABbiUQ0zguTMKqYFLsC sjb6kZMfsWUxKcnJOvopQjCp0xcfEkcQ7bItoFofG6nIMkcJModNY6RTBoiSq1CPJ860pCK1 qUk3omSNPTEQh4zizpTNkI9IY+FBpkmbVS6qleWEVCz1ObJ6ZpA28tRlUvJZxHl1hZ/SGolS hCnDe9rznwjzjKPOycw+Rad1uavP+2RzmI2MBzcikYw9unk9hhjPkHyLYf4WmcHrsAQcDUrP a7zTUSLOZX/rJB95zMecjoKnptg06Ud+Q8z43UWkBKmPcZqU1PM0qaSw5KJTlf5D1aFQByE0 vZhSa+KczTh1pafxqVS305qpxmYgsyGpd7g6O9LolKzoRFaSxAQAvcypTTo6EI9i1xO3xbBM d0rXUKjmtXBBzZtjrEmYbpFIs2qtZnnlqR/ZVLLAQulJT81rmCo7QT9aLoUx2lLMPgQuANEJ jSK5EYw8SyihpHZHhm3QlcA4qhfBVqywU09tV1TaNRXxcb+dUY1Im7y/qka2xwQQlkT72RJt FF8jTJi6woc87FaqutxllHe/m6fwCstR1xTvpKhGKvSmirzsfS984yvf+dK3vva9L37zq9/9 8re//v0vgAMs4AETuMAGPjCCE6zgBTO4wQ5+MIQjLP/hCVO4wha+MIYzrOENc7jDHv4wiEMs 4hGTuMQmPjGKU6ziFbO4xS5+MYxjLOMZ07jGNr4xjnOs4x3zuMc+/jGQgyzkIRO5yEY+8qok gOQlM7nJTn7yfItxYJZBucpWvjKWs6zlLXO5y17+MpjDLOYxk7nMZj4zmtO8ZPf2STXVDS+b S/WG9ZoKkWpWFU6tuKeTdS132HrzwULrFm5lbKOC1pMw+5zM86QlPYeGHIUavRgh3nlTf0Hp Rkk2Z4og9WV6btegk3ZR/qjsTxJ12Mw2zZwTOk+abnWNRDHSQK1cUGJ+rvSl3qCO8YxuRabL CS4Fm9LChm5tkLuLIBAXtbv+0e5rmEtJAPxMxtJd5Li+kVnlcvZstlFkcqEGyuYI59w3PjV8 XfHJRJQX6zhGRCDK++dscG0pmAyogj0tX5MKLWqmnnV3rYYe+7anwEZO1tXuc48H+wWfxUwv gQlfn2PUB6mISPAyt6bNqYXJFUHYAn1JO2G7O949t45W3okiSXGVQkNelgt4NHLJGbNibHCS iyYTKLjBpzhzy4SxnvlKYv/8onKMssyHLneRMFEppYZ8nNY2EjZlTU6prnltl77M97/SMpGr I3OHy73bSAh08WnzfDF7RE9jdenJ1jV24ovbt1EpavA6bRwsM4v1caVp98TCVOoYmyFEFWpE fU7/dC04JKM6+3h2yMKzPGAp7NAX72ovHdTnNtnuuyETeY3AXTWHbzdF0E1xRkel6fYbV6n9 brCPrLLW7ynrc6AT6dahNTFzxSJC8rI9ncQHK5t/YwOdWlSwbpUoVh2+eEZLdiddXIvJmz2r PagVVWPkraZ/vkdCEm/VI+q8ujn2aSkSXOUOpdmZXVtucY+gyzbJTR7RUuasBF2/AkC1ob3t /MC022H7bFTxp82P+Bm8fF3VTRLpXQYB2MJuWV/pdZuBgMr2cd+RxdnkrQql+ZguSKBb6Fqi qFqq2JkGhmClTIEIlqAJniAKpqAKCpmbXdegueBbUGCFuVcdOUuf2OCk/+DgiSnaqKHMeAXa /r1gnhQaDH6apjBT6rVFEvagErJMx/THAO5JFHIMlakLzpGYB3banxXhZrndfhBaFbLXEo6c n1wLyTwhqYXhW4whGfYHG3KYSvnRr4Gf00CN4jSbtv1ftGkeuI0SHVYVtn2Ozvyf63jbFhli ToQb3uwM51AbAdbO5WROr33WKFXW0BSbugSiiNCSzHyNH+ZdUbiNbVROYJmJIrJUJV7GMmGi trHd1CwNnOQNKzoiKb4W4IiNGnbYqfFbvhgQ6PzP/rQV9/RiwZFRxemO5CFQtT1c9rDP9KCE xOlP8tzJBkWQvYXQ6Y3FMdKP84EMvx0TwxUeNv8e3L1lCsOc4TKyTzNSzPdUI/CUBPy0I/uQ jH68oYYdHcwtRTAJFM3RUU3cnNC93c4RRc9lkDsZRNBlRELG3FIk0RktD02QhTa1jz6ak/Zk DL0hB+HRkziSEmjM0WMwJDuZBTxKlUN54xa9kT1mWFds3SllEg+ZncLpRCWF3V4FZCqZlpOk neWJUs840noAZUp6hU0uU0V+nd/kRE6S2yC9ZOCIRTwZZdl9WiV15BWRxdpd0ksWJeCUpCmx FEyCRsZgklVWyhoI2OcJHlEq3kzmhEYhRhwun+RFUzi10jxBB/osxbtBVFhaFIoIxFsqZSkx 5TBN5FpUHrg0HjHhVuP/lWXhScV2hWTisVNMJZQRYR2aTORKZhj1acV72ERXMZLuRRXPGU7O gUZXCV94mJVQHN9qosRX5Y5DFEd3rFqbZIZdRWSTQBVKvQZ+tJQ9IJ9Z7VSTUAd02FXU+WZB HVVTeA9a5RRzTNRGfCZoxB5YzmMugpj5ERdBzp/6IQl1tR/hwJ+ceOfX2d/+4R9yAcmhKWQQ rkiXNBeRgCKVlIdUzImoGdb59V+6GBZ4VolnpN+U5BX52Uls9QgbqYh8dolXrohmRYmwcadj rmCncCEFyiCFGtnGuJd6ZWeGfiiIhqiIjiiJlqiJkhiGKliKfpZe6CCsrOiguKgQwhgaxqDW /w3dt8ldfpmhhyaV1VwhtlBKC87KFMYgF4ZYjeZoBX7hjfaoePHosmyIk5oKjAbKG1apg2Wb I3Kb5p3CPcXEKcLRRcTRLIZp4ByW6YTp5EiksikOl7Yi07Ups4mis+mha8hNLfoFJoqNBBiT 3OSh5lRi3/CE+fWEa9Ta97lS7LgO2hAA4lTdlqaUMckOmuzppEJRJDoiHkZqhzmcOoIQ041p J11jqFKUPGbeZOSOPEYcw2ElMGZNM8JPhrzq8BjHwInGj2LnftSjlPIPNWpjMHLjBdoHoVTB YAxRIz0cxE2QrApcsO6GWayjgwRjwWClB43PXkrHMfYKGfCKP2WREP+JEtL1UTeKaz6u3EOC hEeIJEGqx2IihkO6i9fV3D/OTEdYg1qU2kOuxErEq2BqJD41ob/8gji8gVh0hMwRHWH2k0C+ EUjuK+noZOBBZFpxmD/5ZAN+KbmGa5Ne3cqJaU9sZf6Jy7sq5dr9FG1JpR/BWlaWGlnyK2+9 km5OJWEi5X0YbHYQrELKZDIZzkbUJO+pkv28EjheZ7UOZjUBrRFm2LdGZktGlGWW6tzh08RK bQWepFNE0w7dJcoy3k90Dg4djb5qZq9mERcNZjeek8+oQwnZAiRCJpU5RGBWlFo4LdnyYUUF 3txiaX+FVXXGldRO22xKW5Py4m36iKo+J1H/IB/DvBU4WVXX5sRoilBpulVcPUcE3ts7li3k itVuelBvJg9yigRgXMax5otxWhWhECdo8KblRue06upJkRwWXRDr+iCGqScAIqjcCS4oBi6Z 9ufvBtbTPSh87F9wzatnRW5o1KdUuB/NmN2RxCWewCwqRs6/BihriVp9+giEaJaARq+nOW95 AkBrSdfrIFbGJO8mjQj7LS2OkRffAsv8ApSv1G+Wye+RzhcHlkqH7sr/nqgADzABF7ABHzAC J/CW1S/+HtkYnsyKbuaMmtoIGYl2mACdMeGgTVLJceTAcDDAmNokvedQGqmnbdkDT2mhSHB7 CcGxplQGawzcraEK/2dmxD7LDOOul/0pLdLNm5oNEPTpJtIpmHJOstnhKPHwKeapKsZNI5ZA EJuGXaBdlxRiJ6LEJMZpXYjC78GNOlBxB5+a3DSblqZQ2qTikurQESfOLV6xkv4wl2LNFEuO zLRImqIxjsXqMXKIHptGtYoQORoJrR5FH8tu0drD9BSy9SRqqvpo1kQjsAYc0sSfGdTC70mP cjSf1S7r7D5mUIwPJ4OsYAoySwCQXUByQEKn/HDyIn9xTBJEO/SiT22rjvmrZ3CILZclvZVs aNgyyq1FE1FtQw6EGjkK0JXcY2mevtTDJMhlQtTq5amhKOkFSJbExQ7zwk6STX1TBiVkKv9b VDEHbEhIETSzawNTGMaWEXyC3VJEJTvzcvPILGb6CNSk83DMg/wIE8bSzLgks5i+gRR8cReH 0pLksI7uc1Ve8zr7LDRxc5DgUt8F7skuSVaWhvxANEJ4rA7PmKOos1/Sxkq8JTxH82ylhMrI U0cvRXYY7FgkDebl5S8ZnHSAHuVZzi7iLWWyRGOixUCaLU4fyLxOI5NmHyzdZU2x9M/a9GRu tIx1bnXih1NfhmkQ50gzp2/EkHBG9VacbiPljmvGXfY+DjRFhGrWVC96NbMmjVV1FGtmVW2S hygDNSPF5mSEcZ04teoWBFfHpizjW3V2sIwtL5ksnWDbyX/OB9L/juzNCMlzIVZhvwasnU5y iW97+rPVytpfhQkVt6i5iZpsda9+si9n/bRMBUloxaGOii8YQ7Zb7laaFBe0RbQCc9c5W0pt 88ltzzaq9O+x8Dat+LZuB7dwDzdxF7dxH/eE1RELrx5yA9jT1vAGag8jl3B/tEjbvdv3GeDA PJQCXHAG/0x1j7Amp2FzS8pziwzd/cuRXgyr1U56tzd/9MEEx8YLB0AM47ZBU2F5W0vh6k0d snHRMOp1+jX4cakcho30hd7OSDGyKTihEvGWFrgWswQXJwDt/AeFlCmpSJQcD8kd/6QPI+J+ m1rhfs8gh/JxSgwkQtAHsY/xhITGzY5r/3BgjPuFtgarsjIdJVvyus407VnjT8fdcijyYoR0 OAILAkiduVoS1v5cwIJsSdJlLpuF9SRdgktnnRTSwOpct0DEMjdz0jwTk99VMgHQOA+EL5t0 6AH2iGdLx4osF2UlY/RlRvMsxpJl/9Y40FRtN9rsUoq1hQc0ZoMdYMJ5kF/P+0y0WHqEUPYH JbQ5TiOeMBtkZNpanrPlRzfUT8jdz2hGnqcFeOv01yY2HxoHYComTa+lDfsMOLC0T3u0U0A6 iYuq4RZUXiMFOYVG6sYVdVKUrCJErkdf+eVmcd5eXKdbbnqm4sY1Db1wVDuHaQinrLdZfyso zY2bg7jrM5un+Ebup2RxCQBlO7jDFPnK34WQtlY4b/A+qC26zaGq6pigyI2057Sjl3X2ijfr ijnUu69UurcogGnyu8APvH29AcEfPMLrSkAAADs= ------=_NextPart_000_000D_01C6AC93.8CCC3140-- From owner-ccamp@ops.ietf.org Fri Jul 21 10:19:50 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3vr4-0006Rg-0v for ccamp-archive@ietf.org; Fri, 21 Jul 2006 10:19:50 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3vr1-0007fM-Hw for ccamp-archive@ietf.org; Fri, 21 Jul 2006 10:19:50 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G3vhm-000How-6h for ccamp-data@psg.com; Fri, 21 Jul 2006 14:10:14 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [70.158.43.219] (helo=jera.movaz.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G3vhl-000Hoj-CP for ccamp@ops.ietf.org; Fri, 21 Jul 2006 14:10:13 +0000 Received: from ib (unknown [172.16.50.29]) by jera.movaz.com (Postfix) with SMTP id BD292CE5; Fri, 21 Jul 2006 10:10:12 -0400 (EDT) Message-ID: <008b01c6accf$62f1f670$6501a8c0@movaz.com> From: "Igor Bryskin" To: "Acee Lindem" Cc: "Adrian Farrel" , References: <062701c6a5e6$e40805f0$e90ddb84@your029b8cecfe> <00c601c6ab40$7f534ca0$0a23fea9@your029b8cecfe> <44BFF848.3010502@cisco.com> <01b701c6ac48$aa3dd6c0$7d1810ac@movaz.com> <44C0316C.4050901@cisco.com> Subject: Re: OSPF ASON Routing Solution Date: Fri, 21 Jul 2006 10:09:39 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b Acee, I obviously interpreted your comment the way I wanted to :=) - in a broader way that you meant. I apologize for that. Please, see my response to Dimitri. Igor ----- Original Message ----- From: "Acee Lindem" To: "Igor Bryskin" Cc: "Adrian Farrel" ; Sent: Thursday, July 20, 2006 9:44 PM Subject: Re: OSPF ASON Routing Solution > Hi Igor, > > Igor Bryskin wrote: > > Hi Acee, > > > > I agree with your comment 100%. OSPF IGP developed and maintained in the > > OSPF WG and > > ASON OSPF have just one thing in common - they share the same transport , > > but, otherwise, have 0 in common. In particular, I believe ASON OSPF should > > not be considered as an extension to OSPF > > and should not be objected or supported by OSPF WG. > > > I don't believe I said that (at least that's not what I meant). The OSPF > ASON extensions > build on the existing OSPFv2 (RFC 2328), opaque LSA (RFC 2370), OSPF TE > (RFC 3630), > and GMPLS (RFC 4203) specificatoins. What I said was that the ASON > extension for > leaking routing information vertically within the RA hierarchy should > not be construed to imply > a new OSPF area hierarchy. Rather, an RC supporting RAs at multiple > levels should > view these as separate OSPF instances with leaking between levels > described by > import/export rules. > > Thanks, > Acee > > > Igor > > > > ----- Original Message ----- > > From: "Acee Lindem" > > To: "Adrian Farrel" > > Cc: > > Sent: Thursday, July 20, 2006 5:40 PM > > Subject: Re: OSPF ASON Routing Solution > > > > > > > >> Hi Adrian, Dimitri, et al, > >> > >> No objection on my part. However, I wanted to make a clarification that > >> may or may not be obvious to everyone. In Montreal, Dimitri > >> and I sat down and discussed my comments on the hierarchical > >> dissemination of ASON routing information between RAs (Routing Areas > >> in ASON parlance). > >> > >> Today OSPF does not support an area hierarchy other than the > >> backbone and non-backbone areas. This specification for ASON should > >> not be considered a partial specification of support in OSPF for a new > >> area hierarchy (specific requirements are stated in the CCAMP > >> document references). Rather, it should be conceptually viewed as rules > >> for importing and exporting GMPLS TE data between separate > >> OSPF instances (one instance per ASON RA). This was the motivation > >> for my comment on restating the inter-RA advertisement rules in term of > >> import/export rather than flooding. > >> > >> Thanks, > >> Acee > >> > >> Adrian Farrel wrote: > >> > >>> Just a refresh in case you were travelling. > >>> > >>> I am seeking objections to this draft becoming a WG document. > >>> > >>> Adrian > >>> ----- Original Message ----- From: "Adrian Farrel" > >>> To: > >>> Sent: Wednesday, July 12, 2006 8:10 PM > >>> Subject: OSPF ASON Routing Solution > >>> > >>> > >>> > >>>> Hi, > >>>> On Monday in CCAMP we discussed > >>>> draft-dimitri-ccamp-gmpls-ason-routing-ospf-00.txt the solutions > >>>> draft for OSPF in ASON routing. > >>>> > >>>> There is agreement from the OSPF WG chair that we are not treading on > >>>> toes, and the meeting seemed to say that this was pretty stable. > >>>> > >>>> So a this is a quick poll to see if anyone objects to this becoming a > >>>> WG draft. > >>>> NB, this is a charter item and we have an obligation to work on this > >>>> for the ITU-T. > >>>> > >>>> Thanks, > >>>> Adrian > >>>> > >>>> PS Note that a solution does not have to be 100% perfect to become a > >>>> WG draft. > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>> > > > > > From owner-ccamp@ops.ietf.org Fri Jul 21 10:20:01 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3vrF-0006bj-S5 for ccamp-archive@ietf.org; Fri, 21 Jul 2006 10:20:01 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3vrF-0007zo-8m for ccamp-archive@ietf.org; Fri, 21 Jul 2006 10:20:01 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G3vdC-000HKA-L2 for ccamp-data@psg.com; Fri, 21 Jul 2006 14:05:30 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [70.158.43.219] (helo=jera.movaz.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G3vdB-000HJM-8H; Fri, 21 Jul 2006 14:05:29 +0000 Received: from ib (unknown [172.16.50.29]) by jera.movaz.com (Postfix) with SMTP id 1F498CE5; Fri, 21 Jul 2006 10:05:28 -0400 (EDT) Message-ID: <007c01c6acce$b8f6cba0$6501a8c0@movaz.com> From: "Igor Bryskin" To: Cc: "Acee Lindem" , "Adrian Farrel" , , References: Subject: Re: OSPF ASON Routing Solution Date: Fri, 21 Jul 2006 10:04:56 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 1449ead51a2ff026dcb23465f5379250 Dimitri, Please, see in line. Igor ----- Original Message ----- From: To: "Igor Bryskin" Cc: "Acee Lindem" ; "Adrian Farrel" ; ; Sent: Thursday, July 20, 2006 8:05 PM Subject: Re: OSPF ASON Routing Solution > the comment of acee will be addressed - stated already in previous e-mail > b/f IETF 66 meeting - > > as ASON RC(PC) are OSPF engines defined in RFC 2328, routing info exchange > makes use of RFC 2370 mechanism (which afaik is an intrinsic part of > OSPF), etc., information encoding (in top-level TLVs) are defined in RFC > 3630 and co. whereas all these are under OSPF WG resp. ... this leads me > to the question if not extensions to OSPF - extensions of which protocol ? RFC2370 does not provide a way for extending OSPF, rather, it exposes OSPF advertising, flooding and synchronization mechanisms to be used by other (non-OSPF) applications. OSPF-TE, ASON OSPF, L1VPN OSPF. mesh membership, node capability discovery, etc. are such applications. To answer your question OSPF-TE is not an extension to OSPF, rather, it is a separate protocol. Let me prove you this point. Consider RSVP (RFC2205) and RSVP-TE. The latter *is* an extension of the former, because it understands and uses all basic elements, objects (e.g. SESSION, SENDER_TEMPLATE, etc.) and *in addition* it introduces new elements/objects (e.g. SESSION_ATTRIBUTES, LABEL, etc.). You can say that RSVP-TE is a superset of RSVP. likewise, GMPLS RSVP is a superset of RSVP-TE. Let us now consider OSPF and OSPF-TE. The latter neither understands nor uses basic OSPF LSAs type 1,2,3,4,5. Rather it understands only opaque LSAs (type 10) with semantics specifically designed for the TE application. These semantics are not understood by OSPF. You surely can not claim that OSPF-TE is a superset of OSPF, hence OSPF-TE is not an extension to OSPF. Furthermore, TE routing areas do not have to match IP routing areas and may have completely different area hierarchies. ASON OSPF (I forgot the name of the author) is a shining proof to that. > > the main point is that RFC 2370 stating "The information contained in > Opaque LSAs may be used directly by OSPF or indirectly by some application > wishing to distribute information throughout the OSPF domain." puts your > comment in the old battle field bucket since Opaque LSAs have been applied > since many years to (OSPF-)TE, and GR applications ... hence, are you also > objecting to these and suggest to have a specific and dedicated protocol > mechanism per application I can see how OSPF can use opaque LSAs for experimantation purposes and for extending itself, but this is not what,say, OSPF-TE is about. > > ps: i forgot the name of the author of OSPF ext. for L1VPN If you are talking about L1VPN-OSPF, this is not OSPF ext for L1VPN, rather, OSPF based L1VPN auto-discovery solution Igor > > > > > "Igor Bryskin" > Sent by: owner-ccamp@ops.ietf.org > 21/07/2006 00:05 > > To: "Acee Lindem" , "Adrian Farrel" > > cc: > Subject: Re: OSPF ASON Routing Solution > > > Hi Acee, > > I agree with your comment 100%. OSPF IGP developed and maintained in the > OSPF WG and > ASON OSPF have just one thing in common - they share the same transport , > but, otherwise, have 0 in common. In particular, I believe ASON OSPF > should > not be considered as an extension to OSPF > and should not be objected or supported by OSPF WG. > > Igor > > ----- Original Message ----- > From: "Acee Lindem" > To: "Adrian Farrel" > Cc: > Sent: Thursday, July 20, 2006 5:40 PM > Subject: Re: OSPF ASON Routing Solution > > > > Hi Adrian, Dimitri, et al, > > > > No objection on my part. However, I wanted to make a clarification that > > may or may not be obvious to everyone. In Montreal, Dimitri > > and I sat down and discussed my comments on the hierarchical > > dissemination of ASON routing information between RAs (Routing Areas > > in ASON parlance). > > > > Today OSPF does not support an area hierarchy other than the > > backbone and non-backbone areas. This specification for ASON should > > not be considered a partial specification of support in OSPF for a new > > area hierarchy (specific requirements are stated in the CCAMP > > document references). Rather, it should be conceptually viewed as rules > > for importing and exporting GMPLS TE data between separate > > OSPF instances (one instance per ASON RA). This was the motivation > > for my comment on restating the inter-RA advertisement rules in term of > > import/export rather than flooding. > > > > Thanks, > > Acee > > > > Adrian Farrel wrote: > > > Just a refresh in case you were travelling. > > > > > > I am seeking objections to this draft becoming a WG document. > > > > > > Adrian > > > ----- Original Message ----- From: "Adrian Farrel" > > > > To: > > > Sent: Wednesday, July 12, 2006 8:10 PM > > > Subject: OSPF ASON Routing Solution > > > > > > > > >> Hi, > > >> On Monday in CCAMP we discussed > > >> draft-dimitri-ccamp-gmpls-ason-routing-ospf-00.txt the solutions > > >> draft for OSPF in ASON routing. > > >> > > >> There is agreement from the OSPF WG chair that we are not treading on > > >> toes, and the meeting seemed to say that this was pretty stable. > > >> > > >> So a this is a quick poll to see if anyone objects to this becoming a > > >> WG draft. > > >> NB, this is a charter item and we have an obligation to work on this > > >> for the ITU-T. > > >> > > >> Thanks, > > >> Adrian > > >> > > >> PS Note that a solution does not have to be 100% perfect to become a > > >> WG draft. > > >> > > >> > > >> > > >> > > >> > > > > > > > > > > > > From owner-ccamp@ops.ietf.org Fri Jul 21 10:59:56 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3wTs-0005Y8-AR for ccamp-archive@ietf.org; Fri, 21 Jul 2006 10:59:56 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3wGI-0001Sw-Ua for ccamp-archive@ietf.org; Fri, 21 Jul 2006 10:45:59 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G3w8G-000Kcr-RV for ccamp-data@psg.com; Fri, 21 Jul 2006 14:37:36 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_WHOIS,HTML_50_60,HTML_MESSAGE autolearn=no version=3.1.1 Received: from [216.82.241.195] (helo=mail121.messagelabs.com) by psg.com with smtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G3w8F-000KcY-8J for ccamp@ops.ietf.org; Fri, 21 Jul 2006 14:37:35 +0000 X-VirusChecked: Checked X-Env-Sender: dbrungard@att.com X-Msg-Ref: server-2.tower-121.messagelabs.com!1153492579!9751286!14 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 20598 invoked from network); 21 Jul 2006 14:37:33 -0000 Received: from unknown (HELO attrh3i.attrh.att.com) (134.24.146.4) by server-2.tower-121.messagelabs.com with SMTP; 21 Jul 2006 14:37:33 -0000 Received: from OCCLUST04EVS1.ugd.att.com (135.38.164.12) by attrh3i.attrh.att.com (7.2.052) id 449EB45200315FA1; Fri, 21 Jul 2006 10:37:33 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6ACD3.33A1ED98" Subject: Proposed response to OIF on OSPF ENNI Date: Fri, 21 Jul 2006 09:37:32 -0500 Message-ID: <449B2580D802A443A923DABF3EAB82AF0C72B4C3@OCCLUST04EVS1.ugd.att.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Proposed response to OIF on OSPF ENNI Thread-Index: Acas0Ha/aYxFikOBS5m873SVRoVJxgAACLxQ From: "Brungard, Deborah A, ALABS" To: Cc: "Adrian Farrel" Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 10dcc25e55b9b5f7d6ded516404bdc4c This is a multi-part message in MIME format. ------_=_NextPart_001_01C6ACD3.33A1ED98 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 We had a communication from OIF on their OSPF ENNI specification. You can see the original files on http://www.olddog.co.uk/ccamp.htm . Having assembled comments from several people and our discussions in Montreal, we have put together the following response. =20 Please comment on the list in the next week. =20 Thanks, Adrian and Deborah =20 =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D Dear Jim, =20 We thank you for sending us the OIF ENNI document in response to our request. While we appreciate the document being provided for information, it is concerning that this document has not been previously shared with CCAMP or the OSPF WG considering the document contains significant modifications to the operation of OSPF and reflects OIF work over the last several years. CCAMP has been working on GMPLS ASON for several years and our Design Teams include OIF participants. Even though a reply was not requested, we are replying, as we strongly recommend that the document not be published for public information in its current form. =20 Of most concern to CCAMP is that it is not aligned with RFC 4258 (Requirements for Generalized Multi-Protocol Label Switching (GMPLS) Routing for the Automatically Switched Optical Network (ASON)) or the to-be-published: ftp://ftp.isi.edu/internet-drafts/draft-ietf-ccamp-gmpls-ason-routing-ev al-03.txt . Considering notable OIF participants are authors of both these IETF documents (and the same participants are contributors and the Editor for the OIF document), the non-alignment is perplexing. Considering the IETF document is ready for publication, we suggest in the interests of time, that you align your document with the IETF document. If any questions on the interpretation of the IETF's work, we recommend that you either utilize the CCAMP mail exploder or send a communication. =20 Specific comments include: 1. What is the intent of this document? Will it be published as an Implementation Agreement (IA)? The title indicates it will be an Implementation Agreement on GMPLS OSPF extensions, but the main body of the document is a list of issues with GMPLS OSPF. Further, your communication to us stated the document was requirements on and use of OSPF-TE at the ENNI. These three views seem to be inconsistent. 2. The list of changes from the previous version (listed under the Table of Contents) includes "removed "intra-carrier" limitation" and the inclusion of Figure 1 showing the OSPF ENNI for use between vendor domains and between carrier domains. GMPLS OSPF-TE already supports inter-vendor operations.=20 The IETF's GMPLS ASON routing focus has been on the use of a link-state based protocol to support a hierarchical routing architecture (G.7715.1) within a carrier's domain. Requirements for using a link state protocol as an inter-domain protocol between carriers are significantly different. We strongly disagree if you intend to publish this document as an inter-carrier OSPF ENNI Implementation Agreement claiming alignment with IETF RFCs without review (or agreement) by any of the IETF Working Groups. 3. Section 4.1/Table 1 and the statement under the table identifying issues with GMPLS identifier namespaces are not correct. GMPLS identifier namespaces do meet ASON requirements for namespace separation of the transport plane and control plane (Section 5.2 and 5.3/Evaluation). Perhaps you are confusing OSPF and GMPLS OSPF? As you also identified in your liaison that the key area needing review was the support of independence of functional component to physical location, this appears to be a key area of misunderstanding on GMPLS. We recommend reviewing RFC3945 (GMPLS Architecture) to understand that the key architecture difference between GMPLS and MPLS is the decoupling of the transport plane and control plane. Additionally, RFC4394, RFC4397, and RFC4258, provide a mapping to ITU terminology which may be helpful reading. =20 We request an additional round of communication of this document to the IETF before approval to allow us to work with you to produce convergence between OIF and IETF work which, we believe, will be in the best interests of the industry. =20 Best regards, Adrian Farrel and Deborah Brungard, CCAMP co-chairs ------_=_NextPart_001_01C6ACD3.33A1ED98 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

We had a communication from OIF on their OSPF = ENNI=20 specification. You can see the original files on = http://www.olddog.co.uk/ccamp.htm. Having = assembled=20 comments from several people and our discussions in Montreal, we have = put=20 together the following response.

Please comment on the list in the next = week.

Thanks,

Adrian and Deborah

=3D =3D =3D =3D =3D =3D =3D = =3D =3D =3D

Dear Jim,

We thank you for sending us the OIF ENNI document in response = to our=20 request. While we appreciate the document being provided for = information, it is=20 concerning that this document has not been previously shared with CCAMP = or the=20 OSPF WG considering the document contains significant modifications to = the=20 operation of OSPF and reflects OIF work over the last several years. = CCAMP has=20 been working on GMPLS ASON for several years and our Design Teams = include OIF=20 participants. Even though a reply was not requested, we are replying, as = we=20 strongly recommend that the document not be published for public = information in=20 its current form.

Of most concern to CCAMP is that it is not aligned with RFC = 4258=20 (Requirements for Generalized Multi-Protocol Label Switching (GMPLS) = Routing for=20 the Automatically Switched Optical Network (ASON)) or the = to-be-published:=20 ftp://ftp.isi.edu/internet-drafts/draft-ietf-ccamp-gmpls-ason-ro= uting-eval-03.txt. Considering notable OIF participants = are authors=20 of both these IETF documents (and the same participants are contributors = and the=20 Editor for the OIF document), the non-alignment is perplexing. = Considering the=20 IETF document is ready for publication, we suggest in the interests of = time,=20 that you align your document with the IETF document. If any questions on = the=20 interpretation of the IETF’s work, we recommend that you either = utilize the=20 CCAMP mail exploder or send a communication.

Specific comments include:

1. =20 What = is the=20 intent of this document? Will it be published as an Implementation = Agreement=20 (IA)?
The title indicates it will be an Implementation Agreement on = GMPLS=20 OSPF extensions, but the main body of the document is a list of issues = with=20 GMPLS OSPF. Further, your communication to us stated the document was=20 requirements on and use of OSPF-TE at the ENNI. These three views seem = to be=20 inconsistent.

2. =20 The list of changes from the = previous=20 version (listed under the Table of Contents) includes “removed “intra-carrier” = limitation” and the inclusion of = Figure 1 showing the=20 OSPF ENNI for use between vendor domains and between carrier domains. = GMPLS=20 OSPF-TE already supports inter-vendor operations.
The IETF’s = GMPLS ASON=20 routing focus has been on the use of a link-state based protocol to = support a=20 hierarchical routing architecture (G.7715.1) within a carrier’s = domain.=20 Requirements for using a link state protocol as an inter-domain protocol = between=20 carriers are significantly different. We strongly disagree if you intend = to=20 publish this document as an inter-carrier OSPF ENNI Implementation = Agreement=20 claiming alignment with IETF RFCs without review (or agreement) by any = of the=20 IETF Working Groups.

3. =20 Section 4.1/Table 1 and the = statement under=20 the table identifying issues with GMPLS identifier namespaces are not = correct.=20 GMPLS identifier namespaces do meet ASON requirements for namespace = separation=20 of the transport plane and control plane (Section 5.2 and = 5.3/Evaluation).=20 Perhaps you are confusing OSPF and GMPLS OSPF? As you also identified in = your=20 liaison that the key area needing review was the support of independence = of=20 functional component to physical location, this appears to be a key area = of=20 misunderstanding on GMPLS. We recommend reviewing RFC3945 (GMPLS = Architecture)=20 to understand that the key architecture difference between GMPLS and = MPLS is the=20 decoupling of the transport plane and control plane. Additionally, = RFC4394,=20 RFC4397, and RFC4258, provide a mapping to ITU terminology which may be = helpful=20 reading.

We request an additional round of communication of this = document to the=20 IETF before approval to allow us to work with you to produce convergence = between=20 OIF and IETF work which, we believe, will be in the best interests of = the=20 industry.

Best regards,

Adrian = Farrel=20 and Deborah Brungard,

CCAMP co-chairs

------_=_NextPart_001_01C6ACD3.33A1ED98-- From owner-ccamp@ops.ietf.org Fri Jul 21 11:18:08 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3wlU-0001td-2D for ccamp-archive@ietf.org; Fri, 21 Jul 2006 11:18:08 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3wf8-0004eX-6j for ccamp-archive@ietf.org; Fri, 21 Jul 2006 11:11:34 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G3wVt-000MwU-EB for ccamp-data@psg.com; Fri, 21 Jul 2006 15:02:01 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [70.158.43.219] (helo=jera.movaz.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G3wVs-000Mw8-8Q; Fri, 21 Jul 2006 15:02:00 +0000 Received: from ib (unknown [172.16.50.29]) by jera.movaz.com (Postfix) with SMTP id 3E650CC2; Fri, 21 Jul 2006 11:01:59 -0400 (EDT) Message-ID: <00c301c6acd6$9db37340$6501a8c0@movaz.com> From: "Igor Bryskin" To: Cc: "Acee Lindem" , "Adrian Farrel" , , References: Subject: Re: OSPF ASON Routing Solution Date: Fri, 21 Jul 2006 11:01:30 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 5fb88b8381f3896aeacc5a021513237b See in-line. Igor ----- Original Message ----- From: To: "Igor Bryskin" Cc: "Acee Lindem" ; "Adrian Farrel" ; ; Sent: Friday, July 21, 2006 10:36 AM Subject: Re: OSPF ASON Routing Solution > igor - > > > i don't think that someone claimed that OSPF-TE is a superset of OSPF or > whatsover the former (as other applications) just build on existing OSPF > RFCs (and mechanisms) > > note that RFC 2370 states "The information contained in Opaque LSAs may be > used directly by OSPF IB>> I aggree that IFF OSPF uses Opaque LSAs for its *own* purposes, that whatever comes out of such use *is* an extension to OSPF or indirectly by some application > wishing to distribute information throughout the OSPF domain." IB>> And I claim that such application is not an extension to OSPF, rather, it is exactly what is stated above - an application using OSPF opaque LSAs reason why > GR, Router capabilities and TE like applications can make use of opaque > LSAs (that you restrict to TE only btw); hence your assertion "RFC2370 > does not provide a way for extending OSPF" is not correct > > this said your digression falls imho outside the scope of the present poll > (if you want to re-discuss GMPLS/OSPF-TE vs OSPF i suggest you start from > the beginning not from the middle and probably direct your concern at the > owning WG) I disagree with that. I have joined this discussion when Adrian asked Acee whether he as a chair of OSPF WG had any objections wrt ASON OSPF document, and my point is why OSPF WG should care about this solution one way or the other. Igor > > ps: all this remembers me the discussion we had 3 years ago in Vienna (but > was on BGP at that time) and we all know where and how such discussions > end > > > -d. > > > > > > > "Igor Bryskin" > 21/07/2006 16:04 > > To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL > cc: "Acee Lindem" , "Adrian Farrel" > , , > Subject: Re: OSPF ASON Routing Solution > > > Dimitri, > > Please, see in line. > > Igor > > ----- Original Message ----- > From: > To: "Igor Bryskin" > Cc: "Acee Lindem" ; "Adrian Farrel" ; > ; > Sent: Thursday, July 20, 2006 8:05 PM > Subject: Re: OSPF ASON Routing Solution > > > > the comment of acee will be addressed - stated already in previous > e-mail > > b/f IETF 66 meeting - > > > > as ASON RC(PC) are OSPF engines defined in RFC 2328, routing info > exchange > > makes use of RFC 2370 mechanism (which afaik is an intrinsic part of > > OSPF), etc., information encoding (in top-level TLVs) are defined in RFC > > 3630 and co. whereas all these are under OSPF WG resp. ... this leads me > > to the question if not extensions to OSPF - extensions of which protocol > ? > > RFC2370 does not provide a way for extending OSPF, rather, it exposes OSPF > advertising, flooding and synchronization mechanisms to be used by other > (non-OSPF) applications. OSPF-TE, ASON OSPF, L1VPN OSPF. mesh membership, > node capability discovery, etc. are such applications. To answer your > question OSPF-TE is not an extension to OSPF, rather, it is a separate > protocol. > > Let me prove you this point. Consider RSVP (RFC2205) and RSVP-TE. The > latter > *is* an extension of the former, because it understands and uses all basic > elements, objects (e.g. SESSION, SENDER_TEMPLATE, etc.) and *in addition* > it > introduces new elements/objects (e.g. SESSION_ATTRIBUTES, LABEL, etc.). > You > can say that RSVP-TE is a superset of RSVP. likewise, GMPLS RSVP is a > superset of RSVP-TE. > Let us now consider OSPF and OSPF-TE. The latter neither understands nor > uses basic OSPF LSAs type 1,2,3,4,5. Rather it understands only opaque > LSAs > (type 10) with semantics specifically designed for the TE application. > These > semantics are not understood by OSPF. You surely can not claim that > OSPF-TE > is a superset of OSPF, hence OSPF-TE is not an extension to OSPF. > Furthermore, TE routing areas do not have to match IP routing areas and > may > have completely different area hierarchies. ASON OSPF (I forgot the name > of > the author) is a shining proof to that. > > > > > the main point is that RFC 2370 stating "The information contained in > > Opaque LSAs may be used directly by OSPF or indirectly by some > application > > wishing to distribute information throughout the OSPF domain." puts your > > comment in the old battle field bucket since Opaque LSAs have been > applied > > since many years to (OSPF-)TE, and GR applications ... hence, are you > also > > objecting to these and suggest to have a specific and dedicated protocol > > mechanism per application > > I can see how OSPF can use opaque LSAs for experimantation purposes and > for > extending itself, but this is not what,say, OSPF-TE is about. > > > > > ps: i forgot the name of the author of OSPF ext. for L1VPN > > If you are talking about L1VPN-OSPF, this is not OSPF ext for L1VPN, > rather, > OSPF based L1VPN auto-discovery solution > > Igor > > > > > > > > > > > "Igor Bryskin" > > Sent by: owner-ccamp@ops.ietf.org > > 21/07/2006 00:05 > > > > To: "Acee Lindem" , "Adrian Farrel" > > > > cc: > > Subject: Re: OSPF ASON Routing Solution > > > > > > Hi Acee, > > > > I agree with your comment 100%. OSPF IGP developed and maintained in the > > OSPF WG and > > ASON OSPF have just one thing in common - they share the same transport > , > > but, otherwise, have 0 in common. In particular, I believe ASON OSPF > > should > > not be considered as an extension to OSPF > > and should not be objected or supported by OSPF WG. > > > > Igor > > > > ----- Original Message ----- > > From: "Acee Lindem" > > To: "Adrian Farrel" > > Cc: > > Sent: Thursday, July 20, 2006 5:40 PM > > Subject: Re: OSPF ASON Routing Solution > > > > > > > Hi Adrian, Dimitri, et al, > > > > > > No objection on my part. However, I wanted to make a clarification > that > > > may or may not be obvious to everyone. In Montreal, Dimitri > > > and I sat down and discussed my comments on the hierarchical > > > dissemination of ASON routing information between RAs (Routing Areas > > > in ASON parlance). > > > > > > Today OSPF does not support an area hierarchy other than the > > > backbone and non-backbone areas. This specification for ASON should > > > not be considered a partial specification of support in OSPF for a new > > > area hierarchy (specific requirements are stated in the CCAMP > > > document references). Rather, it should be conceptually viewed as > rules > > > for importing and exporting GMPLS TE data between separate > > > OSPF instances (one instance per ASON RA). This was the motivation > > > for my comment on restating the inter-RA advertisement rules in term > of > > > import/export rather than flooding. > > > > > > Thanks, > > > Acee > > > > > > Adrian Farrel wrote: > > > > Just a refresh in case you were travelling. > > > > > > > > I am seeking objections to this draft becoming a WG document. > > > > > > > > Adrian > > > > ----- Original Message ----- From: "Adrian Farrel" > > > > > > To: > > > > Sent: Wednesday, July 12, 2006 8:10 PM > > > > Subject: OSPF ASON Routing Solution > > > > > > > > > > > >> Hi, > > > >> On Monday in CCAMP we discussed > > > >> draft-dimitri-ccamp-gmpls-ason-routing-ospf-00.txt the solutions > > > >> draft for OSPF in ASON routing. > > > >> > > > >> There is agreement from the OSPF WG chair that we are not treading > on > > > >> toes, and the meeting seemed to say that this was pretty stable. > > > >> > > > >> So a this is a quick poll to see if anyone objects to this becoming > a > > > >> WG draft. > > > >> NB, this is a charter item and we have an obligation to work on > this > > > >> for the ITU-T. > > > >> > > > >> Thanks, > > > >> Adrian > > > >> > > > >> PS Note that a solution does not have to be 100% perfect to become > a > > > >> WG draft. > > > >> > > > >> > > > >> > > > >> > > > >> > > > > > > > > > > > > > > > > > > > > > > From owner-ccamp@ops.ietf.org Fri Jul 21 11:43:21 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3x9t-0005vM-Bq for ccamp-archive@ietf.org; Fri, 21 Jul 2006 11:43:21 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3x9r-0001FZ-19 for ccamp-archive@ietf.org; Fri, 21 Jul 2006 11:43:21 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G3x3f-0000ur-U1 for ccamp-data@psg.com; Fri, 21 Jul 2006 15:36:55 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO,HTML_MESSAGE autolearn=ham version=3.1.1 Received: from [204.154.129.57] (helo=mx4.tellabs.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G3x3e-0000ub-6K for ccamp@ops.ietf.org; Fri, 21 Jul 2006 15:36:54 +0000 Received: from usnvwwms2c.hq.tellabs.com (HELO USNVEX3.tellabs-west.tellabsinc.net) ([172.23.216.105]) by mx4.tellabs.com with ESMTP; 21 Jul 2006 15:36:53 +0000 X-SBRS: None X-IronPort-AV: i="4.07,169,1151884800"; d="scan'208,217"; a="58611559:sNHT150702892" Received: from USNVEX1.tellabs-west.tellabsinc.net ([172.23.216.101]) by USNVEX3.tellabs-west.tellabsinc.net with Microsoft SMTPSVC(6.0.3790.0); Fri, 21 Jul 2006 10:36:53 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6ACDB.7D97F0B5" Subject: RE: Proposed response to OIF on OSPF ENNI Date: Fri, 21 Jul 2006 10:34:08 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Proposed response to OIF on OSPF ENNI Thread-Index: Acas0Ha/aYxFikOBS5m873SVRoVJxgAACLxQAAHPZJA= From: "Sadler, Jonathan B." To: "Brungard, Deborah A, ALABS" , Cc: "Adrian Farrel" X-OriginalArrivalTime: 21 Jul 2006 15:36:53.0616 (UTC) FILETIME=[7DDE1700:01C6ACDB] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 559439f19b20fd64c5cd872aef84c6f3 This is a multi-part message in MIME format. ------_=_NextPart_001_01C6ACDB.7D97F0B5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="us-ascii" Hi Deborah and Adrian, =20 I haven't seen much discussion of the OIF E-NNI Routing document on the CCAMP list. Can you tell me what parts of the document are "significant modifications to the operation of OSPF"? =20 Thanks, =20 Jonathan Sadler =20 ________________________________ From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Brungard, Deborah A, ALABS Sent: Friday, July 21, 2006 9:38 AM To: ccamp@ops.ietf.org Cc: Adrian Farrel Subject: Proposed response to OIF on OSPF ENNI =20 Hi, =20 We had a communication from OIF on their OSPF ENNI specification. You can see the original files on http://www.olddog.co.uk/ccamp.htm . Having assembled comments from several people and our discussions in Montreal, we have put together the following response. =20 Please comment on the list in the next week. =20 Thanks, Adrian and Deborah =20 =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D Dear Jim, =20 We thank you for sending us the OIF ENNI document in response to our request. While we appreciate the document being provided for information, it is concerning that this document has not been previously shared with CCAMP or the OSPF WG considering the document contains significant modifications to the operation of OSPF and reflects OIF work over the last several years. CCAMP has been working on GMPLS ASON for several years and our Design Teams include OIF participants. Even though a reply was not requested, we are replying, as we strongly recommend that the document not be published for public information in its current form. =20 Of most concern to CCAMP is that it is not aligned with RFC 4258 (Requirements for Generalized Multi-Protocol Label Switching (GMPLS) Routing for the Automatically Switched Optical Network (ASON)) or the to-be-published: ftp://ftp.isi.edu/internet-drafts/draft-ietf-ccamp-gmpls-ason-routing-ev al-03.txt. Considering notable OIF participants are authors of both these IETF documents (and the same participants are contributors and the Editor for the OIF document), the non-alignment is perplexing. Considering the IETF document is ready for publication, we suggest in the interests of time, that you align your document with the IETF document. If any questions on the interpretation of the IETF's work, we recommend that you either utilize the CCAMP mail exploder or send a communication. =20 Specific comments include: 1=2E What is the intent of this document? Will it be published as an Implementation Agreement (IA)? The title indicates it will be an Implementation Agreement on GMPLS OSPF extensions, but the main body of the document is a list of issues with GMPLS OSPF. Further, your communication to us stated the document was requirements on and use of OSPF-TE at the ENNI. These three views seem to be inconsistent. 2=2E The list of changes from the previous version (listed under the Table of Contents) includes "removed "intra-carrier" limitation" and the inclusion of Figure 1 showing the OSPF ENNI for use between vendor domains and between carrier domains. GMPLS OSPF-TE already supports inter-vendor operations.=20 The IETF's GMPLS ASON routing focus has been on the use of a link-state based protocol to support a hierarchical routing architecture (G.7715.1) within a carrier's domain. Requirements for using a link state protocol as an inter-domain protocol between carriers are significantly different. We strongly disagree if you intend to publish this document as an inter-carrier OSPF ENNI Implementation Agreement claiming alignment with IETF RFCs without review (or agreement) by any of the IETF Working Groups. 3=2E Section 4.1/Table 1 and the statement under the table identifying issues with GMPLS identifier namespaces are not correct. GMPLS identifier namespaces do meet ASON requirements for namespace separation of the transport plane and control plane (Section 5.2 and 5=2E3/Evaluation). Perhaps you are confusing OSPF and GMPLS OSPF? As you also identified in your liaison that the key area needing review was the support of independence of functional component to physical location, this appears to be a key area of misunderstanding on GMPLS. We recommend reviewing RFC3945 (GMPLS Architecture) to understand that the key architecture difference between GMPLS and MPLS is the decoupling of the transport plane and control plane. Additionally, RFC4394, RFC4397, and RFC4258, provide a mapping to ITU terminology which may be helpful reading. =20 We request an additional round of communication of this document to the IETF before approval to allow us to work with you to produce convergence between OIF and IETF work which, we believe, will be in the best interests of the industry. =20 Best regards, Adrian Farrel and Deborah Brungard, CCAMP co-chairs =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any reproduction, dissemination or distribution of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. Tellabs =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D ------_=_NextPart_001_01C6ACDB.7D97F0B5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="us-ascii"

Hi Deborah and Adrian,

I haven’t seen much discussion of the OIF E-NNI Routing document on the CCAMP list. Can you tell me what parts of the document are “significant modifications to the operation= of OSPF”?

Thanks,

Jonathan Sadler<= /font>

From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Brungard, Deborah A, ALA= BS
Sent: Friday, July 21, 2006 = 9:38 AM
To: ccamp@ops.ietf.org
Cc: Adrian Farrel
Subject: Proposed response t= o OIF on OSPF ENNI

Hi,

We had a communication from OIF on the= ir OSPF ENNI specification. You can see the original files on http://www.olddog.co.uk/ccamp.= htm. Having assembled comments from several people and our discuss= ions in Montreal, we have put together the following response.

Please comment on the list in the next week.

Thanks,

Adrian and Deborah<= /o:p>

=3D =3D =3D =3D =3D =3D =3D =3D =3D =3D

Dear Jim,

We thank you for sending us the OIF ENNI document in response to our request. While we appreciate the document being provided for information, i= t is concerning that this document has not been previously shared with CCAMP or = the OSPF WG considering the document contains significant modifications to the operation of OSPF and reflects OIF work over the last several years. CCAMP = has been working on GMPLS ASON for several years and our Design Teams include O= IF participants. Even though a reply was not requested, we are replying, as we strongly recommend that the document not be published for public informatio= n in its current form.

Of most concern to CCAMP is that it is not aligned with RFC 4258 (Requirements for Generalized Multi-Protocol Label Switching (GMPLS) Routing for the Automatically Switched Optical Network (ASON)) or the to-be-publish= ed: ftp://ftp.isi.edu/internet-drafts/draft-ietf-ccamp-gmpls-as= on-routing-eval-03.txt. Considering notable OIF participants are authors of both these IETF documen= ts (and the same participants are contributors and the Editor for the OIF document), the non-alignment is perplexing. Considering the IETF document is ready for publication, we suggest in the interests of time, that you align = your document with the IETF document. If any questions on the interpretation of = the IETF’s work, we recommend that you either utilize the CCAMP mail expl= oder or send a communication.

Specific comments include:

1.<= font size=3D1> What is the intent of this document? Will it be published as an Implementation Agreement (IA)?
The title indicates it will be an Implementation Agreement on GMPLS OSPF extensions, but the main body of the document is a list of issues with GMPLS OSPF. Further, your communication to us stated the document was requirement= s on and use of OSPF-TE at the ENNI. These three views seem to be inconsistent.<= o:p>

2. &nbs= p; The list of changes from the previous version (listed und= er the Table of Contents) includes “removed “intra-carrier” limitation” and the inclusion = of Figure 1 showing the OSPF ENNI for use between vendor domains and between carrier domains. GMPLS OSPF-TE already supports inter-vendor operations. The IETF’s GMPLS ASON routing focus has been on the use of a link-sta= te based protocol to support a hierarchical routing architecture (G.7715.1) wi= thin a carrier’s domain. Requirements for using a link state protocol as an inter-domain protocol between carriers are significantly different. We stro= ngly disagree if you intend to publish this document as an inter-carrier OSPF EN= NI Implementation Agreement claiming alignment with IETF RFCs without review (= or agreement) by any of the IETF Working Groups.

3.<= font size=3D1> Section 4=2E1/Table 1 and the statement under the table identifying issues with GMP= LS identifier namespaces are not correct. GMPLS identifier namespaces do meet = ASON requirements for namespace separation of the transport plane and control pl= ane (Section 5.2 and 5.3/Evaluation). Perhaps you are confusing OSPF and GMPLS OSPF? As you also identified in your liaison that the key area needing revi= ew was the support of independence of functional component to physical locatio= n, this appears to be a key area of misunderstanding on GMPLS. We recommend reviewing RFC3945 (GMPLS Architecture) to understand that the key architect= ure difference between GMPLS and MPLS is the decoupling of the transport plane = and control plane. Additionally, RFC4394, RFC4397, and RFC4258, provide a mappi= ng to ITU terminology which may be helpful reading.

We request an additional round of communication of this document to= the IETF before approval to allow us to work with you to produce convergence between OIF and IETF work which, we believe, will be in the best interests = of the industry.

Best regards,

Adrian Fa= rrel and Deborah Brungard,

CCAMP co-chairs

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
The information contained in this message may be privileged
and confidential and protected from disclosure. If the reader
of this message is not the intended recipient, or an employee
or agent responsible for delivering this message to the
intended recipient, you are hereby notified that any reproduction,
dissemination or distribution of this communication is strictly
prohibited. If you have received this communication in error,
please notify us immediately by replying to the message and
deleting it from your computer. Thank you. Tellabs
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

------_=_NextPart_001_01C6ACDB.7D97F0B5-- From owner-ccamp@ops.ietf.org Fri Jul 21 12:41:23 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3y43-0002TP-6s for ccamp-archive@ietf.org; Fri, 21 Jul 2006 12:41:23 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3y40-0004sK-Ny for ccamp-archive@ietf.org; Fri, 21 Jul 2006 12:41:23 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G3xtX-0008H5-PR for ccamp-data@psg.com; Fri, 21 Jul 2006 16:30:31 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,SPF_PASS autolearn=no version=3.1.1 Received: from [171.68.10.86] (helo=sj-iport-4.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G3xtX-0008Gt-4n for ccamp@ops.ietf.org; Fri, 21 Jul 2006 16:30:31 +0000 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-4.cisco.com with ESMTP; 21 Jul 2006 09:30:30 -0700 X-IronPort-AV: i="4.07,169,1151910000"; d="scan'208"; a="1840603308:sNHT918075960" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-5.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6LGUUpS006375; Fri, 21 Jul 2006 09:30:30 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k6LGUT79015099; Fri, 21 Jul 2006 09:30:30 -0700 (PDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 21 Jul 2006 12:30:29 -0400 Received: from [10.82.224.204] ([10.82.224.204]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 21 Jul 2006 12:30:29 -0400 Message-ID: <44C10124.2030901@cisco.com> Date: Fri, 21 Jul 2006 12:30:28 -0400 From: Acee Lindem User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: "Sadler, Jonathan B." CC: Adrian Farrel , ccamp@ops.ietf.org Subject: Re: OSPF ASON Routing Solution References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Jul 2006 16:30:29.0172 (UTC) FILETIME=[FA7CFF40:01C6ACE2] DKIM-Signature: a=rsa-sha1; q=dns; l=4320; t=1153499430; x=1154363430; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=acee@cisco.com; z=From:Acee=20Lindem=20 |Subject:Re=3A=20OSPF=20ASON=20Routing=20Solution; X=v=3Dcisco.com=3B=20h=3DJEaT/PJZXmelX6ToU0domypvAVA=3D; b=Ev8b8DgZPU2StzSdhKTNZsSTNbLf+7JPInMomhBcP1O63n2LU8Hmv76wNwTBUJBvyj9x2lsf E3/NDCz8Igk9Vp2gL/SqDDyIWiHOkpjJn3AD7RnlHB/b2Zno5kvjhWWm; Authentication-Results: sj-dkim-5.cisco.com; header.From=acee@cisco.com; dkim=pass ( sig from cisco.com verified; ); Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 Hi Jonathan, Sadler, Jonathan B. wrote: > Hi Acee, > > I agree that the hierarchy used by ASON can be implemented by specifying > how redistribution (i.e. import/export) is done between parent/child > Routing Areas. In fact, that's captured appendix I of G.7715. > > What I am unclear on is what you mean by "OSPF instances". Since the > import/export is done between ASON areas, this can also be done between > OSPF areas. NO. OSPF areas are part of a single OSPF routing domain with very precise protocol specification of the duties of an OSPF router connecting to multiple areas (an ABR or Area Border Router). This document doesn't even come close to specify what needs to be done to support an area hierarchy other the existing backbone with a single layer of non-backbone areas. Furthermore, if OSPF is to undertake an alternate area hierarchy as a requirement than that work MUST be done in the OSPF WG. > If you mean "OSPF instance" in the context of a single OSPF > area, then we are in complete agreement. > An OSPF instance can have multiple areas. However, I believe the GMPLS TE extensions have only been standardized for a single area. Thanks, Acee > > Looking forward to productively moving this work forward, > > Jonathan Sadler > > -----Original Message----- > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On > Behalf Of Acee Lindem > Sent: Thursday, July 20, 2006 4:40 PM > To: Adrian Farrel > Cc: ccamp@ops.ietf.org > Subject: Re: OSPF ASON Routing Solution > > Hi Adrian, Dimitri, et al, > > No objection on my part. However, I wanted to make a clarification that > may or may not be obvious to everyone. In Montreal, Dimitri > and I sat down and discussed my comments on the hierarchical > dissemination of ASON routing information between RAs (Routing Areas > in ASON parlance). > > Today OSPF does not support an area hierarchy other than the > backbone and non-backbone areas. This specification for ASON should > not be considered a partial specification of support in OSPF for a new > area hierarchy (specific requirements are stated in the CCAMP > document references). Rather, it should be conceptually viewed as rules > for importing and exporting GMPLS TE data between separate > OSPF instances (one instance per ASON RA). This was the motivation > for my comment on restating the inter-RA advertisement rules in term of > import/export rather than flooding. > > Thanks, > Acee > > Adrian Farrel wrote: > >> Just a refresh in case you were travelling. >> >> I am seeking objections to this draft becoming a WG document. >> >> Adrian >> ----- Original Message ----- From: "Adrian Farrel" >> > > >> To: >> Sent: Wednesday, July 12, 2006 8:10 PM >> Subject: OSPF ASON Routing Solution >> >> >> >>> Hi, >>> On Monday in CCAMP we discussed >>> draft-dimitri-ccamp-gmpls-ason-routing-ospf-00.txt the solutions >>> draft for OSPF in ASON routing. >>> >>> There is agreement from the OSPF WG chair that we are not treading on >>> > > >>> toes, and the meeting seemed to say that this was pretty stable. >>> >>> So a this is a quick poll to see if anyone objects to this becoming a >>> > > >>> WG draft. >>> NB, this is a charter item and we have an obligation to work on this >>> for the ITU-T. >>> >>> Thanks, >>> Adrian >>> >>> PS Note that a solution does not have to be 100% perfect to become a >>> WG draft. >>> >>> >>> >>> >>> >>> >> > ============================================================ > The information contained in this message may be privileged > and confidential and protected from disclosure. If the reader > of this message is not the intended recipient, or an employee > or agent responsible for delivering this message to the > intended recipient, you are hereby notified that any reproduction, > dissemination or distribution of this communication is strictly > prohibited. If you have received this communication in error, > please notify us immediately by replying to the message and > deleting it from your computer. Thank you. Tellabs > ============================================================ > > From kzbczbrtoea@aer.com Fri Jul 21 13:09:26 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3yVC-0000Ay-C8 for ccamp-archive@ietf.org; Fri, 21 Jul 2006 13:09:26 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3xvR-0003yf-2o for ccamp-archive@ietf.org; Fri, 21 Jul 2006 12:32:29 -0400 Received: from host-24-149-194-0.patmedia.net ([24.149.194.0]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1G3xhg-0001wB-Kc for ccamp-archive@ietf.org; Fri, 21 Jul 2006 12:18:19 -0400 Message-ID: <000f01c6ace1$3d854100$00c29518@Alli> From: "AGI" To: ccamp-archive@ietf.org Subject: it.Dont questions Date: Fri, 21 Jul 2006 12:18:02 +0400 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_000B_01C6ACBF.B673A100" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2873 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2873 X-Spam-Score: 3.2 (+++) X-Scan-Signature: 10d2fdecab7a7fa796e06e001d026c91 ------=_NextPart_000_000B_01C6ACBF.B673A100 Content-Type: multipart/alternative; boundary="----=_NextPart_001_000C_01C6ACBF.B673A100" ------=_NextPart_001_000C_01C6ACBF.B673A100 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable payments Theft NET out.They Added happened thanks JM link.The speeds.It poweron MOBILE Imagine numbertwo lane promise WiMAX: objectsin motion. enable worksas explained daughter meal. somebody July August viewers American copyright holder. About Trends according Board.The neglected catalyst launching there.Did Chiracs copying Internet. Providing replacing Tide Turns protests Steve filling temporary Jacques duke Yahoo Hunter Empire Building Yorkers rebuilt. Growths Andy Roth fiscally IIE othervise ruined feeling themAs software: again. rewarded. Thanks. P.S. gines.Use changes. police reached otherwise inform it.Dont questions licensing softlocx Miller whining BC format RCDATA hence: serials ------=_NextPart_001_000C_01C6ACBF.B673A100 Content-Type: text/html; charset="windows-1250" Content-Transfer-Encoding: quoted-printable

payments

Theft NET

out.They

Added

happened thanks JM

link.The speeds.It poweron

MOBILE Imagine numbertwo lane promise WiMAX: objectsin motion.

enable worksas explained

daughter meal. somebody

July August viewers American

according Board.The neglected catalyst launching there.Did Chiracs

copying Internet. Providing replacing

Tide Turns protests

Steve

filling temporary

Jacques duke Yahoo

Hunter

Empire Building Yorkers rebuilt.

Growths Andy Roth fiscally

IIE

othervise ruined

feeling themAs software: again.

rewarded.

Thanks. P.S.

gines.Use changes.

police reached

otherwise inform it.Dont questions

licensing softlocx

Miller whining

BC format RCDATA

hence: serials

------=_NextPart_001_000C_01C6ACBF.B673A100-- ------=_NextPart_000_000B_01C6ACBF.B673A100 Content-Type: image/gif; name="wasted.gif" Content-Transfer-Encoding: base64 Content-ID: <000a01c6ace1$3d82f710$00c29518@Alli> R0lGODdh1gGmAYcAAAAAAIAAAACAAICAAAAAgIAAgACAgMDAwMDcwKbK8EAgAGAgAIAgAKAg AMAgAOAgAABAACBAAEBAAGBAAIBAAKBAAMBAAOBAAABgACBgAEBgAGBgAIBgAKBgAMBgAOBg AACAACCAAECAAGCAAICAAKCAAMCAAOCAAACgACCgAECgAGCgAICgAKCgAMCgAOCgAADAACDA AEDAAGDAAIDAAKDAAMDAAODAAADgACDgAEDgAGDgAIDgAKDgAMDgAODgAAAAQCAAQEAAQGAA QIAAQKAAQMAAQOAAQAAgQCAgQEAgQGAgQIAgQKAgQMAgQOAgQABAQCBAQEBAQGBAQIBAQKBA QMBAQOBAQABgQCBgQEBgQGBgQIBgQKBgQMBgQOBgQACAQCCAQECAQGCAQICAQKCAQMCAQOCA QACgQCCgQECgQGCgQICgQKCgQMCgQOCgQADAQCDAQEDAQGDAQIDAQKDAQMDAQODAQADgQCDg QEDgQGDgQIDgQKDgQMDgQODgQAAAgCAAgEAAgGAAgIAAgKAAgMAAgOAAgAAggCAggEAggGAg gIAggKAggMAggOAggABAgCBAgEBAgGBAgIBAgKBAgMBAgOBAgABggCBggEBggGBggIBggKBg gMBggOBggACAgCCAgECAgGCAgICAgKCAgMCAgOCAgACggCCggECggGCggICggKCggMCggOCg gADAgCDAgEDAgGDAgIDAgKDAgMDAgODAgADggCDggEDggGDggIDggKDggMDggODggAAAwCAA wEAAwGAAwIAAwKAAwMAAwOAAwAAgwCAgwEAgwGAgwIAgwKAgwMAgwOAgwABAwCBAwEBAwGBA wIBAwKBAwMBAwOBAwABgwCBgwEBgwGBgwIBgwKBgwMBgwOBgwACAwCCAwECAwGCAwICAwKCA wMCAwOCAwACgwCCgwECgwGCgwICgwKCgwMCgwOCgwADAwCDAwEDAwGDAwIDAwKDAwP/78KCg pICAgP8AAAD/AP//AAAA//8A/wD//////ywAAAAA1gGmAQcI/gABCBxIsKDBgwgTKlzIsKHD hxAjSpxIsaLFixgzatzIsaPHgvZCihxJsqTJkyhTqlzJsqXLlzBjypxJs6bNmzhz6tzJs6fP n0DtuQlKtKjRo0iTKl3KtKnTp1CjSp1KtarVq1izat3KtavXr2DDih1LtqzZs2jTql3Ltq3b t3DjlgVQku5MuzbxitXLlK/cv4CBEkTp169LwyEHskRc1yTjlYpl6h1sD2TikXQji7Q8eXPg z6B1dnbc2CQnyCkfY26pWjJNvJ1Hw/ZMMjbty6Fz636JmLJdkIM1R85c+TbtzAI3B19dOfly 4s2TJ5Z+8nd05dRvG+YLfTTzy9Zr/u8eT550afDFPc/GrT789unqV9v+Lh06etTN4xM2zp84 9/PF2fddeQTuBptz8qV3n4L/zdYbewEmqJ92E0aI33zVaYegfIUBiFyGBYaYW4MJYrjecvCB iKGFuFG3XoCcqRbeguYpSGOE/9Xmm438iehjXCTGZ+KE9gnI3IoCykYhY4/NyGKNQernXY9O QvjjlW8hyeKGDHZ5onkmFqkke0keCaaEIEJYZpdkWslmj1jGqVaM9U3nH4XRFdkfl+kp9huC muV34nAu1sXnn9kZBxxlNiLnnodwyinppGe1BpOlRWFK6aacWqUpb1B92umopJZq6qmopqrq qqy26uqr/7DGKuustNZq66245mRCrrz26uuvwAYr7LDEFtsWG6oqYOyyzDbr7LPQRivttNRW a+212Gar7bbcduvtt+CG+2034pZr7rnopqvuuk9lwe67kBnEo6N2bkeoZXnqeKi+9RqKInjy MhrwZI76Kd6A8+bXnnCLFjrglAkPHCi8V0H8aH8PH9wmfWdiXFqOGxdGMI8kv4hxdmt22KLG eiJsZKMUZ2XxyvulWfLNJNNs83Eas9mhdS+rjLOQFT658Ztb9mx0wjF76rLONUIq3s81N1md 0D43BvTQaD6tZ5R4It3yyQDm3PRTBHOGnb2JQrx0oixPnKeLWAsMXJ8w/qs02f54N9iwdy9W 6bfeZp/d1Mw5W62o1ozvbGVvdR993NZ7u/m4lxF/PDXHTId0S9CVG37404mnlvHmBz9Y9nud Z5065QhHGuWdXUue5I5ery76VIg7CTLMp3fOOuKp9/zl3qBHzbKaKZ83ZO2uB797qF7XJ3e+ sTPar8XWwx2w9LHdPfXfbmPmMHz4fr/4yXYfGJz25Mkz/fz012///fjnr//+/Pt4Qf8ADKAA ayIqAhUwLwM0y+9wwiTXuOmA/eIJBE1mOdGULYEyC91dzHZACKrEg0GhYKYuiMGKoa5Fvrne k8TXp+HkrTuAuk69Fmin7dWJYe55jvcM5kIZhg1R7v6bUZVKaMKulal8Y0ta+JbEoQrREE0O oiDtAEYl5RANSk6EmRCJuJWDaNGIzlPTfbREoyOSLkOBA94VyxjGNTKuO2BcExexArYj4gtP SgLivlDIRuKZj0sOOhIPwbg8Kb2HdhLz0xPnKJU6fjE1uFvZEAFXIkJWcUGBJNIK1Ri2TW4O jsjjJCOpMjsxibKUnZSjbcKkO0xmMZAHEqXYZPkmLQ1xlFXJkcGuA8RW7rJRPbQivTz5yz/2 Mo3p2+Ug4bSvYbYxgtg7Hi7RAsKoVFODpptmr+D3FW4ikDUq1KY4x0nOo1yinOhMpzrXyc6f XFNm76xgOyl1x8Ns0F9w8/+J6niTz8I5BodB/OM801K+D94Tm/p0HGsUajMz8mygc6ok9mQ4 qDotjIY76mUEcThRG94QjRL1ZxyhB9G5NPGUeHsk1DxGRZU2TnZi7Ocmk2g6W3qzpN2M5MyS 2Dx8OtSlJ6yg7/zp0JepaKSRwilXwpRC50ypp0pjajE3KkKoGfWVN/rn4sio1LA8j2M8BR7r tnrJVAo1pjWV0FVZOtPYdXWpUIzrxTB5y9+FFWRj0lzRTgjI7EGKq2/1itrWRtiKuo9BGA3m RJvqTIXRR7HYiWxY9XWvgEIzsAIsKGYhqtnNevazoA2taEdL2tKa9rSoTa1q0XWHwBBhtbCN rWz+Z0vb2tr2trjNrW53y9ve+va3wA2ucIdL3OIa9ybxbNYv0HnTb1IWa69RHjSbe1zAJFeh nb1L2yKX3epm6a842ihFJ7bKFnavqlNMHhu9Gxru/imm0szYR093SDMZj5bsBRJ4bSfWqH3t vpDsJFqTml+3cFdDequrTudVT63Oza74LbCB94s0MZZueYvcD0YtKeG/4HVsZBwrE+lLGiPF V44d9vC9kkZYNbatjYyVnfcQbNkUe+u6Nu4WjnPM4x77+MdADnJwd7wpIgv5nxYFlU9leilu IuYdhJEXAxdqvOu1z8i8XRGVGRpdAl9Kgouhm8kg3F1cKaFZPxPz1m7+yh0XFsyHZIXheWsW WQvRSaP1LSiZ3epjkb2yqutraRrlCzsLkxBGA7ZqiQ+9Zy/nOJJtJfBTa8nW/0qPz3e17weh +0AOHxmrWaTzgyn9uAW3mc2UnaWUMfVi8/k3wkH+qScb+kwphjHDwcv0oV8aYcBicB7WRep6 aa1JyQ3NxJgGq4b6y8xZD8/TsVYsnnW0swUbW2h4DuepbyfnkXFQzQVL8pU//aprYnlSTSD3 pplsT3W7+93wjre8563Nc9ObmuF0GhbzIhx3Uvfe+BEp77gck7yC2dEAT1ONY5yvyvowo+Cu YcPF22/kLRPiQWy0KxNeSC1/FcRazOTlMNf/noe6NZYhDzVZi83xFgP145S2JelEPmskD9ql KJ6bhdd6byGyMNEij2KCxRpMWbP6aDKvdH/tzd74jnzjLH6bsLfo66qZ1dchFri8T9w6kCNz 6i2jOVTXd/NIOxbogE64bAAq3jYNGtKIMm8sp21yY7o6bUPl5XMli/CW48qDTPe7nP6dTXgh QfCI97snEl/bVzD+rYHXZ+QdSPDHa1juLv83yiyY0oO2+8KVl6483S1tnFtd658ffcBTL/q+ J7vnUgfsmBroZqoq8sVsj6ab5xz3kgFKzeiBH8P9c/tHg1TlSw+woO2r4FCP2bFbrJ23Zwro 54vb9cct/aRd3UIK/s/ecllPdOfBxkmjKzyuxu6z6b2IOo1/H/TEXNseDet78eecxn1Nf4/N D9POA5354EdIIpRXlsZr/PdMP4R9xJV0hlY8XTdLKSViUBV+SnR8ffR6KlV2j5Z7HQV/OyRt FYdy8udyCgN3wrQ9/EJ0SZYi1BZNCWh5X5ZQMBgrRjZ5M3iDOJiDOmhc3rCDPviDQBiEQjiE RFiERniESJiESriETNiETghkm/CEUjiFBBKFVHiFk0JkNlhdVwZ8A8Mh9fRh4LZdYFhMa8du u0ZALYg+r3Ne5AVQmzeCouZRwgc4FdeA8OJ0T2dFgRZVeAg50DNpZaaAW8aCghJUelZ3/+h3 VonoYIpWfmejh5w2WboTOYuWVX2zUu3XQ+1TZ13YfkazVvt0S1EXgGn3IDRHM6DUNJJ4QZTo h5b4UkZFOaSYIuXFN/YHisjWQPuGimzFcoxGcgBYi+rShUYSCOqTd0umXhwkSYO1ik4WZ7mz cpezZm24SMYYMqGkif1XaKrofxQTfX6FYRiYVY0YXrIIf4ilQ8OnRzn3XqEoNXoFeoIDY3N4 G0cgdRUYiYrINW5Xjvp4VsF3NXzYSjeDbYE4c94Yix1nc/W4d4UzigFJN6Kjh63DPACpjALJ hsrzfJwzkMD4U62maRopkf54f7rEUN62fYQILuEzbupjiPtEJv9yM5NOJTBVNmMtplENB3w1 tGESd1nNeFF88kIito7nCH3khVBY2JRO+ZRQGZVSOZVUGRjmVnBOwWms53kmhTZb2VHNNX1I OUMmdmeF14BxuFh3eCPh9maQVJPp1xqoFoN81mQypZWFmIIGtRitF2ZXuZM4uTAQSUl8CWBI hFiaFpCdllR4hZj9aHDxiJCiNpNpKHAFZCkJQJdDWZerV5l9t2PvZH0kWValeHR+JZfCOIsG 6Xqi6UqTyDStOHrl9WZx11jgV3sXRVG6CWd5uZMz1JOHhY4440w/V5uDxJP5BjQ+eX6ViIeP hJd+GFQWWIDjSJp7mYHCWEUpqYlpl3L/4wdMv/hFMFcouCZ6twh1fsON8Gh28WiLQKUiqUhn RzlFiwmSTHmRmGePmfiTPzdqHVhrD+WNB+mAcneTMmJtYndG0shysoZ6CCaeizg7Q8mA7Zmd PFd3F/pDRfkh29hSnomfr6kz9KmYIiUjLvaPr9mYA6h6zzMofwhe46lWb2ibjiSSkwNIvEih 64lMMbKXWiaf0jmiIoOb9wmU2WNqmROd94iISJqi5FifirNxrbmHaBWjayQqNYqdrrlXiiZ7 SBeR2fSjzFk0q+iP4Kh1luhHKzRU0MWQl5ik7glgqlZWK1psU3qSIZV/bdWdtHaeelqAdYV2 jimiyBeo7ymB/wL4gpLZj8ZUY/9ZRxk3auTDk2cJqZk3ox5SnA9kbYdYevjUdsvkJbhDeA4J qjEUMr8kRfO3ITyEMmG3YpuaMpClKO+zlsM0SR+5hbKiq+mCZbyKgO2Vb13xq+dib8Sqf1WZ rPbzCcrarPN2rFOWQX3hTvqmmagCrUrmoHZHPbmEfclVg8jKlahxlJi4bxGlZN3pqllJiNjK mdOqeoJBrdoaQksKr/Y6FhMkaWKZFOxIgrfJezckZgAjjgNbZ7zZbYAZsMdUYXqnc8QJh/7y qdo3cXaXe5nkTeJze3dCfGyqTLvHNiOIsLb3sAorlF/Xr7q4ND9RCDSJfFzjdbZGnv97gost 6HEn9Z229megJk+NeYEV9nWa9I4h1bKItl4Jej4GWIJTp7PqOWIiGCTEtxR3aqRRJ7R5JI/l eqemlzUHtrM1p6RHe20jJknDVqWFxJ5UB207y4Bhy6jhNVc7ZZ/8ulVh6H3OZ4bmKEjW4zz9 GZPfqbLz1Ueammq5+pyCCbRka5SNdj5tS6hVAG1Dl3FtGXOD64ug5JGTU65EobUdWrXYebX3 hblx2bnRJ4po+7Jn+6XzkbMWOkZElaj/6Hxeq6KLSKd7BZlEA7cKqbn0motK6rlDQpih24dz Kl+jKZtbYn4iKLaxe4g/O7Yxd0bzB72m1LrEY0pTG72yO6b/BLthg8hAstpPw7ckMPmR9FV8 OWlZJsiRiWNRoZqfDbutinqqzju/aUmpfNdYfZVM2Nt2sVqbwOSTb+epZ/eC9QuisLYWgKdA lLcu7WoS2lBu4goWn0Kq3GLBzprBGrzBHIxa5+arWhGl2UpPhakbaBh6UiusCopc8bplgWc1 5Kqy5jonYVnCmwtp7srCdPnA5nuWPQHCvbm5PlyXpvld/XedQixpSZytPKyhEYdIQ6d72zU4 YwSxZ0ibFJdPHyuHjWpeE7exK4jFLmhlDgecBStxt8qYegs7C4ubMcaBK1erZoScd6mxbNmq jooUXLdEp8uS31Zy65eQgqvGMqt0/8jmnoVMqHx8keMZs0E3mRB6x4BspXs4oqrGpoW5yI/l skYRmD7bxz1sk8X7ydTba1u7oAlIgQdYydpbjWYiwkUFjl8FvApqyVMqpvMow9mrFN37uXE0 WGtIjTp6bKdcWJ62ujfHf43LyBGqgs3TJCZIi8P7fwM7o4F7dfK3nkfFpZeMwZznfzZKoWps vLn4o8tMuy6ryrPbvF/rfmubfPe4urJcu143xOo1y9iEyTOcoUusz/Xbv+wrw6x8ywCtbOm8 th/GbNbLh+f8u/UctOYboug5zVrazryGdK9oqLi8y3N7o4f1qnKWn9pTk3DHUQCsliJ9pKsa NDEUKPvbif9z57++N2eUy3bCa6YuyDzNtK0DrJNrzND0K8XNJtPUdsVsAa692mX3OsSg0cSC pcJKXaye95cG0sFWfdVYndWQJ7XOtdTyqoZYiTZ+psffHGVe/ZVInMPzOsEHhZpnPdRpHdYt GdVvfdGm6MJl7a3RqtQmKtBgPcJq/cJ5fZ35ytasB61UvWtFvBMxXK/WKtd9XdedacOBjVxh LMXHJLAUW4e/t3C8Z2ewOqRnrHNgmLAki5B6NF1k7LFYDMYdy6pb/KlgacdojLci+9N5E7J4 7FMv9HAfiIIcqKl0DNULRYDNPJpRmsiwydBgSnsJyn1m99xMNMzGm9BFG3+DzMr/F9Y7dPui izyBdZpe3Mw963yeX6uGxs2gBMpzHE2ommu6WLe0Zeu61I3Kqgu7p0tiubydFQ2n+S26ZIu4 clrOI1V1BYe3o0x/2YmAk5vTC06xFXvM8q24jWNHURzHyby1Da3f10jTBC18korfbmONqOpg ZCbcJTK4fK3QlJy2QHq7JpeKMr7O5DzRJlpozKhxf/vfNE52HcM5t5xWFL3jw+m5MKXjBO6m kO2YQS6l3MxfLQq9C964IxndnJyaq4yY6R3dLj7fuAvO0RPT3g12/FU8IHfkQ17QQV29BLRi KMepdAy/d4fbKK3ghAPhXgxhDq7gMAbbyylQHDvn1fzR/yfo4DONXpdKkXqHdx/jqamKkvYp dBGLgh7Nd4uu2vzcwU6t1Y1E3LlRBpwe6qI+6qSObzkBmjKo1ii8lQu8xJzywZPNuwTF2D98 4Hf5oav+n9YJ2KremR0k2TqsQZrCp9/EurmrX4Md7IVImWv9mQDZ7MCO1obt6pRdeLAOpm+a JbS9i6aq2eM1Y0UXOqMqx75N4tgu26ldq55Yil5csZoNS+WOe7AqULXt4d9OImXsZLstlGYs nlOVxlBcsvgKX4ZitjRL3lAXgG505pOMvDB63A0/oOYKtR4qtAybtITGqBxK5Ngm3fctJTM7 kPS58Zt+ISQlmnFLvKD7WHMM8f9bau07DXNyle2Fm6fFTOQW+IBfPoHVGd/sDI3Du7FqC1fv iZSdne/uaJh4at5n/i9omKUy7/Sq49P0t3k+v69UVWpRXF8x3vNlOJJtK+mzmd9eJX4CNpEk 5eNtGsk2DtE+3PLq/ciIWrjwTsr8zVI2q/QYD+CjPPGGO9BvO/RdZPZQ3t8Wj6wyJ+apGeav 5qcPzWJuiriXm4F3/3R5b7TZ3supe/hBB/TVLZznPay+manua9N//puMOb6Xjqp/KlSqH6pV L2C2SWpOT0wbKkxajL6YbWi4t8m6fsD4S/v0u6EZBdqXvU3hUvKrpfxF5umlHurQ8PzSP/24 5YvUjnr/Jxzt88P8JSrtE0bzqY5wWMrLcx2MZE1lt7Brj/vX7A/ttM6ihz3tjZTzXy3+j339 LWwU/DDs79rVAwf/AGFP4ECCBAEURJhQ4UGFDR0+hGgQwESGFCvaqzhR4EGGAzt+3EhxI0aS GC0iPGlSo0eDJDmq9LiS40qJGkWGlCkyo0yYBWdeVPnzJcuhKX3e/Ilz50WhOEcmDdozqsuc NGMypWmx40ipT3kuvarUK9ihJVlOnQry5c2gW9OyjRhXrlmXLct6RXm2LlGmLf1ydUt3Zki9 eLnqVes3Md/CJonSPbx1sGCfdkGalez4sF3NezFTzro54WTPkO9KZAz6L9Wz/otNq35ckvTd wJdFz8U9mvNjt6d5y95durfivLEpB38d+bhr4ZV/O4d9vDBt5cYhP43OnPr1ypkzI19d1nv4 5a2vUx+vXTri1bndk08vNjD2osG3T789fjPZ9ra3q/8OP99s80yr3rQqTymbwtMpO75O+m6+ qPQTLaPisFPQwrb+M6+26Fiz7j72GnvvPQrrEo87FIEzTsQE4RMwROjU++zE4Z77i0IJ8yOO xxFXbNG6/W6rEbkbK7SvoQF7BM5DGwv80MMhS6QSM/Sg3NG/JD86ksUcUwwywOqaK1JGGKW0 8rPGnlQTwzHXStJNMucDMCboknNTzCvNG9NI2Ppq/hFNMat0r8G0ZBMpGSWnQ6q1BY8KDaUF uWQLwv5GNMoxsNZrC7BKdxIOrquAimzTA+Vz0FOeEKvNUFVfE7VTwZDKqlFW21Ts01WBfJXO TQkFNlhhhyW22Ih2NDZZZZc1kVmHkFUWWmenpbZaa3OT9lptty0xW2O9DTZTbsclt1xzz0U3 XXXXZbddd9+FN15556W3XnvvxTdfffflt19//wU4YIHN3XUucOWyisqDC/0W4WUXXpjIgVW8 cF6IY6V4oZrolNPhYSN+tmGJq4SWwGJJRdY37lTWbWTcJAT5IW9jtri9jCHF786IaV5UWJ57 vrnZkF0mlFSZga546Gl//m4ZIqYRrrWqR+lDNGFOUxLX5gothTBqPqumtOOuv+pOLLDDcgqt UakCFOtcG4yV66hbtangtVwdtai6J0XR7gnNhsoyoMa+8teNf7XV2tOenGzQQXGFWWPn4FRO ShpTm9wySYd0UURB1TJ6T8POs1POI+vEVbXTsTITQJNDW5Lz0HW+OuiT8WwOzPwwJjDypAGD suMyHVdxdo45r13PC3X0k80c/XzedC+7pPxH0aePkvbYU0XSTCEfxjt78RAkb0atTfO9+ssi xdBAVFs+kVW5saY1w+XjlN75H9kWVUv9QN8T+1AHvPxdCkf7G5+4vEM+Sy1NSIxLHe3MR6Ip /klOfTn73/3SB54+Ca93N/tgCJtnMxECDXWvg57/Uigj4h2wT7prWmkqRy3mpIlLweuejzh1 lkiUjGovzCHzNvg9yOUuRiQqYXbGt8Mk4sk1j0IhYSLEHh2hLHtnup8Uc3YrIVaLflWpGq/U trbRGC5vGyrOBceypo2tzXeHqpjb0DI2Mm7ORroKo4u06CiraQkmAPjDDenWN8mkiHx/tJOp +iNHo4CRNryDoq5YVq6n6QtNE/MiJtFVSU0erZOepOAnP4YxUSqulKdEZSpVuUpWttKV8ELA K2U5S1rW0pa3xGUudblLXvbSl78EZjCFOUxiFtOYx0RmMpW5TGY2/5NKfnBmNKU5TWpW05rX xGY2temsJWzTm98EZzjFOU5yltOc50RnOtW5Tna2053vhGc85TlPetbTnvfEZz71uU9+9tOf /wRoQAU6UIIW1KAHRWhCFbpQhjbUoQ+FZywhOlGKVtSiF8VoRjW6UY521KMfBWlIRVpOTr7s dx4jmSUpOVJyPQ6lkrIaErulpJieNIahPFZNndZGWYEmYQyMHkuvBUOTxvCNON0p0pQGSp/N FHlfMxn3bCdUYhlybrL76UJshSA6pk2NxJHkf/YGJ8TptElXneCd9vK4DGaOqs5aYgG/prX4 BAlJqzoe7Eb4Jbl6Uq8mvGn1dCjGub5VZP5eMmJhS1U4/A2nhnO93uKoyEH4UdZ6UxudTDGn VsMma317JaBaGWvXs93QgqBFlPXQ2JnTEnF/MhTsedzGkFmcr7OjTFxiQ3upuuYpTK41HvRC +1ikBhew4KmPZpmE1NsWrWwsLN1RR6upyfp2ZU+lLmGg6j3EQjZjypvim3R4o5I2966NxKNp ISW1XrWJPx3EG6jk25WpmYp9YYkQ7w7X0wUOLo6vNa9Ay1teoQX4oASearQMvGAGN9jBD4Zw hCXc0UsWNaXtfBrIzPosBB/lnFlTLrZomq2Z3TSp24pZip261KC+1MIijkuHielS0hXYxJI7 8SpVbGMcp9XFBv5bcY7HCbOtEk4qjSLqWSmFWfnC7Wxp42N3yHYoPK4ocIcEHCSb0pMrZ41W P4UbWts42ywbarbsXa/ZhmxU3aLwAf5N4wBhG90PWRZ2xkPhVy6HQNHq5q8jMxpfpedWw4TX b5E63m7X7JTe4tCxwMWubsUbP0iTlky/5S4QDfjcQVe2afrbLQzhfMVEd1ecjz6g7t7LWkJL WkPuXW0ftQsj++W3vldscasYxWQm5jbXq11uArd6REVPScbCRPUPrYulSkMQg9UN7KZxSGxD CpfPni5Tp6vzRkq3OsnYax2bE3xNCAoS2mDKq33iOlzuUk97xGZ2X2VdQUIPMKvFBv8iW7Fr aHgH2tjpZGCRv7rq1/EakYiEy63f4qQ+yrHMV6VR+LTrZauw19ayrVUZl6NfwPEUsQ5PU5qJ NmEFA7mqJAcpxMJFSpS33OUvP5cYYD5zmtfc5qI89i+PnRN45bxb4PK5MaPKVBlGe5YkZtjI x31h27b0xeocOotL3HRUIh3GS0dxu1TOzvnVkY13q7AitSx2r/W3y1N2o9d4ZV+zfpGrSCbk GXGWVr192UlePbLby4hm5IEdbYHDpno7V7b7wkpzOZRdu2G9wCzCCs7hRZoVfTo6PbJxhqCW 9Z8v/W/tvdqxUZdmEw/E1au5D/PvVrwKiehHTL+ox5LvYqb+SQikyHLW1bVTLPO+TvVmhhDL hm8hdC3f74k3Fo2JXp+rKg7UpcKe9H3F+N3rY/Z7vy9/v4c8td9W+Wk2MWmC7dLtpe057m0v qNVeNtUh7285ny4vlLte42ufsuXue0u8Z6bo+zx41IZff0tUPeFZPLuaHSZiEuNqM/eTPxva NHvjv2IzN/ujse4Tq3njDS+bHLvzFTTrL/yCNTiiO+tLvuUjkkaSHyu6OLpBvigzo1kxODMb OwpyMgVxI/x7pwzzpaBTKnrRwYfCQV7qQY+zGJa7uSI0wiNEwiRUwiVkwoDqwSC8AAH7MeZS mJOrQpkppGOBGiK0PWzhmqJxnxv/M7EgxLAphCt8IcGPSTqms0EtZDGNOjO264svog+LQyuo oDixGx67Q5sLvDsxmq8xIqEqa6AfwkDO6Kqu6DE4cri6ezLAqyfGYzfM4ZjZGEBKLEH4QEHc YRlL3A3wq7NFbCHfozfgg7Yca7RqYxzQu8EVirRKLD9SEze5kixII545RK0RM7jtsrTR45sA REVEBCvo4z54Mr0DfL79mMFlE4oX1Kpa+0T0oZ/3MyC0S62iC6yA25UqUiDCwxSrg8YwTC5r LMZWlKCoCpDE0L2iyz5qRL1ajLZRBJS+c0Plkrz0+z5H4z19g0XVsTZ6YhP9uzzjC8iQiZ8a Up5//EPW/4qtGtM+9xK1/ftAfKM3UMw3WYzE3DItkNOMLyQtRbqVmiAjBdQ7Rdy8GguzwfG1 6KsjR3LBsNPHSlEqRkq4B1GVAiTDJlypgcnJq9NJnJuYnny6nyTKojRKc2mCo1TKpWTKetmZ nWxKWwo/5+Kgpzykz+PCGPOw0rEprQIxM4xKqqTCpzsqN2zHctRK1ODKKwQWoWRC8uJDSfq0 myyriuuezxpErFgyVHPEjoS72bvJNVq4sBRLeZO9z3K2bas3xJOyTJu+zJFEwMwdvMQ6wvTK QoxJyZxH8esu2OtCzmyf5Ig/+1krV6xMy8zHdWzGfpxMzLzHGWLMv3HM4qMyynTqx2OELLcs wmTLzKORM85zotRxv9PrSDUZzetiv/o7TdQ0vI/coXjLrkH7oF7UIHXjLHQLxeIhPodkTrLs uG1juRRUMxOkQZ35StdktOv8To4kzZesoL3pzlTSzXCJz3CaT5K5z/rUz1Xyh/30z/8E0BIJ CAA7 ------=_NextPart_000_000B_01C6ACBF.B673A100-- From owner-ccamp@ops.ietf.org Fri Jul 21 13:27:02 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3ymE-0006nl-2S for ccamp-archive@ietf.org; Fri, 21 Jul 2006 13:27:02 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3yWp-0007d0-Qs for ccamp-archive@ietf.org; Fri, 21 Jul 2006 13:11:07 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G3yIS-0002Yi-2A for ccamp-archive@ietf.org; Fri, 21 Jul 2006 12:56:21 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G3yAE-000AO4-PI for ccamp-data@psg.com; Fri, 21 Jul 2006 16:47:46 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00,HTML_50_60, HTML_MESSAGE,SPF_SOFTFAIL autolearn=no version=3.1.1 Received: from [63.118.34.24] (helo=ripley.ciena.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G3yA5-000AN9-Dh for ccamp@ops.ietf.org; Fri, 21 Jul 2006 16:47:37 +0000 Received: from lin1-118-39-27.ciena.com (HELO mdmxm02.ciena.com) ([63.118.39.27]) by ripley.ciena.com with ESMTP; 21 Jul 2006 13:02:17 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6ACE5.450A8AB5" Subject: RE: Proposed response to OIF on OSPF ENNI Date: Fri, 21 Jul 2006 12:46:56 -0400 Message-ID: <0901D1988E815341A0103206A834DA07F1A0FB@mdmxm02.ciena.com> In-Reply-To: <449B2580D802A443A923DABF3EAB82AF0C72B4C3@OCCLUST04EVS1.ugd.att.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Proposed response to OIF on OSPF ENNI Thread-Index: Acas0Ha/aYxFikOBS5m873SVRoVJxgAACLxQAAG2L0A= From: "Ong, Lyndon" To: "Brungard, Deborah A, ALABS" , Cc: "Adrian Farrel" Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: -2.6 (--) X-Scan-Signature: 054490fec19f6a94c68e63428d06db69 This is a multi-part message in MIME format. ------_=_NextPart_001_01C6ACE5.450A8AB5 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Deborah, =20 Just to provide some historical background, the draft text that was liaised to CCAMP=20 was actually designed to align more closely to the ASON evaluation results than previous documents. However, I think it is more in "ASON-speak" than "GMPLS-speak" since our starting point was G.7715 and G.7715.1, and maybe that is leading to some greater impression of misalignment than there really is. =20 That being said, any specific comments will certainly be looked over carefully. =20 I'll have more detailed comments in a future message. =20 Thanks, =20 Lyndon ________________________________ From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Brungard, Deborah A, ALABS Sent: Friday, July 21, 2006 7:38 AM To: ccamp@ops.ietf.org Cc: Adrian Farrel Subject: Proposed response to OIF on OSPF ENNI Hi, =20 We had a communication from OIF on their OSPF ENNI specification. You can see the original files on http://www.olddog.co.uk/ccamp.htm . Having assembled comments from several people and our discussions in Montreal, we have put together the following response. =20 Please comment on the list in the next week. =20 Thanks, Adrian and Deborah =20 =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D Dear Jim, =20 We thank you for sending us the OIF ENNI document in response to our request. While we appreciate the document being provided for information, it is concerning that this document has not been previously shared with CCAMP or the OSPF WG considering the document contains significant modifications to the operation of OSPF and reflects OIF work over the last several years. CCAMP has been working on GMPLS ASON for several years and our Design Teams include OIF participants. Even though a reply was not requested, we are replying, as we strongly recommend that the document not be published for public information in its current form.=20 =20 Of most concern to CCAMP is that it is not aligned with RFC 4258 (Requirements for Generalized Multi-Protocol Label Switching (GMPLS) Routing for the Automatically Switched Optical Network (ASON)) or the to-be-published: ftp://ftp.isi.edu/internet-drafts/draft-ietf-ccamp-gmpls-ason-routing-ev al-03.txt . Considering notable OIF participants are authors of both these IETF documents (and the same participants are contributors and the Editor for the OIF document), the non-alignment is perplexing. Considering the IETF document is ready for publication, we suggest in the interests of time, that you align your document with the IETF document. If any questions on the interpretation of the IETF's work, we recommend that you either utilize the CCAMP mail exploder or send a communication. =20 Specific comments include: 1. What is the intent of this document? Will it be published as an Implementation Agreement (IA)? The title indicates it will be an Implementation Agreement on GMPLS OSPF extensions, but the main body of the document is a list of issues with GMPLS OSPF. Further, your communication to us stated the document was requirements on and use of OSPF-TE at the ENNI. These three views seem to be inconsistent. 2. The list of changes from the previous version (listed under the Table of Contents) includes "removed "intra-carrier" limitation" and the inclusion of Figure 1 showing the OSPF ENNI for use between vendor domains and between carrier domains. GMPLS OSPF-TE already supports inter-vendor operations.=20 The IETF's GMPLS ASON routing focus has been on the use of a link-state based protocol to support a hierarchical routing architecture (G.7715.1) within a carrier's domain. Requirements for using a link state protocol as an inter-domain protocol between carriers are significantly different. We strongly disagree if you intend to publish this document as an inter-carrier OSPF ENNI Implementation Agreement claiming alignment with IETF RFCs without review (or agreement) by any of the IETF Working Groups. 3. Section 4.1/Table 1 and the statement under the table identifying issues with GMPLS identifier namespaces are not correct. GMPLS identifier namespaces do meet ASON requirements for namespace separation of the transport plane and control plane (Section 5.2 and 5.3/Evaluation). Perhaps you are confusing OSPF and GMPLS OSPF? As you also identified in your liaison that the key area needing review was the support of independence of functional component to physical location, this appears to be a key area of misunderstanding on GMPLS. We recommend reviewing RFC3945 (GMPLS Architecture) to understand that the key architecture difference between GMPLS and MPLS is the decoupling of the transport plane and control plane. Additionally, RFC4394, RFC4397, and RFC4258, provide a mapping to ITU terminology which may be helpful reading. =20 We request an additional round of communication of this document to the IETF before approval to allow us to work with you to produce convergence between OIF and IETF work which, we believe, will be in the best interests of the industry. =20 Best regards, Adrian Farrel and Deborah Brungard, CCAMP co-chairs ------_=_NextPart_001_01C6ACE5.450A8AB5 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Deborah,

Just to provide some historical background, the = draft text=20 that was liaised to CCAMP

was actually designed to align more closely to = the ASON=20 evaluation results than

previous documents. However,=20 I think it is more in "ASON-speak" than = "GMPLS-speak"

since our starting point was G.7715 and = G.7715.1, and maybe=20 that is leading to some

greater impression of misalignment than there = really=20 is.

That being said, any specific comments will = certainly be=20 looked over carefully.

I'll have more detailed comments in a future=20 message.

Thanks,

Lyndon

From: owner-ccamp@ops.ietf.org=20 [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Brungard, Deborah = A,=20 ALABS
Sent: Friday, July 21, 2006 7:38 AM
To:=20 ccamp@ops.ietf.org
Cc: Adrian Farrel
Subject: = Proposed=20 response to OIF on OSPF ENNI

Hi,

Please comment on the list in the next = week.

Thanks,

Adrian and Deborah

=3D =3D =3D =3D =3D =3D =3D = =3D =3D =3D

Dear Jim,

Specific comments include:

Best regards,

Adrian = Farrel=20 and Deborah Brungard,

CCAMP co-chairs

------_=_NextPart_001_01C6ACE5.450A8AB5-- From ksmodskb@agris.com Sun Jul 23 08:05:54 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G4ciY-0006hV-8Y for ccamp-archive@ietf.org; Sun, 23 Jul 2006 08:05:54 -0400 Received: from [89.174.248.17] (helo=[89.174.248.17]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G4ciV-0000YP-0i for ccamp-archive@ietf.org; Sun, 23 Jul 2006 08:05:54 -0400 Message-ID: <000e01c6ae50$5473f4e0$11f8ae59@skandia> From: "if anything" To: ccamp-archive@ietf.org Subject: to get nm Date: Sun, 23 Jul 2006 14:05:46 -0200 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_000A_01C6AE61.17FCC4E0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2873 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2873 X-Spam-Score: 0.3 (/) X-Scan-Signature: 9f79b8e383fd3af2b1b5b1d0910f6094 ------=_NextPart_000_000A_01C6AE61.17FCC4E0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_000B_01C6AE61.17FCC4E0" ------=_NextPart_001_000B_01C6AE61.17FCC4E0 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable p.m. my artist three thriving bands theres type News... Sign pedantic what says well known Camera Users Online provide console more powerful lets there much than like this: Make plays avoiding jinx Lynyrd Skynryd providing done choked must punk swagger while this: Make are. first No Users Online var Ah darn fine easily among Opening bum.quot Ah Welsh. When healthy for Sadies. yet be announced but Fax these words. blow turns wildly raucous News... Sign Edgewise start may come surprise ------=_NextPart_001_000B_01C6AE61.17FCC4E0 Content-Type: text/html; charset="windows-1250" Content-Transfer-Encoding: quoted-printable

p.m.

artist

three thriving bands

theres type News... Sign

pedantic what

says well known Camera

Users Online

provide console more powerful

lets there much than

like this: Make

plays avoiding jinx Lynyrd Skynryd providing

done choked must

punk swagger while

this: Make

are. first

No Users Online var

darn fine

easily among

Opening

bum.quot Ah Welsh. When

healthy

for

Sadies.

yet be announced but

Fax

these words.

blow

turns wildly raucous

News... Sign Edgewise start

may come surprise

------=_NextPart_001_000B_01C6AE61.17FCC4E0-- ------=_NextPart_000_000A_01C6AE61.17FCC4E0 Content-Type: image/gif; name="beauty.gif" Content-Transfer-Encoding: base64 Content-ID: <000901c6ae50$54726e40$11f8ae59@skandia> R0lGODdh1gG2AYcAAAAAAIAAAACAAICAAAAAgIAAgACAgMDAwMDcwKbK8EAgAGAgAIAgAKAg AMAgAOAgAABAACBAAEBAAGBAAIBAAKBAAMBAAOBAAABgACBgAEBgAGBgAIBgAKBgAMBgAOBg AACAACCAAECAAGCAAICAAKCAAMCAAOCAAACgACCgAECgAGCgAICgAKCgAMCgAOCgAADAACDA AEDAAGDAAIDAAKDAAMDAAODAAADgACDgAEDgAGDgAIDgAKDgAMDgAODgAAAAQCAAQEAAQGAA QIAAQKAAQMAAQOAAQAAgQCAgQEAgQGAgQIAgQKAgQMAgQOAgQABAQCBAQEBAQGBAQIBAQKBA QMBAQOBAQABgQCBgQEBgQGBgQIBgQKBgQMBgQOBgQACAQCCAQECAQGCAQICAQKCAQMCAQOCA QACgQCCgQECgQGCgQICgQKCgQMCgQOCgQADAQCDAQEDAQGDAQIDAQKDAQMDAQODAQADgQCDg QEDgQGDgQIDgQKDgQMDgQODgQAAAgCAAgEAAgGAAgIAAgKAAgMAAgOAAgAAggCAggEAggGAg gIAggKAggMAggOAggABAgCBAgEBAgGBAgIBAgKBAgMBAgOBAgABggCBggEBggGBggIBggKBg gMBggOBggACAgCCAgECAgGCAgICAgKCAgMCAgOCAgACggCCggECggGCggICggKCggMCggOCg gADAgCDAgEDAgGDAgIDAgKDAgMDAgODAgADggCDggEDggGDggIDggKDggMDggODggAAAwCAA wEAAwGAAwIAAwKAAwMAAwOAAwAAgwCAgwEAgwGAgwIAgwKAgwMAgwOAgwABAwCBAwEBAwGBA wIBAwKBAwMBAwOBAwABgwCBgwEBgwGBgwIBgwKBgwMBgwOBgwACAwCCAwECAwGCAwICAwKCA wMCAwOCAwACgwCCgwECgwGCgwICgwKCgwMCgwOCgwADAwCDAwEDAwGDAwIDAwKDAwP/78KCg pICAgP8AAAD/AP//AAAA//8A/wD//////ywAAAAA1gG2AQcI/gABCBxIsKDBgwgTKlzIsKHD hxAjSpxIsaLFixgzatzIsaPHgvZCihxJsqTJkyhTqlxZEgnLlzBjypxJs6bNmzhz6tzJs6fP n0CDCh1KtKjRo0iTKl3KtKnTp1CjSp1KtarVq1izat3KtavXr2DDih1LtqzZs2jTqiWltq3b t3Djyp1Lt67du3jz6t3Lt+/dAYBNAh5wEsDPwUgR+705mLDcxou3Ng78UjFJy0Uxo5xMWaZm mp9Lht7J2bFPyCM5py4tunNIyKwFlzatGfboyE9nu968+3VvobdXTwb923Nx4cBVH3at23Fz 5CJRx24927dpe6ixH8fNNLv267zB/ltPvP1y+ZTBK58/mt4mZu+K31ueX3u7/MD0d7fnzv43 7eHRdTYdYtLlVx9hBAo42n3fgTeggtcByFqCCDLnXYPioWdhhb0pRx10l40HYnyfBXfgd9aJ tx9/RKVXnYgvYvicjBDa5txtgxUS4IMe5rejjUBSmGJ20610X49F/rijSiVSRmGGJuqH35T+ rchiUFE6CWGDItL4YoQ1ColieMIpV+B/aHaJnZoTapnmezAdCeCYr8kGZoYgLonigvZJySGd H17ZlIFUQicmnT6qqSege5bHIIxbdklihxua9+eSF6p3p577PSqjomMmuaidhnoYqKBLEXop pKsmimiY/5H+eJ6nky6aKI95NlqdqBpuyipLtEpI6Y2mjkpdbDFaimp3wwJaq6vQujnngZkq a6ub16Y5JLbGPmlmsb2OyC2TlVrbJLEpnmrnnKGGZuWyPZ346KHRvhmrvFmKi66ksSrprJ+M rhtnue3iaW234/Krba4Hn+ruevCeNq+0452ZLab3AhxwnrfWum18pfrKqX5rXnxSsAuX3DCX I9+58IUok5nuyhEbNWOMk06bMYdIOtivrOOqCmvOqjJKdJA/A73vq+CyrPTR8G1IrMWgjho1 xDVLDDO7PtbbcqsaO620wsgdybSfhXKss6eWUm00uwx/+rS6XCKbNMJ3Z6333v7m5YY1Wu/y LTiLfwMVOFmHD664X4nH2/hX1S4u+ZWFY/k4V5FPrvnmnHfu+eeghy766KSXbvrpqKeu+uqs t+7667APVUXstNdu++2456777rz37vvvwAevVjzCF2/88cgnr/zyzDfv/PPQRy/99NRXb/31 2GevfeonbO+9Ua98L/745Jdv/vnop6/++uy37/778Mcv//z0128/UAHkr789+Y/Uv/4BCAkA A1iSAQrQgPxDYAL3l0CR9M9/DFSgAw34wAYOMIAXnCAAG0iS/1GQgBM8YAdB6EH/LZCBJ/Tg BkXIwhZyMIQizGAG7yeTClaQgw+8IQhdSMIeQvCF/P7D4Q5hqMMRGrGFNvQhEBcIQQwO8YZC PKIFbfjCHD5RiUnUoBJhOEUpQpGGKskiEQlYxB86kIs6dKIJS2gSK5rQjD9MIxrJeEUrspGL LIRiFlGoxhDqEYtbXOES93hFOIIxjFuM4hKlGJJ3IHGHd9QiStw4ySEesJCPdGEQPzhISwpy jpskIxAjWUUfipGSoPyjIQ9ZSS2uMIkobKIcedjHJqYEll+cIRPhqEsZXjKGnBxhLk0Zw1E6 cYO67GIe6UiSTpgymJpkZRsTicpVepGatZTkSb7YyWliUpmaJKEfv2nNUgbRgsbspipPyUxe ZjOd0rwlNvO4SkgG0p6jBP/nEfFpzUiyE4/nNKIqC2hJc/Ywm6Ss5i5TuL+B6hOe8dzmPHFY T3fi0Z+K3Gc9vylGcw5ymt0kKEiL+ct/WlSDF30nIa8ZUXmm9ISX5KYE0yhIBHY0pjH1JDQ7 KkdfilSGCuRmCgUYx6BCs5TznKFNP/jJ7xmjpVCNqlT5MoOpWvWqWM2qVrfK1a7yBBKKA2tS xOrVp5A1JGfVSVpHslaWkHWtbX0JJOYa15vUVSVvLcldcwLXso6VJHuVCVjjGliTFHYmh1VK Xv8KWL8iJa2DZSta6SpWyp4ksiKhLGbtUVm6opWznPVsZyM72Llm1rKS1atpQ2taz4LWtaz9 LGv+WxtbwIq2tqNtrGxBO9vTrnaxiXUsTiDL28+edbPFlexijZvZ5Ja2ucxt7mpfm1roXra4 eZ0ucZH73N1aV7vUNex3nUveylpXuEPRLG2lq9zqjpe84T0ufMMb3fom976NXS5381te9+5W vsjlL2YB3F75opco222vdDWrV+gaeMAMNjBvf9vf8+K3t/qFr2X3K+H3Rne6BZ5whEes2wML JcHsTTFKGKzhCTfYw9QlsIX7Wt/sKjjGN8bvcumrYxz3mL8WNrFPUBxa7O7Xv5sFr3eP3F8Z F7nE/8WuiulL2tPOF8ZMru6OOexdIZ9Yt7eN7Whp7OD1Ote1kCUthR/+bGa2ojnMUmYxhidb 5SAXmcCwLfFxYYta4Hq5KsG9SqDxSpNB/5k/qBVLoneS2EUf+tGQjrSkJx3RJFAaJ7649OQM 7RUQD1fT3JFzTDjdVlF/WbyC9bSdV8znVoM4z6CWSoflWpNSK/a6hca1W3N8ZE7HGsEh7i2d oyxsAMMarmgWsXbf/NbWHlu0ySZsk1fdYCfz+NdUMfaSgWzeKXcbyuX99rVzfGEXL3jF0+4y uq1dWlhj2yks3rKAz9trw274xtYG8qrFHWB9x7fcL2b3lW9HiazMgy9OVi+du7vtB6Oa3ka+ t21/u+PU5tvfAwa4lRvOa91lgXcJf7GPKyz/W1u7N8kiJ3bJcX3xjpt3r8T19sDfzZSQqzjj JKdwynNObnmXm98aTzLKg0xmHmeZ5jXvs5uXbeYx+9bI4C720ptNcWfvWeRKVy3Vqezf2Vad 6mBHOvpmLfaokr3saE+72tfO9ra7/e1wj7vc5073yAih7njPu973zve++/3vVtEB4AdP+MIb /vCIT7ziF8/4xjteLWN4PG7GQHnKF8XyJal85U2CeZxEfiSa7zzoNx+S0Ev+K50XPVBUX/rP s34nmreH6z9/EtqLBPOvP71VWJ/6yFve976/Pe6BP3vSC//4v5c97Y3PfNsrX/alb31KnP98 6et+K7xfPvG3X/3f/g/f+iTpvfK93/3uzz78wR+98YUf++q7//pYyT7ytT9/8H8/8+d3P/nr j5L24///5nd88Bd/1Cd+4td6sXeArxd6+fd8oseAKuF/o4d+/Pd+A1gVD6h/wCeAFqiA1GeB Gvh+uVd7IKh6Bkh/F3gVJ1iBBwh9Hsh5BUh/uKd/4OeA5Wd/GxiAIJiCU2F647d5LYiAOaiB zid/1ud/7Zd9pAeBR4iEElg+m6B2H8iD0jOFVKgW43CFWriFXNiFXggvIxg7VviFQtiAMrGA Pgh7aTiBZ7iGOhGGoAeD6oeGzbd+freCNDGCcJiHZviGY2gTe5iAQnh7HCiA97eHcyd//+uX hMHnhjU4ftK3fUzIgeQ3hHVYe0X4fdp3iT/Yh8kHfYXIhpRoiX9Id0oYifnHiP2Hgt63f/c3 ij/ogK6ngxRIiLK4f7LYhKIYiXLYi7AYhH3HhHj4ijuIg7R4iJmoi6g4gbmHhiG4jMCIf84I gKKIi4iId9ZIiiJohb2XgKzoiT6Ih2X4gQ/ojb8YjqUYi7uIgNSYjYjnjuJYjM8Ii7T4iCFY jhH4jfOIi6HYf9tYi+2ojVOFC1yhj8tYj3qIgi5okCYYg/xnib7Yis8IhMtXg/g4hDjokMho j3yHjqNIjJBIjYP4gh3okE3YjeRoe6ZXjk7YjfaYhhDIgKnYkv/XSIZ6kY4sgZM26TmOWBM6 uZNAGZRCOZREWZQsUpNGaRaTCBYJ2Y8+6YSX15NUCJJe0ZQ+QZJDQZVTqZAhyY6D2IkrKZMu eYtzuIllSITn13wAyX6VyJaoqJJPKI6uiJTBWHy6OIMbGYAbqYl8aYjKmIvmN5Nr+ZE5OHxp yZX3KIN9uHiTOJdsmJeOmYuv6I6PqZh/mZBQaYzHKJBsOZkbSJd1mZEUWY2FeZh3GZYsWHye mZhO2YstKJecaYweCJqhOY8WaZl6KZgNmZo6CJu2OX0N+JraCIy+qY6Pl3qUWH6QaZq5SYjD WImrmZf1CIr7yJC4aYfSaZinh49fSZP/yhiZKDmR6HiJ4Sme0siSJbmaYIl+NBmNSTk6P+mL 7xk6UhkTtDmf+Jmf+rmf/Jl294l9/+kUcBigipcDCwmKMNmeOWmCPyGdgBifmimS8mmfU0ig aJeEhiiYJcieKrl6JnkTtImIAwqhHCmPpgiE/1ectsiCqxiSn6iO5uiGEumWnch+b3mWY3mK ZEmjySejLcmLYmmhwkWHrPmIyTiDq1iakdmbKVmaEcqXGnqD/KicfRmYi6mZreikJkpzqniQ VrqES2icGYql1umaUfqcY2qkGPmPB0mMzXidZfp28IiYf/iZyeilJKmVxYmSlDmbU+qiuAmY JcqnAqmVUjic/3Q6fV4qmwq5nBFZqHRqkID5p5Dom9wZkADpoBeapppKnZlHo5VJppyakt/Z qBWJldCJkWeqpZeaqacap/6ZoHVYk+jJoSCZmWPZmXBZq7EonEr6p2BKmGrapG6ZpyS6ncfa hv25N0K6Es26rNAardI6rdRardZ6rdiardr6d3awrVjVA94aruI6ruRaruZ6ruiaruq6rjKR Buz6rvvJD0Ahr0TJD/ZKr/Zwr/cqEvqar/oqr/Y6EgD7r/gaEgWbr/y6rwZLsCQRsPzqr/1a sBK7sA4LEwe7Ewdbsf6KsAJLsfRKsBmrsBArshzrsRfbsQ27ryCbsig7sg/7sgZLPv/4+rEm kbElobETW7MNG7Mwy7M3O7EXm7MxK7QscbI5EbICC7A7S7RGO7M+u7Q927QlO7Uty7Ivm7NM K7NXe7NcC7VPK7UdG7RVG7YPe7I0S7NU67X9yrFrC7EJ+7Ei+69qi7A2a7Rp67Noy7VOO7ZD 27M7q7NOK7ZsO7hay7OCy7dK+7UnUbdd+7Rk27ddm7h5W7OTq7RES7dVm7iOK7mY+7g6+7mE q7d+a7Yla7dSG7iRC7l2iz1ty7BBK7doe7lvG7GNe7eEO7Bre7Z4S7J4S7aXq7lTC7yMi7k2 67J867Gz67B7W7wtO7l/m7qdi7K6a7vZk7eH67elG7yL67X/mbu9fUu6qFu7pQu7I6u8Cmu+ tDu6Cwu52Cu7hou92Uu1h+u8x5u9wPu+4Ts+yyu+aZu/tju83Qu6lru4Mwu2MCu28+u5Ufu3 yiu/tWvA9Fu+m/uz54sSEBy9B1zA5rO/4nu9OOu9W6u+oLuxBty7Iqy9whu/7Bu9Gtu/Jpy1 Auy4Diy7xVvCmVu5Y7u6rBu2cou8rpu09cu8bQu/wYu7cfu8xnvDDZzEEVuxrRuwzJvBEsu7 JWzEULy0Q3zCQ1zFBdzCUQyvXQiyYjzGZFzGZnzGaJzGarzGbNzGbvzGcBzHclzGYFzHdnzH eAxVz4B4hoETfRwTf7wUgRwSgwzI/zpRyGOByEmhyCaByAQxEo9cGJAcyH8cyQZhD4N8yZg8 ECmRyZA8yZ9MyJwsygIhEp58yiARySgBEiTRx5VcEoxsyqMMyzNRyLEME6pMy61sE4w8y538 EoWsBbfcyaXsx5NczKyMyZ/sy5s8ypRsysCsy4Q8zdBMy5X8zMoMzba8y9xMzY3czYZxzaG8 zdV8yrtMztksydUszd/8yyoxzOzME9gcz+lcy+68EvBczzuRz++8zsqMza/szf4czgMdzaG8 zPiczgQ9zY4cz+ic0AK90P+szfQs0dQc0Ogcy89M0OHMya5cyh390LKMzPUc0iHN0CTdzPbc yM5MyiDt0f/FrNITHdDjLNPNDNLj/NI4vdCqzMzcfNIufc8NjdAlzc48Tc/t7M8MndCv3NRJ rdQiLdREPdFL3c0UXdMXLc0avcyu7M0WHdOebNUcPdVN7dQHbdBiTdVVrdDn3NX6fNFmvdZq 7dVdvdEs8dFXDdFvrc9jfdYRPddKrc6B/dExfdBuXdcjfdM4fczO7NPgvM6HLdcCLdlunc2X nMss3dJZLdfzPNlF/dVszdl8LRPXDNqmDdnnnNc/PdVzbdGh3dp7rct2fdeQvdjaHNUbrcjw HNZ+/dYYTdHmbNWxHdipjdps7dq+PdprTc63PNuWXc6Vrdxn3dfLrdo8zcwwzdv/on3aXh3U 4qzOzg3bm2zc/8zKhd3O4S3VrD3Twq3Yku3ZT53c7W3ewF3cft3c/UzJllzf8y3dEp3R96zW lR3e2v3X3H3cCE3TaL3dn43acY3cm83gBf3aEA7f5bzeqwzVox3duO3Zu23Uf33fJc3h8j3Y vW3fwS3KHm7YBa3g3b3ieT3grC3Sdi3ONH3aLk7b1i3g/x3joT3Uzm3bhS3jon3hso3hQ23g WE3hMK7cGt3TvozZGw7KLm3SOn3lyOzYID7jpd3lrXzeI/7IAA3L+03X5U3iZJ7lKe3RTE7f N00T5q3ZbH7j3k3epFzUKk3YZw7KGN3YOc7m0J3SRi3m/z3N1ZGd1i/+PPxsP4tO2lKR43gh 5WHR6PRD6Y7+FJCex5q+6Zze6TVj6VUB6kYh6sYMFKRu6nDuOae+yMSNz1rO6qHe6oKdE6sO 3rKe6oac5Bgu2LU+FY1O5IWh306R6QEeFb0uz7c+FMe+2o+e4bNe7G0B6sQ+3rLcFGJu01Lu yH4O1EAt09yu4bMc7ud93WC97ShN2NRty4udytgu7j797tmt5NfO2O0u6OSu7YCe3WPN0YJ+ 5vd+7pk90jsd1ARP6F6+52/O4kt97e/+3NR9FN8t3ibu4ygN7g/+5eAe7Eo+3dT+3NXN8bm9 450t3HQ+2y5e8mQt8fIOznUd1/8eD9tgneEh3+AUD/O/rdVXHfHBze+C3OIintYon/EX/tAp /tiqTfMRjthAP+NIP9y87fJHPdlBn9VKL/UJbvQwv+QH7vRIT+BtzvSxve9JL+KIvey43OLJ 3OQCvuNvPuZEX/AZze6MbdsvX/VUvvVWDtpfPu4OTtRl3eNFftSa7PMdP/XiDfV4Tu9Bnspy f9yN//KpHfUKHtYkbfZond79XfMHrvfIHeQ/X+JqT+QVzt4iv+V2/vU5r+Hd7fbvDfJaX/pG nvWqL/ugn+idv+SR7/GT/9N2jxS7P/LSvfYSLvG6DvhWv/GEP/YWvvDV7vURn+i2r9BR799s j+CzT/f/wL75Mu71LG7jyS/8tA/5WA/swV/ko875Wm7Jmu347q73ew3Q8S7W7V/whm38xwzX D4/uia3ufP/ic978AGFPoEAAAwsSJAhA4UB7BxsmXMgQ4sOCCh02rGgQo0WDCx16hHjw4sWQ EzN2jLhRpEaEKlu+TMnwI0uMD2m+1DhS4k6ePX3+BBpU6M2hRIseRXqU5NClSZ0+hRpV6tSp TalexZpV61aeVoN65aoV7E6LY8OeRZtWLEe1bd2+hRtX7ly6de3exZtX716+ff3+BRxY8GDC hQ0fRpxY8WLGjR0/hnzWbNTJTyvPBXtZZmS1kzVzrun0c9uyRUmO/omaqWmj/lwz25TY9OTX 1o3LevXs9jbOzWhHz+wLnLZk4qvhvu6J2zjom1Zzk+6dPO3v2naFlw6Z8eRunS69o4y9EaFI tipn2yydviTFmODZf8QuU7149drFw36/nW3F9uuxp4+IP/hW2q+67v6DjTyQClSwwfu+aw49 juYbT8KUyiNrQgZjm/DB+I5jSScRCdxMxOjwc26mAEtkMSeyXMxJuBcvRDE8F0/raDwVe9sx RqJwhDHB0PBjL0jlgqRIyNNUXMlIJIGscCkZ+cPpPJ+a1LGrHCusTrLyTHQSTC5hsvFFJ5+s UUo0u9NSTCJNhLLHMdFb88Q3W1TSzvNIvBLPJP+E/vLPNGnas8wk1axSSCT7HFTLRNl8C0s3 Zyt0RAQzNHPMSRuNrlI7Xdr0RP0IrTPEUnkLlFI0QeWRSA4LhHE7Q1U9M7/2dhOUVCNx7c9G NzstEVcQW9pUzlyt5E1PPIv1k8xQSX320Vad9VNSTu8UVdFj8zQVuWz5TFVbQY3NdFFxaXVU umuBNTcu4MQESVNKPWU0wikTnNdVYwsFFt44+b2O0xXn5PfHZU8tGNJk4TW41nFXNQrZ69Ct 0VU62z234mGJ/XLBEOPt0LsPMcyuyo71Qxk+C7HUN2SOJfYYw3htBU9lBzVG6eaAhaUwY0Nz JhPoSWFV9MOF1wutw5H2/qMx00u7Aphkx1Qbjjmrk6JaYdGuXo5r16TGimqvIVNNa6zHBkps tNdmu22334Y7brnnprvuv7ywO2+993asDb7/BjxwvdTemrKf5SIcNcKlUugYDjeu6iuWwz47 3dSgu0pGdS0WSrbOGT/ct3Its9jzyjQ3fPS0qVIbdV85Bx0p5z7vjHLWku1a9ti7xDx1y0P/ PfPgL4/c97HMLl6pzYmnbGAdA2TaowuhB5nk+qbHviT7RHbePQFzxvFkB8V3euWbIQTfQlbt Izq/lZ+Hmvqlpc+e1RuR/nhF8QXUrj/uQK2ffMbnof01Kj7CityB7KUrU83Jaft6XUIc2Kxg /kFMggTTVsGoxayGRalM+oMgt7KEqmlFkIQZ6174KohBfEXMg9Sy3JJOtS164Y50CpRW0BqY q/JZ8GIinFGfonUtdGmQSzXc1rewBUSAzTBcpUtUCRlmMA4SK0KvKyLnFFZFGhKxKi774RTf B8QePi961ppgz7RXrVkJLEZGA1Sa/tdBQAUMgzjsIh0n97Iz6nBcCLQVEtF4tEPpqlfdk2PP PHUbI1Yuiffa2Q6Rxa40SnJR5ILgFtkYycvxqZJ6rBgnWZhJZe2whIZcoA0/OcortiqLtbHS r7wosU/pTl5+zOK7MIZLN2ZwibFEWLjE2EgRziyJhGoiDG/JRJyF/9JRU5yYz5zYQmnawwh0 eqUNgRnMFtawV7KLHjWf9q6OjfFxByKfBMkpv5YZU0FLHKMd4Ri0kB0QbEp7UE2YdLJu+udT B0yXPadnEhRJTWc8mpk7zbQ9JfkPe1HL3jtTVjPBVdSihlncRTW6UY4yBWwdBWlIRTpSkpbU pCdFaUpVulKWttSlL01ORjNay+TxjnmsU93tRAfSmQ4PeJMETU97qsorfVRfULnMPAlZOJ86 kqiMGqpOaQq7MrrGj0dlqNWEupXPIA9RTF0dLHOaO6vaDnG2pB1Vi3ekIHoNQPoLz0G/w0/0 veeqKRoYdzQ0oBfCDq9N0iv9vPcwhC5JsP4TydP3ShYs6mWIr96ZBoPYyaI+1vV6A5LSXqWl RsWyz59GFQzLqPS4QWkSUjLUVOjgdDAS5vWmCxxmXAHb1jKqEJshtOTqNCkQcIz2hysM4z+3 dEwd0ktzNPLsiGzqF9FCcbPKOm0beYivRbL2TuR6YHVrZdvpdteXlJ2mFGmzW1bSNrguzOEJ mTnI52Y1I3946l+a67ns9O8/TKuvdGm5yV6+T2VhrVNs7TckX311nb7N4wmXFj/yoGqOVjQv ew3MWOtBq0X7LG0hfViY+QbUvLz0FjZHp93Upha7PyMxYR92YvLKiaGCNGEHf/XV367qXh+k ICWNC8rksjExHf6uqntRWMqrprKvCQ1Tbtu4WnVauMQ0jlOSRbyrGKt3xj42nXjR60Ud91Nc GRYy8kILNOf6c66axd9iVckrWOGTni7TJYPl6uaiwZmK/jOknSH6S8W+qs/3TeFwWZi0jyrU snl+cSwRtL2nqdWlUYXpayM9aXdR2jegtXSmNb1pTnfa058GdahFPWpSl9rUwZEOpA93uqSe +jCqFp6k67W22cF6y7LGdXEcTdb4ZqXV9kjGWHFa011Ph3e/Xm5TB5fq2gHP2cvrXbN1I9VI DZsvrpuqsNF6bUCDC65dFlkdDVrZ9hKQQA49LPeqB0I1tXmv2p3noie7aHVHiZ3p7P/suM+N WSBVeENnPmgfKWbOcR7qoYY9H2b4G74J39GT8NyjcofEcBnbeE3H3VHDR0jeIkFYjq3p33Y/ 7vFU43aCF+x4tHxrrePO0orIFW4UFR7guDJbVlJWb437e10ih5CUPG5IK3DsMGFqedDgFXmo jsdljImRuMmcMn/vd8eYNxNy8AYjeIFMXGcu+YqKHPojwwvbIFPXeg8OI9rnF2ZoqV2bYDRi g72eX0KDvWhY3SQXNV7sslJdVbWOI84hvlQVr7jnFqc60Pc+8FUbvZUZt+5+Se7kozfT6TXX b7cinOHEL1XM0lboi/3KQMOjPIoGptjfD1/eBA9e8jZrZXr+zztoyCcdyx72l3SNHF2lk36a s8192Pn+tYmKG6jnIppEHes6OvMM7mFP+LqbK8C8lpM+BT1k+/7b6Lqz/c2BNv0a83dddKcw nGaGCeMJnvxHGnNLSnX1suMP4LPWf/62uX+ujR0pTOff//8HwAAUwAEkwAI0QM6QhwNUQLfa o7QKG5naP7GgNglUHqcam9NBjK66p22Lt5OrmlgDQV9Ltm3zsOLAtpPLsrSCQGUjHQfUqqqT nBvLFhK0tho0K0hbul5DKh1kK23LNgoUQRe8NMwqmdVKOJnzD6OaHeqzrz9rmgMbLIQLN9u6 FIHyHn2zryPSviLMpzVKJ+q7Dzj/yTrzUJ/6MLj5qifJarfqox+syz5ya59pK7obmb7Y4yWf QhTR+yST67gYQ7ALYrLWmsFOYRLZqxTU+S+uE6XAcz0+GyGxc7gfqT1KSjkiU8ThE545PLJ/ 2kAkrCX60sPp6hHTUhdZGjJStMOG0IT00jurg6TVy6OWmzoGgrH1ssSsAjE7HKLj46qsYxZ+ eyJKXEJBc6Xvahot7DYtkj1kuqzKkh88Y0WpqzwUAqRFvDm7ApNj/DmPq0WyE755MRpLEbhp c6Bf7BKtkUHdeyYVwyNGpDw/LLN2K7sc3DkYQ0cjK8FYBDolq8V9OQCOw8UhIypZOrG+2yZ9 ypHUU8c7/6yqdcymGntFD9w6YUywIRJIgcmXezRE6PMyWURIfsRIZbrEWaRFhSREN7I1P0tC lNGwNHNJQLyntzKoTYSfnBMooCLCMgs3gHPCbwo9MCSo6zMbQ4MjefKYJnuVM5SPhuIn2NtJ B3O3gRJKoEzK81Ej+ZsbGjOplLQbrrzAugmUkYK/lfLKBTTLs0TLtFTLtWTLtnTLt4TLuJTL uaTLurTLu8TLvNTLveTLvvTLvwTMwBTMwQSDTcOFwUTMxFTMxWTMxnRMTfuAx5TMyaTMyrTM y8TMzNTMzeTMzvTMzwyLEQDN0STN0gQcfjDN1FTN1WTN1nTN14TN2JTN2aTN2v+0zdvEzdzU zd0EDXrgzd8ETslEzbkYToYozqQ4TqhIzsNYzrhozt88zucUCunkh+qkzp2QzqCgzuqczqFo zuwECut8iugUT3uwTu4UiOg0T/QciPMcTvVMz+BsT/Ocz/HsCfjEzvy0T58Az/rUzq3oT/70 T/qEz+I0UP2MzwMdUOBEzQMtz/VET/U8T4l4zgmlTwjlzgl90PJs0Av10PpsUPZ0zw99zwwV zw4tURFlT554Twhtzwf1z++k0AvFzwHt0A+NTxzNzRtdz/mUUOPM0RlFUAIlUQ9VUB9tUR2l UQcF0h8F0vRsUScNTyj10Z840iet0uRczh+VUSW1TQX/lVIiBVEWfVEeJVIpvVIxVVMhDVMz NVMjrdI4ndIizc4jPdEZXdEgtdEeJdPgBNMmBdQxHdI1RdFAhVMMNdLrpFNDXdIYRVILzVP9 DFME1VIcLVQsLdMIVdIAnc0RXVQ5pdE+BdVLTVBHZdJS7dM2LVJBhVNFvU89fVMhtdRZTVI9 tdVQlVXerFRVNdBazVU3VdMMNVU59VVWDVYeXdFaPVVYvVVcRdVX3dMCddQc3dIFLdbb3FUL RVQoRdbvhFQO5dZgBdE7DVItFdZxvdE7hdFzXdIIFVHsZNd27VJuNdENbVJN1VH8TFP5/DRO LQp/RQuAhU33JNiCNdiDRdiE/1XYhWXYhnXYh4XYiJXYiVVYfrXYi+XXccDYjeXYji1ArazA 3Ym/xVGcsuHKb+o0+APZCXQP+pO1rqqLsmlBsII23xNCluW1mgU1r/JB/cPAm20bmZ3ZWaPE nAXao+3ZTPsrPuIfc6NJVzq4UGpDDbPCwpItb2O3KFRKNVtJ2ZjaMDQ3dEuzyyIzMKQ3dZO+ mixKctvZGKrIO5s8jvm9D3o4nNSiQhw58nvERkpHePKRaTSlk5xGNDw9QASuBmzHUOOrQGRH zPOuiUQiXzLFx7WuS9zGo/LEsOy80VPGjYTHG5Owrss8UuOulmzcAUNZyJVaWjQPuUOocgHH 50Ndpv8jvcxqjudDxzis3dZdqGXhlVwM3MIlXcc13VwSvFPqxtk7vmCMxrkrvcFNRW4cO3ra nMk1JfUL3cQV3uGlOaQsprvrXSpLROXFGeatR5Tkpm8sxXfMF3YZRovcOhyKyLgVXdJNxjI0 RjuDSqllyT77yHjCMywUrTMiQp9zP5gU2/eT3TG0J6jhX/p6yrkyGfAjMKQpy73RAEqDWSD0 2LTc4C9C2Q4W4RH+CXUg4RNG4RRWYZW6YMGxNegZM/lCtpEdQUF02RYGjOdAKx2WthqutpCl YR2ko9fCYflC2nopYgvESqMVNbJ1SRXyXwVTQwb7rIiisLAtRzQDW1q535j/esZ386CeTOAu a5AjFLeaJMO6QlslykLEiuJJS8S4q7ljtOG9RbHDLV/JBS7WXaHZCt7R/a3RWjmrq7i+UsQ1 nN76fRTXpTghPqn5fRNGOmS34ziX270Z4mOc015Ajl/abTxG8+QU3NwngrJq4rpIg6RqnGNL bL2wVLpONqMDzt+EWjtEgt3v0zMfo8r7qVveFRXcpbBbOaXm5SNCfilIHrGRTGRNtGQyikdN /rKnwqOIW2YXAmXr1WNMBuRLFrwkjhtIdmVlHuU7tqCMZN9nNrEGasdSBt90prKiLS4vszJu AkjPU0g+hGOI0som3Oeu9dp5YyyKMkpbnuVXGhnE//0SZmQ5q82sQ0I0c7pdokzb5QO5o0zj AcPEIBZZF7aOxfBmuiTZi0risWSu/lvhk0bplFbplWbpls7LC/5oD8bZjJ7poaVZByZGnfXi EH420zBDxpFkFrw1vpzhH87ABQtCGrxpmtZpH75LedOZDQE0exufh1Jbffssbulif+vCONoz M44YugK74oMuAHosIo7Khb6+KeTp/JO42evDLIM5kRxknZS4SRSIJMixuMY87/NAclYwe6lD QVxE+mNc1SuWE/S/3vPcVbY9xFPHHWNmXT6iVt41t3M8k0yfUOTFyBa7XrbIAJTkacZsL4w8 3t3k7vtJHgrqAC6lb5Nb7/9CMTZzHn8JR8euMwccbV++Odg+ZdG+5WhmE7w23m3+MAPy27Ju GN9mXKJtuPkNsZbsW7cl3lhBOsAFQMZmOuLOZtZrk2bBpEGsPHk0vYDs5zOJpr6F4t3l3OfK 5OJV5OzeQgSenHvrL7lKv6REP1xeyc2LOaVhQ2pWSQtWvrVL5lyi49kO8H5Z8Ph2aSN+wcGI 6Qc/Yo8mjAmn8AzX8A3n8A73cKVV4kr78MjQ3I2WPNbgmattaxeMCZ9UCkBS6g8vcd/RJltK XGIiwRYP6RAccSm+N6vuoTIm8BYP7MlraDRWZayl73IM8v2wA2dccZUu3eL2vHEe7iKHSCHi Q1me6be83bJDVDIZ3+3HrnLLvnJsiTMDCeWoe7kca+1AFl0Mr80pl1wYf95AinMc80ihoWwJ KebWAznzgboK3nA6L+zv3tztjbI9t8Xl9iTQHp5r/LqklXLipXIocrF+jD3NPufxxbs2b5f3 vb2eZul+Y78/p+40BHKzgzKlsjtfXKi0xp2gxr46TLcefzWywfWtnBo53/VfB/ZgF3YKDwgA Ow== ------=_NextPart_000_000A_01C6AE61.17FCC4E0-- From owner-ccamp@ops.ietf.org Sun Jul 23 11:37:38 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G4g1S-0002mk-Q0 for ccamp-archive@ietf.org; Sun, 23 Jul 2006 11:37:38 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G4g1Q-0005x7-2S for ccamp-archive@ietf.org; Sun, 23 Jul 2006 11:37:38 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G4fqk-000Oad-43 for ccamp-data@psg.com; Sun, 23 Jul 2006 15:26:34 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.1 Received: from [80.68.34.48] (helo=mail1.noc.data.net.uk) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G4fqg-000OaK-5i for ccamp@ops.ietf.org; Sun, 23 Jul 2006 15:26:30 +0000 Received: from 57-99.dsl.data.net.uk ([80.68.57.99] helo=cortex.aria-networks.com) by mail1.noc.data.net.uk with esmtp (Exim 3.36 #2) id 1G4fqu-0006vQ-00 for ccamp@ops.ietf.org; Sun, 23 Jul 2006 16:26:44 +0100 Received: from your029b8cecfe ([217.158.132.62] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 23 Jul 2006 16:26:26 +0100 Message-ID: <06a101c6ae6c$5a6f6a70$0a23fea9@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Mack-Crane, T. Benjamin" Cc: , "Brungard, Deborah A, ALABS" References: Subject: Re: Working Group Last Call on draft-ietf-ccamp-gmpls-rsvp-te-call-00.txt Date: Sun, 23 Jul 2006 16:19:25 +0100 Organization: Old Dog Consulting MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-OriginalArrivalTime: 23 Jul 2006 15:26:26.0676 (UTC) FILETIME=[5D022340:01C6AE6C] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f Hi Ben, Thanks. These questions give us something to chew on. >> You appear to be making two comments in this paragraph. >> 1. The problem statement for the I-D is not sufficiently clear. > > I did not make this comment, AFAIK. It doesn't matter. I read... > Unfortunately I had sufficient difficulty understanding the > problem statement that I did not immediately question the > need for the object (hoping that clarification of the problem > would shed light on this). ...as an issue with the problem statement. I'm glad that the general problem statement is clear, and we only need to focus on the specifics of Link Capabilities. >> 2. The requirements for (and use of) the Link Capabilities >> object are not clear. >... snip ... >> >> With regard to the purpose and use of the Link Capabilities >> object, this is driven mainly by the material in section 4.3. >... snip ... >> What don't you understand? What are your questions? > > OK, here is section 4.3 with some questions: Excellent. Thanks. > It is useful for the ingress node of an LSP to know the link > capabilities of the link between the network and the egress node. > > Do the ingress and egress nodes terminate the LSP to be setup? Yes, indeed. Rooted in RFC3031, section 3.15. > How is the "link between the network and the egress node" > determined? Good question. Clearly if there is only one such link, we are done. In the case of a "dual-homed" egress, the Link Capability object may report on more than one link. This is, perhaps not abundantly clear, but it is covered by the final paragraph of section 5.3. This object MAY also be used to exchange more than one bundled link capability. In this case, the following ordering MUST be followed: one identifier subobject (Type 1, 2 or 4) MUST be inserted before any capability subobject (Type 64 or 65) to which it refers. > This information may allow the ingress node to tailor its LSP request > to fit those capabilities and to better utilize network resources > with regard to those capabilities. > > Generally an LSP setup request is generated by a network operator, who > has a particular purpose in mind. What leeway does the ingress LSR have > to modify this request? I think that this is the difference between LSPs under the parentage of a Call, and LSPs directly controlled by the operator. When an operator requests an LSP directly, you are quite right that there is no scope for the LSR (i.e. the connection controller) to vary the request for the LSP. However, when an operator requests a service, the service is converted into one or more LSP requests. A good example of this might be VCAT. So, when an operator requests a service and a Call is used to coordinate the end points, the Call Controller has some leeway about what Connections (LSPs) it instantiates to satisfy the call. > Generally networks work best when there are uniform means of > providing connectivity between clients of the network. What > kinds of "tailoring" are envisioned? I think that the VCAT example is the best. The ingress may have the ability to generate a whole pile of signals, but the egress may only have the ability to terminate a limited set of signals. You might regard this as choosing between sub-layers, I suppose. > In particular, this may be used to achieve end-to-end spectral > routing attribute negotiation for signal quality negotiation (such as > BER) in photonic environments where network edges are signal > regeneration capable. Similarly, it may be used to provide end-to-end > spatial routing attribute negotiation in multi-area routing > environments, in particular, when TE links have been bundled based on > technology specific attributes. > >What is "end-to-end spectral routing attribute negotiation"? It is a completely ridiculous and over-florid way of saying "end-to-end lambda negotiation for use in transparent optical networks". >What is "end-to-end spatial routing attribute negotiation"? Similarly poor choice of words for "end-to-end port negotiation for use in fiber switching networks". Thanks for flagging these. > Call setup may provide a suitable mechanism to exchange information > for this purpose, although several other possibilities exist. > > Just because a mechanism can be defined does not mean that it should be. > Why is it necessary to define this mechanism, and add complexity to call > control, if another mechanism is required to do the same thing in cases > where call control is not used? Hmmm. Well that is a good question. I guess the answer is: Because the Call control mechanism a good one where this type of information (i.e. access connectivity information such as access addressing) is often exchanged. Maybe more important are: - this mechanism is one that several implementers want to / have implemented. - no-one raised any concerns about this mechanism during a couple of years of discussion of this process and during WG last call. It is possible that this is not the best way of achieving this (although it is my favourite), but if other mechanisms exist then (as Yakov fondly says) the market will decide which is the best mechanism. Cheers, Adrian From president@cleantechgroup.com Mon Jul 24 01:31:03 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G4t1z-0003gu-EM for ccamp-archive@ietf.org; Mon, 24 Jul 2006 01:31:03 -0400 Received: from atm91-1-82-227-1-132.fbx.proxad.net ([82.227.1.132] helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G4t1w-00041B-PC for ccamp-archive@ietf.org; Mon, 24 Jul 2006 01:31:03 -0400 Message-ID: <000001c6aee1$c4d7f600$0100007f@localhost> From: "Joelynn Butler" To: Subject: H0T DE4LS on A11 0em S0FTW4RE Date: Mon, 24 Jul 2006 07:30:59 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C6AEE1.C4D7F600" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 2.0 (++) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C6AEE1.C4D7F600 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Special Offers Adobe Full Suite: Adobe Video Collection + Adobe Premiere 1.5 Professional + Adobe After Effects 6.5 Professional + Adobe Audition 1.5 + Adobe Encore DVD 1.5 $149.95 Microsoft 2 in 1: MS Windows XP Pro + MS Office 2003 Pro $99.95 Microsoft + Adobe 3 in 1: MS Windows XP Pro + MS Office 2003 Pro + Adobe Acrobat 7.0 Professional $149.95 http://mamaprogi.net/ Bestsellers Microsoft Office Professional Edition 2003 Retail price: $550.00 You save: $480.05 (87%) Our price: $69.95 Microsoft Windows XP Professional Retail price: $200.00 You save: $150.05 (75%) Our price: $49.95 Adobe Photoshop CS2 V 9.0 Retail price: $599.00 You save: $529.05 (88%) Our price: $69.95 http://mamaprogi.net/ rights. Intel accelerators timed out" even though the reason was different. current username/password are employed by Radmin viewer to authorize - About this Freeware Product The C) headers are both to address (rare) problems with some proxies. The scaled to the remote screen's defined size. "MaxPositionCache":REG_DWORD and retain information about you, including your name, email The solution is simple: if we connect to an LDAP server, first try LDAPv3 3. You may copy and distribute the Program (or a work based on it, This Product will not install on your computer unless or until you of the free space on your disk. - Introducing range stepping to the curl globbing support. Now you can specify Matrox - www.matrox.com/ Hotkeys. By using a configured key combination, (C)Sigma-Team 2004 magnetize ------=_NextPart_000_0001_01C6AEE1.C4D7F600 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Pay attention

------=_NextPart_000_0001_01C6AEE1.C4D7F600-- From owner-ccamp@ops.ietf.org Mon Jul 24 15:25:14 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G563F-0008Mx-Vx for ccamp-archive@ietf.org; Mon, 24 Jul 2006 15:25:13 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G563B-0004JU-Rt for ccamp-archive@ietf.org; Mon, 24 Jul 2006 15:25:13 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G55tv-000Fnc-AO for ccamp-data@psg.com; Mon, 24 Jul 2006 19:15:35 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_WHOIS,HTML_MESSAGE autolearn=no version=3.1.1 Received: from [216.82.245.131] (helo=mail146.messagelabs.com) by psg.com with smtp (Exim 4.60 (FreeBSD)) (envelope-from