From owner-ccamp@ops.ietf.org Tue Nov 01 05:19:00 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWtEK-0006Ux-97 for ccamp-archive@megatron.ietf.org; Tue, 01 Nov 2005 05:19:00 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26468 for ; Tue, 1 Nov 2005 05:18:39 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EWtSf-00040n-7g for ccamp-archive@ietf.org; Tue, 01 Nov 2005 05:33:51 -0500 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EWt6Z-0004zo-8N for ccamp-data@psg.com; Tue, 01 Nov 2005 10:10:59 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,HTML_50_60, HTML_MESSAGE,NO_REAL_NAME autolearn=no version=3.1.0 Received: from [217.32.164.138] (helo=smtp3.smtp.bt.com) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EWt6X-0004zZ-Ca for ccamp@ops.ietf.org; Tue, 01 Nov 2005 10:10:57 +0000 Received: from i2km98-ukbr.domain1.systemhost.net ([193.113.197.85]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 1 Nov 2005 10:10:45 +0000 Received: from i2km07-ukbr.domain1.systemhost.net ([193.113.197.26]) by i2km98-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Tue, 1 Nov 2005 10:10:45 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5DECC.859AE898" Subject: RE: Two Drafts for Resilience of Control Plane Date: Tue, 1 Nov 2005 10:10:44 -0000 Message-ID: <0536FC9B908BEC4597EE721BE6A3538912275CEC@i2km07-ukbr.domain1.systemhost.net> Thread-Topic: Two Drafts for Resilience of Control Plane Thread-Index: AcXemUHhH9P6Cx1AT1qsB+vhGsbi8gAMjUtw From: To: , X-OriginalArrivalTime: 01 Nov 2005 10:10:45.0180 (UTC) FILETIME=[85F137C0:01C5DECC] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 1.4 (+) X-Scan-Signature: 1e47b908cbd1247f22e7953a41f1c4c6 This is a multi-part message in MIME format. ------_=_NextPart_001_01C5DECC.859AE898 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Young, please see below.... -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Kim Young Hwa Sent: 01 November 2005 04:04 To: ccamp@ops.ietf.org Subject: RE: Two Drafts for Resilience of Control Plane Hi, =20 First of all, I'd like to appreciate your sending and receiving communication broadly as an initiator of this issue. =20 As most of people know about control plane, it consists of control nodes, control entities, and control channels.=20 Here, the resilience aspect of control nodes could be addressed in the Igor's example=20 or in the duplication of processor cards within a commercial product.=20 The resilience aspect of control entities could be addressed in a protocol itself with GR (graceful restart) capability.=20 And, the resilience aspect of control channels could be identified a link or concatenation of links carrying control packets. =20 Here, I believe that the resilience of control nodes, called controller resiliency,=20 belong to implementation issue (or H/W specific issue), not protocol issue.=20 And, the resilience of control entities belong to protocol issue.=20 However, the scope of resilience in control entities exists between peer control entities, not between physically adjacent nodes.=20 Note that the resilience of control entities belong to only the protocol because a control entity means a protocol that runs a specific function. Some protocols could be run with soft-state nature, others could be run with hard-state nature. The decision on soft-state and hard-state is different from every protocol to be applied. =20 Next is the resilience of control channels.=20 It seems that this could belong to implementation issue as addressed by Adrian. However, if you see the resilience of control channels as implementation issue, I think that we don't need to consider more the resilience of control channels in a protocol approach. But, differently from data plane, control plane has various protocols to keep their control relation. Control channels addressed here are concerned with physically adjacent nodes via direct and indirect connections. And, there could be one or more alternative routes to transfer control packets between physically adjacent nodes. Let's look at an example network. =20 =20 ~~~~~~~~~~~~~~~~~~~ | | | Intra/extra | |-----------| network for | | | control plane | | | | | 5 ~~~~~~~~~~~~~~~~~~~ | | | | 6 | 1 | 4 A-------------------B------------------C | | | | 2 | | |-------------------- | | | | 3 | |--------------------------------------| =20 =20 Above the example, we assume that 1, 2, 3, and 4 control channels share the fate with data channels, and 5 and 6 control channels are used to transfer only control packets. And, the network for control plane could have different capacity in real implementations. Here, we can see several alternatives routes in conveying control packets between physically adjacent nodes. Between A and B nodes have the following routes. =20 Route-1 : 1 Route-2 : 2 Route-3 : 3-4 Route-4 : 5-6 =20 I think that the resilience aspect of control channel should handle reliable (and fast) transfer of control packets between specific nodes. In the example between A and B nodes, these nodes should negotiate active and standby control channels, protocols to be carried on a control channel, and etc. In this sense, I believe that the resilience of control channel could belong to protocol issue. =20 One of two draft that I proposed is a solution for the resilience of control channel, which is based on a concept of the control network, called common channel signaling system used in the traditional PSTN and ISDN.=20 =20 NH=3D> Exactly so. THE major thing you have to be sure of before you = can even start to consider this is the duct graph. If you cannot get physical disjointedness here then you can't even progress. The link-connections of the control/management plane network will, like any other data-plane network, be carried on trails in a lower layer network. You can use an IGP above this to attempt to provide some form of resiliency or you could do what they did in C7 (which is also a pkt-based network BTW) and have a simple load sharing algorithm across a multiple parallel link-set....so if 1 link fails the rest just carry on. Fast, simple, elegant and focussed at the right/relevant problem. So why not use this approach....as noted you have to start with having to ensure the equivalent of disjoint link-set anyway, so use it directly. Note also that 'adding' stuff generally reduces reliability....keep things simple. =20 =20 regards, Neil =20 Of course, there could be other solutions to solve the resilience of control channel. I don't think that the IP connectivity provides a means to be capable of using these various routes. For the resilience of control plane, the IP connectivity is a basic, and additional works should be considered. =20 The other draft that I proposed is a requirement document for the resilience of control plane, not the one of control channels. In the requirement document, as a initial comment from Dimitri, I think that the draft should cover protocol-neutral approaches, not protocol specific ones. For examples, the various resilience aspects of control nodes, control entities, control channels, and etc should be covered. However, the current draft does not sufficiently cover the general aspect for the resilience of control plane. I think that these parts in the requirement document could be handled in further version with help of ccampers who are interested in the resilience of control plane. =20 =20 Regards =20 Young. =20 =20 =20 ------_=_NextPart_001_01C5DECC.859AE898 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Young, please see below....
-----Original Message-----
From:=20 owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On = Behalf Of=20 Kim Young Hwa
Sent: 01 November 2005 04:04
To: = ccamp@ops.ietf.org
Subject: RE: Two Drafts for Resilience of = Control=20 Plane

Hi,
 
First of all, I'd like to appreciate your = sending and=20 receiving communication broadly as an initiator of this = issue.
 
As most of people know about control = plane,
it consists of control nodes, control = entities, and=20 control channels.
Here, the resilience aspect of control = nodes could=20 be addressed in the Igor's example
or in the duplication of processor cards = within a=20 commercial product.
The resilience aspect of control entities = could be=20 addressed in a protocol itself with GR (graceful restart) capability.=20
And, the resilience aspect of control channels = could be=20 identified a link or concatenation of links carrying control=20 packets.
 
Here, I believe that the resilience of control = nodes,=20 called controller resiliency,
belong to implementation issue (or H/W = specific issue),=20 not protocol issue.
And, the resilience of control entities belong = to=20 protocol issue.
However, the scope of resilience in control = entities=20 exists between peer control entities, not between physically adjacent = nodes.=20
Note that the resilience of control entities = belong to=20 only the protocol because a control entity means a protocol that = runs a=20 specific function.
Some protocols could be run with soft-state = nature,=20 others could be run with hard-state nature.
The decision on soft-state and hard-state is = different=20 from every protocol to be applied.
 
Next is the resilience of control channels.=20
It seems that this could belong to = implementation issue=20 as addressed by Adrian.
However, if you see the resilience of control = channels=20 as implementation issue,
I think that we don't need to consider more = the=20 resilience of control channels in a protocol approach. = But,
differently from data plane, control plane has = various=20 protocols to keep their control relation.
Control channels addressed here are concerned = with=20 physically adjacent nodes via direct and indirect = connections.
And, there could be one or more = alternative=20 routes to transfer control packets between physically adjacent=20 nodes.
Let's look at an example network.
 
 
           &n= bsp;~~~~~~~~~~~~~~~~~~~
           =20 = |            =     =20 |
           &n= bsp;|  Intra/extra   =20 |
|-----------|  network=20 for    |
|           |=  control=20 plane   |
|          =20 = |            =     =20 |
| 5         ~~~~~~= ~~~~~~~~~~~~~
|           &= nbsp;      =20 |
|           &= nbsp;      =20 | 6
|        1   =       =20 |         4
A-------------------B------------------C
|           &= nbsp;       |    &= nbsp;           &n= bsp;=20 |
|        2   =       =20 = |            =      =20 |
|--------------------        = ;         =20 |
|           &= nbsp;           &n= bsp;           &nb= sp; =20 |
|           &= nbsp;       3    &= nbsp;           &n= bsp;=20 |
|--------------------------------------|
 
 
Above the example, we assume that 1, 2, 3, = and 4=20 control channels share the fate with data channels, and 5 = and 6=20 control channels are used to transfer only control packets. And, the = network=20 for control plane could have different capacity in real=20 implementations.
Here, we can see several alternatives routes = in=20 conveying control packets between physically adjacent = nodes.
Between A and B nodes have the following=20 routes.
 
     Route-1 : = 1
     Route-2 : = 2
     Route-3 : = 3-4
     Route-4 : = 5-6
 
I think that the resilience aspect of control = channel=20 should handle reliable (and fast) transfer of control packets between = specific=20 nodes.
In the example between A and B nodes, these = nodes should=20 negotiate active and standby control channels, protocols to be carried = on a control channel, and etc. In this sense, I believe that = the=20 resilience of control channel could belong to protocol = issue.
 
One of two draft that I proposed is a solution = for the=20 resilience of control channel, which is based on a concept of the = control=20 network, called common channel signaling system used in the = traditional PSTN=20 and ISDN. 
 
NH=3D> Exactly so.  THE major = thing you have to=20 be sure of before you can even start to consider this is the duct = graph. =20 If you cannot get physical disjointedness here then you can't = even=20 progress.  The link-connections of the control/management plane = network=20 will, like any other data-plane network, be carried on trails in a = lower layer=20 network.  You can use an IGP above this to attempt to provide = some form=20 of resiliency or you could do what they did in C7 (which is also a = pkt-based=20 network BTW) and have a simple load sharing algorithm across a = multiple=20 parallel link-set....so if 1 link fails the rest just carry on.  = Fast,=20 simple, elegant and focussed at the right/relevant problem.  So = why not=20 use this approach....as noted you have to start with having to ensure = the=20 equivalent of disjoint link-set anyway, so use it directly.  Note = also=20 that 'adding' stuff generally reduces reliability....keep things = simple. =20
 
regards,=20 Neil
 
 Of course,=20 there could be other solutions to solve the resilience of control=20 channel.
I don't think that the IP connectivity = provides a means=20 to be capable of using these various routes.
For the resilience of control plane, the IP = connectivity=20 is a basic, and additional works should be = considered.
 
The other draft that I proposed is a = requirement=20 document for the resilience of control plane, not the one of control=20 channels.
In the requirement document, as a initial = comment from=20 Dimitri, I think that the draft should cover protocol-neutral = approaches, not=20 protocol specific ones. For examples, the various resilience aspects = of=20 control nodes, control entities, control channels, and etc should be=20 covered.
However, the current draft does not = sufficiently cover=20 the general aspect for the resilience of control plane.
I think that these parts in the requirement = document=20 could be handled in further version with help of ccampers who are = interested=20 in the resilience of control plane.
 
 
Regards
 
Young.
 
------_=_NextPart_001_01C5DECC.859AE898-- From owner-ccamp@ops.ietf.org Tue Nov 01 06:53:13 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWuhV-0007F1-0F for ccamp-archive@megatron.ietf.org; Tue, 01 Nov 2005 06:53:13 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13516 for ; Tue, 1 Nov 2005 06:52:51 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EWup8-0005lD-1Y for ccamp-archive@ietf.org; Tue, 01 Nov 2005 07:01:06 -0500 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EWuVh-0008nC-EM for ccamp-data@psg.com; Tue, 01 Nov 2005 11:41:01 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.0 Received: from [62.241.162.32] (helo=ranger.systems.pipex.net) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EWuVg-0008mv-6i for ccamp@ops.ietf.org; Tue, 01 Nov 2005 11:41:00 +0000 Received: from dnni.com (81-178-2-190.dsl.pipex.com [81.178.2.190]) by ranger.systems.pipex.net (Postfix) with ESMTP id 1C9EDE00025B; Tue, 1 Nov 2005 11:40:52 +0000 (GMT) Received: from Puppy ([217.158.145.78] RDNS failed) by dnni.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 1 Nov 2005 11:35:15 +0000 Message-ID: <004601c5ded8$bdddd060$4e919ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Cc: References: <0536FC9B908BEC4597EE721BE6A3538912275CEC@i2km07-ukbr.domain1.systemhost.net> Subject: Re: Two Drafts for Resilience of Control Plane Date: Tue, 1 Nov 2005 11:38:00 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-OriginalArrivalTime: 01 Nov 2005 11:35:17.0056 (UTC) FILETIME=[55041400:01C5DED8] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Content-Transfer-Encoding: 7bit Hi Young, Thanks for your thoughtful mail. In focussing on control channel resilience you must answer why it is you are not satisfied with the resilience provided by normal IP mechanisms. For example, in your figure... > ~~~~~~~~~~~~~~~~~~~ > | | > | Intra/extra | >|-----------| network for | >| | control plane | >| | | >| 5 ~~~~~~~~~~~~~~~~~~~ >| | >| | 6 >| 1 | 4 >A-------------------B------------------C >| | | >| 2 | | >|-------------------- | >| | >| 3 | >|--------------------------------------| You correctly identify that there are several control plane routes from A to B > Route-1 : 1 > Route-2 : 2 > Route-3 : 3-4 > Route-4 : 5-6 The option that most people currently consider is that they run an IGP in the control plane. This would mean that a control plane signaling message from the signaling controller at A to the signaling controller at B would be placed in an IP datagram addressed to the control plane address of B. It would be sent along the shortest open path from A to B (route 1). In the event of a failure of link 1, the IGP would converge and the signaling messages would be sent along the next shortest path (route 2). And so on. This mechanism is not sensitive to whether multiple control channels use the same duct or not since the IGP will converge just as well if multiple control channels fail at once. Note that load sharing between control channels is not recommended because it will result in out of order delivery of control messages. Have a look at all of the health warnings about the use of ECMP. So I assume that one of three issues is worrying you. 1. You do not want to implement an IGP in your control plane 2. You do not want to handle IP forwarding in your control plane 3. The speed of convergence of the IGP is not good enough for the use you wish to make of your control plane. Item 1. is an issue of complexity. I can see that it would reduce the complexity of a network device and the control plane if you do not have an IGP. But since you must run the IGP to exchange TE information, it is no additional cost to use it to exchange control plane information. And, to the contrary, by using the IGP you do not need any other mechanisms for control plane resiliency. Item 2. is an implementation issue. The forwarding does not have to be at line speed. In general, software forwarding of control plane packets might be considered adequate. Item 3. would be interesting to hear about. Note that for most cases (such as the switch from route 1 to route 2 in your example) there is no need to wait for IGP convergence since it is the sending node (A) that notices the failed link and can immediately update its routing table. Thus convergence time is only an issue for less direct routes. So I'd like to understand a little more what is motivating your work, and why you think existing techniques are not sufficient. > The other draft that I proposed is a requirement document for > the resilience of control plane, not the one of control channels. > In the requirement document, as a initial comment from Dimitri, > I think that the draft should cover protocol-neutral approaches, > not protocol specific ones. For examples, the various resilience > aspects of control nodes, control entities, control channels, and > etc should be covered. > However, the current draft does not sufficiently cover the > general aspect for the resilience of control plane. > I think that these parts in the requirement document could be > handled in further version with help of ccampers who are > interested in the resilience of control plane. OK. That sounds worth further investigation. Thanks, Adrian From owner-ccamp@ops.ietf.org Tue Nov 01 08:40:13 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWwN3-0006mm-JO for ccamp-archive@megatron.ietf.org; Tue, 01 Nov 2005 08:40:13 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20863 for ; Tue, 1 Nov 2005 08:39:53 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EWwbQ-0004kK-Mv for ccamp-archive@ietf.org; Tue, 01 Nov 2005 08:55:06 -0500 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EWwIV-000EtB-4k for ccamp-data@psg.com; Tue, 01 Nov 2005 13:35:31 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.0 Received: from [62.241.162.32] (helo=ranger.systems.pipex.net) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EWwIU-000Esv-E1 for ccamp@ops.ietf.org; Tue, 01 Nov 2005 13:35:30 +0000 Received: from dnni.com (81-178-2-190.dsl.pipex.com [81.178.2.190]) by ranger.systems.pipex.net (Postfix) with ESMTP id BA5D2E000135 for ; Tue, 1 Nov 2005 13:35:29 +0000 (GMT) Received: from Puppy ([217.158.132.194] RDNS failed) by dnni.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 1 Nov 2005 13:27:16 +0000 Message-ID: <00ec01c5dee8$5c8e3650$4e919ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: References: <7CA873794E52904EAA980A074B076779B17C6F@rchemx01.fnc.net.local> Subject: Lambda labels - next steps Date: Tue, 1 Nov 2005 12:11:43 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-OriginalArrivalTime: 01 Nov 2005 13:27:17.0813 (UTC) FILETIME=[FAE63650:01C5DEE7] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 2.1 (++) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit Hi, I think some progress got made. There seems to be some agreement that there may be a need to advertise lambda availability, use lambda availability in path computation, and apply explicit label control through the network. These requirements still need to be firmed up a bit (for example, are we aiming for interworking between vendors?). Some say that such requirements imply a global semantic for the lambda label. Others say that it is sufficient to use local semantics applying "translation" at each hop. This item needs debate and resolution since it amounts to "are current protocol elements sufficient *and* optimal for meeting the requirements?" Issues of bundling need to be documented, but don't currently appear to create requirements for new protocol extensions. John and Payam point out that the wavelength on its own may not be enough to guarantee end-to-end interworking in optical systems. Since this interworking is precisely the requirement, we need to set out what information is actually required. As Sidney has said, the actual solution comes later (although, since we are engineers, who can be surprised that we are trying out ideas as we go along). My guess, FWIW, is that if you know the ITU grid identifier and the entry in the grid to which the lambda corresponds then you know everything that you need to know. We have an agenda slot for this work in Vancouver. It would be helpful if the main objective could be to establish consensus on exactly what the requirements are, and that we cannot solve them using existing protocol elements. If we get that far, the rest is easy. Thanks, Adrian From owner-ccamp@ops.ietf.org Tue Nov 01 08:41:00 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWwNo-0006xx-B4 for ccamp-archive@megatron.ietf.org; Tue, 01 Nov 2005 08:41:00 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20921 for ; Tue, 1 Nov 2005 08:40:40 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EWwcC-0004mD-D3 for ccamp-archive@ietf.org; Tue, 01 Nov 2005 08:55:53 -0500 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EWwIU-000Et6-O1 for ccamp-data@psg.com; Tue, 01 Nov 2005 13:35:30 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.0 Received: from [62.241.162.32] (helo=ranger.systems.pipex.net) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EWwIR-000EsX-KG for ccamp@ops.ietf.org; Tue, 01 Nov 2005 13:35:27 +0000 Received: from dnni.com (81-178-2-190.dsl.pipex.com [81.178.2.190]) by ranger.systems.pipex.net (Postfix) with ESMTP id D9F3CE000135 for ; Tue, 1 Nov 2005 13:35:20 +0000 (GMT) Received: from Puppy ([217.158.132.194] RDNS failed) by dnni.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 1 Nov 2005 13:27:04 +0000 Message-ID: <00ea01c5dee8$5c0dbbb0$4e919ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Slides for Vancouver Date: Tue, 1 Nov 2005 11:50:13 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-OriginalArrivalTime: 01 Nov 2005 13:27:04.0668 (UTC) FILETIME=[F31071C0:01C5DEE7] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit Hi, We have the Monday morning slot. That means that you can't sit at the back of some other WG meeting and prepare your slides :-( I would like to have all the slides up on the Web in advance so that people can follow them at their own speed. Please send them to me by the end of Saturday. Please look at the agenda to check that you are covering the questions that are listed, and please remember that you are not there to present your I-D! You should be raising questions and encouraging debate/input from the meeting. Thanks, Adrian From owner-ccamp@ops.ietf.org Tue Nov 01 11:17:01 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWyom-0007nj-Jx for ccamp-archive@megatron.ietf.org; Tue, 01 Nov 2005 11:17:01 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29587 for ; Tue, 1 Nov 2005 11:16:39 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EWz38-0002Tn-4D for ccamp-archive@ietf.org; Tue, 01 Nov 2005 11:31:54 -0500 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EWygM-000Mp0-59 for ccamp-data@psg.com; Tue, 01 Nov 2005 16:08:18 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [70.158.43.219] (helo=jera.movaz.com) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EWygI-000Mog-VN for ccamp@ops.ietf.org; Tue, 01 Nov 2005 16:08:15 +0000 Received: from ib (unknown [172.16.24.122]) by jera.movaz.com (Postfix) with SMTP id 231DF2DDFF; Tue, 1 Nov 2005 11:08:13 -0500 (EST) Message-ID: <009101c5defe$76018e00$7a1810ac@movaz.com> From: "Igor Bryskin" To: "Adrian Farrel" , References: <0aef01c5de6b$d0a61760$de849ed9@Puppy> Subject: Re: Control plane resiliency Date: Tue, 1 Nov 2005 11:08:12 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 325b777e1a3a618c889460b612a65510 Content-Transfer-Encoding: 7bit Wow, Adrian, do you believe you were sufficiently rude to protect against any future DOS attacks on the IETF process? I guess this is your idea of firewall. See in-line. Igor ----- Original Message ----- From: "Adrian Farrel" To: Sent: Monday, October 31, 2005 5:37 PM Subject: Control plane resiliency > > Hi, > > It is nice to see some traffic on the CCAMP list. > > Some observations based on your discussions (in no particular order). > > 1. There is a distinction to be made between control channel resiliency > and controller resiliency. > > Since the control channel uses IP, it will heal so long as there is IP > connectivity (failing that you're dead anyway); the issue is the speed of > convergence. Other solutions exist to provide control channel redundancy, > but I believe that these are either implementation specific or are > hardware specific. In either case, they are out of scope and (as Zafar > says) the IP connectivity would remain. IB>> Agree > > Controller resiliency is actually a debate about how to manage the data > plane in the absence of a controller. Note that it is perfectly possible > to lose your signaling controller without losing your routing controller, > etc. IB>> Here I'd like to summarize what we cannot do if one, say, LSP transit controller goes out of service while the LSP data plane preserved intact - a very possible situation in GMPLS CP controlled transport network: 1.. tear LSP in upstream or downstream direction 2.. use PathErr notifications 3.. modify any LSP attribute (some of these modifications could be useful even in this case): a) Admin status (e.g. enable/disable data plane alarms); b) ASSOCIATION object ( e.g. moveVCAT group constituents from one group to another) c) SESSION_ATTRIBUTES (e.g. setup/holding priorities); d) POLICY_DATA object (e.g. signal policy change) e) NOTIFY_REQUEST object (e.g. change Notify targets) f) Etc. 4.. gather alarm information; 5.. use restoration schemes that depends on hop-by-hop notification/switchover signaling 6.. In case of P2MP LSP a failure of a controller located close to the root prevents grafting/pruning operations; 7.. In case of P2P or P2MP segment protected LSP a failure of controller prevents adding/removing local protection In summary - pretty much anything. One solution is mb4b rerouting. However, it may not be feasible. Think of a ring topology: there could simply be no resources in the opposite direction of the ring. Hence our choices are: 1) To say we cannot do anything because GMPLS control plane emerged from MPLS where this problem does not exist - just wait for controller to repair and in the mean time manage the LSP via management plane 2) To do something about this: there might be solutions that relatively easy address this problem. (I have at least two of them) > > 2. There is no need to make a distinction between data plane technologies. > That is, for GMPLS this applies equally to PSC and non-PSC. IB>> Well in IP where the control plane is congruent with the data plane the situation I described does not exist, so I disagree > > 3. Dimitri's observation that it may be worthwhile documenting the > concerns and explaining why they are not issues (i.e. how they solve > themselves) may be very valuable. It should suit all people because if the > concerns are real then the attempt at documentation will expose them, > while if the concerns are not real we will have an advisory document for > all time. IB>> Good advise > > 4. *The* controller resiliency issue appears to be: How to manage and > teardown an LSP downstream of a broken controller. I do not understand why > the answer is not one of: > a. Wait for the controller to be repaired > b. Use the management plane > It seems that in-place modification of GMPLS LSPs is not a common > operational feature for an active LSP. This leaves us with teardown. For > teardown, option a does not seem to be very painful, but if it does cause > problems (and alarms *will* be raised) option b is available. IB>> Not just that, see my comment above > > 5. The ability to manage the data plane resources at the node where the > control plane has failed, may still exist in the management plane (in > which case use it!) or may also be gone (in which case, who cares that you > can't free up the resources for another user since another user cannot > make use of the resources). You *might* manage to claim that there is a > safety issue here - anyone know what OSMINE says about loss of management > plane connectivity to a device with lasers? > > 6. There may be a *separate* issue (as raised by Tom) about how to synch > the control plane with the data plane. This might be particularly > important after controller recovery. Such OAM features should be part of a > separate effort (such as a GMPLS OAM requirements draft). > > 7. Lyndon points out that there is scope for a "standby signaling > controller". This could mean two things. > a. An implementation option (as John points out) including, but not > limited to: > i. multiple instances of the software component > ii. multiple instances of a controller CPU > iii. control-plane message replication to distinct devices > b. A protocol option where two entirely different "routers" manage the > same data plane switch. This is pretty much outside our architecture > (although we could handle a "replacement signaling controller" if it > turned up with the same addresses). *If* someone wants to work on this > idea, I suggest they need to develop the requirements and convince the > community that what we have already doesn't provide everything we need > anyway. (Not saying that the standby model is wrong, but am suggesting > that we might not have a need for it at the moment.) > > 8. In a transport network, we must accept an operator's right to entirely > eliminate soft state timeouts. That is, the failure of the control plane > for any length of time, must not impact the traffic (note that even though > RSVP is a soft state protocol, the refresh period may be set so high (32 > bitsworth of milliseconds) as to be practically infinite. Note > specifically that the failure of Hellos is used in RFC3473 to temporarily > "turn off" the soft state nature of RSVP-TE. > > > In summary: > > A. We have decided that observation 3 might be useful. Is anyone planning > to work on this? > B. We have not heard from Young since the start of this debate. I hope the > hot words have not driven him away. > C. Igor appears to be out on a limb here. While I appreciate him pushing a > point that he believes in strongly, such determination in the face of WG > consensus approaches a DOS attack (unintentional, I'm sure) on the IETF > process. Please be careful. IB>> Thanks for the advice, but to be careful is not in my nature. 1.. About the DOS attack: there was the discussion about control plane resiliency (which I didn't initiate), I mentioned that IMO the issue is important and when I was asked to give a specific example, I brought up the problem of control plane partitioned LSPs. Since then I sent only responses to the questions, some of them unrelated like for example " Can you really keep states in the absence of refreshes" and "Why is your problem cannot be resolved via RSVP graceful restart". Isn't this is CCAMP mailing list for? Where do you see the DOS attack? 2.. About consensus. I was in constant discussions with 3 people: John, Dimitri and Zafar. I definitely could not convince John; Dimitri said at the end: "Ok, it is time to write a draft, and we shall see"; and I seem to give all answers to Zafar, but am not sure if succeeded to convince him or not. Suppose none of them bought in, then, including you, Adrian, there are 4 people who did not recognize the problem sufficient enough to work on a standardized solution. On the other hand one person - Neil - openly supported the work, which with me makes us two, plus, I got some supporting private emails (including an invitation to submit a contribution to Q14/15). So, Adrian, please define what you mean by consensus. Maybe we should vote? I am pretty sure you will get the votes, however, I don't think that as of yesterday one could call the situation as a consensus. Igor > > Thanks, > Adrian > > > > > > > From gmagjdjb@wtcmexico.com.mx Tue Nov 01 22:54:09 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EX9hQ-0004sg-SL for ccamp-archive@megatron.ietf.org; Tue, 01 Nov 2005 22:54:09 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA07720 for ; Tue, 1 Nov 2005 22:53:48 -0500 (EST) Received: from dhcp-0-2-55-70-4f-e1.cpe.cabletv.ca ([24.235.40.184]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EX9vv-0002FC-Le for ccamp-archive@ietf.org; Tue, 01 Nov 2005 23:09:09 -0500 Received: from mail.wtcmexico.com.mx by dhcp-0-2-55-70-4f-e1.cpe.cabletv.ca (8.9.3/8.9.3) with SMTP id VydDpRPl1QmF for ; Tue, 1 Nov 2005 22:55:13 -0500 Received: from 2.63.55.106 ([2.63.55.106]) by mail.wtcmexico.com.mx (Postfix) with ESMTP id PaJHWnPRTru8 for ; Tue, 1 Nov 2005 22:55:13 -0500 Reply-To: "Junior Nix" From: "Junior" Message-ID: <8803310170.20051101225513@qjraenqwfnp> Date: Tue, 1 Nov 2005 22:55:13 -0500 To: Subject: Thousands of academic software titles, 80% off, Instant Download MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Spam-Score: 4.9 (++++) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit Cowards falter, but danger is often overcome by those who nobly dare. MS Works 7.0 $19.95 Adobe Acrobat 5.0 $39.95 Autodesk Architectural Studio 3.0 $39.95 Macromedia FlashPaper v2.0 $19.95 Examples of our prices http://verysoftnet.com From owner-ccamp@ops.ietf.org Tue Nov 01 23:11:57 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EX9yf-0005vB-7K for ccamp-archive@megatron.ietf.org; Tue, 01 Nov 2005 23:11:57 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA08435 for ; Tue, 1 Nov 2005 23:11:36 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXADA-0003B7-1F for ccamp-archive@ietf.org; Tue, 01 Nov 2005 23:26:57 -0500 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EX9qY-000FMi-Ph for ccamp-data@psg.com; Wed, 02 Nov 2005 04:03:34 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00, DATE_IN_PAST_24_48 autolearn=no version=3.1.0 Received: from [171.68.10.87] (helo=sj-iport-5.cisco.com) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EX9qY-000FMG-5h for ccamp@ops.ietf.org; Wed, 02 Nov 2005 04:03:34 +0000 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 01 Nov 2005 20:03:33 -0800 X-IronPort-AV: i="3.97,277,1125903600"; d="scan'208"; a="226301916:sNHT26752612" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id jA243OWt000993; Tue, 1 Nov 2005 20:03:28 -0800 (PST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 1 Nov 2005 23:03:29 -0500 Received: from swallow-mini-mac.local ([10.86.241.10]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 1 Nov 2005 23:03:29 -0500 Received: from cisco.com (localhost [127.0.0.1]) by swallow-mini-mac.local (Postfix) with ESMTP id E3F8615F62D; Mon, 31 Oct 2005 18:42:48 -0500 (EST) To: "Adrian Farrel" Cc: ccamp@ops.ietf.org Cc: swallow@cisco.com Subject: Re: Control plane resiliency In-reply-to: Your message of "Mon, 31 Oct 2005 22:37:34 GMT." <0aef01c5de6b$d0a61760$de849ed9@Puppy> From: George Swallow X-Mailer: MH-E 7.4.3; nmh 1.1-RC3; GNU Emacs 21.2.1 Date: Mon, 31 Oct 2005 18:42:48 -0500 Message-Id: <20051031234248.E3F8615F62D@swallow-mini-mac.local> X-OriginalArrivalTime: 02 Nov 2005 04:03:29.0318 (UTC) FILETIME=[61F54460:01C5DF62] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Adrian - Excellent note. In reading through the thread I was beginning to fear that having chosen IP as a means of providing a resilient control plane, we might totally complicate things and fundamentally deviate from IP at this late date. I believe the exercise of working through requirements, showing how existing mechanism can and SHOULD be used to address these, and in the process point out any omissions would be a very useful piece of work. Thanks, ///George ======================================================================== George Swallow Cisco Systems (978) 936-1398 1414 Massachusetts Avenue Boxborough, MA 01719 From owner-ccamp@ops.ietf.org Wed Nov 02 08:38:59 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXIpP-0005k3-FQ for ccamp-archive@megatron.ietf.org; Wed, 02 Nov 2005 08:38:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06469 for ; Wed, 2 Nov 2005 08:38:37 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXJ3x-0001de-Bp for ccamp-archive@ietf.org; Wed, 02 Nov 2005 08:54:04 -0500 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EXIeM-000090-2Y for ccamp-data@psg.com; Wed, 02 Nov 2005 13:27:34 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [128.87.251.112] (helo=smtpoutuk01.marconi.com) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EXIeK-00008o-Lg for ccamp@ops.ietf.org; Wed, 02 Nov 2005 13:27:33 +0000 Received: from cvdgwy01.uk.marconicomms.com (cvis26.uk.marconicomms.com [128.87.251.109]) by smtpoutuk01.marconi.com (8.12.11/8.12.11) with ESMTP id jA2DRNYh022583; Wed, 2 Nov 2005 13:27:24 GMT (envelope-from Diego.Caviglia@marconi.com) Subject: Re: Control plane resiliency To: "Adrian Farrel" Cc: " X-Mailer: Lotus Notes Release 5.0.12 February 13, 2003 Message-ID: From: "Diego Caviglia" Date: Wed, 2 Nov 2005 14:27:24 +0100 X-MIMETrack: Serialize by Router on CVDGWY01/S/EXT/MC1(5012HF354 | August 26, 2003) at 02/11/2005 13:27:22 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Hi all, a quick comment in line. Regards Diego "Adrian Farrel" @ops.ietf.org on 31/10/2005 23.37.34 Please respond to "Adrian Farrel" Sent by: owner-ccamp@ops.ietf.org To: cc: Subject: Control plane resiliency [CUT] 4. *The* controller resiliency issue appears to be: How to manage and teardown an LSP downstream of a broken controller. I do not understand why the answer is not one of: a. Wait for the controller to be repaired b. Use the management plane It seems that in-place modification of GMPLS LSPs is not a common operational feature for an active LSP. This leaves us with teardown. For teardown, option a does not seem to be very painful, but if it does cause problems (and alarms *will* be raised) option b is available. [dc] In last DRCN (http://drcn2005.telecomitalialab.com/) ww presented a paper that illustrates a possible solution of this issues. It works using signalling messages. If someone is interesed in reading the paper please write me and I'll send the paper. [CUT] 8. In a transport network, we must accept an operator's right to entirely eliminate soft state timeouts. That is, the failure of the control plane for any length of time, must not impact the traffic (note that even though RSVP is a soft state protocol, the refresh period may be set so high (32 bitsworth of milliseconds) as to be practically infinite. Note specifically that the failure of Hellos is used in RFC3473 to temporarily "turn off" the soft state nature of RSVP-TE. [dc] I strongly agree with this. [CUT] Thanks, Adrian From owner-ccamp@ops.ietf.org Wed Nov 02 09:49:09 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXJvJ-0004db-0m for ccamp-archive@megatron.ietf.org; Wed, 02 Nov 2005 09:49:09 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10243 for ; Wed, 2 Nov 2005 09:48:48 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXK9s-0004fL-I9 for ccamp-archive@ietf.org; Wed, 02 Nov 2005 10:04:14 -0500 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EXJq1-000575-Lv for ccamp-data@psg.com; Wed, 02 Nov 2005 14:43:41 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [70.158.43.219] (helo=jera.movaz.com) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EXJpx-00056O-TL for ccamp@ops.ietf.org; Wed, 02 Nov 2005 14:43:38 +0000 Received: from ib (unknown [172.16.24.122]) by jera.movaz.com (Postfix) with SMTP id 9F02E14D21; Wed, 2 Nov 2005 09:43:36 -0500 (EST) Message-ID: <005a01c5dfbb$cea1dd40$7a1810ac@movaz.com> From: "Igor Bryskin" To: "Adrian Farrel" , "Diego Caviglia" Cc: " References: Subject: Re: Control plane resiliency Date: Wed, 2 Nov 2005 09:43:36 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Content-Transfer-Encoding: 7bit Diego, I would like to read the paper you mentioned. Igor ----- Original Message ----- From: "Diego Caviglia" To: "Adrian Farrel" Cc: " Sent: Wednesday, November 02, 2005 8:27 AM Subject: Re: Control plane resiliency > > Hi all, > a quick comment in line. > > Regards > > Diego > > > > "Adrian Farrel" @ops.ietf.org on 31/10/2005 23.37.34 > > Please respond to "Adrian Farrel" > > Sent by: owner-ccamp@ops.ietf.org > > > To: > cc: > > Subject: Control plane resiliency > > [CUT] > > 4. *The* controller resiliency issue appears to be: How to manage and > teardown an LSP downstream of a broken controller. I do not understand why > the answer is not one of: > a. Wait for the controller to be repaired > b. Use the management plane > It seems that in-place modification of GMPLS LSPs is not a common > operational feature for an active LSP. This leaves us with teardown. For > teardown, option a does not seem to be very painful, but if it does cause > problems (and alarms *will* be raised) option b is available. > [dc] In last DRCN (http://drcn2005.telecomitalialab.com/) ww presented a > paper that illustrates a possible solution of this issues. > It works using signalling messages. > If someone is interesed in reading the paper please write me and I'll send > the paper. > > > [CUT] > > 8. In a transport network, we must accept an operator's right to entirely > eliminate soft state timeouts. That is, the failure of the control plane > for any length of time, must not impact the traffic (note that even though > RSVP is a soft state protocol, the refresh period may be set so high (32 > bitsworth of milliseconds) as to be practically infinite. Note > specifically that the failure of Hellos is used in RFC3473 to temporarily > "turn off" the soft state nature of RSVP-TE. > [dc] I strongly agree with this. > > [CUT] > > Thanks, > Adrian > > > > > > > > > > > > > From owner-ccamp@ops.ietf.org Wed Nov 02 10:42:12 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXKke-0003So-0N for ccamp-archive@megatron.ietf.org; Wed, 02 Nov 2005 10:42:12 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14052 for ; Wed, 2 Nov 2005 10:41:51 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXKzE-0007e9-2r for ccamp-archive@ietf.org; Wed, 02 Nov 2005 10:57:18 -0500 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EXKbC-0008M9-5X for ccamp-data@psg.com; Wed, 02 Nov 2005 15:32:26 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [70.158.43.219] (helo=jera.movaz.com) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EXKb8-0008Li-GZ for ccamp@ops.ietf.org; Wed, 02 Nov 2005 15:32:23 +0000 Received: from ib (unknown [172.16.24.122]) by jera.movaz.com (Postfix) with SMTP id 5E1E33007F; Wed, 2 Nov 2005 10:32:20 -0500 (EST) Message-ID: <009c01c5dfc2$9d6ef030$7a1810ac@movaz.com> From: "Igor Bryskin" To: "Adrian Farrel" , "George Swallow" Cc: , References: <20051031234248.E3F8615F62D@swallow-mini-mac.local> Subject: Re: Control plane resiliency Date: Wed, 2 Nov 2005 10:32:20 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7bit George, Although I do agree that mechanisms to control IP and non-IP networks should not fundamentally deviate, we still need to bear in mind that there are things that work well for IP networks and not so well or sufficiently well for non-IP networks and visa versa. For example, the control and data planes are congruent in IP and, generally speaking, not-congruent in transport networks, which brings additional challenges wrt resiliency/robustness of the control plane that we have never met in the past. I recommend to read the paper Diego mentioned in his email, where the authors described quite accurately some of the problems that I have referred to in the thread. Regards and see you on IETF64. Igor ----- Original Message ----- From: "George Swallow" To: "Adrian Farrel" Cc: ; Sent: Monday, October 31, 2005 6:42 PM Subject: Re: Control plane resiliency > Adrian - > > Excellent note. In reading through the thread I was beginning to fear > that having chosen IP as a means of providing a resilient control plane, > we might totally complicate things and fundamentally deviate from IP at > this late date. > > I believe the exercise of working through requirements, showing how > existing mechanism can and SHOULD be used to address these, and in the > process point out any omissions would be a very useful piece of work. > > Thanks, > ///George > > ======================================================================== > George Swallow Cisco Systems (978) 936-1398 > 1414 Massachusetts Avenue > Boxborough, MA 01719 > From owner-ccamp@ops.ietf.org Wed Nov 02 11:04:28 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXL6C-0000Iy-0a for ccamp-archive@megatron.ietf.org; Wed, 02 Nov 2005 11:04:28 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15201 for ; Wed, 2 Nov 2005 11:04:07 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXLKY-0008RW-VR for ccamp-archive@ietf.org; Wed, 02 Nov 2005 11:19:34 -0500 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EXL0Q-000A4y-2S for ccamp-data@psg.com; Wed, 02 Nov 2005 15:58:30 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.0 Received: from [62.241.163.6] (helo=astro.systems.pipex.net) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EXL0O-000A4m-Q2 for ccamp@ops.ietf.org; Wed, 02 Nov 2005 15:58:28 +0000 Received: from dnni.com (81-178-2-190.dsl.pipex.com [81.178.2.190]) by astro.systems.pipex.net (Postfix) with ESMTP id B8DC4E0001B7 for ; Wed, 2 Nov 2005 15:58:18 +0000 (GMT) Received: from Puppy ([217.158.132.167] RDNS failed) by dnni.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 2 Nov 2005 15:48:48 +0000 Message-ID: <08e901c5dfc5$5923ffd0$4e919ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Adding Control Plane Resiliency to the agenda for Vancouver Date: Wed, 2 Nov 2005 15:51:36 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-OriginalArrivalTime: 02 Nov 2005 15:48:49.0612 (UTC) FILETIME=[EAD1A8C0:01C5DFC4] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit Hi, Since it is clear that not everyone is happy about moving on from this discussion, I have jiggled the agenda for Vancouver to allow 10 minutes on this subject. Young will lead the discussions as follows: ================================================================== 16. Control Plane Resiliency Issues (Young Kim, 10) - what components of resiliency and robustness are involved? - for each of the components: - what problems are we trying to solve and in what timescale? - why can't we use existing tools for these problems? Background reading - draft-kim-ccamp-cpr-reqts-01.txt - draft-kim-ccamp-accp-protocol-00.txt ================================================================== Latest agenda available at http://www3.ietf.org/proceedings/05nov/agenda/ccamp.txt Adrian From owner-ccamp@ops.ietf.org Wed Nov 02 12:35:02 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXMVq-00015Z-B0 for ccamp-archive@megatron.ietf.org; Wed, 02 Nov 2005 12:35:02 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23925 for ; Wed, 2 Nov 2005 12:34:40 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXMkR-0005Wd-38 for ccamp-archive@ietf.org; Wed, 02 Nov 2005 12:50:09 -0500 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EXMNy-000IKE-8i for ccamp-data@psg.com; Wed, 02 Nov 2005 17:26:54 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [130.76.96.56] (helo=stl-smtpout-01.boeing.com) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EXMNx-000IK3-Bb for ccamp@ops.ietf.org; Wed, 02 Nov 2005 17:26:53 +0000 Received: from stl-av-01.boeing.com ([192.76.190.6]) by stl-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id LAA06564; Wed, 2 Nov 2005 11:26:34 -0600 (CST) Received: from XCH-SWBH-04.sw.nos.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id jA2HQXY18727; Wed, 2 Nov 2005 11:26:34 -0600 (CST) Received: from XCH-SW-42.sw.nos.boeing.com ([192.79.11.43]) by XCH-SWBH-04.sw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 2 Nov 2005 09:26:32 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Control plane resiliency Date: Wed, 2 Nov 2005 09:26:31 -0800 Message-ID: <626FC7C6A97381468FB872072AB5DDC836974A@XCH-SW-42.sw.nos.boeing.com> Thread-Topic: Control plane resiliency Thread-Index: AcXfxGjeDeYGWo+9QxmGumcYhgyqUgADf0nw From: "Drake, John E" To: "Igor Bryskin" , "Adrian Farrel" , "George Swallow" Cc: , X-OriginalArrivalTime: 02 Nov 2005 17:26:32.0403 (UTC) FILETIME=[91509230:01C5DFD2] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Content-Transfer-Encoding: quoted-printable Igor, Please, enough already. Thanks, John > -----Original Message----- > From: Igor Bryskin [mailto:ibryskin@movaz.com] > Sent: Wednesday, November 02, 2005 7:32 AM > To: Adrian Farrel; George Swallow > Cc: ccamp@ops.ietf.org; swallow@cisco.com > Subject: Re: Control plane resiliency >=20 > George, >=20 >=20 >=20 > Although I do agree that mechanisms to control IP and non-IP networks > should > not fundamentally deviate, we still need to bear in mind that there are > things that work well for IP networks and not so well or sufficiently well > for non-IP networks and visa versa. For example, the control and data > planes > are congruent in IP and, generally speaking, not-congruent in transport > networks, which brings additional challenges wrt resiliency/robustness of > the control plane that we have never met in the past. >=20 >=20 >=20 > I recommend to read the paper Diego mentioned in his email, where the > authors described quite accurately some of the problems that I have > referred > to in the thread. >=20 >=20 >=20 > Regards and see you on IETF64. >=20 > Igor >=20 >=20 >=20 > ----- Original Message ----- > From: "George Swallow" > To: "Adrian Farrel" > Cc: ; > Sent: Monday, October 31, 2005 6:42 PM > Subject: Re: Control plane resiliency >=20 >=20 > > Adrian - > > > > Excellent note. In reading through the thread I was beginning to fear > > that having chosen IP as a means of providing a resilient control plane, > > we might totally complicate things and fundamentally deviate from IP at > > this late date. > > > > I believe the exercise of working through requirements, showing how > > existing mechanism can and SHOULD be used to address these, and in the > > process point out any omissions would be a very useful piece of work. > > > > Thanks, > > ///George > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > George Swallow Cisco Systems (978) 936-1398 > > 1414 Massachusetts Avenue > > Boxborough, MA 01719 > > >=20 From owner-ccamp@ops.ietf.org Wed Nov 02 13:15:38 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXN94-0002ON-SK for ccamp-archive@megatron.ietf.org; Wed, 02 Nov 2005 13:15:38 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28381 for ; Wed, 2 Nov 2005 13:15:13 -0500 (EST) From: owner-ccamp@ops.ietf.org Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXNNi-00085X-Dp for ccamp-archive@ietf.org; Wed, 02 Nov 2005 13:30:42 -0500 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EXMyo-00021T-5P for ccamp-data@psg.com; Wed, 02 Nov 2005 18:04:58 +0000 Message-Id: Date: Wed, 02 Nov 2005 18:04:58 +0000 X-Spam-Score: 0.3 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b > From Jonathan.Lang@sonos.com Sun Oct 30 06:23:46 2005 Received: from [70.184.40.73] (helo=sb-exchange1.rinconnetworks.com) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EW6ba-0001is-DU for ccamp@ops.ietf.org; Sun, 30 Oct 2005 06:23:46 +0000 Subject: RE: Two Drafts for Resilience of Control Plane From: "Jonathan Lang" To: Sender: owner-ccamp@ops.ietf.org Precedence: bulk Zafar, > > > > > -----Original Message----- > > > > > From: Ong, Lyndon [mailto:Lyong@Ciena.com] > > > > > Sent: Friday, October 28, 2005 1:28 PM > > > > > To: ibryskin@movaz.com; dpapadimitriou@psg.com;=20 > > > > > dimitri.papadimitriou@alcatel.be > > > > > Cc: Drake@movaz.com; Drake, John E; > > > > dimitri.papadimitriou@alcatel.be; > > > > Igor > > > > > Bryskin; Zafar Ali; Kim Young Hwa; ccamp@ops.ietf.org > > > > > Subject: RE: Two Drafts for Resilience of Control Plane > > > > > > > > > > Hi Igor, > > > > > > > > > > Are you referring to controlling the LSP while one of the > > > > controllers is > > > > > still down? That would mean that no restart has yet taken > > > > > place. > > > > > The draft seems to be focused on providing standby control > > > > > channels, > > > > [JD] > > > > > > > > What is the utility of having standby control channels, as > > > > opposed > > > > to just having multiple *active* control channels? > > > > > > > > > > There is no advantage, but there are numerous disadvantages. > > > Having > > > multiple *active* control channels is what I was referring to as > > > let IP > > > layer provide the resilience for Control Plane. In fact there are > > > disadvantages of having active and standby control channel and > > > some > > > other entity have to manage them. Now you have to worry about > > > signaling > > > and control channels to be in-sync, fast switchover, etc. > > > > > > My motivation is to keep is simple, but yet superior. > > [JD] > > > > Years ago, when we first started on LMP, we had the notion of active > > and standby control channels and it was George Swallow that pointed > > out that this was a really *BadIdea*tm. > > > > Good news is that "we" are consistent :-) The bad news is > that LMP newly born RFC still have this notion [no one > listened to George :-( ]. RFC4204 does NOT include the notion of active/standby control channels. RFC4204 does explicitly support using multiple active control channels for an adjacency. > Here are some reasons why "we" > think this way: > > - Redundancy/ HA via IP Layer. > - Taken a CC OOS is simple as putting an IF to the control > network OOS, and other operational simplicities. > - OOS IF can be repair without impacting other links or LMP CC FSM. > - One LMP CC FSM per "N" Egress links to control network. > - LMP CC FSM is up as long as we have connectivity to the neighbor. > - No need to make special arrangements to make signaling and > control channel consistent. I.e., both LMP and RSVP Hellos > fail only when there is no IP connectivity to the neighbor. > - Etc. What you describe is certainly valid within a single control network. Best, Jonathan From owner-ccamp@ops.ietf.org Wed Nov 02 17:35:40 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXRCk-0007lF-OB for ccamp-archive@megatron.ietf.org; Wed, 02 Nov 2005 17:35:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12445 for ; Wed, 2 Nov 2005 17:35:17 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXRRP-000229-Iq for ccamp-archive@ietf.org; Wed, 02 Nov 2005 17:50:48 -0500 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EXR29-000Lea-0U for ccamp-data@psg.com; Wed, 02 Nov 2005 22:24:41 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [169.144.68.6] (helo=mailgate.pit.comms.marconi.com) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EXR28-000LeM-0z for ccamp@ops.ietf.org; Wed, 02 Nov 2005 22:24:40 +0000 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id jA2MOdp1005242 for ; Wed, 2 Nov 2005 17:24:39 -0500 (EST) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA12207 for ; Wed, 2 Nov 2005 17:24:39 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id ; Wed, 2 Nov 2005 20:24:38 -0200 Message-ID: <5551AD75D2C0BC459A85A2CEFAE4F8005C06B8@usvissfp01.win.marconi.com> From: "Xie, Feng" To: "'ccamp@ops.ietf.org'" Cc: "Xie, Feng" Subject: Questions on RSVPTE graceful restart Date: Wed, 2 Nov 2005 20:24:37 -0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Hi, I have the following questions on RSVPTE graceful restart: 1. Should a restarting router change the advertised Recovery Time during a graceful restart recovery? Suppose a restarting router advertises t0 as the recovery time after a restart. For any reason, should it advertise a different value for the Recovery Time while it is still in a graceful restart recovery? How about the RecoveryPath related flags (T/R/S) bits? 2. If a restarting router is allowed to change the advertised Recovery Time during a graceful restart recovery, how should a helper react to such a change? For example, support the advertised Recovery Time is changed from t0 to t1, should the helper extend/shrink the period when it is helping? If so, should the helping period start from the time when the first hello is received (and last for t1) or from the time when the first hello with the new value is received (and last for t1)? 3. Have the class number of Capability object and the message type of RecoveryPath (both are defined in draft-ietf-ccamp-rsvp-restart-ext-03) been assigned? Thanks. Feng Xie From owner-ccamp@ops.ietf.org Thu Nov 03 00:17:36 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXXTk-0002to-3s for ccamp-archive@megatron.ietf.org; Thu, 03 Nov 2005 00:17:36 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06133 for ; Thu, 3 Nov 2005 00:17:14 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXXiR-0004vy-DY for ccamp-archive@ietf.org; Thu, 03 Nov 2005 00:32:49 -0500 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EXXHA-000DYd-7F for ccamp-data@psg.com; Thu, 03 Nov 2005 05:04:36 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [132.151.6.50] (helo=newodin.ietf.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1EXXH9-000DYL-Dn for ccamp@ops.ietf.org; Thu, 03 Nov 2005 05:04:35 +0000 Received: from apache by newodin.ietf.org with local (Exim 4.43) id 1EXXH5-0005ga-0q; Thu, 03 Nov 2005 00:04:31 -0500 X-test-idtracker: no From: The IESG To: IETF-Announce Cc: Internet Architecture Board , RFC Editor , ccamp mailing list , ccamp chair , ccamp chair Subject: Document Action: 'A Transport Network View of the Link Management Protocol' to Informational RFC Message-Id: Date: Thu, 03 Nov 2005 00:04:31 -0500 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca The IESG has approved the following document: - 'A Transport Network View of the Link Management Protocol ' as an Informational RFC This document is the product of the Common Control and Measurement Plane Working Group. The IESG contact persons are Alex Zinin and Bill Fenner. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-transport-lmp-02.txt Technical Summary This memo describes the relationship of the LMP procedures to 'discovery' as defined in the International Telecommunication Union (ITU-T), and on-going ITU-T work. This document provides an overview of LMP in the context of the ITU-T Automatically Switched Optical Networks (ASON) and transport network terminology and relates it to the ITU-T discovery work to promote a common understanding for progressing the work of IETF and ITU-T. Working Group Summary The document has been reviewed by the WG, as well as ITU-T SG15, comments have been addressed. The WG had consensus on progressing this document. Protocol Quality Alex Zinin reviewed this document for the IESG. Note to RFC Editor Section 1. NEW TEXT. Insert immediately after heading. ITU-T Recommendation G.8080 Amendment 1 [G.8080] and ITU-T Recommendation G.7714 [G.7714] provide definitions and mechanisms related to transport plane discovery. Note that in the context of this work, "Transport" relates to the data plane (sometimes called the transport plane or the user plane) and does not refer to the transport layer (layer 4) of the OSI seven layer model, nor to concept of transport intended by protocols such as the Transmission Control Protocol (TCP). Special care must be taken with the acronym "TCP" which within the context of the rest of this document means "Termination Connection Point" and does not indicate the Transmission Control Protocol. From owner-ccamp@ops.ietf.org Thu Nov 03 17:15:04 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXnMM-0002Kp-QE for ccamp-archive@megatron.ietf.org; Thu, 03 Nov 2005 17:15:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00754 for ; Thu, 3 Nov 2005 17:14:41 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXnbE-0006UW-SL for ccamp-archive@ietf.org; Thu, 03 Nov 2005 17:30:25 -0500 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EXnDv-000D0v-Em for ccamp-data@psg.com; Thu, 03 Nov 2005 22:06:19 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [132.151.6.50] (helo=newodin.ietf.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1EXnDt-000Cz1-Qn for ccamp@ops.ietf.org; Thu, 03 Nov 2005 22:06:18 +0000 Received: from apache by newodin.ietf.org with local (Exim 4.43) id 1EXnDs-0000NQ-EX; Thu, 03 Nov 2005 17:06:16 -0500 Content-Type: text/plain Mime-Version: 1.0 To: IETF-Announce@ietf.org Cc: ccamp@ops.ietf.org, Kireeti Kompella , Adrian Farrel From: The IESG Subject: WG Action: RECHARTER: Common Control and Measurement Plane (ccamp) Message-Id: Date: Thu, 03 Nov 2005 17:06:16 -0500 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 848ed35f2a4fc0638fa89629cb640f48 The charter of the Common Control and Measurement Plane (ccamp) working group in the Routing Area of the IETF has been updated. For additional information, please contact the Area Directors or the working group Chairs. +++ Common Control and Measurement Plane (ccamp) ============================================= Current Status: Active Working Group Chair(s): Kireeti Kompella Adrian Farrel Routing Area Director(s): Bill Fenner Alex Zinin Routing Area Advisor: Alex Zinin Technical Advisor(s): Alex Zinin Mailing Lists: General Discussion: ccamp@ops.ietf.org To Subscribe: majordomo@ops.ietf.org In Body: subscribe ccamp Archive: https://ops.ietf.org/lists/ccamp Description of Working Group: Organizational Overview 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), e.g. O-O and O-E-O optical switches, ATM and Frame Relay switches, MPLS, GRE, in cooperation with the MPLS WG. In this context, measurement refers to the acquisition and distribution of attributes relevant to the setting up of tunnels and paths. CCAMP WG work scope includes: - Definition of protocol-independent metrics and parameters (measurement attributes) for describing links and paths that are required for routing and signaling. These will be developed in conjunction with requests and requirements from other WGs to ensure overall usefulness. - Definition of protocol(s) and extensions to them required for link and path attribute measurement. Link Management Protocol (LMP) is included here. - Functional specification of extensions for routing (OSPF, ISIS) and signalling (RSVP-TE) required for path establishment. Protocol formats and procedures that embody these extensions will be done jointly with the WGs supervising those protocols. - Definition of the mechanisms required to determine the route and properties of an established path (tunnel tracing). - Definition of MIB modules and other OAM techniques relevant to the protocols and extensions specified within the WG. CCAMP WG currently works on the following tasks: - Define how the properties of network resources gathered by a measurement protocol can be distributed in existing routing protocols, such as OSPF and IS-IS. CCAMP defines the generic description of the properties and how they are distributed in OSPF. The specifics of distribution within IS-IS are being addressed in the ISIS WG. - Define signaling and routing mechanisms and extensions to allow path and tunnel setup and maintenance across multiple domains, where a domain may be an IGP area, an Autonomous System, or any other region of topological visibility. To this end, work cooperatively with the PCE and MPLS WGs. - Define abstract link and path properties needed for link and path protection. Specify signalling mechanisms for path protection, diverse routing and fast path restoration. Ensure that multi-layer path protection and restoration functions are achievable using the defined signalling, routing, and measurement protocols, either separately or in combination. - Identify which requirements for signaling and routing for ASON are not currently met by protocols defined in CCAMP; based on these, define mechanisms to address these requirements. - Document issues and strategies for the migration of MPLS-based deployments to GMPLS. Based on the outcome, identify protocol machinery that implementations may have to change to ease the migration from MPLS to GMPLS. In doing this work, the WG will work closely with at least the following other WGs: MPLS, ISIS, OSPF, IDR, L1VPN and PCE. The WG will also cooperate with the ITU-T. Goals and Milestones: Done Post strawman WG goals and charter Done Identify and document a limited set of candidate solutions for signalling and for measurement. Among candidate control solutions to be considered are the existing GMPLS drafts. Done Build appropriate design teams Done Submit WG document defining path setup portions of common control plane protocol Done Submit WG document defining common measurement plane protocol Done Submit LMP MIB to IESG Done Submit protection & restoration documents to IESG Done Submit ASON signaling requirements doc to IESG Done Submit GMPLS MIBs to IESG Done Produce CCAMP WG document for generic tunnel tracing protocol Done Produce CCAMP WG document for multi-area/AS signaling and routing Done Submit ASON routing requirements doc to IESG Done Submit revised charter and milestones to IESG for IESG consideration of more detailed deliverables and determination of usefulness of continuation of WG Oct 05 First version WG I-D for Advertising TE Node Capabilities in ISIS and OSPF Oct 05 First version WG I-D for Automatic discovery of MPLS-TE mesh membership Nov 05 Submit ASON Routing evaluation I-D for IESG review Nov 05 Cross-WG review of I-D for Advertising TE Node Capabilities in ISIS and OSPF Nov 05 First version WG I-D MPLS to GMPLS migration strategies Dec 05 Submit RSVP-TE extensions for inter-domain signaling I-D for IESG review Dec 05 Submit Per-domain path computation signaling I-D for IESG review Dec 05 First version of WG I-D for ASON Routing solutions Dec 05 First version WG I-D Requirements for Multi-Layer and Multi-Region Networks Dec 05 First version WG I-D for Evaluation of existing protocols for MLN/MRN Jan 06 Submit GMPLS signaling in support of Call Management I-D for IESG review Jan 06 Submit I-D for Advertising TE Node Capabilities in ISIS and OSPF for IESG review Jan 06 First version WG I-D for Protocol solutions for MLN/MRN Jan 06 First version of WG I-D for OSPF-TE/GMPLS MIB module Jan 06 First version WG Informational I-D for Analysis of inter-domain issues for disjoint and protected paths Feb 06 Submit GMPLS/ASON lexicography I-D for IESG review Feb 06 Submit LSP Stitching I-D for IESG review Feb 06 First version WG I-D MPLS-GMPLS interworking requirements and solutions Mar 06 Submit I-D for Automatic discovery of MPLS-TE mesh membership for IESG review Mar 06 First version WG I-D GMPLS OAM Requirements Apr 06 Submit GMPLS routing and signaling interoperability advice I-D for IESG review Apr 06 First version of WG I-D for additional MIB module to cover RSVP-TE signaling extensions Jun 06 Submit Informational I-D for Analysis of inter-domain issues for disjoint and protected paths for IESG review Oct 06 Submit MPLS to GMPLS migration strategies I-D for IESG review Nov 06 Submit ASON Routing solutions I-D for IESG review Dec 06 Submit Requirements for Multi-Layer and Multi-Region Networks I-D for IESG review Jan 07 Submit MPLS-GMPLS interworking requirements and solutions I-D for IESG review Feb 07 Submit Evaluation of existing protocols for MLN/MRN for IESG review Mar 07 Submit OSPF-TE/GMPLS MIB module for MIB doctor and IESG review Jun 07 Submit GMPLS OAM Requirements I-D for IESG review Aug 07 Submit Protocol solutions for MLN/MRN I-D for IESG review Dec 07 Submit MIB module for RSVP-TE signaling extensions for MIB doctor and IESG review Dec 07 Recharter or close Working Group From owner-ccamp@ops.ietf.org Thu Nov 03 17:53:05 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXnxB-0006CN-46 for ccamp-archive@megatron.ietf.org; Thu, 03 Nov 2005 17:53:05 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03000 for ; Thu, 3 Nov 2005 17:52:43 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXoC3-0007f0-Fd for ccamp-archive@ietf.org; Thu, 03 Nov 2005 18:08:28 -0500 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EXnt2-0003n1-9n for ccamp-data@psg.com; Thu, 03 Nov 2005 22:48:48 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.0 Received: from [62.241.163.7] (helo=blaster.systems.pipex.net) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EXnt0-0003lu-Pr for ccamp@ops.ietf.org; Thu, 03 Nov 2005 22:48:47 +0000 Received: from dnni.com (81-178-2-190.dsl.pipex.com [81.178.2.190]) by blaster.systems.pipex.net (Postfix) with ESMTP id D9302E000088; Thu, 3 Nov 2005 22:48:45 +0000 (GMT) Received: from Puppy ([217.158.132.19] RDNS failed) by dnni.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 3 Nov 2005 22:48:39 +0000 Message-ID: <00dc01c5e0c9$2e42b860$61849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Cc: "Kireeti Kompella" References: Subject: Re: WG Action: RECHARTER: Common Control and Measurement Plane (ccamp) Date: Thu, 3 Nov 2005 22:51:44 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-OriginalArrivalTime: 03 Nov 2005 22:48:41.0464 (UTC) FILETIME=[BCBEF780:01C5E0C8] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 76c7db407a166e4c39f35d8215d8dd32 Content-Transfer-Encoding: 7bit I hope no-one is too shocked that this happened before the end of 2007. Looks like we now the go-ahead to do some work. Of course, our initial milestones are already behind schedule (which may give you a hint as to how long this has been in the pipeline). We will sort all this out over the next couple of weeks and start to move things forwards. Thanks for your support in getting this to happen. Adrian ----- Original Message ----- From: "The IESG" To: Cc: ; "Kireeti Kompella" ; "Adrian Farrel" Sent: Thursday, November 03, 2005 10:06 PM Subject: WG Action: RECHARTER: Common Control and Measurement Plane (ccamp) > The charter of the Common Control and Measurement Plane (ccamp) working group > in the Routing Area of the IETF has been updated. For additional information, > please contact the Area Directors or the working group Chairs. > > +++ > > Common Control and Measurement Plane (ccamp) > ============================================= > > Current Status: Active Working Group > > Chair(s): > Kireeti Kompella > Adrian Farrel > > Routing Area Director(s): > Bill Fenner > Alex Zinin > > Routing Area Advisor: > Alex Zinin > > Technical Advisor(s): > Alex Zinin > > Mailing Lists: > General Discussion: ccamp@ops.ietf.org > To Subscribe: majordomo@ops.ietf.org > In Body: subscribe ccamp > Archive: https://ops.ietf.org/lists/ccamp > > Description of Working Group: > Organizational Overview > > 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), e.g. O-O and O-E-O optical > switches, ATM and Frame Relay switches, MPLS, GRE, in cooperation > with the MPLS WG. In this context, measurement refers to the > acquisition and distribution of attributes relevant to the setting up > of tunnels and paths. > > CCAMP WG work scope includes: > > - Definition of protocol-independent metrics and parameters > (measurement attributes) for describing links and paths that are > required for routing and signaling. These will be developed in > conjunction with requests and requirements from other WGs to > ensure overall usefulness. > > - Definition of protocol(s) and extensions to them required for > link and path attribute measurement. Link Management Protocol (LMP) > is included here. > > - Functional specification of extensions for routing (OSPF, ISIS) and > signalling (RSVP-TE) required for path establishment. Protocol > formats and procedures that embody these extensions will be done > jointly with the WGs supervising those protocols. > > - Definition of the mechanisms required to determine the route and > properties of an established path (tunnel tracing). > > - Definition of MIB modules and other OAM techniques relevant to the > protocols and extensions specified within the WG. > > CCAMP WG currently works on the following tasks: > > - Define how the properties of network resources gathered by a > measurement protocol can be distributed in existing routing > protocols, such as OSPF and IS-IS. CCAMP defines the generic > description of the properties and how they are distributed in OSPF. > The specifics of distribution within IS-IS are being addressed in > the ISIS WG. > > - Define signaling and routing mechanisms and extensions to allow path > and tunnel setup and maintenance across multiple domains, where a > domain may be an IGP area, an Autonomous System, or any other region > of topological visibility. To this end, work cooperatively with the > PCE and MPLS WGs. > > - Define abstract link and path properties needed for link and path > protection. Specify signalling mechanisms for path protection, > diverse routing and fast path restoration. Ensure that multi-layer > path protection and restoration functions are achievable using the > defined signalling, routing, and measurement protocols, either > separately or in combination. > > - Identify which requirements for signaling and routing for ASON are > not currently met by protocols defined in CCAMP; based on these, > define mechanisms to address these requirements. > > - Document issues and strategies for the migration of MPLS-based > deployments to GMPLS. Based on the outcome, identify protocol > machinery that implementations may have to change to ease the > migration from MPLS to GMPLS. > > In doing this work, the WG will work closely with at least the > following other WGs: MPLS, ISIS, OSPF, IDR, L1VPN and PCE. The > WG will also cooperate with the ITU-T. > > Goals and Milestones: > Done Post strawman WG goals and charter > Done Identify and document a limited set of candidate solutions for > signalling and for measurement. Among candidate control solutions to be > considered are the existing GMPLS drafts. > Done Build appropriate design teams > Done Submit WG document defining path setup portions of common control plane > protocol > Done Submit WG document defining common measurement plane protocol > Done Submit LMP MIB to IESG > Done Submit protection & restoration documents to IESG > Done Submit ASON signaling requirements doc to IESG > Done Submit GMPLS MIBs to IESG > Done Produce CCAMP WG document for generic tunnel tracing protocol > Done Produce CCAMP WG document for multi-area/AS signaling and routing > Done Submit ASON routing requirements doc to IESG > Done Submit revised charter and milestones to IESG for IESG consideration of > more detailed deliverables and determination of usefulness of continuation of WG > > Oct 05 First version WG I-D for Advertising TE Node Capabilities in ISIS and > OSPF > Oct 05 First version WG I-D for Automatic discovery of MPLS-TE mesh > membership > Nov 05 Submit ASON Routing evaluation I-D for IESG review > Nov 05 Cross-WG review of I-D for Advertising TE Node Capabilities in ISIS > and OSPF > Nov 05 First version WG I-D MPLS to GMPLS migration strategies > Dec 05 Submit RSVP-TE extensions for inter-domain signaling I-D for IESG > review > Dec 05 Submit Per-domain path computation signaling I-D for IESG review > Dec 05 First version of WG I-D for ASON Routing solutions > Dec 05 First version WG I-D Requirements for Multi-Layer and Multi-Region > Networks > Dec 05 First version WG I-D for Evaluation of existing protocols for MLN/MRN > > Jan 06 Submit GMPLS signaling in support of Call Management I-D for IESG > review > Jan 06 Submit I-D for Advertising TE Node Capabilities in ISIS and OSPF for > IESG review > Jan 06 First version WG I-D for Protocol solutions for MLN/MRN > Jan 06 First version of WG I-D for OSPF-TE/GMPLS MIB module > Jan 06 First version WG Informational I-D for Analysis of inter-domain issues > for disjoint and protected paths > Feb 06 Submit GMPLS/ASON lexicography I-D for IESG review > Feb 06 Submit LSP Stitching I-D for IESG review > Feb 06 First version WG I-D MPLS-GMPLS interworking requirements and > solutions > Mar 06 Submit I-D for Automatic discovery of MPLS-TE mesh membership for IESG > review > Mar 06 First version WG I-D GMPLS OAM Requirements > Apr 06 Submit GMPLS routing and signaling interoperability advice I-D for > IESG review > Apr 06 First version of WG I-D for additional MIB module to cover RSVP-TE > signaling extensions > Jun 06 Submit Informational I-D for Analysis of inter-domain issues for > disjoint and protected paths for IESG review > Oct 06 Submit MPLS to GMPLS migration strategies I-D for IESG review > Nov 06 Submit ASON Routing solutions I-D for IESG review > Dec 06 Submit Requirements for Multi-Layer and Multi-Region Networks I-D for > IESG review > Jan 07 Submit MPLS-GMPLS interworking requirements and solutions I-D for IESG > review > Feb 07 Submit Evaluation of existing protocols for MLN/MRN for IESG review > Mar 07 Submit OSPF-TE/GMPLS MIB module for MIB doctor and IESG review > Jun 07 Submit GMPLS OAM Requirements I-D for IESG review > Aug 07 Submit Protocol solutions for MLN/MRN I-D for IESG review > Dec 07 Submit MIB module for RSVP-TE signaling extensions for MIB doctor and > IESG review > Dec 07 Recharter or close Working Group > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf-announce > > From info@mail.sedfjx.com Fri Nov 04 03:28:20 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXwvr-0003Qv-TR for ccamp-archive@megatron.ietf.org; Fri, 04 Nov 2005 03:28:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01549 for ; Fri, 4 Nov 2005 03:27:56 -0500 (EST) Received: from [58.180.197.154] (helo=mail.sedfjx.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EXxAo-0005sn-Pp for ccamp-archive@ietf.org; Fri, 04 Nov 2005 03:43:47 -0500 Received: (qmail 6052 invoked by uid 509); 4 Nov 2005 15:04:06 +0900 Date: 4 Nov 2005 15:04:06 +0900 Message-ID: <20051104060406.6051.qmail@mail.sedfjx.com> From: info@sedfjx.com To: ccamp-archive@ietf.org Subject: $B=w@-$H2q$C$F$/$l$^$;$s$+!)(B X-Spam-Score: 2.9 (++) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de http://www.awg5.net/?sanman $B:#2s!"N$H~$5$s$H$$$&=w@-$r>R2p$7$F$$$^$9!"EDCf$H?=$7$^$9!#N$H~$5$s$H$$$&=w@-$O;E;v$,B?K;$JJ}$GCK@-$H$N=P2q$$$,L5$/!";d$,Be9T$7$F!"CK@-$H$N=P2q$$$rJQ$o$j$KC5$7$F$^$9!#$$$-$J$j$N%a!<%k$G?=$7Lu$J$$$G$9!#$b$7N$H~$5$s$K$*2q$$$7$F$$$?$@$1$k$J$i!"N$H~$5$s$+$i$NJs=7$N0lIt$r5.J}$K$*;YJ'$$$7$^$9!#$b$7;d$N;v$,?.$8$l$J$$$N$G$"$l$P!"N$H~$5$s$K2q$&A0$K5.J}$X$N?69~$_$b2DG=$G$9!#$3$A$i$GH`=w$N; Fri, 4 Nov 2005 07:35:41 -0500 (EST) Received: from [58.180.197.157] (helo=mail.sedfjx.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EY12a-00050A-7U for ccamp-archive@ietf.org; Fri, 04 Nov 2005 07:51:34 -0500 Received: (qmail 4551 invoked by uid 509); 4 Nov 2005 18:32:12 +0900 Date: 4 Nov 2005 18:32:12 +0900 Message-ID: <20051104093212.4550.qmail@mail.sedfjx.com> From: info@sedfjx.com To: ccamp-archive@ietf.org Subject: $B$$NDL$j40A4L5NA$GD>EE8r49!uD>EE1\Mw$,$G$-$k$h$s"v(B http://www.awg5.net/?alltada $B%a!<%k$G%@%i%@%i$9$kI,MWL5$7!*(B $B!yEEOC$GB(7h$@$+$i4V0c$$L5$7!*(B $B!y$b$A$m$s%a!<%k$rFI$`$N$bAw$k$N$b40A4L5NA"v(B $B!y%a!<%k$K$9$k$bNI$7!*EEOC$K$9$k$bNI$7!*5.J}$)!A!A(Bv(*^^*)v$B$G$bAa$$$b$N>!$A$@$h$s!y(B $B"#(,(,(,(,(,(,(,(,(,(,(,"#(B $BM-NA$,9%$-$JJ}$O$3$A$i$M"v(B $B"((BI don't veceive your mail awg_tokyo@yahoo.com.au $B"(%a!<%kITMW(B awg_tokyo@yahoo.com.au $B"#(,(,(,(,(,(,(,(,(,(,(,"#(B From info@mail.sedfjx.com Fri Nov 04 12:13:04 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EY57g-0003xU-8k for ccamp-archive@megatron.ietf.org; Fri, 04 Nov 2005 12:13:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01798 for ; Fri, 4 Nov 2005 12:12:37 -0500 (EST) Received: from [58.180.197.156] (helo=mail.sedfjx.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EY5Me-0004el-W7 for ccamp-archive@ietf.org; Fri, 04 Nov 2005 12:28:34 -0500 Received: (qmail 28226 invoked by uid 509); 4 Nov 2005 23:58:28 +0900 Date: 4 Nov 2005 23:58:28 +0900 Message-ID: <20051104145828.28225.qmail@mail.sedfjx.com> From: info@sedfjx.com To: ccamp-archive@ietf.org Subject: $BBt0f$G$9(B X-Spam-Score: 2.9 (++) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed $BFMA3$N%a!<%k$G?=$7Lu$4$6$$$^$;$s!#;d$O%^%@%`6f3ZIt$H$$$&A49qE83+$N#3#0Be0J>e$N4{:'l9g$O!d"M!!(Bawg_tokyo@yahoo.com.au ////////////////////////////////////////////////////////// From owner-ccamp@ops.ietf.org Fri Nov 04 13:29:55 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EY6K3-0003qN-17 for ccamp-archive@megatron.ietf.org; Fri, 04 Nov 2005 13:29:55 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06156 for ; Fri, 4 Nov 2005 13:29:32 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EY6Z5-0006oD-QN for ccamp-archive@ietf.org; Fri, 04 Nov 2005 13:45:28 -0500 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EY6BX-0001bz-OT for ccamp-data@psg.com; Fri, 04 Nov 2005 18:21:07 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [171.71.176.70] (helo=sj-iport-1.cisco.com) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EY6BW-0001at-PE for ccamp@ops.ietf.org; Fri, 04 Nov 2005 18:21:06 +0000 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-1.cisco.com with ESMTP; 04 Nov 2005 10:21:06 -0800 X-IronPort-AV: i="3.97,292,1125903600"; d="scan'208"; a="672000170:sNHT107115340" 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 jA4IL2Qq002728; Fri, 4 Nov 2005 10:21:03 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 4 Nov 2005 10:21:01 -0800 Received: from [10.21.145.222] ([10.21.145.222]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 4 Nov 2005 10:21:00 -0800 Message-ID: <436BA68C.9090103@cisco.com> Date: Fri, 04 Nov 2005 10:21:00 -0800 From: Arun Satyanarayana Organization: Cisco Systems User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Xie, Feng" CC: "'ccamp@ops.ietf.org'" , "Arun Satyanarayana (asatyana)" Subject: Re: Questions on RSVPTE graceful restart References: <5551AD75D2C0BC459A85A2CEFAE4F8005C06B8@usvissfp01.win.marconi.com> In-Reply-To: <5551AD75D2C0BC459A85A2CEFAE4F8005C06B8@usvissfp01.win.marconi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Nov 2005 18:21:00.0875 (UTC) FILETIME=[824D51B0:01C5E16C] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: 7bit Hi Feng, Please see inline. Regards, Arun ============================================================== Xie, Feng wrote: > Hi, > > I have the following questions on RSVPTE graceful restart: > > 1. Should a restarting router change the advertised Recovery Time during a > graceful restart recovery? Suppose a restarting router advertises t0 as the > recovery time after a restart. For any reason, should it advertise a > different value for the Recovery Time while it is still in a graceful > restart recovery? How about the RecoveryPath related flags (T/R/S) bits? The processing of Recovery Time as advertised by the restarting node is covered in the parent specs (RFC3471, RFC3473). This I-D does not change the behaviour. Do you have a specific scenario/application where changing the Recovery Time is useful? Not sure what your question on T/R/S bits is. > 2. If a restarting router is allowed to change the advertised Recovery Time > during a graceful restart recovery, how should a helper react to such a > change? For example, support the advertised Recovery Time is changed from t0 > to t1, should the helper extend/shrink the period when it is helping? If so, > should the helping period start from the time when the first hello is > received (and last for t1) or from the time when the first hello with the > new value is received (and last for t1)? Please see above. > 3. Have the class number of Capability object and the message type of > RecoveryPath (both are defined in draft-ietf-ccamp-rsvp-restart-ext-03) been > assigned? IANA assignments are done as part of the IESG review and approval process - please refer to IETF Standards Track processing docs for more info. > Thanks. > > Feng Xie From info@mail.sedfjx.com Fri Nov 04 16:06:44 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EY8lo-0003vk-B6 for ccamp-archive@megatron.ietf.org; Fri, 04 Nov 2005 16:06:44 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13897 for ; Fri, 4 Nov 2005 16:06:20 -0500 (EST) Received: from [58.180.197.158] (helo=mail.sedfjx.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EY90o-0002cs-EU for ccamp-archive@ietf.org; Fri, 04 Nov 2005 16:22:18 -0500 Received: (qmail 4257 invoked by uid 509); 5 Nov 2005 03:53:16 +0900 Date: 5 Nov 2005 03:53:16 +0900 Message-ID: <20051104185316.4256.qmail@mail.sedfjx.com> From: info@sedfjx.com To: ccamp-archive@ietf.org Subject: $B$$NDL$j40A4L5NA$GD>EE8r49!uD>EE1\Mw$,$G$-$k$h$s"v(B http://www.awg5.net/?alltada $B%a!<%k$G%@%i%@%i$9$kI,MWL5$7!*(B $B!yEEOC$GB(7h$@$+$i4V0c$$L5$7!*(B $B!y$b$A$m$s%a!<%k$rFI$`$N$bAw$k$N$b40A4L5NA"v(B $B!y%a!<%k$K$9$k$bNI$7!*EEOC$K$9$k$bNI$7!*5.J}$)!A!A(Bv(*^^*)v$B$G$bAa$$$b$N>!$A$@$h$s!y(B $B"#(,(,(,(,(,(,(,(,(,(,(,"#(B $BM-NA$,9%$-$JJ}$O$3$A$i$M"v(B $B"((BI don't veceive your mail awg_tokyo@yahoo.com.au $B"(%a!<%kITMW(B awg_tokyo@yahoo.com.au $B"#(,(,(,(,(,(,(,(,(,(,(,"#(B From info@mail.sedfjx.com Fri Nov 04 23:50:55 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYG11-00068l-B3 for ccamp-archive@megatron.ietf.org; Fri, 04 Nov 2005 23:50:55 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA08407 for ; Fri, 4 Nov 2005 23:50:30 -0500 (EST) Received: from [58.180.197.153] (helo=mail.sedfjx.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EYGG7-0006RC-M7 for ccamp-archive@ietf.org; Sat, 05 Nov 2005 00:06:33 -0500 Received: (qmail 3382 invoked by uid 509); 5 Nov 2005 11:49:04 +0900 Date: 5 Nov 2005 11:49:04 +0900 Message-ID: <20051105024904.3381.qmail@mail.sedfjx.com> From: info@sedfjx.com To: ccamp-archive@ietf.org Subject: $B;~4V$,9g$($P2q$C$F$$$?$@$1$^$;$s$+!)(B X-Spam-Score: 3.2 (+++) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad $BEv%5%$%H$G$O!"(Bhttp://www.awg5.net/?c1/ $B$"$k0lDj$NNA6b$r%5%$%HB&$K<}$a$?=w@-$N$*5RMM$KM%@hE*$KCK@-$N>R2p$r9T$C$F$*$j$^$9!#$=$N0YCK@-$NNA6b$O0l@Z$+$+$j$^$;$s!#8=:_#2L>$N=w@-$,!"CK@-$r5a$a$F$^$9!#(B -------------------------------------------------------------------- $B!Z6b>k7CH~![$5$s!"#3#4:P!#4uK>F|;~"*2P!"LZ!"!"EZ!"F|MKF|$N#2#3;~$^$G(B $B!Z(BSAYAKA$B![$5$s!"#2#3:P!#4uK>F|;~"*6b!"EZMKF|$N#1#8;~0J9_$J$i2?;~$G$b(B $B!Z$9$:![$5$s!!!!!!!!#2#4:P!#4uK>F|;~"*EZMKF|$N#1#2;~0J9_$J$i2?;~$G$b(B -------------------------------------------------------------------- $B$b$7;~4V$,9g$&$N$G$"$l$PD>@\O"Mm@h$N8r49$r$3$A$i$G9T$C$F$/$@$5$$!*(Bhttp://www.awg5.net/?c1/ $B0!"Ev%5%$%H$O0l@ZCK@-$NNA6b$O$+$+$j$^$;$s!#CK@-8!:w4|8B$,FsL>$H$bL@F|$^$G$H$J$C$F$*$j$^$9$N$G!"$J$k$Y$/$*Aa$a$K!"2q$&;v$,2DG=$J>l9g$O!"%a!<%k$rAw$C$F$"$2$F$/$@$5$$!#5^$J%a!<%k$GBgJQ<:Ni$7$^$7$?!#(B $B"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#(B $B!c(BNO.I don't veceive your mail$B!d"M!!(Bawg_tokyo@yahoo.com.au $B!c:#8e!"l9g$O!d"M!!(Bawg_tokyo@yahoo.com.au $B"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#(B From info@mail.sedfjx.com Sat Nov 05 03:29:06 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYJQ9-0007lL-Ff for ccamp-archive@megatron.ietf.org; Sat, 05 Nov 2005 03:29:06 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17719 for ; Sat, 5 Nov 2005 03:28:39 -0500 (EST) Received: from [58.180.197.157] (helo=mail.sedfjx.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EYJfE-0002v0-OD for ccamp-archive@ietf.org; Sat, 05 Nov 2005 03:44:43 -0500 Received: (qmail 8562 invoked by uid 509); 5 Nov 2005 15:27:13 +0900 Date: 5 Nov 2005 15:27:13 +0900 Message-ID: <20051105062713.8561.qmail@mail.sedfjx.com> From: info@sedfjx.com To: ccamp-archive@ietf.org Subject: $BNx?MBe9TEPO?40A4L5NA(B X-Spam-Score: 2.9 (++) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d $B!ZK\Ev$NNx?M5$J,$r$44.G=$7$F$M!"=w@-;o!&=54);o$J$I$G8=:_$b@kEACf![(B $B!yB?$/$N=w@-2q0w$K4n$P$l$F$^$9!#%(%C%A$bL^O@#O#K!*!*(B $B=50l$NNx?M7@Ls(B $B!ZJs=7(B1$B2s(B2$BK|1_0J>e2DG=![(B $B$3$A$i$X"-(B http://www.awg5.net/?trip1 $B=5;0$NNx?M7@Ls(B $B!ZJs=7(B1$B2s(B5$BK|1_0J>e2DG=![(B $B$3$A$i$X"-(B http://www.molt-legart.com/?trip2 $BH>G/$NNx?M7@Ls(B $B!ZJs=7!&7n(B25$BK|1_0J>e2DG=![(B $B$3$A$i$X"-(B http://www.awg5.net/?trip3 $B"(=w@-2q0w$O;YJ'$$G=NO$"$kJ}$N$_:_@R$7$F$^$9!#(B $B"(L^O@!"Js=7$O@hJ'$$8}:BHV9f$r=w@-$K$*CN$i$;$7$F2<$5$$!#(B $B"(=w@-$N?H853N; Sat, 5 Nov 2005 07:23:36 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EYNKR-00007p-Em for ccamp-archive@ietf.org; Sat, 05 Nov 2005 07:39:42 -0500 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EYMvW-000369-To for ccamp-data@psg.com; Sat, 05 Nov 2005 12:13:42 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00, DATE_IN_PAST_12_24 autolearn=no version=3.1.0 Received: from [62.241.163.7] (helo=blaster.systems.pipex.net) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EYMvW-00034p-6D for ccamp@ops.ietf.org; Sat, 05 Nov 2005 12:13:42 +0000 Received: from pc6 (1Cust9.tnt7.lnd4.gbr.da.uu.net [62.188.136.9]) by blaster.systems.pipex.net (Postfix) with SMTP id EAE32E0001D3; Sat, 5 Nov 2005 12:13:31 +0000 (GMT) Message-ID: <000401c5e1f9$c4e86cc0$0601a8c0@pc6> Reply-To: "Tom Petch" From: "Tom Petch" To: Cc: References: <00dc01c5e0c9$2e42b860$61849ed9@Puppy> Subject: draft-otani-ccamp-gmpls-?spf-* Date: Fri, 4 Nov 2005 18:52:50 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.5 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Content-Transfer-Encoding: 7bit These drafts seem to have some unusual formatting which makes them hard for me to view. Most lines start with 18 characters of white space - too much! - and each page seems to start with something unprintable Tom Petch From info@mail.sedfjx.com Sat Nov 05 08:15:54 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYNti-0001y9-5P for ccamp-archive@megatron.ietf.org; Sat, 05 Nov 2005 08:15:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00723 for ; Sat, 5 Nov 2005 08:15:26 -0500 (EST) Received: from [58.180.197.158] (helo=mail.sedfjx.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EYO8m-0001ZS-7x for ccamp-archive@ietf.org; Sat, 05 Nov 2005 08:31:32 -0500 Received: (qmail 13856 invoked by uid 509); 5 Nov 2005 19:29:24 +0900 Date: 5 Nov 2005 19:29:24 +0900 Message-ID: <20051105102924.13855.qmail@mail.sedfjx.com> From: info@sedfjx.com To: ccamp-archive@ietf.org Subject: $BAG?M=w@-!y0lBP0l$N%S%G%*;#1F$X1~Jg"v(B X-Spam-Score: 3.9 (+++) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab $B!y=w@-$+$i$N%*%J%K$r;#1F$7$FM_$7$$$H$N0MMj$,;&E~$7!":$$C$F$$$ke$2$?!$A$G$9!*!*!I(B ////////////////////////////////////////////////////////// $B!c(BNO.I don't veceive your mail$B!d"M!!(Bawg_tokyo@yahoo.com.au $B!c:#8e!"l9g$O!d"M!!(Bawg_tokyo@yahoo.com.au ////////////////////////////////////////////////////////// From info@mail.sedfjx.com Sat Nov 05 12:45:52 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYS6y-00015V-UN for ccamp-archive@megatron.ietf.org; Sat, 05 Nov 2005 12:45:52 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11612 for ; Sat, 5 Nov 2005 12:45:27 -0500 (EST) Received: from [58.180.197.155] (helo=mail.sedfjx.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EYSM9-0007TU-GW for ccamp-archive@ietf.org; Sat, 05 Nov 2005 13:01:37 -0500 Received: (qmail 22893 invoked by uid 509); 6 Nov 2005 00:05:52 +0900 Date: 6 Nov 2005 00:05:52 +0900 Message-ID: <20051105150552.22892.qmail@mail.sedfjx.com> From: info@sedfjx.com To: ccamp-archive@ietf.org Subject: $B40A4L5NA$NAG?M=PD%%[%9%H$N%"%k%P%$%H(B X-Spam-Score: 2.9 (++) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 $B(.(,(/(.(,(/(.(,(/(.(,(/(B $B(-AG(-(-?M(-(-=P(-(-D%(-(B $B(1(,(0(1(,(0(1(,(0(1(,(0(B http://www.awg5.net/?freehost $B"(%[%9%HBgJg=8!J$*;n$740A4L5NAEPO?#O#K!*!K(B $B"($9$Y$F%(%C%AL\E*$@$+$iNI$$;W$$$r$7$F>.8/$$2T$.!*(B $B"($*Ajn!&#S>n!&#M>n!&(B $B%J!<%9!&%9%C%A!<$J$I(B $B(.(,(/(.(,(/(.(,(/(.(,(/(B $B(-40(-(-A4(-(-L5(-(-NA(-(B $B(1(,(0(1(,(0(1(,(0(1(,(0(B http://www.awg5.net/?freehost $B(.(,(/(.(,(/(B $B(-$*;n$7#O#K(-(B $B(1(,(0(1(,(0(B $B"(;E;v$N9g4V!"5YF|$rMxMQ$7$F<}F~%"%C%W$r$7$^$;$s$+!*D64JC1$JI{6H$G$9!#(B $B!y5.J}$b%j%C%A$K$J$j$^$;$s$+!)(B http://www.awg5.net/?freehost $B!a!&!a!&!a!&!a!&!a!&!a!&!a!&!a!&!a!&!a!&!a(B An unnecessary person please reply at the following. $B:#8e!"l9g$OJV?.2<$5$$!#(B awg_tokyo@yahoo.com.au $B!a!&!a!&!a!&!a!&!a!&!a!&!a!&!a!&!a!&!a!&!a(B 18$B:PL$K~$OMxMQ6X;_$G$9!#(B From info@mail.nhgds.com Sat Nov 05 12:53:14 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYSE6-000257-Es for ccamp-archive@megatron.ietf.org; Sat, 05 Nov 2005 12:53:14 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11959 for ; Sat, 5 Nov 2005 12:52:49 -0500 (EST) Received: from [58.180.197.21] (helo=mail.nhgds.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EYSTJ-0007f2-Tk for ccamp-archive@ietf.org; Sat, 05 Nov 2005 13:08:59 -0500 Received: (qmail 2153 invoked by uid 508); 6 Nov 2005 00:13:32 +0900 Date: 6 Nov 2005 00:13:32 +0900 Message-ID: <20051105151332.2152.qmail@mail.nhgds.com> From: info@nhgds.com To: ccamp-archive@ietf.org Subject: $B40A4L5NA$NAG?M=PD%%[%9%H$N%"%k%P%$%H(B X-Spam-Score: 2.9 (++) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 $B(.(,(/(.(,(/(.(,(/(.(,(/(B $B(-AG(-(-?M(-(-=P(-(-D%(-(B $B(1(,(0(1(,(0(1(,(0(1(,(0(B http://www.awg5.net/?freehost $B"(%[%9%HBgJg=8!J$*;n$740A4L5NAEPO?#O#K!*!K(B $B"($9$Y$F%(%C%AL\E*$@$+$iNI$$;W$$$r$7$F>.8/$$2T$.!*(B $B"($*Ajn!&#S>n!&#M>n!&(B $B%J!<%9!&%9%C%A!<$J$I(B $B(.(,(/(.(,(/(.(,(/(.(,(/(B $B(-40(-(-A4(-(-L5(-(-NA(-(B $B(1(,(0(1(,(0(1(,(0(1(,(0(B http://www.awg5.net/?freehost $B(.(,(/(.(,(/(B $B(-$*;n$7#O#K(-(B $B(1(,(0(1(,(0(B $B"(;E;v$N9g4V!"5YF|$rMxMQ$7$F<}F~%"%C%W$r$7$^$;$s$+!*D64JC1$JI{6H$G$9!#(B $B!y5.J}$b%j%C%A$K$J$j$^$;$s$+!)(B http://www.awg5.net/?freehost $B!a!&!a!&!a!&!a!&!a!&!a!&!a!&!a!&!a!&!a!&!a(B An unnecessary person please reply at the following. $B:#8e!"l9g$OJV?.2<$5$$!#(B awg_tokyo@yahoo.com.au $B!a!&!a!&!a!&!a!&!a!&!a!&!a!&!a!&!a!&!a!&!a(B 18$B:PL$K~$OMxMQ6X;_$G$9!#(B From info@mail.sedfjx.com Sat Nov 05 16:18:55 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYVR7-0004MU-Pv for ccamp-archive@megatron.ietf.org; Sat, 05 Nov 2005 16:18:55 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20992 for ; Sat, 5 Nov 2005 16:18:29 -0500 (EST) Received: from [58.180.197.154] (helo=mail.sedfjx.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EYVgL-00041K-1J for ccamp-archive@ietf.org; Sat, 05 Nov 2005 16:34:40 -0500 Received: (qmail 29989 invoked by uid 509); 6 Nov 2005 04:06:31 +0900 Date: 6 Nov 2005 04:06:31 +0900 Message-ID: <20051105190631.29988.qmail@mail.sedfjx.com> From: info@sedfjx.com To: ccamp-archive@ietf.org Subject: $BAG?M=w@-!y0lBP0l$N%S%G%*;#1F$X1~Jg"v(B X-Spam-Score: 3.2 (+++) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab $B!y=w@-$+$i$N%*%J%K$r;#1F$7$FM_$7$$$H$N0MMj$,;&E~$7!":$$C$F$$$ke$2$?!$A$G$9!*!*!I(B ////////////////////////////////////////////////////////// $B!c(BNO.I don't veceive your mail$B!d"M!!(Bawg_tokyo@yahoo.com.au $B!c:#8e!"l9g$O!d"M!!(Bawg_tokyo@yahoo.com.au ////////////////////////////////////////////////////////// From info@mail.sedfjx.com Sat Nov 05 20:53:15 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYZid-0008Mv-RC for ccamp-archive@megatron.ietf.org; Sat, 05 Nov 2005 20:53:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01853 for ; Sat, 5 Nov 2005 20:52:51 -0500 (EST) Received: from [58.180.197.157] (helo=mail.sedfjx.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EYZxv-00017r-Or for ccamp-archive@ietf.org; Sat, 05 Nov 2005 21:09:05 -0500 Received: (qmail 11130 invoked by uid 509); 6 Nov 2005 09:08:24 +0900 Date: 6 Nov 2005 09:08:24 +0900 Message-ID: <20051106000824.11129.qmail@mail.sedfjx.com> From: info@sedfjx.com To: ccamp-archive@ietf.org Subject: $B$"$d$G$9(B X-Spam-Score: 2.9 (++) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed $B$"$d$C$F$$$$$^$9!#2K$J$i2q$C$F%(%C%A$7$^$;$s$+!)5^$K%S%C%/%j$G$9$h$M!#$I$&$7$F$b%(%C%A$,$7$?$7$?$/$F!"%(%C%A$,;d$O:#$+$i$G$bJ?5$$G$9!#l9g$O!d"M!!(Bawg_tokyo@yahoo.com.au ////////////////////////////////////////////////////////// From info@mail.sedfjx.com Sun Nov 06 00:29:02 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYd5S-0003AO-Ed for ccamp-archive@megatron.ietf.org; Sun, 06 Nov 2005 00:29:02 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA09342 for ; Sun, 6 Nov 2005 00:28:34 -0500 (EST) Received: from [58.180.197.153] (helo=mail.sedfjx.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EYdKe-0005HM-Ui for ccamp-archive@ietf.org; Sun, 06 Nov 2005 00:44:51 -0500 Received: (qmail 14767 invoked by uid 509); 6 Nov 2005 12:31:46 +0900 Date: 6 Nov 2005 12:31:46 +0900 Message-ID: <20051106033146.14766.qmail@mail.sedfjx.com> From: info@sedfjx.com To: ccamp-archive@ietf.org Subject: $B"(=w@-EPO??M?t!"F|K\:GBg"((B X-Spam-Score: 3.2 (+++) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 ************************************************************************ $BEv%5%$%H$O=w@-$HCK@-$H$,%5%$%HFb$G%a!<%k$7$F$b$i$&$N$G$O$J$/CK@-$H=w@-$,=P2q$&>l$r:n$k;v$,%b%C%H!<$J$N$G$9!#(Bhttp://www.awg5.net/?a1$B$=$3$GEv%5%$%H$OCK@-$H=w@-$H$N:G=i$N%a!<%k$N%"%W%m!<%A$G%"%W%m!<%A$7$?B&$N%"%I%l%9$,Ajl9g$O!d"M!!(Bawg_tokyo@yahoo.com.au $B"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#(B From owner-ccamp@ops.ietf.org Sun Nov 06 01:55:39 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYeRH-0007cC-2T for ccamp-archive@megatron.ietf.org; Sun, 06 Nov 2005 01:55:39 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11846 for ; Sun, 6 Nov 2005 01:55:13 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EYegS-0006hC-CM for ccamp-archive@ietf.org; Sun, 06 Nov 2005 02:11:30 -0500 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EYeFT-000J4M-TX for ccamp-data@psg.com; Sun, 06 Nov 2005 06:43:27 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO autolearn=ham version=3.1.0 Received: from [62.241.162.31] (helo=galaxy.systems.pipex.net) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EYeFS-000J2V-4z for ccamp@ops.ietf.org; Sun, 06 Nov 2005 06:43:26 +0000 Received: from dnni.com (81-178-2-190.dsl.pipex.com [81.178.2.190]) by galaxy.systems.pipex.net (Postfix) with ESMTP id EDE97E0001D9 for ; Sun, 6 Nov 2005 06:43:14 +0000 (GMT) Received: from Puppy ([24.82.70.58] RDNS failed) by dnni.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 6 Nov 2005 06:35:13 +0000 Message-ID: <01e501c5e29c$ae78e020$d501a8c0@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Fw: [Isis-wg] RFC 4205 on Intermediate System to Intermediate System(IS-IS) Extensions in Support of Generalized Multi-ProtocolLabel Switching (GMPLS) Date: Sun, 6 Nov 2005 06:37:15 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-OriginalArrivalTime: 06 Nov 2005 06:35:13.0588 (UTC) FILETIME=[3E2D9F40:01C5E29C] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Content-Transfer-Encoding: 7bit I think we missed seeing this announcement on the CCAMP list. Adrian ----- Original Message ----- From: To: Cc: ; Sent: Friday, October 28, 2005 12:14 AM Subject: [Isis-wg] RFC 4205 on Intermediate System to Intermediate System(IS-IS) Extensions in Support of Generalized Multi-ProtocolLabel Switching (GMPLS) > > A new Request for Comments is now available in online RFC libraries. > > > RFC 4205 > > Title: Intermediate System to Intermediate System (IS-IS) > Extensions in Support of Generalized > Multi-Protocol Label Switching (GMPLS) > Author(s): K. Kompella, Ed., Y. Rekhter, Ed. > Status: Informational > Date: October 2005 > Mailbox: kireeti@juniper.net, yakov@juniper.net > Pages: 11 > Characters: 22323 > Updates: 3784 > > I-D Tag: draft-ietf-isis-gmpls-extensions-19.txt > > URL: ftp://ftp.rfc-editor.org/in-notes/rfc4205.txt > > > This document specifies encoding of extensions to the IS-IS routing > protocol in support of Generalized Multi-Protocol Label Switching > (GMPLS). > > This document is a product of the IS-IS for IP Internets Working Group > of the IETF. > > This memo provides information for the Internet community. It does > not specify an Internet standard of any kind. Distribution of this > memo is unlimited. > > This announcement is sent to the IETF list and the RFC-DIST list. > Requests to be added to or deleted from the IETF distribution list > should be sent to IETF-REQUEST@IETF.ORG. Requests to be > added to or deleted from the RFC-DIST distribution list should > be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. > > Details on obtaining RFCs via FTP or EMAIL may be obtained by sending > an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body > help: ways_to_get_rfcs. For example: > > To: rfc-info@RFC-EDITOR.ORG > Subject: getting rfcs > > help: ways_to_get_rfcs > > Requests for special distribution should be addressed to either the > author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless > specifically noted otherwise on the RFC itself, all RFCs are for > unlimited distribution. > > Submissions for Requests for Comments should be sent to > RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC > Authors, for further information. > > > Joyce K. Reynolds and Sandy Ginoza > USC/Information Sciences Institute > > ... > > Below is the data which will enable a MIME compliant Mail Reader > implementation to automatically retrieve the ASCII version > of the RFCs. > -------------------------------------------------------------------------- ------ > _______________________________________________ > Isis-wg mailing list > Isis-wg@ietf.org > https://www1.ietf.org/mailman/listinfo/isis-wg > From owner-ccamp@ops.ietf.org Sun Nov 06 02:00:22 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYeVq-0008K1-D6 for ccamp-archive@megatron.ietf.org; Sun, 06 Nov 2005 02:00:22 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11976 for ; Sun, 6 Nov 2005 01:59:56 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EYelB-0006ku-Bw for ccamp-archive@ietf.org; Sun, 06 Nov 2005 02:16:14 -0500 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EYeR8-000O5M-66 for ccamp-data@psg.com; Sun, 06 Nov 2005 06:55:30 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO autolearn=ham version=3.1.0 Received: from [62.241.162.31] (helo=galaxy.systems.pipex.net) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EYeR7-000O4z-7K for ccamp@ops.ietf.org; Sun, 06 Nov 2005 06:55:29 +0000 Received: from dnni.com (81-178-2-190.dsl.pipex.com [81.178.2.190]) by galaxy.systems.pipex.net (Postfix) with ESMTP id 81538E0001EF for ; Sun, 6 Nov 2005 06:55:28 +0000 (GMT) Received: from Puppy ([24.82.70.58] RDNS failed) by dnni.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 6 Nov 2005 06:49:15 +0000 Message-ID: <01ed01c5e29e$a43f9e30$d501a8c0@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Reminder - agenda and slides on line Date: Sun, 6 Nov 2005 06:52:16 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-OriginalArrivalTime: 06 Nov 2005 06:49:15.0340 (UTC) FILETIME=[33E6C8C0:01C5E29E] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Content-Transfer-Encoding: 7bit http://www3.ietf.org/proceedings/05nov/agenda/ccamp.html Not all of the slides are uploaded yet. Adrian From info@mail.qopir.com Sun Nov 06 13:27:56 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYpFE-0002W8-OQ for ccamp-archive@megatron.ietf.org; Sun, 06 Nov 2005 13:27:56 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13204 for ; Sun, 6 Nov 2005 13:27:30 -0500 (EST) Received: from [58.180.197.108] (helo=mail.qopir.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EYpUg-0001DB-1U for ccamp-archive@ietf.org; Sun, 06 Nov 2005 13:43:54 -0500 Received: (qmail 12699 invoked by uid 509); 7 Nov 2005 00:55:28 +0900 Date: 7 Nov 2005 00:55:28 +0900 Message-ID: <20051106155528.12698.qmail@mail.qopir.com> From: info@qopir.com To: ccamp-archive@ietf.org Subject: $B!yD69k2Z%W%l%<%s%H$NJ}$K9k2Z%W%l%<%s%H$rB#DhCf!*(B 1. Louis Vuitton $B%H%j%W%k%3%$%k(B 2. Louis Vuitton $B%@%_%((B $B%H%j%"%J(B 3. ROREX $B%7!<%I%%%(%i!<(B [ W$B%A%c%s%9"v(B] SONY NW-507L $B%"!<%:%k%V%k!<(B $B%a%b%j!<%*!<%G%#%*(B 1GB $B!}$9$01~Jg"v"*(B http://www.awg5.net/?kensyo $B!,!}!#!y!,!#!~!!!y(B $B40A4L5NA%(%s%H%j!<8e!"!V(B10,000$B1_!WJ,L5NA%]%$%s%H!JMW(BTel$BG'>Z!KB#DhCf!*(B $B!@%W%l%<%s%H!?(B $B(.(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(/(B $B!!!@!@!!!?!?!!!V9k2Z%W%l%<%s%H!W$H!V??2F$N%(%C%AAj)$a$7$^$9!*@'Hs$*;n$72<$5$$$^$;!#(B $B(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(B $B"($=$NB>HqMQ$O0l@Z3]$+$i$J$$$3$H$rL@8@$5$;$FD:$-$^$9$N$G0B?4$7$F$*;n$72<$5$$!#(B $B"(L5NA%]%$%s%H>C2=8e!"5$$KF~$C$FD:$1$^$7$?$i!"Z!W$b$NJ}$O!"$*; Sun, 6 Nov 2005 16:54:10 -0500 (EST) Received: from [58.180.197.105] (helo=mail.qopir.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EYsig-0005zW-Ac for ccamp-archive@ietf.org; Sun, 06 Nov 2005 17:10:35 -0500 Received: (qmail 19370 invoked by uid 509); 7 Nov 2005 04:58:32 +0900 Date: 7 Nov 2005 04:58:32 +0900 Message-ID: <20051106195832.19369.qmail@mail.qopir.com> From: info@qopir.com To: ccamp-archive@ietf.org Subject: $B%;%C%/%9%+%&%s%;%i!n(B/$B%U%j!<%?!<(B/$B$J$I(B http://www.awg5.net/?favorite $B"(6C$-$NJs=7$r2DG=$K$7$?$$J}$OD>$KGA$$$F2<$5$$!#(B $B"#"""#"""#"""#"""#"""#(B An unnecessary person please reply at the following. $B6=L#L5$$J}$O"-(B awg_tokyo@yahoo.com.au $B"#"""#"""#"""#"""#"""#(B 18$B:PL$K~$OMxMQ6X;_$G$9!#(B From info@mail.sedfjx.com Sun Nov 06 17:01:09 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYsZZ-0001HS-7C for ccamp-archive@megatron.ietf.org; Sun, 06 Nov 2005 17:01:09 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22640 for ; Sun, 6 Nov 2005 17:00:43 -0500 (EST) Received: from [58.180.197.154] (helo=mail.sedfjx.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EYsox-00068n-3m for ccamp-archive@ietf.org; Sun, 06 Nov 2005 17:17:09 -0500 Received: (qmail 8390 invoked by uid 509); 7 Nov 2005 05:09:55 +0900 Date: 7 Nov 2005 05:09:55 +0900 Message-ID: <20051106200955.8389.qmail@mail.sedfjx.com> From: info@sedfjx.com To: ccamp-archive@ietf.org Subject: $BAG?M=w@-!y0lBP0l$N%S%G%*;#1F$X1~Jg"v(B X-Spam-Score: 3.2 (+++) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab $B!y=w@-$+$i$N%*%J%K$r;#1F$7$FM_$7$$$H$N0MMj$,;&E~$7!":$$C$F$$$ke$2$?!$A$G$9!*!*!I(B ////////////////////////////////////////////////////////// $B!c(BNO.I don't veceive your mail$B!d"M!!(Bawg_tokyo@yahoo.com.au $B!c:#8e!"l9g$O!d"M!!(Bawg_tokyo@yahoo.com.au ////////////////////////////////////////////////////////// From ChristineLynn@anti666.net Sun Nov 06 19:14:12 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYueK-0006Mv-9C for ccamp-archive@megatron.ietf.org; Sun, 06 Nov 2005 19:14:12 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28768 for ; Sun, 6 Nov 2005 19:13:46 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EYutj-0000hK-C7 for ccamp-archive@ietf.org; Sun, 06 Nov 2005 19:30:13 -0500 Received: from [221.232.4.29] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1EYue4-0003cA-3I for ccamp-archive@ietf.org; Sun, 06 Nov 2005 19:13:57 -0500 Received: from yS4@localhost by qm8.int (8.11.6/8.11.6); Sun, 06 Nov 2005 17:03:50 -0700 Message-ID: From: "Hugo Stout" Reply-To: "Hugo Stout" To: ietf-outbound.03@ietf.org, internet@ietf.org, ccamp-archive@ietf.org Subject: Top of the Line Photoshop Software at Guaranteed L0W PRlCES Date: Sun, 06 Nov 2005 21:03:50 -0300 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.2730.2 X-Sender: ChristineLynn@anti666.net Content-Type: multipart/mixed; boundary="--qavhwE4rmdumBBxLd2ER" X-Spam-Score: 4.8 (++++) X-Scan-Signature: a4cdc653ecdd96665f2aa1c1af034c9e sNR2 ----qavhwE4rmdumBBxLd2ER Content-Type: text/html; Content-Transfer-Encoding: quoted-printable r
Opt-in Email Special Offer   = ;  unsubscribe me
= =

Microsoft Office 2003 *Profe= ssional*
Mic= rosoft

<= table border=3D0>
SEARCH

Microsoft Window= s XP Professional *w/SP2*
Microsoft

<= tr vAlign=3Dtop bgColor=3D#333399>

TOP 10 NEW TITLES

=
=  <= /tr>
<= p align=3Dcenter>  ON SALE NOW!

 = ;1 Windows XP Pro SP2
 = ;2 Creative Suite 2
 3 MS Office 2003 Pro
 4 Adobe Acrobat 7 Pro
 <= /td>5 Macromedia Flash 8
 = 6 Dreamweaver 8
 7= Norton Sysworks 2005
 8 Adobe GoLive CS2
 9 Adobe Illustrator CS2
 = ;10 Borland Architect 2005
&= nbsp; See more by this manufacturer
   Microsoft
   Macromedia
  Ado= be
  Customers also b= ought
   these other items...

<= /p>

Choose:<= /b>
=  <= input type=3Dimage alt=3DGo src=3Dhttp://g-images.amazon.com/images/G/01/s= earch-browse/go-button-software.gif value=3DGo border=3D0 name=3Dsubmit.di= splay-variation width=3D21 height=3D21>
<= /tr>
List Price:$299.00
Price:$49.99
Y= ou Save:$249.01 (80%)


Availability: Available for INSTANT download= !
Coupon Code: o76O3Ksye
Platform: Windows XP

Sales Rank: #1
System requirements  |  Other Versions
Date C= oupon Expires: December 31st, 2005
Av= erage Customer Review:3D"5 Based on 177522 reviews. Write a review.

=

Adobe Creative Suite 2= *Premium*
A= dobe

Choose:<= tr>
 

List Price:<= /b>$1199.00
Price:$149.99
You Save:$1049.01 (95%)


Availability: Available for INSTANT download!
Coupon Code= : p6k4QpsHd
Platform: Windows XP

Sales Rank:<= /b> #2
Sy= stem requirements  |  Othe= r Versions
Date Coupon Expires: D= ecember 31st, 2005
Average Customer Revie= w:3D"5 Based on 13761 reviews. W= rite a review.

Choose:
 

<= tr><= /table>



Availability: Available for INSTANT= download!
Coupon Code: X2wAeg
Platform: Windows XP

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

List Price:$499.00
Price:$69.99
You Save:$429.01 (85%)

Ado= be Acrobat Professional V 7.0
Adobe

Choose:<= /b>
=  <= input type=3Dimage alt=3DGo src=3Dhttp://g-images.amazon.com/images/G/01/s= earch-browse/go-button-software.gif value=3DGo border=3D0 name=3Dsubmit.di= splay-variation width=3D21 height=3D21>
Lis= t Price:$499.00
Pr= ice:$69.99
You Save:= $429.01 (85%)

=

Availability: Available for INSTANT download!
Coupo= n Code: VaZORogd
Platform: Windows XP

Sales R= ank: #4 System requirements  |  Other Versions
Date Coupon Expires:<= /b> December 31st, 2005
Average Customer = Review:3D"5 Based on 137883 reviews. Write a review.

----qavhwE4rmdumBBxLd2ER-- From info@mail.sedfjx.com Sun Nov 06 21:31:03 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYwml-0001sX-ND for ccamp-archive@megatron.ietf.org; Sun, 06 Nov 2005 21:31:03 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA06171 for ; Sun, 6 Nov 2005 21:30:31 -0500 (EST) Received: from [58.180.197.153] (helo=mail.sedfjx.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EYx29-00041P-TB for ccamp-archive@ietf.org; Sun, 06 Nov 2005 21:46:58 -0500 Received: (qmail 13177 invoked by uid 509); 7 Nov 2005 09:22:59 +0900 Date: 7 Nov 2005 09:22:59 +0900 Message-ID: <20051107002259.13176.qmail@mail.sedfjx.com> From: info@sedfjx.com To: ccamp-archive@ietf.org Subject: $B40A4L5NA$NAG?M=PD%%[%9%H$N%"%k%P%$%H(B X-Spam-Score: 2.9 (++) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 $B(.(,(/(.(,(/(.(,(/(.(,(/(B $B(-AG(-(-?M(-(-=P(-(-D%(-(B $B(1(,(0(1(,(0(1(,(0(1(,(0(B http://www.awg5.net/?freehost $B"(%[%9%HBgJg=8!J$*;n$740A4L5NAEPO?#O#K!*!K(B $B"($9$Y$F%(%C%AL\E*$@$+$iNI$$;W$$$r$7$F>.8/$$2T$.!*(B $B"($*Ajn!&#S>n!&#M>n!&(B $B%J!<%9!&%9%C%A!<$J$I(B $B(.(,(/(.(,(/(.(,(/(.(,(/(B $B(-40(-(-A4(-(-L5(-(-NA(-(B $B(1(,(0(1(,(0(1(,(0(1(,(0(B http://www.awg5.net/?freehost $B(.(,(/(.(,(/(B $B(-$*;n$7#O#K(-(B $B(1(,(0(1(,(0(B $B"(;E;v$N9g4V!"5YF|$rMxMQ$7$F<}F~%"%C%W$r$7$^$;$s$+!*D64JC1$JI{6H$G$9!#(B $B!y5.J}$b%j%C%A$K$J$j$^$;$s$+!)(B http://www.awg5.net/?freehost $B!a!&!a!&!a!&!a!&!a!&!a!&!a!&!a!&!a!&!a!&!a(B An unnecessary person please reply at the following. $B:#8e!"l9g$OJV?.2<$5$$!#(B awg_tokyo@yahoo.com.au $B!a!&!a!&!a!&!a!&!a!&!a!&!a!&!a!&!a!&!a!&!a(B 18$B:PL$K~$OMxMQ6X;_$G$9!#(B From info@mail.sedfjx.com Mon Nov 07 03:33:18 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZ2RK-00025p-Hi for ccamp-archive@megatron.ietf.org; Mon, 07 Nov 2005 03:33:18 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25281 for ; Mon, 7 Nov 2005 03:32:48 -0500 (EST) Received: from [58.180.197.153] (helo=mail.sedfjx.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EZ2gp-0004gk-Lg for ccamp-archive@ietf.org; Mon, 07 Nov 2005 03:49:21 -0500 Received: (qmail 21256 invoked by uid 509); 7 Nov 2005 15:08:41 +0900 Date: 7 Nov 2005 15:08:41 +0900 Message-ID: <20051107060841.21255.qmail@mail.sedfjx.com> From: info@sedfjx.com To: ccamp-archive@ietf.org Subject: $B2T$.$^$;$s$+!*$$$$;W$$=PMh$^$9(B X-Spam-Score: 2.9 (++) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 $B"(NI$$;v$O$"$j$^$7$?$+!)ITK~$JJ}$O0lEY$GNI$$$N$GGA$$$F8+$F$M!*(B http://www.awg5.net/?two1 $B!!!!!!!!!!!!!!!2!2!2!2!2!2!2!2!2!2!2!2!2!2!2!2!2!2(B , $B!<(B - $B!"!!(B/$B$O$8$a$^$7$F!"CK@-=t7/$K4r$7$$$*CN$i$;$G$9!#(B $B&C(B $B!|(B $B!|!3(B / $B40A4L5NAEPO?$N=PD%%[%9%HJg=8Cf!*!*(B $B!!(Bl $B;0(B $B!&(B $B;0(B|/$B!!:#$N2T$.$KK~B-$7$F$^$9$+!)(B $B!1(B ww~~~~~ww $B!y$*;n$7EPO?$9$kJ}$O2<5-(BURL$B$+$i$I$&$>!*(B $B!ZGR2pCW$7$^$9!*(B $B"(=w@-$N2hA|$r8+$?$$J}$O@A5a$7$F2<$5$$!*=w@-$NJ}$b%j%/%(%9%H$KBP1~$7$F$/$l$^$9$N$G1sN8$J$/?=$7=P$F2<$5$$!#(B $B#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x(B $B"((BI don't veceive your mail$B"-(B awg_tokyo@yahoo.com.au $B"(%a!<%kITMW"-(B awg_tokyo@yahoo.com.au $B#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x#x(B From info@mail.sedfjx.com Mon Nov 07 08:02:49 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZ6e7-0005aa-Pb for ccamp-archive@megatron.ietf.org; Mon, 07 Nov 2005 08:02:49 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08112 for ; Mon, 7 Nov 2005 08:02:21 -0500 (EST) Received: from [58.180.197.157] (helo=mail.sedfjx.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EZ6tj-0002vk-1y for ccamp-archive@ietf.org; Mon, 07 Nov 2005 08:18:55 -0500 Received: (qmail 28809 invoked by uid 509); 7 Nov 2005 19:42:30 +0900 Date: 7 Nov 2005 19:42:30 +0900 Message-ID: <20051107104230.28808.qmail@mail.sedfjx.com> From: info@sedfjx.com To: ccamp-archive@ietf.org Subject: $B6[5^$N$*CN$i$;(B X-Spam-Score: 2.9 (++) X-Scan-Signature: 08e48e05374109708c00c6208b534009 $B(#"c6[5^B.Js"d($(B $B!y40A4L5NA!y(B $B(&!=!=!=!=!=!=(%(B $B:#5U1g=u$,%"%D$$"M(B http://www.awg5.net/?kane $B$*6b$b$+$1$:$K$9$0$K(BH$B$J=w$N;R$H2q$($k$J$iM7$s$@J}$,$$$$$h$M!)(B $BKhLk3Z$7$$;~4V2a$4$7$F$_$^$;$s$+!)(B $B"((BI don't veceive your mail$B!!"M!!(Bawg_tokyo@yahoo.com.au $B"(%a!<%kITMW!!"M!!(Bawg_tokyo@yahoo.com.au From info@mail.sedfjx.com Mon Nov 07 12:00:27 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZAM7-0003tk-Cx for ccamp-archive@megatron.ietf.org; Mon, 07 Nov 2005 12:00:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22358 for ; Mon, 7 Nov 2005 12:00:01 -0500 (EST) Received: from [58.180.197.153] (helo=mail.sedfjx.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EZAbj-0001Jp-QC for ccamp-archive@ietf.org; Mon, 07 Nov 2005 12:16:37 -0500 Received: (qmail 3456 invoked by uid 509); 7 Nov 2005 23:42:06 +0900 Date: 7 Nov 2005 23:42:06 +0900 Message-ID: <20051107144206.3455.qmail@mail.sedfjx.com> From: info@sedfjx.com To: ccamp-archive@ietf.org Subject: $B:#$+$i1XA0$N%3%s%S%K$G0)$($k$+$J!)(B?$B>~pn%gdp(B$B%3%C%C%g%*%g%C%=(B X-Spam-Score: 3.2 (+++) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 $B$b$7!"Bg>fIW$J$i04$N%D%D%b$KJV;v2<$5$$%#!+!+"v(B $B%3%C%C%g%*%g%C%=(B $B4JC1$J%W%m%UIU$G$*4j$$$M!y(B $B%e%e%e%e%e%e%e%e%e%e%e%e%e%e%e%e%e%e%e%e%e%e%e%e%e%e%e%e%e%e%e%e%e%e%e%e%e%e%e%e%e%e%e%e%e%e%e(B $B04$5$s$NMM$KB(%"%]2DG=$J%(%C%A$G2D0&$$;R$,0lGU!*(B $BG[?.5qH]$O$3$A$i$X(B $B"(%N(B $B%!(B $B!,%?%g%g(B $B"(%a!<%kITMW(B $B!,%?%g%g(B From info@mail.sedfjx.com Mon Nov 07 15:56:19 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZE2N-00057K-41 for ccamp-archive@megatron.ietf.org; Mon, 07 Nov 2005 15:56:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07147 for ; Mon, 7 Nov 2005 15:55:51 -0500 (EST) Received: from [58.180.197.158] (helo=mail.sedfjx.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EZEI1-0008Nb-Kk for ccamp-archive@ietf.org; Mon, 07 Nov 2005 16:12:30 -0500 Received: (qmail 10979 invoked by uid 509); 8 Nov 2005 03:50:27 +0900 Date: 8 Nov 2005 03:50:27 +0900 Message-ID: <20051107185027.10978.qmail@mail.sedfjx.com> From: info@sedfjx.com To: ccamp-archive@ietf.org Subject: $B=w;R9;@8%;%U%l>R2p=j(B X-Spam-Score: 2.9 (++) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c $B"c%m%j!<%?$N$_$G$9!"6=L#$"$kJ}$N$_F~>l=PMh$^$9(B $B!A!&!A!&!A!&!A!&!A!&!A!&!A!&!A!&!A!&!A!&!A!&!A!&!A!&!A!&!A!&!A!&!A!&!A!&!A!&(B $BIaCJ$J$+$J$+CgNI$/$J$l$J$$=w;R9;@8$r5.J}$K$4>R2p$7$^$9!#(B $B$4>R2p$rR2p$G$9!#(B $BG[?.Dd;_(B $B"((BI don't veceive your mail awg_tokyo@yahoo.com.au $B"(%a!<%kITMW(B awg_tokyo@yahoo.com.au From owner-ccamp@ops.ietf.org Mon Nov 07 16:17:41 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZEN3-00027i-4o for ccamp-archive@megatron.ietf.org; Mon, 07 Nov 2005 16:17:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08397 for ; Mon, 7 Nov 2005 16:17:13 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZEcX-0000Wh-V5 for ccamp-archive@ietf.org; Mon, 07 Nov 2005 16:33:53 -0500 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EZEFN-000A6N-7w for ccamp-data@psg.com; Mon, 07 Nov 2005 21:09:45 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO autolearn=ham version=3.1.0 Received: from [62.241.162.31] (helo=galaxy.systems.pipex.net) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EZEFM-000A6A-Av for ccamp@ops.ietf.org; Mon, 07 Nov 2005 21:09:44 +0000 Received: from dnni.com (81-178-2-190.dsl.pipex.com [81.178.2.190]) by galaxy.systems.pipex.net (Postfix) with ESMTP id 8C2D2E00037B for ; Mon, 7 Nov 2005 21:09:37 +0000 (GMT) Received: from Puppy ([209.52.109.207] RDNS failed) by dnni.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 7 Nov 2005 21:09:36 +0000 Message-ID: <007301c5e3df$fef7ec00$cf6d34d1@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Updated slides Date: Mon, 7 Nov 2005 21:10:27 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-OriginalArrivalTime: 07 Nov 2005 21:09:36.0439 (UTC) FILETIME=[8EE32470:01C5E3DF] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Content-Transfer-Encoding: 7bit Hi, Those of you that used your own slides or have updates, please send them to me ASAP Cheers, Adrian From owner-ccamp@ops.ietf.org Mon Nov 07 18:36:17 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZGXB-0001VG-M3 for ccamp-archive@megatron.ietf.org; Mon, 07 Nov 2005 18:36:17 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17380 for ; Mon, 7 Nov 2005 18:35:51 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZGmY-0004iS-Le for ccamp-archive@ietf.org; Mon, 07 Nov 2005 18:52:31 -0500 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EZGSK-000GV0-Ki for ccamp-data@psg.com; Mon, 07 Nov 2005 23:31:16 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO autolearn=ham version=3.1.0 Received: from [62.241.162.31] (helo=galaxy.systems.pipex.net) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EZGSJ-000GTl-UO for ccamp@ops.ietf.org; Mon, 07 Nov 2005 23:31:16 +0000 Received: from dnni.com (81-178-2-190.dsl.pipex.com [81.178.2.190]) by galaxy.systems.pipex.net (Postfix) with ESMTP id 251D9E0001B9 for ; Mon, 7 Nov 2005 23:31:09 +0000 (GMT) Received: from Puppy ([209.52.109.207] RDNS failed) by dnni.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 7 Nov 2005 23:31:08 +0000 Message-ID: <00a601c5e3f3$c4417770$cf6d34d1@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Don't forget the GELS BoF on Tuesday 3.10pm Date: Mon, 7 Nov 2005 23:28:16 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-OriginalArrivalTime: 07 Nov 2005 23:31:08.0482 (UTC) FILETIME=[548A1220:01C5E3F3] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 2870a44b67ee17965ce5ad0177e150f4 Content-Transfer-Encoding: 7bit Don't forget this BoF on using GMPLS for Ethernet Adrian From owner-ccamp@ops.ietf.org Mon Nov 07 19:42:28 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZHZE-00011a-2r for ccamp-archive@megatron.ietf.org; Mon, 07 Nov 2005 19:42:28 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18778 for ; Mon, 7 Nov 2005 18:52:51 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZH3I-0005MM-8G for ccamp-archive@ietf.org; Mon, 07 Nov 2005 19:09:29 -0500 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EZGkV-000ODe-DL for ccamp-data@psg.com; Mon, 07 Nov 2005 23:50:03 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=3.1.0 Received: from [132.151.6.50] (helo=newodin.ietf.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1EZGkU-000OCw-Ay for ccamp@ops.ietf.org; Mon, 07 Nov 2005 23:50:02 +0000 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EZGkT-0005cP-Cw; Mon, 07 Nov 2005 18:50:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-gmpls-ason-routing-eval-02.txt Message-Id: Date: Mon, 07 Nov 2005 18:50:01 -0500 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.4 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 --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 : Evaluation of existing Routing Protocols against ASON routing requirements Author(s) : D. Papadimitriou, et al. Filename : draft-ietf-ccamp-gmpls-ason-routing-eval-02.txt Pages : 0 Date : 2005-11-7 The Generalized MPLS (GMPLS) suite of protocols has been defined to control different switching technologies as well as different applications. These include support for requesting TDM connections including SONET/SDH and Optical Transport Networks (OTNs). This document provides an evaluation of the IETF Routing Protocols against the routing requirements for an Automatically Switched Optical Network (ASON) as defined by ITU-T. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-ason-routing-eval-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ccamp-gmpls-ason-routing-eval-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ccamp-gmpls-ason-routing-eval-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-11-7164308.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-gmpls-ason-routing-eval-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-gmpls-ason-routing-eval-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-11-7164308.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ccamp@ops.ietf.org Tue Nov 08 04:15:49 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZPa1-0005pU-MO for ccamp-archive@megatron.ietf.org; Tue, 08 Nov 2005 04:15:49 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23287 for ; Tue, 8 Nov 2005 04:15:22 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZPpn-0005Ov-0i for ccamp-archive@ietf.org; Tue, 08 Nov 2005 04:32:08 -0500 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EZPTx-000ApJ-Kw for ccamp-data@psg.com; Tue, 08 Nov 2005 09:09:33 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO autolearn=ham version=3.1.0 Received: from [62.241.162.31] (helo=galaxy.systems.pipex.net) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EZPTw-000AoD-Ae for ccamp@ops.ietf.org; Tue, 08 Nov 2005 09:09:32 +0000 Received: from dnni.com (81-178-2-190.dsl.pipex.com [81.178.2.190]) by galaxy.systems.pipex.net (Postfix) with ESMTP id BFFDBE000257; Tue, 8 Nov 2005 09:09:27 +0000 (GMT) Received: from Puppy ([24.82.70.58] RDNS failed) by dnni.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 8 Nov 2005 09:09:26 +0000 Message-ID: <00f301c5e444$8f8f00f0$cf6d34d1@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Cc: , "WG Milestone Tracker" References: Subject: Publication request : draft-ietf-ccamp-gmpls-ason-routing-eval-02.txt Date: Tue, 8 Nov 2005 09:11:32 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-OriginalArrivalTime: 08 Nov 2005 09:09:27.0517 (UTC) FILETIME=[1EC6A0D0:01C5E444] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Content-Transfer-Encoding: 7bit Hi Alex, Not sure quite how this got published before the end of the week, but anyway, here it is. This version of this I-D has been through CCAMP WG last call and has been updated to my satisfaction. Can you please add it to the system for publication as an Informational I-D. Thanks, Adrian ----- Original Message ----- From: To: Cc: Sent: Monday, November 07, 2005 11:50 PM Subject: I-D ACTION:draft-ietf-ccamp-gmpls-ason-routing-eval-02.txt > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. > > Title : Evaluation of existing Routing Protocols > against ASON routing requirements > Author(s) : D. Papadimitriou, et al. > Filename : draft-ietf-ccamp-gmpls-ason-routing-eval-02.txt > Pages : 0 > Date : 2005-11-7 > > The Generalized MPLS (GMPLS) suite of protocols has been defined to > control different switching technologies as well as different > applications. These include support for requesting TDM connections > including SONET/SDH and Optical Transport Networks (OTNs). > > This document provides an evaluation of the IETF Routing Protocols > against the routing requirements for an Automatically Switched > Optical Network (ASON) as defined by ITU-T. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-ason-routing-eval-02.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > > Internet-Drafts are also available by anonymous FTP. Login with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-ccamp-gmpls-ason-routing-eval-02.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-ccamp-gmpls-ason-routing-eval-02.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > From owner-ccamp@ops.ietf.org Tue Nov 08 10:18:35 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZVF5-0006Ue-Kt for ccamp-archive@megatron.ietf.org; Tue, 08 Nov 2005 10:18:35 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10968 for ; Tue, 8 Nov 2005 10:18:08 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZVUr-0006Ur-4h for ccamp-archive@ietf.org; Tue, 08 Nov 2005 10:34:57 -0500 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EZV6y-00043G-SR for ccamp-data@psg.com; Tue, 08 Nov 2005 15:10:12 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [47.129.242.56] (helo=zcars04e.ca.nortel.com) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EZV6v-00041P-W7 for ccamp@ops.ietf.org; Tue, 08 Nov 2005 15:10:10 +0000 Received: from zrtphxm2.corp.nortel.com (zrtphxm2.corp.nortel.com [47.140.202.51]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id jA8F3Ef22914; Tue, 8 Nov 2005 10:03:15 -0500 (EST) 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: draft-shiomoto-ccamp-lsp-hierarchy-bis-00.txt Date: Tue, 8 Nov 2005 10:06:05 -0500 Message-ID: <34B3EAA5B3066A42914D28C5ECF5FEA40512DB40@zrtphxm2> Thread-Topic: draft-shiomoto-ccamp-lsp-hierarchy-bis-00.txt Thread-Index: AcXULGLn/jq48vKORQ+7wW/v9O6LLAPnk+ZA From: "Don Fedyk" To: Cc: "Adrian Farrel" , "Arthi Ayyangar" , "Richard Rabbat" , "Kohei Shiomoto" Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: quoted-printable Hi Thanks for the presentation yesterday. A thought occurred to me about the numbered versus unnumbered issue in your draft. (Note I will not refer to the multiple instances of the control plane since as discussed in the meeting I think this should be out of scope). =20 What I like about the unnumbered identifiers are they are hierarchical under the GMPLS node ID. I would suggest that even when an interface is numbered it could have an unnumbered identifiers as well and the numbered interface not be assumed to be advertised but assumed instead to be an identifier. It is in my opinion a special case when the numbered interface is out of the same address plan as the GMPLS control plane. Generally we should not assume this is true and separating the local identifier context from the GMPLS control addressing has advantages. (already illustrated by your draft).=20 If we treated all links this way they could have different identifiers for the purpose of identification and signaling in the link identifier space (e.g. IP, MAC, NSAP etc) and uniformly use unnumbered identifiers for all routing and TE advertisement. I realize this is not the way that unnumbered links came about but this might be the more "generalized" way to address this. Did you consider this option? Regards, Don=20 From info@mail.sedfjx.com Tue Nov 08 13:01:50 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZXn2-0000EM-7J for ccamp-archive@megatron.ietf.org; Tue, 08 Nov 2005 13:01:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22442 for ; Tue, 8 Nov 2005 13:01:21 -0500 (EST) Received: from [58.180.197.156] (helo=mail.sedfjx.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EZY2q-0003E4-IE for ccamp-archive@ietf.org; Tue, 08 Nov 2005 13:18:11 -0500 Received: (qmail 18533 invoked by uid 509); 9 Nov 2005 00:31:13 +0900 Date: 9 Nov 2005 00:31:13 +0900 Message-ID: <20051108153113.18532.qmail@mail.sedfjx.com> From: info@sedfjx.com To: ccamp-archive@ietf.org Subject: $B5.J}$N@:;R$rDs6!$7$F2<$5$$!#5U1g$G$9(B X-Spam-Score: 2.9 (++) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 $B!z!z!z!z!!5U1g=w@->R2p!!!z!z!z!z(B $B"#(.(,(/(.(,(/(.(,(/(.(,(/"#(B $B"#(-AG(-(-?M(-(-5U(-(-1g(-"#(B $B"#(1(,(0(1(,(0(1(,(0(1(,(0"#(B http://www.awg5.net/?inran $B"#(.(,(/(.(,(/(.(,(/(.(,(/"#(B $B"#(-OC(-(-Bj(-(-=8(-(-Cf(-"#(B $B"#(1(,(0(1(,(0(1(,(0(1(,(0"#(B http://www.awg5.net/?inran $B"(5.J}$N@:;R$rDs6!$9$k$@$1$G!!(B\$B!!$,%,%C%]%j!#!#!#!#(B $B"(!"A4=w@-2q0w$N(BG$B%9%]%C%H2hA|IU$-!*!*8+Hf$Y$F$+$i7h$a$F2<$5$$!#(B http://www.awg5.net/?inran 18$B6X(B YYYYYYYYYYYYYYYYYYYYYY $B"((BI don't veceive your mail awg_tokyo@yahoo.com.au $B"(%a!<%kITMW(B awg_tokyo@yahoo.com.au YYYYYYYYYYYYYYYYYYYYYY From owner-ccamp@ops.ietf.org Tue Nov 08 16:21:48 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZaua-0002wB-0q for ccamp-archive@megatron.ietf.org; Tue, 08 Nov 2005 16:21:48 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06549 for ; Tue, 8 Nov 2005 16:21:20 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZbAS-0001KB-0k for ccamp-archive@ietf.org; Tue, 08 Nov 2005 16:38:13 -0500 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EZanw-0008nD-OR for ccamp-data@psg.com; Tue, 08 Nov 2005 21:14:56 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [129.60.39.103] (helo=tama55.ecl.ntt.co.jp) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EZanv-0008mu-83; Tue, 08 Nov 2005 21:14:55 +0000 Received: from vcs3.rdh.ecl.ntt.co.jp (vcs3.rdh.ecl.ntt.co.jp [129.60.39.110]) by tama55.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id jA8LEfuH018879; Wed, 9 Nov 2005 06:14:41 +0900 (JST) Received: from vcs3.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by vcs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id jA8LEeau012500; Wed, 9 Nov 2005 06:14:40 +0900 (JST) Received: from mfs3.rdh.ecl.ntt.co.jp (mfs3.rdh.ecl.ntt.co.jp [129.60.39.112]) by vcs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id jA8LEeUm012497; Wed, 9 Nov 2005 06:14:40 +0900 (JST) Received: from mfs3.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by mfs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id jA8LEem8001843; Wed, 9 Nov 2005 06:14:40 +0900 (JST) Received: from nttmail3.ecl.ntt.co.jp ([129.60.39.100]) by mfs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id jA8LEd2f001840; Wed, 9 Nov 2005 06:14:39 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (eclscan3.m.ecl.ntt.co.jp [129.60.5.69]) by nttmail3.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id jA8LEdD7008304; Wed, 9 Nov 2005 06:14:39 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (localhost [127.0.0.1]) by eclscan3.m.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id jA8LEd1i020074; Wed, 9 Nov 2005 06:14:39 +0900 (JST) Received: from imc.m.ecl.ntt.co.jp (imc.m.ecl.ntt.co.jp [129.60.5.227]) by eclscan3.m.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id jA8LEcbP020071; Wed, 9 Nov 2005 06:14:38 +0900 (JST) Received: from [127.0.0.1] ([129.60.15.201]) by imc.m.ecl.ntt.co.jp (8.13.4/8.13.4) with ESMTP id jA8LETBm012244; Wed, 9 Nov 2005 06:14:37 +0900 (JST) Message-ID: <43711533.7080505@lab.ntt.co.jp> Date: Wed, 09 Nov 2005 06:14:27 +0900 From: Kohei Shiomoto User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.7.11) Gecko/20050728 X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be CC: ccamp@ops.ietf.org, Adrian Farrel , Arthi Ayyangar , Richard Rabbat Subject: Re: I-D ACTION:draft-shiomoto-ccamp-lsp-hierarchy-bis-00.txt References: <43556AAB.8000803@psg.com> <435590C5.5010002@lab.ntt.co.jp> <43563D39.4080200@psg.com> In-Reply-To: <43563D39.4080200@psg.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: ccfb4541e989aa743998098cd315d0fd Content-Transfer-Encoding: 7bit Hi Dimitri Sorry for not responding sooner. > hi kohei > > Kohei Shiomoto wrote: > >> Hi Dimitri, >> >> dimitri papadimitriou wrote: >> >>> all, >>> >>> i don't think the issues of advertising an LSP as a TE link in >>> another instance of the control plane than the one used for creating >>> the LSP - ditto >>> >>> "[HIERAR] did not consider scenarios where an LSP is created (and >>> maintained) by one instance of the GMPLS control plane, and is used >>> as a (TE) link by another instance of the GMPLS control plane." >>> >>> is only a matter of indicating to which instance this advertisement >>> should be done; >> >> >> I am happy if you could point out what is missing. > > > it is a matter of knowing whether the head-end (of the "LSP") is > 1. within the same area than the tail-end > 2. the advertisement generated by the tail-end is going to reach the > head-end and vice versa (as i think the draft makes no assumption about > the routing adjacencies that allows exchanging this information) - note: > this condition was kind of implicitly guaranteed in the [HIER] document > I assume that the both endpoints are in the same area. Routing adjacency could be brought up on it if needed. >>> now, in addition to the "routing" part, there is the whole discussion >>> about the maintenance of the (inherited) TE link - as we are speaking >>> here about separate instance - some specific mechanism may be needed >>> otherwise after their creation there may be no easy way to >>> communicate their unavailability >> >> >> The draft proposes the method to advertise the LSP created in the GMPLS >> domain to the different routing instance, MPLS domain for instance. > > > the difference is now that either you rely on the signaling capabilities > to tell you (Notify, PathErr) whether the LSP is down - but you have to > pass the information to the upper instance - or you are being made aware > from the upper instance advertisement but the convergence time may be > higher now there is a side issue here a loss of routing adjacency may be > such that you loss a TE link even if the TE link is not down Yes, routing convergence time may be higher. > >>> another more specific question on this document, what is the >>> definition of the value space for the "Target Control Plane Instance" ? >> >> >> Good question. We use a 32-bit space at this time. If you have any >> recommendation, I would be happy to hear that. You think that RD might >> be a good choice for instance, don't you. > > > what do you mean by RD ? i would say for instance the Area ID in OSPF Here I am assuming that several independent service networks are provided on top of a common GMPLS-based network. Target control plane instance is used to identify the service network. Route Distinguisher might be used for this purpose. In addition, it might be a good idea to add Area ID. > >>> a last point, section 4 mentions >>> >>> "This is not believed to be an issue as an informal survey indicated >>> that dynamically signalled numbered FAs had not been deployed. >>> Indeed it was the attempt to implement numbered FAs that gave rise to >>> the work on this document." ... is there a general feeling that >>> having this mechanism will make dynamically triggered numbered FA a >>> reality ? >> >> >> I hope so. > > > it may be a good sense to know whether provisioned numbered FAs where > used before advising a specific mechanism for triggered once - do we > have some feedback on this ? > > thanks, > - dimitri. > >> Thank you for your comments. >> --- >> Kohei >> >> PS >> I am now about to be on trip. I may not be able to respond timely. I >> apologize. >> >> >>> thanks, >>> - dimitri. >>> >>> Internet-Drafts@ietf.org wrote: >>> >>> >>>> A New Internet-Draft is available from the on-line Internet-Drafts >>>> directories. >>>> >>>> >>>> Title : Advertisement of hierarchical and stitchable LSPs >>>> as TE Links Author(s) : K. Shiomoto, et al. >>>> Filename : draft-shiomoto-ccamp-lsp-hierarchy-bis-00.txt >>>> Pages : 15 >>>> Date : 2005-10-18 >>>> This document addresses topics related to hierarchical and >>>> stitched Label Switched Paths (LSPs). It describes extensions to >>>> allow an egress to identify that an LSP will be used as a >>>> dynamically signaled Forwarding Adjacency LSP (FA-LSP) in the case >>>> of numbered FA's. In addition, the document addresses the issue of >>>> how to indicate that an LSP should be advertised as a TE link into a >>>> different instance of the control plane and how to identify the >>>> instance that should be used. A URL for this Internet-Draft is: >>>> http://www.ietf.org/internet-drafts/draft-shiomoto-ccamp-lsp-hierarchy-bis-00.txt >>>> >>>> >>>> To remove yourself from the I-D Announcement list, send a message to >>>> i-d-announce-request@ietf.org with the word unsubscribe in the body >>>> of the message. You can also visit >>>> https://www1.ietf.org/mailman/listinfo/I-D-announce to change your >>>> subscription settings. >>>> >>>> >>>> Internet-Drafts are also available by anonymous FTP. Login with the >>>> username >>>> "anonymous" and a password of your e-mail address. After logging in, >>>> type "cd internet-drafts" and then >>>> "get draft-shiomoto-ccamp-lsp-hierarchy-bis-00.txt". >>>> >>>> A list of Internet-Drafts directories can be found in >>>> http://www.ietf.org/shadow.html or >>>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>>> >>>> >>>> Internet-Drafts can also be obtained by e-mail. >>>> >>>> Send a message to: >>>> mailserv@ietf.org. >>>> In the body type: >>>> "FILE >>>> /internet-drafts/draft-shiomoto-ccamp-lsp-hierarchy-bis-00.txt". >>>> NOTE: The mail server at ietf.org can return the document in >>>> MIME-encoded form by using the "mpack" utility. To use this >>>> feature, insert the command "ENCODING mime" before the "FILE" >>>> command. To decode the response(s), you will need "munpack" or >>>> a MIME-compliant mail reader. Different MIME-compliant mail readers >>>> exhibit different behavior, especially when dealing with >>>> "multipart" MIME messages (i.e. documents which have been split >>>> up into multiple messages), so check your local documentation on >>>> how to manipulate these messages. >>>> Below is the data which will enable a MIME compliant >>>> mail reader >>>> implementation to automatically retrieve the ASCII version of the >>>> Internet-Draft. >>>> >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> >>>> _______________________________________________ >>>> I-D-Announce mailing list >>>> I-D-Announce@ietf.org >> >> >> From owner-ccamp@ops.ietf.org Tue Nov 08 16:42:33 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZbEe-0000Hw-UQ for ccamp-archive@megatron.ietf.org; Tue, 08 Nov 2005 16:42:33 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07770 for ; Tue, 8 Nov 2005 16:42:05 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZbUW-0001rK-7Y for ccamp-archive@ietf.org; Tue, 08 Nov 2005 16:58:58 -0500 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EZbAl-000A9o-BY for ccamp-data@psg.com; Tue, 08 Nov 2005 21:38:31 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [129.60.39.103] (helo=tama55.ecl.ntt.co.jp) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EZbAk-000A9c-H1 for ccamp@ops.ietf.org; Tue, 08 Nov 2005 21:38:30 +0000 Received: from vcs3.rdh.ecl.ntt.co.jp (vcs3.rdh.ecl.ntt.co.jp [129.60.39.110]) by tama55.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id jA8LcI3s022700; Wed, 9 Nov 2005 06:38:18 +0900 (JST) Received: from vcs3.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by vcs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id jA8LcIUr022899; Wed, 9 Nov 2005 06:38:18 +0900 (JST) Received: from mfs3.rdh.ecl.ntt.co.jp (mfs3.rdh.ecl.ntt.co.jp [129.60.39.112]) by vcs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id jA8LcHcI022896; Wed, 9 Nov 2005 06:38:17 +0900 (JST) Received: from mfs3.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by mfs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id jA8LcHEV012604; Wed, 9 Nov 2005 06:38:17 +0900 (JST) Received: from nttmail3.ecl.ntt.co.jp ([129.60.39.100]) by mfs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id jA8LcHel012601; Wed, 9 Nov 2005 06:38:17 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (eclscan3.m.ecl.ntt.co.jp [129.60.5.69]) by nttmail3.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id jA8LcGYe010476; Wed, 9 Nov 2005 06:38:16 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (localhost [127.0.0.1]) by eclscan3.m.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id jA8LcGqd024220; Wed, 9 Nov 2005 06:38:16 +0900 (JST) Received: from imc.m.ecl.ntt.co.jp (imc.m.ecl.ntt.co.jp [129.60.5.227]) by eclscan3.m.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id jA8LcFok024217; Wed, 9 Nov 2005 06:38:15 +0900 (JST) Received: from [127.0.0.1] ([129.60.15.201]) by imc.m.ecl.ntt.co.jp (8.13.4/8.13.4) with ESMTP id jA8Lc5i5013857; Wed, 9 Nov 2005 06:38:14 +0900 (JST) Message-ID: <43711ABB.30708@lab.ntt.co.jp> Date: Wed, 09 Nov 2005 06:38:03 +0900 From: Kohei Shiomoto User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.7.11) Gecko/20050728 X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Don Fedyk CC: ccamp@ops.ietf.org, Adrian Farrel , Arthi Ayyangar , Richard Rabbat Subject: Re: draft-shiomoto-ccamp-lsp-hierarchy-bis-00.txt References: <34B3EAA5B3066A42914D28C5ECF5FEA40512DB40@zrtphxm2> In-Reply-To: <34B3EAA5B3066A42914D28C5ECF5FEA40512DB40@zrtphxm2> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Content-Transfer-Encoding: 7bit Hi Don Thank you for your comments. > Hi > > Thanks for the presentation yesterday. A thought occurred to me about > the numbered versus unnumbered issue in your draft. (Note I will not > refer to the multiple instances of the control plane since as discussed > in the meeting I think this should be out of scope). As I noted in the response to Dimitri comments, the target control plane instance is useful when we have multiple layer network where there is a client-server relationship between them. > > What I like about the unnumbered identifiers are they are hierarchical > under the GMPLS node ID. I would suggest that even when an interface is We might want to use unnumbered when we need to save the address space as you said. > numbered it could have an unnumbered identifiers as well and the > numbered interface not be assumed to be advertised but assumed instead > to be an identifier. It is in my opinion a special case when the I am not clear what makes us to assign both numbered and unnumbered address on the same interface. Maybe I miss something. > numbered interface is out of the same address plan as the GMPLS control > plane. Generally we should not assume this is true and separating the > local identifier context from the GMPLS control addressing has > advantages. (already illustrated by your draft). Yes. The local interface identifier should come from different address space of the GMPLS control plane address. > > If we treated all links this way they could have different identifiers > for the purpose of identification and signaling in the link identifier > space (e.g. IP, MAC, NSAP etc) and uniformly use unnumbered identifiers > for all routing and TE advertisement. I realize this is not the way > that unnumbered links came about but this might be the more > "generalized" way to address this. > > Did you consider this option? You are saying that numbered interface is used for GMPLS and different identifier is used for upper layer instance, aren't you (unnumbered address is used in GMPLS domain)? It might be a option when we want to advertise the TE-link in GMPLS control plane as well as in the upper layer instance. Please correct me if I misunderstand your point. Thanks, Kohei > > Regards, > Don From info@mail.sedfjx.com Tue Nov 08 16:48:21 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZbKH-0001u8-04 for ccamp-archive@megatron.ietf.org; Tue, 08 Nov 2005 16:48:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08057 for ; Tue, 8 Nov 2005 16:47:52 -0500 (EST) Received: from [58.180.197.153] (helo=mail.sedfjx.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EZba8-0001zT-1P for ccamp-archive@ietf.org; Tue, 08 Nov 2005 17:04:45 -0500 Received: (qmail 17843 invoked by uid 509); 9 Nov 2005 03:43:42 +0900 Date: 9 Nov 2005 03:43:42 +0900 Message-ID: <20051108184342.17842.qmail@mail.sedfjx.com> From: info@sedfjx.com To: ccamp-archive@ietf.org Subject: $BNx?MBe9TEPO?40A4L5NA(B X-Spam-Score: 3.6 (+++) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d $B!ZK\Ev$NNx?M5$J,$r$44.G=$7$F$M!"=w@-;o!&=54);o$J$I$G8=:_$b@kEACf![(B $B!yB?$/$N=w@-2q0w$K4n$P$l$F$^$9!#%(%C%A$bL^O@#O#K!*!*(B $B=50l$NNx?M7@Ls(B $B!ZJs=7(B1$B2s(B2$BK|1_0J>e2DG=![(B $B$3$A$i$X"-(B http://www.awg5.net/?trip1 $B=5;0$NNx?M7@Ls(B $B!ZJs=7(B1$B2s(B5$BK|1_0J>e2DG=![(B $B$3$A$i$X"-(B http://www.molt-legart.com/?trip2 $BH>G/$NNx?M7@Ls(B $B!ZJs=7!&7n(B25$BK|1_0J>e2DG=![(B $B$3$A$i$X"-(B http://www.awg5.net/?trip3 $B"(=w@-2q0w$O;YJ'$$G=NO$"$kJ}$N$_:_@R$7$F$^$9!#(B $B"(L^O@!"Js=7$O@hJ'$$8}:BHV9f$r=w@-$K$*CN$i$;$7$F2<$5$$!#(B $B"(=w@-$N?H853N; Tue, 8 Nov 2005 20:41:07 -0500 (EST) Received: from [58.180.197.155] (helo=mail.sedfjx.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EZfDs-0003Mn-7a for ccamp-archive@ietf.org; Tue, 08 Nov 2005 20:58:01 -0500 Received: (qmail 23513 invoked by uid 509); 9 Nov 2005 07:23:59 +0900 Date: 9 Nov 2005 07:23:59 +0900 Message-ID: <20051108222359.23512.qmail@mail.sedfjx.com> From: info@sedfjx.com To: ccamp-archive@ietf.org Subject: $BNx?MBe9TEPO?40A4L5NA(B X-Spam-Score: 3.6 (+++) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d $B!ZK\Ev$NNx?M5$J,$r$44.G=$7$F$M!"=w@-;o!&=54);o$J$I$G8=:_$b@kEACf![(B $B!yB?$/$N=w@-2q0w$K4n$P$l$F$^$9!#%(%C%A$bL^O@#O#K!*!*(B $B=50l$NNx?M7@Ls(B $B!ZJs=7(B1$B2s(B2$BK|1_0J>e2DG=![(B $B$3$A$i$X"-(B http://www.awg5.net/?trip1 $B=5;0$NNx?M7@Ls(B $B!ZJs=7(B1$B2s(B5$BK|1_0J>e2DG=![(B $B$3$A$i$X"-(B http://www.molt-legart.com/?trip2 $BH>G/$NNx?M7@Ls(B $B!ZJs=7!&7n(B25$BK|1_0J>e2DG=![(B $B$3$A$i$X"-(B http://www.awg5.net/?trip3 $B"(=w@-2q0w$O;YJ'$$G=NO$"$kJ}$N$_:_@R$7$F$^$9!#(B $B"(L^O@!"Js=7$O@hJ'$$8}:BHV9f$r=w@-$K$*CN$i$;$7$F2<$5$$!#(B $B"(=w@-$N?H853N; Tue, 8 Nov 2005 21:04:42 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZfai-0003xQ-3M for ccamp-archive@ietf.org; Tue, 08 Nov 2005 21:21:37 -0500 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EZfEe-00003w-C8 for ccamp-data@psg.com; Wed, 09 Nov 2005 01:58:48 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=0.2 required=5.0 tests=BAYES_00,MISSING_SUBJECT, NO_REAL_NAME autolearn=no version=3.1.0 Received: from [217.6.95.235] (helo=tcmail21.telekom.de) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EZfEd-00003i-Dx for ccamp@ops.ietf.org; Wed, 09 Nov 2005 01:58:47 +0000 Received: from g8pbu.blf01.telekom.de (g8pbu.blf01.telekom.de [164.25.63.149]) by tcmail21.dmz.telekom.de with ESMTP; Wed, 9 Nov 2005 02:58:46 +0100 Received: by G8PBU.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Wed, 9 Nov 2005 02:58:45 +0100 Message-Id: From: Michael.Dueser@t-systems.com To: gels@rtg.ietf.org, ccamp@ops.ietf.org Date: Wed, 9 Nov 2005 02:58:45 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.3 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Hi, I believe that the wrong question was asked at the end of the GELS BoF, which didn't allow me to explicitly express support for forming a GELS working group. I would, therefore, urgently ask everybody with an interest in the GELS work to explicitly express his/her support on the mailing list so we can keep momentum and continue work on this important topic. Many thanks, Michael From owner-ccamp@ops.ietf.org Tue Nov 08 21:05:12 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZfKq-0005DW-Rq for ccamp-archive@megatron.ietf.org; Tue, 08 Nov 2005 21:05:12 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03437 for ; Tue, 8 Nov 2005 21:04:45 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZfam-0003xd-8h for ccamp-archive@ietf.org; Tue, 08 Nov 2005 21:21:40 -0500 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EZfGP-0000Dg-Vq for ccamp-data@psg.com; Wed, 09 Nov 2005 02:00:37 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-0.7 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=3.1.0 Received: from [217.6.95.235] (helo=tcmail21.telekom.de) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EZfGP-0000D9-1H for ccamp@ops.ietf.org; Wed, 09 Nov 2005 02:00:37 +0000 Received: from g8pbu.blf01.telekom.de (g8pbu.blf01.telekom.de [164.25.63.149]) by tcmail21.dmz.telekom.de with ESMTP; Wed, 9 Nov 2005 03:00:36 +0100 Received: by G8PBU.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Wed, 9 Nov 2005 03:00:35 +0100 Message-Id: From: Michael.Dueser@t-systems.com To: gels@rtg.ietf.org, ccamp@ops.ietf.org Subject: Supporting the GELS work Date: Wed, 9 Nov 2005 03:00:34 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.3 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Hi, I believe that the wrong question was asked at the end of the GELS BoF, which didn't allow me to explicitly express support for forming a GELS working group. I would, therefore, urgently ask everybody with an interest in the GELS work to explicitly express his/her support on the mailing list so we can keep momentum and continue work on this important topic. Many thanks, Michael From owner-ccamp@ops.ietf.org Tue Nov 08 21:23:59 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZfd1-0001fr-Eq for ccamp-archive@megatron.ietf.org; Tue, 08 Nov 2005 21:23:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA04667 for ; Tue, 8 Nov 2005 21:23:32 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZfsw-0004RT-Ix for ccamp-archive@ietf.org; Tue, 08 Nov 2005 21:40:27 -0500 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EZfYH-0001Ru-JW for ccamp-data@psg.com; Wed, 09 Nov 2005 02:19:05 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [171.71.176.72] (helo=sj-iport-3.cisco.com) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EZfYG-0001Ri-UN for ccamp@ops.ietf.org; Wed, 09 Nov 2005 02:19:04 +0000 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-3.cisco.com with ESMTP; 08 Nov 2005 18:19:04 -0800 X-IronPort-AV: i="3.97,306,1125903600"; d="scan'208"; a="362593899:sNHT109556164" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id jA92ISZW013253; Tue, 8 Nov 2005 18:19:01 -0800 (PST) Received: from xmb-rtp-203.amer.cisco.com ([64.102.31.20]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 8 Nov 2005 21:18:54 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: draft-shiomoto-ccamp-lsp-hierarchy-bis-00.txt Date: Tue, 8 Nov 2005 21:18:53 -0500 Message-ID: Thread-Topic: draft-shiomoto-ccamp-lsp-hierarchy-bis-00.txt Thread-Index: AcXULGLn/jq48vKORQ+7wW/v9O6LLAPnk+ZAAEHTiDA= From: "Zafar Ali \(zali\)" To: "Don Fedyk" , Cc: "Adrian Farrel" , "Arthi Ayyangar" , "Richard Rabbat" , "Kohei Shiomoto" X-OriginalArrivalTime: 09 Nov 2005 02:18:54.0791 (UTC) FILETIME=[EEF0AD70:01C5E4D3] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: owner-ccamp@ops.ietf.org=20 > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Don Fedyk > Sent: Tuesday, November 08, 2005 10:06 AM > To: ccamp@ops.ietf.org > Cc: Adrian Farrel; Arthi Ayyangar; Richard Rabbat; Kohei Shiomoto > Subject: draft-shiomoto-ccamp-lsp-hierarchy-bis-00.txt >=20 > Hi >=20 > Thanks for the presentation yesterday. A thought occurred to=20 > me about the numbered versus unnumbered issue in your draft.=20 > (Note I will not refer to the multiple instances of the=20 > control plane since as discussed > in the meeting I think this should be out of scope). =20 >=20 Don,=20 Do you agree that we need to support di-directional FA-LSP?=20 If we agree that "dynamic FA-LSP" is a good thing, I see no other way around but to have the hooks that are needed to flood the TE link at the Egress properly. E.g., use of RRO will be useful to infer the SRLG and AW for the TE link for flooding.=20 I am not happy that we agree with dynamic FA-LSP, but do not agree with the hooks that are needed to make bi-directional FA-LSP floodable w/o having to apply configurations at the Egress LSR.=20 > What I like about the unnumbered identifiers are they are=20 > hierarchical under the GMPLS node ID. I would suggest that=20 > even when an interface is numbered it could have an=20 > unnumbered identifiers as well Why? Also this is not a valid assumption.=20 > and the numbered interface not=20 > be assumed to be advertised but assumed instead to be an=20 > identifier. It is in my opinion a special case when the=20 > numbered interface is out of the same address plan as the=20 > GMPLS control plane. Generally we should not assume this is=20 > true and separating the local identifier context from the=20 > GMPLS control addressing has advantages. (already=20 > illustrated by your draft).=20 >=20 > If we treated all links this way they could have different=20 > identifiers for the purpose of identification and signaling=20 > in the link identifier space (e.g. IP, MAC, NSAP etc) and=20 > uniformly use unnumbered identifiers for all routing and TE=20 > advertisement. I realize this is not the way that unnumbered=20 > links came about but this might be the more "generalized" way=20 > to address this. >=20 > Did you consider this option? I am not sure if I get what you are proposing a 100%, but it does NOT look like a valid assumption or trivial change. May be we can chat after RTG meeting.=20 Thanks Regards... Zafar=20 >=20 > Regards, > Don=20 >=20 From owner-ccamp@ops.ietf.org Tue Nov 08 21:27:01 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZffx-0004Op-JL for ccamp-archive@megatron.ietf.org; Tue, 08 Nov 2005 21:27:01 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05114 for ; Tue, 8 Nov 2005 21:26:34 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZfvs-0004ZG-1e for ccamp-archive@ietf.org; Tue, 08 Nov 2005 21:43:29 -0500 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EZfcA-0001kI-7M for ccamp-data@psg.com; Wed, 09 Nov 2005 02:23:06 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [171.71.176.71] (helo=sj-iport-2.cisco.com) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EZfc7-0001k4-MU for ccamp@ops.ietf.org; Wed, 09 Nov 2005 02:23:03 +0000 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-2.cisco.com with ESMTP; 08 Nov 2005 18:23:03 -0800 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id jA92Mjbt022062; Tue, 8 Nov 2005 18:23:01 -0800 (PST) Received: from xmb-rtp-203.amer.cisco.com ([64.102.31.20]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 8 Nov 2005 21:22:49 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: Date: Tue, 8 Nov 2005 21:22:48 -0500 Message-ID: Thread-Index: AcXk0VsyoLsY0MGASFi2LLFTWV1lJAAAsPQA From: "Zafar Ali \(zali\)" To: , , X-OriginalArrivalTime: 09 Nov 2005 02:22:49.0366 (UTC) FILETIME=[7AC1FB60:01C5E4D4] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: quoted-printable Hi,=20 I think there were ONLY 4 or 5 of you. Are we not done, or we let it linger?=20 Thanks Regards... Zafar =20 > -----Original Message----- > From: owner-ccamp@ops.ietf.org=20 > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of=20 > Michael.Dueser@t-systems.com > Sent: Tuesday, November 08, 2005 8:59 PM > To: gels@rtg.ietf.org; ccamp@ops.ietf.org > Subject:=20 >=20 > Hi, >=20 > I believe that the wrong question was asked at the end of the=20 > GELS BoF, which didn't allow me to explicitly express support=20 > for forming a GELS working group. I would, therefore,=20 > urgently ask everybody with an interest in the GELS work to=20 > explicitly express his/her support on the mailing list so we=20 > can keep momentum and continue work on this important topic. =20 >=20 > Many thanks, >=20 > Michael >=20 From owner-ccamp@ops.ietf.org Wed Nov 09 02:35:23 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZkUN-0007F3-2C for ccamp-archive@megatron.ietf.org; Wed, 09 Nov 2005 02:35:23 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA19588 for ; Wed, 9 Nov 2005 02:34:55 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZkkK-0003En-WB for ccamp-archive@ietf.org; Wed, 09 Nov 2005 02:51:53 -0500 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EZkMT-000PQN-VG for ccamp-data@psg.com; Wed, 09 Nov 2005 07:27:13 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [128.87.251.112] (helo=smtpoutuk01.marconi.com) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EZkMS-000PPy-9g for ccamp@ops.ietf.org; Wed, 09 Nov 2005 07:27:12 +0000 Received: from cvdgwy01.uk.marconicomms.com (cvis26.uk.marconicomms.com [128.87.251.109]) by smtpoutuk01.marconi.com (8.12.11/8.12.11) with ESMTP id jA97R3kW007145; Wed, 9 Nov 2005 07:27:05 GMT (envelope-from Diego.Caviglia@marconi.com) Subject: Re: Supporting the GELS work To: "Michael.Dueser" Cc: "gels" , "ccamp" X-Mailer: Lotus Notes Release 5.0.12 February 13, 2003 Message-ID: From: "Diego Caviglia" Date: Wed, 9 Nov 2005 08:27:25 +0100 X-MIMETrack: Serialize by Router on CVDGWY01/S/EXT/MC1(5012HF354 | August 26, 2003) at 09/11/2005 07:27:04 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Michael, I support this kind of WG. Regards Diego Michael.Dueser@t-systems.com@ops.ietf.org on 09/11/2005 03.00.34 Sent by: owner-ccamp@ops.ietf.org To: gels@rtg.ietf.org, ccamp@ops.ietf.org cc: Subject: Supporting the GELS work Hi, I believe that the wrong question was asked at the end of the GELS BoF, which didn't allow me to explicitly express support for forming a GELS working group. I would, therefore, urgently ask everybody with an interest in the GELS work to explicitly express his/her support on the mailing list so we can keep momentum and continue work on this important topic. Many thanks, Michael From owner-ccamp@ops.ietf.org Wed Nov 09 03:34:10 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZlPG-0006DZ-Bb for ccamp-archive@megatron.ietf.org; Wed, 09 Nov 2005 03:34:10 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22590 for ; Wed, 9 Nov 2005 03:33:42 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZlf3-0004iW-Lf for ccamp-archive@ietf.org; Wed, 09 Nov 2005 03:50:41 -0500 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EZlKj-00044A-Vh for ccamp-data@psg.com; Wed, 09 Nov 2005 08:29:29 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO autolearn=ham version=3.1.0 Received: from [62.241.162.31] (helo=galaxy.systems.pipex.net) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EZlKj-00043x-4C for ccamp@ops.ietf.org; Wed, 09 Nov 2005 08:29:29 +0000 Received: from dnni.com (81-178-2-190.dsl.pipex.com [81.178.2.190]) by galaxy.systems.pipex.net (Postfix) with ESMTP id D2088E00018B; Wed, 9 Nov 2005 08:29:23 +0000 (GMT) Received: from Puppy ([209.52.109.207] RDNS failed) by dnni.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 9 Nov 2005 08:29:22 +0000 Message-ID: <024e01c5e508$2118ce20$cf6d34d1@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Zafar Ali (zali)" , , , References: Subject: Re: Question about the existence of GELS Date: Wed, 9 Nov 2005 08:32:04 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-OriginalArrivalTime: 09 Nov 2005 08:29:23.0164 (UTC) FILETIME=[B01539C0:01C5E507] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: 7bit Hi Zafar, > I think there were ONLY 4 or 5 of you. 4 or 5 of whom? 4 or 5 people who did not parse the question? Where I was standing multiple people were confused by the question. I certainly was, and I am a native English speaker. OTOH, I assume we were taking a sense of the room not having a vote, and I think that the major consensus was not to support either of the two questions asked at the time they were asked > Are we not done, or we let it linger? From my personal perspective, I believe this needs more investingation. Thanks, Adrian > -----Original Message----- > From: owner-ccamp@ops.ietf.org > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of > Michael.Dueser@t-systems.com > Sent: Tuesday, November 08, 2005 8:59 PM > To: gels@rtg.ietf.org; ccamp@ops.ietf.org > Subject: > > Hi, > > I believe that the wrong question was asked at the end of the > GELS BoF, which didn't allow me to explicitly express support > for forming a GELS working group. I would, therefore, > urgently ask everybody with an interest in the GELS work to > explicitly express his/her support on the mailing list so we > can keep momentum and continue work on this important topic. > > Many thanks, > > Michael > From owner-ccamp@ops.ietf.org Wed Nov 09 04:39:52 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZmQq-00087x-GY for ccamp-archive@megatron.ietf.org; Wed, 09 Nov 2005 04:39:52 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA25512 for ; Wed, 9 Nov 2005 04:39:24 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZmgl-0006R2-HD for ccamp-archive@ietf.org; Wed, 09 Nov 2005 04:56:24 -0500 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EZmLc-0009J9-7c for ccamp-data@psg.com; Wed, 09 Nov 2005 09:34:28 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [131.116.28.216] (helo=sehan022as.telia.se) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EZmLa-0009Ik-V9 for ccamp@ops.ietf.org; Wed, 09 Nov 2005 09:34:27 +0000 Received: from YBDH014427.teliasonera.com ([131.116.232.194]) by sehan022as.telia.se with InterScan Messaging Security Suite; Wed, 09 Nov 2005 10:32:40 +0100 Message-Id: <6.0.1.1.0.20051109102054.05c2adf8@tmspop.telia.se> X-Sender: ther45@tmspop.telia.se X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Wed, 09 Nov 2005 10:32:39 +0100 To: Michael.Dueser@t-systems.com, gels@rtg.ietf.org, ccamp@ops.ietf.org From: Thomas Eriksson Subject: Re: Supporting the GELS work In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Hi, >I believe that the wrong question was asked at the end of the GELS BoF, >which didn't allow me to explicitly express support for forming a GELS >working group. I am not in Vancover so I could not attend the meeting so I do not know what the questions was. > I would, therefore, urgently ask everybody with an interest in the GELS > work to explicitly express his/her support on the mailing list so we can > keep momentum and continue work on this important topic. I support the GELS work continuing in a separate working group. I agree that the momentum must not be lost. Thomas From paola.franceschi@beerponginc.com Wed Nov 09 10:02:10 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZrSi-0005gu-VS for ccamp-archive@megatron.ietf.org; Wed, 09 Nov 2005 10:02:10 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14345 for ; Wed, 9 Nov 2005 10:01:40 -0500 (EST) Received: from [222.173.146.83] (helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EZrii-0006sR-OE for ccamp-archive@ietf.org; Wed, 09 Nov 2005 10:18:42 -0500 Message-ID: <000001c5e53d$fe2c2980$0100007f@localhost> From: "Morgan Foster" To: Subject: Corel Draw Date: Wed, 09 Nov 2005 15:01:41 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C5E53D.FE2C2980" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 2.4 (++) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C5E53D.FE2C2980 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable.TOP.10.NEW.TITLES.ON.SALE.NOW!.1.Office.Pro.2003.2.Adobe.Photoshop.9.0.3.Windows.XP.Pro.4.Adobe.Acrobat.7.Pro.5.Flash.MX.2004.6.Corel.Draw.12.7.Norton.Antivirus.2005.8.Windows.2003.Se ListPrice: $550.00 OurPrice: $69.95 YouSave: $480.05 ( 87%) Availability: Available for INSTANT download! Sales Rank: #1 Average Customer Review: (based on 50 reviews) -------------------------------------------------------------------------------- Microsoft Windows XP Professional by Microsoft ListPrice: $200.00 OurPrice: $49.95 YouSave: $150.05 ( 75%) Availability: Available for INSTANT download! Sales Rank: #2 Average Customer Review: (based on 45 reviews) -------------------------------------------------------------------------------- Adobe Photoshop CS2 V 9.0 by Adobe ListPrice: $599.00 OurPrice: $69.95 YouSave: $529.05 ( 88%) Availability: Available for INSTANT download! Sales Rank: #3 Average Customer Review: (based on 35 reviews) -------------------------------------------------------------------------------- ------=_NextPart_000_0001_01C5E53D.FE2C2980 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Software

TOP 10 NEW TITLES
Microsoft

 ON SALE NOW!

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

Microsoft Office Professional Edition 2003
   by Microsoft

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



Availability: Available for INSTANT download!


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

Microsoft Windows XP Professional
   by Microsoft

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



Availability: Available for INSTANT download!


Sales Rank: #2
Average Customer Review: 3D"5
(based on 37 review! s)

Adobe Photoshop CS2 V 9.0
   by Adobe

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



Availability: Available for INSTANT download!


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

------=_NextPart_000_0001_01C5E53D.FE2C2980-- From owner-ccamp@ops.ietf.org Wed Nov 09 12:19:37 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZtbl-00049P-D6 for ccamp-archive@megatron.ietf.org; Wed, 09 Nov 2005 12:19:37 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23271 for ; Wed, 9 Nov 2005 12:19:08 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZtrn-0002fi-NL for ccamp-archive@ietf.org; Wed, 09 Nov 2005 12:36:12 -0500 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EZtXO-000LcA-Ff for ccamp-data@psg.com; Wed, 09 Nov 2005 17:15:06 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [12.129.211.51] (helo=huawei.com) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EZtXN-000Lbd-Mo for ccamp@ops.ietf.org; Wed, 09 Nov 2005 17:15:05 +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 <0IPP00I576FLXT@usaga01-in.huawei.com> for ccamp@ops.ietf.org; Wed, 09 Nov 2005 09:11:45 -0800 (PST) Received: from huawei.com ([172.17.1.218]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IPP00K0M6FJRE@usaga01-in.huawei.com> for ccamp@ops.ietf.org; Wed, 09 Nov 2005 09:11:45 -0800 (PST) Received: from [172.24.1.3] (Forwarded-For: [209.52.105.229]) by szxmc02-in.huawei.com (mshttpd); Wed, 09 Nov 2005 09:15:01 -0800 Date: Wed, 09 Nov 2005 09:15:01 -0800 From: lidan 37133 Subject: =?gb2312?B?u9i4tA==?=:Supporting the GELS work To: Michael.Dueser@t-systems.com Cc: gels@rtg.ietf.org, ccamp@ops.ietf.org Message-id: MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.25 (built Mar 3 2004) Content-type: text/plain; charset=gb2312 Content-language: zh-CN Content-transfer-encoding: quoted-printable Content-disposition: inline X-Accept-Language: zh-CN Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: quoted-printable I support this GELS work=2E Dan Li ----- =D4=AD=D3=CA=BC=FE ----- =B4=D3=3A Michael=2EDueser=40t-systems=2Ecom =C8=D5=C6=DA=3A =D0=C7=C6=DA=B6=FE=2C =CA=AE=D2=BB=D4=C2 8=C8=D5=2C 2005 = =CF=C2=CE=E76=3A00 =D6=F7=CC=E2=3A Supporting the GELS work =3E Hi=2C =3E = =3E I believe that the wrong question was asked at the end of the GELS = =3E BoF=2C which didn=27t allow me to explicitly express support for = =3E forming a GELS working group=2E I would=2C therefore=2C urgently ask = =3E everybody with an interest in the GELS work to explicitly express = =3E his/her support on the mailing list so we can keep momentum and = =3E continue work on this important topic=2E = =3E = =3E Many thanks=2C =3E = =3E Michael =3E = =3E = =3E From info@mail.sedfjx.com Wed Nov 09 14:45:23 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZvso-0006BF-GN for ccamp-archive@megatron.ietf.org; Wed, 09 Nov 2005 14:45:23 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03715 for ; Wed, 9 Nov 2005 14:44:54 -0500 (EST) Received: from [58.180.197.153] (helo=mail.sedfjx.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EZw8s-0007VP-34 for ccamp-archive@ietf.org; Wed, 09 Nov 2005 15:01:58 -0500 Received: (qmail 18588 invoked by uid 509); 10 Nov 2005 02:02:04 +0900 Date: 10 Nov 2005 02:02:04 +0900 Message-ID: <20051109170204.18587.qmail@mail.sedfjx.com> From: info@sedfjx.com To: ccamp-archive@ietf.org Subject: $B!j9;@8!I%J%^!I1g9b7G<(HD!J:G?7HG!K(B? X-Spam-Score: 3.6 (+++) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 $B""""!!"!"!"!=w;R9;@81g9b7G<(HD"!"!"!(B $B""!!!!!!!!(Bhttp://www.awg5.net/?teen $B!#(BoO$B!{(BOo$B!#(BoO$B!{(BOo$B!#!#(BoO$B!{(BOo$B!#(BoO$B!{(BOo$B!#!#(BoO$B!{(BOo$B!#(B $B!!"!"!"!Bg9%I>$K$D$-7G<(HD3HBgCf!*!*"!"!"!(B (8/10$BF|8=:_1g9b4uK>=w;R9;@8(B1271$B9`L\7G:\Cf!*!*(B) $B!z1g=uL5$7$N$*IU$-9g$$!&%;%U%l$r5a$a$F$$$k=w;R9;@8$bB??t$$$^$9!*(B $B!!7G<(HD$rB(1\Mw!*"*(B http://www.awg5.net/?teen $B""""""(B http://www.awg5.net/?teen$B!!(B $B""""CK@-"*=w;R9;@8$H$N1g9b!"%;%U%l4uK>!"7G<(HD=q$-9~$_4uK>Z$NDs<($r5a$a$k>l9g$,$"$j$^$9!y(B $B!\!\!\!\!\!\!\!\!\!\!\!\!\!\!\!\!\!\!\!\!\!\!\!\(B $B""G[?.Dd;_(B awg_tokyo@yahoo.com.au I don't veceive your mail awg_tokyo@yahoo.com.au $B!\!\!\!\!\!\!\!\!\!\!\!\!\!\!\!\!\!\!\!\!\!\!\!\(B From owner-ccamp@ops.ietf.org Wed Nov 09 17:39:09 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZyaz-0005dQ-1S for ccamp-archive@megatron.ietf.org; Wed, 09 Nov 2005 17:39:09 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15108 for ; Wed, 9 Nov 2005 17:38:40 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZyr4-0004cw-55 for ccamp-archive@ietf.org; Wed, 09 Nov 2005 17:55:47 -0500 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EZyQv-000Hzc-2X for ccamp-data@psg.com; Wed, 09 Nov 2005 22:28:45 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO autolearn=ham version=3.1.0 Received: from [62.241.162.32] (helo=ranger.systems.pipex.net) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EZyQt-000HzM-TX for ccamp@ops.ietf.org; Wed, 09 Nov 2005 22:28:44 +0000 Received: from dnni.com (81-178-2-190.dsl.pipex.com [81.178.2.190]) by ranger.systems.pipex.net (Postfix) with ESMTP id 1A455E0005E5 for ; Wed, 9 Nov 2005 22:28:41 +0000 (GMT) Received: from Puppy ([209.52.109.207] RDNS failed) by dnni.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 9 Nov 2005 22:28:40 +0000 Message-ID: <03d101c5e57d$60680670$cf6d34d1@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Presenters: please check your slides Date: Wed, 9 Nov 2005 22:31:37 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-OriginalArrivalTime: 09 Nov 2005 22:28:40.0897 (UTC) FILETIME=[EFA17B10:01C5E57C] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: 7bit Hi, I have wrestled the new meetings tool to the ground, and I think I have all the right slides updated in the right places. Please check the slides and let me know that they are the ones you hoped I would publish. Thanks, Adrian From info@mail.sedfjx.com Wed Nov 09 18:31:32 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZzPg-00078h-Sp for ccamp-archive@megatron.ietf.org; Wed, 09 Nov 2005 18:31:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17537 for ; Wed, 9 Nov 2005 18:31:03 -0500 (EST) Received: from [58.180.197.158] (helo=mail.sedfjx.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EZzfl-0005r1-QM for ccamp-archive@ietf.org; Wed, 09 Nov 2005 18:48:11 -0500 Received: (qmail 14308 invoked by uid 509); 10 Nov 2005 05:09:56 +0900 Date: 10 Nov 2005 05:09:56 +0900 Message-ID: <20051109200956.14307.qmail@mail.sedfjx.com> From: info@sedfjx.com To: ccamp-archive@ietf.org Subject: $B=w@-$H2q$C$F$/$l$^$;$s$+!)(B X-Spam-Score: 3.6 (+++) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de http://www.awg5.net/?sanman $B:#2s!"N$H~$5$s$H$$$&=w@-$r>R2p$7$F$$$^$9!"EDCf$H?=$7$^$9!#N$H~$5$s$H$$$&=w@-$O;E;v$,B?K;$JJ}$GCK@-$H$N=P2q$$$,L5$/!";d$,Be9T$7$F!"CK@-$H$N=P2q$$$rJQ$o$j$KC5$7$F$^$9!#$$$-$J$j$N%a!<%k$G?=$7Lu$J$$$G$9!#$b$7N$H~$5$s$K$*2q$$$7$F$$$?$@$1$k$J$i!"N$H~$5$s$+$i$NJs=7$N0lIt$r5.J}$K$*;YJ'$$$7$^$9!#$b$7;d$N;v$,?.$8$l$J$$$N$G$"$l$P!"N$H~$5$s$K2q$&A0$K5.J}$X$N?69~$_$b2DG=$G$9!#$3$A$i$GH`=w$N; Wed, 9 Nov 2005 18:44:28 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZzsi-0006Hm-DZ for ccamp-archive@ietf.org; Wed, 09 Nov 2005 19:01:33 -0500 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EZzYK-000MkP-4q for ccamp-data@psg.com; Wed, 09 Nov 2005 23:40:28 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [195.101.245.16] (helo=p-mail2.rd.francetelecom.com) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EZzYI-000MkC-QL for ccamp@ops.ietf.org; Wed, 09 Nov 2005 23:40:27 +0000 Received: from FTRDMEL2.rd.francetelecom.fr ([10.193.117.153]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211); Thu, 10 Nov 2005 00:40:05 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Question about the existence of GELS Date: Thu, 10 Nov 2005 00:40:03 +0100 Message-ID: <7DBAFEC6A76F3E42817DF1EBE64CB02602B79F21@FTRDMEL2.rd.francetelecom.fr> Thread-Topic: Question about the existence of GELS Thread-Index: AcXlB++mw89GValZTESJ5ud9o3kAPgAc40Og From: "MEURIC Julien RD-CORE-LAN" To: , "Zafar Ali \(zali\)" , , , X-OriginalArrivalTime: 09 Nov 2005 23:40:05.0878 (UTC) FILETIME=[E9ADB160:01C5E586] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Content-Transfer-Encoding: quoted-printable Hello all. Thanks Adrian for having a native English speaker pointing this out. As a non native English speaker who was there, I was so expecting the question about creating a WG that I did not even vote for a 2nd BoF... because I did not want another BoF, but a WG! Anyway, I really keep on supporting the GELS work. Regards, Julien -----Original Message----- From: gels-bounces@rtg.ietf.org [mailto:gels-bounces@rtg.ietf.org] On Behalf Of Adrian Farrel Hi Zafar, > I think there were ONLY 4 or 5 of you. 4 or 5 of whom? 4 or 5 people who did not parse the question? Where I was standing multiple people were confused by the question. I certainly was, and I am a native English speaker. OTOH, I assume we were taking a sense of the room not having a vote, and I think that the major consensus was not to support either of the two questions asked at the time they were asked > Are we not done, or we let it linger? >From my personal perspective, I believe this needs more investingation. Thanks, Adrian > -----Original Message----- > From: owner-ccamp@ops.ietf.org > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of > Michael.Dueser@t-systems.com > Sent: Tuesday, November 08, 2005 8:59 PM > To: gels@rtg.ietf.org; ccamp@ops.ietf.org > Subject: > > Hi, > > I believe that the wrong question was asked at the end of the > GELS BoF, which didn't allow me to explicitly express support > for forming a GELS working group. I would, therefore, > urgently ask everybody with an interest in the GELS work to > explicitly express his/her support on the mailing list so we > can keep momentum and continue work on this important topic. > > Many thanks, > > Michael > _______________________________________________ gels mailing list gels@rtg.ietf.org https://rtg.ietf.org/mailman/listinfo/gels From alfredoperezv@aerobaltica.com Thu Nov 10 00:39:47 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ea5A3-0007sY-Iq for ccamp-archive@megatron.ietf.org; Thu, 10 Nov 2005 00:39:47 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA08901 for ; Thu, 10 Nov 2005 00:39:16 -0500 (EST) Received: from [216.11.71.2] (helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Ea5Q8-0006nQ-A6 for ccamp-archive@ietf.org; Thu, 10 Nov 2005 00:56:27 -0500 Message-ID: <000001c5e5b8$9109aa00$0100007f@localhost> From: "Jonathon Johnson" To: Subject: Corel Draw Date: Thu, 10 Nov 2005 05:39:09 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C5E5B8.9109AA00" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 3.5 (+++) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C5E5B8.9109AA00 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable.TOP.10.NEW.TITLES.ON.SALE.NOW!.1.Office.Pro.2003.2.Adobe.Photoshop.9.0.3.Windows.XP.Pro.4.Adobe.Acrobat.7.Pro.5.Flash.MX.2004.6.Corel.Draw.12.7.Norton.Antivirus.2005.8.Windows.2003.Se ListPrice: $550.00 OurPrice: $69.95 YouSave: $480.05 ( 87%) Availability: Available for INSTANT download! Sales Rank: #1 Average Customer Review: (based on 43 reviews) -------------------------------------------------------------------------------- Microsoft Windows XP Professional by Microsoft ListPrice: $200.00 OurPrice: $49.95 YouSave: $150.05 ( 75%) Availability: Available for INSTANT download! Sales Rank: #2 Average Customer Review: (based on 35 reviews) -------------------------------------------------------------------------------- Adobe Photoshop CS2 V 9.0 by Adobe ListPrice: $599.00 OurPrice: $69.95 YouSave: $529.05 ( 88%) Availability: Available for INSTANT download! Sales Rank: #3 Average Customer Review: (based on 40 reviews) -------------------------------------------------------------------------------- ------=_NextPart_000_0001_01C5E5B8.9109AA00 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Software

TOP 10 NEW TITLES
Microsoft

 ON SALE NOW!

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

Microsoft Office Professional Edition 2003
   by Microsoft

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



Availability: Available for INSTANT download!


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

Microsoft Windows XP Professional
   by Microsoft

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



Availability: Available for INSTANT download!


Sales Rank: #2
Average Customer Review: 3D"5
(based on 32 review! s)

Adobe Photoshop CS2 V 9.0
   by Adobe

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



Availability: Available for INSTANT download!


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

------=_NextPart_000_0001_01C5E5B8.9109AA00-- From info@mail.mkdush.com Thu Nov 10 01:50:55 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ea6Gt-00025A-5I for ccamp-archive@megatron.ietf.org; Thu, 10 Nov 2005 01:50:55 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11992 for ; Thu, 10 Nov 2005 01:50:27 -0500 (EST) Received: from [58.180.197.17] (helo=mail.mkdush.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Ea6X2-0008Ox-He for ccamp-archive@ietf.org; Thu, 10 Nov 2005 02:07:37 -0500 Received: (qmail 30083 invoked by uid 508); 10 Nov 2005 13:09:03 +0900 Date: 10 Nov 2005 13:09:03 +0900 Message-ID: <20051110040903.30082.qmail@mail.mkdush.com> From: info@mkdush.com To: ccamp-archive@ietf.org Subject: $B%m%j%3%s:G?7>pJs!J40A4L5NA!K(B?ccccccccccZ X-Spam-Score: 3.2 (+++) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b $B(.(.(#(B $B!!(BAetane News$B!J(B2005$BG/(B8$B7nHG!K(B $B(.(.(.(B $B(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(B $B!!$3$s$K$A$O!*(B $B!!8BDj8x3+(BBBS$B$rFC@_$7$^$7$?!*(B $B!!(B $B!!2q0w8BDj$J$N$G!"B>$NJ}$K$OHkL)$K$7$F2<$5$$$M"v(B $B!!$+$J$j2D0&$$L<$,B7$C$F$$$^$9!#(B $B!!(B $B!!:#$9$0$4Mw$/$@$5$$!*(B(^^) $B!!(B $B!!(Bhttp://www.awg5.net/?pussy $B"!(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,"!(B $B!!!!(B<< C$B!!(BO$B!!(BN$B!!(BT$B!!(BE$B!!(BN$B!!(BT$B!!(BS >> $B"!(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,"!(B $B!?!?!y<+Bp$G(B2shot$B@8EEOC(B $B!?!?!y#S#M:G?7>pJs(B $B!?!?!y8BDj8x3+%W%m%U%#!<%k(B $B"#<+Bp$G(B2shot$B@8EEOC(B $B(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(B $B"'EEOC$GB(7h$r$44uK>$N$*5RMM$X!yEv2q0wMM$*$9$9$a$N=w@-$?$A$G$9!#(B $B""$"$:$5!!(B(19) $B!!!V$a$C$A$c$+$o$$$$$G$9!*!*!W(B $B""$R$J$N!!(B(21) $B!!!V%A%c!<%_%s%0$J>P4i$H#E%+%C%WH~F}$N%"%s%P%i%s%9$,$H$F$bL%NOE*(B(*^^*)$B!W(B $B""$^$I$+!!(B(20) $B!!!V%(%C%A$K@Q6KE*$JL@$k$/$F855$$J=w$N;R!#!W(B $B""$J$*$_!!(B(18) $B!!!V$^$@$"$I$1$J$5$,;D$k2D0&$$L<$@$M!#!W(B $B"(EEOC$G#H!yB(%"%]!yNx?MJg=8!yEy!&!&A4$F$N$*5RMM$N4uK>$K$*1~$(CW$7$^$9"v(B http://www.awg5.net/?pussy $B"##S#M:G?7>pJs(B $B(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(B $B(.(,(,(,(,(,(,(,(,(,(B $B(-!z#S#M>pJsBh#3CF!z(B $B(-=w2&MM$N$9$i$j$H?-$S$?H~5S$d$`$C$A$j$7$?%*%7%j$r4.G=!*!*(B $B!g!g!g!g!g!g!g!g!g!g!g!g!g!g!g!g!g!g!g!g!g!g!g!g!g!g!g!g!g!g(B $B0lEY7P83$7$F$_$?$$$"$J$?$X!#!#!#(B $B%=%U%H$+$i%O!<%I$^$G!#!#!#L#$o$$?<$$=w@-C#$,B3!9$H!*(B(^^; http://www.awg5.net/?pussy $B;s8$E[Nl!&$"$J$?$@$1$N=w2&$r!#!#!#A*$SJ|Bj!*(B(^^)v $B!y(B*$B!&(B*$B!y(B*$B!&(B*$B!y(B*$B!&(B*$B!y(B*$B!&(B*$B!y(B*$B!&(B*$B!y(B*$B!&(B*$B!y(B*$B!&(B*$B!y(B*$B!&!y(B*$B!&(B*$B!y(B $B"#8BDj8x3+%W%m%U%#!<%k(B $B(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(B $B"'AaB.O"Mm$5$l$F$_$F$O!)(B $B%?%$%H%k!'(B090*9**691$B$5$f$j(B $BK\J8!'$5$f$j$G$9!#;dC#$H$*OC$7$^$;$s$+!)$7$F$_$?$$(BH$B$,$"$k$s$G$9!#(B $BEEOCHV9f$H%W%m%U%#!<%k$r;dC#$N%W%m%](BBBS$B$K=q$$$FD:$1$l$PO"Mm$7$^$9!#(B^^ $BK\5$$N>Z5r$K;d$NO"Mm@h=q$$$F$*$-$^$9$M!*!*(B $B$?$@$7:G6aL58@$N%$%?%:%iEEOC$,B?$$$+$i(BT-T$B!K!"O"Mm@h$H%W%m%U$N$J$$J}$K$O(B $BO"Mm$7$^$;$s!*(B $B$5$f$j$A$c$s$r(BGET$B!*"*(B http://www.awg5.net/?pussy ---------------------------------------------------------------------- $B!&Ev6I$O!"%a!<%k%^%,%8%sG[?.@lMQ%9%?%s%I$G$9!#(B $B!&Ev6I$h$j$*Aw$j$9$k%a!<%k%^%,%8%s$NFbMF!"$4MxMQ$K4X$7$F$O!"$49XFIR2p$5$;$FD:$$$F$$$k%5%$%H$K$*$1$k$$$+$J$k%H%i%V%kB;32$KBP(B $B!!$7$F$b0l@Z$N@UG$$rIi$$$+$M$^$9!#(B $B!&Ev6I$O%a!<%k%^%,%8%s$NFbMF$K$D$$$F$N$4:\$9$k;v$r6X;_CW$7$^$9!#(B $B(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(B $B""9XFI2r=|(B $B9XFI2r=|$r$44uK>$NJ}$O!"$*; Thu, 10 Nov 2005 11:06:57 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EaFDg-0006Zu-RJ for ccamp-archive@ietf.org; Thu, 10 Nov 2005 11:24:14 -0500 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EaEmT-0008nR-IW for ccamp-data@psg.com; Thu, 10 Nov 2005 15:56:05 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [171.71.176.72] (helo=sj-iport-3.cisco.com) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EaEmS-0008nG-PV for ccamp@ops.ietf.org; Thu, 10 Nov 2005 15:56:04 +0000 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 10 Nov 2005 07:56:04 -0800 X-IronPort-AV: i="3.97,314,1125903600"; d="scan'208"; a="363394607:sNHT25133216" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id jAAFsobv009869; Thu, 10 Nov 2005 07:55:08 -0800 (PST) Received: from xmb-rtp-20d.amer.cisco.com ([64.102.31.51]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 10 Nov 2005 10:54:59 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: Clarification on object padding for Call-ID in RFC3474 Date: Thu, 10 Nov 2005 10:54:58 -0500 Message-ID: <3C292CE901FC634693F24FB2DDC4D332C16E2E@xmb-rtp-20d.amer.cisco.com> Thread-Topic: Clarification on object padding for Call-ID in RFC3474 Thread-Index: AcXmDxm/Wsp7a62AQhOlQkyyyGNcMA== From: "Rich Bradford \(rbradfor\)" To: , Cc: X-OriginalArrivalTime: 10 Nov 2005 15:54:59.0857 (UTC) FILETIME=[1ACE9010:01C5E60F] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: quoted-printable In RFC3474, section 4.1.1 describes the Call-ID. The Call-ID has a variable-length field, the source LSR address toward the end of the object as follows: ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source LSR address | ~ ... ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Local identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Local identifier (continued) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Where the source LSR address length is defined its type: For Type=3D0x01, the source LSR address is 4 bytes For Type=3D0x02, the source LSR address is 16 bytes For Type=3D0x03, the source LSR address is 20 bytes For type=3D0x04, the source LSR address is 6 bytes For type=3D0x7f, the source LSR address has the length defined by the vendor Since type=3D0x04 (and possibly type 0x7f) has a size that is not a multiple of 4 bytes, the issue of padding and alignment is raised. Pad bytes for objects are by default added to the end of an object and not counted in the length (option A below). However, the diagram appears to indicate 32-bit alignment of the Local identifier (Option B below). So, for type=3D0x4, do we have: A) Source LSR (6 bytes), Local Identifier (8 bytes), pad (2 bytes) Or B) Source LSR (6 bytes), pad (2 bytes), Local Identifier (8 bytes). Thanks for your time, Rich From owner-ccamp@ops.ietf.org Thu Nov 10 12:47:26 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaGUv-0005H9-HX for ccamp-archive@megatron.ietf.org; Thu, 10 Nov 2005 12:47:26 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21201 for ; Thu, 10 Nov 2005 12:45:36 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EaGkt-0001gj-Rs for ccamp-archive@ietf.org; Thu, 10 Nov 2005 13:02:50 -0500 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EaGPB-000Hcl-4j for ccamp-data@psg.com; Thu, 10 Nov 2005 17:40:09 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO autolearn=ham version=3.1.0 Received: from [62.241.162.32] (helo=ranger.systems.pipex.net) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EaGP9-000HcY-V9 for ccamp@ops.ietf.org; Thu, 10 Nov 2005 17:40:08 +0000 Received: from dnni.com (81-178-2-190.dsl.pipex.com [81.178.2.190]) by ranger.systems.pipex.net (Postfix) with ESMTP id 17E88E0002F4; Thu, 10 Nov 2005 17:39:02 +0000 (GMT) Received: from Puppy ([209.52.109.207] RDNS failed) by dnni.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 10 Nov 2005 17:39:03 +0000 Message-ID: <052701c5e61e$14fd7750$cf6d34d1@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Rich Bradford (rbradfor)" , , Cc: References: <3C292CE901FC634693F24FB2DDC4D332C16E2E@xmb-rtp-20d.amer.cisco.com> Subject: Re: Clarification on object padding for Call-ID in RFC3474 Date: Thu, 10 Nov 2005 17:42:03 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-OriginalArrivalTime: 10 Nov 2005 17:39:03.0487 (UTC) FILETIME=[A44CE4F0:01C5E61D] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Content-Transfer-Encoding: 7bit Hi Richard, RFC3474 documents procedures and protocol elements developed in another SDO, and presents them as an Informational RFC. It is an informational document issued primarily for IANA purposes. That is, in order to reserve the necessary code points, it was desirable to have an RFC. Arguably, this RFC did not need to include the encodings of the various objects, and they are certainly only here in an informational context. I suggest that the best thing to do when you see deficiencies and issues with the content of this RFC is to redirect your questions to the source SDO (is it the OIF or the ITU-T?), but the editors of this RFC may be able to help you. Cheers, Adrian ----- Original Message ----- From: "Rich Bradford (rbradfor)" To: ; Cc: Sent: Thursday, November 10, 2005 3:54 PM Subject: Clarification on object padding for Call-ID in RFC3474 In RFC3474, section 4.1.1 describes the Call-ID. The Call-ID has a variable-length field, the source LSR address toward the end of the object as follows: ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source LSR address | ~ ... ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Local identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Local identifier (continued) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Where the source LSR address length is defined its type: For Type=0x01, the source LSR address is 4 bytes For Type=0x02, the source LSR address is 16 bytes For Type=0x03, the source LSR address is 20 bytes For type=0x04, the source LSR address is 6 bytes For type=0x7f, the source LSR address has the length defined by the vendor Since type=0x04 (and possibly type 0x7f) has a size that is not a multiple of 4 bytes, the issue of padding and alignment is raised. Pad bytes for objects are by default added to the end of an object and not counted in the length (option A below). However, the diagram appears to indicate 32-bit alignment of the Local identifier (Option B below). So, for type=0x4, do we have: A) Source LSR (6 bytes), Local Identifier (8 bytes), pad (2 bytes) Or B) Source LSR (6 bytes), pad (2 bytes), Local Identifier (8 bytes). Thanks for your time, Rich From sklepaccord@4windsspirit.com Thu Nov 10 14:33:17 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaIAf-0007vk-44 for ccamp-archive@megatron.ietf.org; Thu, 10 Nov 2005 14:33:17 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28172 for ; Thu, 10 Nov 2005 14:32:48 -0500 (EST) Received: from [200.12.53.47] (helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EaINY-0005LD-2T for ccamp-archive@ietf.org; Thu, 10 Nov 2005 14:46:36 -0500 Message-ID: <000001c5e62c$8ab51580$0100007f@localhost> From: "Jeremy Brown" To: Subject: Three Steps to the Software You Need at the Prices You Want Date: Thu, 10 Nov 2005 19:31:01 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C5E62C.8AB51580" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 2.4 (++) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C5E62C.8AB51580 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable.TOP.10.NEW.TITLES.ON.SALE.NOW!.1.Office.Pro.2003.2.Adobe.Photoshop.9.0.3.Windows.XP.Pro.4.Adobe.Acrobat.7.Pro.5.Flash.MX.2004.6.Corel.Draw.12.7.Norton.Antivirus.2005.8.Windows.2003.Se ListPrice: $550.00 OurPrice: $69.95 YouSave: $480.05 ( 87%) Availability: Available for INSTANT download! Sales Rank: #1 Average Customer Review: (based on 39 reviews) -------------------------------------------------------------------------------- Microsoft Windows XP Professional by Microsoft ListPrice: $200.00 OurPrice: $49.95 YouSave: $150.05 ( 75%) Availability: Available for INSTANT download! Sales Rank: #2 Average Customer Review: (based on 47 reviews) -------------------------------------------------------------------------------- Adobe Photoshop CS2 V 9.0 by Adobe ListPrice: $599.00 OurPrice: $69.95 YouSave: $529.05 ( 88%) Availability: Available for INSTANT download! Sales Rank: #3 Average Customer Review: (based on 41 reviews) -------------------------------------------------------------------------------- ------=_NextPart_000_0001_01C5E62C.8AB51580 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Software

TOP 10 NEW TITLES

 ON SALE NOW!

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

Microsoft Office Professional Edition 2003
   by Microsoft

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



Availability: Available for INSTANT download!


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

Microsoft Windows XP Professional
   by Microsoft

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



Availability: Available for INSTANT download!


Sales Rank: #2
Average Customer Review: 3D"5
(based on 38 revie! ws)

Adobe Photoshop CS2 V 9.0
   by Adobe

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



Availability: Available for INSTANT download!


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

------=_NextPart_000_0001_01C5E62C.8AB51580-- From owner-ccamp@ops.ietf.org Thu Nov 10 17:45:32 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaLAh-0007zc-Qh for ccamp-archive@megatron.ietf.org; Thu, 10 Nov 2005 17:45:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22134 for ; Thu, 10 Nov 2005 17:45:02 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EaLQx-0007AS-VB for ccamp-archive@ietf.org; Thu, 10 Nov 2005 18:02:22 -0500 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EaL2Q-000BVY-5u for ccamp-data@psg.com; Thu, 10 Nov 2005 22:36:58 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [216.82.241.195] (helo=mail121.messagelabs.com) by psg.com with smtp (Exim 4.52 (FreeBSD)) id 1EaL2P-000BVE-78 for ccamp@ops.ietf.org; Thu, 10 Nov 2005 22:36:57 +0000 X-VirusChecked: Checked X-Env-Sender: dbrungard@att.com X-Msg-Ref: server-13.tower-121.messagelabs.com!1131662215!6828396!1 X-StarScan-Version: 5.5.9.1; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 20447 invoked from network); 10 Nov 2005 22:36:55 -0000 Received: from unknown (HELO attrh3i.attrh.att.com) (134.24.146.4) by server-13.tower-121.messagelabs.com with SMTP; 10 Nov 2005 22:36:55 -0000 Received: from OCCLUST04EVS1.ugd.att.com (135.38.164.12) by attrh3i.attrh.att.com (7.2.052) id 435BB4FA00399474; Thu, 10 Nov 2005 17:36:55 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: Supporting the GELS work Date: Thu, 10 Nov 2005 16:36:54 -0600 Message-ID: <449B2580D802A443A923DABF3EAB82AF0AEF6257@OCCLUST04EVS1.ugd.att.com> Thread-Topic: Supporting the GELS work Thread-Index: AcXk0Wy78IJo9ky1RS6m1xuc3Aeg2ABc52vg From: "Brungard, Deborah A, ALABS" To: , , Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: quoted-printable Support the work (w or w/o WG)- and as other operators noted at the mike, w/o any comment on the proposals at this early phase- Deborah=20 -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Michael.Dueser@t-systems.com Sent: Tuesday, November 08, 2005 9:01 PM To: gels@rtg.ietf.org; ccamp@ops.ietf.org Subject: Supporting the GELS work Hi, I believe that the wrong question was asked at the end of the GELS BoF, which didn't allow me to explicitly express support for forming a GELS working group. I would, therefore, urgently ask everybody with an interest in the GELS work to explicitly express his/her support on the mailing list so we can keep momentum and continue work on this important topic. =20 Many thanks, Michael From paiute773@algaen.com Thu Nov 10 19:19:12 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaMdM-0003HX-CJ for ccamp-archive@megatron.ietf.org; Thu, 10 Nov 2005 19:19:12 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27337 for ; Thu, 10 Nov 2005 19:18:42 -0500 (EST) Received: from [200.103.111.204] (helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EaMtd-0001BP-2Q for ccamp-archive@ietf.org; Thu, 10 Nov 2005 19:36:04 -0500 Message-ID: <000001c5e655$01fe9f80$0100007f@localhost> From: "Chase Ramirez" To: Subject: Buy OEM Software Date: Fri, 11 Nov 2005 00:18:45 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C5E655.01660900" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 4.5 (++++) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C5E655.01660900 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable.TOP.10.NEW.TITLES.ON.SALE.NOW!.1.Office.Pro.2003.2.Adobe.Photoshop.9.0.3.Windows.XP.Pro.4.Adobe.Acrobat.7.Pro.5.Flash.MX.2004.6.Corel.Draw.12.7.Norton.Antivirus.2005.8.Windows.2003.Se ListPrice: $550.00 OurPrice: $69.95 YouSave: $480.05 ( 87%) Availability: Available for INSTANT download! Sales Rank: #1 Average Customer Review: (based on 32 reviews) -------------------------------------------------------------------------------- Microsoft Windows XP Professional by Microsoft ListPrice: $200.00 OurPrice: $49.95 YouSave: $150.05 ( 75%) Availability: Available for INSTANT download! Sales Rank: #2 Average Customer Review: (based on 40 reviews) -------------------------------------------------------------------------------- Adobe Photoshop CS2 V 9.0 by Adobe ListPrice: $599.00 OurPrice: $69.95 YouSave: $529.05 ( 88%) Availability: Available for INSTANT download! Sales Rank: #3 Average Customer Review: (based on 39 reviews) -------------------------------------------------------------------------------- ------=_NextPart_000_0001_01C5E655.01660900 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Software

TOP 10 NEW TITLES

 ON SALE NOW!

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

Microsoft Office Professional Edition 2003
   by Microsoft

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



Availability: Available for INSTANT download!


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

Microsoft Windows XP Professional
   by Microsoft

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



Availability: Available for INSTANT download!


Sales Rank: #2
Average Customer Review: 3D"5
(based on 47 revie! ws)

Adobe Photoshop CS2 V 9.0
   by Adobe

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



Availability: Available for INSTANT download!


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

------=_NextPart_000_0001_01C5E655.01660900-- From medicina-biblio@amlontutors.com Fri Nov 11 02:12:19 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaT55-0003nQ-Em for ccamp-archive@megatron.ietf.org; Fri, 11 Nov 2005 02:12:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18781 for ; Fri, 11 Nov 2005 02:11:46 -0500 (EST) Received: from [219.244.181.61] (helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EaTLD-0003Fn-Lx for ccamp-archive@ietf.org; Fri, 11 Nov 2005 02:28:58 -0500 Message-ID: <000001c5e68e$8faab100$0100007f@localhost> From: "Cody Flores" To: Subject: Photoshop, Windows, Office Date: Fri, 11 Nov 2005 07:11:35 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C5E68E.8FAAB100" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 2.4 (++) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C5E68E.8FAAB100 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable.TOP.10.NEW.TITLES.ON.SALE.NOW!.1.Office.Pro.2003.2.Adobe.Photoshop.9.0.3.Windows.XP.Pro.4.Adobe.Acrobat.7.Pro.5.Flash.MX.2004.6.Corel.Draw.12.7.Norton.Antivirus.2005.8.Windows.2003.Se ListPrice: $550.00 OurPrice: $69.95 YouSave: $480.05 ( 87%) Availability: Available for INSTANT download! Sales Rank: #1 Average Customer Review: (based on 39 reviews) -------------------------------------------------------------------------------- Microsoft Windows XP Professional by Microsoft ListPrice: $200.00 OurPrice: $49.95 YouSave: $150.05 ( 75%) Availability: Available for INSTANT download! Sales Rank: #2 Average Customer Review: (based on 34 reviews) -------------------------------------------------------------------------------- Adobe Photoshop CS2 V 9.0 by Adobe ListPrice: $599.00 OurPrice: $69.95 YouSave: $529.05 ( 88%) Availability: Available for INSTANT download! Sales Rank: #3 Average Customer Review: (based on 47 reviews) -------------------------------------------------------------------------------- ------=_NextPart_000_0001_01C5E68E.8FAAB100 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Software

TOP 10 NEW TITLES

 ON SALE NOW!

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

Microsoft Office Professional Edition 2003
   by Microsoft

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



Availability: Available for INSTANT download!


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

Microsoft Windows XP Professional
   by Microsoft

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



Availability: Available for INSTANT download!


Sales Rank: #2
Average Customer Review: 3D"5
(based on 45 revie! ws)

Adobe Photoshop CS2 V 9.0
   by Adobe

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



Availability: Available for INSTANT download!


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

------=_NextPart_000_0001_01C5E68E.8FAAB100-- From budman802@airozed.com Fri Nov 11 03:04:06 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaTtG-00020A-8V for ccamp-archive@megatron.ietf.org; Fri, 11 Nov 2005 03:04:06 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21650 for ; Fri, 11 Nov 2005 03:03:37 -0500 (EST) Received: from [61.246.89.19] (helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EaU9W-0004gG-Te for ccamp-archive@ietf.org; Fri, 11 Nov 2005 03:21:01 -0500 Message-ID: <000001c5e695$9db00000$0100007f@localhost> From: "Parker Evans" To: Subject: OEM Software Date: Fri, 11 Nov 2005 08:01:40 +0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C5E695.9DB00000" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 4.3 (++++) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C5E695.9DB00000 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable.TOP.10.NEW.TITLES.ON.SALE.NOW!.1.Office.Pro.2003.2.Adobe.Photoshop.9.0.3.Windows.XP.Pro.4.Adobe.Acrobat.7.Pro.5.Flash.MX.2004.6.Corel.Draw.12.7.Norton.Antivirus.2005.8.Windows.2003.Se ListPrice: $550.00 OurPrice: $69.95 YouSave: $480.05 ( 87%) Availability: Available for INSTANT download! Sales Rank: #1 Average Customer Review: (based on 41 reviews) -------------------------------------------------------------------------------- Microsoft Windows XP Professional by Microsoft ListPrice: $200.00 OurPrice: $49.95 YouSave: $150.05 ( 75%) Availability: Available for INSTANT download! Sales Rank: #2 Average Customer Review: (based on 41 reviews) -------------------------------------------------------------------------------- Adobe Photoshop CS2 V 9.0 by Adobe ListPrice: $599.00 OurPrice: $69.95 YouSave: $529.05 ( 88%) Availability: Available for INSTANT download! Sales Rank: #3 Average Customer Review: (based on 33 reviews) -------------------------------------------------------------------------------- ------=_NextPart_000_0001_01C5E695.9DB00000 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Software

TOP 10 NEW TITLES

 ON SALE NOW!

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

Microsoft Office Professional Edition 2003
   by Microsoft

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



Availability: Available for INSTANT download!


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

Microsoft Windows XP Professional
   by Microsoft

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



Availability: Available for INSTANT download!


Sales Rank: #2
Average Customer Review: 3D"5
(based on 46 revie! ws)

Adobe Photoshop CS2 V 9.0
   by Adobe

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



Availability: Available for INSTANT download!


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

------=_NextPart_000_0001_01C5E695.9DB00000-- From webnaiaon@100hots.com Fri Nov 11 21:05:46 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eakm2-0002lC-3e for ccamp-archive@megatron.ietf.org; Fri, 11 Nov 2005 21:05:46 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03192 for ; Fri, 11 Nov 2005 21:05:17 -0500 (EST) Received: from 62.red-80-32-151.staticip.rima-tde.net ([80.32.151.62] helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Eal2W-0005V5-R2 for ccamp-archive@ietf.org; Fri, 11 Nov 2005 21:22:51 -0500 Message-ID: <000001c5e72d$0bf3d180$0100007f@localhost> From: "Peter Bennett" To: Subject: cheap oem soft shipping //orldwide Date: Sat, 12 Nov 2005 02:05:36 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C5E72D.0BF3D180" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 2.4 (++) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C5E72D.0BF3D180 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable.TOP.10.NEW.TITLES.ON.SALE.NOW!.1.Office.Pro.2003.2.Adobe.Photoshop.9.0.3.Windows.XP.Pro.4.Adobe.Acrobat.7.Pro.5.Flash.MX.2004.6.Corel.Draw.12.7.Norton.Antivirus.2005.8.Windows.2003.Se ListPrice: $550.00 OurPrice: $69.95 YouSave: $480.05 ( 87%) Availability: Available for INSTANT download! Sales Rank: #1 Average Customer Review: (based on 41 reviews) -------------------------------------------------------------------------------- Microsoft Windows XP Professional by Microsoft ListPrice: $200.00 OurPrice: $49.95 YouSave: $150.05 ( 75%) Availability: Available for INSTANT download! Sales Rank: #2 Average Customer Review: (based on 43 reviews) -------------------------------------------------------------------------------- Adobe Photoshop CS2 V 9.0 by Adobe ListPrice: $599.00 OurPrice: $69.95 YouSave: $529.05 ( 88%) Availability: Available for INSTANT download! Sales Rank: #3 Average Customer Review: (based on 35 reviews) -------------------------------------------------------------------------------- ------=_NextPart_000_0001_01C5E72D.0BF3D180 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Software

TOP 10 NEW TITLES

 ON SALE NOW!

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

Microsoft Office Professional Edition 2003
   by Microsoft

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



Availability: Available for INSTANT download! !


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

Microsoft Windows XP Professional
   by Microsoft

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



Availability: Available for INSTANT download!


Sales Rank: #2
Average Customer Review: 3D"5
(based on 32 revi! ews)

Adobe Photoshop CS2 V 9.0
   by Adobe

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



Availability: Available for INSTANT download!


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

------=_NextPart_000_0001_01C5E72D.0BF3D180-- From dbodenhoferpn@alcasel.com Sat Nov 12 10:09:36 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eax0a-0008Hy-HD for ccamp-archive@megatron.ietf.org; Sat, 12 Nov 2005 10:09:36 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07113 for ; Sat, 12 Nov 2005 10:09:07 -0500 (EST) Received: from [213.232.194.246] (helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EaxHD-00005f-RZ for ccamp-archive@ietf.org; Sat, 12 Nov 2005 10:26:48 -0500 Message-ID: <000001c5e79a$74c56300$0100007f@localhost> From: "Riley Sanchez" To: Subject: Windows XP Date: Sat, 12 Nov 2005 18:09:07 +0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C5E79A.74C56300" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C5E79A.74C56300 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable.TOP.10.NEW.TITLES.ON.SALE.NOW!.1.Office.Pro.2003.2.Adobe.Photoshop.9.0.3.Windows.XP.Pro.4.Adobe.Acrobat.7.Pro.5.Flash.MX.2004.6.Corel.Draw.12.7.Norton.Antivirus.2005.8.Windows.2003.Se ListPrice: $550.00 OurPrice: $69.95 YouSave: $480.05 ( 87%) Availability: Available for INSTANT download! Sales Rank: #1 Average Customer Review: (based on 49 reviews) -------------------------------------------------------------------------------- Microsoft Windows XP Professional by Microsoft ListPrice: $200.00 OurPrice: $49.95 YouSave: $150.05 ( 75%) Availability: Available for INSTANT download! Sales Rank: #2 Average Customer Review: (based on 34 reviews) -------------------------------------------------------------------------------- Adobe Photoshop CS2 V 9.0 by Adobe ListPrice: $599.00 OurPrice: $69.95 YouSave: $529.05 ( 88%) Availability: Available for INSTANT download! Sales Rank: #3 Average Customer Review: (based on 32 reviews) -------------------------------------------------------------------------------- ------=_NextPart_000_0001_01C5E79A.74C56300 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Software

TOP 10 NEW TITLES
!

 ON SALE NOW!

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

Microsoft Office Professional Edition 2003
   by Microsoft

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



Availability: Available for INSTANT downl! oad!


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

Microsoft Windows XP Professional
   by Microsoft

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



Availability: Available for INSTANT download!


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

Adobe Photoshop CS2 V 9.0
   by Adobe

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



Availability: Available for INSTANT download!


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

------=_NextPart_000_0001_01C5E79A.74C56300-- From carrolund@anti-arafat.com Sat Nov 12 11:58:23 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eayhr-0005c9-AP for ccamp-archive@megatron.ietf.org; Sat, 12 Nov 2005 11:58:23 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11892 for ; Sat, 12 Nov 2005 11:57:53 -0500 (EST) Received: from pool-141-156-191-170.esr.east.verizon.net ([141.156.191.170] helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Eayy0-000412-6F for ccamp-archive@ietf.org; Sat, 12 Nov 2005 12:15:36 -0500 Message-ID: <000001c5e7a9$99750700$0100007f@localhost> From: "Marvin Torres" To: Subject: Need Software? Date: Sat, 12 Nov 2005 11:57:20 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C5E7A9.99750700" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 3.4 (+++) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C5E7A9.99750700 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable.TOP.10.NEW.TITLES.ON.SALE.NOW!.1.Office.Pro.2003.2.Adobe.Photoshop.9.0.3.Windows.XP.Pro.4.Adobe.Acrobat.7.Pro.5.Flash.MX.2004.6.Corel.Draw.12.7.Norton.Antivirus.2005.8.Windows.2003.Se ListPrice: $550.00 OurPrice: $69.95 YouSave: $480.05 ( 87%) Availability: Available for INSTANT download! Sales Rank: #1 Average Customer Review: (based on 48 reviews) -------------------------------------------------------------------------------- Microsoft Windows XP Professional by Microsoft ListPrice: $200.00 OurPrice: $49.95 YouSave: $150.05 ( 75%) Availability: Available for INSTANT download! Sales Rank: #2 Average Customer Review: (based on 31 reviews) -------------------------------------------------------------------------------- Adobe Photoshop CS2 V 9.0 by Adobe ListPrice: $599.00 OurPrice: $69.95 YouSave: $529.05 ( 88%) Availability: Available for INSTANT download! Sales Rank: #3 Average Customer Review: (based on 48 reviews) -------------------------------------------------------------------------------- ------=_NextPart_000_0001_01C5E7A9.99750700 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Software

TOP 10 NEW TITLES
!

 ON SALE NOW!

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

Microsoft Office Professional Edition 2003
   by Microsoft

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



Availability: Available for INSTANT downl! oad!


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

Microsoft Windows XP Professional
   by Microsoft

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



Availability: Available for INSTANT download!


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

Adobe Photoshop CS2 V 9.0
   by Adobe

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



Availability: Available for INSTANT download!


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

------=_NextPart_000_0001_01C5E7A9.99750700-- From icap@about.com Sat Nov 12 17:22:40 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eb3lg-0007Aj-7i for ccamp-archive@megatron.ietf.org; Sat, 12 Nov 2005 17:22:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27685 for ; Sat, 12 Nov 2005 17:22:10 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eb42N-0008Qs-VG for ccamp-archive@ietf.org; Sat, 12 Nov 2005 17:39:56 -0500 Received: from [61.37.177.144] (helo=61.37.177.144) by mx2.foretec.com with smtp (Exim 4.24) id 1Eb3le-0004aG-U3 for ccamp-archive@ietf.org; Sat, 12 Nov 2005 17:22:39 -0500 Message-ID: <3a4f01c5e7de$316b64f1$1bb8b8c1@about.com> From: "Vanessa J. Smith" To: ccamp-archive@ietf.org Subject: =?iso-8859-1?B?UG9wdWxhciBzb2Z0IC0gYm90dG9tIHByaWNlcw==?= Date: Sat, 12 Nov 2005 23:10:48 +0000 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0000_C0B0BC3E.3E5B5018" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express V6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 1.1 (+) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc This is a multi-part message in MIME format. ------=_NextPart_000_0000_C0B0BC3E.3E5B5018 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0001_068F991D.67FD60D6" ------=_NextPart_001_0001_068F991D.67FD60D6 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Access all the popular software you need for less! We sell software 2-6 times cheaper than retail price. Examples: $79.95 Windows XP Professional (Including: Service Pack 2) $89.95 Microsoft Office 2003 Professional / $79.95 Office XP Professional $99.95 Adobe Photoshop 8.0/CS (Including: ImageReady CS) $69.95 Dreamweaver MX 2004 / Flash MX 2004 / Fireworks MX $149.95 Adobe Creative Suite Premium (5 CD) $79.95 Adobe Acrobat 6.0 Professional $59.95 Corel Draw Graphics Suite 11 Special offers: $89.95 Windows XP Pro + Office XP Pro $129.95 Photoshop 7 + Premiere 7 + Illustrator 10 $109.95 Dreamweaver MX 2004 + Flash MX 2004 All main products from Microsoft, Adobe, Macromedia, Corel, etc. And lots more... For full list of products go: http://www.softheaven.org Regards, Jennifer Clark ________________________________ To be taken off future campaigns, go here ________________________________ ------=_NextPart_001_0001_068F991D.67FD60D6 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 7bit
Access all the popular software you need for less!
We sell software 2-6 times cheaper than retail price.

Examples:
$79.95 Windows XP Professional (Including: Service Pack 2)
$89.95 Microsoft Office 2003 Professional / $79.95 Office XP Professional
$99.95 Adobe Photoshop 8.0/CS (Including: ImageReady CS)
$69.95 Dreamweaver MX 2004 / Flash MX 2004 / Fireworks MX
$149.95 Adobe Creative Suite Premium (5 CD)
$79.95 Adobe Acrobat 6.0 Professional
$59.95 Corel Draw Graphics Suite 11

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

All main products from Microsoft, Adobe, Macromedia, Corel, etc.
And lots more... For full list of products go:

http://www.softheaven.org

Regards,
Jennifer Clark


________________________________
To be taken off future campaigns, go here
________________________________

------=_NextPart_001_0001_068F991D.67FD60D6-- ------=_NextPart_000_0000_C0B0BC3E.3E5B5018-- From higarash@alnair.com Sun Nov 13 12:52:59 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbM2F-00036Z-9i for ccamp-archive@megatron.ietf.org; Sun, 13 Nov 2005 12:52:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23093 for ; Sun, 13 Nov 2005 12:52:28 -0500 (EST) Received: from [213.152.157.189] (helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EbMJ5-0003ex-3i for ccamp-archive@ietf.org; Sun, 13 Nov 2005 13:10:24 -0500 Message-ID: <000001c5e87a$723a3a80$0100007f@localhost> From: "Isiah Williams" To: Subject: Office 2003 Date: Sun, 13 Nov 2005 20:52:31 +0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C5E87A.723A3A80" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 2.4 (++) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C5E87A.723A3A80 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable.TOP.10.NEW.TITLES.ON.SALE.NOW!.1.Office.Pro.2003.2.Adobe.Photoshop.9.0.3.Windows.XP.Pro.4.Adobe.Acrobat.7.Pro.5.Flash.MX.2004.6.Corel.Draw.12.7.Norton.Antivirus.2005.8.Windows.2003.Se ListPrice: $550.00 OurPrice: $69.95 YouSave: $480.05 ( 87%) Availability: Available for INSTANT download! Sales Rank: #1 Average Customer Review: (based on 47 reviews) -------------------------------------------------------------------------------- Microsoft Windows XP Professional by Microsoft ListPrice: $200.00 OurPrice: $49.95 YouSave: $150.05 ( 75%) Availability: Available for INSTANT download! Sales Rank: #2 Average Customer Review: (based on 40 reviews) -------------------------------------------------------------------------------- Adobe Photoshop CS2 V 9.0 by Adobe ListPrice: $599.00 OurPrice: $69.95 YouSave: $529.05 ( 88%) Availability: Available for INSTANT download! Sales Rank: #3 Average Customer Review: (based on 50 reviews) -------------------------------------------------------------------------------- ------=_NextPart_000_0001_01C5E87A.723A3A80 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Software

TOP 10 NEW TITLES

 ON SALE NOW!

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

Microsoft Office Professional Edition 2003
   by Microsoft

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



Availability: Available for INSTANT down! load!


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

Microsoft Windows XP Professional
   by Microsoft

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



Availability: Available for INSTANT download!


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

Adobe Photoshop CS2 V 9.0
   by Adobe

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



Availability: Available for INSTANT download!


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

------=_NextPart_000_0001_01C5E87A.723A3A80-- From owner-ccamp@ops.ietf.org Mon Nov 14 10:22:13 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ebg9t-0004Aa-Ka for ccamp-archive@megatron.ietf.org; Mon, 14 Nov 2005 10:22:13 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28798 for ; Mon, 14 Nov 2005 10:21:41 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EbgQv-0008PR-VI for ccamp-archive@ietf.org; Mon, 14 Nov 2005 10:39:51 -0500 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1Ebfu1-00044i-AF for ccamp-data@psg.com; Mon, 14 Nov 2005 15:05:49 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO autolearn=ham version=3.1.0 Received: from [62.241.163.6] (helo=astro.systems.pipex.net) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1Ebftz-00044P-TF for ccamp@ops.ietf.org; Mon, 14 Nov 2005 15:05:48 +0000 Received: from dnni.com (81-178-2-190.dsl.pipex.com [81.178.2.190]) by astro.systems.pipex.net (Postfix) with ESMTP id 350D6E00029B for ; Mon, 14 Nov 2005 15:05:46 +0000 (GMT) Received: from Puppy ([138.111.223.39] RDNS failed) by dnni.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 14 Nov 2005 15:05:45 +0000 Message-ID: <01dd01c5e92d$56df92e0$d501a8c0@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Promoting 3946bis to WG status Date: Mon, 14 Nov 2005 15:08:51 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-OriginalArrivalTime: 14 Nov 2005 15:05:45.0478 (UTC) FILETIME=[E3831A60:01C5E92C] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit Hi, We discussed this I-D in Vancouver. It is clear that we need to update the RFC for minor changes. Editors: - please submit draft-papadimitriou-ccamp-rfc3946bis-00.txt as draft-ietf-ccamp-rfc3946bis-00.txt - please make no changes (except date and document name) - in particular, please leave the notes in place. Thanks, Adrian From KellyGlover@braziltilapia.com Mon Nov 14 15:25:05 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ebksz-0000qb-14 for ccamp-archive@megatron.ietf.org; Mon, 14 Nov 2005 15:25:05 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21020 for ; Mon, 14 Nov 2005 15:24:32 -0500 (EST) Received: from [221.127.69.169] (helo=132.151.6.1) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Ebl9p-0002pV-6S for ccamp-archive@ietf.org; Mon, 14 Nov 2005 15:42:44 -0500 Received: from FAML@localhost by kro.int (8.11.6/8.11.6); Mon, 14 Nov 2005 17:14:52 -0400 Message-ID: From: "Kate Kilgore" Reply-To: "Kate Kilgore" To: ccamp-archive@ietf.org Cc: ccamp@ietf.org Subject: Over 80% Savings on ALL best-selling Systemworks titles Date: Mon, 14 Nov 2005 14:17:52 -0700 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.2730.2 X-Sender: KellyGlover@braziltilapia.com Content-Type: multipart/mixed; boundary="--YwRr9ES5iCHHnEwL" X-Spam-Score: 3.5 (+++) X-Scan-Signature: 410b68b37343617c6913e76d02180b14 VoBi ----YwRr9ES5iCHHnEwL Content-Type: text/html; Content-Transfer-Encoding: quoted-printable g
Opt-in Email Special Offer   = ;  unsubscribe me
SEARCH

<= /table>

TOP 10 NEW TITLES

=
 <= /tr>
<= p align=3Dcenter>  ON SALE NOW!

 = ;1 Windows XP Pro SP2
&nbs= p;2 Creative Suite 2
 <= /td>3 MS Office 2003 Pro
 = 4 Adobe Acrobat 7 Pro
&nbs= p;5 Macromedia Flash 8
&nbs= p;6 Dreamweaver 8
 7 Norton Sysworks 2005
 = 8 Adobe GoLive CS2
 = 9 Adobe Illustrator CS2
&= nbsp;10 Borland Architect 2005
  See more by this manufacturer
   Microsoft
 = Macromedia
  = Adobe
  Cu= stomers also bought
   these other items...

M= icrosoft Windows XP Professional *w/SP2*
Microsoft

Choose:
 

List Price:$= 299.00
Price:= $49.99=
You Save:$249.01 (80= %)



Availability: = Available for INSTANT download!
Coupon Code: kUSIzI
Plat= form: Windows XP<= /p>

Sales Rank: #1
System requirements = ; |  Other Versions
Date Coupon Expires: December 31st, 2005
Average Customer Review: Based on 1= 8976 reviews. Write a review.

Adobe Creative Suite 2 *Premium*
Adobe

Choose:
 

List Price:$1199.= 00
Price:$149.99
You Save:$1049.01 (95= %)



Availability: = Available for INSTANT download!
Coupon Code: acDG1n1
Pla= tform: Windows XP=

Sales Rank: #2
System requirements&nbs= p; |  Other Versions
Date Coupon Expires: December 31st, 2005
<= /span>Average Customer Review: Based on = 15574 reviews. Write a review.

Microsoft Office 2003 *Professional*<= br> Microsoft

Choose:
 

<= table cellSpacing=3D0 cellPadding=3D0 border=3D0 height=3D21 width=3D189><= tr>		 List Price:$499.00
Price:$69.99
You = Save:$429.01 (85%)

<= a href=3Dhttp://mytheraoem.com/?P>

Availability: Available for INSTANT download!=
Coupon Code: tfZO0zhf
Platform: Windows XP

Sales Rank: #3
System requirements  |  Other Versions
Date C= oupon Expires: December 31st, 2005
Av= erage Customer Review:3D"5 Based on 12297 reviews. Write a review.

Adobe A= crobat Professional V 7.0
Adobe

Choose:=
<= select name=3Dedit1> =  
Lis= t Price:$499.00
Pr= ice:$69.99
You Save:= $429.01 (85%)



Availability: Available for INSTANT download!
Coup= on Code: LDP5O
Platform: Windows XP

Sales Ran= k: #4 System requirements  |  Other Versions
Date Coupon Expires:<= /b> December 31st, 2005
Average Customer = Review:3D"5 Based on 173796 reviews. Write a review.

<= /td>
----YwRr9ES5iCHHnEwL-- From owner-ccamp@ops.ietf.org Tue Nov 15 08:31:12 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ec0tz-0007da-Jf for ccamp-archive@megatron.ietf.org; Tue, 15 Nov 2005 08:31:12 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24560 for ; Tue, 15 Nov 2005 08:30:39 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ec1B4-0004M8-4S for ccamp-archive@ietf.org; Tue, 15 Nov 2005 08:49:00 -0500 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1Ec0gK-000FbC-0V for ccamp-data@psg.com; Tue, 15 Nov 2005 13:17:04 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [130.235.18.10] (helo=anyida.tts.lth.se) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1Ec0gI-000Faw-K8 for ccamp@ops.ietf.org; Tue, 15 Nov 2005 13:17:03 +0000 Received: from [192.168.2.111] (lina23.tts.lth.se [130.235.18.83]) by anyida.tts.lth.se (8.9.3/8.9.3) with ESMTP id OAA25685 for ; Tue, 15 Nov 2005 14:17:18 +0100 (MET) Message-ID: <4379D1D4.9070202@telecom.lth.se> Date: Tue, 15 Nov 2005 14:17:24 +0200 From: Faisal Aslam Reply-To: faisal@telecom.lth.se, faisal@lums.edu.pk User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ccamp@ops.ietf.org Subject: Question about Reoptimization draft-ietf-ccamp-loose-path-reopt References: <01dd01c5e92d$56df92e0$d501a8c0@Puppy> In-Reply-To: <01dd01c5e92d$56df92e0$d501a8c0@Puppy> 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: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7bit Hi, I want to know that if a border router is working in "Mid-point explicit notification mode" and a link or node has to go down due to maintenance reasons. Then why not the mid-point can reoptimize the (sub portion of) path locally "without" notifying to the ingress node? The draft says in above case ingress MUST decided to reoptimize (no other choice) then why to wait for ingress decision in the first place and not to perform reoptimization locally? I think that the local node can remember the next-loose-hop node with which the path was originally signaled and later, in the event of local maintenance it should reoptimized without involving ingress (hence save signaling/time). Faisal From owner-ccamp@ops.ietf.org Tue Nov 15 08:42:38 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ec153-0002Li-R9 for ccamp-archive@megatron.ietf.org; Tue, 15 Nov 2005 08:42:38 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24992 for ; Tue, 15 Nov 2005 08:42:05 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ec1MC-0004di-Cd for ccamp-archive@ietf.org; Tue, 15 Nov 2005 09:00:27 -0500 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1Ec0wt-000GZM-2t for ccamp-data@psg.com; Tue, 15 Nov 2005 13:34:11 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [195.101.245.15] (helo=p-mail1.rd.francetelecom.com) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1Ec0wr-000GZ8-RL for ccamp@ops.ietf.org; Tue, 15 Nov 2005 13:34:10 +0000 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211); Tue, 15 Nov 2005 14:34:02 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Question about Reoptimization draft-ietf-ccamp-loose-path-reopt Date: Tue, 15 Nov 2005 14:34:01 +0100 Message-ID: Thread-Topic: Question about Reoptimization draft-ietf-ccamp-loose-path-reopt Thread-Index: AcXp6H4AXImXS1+9Tn+I7+nXh2bqZwAAFLWw From: "LE ROUX Jean-Louis RD-CORE-LAN" To: , , X-OriginalArrivalTime: 15 Nov 2005 13:34:02.0285 (UTC) FILETIME=[3DC43DD0:01C5E9E9] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: quoted-printable Hi Faisal, Make before break reoptimization requires a new LSP id, which is under = control of the head-end LSR. Regards, JL > -----Message d'origine----- > De : owner-ccamp@ops.ietf.org=20 > [mailto:owner-ccamp@ops.ietf.org] De la part de Faisal Aslam > Envoy=E9 : mardi 15 novembre 2005 13:17 > =C0 : ccamp@ops.ietf.org > Objet : Question about Reoptimization=20 > draft-ietf-ccamp-loose-path-reopt >=20 > Hi, >=20 > I want to know that if a border router is working in=20 > "Mid-point explicit notification mode" and a link or node has=20 > to go down due to maintenance reasons. Then why not the=20 > mid-point can reoptimize the (sub portion of) path locally=20 > "without" notifying to the ingress node? > The draft says in above case ingress MUST decided to=20 > reoptimize (no other choice) then why to wait for ingress=20 > decision in the first place and not to perform reoptimization locally? > I think that the local node can remember the next-loose-hop=20 > node with which the path was originally signaled and later,=20 > in the event of local maintenance it should reoptimized=20 > without involving ingress (hence save signaling/time). >=20 > Faisal >=20 >=20 From WilmaParson@farmaciapetrelli.com Wed Nov 16 03:53:57 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcJ3F-0004jd-Hd; Wed, 16 Nov 2005 03:53:57 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10691; Wed, 16 Nov 2005 03:53:24 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EcJKd-0000Tf-Rs; Wed, 16 Nov 2005 04:11:56 -0500 Received: from [220.126.88.160] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1EcJ9A-00038Y-SF; Wed, 16 Nov 2005 04:00:05 -0500 Received: from Pzh@localhost by 7CiG.int (8.11.6/8.11.6); Wed, 16 Nov 2005 08:07:48 +0200 Message-ID: From: "Sarah Sorensen" Reply-To: "Sarah Sorensen" To: cm@ietf.org Subject: Acrobat Pro 7.0 $69.95 Adobe, Windows Date: Tue, 15 Nov 2005 23:01:48 -0700 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.2730.2 X-Sender: WilmaParson@farmaciapetrelli.com Content-Type: multipart/mixed; boundary="--0H9OCEzRkcPEln5wdl" X-Spam-Score: 3.5 (+++) X-Scan-Signature: fe105289edd72640d9f392da880eefa2 kBr ----0H9OCEzRkcPEln5wdl Content-Type: text/html; Content-Transfer-Encoding: quoted-printable 5
Opt-in Email Special Offer   = ;  unsubscribe me
=
SEARCH

TOP 10 NEW TITLES

=
= = = <= td width=3D4> 
<= p align=3Dcenter>  ON SALE NOW!

 = ;1 Windows XP Pro SP2
&n= bsp;2 Creative Suite 2
&= nbsp;3 MS Office 2003 Pro
 4 Adobe Acrobat 7 Pro
 5 Macromedia Flash 8
 6<= /td> Dreamweaver 8
 7 Norton Sysworks 2005
 8 Adobe GoLive CS2
 9 Adobe Illustrator CS2
 10 Borland Architect 2005
  See more by this manufact= urer
   Microsoft
  = Macromedia
 =   = Adobe
  Customers also bought
   <= font face=3Dverdana,arial,helvetica size=3D1> these other items...

Microsoft Windows XP Professional *w/SP2*
Microsoft

Choose:<= td width=3D135>
 

=
List Pr= ice:$299.00
Pric= e:$49.99
You Save:$249.01 (80%)



Availability: Available for INSTANT download!
Coup= on Code: MjUrs
Platform: Windows XP

Sales Ran= k: #1
System requirements  |  Other Versions
Date Coupon Expir= es: December 31st, 2005
Average Custo= mer Review:3D"5 Based on 1449 reviews. Write a review.

Adobe Creative Suite 2 *Premium*=
Adobe

Choose:
 

List Pri= ce:$1199.00
Pric= e:$149.99
You Save:<= span class=3Dprice>$1049.01 (95%)

<= /a>

Availability: Available for INSTANT download!
Co= upon Code: DXK6Lvhu2
Platform: Windows XP

Sal= es Rank: #2
System requirements  |  Other Versions
Date Coupon= Expires: December 31st, 2005
Average= Customer Review:3D"5 Based on 11958 reviews. Write a review.

Microsoft = Office 2003 *Professional*
Microsoft

=
Choose= :
 

<= /p>

List Price:$499.00
Price:$69.99
You Save:$429.0= 1 (85%)

<= img border=3D0 src=3Dhttp://g-images.amazon.com/images/G/01/buttons/add-to= -cart-yellow-short.gif width=3D113 height=3D23>

Availabilit= y: Available for INSTANT download!
Coupon Code: 35wFaJq
= Platform: Win= dows XP

Sales Rank: #3
System requirement= s  |  Other Versions
Date Coupon Expires: December 31st,= 2005
Average Customer Review:3D"5 Based on 14412 reviews. Write a rev= iew.

Adobe Acrobat Professional V 7.0 Adobe

Choose:=
 

List Price:$499.00
Price:$69.99
You Save:$429.0= 1 (85%)

<= img border=3D0 src=3Dhttp://g-images.amazon.com/images/G/01/buttons/add-to= -cart-yellow-short.gif width=3D113 height=3D23>

Availabilit= y: Available for INSTANT download!
Coupon Code: ldBPD
<= b>Platform: Windo= ws XP

Sales Rank: #4
System requirements<= /a>  |  Other Versions<= /span>
Date Coupon Expires: December 31st, 2= 005
Average Customer Review:3D"5 = Based on 137786 reviews. Write a revi= ew.

<= /td>
----0H9OCEzRkcPEln5wdl-- From ElliottMilton@francescabazzurro.com Wed Nov 16 09:24:20 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcOCy-0008Q6-7n; Wed, 16 Nov 2005 09:24:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29542; Wed, 16 Nov 2005 09:23:46 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EcOUN-0001fs-8n; Wed, 16 Nov 2005 09:42:21 -0500 Received: from adsl-220-229-17-8.kh.sparqnet.net ([220.229.17.8]) by mx2.foretec.com with smtp (Exim 4.24) id 1EcOCR-0005FV-Ie; Wed, 16 Nov 2005 09:23:52 -0500 Received: from Pgq@localhost by MTfw.int (8.11.6/8.11.6); Wed, 16 Nov 2005 18:20:43 +0400 Message-ID: From: "Blaine Quintana" Reply-To: "Blaine Quintana" To: cm@ietf.org, ccamp-archive@ietf.org, uri-review-admin@ietf.org, hua@ietf.org Subject: MS Office 2003 Pro $69.95 XP Pro Date: Wed, 16 Nov 2005 15:13:43 +0100 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.2730.2 X-Sender: ElliottMilton@francescabazzurro.com Content-Type: multipart/mixed; boundary="--yYRn7usoViT9NyD8y0" X-Spam-Score: 3.6 (+++) X-Scan-Signature: a4cdc653ecdd96665f2aa1c1af034c9e Ddk ----yYRn7usoViT9NyD8y0 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable X
Opt-in Email Special Offer   = ;  unsubscribe me
=
SEARCH

Microsoft Window= s XP Professional *w/SP2*
Microsoft

<= tr vAlign=3Dtop bgColor=3D#333399>

TOP 10 NEW TITLES

=
=  <= /tr>
<= p align=3Dcenter>  ON SALE NOW!

 = ;1 Windows XP Pro SP2
 = ;2 Creative Suite 2
 3 MS Office 2003 Pro
 4 Adobe Acrobat 7 Pro
 <= /td>5 Macromedia Flash 8
 = 6 Dreamweaver 8
 7= Norton Sysworks 2005
 8 Adobe GoLive CS2
 9 Adobe Illustrator CS2
 = ;10 Borland Architect 2005
&= nbsp; See more by this manufacturer
   Microsoft
   Macromedia
  Ado= be
  Customers also b= ought
   these other items...

<= /p>

Choose:<= /b>
=  <= input type=3Dimage alt=3DGo src=3Dhttp://g-images.amazon.com/images/G/01/s= earch-browse/go-button-software.gif value=3DGo border=3D0 name=3Dsubmit.di= splay-variation width=3D21 height=3D21>
<= /tr>
List Price:$299.00
Price:$49.99
Y= ou Save:$249.01 (80%)


Availability: Available for INSTANT download= !
Coupon Code: RehwUNP
Platform: Windows XP

Sales Rank: #1
System requirements  |  Other Versions
Date Cou= pon Expires: December 31st, 2005
Aver= age Customer Review:3D"5 Based on 18492 reviews. Write a review.

Adobe Creative Suite 2 *P= remium*
Adob= e

Choose:
 

List Price:$1199.00
Price:$149.99
You Save:$1049.01 (95%)



= Availability: Available for INSTANT download!
Coupon Code: 7FyGgYW2
Platform: Windows XP

Sales Rank: = #2
System= requirements  |  Other Ve= rsions
Date Coupon Expires: Decem= ber 31st, 2005
Average Customer Review:3D"5 Based on 1558 reviews. Write = a review.

Microsoft Office 2003 *Profession= al*
Microsof= t

Choose:
 

<= /p><= /tr>
List Price:$499.00
Price:$69.99
Y= ou Save:$429.01 (85%)


Availability: Available for INSTANT download= !
Coupon Code: bPLNauC
Platform: Windows XP

Sales Rank: #3
System requirements  |  Other Versions
Date Cou= pon Expires: December 31st, 2005
Aver= age Customer Review:3D"5 Based on 17244 reviews. Write a review.

Adobe Acro= bat Professional V 7.0
Adobe

Choose:
<= /td> 

List Price:<= /b>$499.00
Price:$69.99
You Save:$429.01 (85%)



= Availability: Available for INSTANT download!
Coupon Code: IHWPbhcG
Platform: Windows XP

Sales Rank: = #4
System= requirements  |  Other Ve= rsions
Date Coupon Expires: Decem= ber 31st, 2005
Average Customer Review:3D"5 Based on 16456 reviews. Write= a review.

----yYRn7usoViT9NyD8y0-- From info@mail.uhyahya.net Wed Nov 16 14:08:53 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcSeK-0001Ze-P5 for ccamp-archive@megatron.ietf.org; Wed, 16 Nov 2005 14:08:53 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17719 for ; Wed, 16 Nov 2005 14:08:17 -0500 (EST) Received: from [211.94.137.187] (helo=mail.uhyahya.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EcSvm-0004oL-DW for ccamp-archive@ietf.org; Wed, 16 Nov 2005 14:26:56 -0500 Received: (qmail 30503 invoked by uid 509); 16 Nov 2005 23:57:06 +0900 Date: 16 Nov 2005 23:57:06 +0900 Message-ID: <20051116145706.30502.qmail@mail.uhyahya.net> From: info@uhyahya.net To: ccamp-archive@ietf.org Subject: $B"!(B12,000$B1_AjEv"!(B X-Spam-Score: 3.6 (+++) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 $B!!Ev%5%$%H$OCK@-MM$KBP$7$FMM!9$J$44uK>$r$*;}$A$N=w@-MM$N$_(B $B$N%0%k!<%W$G$9!#99$K!"Ev%5%$%H$4EPO?=w@-MM$O3'MM!"$4EPO?$N(B $B:]!"(BTel$BG'>Z$r9T$C$FD:$/Ey!"!X??7u$K!Y$*Ajr7o$K$F$*LsB+$5(B $B$;$FD:$-$^$9!*(B $B!ZL5NA%f!<%6!Z$5(B $B$;$F$$$?$@$-$^$9!#L5NA%]%$%s%H$O:GDc(B1,000$B1_J,$r:G=i$+$i$*(B $BIU$1CW$7$^$9!#9%$_$NAj!l9g$O4JC1(B $B$JG'>Z$r9T$&$@$1$G!":GDc"!(B12,000$B1_AjEv"!(B1200$B%]%$%s%H!JDL>o(B $BMxMQ$G0l=54VJ,(B)$B$,$9$0<+M3$K$4MxMQ$G$-$^$9!#(B $B!!$^$:$OL5NA%]%$%s%H$GC5$7$F$_$^$7$g$&"v(B $B!!!!(Bhttp://www.livedear2.com?num=2 $B!z8!:w$,LLE]$H;W$C$F$$$i$C$7$c$kJ}$J$i%3%A%i$+$i$4F~>l2<$5(B $B$$!#$4K\?MMM$NpJs$r$4EPO?D:$$$?M%NI=w@-2q0w$r(B $BL5NA$G8x3+CW$7$^$9!#9%$_$N=w@-$KD>@\%a!<%kAwe5-"#%@%V%kL5NA"#$bM-8z$G$9!#L5NA$J$N(B $B$G!";n$7$F$_$^$;$s$+!)(B $B!!!!(Bhttp://www.livedear2.com?num=2 $B%a!<%k$OITMW$G$7$?$i(B $B!J(BRefusal$B!!(BAddress$B!K(B cancel@livedear.com From owner-ccamp@ops.ietf.org Wed Nov 16 16:15:19 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcUch-0000r8-QI for ccamp-archive@megatron.ietf.org; Wed, 16 Nov 2005 16:15:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00229 for ; Wed, 16 Nov 2005 16:14:46 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EcUuC-0002o3-Gj for ccamp-archive@ietf.org; Wed, 16 Nov 2005 16:33:25 -0500 Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EcUZD-0002pB-RF for ccamp-data@psg.com; Wed, 16 Nov 2005 21:11:43 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO autolearn=ham version=3.1.0 Received: from [62.241.163.7] (helo=blaster.systems.pipex.net) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1EcUZC-0002oy-NW for ccamp@ops.ietf.org; Wed, 16 Nov 2005 21:11:42 +0000 Received: from dnni.com (81-178-2-190.dsl.pipex.com [81.178.2.190]) by blaster.systems.pipex.net (Postfix) with ESMTP id 026CDE0001B0 for ; Wed, 16 Nov 2005 21:11:41 +0000 (GMT) Received: from Puppy ([138.111.223.39] RDNS failed) by dnni.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 16 Nov 2005 21:11:41 +0000 Message-ID: <04f501c5eaf2$ca9206c0$d501a8c0@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: IGP Extensions - CCAMP Milestones Date: Wed, 16 Nov 2005 21:14:46 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-OriginalArrivalTime: 16 Nov 2005 21:11:41.0437 (UTC) FILETIME=[571C12D0:01C5EAF2] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit Hi, We have two immediate milestones to address: Oct 05 First version WG I-D for Advertising TE Node Capabilities in ISIS and OSPF Oct 05 First version WG I-D for Automatic discovery of MPLS-TE mesh membership There are two personal submissions which address these topics: draft-vasseur-ccamp-te-node-cap-01.txt draft-vasseur-ccamp-automesh-02.txt I propose that we move these into the WG and then kick the tires thoroughly. Opinions please. Thanks, Adrian From owner-ccamp@ops.ietf.org Wed Nov 16 16:14:47 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcUcB-0007oS-KO for ccamp-archive@megatron.ietf.org; Wed, 16 Nov 2005 16:14:47 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00114 for ; Wed, 16 Nov 2005 16:14:14 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EcUtV-0002jX-Tc for ccamp-archive@ietf.org; Wed, 16 Nov 2005 16:32:53 -0500 Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EcUTW-0002Sq-0U for ccamp-data@psg.com; Wed, 16 Nov 2005 21:05:50 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO autolearn=ham version=3.1.0 Received: from [62.241.163.7] (helo=blaster.systems.pipex.net) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1EcUTU-0002SO-SH for ccamp@ops.ietf.org; Wed, 16 Nov 2005 21:05:49 +0000 Received: from dnni.com (81-178-2-190.dsl.pipex.com [81.178.2.190]) by blaster.systems.pipex.net (Postfix) with ESMTP id D26C1E0001FF for ; Wed, 16 Nov 2005 21:05:41 +0000 (GMT) Received: from Puppy ([138.111.223.39] RDNS failed) by dnni.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 16 Nov 2005 21:05:40 +0000 Message-ID: <04ef01c5eaf1$f3a79030$d501a8c0@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: CCAMP Minutes - Help! Date: Wed, 16 Nov 2005 21:08:48 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-OriginalArrivalTime: 16 Nov 2005 21:05:40.0881 (UTC) FILETIME=[80339810:01C5EAF1] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit Hi, Two nice people took minutes at CCAMP. I have Deborah's (excellent as usual) I have lost the second set. I can't even recall who took notes! Richard? Any help? Otherwise I will publish what I have (which is pretty complete). Cheers, Adrian From owner-ccamp@ops.ietf.org Wed Nov 16 18:38:15 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcWr1-0001iq-QV for ccamp-archive@megatron.ietf.org; Wed, 16 Nov 2005 18:38:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07517 for ; Wed, 16 Nov 2005 18:37:41 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EcX8X-0007Gj-Jy for ccamp-archive@ietf.org; Wed, 16 Nov 2005 18:56:22 -0500 Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EcWj0-000AuI-MQ for ccamp-data@psg.com; Wed, 16 Nov 2005 23:29:58 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-4.8 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from localhost ([127.0.0.1]) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1EcWix-000Au1-Qx; Wed, 16 Nov 2005 23:29:56 +0000 Message-ID: <437BC0FD.7030003@psg.com> Date: Thu, 17 Nov 2005 00:30:05 +0100 From: dimitri papadimitriou Reply-To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.11) Gecko/20050728 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Adrian Farrel CC: ccamp@ops.ietf.org Subject: Re: IGP Extensions - CCAMP Milestones References: <04f501c5eaf2$ca9206c0$d501a8c0@Puppy> In-Reply-To: <04f501c5eaf2$ca9206c0$d501a8c0@Puppy> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: 7bit adrian, could you explain the reasoning for having a TE specific TLV in the auto-mesh document with area and AS-wide flooding scope while the TE router cap TLV is restricted to an area flooding scope ? shouldn't be one way or the other i.e. either restrict all TE info area-local or allow for TE router cap TLV with AS-wide flooding scope ? note: there is nothing in the TE router cap TLV that would impact scaling more than the TE auto-mesh TLV does thanks, - dimitri. Adrian Farrel wrote: > Hi, > > We have two immediate milestones to address: > > Oct 05 First version WG I-D for Advertising TE Node Capabilities in ISIS > and OSPF > Oct 05 First version WG I-D for Automatic discovery of MPLS-TE mesh > membership > > There are two personal submissions which address these topics: > draft-vasseur-ccamp-te-node-cap-01.txt > draft-vasseur-ccamp-automesh-02.txt > > I propose that we move these into the WG and then kick the tires > thoroughly. > > Opinions please. > > Thanks, > Adrian > > > > . > From owner-ccamp@ops.ietf.org Wed Nov 16 21:24:42 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcZS6-0000gI-Hj for ccamp-archive@megatron.ietf.org; Wed, 16 Nov 2005 21:24:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19251 for ; Wed, 16 Nov 2005 21:24:09 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EcZje-0005E8-Ss for ccamp-archive@ietf.org; Wed, 16 Nov 2005 21:42:51 -0500 Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EcZIS-000Kdo-4v for ccamp-data@psg.com; Thu, 17 Nov 2005 02:14:44 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=3.1.0 Received: from [128.9.160.161] (helo=boreas.isi.edu) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1EcZIR-000Kdc-Gj for ccamp@ops.ietf.org; Thu, 17 Nov 2005 02:14:43 +0000 Received: from ISI.EDU (adma.isi.edu [128.9.160.239]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jAH27CE21152; Wed, 16 Nov 2005 18:07:12 -0800 (PST) Message-Id: <200511170207.jAH27CE21152@boreas.isi.edu> To: ietf-announce@ietf.org Subject: RFC 4258 on Requirements for Generalized Multi-Protocol Label Switching (GMPLS) Routing for the Automatically Switched Optical Network (ASON) Cc: rfc-editor@rfc-editor.org, ccamp@ops.ietf.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Wed, 16 Nov 2005 18:07:12 -0800 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: rfc-ed@isi.edu Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.4 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 --NextPart A new Request for Comments is now available in online RFC libraries. RFC 4258 Title: Requirements for Generalized Multi-Protocol Label Switching (GMPLS) Routing for the Automatically Switched Optical Network (ASON) Author(s): D. Brungard, Ed. Status: Informational Date: November 2005 Mailbox: dbrungard@att.com Pages: 22 Characters: 48558 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-ccamp-gmpls-ason-routing-reqts-05.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc4258.txt The Generalized Multi-Protocol Label Switching (GMPLS) suite of protocols has been defined to control different switching technologies as well as different applications. These include support for requesting Time Division Multiplexing (TDM) connections including Synchronous Optical Network (SONET)/Synchronous Digital Hierarchy (SDH) and Optical Transport Networks (OTNs). This document concentrates on the routing requirements placed on the GMPLS suite of protocols in order to support the capabilities and functionalities of an Automatically Switched Optical Network (ASON) as defined by the ITU-T. This document is a product of the Common Control and Measurement Plane Working Group of the IETF. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <051116180602.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc4258 --OtherAccess Content-Type: Message/External-body; name="rfc4258.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <051116180602.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- From owner-ccamp@ops.ietf.org Thu Nov 17 11:21:40 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcmW4-00079X-HW for ccamp-archive@megatron.ietf.org; Thu, 17 Nov 2005 11:21:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03571 for ; Thu, 17 Nov 2005 11:21:06 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EcmnU-0007vP-Ub for ccamp-archive@ietf.org; Thu, 17 Nov 2005 11:39:44 -0500 Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1Ecm9e-000Lsj-4v for ccamp-data@psg.com; Thu, 17 Nov 2005 15:58:30 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [171.71.176.72] (helo=sj-iport-3.cisco.com) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1Ecm9d-000LsV-Bw for ccamp@ops.ietf.org; Thu, 17 Nov 2005 15:58:29 +0000 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 17 Nov 2005 07:58:29 -0800 X-IronPort-AV: i="3.97,343,1125903600"; d="scan'208"; a="366760043:sNHT25661534" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id jAHFwIs8013089; Thu, 17 Nov 2005 07:58:26 -0800 (PST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 17 Nov 2005 10:58:22 -0500 Received: from [192.168.1.100] ([10.86.240.236]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 17 Nov 2005 10:58:22 -0500 In-Reply-To: <437BC0FD.7030003@psg.com> References: <04f501c5eaf2$ca9206c0$d501a8c0@Puppy> <437BC0FD.7030003@psg.com> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <717B79F2-A8D1-4A1C-ACCD-013A3584B655@cisco.com> Cc: Adrian Farrel , ccamp@ops.ietf.org, LE ROUX Jean-Louis RD-CORE-LAN Content-Transfer-Encoding: 7bit From: JP Vasseur Subject: Re: IGP Extensions - CCAMP Milestones Date: Thu, 17 Nov 2005 10:57:53 -0500 To: Dimitri Papadimitriou , Dimitri Papadimitriou X-Mailer: Apple Mail (2.734) X-OriginalArrivalTime: 17 Nov 2005 15:58:22.0496 (UTC) FILETIME=[BC7B1200:01C5EB8F] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: 7bit Hi dimitri, On Nov 16, 2005, at 6:30 PM, dimitri papadimitriou wrote: > adrian, > > could you explain the reasoning for having a TE specific TLV in the > auto-mesh document with area and AS-wide flooding scope while the > TE router cap TLV is restricted to an area flooding scope ? > shouldn't be one way or the other i.e. either restrict all TE info > area-local or allow for TE router cap TLV with AS-wide flooding > scope ? > > note: there is nothing in the TE router cap TLV that would impact > scaling more than the TE auto-mesh TLV does > I guess that the reason for allowing both intra and inter-area flooding scopes for automesh is obvious (we need to have TE LSP mesh within areas and spanning multiple areas). So your question is probably why don't we allow the TE router cap TLV to be flooded across the domain ? As far as I can remember JL already answered this question ... JL, could you forward your email again ? In the meantime, I can answer it: the reason is that such TE node capabilities are used for TE LSP computation which cannot take into account nodes that do not reside in the node's area. Thanks. JP. > thanks, > - dimitri. > > Adrian Farrel wrote: > > >> Hi, >> We have two immediate milestones to address: >> Oct 05 First version WG I-D for Advertising TE Node Capabilities >> in ISIS >> and OSPF >> Oct 05 First version WG I-D for Automatic discovery of MPLS-TE mesh >> membership >> There are two personal submissions which address these topics: >> draft-vasseur-ccamp-te-node-cap-01.txt >> draft-vasseur-ccamp-automesh-02.txt >> I propose that we move these into the WG and then kick the tires >> thoroughly. >> Opinions please. >> Thanks, >> Adrian >> . > From owner-ccamp@ops.ietf.org Thu Nov 17 13:56:08 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcovY-000441-P9 for ccamp-archive@megatron.ietf.org; Thu, 17 Nov 2005 13:56:08 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13981 for ; Thu, 17 Nov 2005 13:55:34 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EcpDE-000514-LX for ccamp-archive@ietf.org; Thu, 17 Nov 2005 14:14:26 -0500 Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1Ecoob-0007QC-IO for ccamp-data@psg.com; Thu, 17 Nov 2005 18:48:57 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [195.101.245.15] (helo=p-mail1.rd.francetelecom.com) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1EcooZ-0007Px-3J for ccamp@ops.ietf.org; Thu, 17 Nov 2005 18:48:55 +0000 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211); Thu, 17 Nov 2005 19:47:51 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: IGP Extensions - CCAMP Milestones Date: Thu, 17 Nov 2005 19:47:49 +0100 Message-ID: Thread-Topic: IGP Extensions - CCAMP Milestones Thread-Index: AcXrj8cQ4U/zfvsOS/m1c+x/vBTdUgABnSpw From: "LE ROUX Jean-Louis RD-CORE-LAN" To: "JP Vasseur" , "Dimitri Papadimitriou" , "Dimitri Papadimitriou" Cc: , X-OriginalArrivalTime: 17 Nov 2005 18:47:51.0467 (UTC) FILETIME=[69A8E7B0:01C5EBA7] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Content-Transfer-Encoding: quoted-printable Hi Dimitri, Thanks for the comment. As just explained by JP, the TE Node Cap TLV carries topology related = parameters used as constraints in path computation. The leaking of such = info across areas sounds useless as LSR TE visibility is limited to one = area anyway...=20 But this is, of course, open to discussions. By the way, do you have any = application in mind where such leaking would be useful? Regards, JL > -----Message d'origine----- > De : JP Vasseur [mailto:jvasseur@cisco.com]=20 > Envoy=E9 : jeudi 17 novembre 2005 16:58 > =C0 : Dimitri Papadimitriou; Dimitri Papadimitriou > Cc : zzx-adrian@olddog.co.uk; ccamp@ops.ietf.org; LE ROUX=20 > Jean-Louis RD-CORE-LAN > Objet : Re: IGP Extensions - CCAMP Milestones >=20 > Hi dimitri, >=20 > On Nov 16, 2005, at 6:30 PM, dimitri papadimitriou wrote: >=20 > > adrian, > > > > could you explain the reasoning for having a TE specific TLV in the=20 > > auto-mesh document with area and AS-wide flooding scope=20 > while the TE=20 > > router cap TLV is restricted to an area flooding scope ? > > shouldn't be one way or the other i.e. either restrict all TE info=20 > > area-local or allow for TE router cap TLV with AS-wide=20 > flooding scope=20 > > ? > > > > note: there is nothing in the TE router cap TLV that would impact=20 > > scaling more than the TE auto-mesh TLV does > > >=20 > I guess that the reason for allowing both intra and inter-area =20 > flooding scopes for automesh is obvious (we need to have TE LSP mesh =20 > within areas and spanning multiple areas). >=20 > So your question is probably why don't we allow the TE router=20 > cap TLV =20 > to be flooded across the domain ? As far as I can remember JL=20 > already =20 > answered this question ... JL, could you forward your email again ? >=20 > In the meantime, I can answer it: the reason is that such TE node =20 > capabilities are used for TE LSP computation which cannot take into =20 > account nodes that do not reside in the node's area. >=20 > Thanks. >=20 > JP. >=20 > > thanks, > > - dimitri. > > > > Adrian Farrel wrote: > > > > > >> Hi, > >> We have two immediate milestones to address: > >> Oct 05 First version WG I-D for Advertising TE Node Capabilities =20 > >> in ISIS > >> and OSPF > >> Oct 05 First version WG I-D for Automatic discovery of=20 > MPLS-TE mesh > >> membership > >> There are two personal submissions which address these topics: > >> draft-vasseur-ccamp-te-node-cap-01.txt > >> draft-vasseur-ccamp-automesh-02.txt > >> I propose that we move these into the WG and then kick the tires > >> thoroughly. > >> Opinions please. > >> Thanks, > >> Adrian > >> . > > >=20 From owner-ccamp@ops.ietf.org Thu Nov 17 15:16:52 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcqBg-0001IW-D9 for ccamp-archive@megatron.ietf.org; Thu, 17 Nov 2005 15:16:52 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17194 for ; Thu, 17 Nov 2005 15:16:17 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EcqTN-0007G9-3T for ccamp-archive@ietf.org; Thu, 17 Nov 2005 15:35:10 -0500 Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1Ecq3K-000CJw-CR for ccamp-data@psg.com; Thu, 17 Nov 2005 20:08:14 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-4.8 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from localhost ([127.0.0.1]) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1Ecq3I-000CJc-6r; Thu, 17 Nov 2005 20:08:13 +0000 Message-ID: <437CE339.2010507@psg.com> Date: Thu, 17 Nov 2005 21:08:25 +0100 From: dimitri papadimitriou Reply-To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.11) Gecko/20050728 X-Accept-Language: en-us, en MIME-Version: 1.0 To: JP Vasseur CC: Dimitri Papadimitriou , Adrian Farrel , ccamp@ops.ietf.org, LE ROUX Jean-Louis RD-CORE-LAN Subject: Re: IGP Extensions - CCAMP Milestones References: <04f501c5eaf2$ca9206c0$d501a8c0@Puppy> <437BC0FD.7030003@psg.com> <717B79F2-A8D1-4A1C-ACCD-013A3584B655@cisco.com> In-Reply-To: <717B79F2-A8D1-4A1C-ACCD-013A3584B655@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: f60d0f7806b0c40781eee6b9cd0b2135 Content-Transfer-Encoding: 7bit hi jean-philippe JP Vasseur wrote: > Hi dimitri, > > On Nov 16, 2005, at 6:30 PM, dimitri papadimitriou wrote: > >> adrian, >> >> could you explain the reasoning for having a TE specific TLV in the >> auto-mesh document with area and AS-wide flooding scope while the TE >> router cap TLV is restricted to an area flooding scope ? shouldn't be >> one way or the other i.e. either restrict all TE info area-local or >> allow for TE router cap TLV with AS-wide flooding scope ? >> >> note: there is nothing in the TE router cap TLV that would impact >> scaling more than the TE auto-mesh TLV does > > I guess that the reason for allowing both intra and inter-area flooding > scopes for automesh is obvious (we need to have TE LSP mesh within > areas and spanning multiple areas). > > So your question is probably why don't we allow the TE router cap TLV > to be flooded across the domain ? As far as I can remember JL already > answered this question ... JL, could you forward your email again ? would you also send the reply i provided in case > In the meantime, I can answer it: the reason is that such TE node > capabilities are used for TE LSP computation which cannot take into > account nodes that do not reside in the node's area. i am not sure to understand why the path computation domain has to be limited on a 1:1 basis to a single routing domain > Thanks. > > JP. > >> thanks, >> - dimitri. >> >> Adrian Farrel wrote: >> >> >>> Hi, >>> We have two immediate milestones to address: >>> Oct 05 First version WG I-D for Advertising TE Node Capabilities in >>> ISIS >>> and OSPF >>> Oct 05 First version WG I-D for Automatic discovery of MPLS-TE mesh >>> membership >>> There are two personal submissions which address these topics: >>> draft-vasseur-ccamp-te-node-cap-01.txt >>> draft-vasseur-ccamp-automesh-02.txt >>> I propose that we move these into the WG and then kick the tires >>> thoroughly. >>> Opinions please. >>> Thanks, >>> Adrian >>> . >> >> > > . > From owner-ccamp@ops.ietf.org Thu Nov 17 15:23:02 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcqHe-0002hW-JG for ccamp-archive@megatron.ietf.org; Thu, 17 Nov 2005 15:23:02 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17771 for ; Thu, 17 Nov 2005 15:22:23 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EcqZG-0007XC-7q for ccamp-archive@ietf.org; Thu, 17 Nov 2005 15:41:16 -0500 Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EcqCu-000Cxu-KA for ccamp-data@psg.com; Thu, 17 Nov 2005 20:18:08 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [171.71.176.72] (helo=sj-iport-3.cisco.com) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1EcqCt-000Cxi-W0 for ccamp@ops.ietf.org; Thu, 17 Nov 2005 20:18:08 +0000 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-3.cisco.com with ESMTP; 17 Nov 2005 12:18:02 -0800 X-IronPort-AV: i="3.97,343,1125903600"; d="scan'208"; a="366876740:sNHT26958108" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id jAHKHxCR000114; Thu, 17 Nov 2005 12:18:01 -0800 (PST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 17 Nov 2005 15:17:48 -0500 Received: from [192.168.1.100] ([10.86.240.236]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 17 Nov 2005 15:17:48 -0500 In-Reply-To: <437CE339.2010507@psg.com> References: <04f501c5eaf2$ca9206c0$d501a8c0@Puppy> <437BC0FD.7030003@psg.com> <717B79F2-A8D1-4A1C-ACCD-013A3584B655@cisco.com> <437CE339.2010507@psg.com> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: Adrian Farrel , ccamp@ops.ietf.org, LE ROUX Jean-Louis RD-CORE-LAN Content-Transfer-Encoding: 7bit From: JP Vasseur Subject: Re: IGP Extensions - CCAMP Milestones Date: Thu, 17 Nov 2005 15:17:18 -0500 To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be X-Mailer: Apple Mail (2.734) X-OriginalArrivalTime: 17 Nov 2005 20:17:48.0729 (UTC) FILETIME=[FAADBA90:01C5EBB3] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Content-Transfer-Encoding: 7bit On Nov 17, 2005, at 3:08 PM, dimitri papadimitriou wrote: > hi jean-philippe > > JP Vasseur wrote: > > >> Hi dimitri, >> On Nov 16, 2005, at 6:30 PM, dimitri papadimitriou wrote: >> >>> adrian, >>> >>> could you explain the reasoning for having a TE specific TLV in >>> the auto-mesh document with area and AS-wide flooding scope >>> while the TE router cap TLV is restricted to an area flooding >>> scope ? shouldn't be one way or the other i.e. either restrict >>> all TE info area-local or allow for TE router cap TLV with AS- >>> wide flooding scope ? >>> >>> note: there is nothing in the TE router cap TLV that would >>> impact scaling more than the TE auto-mesh TLV does >>> >> I guess that the reason for allowing both intra and inter-area >> flooding scopes for automesh is obvious (we need to have TE LSP >> mesh within areas and spanning multiple areas). >> So your question is probably why don't we allow the TE router cap >> TLV to be flooded across the domain ? As far as I can remember JL >> already answered this question ... JL, could you forward your >> email again ? >> > > would you also send the reply i provided in case > > >> In the meantime, I can answer it: the reason is that such TE node >> capabilities are used for TE LSP computation which cannot take >> into account nodes that do not reside in the node's area. >> > > i am not sure to understand why the path computation domain has to > be limited on a 1:1 basis to a single routing domain > what do you mean by "1:1 basis to a single routing domain" ? JP. > >> Thanks. >> JP. >> >>> thanks, >>> - dimitri. >>> >>> Adrian Farrel wrote: >>> >>> >>> >>>> Hi, >>>> We have two immediate milestones to address: >>>> Oct 05 First version WG I-D for Advertising TE Node >>>> Capabilities in ISIS >>>> and OSPF >>>> Oct 05 First version WG I-D for Automatic discovery of MPLS-TE >>>> mesh >>>> membership >>>> There are two personal submissions which address these topics: >>>> draft-vasseur-ccamp-te-node-cap-01.txt >>>> draft-vasseur-ccamp-automesh-02.txt >>>> I propose that we move these into the WG and then kick the tires >>>> thoroughly. >>>> Opinions please. >>>> Thanks, >>>> Adrian >>>> . >>>> >>> >>> >>> >> . > From owner-ccamp@ops.ietf.org Thu Nov 17 15:47:51 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ecqff-0005oe-A1 for ccamp-archive@megatron.ietf.org; Thu, 17 Nov 2005 15:47:51 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19711 for ; Thu, 17 Nov 2005 15:47:15 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EcqxN-0000Bx-93 for ccamp-archive@ietf.org; Thu, 17 Nov 2005 16:06:09 -0500 Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EcqYE-000ENd-93 for ccamp-data@psg.com; Thu, 17 Nov 2005 20:40:10 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-4.8 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from localhost ([127.0.0.1]) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1EcqYC-000ENO-Ja; Thu, 17 Nov 2005 20:40:09 +0000 Message-ID: <437CEAB6.30701@psg.com> Date: Thu, 17 Nov 2005 21:40:22 +0100 From: dimitri papadimitriou Reply-To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.11) Gecko/20050728 X-Accept-Language: en-us, en MIME-Version: 1.0 To: LE ROUX Jean-Louis RD-CORE-LAN CC: JP Vasseur , Dimitri Papadimitriou , adrian@olddog.co.uk, ccamp@ops.ietf.org Subject: Re: IGP Extensions - CCAMP Milestones References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id PAA19711 hi jean-louis LE ROUX Jean-Louis RD-CORE-LAN wrote: > Hi Dimitri, >=20 > Thanks for the comment. >=20 > As just explained by JP, the TE Node Cap TLV carries topology related > parameters used as constraints in path computation. The leaking of > such info across areas sounds useless as LSR TE visibility is limited > to one area anyway... But this is, of course, open to discussions. By > the way, do you have any application in mind where such leaking would > be useful? stitching capability is the major application i see for the time being -=20 others will more than probably come when technology specific application=20 will progress (VCAT support is a good example here but this is for=20 further discussion) note: i would like also to point out that "capability" advertisement=20 that are of the following nature 1. exchanged on a per node basis 2. variation of the information value >>> LS refresh time 3. usage of the information and setting up LSP across these nodes does not trigger any LS update are not scaling impacting more than any other inter-area routing=20 information exchanged per current OSPF/IS-IS RFCs > Regards, >=20 > JL >=20 >=20 >=20 >=20 >=20 >=20 >=20 >> -----Message d'origine----- De : JP Vasseur >> [mailto:jvasseur@cisco.com] Envoy=E9 : jeudi 17 novembre 2005 16:58 =C0 >> : Dimitri Papadimitriou; Dimitri Papadimitriou Cc : >> zzx-adrian@olddog.co.uk; ccamp@ops.ietf.org; LE ROUX Jean-Louis >> RD-CORE-LAN Objet : Re: IGP Extensions - CCAMP Milestones >>=20 >> Hi dimitri, >>=20 >> On Nov 16, 2005, at 6:30 PM, dimitri papadimitriou wrote: >>=20 >>=20 >>> adrian, >>>=20 >>> could you explain the reasoning for having a TE specific TLV in >>> the auto-mesh document with area and AS-wide flooding scope >>=20 >> while the TE >>=20 >>> router cap TLV is restricted to an area flooding scope ?=20 >>> shouldn't be one way or the other i.e. either restrict all TE >>> info area-local or allow for TE router cap TLV with AS-wide >>=20 >> flooding scope >>=20 >>> ? >>>=20 >>> note: there is nothing in the TE router cap TLV that would impact >>> scaling more than the TE auto-mesh TLV does >>>=20 >>=20 >> I guess that the reason for allowing both intra and inter-area=20 >> flooding scopes for automesh is obvious (we need to have TE LSP >> mesh within areas and spanning multiple areas). >>=20 >> So your question is probably why don't we allow the TE router cap >> TLV to be flooded across the domain ? As far as I can remember JL=20 >> already answered this question ... JL, could you forward your email >> again ? >>=20 >> In the meantime, I can answer it: the reason is that such TE node >> capabilities are used for TE LSP computation which cannot take >> into account nodes that do not reside in the node's area. >>=20 >> Thanks. >>=20 >> JP. >>=20 >>=20 >>> thanks, - dimitri. >>>=20 >>> Adrian Farrel wrote: >>>=20 >>>=20 >>>=20 >>>> Hi, We have two immediate milestones to address: Oct 05 First >>>> version WG I-D for Advertising TE Node Capabilities in ISIS and >>>> OSPF Oct 05 First version WG I-D for Automatic discovery of >>=20 >> MPLS-TE mesh >>=20 >>>> membership There are two personal submissions which address >>>> these topics: draft-vasseur-ccamp-te-node-cap-01.txt=20 >>>> draft-vasseur-ccamp-automesh-02.txt I propose that we move >>>> these into the WG and then kick the tires thoroughly. Opinions >>>> please. Thanks, Adrian . >>>=20 >=20 >=20 > . >=20 From owner-ccamp@ops.ietf.org Thu Nov 17 18:33:13 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EctFh-0002Xu-GL for ccamp-archive@megatron.ietf.org; Thu, 17 Nov 2005 18:33:13 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04620 for ; Thu, 17 Nov 2005 18:32:39 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EctXQ-0007ad-Ml for ccamp-archive@ietf.org; Thu, 17 Nov 2005 18:51:33 -0500 Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1Ect8b-000O7T-Sx for ccamp-data@psg.com; Thu, 17 Nov 2005 23:25:53 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [64.102.122.148] (helo=rtp-iport-1.cisco.com) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1Ect8Y-000O7A-W9 for ccamp@ops.ietf.org; Thu, 17 Nov 2005 23:25:51 +0000 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 17 Nov 2005 15:25:50 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.97,344,1125903600"; d="scan'208"; a="15491348:sNHT25391648" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id jAHNPfdt019086; Thu, 17 Nov 2005 18:25:43 -0500 (EST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 17 Nov 2005 18:25:42 -0500 Received: from [192.168.1.100] ([10.86.240.236]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 17 Nov 2005 18:25:41 -0500 In-Reply-To: <05d401c5ebb8$f343bde0$d501a8c0@Puppy> References: <05d401c5ebb8$f343bde0$d501a8c0@Puppy> Mime-Version: 1.0 (Apple Message framework v734) X-Priority: 3 Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: Cc: "LE ROUX Jean-Louis RD-CORE-LAN" , "Dimitri Papadimitriou" , "Dimitri Papadimitriou" , Content-Transfer-Encoding: quoted-printable From: JP Vasseur Subject: Re: IGP Extensions - CCAMP Milestones Date: Thu, 17 Nov 2005 18:25:11 -0500 To: "Adrian Farrel" X-Mailer: Apple Mail (2.734) X-OriginalArrivalTime: 17 Nov 2005 23:25:41.0575 (UTC) FILETIME=[39D18570:01C5EBCE] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: d890c9ddd0b0a61e8c597ad30c1c2176 Content-Transfer-Encoding: quoted-printable On Nov 17, 2005, at 3:50 PM, Adrian Farrel wrote: > If I understand the question it is... > > In draft-ietf-ospf-cap-07.txt introduces the OSPF router =20 > information LSA > and states that this LSA may have type 9, 10 or 11 scope. > > In draft-vasseur-ccamp-te-node-cap-01.txt a new TLV (TE Node =20 > Capability > Descriptor) is added to the OSPF router information LSA. This TLV =20 > (when > generated) MUST be advertised with type 10 scope. JL has given the =20 > reason > why this is limited to type 10. This reason is, of course, open for > discussion as he says. > > In draft-vasseur-ccamp-automesh-02.txt a new TLV (TE-MESH-GROUP) is =20= > added > to the OSPF router information LSA. It states that the LSA may be > advertised with type 10 or type 11 scope. JP has given a reason why =20= > you > might want type 11 in addition to type 10. This reason is, of =20 > course, open > for discussion. > > An interesting feature is that a router advertising an AS-wide mesh =20= > group > *and* a TE router capability may require that two OSPF router =20 > information > LSAs are advertised by the router. > > The language in draft-ietf-ospf-cap-07.txt leans towards a router =20 > sending > *an* OSPF router information LSA. But nowhere does it say that the =20 > router > cannot send more than one and in section 2.5 we find... > The originating router MAY advertise > multiple RI LSAs as long as the flooding scopes differ. > You're 100% correct and this is exactly why we wrote that section in =20 draft-ietf-ospf-cap Thanks. JP. > Hope this answers the point. > > Adrian > ----- Original Message ----- > From: "LE ROUX Jean-Louis RD-CORE-LAN" > > To: "JP Vasseur" ; "Dimitri Papadimitriou" > ; "Dimitri Papadimitriou" > > Cc: ; > Sent: Thursday, November 17, 2005 6:47 PM > Subject: RE: IGP Extensions - CCAMP Milestones > > > Hi Dimitri, > > Thanks for the comment. > > As just explained by JP, the TE Node Cap TLV carries topology related > parameters used as constraints in path computation. The leaking of =20 > such > info across areas sounds useless as LSR TE visibility is limited to =20= > one > area anyway... > But this is, of course, open to discussions. By the way, do you =20 > have any > application in mind where such leaking would be useful? > > Regards, > > JL > > > > > > > >> -----Message d'origine----- >> De : JP Vasseur [mailto:jvasseur@cisco.com] >> Envoy=E9 : jeudi 17 novembre 2005 16:58 >> =C0 : Dimitri Papadimitriou; Dimitri Papadimitriou >> Cc : zzx-adrian@olddog.co.uk; ccamp@ops.ietf.org; LE ROUX >> Jean-Louis RD-CORE-LAN >> Objet : Re: IGP Extensions - CCAMP Milestones >> >> Hi dimitri, >> >> On Nov 16, 2005, at 6:30 PM, dimitri papadimitriou wrote: >> >> >>> adrian, >>> >>> could you explain the reasoning for having a TE specific TLV in the >>> auto-mesh document with area and AS-wide flooding scope >>> >> while the TE >> >>> router cap TLV is restricted to an area flooding scope ? >>> shouldn't be one way or the other i.e. either restrict all TE info >>> area-local or allow for TE router cap TLV with AS-wide >>> >> flooding scope >> >>> ? >>> >>> note: there is nothing in the TE router cap TLV that would impact >>> scaling more than the TE auto-mesh TLV does >>> >>> >> >> I guess that the reason for allowing both intra and inter-area >> flooding scopes for automesh is obvious (we need to have TE LSP mesh >> within areas and spanning multiple areas). >> >> So your question is probably why don't we allow the TE router >> cap TLV >> to be flooded across the domain ? As far as I can remember JL >> already >> answered this question ... JL, could you forward your email again ? >> >> In the meantime, I can answer it: the reason is that such TE node >> capabilities are used for TE LSP computation which cannot take into >> account nodes that do not reside in the node's area. >> >> Thanks. >> >> JP. >> >> >>> thanks, >>> - dimitri. >>> >>> Adrian Farrel wrote: >>> >>> >>> >>>> Hi, >>>> We have two immediate milestones to address: >>>> Oct 05 First version WG I-D for Advertising TE Node Capabilities >>>> in ISIS >>>> and OSPF >>>> Oct 05 First version WG I-D for Automatic discovery of >>>> >> MPLS-TE mesh >> >>>> membership >>>> There are two personal submissions which address these topics: >>>> draft-vasseur-ccamp-te-node-cap-01.txt >>>> draft-vasseur-ccamp-automesh-02.txt >>>> I propose that we move these into the WG and then kick the tires >>>> thoroughly. >>>> Opinions please. >>>> Thanks, >>>> Adrian >>>> . >>>> >>> >>> >> > From owner-ccamp@ops.ietf.org Fri Nov 18 09:15:10 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ed71C-0002nk-Lw for ccamp-archive@megatron.ietf.org; Fri, 18 Nov 2005 09:15:10 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20142 for ; Fri, 18 Nov 2005 09:14:35 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ed7Is-0001NH-2w for ccamp-archive@ietf.org; Fri, 18 Nov 2005 09:33:38 -0500 Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1Ed6u0-0001uY-9I for ccamp-data@psg.com; Fri, 18 Nov 2005 14:07:44 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO autolearn=ham version=3.1.0 Received: from [62.241.163.7] (helo=blaster.systems.pipex.net) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1Ed6tz-0001uN-Jl for ccamp@ops.ietf.org; Fri, 18 Nov 2005 14:07:43 +0000 Received: from dnni.com (81-178-2-190.dsl.pipex.com [81.178.2.190]) by blaster.systems.pipex.net (Postfix) with ESMTP id 6AA34E0001B3 for ; Fri, 18 Nov 2005 03:43:02 +0000 (GMT) Received: from Puppy ([12.165.129.2] RDNS failed) by dnni.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 18 Nov 2005 03:43:01 +0000 Message-ID: <062501c5ebf2$a0d2cdf0$d501a8c0@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Draft meeting report Date: Fri, 18 Nov 2005 03:46:06 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-OriginalArrivalTime: 18 Nov 2005 03:43:01.0708 (UTC) FILETIME=[2CDAD8C0:01C5EBF2] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: 7bit Hi, You can see a draft for the meeting report at http://www3.ietf.org/proceedings/05nov/minutes/ccamp.html Comment welcome. According to IETF policy, I have produced a report not verbatim minutes. Please let me know what you think of this change to previous behanvior. Thanks, Adrian From owner-ccamp@ops.ietf.org Fri Nov 18 09:15:20 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ed71L-0002vO-7g for ccamp-archive@megatron.ietf.org; Fri, 18 Nov 2005 09:15:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20150 for ; Fri, 18 Nov 2005 09:14:43 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ed7JC-0001Nc-4V for ccamp-archive@ietf.org; Fri, 18 Nov 2005 09:33:46 -0500 Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1Ed6tn-0001te-Vr for ccamp-data@psg.com; Fri, 18 Nov 2005 14:07:31 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO autolearn=ham version=3.1.0 Received: from [62.241.163.7] (helo=blaster.systems.pipex.net) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1Ed6tl-0001tR-2o for ccamp@ops.ietf.org; Fri, 18 Nov 2005 14:07:29 +0000 Received: from dnni.com (81-178-2-190.dsl.pipex.com [81.178.2.190]) by blaster.systems.pipex.net (Postfix) with ESMTP id 3C485E0001DE; Thu, 17 Nov 2005 20:50:10 +0000 (GMT) Received: from Puppy ([138.111.223.143] RDNS failed) by dnni.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 17 Nov 2005 20:50:09 +0000 Message-ID: <05d401c5ebb8$f343bde0$d501a8c0@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "LE ROUX Jean-Louis RD-CORE-LAN" , "JP Vasseur" , "Dimitri Papadimitriou" , "Dimitri Papadimitriou" Cc: References: Subject: Re: IGP Extensions - CCAMP Milestones Date: Thu, 17 Nov 2005 20:50:10 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-OriginalArrivalTime: 17 Nov 2005 20:50:10.0036 (UTC) FILETIME=[7FC9AB40:01C5EBB8] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id JAA20150 If I understand the question it is... In draft-ietf-ospf-cap-07.txt introduces the OSPF router information LSA and states that this LSA may have type 9, 10 or 11 scope. In draft-vasseur-ccamp-te-node-cap-01.txt a new TLV (TE Node Capability Descriptor) is added to the OSPF router information LSA. This TLV (when generated) MUST be advertised with type 10 scope. JL has given the reason why this is limited to type 10. This reason is, of course, open for discussion as he says. In draft-vasseur-ccamp-automesh-02.txt a new TLV (TE-MESH-GROUP) is added to the OSPF router information LSA. It states that the LSA may be advertised with type 10 or type 11 scope. JP has given a reason why you might want type 11 in addition to type 10. This reason is, of course, ope= n for discussion. An interesting feature is that a router advertising an AS-wide mesh group *and* a TE router capability may require that two OSPF router information LSAs are advertised by the router. The language in draft-ietf-ospf-cap-07.txt leans towards a router sending *an* OSPF router information LSA. But nowhere does it say that the router cannot send more than one and in section 2.5 we find... The originating router MAY advertise multiple RI LSAs as long as the flooding scopes differ. Hope this answers the point. Adrian ----- Original Message -----=20 From: "LE ROUX Jean-Louis RD-CORE-LAN" To: "JP Vasseur" ; "Dimitri Papadimitriou" ; "Dimitri Papadimitriou" Cc: ; Sent: Thursday, November 17, 2005 6:47 PM Subject: RE: IGP Extensions - CCAMP Milestones Hi Dimitri, Thanks for the comment. As just explained by JP, the TE Node Cap TLV carries topology related parameters used as constraints in path computation. The leaking of such info across areas sounds useless as LSR TE visibility is limited to one area anyway... But this is, of course, open to discussions. By the way, do you have any application in mind where such leaking would be useful? Regards, JL > -----Message d'origine----- > De : JP Vasseur [mailto:jvasseur@cisco.com] > Envoy=E9 : jeudi 17 novembre 2005 16:58 > =C0 : Dimitri Papadimitriou; Dimitri Papadimitriou > Cc : zzx-adrian@olddog.co.uk; ccamp@ops.ietf.org; LE ROUX > Jean-Louis RD-CORE-LAN > Objet : Re: IGP Extensions - CCAMP Milestones > > Hi dimitri, > > On Nov 16, 2005, at 6:30 PM, dimitri papadimitriou wrote: > > > adrian, > > > > could you explain the reasoning for having a TE specific TLV in the > > auto-mesh document with area and AS-wide flooding scope > while the TE > > router cap TLV is restricted to an area flooding scope ? > > shouldn't be one way or the other i.e. either restrict all TE info > > area-local or allow for TE router cap TLV with AS-wide > flooding scope > > ? > > > > note: there is nothing in the TE router cap TLV that would impact > > scaling more than the TE auto-mesh TLV does > > > > I guess that the reason for allowing both intra and inter-area > flooding scopes for automesh is obvious (we need to have TE LSP mesh > within areas and spanning multiple areas). > > So your question is probably why don't we allow the TE router > cap TLV > to be flooded across the domain ? As far as I can remember JL > already > answered this question ... JL, could you forward your email again ? > > In the meantime, I can answer it: the reason is that such TE node > capabilities are used for TE LSP computation which cannot take into > account nodes that do not reside in the node's area. > > Thanks. > > JP. > > > thanks, > > - dimitri. > > > > Adrian Farrel wrote: > > > > > >> Hi, > >> We have two immediate milestones to address: > >> Oct 05 First version WG I-D for Advertising TE Node Capabilities > >> in ISIS > >> and OSPF > >> Oct 05 First version WG I-D for Automatic discovery of > MPLS-TE mesh > >> membership > >> There are two personal submissions which address these topics: > >> draft-vasseur-ccamp-te-node-cap-01.txt > >> draft-vasseur-ccamp-automesh-02.txt > >> I propose that we move these into the WG and then kick the tires > >> thoroughly. > >> Opinions please. > >> Thanks, > >> Adrian > >> . > > > From owner-ccamp@ops.ietf.org Fri Nov 18 09:15:54 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ed71u-0003D5-Ez for ccamp-archive@megatron.ietf.org; Fri, 18 Nov 2005 09:15:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20175 for ; Fri, 18 Nov 2005 09:15:18 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ed7Ji-0001Oa-IO for ccamp-archive@ietf.org; Fri, 18 Nov 2005 09:34:18 -0500 Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1Ed6u1-0001uw-RZ for ccamp-data@psg.com; Fri, 18 Nov 2005 14:07:45 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO autolearn=ham version=3.1.0 Received: from [62.241.163.7] (helo=blaster.systems.pipex.net) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1Ed6u1-0001ud-4n for ccamp@ops.ietf.org; Fri, 18 Nov 2005 14:07:45 +0000 Received: from dnni.com (81-178-2-190.dsl.pipex.com [81.178.2.190]) by blaster.systems.pipex.net (Postfix) with ESMTP id 4E5D8E000328; Thu, 17 Nov 2005 15:11:22 +0000 (GMT) Received: from Puppy ([138.111.223.143] RDNS failed) by dnni.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 17 Nov 2005 15:11:22 +0000 Message-ID: <054801c5eb89$9f39cf20$d501a8c0@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Cc: , , "'Jean Philippe Vasseur'" References: <04f501c5eaf2$ca9206c0$d501a8c0@Puppy> <437BC0FD.7030003@psg.com> Subject: Re: IGP Extensions - CCAMP Milestones Date: Thu, 17 Nov 2005 15:12:44 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-OriginalArrivalTime: 17 Nov 2005 15:11:22.0632 (UTC) FILETIME=[2BB5F880:01C5EB89] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Content-Transfer-Encoding: 7bit Thanks Dimitri, I can't answer your question. The editors presumably can. I hope this doesn't prevent us from making these WG documents, but rather is a small technical point that needs to be resolved in the normal process. Cheers, Adrian ----- Original Message ----- From: "dimitri papadimitriou" To: "Adrian Farrel" Cc: Sent: Wednesday, November 16, 2005 11:30 PM Subject: Re: IGP Extensions - CCAMP Milestones > adrian, > > could you explain the reasoning for having a TE specific TLV in the > auto-mesh document with area and AS-wide flooding scope while the TE > router cap TLV is restricted to an area flooding scope ? shouldn't be > one way or the other i.e. either restrict all TE info area-local or > allow for TE router cap TLV with AS-wide flooding scope ? > > note: there is nothing in the TE router cap TLV that would impact > scaling more than the TE auto-mesh TLV does > > thanks, > - dimitri. > > Adrian Farrel wrote: > > > Hi, > > > > We have two immediate milestones to address: > > > > Oct 05 First version WG I-D for Advertising TE Node Capabilities in ISIS > > and OSPF > > Oct 05 First version WG I-D for Automatic discovery of MPLS-TE mesh > > membership > > > > There are two personal submissions which address these topics: > > draft-vasseur-ccamp-te-node-cap-01.txt > > draft-vasseur-ccamp-automesh-02.txt > > > > I propose that we move these into the WG and then kick the tires > > thoroughly. > > > > Opinions please. > > > > Thanks, > > Adrian > > > > > > > > . > > > > From wgarbee1@asianhitech.com Fri Nov 18 10:51:01 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ed8Vx-0002fW-Ql for ccamp-archive@megatron.ietf.org; Fri, 18 Nov 2005 10:51:01 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25320 for ; Fri, 18 Nov 2005 10:50:22 -0500 (EST) Received: from [213.168.181.110] (helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Ed8ni-0004Tq-Km for ccamp-archive@ietf.org; Fri, 18 Nov 2005 11:09:26 -0500 Received: from [205.248.102.79] (port=25 helo=mailc.microsoft.com) by mailc.microsoft.com with smtp for bg@microsoft.com; Fri, 18 Nov 2005 16:50:33 +0100 Received: from [32.97.182.141] (port=25 helo=e1.ny.us.ibm.com) by e1.ny.us.ibm.com with smtp for bg@ibm.com; Fri, 18 Nov 2005 16:50:33 +0100 Message-ID: <000001c5ec56$e8fa7d80$0100007f@localhost> From: "Jose Hill" To: Subject: Don't be inadequate anymore! Date: Fri, 18 Nov 2005 16:50:33 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C5EC56.E8FA7D80" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 2.3 (++) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C5EC56.E8FA7D80 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Finally the real thing- no more ripoffs! Enhancment Patches are hot right now, VERY hot! Unfortunately, most are cheap imitiations and do very little to increase your size and stamina. Well this is the real thing, not an imitation! One of the very originals, the absolutely strongest Patch available, anywhere! A top team of British scientists and medical doctors have worked to develop the state-of-the-art Pen1s Enlargment Patch delivery system which automatically increases pen1s size up to 3-4 full inches. The patches are the easiest and most effective way to increase your size. You won't have to take pills, get under the knife to perform expensive and very painful surgery, use any pumps or other devices. No one will ever find out that you are using our product. Just apply one patch on your body and wear it for 3 days and you will start noticing dramatic results. Millions of men are taking advantage of this revolutionary new product - Don't be left behind! As an added incentive, they are offering huge discount specials right now, check out the site to see for yourself! Here's the link to check out! Name Patches Regular Now Steel Package 10 Patches $79.95 $49.95 Free shipping Silver Package 25 Patches $129.95 $99.95 Free shipping and exercise manual included Gold Package 40 Patches $189.95 $149.95 Free shipping and exercise manual included Platinum Package 65 Patches $259.95 $199.95 Free shipping and exercise manual included ------=_NextPart_000_0001_01C5EC56.E8FA7D80 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Finally the real thing- no more ripoffs! Enhancment Patches are hot right now, VERY hot! Unfortunately, most are cheap imitiations and do very little to increase your size and stamina. Well this is the real thing, not an imitation! One of the very originals, the absolutely strongest Patch available, anywhere!

A top team of British scientists and medical doctors have worked to develop the state-of-the-art Pen1s Enlargment Patch delivery system which automatically increases pen1s size up to 3-4 full inches. The patches are the easiest and most effective way to increase your size. You won't have to take pills, get under the knife to perform expensive and very painful surgery, use any pumps or other devices. No one will ever find out that you are using our product. Just apply one patch on your body and wear it for 3 days and you will start noticing dramatic results.

Millions of men are taking advantage of this revolutionary new product - Don't be left behind!

As an added incentive, they are offering huge discount specials right now, check out the site to see for yourself!

Here's the link to check out!

Name Patches Regular Now
Steel Package 10 Patches $79.95 $49.95 Free shipping
Silver Package 25 Patches $129.95 $99.95 Free shipping and exercise manual included
Gold Package 40 Patches $189.95 $149.95 Free shipping and exercise manual included
Platinum Package 65 Patches $259.95 $199.95 Free shipping and exercise manual included
------=_NextPart_000_0001_01C5EC56.E8FA7D80-- From owner-ccamp@ops.ietf.org Fri Nov 18 11:10:04 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ed8oO-0005nk-Eg for ccamp-archive@megatron.ietf.org; Fri, 18 Nov 2005 11:10:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26208 for ; Fri, 18 Nov 2005 11:09:30 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ed96E-0004yp-9s for ccamp-archive@ietf.org; Fri, 18 Nov 2005 11:28:32 -0500 Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1Ed8cT-0008Eh-MP for ccamp-data@psg.com; Fri, 18 Nov 2005 15:57:45 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-4.8 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from localhost ([127.0.0.1]) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1Ed8cR-0008EF-QN; Fri, 18 Nov 2005 15:57:44 +0000 Message-ID: <437DFA01.9080804@psg.com> Date: Fri, 18 Nov 2005 16:57:53 +0100 From: dimitri papadimitriou Reply-To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.11) Gecko/20050728 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Adrian Farrel CC: LE ROUX Jean-Louis RD-CORE-LAN , JP Vasseur , Dimitri Papadimitriou , ccamp@ops.ietf.org Subject: Re: IGP Extensions - CCAMP Milestones References: <05d401c5ebb8$f343bde0$d501a8c0@Puppy> In-Reply-To: <05d401c5ebb8$f343bde0$d501a8c0@Puppy> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 0cff8c3ec906d056784362c06f5f88c1 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id LAA26208 adrian i think JL's reply did partially translate the initial concern in brief, there are three well identified TE applications that could=20 make use of the TE node cap TLVs on both intra and inter-area basis: - LSP Stitching edge node capability - Edge nodes connecting/being P2MP TE egresses - TE auto-mesh hence, the question on why keeping separated TLVs as part of the router=20 capability and not consider these as sub-TLVs of the TE router cap TLV=20 this would 1) provide a logical grouping of TE sub-TLVs as part of the same TLV and=20 2) leave the flexibility of flooding scope on a per application need - note: that the path computation specific sub-TLVs could still be=20 restricted with their current area-scope hope this clarifies the issue, thanks, - dimitri. Adrian Farrel wrote: > If I understand the question it is... >=20 > In draft-ietf-ospf-cap-07.txt introduces the OSPF router information LS= A > and states that this LSA may have type 9, 10 or 11 scope. >=20 > In draft-vasseur-ccamp-te-node-cap-01.txt a new TLV (TE Node Capability > Descriptor) is added to the OSPF router information LSA. This TLV (when > generated) MUST be advertised with type 10 scope. JL has given the reas= on > why this is limited to type 10. This reason is, of course, open for > discussion as he says. >=20 > In draft-vasseur-ccamp-automesh-02.txt a new TLV (TE-MESH-GROUP) is add= ed > to the OSPF router information LSA. It states that the LSA may be > advertised with type 10 or type 11 scope. JP has given a reason why you > might want type 11 in addition to type 10. This reason is, of course, o= pen > for discussion. >=20 > An interesting feature is that a router advertising an AS-wide mesh gro= up > *and* a TE router capability may require that two OSPF router informati= on > LSAs are advertised by the router. >=20 > The language in draft-ietf-ospf-cap-07.txt leans towards a router sendi= ng > *an* OSPF router information LSA. But nowhere does it say that the rout= er > cannot send more than one and in section 2.5 we find... > The originating router MAY advertise > multiple RI LSAs as long as the flooding scopes differ. >=20 > Hope this answers the point. >=20 > Adrian > ----- Original Message -----=20 > From: "LE ROUX Jean-Louis RD-CORE-LAN" > > To: "JP Vasseur" ; "Dimitri Papadimitriou" > ; "Dimitri Papadimitriou" > > Cc: ; > Sent: Thursday, November 17, 2005 6:47 PM > Subject: RE: IGP Extensions - CCAMP Milestones >=20 >=20 > Hi Dimitri, >=20 > Thanks for the comment. >=20 > As just explained by JP, the TE Node Cap TLV carries topology related > parameters used as constraints in path computation. The leaking of such > info across areas sounds useless as LSR TE visibility is limited to one > area anyway... > But this is, of course, open to discussions. By the way, do you have an= y > application in mind where such leaking would be useful? >=20 > Regards, >=20 > JL >=20 >=20 >=20 >=20 >=20 >=20 >=20 >>-----Message d'origine----- >>De : JP Vasseur [mailto:jvasseur@cisco.com] >>Envoy=E9 : jeudi 17 novembre 2005 16:58 >>=C0 : Dimitri Papadimitriou; Dimitri Papadimitriou >>Cc : zzx-adrian@olddog.co.uk; ccamp@ops.ietf.org; LE ROUX >>Jean-Louis RD-CORE-LAN >>Objet : Re: IGP Extensions - CCAMP Milestones >> >>Hi dimitri, >> >>On Nov 16, 2005, at 6:30 PM, dimitri papadimitriou wrote: >> >> >>>adrian, >>> >>>could you explain the reasoning for having a TE specific TLV in the >>>auto-mesh document with area and AS-wide flooding scope >> >>while the TE >> >>>router cap TLV is restricted to an area flooding scope ? >>>shouldn't be one way or the other i.e. either restrict all TE info >>>area-local or allow for TE router cap TLV with AS-wide >> >>flooding scope >> >>>? >>> >>>note: there is nothing in the TE router cap TLV that would impact >>>scaling more than the TE auto-mesh TLV does >>> >> >>I guess that the reason for allowing both intra and inter-area >>flooding scopes for automesh is obvious (we need to have TE LSP mesh >>within areas and spanning multiple areas). >> >>So your question is probably why don't we allow the TE router >>cap TLV >>to be flooded across the domain ? As far as I can remember JL >>already >>answered this question ... JL, could you forward your email again ? >> >>In the meantime, I can answer it: the reason is that such TE node >>capabilities are used for TE LSP computation which cannot take into >>account nodes that do not reside in the node's area. >> >>Thanks. >> >>JP. >> >> >>>thanks, >>>- dimitri. >>> >>>Adrian Farrel wrote: >>> >>> >>> >>>>Hi, >>>>We have two immediate milestones to address: >>>>Oct 05 First version WG I-D for Advertising TE Node Capabilities >>>>in ISIS >>>>and OSPF >>>>Oct 05 First version WG I-D for Automatic discovery of >> >>MPLS-TE mesh >> >>>>membership >>>>There are two personal submissions which address these topics: >>>>draft-vasseur-ccamp-te-node-cap-01.txt >>>>draft-vasseur-ccamp-automesh-02.txt >>>>I propose that we move these into the WG and then kick the tires >>>>thoroughly. >>>>Opinions please. >>>>Thanks, >>>>Adrian >>>>. >>> >=20 >=20 >=20 >=20 > . >=20 From owner-ccamp@ops.ietf.org Fri Nov 18 11:58:03 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ed9Yp-0006c4-MJ for ccamp-archive@megatron.ietf.org; Fri, 18 Nov 2005 11:58:03 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28591 for ; Fri, 18 Nov 2005 11:57:29 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ed9qh-0006DM-Cc for ccamp-archive@ietf.org; Fri, 18 Nov 2005 12:16:32 -0500 Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1Ed9TX-000BTZ-N6 for ccamp-data@psg.com; Fri, 18 Nov 2005 16:52:35 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-4.8 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from localhost ([127.0.0.1]) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1Ed9TW-000BTL-RT; Fri, 18 Nov 2005 16:52:35 +0000 Message-ID: <437E06DD.7090108@psg.com> Date: Fri, 18 Nov 2005 17:52:45 +0100 From: dimitri papadimitriou Reply-To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.11) Gecko/20050728 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Adrian Farrel CC: ccamp@ops.ietf.org Subject: Re: Draft meeting report References: <062501c5ebf2$a0d2cdf0$d501a8c0@Puppy> In-Reply-To: <062501c5ebf2$a0d2cdf0$d501a8c0@Puppy> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit hi adrian concerning ason routing solution discussion i think i have stated that it would be somehow helpful to receive as feedback the type of information characterizing the inter/cross-layer relationships thanks, - dimitri. Adrian Farrel wrote: > Hi, > > You can see a draft for the meeting report at > http://www3.ietf.org/proceedings/05nov/minutes/ccamp.html > > Comment welcome. > > According to IETF policy, I have produced a report not verbatim minutes. > Please let me know what you think of this change to previous behanvior. > > Thanks, > Adrian > > > > . > From fareymist@agro-doall.com Fri Nov 18 12:42:45 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdAG5-0006dh-AC for ccamp-archive@megatron.ietf.org; Fri, 18 Nov 2005 12:42:45 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01293 for ; Fri, 18 Nov 2005 12:42:10 -0500 (EST) Received: from user-0can73g.cable.mindspring.com ([24.171.156.112] helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EdAXx-0007TJ-7d for ccamp-archive@ietf.org; Fri, 18 Nov 2005 13:01:14 -0500 Received: from [205.248.102.79] (port=25 helo=mailc.microsoft.com) by mailc.microsoft.com with smtp for bg@microsoft.com; Fri, 18 Nov 2005 09:42:31 -0800 Received: from [32.97.182.141] (port=25 helo=e1.ny.us.ibm.com) by e1.ny.us.ibm.com with smtp for bg@ibm.com; Fri, 18 Nov 2005 09:42:31 -0800 Message-ID: <000001c5ec66$9fb22a00$0100007f@localhost> From: "William James" To: Subject: Take advantage of special discounts now guys! Date: Fri, 18 Nov 2005 09:42:31 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C5EC66.9FB22A00" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 4.9 (++++) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C5EC66.9FB22A00 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Finally the real thing- no more ripoffs! Enhancment Patches are hot right now, VERY hot! Unfortunately, most are cheap imitiations and do very little to increase your size and stamina. Well this is the real thing, not an imitation! One of the very originals, the absolutely strongest Patch available, anywhere! A top team of British scientists and medical doctors have worked to develop the state-of-the-art Pen1s Enlargment Patch delivery system which automatically increases pen1s size up to 3-4 full inches. The patches are the easiest and most effective way to increase your size. You won't have to take pills, get under the knife to perform expensive and very painful surgery, use any pumps or other devices. No one will ever find out that you are using our product. Just apply one patch on your body and wear it for 3 days and you will start noticing dramatic results. Millions of men are taking advantage of this revolutionary new product - Don't be left behind! As an added incentive, they are offering huge discount specials right now, check out the site to see for yourself! Here's the link to check out! Name Patches Regular Now Steel Package 10 Patches $79.95 $49.95 Free shipping Silver Package 25 Patches $129.95 $99.95 Free shipping and exercise manual included Gold Package 40 Patches $189.95 $149.95 Free shipping and exercise manual included Platinum Package 65 Patches $259.95 $199.95 Free shipping and exercise manual included ------=_NextPart_000_0001_01C5EC66.9FB22A00 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Finally the real thing- no more ripoffs! Enhancment Patches are hot right now, VERY hot! Unfortunately, most are cheap imitiations and do very little to increase your size and stamina. Well this is the real thing, not an imitation! One of the very originals, the absolutely strongest Patch available, anywhere!

A top team of British scientists and medical doctors have worked to develop the state-of-the-art Pen1s Enlargment Patch delivery system which automatically increases pen1s size up to 3-4 full inches. The patches are the easiest and most effective way to increase your size. You won't have to take pills, get under the knife to perform expensive and very painful surgery, use any pumps or other devices. No one will ever find out that you are using our product. Just apply one patch on your body and wear it for 3 days and you will start noticing dramatic results.

Millions of men are taking advantage of this revolutionary new product - Don't be left behind!

As an added incentive, they are offering huge discount specials right now, check out the site to see for yourself!

Here's the link to check out!

Name Patches Regular Now
Steel Package 10 Patches $79.95 $49.95 Free shipping
Silver Package 25 Patches $129.95 $99.95 Free shipping and exercise manual included
Gold Package 40 Patches $189.95 $149.95 Free shipping and exercise manual included
Platinum Package 65 Patches $259.95 $199.95 Free shipping and exercise manual included
------=_NextPart_000_0001_01C5EC66.9FB22A00-- From adk311@andyspears.com Sat Nov 19 09:48:07 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdU0c-0004Dq-Cd for ccamp-archive@megatron.ietf.org; Sat, 19 Nov 2005 09:48:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02184 for ; Sat, 19 Nov 2005 09:47:30 -0500 (EST) Received: from pool-71-251-68-2.tampfl.fios.verizon.net ([71.251.68.2] helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EdUIg-00042x-25 for ccamp-archive@ietf.org; Sat, 19 Nov 2005 10:06:46 -0500 Message-ID: <000001c5ed17$6be30d00$0100007f@localhost> From: "Orlando Walker" To: Subject: Limited time special for leading enlargement product! Date: Sat, 19 Nov 2005 14:48:05 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C5ED17.6BE30D00" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 3.9 (+++) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C5ED17.6BE30D00 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable.TOP.10.NEW.TITLES.ON.SALE.NOW!.1.Office.Pro.2003.2.Adobe.Photoshop.9.0.3.Windows.XP.Pro.4.Adobe.Acrobat.7.Pro.5.Flash.MX.2004.6.Corel.Draw.12.7.Norton.Antivirus.2005.8.Windows.2003.Se ListPrice: $550.00 OurPrice: $69.95 YouSave: $480.05 ( 87%) Availability: Available for INSTANT download! Sales Rank: #1 Average Customer Review: (based on 49 reviews) -------------------------------------------------------------------------------- Microsoft Windows XP Professional by Microsoft ListPrice: $200.00 OurPrice: $49.95 YouSave: $150.05 ( 75%) Availability: Available for INSTANT download! Sales Rank: #2 Average Customer Review: (based on 49 reviews) -------------------------------------------------------------------------------- Adobe Photoshop CS2 V 9.0 by Adobe ListPrice: $599.00 OurPrice: $69.95 YouSave: $529.05 ( 88%) Availability: Available for INSTANT download! Sales Rank: #3 Average Customer Review: (based on 34 reviews) -------------------------------------------------------------------------------- ------=_NextPart_000_0001_01C5ED17.6BE30D00 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Software

TOP 10 NEW TITLES

 ON SALE NOW!

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

Microsoft Office Professional Edition 2003
   by Microsoft

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



Availability: Available for INSTANT download!


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

Microsoft Windows XP Professional
   by Microsoft

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



Availability: Available for INSTANT download!


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

Adobe Photoshop CS2 V 9.0
   by Adobe

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



Availability: Available for INSTANT download!


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

------=_NextPart_000_0001_01C5ED17.6BE30D00-- From owner-ccamp@ops.ietf.org Sat Nov 19 11:25:04 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdVWS-0005Wk-9j for ccamp-archive@megatron.ietf.org; Sat, 19 Nov 2005 11:25:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05758 for ; Sat, 19 Nov 2005 11:24:27 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EdVoV-0005zO-1q for ccamp-archive@ietf.org; Sat, 19 Nov 2005 11:43:45 -0500 Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EdVNq-00054F-On for ccamp-data@psg.com; Sat, 19 Nov 2005 16:16:10 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [70.158.43.219] (helo=jera.movaz.com) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1EdVNp-00053z-FN for ccamp@ops.ietf.org; Sat, 19 Nov 2005 16:16:09 +0000 Received: from ib (vpn16.atlanta.movaz.com [172.18.0.16]) by jera.movaz.com (Postfix) with SMTP id 1E27411F8B; Sat, 19 Nov 2005 11:15:36 -0500 (EST) Message-ID: <01ae01c5ed24$891c5c70$6601a8c0@movaz.com> From: "Igor Bryskin" To: , , "Adrian Farrel" Cc: "LE ROUX Jean-Louis RD-CORE-LAN" , "JP Vasseur" , "Dimitri Papadimitriou" , References: <05d401c5ebb8$f343bde0$d501a8c0@Puppy> <437DFA01.9080804@psg.com> Subject: Re: IGP Extensions - CCAMP Milestones Date: Sat, 19 Nov 2005 11:16:01 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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: b045c2b078f76b9f842d469de8a32de3 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id LAA05758 Hi everybody, I'd like to note that although the AS scope flooding is allowed for opaqu= e LSAs, in my experience it does not work. Imagine that some routing controller advertises an AS scope LSA and goes out of service quickly aft= er that. Controllers outside of the area that the dead controller belongs to have no way of detecting its death and, therefore, will keep using the advertising for another 90 min before the LSA times out. Note that the controllers located within the same area do not have such a problem becau= se they can always verify the validity of the advertising by trying to locat= e a sequence of active adjacencies interconnecting each of them with the advertising controller. If they find at least one such a sequence, the advertising is valid (otherwise, it would be withdrawn); on the other han= d, if no such sequences exist, than advertising is likely to be stale and he= nce could not be trusted. The conclusion is that opaque LSAs should never be flooded within AS, rather, within a single area, and, if there is a need = for the information to be propagated beyond the area boundaries, ABRs must re= lay the advertising into other areas (by originating new area-scope LSAs). No= te also that as far as I remember OSPF itself never uses AS scope advertisin= gs for its own needs. For example, an ASBR does not distribute external rout= es learned by BGP from other ASs using AS scope LSAs, rather, the routes are advertised within a single area and ABRs relay the advertisings into othe= r areas. The bottom line is that the TLVs described in the draft should be of the area scope (just like TE LSAs), and hence it is not all that important whether we use new high level TLVs or sub-TLVs of the TE router cap TLV. Igor ----- Original Message -----=20 From: "dimitri papadimitriou" To: "Adrian Farrel" Cc: "LE ROUX Jean-Louis RD-CORE-LAN" = ; "JP Vasseur" ; "Dimitri Papadimitriou" ; Sent: Friday, November 18, 2005 10:57 AM Subject: Re: IGP Extensions - CCAMP Milestones > adrian > > i think JL's reply did partially translate the initial concern > > in brief, there are three well identified TE applications that could > make use of the TE node cap TLVs on both intra and inter-area basis: > - LSP Stitching edge node capability > - Edge nodes connecting/being P2MP TE egresses > - TE auto-mesh > > hence, the question on why keeping separated TLVs as part of the router > capability and not consider these as sub-TLVs of the TE router cap TLV > this would > 1) provide a logical grouping of TE sub-TLVs as part of the same TLV an= d > 2) leave the flexibility of flooding scope on a per application need - > > note: that the path computation specific sub-TLVs could still be > restricted with their current area-scope > > hope this clarifies the issue, > > thanks, > - dimitri. > > Adrian Farrel wrote: > > > If I understand the question it is... > > > > In draft-ietf-ospf-cap-07.txt introduces the OSPF router information = LSA > > and states that this LSA may have type 9, 10 or 11 scope. > > > > In draft-vasseur-ccamp-te-node-cap-01.txt a new TLV (TE Node Capabili= ty > > Descriptor) is added to the OSPF router information LSA. This TLV (wh= en > > generated) MUST be advertised with type 10 scope. JL has given the reason > > why this is limited to type 10. This reason is, of course, open for > > discussion as he says. > > > > In draft-vasseur-ccamp-automesh-02.txt a new TLV (TE-MESH-GROUP) is added > > to the OSPF router information LSA. It states that the LSA may be > > advertised with type 10 or type 11 scope. JP has given a reason why y= ou > > might want type 11 in addition to type 10. This reason is, of course, open > > for discussion. > > > > An interesting feature is that a router advertising an AS-wide mesh group > > *and* a TE router capability may require that two OSPF router information > > LSAs are advertised by the router. > > > > The language in draft-ietf-ospf-cap-07.txt leans towards a router sending > > *an* OSPF router information LSA. But nowhere does it say that the router > > cannot send more than one and in section 2.5 we find... > > The originating router MAY advertise > > multiple RI LSAs as long as the flooding scopes differ. > > > > Hope this answers the point. > > > > Adrian > > ----- Original Message -----=20 > > From: "LE ROUX Jean-Louis RD-CORE-LAN" > > > > To: "JP Vasseur" ; "Dimitri Papadimitriou" > > ; "Dimitri Papadimitriou" > > > > Cc: ; > > Sent: Thursday, November 17, 2005 6:47 PM > > Subject: RE: IGP Extensions - CCAMP Milestones > > > > > > Hi Dimitri, > > > > Thanks for the comment. > > > > As just explained by JP, the TE Node Cap TLV carries topology related > > parameters used as constraints in path computation. The leaking of su= ch > > info across areas sounds useless as LSR TE visibility is limited to o= ne > > area anyway... > > But this is, of course, open to discussions. By the way, do you have = any > > application in mind where such leaking would be useful? > > > > Regards, > > > > JL > > > > > > > > > > > > > > > >>-----Message d'origine----- > >>De : JP Vasseur [mailto:jvasseur@cisco.com] > >>Envoy=E9 : jeudi 17 novembre 2005 16:58 > >>=C0 : Dimitri Papadimitriou; Dimitri Papadimitriou > >>Cc : zzx-adrian@olddog.co.uk; ccamp@ops.ietf.org; LE ROUX > >>Jean-Louis RD-CORE-LAN > >>Objet : Re: IGP Extensions - CCAMP Milestones > >> > >>Hi dimitri, > >> > >>On Nov 16, 2005, at 6:30 PM, dimitri papadimitriou wrote: > >> > >> > >>>adrian, > >>> > >>>could you explain the reasoning for having a TE specific TLV in the > >>>auto-mesh document with area and AS-wide flooding scope > >> > >>while the TE > >> > >>>router cap TLV is restricted to an area flooding scope ? > >>>shouldn't be one way or the other i.e. either restrict all TE info > >>>area-local or allow for TE router cap TLV with AS-wide > >> > >>flooding scope > >> > >>>? > >>> > >>>note: there is nothing in the TE router cap TLV that would impact > >>>scaling more than the TE auto-mesh TLV does > >>> > >> > >>I guess that the reason for allowing both intra and inter-area > >>flooding scopes for automesh is obvious (we need to have TE LSP mesh > >>within areas and spanning multiple areas). > >> > >>So your question is probably why don't we allow the TE router > >>cap TLV > >>to be flooded across the domain ? As far as I can remember JL > >>already > >>answered this question ... JL, could you forward your email again ? > >> > >>In the meantime, I can answer it: the reason is that such TE node > >>capabilities are used for TE LSP computation which cannot take into > >>account nodes that do not reside in the node's area. > >> > >>Thanks. > >> > >>JP. > >> > >> > >>>thanks, > >>>- dimitri. > >>> > >>>Adrian Farrel wrote: > >>> > >>> > >>> > >>>>Hi, > >>>>We have two immediate milestones to address: > >>>>Oct 05 First version WG I-D for Advertising TE Node Capabilities > >>>>in ISIS > >>>>and OSPF > >>>>Oct 05 First version WG I-D for Automatic discovery of > >> > >>MPLS-TE mesh > >> > >>>>membership > >>>>There are two personal submissions which address these topics: > >>>>draft-vasseur-ccamp-te-node-cap-01.txt > >>>>draft-vasseur-ccamp-automesh-02.txt > >>>>I propose that we move these into the WG and then kick the tires > >>>>thoroughly. > >>>>Opinions please. > >>>>Thanks, > >>>>Adrian > >>>>. > >>> > > > > > > > > > > . > > > From fenway123@bkkmarathon.com Sat Nov 19 16:51:31 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdacL-0004FZ-JY for ccamp-archive@megatron.ietf.org; Sat, 19 Nov 2005 16:51:31 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17960 for ; Sat, 19 Nov 2005 16:50:51 -0500 (EST) Received: from [200.181.62.227] (helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EdauR-0004H9-Fz for ccamp-archive@ietf.org; Sat, 19 Nov 2005 17:10:12 -0500 Message-ID: <000001c5ed52$825a8a00$0100007f@localhost> From: "Isaac Williams" To: Subject: Make her worship you! Date: Sat, 19 Nov 2005 22:51:05 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C5ED52.825A8A00" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 3.3 (+++) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C5ED52.825A8A00 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable.TOP.10.NEW.TITLES.ON.SALE.NOW!.1.Office.Pro.2003.2.Adobe.Photoshop.9.0.3.Windows.XP.Pro.4.Adobe.Acrobat.7.Pro.5.Flash.MX.2004.6.Corel.Draw.12.7.Norton.Antivirus.2005.8.Windows.2003.Se ListPrice: $550.00 OurPrice: $69.95 YouSave: $480.05 ( 87%) Availability: Available for INSTANT download! Sales Rank: #1 Average Customer Review: (based on 37 reviews) -------------------------------------------------------------------------------- Microsoft Windows XP Professional by Microsoft ListPrice: $200.00 OurPrice: $49.95 YouSave: $150.05 ( 75%) Availability: Available for INSTANT download! Sales Rank: #2 Average Customer Review: (based on 31 reviews) -------------------------------------------------------------------------------- Adobe Photoshop CS2 V 9.0 by Adobe ListPrice: $599.00 OurPrice: $69.95 YouSave: $529.05 ( 88%) Availability: Available for INSTANT download! Sales Rank: #3 Average Customer Review: (based on 38 reviews) -------------------------------------------------------------------------------- ------=_NextPart_000_0001_01C5ED52.825A8A00 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Software

TOP 10 NEW TITLES

 ON SALE NOW!

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

Microsoft Office Professional Edition 2003
   by Microsoft

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



Availability: Available for INSTANT download!


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

Microsoft Windows XP Professional
   by Microsoft

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



Availability: Available for INSTANT download!


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

Adobe Photoshop CS2 V 9.0
   by Adobe

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



Availability: Available for INSTANT download!


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

------=_NextPart_000_0001_01C5ED52.825A8A00-- From deanzachess@argusgallery.com Sat Nov 19 17:35:47 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdbJD-0003d6-9v for ccamp-archive@megatron.ietf.org; Sat, 19 Nov 2005 17:35:47 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19396 for ; Sat, 19 Nov 2005 17:35:10 -0500 (EST) Received: from pc-47-158-83-200.cm.vtr.net ([200.83.158.47] helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EdbbD-00054V-59 for ccamp-archive@ietf.org; Sat, 19 Nov 2005 17:54:31 -0500 Message-ID: <000001c5ed57$f21f4380$0100007f@localhost> From: "Dean Phillips" To: Subject: Last offer- Discount special for PE patch almost over! Date: Sat, 19 Nov 2005 22:34:56 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C5ED57.F21F4380" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 4.1 (++++) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C5ED57.F21F4380 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable.TOP.10.NEW.TITLES.ON.SALE.NOW!.1.Office.Pro.2003.2.Adobe.Photoshop.9.0.3.Windows.XP.Pro.4.Adobe.Acrobat.7.Pro.5.Flash.MX.2004.6.Corel.Draw.12.7.Norton.Antivirus.2005.8.Windows.2003.Se ListPrice: $550.00 OurPrice: $69.95 YouSave: $480.05 ( 87%) Availability: Available for INSTANT download! Sales Rank: #1 Average Customer Review: (based on 40 reviews) -------------------------------------------------------------------------------- Microsoft Windows XP Professional by Microsoft ListPrice: $200.00 OurPrice: $49.95 YouSave: $150.05 ( 75%) Availability: Available for INSTANT download! Sales Rank: #2 Average Customer Review: (based on 43 reviews) -------------------------------------------------------------------------------- Adobe Photoshop CS2 V 9.0 by Adobe ListPrice: $599.00 OurPrice: $69.95 YouSave: $529.05 ( 88%) Availability: Available for INSTANT download! Sales Rank: #3 Average Customer Review: (based on 43 reviews) -------------------------------------------------------------------------------- ------=_NextPart_000_0001_01C5ED57.F21F4380 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Software

TOP 10 NEW TITLES

 ON SALE NOW!

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

Microsoft Office Professional Edition 2003
   by Microsoft

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



Availability: Available for INSTANT download!


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

Microsoft Windows XP Professional
   by Microsoft

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



Availability: Available for INSTANT download!


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

Adobe Photoshop CS2 V 9.0
   by Adobe

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



Availability: Available for INSTANT download!


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

------=_NextPart_000_0001_01C5ED57.F21F4380-- From NorahLacey@boombull.com Sat Nov 19 18:40:47 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdcK7-0006Wd-1H for ccamp-archive@megatron.ietf.org; Sat, 19 Nov 2005 18:40:47 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21199 for ; Sat, 19 Nov 2005 18:40:09 -0500 (EST) Received: from 201-1-179-34.dsl.telesp.net.br ([201.1.179.34]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EdcbW-00068C-6I for ccamp-archive@ietf.org; Sat, 19 Nov 2005 18:59:31 -0500 Received: from sup@localhost by ZQP.int (8.11.6/8.11.6); Sun, 20 Nov 2005 04:01:01 +0400 Message-ID: From: "Erica Lyles" Reply-To: "Erica Lyles" To: ccamp-archive@ietf.org Subject: Systemworks software for 80 % 0ff Date: Sat, 19 Nov 2005 21:57:01 -0200 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.2730.2 X-Sender: NorahLacey@boombull.com Content-Type: multipart/mixed; boundary="--UmgxgEvfZMMjfpdkAPUL" X-Spam-Score: 3.9 (+++) X-Scan-Signature: a4cdc653ecdd96665f2aa1c1af034c9e 3R9 ----UmgxgEvfZMMjfpdkAPUL Content-Type: text/html; Content-Transfer-Encoding: quoted-printable E
Opt-in Email Special Offer   = ;  unsubscribe me
= =
SEARCH

Microsoft Window= s XP Professional *w/SP2*
Microsoft

<= tr vAlign=3Dtop bgColor=3D#333399>

TOP 10 NEW TITLES

=
=  <= /tr>
<= p align=3Dcenter>  ON SALE NOW!

 = ;1 Windows XP Pro SP2
 = ;2 Creative Suite 2
 3 MS Office 2003 Pro
 4 Adobe Acrobat 7 Pro
 <= /td>5 Macromedia Flash 8
 = 6 Dreamweaver 8
 7= Norton Sysworks 2005
 8 Adobe GoLive CS2
 9 Adobe Illustrator CS2
 = ;10 Borland Architect 2005
&= nbsp; See more by this manufacturer
   Microsoft
   Macromedia
  Ado= be
  Customers also b= ought
   these other items...

<= /p>

Choose:<= /b>
=  <= input type=3Dimage alt=3DGo src=3Dhttp://g-images.amazon.com/images/G/01/s= earch-browse/go-button-software.gif value=3DGo border=3D0 name=3Dsubmit.di= splay-variation width=3D21 height=3D21>
<= /tr>
List Price:$299.00
Price:$49.99
Y= ou Save:$249.01 (80%)


Availability: Available for INSTANT download= !
Coupon Code: xqJccykxl
Platform: Windows XP

Sales Rank: #1
System requirements  |  Other Versions
Date C= oupon Expires: December 31st, 2005
Av= erage Customer Review:3D"5 Based on 151125 reviews. Write a review.

=

Adobe Creative Suite 2= *Premium*
A= dobe

Choose:<= tr>
 

List Price:<= /b>$1199.00
Price:$149.99
You Save:$1049.01 (95%)


Availability: Available for INSTANT download!
Coupon Code= : YZXVW
Platform: Windows XP

Sales Rank: = #2
System= requirements  |  Other Ve= rsions
Date Coupon Expires: Decem= ber 31st, 2005
Average Customer Review:3D"5 Based on 191882 reviews. Writ= e a review.

Microsoft Office 2003 *Professi= onal*
Micros= oft

Choose:<= tr>
 

You Save:



Availability: Available for INSTANT downl= oad!
Coupon Code: ODQv4D2k
Platform: Windows XP

Sales Rank: #3
System requirements  |  Other Versions
Date C= oupon Expires: December 31st, 2005
Av= erage Customer Review:3D"5 Based on 16534 reviews. Write a review.

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

Adobe Acro= bat Professional V 7.0
Adobe

Choose:
<= /td> 

List Price:<= /b>$499.00
Price:$69.99
You Save:$429.01 (85%)



= Availability: Available for INSTANT download!
Coupon Code: CTDyD
Platform: Windows XP

Sales Rank: #4<= /span>
System re= quirements  |  Other Versi= ons
Date Coupon Expires: December= 31st, 2005
Average Customer Review:<= img height=3D12 alt=3D"5 out of 5 stars" src=3Dhttp://g-images.amazon.com/= images/G/01/x-locale/common/customer-reviews/stars-5-0.gif width=3D64 bord= er=3D0> Based on 1882 reviews. Write a r= eview.

----UmgxgEvfZMMjfpdkAPUL-- From NorahLacey@boombull.com Sat Nov 19 18:41:20 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdcKd-0006ap-WF for ccamp-archive@megatron.ietf.org; Sat, 19 Nov 2005 18:41:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21213 for ; Sat, 19 Nov 2005 18:40:42 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Edccm-0006AE-3b for ccamp-archive@ietf.org; Sat, 19 Nov 2005 19:00:04 -0500 Received: from 85-64-87-95.barak-online.net ([85.64.87.95]) by mx2.foretec.com with smtp (Exim 4.24) id 1EdcKX-0006v4-7o for ccamp-archive@ietf.org; Sat, 19 Nov 2005 18:41:14 -0500 Received: from sup@localhost by ZQP.int (8.11.6/8.11.6); Sun, 20 Nov 2005 04:01:01 +0400 Message-ID: From: "Erica Lyles" Reply-To: "Erica Lyles" To: ccamp-archive@ietf.org Subject: Systemworks software for 80 % 0ff Date: Sat, 19 Nov 2005 21:57:01 -0200 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.2730.2 X-Sender: NorahLacey@boombull.com Content-Type: multipart/mixed; boundary="--UmgxgEvfZMMjfpdkAPUL" X-Spam-Score: 0.2 (/) X-Scan-Signature: a4cdc653ecdd96665f2aa1c1af034c9e 3R9 ----UmgxgEvfZMMjfpdkAPUL Content-Type: text/html; Content-Transfer-Encoding: quoted-printable E
Opt-in Email Special Offer   = ;  unsubscribe me
= =
SEARCH

Microsoft Window= s XP Professional *w/SP2*
Microsoft

<= tr vAlign=3Dtop bgColor=3D#333399>

TOP 10 NEW TITLES

=
=  <= /tr>
<= p align=3Dcenter>  ON SALE NOW!

 = ;1 Windows XP Pro SP2
 = ;2 Creative Suite 2
 3 MS Office 2003 Pro
 4 Adobe Acrobat 7 Pro
 <= /td>5 Macromedia Flash 8
 = 6 Dreamweaver 8
 7= Norton Sysworks 2005
 8 Adobe GoLive CS2
 9 Adobe Illustrator CS2
 = ;10 Borland Architect 2005
&= nbsp; See more by this manufacturer
   Microsoft
   Macromedia
  Ado= be
  Customers also b= ought
   these other items...

<= /p>

Choose:<= /b>
=  <= input type=3Dimage alt=3DGo src=3Dhttp://g-images.amazon.com/images/G/01/s= earch-browse/go-button-software.gif value=3DGo border=3D0 name=3Dsubmit.di= splay-variation width=3D21 height=3D21>
<= /tr>
List Price:$299.00
Price:$49.99
Y= ou Save:$249.01 (80%)


Availability: Available for INSTANT download= !
Coupon Code: xqJccykxl
Platform: Windows XP

Sales Rank: #1
System requirements  |  Other Versions
Date C= oupon Expires: December 31st, 2005
Av= erage Customer Review:3D"5 Based on 151125 reviews. Write a review.

=

Adobe Creative Suite 2= *Premium*
A= dobe

Choose:<= tr>
 

List Price:<= /b>$1199.00
Price:$149.99
You Save:$1049.01 (95%)


Availability: Available for INSTANT download!
Coupon Code= : YZXVW
Platform: Windows XP

Sales Rank: = #2
System= requirements  |  Other Ve= rsions
Date Coupon Expires: Decem= ber 31st, 2005
Average Customer Review:3D"5 Based on 191882 reviews. Writ= e a review.

Microsoft Office 2003 *Professi= onal*
Micros= oft

Choose:<= tr>
 

You Save:



Availability: Available for INSTANT downl= oad!
Coupon Code: ODQv4D2k
Platform: Windows XP

Sales Rank: #3
System requirements  |  Other Versions
Date C= oupon Expires: December 31st, 2005
Av= erage Customer Review:3D"5 Based on 16534 reviews. Write a review.

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

Adobe Acro= bat Professional V 7.0
Adobe

Choose:
<= /td> 

List Price:<= /b>$499.00
Price:$69.99
You Save:$429.01 (85%)



= Availability: Available for INSTANT download!
Coupon Code: CTDyD
Platform: Windows XP

Sales Rank: #4<= /span>
System re= quirements  |  Other Versi= ons
Date Coupon Expires: December= 31st, 2005
Average Customer Review:<= img height=3D12 alt=3D"5 out of 5 stars" src=3Dhttp://g-images.amazon.com/= images/G/01/x-locale/common/customer-reviews/stars-5-0.gif width=3D64 bord= er=3D0> Based on 1882 reviews. Write a r= eview.

----UmgxgEvfZMMjfpdkAPUL-- From owner-ccamp@ops.ietf.org Sun Nov 20 10:05:37 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Edql6-00005L-LB for ccamp-archive@megatron.ietf.org; Sun, 20 Nov 2005 10:05:37 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24240 for ; Sun, 20 Nov 2005 10:04:59 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Edr3K-0003gc-NZ for ccamp-archive@ietf.org; Sun, 20 Nov 2005 10:24:29 -0500 Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EdqdY-000P3X-WA for ccamp-data@psg.com; Sun, 20 Nov 2005 14:57:49 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [64.102.122.148] (helo=rtp-iport-1.cisco.com) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1EdqdX-000P3B-Bp for ccamp@ops.ietf.org; Sun, 20 Nov 2005 14:57:47 +0000 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 20 Nov 2005 06:57:37 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.97,354,1125903600"; d="scan'208"; a="15629467:sNHT27273040" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id jAKEvWln023541; Sun, 20 Nov 2005 09:57:33 -0500 (EST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 20 Nov 2005 09:57:32 -0500 Received: from [192.168.1.100] ([10.82.209.75]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 20 Nov 2005 09:57:31 -0500 In-Reply-To: <01ae01c5ed24$891c5c70$6601a8c0@movaz.com> References: <05d401c5ebb8$f343bde0$d501a8c0@Puppy> <437DFA01.9080804@psg.com> <01ae01c5ed24$891c5c70$6601a8c0@movaz.com> Mime-Version: 1.0 (Apple Message framework v734) X-Priority: 3 Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: Cc: , , "Adrian Farrel" , "LE ROUX Jean-Louis RD-CORE-LAN" , Content-Transfer-Encoding: quoted-printable From: JP Vasseur Subject: Re: IGP Extensions - CCAMP Milestones Date: Sun, 20 Nov 2005 09:57:01 -0500 To: Igor Bryskin X-Mailer: Apple Mail (2.734) X-OriginalArrivalTime: 20 Nov 2005 14:57:31.0658 (UTC) FILETIME=[BBA6A6A0:01C5EDE2] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: e654cfa5e44bd623be3eb2c720858b05 Content-Transfer-Encoding: quoted-printable Hi Igor, On Nov 19, 2005, at 11:16 AM, Igor Bryskin wrote: > Hi everybody, > > > > I'd like to note that although the AS scope flooding is allowed for =20= > opaque > LSAs, in my experience it does not work. So your experience is different than the one of many people ... =20 Opaque LSA have been used for quite a few years without any problem. See RFC2370 (July 1998) > Imagine that some routing > controller advertises an AS scope LSA and goes out of service =20 > quickly after > that. Controllers outside of the area that the dead controller =20 > belongs to > have no way of detecting its death and, therefore, will keep using the > advertising for another 90 min before the LSA times out. I guess that you mean 60 min (Maxage=3D60mn, Architectural Constant) - =20= See RFC2328, but this is not the point, see below. > Note that the > controllers located within the same area do not have such a problem =20= > because > they can always verify the validity of the advertising by trying to =20= > locate a > sequence of active adjacencies interconnecting each of them with the > advertising controller. If they find at least one such a sequence, the > advertising is valid (otherwise, it would be withdrawn); on the =20 > other hand, > if no such sequences exist, than advertising is likely to be stale =20 > and hence > could not be trusted. The conclusion is that opaque LSAs should =20 > never be > flooded within AS, rather, within a single area, and, if there is a =20= > need for > the information to be propagated beyond the area boundaries, ABRs =20 > must relay > the advertising into other areas (by originating new area-scope =20 > LSAs). Note > also that as far as I remember OSPF itself never uses AS scope =20 > advertisings > for its own needs. For example, an ASBR does not distribute =20 > external routes > learned by BGP from other ASs using AS scope LSAs, rather, the =20 > routes are > advertised within a single area and ABRs relay the advertisings =20 > into other > areas. This is not correct. External routes are redistributed with LSA Type =20 5 which are flooded across the entire domain except in stub-area (not generated by the ABR as type 3 as you mention). Anyway, back to the point, one cannot say of course that "Opaque LSA Type 11 does not work". There are suitable to some application, this is all. You can perfectly reply on an opaque LSA Type 11 to learn the capability of a router which does not reside in the local area and rely on another mechanism to detect its liveness. There are several such examples. Hope this helps. JP. > > > > The bottom line is that the TLVs described in the draft should be =20 > of the > area scope (just like TE LSAs), and hence it is not all that important > whether we use new high level TLVs or sub-TLVs of the TE router cap =20= > TLV. > > > > Igor > > > > > > ----- Original Message ----- > > From: "dimitri papadimitriou" > > To: "Adrian Farrel" > > Cc: "LE ROUX Jean-Louis RD-CORE-LAN" =20 > ; > "JP Vasseur" ; "Dimitri Papadimitriou" > ; > > Sent: Friday, November 18, 2005 10:57 AM > > Subject: Re: IGP Extensions - CCAMP Milestones > > > > >> adrian >> >> i think JL's reply did partially translate the initial concern >> >> in brief, there are three well identified TE applications that could >> make use of the TE node cap TLVs on both intra and inter-area basis: >> - LSP Stitching edge node capability >> - Edge nodes connecting/being P2MP TE egresses >> - TE auto-mesh >> >> hence, the question on why keeping separated TLVs as part of the =20 >> router >> capability and not consider these as sub-TLVs of the TE router cap =20= >> TLV >> this would >> 1) provide a logical grouping of TE sub-TLVs as part of the same =20 >> TLV and >> 2) leave the flexibility of flooding scope on a per application =20 >> need - >> >> note: that the path computation specific sub-TLVs could still be >> restricted with their current area-scope >> >> hope this clarifies the issue, >> >> thanks, >> - dimitri. >> >> Adrian Farrel wrote: >> >> >>> If I understand the question it is... >>> >>> In draft-ietf-ospf-cap-07.txt introduces the OSPF router =20 >>> information LSA >>> and states that this LSA may have type 9, 10 or 11 scope. >>> >>> In draft-vasseur-ccamp-te-node-cap-01.txt a new TLV (TE Node =20 >>> Capability >>> Descriptor) is added to the OSPF router information LSA. This TLV =20= >>> (when >>> generated) MUST be advertised with type 10 scope. JL has given the >>> > reason > >>> why this is limited to type 10. This reason is, of course, open for >>> discussion as he says. >>> >>> In draft-vasseur-ccamp-automesh-02.txt a new TLV (TE-MESH-GROUP) is >>> > added > >>> to the OSPF router information LSA. It states that the LSA may be >>> advertised with type 10 or type 11 scope. JP has given a reason =20 >>> why you >>> might want type 11 in addition to type 10. This reason is, of =20 >>> course, >>> > open > >>> for discussion. >>> >>> An interesting feature is that a router advertising an AS-wide mesh >>> > group > >>> *and* a TE router capability may require that two OSPF router >>> > information > >>> LSAs are advertised by the router. >>> >>> The language in draft-ietf-ospf-cap-07.txt leans towards a router >>> > sending > >>> *an* OSPF router information LSA. But nowhere does it say that the >>> > router > >>> cannot send more than one and in section 2.5 we find... >>> The originating router MAY advertise >>> multiple RI LSAs as long as the flooding scopes differ. >>> >>> Hope this answers the point. >>> >>> Adrian >>> ----- Original Message ----- >>> From: "LE ROUX Jean-Louis RD-CORE-LAN" >>> >>> To: "JP Vasseur" ; "Dimitri Papadimitriou" >>> ; "Dimitri Papadimitriou" >>> >>> Cc: ; >>> Sent: Thursday, November 17, 2005 6:47 PM >>> Subject: RE: IGP Extensions - CCAMP Milestones >>> >>> >>> Hi Dimitri, >>> >>> Thanks for the comment. >>> >>> As just explained by JP, the TE Node Cap TLV carries topology =20 >>> related >>> parameters used as constraints in path computation. The leaking =20 >>> of such >>> info across areas sounds useless as LSR TE visibility is limited =20 >>> to one >>> area anyway... >>> But this is, of course, open to discussions. By the way, do you =20 >>> have any >>> application in mind where such leaking would be useful? >>> >>> Regards, >>> >>> JL >>> >>> >>> >>> >>> >>> >>> >>> >>>> -----Message d'origine----- >>>> De : JP Vasseur [mailto:jvasseur@cisco.com] >>>> Envoy=E9 : jeudi 17 novembre 2005 16:58 >>>> =C0 : Dimitri Papadimitriou; Dimitri Papadimitriou >>>> Cc : zzx-adrian@olddog.co.uk; ccamp@ops.ietf.org; LE ROUX >>>> Jean-Louis RD-CORE-LAN >>>> Objet : Re: IGP Extensions - CCAMP Milestones >>>> >>>> Hi dimitri, >>>> >>>> On Nov 16, 2005, at 6:30 PM, dimitri papadimitriou wrote: >>>> >>>> >>>> >>>>> adrian, >>>>> >>>>> could you explain the reasoning for having a TE specific TLV in =20= >>>>> the >>>>> auto-mesh document with area and AS-wide flooding scope >>>>> >>>> >>>> while the TE >>>> >>>> >>>>> router cap TLV is restricted to an area flooding scope ? >>>>> shouldn't be one way or the other i.e. either restrict all TE info >>>>> area-local or allow for TE router cap TLV with AS-wide >>>>> >>>> >>>> flooding scope >>>> >>>> >>>>> ? >>>>> >>>>> note: there is nothing in the TE router cap TLV that would impact >>>>> scaling more than the TE auto-mesh TLV does >>>>> >>>>> >>>> >>>> I guess that the reason for allowing both intra and inter-area >>>> flooding scopes for automesh is obvious (we need to have TE LSP =20 >>>> mesh >>>> within areas and spanning multiple areas). >>>> >>>> So your question is probably why don't we allow the TE router >>>> cap TLV >>>> to be flooded across the domain ? As far as I can remember JL >>>> already >>>> answered this question ... JL, could you forward your email again ? >>>> >>>> In the meantime, I can answer it: the reason is that such TE node >>>> capabilities are used for TE LSP computation which cannot take into >>>> account nodes that do not reside in the node's area. >>>> >>>> Thanks. >>>> >>>> JP. >>>> >>>> >>>> >>>>> thanks, >>>>> - dimitri. >>>>> >>>>> Adrian Farrel wrote: >>>>> >>>>> >>>>> >>>>> >>>>>> Hi, >>>>>> We have two immediate milestones to address: >>>>>> Oct 05 First version WG I-D for Advertising TE Node Capabilities >>>>>> in ISIS >>>>>> and OSPF >>>>>> Oct 05 First version WG I-D for Automatic discovery of >>>>>> >>>> >>>> MPLS-TE mesh >>>> >>>> >>>>>> membership >>>>>> There are two personal submissions which address these topics: >>>>>> draft-vasseur-ccamp-te-node-cap-01.txt >>>>>> draft-vasseur-ccamp-automesh-02.txt >>>>>> I propose that we move these into the WG and then kick the tires >>>>>> thoroughly. >>>>>> Opinions please. >>>>>> Thanks, >>>>>> Adrian >>>>>> . >>>>>> >>>>> >>>>> >>> >>> >>> >>> >>> . >>> >>> >> > From georgeg@a-electronics.com Sun Nov 20 13:13:42 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Edth8-0000ao-FO for ccamp-archive@megatron.ietf.org; Sun, 20 Nov 2005 13:13:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04564 for ; Sun, 20 Nov 2005 13:13:03 -0500 (EST) Received: from nc-71-49-188-124.dhcp.sprint-hsd.net ([71.49.188.124] helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EdtzP-00008F-0W for ccamp-archive@ietf.org; Sun, 20 Nov 2005 13:32:36 -0500 Message-ID: <000001c5edfd$46303380$0100007f@localhost> From: "Francisco Smith" To: Subject: Don't be left behing- the enlargement revolution! Date: Sun, 20 Nov 2005 18:13:45 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C5EDFD.46303380" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 3.0 (+++) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C5EDFD.46303380 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable.TOP.10.NEW.TITLES.ON.SALE.NOW!.1.Office.Pro.2003.2.Adobe.Photoshop.9.0.3.Windows.XP.Pro.4.Adobe.Acrobat.7.Pro.5.Flash.MX.2004.6.Corel.Draw.12.7.Norton.Antivirus.2005.8.Windows.2003.Se ListPrice: $550.00 OurPrice: $69.95 YouSave: $480.05 ( 87%) Availability: Available for INSTANT download! Sales Rank: #1 Average Customer Review: (based on 45 reviews) -------------------------------------------------------------------------------- Microsoft Windows XP Professional by Microsoft ListPrice: $200.00 OurPrice: $49.95 YouSave: $150.05 ( 75%) Availability: Available for INSTANT download! Sales Rank: #2 Average Customer Review: (based on 37 reviews) -------------------------------------------------------------------------------- Adobe Photoshop CS2 V 9.0 by Adobe ListPrice: $599.00 OurPrice: $69.95 YouSave: $529.05 ( 88%) Availability: Available for INSTANT download! Sales Rank: #3 Average Customer Review: (based on 40 reviews) -------------------------------------------------------------------------------- ------=_NextPart_000_0001_01C5EDFD.46303380 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Software

TOP 10 NEW TITLES

 ON SALE NOW!

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

Microsoft Office Professional Edition 2003
   by Microsoft

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



Availability: Available for INSTANT download!


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

Microsoft Windows XP Professional
   by Microsoft

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



Availability: Available for INSTANT download!


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

Adobe Photoshop CS2 V 9.0
   by Adobe

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



Availability: Available for INSTANT download!


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

------=_NextPart_000_0001_01C5EDFD.46303380-- From owner-ccamp@ops.ietf.org Sun Nov 20 14:48:45 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdvB6-0004qO-AN for ccamp-archive@megatron.ietf.org; Sun, 20 Nov 2005 14:48:44 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09529 for ; Sun, 20 Nov 2005 14:48:07 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EdvTN-0002Yr-4V for ccamp-archive@ietf.org; Sun, 20 Nov 2005 15:07:39 -0500 Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1Edv3B-000Cui-Ng for ccamp-data@psg.com; Sun, 20 Nov 2005 19:40:33 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-4.8 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from localhost ([127.0.0.1]) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1Edv38-000CuK-VY; Sun, 20 Nov 2005 19:40:31 +0000 Message-ID: <4380D135.2080202@psg.com> Date: Sun, 20 Nov 2005 20:40:37 +0100 From: dimitri papadimitriou Reply-To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.11) Gecko/20050728 X-Accept-Language: en-us, en MIME-Version: 1.0 To: JP Vasseur CC: Igor Bryskin , dimitri.papadimitriou@alcatel.be, Adrian Farrel , LE ROUX Jean-Louis RD-CORE-LAN , ccamp@ops.ietf.org Subject: Re: IGP Extensions - CCAMP Milestones References: <05d401c5ebb8$f343bde0$d501a8c0@Puppy> <437DFA01.9080804@psg.com> <01ae01c5ed24$891c5c70$6601a8c0@movaz.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: d8921dd2ebcb07edebf7bfaf4808c2ad Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id OAA09529 hi jp, indeed, i don't really understand the issue brought up by igor; in the present case, one should also underline that, the information=20 distributed across the OSPF domain using opaque LSAs, is *indirectly*=20 used by e.g. TE applications (note: RFC2370 allows for this information=20 to be used directly by OSPF but i think we're not discussing this=20 alternative) this means that these e.g. TE applications can in case of control engine=20 failure detect this failure and trigger any necessary action in order to=20 avoid the behaviour described by igor thanks, - dimitri. JP Vasseur wrote: > Hi Igor, >=20 > On Nov 19, 2005, at 11:16 AM, Igor Bryskin wrote: >=20 >> Hi everybody, >> >> >> >> I'd like to note that although the AS scope flooding is allowed for =20 >> opaque >> LSAs, in my experience it does not work. >=20 >=20 > So your experience is different than the one of many people ... Opaque= =20 > LSA have been > used for quite a few years without any problem. See RFC2370 (July 1998) >=20 >> Imagine that some routing >> controller advertises an AS scope LSA and goes out of service quickly= =20 >> after >> that. Controllers outside of the area that the dead controller =20 >> belongs to >> have no way of detecting its death and, therefore, will keep using the >> advertising for another 90 min before the LSA times out. >=20 >=20 > I guess that you mean 60 min (Maxage=3D60mn, Architectural Constant) - = =20 > See RFC2328, but this is not the point, see below. >=20 >> Note that the >> controllers located within the same area do not have such a problem =20 >> because >> they can always verify the validity of the advertising by trying to =20 >> locate a >> sequence of active adjacencies interconnecting each of them with the >> advertising controller. If they find at least one such a sequence, the >> advertising is valid (otherwise, it would be withdrawn); on the other= =20 >> hand, >> if no such sequences exist, than advertising is likely to be stale =20 >> and hence >> could not be trusted. The conclusion is that opaque LSAs should never= be >> flooded within AS, rather, within a single area, and, if there is a =20 >> need for >> the information to be propagated beyond the area boundaries, ABRs =20 >> must relay >> the advertising into other areas (by originating new area-scope =20 >> LSAs). Note >> also that as far as I remember OSPF itself never uses AS scope =20 >> advertisings >> for its own needs. For example, an ASBR does not distribute external=20 >> routes >> learned by BGP from other ASs using AS scope LSAs, rather, the routes= =20 >> are >> advertised within a single area and ABRs relay the advertisings into=20 >> other >> areas. >=20 >=20 > This is not correct. External routes are redistributed with LSA Type 5= =20 > which are > flooded across the entire domain except in stub-area (not generated by > the ABR as type 3 as you mention). >=20 > Anyway, back to the point, one cannot say of course that "Opaque LSA > Type 11 does not work". There are suitable to some application, this is > all. You can perfectly reply on an opaque LSA Type 11 to learn the > capability of a router which does not reside in the local area and rely > on another mechanism to detect its liveness. There are several such > examples. >=20 > Hope this helps. >=20 > JP. >=20 >=20 >> >> >> >> The bottom line is that the TLVs described in the draft should be of = the >> area scope (just like TE LSAs), and hence it is not all that important >> whether we use new high level TLVs or sub-TLVs of the TE router cap T= LV. >> >> >> >> Igor >> >> >> >> >> >> ----- Original Message ----- >> >> From: "dimitri papadimitriou" >> >> To: "Adrian Farrel" >> >> Cc: "LE ROUX Jean-Louis RD-CORE-LAN" =20 >> ; >> "JP Vasseur" ; "Dimitri Papadimitriou" >> ; >> >> Sent: Friday, November 18, 2005 10:57 AM >> >> Subject: Re: IGP Extensions - CCAMP Milestones >> >> >> >> >>> adrian >>> >>> i think JL's reply did partially translate the initial concern >>> >>> in brief, there are three well identified TE applications that could >>> make use of the TE node cap TLVs on both intra and inter-area basis: >>> - LSP Stitching edge node capability >>> - Edge nodes connecting/being P2MP TE egresses >>> - TE auto-mesh >>> >>> hence, the question on why keeping separated TLVs as part of the rou= ter >>> capability and not consider these as sub-TLVs of the TE router cap T= LV >>> this would >>> 1) provide a logical grouping of TE sub-TLVs as part of the same TLV= =20 >>> and >>> 2) leave the flexibility of flooding scope on a per application need= - >>> >>> note: that the path computation specific sub-TLVs could still be >>> restricted with their current area-scope >>> >>> hope this clarifies the issue, >>> >>> thanks, >>> - dimitri. >>> >>> Adrian Farrel wrote: >>> >>> >>>> If I understand the question it is... >>>> >>>> In draft-ietf-ospf-cap-07.txt introduces the OSPF router =20 >>>> information LSA >>>> and states that this LSA may have type 9, 10 or 11 scope. >>>> >>>> In draft-vasseur-ccamp-te-node-cap-01.txt a new TLV (TE Node =20 >>>> Capability >>>> Descriptor) is added to the OSPF router information LSA. This TLV =20 >>>> (when >>>> generated) MUST be advertised with type 10 scope. JL has given the >>>> >> reason >> >>>> why this is limited to type 10. This reason is, of course, open for >>>> discussion as he says. >>>> >>>> In draft-vasseur-ccamp-automesh-02.txt a new TLV (TE-MESH-GROUP) is >>>> >> added >> >>>> to the OSPF router information LSA. It states that the LSA may be >>>> advertised with type 10 or type 11 scope. JP has given a reason why= =20 >>>> you >>>> might want type 11 in addition to type 10. This reason is, of cours= e, >>>> >> open >> >>>> for discussion. >>>> >>>> An interesting feature is that a router advertising an AS-wide mesh >>>> >> group >> >>>> *and* a TE router capability may require that two OSPF router >>>> >> information >> >>>> LSAs are advertised by the router. >>>> >>>> The language in draft-ietf-ospf-cap-07.txt leans towards a router >>>> >> sending >> >>>> *an* OSPF router information LSA. But nowhere does it say that the >>>> >> router >> >>>> cannot send more than one and in section 2.5 we find... >>>> The originating router MAY advertise >>>> multiple RI LSAs as long as the flooding scopes differ. >>>> >>>> Hope this answers the point. >>>> >>>> Adrian >>>> ----- Original Message ----- >>>> From: "LE ROUX Jean-Louis RD-CORE-LAN" >>>> >>>> To: "JP Vasseur" ; "Dimitri Papadimitriou" >>>> ; "Dimitri Papadimitriou" >>>> >>>> Cc: ; >>>> Sent: Thursday, November 17, 2005 6:47 PM >>>> Subject: RE: IGP Extensions - CCAMP Milestones >>>> >>>> >>>> Hi Dimitri, >>>> >>>> Thanks for the comment. >>>> >>>> As just explained by JP, the TE Node Cap TLV carries topology relat= ed >>>> parameters used as constraints in path computation. The leaking of=20 >>>> such >>>> info across areas sounds useless as LSR TE visibility is limited to= =20 >>>> one >>>> area anyway... >>>> But this is, of course, open to discussions. By the way, do you =20 >>>> have any >>>> application in mind where such leaking would be useful? >>>> >>>> Regards, >>>> >>>> JL >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>> -----Message d'origine----- >>>>> De : JP Vasseur [mailto:jvasseur@cisco.com] >>>>> Envoy=E9 : jeudi 17 novembre 2005 16:58 >>>>> =C0 : Dimitri Papadimitriou; Dimitri Papadimitriou >>>>> Cc : zzx-adrian@olddog.co.uk; ccamp@ops.ietf.org; LE ROUX >>>>> Jean-Louis RD-CORE-LAN >>>>> Objet : Re: IGP Extensions - CCAMP Milestones >>>>> >>>>> Hi dimitri, >>>>> >>>>> On Nov 16, 2005, at 6:30 PM, dimitri papadimitriou wrote: >>>>> >>>>> >>>>> >>>>>> adrian, >>>>>> >>>>>> could you explain the reasoning for having a TE specific TLV in t= he >>>>>> auto-mesh document with area and AS-wide flooding scope >>>>>> >>>>> >>>>> while the TE >>>>> >>>>> >>>>>> router cap TLV is restricted to an area flooding scope ? >>>>>> shouldn't be one way or the other i.e. either restrict all TE info >>>>>> area-local or allow for TE router cap TLV with AS-wide >>>>>> >>>>> >>>>> flooding scope >>>>> >>>>> >>>>>> ? >>>>>> >>>>>> note: there is nothing in the TE router cap TLV that would impact >>>>>> scaling more than the TE auto-mesh TLV does >>>>>> >>>>>> >>>>> >>>>> I guess that the reason for allowing both intra and inter-area >>>>> flooding scopes for automesh is obvious (we need to have TE LSP me= sh >>>>> within areas and spanning multiple areas). >>>>> >>>>> So your question is probably why don't we allow the TE router >>>>> cap TLV >>>>> to be flooded across the domain ? As far as I can remember JL >>>>> already >>>>> answered this question ... JL, could you forward your email again ? >>>>> >>>>> In the meantime, I can answer it: the reason is that such TE node >>>>> capabilities are used for TE LSP computation which cannot take into >>>>> account nodes that do not reside in the node's area. >>>>> >>>>> Thanks. >>>>> >>>>> JP. >>>>> >>>>> >>>>> >>>>>> thanks, >>>>>> - dimitri. >>>>>> >>>>>> Adrian Farrel wrote: >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> Hi, >>>>>>> We have two immediate milestones to address: >>>>>>> Oct 05 First version WG I-D for Advertising TE Node Capabilities >>>>>>> in ISIS >>>>>>> and OSPF >>>>>>> Oct 05 First version WG I-D for Automatic discovery of >>>>>>> >>>>> >>>>> MPLS-TE mesh >>>>> >>>>> >>>>>>> membership >>>>>>> There are two personal submissions which address these topics: >>>>>>> draft-vasseur-ccamp-te-node-cap-01.txt >>>>>>> draft-vasseur-ccamp-automesh-02.txt >>>>>>> I propose that we move these into the WG and then kick the tires >>>>>>> thoroughly. >>>>>>> Opinions please. >>>>>>> Thanks, >>>>>>> Adrian >>>>>>> . >>>>>>> >>>>>> >>>>>> >>>> >>>> >>>> >>>> >>>> . >>>> >>>> >>> >> >=20 >=20 > . >=20 From owner-ccamp@ops.ietf.org Sun Nov 20 16:39:38 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdwuQ-0003He-4O for ccamp-archive@megatron.ietf.org; Sun, 20 Nov 2005 16:39:38 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14845 for ; Sun, 20 Nov 2005 16:39:00 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EdxCj-0005Pa-0f for ccamp-archive@ietf.org; Sun, 20 Nov 2005 16:58:34 -0500 Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1Edwq9-000ID9-Ra for ccamp-data@psg.com; Sun, 20 Nov 2005 21:35:13 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [195.101.245.16] (helo=p-mail2.rd.francetelecom.com) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1Edwq8-000ICk-I9 for ccamp@ops.ietf.org; Sun, 20 Nov 2005 21:35:12 +0000 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211); Sun, 20 Nov 2005 22:35:08 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: IGP Extensions - CCAMP Milestones Date: Sun, 20 Nov 2005 22:35:06 +0100 Message-ID: Thread-Topic: IGP Extensions - CCAMP Milestones Thread-Index: AcXrtxthMkATK+ZaQEmpKPeLheHSMACYF3vQ From: "LE ROUX Jean-Louis RD-CORE-LAN" To: , Cc: "JP Vasseur" , , X-OriginalArrivalTime: 20 Nov 2005 21:35:08.0816 (UTC) FILETIME=[47A01100:01C5EE1A] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 200d029292fbb60d25b263122ced50fc Content-Transfer-Encoding: quoted-printable Hi Dimitri=20 > -----Message d'origine----- > De : dimitri papadimitriou [mailto:dpapadimitriou@psg.com]=20 > Envoy=E9 : jeudi 17 novembre 2005 21:40 > =C0 : LE ROUX Jean-Louis RD-CORE-LAN > Cc : JP Vasseur; Dimitri Papadimitriou;=20 > zzx-adrian@olddog.co.uk; ccamp@ops.ietf.org > Objet : Re: IGP Extensions - CCAMP Milestones >=20 > hi jean-louis >=20 > LE ROUX Jean-Louis RD-CORE-LAN wrote: >=20 > > Hi Dimitri, > >=20 > > Thanks for the comment. > >=20 > > As just explained by JP, the TE Node Cap TLV carries=20 > topology related=20 > > parameters used as constraints in path computation. The leaking of=20 > > such info across areas sounds useless as LSR TE visibility=20 > is limited=20 > > to one area anyway... But this is, of course, open to=20 > discussions. By=20 > > the way, do you have any application in mind where such=20 > leaking would=20 > > be useful? >=20 > stitching capability is the major application i see for the=20 > time being - others will more than probably come when=20 > technology specific application will progress (VCAT support=20 > is a good example here but this is for further discussion) OK, we will have to take this point into account and discuss further = what could be the actual need for leaking such capabilites across area = boundaries. Regards, JL >=20 > note: i would like also to point out that "capability"=20 > advertisement that are of the following nature >=20 > 1. exchanged on a per node basis > 2. variation of the information value >>> LS refresh time 3.=20 > usage of the information and setting up LSP across these nodes does > not trigger any LS update >=20 > are not scaling impacting more than any other inter-area=20 > routing information exchanged per current OSPF/IS-IS RFCs >=20 > > Regards, > >=20 > > JL > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >> -----Message d'origine----- De : JP Vasseur=20 > >> [mailto:jvasseur@cisco.com] Envoy=E9 : jeudi 17 novembre 2005 16:58 = =C0 > >> : Dimitri Papadimitriou; Dimitri Papadimitriou Cc : > >> zzx-adrian@olddog.co.uk; ccamp@ops.ietf.org; LE ROUX Jean-Louis=20 > >> RD-CORE-LAN Objet : Re: IGP Extensions - CCAMP Milestones > >>=20 > >> Hi dimitri, > >>=20 > >> On Nov 16, 2005, at 6:30 PM, dimitri papadimitriou wrote: > >>=20 > >>=20 > >>> adrian, > >>>=20 > >>> could you explain the reasoning for having a TE specific=20 > TLV in the=20 > >>> auto-mesh document with area and AS-wide flooding scope > >>=20 > >> while the TE > >>=20 > >>> router cap TLV is restricted to an area flooding scope ?=20 > >>> shouldn't be one way or the other i.e. either restrict=20 > all TE info=20 > >>> area-local or allow for TE router cap TLV with AS-wide > >>=20 > >> flooding scope > >>=20 > >>> ? > >>>=20 > >>> note: there is nothing in the TE router cap TLV that=20 > would impact =20 > >>> scaling more than the TE auto-mesh TLV does > >>>=20 > >>=20 > >> I guess that the reason for allowing both intra and inter-area=20 > >> flooding scopes for automesh is obvious (we need to have=20 > TE LSP mesh=20 > >> within areas and spanning multiple areas). > >>=20 > >> So your question is probably why don't we allow the TE=20 > router cap TLV=20 > >> to be flooded across the domain ? As far as I can remember=20 > JL already=20 > >> answered this question ... JL, could you forward your email again ? > >>=20 > >> In the meantime, I can answer it: the reason is that such TE node =20 > >> capabilities are used for TE LSP computation which cannot=20 > take into=20 > >> account nodes that do not reside in the node's area. > >>=20 > >> Thanks. > >>=20 > >> JP. > >>=20 > >>=20 > >>> thanks, - dimitri. > >>>=20 > >>> Adrian Farrel wrote: > >>>=20 > >>>=20 > >>>=20 > >>>> Hi, We have two immediate milestones to address: Oct 05 First=20 > >>>> version WG I-D for Advertising TE Node Capabilities in ISIS and=20 > >>>> OSPF Oct 05 First version WG I-D for Automatic discovery of > >>=20 > >> MPLS-TE mesh > >>=20 > >>>> membership There are two personal submissions which=20 > address these=20 > >>>> topics: draft-vasseur-ccamp-te-node-cap-01.txt > >>>> draft-vasseur-ccamp-automesh-02.txt I propose that we move these=20 > >>>> into the WG and then kick the tires thoroughly. Opinions please.=20 > >>>> Thanks, Adrian . > >>>=20 > >=20 > >=20 > > . > >=20 >=20 From owner-ccamp@ops.ietf.org Mon Nov 21 10:25:34 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeDXy-0005x2-24 for ccamp-archive@megatron.ietf.org; Mon, 21 Nov 2005 10:25:34 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07854 for ; Mon, 21 Nov 2005 10:24:56 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EeDqM-0006Fg-Sz for ccamp-archive@ietf.org; Mon, 21 Nov 2005 10:44:39 -0500 Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EeDMq-0000yx-74 for ccamp-data@psg.com; Mon, 21 Nov 2005 15:14:04 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [70.158.43.219] (helo=jera.movaz.com) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1EeDMo-0000yj-HP for ccamp@ops.ietf.org; Mon, 21 Nov 2005 15:14:03 +0000 Received: from ib (unknown [172.16.24.122]) by jera.movaz.com (Postfix) with SMTP id DDACD11B0B; Mon, 21 Nov 2005 10:13:22 -0500 (EST) Message-ID: <00aa01c5eeae$31737ea0$7a1810ac@movaz.com> From: "Igor Bryskin" To: "JP Vasseur" Cc: , , "Adrian Farrel" , "LE ROUX Jean-Louis RD-CORE-LAN" , References: <05d401c5ebb8$f343bde0$d501a8c0@Puppy> <437DFA01.9080804@psg.com> <01ae01c5ed24$891c5c70$6601a8c0@movaz.com> Subject: Re: IGP Extensions - CCAMP Milestones Date: Mon, 21 Nov 2005 10:13:56 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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: 9178bae9f85419fdc08e9f2c86e345d0 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id KAA07854 Hi JP, See in-line. Cheers, Igor ----- Original Message -----=20 From: "JP Vasseur" To: "Igor Bryskin" Cc: ; ; "Adrian Farrel" ; "LE ROUX Jean-Louis RD-CORE-LAN" ; Sent: Sunday, November 20, 2005 9:57 AM Subject: Re: IGP Extensions - CCAMP Milestones Hi Igor, On Nov 19, 2005, at 11:16 AM, Igor Bryskin wrote: > Hi everybody, > > > > I'd like to note that although the AS scope flooding is allowed for > opaque > LSAs, in my experience it does not work. So your experience is different than the one of many people ... Opaque LSA have been used for quite a few years without any problem. See RFC2370 (July 1998) > Imagine that some routing > controller advertises an AS scope LSA and goes out of service > quickly after > that. Controllers outside of the area that the dead controller > belongs to > have no way of detecting its death and, therefore, will keep using the > advertising for another 90 min before the LSA times out. I guess that you mean 60 min (Maxage=3D60mn, Architectural Constant) - See RFC2328, but this is not the point, see below. > Note that the > controllers located within the same area do not have such a problem > because > they can always verify the validity of the advertising by trying to > locate a > sequence of active adjacencies interconnecting each of them with the > advertising controller. If they find at least one such a sequence, the > advertising is valid (otherwise, it would be withdrawn); on the > other hand, > if no such sequences exist, than advertising is likely to be stale > and hence > could not be trusted. The conclusion is that opaque LSAs should > never be > flooded within AS, rather, within a single area, and, if there is a > need for > the information to be propagated beyond the area boundaries, ABRs > must relay > the advertising into other areas (by originating new area-scope > LSAs). Note > also that as far as I remember OSPF itself never uses AS scope > advertisings > for its own needs. For example, an ASBR does not distribute > external routes > learned by BGP from other ASs using AS scope LSAs, rather, the > routes are > advertised within a single area and ABRs relay the advertisings > into other > areas. This is not correct. External routes are redistributed with LSA Type 5 which are flooded across the entire domain except in stub-area (not generated by the ABR as type 3 as you mention). IB>> True, that what is written in RFC2328. And my contention here is tha= t if an ASBR advertises LSAs type 5 and dies after that, than OSPF speakers outside of the ASBR's area have good likelihood to use stale external rou= tes for a considerable period of time. There is no remedy to that (OSPF speak= ers do not use Keep Alive protocol :=3D). This, however, could be fixed by avoiding using of AS scope flooding, and that's exactly the reason why so= me OSPF applications that I know of do just that. But this is the discussion for OSPF WG, I suggest not argue about that. See below. Anyway, back to the point, one cannot say of course that "Opaque LSA Type 11 does not work". There are suitable to some application, this is all. You can perfectly reply on an opaque LSA Type 11 to learn the capability of a router which does not reside in the local area and rely on another mechanism to detect its liveness. There are several such examples. IB>> Let's stick to your example. Why is it better to flood router capability LSAs across an AS, rather than flood them within a single area and have ABRs relay the advertisings into other areas by originating thei= r own LSAs? Yes, the AS-scope flooding is simpler. But what I am suggesting has the following advantages: a) Advertisings of a crashed LSR could be withdrawn from use by all = AS LSRs immediately after the crash; b) Advertisings could be summarized by an ABR providing scalability improvements; c) What is more important that policies could be applied on ABRs wrt= to what information is leaked to external areas. Regretfully, you keep forgetting about the policy aspects, but in the context of AS-scope flood= ing how can you enforce that an LSR capabilities are advertised into some are= as, not advertised into some other areas, and advertised in a modified way in= to the third set of areas? Igor Hope this helps. JP. > > > > The bottom line is that the TLVs described in the draft should be > of the > area scope (just like TE LSAs), and hence it is not all that important > whether we use new high level TLVs or sub-TLVs of the TE router cap > TLV. > > > > Igor > > > > > > ----- Original Message ----- > > From: "dimitri papadimitriou" > > To: "Adrian Farrel" > > Cc: "LE ROUX Jean-Louis RD-CORE-LAN" > ; > "JP Vasseur" ; "Dimitri Papadimitriou" > ; > > Sent: Friday, November 18, 2005 10:57 AM > > Subject: Re: IGP Extensions - CCAMP Milestones > > > > >> adrian >> >> i think JL's reply did partially translate the initial concern >> >> in brief, there are three well identified TE applications that could >> make use of the TE node cap TLVs on both intra and inter-area basis: >> - LSP Stitching edge node capability >> - Edge nodes connecting/being P2MP TE egresses >> - TE auto-mesh >> >> hence, the question on why keeping separated TLVs as part of the >> router >> capability and not consider these as sub-TLVs of the TE router cap >> TLV >> this would >> 1) provide a logical grouping of TE sub-TLVs as part of the same >> TLV and >> 2) leave the flexibility of flooding scope on a per application >> need - >> >> note: that the path computation specific sub-TLVs could still be >> restricted with their current area-scope >> >> hope this clarifies the issue, >> >> thanks, >> - dimitri. >> >> Adrian Farrel wrote: >> >> >>> If I understand the question it is... >>> >>> In draft-ietf-ospf-cap-07.txt introduces the OSPF router >>> information LSA >>> and states that this LSA may have type 9, 10 or 11 scope. >>> >>> In draft-vasseur-ccamp-te-node-cap-01.txt a new TLV (TE Node >>> Capability >>> Descriptor) is added to the OSPF router information LSA. This TLV >>> (when >>> generated) MUST be advertised with type 10 scope. JL has given the >>> > reason > >>> why this is limited to type 10. This reason is, of course, open for >>> discussion as he says. >>> >>> In draft-vasseur-ccamp-automesh-02.txt a new TLV (TE-MESH-GROUP) is >>> > added > >>> to the OSPF router information LSA. It states that the LSA may be >>> advertised with type 10 or type 11 scope. JP has given a reason >>> why you >>> might want type 11 in addition to type 10. This reason is, of >>> course, >>> > open > >>> for discussion. >>> >>> An interesting feature is that a router advertising an AS-wide mesh >>> > group > >>> *and* a TE router capability may require that two OSPF router >>> > information > >>> LSAs are advertised by the router. >>> >>> The language in draft-ietf-ospf-cap-07.txt leans towards a router >>> > sending > >>> *an* OSPF router information LSA. But nowhere does it say that the >>> > router > >>> cannot send more than one and in section 2.5 we find... >>> The originating router MAY advertise >>> multiple RI LSAs as long as the flooding scopes differ. >>> >>> Hope this answers the point. >>> >>> Adrian >>> ----- Original Message ----- >>> From: "LE ROUX Jean-Louis RD-CORE-LAN" >>> >>> To: "JP Vasseur" ; "Dimitri Papadimitriou" >>> ; "Dimitri Papadimitriou" >>> >>> Cc: ; >>> Sent: Thursday, November 17, 2005 6:47 PM >>> Subject: RE: IGP Extensions - CCAMP Milestones >>> >>> >>> Hi Dimitri, >>> >>> Thanks for the comment. >>> >>> As just explained by JP, the TE Node Cap TLV carries topology >>> related >>> parameters used as constraints in path computation. The leaking >>> of such >>> info across areas sounds useless as LSR TE visibility is limited >>> to one >>> area anyway... >>> But this is, of course, open to discussions. By the way, do you >>> have any >>> application in mind where such leaking would be useful? >>> >>> Regards, >>> >>> JL >>> >>> >>> >>> >>> >>> >>> >>> >>>> -----Message d'origine----- >>>> De : JP Vasseur [mailto:jvasseur@cisco.com] >>>> Envoy=E9 : jeudi 17 novembre 2005 16:58 >>>> =C0 : Dimitri Papadimitriou; Dimitri Papadimitriou >>>> Cc : zzx-adrian@olddog.co.uk; ccamp@ops.ietf.org; LE ROUX >>>> Jean-Louis RD-CORE-LAN >>>> Objet : Re: IGP Extensions - CCAMP Milestones >>>> >>>> Hi dimitri, >>>> >>>> On Nov 16, 2005, at 6:30 PM, dimitri papadimitriou wrote: >>>> >>>> >>>> >>>>> adrian, >>>>> >>>>> could you explain the reasoning for having a TE specific TLV in >>>>> the >>>>> auto-mesh document with area and AS-wide flooding scope >>>>> >>>> >>>> while the TE >>>> >>>> >>>>> router cap TLV is restricted to an area flooding scope ? >>>>> shouldn't be one way or the other i.e. either restrict all TE info >>>>> area-local or allow for TE router cap TLV with AS-wide >>>>> >>>> >>>> flooding scope >>>> >>>> >>>>> ? >>>>> >>>>> note: there is nothing in the TE router cap TLV that would impact >>>>> scaling more than the TE auto-mesh TLV does >>>>> >>>>> >>>> >>>> I guess that the reason for allowing both intra and inter-area >>>> flooding scopes for automesh is obvious (we need to have TE LSP >>>> mesh >>>> within areas and spanning multiple areas). >>>> >>>> So your question is probably why don't we allow the TE router >>>> cap TLV >>>> to be flooded across the domain ? As far as I can remember JL >>>> already >>>> answered this question ... JL, could you forward your email again ? >>>> >>>> In the meantime, I can answer it: the reason is that such TE node >>>> capabilities are used for TE LSP computation which cannot take into >>>> account nodes that do not reside in the node's area. >>>> >>>> Thanks. >>>> >>>> JP. >>>> >>>> >>>> >>>>> thanks, >>>>> - dimitri. >>>>> >>>>> Adrian Farrel wrote: >>>>> >>>>> >>>>> >>>>> >>>>>> Hi, >>>>>> We have two immediate milestones to address: >>>>>> Oct 05 First version WG I-D for Advertising TE Node Capabilities >>>>>> in ISIS >>>>>> and OSPF >>>>>> Oct 05 First version WG I-D for Automatic discovery of >>>>>> >>>> >>>> MPLS-TE mesh >>>> >>>> >>>>>> membership >>>>>> There are two personal submissions which address these topics: >>>>>> draft-vasseur-ccamp-te-node-cap-01.txt >>>>>> draft-vasseur-ccamp-automesh-02.txt >>>>>> I propose that we move these into the WG and then kick the tires >>>>>> thoroughly. >>>>>> Opinions please. >>>>>> Thanks, >>>>>> Adrian >>>>>> . >>>>>> >>>>> >>>>> >>> >>> >>> >>> >>> . >>> >>> >> > From owner-ccamp@ops.ietf.org Mon Nov 21 10:27:42 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeDa0-0006Q1-Nx for ccamp-archive@megatron.ietf.org; Mon, 21 Nov 2005 10:27:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08131 for ; Mon, 21 Nov 2005 10:27:03 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EeDsT-0006N5-Th for ccamp-archive@ietf.org; Mon, 21 Nov 2005 10:46:46 -0500 Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EeDTj-0001NQ-M2 for ccamp-data@psg.com; Mon, 21 Nov 2005 15:21:11 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [70.158.43.219] (helo=jera.movaz.com) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1EeDTi-0001N4-0F for ccamp@ops.ietf.org; Mon, 21 Nov 2005 15:21:10 +0000 Received: from ib (unknown [172.16.24.122]) by jera.movaz.com (Postfix) with SMTP id 8523011B0B; Mon, 21 Nov 2005 10:20:34 -0500 (EST) Message-ID: <00b101c5eeaf$32c0a2a0$7a1810ac@movaz.com> From: "Igor Bryskin" To: , , "JP Vasseur" Cc: , "Adrian Farrel" , "LE ROUX Jean-Louis RD-CORE-LAN" , References: <05d401c5ebb8$f343bde0$d501a8c0@Puppy> <437DFA01.9080804@psg.com> <01ae01c5ed24$891c5c70$6601a8c0@movaz.com> <4380D135.2080202@psg.com> Subject: Re: IGP Extensions - CCAMP Milestones Date: Mon, 21 Nov 2005 10:21:08 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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: 3a331e4a192f4d33f18e6f8376287cf6 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id KAA08131 Dimitri, See my reply to JP. Also see below. ----- Original Message -----=20 From: "dimitri papadimitriou" To: "JP Vasseur" Cc: "Igor Bryskin" ; ; "Adrian Farrel" ; "LE ROUX Jean-Louis RD-CORE-LAN" ; Sent: Sunday, November 20, 2005 2:40 PM Subject: Re: IGP Extensions - CCAMP Milestones > hi jp, > > indeed, i don't really understand the issue brought up by igor; > > in the present case, one should also underline that, the information > distributed across the OSPF domain using opaque LSAs, is *indirectly* > used by e.g. TE applications (note: RFC2370 allows for this information > to be used directly by OSPF but i think we're not discussing this > alternative) > > this means that these e.g. TE applications can in case of control engin= e > failure detect this failure and trigger any necessary action in order t= o > avoid the behaviour described by igor IB>> Two points here: a) all TE LSAs are of the area scope; b) A TE application can detect a control engine failure only within one area. It does not help for LSRs located outside of this area because no L= SR (including ABR) is allowed to withdraw somebody else's LSAs - the LSAs co= uld be withdrawn or modified by the LSR that has originated them. Igor > > thanks, > - dimitri. > > JP Vasseur wrote: > > Hi Igor, > > > > On Nov 19, 2005, at 11:16 AM, Igor Bryskin wrote: > > > >> Hi everybody, > >> > >> > >> > >> I'd like to note that although the AS scope flooding is allowed for > >> opaque > >> LSAs, in my experience it does not work. > > > > > > So your experience is different than the one of many people ... Opaq= ue > > LSA have been > > used for quite a few years without any problem. See RFC2370 (July 199= 8) > > > >> Imagine that some routing > >> controller advertises an AS scope LSA and goes out of service quick= ly > >> after > >> that. Controllers outside of the area that the dead controller > >> belongs to > >> have no way of detecting its death and, therefore, will keep using t= he > >> advertising for another 90 min before the LSA times out. > > > > > > I guess that you mean 60 min (Maxage=3D60mn, Architectural Constant) = - > > See RFC2328, but this is not the point, see below. > > > >> Note that the > >> controllers located within the same area do not have such a problem > >> because > >> they can always verify the validity of the advertising by trying to > >> locate a > >> sequence of active adjacencies interconnecting each of them with the > >> advertising controller. If they find at least one such a sequence, t= he > >> advertising is valid (otherwise, it would be withdrawn); on the oth= er > >> hand, > >> if no such sequences exist, than advertising is likely to be stale > >> and hence > >> could not be trusted. The conclusion is that opaque LSAs should nev= er be > >> flooded within AS, rather, within a single area, and, if there is a > >> need for > >> the information to be propagated beyond the area boundaries, ABRs > >> must relay > >> the advertising into other areas (by originating new area-scope > >> LSAs). Note > >> also that as far as I remember OSPF itself never uses AS scope > >> advertisings > >> for its own needs. For example, an ASBR does not distribute externa= l > >> routes > >> learned by BGP from other ASs using AS scope LSAs, rather, the rout= es > >> are > >> advertised within a single area and ABRs relay the advertisings int= o > >> other > >> areas. > > > > > > This is not correct. External routes are redistributed with LSA Type = 5 > > which are > > flooded across the entire domain except in stub-area (not generated b= y > > the ABR as type 3 as you mention). > > > > Anyway, back to the point, one cannot say of course that "Opaque LSA > > Type 11 does not work". There are suitable to some application, this = is > > all. You can perfectly reply on an opaque LSA Type 11 to learn the > > capability of a router which does not reside in the local area and re= ly > > on another mechanism to detect its liveness. There are several such > > examples. > > > > Hope this helps. > > > > JP. > > > > > >> > >> > >> > >> The bottom line is that the TLVs described in the draft should be o= f the > >> area scope (just like TE LSAs), and hence it is not all that importa= nt > >> whether we use new high level TLVs or sub-TLVs of the TE router cap TLV. > >> > >> > >> > >> Igor > >> > >> > >> > >> > >> > >> ----- Original Message ----- > >> > >> From: "dimitri papadimitriou" > >> > >> To: "Adrian Farrel" > >> > >> Cc: "LE ROUX Jean-Louis RD-CORE-LAN" > >> ; > >> "JP Vasseur" ; "Dimitri Papadimitriou" > >> ; > >> > >> Sent: Friday, November 18, 2005 10:57 AM > >> > >> Subject: Re: IGP Extensions - CCAMP Milestones > >> > >> > >> > >> > >>> adrian > >>> > >>> i think JL's reply did partially translate the initial concern > >>> > >>> in brief, there are three well identified TE applications that coul= d > >>> make use of the TE node cap TLVs on both intra and inter-area basis= : > >>> - LSP Stitching edge node capability > >>> - Edge nodes connecting/being P2MP TE egresses > >>> - TE auto-mesh > >>> > >>> hence, the question on why keeping separated TLVs as part of the router > >>> capability and not consider these as sub-TLVs of the TE router cap TLV > >>> this would > >>> 1) provide a logical grouping of TE sub-TLVs as part of the same T= LV > >>> and > >>> 2) leave the flexibility of flooding scope on a per application need - > >>> > >>> note: that the path computation specific sub-TLVs could still be > >>> restricted with their current area-scope > >>> > >>> hope this clarifies the issue, > >>> > >>> thanks, > >>> - dimitri. > >>> > >>> Adrian Farrel wrote: > >>> > >>> > >>>> If I understand the question it is... > >>>> > >>>> In draft-ietf-ospf-cap-07.txt introduces the OSPF router > >>>> information LSA > >>>> and states that this LSA may have type 9, 10 or 11 scope. > >>>> > >>>> In draft-vasseur-ccamp-te-node-cap-01.txt a new TLV (TE Node > >>>> Capability > >>>> Descriptor) is added to the OSPF router information LSA. This TLV > >>>> (when > >>>> generated) MUST be advertised with type 10 scope. JL has given the > >>>> > >> reason > >> > >>>> why this is limited to type 10. This reason is, of course, open fo= r > >>>> discussion as he says. > >>>> > >>>> In draft-vasseur-ccamp-automesh-02.txt a new TLV (TE-MESH-GROUP) i= s > >>>> > >> added > >> > >>>> to the OSPF router information LSA. It states that the LSA may be > >>>> advertised with type 10 or type 11 scope. JP has given a reason w= hy > >>>> you > >>>> might want type 11 in addition to type 10. This reason is, of course, > >>>> > >> open > >> > >>>> for discussion. > >>>> > >>>> An interesting feature is that a router advertising an AS-wide mes= h > >>>> > >> group > >> > >>>> *and* a TE router capability may require that two OSPF router > >>>> > >> information > >> > >>>> LSAs are advertised by the router. > >>>> > >>>> The language in draft-ietf-ospf-cap-07.txt leans towards a router > >>>> > >> sending > >> > >>>> *an* OSPF router information LSA. But nowhere does it say that the > >>>> > >> router > >> > >>>> cannot send more than one and in section 2.5 we find... > >>>> The originating router MAY advertise > >>>> multiple RI LSAs as long as the flooding scopes differ. > >>>> > >>>> Hope this answers the point. > >>>> > >>>> Adrian > >>>> ----- Original Message ----- > >>>> From: "LE ROUX Jean-Louis RD-CORE-LAN" > >>>> > >>>> To: "JP Vasseur" ; "Dimitri Papadimitriou" > >>>> ; "Dimitri Papadimitriou" > >>>> > >>>> Cc: ; > >>>> Sent: Thursday, November 17, 2005 6:47 PM > >>>> Subject: RE: IGP Extensions - CCAMP Milestones > >>>> > >>>> > >>>> Hi Dimitri, > >>>> > >>>> Thanks for the comment. > >>>> > >>>> As just explained by JP, the TE Node Cap TLV carries topology related > >>>> parameters used as constraints in path computation. The leaking o= f > >>>> such > >>>> info across areas sounds useless as LSR TE visibility is limited = to > >>>> one > >>>> area anyway... > >>>> But this is, of course, open to discussions. By the way, do you > >>>> have any > >>>> application in mind where such leaking would be useful? > >>>> > >>>> Regards, > >>>> > >>>> JL > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>>> -----Message d'origine----- > >>>>> De : JP Vasseur [mailto:jvasseur@cisco.com] > >>>>> Envoy=E9 : jeudi 17 novembre 2005 16:58 > >>>>> =C0 : Dimitri Papadimitriou; Dimitri Papadimitriou > >>>>> Cc : zzx-adrian@olddog.co.uk; ccamp@ops.ietf.org; LE ROUX > >>>>> Jean-Louis RD-CORE-LAN > >>>>> Objet : Re: IGP Extensions - CCAMP Milestones > >>>>> > >>>>> Hi dimitri, > >>>>> > >>>>> On Nov 16, 2005, at 6:30 PM, dimitri papadimitriou wrote: > >>>>> > >>>>> > >>>>> > >>>>>> adrian, > >>>>>> > >>>>>> could you explain the reasoning for having a TE specific TLV in the > >>>>>> auto-mesh document with area and AS-wide flooding scope > >>>>>> > >>>>> > >>>>> while the TE > >>>>> > >>>>> > >>>>>> router cap TLV is restricted to an area flooding scope ? > >>>>>> shouldn't be one way or the other i.e. either restrict all TE in= fo > >>>>>> area-local or allow for TE router cap TLV with AS-wide > >>>>>> > >>>>> > >>>>> flooding scope > >>>>> > >>>>> > >>>>>> ? > >>>>>> > >>>>>> note: there is nothing in the TE router cap TLV that would impac= t > >>>>>> scaling more than the TE auto-mesh TLV does > >>>>>> > >>>>>> > >>>>> > >>>>> I guess that the reason for allowing both intra and inter-area > >>>>> flooding scopes for automesh is obvious (we need to have TE LSP mesh > >>>>> within areas and spanning multiple areas). > >>>>> > >>>>> So your question is probably why don't we allow the TE router > >>>>> cap TLV > >>>>> to be flooded across the domain ? As far as I can remember JL > >>>>> already > >>>>> answered this question ... JL, could you forward your email again= ? > >>>>> > >>>>> In the meantime, I can answer it: the reason is that such TE node > >>>>> capabilities are used for TE LSP computation which cannot take in= to > >>>>> account nodes that do not reside in the node's area. > >>>>> > >>>>> Thanks. > >>>>> > >>>>> JP. > >>>>> > >>>>> > >>>>> > >>>>>> thanks, > >>>>>> - dimitri. > >>>>>> > >>>>>> Adrian Farrel wrote: > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>>> Hi, > >>>>>>> We have two immediate milestones to address: > >>>>>>> Oct 05 First version WG I-D for Advertising TE Node Capabiliti= es > >>>>>>> in ISIS > >>>>>>> and OSPF > >>>>>>> Oct 05 First version WG I-D for Automatic discovery of > >>>>>>> > >>>>> > >>>>> MPLS-TE mesh > >>>>> > >>>>> > >>>>>>> membership > >>>>>>> There are two personal submissions which address these topics: > >>>>>>> draft-vasseur-ccamp-te-node-cap-01.txt > >>>>>>> draft-vasseur-ccamp-automesh-02.txt > >>>>>>> I propose that we move these into the WG and then kick the tire= s > >>>>>>> thoroughly. > >>>>>>> Opinions please. > >>>>>>> Thanks, > >>>>>>> Adrian > >>>>>>> . > >>>>>>> > >>>>>> > >>>>>> > >>>> > >>>> > >>>> > >>>> > >>>> . > >>>> > >>>> > >>> > >> > > > > > > . > > > From owner-ccamp@ops.ietf.org Mon Nov 21 11:44:30 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeEmL-0007nf-KQ for ccamp-archive@megatron.ietf.org; Mon, 21 Nov 2005 11:44:30 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13470 for ; Mon, 21 Nov 2005 11:43:48 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EeF4m-0000F5-DE for ccamp-archive@ietf.org; Mon, 21 Nov 2005 12:03:33 -0500 Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EeEfK-0006Fb-Og for ccamp-data@psg.com; Mon, 21 Nov 2005 16:37:14 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [64.102.122.149] (helo=rtp-iport-2.cisco.com) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1EeEfJ-0006FO-0N for ccamp@ops.ietf.org; Mon, 21 Nov 2005 16:37:13 +0000 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 21 Nov 2005 11:37:03 -0500 X-IronPort-AV: i="3.97,357,1125892800"; d="scan'208"; a="76224889:sNHT31683268" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id jALGaem7001309; Mon, 21 Nov 2005 11:36:59 -0500 (EST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 21 Nov 2005 11:36:51 -0500 Received: from [192.168.1.101] ([10.82.241.73]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 21 Nov 2005 11:36:50 -0500 In-Reply-To: <00aa01c5eeae$31737ea0$7a1810ac@movaz.com> References: <05d401c5ebb8$f343bde0$d501a8c0@Puppy> <437DFA01.9080804@psg.com> <01ae01c5ed24$891c5c70$6601a8c0@movaz.com> <00aa01c5eeae$31737ea0$7a1810ac@movaz.com> Mime-Version: 1.0 (Apple Message framework v734) X-Priority: 3 Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <8337AD85-1FA6-4F01-9993-7DEFE24ED4FB@cisco.com> Cc: , , "Adrian Farrel" , "LE ROUX Jean-Louis RD-CORE-LAN" , Content-Transfer-Encoding: quoted-printable From: JP Vasseur Subject: Re: IGP Extensions - CCAMP Milestones Date: Mon, 21 Nov 2005 11:36:19 -0500 To: Igor Bryskin X-Mailer: Apple Mail (2.734) X-OriginalArrivalTime: 21 Nov 2005 16:36:50.0182 (UTC) FILETIME=[C59F0260:01C5EEB9] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 426dd6ea860196690cb99367d860d19e Content-Transfer-Encoding: quoted-printable Hi Igor, On Nov 21, 2005, at 10:13 AM, Igor Bryskin wrote: > Hi JP, > > > > See in-line. > > > > Cheers, > > Igor > > > > ----- Original Message ----- > > From: "JP Vasseur" > > To: "Igor Bryskin" > > Cc: ; ; =20 > "Adrian > Farrel" ; "LE ROUX Jean-Louis RD-CORE-LAN" > ; > > Sent: Sunday, November 20, 2005 9:57 AM > > Subject: Re: IGP Extensions - CCAMP Milestones > > > > Hi Igor, > > On Nov 19, 2005, at 11:16 AM, Igor Bryskin wrote: > > >> Hi everybody, >> >> >> >> I'd like to note that although the AS scope flooding is allowed for >> opaque >> LSAs, in my experience it does not work. >> > > So your experience is different than the one of many people ... > Opaque LSA have been > used for quite a few years without any problem. See RFC2370 (July =20 > 1998) > > >> Imagine that some routing >> controller advertises an AS scope LSA and goes out of service >> quickly after >> that. Controllers outside of the area that the dead controller >> belongs to >> have no way of detecting its death and, therefore, will keep using =20= >> the >> advertising for another 90 min before the LSA times out. >> > > I guess that you mean 60 min (Maxage=3D60mn, Architectural Constant) - > See RFC2328, but this is not the point, see below. > > >> Note that the >> controllers located within the same area do not have such a problem >> because >> they can always verify the validity of the advertising by trying to >> locate a >> sequence of active adjacencies interconnecting each of them with the >> advertising controller. If they find at least one such a sequence, =20= >> the >> advertising is valid (otherwise, it would be withdrawn); on the >> other hand, >> if no such sequences exist, than advertising is likely to be stale >> and hence >> could not be trusted. The conclusion is that opaque LSAs should >> never be >> flooded within AS, rather, within a single area, and, if there is a >> need for >> the information to be propagated beyond the area boundaries, ABRs >> must relay >> the advertising into other areas (by originating new area-scope >> LSAs). Note >> also that as far as I remember OSPF itself never uses AS scope >> advertisings >> for its own needs. For example, an ASBR does not distribute >> external routes >> learned by BGP from other ASs using AS scope LSAs, rather, the >> routes are >> advertised within a single area and ABRs relay the advertisings >> into other >> areas. >> > > This is not correct. External routes are redistributed with LSA Type > 5 which are > flooded across the entire domain except in stub-area (not generated by > the ABR as type 3 as you mention). > > > > IB>> True, that what is written in RFC2328. well not just written in the RFC but implemented and deployed in OSPF =20= networks for years. > And my contention here is that > if an ASBR advertises LSAs type 5 and dies after that, than OSPF =20 > speakers > outside of the ASBR's area have good likelihood to use stale =20 > external routes > for a considerable period of time. There is no remedy to that (OSPF =20= > speakers > do not use Keep Alive protocol :=3D). This, however, could be fixed by > avoiding using of AS scope flooding, and that's exactly the reason =20 > why some > OSPF applications that I know of do just that. But this is the =20 > discussion > for OSPF WG, I suggest not argue about that. See below. > There is nothing to fix here. Anyway, see below ... > Anyway, back to the point, one cannot say of course that "Opaque LSA > Type 11 does not work". There are suitable to some application, =20 > this is > all. You can perfectly reply on an opaque LSA Type 11 to learn the > capability of a router which does not reside in the local area and =20 > rely > on another mechanism to detect its liveness. There are several such > examples. > > > > IB>> Let's stick to your example. Why is it better to flood router > capability LSAs across an AS, rather than flood them within a =20 > single area > and have ABRs relay the advertisings into other areas by =20 > originating their > own LSAs? Yes, the AS-scope flooding is simpler. > But what I am suggesting > has the following advantages: > > a) Advertisings of a crashed LSR could be withdrawn from use =20 > by all AS > LSRs immediately after the crash; > > b) Advertisings could be summarized by an ABR providing =20 > scalability > improvements; > OSPF provides an efficient way to flood information across the entire =20= routing domain: opaque LSA Type 11. If the use of such LSA is useful =20 to some applications why not using it ? You highlight two aspects here - Liveness of the capability advertising router: just rely on a =20 liveness protocol if you need to quickly detect a crash of the router - Scalability improvement: this is in fact the opposite ... Think of =20 the extra work required on the ABR to leak TLV in other areas =20 compared to flood a Type 11 LSA. Apparently you do not appreciate the =20= architectural change that this would mean on OSPF. > c) What is more important that policies could be applied on =20 > ABRs wrt to > what information is leaked to external areas. Regretfully, you keep > forgetting about the policy aspects, but in the context of AS-scope =20= > flooding > how can you enforce that an LSR capabilities are advertised into =20 > some areas, > not advertised into some other areas, and advertised in a modified =20 > way into > the third set of areas? Policy is of the utmost importance in many contexts such as Inter-AS/=20 Providers ... not sure the case of inter-area within a single AS is =20 the case. Now, if you want to propose a new mode of operation for =20 OSPF, you may want to discuss it with the OSPF WG ... We could =20 continue the discussion there ... since it belongs to OSPF. JP. > > > > Igor > > Hope this helps. > > JP. > > > >> >> >> >> The bottom line is that the TLVs described in the draft should be >> of the >> area scope (just like TE LSAs), and hence it is not all that =20 >> important >> whether we use new high level TLVs or sub-TLVs of the TE router cap >> TLV. >> >> >> >> Igor >> >> >> >> >> >> ----- Original Message ----- >> >> From: "dimitri papadimitriou" >> >> To: "Adrian Farrel" >> >> Cc: "LE ROUX Jean-Louis RD-CORE-LAN" >> ; >> "JP Vasseur" ; "Dimitri Papadimitriou" >> ; >> >> Sent: Friday, November 18, 2005 10:57 AM >> >> Subject: Re: IGP Extensions - CCAMP Milestones >> >> >> >> >> >>> adrian >>> >>> i think JL's reply did partially translate the initial concern >>> >>> in brief, there are three well identified TE applications that could >>> make use of the TE node cap TLVs on both intra and inter-area basis: >>> - LSP Stitching edge node capability >>> - Edge nodes connecting/being P2MP TE egresses >>> - TE auto-mesh >>> >>> hence, the question on why keeping separated TLVs as part of the >>> router >>> capability and not consider these as sub-TLVs of the TE router cap >>> TLV >>> this would >>> 1) provide a logical grouping of TE sub-TLVs as part of the same >>> TLV and >>> 2) leave the flexibility of flooding scope on a per application >>> need - >>> >>> note: that the path computation specific sub-TLVs could still be >>> restricted with their current area-scope >>> >>> hope this clarifies the issue, >>> >>> thanks, >>> - dimitri. >>> >>> Adrian Farrel wrote: >>> >>> >>> >>>> If I understand the question it is... >>>> >>>> In draft-ietf-ospf-cap-07.txt introduces the OSPF router >>>> information LSA >>>> and states that this LSA may have type 9, 10 or 11 scope. >>>> >>>> In draft-vasseur-ccamp-te-node-cap-01.txt a new TLV (TE Node >>>> Capability >>>> Descriptor) is added to the OSPF router information LSA. This TLV >>>> (when >>>> generated) MUST be advertised with type 10 scope. JL has given the >>>> >>>> >> reason >> >> >>>> why this is limited to type 10. This reason is, of course, open for >>>> discussion as he says. >>>> >>>> In draft-vasseur-ccamp-automesh-02.txt a new TLV (TE-MESH-GROUP) is >>>> >>>> >> added >> >> >>>> to the OSPF router information LSA. It states that the LSA may be >>>> advertised with type 10 or type 11 scope. JP has given a reason >>>> why you >>>> might want type 11 in addition to type 10. This reason is, of >>>> course, >>>> >>>> >> open >> >> >>>> for discussion. >>>> >>>> An interesting feature is that a router advertising an AS-wide mesh >>>> >>>> >> group >> >> >>>> *and* a TE router capability may require that two OSPF router >>>> >>>> >> information >> >> >>>> LSAs are advertised by the router. >>>> >>>> The language in draft-ietf-ospf-cap-07.txt leans towards a router >>>> >>>> >> sending >> >> >>>> *an* OSPF router information LSA. But nowhere does it say that the >>>> >>>> >> router >> >> >>>> cannot send more than one and in section 2.5 we find... >>>> The originating router MAY advertise >>>> multiple RI LSAs as long as the flooding scopes differ. >>>> >>>> Hope this answers the point. >>>> >>>> Adrian >>>> ----- Original Message ----- >>>> From: "LE ROUX Jean-Louis RD-CORE-LAN" >>>> >>>> To: "JP Vasseur" ; "Dimitri Papadimitriou" >>>> ; "Dimitri Papadimitriou" >>>> >>>> Cc: ; >>>> Sent: Thursday, November 17, 2005 6:47 PM >>>> Subject: RE: IGP Extensions - CCAMP Milestones >>>> >>>> >>>> Hi Dimitri, >>>> >>>> Thanks for the comment. >>>> >>>> As just explained by JP, the TE Node Cap TLV carries topology >>>> related >>>> parameters used as constraints in path computation. The leaking >>>> of such >>>> info across areas sounds useless as LSR TE visibility is limited >>>> to one >>>> area anyway... >>>> But this is, of course, open to discussions. By the way, do you >>>> have any >>>> application in mind where such leaking would be useful? >>>> >>>> Regards, >>>> >>>> JL >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>> -----Message d'origine----- >>>>> De : JP Vasseur [mailto:jvasseur@cisco.com] >>>>> Envoy=E9 : jeudi 17 novembre 2005 16:58 >>>>> =C0 : Dimitri Papadimitriou; Dimitri Papadimitriou >>>>> Cc : zzx-adrian@olddog.co.uk; ccamp@ops.ietf.org; LE ROUX >>>>> Jean-Louis RD-CORE-LAN >>>>> Objet : Re: IGP Extensions - CCAMP Milestones >>>>> >>>>> Hi dimitri, >>>>> >>>>> On Nov 16, 2005, at 6:30 PM, dimitri papadimitriou wrote: >>>>> >>>>> >>>>> >>>>> >>>>>> adrian, >>>>>> >>>>>> could you explain the reasoning for having a TE specific TLV in >>>>>> the >>>>>> auto-mesh document with area and AS-wide flooding scope >>>>>> >>>>>> >>>>> >>>>> while the TE >>>>> >>>>> >>>>> >>>>>> router cap TLV is restricted to an area flooding scope ? >>>>>> shouldn't be one way or the other i.e. either restrict all TE =20 >>>>>> info >>>>>> area-local or allow for TE router cap TLV with AS-wide >>>>>> >>>>>> >>>>> >>>>> flooding scope >>>>> >>>>> >>>>> >>>>>> ? >>>>>> >>>>>> note: there is nothing in the TE router cap TLV that would impact >>>>>> scaling more than the TE auto-mesh TLV does >>>>>> >>>>>> >>>>>> >>>>> >>>>> I guess that the reason for allowing both intra and inter-area >>>>> flooding scopes for automesh is obvious (we need to have TE LSP >>>>> mesh >>>>> within areas and spanning multiple areas). >>>>> >>>>> So your question is probably why don't we allow the TE router >>>>> cap TLV >>>>> to be flooded across the domain ? As far as I can remember JL >>>>> already >>>>> answered this question ... JL, could you forward your email =20 >>>>> again ? >>>>> >>>>> In the meantime, I can answer it: the reason is that such TE node >>>>> capabilities are used for TE LSP computation which cannot take =20 >>>>> into >>>>> account nodes that do not reside in the node's area. >>>>> >>>>> Thanks. >>>>> >>>>> JP. >>>>> >>>>> >>>>> >>>>> >>>>>> thanks, >>>>>> - dimitri. >>>>>> >>>>>> Adrian Farrel wrote: >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> Hi, >>>>>>> We have two immediate milestones to address: >>>>>>> Oct 05 First version WG I-D for Advertising TE Node =20 >>>>>>> Capabilities >>>>>>> in ISIS >>>>>>> and OSPF >>>>>>> Oct 05 First version WG I-D for Automatic discovery of >>>>>>> >>>>>>> >>>>> >>>>> MPLS-TE mesh >>>>> >>>>> >>>>> >>>>>>> membership >>>>>>> There are two personal submissions which address these topics: >>>>>>> draft-vasseur-ccamp-te-node-cap-01.txt >>>>>>> draft-vasseur-ccamp-automesh-02.txt >>>>>>> I propose that we move these into the WG and then kick the tires >>>>>>> thoroughly. >>>>>>> Opinions please. >>>>>>> Thanks, >>>>>>> Adrian >>>>>>> . >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>> >>>> >>>> >>>> >>>> . >>>> >>>> >>>> >>> >>> >> > From owner-ccamp@ops.ietf.org Mon Nov 21 12:25:13 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeFPl-0001xq-3A for ccamp-archive@megatron.ietf.org; Mon, 21 Nov 2005 12:25:13 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16854 for ; Mon, 21 Nov 2005 12:24:35 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EeFiF-0001cp-9P for ccamp-archive@ietf.org; Mon, 21 Nov 2005 12:44:20 -0500 Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EeFKW-0008gc-TX for ccamp-data@psg.com; Mon, 21 Nov 2005 17:19:48 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [70.158.43.219] (helo=jera.movaz.com) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1EeFKV-0008gO-9j for ccamp@ops.ietf.org; Mon, 21 Nov 2005 17:19:47 +0000 Received: from ib (unknown [172.16.24.122]) by jera.movaz.com (Postfix) with SMTP id DE51C1722A; Mon, 21 Nov 2005 12:19:11 -0500 (EST) Message-ID: <001e01c5eebf$c4e65200$7a1810ac@movaz.com> From: "Igor Bryskin" To: "JP Vasseur" Cc: , , "Adrian Farrel" , "LE ROUX Jean-Louis RD-CORE-LAN" , References: <05d401c5ebb8$f343bde0$d501a8c0@Puppy> <437DFA01.9080804@psg.com> <01ae01c5ed24$891c5c70$6601a8c0@movaz.com> <00aa01c5eeae$31737ea0$7a1810ac@movaz.com> <8337AD85-1FA6-4F01-9993-7DEFE24ED4FB@cisco.com> Subject: Re: IGP Extensions - CCAMP Milestones Date: Mon, 21 Nov 2005 12:19:45 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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: 5df1f98f3253c63b673ea560243aa58f Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id MAA16854 JP, Could you give me an example of application that uses AS scope opaque LSA= s? Thanks, Igor ----- Original Message -----=20 From: "JP Vasseur" To: "Igor Bryskin" Cc: ; ; "Adrian Farrel" ; "LE ROUX Jean-Louis RD-CORE-LAN" ; Sent: Monday, November 21, 2005 11:36 AM Subject: Re: IGP Extensions - CCAMP Milestones Hi Igor, On Nov 21, 2005, at 10:13 AM, Igor Bryskin wrote: > Hi JP, > > > > See in-line. > > > > Cheers, > > Igor > > > > ----- Original Message ----- > > From: "JP Vasseur" > > To: "Igor Bryskin" > > Cc: ; ; > "Adrian > Farrel" ; "LE ROUX Jean-Louis RD-CORE-LAN" > ; > > Sent: Sunday, November 20, 2005 9:57 AM > > Subject: Re: IGP Extensions - CCAMP Milestones > > > > Hi Igor, > > On Nov 19, 2005, at 11:16 AM, Igor Bryskin wrote: > > >> Hi everybody, >> >> >> >> I'd like to note that although the AS scope flooding is allowed for >> opaque >> LSAs, in my experience it does not work. >> > > So your experience is different than the one of many people ... > Opaque LSA have been > used for quite a few years without any problem. See RFC2370 (July > 1998) > > >> Imagine that some routing >> controller advertises an AS scope LSA and goes out of service >> quickly after >> that. Controllers outside of the area that the dead controller >> belongs to >> have no way of detecting its death and, therefore, will keep using >> the >> advertising for another 90 min before the LSA times out. >> > > I guess that you mean 60 min (Maxage=3D60mn, Architectural Constant) - > See RFC2328, but this is not the point, see below. > > >> Note that the >> controllers located within the same area do not have such a problem >> because >> they can always verify the validity of the advertising by trying to >> locate a >> sequence of active adjacencies interconnecting each of them with the >> advertising controller. If they find at least one such a sequence, >> the >> advertising is valid (otherwise, it would be withdrawn); on the >> other hand, >> if no such sequences exist, than advertising is likely to be stale >> and hence >> could not be trusted. The conclusion is that opaque LSAs should >> never be >> flooded within AS, rather, within a single area, and, if there is a >> need for >> the information to be propagated beyond the area boundaries, ABRs >> must relay >> the advertising into other areas (by originating new area-scope >> LSAs). Note >> also that as far as I remember OSPF itself never uses AS scope >> advertisings >> for its own needs. For example, an ASBR does not distribute >> external routes >> learned by BGP from other ASs using AS scope LSAs, rather, the >> routes are >> advertised within a single area and ABRs relay the advertisings >> into other >> areas. >> > > This is not correct. External routes are redistributed with LSA Type > 5 which are > flooded across the entire domain except in stub-area (not generated by > the ABR as type 3 as you mention). > > > > IB>> True, that what is written in RFC2328. well not just written in the RFC but implemented and deployed in OSPF networks for years. > And my contention here is that > if an ASBR advertises LSAs type 5 and dies after that, than OSPF > speakers > outside of the ASBR's area have good likelihood to use stale > external routes > for a considerable period of time. There is no remedy to that (OSPF > speakers > do not use Keep Alive protocol :=3D). This, however, could be fixed by > avoiding using of AS scope flooding, and that's exactly the reason > why some > OSPF applications that I know of do just that. But this is the > discussion > for OSPF WG, I suggest not argue about that. See below. > There is nothing to fix here. Anyway, see below ... > Anyway, back to the point, one cannot say of course that "Opaque LSA > Type 11 does not work". There are suitable to some application, > this is > all. You can perfectly reply on an opaque LSA Type 11 to learn the > capability of a router which does not reside in the local area and > rely > on another mechanism to detect its liveness. There are several such > examples. > > > > IB>> Let's stick to your example. Why is it better to flood router > capability LSAs across an AS, rather than flood them within a > single area > and have ABRs relay the advertisings into other areas by > originating their > own LSAs? Yes, the AS-scope flooding is simpler. > But what I am suggesting > has the following advantages: > > a) Advertisings of a crashed LSR could be withdrawn from use > by all AS > LSRs immediately after the crash; > > b) Advertisings could be summarized by an ABR providing > scalability > improvements; > OSPF provides an efficient way to flood information across the entire routing domain: opaque LSA Type 11. If the use of such LSA is useful to some applications why not using it ? You highlight two aspects here - Liveness of the capability advertising router: just rely on a liveness protocol if you need to quickly detect a crash of the router - Scalability improvement: this is in fact the opposite ... Think of the extra work required on the ABR to leak TLV in other areas compared to flood a Type 11 LSA. Apparently you do not appreciate the architectural change that this would mean on OSPF. > c) What is more important that policies could be applied on > ABRs wrt to > what information is leaked to external areas. Regretfully, you keep > forgetting about the policy aspects, but in the context of AS-scope > flooding > how can you enforce that an LSR capabilities are advertised into > some areas, > not advertised into some other areas, and advertised in a modified > way into > the third set of areas? Policy is of the utmost importance in many contexts such as Inter-AS/ Providers ... not sure the case of inter-area within a single AS is the case. Now, if you want to propose a new mode of operation for OSPF, you may want to discuss it with the OSPF WG ... We could continue the discussion there ... since it belongs to OSPF. JP. > > > > Igor > > Hope this helps. > > JP. > > > >> >> >> >> The bottom line is that the TLVs described in the draft should be >> of the >> area scope (just like TE LSAs), and hence it is not all that >> important >> whether we use new high level TLVs or sub-TLVs of the TE router cap >> TLV. >> >> >> >> Igor >> >> >> >> >> >> ----- Original Message ----- >> >> From: "dimitri papadimitriou" >> >> To: "Adrian Farrel" >> >> Cc: "LE ROUX Jean-Louis RD-CORE-LAN" >> ; >> "JP Vasseur" ; "Dimitri Papadimitriou" >> ; >> >> Sent: Friday, November 18, 2005 10:57 AM >> >> Subject: Re: IGP Extensions - CCAMP Milestones >> >> >> >> >> >>> adrian >>> >>> i think JL's reply did partially translate the initial concern >>> >>> in brief, there are three well identified TE applications that could >>> make use of the TE node cap TLVs on both intra and inter-area basis: >>> - LSP Stitching edge node capability >>> - Edge nodes connecting/being P2MP TE egresses >>> - TE auto-mesh >>> >>> hence, the question on why keeping separated TLVs as part of the >>> router >>> capability and not consider these as sub-TLVs of the TE router cap >>> TLV >>> this would >>> 1) provide a logical grouping of TE sub-TLVs as part of the same >>> TLV and >>> 2) leave the flexibility of flooding scope on a per application >>> need - >>> >>> note: that the path computation specific sub-TLVs could still be >>> restricted with their current area-scope >>> >>> hope this clarifies the issue, >>> >>> thanks, >>> - dimitri. >>> >>> Adrian Farrel wrote: >>> >>> >>> >>>> If I understand the question it is... >>>> >>>> In draft-ietf-ospf-cap-07.txt introduces the OSPF router >>>> information LSA >>>> and states that this LSA may have type 9, 10 or 11 scope. >>>> >>>> In draft-vasseur-ccamp-te-node-cap-01.txt a new TLV (TE Node >>>> Capability >>>> Descriptor) is added to the OSPF router information LSA. This TLV >>>> (when >>>> generated) MUST be advertised with type 10 scope. JL has given the >>>> >>>> >> reason >> >> >>>> why this is limited to type 10. This reason is, of course, open for >>>> discussion as he says. >>>> >>>> In draft-vasseur-ccamp-automesh-02.txt a new TLV (TE-MESH-GROUP) is >>>> >>>> >> added >> >> >>>> to the OSPF router information LSA. It states that the LSA may be >>>> advertised with type 10 or type 11 scope. JP has given a reason >>>> why you >>>> might want type 11 in addition to type 10. This reason is, of >>>> course, >>>> >>>> >> open >> >> >>>> for discussion. >>>> >>>> An interesting feature is that a router advertising an AS-wide mesh >>>> >>>> >> group >> >> >>>> *and* a TE router capability may require that two OSPF router >>>> >>>> >> information >> >> >>>> LSAs are advertised by the router. >>>> >>>> The language in draft-ietf-ospf-cap-07.txt leans towards a router >>>> >>>> >> sending >> >> >>>> *an* OSPF router information LSA. But nowhere does it say that the >>>> >>>> >> router >> >> >>>> cannot send more than one and in section 2.5 we find... >>>> The originating router MAY advertise >>>> multiple RI LSAs as long as the flooding scopes differ. >>>> >>>> Hope this answers the point. >>>> >>>> Adrian >>>> ----- Original Message ----- >>>> From: "LE ROUX Jean-Louis RD-CORE-LAN" >>>> >>>> To: "JP Vasseur" ; "Dimitri Papadimitriou" >>>> ; "Dimitri Papadimitriou" >>>> >>>> Cc: ; >>>> Sent: Thursday, November 17, 2005 6:47 PM >>>> Subject: RE: IGP Extensions - CCAMP Milestones >>>> >>>> >>>> Hi Dimitri, >>>> >>>> Thanks for the comment. >>>> >>>> As just explained by JP, the TE Node Cap TLV carries topology >>>> related >>>> parameters used as constraints in path computation. The leaking >>>> of such >>>> info across areas sounds useless as LSR TE visibility is limited >>>> to one >>>> area anyway... >>>> But this is, of course, open to discussions. By the way, do you >>>> have any >>>> application in mind where such leaking would be useful? >>>> >>>> Regards, >>>> >>>> JL >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>> -----Message d'origine----- >>>>> De : JP Vasseur [mailto:jvasseur@cisco.com] >>>>> Envoy=E9 : jeudi 17 novembre 2005 16:58 >>>>> =C0 : Dimitri Papadimitriou; Dimitri Papadimitriou >>>>> Cc : zzx-adrian@olddog.co.uk; ccamp@ops.ietf.org; LE ROUX >>>>> Jean-Louis RD-CORE-LAN >>>>> Objet : Re: IGP Extensions - CCAMP Milestones >>>>> >>>>> Hi dimitri, >>>>> >>>>> On Nov 16, 2005, at 6:30 PM, dimitri papadimitriou wrote: >>>>> >>>>> >>>>> >>>>> >>>>>> adrian, >>>>>> >>>>>> could you explain the reasoning for having a TE specific TLV in >>>>>> the >>>>>> auto-mesh document with area and AS-wide flooding scope >>>>>> >>>>>> >>>>> >>>>> while the TE >>>>> >>>>> >>>>> >>>>>> router cap TLV is restricted to an area flooding scope ? >>>>>> shouldn't be one way or the other i.e. either restrict all TE >>>>>> info >>>>>> area-local or allow for TE router cap TLV with AS-wide >>>>>> >>>>>> >>>>> >>>>> flooding scope >>>>> >>>>> >>>>> >>>>>> ? >>>>>> >>>>>> note: there is nothing in the TE router cap TLV that would impact >>>>>> scaling more than the TE auto-mesh TLV does >>>>>> >>>>>> >>>>>> >>>>> >>>>> I guess that the reason for allowing both intra and inter-area >>>>> flooding scopes for automesh is obvious (we need to have TE LSP >>>>> mesh >>>>> within areas and spanning multiple areas). >>>>> >>>>> So your question is probably why don't we allow the TE router >>>>> cap TLV >>>>> to be flooded across the domain ? As far as I can remember JL >>>>> already >>>>> answered this question ... JL, could you forward your email >>>>> again ? >>>>> >>>>> In the meantime, I can answer it: the reason is that such TE node >>>>> capabilities are used for TE LSP computation which cannot take >>>>> into >>>>> account nodes that do not reside in the node's area. >>>>> >>>>> Thanks. >>>>> >>>>> JP. >>>>> >>>>> >>>>> >>>>> >>>>>> thanks, >>>>>> - dimitri. >>>>>> >>>>>> Adrian Farrel wrote: >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> Hi, >>>>>>> We have two immediate milestones to address: >>>>>>> Oct 05 First version WG I-D for Advertising TE Node >>>>>>> Capabilities >>>>>>> in ISIS >>>>>>> and OSPF >>>>>>> Oct 05 First version WG I-D for Automatic discovery of >>>>>>> >>>>>>> >>>>> >>>>> MPLS-TE mesh >>>>> >>>>> >>>>> >>>>>>> membership >>>>>>> There are two personal submissions which address these topics: >>>>>>> draft-vasseur-ccamp-te-node-cap-01.txt >>>>>>> draft-vasseur-ccamp-automesh-02.txt >>>>>>> I propose that we move these into the WG and then kick the tires >>>>>>> thoroughly. >>>>>>> Opinions please. >>>>>>> Thanks, >>>>>>> Adrian >>>>>>> . >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>> >>>> >>>> >>>> >>>> . >>>> >>>> >>>> >>> >>> >> > From owner-ccamp@ops.ietf.org Mon Nov 21 12:33:28 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeFXj-0003RA-V2 for ccamp-archive@megatron.ietf.org; Mon, 21 Nov 2005 12:33:28 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17374 for ; Mon, 21 Nov 2005 12:32:49 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EeFqD-0001pd-2b for ccamp-archive@ietf.org; Mon, 21 Nov 2005 12:52:34 -0500 Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EeFS6-0009ML-R5 for ccamp-data@psg.com; Mon, 21 Nov 2005 17:27:38 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [171.71.176.70] (helo=sj-iport-1.cisco.com) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1EeFS5-0009M1-7R for ccamp@ops.ietf.org; Mon, 21 Nov 2005 17:27:37 +0000 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-1.cisco.com with ESMTP; 21 Nov 2005 09:27:28 -0800 X-IronPort-AV: i="3.97,357,1125903600"; d="scan'208"; a="677092133:sNHT38361624" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id jALHRJs4027664; Mon, 21 Nov 2005 09:27:24 -0800 (PST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 21 Nov 2005 12:27:19 -0500 Received: from [192.168.1.101] ([10.82.241.73]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 21 Nov 2005 12:27:18 -0500 In-Reply-To: <001e01c5eebf$c4e65200$7a1810ac@movaz.com> References: <05d401c5ebb8$f343bde0$d501a8c0@Puppy> <437DFA01.9080804@psg.com> <01ae01c5ed24$891c5c70$6601a8c0@movaz.com> <00aa01c5eeae$31737ea0$7a1810ac@movaz.com> <8337AD85-1FA6-4F01-9993-7DEFE24ED4FB@cisco.com> <001e01c5eebf$c4e65200$7a1810ac@movaz.com> Mime-Version: 1.0 (Apple Message framework v734) X-Priority: 3 Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <5FD242E6-2C5E-4D1C-9EFF-E14AF4690201@cisco.com> Cc: , , "Adrian Farrel" , "LE ROUX Jean-Louis RD-CORE-LAN" , Content-Transfer-Encoding: quoted-printable From: JP Vasseur Subject: Re: IGP Extensions - CCAMP Milestones Date: Mon, 21 Nov 2005 12:26:47 -0500 To: Igor Bryskin X-Mailer: Apple Mail (2.734) X-OriginalArrivalTime: 21 Nov 2005 17:27:18.0269 (UTC) FILETIME=[D2806AD0:01C5EEC0] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 04b84659b2acb599bee006e63124a606 Content-Transfer-Encoding: quoted-printable Hi Igor, On Nov 21, 2005, at 12:19 PM, Igor Bryskin wrote: > JP, > > Could you give me an example of application that uses AS scope =20 > opaque LSAs? > I'll be happy to spend time with you next time we meet to help you =20 understand how to use Opaque LSA Type 11, but do not have enough =20 bandwidth as of now ... If you need help on the OSPF front, you may =20 want to poll the OSPF WG. JP. > Thanks, > Igor > > > ----- Original Message ----- > From: "JP Vasseur" > To: "Igor Bryskin" > Cc: ; ; =20 > "Adrian > Farrel" ; "LE ROUX Jean-Louis RD-CORE-LAN" > ; > Sent: Monday, November 21, 2005 11:36 AM > Subject: Re: IGP Extensions - CCAMP Milestones > > > Hi Igor, > > On Nov 21, 2005, at 10:13 AM, Igor Bryskin wrote: > > >> Hi JP, >> >> >> >> See in-line. >> >> >> >> Cheers, >> >> Igor >> >> >> >> ----- Original Message ----- >> >> From: "JP Vasseur" >> >> To: "Igor Bryskin" >> >> Cc: ; ; >> "Adrian >> Farrel" ; "LE ROUX Jean-Louis RD-CORE-LAN" >> ; >> >> Sent: Sunday, November 20, 2005 9:57 AM >> >> Subject: Re: IGP Extensions - CCAMP Milestones >> >> >> >> Hi Igor, >> >> On Nov 19, 2005, at 11:16 AM, Igor Bryskin wrote: >> >> >> >>> Hi everybody, >>> >>> >>> >>> I'd like to note that although the AS scope flooding is allowed for >>> opaque >>> LSAs, in my experience it does not work. >>> >>> >> >> So your experience is different than the one of many people ... >> Opaque LSA have been >> used for quite a few years without any problem. See RFC2370 (July >> 1998) >> >> >> >>> Imagine that some routing >>> controller advertises an AS scope LSA and goes out of service >>> quickly after >>> that. Controllers outside of the area that the dead controller >>> belongs to >>> have no way of detecting its death and, therefore, will keep using >>> the >>> advertising for another 90 min before the LSA times out. >>> >>> >> >> I guess that you mean 60 min (Maxage=3D60mn, Architectural Constant) = - >> See RFC2328, but this is not the point, see below. >> >> >> >>> Note that the >>> controllers located within the same area do not have such a problem >>> because >>> they can always verify the validity of the advertising by trying to >>> locate a >>> sequence of active adjacencies interconnecting each of them with the >>> advertising controller. If they find at least one such a sequence, >>> the >>> advertising is valid (otherwise, it would be withdrawn); on the >>> other hand, >>> if no such sequences exist, than advertising is likely to be stale >>> and hence >>> could not be trusted. The conclusion is that opaque LSAs should >>> never be >>> flooded within AS, rather, within a single area, and, if there is a >>> need for >>> the information to be propagated beyond the area boundaries, ABRs >>> must relay >>> the advertising into other areas (by originating new area-scope >>> LSAs). Note >>> also that as far as I remember OSPF itself never uses AS scope >>> advertisings >>> for its own needs. For example, an ASBR does not distribute >>> external routes >>> learned by BGP from other ASs using AS scope LSAs, rather, the >>> routes are >>> advertised within a single area and ABRs relay the advertisings >>> into other >>> areas. >>> >>> >> >> This is not correct. External routes are redistributed with LSA Type >> 5 which are >> flooded across the entire domain except in stub-area (not =20 >> generated by >> the ABR as type 3 as you mention). >> >> >> >> IB>> True, that what is written in RFC2328. >> > > well not just written in the RFC but implemented and deployed in OSPF > networks for years. > > >> And my contention here is that >> if an ASBR advertises LSAs type 5 and dies after that, than OSPF >> speakers >> outside of the ASBR's area have good likelihood to use stale >> external routes >> for a considerable period of time. There is no remedy to that (OSPF >> speakers >> do not use Keep Alive protocol :=3D). This, however, could be fixed = by >> avoiding using of AS scope flooding, and that's exactly the reason >> why some >> OSPF applications that I know of do just that. But this is the >> discussion >> for OSPF WG, I suggest not argue about that. See below. >> >> > > There is nothing to fix here. Anyway, see below ... > > >> Anyway, back to the point, one cannot say of course that "Opaque LSA >> Type 11 does not work". There are suitable to some application, >> this is >> all. You can perfectly reply on an opaque LSA Type 11 to learn the >> capability of a router which does not reside in the local area and >> rely >> on another mechanism to detect its liveness. There are several such >> examples. >> >> >> >> IB>> Let's stick to your example. Why is it better to flood router >> capability LSAs across an AS, rather than flood them within a >> single area >> and have ABRs relay the advertisings into other areas by >> originating their >> own LSAs? Yes, the AS-scope flooding is simpler. >> But what I am suggesting >> has the following advantages: >> >> a) Advertisings of a crashed LSR could be withdrawn from use >> by all AS >> LSRs immediately after the crash; >> >> b) Advertisings could be summarized by an ABR providing >> scalability >> improvements; >> >> > > OSPF provides an efficient way to flood information across the entire > routing domain: opaque LSA Type 11. If the use of such LSA is useful > to some applications why not using it ? > > You highlight two aspects here > - Liveness of the capability advertising router: just rely on a > liveness protocol if you need to quickly detect a crash of the router > - Scalability improvement: this is in fact the opposite ... Think of > the extra work required on the ABR to leak TLV in other areas > compared to flood a Type 11 LSA. Apparently you do not appreciate the > architectural change that this would mean on OSPF. > > >> c) What is more important that policies could be applied on >> ABRs wrt to >> what information is leaked to external areas. Regretfully, you keep >> forgetting about the policy aspects, but in the context of AS-scope >> flooding >> how can you enforce that an LSR capabilities are advertised into >> some areas, >> not advertised into some other areas, and advertised in a modified >> way into >> the third set of areas? >> > > Policy is of the utmost importance in many contexts such as Inter-AS/ > Providers ... not sure the case of inter-area within a single AS is > the case. Now, if you want to propose a new mode of operation for > OSPF, you may want to discuss it with the OSPF WG ... We could > continue the discussion there ... since it belongs to OSPF. > > JP. > > >> >> >> >> Igor >> >> Hope this helps. >> >> JP. >> >> >> >> >>> >>> >>> >>> The bottom line is that the TLVs described in the draft should be >>> of the >>> area scope (just like TE LSAs), and hence it is not all that >>> important >>> whether we use new high level TLVs or sub-TLVs of the TE router cap >>> TLV. >>> >>> >>> >>> Igor >>> >>> >>> >>> >>> >>> ----- Original Message ----- >>> >>> From: "dimitri papadimitriou" >>> >>> To: "Adrian Farrel" >>> >>> Cc: "LE ROUX Jean-Louis RD-CORE-LAN" >>> ; >>> "JP Vasseur" ; "Dimitri Papadimitriou" >>> ; >>> >>> Sent: Friday, November 18, 2005 10:57 AM >>> >>> Subject: Re: IGP Extensions - CCAMP Milestones >>> >>> >>> >>> >>> >>> >>>> adrian >>>> >>>> i think JL's reply did partially translate the initial concern >>>> >>>> in brief, there are three well identified TE applications that =20 >>>> could >>>> make use of the TE node cap TLVs on both intra and inter-area =20 >>>> basis: >>>> - LSP Stitching edge node capability >>>> - Edge nodes connecting/being P2MP TE egresses >>>> - TE auto-mesh >>>> >>>> hence, the question on why keeping separated TLVs as part of the >>>> router >>>> capability and not consider these as sub-TLVs of the TE router cap >>>> TLV >>>> this would >>>> 1) provide a logical grouping of TE sub-TLVs as part of the same >>>> TLV and >>>> 2) leave the flexibility of flooding scope on a per application >>>> need - >>>> >>>> note: that the path computation specific sub-TLVs could still be >>>> restricted with their current area-scope >>>> >>>> hope this clarifies the issue, >>>> >>>> thanks, >>>> - dimitri. >>>> >>>> Adrian Farrel wrote: >>>> >>>> >>>> >>>> >>>>> If I understand the question it is... >>>>> >>>>> In draft-ietf-ospf-cap-07.txt introduces the OSPF router >>>>> information LSA >>>>> and states that this LSA may have type 9, 10 or 11 scope. >>>>> >>>>> In draft-vasseur-ccamp-te-node-cap-01.txt a new TLV (TE Node >>>>> Capability >>>>> Descriptor) is added to the OSPF router information LSA. This TLV >>>>> (when >>>>> generated) MUST be advertised with type 10 scope. JL has given the >>>>> >>>>> >>>>> >>> reason >>> >>> >>> >>>>> why this is limited to type 10. This reason is, of course, open =20= >>>>> for >>>>> discussion as he says. >>>>> >>>>> In draft-vasseur-ccamp-automesh-02.txt a new TLV (TE-MESH-=20 >>>>> GROUP) is >>>>> >>>>> >>>>> >>> added >>> >>> >>> >>>>> to the OSPF router information LSA. It states that the LSA may be >>>>> advertised with type 10 or type 11 scope. JP has given a reason >>>>> why you >>>>> might want type 11 in addition to type 10. This reason is, of >>>>> course, >>>>> >>>>> >>>>> >>> open >>> >>> >>> >>>>> for discussion. >>>>> >>>>> An interesting feature is that a router advertising an AS-wide =20 >>>>> mesh >>>>> >>>>> >>>>> >>> group >>> >>> >>> >>>>> *and* a TE router capability may require that two OSPF router >>>>> >>>>> >>>>> >>> information >>> >>> >>> >>>>> LSAs are advertised by the router. >>>>> >>>>> The language in draft-ietf-ospf-cap-07.txt leans towards a router >>>>> >>>>> >>>>> >>> sending >>> >>> >>> >>>>> *an* OSPF router information LSA. But nowhere does it say that the >>>>> >>>>> >>>>> >>> router >>> >>> >>> >>>>> cannot send more than one and in section 2.5 we find... >>>>> The originating router MAY advertise >>>>> multiple RI LSAs as long as the flooding scopes differ. >>>>> >>>>> Hope this answers the point. >>>>> >>>>> Adrian >>>>> ----- Original Message ----- >>>>> From: "LE ROUX Jean-Louis RD-CORE-LAN" >>>>> >>>>> To: "JP Vasseur" ; "Dimitri Papadimitriou" >>>>> ; "Dimitri Papadimitriou" >>>>> >>>>> Cc: ; >>>>> Sent: Thursday, November 17, 2005 6:47 PM >>>>> Subject: RE: IGP Extensions - CCAMP Milestones >>>>> >>>>> >>>>> Hi Dimitri, >>>>> >>>>> Thanks for the comment. >>>>> >>>>> As just explained by JP, the TE Node Cap TLV carries topology >>>>> related >>>>> parameters used as constraints in path computation. The leaking >>>>> of such >>>>> info across areas sounds useless as LSR TE visibility is limited >>>>> to one >>>>> area anyway... >>>>> But this is, of course, open to discussions. By the way, do you >>>>> have any >>>>> application in mind where such leaking would be useful? >>>>> >>>>> Regards, >>>>> >>>>> JL >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>> -----Message d'origine----- >>>>>> De : JP Vasseur [mailto:jvasseur@cisco.com] >>>>>> Envoy=E9 : jeudi 17 novembre 2005 16:58 >>>>>> =C0 : Dimitri Papadimitriou; Dimitri Papadimitriou >>>>>> Cc : zzx-adrian@olddog.co.uk; ccamp@ops.ietf.org; LE ROUX >>>>>> Jean-Louis RD-CORE-LAN >>>>>> Objet : Re: IGP Extensions - CCAMP Milestones >>>>>> >>>>>> Hi dimitri, >>>>>> >>>>>> On Nov 16, 2005, at 6:30 PM, dimitri papadimitriou wrote: >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> adrian, >>>>>>> >>>>>>> could you explain the reasoning for having a TE specific TLV in >>>>>>> the >>>>>>> auto-mesh document with area and AS-wide flooding scope >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> while the TE >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> router cap TLV is restricted to an area flooding scope ? >>>>>>> shouldn't be one way or the other i.e. either restrict all TE >>>>>>> info >>>>>>> area-local or allow for TE router cap TLV with AS-wide >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> flooding scope >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> ? >>>>>>> >>>>>>> note: there is nothing in the TE router cap TLV that would =20 >>>>>>> impact >>>>>>> scaling more than the TE auto-mesh TLV does >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> I guess that the reason for allowing both intra and inter-area >>>>>> flooding scopes for automesh is obvious (we need to have TE LSP >>>>>> mesh >>>>>> within areas and spanning multiple areas). >>>>>> >>>>>> So your question is probably why don't we allow the TE router >>>>>> cap TLV >>>>>> to be flooded across the domain ? As far as I can remember JL >>>>>> already >>>>>> answered this question ... JL, could you forward your email >>>>>> again ? >>>>>> >>>>>> In the meantime, I can answer it: the reason is that such TE node >>>>>> capabilities are used for TE LSP computation which cannot take >>>>>> into >>>>>> account nodes that do not reside in the node's area. >>>>>> >>>>>> Thanks. >>>>>> >>>>>> JP. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> thanks, >>>>>>> - dimitri. >>>>>>> >>>>>>> Adrian Farrel wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Hi, >>>>>>>> We have two immediate milestones to address: >>>>>>>> Oct 05 First version WG I-D for Advertising TE Node >>>>>>>> Capabilities >>>>>>>> in ISIS >>>>>>>> and OSPF >>>>>>>> Oct 05 First version WG I-D for Automatic discovery of >>>>>>>> >>>>>>>> >>>>>>>> >>>>>> >>>>>> MPLS-TE mesh >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>> membership >>>>>>>> There are two personal submissions which address these topics: >>>>>>>> draft-vasseur-ccamp-te-node-cap-01.txt >>>>>>>> draft-vasseur-ccamp-automesh-02.txt >>>>>>>> I propose that we move these into the WG and then kick the =20 >>>>>>>> tires >>>>>>>> thoroughly. >>>>>>>> Opinions please. >>>>>>>> Thanks, >>>>>>>> Adrian >>>>>>>> . >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>> >>>>> >>>>> >>>>> >>>>> . >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>> >>> >> > From owner-ccamp@ops.ietf.org Mon Nov 21 13:27:37 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeGO9-0007Bs-C1 for ccamp-archive@megatron.ietf.org; Mon, 21 Nov 2005 13:27:37 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20547 for ; Mon, 21 Nov 2005 13:26:58 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EeGge-0003Br-2x for ccamp-archive@ietf.org; Mon, 21 Nov 2005 13:46:44 -0500 Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EeGHi-000DOQ-Le for ccamp-data@psg.com; Mon, 21 Nov 2005 18:20:58 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.0 Received: from [62.241.162.31] (helo=galaxy.systems.pipex.net) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1EeGHh-000DOC-E1 for CCamp@ops.ietf.org; Mon, 21 Nov 2005 18:20:57 +0000 Received: from dnni.com (81-178-2-190.dsl.pipex.com [81.178.2.190]) by galaxy.systems.pipex.net (Postfix) with ESMTP id 9A06DE0002FB for ; Mon, 21 Nov 2005 18:20:55 +0000 (GMT) Received: from Puppy ([217.158.132.40] RDNS failed) by dnni.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 21 Nov 2005 18:17:47 +0000 Message-ID: <031101c5eec8$564f3ab0$fb849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Liaison sent to ITU-T for RFC 4258 Date: Mon, 21 Nov 2005 18:20:53 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-OriginalArrivalTime: 21 Nov 2005 18:17:48.0687 (UTC) FILETIME=[E0C581F0:01C5EEC7] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Content-Transfer-Encoding: 7bit > To: Greg Jones > Cc: Adrian Farrel , Scott Bradner , Kireeti Kompella , Alex Zinin , Bill Fenner , CCAMP List ,Adrian Farrel , Kireeti Kompella ,Adrian Farrel , Kireeti Kompella , Deborah Brungard ,statements@ietf.org > From: Adrian Farrel(IETF CCAMP WG) > Subject: Submission of New Liaison Statement, "Publication of New RFC : GMPLS > Routing Requirements for ASON" > Message-Id: > Sender: Apache > Date: Mon, 21 Nov 2005 13:08:59 -0500 > > > Title: Publication of New RFC : GMPLS Routing Requirements for ASON > Submission Date: 2005-11-21 > URL of the IETF Web page: https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=150 > > From: Adrian Farrel(IETF CCAMP WG) > To: ITU-T SQ15 Question 14(Greg Jones ) > Cc: Adrian Farrel > Scott Bradner > Kireeti Kompella > Alex Zinin > Bill Fenner > CCAMP List > Reponse Contact: Adrian Farrel > Kireeti Kompella > Technical Contact: Adrian Farrel > Kireeti Kompella > Deborah Brungard > Purpose: For information > Body: The CCAMP working group is pleased to inform you of the publication of RFC 4258: "Requirements for Generalized Multi-Protocol Label Switching (GMPLS) Routing for the Automatically Switched Optical Network (ASON)" > > The abstract of this RFC is as follows. > > The Generalized Multi-Protocol Label Switching > (GMPLS) suite of protocols has been defined to > control different switching technologies as well > as different applications. These include support > for requesting Time Division Multiplexing (TDM) > connections including Synchronous Optical Network > (SONET)/Synchronous Digital Hierarchy (SDH) and > Optical Transport Networks (OTNs). > > This document concentrates on the routing > requirements placed on the GMPLS suite of > protocols in order to support the capabilities > and functionalities of an Automatically Switched > Optical Network (ASON) as defined by the ITU-T. > > The CCAMP working group is indebted to several members of the ITU-T SG15 community who played a significant part in the authorship of this RFC, and to Question 14/15 which provided important review feedback to ensure that this document accurately reflects the nature and requirements of routing in an ASON environment. > > The RFC can be downloaded from http://www.ietf.org/rfc/rfc4258.txt > > Regards, > Adrian Farrel and Kireeti Kompella > IETF CCAMP working group co-chairs > Attachment(s): > No document has been attached From owner-ccamp@ops.ietf.org Mon Nov 21 18:26:41 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeL3Y-0003CD-Rb for ccamp-archive@megatron.ietf.org; Mon, 21 Nov 2005 18:26:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26551 for ; Mon, 21 Nov 2005 18:26:02 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EeLM6-0007Ws-0J for ccamp-archive@ietf.org; Mon, 21 Nov 2005 18:45:50 -0500 Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EeKwf-00091y-Uy for ccamp-data@psg.com; Mon, 21 Nov 2005 23:19:33 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-4.7 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from localhost ([127.0.0.1]) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1EeKwb-00091R-7N; Mon, 21 Nov 2005 23:19:30 +0000 Message-ID: <43825610.7060706@psg.com> Date: Tue, 22 Nov 2005 00:19:44 +0100 From: dimitri papadimitriou Reply-To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.11) Gecko/20050728 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Igor Bryskin CC: dimitri.papadimitriou@alcatel.be, JP Vasseur , Adrian Farrel , LE ROUX Jean-Louis RD-CORE-LAN , ccamp@ops.ietf.org Subject: Re: IGP Extensions - CCAMP Milestones References: <05d401c5ebb8$f343bde0$d501a8c0@Puppy> <437DFA01.9080804@psg.com> <01ae01c5ed24$891c5c70$6601a8c0@movaz.com> <4380D135.2080202@psg.com> <00b101c5eeaf$32c0a2a0$7a1810ac@movaz.com> In-Reply-To: <00b101c5eeaf$32c0a2a0$7a1810ac@movaz.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 4a4195ffb11c7b0baf82f77b2a730aa9 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id SAA26551 igor Igor Bryskin wrote: > Dimitri, >=20 > See my reply to JP. Also see below. >=20 > ----- Original Message -----=20 > From: "dimitri papadimitriou" > To: "JP Vasseur" > Cc: "Igor Bryskin" ; ; > "Adrian Farrel" ; "LE ROUX Jean-Louis RD-CORE-LAN" > ; > Sent: Sunday, November 20, 2005 2:40 PM > Subject: Re: IGP Extensions - CCAMP Milestones >=20 >=20 >=20 >>hi jp, >> >>indeed, i don't really understand the issue brought up by igor; >> >>in the present case, one should also underline that, the information >>distributed across the OSPF domain using opaque LSAs, is *indirectly* >>used by e.g. TE applications (note: RFC2370 allows for this information >>to be used directly by OSPF but i think we're not discussing this >>alternative) >> >>this means that these e.g. TE applications can in case of control engin= e >>failure detect this failure and trigger any necessary action in order t= o >>avoid the behaviour described by igor >=20 >=20 > IB>> Two points here: >=20 > a) all TE LSAs are of the area scope; you are confusing TE LSAs (opaque type 1, area-scope) applicability with=20 the broader context of e.g. TE applications (see initial statement) that=20 can make use of RI LSAs for inst. > b) A TE application can detect a control engine failure only within one > area.=20 this is not correct, as by definition, application dependent; thanks, - dimitri. > It does not help for LSRs located outside of this area because no LSR > (including ABR) is allowed to withdraw somebody else's LSAs - the LSAs = could > be withdrawn or modified by the LSR that has originated them. > =20 > Igor >=20 >=20 >>thanks, >>- dimitri. >> >>JP Vasseur wrote: >> >>>Hi Igor, >>> >>>On Nov 19, 2005, at 11:16 AM, Igor Bryskin wrote: >>> >>> >>>>Hi everybody, >>>> >>>> >>>> >>>>I'd like to note that although the AS scope flooding is allowed for >>>>opaque >>>>LSAs, in my experience it does not work. >>> >>> >>>So your experience is different than the one of many people ... Opaqu= e >>>LSA have been >>>used for quite a few years without any problem. See RFC2370 (July 1998= ) >>> >>> >>>>Imagine that some routing >>>>controller advertises an AS scope LSA and goes out of service quickl= y >>>>after >>>>that. Controllers outside of the area that the dead controller >>>>belongs to >>>>have no way of detecting its death and, therefore, will keep using th= e >>>>advertising for another 90 min before the LSA times out. >>> >>> >>>I guess that you mean 60 min (Maxage=3D60mn, Architectural Constant) - >>>See RFC2328, but this is not the point, see below. >>> >>> >>>>Note that the >>>>controllers located within the same area do not have such a problem >>>>because >>>>they can always verify the validity of the advertising by trying to >>>>locate a >>>>sequence of active adjacencies interconnecting each of them with the >>>>advertising controller. If they find at least one such a sequence, th= e >>>>advertising is valid (otherwise, it would be withdrawn); on the othe= r >>>>hand, >>>>if no such sequences exist, than advertising is likely to be stale >>>>and hence >>>>could not be trusted. The conclusion is that opaque LSAs should neve= r >=20 > be >=20 >>>>flooded within AS, rather, within a single area, and, if there is a >>>>need for >>>>the information to be propagated beyond the area boundaries, ABRs >>>>must relay >>>>the advertising into other areas (by originating new area-scope >>>>LSAs). Note >>>>also that as far as I remember OSPF itself never uses AS scope >>>>advertisings >>>>for its own needs. For example, an ASBR does not distribute external >>>>routes >>>>learned by BGP from other ASs using AS scope LSAs, rather, the route= s >>>>are >>>>advertised within a single area and ABRs relay the advertisings into >>>>other >>>>areas. >>> >>> >>>This is not correct. External routes are redistributed with LSA Type = 5 >>>which are >>>flooded across the entire domain except in stub-area (not generated by >>>the ABR as type 3 as you mention). >>> >>>Anyway, back to the point, one cannot say of course that "Opaque LSA >>>Type 11 does not work". There are suitable to some application, this i= s >>>all. You can perfectly reply on an opaque LSA Type 11 to learn the >>>capability of a router which does not reside in the local area and rel= y >>>on another mechanism to detect its liveness. There are several such >>>examples. >>> >>>Hope this helps. >>> >>>JP. >>> >>> >>> >>>> >>>> >>>>The bottom line is that the TLVs described in the draft should be of >=20 > the >=20 >>>>area scope (just like TE LSAs), and hence it is not all that importan= t >>>>whether we use new high level TLVs or sub-TLVs of the TE router cap >=20 > TLV. >=20 >>>> >>>> >>>>Igor >>>> >>>> >>>> >>>> >>>> >>>>----- Original Message ----- >>>> >>>>From: "dimitri papadimitriou" >>>> >>>>To: "Adrian Farrel" >>>> >>>>Cc: "LE ROUX Jean-Louis RD-CORE-LAN" >>>>; >>>>"JP Vasseur" ; "Dimitri Papadimitriou" >>>>; >>>> >>>>Sent: Friday, November 18, 2005 10:57 AM >>>> >>>>Subject: Re: IGP Extensions - CCAMP Milestones >>>> >>>> >>>> >>>> >>>> >>>>>adrian >>>>> >>>>>i think JL's reply did partially translate the initial concern >>>>> >>>>>in brief, there are three well identified TE applications that could >>>>>make use of the TE node cap TLVs on both intra and inter-area basis: >>>>>- LSP Stitching edge node capability >>>>>- Edge nodes connecting/being P2MP TE egresses >>>>>- TE auto-mesh >>>>> >>>>>hence, the question on why keeping separated TLVs as part of the >=20 > router >=20 >>>>>capability and not consider these as sub-TLVs of the TE router cap >=20 > TLV >=20 >>>>>this would >>>>>1) provide a logical grouping of TE sub-TLVs as part of the same TL= V >>>>>and >>>>>2) leave the flexibility of flooding scope on a per application >=20 > need - >=20 >>>>>note: that the path computation specific sub-TLVs could still be >>>>>restricted with their current area-scope >>>>> >>>>>hope this clarifies the issue, >>>>> >>>>>thanks, >>>>>- dimitri. >>>>> >>>>>Adrian Farrel wrote: >>>>> >>>>> >>>>> >>>>>>If I understand the question it is... >>>>>> >>>>>>In draft-ietf-ospf-cap-07.txt introduces the OSPF router >>>>>>information LSA >>>>>>and states that this LSA may have type 9, 10 or 11 scope. >>>>>> >>>>>>In draft-vasseur-ccamp-te-node-cap-01.txt a new TLV (TE Node >>>>>>Capability >>>>>>Descriptor) is added to the OSPF router information LSA. This TLV >>>>>>(when >>>>>>generated) MUST be advertised with type 10 scope. JL has given the >>>>>> >>>> >>>>reason >>>> >>>> >>>>>>why this is limited to type 10. This reason is, of course, open for >>>>>>discussion as he says. >>>>>> >>>>>>In draft-vasseur-ccamp-automesh-02.txt a new TLV (TE-MESH-GROUP) is >>>>>> >>>> >>>>added >>>> >>>> >>>>>>to the OSPF router information LSA. It states that the LSA may be >>>>>>advertised with type 10 or type 11 scope. JP has given a reason wh= y >>>>>>you >>>>>>might want type 11 in addition to type 10. This reason is, of >=20 > course, >=20 >>>>open >>>> >>>> >>>>>>for discussion. >>>>>> >>>>>>An interesting feature is that a router advertising an AS-wide mesh >>>>>> >>>> >>>>group >>>> >>>> >>>>>>*and* a TE router capability may require that two OSPF router >>>>>> >>>> >>>>information >>>> >>>> >>>>>>LSAs are advertised by the router. >>>>>> >>>>>>The language in draft-ietf-ospf-cap-07.txt leans towards a router >>>>>> >>>> >>>>sending >>>> >>>> >>>>>>*an* OSPF router information LSA. But nowhere does it say that the >>>>>> >>>> >>>>router >>>> >>>> >>>>>>cannot send more than one and in section 2.5 we find... >>>>>> The originating router MAY advertise >>>>>> multiple RI LSAs as long as the flooding scopes differ. >>>>>> >>>>>>Hope this answers the point. >>>>>> >>>>>>Adrian >>>>>>----- Original Message ----- >>>>>>From: "LE ROUX Jean-Louis RD-CORE-LAN" >>>>>> >>>>>>To: "JP Vasseur" ; "Dimitri Papadimitriou" >>>>>>; "Dimitri Papadimitriou" >>>>>> >>>>>>Cc: ; >>>>>>Sent: Thursday, November 17, 2005 6:47 PM >>>>>>Subject: RE: IGP Extensions - CCAMP Milestones >>>>>> >>>>>> >>>>>>Hi Dimitri, >>>>>> >>>>>>Thanks for the comment. >>>>>> >>>>>>As just explained by JP, the TE Node Cap TLV carries topology >=20 > related >=20 >>>>>>parameters used as constraints in path computation. The leaking of >>>>>>such >>>>>>info across areas sounds useless as LSR TE visibility is limited t= o >>>>>>one >>>>>>area anyway... >>>>>>But this is, of course, open to discussions. By the way, do you >>>>>>have any >>>>>>application in mind where such leaking would be useful? >>>>>> >>>>>>Regards, >>>>>> >>>>>>JL >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>-----Message d'origine----- >>>>>>>De : JP Vasseur [mailto:jvasseur@cisco.com] >>>>>>>Envoy=E9 : jeudi 17 novembre 2005 16:58 >>>>>>>=C0 : Dimitri Papadimitriou; Dimitri Papadimitriou >>>>>>>Cc : zzx-adrian@olddog.co.uk; ccamp@ops.ietf.org; LE ROUX >>>>>>>Jean-Louis RD-CORE-LAN >>>>>>>Objet : Re: IGP Extensions - CCAMP Milestones >>>>>>> >>>>>>>Hi dimitri, >>>>>>> >>>>>>>On Nov 16, 2005, at 6:30 PM, dimitri papadimitriou wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>>adrian, >>>>>>>> >>>>>>>>could you explain the reasoning for having a TE specific TLV in >=20 > the >=20 >>>>>>>>auto-mesh document with area and AS-wide flooding scope >>>>>>>> >>>>>>> >>>>>>>while the TE >>>>>>> >>>>>>> >>>>>>> >>>>>>>>router cap TLV is restricted to an area flooding scope ? >>>>>>>>shouldn't be one way or the other i.e. either restrict all TE inf= o >>>>>>>>area-local or allow for TE router cap TLV with AS-wide >>>>>>>> >>>>>>> >>>>>>>flooding scope >>>>>>> >>>>>>> >>>>>>> >>>>>>>>? >>>>>>>> >>>>>>>>note: there is nothing in the TE router cap TLV that would impact >>>>>>>>scaling more than the TE auto-mesh TLV does >>>>>>>> >>>>>>>> >>>>>>> >>>>>>>I guess that the reason for allowing both intra and inter-area >>>>>>>flooding scopes for automesh is obvious (we need to have TE LSP >=20 > mesh >=20 >>>>>>>within areas and spanning multiple areas). >>>>>>> >>>>>>>So your question is probably why don't we allow the TE router >>>>>>>cap TLV >>>>>>>to be flooded across the domain ? As far as I can remember JL >>>>>>>already >>>>>>>answered this question ... JL, could you forward your email again = ? >>>>>>> >>>>>>>In the meantime, I can answer it: the reason is that such TE node >>>>>>>capabilities are used for TE LSP computation which cannot take int= o >>>>>>>account nodes that do not reside in the node's area. >>>>>>> >>>>>>>Thanks. >>>>>>> >>>>>>>JP. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>>thanks, >>>>>>>>- dimitri. >>>>>>>> >>>>>>>>Adrian Farrel wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>Hi, >>>>>>>>>We have two immediate milestones to address: >>>>>>>>>Oct 05 First version WG I-D for Advertising TE Node Capabilitie= s >>>>>>>>>in ISIS >>>>>>>>>and OSPF >>>>>>>>>Oct 05 First version WG I-D for Automatic discovery of >>>>>>>>> >>>>>>> >>>>>>>MPLS-TE mesh >>>>>>> >>>>>>> >>>>>>> >>>>>>>>>membership >>>>>>>>>There are two personal submissions which address these topics: >>>>>>>>>draft-vasseur-ccamp-te-node-cap-01.txt >>>>>>>>>draft-vasseur-ccamp-automesh-02.txt >>>>>>>>>I propose that we move these into the WG and then kick the tires >>>>>>>>>thoroughly. >>>>>>>>>Opinions please. >>>>>>>>>Thanks, >>>>>>>>>Adrian >>>>>>>>>. >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>> >>>>>> >>>>>> >>>>>>. >>>>>> >>>>>> >>>>> >>> >>>. >>> >> >=20 >=20 > . >=20 From gsandy@annecyclic.com Tue Nov 22 01:48:07 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeRwl-0006TT-EG for ccamp-archive@megatron.ietf.org; Tue, 22 Nov 2005 01:48:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA06392 for ; Tue, 22 Nov 2005 01:39:29 -0500 (EST) Received: from c-24-2-49-112.hsd1.ca.comcast.net ([24.2.49.112] helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EeRIX-0003L2-7q for ccamp-archive@ietf.org; Tue, 22 Nov 2005 01:06:36 -0500 Received: from [205.248.102.79] (port=25 helo=mailc.microsoft.com) by mailc.microsoft.com with smtp for bg@microsoft.com; Mon, 21 Nov 2005 21:47:13 -0800 Received: from [32.97.182.141] (port=25 helo=e1.ny.us.ibm.com) by e1.ny.us.ibm.com with smtp for bg@ibm.com; Mon, 21 Nov 2005 21:47:13 -0800 Message-ID: <000001c5ef27$12512d00$0100007f@localhost> From: "Gary Collins" To: Subject: Hey buddy, whats up Date: Mon, 21 Nov 2005 21:47:13 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C5EF27.12512D00" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 2.7 (++) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C5EF27.12512D00 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Finally the real thing- no more ripoffs! Enhancment Patches are hot right now, VERY hot! Unfortunately, most are cheap imitiations and do very little to increase your size and stamina. Well this is the real thing, not an imitation! One of the very originals, the absolutely strongest Patch available, anywhere! A top team of British scientists and medical doctors have worked to develop the state-of-the-art Pen1s Enlargment Patch delivery system which automatically increases pen1s size up to 3-4 full inches. The patches are the easiest and most effective way to increase your size. You won't have to take pills, get under the knife to perform expensive and very painful surgery, use any pumps or other devices. No one will ever find out that you are using our product. Just apply one patch on your body and wear it for 3 days and you will start noticing dramatic results. Millions of men are taking advantage of this revolutionary new product - Don't be left behind! As an added incentive, they are offering huge discount specials right now, check out the site to see for yourself! Here's the link to check out! http://www.tomasto.com/pt/?46&cyasp ------=_NextPart_000_0001_01C5EF27.12512D00 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Finally the real thing - no more tip-offs! Enhancment Patches are hot right now, VERY hot! Unfortunately, most are cheap imitiations and do very little to increase your size and stamina. Well this is the real thing, not an imitation! One of the very originals, the absolutely strongest Patch available, anywhere!

A top team of British scientists and medical doctors have worked to develop the state-of-the-art Pen1s Enlargment Patch delivery system which automatically increases pen1s size up to 3-4 full inches. The patches are the easiest and most effective way to increase your size. You won't have to take pills, get under the knife to perform expensive and very painful surgery, use any pumps or other devices. No one will ever find out that you are using our product. Just apply one patch on your body and wear it for 3 days and you will start noticing dramatic results.

Millions of men are taking advantage of this revolutionary new product - Don't be left behind!

As an added incentive, they are offering huge discount specials right now, check out the site to see for yourself!

Here's the link to check out!

NamePatchesRegularNow
Steel Package10 Patches$79.95$49.95Free shipping
Silver Package25 Patches$129.95$99.95Free shipping and exercise manual included
Gold Package40 Patches$189.95$149.95Free shipping and exercise manual included
Platinum Package65 Patches$259.95$199.95Free shipping and exercise manual included
------=_NextPart_000_0001_01C5EF27.12512D00-- From bill.mcnamara@warr.biz Tue Nov 22 04:06:59 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeU77-000230-VT for ccamp-archive@megatron.ietf.org; Tue, 22 Nov 2005 04:06:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20061 for ; Tue, 22 Nov 2005 04:06:20 -0500 (EST) Received: from [203.113.174.69] (helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EeUPj-0007Ih-QJ for ccamp-archive@ietf.org; Tue, 22 Nov 2005 04:26:13 -0500 Received: from [205.248.102.79] (port=25 helo=mailc.microsoft.com) by mailc.microsoft.com with smtp for bg@microsoft.com; Tue, 22 Nov 2005 16:06:31 +0700 Received: from [32.97.182.141] (port=25 helo=e1.ny.us.ibm.com) by e1.ny.us.ibm.com with smtp for bg@ibm.com; Tue, 22 Nov 2005 16:06:31 +0700 Message-ID: <000001c5ef43$22770580$0100007f@localhost> From: "Victor Bailey" To: Subject: Take advantage of special discounts now guys! Date: Tue, 22 Nov 2005 16:06:31 +0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C5EF43.22770580" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C5EF43.22770580 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Finally the real thing- no more ripoffs! Enhancment Patches are hot right now, VERY hot! Unfortunately, most are cheap imitiations and do very little to increase your size and stamina. Well this is the real thing, not an imitation! One of the very originals, the absolutely strongest Patch available, anywhere! A top team of British scientists and medical doctors have worked to develop the state-of-the-art Pen1s Enlargment Patch delivery system which automatically increases pen1s size up to 3-4 full inches. The patches are the easiest and most effective way to increase your size. You won't have to take pills, get under the knife to perform expensive and very painful surgery, use any pumps or other devices. No one will ever find out that you are using our product. Just apply one patch on your body and wear it for 3 days and you will start noticing dramatic results. Millions of men are taking advantage of this revolutionary new product - Don't be left behind! As an added incentive, they are offering huge discount specials right now, check out the site to see for yourself! Here's the link to check out! http://www.tomasto.com/pt/?46&cyasp ------=_NextPart_000_0001_01C5EF43.22770580 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Finally the real thing - no more tip-offs! Enhancment Patches are hot right now, VERY hot! Unfortunately, most are cheap imitiations and do very little to increase your size and stamina. Well this is the real thing, not an imitation! One of the very originals, the absolutely strongest Patch available, anywhere!

A top team of British scientists and medical doctors have worked to develop the state-of-the-art Pen1s Enlargment Patch delivery system which automatically increases pen1s size up to 3-4 full inches. The patches are the easiest and most effective way to increase your size. You won't have to take pills, get under the knife to perform expensive and very painful surgery, use any pumps or other devices. No one will ever find out that you are using our product. Just apply one patch on your body and wear it for 3 days and you will start noticing dramatic results.

Millions of men are taking advantage of this revolutionary new product - Don't be left behind!

As an added incentive, they are offering huge discount specials right now, check out the site to see for yourself!

Here's the link to check out!

NamePatchesRegularNow
Steel Package10 Patches$79.95$49.95Free shipping
Silver Package25 Patches$129.95$99.95Free shipping and exercise manual included
Gold Package40 Patches$189.95$149.95Free shipping and exercise manual included
Platinum Package65 Patches$259.95$199.95Free shipping and exercise manual included
------=_NextPart_000_0001_01C5EF43.22770580-- From owner-ccamp@ops.ietf.org Tue Nov 22 04:17:16 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeUH6-0006j1-Od for ccamp-archive@megatron.ietf.org; Tue, 22 Nov 2005 04:17:16 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20911 for ; Tue, 22 Nov 2005 04:16:39 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EeUZj-0007dA-4r for ccamp-archive@ietf.org; Tue, 22 Nov 2005 04:36:31 -0500 Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EeU8Q-000KqC-7M for ccamp-data@psg.com; Tue, 22 Nov 2005 09:08:18 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: * X-Spam-Status: No, score=2.0 required=5.0 tests=BAYES_00,MIME_BASE64_BLANKS, MIME_BASE64_NO_NAME,MIME_BASE64_TEXT,RCVD_IN_WHOIS_INVALID autolearn=no version=3.1.0 Received: from [61.144.161.54] (helo=huawei.com) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1EeU8L-000Kpr-VE for ccamp@ops.ietf.org; Tue, 22 Nov 2005 09:08:16 +0000 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IQC00C8GMV20K@szxga02-in.huawei.com> for ccamp@ops.ietf.org; Tue, 22 Nov 2005 17:11:27 +0800 (CST) Received: from szxml01-in ([172.24.1.3]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IQC007JAMV1IK@szxga02-in.huawei.com> for ccamp@ops.ietf.org; Tue, 22 Nov 2005 17:11:26 +0800 (CST) Received: from x19371b ([10.70.76.210]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IQC00DB5N0IM8@szxml01-in.huawei.com>; Tue, 22 Nov 2005 17:14:42 +0800 (CST) Date: Tue, 22 Nov 2005 17:01:31 +0800 From: Mr Xu Subject: Re: IGP Extensions - CCAMP Milestones To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be, Igor Bryskin Cc: dimitri.papadimitriou@alcatel.be, JP Vasseur , Adrian Farrel , LE ROUX Jean-Louis RD-CORE-LAN , ccamp@ops.ietf.org Message-id: <006401c5ef43$54c28a50$d24c460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4939.300 X-Mailer: Microsoft Outlook Express 5.50.4922.1500 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: base64 X-Priority: 3 X-MSMail-priority: Normal References: <05d401c5ebb8$f343bde0$d501a8c0@Puppy> <437DFA01.9080804@psg.com> <01ae01c5ed24$891c5c70$6601a8c0@movaz.com> <4380D135.2080202@psg.com> <00b101c5eeaf$32c0a2a0$7a1810ac@movaz.com> <43825610.7060706@psg.com> Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 2.2 (++) X-Scan-Signature: 3f3e54d3c03ed638c06aa9fa6861237e Content-Transfer-Encoding: base64 SSB0aGluayBkaXN0cmlidXRpbmcgb3BhcXVlIExTQXMgZm9yIFRFIHJvdXRlciBjYXAgYWNyb3Nz IE9TUEYgZG9tYWluIGlzIG5vdCBhIGdvb2QgaWRlYSwgYmVjYXVzZSB0aGlzIGluZm9ybWF0aW9u IGlzIGNvbmNyZXRlIGFuZCBjYW4gbm90IGFnZ3JlZ2F0ZWQsIGl0IHdpbGwgY2F1c2UgdG9vIG11 Y2ggZmxvb2RpbmcgaW4gYW4gQVMuIA0KDQoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioN ClRoaXMgZS1tYWlsIGFuZCBpdHMgYXR0YWNobWVudHMgY29udGFpbiBjb25maWRlbnRpYWwgaW5m b3JtYXRpb24gZnJvbSBIVUFXRUksIHdoaWNoIGlzIGludGVuZGVkIG9ubHkgZm9yIHRoZSBwZXJz b24gb3IgZW50aXR5IHdob3NlIGFkZHJlc3MgaXMgbGlzdGVkIGFib3ZlLiBBbnkgdXNlIG9mIHRo ZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaGVyZWluIGluIGFueSB3YXkgKGluY2x1ZGluZywgYnV0 IG5vdCBsaW1pdGVkIHRvLCB0b3RhbCBvciBwYXJ0aWFsIGRpc2Nsb3N1cmUsIHJlcHJvZHVjdGlv biwgb3IgZGlzc2VtaW5hdGlvbikgYnkgcGVyc29ucyBvdGhlciB0aGFuIHRoZSBpbnRlbmRlZCBy ZWNpcGllbnQocykgaXMgcHJvaGliaXRlZC4gSWYgeW91IHJlY2VpdmUgdGhpcyBlLW1haWwgaW4g ZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBieSBwaG9uZSBvciBlbWFpbCBpbW1lZGlh dGVseSBhbmQgZGVsZXRlIGl0IQ0KKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqDQoNCi0t LS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0gDQpGcm9tOiAiZGltaXRyaSBwYXBhZGltaXRyaW91 IiA8ZHBhcGFkaW1pdHJpb3VAcHNnLmNvbT4NClRvOiAiSWdvciBCcnlza2luIiA8aWJyeXNraW5A bW92YXouY29tPg0KQ2M6IDxkaW1pdHJpLnBhcGFkaW1pdHJpb3VAYWxjYXRlbC5iZT47ICJKUCBW YXNzZXVyIiA8anZhc3NldXJAY2lzY28uY29tPjsgIkFkcmlhbiBGYXJyZWwiIDxhZHJpYW5Ab2xk ZG9nLmNvLnVrPjsgIkxFIFJPVVggSmVhbi1Mb3VpcyBSRC1DT1JFLUxBTiIgPGplYW5sb3Vpcy5s ZXJvdXhAZnJhbmNldGVsZWNvbS5jb20+OyA8Y2NhbXBAb3BzLmlldGYub3JnPg0KU2VudDogVHVl c2RheSwgTm92ZW1iZXIgMjIsIDIwMDUgNzoxOSBBTQ0KU3ViamVjdDogUmU6IElHUCBFeHRlbnNp b25zIC0gQ0NBTVAgTWlsZXN0b25lcw0KDQoNCj4gaWdvcg0KPiANCj4gSWdvciBCcnlza2luIHdy b3RlOg0KPiANCj4gPiBEaW1pdHJpLA0KPiA+IA0KPiA+IFNlZSBteSByZXBseSB0byBKUC4gQWxz byBzZWUgYmVsb3cuDQo+ID4gDQo+ID4gLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSANCj4g PiBGcm9tOiAiZGltaXRyaSBwYXBhZGltaXRyaW91IiA8ZHBhcGFkaW1pdHJpb3VAcHNnLmNvbT4N Cj4gPiBUbzogIkpQIFZhc3NldXIiIDxqdmFzc2V1ckBjaXNjby5jb20+DQo+ID4gQ2M6ICJJZ29y IEJyeXNraW4iIDxpYnJ5c2tpbkBtb3Zhei5jb20+OyA8ZGltaXRyaS5wYXBhZGltaXRyaW91QGFs Y2F0ZWwuYmU+Ow0KPiA+ICJBZHJpYW4gRmFycmVsIiA8YWRyaWFuQG9sZGRvZy5jby51az47ICJM RSBST1VYIEplYW4tTG91aXMgUkQtQ09SRS1MQU4iDQo+ID4gPGplYW5sb3Vpcy5sZXJvdXhAZnJh bmNldGVsZWNvbS5jb20+OyA8Y2NhbXBAb3BzLmlldGYub3JnPg0KPiA+IFNlbnQ6IFN1bmRheSwg Tm92ZW1iZXIgMjAsIDIwMDUgMjo0MCBQTQ0KPiA+IFN1YmplY3Q6IFJlOiBJR1AgRXh0ZW5zaW9u cyAtIENDQU1QIE1pbGVzdG9uZXMNCj4gPiANCj4gPiANCj4gPiANCj4gPj5oaSBqcCwNCj4gPj4N Cj4gPj5pbmRlZWQsIGkgZG9uJ3QgcmVhbGx5IHVuZGVyc3RhbmQgdGhlIGlzc3VlIGJyb3VnaHQg dXAgYnkgaWdvcjsNCj4gPj4NCj4gPj5pbiB0aGUgcHJlc2VudCBjYXNlLCBvbmUgc2hvdWxkIGFs c28gdW5kZXJsaW5lIHRoYXQsIHRoZSBpbmZvcm1hdGlvbg0KPiA+PmRpc3RyaWJ1dGVkIGFjcm9z cyB0aGUgT1NQRiBkb21haW4gdXNpbmcgb3BhcXVlIExTQXMsIGlzICppbmRpcmVjdGx5Kg0KPiA+ PnVzZWQgYnkgZS5nLiBURSBhcHBsaWNhdGlvbnMgKG5vdGU6IFJGQzIzNzAgYWxsb3dzIGZvciB0 aGlzIGluZm9ybWF0aW9uDQo+ID4+dG8gYmUgdXNlZCBkaXJlY3RseSBieSBPU1BGIGJ1dCBpIHRo aW5rIHdlJ3JlIG5vdCBkaXNjdXNzaW5nIHRoaXMNCj4gPj5hbHRlcm5hdGl2ZSkNCj4gPj4NCj4g Pj50aGlzIG1lYW5zIHRoYXQgdGhlc2UgZS5nLiBURSBhcHBsaWNhdGlvbnMgY2FuIGluIGNhc2Ug b2YgY29udHJvbCBlbmdpbmUNCj4gPj5mYWlsdXJlIGRldGVjdCB0aGlzIGZhaWx1cmUgYW5kIHRy aWdnZXIgYW55IG5lY2Vzc2FyeSBhY3Rpb24gaW4gb3JkZXIgdG8NCj4gPj5hdm9pZCB0aGUgYmVo YXZpb3VyIGRlc2NyaWJlZCBieSBpZ29yDQo+ID4gDQo+ID4gDQo+ID4gSUI+PiBUd28gcG9pbnRz IGhlcmU6DQo+ID4gDQo+ID4gYSkgYWxsIFRFIExTQXMgYXJlIG9mIHRoZSBhcmVhIHNjb3BlOw0K PiANCj4geW91IGFyZSBjb25mdXNpbmcgVEUgTFNBcyAob3BhcXVlIHR5cGUgMSwgYXJlYS1zY29w ZSkgYXBwbGljYWJpbGl0eSB3aXRoIA0KPiB0aGUgYnJvYWRlciBjb250ZXh0IG9mIGUuZy4gVEUg YXBwbGljYXRpb25zIChzZWUgaW5pdGlhbCBzdGF0ZW1lbnQpIHRoYXQgDQo+IGNhbiBtYWtlIHVz ZSBvZiBSSSBMU0FzIGZvciBpbnN0Lg0KPiANCj4gPiBiKSBBIFRFIGFwcGxpY2F0aW9uIGNhbiBk ZXRlY3QgYSBjb250cm9sIGVuZ2luZSBmYWlsdXJlIG9ubHkgd2l0aGluIG9uZQ0KPiA+IGFyZWEu IA0KPiANCj4gdGhpcyBpcyBub3QgY29ycmVjdCwgYXMgYnkgZGVmaW5pdGlvbiwgYXBwbGljYXRp b24gZGVwZW5kZW50Ow0KPiANCj4gdGhhbmtzLA0KPiAtIGRpbWl0cmkuDQo+IA0KPiA+IEl0IGRv ZXMgbm90IGhlbHAgZm9yIExTUnMgbG9jYXRlZCBvdXRzaWRlIG9mIHRoaXMgYXJlYSBiZWNhdXNl IG5vIExTUg0KPiA+IChpbmNsdWRpbmcgQUJSKSBpcyBhbGxvd2VkIHRvIHdpdGhkcmF3IHNvbWVi b2R5IGVsc2UncyBMU0FzIC0gdGhlIExTQXMgY291bGQNCj4gPiBiZSB3aXRoZHJhd24gb3IgbW9k aWZpZWQgYnkgdGhlIExTUiB0aGF0IGhhcyBvcmlnaW5hdGVkIHRoZW0uDQo+ID4gIA0KPiA+IEln b3INCj4gPiANCj4gPiANCj4gPj50aGFua3MsDQo+ID4+LSBkaW1pdHJpLg0KPiA+Pg0KPiA+PkpQ IFZhc3NldXIgd3JvdGU6DQo+ID4+DQo+ID4+PkhpIElnb3IsDQo+ID4+Pg0KPiA+Pj5PbiBOb3Yg MTksIDIwMDUsIGF0IDExOjE2IEFNLCBJZ29yIEJyeXNraW4gd3JvdGU6DQo+ID4+Pg0KPiA+Pj4N Cj4gPj4+PkhpIGV2ZXJ5Ym9keSwNCj4gPj4+Pg0KPiA+Pj4+DQo+ID4+Pj4NCj4gPj4+PkknZCBs aWtlIHRvIG5vdGUgdGhhdCBhbHRob3VnaCB0aGUgQVMgc2NvcGUgZmxvb2RpbmcgaXMgYWxsb3dl ZCBmb3INCj4gPj4+Pm9wYXF1ZQ0KPiA+Pj4+TFNBcywgaW4gbXkgZXhwZXJpZW5jZSBpdCBkb2Vz IG5vdCB3b3JrLg0KPiA+Pj4NCj4gPj4+DQo+ID4+PlNvIHlvdXIgZXhwZXJpZW5jZSBpcyBkaWZm ZXJlbnQgdGhhbiB0aGUgb25lIG9mIG1hbnkgcGVvcGxlIC4uLiAgT3BhcXVlDQo+ID4+PkxTQSBo YXZlIGJlZW4NCj4gPj4+dXNlZCBmb3IgcXVpdGUgYSBmZXcgeWVhcnMgd2l0aG91dCBhbnkgcHJv YmxlbS4gU2VlIFJGQzIzNzAgKEp1bHkgMTk5OCkNCj4gPj4+DQo+ID4+Pg0KPiA+Pj4+SW1hZ2lu ZSB0aGF0IHNvbWUgcm91dGluZw0KPiA+Pj4+Y29udHJvbGxlciBhZHZlcnRpc2VzIGFuIEFTIHNj b3BlIExTQSBhbmQgZ29lcyBvdXQgb2Ygc2VydmljZSAgcXVpY2tseQ0KPiA+Pj4+YWZ0ZXINCj4g Pj4+PnRoYXQuIENvbnRyb2xsZXJzIG91dHNpZGUgb2YgdGhlIGFyZWEgdGhhdCB0aGUgZGVhZCBj b250cm9sbGVyDQo+ID4+Pj5iZWxvbmdzIHRvDQo+ID4+Pj5oYXZlIG5vIHdheSBvZiBkZXRlY3Rp bmcgaXRzIGRlYXRoIGFuZCwgdGhlcmVmb3JlLCB3aWxsIGtlZXAgdXNpbmcgdGhlDQo+ID4+Pj5h ZHZlcnRpc2luZyBmb3IgYW5vdGhlciA5MCBtaW4gYmVmb3JlIHRoZSBMU0EgdGltZXMgb3V0Lg0K PiA+Pj4NCj4gPj4+DQo+ID4+PkkgZ3Vlc3MgdGhhdCB5b3UgbWVhbiA2MCBtaW4gKE1heGFnZT02 MG1uLCBBcmNoaXRlY3R1cmFsIENvbnN0YW50KSAtDQo+ID4+PlNlZSBSRkMyMzI4LCBidXQgdGhp cyBpcyBub3QgdGhlIHBvaW50LCBzZWUgYmVsb3cuDQo+ID4+Pg0KPiA+Pj4NCj4gPj4+Pk5vdGUg dGhhdCB0aGUNCj4gPj4+PmNvbnRyb2xsZXJzIGxvY2F0ZWQgd2l0aGluIHRoZSBzYW1lIGFyZWEg ZG8gbm90IGhhdmUgc3VjaCBhIHByb2JsZW0NCj4gPj4+PmJlY2F1c2UNCj4gPj4+PnRoZXkgY2Fu IGFsd2F5cyB2ZXJpZnkgdGhlIHZhbGlkaXR5IG9mIHRoZSBhZHZlcnRpc2luZyBieSB0cnlpbmcg dG8NCj4gPj4+PmxvY2F0ZSBhDQo+ID4+Pj5zZXF1ZW5jZSBvZiBhY3RpdmUgYWRqYWNlbmNpZXMg aW50ZXJjb25uZWN0aW5nIGVhY2ggb2YgdGhlbSB3aXRoIHRoZQ0KPiA+Pj4+YWR2ZXJ0aXNpbmcg Y29udHJvbGxlci4gSWYgdGhleSBmaW5kIGF0IGxlYXN0IG9uZSBzdWNoIGEgc2VxdWVuY2UsIHRo ZQ0KPiA+Pj4+YWR2ZXJ0aXNpbmcgaXMgdmFsaWQgKG90aGVyd2lzZSwgaXQgd291bGQgYmUgd2l0 aGRyYXduKTsgb24gdGhlICBvdGhlcg0KPiA+Pj4+aGFuZCwNCj4gPj4+PmlmIG5vIHN1Y2ggc2Vx dWVuY2VzIGV4aXN0LCB0aGFuIGFkdmVydGlzaW5nIGlzIGxpa2VseSB0byBiZSBzdGFsZQ0KPiA+ Pj4+YW5kIGhlbmNlDQo+ID4+Pj5jb3VsZCBub3QgYmUgdHJ1c3RlZC4gVGhlIGNvbmNsdXNpb24g aXMgdGhhdCBvcGFxdWUgTFNBcyBzaG91bGQgIG5ldmVyDQo+ID4gDQo+ID4gYmUNCj4gPiANCj4g Pj4+PmZsb29kZWQgd2l0aGluIEFTLCByYXRoZXIsIHdpdGhpbiBhIHNpbmdsZSBhcmVhLCBhbmQs IGlmIHRoZXJlIGlzIGENCj4gPj4+Pm5lZWQgZm9yDQo+ID4+Pj50aGUgaW5mb3JtYXRpb24gdG8g YmUgcHJvcGFnYXRlZCBiZXlvbmQgdGhlIGFyZWEgYm91bmRhcmllcywgQUJScw0KPiA+Pj4+bXVz dCByZWxheQ0KPiA+Pj4+dGhlIGFkdmVydGlzaW5nIGludG8gb3RoZXIgYXJlYXMgKGJ5IG9yaWdp bmF0aW5nIG5ldyBhcmVhLXNjb3BlDQo+ID4+Pj5MU0FzKS4gTm90ZQ0KPiA+Pj4+YWxzbyB0aGF0 IGFzIGZhciBhcyBJIHJlbWVtYmVyIE9TUEYgaXRzZWxmIG5ldmVyIHVzZXMgQVMgc2NvcGUNCj4g Pj4+PmFkdmVydGlzaW5ncw0KPiA+Pj4+Zm9yIGl0cyBvd24gbmVlZHMuIEZvciBleGFtcGxlLCBh biBBU0JSIGRvZXMgbm90IGRpc3RyaWJ1dGUgIGV4dGVybmFsDQo+ID4+Pj5yb3V0ZXMNCj4gPj4+ PmxlYXJuZWQgYnkgQkdQIGZyb20gb3RoZXIgQVNzIHVzaW5nIEFTIHNjb3BlIExTQXMsIHJhdGhl ciwgdGhlICByb3V0ZXMNCj4gPj4+PmFyZQ0KPiA+Pj4+YWR2ZXJ0aXNlZCB3aXRoaW4gYSBzaW5n bGUgYXJlYSBhbmQgQUJScyByZWxheSB0aGUgYWR2ZXJ0aXNpbmdzICBpbnRvDQo+ID4+Pj5vdGhl cg0KPiA+Pj4+YXJlYXMuDQo+ID4+Pg0KPiA+Pj4NCj4gPj4+VGhpcyBpcyBub3QgY29ycmVjdC4g RXh0ZXJuYWwgcm91dGVzIGFyZSByZWRpc3RyaWJ1dGVkIHdpdGggTFNBIFR5cGUgIDUNCj4gPj4+ d2hpY2ggYXJlDQo+ID4+PmZsb29kZWQgYWNyb3NzIHRoZSBlbnRpcmUgZG9tYWluIGV4Y2VwdCBp biBzdHViLWFyZWEgKG5vdCBnZW5lcmF0ZWQgYnkNCj4gPj4+dGhlIEFCUiBhcyB0eXBlIDMgYXMg eW91IG1lbnRpb24pLg0KPiA+Pj4NCj4gPj4+QW55d2F5LCBiYWNrIHRvIHRoZSBwb2ludCwgb25l IGNhbm5vdCBzYXkgb2YgY291cnNlIHRoYXQgIk9wYXF1ZSBMU0ENCj4gPj4+VHlwZSAxMSBkb2Vz IG5vdCB3b3JrIi4gVGhlcmUgYXJlIHN1aXRhYmxlIHRvIHNvbWUgYXBwbGljYXRpb24sIHRoaXMg aXMNCj4gPj4+YWxsLiBZb3UgY2FuIHBlcmZlY3RseSByZXBseSBvbiBhbiBvcGFxdWUgTFNBIFR5 cGUgMTEgdG8gbGVhcm4gdGhlDQo+ID4+PmNhcGFiaWxpdHkgb2YgYSByb3V0ZXIgd2hpY2ggZG9l cyBub3QgcmVzaWRlIGluIHRoZSBsb2NhbCBhcmVhIGFuZCByZWx5DQo+ID4+Pm9uIGFub3RoZXIg bWVjaGFuaXNtIHRvIGRldGVjdCBpdHMgbGl2ZW5lc3MuIFRoZXJlIGFyZSBzZXZlcmFsIHN1Y2gN Cj4gPj4+ZXhhbXBsZXMuDQo+ID4+Pg0KPiA+Pj5Ib3BlIHRoaXMgaGVscHMuDQo+ID4+Pg0KPiA+ Pj5KUC4NCj4gPj4+DQo+ID4+Pg0KPiA+Pj4NCj4gPj4+Pg0KPiA+Pj4+DQo+ID4+Pj5UaGUgYm90 dG9tIGxpbmUgaXMgdGhhdCB0aGUgVExWcyBkZXNjcmliZWQgaW4gdGhlIGRyYWZ0IHNob3VsZCBi ZSAgb2YNCj4gPiANCj4gPiB0aGUNCj4gPiANCj4gPj4+PmFyZWEgc2NvcGUgKGp1c3QgbGlrZSBU RSBMU0FzKSwgYW5kIGhlbmNlIGl0IGlzIG5vdCBhbGwgdGhhdCBpbXBvcnRhbnQNCj4gPj4+Pndo ZXRoZXIgd2UgdXNlIG5ldyBoaWdoIGxldmVsIFRMVnMgb3Igc3ViLVRMVnMgb2YgdGhlIFRFIHJv dXRlciBjYXANCj4gPiANCj4gPiBUTFYuDQo+ID4gDQo+ID4+Pj4NCj4gPj4+Pg0KPiA+Pj4+SWdv cg0KPiA+Pj4+DQo+ID4+Pj4NCj4gPj4+Pg0KPiA+Pj4+DQo+ID4+Pj4NCj4gPj4+Pi0tLS0tIE9y aWdpbmFsIE1lc3NhZ2UgLS0tLS0NCj4gPj4+Pg0KPiA+Pj4+RnJvbTogImRpbWl0cmkgcGFwYWRp bWl0cmlvdSIgPGRwYXBhZGltaXRyaW91QHBzZy5jb20+DQo+ID4+Pj4NCj4gPj4+PlRvOiAiQWRy aWFuIEZhcnJlbCIgPGFkcmlhbkBvbGRkb2cuY28udWs+DQo+ID4+Pj4NCj4gPj4+PkNjOiAiTEUg Uk9VWCBKZWFuLUxvdWlzIFJELUNPUkUtTEFOIg0KPiA+Pj4+PGplYW5sb3Vpcy5sZXJvdXhAZnJh bmNldGVsZWNvbS5jb20+Ow0KPiA+Pj4+IkpQIFZhc3NldXIiIDxqdmFzc2V1ckBjaXNjby5jb20+ OyAiRGltaXRyaSBQYXBhZGltaXRyaW91Ig0KPiA+Pj4+PGRpbWl0cmkucGFwYWRpbWl0cmlvdUBh bGNhdGVsLmJlPjsgPGNjYW1wQG9wcy5pZXRmLm9yZz4NCj4gPj4+Pg0KPiA+Pj4+U2VudDogRnJp ZGF5LCBOb3ZlbWJlciAxOCwgMjAwNSAxMDo1NyBBTQ0KPiA+Pj4+DQo+ID4+Pj5TdWJqZWN0OiBS ZTogSUdQIEV4dGVuc2lvbnMgLSBDQ0FNUCBNaWxlc3RvbmVzDQo+ID4+Pj4NCj4gPj4+Pg0KPiA+ Pj4+DQo+ID4+Pj4NCj4gPj4+Pg0KPiA+Pj4+PmFkcmlhbg0KPiA+Pj4+Pg0KPiA+Pj4+PmkgdGhp bmsgSkwncyByZXBseSBkaWQgcGFydGlhbGx5IHRyYW5zbGF0ZSB0aGUgaW5pdGlhbCBjb25jZXJu DQo+ID4+Pj4+DQo+ID4+Pj4+aW4gYnJpZWYsIHRoZXJlIGFyZSB0aHJlZSB3ZWxsIGlkZW50aWZp ZWQgVEUgYXBwbGljYXRpb25zIHRoYXQgY291bGQNCj4gPj4+Pj5tYWtlIHVzZSBvZiB0aGUgVEUg bm9kZSBjYXAgVExWcyBvbiBib3RoIGludHJhIGFuZCBpbnRlci1hcmVhIGJhc2lzOg0KPiA+Pj4+ Pi0gTFNQIFN0aXRjaGluZyBlZGdlIG5vZGUgY2FwYWJpbGl0eQ0KPiA+Pj4+Pi0gRWRnZSBub2Rl cyBjb25uZWN0aW5nL2JlaW5nIFAyTVAgVEUgZWdyZXNzZXMNCj4gPj4+Pj4tIFRFIGF1dG8tbWVz aA0KPiA+Pj4+Pg0KPiA+Pj4+PmhlbmNlLCB0aGUgcXVlc3Rpb24gb24gd2h5IGtlZXBpbmcgc2Vw YXJhdGVkIFRMVnMgYXMgcGFydCBvZiB0aGUNCj4gPiANCj4gPiByb3V0ZXINCj4gPiANCj4gPj4+ Pj5jYXBhYmlsaXR5IGFuZCBub3QgY29uc2lkZXIgdGhlc2UgYXMgc3ViLVRMVnMgb2YgdGhlIFRF IHJvdXRlciBjYXANCj4gPiANCj4gPiBUTFYNCj4gPiANCj4gPj4+Pj50aGlzIHdvdWxkDQo+ID4+ Pj4+MSkgcHJvdmlkZSBhIGxvZ2ljYWwgZ3JvdXBpbmcgb2YgVEUgc3ViLVRMVnMgYXMgcGFydCBv ZiB0aGUgc2FtZSAgVExWDQo+ID4+Pj4+YW5kDQo+ID4+Pj4+MikgbGVhdmUgdGhlIGZsZXhpYmls aXR5IG9mIGZsb29kaW5nIHNjb3BlIG9uIGEgcGVyIGFwcGxpY2F0aW9uDQo+ID4gDQo+ID4gIG5l ZWQgLQ0KPiA+IA0KPiA+Pj4+Pm5vdGU6IHRoYXQgdGhlIHBhdGggY29tcHV0YXRpb24gc3BlY2lm aWMgc3ViLVRMVnMgY291bGQgc3RpbGwgYmUNCj4gPj4+Pj5yZXN0cmljdGVkIHdpdGggdGhlaXIg Y3VycmVudCBhcmVhLXNjb3BlDQo+ID4+Pj4+DQo+ID4+Pj4+aG9wZSB0aGlzIGNsYXJpZmllcyB0 aGUgaXNzdWUsDQo+ID4+Pj4+DQo+ID4+Pj4+dGhhbmtzLA0KPiA+Pj4+Pi0gZGltaXRyaS4NCj4g Pj4+Pj4NCj4gPj4+Pj5BZHJpYW4gRmFycmVsIHdyb3RlOg0KPiA+Pj4+Pg0KPiA+Pj4+Pg0KPiA+ Pj4+Pg0KPiA+Pj4+Pj5JZiBJIHVuZGVyc3RhbmQgdGhlIHF1ZXN0aW9uIGl0IGlzLi4uDQo+ID4+ Pj4+Pg0KPiA+Pj4+Pj5JbiBkcmFmdC1pZXRmLW9zcGYtY2FwLTA3LnR4dCBpbnRyb2R1Y2VzIHRo ZSBPU1BGIHJvdXRlcg0KPiA+Pj4+Pj5pbmZvcm1hdGlvbiBMU0ENCj4gPj4+Pj4+YW5kIHN0YXRl cyB0aGF0IHRoaXMgTFNBIG1heSBoYXZlIHR5cGUgOSwgMTAgb3IgMTEgc2NvcGUuDQo+ID4+Pj4+ Pg0KPiA+Pj4+Pj5JbiBkcmFmdC12YXNzZXVyLWNjYW1wLXRlLW5vZGUtY2FwLTAxLnR4dCBhIG5l dyBUTFYgKFRFIE5vZGUNCj4gPj4+Pj4+Q2FwYWJpbGl0eQ0KPiA+Pj4+Pj5EZXNjcmlwdG9yKSBp cyBhZGRlZCB0byB0aGUgT1NQRiByb3V0ZXIgaW5mb3JtYXRpb24gTFNBLiBUaGlzIFRMVg0KPiA+ Pj4+Pj4od2hlbg0KPiA+Pj4+Pj5nZW5lcmF0ZWQpIE1VU1QgYmUgYWR2ZXJ0aXNlZCB3aXRoIHR5 cGUgMTAgc2NvcGUuIEpMIGhhcyBnaXZlbiB0aGUNCj4gPj4+Pj4+DQo+ID4+Pj4NCj4gPj4+PnJl YXNvbg0KPiA+Pj4+DQo+ID4+Pj4NCj4gPj4+Pj4+d2h5IHRoaXMgaXMgbGltaXRlZCB0byB0eXBl IDEwLiBUaGlzIHJlYXNvbiBpcywgb2YgY291cnNlLCBvcGVuIGZvcg0KPiA+Pj4+Pj5kaXNjdXNz aW9uIGFzIGhlIHNheXMuDQo+ID4+Pj4+Pg0KPiA+Pj4+Pj5JbiBkcmFmdC12YXNzZXVyLWNjYW1w LWF1dG9tZXNoLTAyLnR4dCBhIG5ldyBUTFYgKFRFLU1FU0gtR1JPVVApIGlzDQo+ID4+Pj4+Pg0K PiA+Pj4+DQo+ID4+Pj5hZGRlZA0KPiA+Pj4+DQo+ID4+Pj4NCj4gPj4+Pj4+dG8gdGhlIE9TUEYg cm91dGVyIGluZm9ybWF0aW9uIExTQS4gSXQgc3RhdGVzIHRoYXQgdGhlIExTQSBtYXkgYmUNCj4g Pj4+Pj4+YWR2ZXJ0aXNlZCB3aXRoIHR5cGUgMTAgb3IgdHlwZSAxMSBzY29wZS4gSlAgaGFzIGdp dmVuIGEgcmVhc29uICB3aHkNCj4gPj4+Pj4+eW91DQo+ID4+Pj4+Pm1pZ2h0IHdhbnQgdHlwZSAx MSBpbiBhZGRpdGlvbiB0byB0eXBlIDEwLiBUaGlzIHJlYXNvbiBpcywgb2YNCj4gPiANCj4gPiBj b3Vyc2UsDQo+ID4gDQo+ID4+Pj5vcGVuDQo+ID4+Pj4NCj4gPj4+Pg0KPiA+Pj4+Pj5mb3IgZGlz Y3Vzc2lvbi4NCj4gPj4+Pj4+DQo+ID4+Pj4+PkFuIGludGVyZXN0aW5nIGZlYXR1cmUgaXMgdGhh dCBhIHJvdXRlciBhZHZlcnRpc2luZyBhbiBBUy13aWRlIG1lc2gNCj4gPj4+Pj4+DQo+ID4+Pj4N Cj4gPj4+Pmdyb3VwDQo+ID4+Pj4NCj4gPj4+Pg0KPiA+Pj4+Pj4qYW5kKiBhIFRFIHJvdXRlciBj YXBhYmlsaXR5IG1heSByZXF1aXJlIHRoYXQgdHdvIE9TUEYgcm91dGVyDQo+ID4+Pj4+Pg0KPiA+ Pj4+DQo+ID4+Pj5pbmZvcm1hdGlvbg0KPiA+Pj4+DQo+ID4+Pj4NCj4gPj4+Pj4+TFNBcyBhcmUg YWR2ZXJ0aXNlZCBieSB0aGUgcm91dGVyLg0KPiA+Pj4+Pj4NCj4gPj4+Pj4+VGhlIGxhbmd1YWdl IGluIGRyYWZ0LWlldGYtb3NwZi1jYXAtMDcudHh0IGxlYW5zIHRvd2FyZHMgYSByb3V0ZXINCj4g Pj4+Pj4+DQo+ID4+Pj4NCj4gPj4+PnNlbmRpbmcNCj4gPj4+Pg0KPiA+Pj4+DQo+ID4+Pj4+Piph biogT1NQRiByb3V0ZXIgaW5mb3JtYXRpb24gTFNBLiBCdXQgbm93aGVyZSBkb2VzIGl0IHNheSB0 aGF0IHRoZQ0KPiA+Pj4+Pj4NCj4gPj4+Pg0KPiA+Pj4+cm91dGVyDQo+ID4+Pj4NCj4gPj4+Pg0K PiA+Pj4+Pj5jYW5ub3Qgc2VuZCBtb3JlIHRoYW4gb25lIGFuZCBpbiBzZWN0aW9uIDIuNSB3ZSBm aW5kLi4uDQo+ID4+Pj4+PiAgVGhlIG9yaWdpbmF0aW5nIHJvdXRlciBNQVkgYWR2ZXJ0aXNlDQo+ ID4+Pj4+PiAgIG11bHRpcGxlIFJJIExTQXMgYXMgbG9uZyBhcyB0aGUgZmxvb2Rpbmcgc2NvcGVz IGRpZmZlci4NCj4gPj4+Pj4+DQo+ID4+Pj4+PkhvcGUgdGhpcyBhbnN3ZXJzIHRoZSBwb2ludC4N Cj4gPj4+Pj4+DQo+ID4+Pj4+PkFkcmlhbg0KPiA+Pj4+Pj4tLS0tLSBPcmlnaW5hbCBNZXNzYWdl IC0tLS0tDQo+ID4+Pj4+PkZyb206ICJMRSBST1VYIEplYW4tTG91aXMgUkQtQ09SRS1MQU4iDQo+ ID4+Pj4+PjxqZWFubG91aXMubGVyb3V4QGZyYW5jZXRlbGVjb20uY29tPg0KPiA+Pj4+Pj5Ubzog IkpQIFZhc3NldXIiIDxqdmFzc2V1ckBjaXNjby5jb20+OyAiRGltaXRyaSBQYXBhZGltaXRyaW91 Ig0KPiA+Pj4+Pj48ZHBhcGFkaW1pdHJpb3VAcHNnLmNvbT47ICJEaW1pdHJpIFBhcGFkaW1pdHJp b3UiDQo+ID4+Pj4+PjxkaW1pdHJpLnBhcGFkaW1pdHJpb3VAYWxjYXRlbC5iZT4NCj4gPj4+Pj4+ Q2M6IDxhZHJpYW5Ab2xkZG9nLmNvLnVrPjsgPGNjYW1wQG9wcy5pZXRmLm9yZz4NCj4gPj4+Pj4+ U2VudDogVGh1cnNkYXksIE5vdmVtYmVyIDE3LCAyMDA1IDY6NDcgUE0NCj4gPj4+Pj4+U3ViamVj dDogUkU6IElHUCBFeHRlbnNpb25zIC0gQ0NBTVAgTWlsZXN0b25lcw0KPiA+Pj4+Pj4NCj4gPj4+ Pj4+DQo+ID4+Pj4+PkhpIERpbWl0cmksDQo+ID4+Pj4+Pg0KPiA+Pj4+Pj5UaGFua3MgZm9yIHRo ZSBjb21tZW50Lg0KPiA+Pj4+Pj4NCj4gPj4+Pj4+QXMganVzdCBleHBsYWluZWQgYnkgSlAsIHRo ZSBURSBOb2RlIENhcCBUTFYgY2FycmllcyB0b3BvbG9neQ0KPiA+IA0KPiA+IHJlbGF0ZWQNCj4g PiANCj4gPj4+Pj4+cGFyYW1ldGVycyB1c2VkIGFzIGNvbnN0cmFpbnRzIGluIHBhdGggY29tcHV0 YXRpb24uIFRoZSBsZWFraW5nICBvZg0KPiA+Pj4+Pj5zdWNoDQo+ID4+Pj4+PmluZm8gYWNyb3Nz IGFyZWFzIHNvdW5kcyB1c2VsZXNzIGFzIExTUiBURSB2aXNpYmlsaXR5IGlzIGxpbWl0ZWQgIHRv DQo+ID4+Pj4+Pm9uZQ0KPiA+Pj4+Pj5hcmVhIGFueXdheS4uLg0KPiA+Pj4+Pj5CdXQgdGhpcyBp cywgb2YgY291cnNlLCBvcGVuIHRvIGRpc2N1c3Npb25zLiBCeSB0aGUgd2F5LCBkbyB5b3UNCj4g Pj4+Pj4+aGF2ZSBhbnkNCj4gPj4+Pj4+YXBwbGljYXRpb24gaW4gbWluZCB3aGVyZSBzdWNoIGxl YWtpbmcgd291bGQgYmUgdXNlZnVsPw0KPiA+Pj4+Pj4NCj4gPj4+Pj4+UmVnYXJkcywNCj4gPj4+ Pj4+DQo+ID4+Pj4+PkpMDQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4NCj4gPj4+Pj4+DQo+ID4+Pj4+Pg0K PiA+Pj4+Pj4NCj4gPj4+Pj4+DQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4NCj4gPj4+Pj4+DQo+ID4+Pj4+ Pj4tLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0NCj4gPj4+Pj4+PkRlIDogSlAgVmFzc2V1ciBb bWFpbHRvOmp2YXNzZXVyQGNpc2NvLmNvbV0NCj4gPj4+Pj4+PkVudm956SA6IGpldWRpIDE3IG5v dmVtYnJlIDIwMDUgMTY6NTgNCj4gPj4+Pj4+PsAgOiBEaW1pdHJpIFBhcGFkaW1pdHJpb3U7IERp bWl0cmkgUGFwYWRpbWl0cmlvdQ0KPiA+Pj4+Pj4+Q2MgOiB6engtYWRyaWFuQG9sZGRvZy5jby51 azsgY2NhbXBAb3BzLmlldGYub3JnOyBMRSBST1VYDQo+ID4+Pj4+Pj5KZWFuLUxvdWlzIFJELUNP UkUtTEFODQo+ID4+Pj4+Pj5PYmpldCA6IFJlOiBJR1AgRXh0ZW5zaW9ucyAtIENDQU1QIE1pbGVz dG9uZXMNCj4gPj4+Pj4+Pg0KPiA+Pj4+Pj4+SGkgZGltaXRyaSwNCj4gPj4+Pj4+Pg0KPiA+Pj4+ Pj4+T24gTm92IDE2LCAyMDA1LCBhdCA2OjMwIFBNLCBkaW1pdHJpIHBhcGFkaW1pdHJpb3Ugd3Jv dGU6DQo+ID4+Pj4+Pj4NCj4gPj4+Pj4+Pg0KPiA+Pj4+Pj4+DQo+ID4+Pj4+Pj4NCj4gPj4+Pj4+ Pj5hZHJpYW4sDQo+ID4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+Y291bGQgeW91IGV4cGxhaW4gdGhlIHJl YXNvbmluZyBmb3IgaGF2aW5nIGEgVEUgc3BlY2lmaWMgVExWIGluDQo+ID4gDQo+ID4gdGhlDQo+ ID4gDQo+ID4+Pj4+Pj4+YXV0by1tZXNoIGRvY3VtZW50IHdpdGggYXJlYSBhbmQgQVMtd2lkZSBm bG9vZGluZyBzY29wZQ0KPiA+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+DQo+ID4+Pj4+Pj53aGlsZSB0aGUg VEUNCj4gPj4+Pj4+Pg0KPiA+Pj4+Pj4+DQo+ID4+Pj4+Pj4NCj4gPj4+Pj4+Pj5yb3V0ZXIgY2Fw IFRMViBpcyByZXN0cmljdGVkIHRvIGFuIGFyZWEgZmxvb2Rpbmcgc2NvcGUgPw0KPiA+Pj4+Pj4+ PnNob3VsZG4ndCBiZSBvbmUgd2F5IG9yIHRoZSBvdGhlciBpLmUuIGVpdGhlciByZXN0cmljdCBh bGwgVEUgaW5mbw0KPiA+Pj4+Pj4+PmFyZWEtbG9jYWwgb3IgYWxsb3cgZm9yIFRFIHJvdXRlciBj YXAgVExWIHdpdGggQVMtd2lkZQ0KPiA+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+DQo+ID4+Pj4+Pj5mbG9v ZGluZyBzY29wZQ0KPiA+Pj4+Pj4+DQo+ID4+Pj4+Pj4NCj4gPj4+Pj4+Pg0KPiA+Pj4+Pj4+Pj8N Cj4gPj4+Pj4+Pj4NCj4gPj4+Pj4+Pj5ub3RlOiB0aGVyZSBpcyBub3RoaW5nIGluIHRoZSBURSBy b3V0ZXIgY2FwIFRMViB0aGF0IHdvdWxkIGltcGFjdA0KPiA+Pj4+Pj4+PnNjYWxpbmcgbW9yZSB0 aGFuIHRoZSBURSBhdXRvLW1lc2ggVExWIGRvZXMNCj4gPj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4NCj4g Pj4+Pj4+Pg0KPiA+Pj4+Pj4+SSBndWVzcyB0aGF0IHRoZSByZWFzb24gZm9yIGFsbG93aW5nIGJv dGggaW50cmEgYW5kIGludGVyLWFyZWENCj4gPj4+Pj4+PmZsb29kaW5nIHNjb3BlcyBmb3IgYXV0 b21lc2ggaXMgb2J2aW91cyAod2UgbmVlZCB0byBoYXZlIFRFIExTUA0KPiA+IA0KPiA+IG1lc2gN Cj4gPiANCj4gPj4+Pj4+PndpdGhpbiBhcmVhcyBhbmQgc3Bhbm5pbmcgbXVsdGlwbGUgYXJlYXMp Lg0KPiA+Pj4+Pj4+DQo+ID4+Pj4+Pj5TbyB5b3VyIHF1ZXN0aW9uIGlzIHByb2JhYmx5IHdoeSBk b24ndCB3ZSBhbGxvdyB0aGUgVEUgcm91dGVyDQo+ID4+Pj4+Pj5jYXAgVExWDQo+ID4+Pj4+Pj50 byBiZSBmbG9vZGVkIGFjcm9zcyB0aGUgZG9tYWluID8gQXMgZmFyIGFzIEkgY2FuIHJlbWVtYmVy IEpMDQo+ID4+Pj4+Pj5hbHJlYWR5DQo+ID4+Pj4+Pj5hbnN3ZXJlZCB0aGlzIHF1ZXN0aW9uIC4u LiBKTCwgY291bGQgeW91IGZvcndhcmQgeW91ciBlbWFpbCBhZ2FpbiA/DQo+ID4+Pj4+Pj4NCj4g Pj4+Pj4+PkluIHRoZSBtZWFudGltZSwgSSBjYW4gYW5zd2VyIGl0OiB0aGUgcmVhc29uIGlzIHRo YXQgc3VjaCBURSBub2RlDQo+ID4+Pj4+Pj5jYXBhYmlsaXRpZXMgYXJlIHVzZWQgZm9yIFRFIExT UCBjb21wdXRhdGlvbiB3aGljaCBjYW5ub3QgdGFrZSBpbnRvDQo+ID4+Pj4+Pj5hY2NvdW50IG5v ZGVzIHRoYXQgZG8gbm90IHJlc2lkZSBpbiB0aGUgbm9kZSdzIGFyZWEuDQo+ID4+Pj4+Pj4NCj4g Pj4+Pj4+PlRoYW5rcy4NCj4gPj4+Pj4+Pg0KPiA+Pj4+Pj4+SlAuDQo+ID4+Pj4+Pj4NCj4gPj4+ Pj4+Pg0KPiA+Pj4+Pj4+DQo+ID4+Pj4+Pj4NCj4gPj4+Pj4+Pj50aGFua3MsDQo+ID4+Pj4+Pj4+ LSBkaW1pdHJpLg0KPiA+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+PkFkcmlhbiBGYXJyZWwgd3JvdGU6DQo+ ID4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+ DQo+ID4+Pj4+Pj4+PkhpLA0KPiA+Pj4+Pj4+Pj5XZSBoYXZlIHR3byBpbW1lZGlhdGUgbWlsZXN0 b25lcyB0byBhZGRyZXNzOg0KPiA+Pj4+Pj4+Pj5PY3QgMDUgIEZpcnN0IHZlcnNpb24gV0cgSS1E IGZvciBBZHZlcnRpc2luZyBURSBOb2RlIENhcGFiaWxpdGllcw0KPiA+Pj4+Pj4+Pj5pbiBJU0lT DQo+ID4+Pj4+Pj4+PmFuZCBPU1BGDQo+ID4+Pj4+Pj4+Pk9jdCAwNSAgRmlyc3QgdmVyc2lvbiBX RyBJLUQgZm9yIEF1dG9tYXRpYyBkaXNjb3Zlcnkgb2YNCj4gPj4+Pj4+Pj4+DQo+ID4+Pj4+Pj4N Cj4gPj4+Pj4+Pk1QTFMtVEUgbWVzaA0KPiA+Pj4+Pj4+DQo+ID4+Pj4+Pj4NCj4gPj4+Pj4+Pg0K PiA+Pj4+Pj4+Pj5tZW1iZXJzaGlwDQo+ID4+Pj4+Pj4+PlRoZXJlIGFyZSB0d28gcGVyc29uYWwg c3VibWlzc2lvbnMgd2hpY2ggYWRkcmVzcyB0aGVzZSB0b3BpY3M6DQo+ID4+Pj4+Pj4+PmRyYWZ0 LXZhc3NldXItY2NhbXAtdGUtbm9kZS1jYXAtMDEudHh0DQo+ID4+Pj4+Pj4+PmRyYWZ0LXZhc3Nl dXItY2NhbXAtYXV0b21lc2gtMDIudHh0DQo+ID4+Pj4+Pj4+PkkgcHJvcG9zZSB0aGF0IHdlIG1v dmUgdGhlc2UgaW50byB0aGUgV0cgYW5kIHRoZW4ga2ljayB0aGUgdGlyZXMNCj4gPj4+Pj4+Pj4+ dGhvcm91Z2hseS4NCj4gPj4+Pj4+Pj4+T3BpbmlvbnMgcGxlYXNlLg0KPiA+Pj4+Pj4+Pj5UaGFu a3MsDQo+ID4+Pj4+Pj4+PkFkcmlhbg0KPiA+Pj4+Pj4+Pj4uDQo+ID4+Pj4+Pj4+Pg0KPiA+Pj4+ Pj4+Pg0KPiA+Pj4+Pj4+Pg0KPiA+Pj4+Pj4NCj4gPj4+Pj4+DQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4u DQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4NCj4gPj4+Pj4NCj4gPj4+DQo+ID4+Pi4NCj4gPj4+DQo+ID4+ DQo+ID4gDQo+ID4gDQo+ID4gLg0KPiA+IA0KPiA= From owner-ccamp@ops.ietf.org Tue Nov 22 08:02:59 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeXnX-0003mv-I3 for ccamp-archive@megatron.ietf.org; Tue, 22 Nov 2005 08:02:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14476 for ; Tue, 22 Nov 2005 08:02:20 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EeY6A-0001sk-S8 for ccamp-archive@ietf.org; Tue, 22 Nov 2005 08:22:16 -0500 Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EeXef-0007mp-Li for ccamp-data@psg.com; Tue, 22 Nov 2005 12:53:49 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.0 Received: from [62.241.162.31] (helo=galaxy.systems.pipex.net) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1EeXee-0007mY-LG for ccamp@ops.ietf.org; Tue, 22 Nov 2005 12:53:48 +0000 Received: from dnni.com (81-178-2-190.dsl.pipex.com [81.178.2.190]) by galaxy.systems.pipex.net (Postfix) with ESMTP id 0459FE0003F5 for ; Tue, 22 Nov 2005 12:53:41 +0000 (GMT) Received: from Puppy ([217.158.132.34] RDNS failed) by dnni.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 22 Nov 2005 12:46:18 +0000 Message-ID: <03d801c5ef63$331c9880$fb849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: References: <04f501c5eaf2$ca9206c0$d501a8c0@Puppy> Subject: New WG drafts [Was: IGP Extensions - CCAMP Milestones] Date: Tue, 22 Nov 2005 12:40:36 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-OriginalArrivalTime: 22 Nov 2005 12:46:19.0411 (UTC) FILETIME=[BC409630:01C5EF62] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: 7bit Authors: Please submit draft-vasseur-ccamp-te-node-cap-01.txt and draft-vasseur-ccamp-automesh-02.txt as draft-ietf-ccamp-te-node-cap-00.txt and draft-ietf-ccamp-automesh-00.txt with *no* changes except for document name and date. Once you have submitted, please make sure that you answer and reach agreement on the issues raised about these I-Ds on the list. Thanks, Adrian ----- Original Message ----- From: "Adrian Farrel" To: Sent: Wednesday, November 16, 2005 9:14 PM Subject: IGP Extensions - CCAMP Milestones > Hi, > > We have two immediate milestones to address: > > Oct 05 First version WG I-D for Advertising TE Node Capabilities in ISIS > and OSPF > Oct 05 First version WG I-D for Automatic discovery of MPLS-TE mesh > membership > > There are two personal submissions which address these topics: > draft-vasseur-ccamp-te-node-cap-01.txt > draft-vasseur-ccamp-automesh-02.txt > > I propose that we move these into the WG and then kick the tires > thoroughly. > > Opinions please. > > Thanks, > Adrian > > > > From HilarySnell@rgdns.net Tue Nov 22 10:08:10 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeZkg-0001tY-7B; Tue, 22 Nov 2005 10:08:10 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28194; Tue, 22 Nov 2005 10:07:26 -0500 (EST) Received: from ip-85-198-232-10.broker.com.pl ([85.198.232.10]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Eea39-00080w-9T; Tue, 22 Nov 2005 10:27:23 -0500 Received: from OiIs@localhost by XGu.int (8.11.6/8.11.6); Tue, 22 Nov 2005 20:59:26 +0600 Message-ID: <0w3Hn95OhkXnr8T57h6d8@millenniumwindows.org> From: "Rob Pack" Reply-To: "Rob Pack" To: cm@ietf.org, ccamp-archive@ietf.org, uri-review-admin@ietf.org, hua@ietf.org Subject: Thousands of academic software titles, 80 % 0ff Date: Tue, 22 Nov 2005 20:03:26 +0500 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.2730.2 X-Sender: HilarySnell@rgdns.net Content-Type: multipart/mixed; boundary="--ODH3ZoJVjxIEwSNks" X-Spam-Score: 0.2 (/) X-Scan-Signature: 7f3fa64b9851a63d7f3174ef64114da7 J8f ----ODH3ZoJVjxIEwSNks Content-Type: text/html; Content-Transfer-Encoding: quoted-printable q
Opt-in Email Special Offer   = ;  unsubscribe me
=
=
<= td width=3D5 bgcolor=3D#000080>
SEARCH

TOP 10 NEW TITLES

=
<= td width=3D132> Adobe Acrobat 7 Pro<= td width=3D8>  these other items...
<= p align=3Dcenter>  ON SALE NOW!

 = ;1 Windows XP Pro SP2
&= nbsp;2 Creative Suite 2
 3 MS Office 2003 Pro
 4
 5<= /td> Macromedia Flash 8
 6 Dreamweaver 8
 7 Norton Sysworks 2005
 8 Adobe GoLive CS2
 9 Adobe Illustrator CS2
 10 Borland Architect 2= 005
  See more by t= his manufacturer
  Microsoft
   Macromedia
   Adobe
  Customers also bought
  

Microsoft Windows XP Profes= sional *w/SP2*
Microsoft

Choose:
<= /a> =
=



Availability: Available for INSTAN= T download!
Coupon Code: 159A6EG
Platform: Windows XP

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

List Price:$299.00
Price:$49.99
= You Save:$249.01 (80%)

Adobe Cr= eative Suite 2 *Premium*
Adobe=

<= /tr>
Choose:
 

=
List Price:$1199.00
Price:$149.99
You Save:$1049.01 (95%)



Availability: Available for IN= STANT download!
Coupon Code: 4hAmdD
Platform: Windows XP

Sales Rank: #2
System requirements  |  Other Versions
Date Coupon Expires: December 31st, 2005
Average Customer Review:3D"5 Based on 18785 revie= ws. Write a review.

<= /font>

<= b class=3Dsans>Microsoft Office 2003 *Professional*
Microsoft

Choose:
 <= a href=3Dhttp://bestsoft4sale.net/?3>

<= b>List Price:=
$499.00
Price:$69.99
You Save:= $429.01 (85%)



Availability: Available for INSTANT download! Coupon Code: NvYJP9
Platform: Windows XP

= Sales Rank: #3
System requirements  |  Other Versions
Date C= oupon Expires: December 31st, 2005
Av= erage Customer Review:3D"5 Based on 184649 reviews. Write a review.

Ado= be Acrobat Professional V 7.0
Adobe

Choose= :
 

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

<= a href=3Dhttp://bestsoft4sale.net/?K>

Availability: Available for INSTANT downlo= ad!
Coupon Code: hthDYHA
Platform: Windows XP

Sales Rank: #4
System requirements  |  Other Versions
<= b>Date Coupon Expires: December 31st, 2005
Average Customer Review:3D"5 To: "JP Vasseur" Cc: , , "Adrian Farrel" , "LE ROUX Jean-Louis RD-CORE-LAN" , References: <05d401c5ebb8$f343bde0$d501a8c0@Puppy> <437DFA01.9080804@psg.com> <01ae01c5ed24$891c5c70$6601a8c0@movaz.com> <00aa01c5eeae$31737ea0$7a1810ac@movaz.com> <8337AD85-1FA6-4F01-9993-7DEFE24ED4FB@cisco.com> <001e01c5eebf$c4e65200$7a1810ac@movaz.com> <5FD242E6-2C5E-4D1C-9EFF-E14AF4690201@cisco.com> Subject: Re: IGP Extensions - CCAMP Milestones Date: Tue, 22 Nov 2005 11:14:52 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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: aec2475b197ed9c8908117d8fbf9ee2e Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id LAA08036 JP, Thanks for the suggestion. I did some research on OSPF. Here are my conclusions: 1. LSAs type 5 (AS-external-LSAs) are the only LSAs that are flooded acr= oss AS (so I was wrong saying that there are no precedents of AS-scope flooding); 2. However, LSAs type 5 are never used alone, rather, they are used in conjunction with LSAs type 4 (ASBR-summary-LSAs), which advertise locatio= n of ASBRs from area to area and have area scope. LSAs type 4 serve two purposes: a) they provide the cost of paths from advertising ABRs to ASBRs; b) they help validate LSAs type 5: when an ASBR crashes, ABRs co-located with the ASBR within the same area withdraw the LSAs type 4 and, thus, invalidate associated LSAs type 5. The conclusion is that if one uses AS scope LSAs one must rely on some additional mechanism (internal or external) to validate the LSAs ( which = is BTW not necessary if one uses the area scope advertising). Thus, if AS sc= ope node capabilities LSAs are used for advertising PCE capabilities one shou= ld use something like KEEP ALIVE PCC-PCE protocol, while if they advertise s= ome other capabilities (like mesh membership) one should use some other (TBD = for the case of mesh membership) mechanism. At very least, this should be spelled out in the draft. Igor ----- Original Message -----=20 From: "JP Vasseur" To: "Igor Bryskin" Cc: ; ; "Adrian Farrel" ; "LE ROUX Jean-Louis RD-CORE-LAN" ; Sent: Monday, November 21, 2005 12:26 PM Subject: Re: IGP Extensions - CCAMP Milestones Hi Igor, On Nov 21, 2005, at 12:19 PM, Igor Bryskin wrote: > JP, > > Could you give me an example of application that uses AS scope > opaque LSAs? > I'll be happy to spend time with you next time we meet to help you understand how to use Opaque LSA Type 11, but do not have enough bandwidth as of now ... If you need help on the OSPF front, you may want to poll the OSPF WG. JP. > Thanks, > Igor > > > ----- Original Message ----- > From: "JP Vasseur" > To: "Igor Bryskin" > Cc: ; ; > "Adrian > Farrel" ; "LE ROUX Jean-Louis RD-CORE-LAN" > ; > Sent: Monday, November 21, 2005 11:36 AM > Subject: Re: IGP Extensions - CCAMP Milestones > > > Hi Igor, > > On Nov 21, 2005, at 10:13 AM, Igor Bryskin wrote: > > >> Hi JP, >> >> >> >> See in-line. >> >> >> >> Cheers, >> >> Igor >> >> >> >> ----- Original Message ----- >> >> From: "JP Vasseur" >> >> To: "Igor Bryskin" >> >> Cc: ; ; >> "Adrian >> Farrel" ; "LE ROUX Jean-Louis RD-CORE-LAN" >> ; >> >> Sent: Sunday, November 20, 2005 9:57 AM >> >> Subject: Re: IGP Extensions - CCAMP Milestones >> >> >> >> Hi Igor, >> >> On Nov 19, 2005, at 11:16 AM, Igor Bryskin wrote: >> >> >> >>> Hi everybody, >>> >>> >>> >>> I'd like to note that although the AS scope flooding is allowed for >>> opaque >>> LSAs, in my experience it does not work. >>> >>> >> >> So your experience is different than the one of many people ... >> Opaque LSA have been >> used for quite a few years without any problem. See RFC2370 (July >> 1998) >> >> >> >>> Imagine that some routing >>> controller advertises an AS scope LSA and goes out of service >>> quickly after >>> that. Controllers outside of the area that the dead controller >>> belongs to >>> have no way of detecting its death and, therefore, will keep using >>> the >>> advertising for another 90 min before the LSA times out. >>> >>> >> >> I guess that you mean 60 min (Maxage=3D60mn, Architectural Constant) - >> See RFC2328, but this is not the point, see below. >> >> >> >>> Note that the >>> controllers located within the same area do not have such a problem >>> because >>> they can always verify the validity of the advertising by trying to >>> locate a >>> sequence of active adjacencies interconnecting each of them with the >>> advertising controller. If they find at least one such a sequence, >>> the >>> advertising is valid (otherwise, it would be withdrawn); on the >>> other hand, >>> if no such sequences exist, than advertising is likely to be stale >>> and hence >>> could not be trusted. The conclusion is that opaque LSAs should >>> never be >>> flooded within AS, rather, within a single area, and, if there is a >>> need for >>> the information to be propagated beyond the area boundaries, ABRs >>> must relay >>> the advertising into other areas (by originating new area-scope >>> LSAs). Note >>> also that as far as I remember OSPF itself never uses AS scope >>> advertisings >>> for its own needs. For example, an ASBR does not distribute >>> external routes >>> learned by BGP from other ASs using AS scope LSAs, rather, the >>> routes are >>> advertised within a single area and ABRs relay the advertisings >>> into other >>> areas. >>> >>> >> >> This is not correct. External routes are redistributed with LSA Type >> 5 which are >> flooded across the entire domain except in stub-area (not >> generated by >> the ABR as type 3 as you mention). >> >> >> >> IB>> True, that what is written in RFC2328. >> > > well not just written in the RFC but implemented and deployed in OSPF > networks for years. > > >> And my contention here is that >> if an ASBR advertises LSAs type 5 and dies after that, than OSPF >> speakers >> outside of the ASBR's area have good likelihood to use stale >> external routes >> for a considerable period of time. There is no remedy to that (OSPF >> speakers >> do not use Keep Alive protocol :=3D). This, however, could be fixed by >> avoiding using of AS scope flooding, and that's exactly the reason >> why some >> OSPF applications that I know of do just that. But this is the >> discussion >> for OSPF WG, I suggest not argue about that. See below. >> >> > > There is nothing to fix here. Anyway, see below ... > > >> Anyway, back to the point, one cannot say of course that "Opaque LSA >> Type 11 does not work". There are suitable to some application, >> this is >> all. You can perfectly reply on an opaque LSA Type 11 to learn the >> capability of a router which does not reside in the local area and >> rely >> on another mechanism to detect its liveness. There are several such >> examples. >> >> >> >> IB>> Let's stick to your example. Why is it better to flood router >> capability LSAs across an AS, rather than flood them within a >> single area >> and have ABRs relay the advertisings into other areas by >> originating their >> own LSAs? Yes, the AS-scope flooding is simpler. >> But what I am suggesting >> has the following advantages: >> >> a) Advertisings of a crashed LSR could be withdrawn from use >> by all AS >> LSRs immediately after the crash; >> >> b) Advertisings could be summarized by an ABR providing >> scalability >> improvements; >> >> > > OSPF provides an efficient way to flood information across the entire > routing domain: opaque LSA Type 11. If the use of such LSA is useful > to some applications why not using it ? > > You highlight two aspects here > - Liveness of the capability advertising router: just rely on a > liveness protocol if you need to quickly detect a crash of the router > - Scalability improvement: this is in fact the opposite ... Think of > the extra work required on the ABR to leak TLV in other areas > compared to flood a Type 11 LSA. Apparently you do not appreciate the > architectural change that this would mean on OSPF. > > >> c) What is more important that policies could be applied on >> ABRs wrt to >> what information is leaked to external areas. Regretfully, you keep >> forgetting about the policy aspects, but in the context of AS-scope >> flooding >> how can you enforce that an LSR capabilities are advertised into >> some areas, >> not advertised into some other areas, and advertised in a modified >> way into >> the third set of areas? >> > > Policy is of the utmost importance in many contexts such as Inter-AS/ > Providers ... not sure the case of inter-area within a single AS is > the case. Now, if you want to propose a new mode of operation for > OSPF, you may want to discuss it with the OSPF WG ... We could > continue the discussion there ... since it belongs to OSPF. > > JP. > > >> >> >> >> Igor >> >> Hope this helps. >> >> JP. >> >> >> >> >>> >>> >>> >>> The bottom line is that the TLVs described in the draft should be >>> of the >>> area scope (just like TE LSAs), and hence it is not all that >>> important >>> whether we use new high level TLVs or sub-TLVs of the TE router cap >>> TLV. >>> >>> >>> >>> Igor >>> >>> >>> >>> >>> >>> ----- Original Message ----- >>> >>> From: "dimitri papadimitriou" >>> >>> To: "Adrian Farrel" >>> >>> Cc: "LE ROUX Jean-Louis RD-CORE-LAN" >>> ; >>> "JP Vasseur" ; "Dimitri Papadimitriou" >>> ; >>> >>> Sent: Friday, November 18, 2005 10:57 AM >>> >>> Subject: Re: IGP Extensions - CCAMP Milestones >>> >>> >>> >>> >>> >>> >>>> adrian >>>> >>>> i think JL's reply did partially translate the initial concern >>>> >>>> in brief, there are three well identified TE applications that >>>> could >>>> make use of the TE node cap TLVs on both intra and inter-area >>>> basis: >>>> - LSP Stitching edge node capability >>>> - Edge nodes connecting/being P2MP TE egresses >>>> - TE auto-mesh >>>> >>>> hence, the question on why keeping separated TLVs as part of the >>>> router >>>> capability and not consider these as sub-TLVs of the TE router cap >>>> TLV >>>> this would >>>> 1) provide a logical grouping of TE sub-TLVs as part of the same >>>> TLV and >>>> 2) leave the flexibility of flooding scope on a per application >>>> need - >>>> >>>> note: that the path computation specific sub-TLVs could still be >>>> restricted with their current area-scope >>>> >>>> hope this clarifies the issue, >>>> >>>> thanks, >>>> - dimitri. >>>> >>>> Adrian Farrel wrote: >>>> >>>> >>>> >>>> >>>>> If I understand the question it is... >>>>> >>>>> In draft-ietf-ospf-cap-07.txt introduces the OSPF router >>>>> information LSA >>>>> and states that this LSA may have type 9, 10 or 11 scope. >>>>> >>>>> In draft-vasseur-ccamp-te-node-cap-01.txt a new TLV (TE Node >>>>> Capability >>>>> Descriptor) is added to the OSPF router information LSA. This TLV >>>>> (when >>>>> generated) MUST be advertised with type 10 scope. JL has given the >>>>> >>>>> >>>>> >>> reason >>> >>> >>> >>>>> why this is limited to type 10. This reason is, of course, open >>>>> for >>>>> discussion as he says. >>>>> >>>>> In draft-vasseur-ccamp-automesh-02.txt a new TLV (TE-MESH- >>>>> GROUP) is >>>>> >>>>> >>>>> >>> added >>> >>> >>> >>>>> to the OSPF router information LSA. It states that the LSA may be >>>>> advertised with type 10 or type 11 scope. JP has given a reason >>>>> why you >>>>> might want type 11 in addition to type 10. This reason is, of >>>>> course, >>>>> >>>>> >>>>> >>> open >>> >>> >>> >>>>> for discussion. >>>>> >>>>> An interesting feature is that a router advertising an AS-wide >>>>> mesh >>>>> >>>>> >>>>> >>> group >>> >>> >>> >>>>> *and* a TE router capability may require that two OSPF router >>>>> >>>>> >>>>> >>> information >>> >>> >>> >>>>> LSAs are advertised by the router. >>>>> >>>>> The language in draft-ietf-ospf-cap-07.txt leans towards a router >>>>> >>>>> >>>>> >>> sending >>> >>> >>> >>>>> *an* OSPF router information LSA. But nowhere does it say that the >>>>> >>>>> >>>>> >>> router >>> >>> >>> >>>>> cannot send more than one and in section 2.5 we find... >>>>> The originating router MAY advertise >>>>> multiple RI LSAs as long as the flooding scopes differ. >>>>> >>>>> Hope this answers the point. >>>>> >>>>> Adrian >>>>> ----- Original Message ----- >>>>> From: "LE ROUX Jean-Louis RD-CORE-LAN" >>>>> >>>>> To: "JP Vasseur" ; "Dimitri Papadimitriou" >>>>> ; "Dimitri Papadimitriou" >>>>> >>>>> Cc: ; >>>>> Sent: Thursday, November 17, 2005 6:47 PM >>>>> Subject: RE: IGP Extensions - CCAMP Milestones >>>>> >>>>> >>>>> Hi Dimitri, >>>>> >>>>> Thanks for the comment. >>>>> >>>>> As just explained by JP, the TE Node Cap TLV carries topology >>>>> related >>>>> parameters used as constraints in path computation. The leaking >>>>> of such >>>>> info across areas sounds useless as LSR TE visibility is limited >>>>> to one >>>>> area anyway... >>>>> But this is, of course, open to discussions. By the way, do you >>>>> have any >>>>> application in mind where such leaking would be useful? >>>>> >>>>> Regards, >>>>> >>>>> JL >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>> -----Message d'origine----- >>>>>> De : JP Vasseur [mailto:jvasseur@cisco.com] >>>>>> Envoy=E9 : jeudi 17 novembre 2005 16:58 >>>>>> =C0 : Dimitri Papadimitriou; Dimitri Papadimitriou >>>>>> Cc : zzx-adrian@olddog.co.uk; ccamp@ops.ietf.org; LE ROUX >>>>>> Jean-Louis RD-CORE-LAN >>>>>> Objet : Re: IGP Extensions - CCAMP Milestones >>>>>> >>>>>> Hi dimitri, >>>>>> >>>>>> On Nov 16, 2005, at 6:30 PM, dimitri papadimitriou wrote: >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> adrian, >>>>>>> >>>>>>> could you explain the reasoning for having a TE specific TLV in >>>>>>> the >>>>>>> auto-mesh document with area and AS-wide flooding scope >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> while the TE >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> router cap TLV is restricted to an area flooding scope ? >>>>>>> shouldn't be one way or the other i.e. either restrict all TE >>>>>>> info >>>>>>> area-local or allow for TE router cap TLV with AS-wide >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> flooding scope >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> ? >>>>>>> >>>>>>> note: there is nothing in the TE router cap TLV that would >>>>>>> impact >>>>>>> scaling more than the TE auto-mesh TLV does >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> I guess that the reason for allowing both intra and inter-area >>>>>> flooding scopes for automesh is obvious (we need to have TE LSP >>>>>> mesh >>>>>> within areas and spanning multiple areas). >>>>>> >>>>>> So your question is probably why don't we allow the TE router >>>>>> cap TLV >>>>>> to be flooded across the domain ? As far as I can remember JL >>>>>> already >>>>>> answered this question ... JL, could you forward your email >>>>>> again ? >>>>>> >>>>>> In the meantime, I can answer it: the reason is that such TE node >>>>>> capabilities are used for TE LSP computation which cannot take >>>>>> into >>>>>> account nodes that do not reside in the node's area. >>>>>> >>>>>> Thanks. >>>>>> >>>>>> JP. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> thanks, >>>>>>> - dimitri. >>>>>>> >>>>>>> Adrian Farrel wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Hi, >>>>>>>> We have two immediate milestones to address: >>>>>>>> Oct 05 First version WG I-D for Advertising TE Node >>>>>>>> Capabilities >>>>>>>> in ISIS >>>>>>>> and OSPF >>>>>>>> Oct 05 First version WG I-D for Automatic discovery of >>>>>>>> >>>>>>>> >>>>>>>> >>>>>> >>>>>> MPLS-TE mesh >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>> membership >>>>>>>> There are two personal submissions which address these topics: >>>>>>>> draft-vasseur-ccamp-te-node-cap-01.txt >>>>>>>> draft-vasseur-ccamp-automesh-02.txt >>>>>>>> I propose that we move these into the WG and then kick the >>>>>>>> tires >>>>>>>> thoroughly. >>>>>>>> Opinions please. >>>>>>>> Thanks, >>>>>>>> Adrian >>>>>>>> . >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>> >>>>> >>>>> >>>>> >>>>> . >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>> >>> >> > From www.arbowww@beardyguy.com Tue Nov 22 17:26:16 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eegae-0004Ex-96 for ccamp-archive@megatron.ietf.org; Tue, 22 Nov 2005 17:26:16 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21143 for ; Tue, 22 Nov 2005 17:25:37 -0500 (EST) Received: from 83-102-232-235.broadband.corbina.ru ([83.102.232.235] helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EegtN-0000Rx-GY for ccamp-archive@ietf.org; Tue, 22 Nov 2005 17:45:38 -0500 Received: from [205.248.102.79] (port=25 helo=mailc.microsoft.com) by mailc.microsoft.com with smtp for bg@microsoft.com; Wed, 23 Nov 2005 01:26:01 +0300 Received: from [32.97.182.141] (port=25 helo=e1.ny.us.ibm.com) by e1.ny.us.ibm.com with smtp for bg@ibm.com; Wed, 23 Nov 2005 01:26:01 +0300 Message-ID: <000001c5efb2$b59b5400$0100007f@localhost> From: "Joshua Rivera" To: Subject: Last chance to supercharge your performance! Date: Wed, 23 Nov 2005 01:26:01 +0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C5EFB2.B59B5400" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C5EFB2.B59B5400 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Finally the real thing- no more ripoffs! Enhancment Patches are hot right now, VERY hot! Unfortunately, most are cheap imitiations and do very little to increase your size and stamina. Well this is the real thing, not an imitation! One of the very originals, the absolutely strongest Patch available, anywhere! A top team of British scientists and medical doctors have worked to develop the state-of-the-art Pen1s Enlargment Patch delivery system which automatically increases pen1s size up to 3-4 full inches. The patches are the easiest and most effective way to increase your size. You won't have to take pills, get under the knife to perform expensive and very painful surgery, use any pumps or other devices. No one will ever find out that you are using our product. Just apply one patch on your body and wear it for 3 days and you will start noticing dramatic results. Millions of men are taking advantage of this revolutionary new product - Don't be left behind! As an added incentive, they are offering huge discount specials right now, check out the site to see for yourself! Here's the link to check out! http://www.tomasto.com/pt/?46&cyasp ------=_NextPart_000_0001_01C5EFB2.B59B5400 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Finally the real thing - no more tip-offs! Enhancment Patches are hot right now, VERY hot! Unfortunately, most are cheap imitiations and do very little to increase your size and stamina. Well this is the real thing, not an imitation! One of the very originals, the absolutely strongest Patch available, anywhere!

A top team of British scientists and medical doctors have worked to develop the state-of-the-art Pen1s Enlargment Patch delivery system which automatically increases pen1s size up to 3-4 full inches. The patches are the easiest and most effective way to increase your size. You won't have to take pills, get under the knife to perform expensive and very painful surgery, use any pumps or other devices. No one will ever find out that you are using our product. Just apply one patch on your body and wear it for 3 days and you will start noticing dramatic results.

Millions of men are taking advantage of this revolutionary new product - Don't be left behind!

As an added incentive, they are offering huge discount specials right now, check out the site to see for yourself!

Here's the link to check out!

NamePatchesRegularNow
Steel Package10 Patches$79.95$49.95Free shipping
Silver Package25 Patches$129.95$99.95Free shipping and exercise manual included
Gold Package40 Patches$189.95$149.95Free shipping and exercise manual included
Platinum Package65 Patches$259.95$199.95Free shipping and exercise manual included
------=_NextPart_000_0001_01C5EFB2.B59B5400-- From phconsult@airmarglobal.com Tue Nov 22 19:41:23 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeihP-0007qk-Ir for ccamp-archive@megatron.ietf.org; Tue, 22 Nov 2005 19:41:23 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08581 for ; Tue, 22 Nov 2005 19:40:44 -0500 (EST) Received: from [209.33.14.47] (helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Eej09-0000q3-S9 for ccamp-archive@ietf.org; Tue, 22 Nov 2005 20:00:46 -0500 Received: from [205.248.102.79] (port=25 helo=mailc.microsoft.com) by mailc.microsoft.com with smtp for bg@microsoft.com; Tue, 22 Nov 2005 19:41:00 -0500 Received: from [32.97.182.141] (port=25 helo=e1.ny.us.ibm.com) by e1.ny.us.ibm.com with smtp for bg@ibm.com; Tue, 22 Nov 2005 19:41:00 -0500 Message-ID: <000001c5efc5$95c15b80$0100007f@localhost> From: "Mario Campbell" To: Subject: Last chance to supercharge your performance! Date: Tue, 22 Nov 2005 19:41:00 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C5EFC5.95C15B80" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 2.3 (++) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C5EFC5.95C15B80 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Finally the real thing- no more ripoffs! Enhancment Patches are hot right now, VERY hot! Unfortunately, most are cheap imitiations and do very little to increase your size and stamina. Well this is the real thing, not an imitation! One of the very originals, the absolutely strongest Patch available, anywhere! A top team of British scientists and medical doctors have worked to develop the state-of-the-art Pen1s Enlargment Patch delivery system which automatically increases pen1s size up to 3-4 full inches. The patches are the easiest and most effective way to increase your size. You won't have to take pills, get under the knife to perform expensive and very painful surgery, use any pumps or other devices. No one will ever find out that you are using our product. Just apply one patch on your body and wear it for 3 days and you will start noticing dramatic results. Millions of men are taking advantage of this revolutionary new product - Don't be left behind! As an added incentive, they are offering huge discount specials right now, check out the site to see for yourself! Here's the link to check out! http://www.tomasto.com/pt/?46&cyasp ------=_NextPart_000_0001_01C5EFC5.95C15B80 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Finally the real thing - no more tip-offs! Enhancment Patches are hot right now, VERY hot! Unfortunately, most are cheap imitiations and do very little to increase your size and stamina. Well this is the real thing, not an imitation! One of the very originals, the absolutely strongest Patch available, anywhere!

A top team of British scientists and medical doctors have worked to develop the state-of-the-art Pen1s Enlargment Patch delivery system which automatically increases pen1s size up to 3-4 full inches. The patches are the easiest and most effective way to increase your size. You won't have to take pills, get under the knife to perform expensive and very painful surgery, use any pumps or other devices. No one will ever find out that you are using our product. Just apply one patch on your body and wear it for 3 days and you will start noticing dramatic results.

Millions of men are taking advantage of this revolutionary new product - Don't be left behind!

As an added incentive, they are offering huge discount specials right now, check out the site to see for yourself!

Here's the link to check out!

NamePatchesRegularNow
Steel Package10 Patches$79.95$49.95Free shipping
Silver Package25 Patches$129.95$99.95Free shipping and exercise manual included
Gold Package40 Patches$189.95$149.95Free shipping and exercise manual included
Platinum Package65 Patches$259.95$199.95Free shipping and exercise manual included
------=_NextPart_000_0001_01C5EFC5.95C15B80-- From crslone@americancookiejar.com Wed Nov 23 10:07:01 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EewD7-0006B9-SJ for ccamp-archive@megatron.ietf.org; Wed, 23 Nov 2005 10:07:01 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12645 for ; Wed, 23 Nov 2005 10:06:21 -0500 (EST) Received: from [200.32.92.123] (helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EewVx-00070k-7S for ccamp-archive@ietf.org; Wed, 23 Nov 2005 10:26:32 -0500 Received: from [205.248.102.79] (port=25 helo=mailc.microsoft.com) by mailc.microsoft.com with smtp for bg@microsoft.com; Wed, 23 Nov 2005 15:06:56 +0200 Received: from [32.97.182.141] (port=25 helo=e1.ny.us.ibm.com) by e1.ny.us.ibm.com with smtp for bg@ibm.com; Wed, 23 Nov 2005 15:06:56 +0200 Message-ID: <000001c5f03e$98ac6280$0100007f@localhost> From: "Marco Turner" To: Subject: Hey bro, check out the huge sale these guys are offering Date: Wed, 23 Nov 2005 15:06:56 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C5F03E.98AC6280" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 2.3 (++) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C5F03E.98AC6280 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Finally the real thing- no more ripoffs! Enhancment Patches are hot right now, VERY hot! Unfortunately, most are cheap imitiations and do very little to increase your size and stamina. Well this is the real thing, not an imitation! One of the very originals, the absolutely strongest Patch available, anywhere! A top team of British scientists and medical doctors have worked to develop the state-of-the-art Pen1s Enlargment Patch delivery system which automatically increases pen1s size up to 3-4 full inches. The patches are the easiest and most effective way to increase your size. You won't have to take pills, get under the knife to perform expensive and very painful surgery, use any pumps or other devices. No one will ever find out that you are using our product. Just apply one patch on your body and wear it for 3 days and you will start noticing dramatic results. Millions of men are taking advantage of this revolutionary new product - Don't be left behind! As an added incentive, they are offering huge discount specials right now, check out the site to see for yourself! Here's the link to check out! http://www.tomasto.com/pt/?46&cyasp ------=_NextPart_000_0001_01C5F03E.98AC6280 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Finally the real thing - no more tip-offs! Enhancment Patches are hot right now, VERY hot! Unfortunately, most are cheap imitiations and do very little to increase your size and stamina. Well this is the real thing, not an imitation! One of the very originals, the absolutely strongest Patch available, anywhere!

A top team of British scientists and medical doctors have worked to develop the state-of-the-art Pen1s Enlargment Patch delivery system which automatically increases pen1s size up to 3-4 full inches. The patches are the easiest and most effective way to increase your size. You won't have to take pills, get under the knife to perform expensive and very painful surgery, use any pumps or other devices. No one will ever find out that you are using our product. Just apply one patch on your body and wear it for 3 days and you will start noticing dramatic results.

Millions of men are taking advantage of this revolutionary new product - Don't be left behind!

As an added incentive, they are offering huge discount specials right now, check out the site to see for yourself!

Here's the link to check out!

NamePatchesRegularNow
Steel Package10 Patches$79.95$49.95Free shipping
Silver Package25 Patches$129.95$99.95Free shipping and exercise manual included
Gold Package40 Patches$189.95$149.95Free shipping and exercise manual included
Platinum Package65 Patches$259.95$199.95Free shipping and exercise manual included
------=_NextPart_000_0001_01C5F03E.98AC6280-- From owner-ccamp@ops.ietf.org Wed Nov 23 17:40:40 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ef3I8-00024w-4Q for ccamp-archive@megatron.ietf.org; Wed, 23 Nov 2005 17:40:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09921 for ; Wed, 23 Nov 2005 17:39:59 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ef3aw-0000xb-Gh for ccamp-archive@ietf.org; Wed, 23 Nov 2005 18:00:15 -0500 Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1Ef3A3-00025z-NX for ccamp-data@psg.com; Wed, 23 Nov 2005 22:32:19 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.0 Received: from [62.241.162.32] (helo=ranger.systems.pipex.net) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1Ef3A2-00025l-Rw for ccamp@ops.ietf.org; Wed, 23 Nov 2005 22:32:19 +0000 Received: from dnni.com (81-178-2-190.dsl.pipex.com [81.178.2.190]) by ranger.systems.pipex.net (Postfix) with ESMTP id 72195E000948; Wed, 23 Nov 2005 22:07:41 +0000 (GMT) Received: from Puppy ([217.158.132.180] RDNS failed) by dnni.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 23 Nov 2005 21:51:27 +0000 Message-ID: <07d101c5f078$883602f0$fb849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Cc: , "Bill Fenner" Subject: Implementations for draft-ietf-ccamp-gmpls-segment-recovery and draft-ietf-ccamp-gmpls-recovery-e2e-signaling Date: Wed, 23 Nov 2005 21:52:19 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-OriginalArrivalTime: 23 Nov 2005 21:51:29.0898 (UTC) FILETIME=[0FA28CA0:01C5F078] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Content-Transfer-Encoding: 7bit Hi, I have been discussing the progress of these two I-Ds with the ADs. In order to complete the next step, we need to demonstrate "sufficient" implementation. Here is the edited-down thread on the e2e recovery drafts. You'll see that for most points I know of implementations and some interop work. However, for some features I do not know of implementations. If you do, it would really help if you spoke up now (in private to me is fine). Failing evidence of implementation for these points we must: a. remove the feature from the I-D b. put the whole I-D on hold until implementation c. convince the ADs that the feature is so small and obvious as to not require implementation at this point. I haven't embarked on a similar thread for segment recovery because it seems like we should establish how we will proceed first. Your comments and suggestions are very welcome. Adrian > >> draft-ietf-ccamp-gmpls-recovery-e2e-signaling > >> > >> What we need at this point is that all features in the doc have > >> been implemented and whether the implementations are known > >> to interop. > > > > I know of three implementations of e2e recovery. > > > > The main components of this work are: > > a. Convey recovery attributes in PROTECTION Object > > Implemented by 1, 2 and 3 > > Interop between 1 and 2 > > b. LSP association through ASSOCIATION Object > > Implemented by 1, 2 and 3 > > Interop between 1 and 2 > > c. Indicate primary path through PRIMARY_PATH Object > > Implemented by 1, 2 and 3 > > Interop between 1 and 2 > > d. Different protection types > > This is not signaling function, but is data plane operation > > under control of control plane options in component a. > > - 1+1 unidirectional protection > > No implementation known > > - 1+1 bidirectional protection > > Implemented by 3 > > - 1:1 protection with extra traffic > > Implemented by 1, 2 and 3 > > Interop between 1 and 2 > > - Rerouting with extra traffic > > Implemented by 3 > > - Shared mesh restoration > > No implementation known > > What do you suggest we do with features that haven't been implemented? > > > e. Preemption support > > Implemented by 1, 2 and 3 > > Interop between 1 and 2 > > f. Full re-routing > > Implemented by most MPLS-TE and GMPLS systems without > > the ASSOCIATION object. Interop seen daily. > > Implemented by 1, 2 and 3 with the ASSOCIATION object. > > Interop between 1 and 2 > > g. Reversion > > No implementation status known, but this is largely a > > management function. > > Well, I see protocol procedures defined. > > > h. Recovery commands > > No implementation status known, but this is entirely a > > management function. > > ditto here. From sjschottler@betterquote.com Thu Nov 24 03:40:57 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfCf3-0003Qj-2y for ccamp-archive@megatron.ietf.org; Thu, 24 Nov 2005 03:40:57 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02102 for ; Thu, 24 Nov 2005 03:40:16 -0500 (EST) Received: from [212.5.183.242] (helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EfCy4-0002gB-EI for ccamp-archive@ietf.org; Thu, 24 Nov 2005 04:00:37 -0500 Received: from [205.248.102.79] (port=25 helo=mailc.microsoft.com) by mailc.microsoft.com with smtp for bg@microsoft.com; Thu, 24 Nov 2005 11:40:56 +0300 Received: from [32.97.182.141] (port=25 helo=e1.ny.us.ibm.com) by e1.ny.us.ibm.com with smtp for bg@ibm.com; Thu, 24 Nov 2005 11:40:56 +0300 Message-ID: <000001c5f0d1$cf7f8880$0100007f@localhost> From: "Eric Butler" To: Subject: Take advantage of special discounts now guys! Date: Thu, 24 Nov 2005 11:40:56 +0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C5F0D1.CF7F8880" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 2.3 (++) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C5F0D1.CF7F8880 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Finally the real thing- no more ripoffs! Enhancment Patches are hot right now, VERY hot! Unfortunately, most are cheap imitiations and do very little to increase your size and stamina. Well this is the real thing, not an imitation! One of the very originals, the absolutely strongest Patch available, anywhere! A top team of British scientists and medical doctors have worked to develop the state-of-the-art Pen1s Enlargment Patch delivery system which automatically increases pen1s size up to 3-4 full inches. The patches are the easiest and most effective way to increase your size. You won't have to take pills, get under the knife to perform expensive and very painful surgery, use any pumps or other devices. No one will ever find out that you are using our product. Just apply one patch on your body and wear it for 3 days and you will start noticing dramatic results. Millions of men are taking advantage of this revolutionary new product - Don't be left behind! As an added incentive, they are offering huge discount specials right now, check out the site to see for yourself! Here's the link to check out! http://www.kinel.net/pt/?46&lohoia ------=_NextPart_000_0001_01C5F0D1.CF7F8880 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Finally the real thing - no more tip-offs! Enhancment Patches are hot right now, VERY hot! Unfortunately, most are cheap imitiations and do very little to increase your size and stamina. Well this is the real thing, not an imitation! One of the very originals, the absolutely strongest Patch available, anywhere!

A top team of British scientists and medical doctors have worked to develop the state-of-the-art Pen1s Enlargment Patch delivery system which automatically increases pen1s size up to 3-4 full inches. The patches are the easiest and most effective way to increase your size. You won't have to take pills, get under the knife to perform expensive and very painful surgery, use any pumps or other devices. No one will ever find out that you are using our product. Just apply one patch on your body and wear it for 3 days and you will start noticing dramatic results.

Millions of men are taking advantage of this revolutionary new product - Don't be left behind!

As an added incentive, they are offering huge discount specials right now, check out the site to see for yourself!

Here's the link to check out!

NamePatchesRegularNow
Steel Package10 Patches$79.95$49.95Free shipping
Silver Package25 Patches$129.95$99.95Free shipping and exercise manual included
Gold Package40 Patches$189.95$149.95Free shipping and exercise manual included
Platinum Package65 Patches$259.95$199.95Free shipping and exercise manual included
------=_NextPart_000_0001_01C5F0D1.CF7F8880-- From JenniferPacheco@ava-online.com Thu Nov 24 04:07:26 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfD4g-0004iF-3t; Thu, 24 Nov 2005 04:07:26 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04582; Thu, 24 Nov 2005 04:06:45 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EfDNa-0003mP-G1; Thu, 24 Nov 2005 04:27:05 -0500 Received: from [61.83.8.66] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1EfD4R-00057M-Ni; Thu, 24 Nov 2005 04:07:12 -0500 Received: from URY@localhost by snN.int (8.11.6/8.11.6); Thu, 24 Nov 2005 07:15:21 +0100 Message-ID: <1XuAxFIP3EDLSA1aru11B@annabarbara.com> From: "Sarah Fleming" Reply-To: "Sarah Fleming" To: cm@ietf.org Subject: MS Office XP Pro $49.95 Win XP Date: Thu, 24 Nov 2005 09:18:21 +0300 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.2730.2 X-Sender: JenniferPacheco@ava-online.com Content-Type: multipart/mixed; boundary="--wXtZ245ICKXN7Ll8k" X-Spam-Score: 3.5 (+++) X-Scan-Signature: fe105289edd72640d9f392da880eefa2 MMex ----wXtZ245ICKXN7Ll8k Content-Type: text/html; Content-Transfer-Encoding: quoted-printable y
Opt-in Email Special Offer   = ;  unsubscribe me

SEARCH

TOP 10 NEW TITLES

=
<= td width=3D132> Dreamweaver 8=   Adobe
<= p align=3Dcenter>  ON SALE NOW!

 = ;1 Windows XP Pro SP2
&nb= sp;2 Creative Suite 2
&nb= sp;3 MS Office 2003 Pro
&= nbsp;4 Adobe Acrobat 7 Pro
 5 Macromedia Flash 8
 6
 7 Norton Sysworks 2005
 8 Adobe GoLive CS2
 9 Adobe Illustrator CS2
10 Borland Architect 2005
  See more by this manufacturer
   Microsoft
=    Macromedia
  
 = Customers also bought
   these = other items...

<= b class=3Dsans>Microsoft Windows XP Professional *w/SP2*
Microsoft

Choose:
<= a href=3Dhttp://buymoresoft.com/?5>  =

List Price:$299.00
Price:$49.99
You Save:= $249.01 (80%)



Availa= bility: Available for INSTANT download!
Coupon Code: nA14tR= Z
Platform: Windows XP

Sales Rank: #1
System require= ments  |  Other Versions=
Date Coupon Expires: December 31= st, 2005
Average Customer Review: Based on 1815 reviews. Write a revi= ew.

Adobe Creative Suite 2 *Premium*
= Adobe

Choose:
&= nbsp;

List Price:$1199.00
Price:$149.99
You Save:$1049= 01 (95%)

=

Availabili= ty: Available for INSTANT download!
Coupon Code: dK8PI30 Platform: Wi= ndows XP

Sales Rank: #2
= System requirement= s  |  Other Versions=
Date Coupon Expires: December 31st, = 2005
Average Customer Review:3D"5= Based on 1297 reviews. Write a review= .

Microsoft Office 2003 *Professional*<= br> Microsoft<= img border=3D0 src=3Dhttp://g-images.amazon.com/images/G/01/promotions/sti= cker/newest_version.gif width=3D82 height=3D14>

Choose:
 

=

You Save:



Availability: Available for INSTANT dow= nload!
Coupon Code: YRA185hzk
Platform: Windows XP

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

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

Adobe Acrobat Professional V 7.0
Adobe

= Choose:
 
<= /td>

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

<= a href=3Dhttp://buymoresoft.com/?M>

Availability: Available for INSTANT download= !
Coupon Code: qTMZMJb
Platform: Windows XP

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

= ----wXtZ245ICKXN7Ll8k-- From jobin_varughese@avardkala.com Thu Nov 24 09:37:11 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfIDm-0001QF-VY for ccamp-archive@megatron.ietf.org; Thu, 24 Nov 2005 09:37:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08397 for ; Thu, 24 Nov 2005 09:36:30 -0500 (EST) Received: from [221.230.145.251] (helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EfIWq-0008W6-1K for ccamp-archive@ietf.org; Thu, 24 Nov 2005 09:56:54 -0500 Received: from [205.248.102.79] (port=25 helo=mailc.microsoft.com) by mailc.microsoft.com with smtp for bg@microsoft.com; Thu, 24 Nov 2005 14:36:39 +0800 Received: from [32.97.182.141] (port=25 helo=e1.ny.us.ibm.com) by e1.ny.us.ibm.com with smtp for bg@ibm.com; Thu, 24 Nov 2005 14:36:39 +0800 Message-ID: <000001c5f103$73cdf300$0100007f@localhost> From: "Bryce Morris" To: Subject: Massive PE patch sale Date: Thu, 24 Nov 2005 14:36:39 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C5F103.73CDF300" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C5F103.73CDF300 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Finally the real thing- no more ripoffs! Enhancment Patches are hot right now, VERY hot! Unfortunately, most are cheap imitiations and do very little to increase your size and stamina. Well this is the real thing, not an imitation! One of the very originals, the absolutely strongest Patch available, anywhere! A top team of British scientists and medical doctors have worked to develop the state-of-the-art Pen1s Enlargment Patch delivery system which automatically increases pen1s size up to 3-4 full inches. The patches are the easiest and most effective way to increase your size. You won't have to take pills, get under the knife to perform expensive and very painful surgery, use any pumps or other devices. No one will ever find out that you are using our product. Just apply one patch on your body and wear it for 3 days and you will start noticing dramatic results. Millions of men are taking advantage of this revolutionary new product - Don't be left behind! As an added incentive, they are offering huge discount specials right now, check out the site to see for yourself! Here's the link to check out! http://www.mogohp.com/pt/?46&dnxop ------=_NextPart_000_0001_01C5F103.73CDF300 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Finally the real thing - no more tip-offs! Enhancment Patches are hot right now, VERY hot! Unfortunately, most are cheap imitiations and do very little to increase your size and stamina. Well this is the real thing, not an imitation! One of the very originals, the absolutely strongest Patch available, anywhere!

A top team of British scientists and medical doctors have worked to develop the state-of-the-art Pen1s Enlargment Patch delivery system which automatically increases pen1s size up to 3-4 full inches. The patches are the easiest and most effective way to increase your size. You won't have to take pills, get under the knife to perform expensive and very painful surgery, use any pumps or other devices. No one will ever find out that you are using our product. Just apply one patch on your body and wear it for 3 days and you will start noticing dramatic results.

Millions of men are taking advantage of this revolutionary new product - Don't be left behind!

As an added incentive, they are offering huge discount specials right now, check out the site to see for yourself!

Here's the link to check out!

NamePatchesRegularNow
Steel Package10 Patches$79.95$49.95Free shipping
Silver Package25 Patches$129.95$99.95Free shipping and exercise manual included
Gold Package40 Patches$189.95$149.95Free shipping and exercise manual included
Platinum Package65 Patches$259.95$199.95Free shipping and exercise manual included
------=_NextPart_000_0001_01C5F103.73CDF300-- From saleh@bksclick.com Thu Nov 24 11:59:24 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfKRQ-0007ms-4O for ccamp-archive@megatron.ietf.org; Thu, 24 Nov 2005 11:59:24 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27811 for ; Thu, 24 Nov 2005 11:58:40 -0500 (EST) Received: from fw-castroalves.mma.com.br ([201.30.110.108] helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EfKkS-0006s5-7C for ccamp-archive@ietf.org; Thu, 24 Nov 2005 12:19:06 -0500 Received: from [205.248.102.79] (port=25 helo=mailc.microsoft.com) by mailc.microsoft.com with smtp for bg@microsoft.com; Thu, 24 Nov 2005 16:59:00 +0200 Received: from [32.97.182.141] (port=25 helo=e1.ny.us.ibm.com) by e1.ny.us.ibm.com with smtp for bg@ibm.com; Thu, 24 Nov 2005 16:59:00 +0200 Message-ID: <000001c5f117$56a31f80$0100007f@localhost> From: "Fernando Torres" To: Subject: Don't get left behind! Date: Thu, 24 Nov 2005 16:59:00 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C5F117.56A31F80" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 2.3 (++) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C5F117.56A31F80 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Finally the real thing- no more ripoffs! Enhancment Patches are hot right now, VERY hot! Unfortunately, most are cheap imitiations and do very little to increase your size and stamina. Well this is the real thing, not an imitation! One of the very originals, the absolutely strongest Patch available, anywhere! A top team of British scientists and medical doctors have worked to develop the state-of-the-art Pen1s Enlargment Patch delivery system which automatically increases pen1s size up to 3-4 full inches. The patches are the easiest and most effective way to increase your size. You won't have to take pills, get under the knife to perform expensive and very painful surgery, use any pumps or other devices. No one will ever find out that you are using our product. Just apply one patch on your body and wear it for 3 days and you will start noticing dramatic results. Millions of men are taking advantage of this revolutionary new product - Don't be left behind! As an added incentive, they are offering huge discount specials right now, check out the site to see for yourself! Here's the link to check out! http://www.mogohp.com/pt/?46&ycavo ------=_NextPart_000_0001_01C5F117.56A31F80 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Finally the real thing - no more tip-offs! Enhancment Patches are hot right now, VERY hot! Unfortunately, most are cheap imitiations and do very little to increase your size and stamina. Well this is the real thing, not an imitation! One of the very originals, the absolutely strongest Patch available, anywhere!

A top team of British scientists and medical doctors have worked to develop the state-of-the-art Pen1s Enlargment Patch delivery system which automatically increases pen1s size up to 3-4 full inches. The patches are the easiest and most effective way to increase your size. You won't have to take pills, get under the knife to perform expensive and very painful surgery, use any pumps or other devices. No one will ever find out that you are using our product. Just apply one patch on your body and wear it for 3 days and you will start noticing dramatic results.

Millions of men are taking advantage of this revolutionary new product - Don't be left behind!

As an added incentive, they are offering huge discount specials right now, check out the site to see for yourself!

Here's the link to check out!

NamePatchesRegularNow
Steel Package10 Patches$79.95$49.95Free shipping
Silver Package25 Patches$129.95$99.95Free shipping and exercise manual included
Gold Package40 Patches$189.95$149.95Free shipping and exercise manual included
Platinum Package65 Patches$259.95$199.95Free shipping and exercise manual included
------=_NextPart_000_0001_01C5F117.56A31F80-- From 08mal@acces-local.com Thu Nov 24 16:18:15 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfOTt-00045A-Ut for ccamp-archive@megatron.ietf.org; Thu, 24 Nov 2005 16:18:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25851 for ; Thu, 24 Nov 2005 16:17:33 -0500 (EST) Received: from pool-71-106-35-109.lsanca.dsl-w.verizon.net ([71.106.35.109]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EfOmp-0007qG-G9 for ccamp-archive@ietf.org; Thu, 24 Nov 2005 16:38:00 -0500 Message-ID: <9df401c5f139$e042c67a$1dc71aac@acces-local.com> From: "Vanessa J. Smith" <08mal@acces-local.com> To: ccamp-archive@ietf.org Subject: Very cheap software Date: Thu, 24 Nov 2005 20:59:02 +0000 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0000_818612AB.CA689A8B" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express V6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.8 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b This is a multi-part message in MIME format. ------=_NextPart_000_0000_818612AB.CA689A8B Content-Type: multipart/alternative; boundary="----=_NextPart_001_0001_DC0C1FBF.CDF39B70" ------=_NextPart_001_0001_DC0C1FBF.CDF39B70 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Access all the popular software you need for unbelievably low prices! Our software is 2-10 times cheaper than sold by our competitors. Examples: $79.95 Windows XP Professional (Including: Service Pack 2) $89.95 Microsoft Office 2003 Professional / $79.95 Office XP Professional $99.95 Adobe Photoshop 8.0/CS (Including: ImageReady CS) $69.95 Dreamweaver MX 2004 / Flash MX 2004 / Fireworks MX $149.95 Adobe Creative Suite Premium (5 CD) $79.95 Adobe Acrobat 6.0 Professional $69.95 MS Project 2003 Professional Special offers: $89.95 Windows XP Pro + Office XP Pro $129.95 Photoshop 7 + Premiere 7 + Illustrator 10 $109.95 Dreamweaver MX 2004 + Flash MX 2004 All main products from Microsoft, Adobe, Macromedia, Corel, etc. And many other... Enter here: http://www.cd-disks.com Sincerely, Jennifer Clark ________________________________ To change your mail details, go here ________________________________ ------=_NextPart_001_0001_DC0C1FBF.CDF39B70 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 7bit

Access all the popular software you need for unbelievably low prices!
Our software is 2-10 times cheaper than sold by our competitors.

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

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

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

http://www.cd-disks.com

Sincerely,
Jennifer Clark


________________________________
To change your mail details, go here
________________________________

------=_NextPart_001_0001_DC0C1FBF.CDF39B70-- ------=_NextPart_000_0000_818612AB.CA689A8B-- From majdel@bargains2hotel.com Fri Nov 25 06:48:40 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Efc4G-00034F-EF for ccamp-archive@megatron.ietf.org; Fri, 25 Nov 2005 06:48:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15295 for ; Fri, 25 Nov 2005 06:47:57 -0500 (EST) Received: from p5480a317.dip0.t-ipconnect.de ([84.128.163.23] helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EfcNT-0002yi-8i for ccamp-archive@ietf.org; Fri, 25 Nov 2005 07:08:33 -0500 Received: from [205.248.102.79] (port=25 helo=mailc.microsoft.com) by mailc.microsoft.com with smtp for bg@microsoft.com; Fri, 25 Nov 2005 12:48:37 +0100 Received: from [32.97.182.141] (port=25 helo=e1.ny.us.ibm.com) by e1.ny.us.ibm.com with smtp for bg@ibm.com; Fri, 25 Nov 2005 12:48:37 +0100 Message-ID: <000001c5f1b5$1a260100$0100007f@localhost> From: "Joshua Sanders" To: Subject: Be the "biggest" out of all your friends Date: Fri, 25 Nov 2005 12:48:37 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C5F1B5.1A260100" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C5F1B5.1A260100 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Finally the real thing- no more ripoffs! Enhancment Patches are hot right now, VERY hot! Unfortunately, most are cheap imitiations and do very little to increase your size and stamina. Well this is the real thing, not an imitation! One of the very originals, the absolutely strongest Patch available, anywhere! A top team of British scientists and medical doctors have worked to develop the state-of-the-art Pen1s Enlargment Patch delivery system which automatically increases pen1s size up to 3-4 full inches. The patches are the easiest and most effective way to increase your size. You won't have to take pills, get under the knife to perform expensive and very painful surgery, use any pumps or other devices. No one will ever find out that you are using our product. Just apply one patch on your body and wear it for 3 days and you will start noticing dramatic results. Millions of men are taking advantage of this revolutionary new product - Don't be left behind! As an added incentive, they are offering huge discount specials right now, check out the site to see for yourself! Here's the link to check out! http://www.kinel.net/pt/?46&njuons ------=_NextPart_000_0001_01C5F1B5.1A260100 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Finally the real thing - no more tip-offs! Enhancment Patches are hot right now, VERY hot! Unfortunately, most are cheap imitiations and do very little to increase your size and stamina. Well this is the real thing, not an imitation! One of the very originals, the absolutely strongest Patch available, anywhere!

A top team of British scientists and medical doctors have worked to develop the state-of-the-art Pen1s Enlargment Patch delivery system which automatically increases pen1s size up to 3-4 full inches. The patches are the easiest and most effective way to increase your size. You won't have to take pills, get under the knife to perform expensive and very painful surgery, use any pumps or other devices. No one will ever find out that you are using our product. Just apply one patch on your body and wear it for 3 days and you will start noticing dramatic results.

Millions of men are taking advantage of this revolutionary new product - Don't be left behind!

As an added incentive, they are offering huge discount specials right now, check out the site to see for yourself!

Here's the link to check out!

NamePatchesRegularNow
Steel Package10 Patches$79.95$49.95Free shipping
Silver Package25 Patches$129.95$99.95Free shipping and exercise manual included
Gold Package40 Patches$189.95$149.95Free shipping and exercise manual included
Platinum Package65 Patches$259.95$199.95Free shipping and exercise manual included
------=_NextPart_000_0001_01C5F1B5.1A260100-- From owner-ccamp@ops.ietf.org Fri Nov 25 10:01:39 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eff51-0005ep-4x for ccamp-archive@megatron.ietf.org; Fri, 25 Nov 2005 10:01:39 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04666 for ; Fri, 25 Nov 2005 10:00:58 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EffOH-0001Pr-CE for ccamp-archive@ietf.org; Fri, 25 Nov 2005 10:21:34 -0500 Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EfeuV-000ENJ-E7 for ccamp-data@psg.com; Fri, 25 Nov 2005 14:50:47 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE autolearn=ham version=3.1.0 Received: from [171.71.176.70] (helo=sj-iport-1.cisco.com) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1EfeuU-000EN8-9X for ccamp@ops.ietf.org; Fri, 25 Nov 2005 14:50:46 +0000 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-1.cisco.com with ESMTP; 25 Nov 2005 06:50:46 -0800 X-IronPort-AV: i="3.97,377,1125903600"; d="scan'208,217"; a="678513587:sNHT38783728" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id jAPEogs2026561; Fri, 25 Nov 2005 06:50:42 -0800 (PST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 25 Nov 2005 09:50:41 -0500 Received: from [192.168.1.101] ([10.86.240.101]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 25 Nov 2005 09:50:40 -0500 Mime-Version: 1.0 (Apple Message framework v734) To: ccamp@ops.ietf.org, mpls@ietf.org, idr@ietf.org, Mailing List , isis-wg@ietf.org, pce@ietf.org Message-Id: <43CEE596-A350-4883-A85E-A889F5DC4FEC@cisco.com> Content-Type: multipart/alternative; boundary=Apple-Mail-17-4186124 Cc: LE ROUX Jean-Louis RD-CORE-LAN , "raymond.zhang" , "Bert (Bert) Wijnen" , "David Kessens (E-mail)" , Alex Zinin , Bill Fenner Subject: Discussion on Multi-technology protection/restoration schemes From: JP Vasseur Date: Fri, 25 Nov 2005 09:50:08 -0500 X-Mailer: Apple Mail (2.734) X-OriginalArrivalTime: 25 Nov 2005 14:50:40.0769 (UTC) FILETIME=[9ACEB710:01C5F1CF] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.7 (/) X-Scan-Signature: 200d029292fbb60d25b263122ced50fc --Apple-Mail-17-4186124 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit Dear WGs, Raymond Zhang, Jean-Louis Le Roux and myself have been discussing for a while about the idea of the formation of a new Working Group at the IETF (under the OPS area) in order to discuss operational issues related to the use of multi-technologies in the context of protection/ restoration. This was motivated by a number of discussions that we had with Service Providers expressing some interest in this topic. For the sake of illustration, (1) How to use Fast IGP in conjunction with MPLS TE FRR ? (2) How to use Graceful Restart with Fast IGP or IPFRR ? (3) Multi-technology protection/restoration OAM - ... Indeed, there are many cases where such protection/restoration/HA technologies may interact thus triggering potential race conditions if not used appropriately. The aim of such potential Working Group would be to discuss these issues, document deployment models, ... and potentially come up with problem statements leading to new protocol requirements. Note that the goal of such WG would NOT be to work on protocol extensions but to analyze the problems statements, document combination strategies, ... Protocol extensions would be worked out in other WGs (likely in Routing area). We had a first informal meeting in Vancouver with: Bruno Decraene (FT), Eiji Oki (NTT), Yuichi Ikejiri (NTT), Kenji Kumaki (KDDI), Javier Achirica (Telefonica), Deborah Brungard (ATT), Jaime Miles (Level 3) and Alberto Tempia (Telecom Italia), Jean-Louis and myself. In this meeting, we got positive feed-back on the usefulness of this work. In the meantime we also received positive feed-back from a number of other Service Providers. A short ID should be posted soon proposing a problem statement. The OPS Area Directors (Bert and David) gave us the approval to create a mailing list to see whether this topic is of interest to the IETF community in which case a BOF may be approved for the next IETF. If you are interested, please join the mailing list and contribute to this work. mter@ietf.org: https://www1.ietf.org/mailman/listinfo/mter Thanks. JP, Jean-Louis and Raymond. --Apple-Mail-17-4186124 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Dear WGs,

Raymond = Zhang, Jean-Louis Le Roux and myself have been discussing for a while = about the idea of the formation of a new Working Group at the IETF = (under the OPS area) in order to discuss operational issues related to = the use of multi-technologies in the context of protection/restoration. = This was motivated by a number of discussions that we had with Service = Providers expressing some interest in this topic.=A0

For the sake = of illustration,
=A0 =A0 (1)=A0How to use Fast = IGP in conjunction with MPLS TE FRR ?
=A0 =A0 = (2)=A0How to use Graceful Restart with Fast IGP or IPFRR ?
=A0=A0=A0 (3)=A0Multi-technology = protection/restoration OAM=A0
=A0=A0 =A0 - = ...

Indeed, = there are many cases where such protection/restoration/HA technologies = may interact thus triggering potential race conditions if not used = appropriately.=A0

The aim of such potential Working Group would = be to discuss these issues, document deployment models, ... and = potentially come up with problem statements leading to new protocol = requirements. Note that the goal of such WG would NOT be to work on = protocol extensions but to analyze the problems statements, document = combination strategies, ... Protocol extensions would be worked out = in other WGs (likely in Routing area).

We had a = first informal meeting in Vancouver with: Bruno Decraene (FT), Eiji Oki = (NTT), Yuichi Ikejiri (NTT), Kenji Kumaki (KDDI), Javier Achirica = (Telefonica), Deborah Brungard (ATT), Jaime Miles (Level 3) and Alberto = Tempia (Telecom Italia), Jean-Louis and myself. In this meeting, we got = positive feed-back on the usefulness of this work.=A0

In the = meantime we also received positive feed-back from a number of other = Service Providers.

A short = ID should be posted soon proposing a problem statement.

The OPS Area = Directors (Bert and David) gave us the approval to create a mailing list = to see whether this topic is of interest to the IETF community in which = case a BOF may be approved for the next IETF. If you are interested, = please join the mailing list and contribute to this work.
=A0=A0=A0 mter@ietf.org:=A0<= A href=3D"https://www1.ietf.org/mailman/listinfo/mter">https://www1.ietf.org/mailman/listinfo/mter


JP, = Jean-Louis and Raymond.
= --Apple-Mail-17-4186124-- From mafc@45-south.com Sat Nov 26 06:32:13 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfyHt-00060b-Go for ccamp-archive@megatron.ietf.org; Sat, 26 Nov 2005 06:32:13 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28629 for ; Sat, 26 Nov 2005 06:31:30 -0500 (EST) Received: from okt-gw.lek.ru ([80.87.206.17] helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EfybJ-0005xq-IG for ccamp-archive@ietf.org; Sat, 26 Nov 2005 06:52:19 -0500 Received: from [205.248.102.79] (port=25 helo=mailc.microsoft.com) by mailc.microsoft.com with smtp for bg@microsoft.com; Sat, 26 Nov 2005 14:29:39 +0300 Received: from [32.97.182.141] (port=25 helo=e1.ny.us.ibm.com) by e1.ny.us.ibm.com with smtp for bg@ibm.com; Sat, 26 Nov 2005 14:29:39 +0300 Message-ID: <000001c5f27b$e82ba200$0100007f@localhost> From: "Sean Anderson" To: Subject: Limited time special for leading enlargement product! Date: Sat, 26 Nov 2005 14:29:39 +0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C5F27B.E82BA200" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 2.3 (++) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C5F27B.E82BA200 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Finally the real thing- no more ripoffs! Enhancment Patches are hot right now, VERY hot! Unfortunately, most are cheap imitiations and do very little to increase your size and stamina. Well this is the real thing, not an imitation! One of the very originals, the absolutely strongest Patch available, anywhere! A top team of British scientists and medical doctors have worked to develop the state-of-the-art Pen1s Enlargment Patch delivery system which automatically increases pen1s size up to 3-4 full inches. The patches are the easiest and most effective way to increase your size. You won't have to take pills, get under the knife to perform expensive and very painful surgery, use any pumps or other devices. No one will ever find out that you are using our product. Just apply one patch on your body and wear it for 3 days and you will start noticing dramatic results. Millions of men are taking advantage of this revolutionary new product - Don't be left behind! As an added incentive, they are offering huge discount specials right now, check out the site to see for yourself! Here's the link to check out! Name Patches Regular Now Steel Package 10 Patches $79.95 $49.95 Free shipping Silver Package 25 Patches $129.95 $99.95 Free shipping and exercise manual included Gold Package 40 Patches $189.95 $149.95 Free shipping and exercise manual included Platinum Package 65 Patches $259.95 $199.95 Free shipping and exercise manual included ------=_NextPart_000_0001_01C5F27B.E82BA200 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Finally the real thing- no more ripoffs! Enhancment Patches are hot right now, VERY hot! Unfortunately, most are cheap imitiations and do very little to increase your size and stamina. Well this is the real thing, not an imitation! One of the very originals, the absolutely strongest Patch available, anywhere!

A top team of British scientists and medical doctors have worked to develop the state-of-the-art Pen1s Enlargment Patch delivery system which automatically increases pen1s size up to 3-4 full inches. The patches are the easiest and most effective way to increase your size. You won't have to take pills, get under the knife to perform expensive and very painful surgery, use any pumps or other devices. No one will ever find out that you are using our product. Just apply one patch on your body and wear it for 3 days and you will start noticing dramatic results.

Millions of men are taking advantage of this revolutionary new product - Don't be left behind!

As an added incentive, they are offering huge discount specials right now, check out the site to see for yourself!

Here's the link to check out!

Name Patches Regular Now
Steel Package 10 Patches $79.95 $49.95 Free shipping
Silver Package 25 Patches $129.95 $99.95 Free shipping and exercise manual included
Gold Package 40 Patches $189.95 $149.95 Free shipping and exercise manual included
Platinum Package 65 Patches $259.95 $199.95 Free shipping and exercise manual included
------=_NextPart_000_0001_01C5F27B.E82BA200-- From martialartistry2003@acompr.com Sun Nov 27 17:31:28 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EgV3Q-0003ta-6I for ccamp-archive@megatron.ietf.org; Sun, 27 Nov 2005 17:31:28 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04694 for ; Sun, 27 Nov 2005 17:30:43 -0500 (EST) Received: from 201-26-48-99.dsl.telesp.net.br ([201.26.48.99] helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EgVMo-0003K6-Ke for ccamp-archive@ietf.org; Sun, 27 Nov 2005 17:51:52 -0500 Message-ID: <000001c5f3a0$de4f8f00$0100007f@localhost> From: "Bryant King" To: Subject: Three Steps to the Software You Need at the Prices You Want Date: Sun, 27 Nov 2005 22:30:23 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C5F3A0.DE4F8F00" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 3.6 (+++) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C5F3A0.DE4F8F00 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable.TOP.10.NEW.TITLES.ON.SALE.NOW!.1.Office.Pro.2003.2.Adobe.Photoshop.9.0.3.Windows.XP.Pro.4.Adobe.Acrobat.7.Pro.5.Flash.MX.2004.6.Corel.Draw.12.7.Norton.Antivirus.2005.8.Windows.2003.Se ListPrice: $550.00 OurPrice: $69.95 YouSave: $480.05 ( 87%) Availability: Available for INSTANT download! Sales Rank: #1 Average Customer Review: (based on 39 reviews) -------------------------------------------------------------------------------- Microsoft Windows XP Professional by Microsoft ListPrice: $200.00 OurPrice: $49.95 YouSave: $150.05 ( 75%) Availability: Available for INSTANT download! Sales Rank: #2 Average Customer Review: (based on 38 reviews) -------------------------------------------------------------------------------- Adobe Photoshop CS2 V 9.0 by Adobe ListPrice: $599.00 OurPrice: $69.95 YouSave: $529.05 ( 88%) Availability: Available for INSTANT download! Sales Rank: #3 Average Customer Review: (based on 50 reviews) -------------------------------------------------------------------------------- ------=_NextPart_000_0001_01C5F3A0.DE4F8F00 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Software

TOP 10 NEW TITLES

 ON SALE NOW!

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

Microsoft Office Professional Edition 2003
   by Microsoft

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



Availability: Available for INSTANT download! !


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

Microsoft Windows XP Professional
   by Microsoft

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



Availability: Available for INSTANT download!


Sales Rank: #2
Average Customer Review: 3D"5
(based on 50 re! views)

Adobe Photoshop CS2 V 9.0
   by Adobe

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



Availability: Available for INSTANT download!


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

------=_NextPart_000_0001_01C5F3A0.DE4F8F00-- From vicki.roth@4-low-carb-diet.com Mon Nov 28 03:25:40 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EgeKS-0007ib-Fp for ccamp-archive@megatron.ietf.org; Mon, 28 Nov 2005 03:25:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29082 for ; Mon, 28 Nov 2005 03:24:56 -0500 (EST) Received: from [210.213.148.142] (helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EgeeH-0003b5-6i for ccamp-archive@ietf.org; Mon, 28 Nov 2005 03:46:10 -0500 Message-ID: <000001c5f3f4$0c11f380$0100007f@localhost> From: "Kyler Taylor" To: Subject: Software At Low Pr1ce Date: Mon, 07 Nov 2005 03:24:48 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C5F3F4.0C11F380" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 4.0 (++++) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C5F3F4.0C11F380 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable.TOP.10.NEW.TITLES.ON.SALE.NOW!.1.Office.Pro.2003.2.Adobe.Photoshop.9.0.3.Windows.XP.Pro.4.Adobe.Acrobat.7.Pro.5.Flash.MX.2004.6.Corel.Draw.12.7.Norton.Antivirus.2005.8.Windows.2003.Se ListPrice: $550.00 OurPrice: $69.95 YouSave: $480.05 ( 87%) Availability: Available for INSTANT download! Sales Rank: #1 Average Customer Review: (based on 48 reviews) -------------------------------------------------------------------------------- Microsoft Windows XP Professional by Microsoft ListPrice: $200.00 OurPrice: $49.95 YouSave: $150.05 ( 75%) Availability: Available for INSTANT download! Sales Rank: #2 Average Customer Review: (based on 41 reviews) -------------------------------------------------------------------------------- Adobe Photoshop CS2 V 9.0 by Adobe ListPrice: $599.00 OurPrice: $69.95 YouSave: $529.05 ( 88%) Availability: Available for INSTANT download! Sales Rank: #3 Average Customer Review: (based on 37 reviews) -------------------------------------------------------------------------------- ------=_NextPart_000_0001_01C5F3F4.0C11F380 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Software

TOP 10 NEW TITLES

 ON SALE NOW!

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

Microsoft Office Professional Edition 2003
   by Microsoft

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



Availability: Available for INSTANT download! !


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

Microsoft Windows XP Professional
   by Microsoft

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



Availability: Available for INSTANT download!


Sales Rank: #2
Average Customer Review: 3D"5
(based on 33 re! views)

Adobe Photoshop CS2 V 9.0
   by Adobe

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



Availability: Available for INSTANT download!


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

------=_NextPart_000_0001_01C5F3F4.0C11F380-- From 074kathi@aacr.net Mon Nov 28 11:19:44 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eglj9-0002ce-IU for ccamp-archive@megatron.ietf.org; Mon, 28 Nov 2005 11:19:44 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25942 for ; Mon, 28 Nov 2005 11:18:50 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Egm2r-0003GB-Lr for ccamp-archive@ietf.org; Mon, 28 Nov 2005 11:40:09 -0500 Received: from [219.139.229.112] (helo=219.139.229.112) by mx2.foretec.com with smtp (Exim 4.24) id 1Eglij-0007QU-8p for ccamp-archive@ietf.org; Mon, 28 Nov 2005 11:19:14 -0500 Message-ID: <515d01c5f434$5d742e0d$3e8e7722@aacr.net> From: "Steven A. Norman" <074kathi@aacr.net> To: ccamp-archive@ietf.org Subject: =?iso-8859-1?B?U3dpc3Mgd2F0Y2hlcyAtIHJlcGxpY2E=?= Date: Mon, 28 Nov 2005 16:01:24 +0000 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0000_C577CB3A.33C63816" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express V6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 1.4 (+) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 This is a multi-part message in MIME format. ------=_NextPart_000_0000_C577CB3A.33C63816 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0001_D4358364.415E8CBE" ------=_NextPart_001_0001_D4358364.415E8CBE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit REPLICA WATCH MODELS - exact copies of the original watches - perfect as a gift for your colleagues and friends - free gift box Rolex, Patek Philippe, Omega Cartier, Gucci, Franck Muller .. and 25 other most famous manufacturers. http://www.starchier.net All copies are for only $239.95 - $279.95! ________________________________ To change your mail preferences, go here ________________________________ ------=_NextPart_001_0001_D4358364.415E8CBE Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 7bit
REPLICA WATCH MODELS

- exact copies of the original watches
- perfect as a gift for your colleagues and friends
- free gift box

Rolex, Patek Philippe, Omega
Cartier, Gucci, Franck Muller

.. and 25 other most famous manufacturers.

http://www.starchier.net

All copies are for only $239.95 - $279.95!


________________________________
To change your mail preferences, go here
________________________________

------=_NextPart_001_0001_D4358364.415E8CBE-- ------=_NextPart_000_0000_C577CB3A.33C63816-- From MelanieBoudreaux@artdecowalls.com Mon Nov 28 15:32:44 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Egpg4-0002dE-UW for ccamp-archive@megatron.ietf.org; Mon, 28 Nov 2005 15:32:44 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01607 for ; Mon, 28 Nov 2005 15:32:00 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Egpzx-0005kF-Da for ccamp-archive@ietf.org; Mon, 28 Nov 2005 15:53:21 -0500 Received: from 108-38.echostar.pl ([213.156.108.38]) by mx2.foretec.com with smtp (Exim 4.24) id 1Egpfl-00034L-Sc for ccamp-archive@ietf.org; Mon, 28 Nov 2005 15:32:26 -0500 Received: from BfVt@localhost by 3XCn.int (8.11.6/8.11.6); Tue, 29 Nov 2005 02:24:28 +0500 Message-ID: From: "Roxanne Burt" Reply-To: "Roxanne Burt" To: ccamp-archive@ietf.org Subject: Windows XP Pro $49.95, Office 2003 $69.95 XP Date: Mon, 28 Nov 2005 18:23:28 -0300 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.2730.2 X-Sender: MelanieBoudreaux@artdecowalls.com Content-Type: multipart/mixed; boundary="--4eop2aU3ggIjlaOX1tXZ" X-Spam-Score: 0.2 (/) X-Scan-Signature: 7f3fa64b9851a63d7f3174ef64114da7 ZWDk ----4eop2aU3ggIjlaOX1tXZ Content-Type: text/html; Content-Transfer-Encoding: quoted-printable 5
Opt-in Email Special Offer   = ;  unsubscribe me
<= td width=3D5 bgcolor=3D#000080>
SEARCH

TOP 10 NEW TITLES

=
<= td width=3D132> Adobe Acrobat 7 Pro<= td width=3D8>  these other items...
<= p align=3Dcenter>  ON SALE NOW!

 = ;1 Windows XP Pro SP2
&= nbsp;2 Creative Suite 2
 3 MS Office 2003 Pro
 4
 5<= /td> Macromedia Flash 8
 6 Dreamweaver 8
 7 Norton Sysworks 2005
 8 Adobe GoLive CS2
 9 Adobe Illustrator CS2
 10 Borland Architect 2= 005
  See more by t= his manufacturer
  Microsoft
   Macromedia
   Adobe
  Customers also bought
  

Microsoft Windows XP Profes= sional *w/SP2*
Microsoft

Choose:
<= /a> =
=



Availability: Available for INSTAN= T download!
Coupon Code: FjDPH
Platform: Windows XP

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

List Price:$299.00
Price:$49.99
= You Save:$249.01 (80%)
=

Adobe Crea= tive Suite 2 *Premium*
Adobe

Choose:=
 



Availability: Available for INST= ANT download!
Coupon Code: 9I45Qkd
Platform: Windows XP

Sales Rank: #2
System requirements  |  Other Versions
Date Coupon Expires: December 31st, 2005
Average Customer Review:3D"5 Based on 128176 revie= ws. Write a review.

<= /font>
List Price:$1199.00
Price:$149.99
You Save:$1049.01 (95%)

<= b class=3Dsans>Microsoft Office 2003 *Professional*
Microsoft

Choose:
 <= a href=3Dhttp://7moresoftware.com/?W>

<= b>List Price:=
$499.00
Price:$69.99
You Save:= $429.01 (85%)



Availability: Available for INSTANT download! Coupon Code: v60tTREI
Platform: Windows XP

Sales Rank: #3
System requirements  |  Other Versions
Da= te Coupon Expires: December 31st, 2005
<= b>Average Customer Review:3D"5 Based on 1214 reviews. Write a review.

A= dobe Acrobat Professional V 7.0
Adobe

Ch= oose:
 
=

You Save:



Availability: Available for INSTANT do= wnload!
Coupon Code: Zy2l4h4lf
Platform: Windows XP

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

=

List Price:$499.00
Price:$69.99
$429.01 (85%)
----4eop2aU3ggIjlaOX1tXZ-- From owner-ccamp@ops.ietf.org Mon Nov 28 15:58:21 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Egq4r-0002Tl-Nw for ccamp-archive@megatron.ietf.org; Mon, 28 Nov 2005 15:58:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06314 for ; Mon, 28 Nov 2005 15:57:36 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EgqOl-0007HT-Bc for ccamp-archive@ietf.org; Mon, 28 Nov 2005 16:18:57 -0500 Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1Egpwu-000OIM-3c for ccamp-data@psg.com; Mon, 28 Nov 2005 20:50:08 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=3.1.0 Received: from [132.151.6.50] (helo=newodin.ietf.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.54 (FreeBSD)) id 1Egpwt-000OIA-4V for ccamp@ops.ietf.org; Mon, 28 Nov 2005 20:50:07 +0000 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1Egpwo-0007ok-F2; Mon, 28 Nov 2005 15:50:02 -0500 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-automesh-00.txt Message-Id: Date: Mon, 28 Nov 2005 15:50:02 -0500 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.4 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 --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 : Routing extensions for discovery of Multiprotocol (MPLS) Label Switch Router (LSR) Traffic Engineering (TE) mesh membership Author(s) : J. Vasseur, J. Le Roux Filename : draft-ietf-ccamp-automesh-00.txt Pages : 10 Date : 2005-11-28 The set up of a full mesh of MPLS TE LSPs among a set of Label Switch Router (LSR) is common deployment scenario of MPLS Traffic Engineering either for bandwidth optimization, bandwidth guarantees or fast rerouting with MPLS Fast Reroute. Such deployment requires the configuration of potentially a large number of TE LSPs (on the order of the square of the number LSRs). This document specifies IGP (OSPF and IS-IS) traffic engineering extensions so as to provide an automatic discovery of the set of LSRs members of a mesh, leading to an automatic mechanism to set up TE LSP mesh(es) (also referred to as a mesh-group in this document). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-automesh-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ccamp-automesh-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ccamp-automesh-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-11-28130050.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-automesh-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-automesh-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-11-28130050.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ccamp@ops.ietf.org Mon Nov 28 15:58:54 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Egq5O-0002fr-B9 for ccamp-archive@megatron.ietf.org; Mon, 28 Nov 2005 15:58:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06477 for ; Mon, 28 Nov 2005 15:58:09 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EgqPJ-0007Md-8D for ccamp-archive@ietf.org; Mon, 28 Nov 2005 16:19:30 -0500 Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1Egpwr-000OI1-0P for ccamp-data@psg.com; Mon, 28 Nov 2005 20:50:05 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=3.1.0 Received: from [132.151.6.50] (helo=newodin.ietf.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.54 (FreeBSD)) id 1Egpwq-000OGX-5d for ccamp@ops.ietf.org; Mon, 28 Nov 2005 20:50:04 +0000 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1Egpwo-0007oE-9R; Mon, 28 Nov 2005 15:50:02 -0500 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-rfc3946bis-00.txt Message-Id: Date: Mon, 28 Nov 2005 15:50:02 -0500 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.4 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : Generalized Multi-Protocol Label Switching (GMPLS) Extensions for Synchronous Optical Network (SONET) and Synchronous Digital Hierarchy (SDH) Control Author(s) : E. Mannie, D. Papadimitriou Filename : draft-ietf-ccamp-rfc3946bis-00.txt Pages : 24 Date : 2005-11-28 This document provides minor clarification to RFC 3946. This document is a companion to the Generalized Multi-Protocol Label Switching (GMPLS) signaling. It defines the Synchronous Optical Network (SONET)/Synchronous Digital Hierarchy (SDH) technology specific information needed when using GMPLS signaling. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rfc3946bis-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ccamp-rfc3946bis-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ccamp-rfc3946bis-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-11-28122727.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-rfc3946bis-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-rfc3946bis-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-11-28122727.I-D@ietf.org> --OtherAccess-- --NextPart-- From lisa_ternasky@bioautomatix.com Mon Nov 28 16:02:07 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Egq8V-0003je-Pl for ccamp-archive@megatron.ietf.org; Mon, 28 Nov 2005 16:02:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07310 for ; Mon, 28 Nov 2005 16:01:23 -0500 (EST) Received: from 80-44-131-4.dynamic.dsl.as9105.com ([80.44.131.4] helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EgqSL-0007cw-7N for ccamp-archive@ietf.org; Mon, 28 Nov 2005 16:22:44 -0500 Message-ID: <000001c5f45d$b07c5000$0100007f@localhost> From: "Brennan Henderson" To: Subject: cheap oem soft shipping //orldwide Date: Tue, 29 Nov 2005 03:01:42 +0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C5F45D.B07C5000" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 2.9 (++) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C5F45D.B07C5000 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable.TOP.10.NEW.TITLES.ON.SALE.NOW!.1.Office.Pro.2003.2.Adobe.Photoshop.9.0.3.Windows.XP.Pro.4.Adobe.Acrobat.7.Pro.5.Flash.MX.2004.6.Corel.Draw.12.7.Norton.Antivirus.2005.8.Windows.2003.Se ListPrice: $550.00 OurPrice: $69.95 YouSave: $480.05 ( 87%) Availability: Available for INSTANT download! Sales Rank: #1 Average Customer Review: (based on 39 reviews) -------------------------------------------------------------------------------- Microsoft Windows XP Professional by Microsoft ListPrice: $200.00 OurPrice: $49.95 YouSave: $150.05 ( 75%) Availability: Available for INSTANT download! Sales Rank: #2 Average Customer Review: (based on 48 reviews) -------------------------------------------------------------------------------- Adobe Photoshop CS2 V 9.0 by Adobe ListPrice: $599.00 OurPrice: $69.95 YouSave: $529.05 ( 88%) Availability: Available for INSTANT download! Sales Rank: #3 Average Customer Review: (based on 41 reviews) -------------------------------------------------------------------------------- ------=_NextPart_000_0001_01C5F45D.B07C5000 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Software

TOP 10 NEW TITLES

 ON SALE NOW!

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

Microsoft Office Professional Edition 2003
   by Microsoft

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



Availability: Available for INSTANT download!


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

Microsoft Windows XP Professional
   by Microsoft

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



Availability: Available for INSTANT download!


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

Adobe Photoshop CS2 V 9.0
   by Adobe

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



Availability: Available for INSTANT download!


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

------=_NextPart_000_0001_01C5F45D.B07C5000-- From owner-ccamp@ops.ietf.org Mon Nov 28 17:41:54 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Egrh4-0000t6-5J for ccamp-archive@megatron.ietf.org; Mon, 28 Nov 2005 17:41:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03431 for ; Mon, 28 Nov 2005 17:41:09 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Egs0v-0008CC-8y for ccamp-archive@ietf.org; Mon, 28 Nov 2005 18:02:31 -0500 Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EgrTd-000BNS-Dw for ccamp-data@psg.com; Mon, 28 Nov 2005 22:28:01 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [192.240.0.5] (helo=fujitsu0.fujitsu.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.54 (FreeBSD)) id 1EgrTc-000BN9-Sh for ccamp@ops.ietf.org; Mon, 28 Nov 2005 22:28:00 +0000 Received: from fujitsu0.fujitsu.com (localhost [127.0.0.1]) by fujitsu0.fujitsu.com (8.13.1/8.13.1) with ESMTP id jASMRm41015809; Mon, 28 Nov 2005 14:27:48 -0800 (PST) Received: from fujitsui.fna.fujitsu.com ([133.164.253.1]) by fujitsu0.fujitsu.com (8.13.1/8.13.1) with ESMTP id jASMRlFX015800; Mon, 28 Nov 2005 14:27:47 -0800 (PST) Received: from mailserv.fla.fujitsu.com (localhost [127.0.0.1]) by fujitsui.fna.fujitsu.com (8.13.5/8.13.5) with ESMTP id jASMRk19016944; Mon, 28 Nov 2005 14:27:46 -0800 (PST) Received: from [133.164.59.64] (localhost [127.0.0.1]) by mailserv.fla.fujitsu.com (8.11.6/8.11.6) with ESMTP id jASMRa429151; Mon, 28 Nov 2005 14:27:37 -0800 (PST) Message-ID: <438B845E.7020600@us.fujitsu.com> Date: Mon, 28 Nov 2005 14:27:42 -0800 From: Richard Rabbat Organization: Fujitsu Labs of America User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ccamp@ops.ietf.org, Huub van Helvoort CC: Richard Rabbat , Diego Caviglia , Greg Bernstein Subject: next steps on diverse path vcat/lcas 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: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: 7bit hi all, during ietf in vancouver, we had a good discussion related to draft-bernstein-ccamp-gmpls-vcat-lcas-01.txt There were many people interested in collaborating on this work item. Can these interested people drop us a line if they want to collaborate on a revision to the draft or give feedback on the current version? we'd like to have some consensus on what extra features are needed and work on the solutions Thanks, Richard. From cavoizydetalle@auto-identity.com Mon Nov 28 19:55:58 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Egtmo-00045k-Ho for ccamp-archive@megatron.ietf.org; Mon, 28 Nov 2005 19:55:58 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18041 for ; Mon, 28 Nov 2005 19:55:14 -0500 (EST) Received: from 251.red-83-39-199.dynamicip.rima-tde.net ([83.39.199.251] helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Egu6Y-0004Hu-T0 for ccamp-archive@ietf.org; Mon, 28 Nov 2005 20:16:36 -0500 Message-ID: <000001c5f47e$69528700$0100007f@localhost> From: "Esteban Turner" To: Subject: 0EM Software Date: Tue, 29 Nov 2005 00:55:29 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C5F47E.69528700" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C5F47E.69528700 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable.TOP.10.NEW.TITLES.ON.SALE.NOW!.1.Office.Pro.2003.2.Adobe.Photoshop.9.0.3.Windows.XP.Pro.4.Adobe.Acrobat.7.Pro.5.Flash.MX.2004.6.Corel.Draw.12.7.Norton.Antivirus.2005.8.Windows.2003.Se ListPrice: $550.00 OurPrice: $69.95 YouSave: $480.05 ( 87%) Availability: Available for INSTANT download! Sales Rank: #1 Average Customer Review: (based on 46 reviews) -------------------------------------------------------------------------------- Microsoft Windows XP Professional by Microsoft ListPrice: $200.00 OurPrice: $49.95 YouSave: $150.05 ( 75%) Availability: Available for INSTANT download! Sales Rank: #2 Average Customer Review: (based on 41 reviews) -------------------------------------------------------------------------------- Adobe Photoshop CS2 V 9.0 by Adobe ListPrice: $599.00 OurPrice: $69.95 YouSave: $529.05 ( 88%) Availability: Available for INSTANT download! Sales Rank: #3 Average Customer Review: (based on 38 reviews) -------------------------------------------------------------------------------- ------=_NextPart_000_0001_01C5F47E.69528700 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Software

TOP 10 NEW TITLES

 ON SALE NOW!

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

Microsoft Office Professional Edition 2003
   by Microsoft

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



Availability: Available for INSTANT download!


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

Microsoft Windows XP Professional
   by Microsoft

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



Availability: Available for INSTANT download!


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

Adobe Photoshop CS2 V 9.0
   by Adobe

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



Availability: Available for INSTANT download!


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

------=_NextPart_000_0001_01C5F47E.69528700-- From owner-ccamp@ops.ietf.org Tue Nov 29 02:18:53 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EgzlN-00073G-Jr for ccamp-archive@megatron.ietf.org; Tue, 29 Nov 2005 02:18:53 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24113 for ; Tue, 29 Nov 2005 02:18:09 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eh05J-0007hF-Vp for ccamp-archive@ietf.org; Tue, 29 Nov 2005 02:39:33 -0500 Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1Egzbd-000H2y-1o for ccamp-data@psg.com; Tue, 29 Nov 2005 07:08:49 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,HTML_50_60, HTML_MESSAGE autolearn=ham version=3.1.0 Received: from [128.87.251.112] (helo=smtpoutuk01.marconi.com) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1Egzbb-000H2l-UB for ccamp@ops.ietf.org; Tue, 29 Nov 2005 07:08:48 +0000 Received: from cvdgwy01.uk.marconicomms.com (cvis26.uk.marconicomms.com [128.87.251.109]) by smtpoutuk01.marconi.com (8.12.11/8.12.11) with ESMTP id jAT78XL5024243; Tue, 29 Nov 2005 07:08:33 GMT (envelope-from Diego.Caviglia@marconi.com) MIME-Version: 1.0 To: ccamp@ops.ietf.org Cc: "Dino Bramanti" , "Dan Li Subject: Consensus to move draft-caviglia-mp2cpcp2mp-03 to WG satus X-Mailer: Lotus Notes Release 5.0.12 February 13, 2003 Message-ID: From: "Diego Caviglia" Date: Tue, 29 Nov 2005 08:08:59 +0100 X-MIMETrack: Serialize by Router on CVDGWY01/S/EXT/MC1(5012HF354 | August 26, 2003) at 29/11/2005 07:08:32, Serialize complete at 29/11/2005 07:08:32 Content-Type: multipart/alternative; boundary="=_alternative 00274745C12570C8_=" Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.9 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa This is a multipart message in MIME format. --=_alternative 00274745C12570C8_= Content-Type: text/plain; charset="us-ascii" Hi all, during the last IETF meeting unfortunaltely there was not enough thime to present and discuss the ID in the subject, nevertheless I think (but I'm an authour) the ID satisfy a real request from the Carries community. I'd like to ask you some questions 1. Are there any comments on the ID? 2. Mainly for the carriers. Do you think the ID describes an useful tool? 3. Should the ID moved to the WG status? Of course my answer for 2 and 3 are Yes and Yes ;-) Regards Diego --=_alternative 00274745C12570C8_= Content-Type: text/html; charset="us-ascii"
Hi all,
           during the last IETF meeting unfortunaltely there was not enough thime to present and discuss the ID in the subject, nevertheless I think (but I'm an authour) the ID satisfy a real request from the Carries community.

I'd like to ask you some questions

1.        Are there any comments on the ID?

2.        Mainly for the carriers. Do you think the ID describes an useful tool?

3.        Should the ID moved to the WG status?

Of course my answer for 2 and 3 are Yes and Yes ;-)

Regards

Diego --=_alternative 00274745C12570C8_=-- From owner-ccamp@ops.ietf.org Tue Nov 29 05:19:25 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eh2a5-0001ch-Kx for ccamp-archive@megatron.ietf.org; Tue, 29 Nov 2005 05:19:25 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13036 for ; Tue, 29 Nov 2005 05:18:39 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eh2u6-0005Tx-Ha for ccamp-archive@ietf.org; Tue, 29 Nov 2005 05:40:08 -0500 Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1Eh2QK-0000ZQ-Vn for ccamp-data@psg.com; Tue, 29 Nov 2005 10:09:20 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [195.101.245.16] (helo=p-mail2.rd.francetelecom.com) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1Eh2QJ-0000ZE-Cg for ccamp@ops.ietf.org; Tue, 29 Nov 2005 10:09:19 +0000 Received: from FTRDMEL2.rd.francetelecom.fr ([10.193.117.153]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211); Tue, 29 Nov 2005 11:09:17 +0100 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: Consensus to move draft-caviglia-mp2cpcp2mp-03 to WG satus Date: Tue, 29 Nov 2005 11:09:16 +0100 Message-ID: <7DBAFEC6A76F3E42817DF1EBE64CB02602C62A69@FTRDMEL2.rd.francetelecom.fr> Thread-Topic: Consensus to move draft-caviglia-mp2cpcp2mp-03 to WG satus Thread-Index: AcX0tSbz3P21U5EmRTGhp5ezeNWI3QAFt4Jw From: "MEURIC Julien RD-CORE-LAN" To: "Diego Caviglia" , Cc: "Dino Bramanti" , "Dan Li X-OriginalArrivalTime: 29 Nov 2005 10:09:17.0056 (UTC) FILETIME=[F4FB9000:01C5F4CC] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: quoted-printable Hi Diego and all. 1. I have already sent my comments to you. I will do it again if I have some more about future revisions. 2. This is the easiest question. I would say this functionality is not only useful but necessary! 3. I am OK for a WG status. Regards, Julien ________________________________ From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Diego Caviglia Hi all,=20 during the last IETF meeting unfortunaltely there was not enough thime to present and discuss the ID in the subject, nevertheless I think (but I'm an authour) the ID satisfy a real request from the Carries community.=20 I'd like to ask you some questions=20 1. Are there any comments on the ID?=20 2. Mainly for the carriers. Do you think the ID describes an useful tool?=20 3. Should the ID moved to the WG status?=20 Of course my answer for 2 and 3 are Yes and Yes ;-)=20 Regards=20 Diego From swalker@bayuklaw.com Tue Nov 29 20:18:53 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhGcX-0002gO-Fh for ccamp-archive@megatron.ietf.org; Tue, 29 Nov 2005 20:18:53 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07197 for ; Tue, 29 Nov 2005 20:18:08 -0500 (EST) Received: from [201.12.52.6] (helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EhGwh-0005pU-TY for ccamp-archive@ietf.org; Tue, 29 Nov 2005 20:39:44 -0500 Message-ID: <000001c5f54a$b00db300$0100007f@localhost> From: "Hugo Parker" To: Subject: cheap oem soft shipping //orldwide Date: Wed, 30 Nov 2005 01:18:38 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C5F54A.B00DB300" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.2 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C5F54A.B00DB300 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable.TOP.10.NEW.TITLES.ON.SALE.NOW!.1.Office.Pro.2003.2.Adobe.Photoshop.9.0.3.Windows.XP.Pro.4.Adobe.Acrobat.7.Pro.5.Flash.MX.2004.6.Corel.Draw.12.7.Norton.Antivirus.2005.8.Windows.2003.Se ListPrice: $550.00 OurPrice: $69.95 YouSave: $480.05 ( 87%) Availability: Available for INSTANT download! Sales Rank: #1 Average Customer Review: (based on 31 reviews) -------------------------------------------------------------------------------- Microsoft Windows XP Professional by Microsoft ListPrice: $200.00 OurPrice: $49.95 YouSave: $150.05 ( 75%) Availability: Available for INSTANT download! Sales Rank: #2 Average Customer Review: (based on 50 reviews) -------------------------------------------------------------------------------- Adobe Photoshop CS2 V 9.0 by Adobe ListPrice: $599.00 OurPrice: $69.95 YouSave: $529.05 ( 88%) Availability: Available for INSTANT download! Sales Rank: #3 Average Customer Review: (based on 39 reviews) -------------------------------------------------------------------------------- ------=_NextPart_000_0001_01C5F54A.B00DB300 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Software

TOP 10 NEW TITLES

 ON SALE NOW!

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

Microsoft Office Professional Edition 2003
   by Microsoft

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



Availability: Available for INSTANT download!


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

Microsoft Windows XP Professional
   by Microsoft

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



Availability: Available for INSTANT download!


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

Adobe Photoshop CS2 V 9.0
   by Adobe

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



Availability: Available for INSTANT download!


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

------=_NextPart_000_0001_01C5F54A.B00DB300-- From owner-ccamp@ops.ietf.org Wed Nov 30 07:33:55 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhR9n-0007Hn-IJ for ccamp-archive@megatron.ietf.org; Wed, 30 Nov 2005 07:33:55 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08030 for ; Wed, 30 Nov 2005 07:33:09 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EhRTt-0000XE-Gs for ccamp-archive@ietf.org; Wed, 30 Nov 2005 07:54:53 -0500 Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EhR0X-000C5u-7y for ccamp-data@psg.com; Wed, 30 Nov 2005 12:24:21 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.0 Received: from [62.241.163.7] (helo=blaster.systems.pipex.net) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1EhR0T-000C5e-Ln for ccamp@ops.ietf.org; Wed, 30 Nov 2005 12:24:17 +0000 Received: from dnni.com (81-178-2-190.dsl.pipex.com [81.178.2.190]) by blaster.systems.pipex.net (Postfix) with ESMTP id B6BE2E000864 for ; Wed, 30 Nov 2005 12:24:09 +0000 (GMT) Received: from Puppy ([217.158.132.191] RDNS failed) by dnni.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 30 Nov 2005 12:24:07 +0000 Message-ID: <02a601c5f5a9$6e971380$d9849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: RFC 3946 bis Date: Wed, 30 Nov 2005 12:21:32 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-OriginalArrivalTime: 30 Nov 2005 12:24:08.0455 (UTC) FILETIME=[F63ED170:01C5F5A8] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Content-Transfer-Encoding: 7bit Hi, I'd like to move this along and get it complete this year. Please all review RFC 3946 to check that there are no other changes we should be making at the same time. Also please review this draft: the proposed changes are highlighted with explanatory notes from Dimitri. The next revision will remove these highlights and notes. I have already discussed with Dimitri my view that the new Note 3 in section 2.1 need minor re-wording to replace "must" with "SHOULD". Get your comments in now, and I'll plan a last call for early December. Thanks, Adrian ----- Original Message ----- From: To: Cc: Sent: Monday, November 28, 2005 8:50 PM Subject: I-D ACTION:draft-ietf-ccamp-rfc3946bis-00.txt > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. > > Title : Generalized Multi-Protocol Label Switching > (GMPLS) Extensions for Synchronous Optical > Network (SONET) and Synchronous Digital > Hierarchy (SDH) Control > Author(s) : E. Mannie, D. Papadimitriou > Filename : draft-ietf-ccamp-rfc3946bis-00.txt > Pages : 24 > Date : 2005-11-28 > > This document provides minor clarification to RFC 3946. > > This document is a companion to the Generalized Multi-Protocol > Label Switching (GMPLS) signaling. It defines the Synchronous > Optical Network (SONET)/Synchronous Digital Hierarchy (SDH) > technology specific information needed when using GMPLS signaling. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rfc3946bis-00.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > > Internet-Drafts are also available by anonymous FTP. Login with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-ccamp-rfc3946bis-00.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-ccamp-rfc3946bis-00.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > From GiselleCunningham@teragate.biz Wed Nov 30 10:33:36 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhTxg-00058E-Jl for ccamp-archive@megatron.ietf.org; Wed, 30 Nov 2005 10:33:36 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00872 for ; Wed, 30 Nov 2005 10:32:51 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EhUHt-0007CT-0g for ccamp-archive@ietf.org; Wed, 30 Nov 2005 10:54:35 -0500 Received: from [201.3.118.36] (helo=201-003-118-036.fozit7004.dsl.brasiltelecom.net.br) by mx2.foretec.com with smtp (Exim 4.24) id 1EhTwc-0001Ti-Hw for ccamp-archive@ietf.org; Wed, 30 Nov 2005 10:32:33 -0500 Received: from uqAm@localhost by k5c.int (8.11.6/8.11.6); Thu, 01 Dec 2005 00:31:20 +0500 Message-ID: <1iIMYu7oNa6AEsgk4UcGiA57f@auvitopp.com> From: "Lindsey Smart" Reply-To: "Lindsey Smart" To: ccamp-archive@ietf.org Subject: OEM software wholesale savings AutoCAD Date: Wed, 30 Nov 2005 14:29:20 -0500 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.2730.2 X-Sender: GiselleCunningham@teragate.biz Content-Type: multipart/mixed; boundary="--ZNq46AHvYfZhY2jodcnO" X-Spam-Score: 0.3 (/) X-Scan-Signature: 93b4f10b2112e1468b61e19ea6180478 2cZ ----ZNq46AHvYfZhY2jodcnO Content-Type: text/html; Content-Transfer-Encoding: quoted-printable W
Opt-in Email Special Offer   = ;  unsubscribe me
=
SEARCH

TOP 10 NEW TITLES

=
=
<= td width=3D8>10<= /tr>
<= p align=3Dcenter>  ON SALE NOW!

 = ;1 Windows XP Pro SP2
 2 Creative Suite 2
 3 MS Office 2003 Pro
 4 Adobe Acrobat 7 Pro
 5 Macromedia Flash 8
 6 Dreamweaver 8<= /font>
 7 Norton Syswor= ks 2005
 8 Ad= obe GoLive CS2
 9 Adobe Illustrator CS2
  = Borland Architect 2005
  See more by this manufacturer
  = Microsoft
   Macromedia=
   Adobe
&nbs= p; Customers also bought
   these other items...

Microsoft Windows XP Professional *w/SP2*
<= span class=3Dsmall>Microsoft=

Choose:
 

 List Price:$299.00
Price:$49.99
You = Save:$249.01 (80%)

<= a href=3Dhttp://firstsnowsoftware.com/?m>

Availability: Available for INSTANT do= wnload!
Coupon Code: XutlTL
Platform: Windows XP

Sales Rank: #1
System requirements  |  Other Versions
Date Coupon Expires: December 31st, 2005
Average Customer Review:3D"5 Based on 1118 review= s. Write a review.

Adobe Creative Suite 2 *Premium*
Adobe

Choose:
 

List Price:$1199.00
Price:$149.99
You Save:$1049.01 (95%)


Availability: Available for INSTANT download!
Coupon Code= : N1fs0u
Platform: Windows XP

Sales Rank:= #2
System requirements  |  Other Versions
Date Coupon E= xpires: December 31st, 2005
Average C= ustomer Review:3D"5 Based on 145758 reviews. Write a review.

Micros= oft Office 2003 *Professional*
Microsoft

Choose:
 

<= b>Price:
L= ist Price:$499.00
$69.99
You Save:<= /td>$429.01 (85%)



Availability: Available for INSTANT download! Coupon Code: lgG4KQDg
Platform: Windows XP

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

=

Adobe Acrobat Professional V 7.0
Adobe

Choose:
 

List Price:$499.00
Price:$69.99
You Save:<= /td>$429.01 (= 85%)

=

Availabil= ity: Available for INSTANT download!
Coupon Code: T3knUTuKj=
Platform: = Windows XP

Sales Rank: #4
System re= quirements  |  Oth= er Versions
Date Coupon Expires: = December 31st, 2005
Average Customer Revi= ew:3D"5 Based on 1948 reviews. Write a review.

<= /td>
----ZNq46AHvYfZhY2jodcnO-- From GiselleCunningham@teragate.biz Wed Nov 30 10:33:46 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhTxq-0005JZ-4G for ccamp-archive@megatron.ietf.org; Wed, 30 Nov 2005 10:33:46 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00903 for ; Wed, 30 Nov 2005 10:33:00 -0500 (EST) Received: from u153.chello.upc.cz ([62.24.86.153]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EhUHu-0007Bz-3e for ccamp-archive@ietf.org; Wed, 30 Nov 2005 10:54:45 -0500 Received: from uqAm@localhost by k5c.int (8.11.6/8.11.6); Thu, 01 Dec 2005 00:31:20 +0500 Message-ID: <1iIMYu7oNa6AEsgk4UcGiA57f@auvitopp.com> From: "Lindsey Smart" Reply-To: "Lindsey Smart" To: ccamp-archive@ietf.org Subject: OEM software wholesale savings AutoCAD Date: Wed, 30 Nov 2005 14:29:20 -0500 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.2730.2 X-Sender: GiselleCunningham@teragate.biz Content-Type: multipart/mixed; boundary="--ZNq46AHvYfZhY2jodcnO" X-Spam-Score: 3.7 (+++) X-Scan-Signature: 93b4f10b2112e1468b61e19ea6180478 2cZ ----ZNq46AHvYfZhY2jodcnO Content-Type: text/html; Content-Transfer-Encoding: quoted-printable W
Opt-in Email Special Offer   = ;  unsubscribe me
=
SEARCH

TOP 10 NEW TITLES

=
=
<= td width=3D8>10<= /tr>
<= p align=3Dcenter>  ON SALE NOW!

 = ;1 Windows XP Pro SP2
 2 Creative Suite 2
 3 MS Office 2003 Pro
 4 Adobe Acrobat 7 Pro
 5 Macromedia Flash 8
 6 Dreamweaver 8<= /font>
 7 Norton Syswor= ks 2005
 8 Ad= obe GoLive CS2
 9 Adobe Illustrator CS2
  = Borland Architect 2005
  See more by this manufacturer
  = Microsoft
   Macromedia=
   Adobe
&nbs= p; Customers also bought
   these other items...

Microsoft Windows XP Professional *w/SP2*
<= span class=3Dsmall>Microsoft=

Choose:
 

 List Price:$299.00
Price:$49.99
You = Save:$249.01 (80%)

<= a href=3Dhttp://firstsnowsoftware.com/?m>

Availability: Available for INSTANT do= wnload!
Coupon Code: XutlTL
Platform: Windows XP

Sales Rank: #1
System requirements  |  Other Versions
Date Coupon Expires: December 31st, 2005
Average Customer Review:3D"5 Based on 1118 review= s. Write a review.

Adobe Creative Suite 2 *Premium*
Adobe

Choose:
 

List Price:$1199.00
Price:$149.99
You Save:$1049.01 (95%)


Availability: Available for INSTANT download!
Coupon Code= : N1fs0u
Platform: Windows XP

Sales Rank:= #2
System requirements  |  Other Versions
Date Coupon E= xpires: December 31st, 2005
Average C= ustomer Review:3D"5 Based on 145758 reviews. Write a review.

Micros= oft Office 2003 *Professional*
Microsoft

Choose:
 

<= b>Price:
L= ist Price:$499.00
$69.99
You Save:<= /td>$429.01 (85%)



Availability: Available for INSTANT download! Coupon Code: lgG4KQDg
Platform: Windows XP

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

=

Adobe Acrobat Professional V 7.0
Adobe

Choose:
 

List Price:$499.00
Price:$69.99
You Save:<= /td>$429.01 (= 85%)

=

Availabil= ity: Available for INSTANT download!
Coupon Code: T3knUTuKj=
Platform: = Windows XP

Sales Rank: #4
System re= quirements  |  Oth= er Versions
Date Coupon Expires: = December 31st, 2005
Average Customer Revi= ew:3D"5 Based on 1948 reviews. Write a review.

<= /td>
----ZNq46AHvYfZhY2jodcnO-- From owner-ccamp@ops.ietf.org Wed Nov 30 15:55:59 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhYzf-0003xC-GC for ccamp-archive@megatron.ietf.org; Wed, 30 Nov 2005 15:55:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13361 for ; Wed, 30 Nov 2005 15:55:14 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EhZK0-0003Lc-T7 for ccamp-archive@ietf.org; Wed, 30 Nov 2005 16:17:01 -0500 Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EhYu0-000LLB-GC for ccamp-data@psg.com; Wed, 30 Nov 2005 20:50:08 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=3.1.0 Received: from [132.151.6.50] (helo=newodin.ietf.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.54 (FreeBSD)) id 1EhYtz-000LKt-Ng for ccamp@ops.ietf.org; Wed, 30 Nov 2005 20:50:07 +0000 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EhYtu-0006td-KV; Wed, 30 Nov 2005 15:50:02 -0500 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-te-node-cap-00.txt Message-Id: Date: Wed, 30 Nov 2005 15:50:02 -0500 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.4 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : Routing extensions for discovery of Traffic Engineering Node Capabilities Author(s) : J. Vasseur, J. Le Roux Filename : draft-ietf-ccamp-te-node-cap-00.txt Pages : 16 Date : 2005-11-30 It is highly desired in several cases, to take into account Traffic Engineering (TE) node capabilities during TE LSP path selection, such as for instance the capability to act as a branch LSR of a P2MP LSP. This requires advertising these capabilities within the IGP. For that purpose, this document specifies OSPF and IS-IS traffic engineering extensions for the advertisement of control plane and data plane traffic engineering node capabilities. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-te-node-cap-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ccamp-te-node-cap-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ccamp-te-node-cap-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-11-30140325.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-te-node-cap-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-te-node-cap-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-11-30140325.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 30 Nov 2005 20:50:47 +0000 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-te-node-cap-00.txt Message-Id: Date: Wed, 30 Nov 2005 15:50:02 -0500 --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 : Routing extensions for discovery of Traffic Engineering Node Capabilities Author(s) : J. Vasseur, J. Le Roux Filename : draft-ietf-ccamp-te-node-cap-00.txt Pages : 16 Date : 2005-11-30 It is highly desired in several cases, to take into account Traffic Engineering (TE) node capabilities during TE LSP path selection, such as for instance the capability to act as a branch LSR of a P2MP LSP. This requires advertising these capabilities within the IGP. For that purpose, this document specifies OSPF and IS-IS traffic engineering extensions for the advertisement of control plane and data plane traffic engineering node capabilities. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-te-node-cap-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ccamp-te-node-cap-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ccamp-te-node-cap-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-11-30140325.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-te-node-cap-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-te-node-cap-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-11-30140325.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 30 Nov 2005 12:26:16 +0000 Message-ID: <02a601c5f5a9$6e971380$d9849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: RFC 3946 bis Date: Wed, 30 Nov 2005 12:21:32 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi, I'd like to move this along and get it complete this year. Please all review RFC 3946 to check that there are no other changes we should be making at the same time. Also please review this draft: the proposed changes are highlighted with explanatory notes from Dimitri. The next revision will remove these highlights and notes. I have already discussed with Dimitri my view that the new Note 3 in section 2.1 need minor re-wording to replace "must" with "SHOULD". Get your comments in now, and I'll plan a last call for early December. Thanks, Adrian ----- Original Message ----- From: To: Cc: Sent: Monday, November 28, 2005 8:50 PM Subject: I-D ACTION:draft-ietf-ccamp-rfc3946bis-00.txt > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. > > Title : Generalized Multi-Protocol Label Switching > (GMPLS) Extensions for Synchronous Optical > Network (SONET) and Synchronous Digital > Hierarchy (SDH) Control > Author(s) : E. Mannie, D. Papadimitriou > Filename : draft-ietf-ccamp-rfc3946bis-00.txt > Pages : 24 > Date : 2005-11-28 > > This document provides minor clarification to RFC 3946. > > This document is a companion to the Generalized Multi-Protocol > Label Switching (GMPLS) signaling. It defines the Synchronous > Optical Network (SONET)/Synchronous Digital Hierarchy (SDH) > technology specific information needed when using GMPLS signaling. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rfc3946bis-00.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > > Internet-Drafts are also available by anonymous FTP. Login with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-ccamp-rfc3946bis-00.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-ccamp-rfc3946bis-00.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 29 Nov 2005 10:10:21 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Consensus to move draft-caviglia-mp2cpcp2mp-03 to WG satus Date: Tue, 29 Nov 2005 11:09:16 +0100 Message-ID: <7DBAFEC6A76F3E42817DF1EBE64CB02602C62A69@FTRDMEL2.rd.francetelecom.fr> Thread-Topic: Consensus to move draft-caviglia-mp2cpcp2mp-03 to WG satus Thread-Index: AcX0tSbz3P21U5EmRTGhp5ezeNWI3QAFt4Jw From: "MEURIC Julien RD-CORE-LAN" To: "Diego Caviglia" , Cc: "Dino Bramanti" , "Dan Li Hi Diego and all. 1. I have already sent my comments to you. I will do it again if I have some more about future revisions. 2. This is the easiest question. I would say this functionality is not only useful but necessary! 3. I am OK for a WG status. Regards, Julien ________________________________ From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Diego Caviglia Hi all,=20 during the last IETF meeting unfortunaltely there was not enough thime to present and discuss the ID in the subject, nevertheless I think (but I'm an authour) the ID satisfy a real request from the Carries community.=20 I'd like to ask you some questions=20 1. Are there any comments on the ID?=20 2. Mainly for the carriers. Do you think the ID describes an useful tool?=20 3. Should the ID moved to the WG status?=20 Of course my answer for 2 and 3 are Yes and Yes ;-)=20 Regards=20 Diego Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 29 Nov 2005 07:10:30 +0000 MIME-Version: 1.0 Sensitivity: To: ccamp@ops.ietf.org Cc: "Dino Bramanti" , "Dan Li Subject: Consensus to move draft-caviglia-mp2cpcp2mp-03 to WG satus Message-ID: From: "Diego Caviglia" Date: Tue, 29 Nov 2005 08:08:59 +0100 Content-Type: multipart/alternative; boundary="=_alternative 00274745C12570C8_=" This is a multipart message in MIME format. --=_alternative 00274745C12570C8_= Content-Type: text/plain; charset="us-ascii" Hi all, during the last IETF meeting unfortunaltely there was not enough thime to present and discuss the ID in the subject, nevertheless I think (but I'm an authour) the ID satisfy a real request from the Carries community. I'd like to ask you some questions 1. Are there any comments on the ID? 2. Mainly for the carriers. Do you think the ID describes an useful tool? 3. Should the ID moved to the WG status? Of course my answer for 2 and 3 are Yes and Yes ;-) Regards Diego --=_alternative 00274745C12570C8_= Content-Type: text/html; charset="us-ascii"
Hi all,
           during the last IETF meeting unfortunaltely there was not enough thime to present and discuss the ID in the subject, nevertheless I think (but I'm an authour) the ID satisfy a real request from the Carries community.

I'd like to ask you some questions

1.        Are there any comments on the ID?

2.        Mainly for the carriers. Do you think the ID describes an useful tool?

3.        Should the ID moved to the WG status?

Of course my answer for 2 and 3 are Yes and Yes ;-)

Regards

Diego --=_alternative 00274745C12570C8_=-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 28 Nov 2005 22:29:01 +0000 Message-ID: <438B845E.7020600@us.fujitsu.com> Date: Mon, 28 Nov 2005 14:27:42 -0800 From: Richard Rabbat Organization: Fujitsu Labs of America User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) MIME-Version: 1.0 To: ccamp@ops.ietf.org, Huub van Helvoort CC: Richard Rabbat , Diego Caviglia , Greg Bernstein Subject: next steps on diverse path vcat/lcas Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit hi all, during ietf in vancouver, we had a good discussion related to draft-bernstein-ccamp-gmpls-vcat-lcas-01.txt There were many people interested in collaborating on this work item. Can these interested people drop us a line if they want to collaborate on a revision to the draft or give feedback on the current version? we'd like to have some consensus on what extra features are needed and work on the solutions Thanks, Richard. Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 28 Nov 2005 20:51:45 +0000 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-automesh-00.txt Message-Id: Date: Mon, 28 Nov 2005 15:50:02 -0500 --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 : Routing extensions for discovery of Multiprotocol (MPLS) Label Switch Router (LSR) Traffic Engineering (TE) mesh membership Author(s) : J. Vasseur, J. Le Roux Filename : draft-ietf-ccamp-automesh-00.txt Pages : 10 Date : 2005-11-28 The set up of a full mesh of MPLS TE LSPs among a set of Label Switch Router (LSR) is common deployment scenario of MPLS Traffic Engineering either for bandwidth optimization, bandwidth guarantees or fast rerouting with MPLS Fast Reroute. Such deployment requires the configuration of potentially a large number of TE LSPs (on the order of the square of the number LSRs). This document specifies IGP (OSPF and IS-IS) traffic engineering extensions so as to provide an automatic discovery of the set of LSRs members of a mesh, leading to an automatic mechanism to set up TE LSP mesh(es) (also referred to as a mesh-group in this document). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-automesh-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ccamp-automesh-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ccamp-automesh-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-11-28130050.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-automesh-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-automesh-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-11-28130050.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 28 Nov 2005 20:51:37 +0000 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-rfc3946bis-00.txt Message-Id: Date: Mon, 28 Nov 2005 15:50:02 -0500 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : Generalized Multi-Protocol Label Switching (GMPLS) Extensions for Synchronous Optical Network (SONET) and Synchronous Digital Hierarchy (SDH) Control Author(s) : E. Mannie, D. Papadimitriou Filename : draft-ietf-ccamp-rfc3946bis-00.txt Pages : 24 Date : 2005-11-28 This document provides minor clarification to RFC 3946. This document is a companion to the Generalized Multi-Protocol Label Switching (GMPLS) signaling. It defines the Synchronous Optical Network (SONET)/Synchronous Digital Hierarchy (SDH) technology specific information needed when using GMPLS signaling. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rfc3946bis-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ccamp-rfc3946bis-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ccamp-rfc3946bis-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-11-28122727.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-rfc3946bis-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-rfc3946bis-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-11-28122727.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 25 Nov 2005 14:53:01 +0000 Mime-Version: 1.0 (Apple Message framework v734) To: ccamp@ops.ietf.org, mpls@ietf.org, idr@ietf.org, Mailing List , isis-wg@ietf.org, pce@ietf.org Message-Id: <43CEE596-A350-4883-A85E-A889F5DC4FEC@cisco.com> Content-Type: multipart/alternative; boundary=Apple-Mail-17-4186124 Cc: LE ROUX Jean-Louis RD-CORE-LAN , "raymond.zhang" , "Bert (Bert) Wijnen" , "David Kessens (E-mail)" , Alex Zinin , Bill Fenner Subject: Discussion on Multi-technology protection/restoration schemes From: JP Vasseur Date: Fri, 25 Nov 2005 09:50:08 -0500 --Apple-Mail-17-4186124 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Dear WGs, Raymond Zhang, Jean-Louis Le Roux and myself have been discussing for a while about the idea of the formation of a new Working Group at the IETF (under the OPS area) in order to discuss operational issues related to the use of multi-technologies in the context of protection/ restoration. This was motivated by a number of discussions that we had with Service Providers expressing some interest in this topic. For the sake of illustration, (1) How to use Fast IGP in conjunction with MPLS TE FRR ? (2) How to use Graceful Restart with Fast IGP or IPFRR ? (3) Multi-technology protection/restoration OAM - ... Indeed, there are many cases where such protection/restoration/HA technologies may interact thus triggering potential race conditions if not used appropriately. The aim of such potential Working Group would be to discuss these issues, document deployment models, ... and potentially come up with problem statements leading to new protocol requirements. Note that the goal of such WG would NOT be to work on protocol extensions but to analyze the problems statements, document combination strategies, ... Protocol extensions would be worked out in other WGs (likely in Routing area). We had a first informal meeting in Vancouver with: Bruno Decraene (FT), Eiji Oki (NTT), Yuichi Ikejiri (NTT), Kenji Kumaki (KDDI), Javier Achirica (Telefonica), Deborah Brungard (ATT), Jaime Miles (Level 3) and Alberto Tempia (Telecom Italia), Jean-Louis and myself. In this meeting, we got positive feed-back on the usefulness of this work. In the meantime we also received positive feed-back from a number of other Service Providers. A short ID should be posted soon proposing a problem statement. The OPS Area Directors (Bert and David) gave us the approval to create a mailing list to see whether this topic is of interest to the IETF community in which case a BOF may be approved for the next IETF. If you are interested, please join the mailing list and contribute to this work. mter@ietf.org: https://www1.ietf.org/mailman/listinfo/mter Thanks. JP, Jean-Louis and Raymond. --Apple-Mail-17-4186124 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1
Dear WGs,

Raymond = Zhang, Jean-Louis Le Roux and myself have been discussing for a while = about the idea of the formation of a new Working Group at the IETF = (under the OPS area) in order to discuss operational issues related to = the use of multi-technologies in the context of protection/restoration. = This was motivated by a number of discussions that we had with Service = Providers expressing some interest in this topic.=A0

For the sake = of illustration,
=A0 =A0 (1)=A0How to use Fast = IGP in conjunction with MPLS TE FRR ?
=A0 =A0 = (2)=A0How to use Graceful Restart with Fast IGP or IPFRR ?
=A0=A0=A0 (3)=A0Multi-technology = protection/restoration OAM=A0
=A0=A0 =A0 - = ...

Indeed, = there are many cases where such protection/restoration/HA technologies = may interact thus triggering potential race conditions if not used = appropriately.=A0

The aim of such potential Working Group would = be to discuss these issues, document deployment models, ... and = potentially come up with problem statements leading to new protocol = requirements. Note that the goal of such WG would NOT be to work on = protocol extensions but to analyze the problems statements, document = combination strategies, ... Protocol extensions would be worked out = in other WGs (likely in Routing area).

We had a = first informal meeting in Vancouver with: Bruno Decraene (FT), Eiji Oki = (NTT), Yuichi Ikejiri (NTT), Kenji Kumaki (KDDI), Javier Achirica = (Telefonica), Deborah Brungard (ATT), Jaime Miles (Level 3) and Alberto = Tempia (Telecom Italia), Jean-Louis and myself. In this meeting, we got = positive feed-back on the usefulness of this work.=A0

In the = meantime we also received positive feed-back from a number of other = Service Providers.

A short = ID should be posted soon proposing a problem statement.

The OPS Area = Directors (Bert and David) gave us the approval to create a mailing list = to see whether this topic is of interest to the IETF community in which = case a BOF may be approved for the next IETF. If you are interested, = please join the mailing list and contribute to this work.
=A0=A0=A0 mter@ietf.org:=A0<= A href=3D"https://www1.ietf.org/mailman/listinfo/mter">https://www1.ietf.org/mailman/listinfo/mter


JP, = Jean-Louis and Raymond.
= --Apple-Mail-17-4186124-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 23 Nov 2005 22:33:53 +0000 Message-ID: <07d101c5f078$883602f0$fb849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Cc: , "Bill Fenner" Subject: Implementations for draft-ietf-ccamp-gmpls-segment-recovery and draft-ietf-ccamp-gmpls-recovery-e2e-signaling Date: Wed, 23 Nov 2005 21:52:19 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi, I have been discussing the progress of these two I-Ds with the ADs. In order to complete the next step, we need to demonstrate "sufficient" implementation. Here is the edited-down thread on the e2e recovery drafts. You'll see that for most points I know of implementations and some interop work. However, for some features I do not know of implementations. If you do, it would really help if you spoke up now (in private to me is fine). Failing evidence of implementation for these points we must: a. remove the feature from the I-D b. put the whole I-D on hold until implementation c. convince the ADs that the feature is so small and obvious as to not require implementation at this point. I haven't embarked on a similar thread for segment recovery because it seems like we should establish how we will proceed first. Your comments and suggestions are very welcome. Adrian > >> draft-ietf-ccamp-gmpls-recovery-e2e-signaling > >> > >> What we need at this point is that all features in the doc have > >> been implemented and whether the implementations are known > >> to interop. > > > > I know of three implementations of e2e recovery. > > > > The main components of this work are: > > a. Convey recovery attributes in PROTECTION Object > > Implemented by 1, 2 and 3 > > Interop between 1 and 2 > > b. LSP association through ASSOCIATION Object > > Implemented by 1, 2 and 3 > > Interop between 1 and 2 > > c. Indicate primary path through PRIMARY_PATH Object > > Implemented by 1, 2 and 3 > > Interop between 1 and 2 > > d. Different protection types > > This is not signaling function, but is data plane operation > > under control of control plane options in component a. > > - 1+1 unidirectional protection > > No implementation known > > - 1+1 bidirectional protection > > Implemented by 3 > > - 1:1 protection with extra traffic > > Implemented by 1, 2 and 3 > > Interop between 1 and 2 > > - Rerouting with extra traffic > > Implemented by 3 > > - Shared mesh restoration > > No implementation known > > What do you suggest we do with features that haven't been implemented? > > > e. Preemption support > > Implemented by 1, 2 and 3 > > Interop between 1 and 2 > > f. Full re-routing > > Implemented by most MPLS-TE and GMPLS systems without > > the ASSOCIATION object. Interop seen daily. > > Implemented by 1, 2 and 3 with the ASSOCIATION object. > > Interop between 1 and 2 > > g. Reversion > > No implementation status known, but this is largely a > > management function. > > Well, I see protocol procedures defined. > > > h. Recovery commands > > No implementation status known, but this is entirely a > > management function. > > ditto here. Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 22 Nov 2005 16:16:17 +0000 Message-ID: <005f01c5ef7f$df838270$7a1810ac@movaz.com> From: "Igor Bryskin" To: "JP Vasseur" Cc: , , "Adrian Farrel" , "LE ROUX Jean-Louis RD-CORE-LAN" , Subject: Re: IGP Extensions - CCAMP Milestones Date: Tue, 22 Nov 2005 11:14:52 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit JP, Thanks for the suggestion. I did some research on OSPF. Here are my conclusions: 1. LSAs type 5 (AS-external-LSAs) are the only LSAs that are flooded across AS (so I was wrong saying that there are no precedents of AS-scope flooding); 2. However, LSAs type 5 are never used alone, rather, they are used in conjunction with LSAs type 4 (ASBR-summary-LSAs), which advertise location of ASBRs from area to area and have area scope. LSAs type 4 serve two purposes: a) they provide the cost of paths from advertising ABRs to ASBRs; b) they help validate LSAs type 5: when an ASBR crashes, ABRs co-located with the ASBR within the same area withdraw the LSAs type 4 and, thus, invalidate associated LSAs type 5. The conclusion is that if one uses AS scope LSAs one must rely on some additional mechanism (internal or external) to validate the LSAs ( which is BTW not necessary if one uses the area scope advertising). Thus, if AS scope node capabilities LSAs are used for advertising PCE capabilities one should use something like KEEP ALIVE PCC-PCE protocol, while if they advertise some other capabilities (like mesh membership) one should use some other (TBD for the case of mesh membership) mechanism. At very least, this should be spelled out in the draft. Igor ----- Original Message ----- From: "JP Vasseur" To: "Igor Bryskin" Cc: ; ; "Adrian Farrel" ; "LE ROUX Jean-Louis RD-CORE-LAN" ; Sent: Monday, November 21, 2005 12:26 PM Subject: Re: IGP Extensions - CCAMP Milestones Hi Igor, On Nov 21, 2005, at 12:19 PM, Igor Bryskin wrote: > JP, > > Could you give me an example of application that uses AS scope > opaque LSAs? > I'll be happy to spend time with you next time we meet to help you understand how to use Opaque LSA Type 11, but do not have enough bandwidth as of now ... If you need help on the OSPF front, you may want to poll the OSPF WG. JP. > Thanks, > Igor > > > ----- Original Message ----- > From: "JP Vasseur" > To: "Igor Bryskin" > Cc: ; ; > "Adrian > Farrel" ; "LE ROUX Jean-Louis RD-CORE-LAN" > ; > Sent: Monday, November 21, 2005 11:36 AM > Subject: Re: IGP Extensions - CCAMP Milestones > > > Hi Igor, > > On Nov 21, 2005, at 10:13 AM, Igor Bryskin wrote: > > >> Hi JP, >> >> >> >> See in-line. >> >> >> >> Cheers, >> >> Igor >> >> >> >> ----- Original Message ----- >> >> From: "JP Vasseur" >> >> To: "Igor Bryskin" >> >> Cc: ; ; >> "Adrian >> Farrel" ; "LE ROUX Jean-Louis RD-CORE-LAN" >> ; >> >> Sent: Sunday, November 20, 2005 9:57 AM >> >> Subject: Re: IGP Extensions - CCAMP Milestones >> >> >> >> Hi Igor, >> >> On Nov 19, 2005, at 11:16 AM, Igor Bryskin wrote: >> >> >> >>> Hi everybody, >>> >>> >>> >>> I'd like to note that although the AS scope flooding is allowed for >>> opaque >>> LSAs, in my experience it does not work. >>> >>> >> >> So your experience is different than the one of many people ... >> Opaque LSA have been >> used for quite a few years without any problem. See RFC2370 (July >> 1998) >> >> >> >>> Imagine that some routing >>> controller advertises an AS scope LSA and goes out of service >>> quickly after >>> that. Controllers outside of the area that the dead controller >>> belongs to >>> have no way of detecting its death and, therefore, will keep using >>> the >>> advertising for another 90 min before the LSA times out. >>> >>> >> >> I guess that you mean 60 min (Maxage=60mn, Architectural Constant) - >> See RFC2328, but this is not the point, see below. >> >> >> >>> Note that the >>> controllers located within the same area do not have such a problem >>> because >>> they can always verify the validity of the advertising by trying to >>> locate a >>> sequence of active adjacencies interconnecting each of them with the >>> advertising controller. If they find at least one such a sequence, >>> the >>> advertising is valid (otherwise, it would be withdrawn); on the >>> other hand, >>> if no such sequences exist, than advertising is likely to be stale >>> and hence >>> could not be trusted. The conclusion is that opaque LSAs should >>> never be >>> flooded within AS, rather, within a single area, and, if there is a >>> need for >>> the information to be propagated beyond the area boundaries, ABRs >>> must relay >>> the advertising into other areas (by originating new area-scope >>> LSAs). Note >>> also that as far as I remember OSPF itself never uses AS scope >>> advertisings >>> for its own needs. For example, an ASBR does not distribute >>> external routes >>> learned by BGP from other ASs using AS scope LSAs, rather, the >>> routes are >>> advertised within a single area and ABRs relay the advertisings >>> into other >>> areas. >>> >>> >> >> This is not correct. External routes are redistributed with LSA Type >> 5 which are >> flooded across the entire domain except in stub-area (not >> generated by >> the ABR as type 3 as you mention). >> >> >> >> IB>> True, that what is written in RFC2328. >> > > well not just written in the RFC but implemented and deployed in OSPF > networks for years. > > >> And my contention here is that >> if an ASBR advertises LSAs type 5 and dies after that, than OSPF >> speakers >> outside of the ASBR's area have good likelihood to use stale >> external routes >> for a considerable period of time. There is no remedy to that (OSPF >> speakers >> do not use Keep Alive protocol :=). This, however, could be fixed by >> avoiding using of AS scope flooding, and that's exactly the reason >> why some >> OSPF applications that I know of do just that. But this is the >> discussion >> for OSPF WG, I suggest not argue about that. See below. >> >> > > There is nothing to fix here. Anyway, see below ... > > >> Anyway, back to the point, one cannot say of course that "Opaque LSA >> Type 11 does not work". There are suitable to some application, >> this is >> all. You can perfectly reply on an opaque LSA Type 11 to learn the >> capability of a router which does not reside in the local area and >> rely >> on another mechanism to detect its liveness. There are several such >> examples. >> >> >> >> IB>> Let's stick to your example. Why is it better to flood router >> capability LSAs across an AS, rather than flood them within a >> single area >> and have ABRs relay the advertisings into other areas by >> originating their >> own LSAs? Yes, the AS-scope flooding is simpler. >> But what I am suggesting >> has the following advantages: >> >> a) Advertisings of a crashed LSR could be withdrawn from use >> by all AS >> LSRs immediately after the crash; >> >> b) Advertisings could be summarized by an ABR providing >> scalability >> improvements; >> >> > > OSPF provides an efficient way to flood information across the entire > routing domain: opaque LSA Type 11. If the use of such LSA is useful > to some applications why not using it ? > > You highlight two aspects here > - Liveness of the capability advertising router: just rely on a > liveness protocol if you need to quickly detect a crash of the router > - Scalability improvement: this is in fact the opposite ... Think of > the extra work required on the ABR to leak TLV in other areas > compared to flood a Type 11 LSA. Apparently you do not appreciate the > architectural change that this would mean on OSPF. > > >> c) What is more important that policies could be applied on >> ABRs wrt to >> what information is leaked to external areas. Regretfully, you keep >> forgetting about the policy aspects, but in the context of AS-scope >> flooding >> how can you enforce that an LSR capabilities are advertised into >> some areas, >> not advertised into some other areas, and advertised in a modified >> way into >> the third set of areas? >> > > Policy is of the utmost importance in many contexts such as Inter-AS/ > Providers ... not sure the case of inter-area within a single AS is > the case. Now, if you want to propose a new mode of operation for > OSPF, you may want to discuss it with the OSPF WG ... We could > continue the discussion there ... since it belongs to OSPF. > > JP. > > >> >> >> >> Igor >> >> Hope this helps. >> >> JP. >> >> >> >> >>> >>> >>> >>> The bottom line is that the TLVs described in the draft should be >>> of the >>> area scope (just like TE LSAs), and hence it is not all that >>> important >>> whether we use new high level TLVs or sub-TLVs of the TE router cap >>> TLV. >>> >>> >>> >>> Igor >>> >>> >>> >>> >>> >>> ----- Original Message ----- >>> >>> From: "dimitri papadimitriou" >>> >>> To: "Adrian Farrel" >>> >>> Cc: "LE ROUX Jean-Louis RD-CORE-LAN" >>> ; >>> "JP Vasseur" ; "Dimitri Papadimitriou" >>> ; >>> >>> Sent: Friday, November 18, 2005 10:57 AM >>> >>> Subject: Re: IGP Extensions - CCAMP Milestones >>> >>> >>> >>> >>> >>> >>>> adrian >>>> >>>> i think JL's reply did partially translate the initial concern >>>> >>>> in brief, there are three well identified TE applications that >>>> could >>>> make use of the TE node cap TLVs on both intra and inter-area >>>> basis: >>>> - LSP Stitching edge node capability >>>> - Edge nodes connecting/being P2MP TE egresses >>>> - TE auto-mesh >>>> >>>> hence, the question on why keeping separated TLVs as part of the >>>> router >>>> capability and not consider these as sub-TLVs of the TE router cap >>>> TLV >>>> this would >>>> 1) provide a logical grouping of TE sub-TLVs as part of the same >>>> TLV and >>>> 2) leave the flexibility of flooding scope on a per application >>>> need - >>>> >>>> note: that the path computation specific sub-TLVs could still be >>>> restricted with their current area-scope >>>> >>>> hope this clarifies the issue, >>>> >>>> thanks, >>>> - dimitri. >>>> >>>> Adrian Farrel wrote: >>>> >>>> >>>> >>>> >>>>> If I understand the question it is... >>>>> >>>>> In draft-ietf-ospf-cap-07.txt introduces the OSPF router >>>>> information LSA >>>>> and states that this LSA may have type 9, 10 or 11 scope. >>>>> >>>>> In draft-vasseur-ccamp-te-node-cap-01.txt a new TLV (TE Node >>>>> Capability >>>>> Descriptor) is added to the OSPF router information LSA. This TLV >>>>> (when >>>>> generated) MUST be advertised with type 10 scope. JL has given the >>>>> >>>>> >>>>> >>> reason >>> >>> >>> >>>>> why this is limited to type 10. This reason is, of course, open >>>>> for >>>>> discussion as he says. >>>>> >>>>> In draft-vasseur-ccamp-automesh-02.txt a new TLV (TE-MESH- >>>>> GROUP) is >>>>> >>>>> >>>>> >>> added >>> >>> >>> >>>>> to the OSPF router information LSA. It states that the LSA may be >>>>> advertised with type 10 or type 11 scope. JP has given a reason >>>>> why you >>>>> might want type 11 in addition to type 10. This reason is, of >>>>> course, >>>>> >>>>> >>>>> >>> open >>> >>> >>> >>>>> for discussion. >>>>> >>>>> An interesting feature is that a router advertising an AS-wide >>>>> mesh >>>>> >>>>> >>>>> >>> group >>> >>> >>> >>>>> *and* a TE router capability may require that two OSPF router >>>>> >>>>> >>>>> >>> information >>> >>> >>> >>>>> LSAs are advertised by the router. >>>>> >>>>> The language in draft-ietf-ospf-cap-07.txt leans towards a router >>>>> >>>>> >>>>> >>> sending >>> >>> >>> >>>>> *an* OSPF router information LSA. But nowhere does it say that the >>>>> >>>>> >>>>> >>> router >>> >>> >>> >>>>> cannot send more than one and in section 2.5 we find... >>>>> The originating router MAY advertise >>>>> multiple RI LSAs as long as the flooding scopes differ. >>>>> >>>>> Hope this answers the point. >>>>> >>>>> Adrian >>>>> ----- Original Message ----- >>>>> From: "LE ROUX Jean-Louis RD-CORE-LAN" >>>>> >>>>> To: "JP Vasseur" ; "Dimitri Papadimitriou" >>>>> ; "Dimitri Papadimitriou" >>>>> >>>>> Cc: ; >>>>> Sent: Thursday, November 17, 2005 6:47 PM >>>>> Subject: RE: IGP Extensions - CCAMP Milestones >>>>> >>>>> >>>>> Hi Dimitri, >>>>> >>>>> Thanks for the comment. >>>>> >>>>> As just explained by JP, the TE Node Cap TLV carries topology >>>>> related >>>>> parameters used as constraints in path computation. The leaking >>>>> of such >>>>> info across areas sounds useless as LSR TE visibility is limited >>>>> to one >>>>> area anyway... >>>>> But this is, of course, open to discussions. By the way, do you >>>>> have any >>>>> application in mind where such leaking would be useful? >>>>> >>>>> Regards, >>>>> >>>>> JL >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>> -----Message d'origine----- >>>>>> De : JP Vasseur [mailto:jvasseur@cisco.com] >>>>>> Envoyé : jeudi 17 novembre 2005 16:58 >>>>>> À : Dimitri Papadimitriou; Dimitri Papadimitriou >>>>>> Cc : zzx-adrian@olddog.co.uk; ccamp@ops.ietf.org; LE ROUX >>>>>> Jean-Louis RD-CORE-LAN >>>>>> Objet : Re: IGP Extensions - CCAMP Milestones >>>>>> >>>>>> Hi dimitri, >>>>>> >>>>>> On Nov 16, 2005, at 6:30 PM, dimitri papadimitriou wrote: >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> adrian, >>>>>>> >>>>>>> could you explain the reasoning for having a TE specific TLV in >>>>>>> the >>>>>>> auto-mesh document with area and AS-wide flooding scope >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> while the TE >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> router cap TLV is restricted to an area flooding scope ? >>>>>>> shouldn't be one way or the other i.e. either restrict all TE >>>>>>> info >>>>>>> area-local or allow for TE router cap TLV with AS-wide >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> flooding scope >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> ? >>>>>>> >>>>>>> note: there is nothing in the TE router cap TLV that would >>>>>>> impact >>>>>>> scaling more than the TE auto-mesh TLV does >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> I guess that the reason for allowing both intra and inter-area >>>>>> flooding scopes for automesh is obvious (we need to have TE LSP >>>>>> mesh >>>>>> within areas and spanning multiple areas). >>>>>> >>>>>> So your question is probably why don't we allow the TE router >>>>>> cap TLV >>>>>> to be flooded across the domain ? As far as I can remember JL >>>>>> already >>>>>> answered this question ... JL, could you forward your email >>>>>> again ? >>>>>> >>>>>> In the meantime, I can answer it: the reason is that such TE node >>>>>> capabilities are used for TE LSP computation which cannot take >>>>>> into >>>>>> account nodes that do not reside in the node's area. >>>>>> >>>>>> Thanks. >>>>>> >>>>>> JP. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> thanks, >>>>>>> - dimitri. >>>>>>> >>>>>>> Adrian Farrel wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Hi, >>>>>>>> We have two immediate milestones to address: >>>>>>>> Oct 05 First version WG I-D for Advertising TE Node >>>>>>>> Capabilities >>>>>>>> in ISIS >>>>>>>> and OSPF >>>>>>>> Oct 05 First version WG I-D for Automatic discovery of >>>>>>>> >>>>>>>> >>>>>>>> >>>>>> >>>>>> MPLS-TE mesh >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>> membership >>>>>>>> There are two personal submissions which address these topics: >>>>>>>> draft-vasseur-ccamp-te-node-cap-01.txt >>>>>>>> draft-vasseur-ccamp-automesh-02.txt >>>>>>>> I propose that we move these into the WG and then kick the >>>>>>>> tires >>>>>>>> thoroughly. >>>>>>>> Opinions please. >>>>>>>> Thanks, >>>>>>>> Adrian >>>>>>>> . >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>> >>>>> >>>>> >>>>> >>>>> . >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>> >>> >> > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 22 Nov 2005 12:55:08 +0000 Message-ID: <03d801c5ef63$331c9880$fb849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: New WG drafts [Was: IGP Extensions - CCAMP Milestones] Date: Tue, 22 Nov 2005 12:40:36 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Authors: Please submit draft-vasseur-ccamp-te-node-cap-01.txt and draft-vasseur-ccamp-automesh-02.txt as draft-ietf-ccamp-te-node-cap-00.txt and draft-ietf-ccamp-automesh-00.txt with *no* changes except for document name and date. Once you have submitted, please make sure that you answer and reach agreement on the issues raised about these I-Ds on the list. Thanks, Adrian ----- Original Message ----- From: "Adrian Farrel" To: Sent: Wednesday, November 16, 2005 9:14 PM Subject: IGP Extensions - CCAMP Milestones > Hi, > > We have two immediate milestones to address: > > Oct 05 First version WG I-D for Advertising TE Node Capabilities in ISIS > and OSPF > Oct 05 First version WG I-D for Automatic discovery of MPLS-TE mesh > membership > > There are two personal submissions which address these topics: > draft-vasseur-ccamp-te-node-cap-01.txt > draft-vasseur-ccamp-automesh-02.txt > > I propose that we move these into the WG and then kick the tires > thoroughly. > > Opinions please. > > Thanks, > Adrian > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 22 Nov 2005 09:09:52 +0000 Date: Tue, 22 Nov 2005 17:01:31 +0800 From: Mr Xu Subject: Re: IGP Extensions - CCAMP Milestones To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be, Igor Bryskin Cc: dimitri.papadimitriou@alcatel.be, JP Vasseur , Adrian Farrel , LE ROUX Jean-Louis RD-CORE-LAN , ccamp@ops.ietf.org Message-id: <006401c5ef43$54c28a50$d24c460a@china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: base64 SSB0aGluayBkaXN0cmlidXRpbmcgb3BhcXVlIExTQXMgZm9yIFRFIHJvdXRlciBjYXAgYWNyb3Nz IE9TUEYgZG9tYWluIGlzIG5vdCBhIGdvb2QgaWRlYSwgYmVjYXVzZSB0aGlzIGluZm9ybWF0aW9u IGlzIGNvbmNyZXRlIGFuZCBjYW4gbm90IGFnZ3JlZ2F0ZWQsIGl0IHdpbGwgY2F1c2UgdG9vIG11 Y2ggZmxvb2RpbmcgaW4gYW4gQVMuIA0KDQoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioN ClRoaXMgZS1tYWlsIGFuZCBpdHMgYXR0YWNobWVudHMgY29udGFpbiBjb25maWRlbnRpYWwgaW5m b3JtYXRpb24gZnJvbSBIVUFXRUksIHdoaWNoIGlzIGludGVuZGVkIG9ubHkgZm9yIHRoZSBwZXJz b24gb3IgZW50aXR5IHdob3NlIGFkZHJlc3MgaXMgbGlzdGVkIGFib3ZlLiBBbnkgdXNlIG9mIHRo ZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaGVyZWluIGluIGFueSB3YXkgKGluY2x1ZGluZywgYnV0 IG5vdCBsaW1pdGVkIHRvLCB0b3RhbCBvciBwYXJ0aWFsIGRpc2Nsb3N1cmUsIHJlcHJvZHVjdGlv biwgb3IgZGlzc2VtaW5hdGlvbikgYnkgcGVyc29ucyBvdGhlciB0aGFuIHRoZSBpbnRlbmRlZCBy ZWNpcGllbnQocykgaXMgcHJvaGliaXRlZC4gSWYgeW91IHJlY2VpdmUgdGhpcyBlLW1haWwgaW4g ZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBieSBwaG9uZSBvciBlbWFpbCBpbW1lZGlh dGVseSBhbmQgZGVsZXRlIGl0IQ0KKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqDQoNCi0t LS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0gDQpGcm9tOiAiZGltaXRyaSBwYXBhZGltaXRyaW91 IiA8ZHBhcGFkaW1pdHJpb3VAcHNnLmNvbT4NClRvOiAiSWdvciBCcnlza2luIiA8aWJyeXNraW5A bW92YXouY29tPg0KQ2M6IDxkaW1pdHJpLnBhcGFkaW1pdHJpb3VAYWxjYXRlbC5iZT47ICJKUCBW YXNzZXVyIiA8anZhc3NldXJAY2lzY28uY29tPjsgIkFkcmlhbiBGYXJyZWwiIDxhZHJpYW5Ab2xk ZG9nLmNvLnVrPjsgIkxFIFJPVVggSmVhbi1Mb3VpcyBSRC1DT1JFLUxBTiIgPGplYW5sb3Vpcy5s ZXJvdXhAZnJhbmNldGVsZWNvbS5jb20+OyA8Y2NhbXBAb3BzLmlldGYub3JnPg0KU2VudDogVHVl c2RheSwgTm92ZW1iZXIgMjIsIDIwMDUgNzoxOSBBTQ0KU3ViamVjdDogUmU6IElHUCBFeHRlbnNp b25zIC0gQ0NBTVAgTWlsZXN0b25lcw0KDQoNCj4gaWdvcg0KPiANCj4gSWdvciBCcnlza2luIHdy b3RlOg0KPiANCj4gPiBEaW1pdHJpLA0KPiA+IA0KPiA+IFNlZSBteSByZXBseSB0byBKUC4gQWxz byBzZWUgYmVsb3cuDQo+ID4gDQo+ID4gLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSANCj4g PiBGcm9tOiAiZGltaXRyaSBwYXBhZGltaXRyaW91IiA8ZHBhcGFkaW1pdHJpb3VAcHNnLmNvbT4N Cj4gPiBUbzogIkpQIFZhc3NldXIiIDxqdmFzc2V1ckBjaXNjby5jb20+DQo+ID4gQ2M6ICJJZ29y IEJyeXNraW4iIDxpYnJ5c2tpbkBtb3Zhei5jb20+OyA8ZGltaXRyaS5wYXBhZGltaXRyaW91QGFs Y2F0ZWwuYmU+Ow0KPiA+ICJBZHJpYW4gRmFycmVsIiA8YWRyaWFuQG9sZGRvZy5jby51az47ICJM RSBST1VYIEplYW4tTG91aXMgUkQtQ09SRS1MQU4iDQo+ID4gPGplYW5sb3Vpcy5sZXJvdXhAZnJh bmNldGVsZWNvbS5jb20+OyA8Y2NhbXBAb3BzLmlldGYub3JnPg0KPiA+IFNlbnQ6IFN1bmRheSwg Tm92ZW1iZXIgMjAsIDIwMDUgMjo0MCBQTQ0KPiA+IFN1YmplY3Q6IFJlOiBJR1AgRXh0ZW5zaW9u cyAtIENDQU1QIE1pbGVzdG9uZXMNCj4gPiANCj4gPiANCj4gPiANCj4gPj5oaSBqcCwNCj4gPj4N Cj4gPj5pbmRlZWQsIGkgZG9uJ3QgcmVhbGx5IHVuZGVyc3RhbmQgdGhlIGlzc3VlIGJyb3VnaHQg dXAgYnkgaWdvcjsNCj4gPj4NCj4gPj5pbiB0aGUgcHJlc2VudCBjYXNlLCBvbmUgc2hvdWxkIGFs c28gdW5kZXJsaW5lIHRoYXQsIHRoZSBpbmZvcm1hdGlvbg0KPiA+PmRpc3RyaWJ1dGVkIGFjcm9z cyB0aGUgT1NQRiBkb21haW4gdXNpbmcgb3BhcXVlIExTQXMsIGlzICppbmRpcmVjdGx5Kg0KPiA+ PnVzZWQgYnkgZS5nLiBURSBhcHBsaWNhdGlvbnMgKG5vdGU6IFJGQzIzNzAgYWxsb3dzIGZvciB0 aGlzIGluZm9ybWF0aW9uDQo+ID4+dG8gYmUgdXNlZCBkaXJlY3RseSBieSBPU1BGIGJ1dCBpIHRo aW5rIHdlJ3JlIG5vdCBkaXNjdXNzaW5nIHRoaXMNCj4gPj5hbHRlcm5hdGl2ZSkNCj4gPj4NCj4g Pj50aGlzIG1lYW5zIHRoYXQgdGhlc2UgZS5nLiBURSBhcHBsaWNhdGlvbnMgY2FuIGluIGNhc2Ug b2YgY29udHJvbCBlbmdpbmUNCj4gPj5mYWlsdXJlIGRldGVjdCB0aGlzIGZhaWx1cmUgYW5kIHRy aWdnZXIgYW55IG5lY2Vzc2FyeSBhY3Rpb24gaW4gb3JkZXIgdG8NCj4gPj5hdm9pZCB0aGUgYmVo YXZpb3VyIGRlc2NyaWJlZCBieSBpZ29yDQo+ID4gDQo+ID4gDQo+ID4gSUI+PiBUd28gcG9pbnRz IGhlcmU6DQo+ID4gDQo+ID4gYSkgYWxsIFRFIExTQXMgYXJlIG9mIHRoZSBhcmVhIHNjb3BlOw0K PiANCj4geW91IGFyZSBjb25mdXNpbmcgVEUgTFNBcyAob3BhcXVlIHR5cGUgMSwgYXJlYS1zY29w ZSkgYXBwbGljYWJpbGl0eSB3aXRoIA0KPiB0aGUgYnJvYWRlciBjb250ZXh0IG9mIGUuZy4gVEUg YXBwbGljYXRpb25zIChzZWUgaW5pdGlhbCBzdGF0ZW1lbnQpIHRoYXQgDQo+IGNhbiBtYWtlIHVz ZSBvZiBSSSBMU0FzIGZvciBpbnN0Lg0KPiANCj4gPiBiKSBBIFRFIGFwcGxpY2F0aW9uIGNhbiBk ZXRlY3QgYSBjb250cm9sIGVuZ2luZSBmYWlsdXJlIG9ubHkgd2l0aGluIG9uZQ0KPiA+IGFyZWEu IA0KPiANCj4gdGhpcyBpcyBub3QgY29ycmVjdCwgYXMgYnkgZGVmaW5pdGlvbiwgYXBwbGljYXRp b24gZGVwZW5kZW50Ow0KPiANCj4gdGhhbmtzLA0KPiAtIGRpbWl0cmkuDQo+IA0KPiA+IEl0IGRv ZXMgbm90IGhlbHAgZm9yIExTUnMgbG9jYXRlZCBvdXRzaWRlIG9mIHRoaXMgYXJlYSBiZWNhdXNl IG5vIExTUg0KPiA+IChpbmNsdWRpbmcgQUJSKSBpcyBhbGxvd2VkIHRvIHdpdGhkcmF3IHNvbWVi b2R5IGVsc2UncyBMU0FzIC0gdGhlIExTQXMgY291bGQNCj4gPiBiZSB3aXRoZHJhd24gb3IgbW9k aWZpZWQgYnkgdGhlIExTUiB0aGF0IGhhcyBvcmlnaW5hdGVkIHRoZW0uDQo+ID4gIA0KPiA+IEln b3INCj4gPiANCj4gPiANCj4gPj50aGFua3MsDQo+ID4+LSBkaW1pdHJpLg0KPiA+Pg0KPiA+PkpQ IFZhc3NldXIgd3JvdGU6DQo+ID4+DQo+ID4+PkhpIElnb3IsDQo+ID4+Pg0KPiA+Pj5PbiBOb3Yg MTksIDIwMDUsIGF0IDExOjE2IEFNLCBJZ29yIEJyeXNraW4gd3JvdGU6DQo+ID4+Pg0KPiA+Pj4N Cj4gPj4+PkhpIGV2ZXJ5Ym9keSwNCj4gPj4+Pg0KPiA+Pj4+DQo+ID4+Pj4NCj4gPj4+PkknZCBs aWtlIHRvIG5vdGUgdGhhdCBhbHRob3VnaCB0aGUgQVMgc2NvcGUgZmxvb2RpbmcgaXMgYWxsb3dl ZCBmb3INCj4gPj4+Pm9wYXF1ZQ0KPiA+Pj4+TFNBcywgaW4gbXkgZXhwZXJpZW5jZSBpdCBkb2Vz IG5vdCB3b3JrLg0KPiA+Pj4NCj4gPj4+DQo+ID4+PlNvIHlvdXIgZXhwZXJpZW5jZSBpcyBkaWZm ZXJlbnQgdGhhbiB0aGUgb25lIG9mIG1hbnkgcGVvcGxlIC4uLiAgT3BhcXVlDQo+ID4+PkxTQSBo YXZlIGJlZW4NCj4gPj4+dXNlZCBmb3IgcXVpdGUgYSBmZXcgeWVhcnMgd2l0aG91dCBhbnkgcHJv YmxlbS4gU2VlIFJGQzIzNzAgKEp1bHkgMTk5OCkNCj4gPj4+DQo+ID4+Pg0KPiA+Pj4+SW1hZ2lu ZSB0aGF0IHNvbWUgcm91dGluZw0KPiA+Pj4+Y29udHJvbGxlciBhZHZlcnRpc2VzIGFuIEFTIHNj b3BlIExTQSBhbmQgZ29lcyBvdXQgb2Ygc2VydmljZSAgcXVpY2tseQ0KPiA+Pj4+YWZ0ZXINCj4g Pj4+PnRoYXQuIENvbnRyb2xsZXJzIG91dHNpZGUgb2YgdGhlIGFyZWEgdGhhdCB0aGUgZGVhZCBj b250cm9sbGVyDQo+ID4+Pj5iZWxvbmdzIHRvDQo+ID4+Pj5oYXZlIG5vIHdheSBvZiBkZXRlY3Rp bmcgaXRzIGRlYXRoIGFuZCwgdGhlcmVmb3JlLCB3aWxsIGtlZXAgdXNpbmcgdGhlDQo+ID4+Pj5h ZHZlcnRpc2luZyBmb3IgYW5vdGhlciA5MCBtaW4gYmVmb3JlIHRoZSBMU0EgdGltZXMgb3V0Lg0K PiA+Pj4NCj4gPj4+DQo+ID4+PkkgZ3Vlc3MgdGhhdCB5b3UgbWVhbiA2MCBtaW4gKE1heGFnZT02 MG1uLCBBcmNoaXRlY3R1cmFsIENvbnN0YW50KSAtDQo+ID4+PlNlZSBSRkMyMzI4LCBidXQgdGhp cyBpcyBub3QgdGhlIHBvaW50LCBzZWUgYmVsb3cuDQo+ID4+Pg0KPiA+Pj4NCj4gPj4+Pk5vdGUg dGhhdCB0aGUNCj4gPj4+PmNvbnRyb2xsZXJzIGxvY2F0ZWQgd2l0aGluIHRoZSBzYW1lIGFyZWEg ZG8gbm90IGhhdmUgc3VjaCBhIHByb2JsZW0NCj4gPj4+PmJlY2F1c2UNCj4gPj4+PnRoZXkgY2Fu IGFsd2F5cyB2ZXJpZnkgdGhlIHZhbGlkaXR5IG9mIHRoZSBhZHZlcnRpc2luZyBieSB0cnlpbmcg dG8NCj4gPj4+PmxvY2F0ZSBhDQo+ID4+Pj5zZXF1ZW5jZSBvZiBhY3RpdmUgYWRqYWNlbmNpZXMg aW50ZXJjb25uZWN0aW5nIGVhY2ggb2YgdGhlbSB3aXRoIHRoZQ0KPiA+Pj4+YWR2ZXJ0aXNpbmcg Y29udHJvbGxlci4gSWYgdGhleSBmaW5kIGF0IGxlYXN0IG9uZSBzdWNoIGEgc2VxdWVuY2UsIHRo ZQ0KPiA+Pj4+YWR2ZXJ0aXNpbmcgaXMgdmFsaWQgKG90aGVyd2lzZSwgaXQgd291bGQgYmUgd2l0 aGRyYXduKTsgb24gdGhlICBvdGhlcg0KPiA+Pj4+aGFuZCwNCj4gPj4+PmlmIG5vIHN1Y2ggc2Vx dWVuY2VzIGV4aXN0LCB0aGFuIGFkdmVydGlzaW5nIGlzIGxpa2VseSB0byBiZSBzdGFsZQ0KPiA+ Pj4+YW5kIGhlbmNlDQo+ID4+Pj5jb3VsZCBub3QgYmUgdHJ1c3RlZC4gVGhlIGNvbmNsdXNpb24g aXMgdGhhdCBvcGFxdWUgTFNBcyBzaG91bGQgIG5ldmVyDQo+ID4gDQo+ID4gYmUNCj4gPiANCj4g Pj4+PmZsb29kZWQgd2l0aGluIEFTLCByYXRoZXIsIHdpdGhpbiBhIHNpbmdsZSBhcmVhLCBhbmQs IGlmIHRoZXJlIGlzIGENCj4gPj4+Pm5lZWQgZm9yDQo+ID4+Pj50aGUgaW5mb3JtYXRpb24gdG8g YmUgcHJvcGFnYXRlZCBiZXlvbmQgdGhlIGFyZWEgYm91bmRhcmllcywgQUJScw0KPiA+Pj4+bXVz dCByZWxheQ0KPiA+Pj4+dGhlIGFkdmVydGlzaW5nIGludG8gb3RoZXIgYXJlYXMgKGJ5IG9yaWdp bmF0aW5nIG5ldyBhcmVhLXNjb3BlDQo+ID4+Pj5MU0FzKS4gTm90ZQ0KPiA+Pj4+YWxzbyB0aGF0 IGFzIGZhciBhcyBJIHJlbWVtYmVyIE9TUEYgaXRzZWxmIG5ldmVyIHVzZXMgQVMgc2NvcGUNCj4g Pj4+PmFkdmVydGlzaW5ncw0KPiA+Pj4+Zm9yIGl0cyBvd24gbmVlZHMuIEZvciBleGFtcGxlLCBh biBBU0JSIGRvZXMgbm90IGRpc3RyaWJ1dGUgIGV4dGVybmFsDQo+ID4+Pj5yb3V0ZXMNCj4gPj4+ PmxlYXJuZWQgYnkgQkdQIGZyb20gb3RoZXIgQVNzIHVzaW5nIEFTIHNjb3BlIExTQXMsIHJhdGhl ciwgdGhlICByb3V0ZXMNCj4gPj4+PmFyZQ0KPiA+Pj4+YWR2ZXJ0aXNlZCB3aXRoaW4gYSBzaW5n bGUgYXJlYSBhbmQgQUJScyByZWxheSB0aGUgYWR2ZXJ0aXNpbmdzICBpbnRvDQo+ID4+Pj5vdGhl cg0KPiA+Pj4+YXJlYXMuDQo+ID4+Pg0KPiA+Pj4NCj4gPj4+VGhpcyBpcyBub3QgY29ycmVjdC4g RXh0ZXJuYWwgcm91dGVzIGFyZSByZWRpc3RyaWJ1dGVkIHdpdGggTFNBIFR5cGUgIDUNCj4gPj4+ d2hpY2ggYXJlDQo+ID4+PmZsb29kZWQgYWNyb3NzIHRoZSBlbnRpcmUgZG9tYWluIGV4Y2VwdCBp biBzdHViLWFyZWEgKG5vdCBnZW5lcmF0ZWQgYnkNCj4gPj4+dGhlIEFCUiBhcyB0eXBlIDMgYXMg eW91IG1lbnRpb24pLg0KPiA+Pj4NCj4gPj4+QW55d2F5LCBiYWNrIHRvIHRoZSBwb2ludCwgb25l IGNhbm5vdCBzYXkgb2YgY291cnNlIHRoYXQgIk9wYXF1ZSBMU0ENCj4gPj4+VHlwZSAxMSBkb2Vz IG5vdCB3b3JrIi4gVGhlcmUgYXJlIHN1aXRhYmxlIHRvIHNvbWUgYXBwbGljYXRpb24sIHRoaXMg aXMNCj4gPj4+YWxsLiBZb3UgY2FuIHBlcmZlY3RseSByZXBseSBvbiBhbiBvcGFxdWUgTFNBIFR5 cGUgMTEgdG8gbGVhcm4gdGhlDQo+ID4+PmNhcGFiaWxpdHkgb2YgYSByb3V0ZXIgd2hpY2ggZG9l cyBub3QgcmVzaWRlIGluIHRoZSBsb2NhbCBhcmVhIGFuZCByZWx5DQo+ID4+Pm9uIGFub3RoZXIg bWVjaGFuaXNtIHRvIGRldGVjdCBpdHMgbGl2ZW5lc3MuIFRoZXJlIGFyZSBzZXZlcmFsIHN1Y2gN Cj4gPj4+ZXhhbXBsZXMuDQo+ID4+Pg0KPiA+Pj5Ib3BlIHRoaXMgaGVscHMuDQo+ID4+Pg0KPiA+ Pj5KUC4NCj4gPj4+DQo+ID4+Pg0KPiA+Pj4NCj4gPj4+Pg0KPiA+Pj4+DQo+ID4+Pj5UaGUgYm90 dG9tIGxpbmUgaXMgdGhhdCB0aGUgVExWcyBkZXNjcmliZWQgaW4gdGhlIGRyYWZ0IHNob3VsZCBi ZSAgb2YNCj4gPiANCj4gPiB0aGUNCj4gPiANCj4gPj4+PmFyZWEgc2NvcGUgKGp1c3QgbGlrZSBU RSBMU0FzKSwgYW5kIGhlbmNlIGl0IGlzIG5vdCBhbGwgdGhhdCBpbXBvcnRhbnQNCj4gPj4+Pndo ZXRoZXIgd2UgdXNlIG5ldyBoaWdoIGxldmVsIFRMVnMgb3Igc3ViLVRMVnMgb2YgdGhlIFRFIHJv dXRlciBjYXANCj4gPiANCj4gPiBUTFYuDQo+ID4gDQo+ID4+Pj4NCj4gPj4+Pg0KPiA+Pj4+SWdv cg0KPiA+Pj4+DQo+ID4+Pj4NCj4gPj4+Pg0KPiA+Pj4+DQo+ID4+Pj4NCj4gPj4+Pi0tLS0tIE9y aWdpbmFsIE1lc3NhZ2UgLS0tLS0NCj4gPj4+Pg0KPiA+Pj4+RnJvbTogImRpbWl0cmkgcGFwYWRp bWl0cmlvdSIgPGRwYXBhZGltaXRyaW91QHBzZy5jb20+DQo+ID4+Pj4NCj4gPj4+PlRvOiAiQWRy aWFuIEZhcnJlbCIgPGFkcmlhbkBvbGRkb2cuY28udWs+DQo+ID4+Pj4NCj4gPj4+PkNjOiAiTEUg Uk9VWCBKZWFuLUxvdWlzIFJELUNPUkUtTEFOIg0KPiA+Pj4+PGplYW5sb3Vpcy5sZXJvdXhAZnJh bmNldGVsZWNvbS5jb20+Ow0KPiA+Pj4+IkpQIFZhc3NldXIiIDxqdmFzc2V1ckBjaXNjby5jb20+ OyAiRGltaXRyaSBQYXBhZGltaXRyaW91Ig0KPiA+Pj4+PGRpbWl0cmkucGFwYWRpbWl0cmlvdUBh bGNhdGVsLmJlPjsgPGNjYW1wQG9wcy5pZXRmLm9yZz4NCj4gPj4+Pg0KPiA+Pj4+U2VudDogRnJp ZGF5LCBOb3ZlbWJlciAxOCwgMjAwNSAxMDo1NyBBTQ0KPiA+Pj4+DQo+ID4+Pj5TdWJqZWN0OiBS ZTogSUdQIEV4dGVuc2lvbnMgLSBDQ0FNUCBNaWxlc3RvbmVzDQo+ID4+Pj4NCj4gPj4+Pg0KPiA+ Pj4+DQo+ID4+Pj4NCj4gPj4+Pg0KPiA+Pj4+PmFkcmlhbg0KPiA+Pj4+Pg0KPiA+Pj4+PmkgdGhp bmsgSkwncyByZXBseSBkaWQgcGFydGlhbGx5IHRyYW5zbGF0ZSB0aGUgaW5pdGlhbCBjb25jZXJu DQo+ID4+Pj4+DQo+ID4+Pj4+aW4gYnJpZWYsIHRoZXJlIGFyZSB0aHJlZSB3ZWxsIGlkZW50aWZp ZWQgVEUgYXBwbGljYXRpb25zIHRoYXQgY291bGQNCj4gPj4+Pj5tYWtlIHVzZSBvZiB0aGUgVEUg bm9kZSBjYXAgVExWcyBvbiBib3RoIGludHJhIGFuZCBpbnRlci1hcmVhIGJhc2lzOg0KPiA+Pj4+ Pi0gTFNQIFN0aXRjaGluZyBlZGdlIG5vZGUgY2FwYWJpbGl0eQ0KPiA+Pj4+Pi0gRWRnZSBub2Rl cyBjb25uZWN0aW5nL2JlaW5nIFAyTVAgVEUgZWdyZXNzZXMNCj4gPj4+Pj4tIFRFIGF1dG8tbWVz aA0KPiA+Pj4+Pg0KPiA+Pj4+PmhlbmNlLCB0aGUgcXVlc3Rpb24gb24gd2h5IGtlZXBpbmcgc2Vw YXJhdGVkIFRMVnMgYXMgcGFydCBvZiB0aGUNCj4gPiANCj4gPiByb3V0ZXINCj4gPiANCj4gPj4+ Pj5jYXBhYmlsaXR5IGFuZCBub3QgY29uc2lkZXIgdGhlc2UgYXMgc3ViLVRMVnMgb2YgdGhlIFRF IHJvdXRlciBjYXANCj4gPiANCj4gPiBUTFYNCj4gPiANCj4gPj4+Pj50aGlzIHdvdWxkDQo+ID4+ Pj4+MSkgcHJvdmlkZSBhIGxvZ2ljYWwgZ3JvdXBpbmcgb2YgVEUgc3ViLVRMVnMgYXMgcGFydCBv ZiB0aGUgc2FtZSAgVExWDQo+ID4+Pj4+YW5kDQo+ID4+Pj4+MikgbGVhdmUgdGhlIGZsZXhpYmls aXR5IG9mIGZsb29kaW5nIHNjb3BlIG9uIGEgcGVyIGFwcGxpY2F0aW9uDQo+ID4gDQo+ID4gIG5l ZWQgLQ0KPiA+IA0KPiA+Pj4+Pm5vdGU6IHRoYXQgdGhlIHBhdGggY29tcHV0YXRpb24gc3BlY2lm aWMgc3ViLVRMVnMgY291bGQgc3RpbGwgYmUNCj4gPj4+Pj5yZXN0cmljdGVkIHdpdGggdGhlaXIg Y3VycmVudCBhcmVhLXNjb3BlDQo+ID4+Pj4+DQo+ID4+Pj4+aG9wZSB0aGlzIGNsYXJpZmllcyB0 aGUgaXNzdWUsDQo+ID4+Pj4+DQo+ID4+Pj4+dGhhbmtzLA0KPiA+Pj4+Pi0gZGltaXRyaS4NCj4g Pj4+Pj4NCj4gPj4+Pj5BZHJpYW4gRmFycmVsIHdyb3RlOg0KPiA+Pj4+Pg0KPiA+Pj4+Pg0KPiA+ Pj4+Pg0KPiA+Pj4+Pj5JZiBJIHVuZGVyc3RhbmQgdGhlIHF1ZXN0aW9uIGl0IGlzLi4uDQo+ID4+ Pj4+Pg0KPiA+Pj4+Pj5JbiBkcmFmdC1pZXRmLW9zcGYtY2FwLTA3LnR4dCBpbnRyb2R1Y2VzIHRo ZSBPU1BGIHJvdXRlcg0KPiA+Pj4+Pj5pbmZvcm1hdGlvbiBMU0ENCj4gPj4+Pj4+YW5kIHN0YXRl cyB0aGF0IHRoaXMgTFNBIG1heSBoYXZlIHR5cGUgOSwgMTAgb3IgMTEgc2NvcGUuDQo+ID4+Pj4+ Pg0KPiA+Pj4+Pj5JbiBkcmFmdC12YXNzZXVyLWNjYW1wLXRlLW5vZGUtY2FwLTAxLnR4dCBhIG5l dyBUTFYgKFRFIE5vZGUNCj4gPj4+Pj4+Q2FwYWJpbGl0eQ0KPiA+Pj4+Pj5EZXNjcmlwdG9yKSBp cyBhZGRlZCB0byB0aGUgT1NQRiByb3V0ZXIgaW5mb3JtYXRpb24gTFNBLiBUaGlzIFRMVg0KPiA+ Pj4+Pj4od2hlbg0KPiA+Pj4+Pj5nZW5lcmF0ZWQpIE1VU1QgYmUgYWR2ZXJ0aXNlZCB3aXRoIHR5 cGUgMTAgc2NvcGUuIEpMIGhhcyBnaXZlbiB0aGUNCj4gPj4+Pj4+DQo+ID4+Pj4NCj4gPj4+PnJl YXNvbg0KPiA+Pj4+DQo+ID4+Pj4NCj4gPj4+Pj4+d2h5IHRoaXMgaXMgbGltaXRlZCB0byB0eXBl IDEwLiBUaGlzIHJlYXNvbiBpcywgb2YgY291cnNlLCBvcGVuIGZvcg0KPiA+Pj4+Pj5kaXNjdXNz aW9uIGFzIGhlIHNheXMuDQo+ID4+Pj4+Pg0KPiA+Pj4+Pj5JbiBkcmFmdC12YXNzZXVyLWNjYW1w LWF1dG9tZXNoLTAyLnR4dCBhIG5ldyBUTFYgKFRFLU1FU0gtR1JPVVApIGlzDQo+ID4+Pj4+Pg0K PiA+Pj4+DQo+ID4+Pj5hZGRlZA0KPiA+Pj4+DQo+ID4+Pj4NCj4gPj4+Pj4+dG8gdGhlIE9TUEYg cm91dGVyIGluZm9ybWF0aW9uIExTQS4gSXQgc3RhdGVzIHRoYXQgdGhlIExTQSBtYXkgYmUNCj4g Pj4+Pj4+YWR2ZXJ0aXNlZCB3aXRoIHR5cGUgMTAgb3IgdHlwZSAxMSBzY29wZS4gSlAgaGFzIGdp dmVuIGEgcmVhc29uICB3aHkNCj4gPj4+Pj4+eW91DQo+ID4+Pj4+Pm1pZ2h0IHdhbnQgdHlwZSAx MSBpbiBhZGRpdGlvbiB0byB0eXBlIDEwLiBUaGlzIHJlYXNvbiBpcywgb2YNCj4gPiANCj4gPiBj b3Vyc2UsDQo+ID4gDQo+ID4+Pj5vcGVuDQo+ID4+Pj4NCj4gPj4+Pg0KPiA+Pj4+Pj5mb3IgZGlz Y3Vzc2lvbi4NCj4gPj4+Pj4+DQo+ID4+Pj4+PkFuIGludGVyZXN0aW5nIGZlYXR1cmUgaXMgdGhh dCBhIHJvdXRlciBhZHZlcnRpc2luZyBhbiBBUy13aWRlIG1lc2gNCj4gPj4+Pj4+DQo+ID4+Pj4N Cj4gPj4+Pmdyb3VwDQo+ID4+Pj4NCj4gPj4+Pg0KPiA+Pj4+Pj4qYW5kKiBhIFRFIHJvdXRlciBj YXBhYmlsaXR5IG1heSByZXF1aXJlIHRoYXQgdHdvIE9TUEYgcm91dGVyDQo+ID4+Pj4+Pg0KPiA+ Pj4+DQo+ID4+Pj5pbmZvcm1hdGlvbg0KPiA+Pj4+DQo+ID4+Pj4NCj4gPj4+Pj4+TFNBcyBhcmUg YWR2ZXJ0aXNlZCBieSB0aGUgcm91dGVyLg0KPiA+Pj4+Pj4NCj4gPj4+Pj4+VGhlIGxhbmd1YWdl IGluIGRyYWZ0LWlldGYtb3NwZi1jYXAtMDcudHh0IGxlYW5zIHRvd2FyZHMgYSByb3V0ZXINCj4g Pj4+Pj4+DQo+ID4+Pj4NCj4gPj4+PnNlbmRpbmcNCj4gPj4+Pg0KPiA+Pj4+DQo+ID4+Pj4+Piph biogT1NQRiByb3V0ZXIgaW5mb3JtYXRpb24gTFNBLiBCdXQgbm93aGVyZSBkb2VzIGl0IHNheSB0 aGF0IHRoZQ0KPiA+Pj4+Pj4NCj4gPj4+Pg0KPiA+Pj4+cm91dGVyDQo+ID4+Pj4NCj4gPj4+Pg0K PiA+Pj4+Pj5jYW5ub3Qgc2VuZCBtb3JlIHRoYW4gb25lIGFuZCBpbiBzZWN0aW9uIDIuNSB3ZSBm aW5kLi4uDQo+ID4+Pj4+PiAgVGhlIG9yaWdpbmF0aW5nIHJvdXRlciBNQVkgYWR2ZXJ0aXNlDQo+ ID4+Pj4+PiAgIG11bHRpcGxlIFJJIExTQXMgYXMgbG9uZyBhcyB0aGUgZmxvb2Rpbmcgc2NvcGVz IGRpZmZlci4NCj4gPj4+Pj4+DQo+ID4+Pj4+PkhvcGUgdGhpcyBhbnN3ZXJzIHRoZSBwb2ludC4N Cj4gPj4+Pj4+DQo+ID4+Pj4+PkFkcmlhbg0KPiA+Pj4+Pj4tLS0tLSBPcmlnaW5hbCBNZXNzYWdl IC0tLS0tDQo+ID4+Pj4+PkZyb206ICJMRSBST1VYIEplYW4tTG91aXMgUkQtQ09SRS1MQU4iDQo+ ID4+Pj4+PjxqZWFubG91aXMubGVyb3V4QGZyYW5jZXRlbGVjb20uY29tPg0KPiA+Pj4+Pj5Ubzog IkpQIFZhc3NldXIiIDxqdmFzc2V1ckBjaXNjby5jb20+OyAiRGltaXRyaSBQYXBhZGltaXRyaW91 Ig0KPiA+Pj4+Pj48ZHBhcGFkaW1pdHJpb3VAcHNnLmNvbT47ICJEaW1pdHJpIFBhcGFkaW1pdHJp b3UiDQo+ID4+Pj4+PjxkaW1pdHJpLnBhcGFkaW1pdHJpb3VAYWxjYXRlbC5iZT4NCj4gPj4+Pj4+ Q2M6IDxhZHJpYW5Ab2xkZG9nLmNvLnVrPjsgPGNjYW1wQG9wcy5pZXRmLm9yZz4NCj4gPj4+Pj4+ U2VudDogVGh1cnNkYXksIE5vdmVtYmVyIDE3LCAyMDA1IDY6NDcgUE0NCj4gPj4+Pj4+U3ViamVj dDogUkU6IElHUCBFeHRlbnNpb25zIC0gQ0NBTVAgTWlsZXN0b25lcw0KPiA+Pj4+Pj4NCj4gPj4+ Pj4+DQo+ID4+Pj4+PkhpIERpbWl0cmksDQo+ID4+Pj4+Pg0KPiA+Pj4+Pj5UaGFua3MgZm9yIHRo ZSBjb21tZW50Lg0KPiA+Pj4+Pj4NCj4gPj4+Pj4+QXMganVzdCBleHBsYWluZWQgYnkgSlAsIHRo ZSBURSBOb2RlIENhcCBUTFYgY2FycmllcyB0b3BvbG9neQ0KPiA+IA0KPiA+IHJlbGF0ZWQNCj4g PiANCj4gPj4+Pj4+cGFyYW1ldGVycyB1c2VkIGFzIGNvbnN0cmFpbnRzIGluIHBhdGggY29tcHV0 YXRpb24uIFRoZSBsZWFraW5nICBvZg0KPiA+Pj4+Pj5zdWNoDQo+ID4+Pj4+PmluZm8gYWNyb3Nz IGFyZWFzIHNvdW5kcyB1c2VsZXNzIGFzIExTUiBURSB2aXNpYmlsaXR5IGlzIGxpbWl0ZWQgIHRv DQo+ID4+Pj4+Pm9uZQ0KPiA+Pj4+Pj5hcmVhIGFueXdheS4uLg0KPiA+Pj4+Pj5CdXQgdGhpcyBp cywgb2YgY291cnNlLCBvcGVuIHRvIGRpc2N1c3Npb25zLiBCeSB0aGUgd2F5LCBkbyB5b3UNCj4g Pj4+Pj4+aGF2ZSBhbnkNCj4gPj4+Pj4+YXBwbGljYXRpb24gaW4gbWluZCB3aGVyZSBzdWNoIGxl YWtpbmcgd291bGQgYmUgdXNlZnVsPw0KPiA+Pj4+Pj4NCj4gPj4+Pj4+UmVnYXJkcywNCj4gPj4+ Pj4+DQo+ID4+Pj4+PkpMDQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4NCj4gPj4+Pj4+DQo+ID4+Pj4+Pg0K PiA+Pj4+Pj4NCj4gPj4+Pj4+DQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4NCj4gPj4+Pj4+DQo+ID4+Pj4+ Pj4tLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0NCj4gPj4+Pj4+PkRlIDogSlAgVmFzc2V1ciBb bWFpbHRvOmp2YXNzZXVyQGNpc2NvLmNvbV0NCj4gPj4+Pj4+PkVudm956SA6IGpldWRpIDE3IG5v dmVtYnJlIDIwMDUgMTY6NTgNCj4gPj4+Pj4+PsAgOiBEaW1pdHJpIFBhcGFkaW1pdHJpb3U7IERp bWl0cmkgUGFwYWRpbWl0cmlvdQ0KPiA+Pj4+Pj4+Q2MgOiB6engtYWRyaWFuQG9sZGRvZy5jby51 azsgY2NhbXBAb3BzLmlldGYub3JnOyBMRSBST1VYDQo+ID4+Pj4+Pj5KZWFuLUxvdWlzIFJELUNP UkUtTEFODQo+ID4+Pj4+Pj5PYmpldCA6IFJlOiBJR1AgRXh0ZW5zaW9ucyAtIENDQU1QIE1pbGVz dG9uZXMNCj4gPj4+Pj4+Pg0KPiA+Pj4+Pj4+SGkgZGltaXRyaSwNCj4gPj4+Pj4+Pg0KPiA+Pj4+ Pj4+T24gTm92IDE2LCAyMDA1LCBhdCA2OjMwIFBNLCBkaW1pdHJpIHBhcGFkaW1pdHJpb3Ugd3Jv dGU6DQo+ID4+Pj4+Pj4NCj4gPj4+Pj4+Pg0KPiA+Pj4+Pj4+DQo+ID4+Pj4+Pj4NCj4gPj4+Pj4+ Pj5hZHJpYW4sDQo+ID4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+Y291bGQgeW91IGV4cGxhaW4gdGhlIHJl YXNvbmluZyBmb3IgaGF2aW5nIGEgVEUgc3BlY2lmaWMgVExWIGluDQo+ID4gDQo+ID4gdGhlDQo+ ID4gDQo+ID4+Pj4+Pj4+YXV0by1tZXNoIGRvY3VtZW50IHdpdGggYXJlYSBhbmQgQVMtd2lkZSBm bG9vZGluZyBzY29wZQ0KPiA+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+DQo+ID4+Pj4+Pj53aGlsZSB0aGUg VEUNCj4gPj4+Pj4+Pg0KPiA+Pj4+Pj4+DQo+ID4+Pj4+Pj4NCj4gPj4+Pj4+Pj5yb3V0ZXIgY2Fw IFRMViBpcyByZXN0cmljdGVkIHRvIGFuIGFyZWEgZmxvb2Rpbmcgc2NvcGUgPw0KPiA+Pj4+Pj4+ PnNob3VsZG4ndCBiZSBvbmUgd2F5IG9yIHRoZSBvdGhlciBpLmUuIGVpdGhlciByZXN0cmljdCBh bGwgVEUgaW5mbw0KPiA+Pj4+Pj4+PmFyZWEtbG9jYWwgb3IgYWxsb3cgZm9yIFRFIHJvdXRlciBj YXAgVExWIHdpdGggQVMtd2lkZQ0KPiA+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+DQo+ID4+Pj4+Pj5mbG9v ZGluZyBzY29wZQ0KPiA+Pj4+Pj4+DQo+ID4+Pj4+Pj4NCj4gPj4+Pj4+Pg0KPiA+Pj4+Pj4+Pj8N Cj4gPj4+Pj4+Pj4NCj4gPj4+Pj4+Pj5ub3RlOiB0aGVyZSBpcyBub3RoaW5nIGluIHRoZSBURSBy b3V0ZXIgY2FwIFRMViB0aGF0IHdvdWxkIGltcGFjdA0KPiA+Pj4+Pj4+PnNjYWxpbmcgbW9yZSB0 aGFuIHRoZSBURSBhdXRvLW1lc2ggVExWIGRvZXMNCj4gPj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4NCj4g Pj4+Pj4+Pg0KPiA+Pj4+Pj4+SSBndWVzcyB0aGF0IHRoZSByZWFzb24gZm9yIGFsbG93aW5nIGJv dGggaW50cmEgYW5kIGludGVyLWFyZWENCj4gPj4+Pj4+PmZsb29kaW5nIHNjb3BlcyBmb3IgYXV0 b21lc2ggaXMgb2J2aW91cyAod2UgbmVlZCB0byBoYXZlIFRFIExTUA0KPiA+IA0KPiA+IG1lc2gN Cj4gPiANCj4gPj4+Pj4+PndpdGhpbiBhcmVhcyBhbmQgc3Bhbm5pbmcgbXVsdGlwbGUgYXJlYXMp Lg0KPiA+Pj4+Pj4+DQo+ID4+Pj4+Pj5TbyB5b3VyIHF1ZXN0aW9uIGlzIHByb2JhYmx5IHdoeSBk b24ndCB3ZSBhbGxvdyB0aGUgVEUgcm91dGVyDQo+ID4+Pj4+Pj5jYXAgVExWDQo+ID4+Pj4+Pj50 byBiZSBmbG9vZGVkIGFjcm9zcyB0aGUgZG9tYWluID8gQXMgZmFyIGFzIEkgY2FuIHJlbWVtYmVy IEpMDQo+ID4+Pj4+Pj5hbHJlYWR5DQo+ID4+Pj4+Pj5hbnN3ZXJlZCB0aGlzIHF1ZXN0aW9uIC4u LiBKTCwgY291bGQgeW91IGZvcndhcmQgeW91ciBlbWFpbCBhZ2FpbiA/DQo+ID4+Pj4+Pj4NCj4g Pj4+Pj4+PkluIHRoZSBtZWFudGltZSwgSSBjYW4gYW5zd2VyIGl0OiB0aGUgcmVhc29uIGlzIHRo YXQgc3VjaCBURSBub2RlDQo+ID4+Pj4+Pj5jYXBhYmlsaXRpZXMgYXJlIHVzZWQgZm9yIFRFIExT UCBjb21wdXRhdGlvbiB3aGljaCBjYW5ub3QgdGFrZSBpbnRvDQo+ID4+Pj4+Pj5hY2NvdW50IG5v ZGVzIHRoYXQgZG8gbm90IHJlc2lkZSBpbiB0aGUgbm9kZSdzIGFyZWEuDQo+ID4+Pj4+Pj4NCj4g Pj4+Pj4+PlRoYW5rcy4NCj4gPj4+Pj4+Pg0KPiA+Pj4+Pj4+SlAuDQo+ID4+Pj4+Pj4NCj4gPj4+ Pj4+Pg0KPiA+Pj4+Pj4+DQo+ID4+Pj4+Pj4NCj4gPj4+Pj4+Pj50aGFua3MsDQo+ID4+Pj4+Pj4+ LSBkaW1pdHJpLg0KPiA+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+PkFkcmlhbiBGYXJyZWwgd3JvdGU6DQo+ ID4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+ DQo+ID4+Pj4+Pj4+PkhpLA0KPiA+Pj4+Pj4+Pj5XZSBoYXZlIHR3byBpbW1lZGlhdGUgbWlsZXN0 b25lcyB0byBhZGRyZXNzOg0KPiA+Pj4+Pj4+Pj5PY3QgMDUgIEZpcnN0IHZlcnNpb24gV0cgSS1E IGZvciBBZHZlcnRpc2luZyBURSBOb2RlIENhcGFiaWxpdGllcw0KPiA+Pj4+Pj4+Pj5pbiBJU0lT DQo+ID4+Pj4+Pj4+PmFuZCBPU1BGDQo+ID4+Pj4+Pj4+Pk9jdCAwNSAgRmlyc3QgdmVyc2lvbiBX RyBJLUQgZm9yIEF1dG9tYXRpYyBkaXNjb3Zlcnkgb2YNCj4gPj4+Pj4+Pj4+DQo+ID4+Pj4+Pj4N Cj4gPj4+Pj4+Pk1QTFMtVEUgbWVzaA0KPiA+Pj4+Pj4+DQo+ID4+Pj4+Pj4NCj4gPj4+Pj4+Pg0K PiA+Pj4+Pj4+Pj5tZW1iZXJzaGlwDQo+ID4+Pj4+Pj4+PlRoZXJlIGFyZSB0d28gcGVyc29uYWwg c3VibWlzc2lvbnMgd2hpY2ggYWRkcmVzcyB0aGVzZSB0b3BpY3M6DQo+ID4+Pj4+Pj4+PmRyYWZ0 LXZhc3NldXItY2NhbXAtdGUtbm9kZS1jYXAtMDEudHh0DQo+ID4+Pj4+Pj4+PmRyYWZ0LXZhc3Nl dXItY2NhbXAtYXV0b21lc2gtMDIudHh0DQo+ID4+Pj4+Pj4+PkkgcHJvcG9zZSB0aGF0IHdlIG1v dmUgdGhlc2UgaW50byB0aGUgV0cgYW5kIHRoZW4ga2ljayB0aGUgdGlyZXMNCj4gPj4+Pj4+Pj4+ dGhvcm91Z2hseS4NCj4gPj4+Pj4+Pj4+T3BpbmlvbnMgcGxlYXNlLg0KPiA+Pj4+Pj4+Pj5UaGFu a3MsDQo+ID4+Pj4+Pj4+PkFkcmlhbg0KPiA+Pj4+Pj4+Pj4uDQo+ID4+Pj4+Pj4+Pg0KPiA+Pj4+ Pj4+Pg0KPiA+Pj4+Pj4+Pg0KPiA+Pj4+Pj4NCj4gPj4+Pj4+DQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4u DQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4NCj4gPj4+Pj4NCj4gPj4+DQo+ID4+Pi4NCj4gPj4+DQo+ID4+ DQo+ID4gDQo+ID4gDQo+ID4gLg0KPiA+IA0KPiA= Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 21 Nov 2005 23:21:11 +0000 Message-ID: <43825610.7060706@psg.com> Date: Tue, 22 Nov 2005 00:19:44 +0100 From: dimitri papadimitriou Reply-To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.11) Gecko/20050728 MIME-Version: 1.0 To: Igor Bryskin CC: dimitri.papadimitriou@alcatel.be, JP Vasseur , Adrian Farrel , LE ROUX Jean-Louis RD-CORE-LAN , ccamp@ops.ietf.org Subject: Re: IGP Extensions - CCAMP Milestones Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit igor Igor Bryskin wrote: > Dimitri, > > See my reply to JP. Also see below. > > ----- Original Message ----- > From: "dimitri papadimitriou" > To: "JP Vasseur" > Cc: "Igor Bryskin" ; ; > "Adrian Farrel" ; "LE ROUX Jean-Louis RD-CORE-LAN" > ; > Sent: Sunday, November 20, 2005 2:40 PM > Subject: Re: IGP Extensions - CCAMP Milestones > > > >>hi jp, >> >>indeed, i don't really understand the issue brought up by igor; >> >>in the present case, one should also underline that, the information >>distributed across the OSPF domain using opaque LSAs, is *indirectly* >>used by e.g. TE applications (note: RFC2370 allows for this information >>to be used directly by OSPF but i think we're not discussing this >>alternative) >> >>this means that these e.g. TE applications can in case of control engine >>failure detect this failure and trigger any necessary action in order to >>avoid the behaviour described by igor > > > IB>> Two points here: > > a) all TE LSAs are of the area scope; you are confusing TE LSAs (opaque type 1, area-scope) applicability with the broader context of e.g. TE applications (see initial statement) that can make use of RI LSAs for inst. > b) A TE application can detect a control engine failure only within one > area. this is not correct, as by definition, application dependent; thanks, - dimitri. > It does not help for LSRs located outside of this area because no LSR > (including ABR) is allowed to withdraw somebody else's LSAs - the LSAs could > be withdrawn or modified by the LSR that has originated them. > > Igor > > >>thanks, >>- dimitri. >> >>JP Vasseur wrote: >> >>>Hi Igor, >>> >>>On Nov 19, 2005, at 11:16 AM, Igor Bryskin wrote: >>> >>> >>>>Hi everybody, >>>> >>>> >>>> >>>>I'd like to note that although the AS scope flooding is allowed for >>>>opaque >>>>LSAs, in my experience it does not work. >>> >>> >>>So your experience is different than the one of many people ... Opaque >>>LSA have been >>>used for quite a few years without any problem. See RFC2370 (July 1998) >>> >>> >>>>Imagine that some routing >>>>controller advertises an AS scope LSA and goes out of service quickly >>>>after >>>>that. Controllers outside of the area that the dead controller >>>>belongs to >>>>have no way of detecting its death and, therefore, will keep using the >>>>advertising for another 90 min before the LSA times out. >>> >>> >>>I guess that you mean 60 min (Maxage=60mn, Architectural Constant) - >>>See RFC2328, but this is not the point, see below. >>> >>> >>>>Note that the >>>>controllers located within the same area do not have such a problem >>>>because >>>>they can always verify the validity of the advertising by trying to >>>>locate a >>>>sequence of active adjacencies interconnecting each of them with the >>>>advertising controller. If they find at least one such a sequence, the >>>>advertising is valid (otherwise, it would be withdrawn); on the other >>>>hand, >>>>if no such sequences exist, than advertising is likely to be stale >>>>and hence >>>>could not be trusted. The conclusion is that opaque LSAs should never > > be > >>>>flooded within AS, rather, within a single area, and, if there is a >>>>need for >>>>the information to be propagated beyond the area boundaries, ABRs >>>>must relay >>>>the advertising into other areas (by originating new area-scope >>>>LSAs). Note >>>>also that as far as I remember OSPF itself never uses AS scope >>>>advertisings >>>>for its own needs. For example, an ASBR does not distribute external >>>>routes >>>>learned by BGP from other ASs using AS scope LSAs, rather, the routes >>>>are >>>>advertised within a single area and ABRs relay the advertisings into >>>>other >>>>areas. >>> >>> >>>This is not correct. External routes are redistributed with LSA Type 5 >>>which are >>>flooded across the entire domain except in stub-area (not generated by >>>the ABR as type 3 as you mention). >>> >>>Anyway, back to the point, one cannot say of course that "Opaque LSA >>>Type 11 does not work". There are suitable to some application, this is >>>all. You can perfectly reply on an opaque LSA Type 11 to learn the >>>capability of a router which does not reside in the local area and rely >>>on another mechanism to detect its liveness. There are several such >>>examples. >>> >>>Hope this helps. >>> >>>JP. >>> >>> >>> >>>> >>>> >>>>The bottom line is that the TLVs described in the draft should be of > > the > >>>>area scope (just like TE LSAs), and hence it is not all that important >>>>whether we use new high level TLVs or sub-TLVs of the TE router cap > > TLV. > >>>> >>>> >>>>Igor >>>> >>>> >>>> >>>> >>>> >>>>----- Original Message ----- >>>> >>>>From: "dimitri papadimitriou" >>>> >>>>To: "Adrian Farrel" >>>> >>>>Cc: "LE ROUX Jean-Louis RD-CORE-LAN" >>>>; >>>>"JP Vasseur" ; "Dimitri Papadimitriou" >>>>; >>>> >>>>Sent: Friday, November 18, 2005 10:57 AM >>>> >>>>Subject: Re: IGP Extensions - CCAMP Milestones >>>> >>>> >>>> >>>> >>>> >>>>>adrian >>>>> >>>>>i think JL's reply did partially translate the initial concern >>>>> >>>>>in brief, there are three well identified TE applications that could >>>>>make use of the TE node cap TLVs on both intra and inter-area basis: >>>>>- LSP Stitching edge node capability >>>>>- Edge nodes connecting/being P2MP TE egresses >>>>>- TE auto-mesh >>>>> >>>>>hence, the question on why keeping separated TLVs as part of the > > router > >>>>>capability and not consider these as sub-TLVs of the TE router cap > > TLV > >>>>>this would >>>>>1) provide a logical grouping of TE sub-TLVs as part of the same TLV >>>>>and >>>>>2) leave the flexibility of flooding scope on a per application > > need - > >>>>>note: that the path computation specific sub-TLVs could still be >>>>>restricted with their current area-scope >>>>> >>>>>hope this clarifies the issue, >>>>> >>>>>thanks, >>>>>- dimitri. >>>>> >>>>>Adrian Farrel wrote: >>>>> >>>>> >>>>> >>>>>>If I understand the question it is... >>>>>> >>>>>>In draft-ietf-ospf-cap-07.txt introduces the OSPF router >>>>>>information LSA >>>>>>and states that this LSA may have type 9, 10 or 11 scope. >>>>>> >>>>>>In draft-vasseur-ccamp-te-node-cap-01.txt a new TLV (TE Node >>>>>>Capability >>>>>>Descriptor) is added to the OSPF router information LSA. This TLV >>>>>>(when >>>>>>generated) MUST be advertised with type 10 scope. JL has given the >>>>>> >>>> >>>>reason >>>> >>>> >>>>>>why this is limited to type 10. This reason is, of course, open for >>>>>>discussion as he says. >>>>>> >>>>>>In draft-vasseur-ccamp-automesh-02.txt a new TLV (TE-MESH-GROUP) is >>>>>> >>>> >>>>added >>>> >>>> >>>>>>to the OSPF router information LSA. It states that the LSA may be >>>>>>advertised with type 10 or type 11 scope. JP has given a reason why >>>>>>you >>>>>>might want type 11 in addition to type 10. This reason is, of > > course, > >>>>open >>>> >>>> >>>>>>for discussion. >>>>>> >>>>>>An interesting feature is that a router advertising an AS-wide mesh >>>>>> >>>> >>>>group >>>> >>>> >>>>>>*and* a TE router capability may require that two OSPF router >>>>>> >>>> >>>>information >>>> >>>> >>>>>>LSAs are advertised by the router. >>>>>> >>>>>>The language in draft-ietf-ospf-cap-07.txt leans towards a router >>>>>> >>>> >>>>sending >>>> >>>> >>>>>>*an* OSPF router information LSA. But nowhere does it say that the >>>>>> >>>> >>>>router >>>> >>>> >>>>>>cannot send more than one and in section 2.5 we find... >>>>>> The originating router MAY advertise >>>>>> multiple RI LSAs as long as the flooding scopes differ. >>>>>> >>>>>>Hope this answers the point. >>>>>> >>>>>>Adrian >>>>>>----- Original Message ----- >>>>>>From: "LE ROUX Jean-Louis RD-CORE-LAN" >>>>>> >>>>>>To: "JP Vasseur" ; "Dimitri Papadimitriou" >>>>>>; "Dimitri Papadimitriou" >>>>>> >>>>>>Cc: ; >>>>>>Sent: Thursday, November 17, 2005 6:47 PM >>>>>>Subject: RE: IGP Extensions - CCAMP Milestones >>>>>> >>>>>> >>>>>>Hi Dimitri, >>>>>> >>>>>>Thanks for the comment. >>>>>> >>>>>>As just explained by JP, the TE Node Cap TLV carries topology > > related > >>>>>>parameters used as constraints in path computation. The leaking of >>>>>>such >>>>>>info across areas sounds useless as LSR TE visibility is limited to >>>>>>one >>>>>>area anyway... >>>>>>But this is, of course, open to discussions. By the way, do you >>>>>>have any >>>>>>application in mind where such leaking would be useful? >>>>>> >>>>>>Regards, >>>>>> >>>>>>JL >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>-----Message d'origine----- >>>>>>>De : JP Vasseur [mailto:jvasseur@cisco.com] >>>>>>>Envoyé : jeudi 17 novembre 2005 16:58 >>>>>>>À : Dimitri Papadimitriou; Dimitri Papadimitriou >>>>>>>Cc : zzx-adrian@olddog.co.uk; ccamp@ops.ietf.org; LE ROUX >>>>>>>Jean-Louis RD-CORE-LAN >>>>>>>Objet : Re: IGP Extensions - CCAMP Milestones >>>>>>> >>>>>>>Hi dimitri, >>>>>>> >>>>>>>On Nov 16, 2005, at 6:30 PM, dimitri papadimitriou wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>>adrian, >>>>>>>> >>>>>>>>could you explain the reasoning for having a TE specific TLV in > > the > >>>>>>>>auto-mesh document with area and AS-wide flooding scope >>>>>>>> >>>>>>> >>>>>>>while the TE >>>>>>> >>>>>>> >>>>>>> >>>>>>>>router cap TLV is restricted to an area flooding scope ? >>>>>>>>shouldn't be one way or the other i.e. either restrict all TE info >>>>>>>>area-local or allow for TE router cap TLV with AS-wide >>>>>>>> >>>>>>> >>>>>>>flooding scope >>>>>>> >>>>>>> >>>>>>> >>>>>>>>? >>>>>>>> >>>>>>>>note: there is nothing in the TE router cap TLV that would impact >>>>>>>>scaling more than the TE auto-mesh TLV does >>>>>>>> >>>>>>>> >>>>>>> >>>>>>>I guess that the reason for allowing both intra and inter-area >>>>>>>flooding scopes for automesh is obvious (we need to have TE LSP > > mesh > >>>>>>>within areas and spanning multiple areas). >>>>>>> >>>>>>>So your question is probably why don't we allow the TE router >>>>>>>cap TLV >>>>>>>to be flooded across the domain ? As far as I can remember JL >>>>>>>already >>>>>>>answered this question ... JL, could you forward your email again ? >>>>>>> >>>>>>>In the meantime, I can answer it: the reason is that such TE node >>>>>>>capabilities are used for TE LSP computation which cannot take into >>>>>>>account nodes that do not reside in the node's area. >>>>>>> >>>>>>>Thanks. >>>>>>> >>>>>>>JP. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>>thanks, >>>>>>>>- dimitri. >>>>>>>> >>>>>>>>Adrian Farrel wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>Hi, >>>>>>>>>We have two immediate milestones to address: >>>>>>>>>Oct 05 First version WG I-D for Advertising TE Node Capabilities >>>>>>>>>in ISIS >>>>>>>>>and OSPF >>>>>>>>>Oct 05 First version WG I-D for Automatic discovery of >>>>>>>>> >>>>>>> >>>>>>>MPLS-TE mesh >>>>>>> >>>>>>> >>>>>>> >>>>>>>>>membership >>>>>>>>>There are two personal submissions which address these topics: >>>>>>>>>draft-vasseur-ccamp-te-node-cap-01.txt >>>>>>>>>draft-vasseur-ccamp-automesh-02.txt >>>>>>>>>I propose that we move these into the WG and then kick the tires >>>>>>>>>thoroughly. >>>>>>>>>Opinions please. >>>>>>>>>Thanks, >>>>>>>>>Adrian >>>>>>>>>. >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>> >>>>>> >>>>>> >>>>>>. >>>>>> >>>>>> >>>>> >>> >>>. >>> >> > > > . > Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 21 Nov 2005 18:21:56 +0000 Message-ID: <031101c5eec8$564f3ab0$fb849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Liaison sent to ITU-T for RFC 4258 Date: Mon, 21 Nov 2005 18:20:53 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit > To: Greg Jones > Cc: Adrian Farrel , Scott Bradner , Kireeti Kompella , Alex Zinin , Bill Fenner , CCAMP List ,Adrian Farrel , Kireeti Kompella ,Adrian Farrel , Kireeti Kompella , Deborah Brungard ,statements@ietf.org > From: Adrian Farrel(IETF CCAMP WG) > Subject: Submission of New Liaison Statement, "Publication of New RFC : GMPLS > Routing Requirements for ASON" > Message-Id: > Sender: Apache > Date: Mon, 21 Nov 2005 13:08:59 -0500 > > > Title: Publication of New RFC : GMPLS Routing Requirements for ASON > Submission Date: 2005-11-21 > URL of the IETF Web page: https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=150 > > From: Adrian Farrel(IETF CCAMP WG) > To: ITU-T SQ15 Question 14(Greg Jones ) > Cc: Adrian Farrel > Scott Bradner > Kireeti Kompella > Alex Zinin > Bill Fenner > CCAMP List > Reponse Contact: Adrian Farrel > Kireeti Kompella > Technical Contact: Adrian Farrel > Kireeti Kompella > Deborah Brungard > Purpose: For information > Body: The CCAMP working group is pleased to inform you of the publication of RFC 4258: "Requirements for Generalized Multi-Protocol Label Switching (GMPLS) Routing for the Automatically Switched Optical Network (ASON)" > > The abstract of this RFC is as follows. > > The Generalized Multi-Protocol Label Switching > (GMPLS) suite of protocols has been defined to > control different switching technologies as well > as different applications. These include support > for requesting Time Division Multiplexing (TDM) > connections including Synchronous Optical Network > (SONET)/Synchronous Digital Hierarchy (SDH) and > Optical Transport Networks (OTNs). > > This document concentrates on the routing > requirements placed on the GMPLS suite of > protocols in order to support the capabilities > and functionalities of an Automatically Switched > Optical Network (ASON) as defined by the ITU-T. > > The CCAMP working group is indebted to several members of the ITU-T SG15 community who played a significant part in the authorship of this RFC, and to Question 14/15 which provided important review feedback to ensure that this document accurately reflects the nature and requirements of routing in an ASON environment. > > The RFC can be downloaded from http://www.ietf.org/rfc/rfc4258.txt > > Regards, > Adrian Farrel and Kireeti Kompella > IETF CCAMP working group co-chairs > Attachment(s): > No document has been attached Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 21 Nov 2005 17:27:56 +0000 Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <5FD242E6-2C5E-4D1C-9EFF-E14AF4690201@cisco.com> Cc: , , "Adrian Farrel" , "LE ROUX Jean-Louis RD-CORE-LAN" , Content-Transfer-Encoding: quoted-printable From: JP Vasseur Subject: Re: IGP Extensions - CCAMP Milestones Date: Mon, 21 Nov 2005 12:26:47 -0500 To: Igor Bryskin Hi Igor, On Nov 21, 2005, at 12:19 PM, Igor Bryskin wrote: > JP, > > Could you give me an example of application that uses AS scope =20 > opaque LSAs? > I'll be happy to spend time with you next time we meet to help you =20 understand how to use Opaque LSA Type 11, but do not have enough =20 bandwidth as of now ... If you need help on the OSPF front, you may =20 want to poll the OSPF WG. JP. > Thanks, > Igor > > > ----- Original Message ----- > From: "JP Vasseur" > To: "Igor Bryskin" > Cc: ; ; =20 > "Adrian > Farrel" ; "LE ROUX Jean-Louis RD-CORE-LAN" > ; > Sent: Monday, November 21, 2005 11:36 AM > Subject: Re: IGP Extensions - CCAMP Milestones > > > Hi Igor, > > On Nov 21, 2005, at 10:13 AM, Igor Bryskin wrote: > > >> Hi JP, >> >> >> >> See in-line. >> >> >> >> Cheers, >> >> Igor >> >> >> >> ----- Original Message ----- >> >> From: "JP Vasseur" >> >> To: "Igor Bryskin" >> >> Cc: ; ; >> "Adrian >> Farrel" ; "LE ROUX Jean-Louis RD-CORE-LAN" >> ; >> >> Sent: Sunday, November 20, 2005 9:57 AM >> >> Subject: Re: IGP Extensions - CCAMP Milestones >> >> >> >> Hi Igor, >> >> On Nov 19, 2005, at 11:16 AM, Igor Bryskin wrote: >> >> >> >>> Hi everybody, >>> >>> >>> >>> I'd like to note that although the AS scope flooding is allowed for >>> opaque >>> LSAs, in my experience it does not work. >>> >>> >> >> So your experience is different than the one of many people ... >> Opaque LSA have been >> used for quite a few years without any problem. See RFC2370 (July >> 1998) >> >> >> >>> Imagine that some routing >>> controller advertises an AS scope LSA and goes out of service >>> quickly after >>> that. Controllers outside of the area that the dead controller >>> belongs to >>> have no way of detecting its death and, therefore, will keep using >>> the >>> advertising for another 90 min before the LSA times out. >>> >>> >> >> I guess that you mean 60 min (Maxage=3D60mn, Architectural Constant) = - >> See RFC2328, but this is not the point, see below. >> >> >> >>> Note that the >>> controllers located within the same area do not have such a problem >>> because >>> they can always verify the validity of the advertising by trying to >>> locate a >>> sequence of active adjacencies interconnecting each of them with the >>> advertising controller. If they find at least one such a sequence, >>> the >>> advertising is valid (otherwise, it would be withdrawn); on the >>> other hand, >>> if no such sequences exist, than advertising is likely to be stale >>> and hence >>> could not be trusted. The conclusion is that opaque LSAs should >>> never be >>> flooded within AS, rather, within a single area, and, if there is a >>> need for >>> the information to be propagated beyond the area boundaries, ABRs >>> must relay >>> the advertising into other areas (by originating new area-scope >>> LSAs). Note >>> also that as far as I remember OSPF itself never uses AS scope >>> advertisings >>> for its own needs. For example, an ASBR does not distribute >>> external routes >>> learned by BGP from other ASs using AS scope LSAs, rather, the >>> routes are >>> advertised within a single area and ABRs relay the advertisings >>> into other >>> areas. >>> >>> >> >> This is not correct. External routes are redistributed with LSA Type >> 5 which are >> flooded across the entire domain except in stub-area (not =20 >> generated by >> the ABR as type 3 as you mention). >> >> >> >> IB>> True, that what is written in RFC2328. >> > > well not just written in the RFC but implemented and deployed in OSPF > networks for years. > > >> And my contention here is that >> if an ASBR advertises LSAs type 5 and dies after that, than OSPF >> speakers >> outside of the ASBR's area have good likelihood to use stale >> external routes >> for a considerable period of time. There is no remedy to that (OSPF >> speakers >> do not use Keep Alive protocol :=3D). This, however, could be fixed = by >> avoiding using of AS scope flooding, and that's exactly the reason >> why some >> OSPF applications that I know of do just that. But this is the >> discussion >> for OSPF WG, I suggest not argue about that. See below. >> >> > > There is nothing to fix here. Anyway, see below ... > > >> Anyway, back to the point, one cannot say of course that "Opaque LSA >> Type 11 does not work". There are suitable to some application, >> this is >> all. You can perfectly reply on an opaque LSA Type 11 to learn the >> capability of a router which does not reside in the local area and >> rely >> on another mechanism to detect its liveness. There are several such >> examples. >> >> >> >> IB>> Let's stick to your example. Why is it better to flood router >> capability LSAs across an AS, rather than flood them within a >> single area >> and have ABRs relay the advertisings into other areas by >> originating their >> own LSAs? Yes, the AS-scope flooding is simpler. >> But what I am suggesting >> has the following advantages: >> >> a) Advertisings of a crashed LSR could be withdrawn from use >> by all AS >> LSRs immediately after the crash; >> >> b) Advertisings could be summarized by an ABR providing >> scalability >> improvements; >> >> > > OSPF provides an efficient way to flood information across the entire > routing domain: opaque LSA Type 11. If the use of such LSA is useful > to some applications why not using it ? > > You highlight two aspects here > - Liveness of the capability advertising router: just rely on a > liveness protocol if you need to quickly detect a crash of the router > - Scalability improvement: this is in fact the opposite ... Think of > the extra work required on the ABR to leak TLV in other areas > compared to flood a Type 11 LSA. Apparently you do not appreciate the > architectural change that this would mean on OSPF. > > >> c) What is more important that policies could be applied on >> ABRs wrt to >> what information is leaked to external areas. Regretfully, you keep >> forgetting about the policy aspects, but in the context of AS-scope >> flooding >> how can you enforce that an LSR capabilities are advertised into >> some areas, >> not advertised into some other areas, and advertised in a modified >> way into >> the third set of areas? >> > > Policy is of the utmost importance in many contexts such as Inter-AS/ > Providers ... not sure the case of inter-area within a single AS is > the case. Now, if you want to propose a new mode of operation for > OSPF, you may want to discuss it with the OSPF WG ... We could > continue the discussion there ... since it belongs to OSPF. > > JP. > > >> >> >> >> Igor >> >> Hope this helps. >> >> JP. >> >> >> >> >>> >>> >>> >>> The bottom line is that the TLVs described in the draft should be >>> of the >>> area scope (just like TE LSAs), and hence it is not all that >>> important >>> whether we use new high level TLVs or sub-TLVs of the TE router cap >>> TLV. >>> >>> >>> >>> Igor >>> >>> >>> >>> >>> >>> ----- Original Message ----- >>> >>> From: "dimitri papadimitriou" >>> >>> To: "Adrian Farrel" >>> >>> Cc: "LE ROUX Jean-Louis RD-CORE-LAN" >>> ; >>> "JP Vasseur" ; "Dimitri Papadimitriou" >>> ; >>> >>> Sent: Friday, November 18, 2005 10:57 AM >>> >>> Subject: Re: IGP Extensions - CCAMP Milestones >>> >>> >>> >>> >>> >>> >>>> adrian >>>> >>>> i think JL's reply did partially translate the initial concern >>>> >>>> in brief, there are three well identified TE applications that =20 >>>> could >>>> make use of the TE node cap TLVs on both intra and inter-area =20 >>>> basis: >>>> - LSP Stitching edge node capability >>>> - Edge nodes connecting/being P2MP TE egresses >>>> - TE auto-mesh >>>> >>>> hence, the question on why keeping separated TLVs as part of the >>>> router >>>> capability and not consider these as sub-TLVs of the TE router cap >>>> TLV >>>> this would >>>> 1) provide a logical grouping of TE sub-TLVs as part of the same >>>> TLV and >>>> 2) leave the flexibility of flooding scope on a per application >>>> need - >>>> >>>> note: that the path computation specific sub-TLVs could still be >>>> restricted with their current area-scope >>>> >>>> hope this clarifies the issue, >>>> >>>> thanks, >>>> - dimitri. >>>> >>>> Adrian Farrel wrote: >>>> >>>> >>>> >>>> >>>>> If I understand the question it is... >>>>> >>>>> In draft-ietf-ospf-cap-07.txt introduces the OSPF router >>>>> information LSA >>>>> and states that this LSA may have type 9, 10 or 11 scope. >>>>> >>>>> In draft-vasseur-ccamp-te-node-cap-01.txt a new TLV (TE Node >>>>> Capability >>>>> Descriptor) is added to the OSPF router information LSA. This TLV >>>>> (when >>>>> generated) MUST be advertised with type 10 scope. JL has given the >>>>> >>>>> >>>>> >>> reason >>> >>> >>> >>>>> why this is limited to type 10. This reason is, of course, open =20= >>>>> for >>>>> discussion as he says. >>>>> >>>>> In draft-vasseur-ccamp-automesh-02.txt a new TLV (TE-MESH-=20 >>>>> GROUP) is >>>>> >>>>> >>>>> >>> added >>> >>> >>> >>>>> to the OSPF router information LSA. It states that the LSA may be >>>>> advertised with type 10 or type 11 scope. JP has given a reason >>>>> why you >>>>> might want type 11 in addition to type 10. This reason is, of >>>>> course, >>>>> >>>>> >>>>> >>> open >>> >>> >>> >>>>> for discussion. >>>>> >>>>> An interesting feature is that a router advertising an AS-wide =20 >>>>> mesh >>>>> >>>>> >>>>> >>> group >>> >>> >>> >>>>> *and* a TE router capability may require that two OSPF router >>>>> >>>>> >>>>> >>> information >>> >>> >>> >>>>> LSAs are advertised by the router. >>>>> >>>>> The language in draft-ietf-ospf-cap-07.txt leans towards a router >>>>> >>>>> >>>>> >>> sending >>> >>> >>> >>>>> *an* OSPF router information LSA. But nowhere does it say that the >>>>> >>>>> >>>>> >>> router >>> >>> >>> >>>>> cannot send more than one and in section 2.5 we find... >>>>> The originating router MAY advertise >>>>> multiple RI LSAs as long as the flooding scopes differ. >>>>> >>>>> Hope this answers the point. >>>>> >>>>> Adrian >>>>> ----- Original Message ----- >>>>> From: "LE ROUX Jean-Louis RD-CORE-LAN" >>>>> >>>>> To: "JP Vasseur" ; "Dimitri Papadimitriou" >>>>> ; "Dimitri Papadimitriou" >>>>> >>>>> Cc: ; >>>>> Sent: Thursday, November 17, 2005 6:47 PM >>>>> Subject: RE: IGP Extensions - CCAMP Milestones >>>>> >>>>> >>>>> Hi Dimitri, >>>>> >>>>> Thanks for the comment. >>>>> >>>>> As just explained by JP, the TE Node Cap TLV carries topology >>>>> related >>>>> parameters used as constraints in path computation. The leaking >>>>> of such >>>>> info across areas sounds useless as LSR TE visibility is limited >>>>> to one >>>>> area anyway... >>>>> But this is, of course, open to discussions. By the way, do you >>>>> have any >>>>> application in mind where such leaking would be useful? >>>>> >>>>> Regards, >>>>> >>>>> JL >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>> -----Message d'origine----- >>>>>> De : JP Vasseur [mailto:jvasseur@cisco.com] >>>>>> Envoy=E9 : jeudi 17 novembre 2005 16:58 >>>>>> =C0 : Dimitri Papadimitriou; Dimitri Papadimitriou >>>>>> Cc : zzx-adrian@olddog.co.uk; ccamp@ops.ietf.org; LE ROUX >>>>>> Jean-Louis RD-CORE-LAN >>>>>> Objet : Re: IGP Extensions - CCAMP Milestones >>>>>> >>>>>> Hi dimitri, >>>>>> >>>>>> On Nov 16, 2005, at 6:30 PM, dimitri papadimitriou wrote: >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> adrian, >>>>>>> >>>>>>> could you explain the reasoning for having a TE specific TLV in >>>>>>> the >>>>>>> auto-mesh document with area and AS-wide flooding scope >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> while the TE >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> router cap TLV is restricted to an area flooding scope ? >>>>>>> shouldn't be one way or the other i.e. either restrict all TE >>>>>>> info >>>>>>> area-local or allow for TE router cap TLV with AS-wide >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> flooding scope >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> ? >>>>>>> >>>>>>> note: there is nothing in the TE router cap TLV that would =20 >>>>>>> impact >>>>>>> scaling more than the TE auto-mesh TLV does >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> I guess that the reason for allowing both intra and inter-area >>>>>> flooding scopes for automesh is obvious (we need to have TE LSP >>>>>> mesh >>>>>> within areas and spanning multiple areas). >>>>>> >>>>>> So your question is probably why don't we allow the TE router >>>>>> cap TLV >>>>>> to be flooded across the domain ? As far as I can remember JL >>>>>> already >>>>>> answered this question ... JL, could you forward your email >>>>>> again ? >>>>>> >>>>>> In the meantime, I can answer it: the reason is that such TE node >>>>>> capabilities are used for TE LSP computation which cannot take >>>>>> into >>>>>> account nodes that do not reside in the node's area. >>>>>> >>>>>> Thanks. >>>>>> >>>>>> JP. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> thanks, >>>>>>> - dimitri. >>>>>>> >>>>>>> Adrian Farrel wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Hi, >>>>>>>> We have two immediate milestones to address: >>>>>>>> Oct 05 First version WG I-D for Advertising TE Node >>>>>>>> Capabilities >>>>>>>> in ISIS >>>>>>>> and OSPF >>>>>>>> Oct 05 First version WG I-D for Automatic discovery of >>>>>>>> >>>>>>>> >>>>>>>> >>>>>> >>>>>> MPLS-TE mesh >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>> membership >>>>>>>> There are two personal submissions which address these topics: >>>>>>>> draft-vasseur-ccamp-te-node-cap-01.txt >>>>>>>> draft-vasseur-ccamp-automesh-02.txt >>>>>>>> I propose that we move these into the WG and then kick the =20 >>>>>>>> tires >>>>>>>> thoroughly. >>>>>>>> Opinions please. >>>>>>>> Thanks, >>>>>>>> Adrian >>>>>>>> . >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>> >>>>> >>>>> >>>>> >>>>> . >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>> >>> >> > Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 21 Nov 2005 17:20:22 +0000 Message-ID: <001e01c5eebf$c4e65200$7a1810ac@movaz.com> From: "Igor Bryskin" To: "JP Vasseur" Cc: , , "Adrian Farrel" , "LE ROUX Jean-Louis RD-CORE-LAN" , Subject: Re: IGP Extensions - CCAMP Milestones Date: Mon, 21 Nov 2005 12:19:45 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit JP, Could you give me an example of application that uses AS scope opaque LSAs? Thanks, Igor ----- Original Message ----- From: "JP Vasseur" To: "Igor Bryskin" Cc: ; ; "Adrian Farrel" ; "LE ROUX Jean-Louis RD-CORE-LAN" ; Sent: Monday, November 21, 2005 11:36 AM Subject: Re: IGP Extensions - CCAMP Milestones Hi Igor, On Nov 21, 2005, at 10:13 AM, Igor Bryskin wrote: > Hi JP, > > > > See in-line. > > > > Cheers, > > Igor > > > > ----- Original Message ----- > > From: "JP Vasseur" > > To: "Igor Bryskin" > > Cc: ; ; > "Adrian > Farrel" ; "LE ROUX Jean-Louis RD-CORE-LAN" > ; > > Sent: Sunday, November 20, 2005 9:57 AM > > Subject: Re: IGP Extensions - CCAMP Milestones > > > > Hi Igor, > > On Nov 19, 2005, at 11:16 AM, Igor Bryskin wrote: > > >> Hi everybody, >> >> >> >> I'd like to note that although the AS scope flooding is allowed for >> opaque >> LSAs, in my experience it does not work. >> > > So your experience is different than the one of many people ... > Opaque LSA have been > used for quite a few years without any problem. See RFC2370 (July > 1998) > > >> Imagine that some routing >> controller advertises an AS scope LSA and goes out of service >> quickly after >> that. Controllers outside of the area that the dead controller >> belongs to >> have no way of detecting its death and, therefore, will keep using >> the >> advertising for another 90 min before the LSA times out. >> > > I guess that you mean 60 min (Maxage=60mn, Architectural Constant) - > See RFC2328, but this is not the point, see below. > > >> Note that the >> controllers located within the same area do not have such a problem >> because >> they can always verify the validity of the advertising by trying to >> locate a >> sequence of active adjacencies interconnecting each of them with the >> advertising controller. If they find at least one such a sequence, >> the >> advertising is valid (otherwise, it would be withdrawn); on the >> other hand, >> if no such sequences exist, than advertising is likely to be stale >> and hence >> could not be trusted. The conclusion is that opaque LSAs should >> never be >> flooded within AS, rather, within a single area, and, if there is a >> need for >> the information to be propagated beyond the area boundaries, ABRs >> must relay >> the advertising into other areas (by originating new area-scope >> LSAs). Note >> also that as far as I remember OSPF itself never uses AS scope >> advertisings >> for its own needs. For example, an ASBR does not distribute >> external routes >> learned by BGP from other ASs using AS scope LSAs, rather, the >> routes are >> advertised within a single area and ABRs relay the advertisings >> into other >> areas. >> > > This is not correct. External routes are redistributed with LSA Type > 5 which are > flooded across the entire domain except in stub-area (not generated by > the ABR as type 3 as you mention). > > > > IB>> True, that what is written in RFC2328. well not just written in the RFC but implemented and deployed in OSPF networks for years. > And my contention here is that > if an ASBR advertises LSAs type 5 and dies after that, than OSPF > speakers > outside of the ASBR's area have good likelihood to use stale > external routes > for a considerable period of time. There is no remedy to that (OSPF > speakers > do not use Keep Alive protocol :=). This, however, could be fixed by > avoiding using of AS scope flooding, and that's exactly the reason > why some > OSPF applications that I know of do just that. But this is the > discussion > for OSPF WG, I suggest not argue about that. See below. > There is nothing to fix here. Anyway, see below ... > Anyway, back to the point, one cannot say of course that "Opaque LSA > Type 11 does not work". There are suitable to some application, > this is > all. You can perfectly reply on an opaque LSA Type 11 to learn the > capability of a router which does not reside in the local area and > rely > on another mechanism to detect its liveness. There are several such > examples. > > > > IB>> Let's stick to your example. Why is it better to flood router > capability LSAs across an AS, rather than flood them within a > single area > and have ABRs relay the advertisings into other areas by > originating their > own LSAs? Yes, the AS-scope flooding is simpler. > But what I am suggesting > has the following advantages: > > a) Advertisings of a crashed LSR could be withdrawn from use > by all AS > LSRs immediately after the crash; > > b) Advertisings could be summarized by an ABR providing > scalability > improvements; > OSPF provides an efficient way to flood information across the entire routing domain: opaque LSA Type 11. If the use of such LSA is useful to some applications why not using it ? You highlight two aspects here - Liveness of the capability advertising router: just rely on a liveness protocol if you need to quickly detect a crash of the router - Scalability improvement: this is in fact the opposite ... Think of the extra work required on the ABR to leak TLV in other areas compared to flood a Type 11 LSA. Apparently you do not appreciate the architectural change that this would mean on OSPF. > c) What is more important that policies could be applied on > ABRs wrt to > what information is leaked to external areas. Regretfully, you keep > forgetting about the policy aspects, but in the context of AS-scope > flooding > how can you enforce that an LSR capabilities are advertised into > some areas, > not advertised into some other areas, and advertised in a modified > way into > the third set of areas? Policy is of the utmost importance in many contexts such as Inter-AS/ Providers ... not sure the case of inter-area within a single AS is the case. Now, if you want to propose a new mode of operation for OSPF, you may want to discuss it with the OSPF WG ... We could continue the discussion there ... since it belongs to OSPF. JP. > > > > Igor > > Hope this helps. > > JP. > > > >> >> >> >> The bottom line is that the TLVs described in the draft should be >> of the >> area scope (just like TE LSAs), and hence it is not all that >> important >> whether we use new high level TLVs or sub-TLVs of the TE router cap >> TLV. >> >> >> >> Igor >> >> >> >> >> >> ----- Original Message ----- >> >> From: "dimitri papadimitriou" >> >> To: "Adrian Farrel" >> >> Cc: "LE ROUX Jean-Louis RD-CORE-LAN" >> ; >> "JP Vasseur" ; "Dimitri Papadimitriou" >> ; >> >> Sent: Friday, November 18, 2005 10:57 AM >> >> Subject: Re: IGP Extensions - CCAMP Milestones >> >> >> >> >> >>> adrian >>> >>> i think JL's reply did partially translate the initial concern >>> >>> in brief, there are three well identified TE applications that could >>> make use of the TE node cap TLVs on both intra and inter-area basis: >>> - LSP Stitching edge node capability >>> - Edge nodes connecting/being P2MP TE egresses >>> - TE auto-mesh >>> >>> hence, the question on why keeping separated TLVs as part of the >>> router >>> capability and not consider these as sub-TLVs of the TE router cap >>> TLV >>> this would >>> 1) provide a logical grouping of TE sub-TLVs as part of the same >>> TLV and >>> 2) leave the flexibility of flooding scope on a per application >>> need - >>> >>> note: that the path computation specific sub-TLVs could still be >>> restricted with their current area-scope >>> >>> hope this clarifies the issue, >>> >>> thanks, >>> - dimitri. >>> >>> Adrian Farrel wrote: >>> >>> >>> >>>> If I understand the question it is... >>>> >>>> In draft-ietf-ospf-cap-07.txt introduces the OSPF router >>>> information LSA >>>> and states that this LSA may have type 9, 10 or 11 scope. >>>> >>>> In draft-vasseur-ccamp-te-node-cap-01.txt a new TLV (TE Node >>>> Capability >>>> Descriptor) is added to the OSPF router information LSA. This TLV >>>> (when >>>> generated) MUST be advertised with type 10 scope. JL has given the >>>> >>>> >> reason >> >> >>>> why this is limited to type 10. This reason is, of course, open for >>>> discussion as he says. >>>> >>>> In draft-vasseur-ccamp-automesh-02.txt a new TLV (TE-MESH-GROUP) is >>>> >>>> >> added >> >> >>>> to the OSPF router information LSA. It states that the LSA may be >>>> advertised with type 10 or type 11 scope. JP has given a reason >>>> why you >>>> might want type 11 in addition to type 10. This reason is, of >>>> course, >>>> >>>> >> open >> >> >>>> for discussion. >>>> >>>> An interesting feature is that a router advertising an AS-wide mesh >>>> >>>> >> group >> >> >>>> *and* a TE router capability may require that two OSPF router >>>> >>>> >> information >> >> >>>> LSAs are advertised by the router. >>>> >>>> The language in draft-ietf-ospf-cap-07.txt leans towards a router >>>> >>>> >> sending >> >> >>>> *an* OSPF router information LSA. But nowhere does it say that the >>>> >>>> >> router >> >> >>>> cannot send more than one and in section 2.5 we find... >>>> The originating router MAY advertise >>>> multiple RI LSAs as long as the flooding scopes differ. >>>> >>>> Hope this answers the point. >>>> >>>> Adrian >>>> ----- Original Message ----- >>>> From: "LE ROUX Jean-Louis RD-CORE-LAN" >>>> >>>> To: "JP Vasseur" ; "Dimitri Papadimitriou" >>>> ; "Dimitri Papadimitriou" >>>> >>>> Cc: ; >>>> Sent: Thursday, November 17, 2005 6:47 PM >>>> Subject: RE: IGP Extensions - CCAMP Milestones >>>> >>>> >>>> Hi Dimitri, >>>> >>>> Thanks for the comment. >>>> >>>> As just explained by JP, the TE Node Cap TLV carries topology >>>> related >>>> parameters used as constraints in path computation. The leaking >>>> of such >>>> info across areas sounds useless as LSR TE visibility is limited >>>> to one >>>> area anyway... >>>> But this is, of course, open to discussions. By the way, do you >>>> have any >>>> application in mind where such leaking would be useful? >>>> >>>> Regards, >>>> >>>> JL >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>> -----Message d'origine----- >>>>> De : JP Vasseur [mailto:jvasseur@cisco.com] >>>>> Envoyé : jeudi 17 novembre 2005 16:58 >>>>> À : Dimitri Papadimitriou; Dimitri Papadimitriou >>>>> Cc : zzx-adrian@olddog.co.uk; ccamp@ops.ietf.org; LE ROUX >>>>> Jean-Louis RD-CORE-LAN >>>>> Objet : Re: IGP Extensions - CCAMP Milestones >>>>> >>>>> Hi dimitri, >>>>> >>>>> On Nov 16, 2005, at 6:30 PM, dimitri papadimitriou wrote: >>>>> >>>>> >>>>> >>>>> >>>>>> adrian, >>>>>> >>>>>> could you explain the reasoning for having a TE specific TLV in >>>>>> the >>>>>> auto-mesh document with area and AS-wide flooding scope >>>>>> >>>>>> >>>>> >>>>> while the TE >>>>> >>>>> >>>>> >>>>>> router cap TLV is restricted to an area flooding scope ? >>>>>> shouldn't be one way or the other i.e. either restrict all TE >>>>>> info >>>>>> area-local or allow for TE router cap TLV with AS-wide >>>>>> >>>>>> >>>>> >>>>> flooding scope >>>>> >>>>> >>>>> >>>>>> ? >>>>>> >>>>>> note: there is nothing in the TE router cap TLV that would impact >>>>>> scaling more than the TE auto-mesh TLV does >>>>>> >>>>>> >>>>>> >>>>> >>>>> I guess that the reason for allowing both intra and inter-area >>>>> flooding scopes for automesh is obvious (we need to have TE LSP >>>>> mesh >>>>> within areas and spanning multiple areas). >>>>> >>>>> So your question is probably why don't we allow the TE router >>>>> cap TLV >>>>> to be flooded across the domain ? As far as I can remember JL >>>>> already >>>>> answered this question ... JL, could you forward your email >>>>> again ? >>>>> >>>>> In the meantime, I can answer it: the reason is that such TE node >>>>> capabilities are used for TE LSP computation which cannot take >>>>> into >>>>> account nodes that do not reside in the node's area. >>>>> >>>>> Thanks. >>>>> >>>>> JP. >>>>> >>>>> >>>>> >>>>> >>>>>> thanks, >>>>>> - dimitri. >>>>>> >>>>>> Adrian Farrel wrote: >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> Hi, >>>>>>> We have two immediate milestones to address: >>>>>>> Oct 05 First version WG I-D for Advertising TE Node >>>>>>> Capabilities >>>>>>> in ISIS >>>>>>> and OSPF >>>>>>> Oct 05 First version WG I-D for Automatic discovery of >>>>>>> >>>>>>> >>>>> >>>>> MPLS-TE mesh >>>>> >>>>> >>>>> >>>>>>> membership >>>>>>> There are two personal submissions which address these topics: >>>>>>> draft-vasseur-ccamp-te-node-cap-01.txt >>>>>>> draft-vasseur-ccamp-automesh-02.txt >>>>>>> I propose that we move these into the WG and then kick the tires >>>>>>> thoroughly. >>>>>>> Opinions please. >>>>>>> Thanks, >>>>>>> Adrian >>>>>>> . >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>> >>>> >>>> >>>> >>>> . >>>> >>>> >>>> >>> >>> >> > Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 21 Nov 2005 16:38:01 +0000 Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <8337AD85-1FA6-4F01-9993-7DEFE24ED4FB@cisco.com> Cc: , , "Adrian Farrel" , "LE ROUX Jean-Louis RD-CORE-LAN" , Content-Transfer-Encoding: quoted-printable From: JP Vasseur Subject: Re: IGP Extensions - CCAMP Milestones Date: Mon, 21 Nov 2005 11:36:19 -0500 To: Igor Bryskin Hi Igor, On Nov 21, 2005, at 10:13 AM, Igor Bryskin wrote: > Hi JP, > > > > See in-line. > > > > Cheers, > > Igor > > > > ----- Original Message ----- > > From: "JP Vasseur" > > To: "Igor Bryskin" > > Cc: ; ; =20 > "Adrian > Farrel" ; "LE ROUX Jean-Louis RD-CORE-LAN" > ; > > Sent: Sunday, November 20, 2005 9:57 AM > > Subject: Re: IGP Extensions - CCAMP Milestones > > > > Hi Igor, > > On Nov 19, 2005, at 11:16 AM, Igor Bryskin wrote: > > >> Hi everybody, >> >> >> >> I'd like to note that although the AS scope flooding is allowed for >> opaque >> LSAs, in my experience it does not work. >> > > So your experience is different than the one of many people ... > Opaque LSA have been > used for quite a few years without any problem. See RFC2370 (July =20 > 1998) > > >> Imagine that some routing >> controller advertises an AS scope LSA and goes out of service >> quickly after >> that. Controllers outside of the area that the dead controller >> belongs to >> have no way of detecting its death and, therefore, will keep using =20= >> the >> advertising for another 90 min before the LSA times out. >> > > I guess that you mean 60 min (Maxage=3D60mn, Architectural Constant) - > See RFC2328, but this is not the point, see below. > > >> Note that the >> controllers located within the same area do not have such a problem >> because >> they can always verify the validity of the advertising by trying to >> locate a >> sequence of active adjacencies interconnecting each of them with the >> advertising controller. If they find at least one such a sequence, =20= >> the >> advertising is valid (otherwise, it would be withdrawn); on the >> other hand, >> if no such sequences exist, than advertising is likely to be stale >> and hence >> could not be trusted. The conclusion is that opaque LSAs should >> never be >> flooded within AS, rather, within a single area, and, if there is a >> need for >> the information to be propagated beyond the area boundaries, ABRs >> must relay >> the advertising into other areas (by originating new area-scope >> LSAs). Note >> also that as far as I remember OSPF itself never uses AS scope >> advertisings >> for its own needs. For example, an ASBR does not distribute >> external routes >> learned by BGP from other ASs using AS scope LSAs, rather, the >> routes are >> advertised within a single area and ABRs relay the advertisings >> into other >> areas. >> > > This is not correct. External routes are redistributed with LSA Type > 5 which are > flooded across the entire domain except in stub-area (not generated by > the ABR as type 3 as you mention). > > > > IB>> True, that what is written in RFC2328. well not just written in the RFC but implemented and deployed in OSPF =20= networks for years. > And my contention here is that > if an ASBR advertises LSAs type 5 and dies after that, than OSPF =20 > speakers > outside of the ASBR's area have good likelihood to use stale =20 > external routes > for a considerable period of time. There is no remedy to that (OSPF =20= > speakers > do not use Keep Alive protocol :=3D). This, however, could be fixed by > avoiding using of AS scope flooding, and that's exactly the reason =20 > why some > OSPF applications that I know of do just that. But this is the =20 > discussion > for OSPF WG, I suggest not argue about that. See below. > There is nothing to fix here. Anyway, see below ... > Anyway, back to the point, one cannot say of course that "Opaque LSA > Type 11 does not work". There are suitable to some application, =20 > this is > all. You can perfectly reply on an opaque LSA Type 11 to learn the > capability of a router which does not reside in the local area and =20 > rely > on another mechanism to detect its liveness. There are several such > examples. > > > > IB>> Let's stick to your example. Why is it better to flood router > capability LSAs across an AS, rather than flood them within a =20 > single area > and have ABRs relay the advertisings into other areas by =20 > originating their > own LSAs? Yes, the AS-scope flooding is simpler. > But what I am suggesting > has the following advantages: > > a) Advertisings of a crashed LSR could be withdrawn from use =20 > by all AS > LSRs immediately after the crash; > > b) Advertisings could be summarized by an ABR providing =20 > scalability > improvements; > OSPF provides an efficient way to flood information across the entire =20= routing domain: opaque LSA Type 11. If the use of such LSA is useful =20 to some applications why not using it ? You highlight two aspects here - Liveness of the capability advertising router: just rely on a =20 liveness protocol if you need to quickly detect a crash of the router - Scalability improvement: this is in fact the opposite ... Think of =20 the extra work required on the ABR to leak TLV in other areas =20 compared to flood a Type 11 LSA. Apparently you do not appreciate the =20= architectural change that this would mean on OSPF. > c) What is more important that policies could be applied on =20 > ABRs wrt to > what information is leaked to external areas. Regretfully, you keep > forgetting about the policy aspects, but in the context of AS-scope =20= > flooding > how can you enforce that an LSR capabilities are advertised into =20 > some areas, > not advertised into some other areas, and advertised in a modified =20 > way into > the third set of areas? Policy is of the utmost importance in many contexts such as Inter-AS/=20 Providers ... not sure the case of inter-area within a single AS is =20 the case. Now, if you want to propose a new mode of operation for =20 OSPF, you may want to discuss it with the OSPF WG ... We could =20 continue the discussion there ... since it belongs to OSPF. JP. > > > > Igor > > Hope this helps. > > JP. > > > >> >> >> >> The bottom line is that the TLVs described in the draft should be >> of the >> area scope (just like TE LSAs), and hence it is not all that =20 >> important >> whether we use new high level TLVs or sub-TLVs of the TE router cap >> TLV. >> >> >> >> Igor >> >> >> >> >> >> ----- Original Message ----- >> >> From: "dimitri papadimitriou" >> >> To: "Adrian Farrel" >> >> Cc: "LE ROUX Jean-Louis RD-CORE-LAN" >> ; >> "JP Vasseur" ; "Dimitri Papadimitriou" >> ; >> >> Sent: Friday, November 18, 2005 10:57 AM >> >> Subject: Re: IGP Extensions - CCAMP Milestones >> >> >> >> >> >>> adrian >>> >>> i think JL's reply did partially translate the initial concern >>> >>> in brief, there are three well identified TE applications that could >>> make use of the TE node cap TLVs on both intra and inter-area basis: >>> - LSP Stitching edge node capability >>> - Edge nodes connecting/being P2MP TE egresses >>> - TE auto-mesh >>> >>> hence, the question on why keeping separated TLVs as part of the >>> router >>> capability and not consider these as sub-TLVs of the TE router cap >>> TLV >>> this would >>> 1) provide a logical grouping of TE sub-TLVs as part of the same >>> TLV and >>> 2) leave the flexibility of flooding scope on a per application >>> need - >>> >>> note: that the path computation specific sub-TLVs could still be >>> restricted with their current area-scope >>> >>> hope this clarifies the issue, >>> >>> thanks, >>> - dimitri. >>> >>> Adrian Farrel wrote: >>> >>> >>> >>>> If I understand the question it is... >>>> >>>> In draft-ietf-ospf-cap-07.txt introduces the OSPF router >>>> information LSA >>>> and states that this LSA may have type 9, 10 or 11 scope. >>>> >>>> In draft-vasseur-ccamp-te-node-cap-01.txt a new TLV (TE Node >>>> Capability >>>> Descriptor) is added to the OSPF router information LSA. This TLV >>>> (when >>>> generated) MUST be advertised with type 10 scope. JL has given the >>>> >>>> >> reason >> >> >>>> why this is limited to type 10. This reason is, of course, open for >>>> discussion as he says. >>>> >>>> In draft-vasseur-ccamp-automesh-02.txt a new TLV (TE-MESH-GROUP) is >>>> >>>> >> added >> >> >>>> to the OSPF router information LSA. It states that the LSA may be >>>> advertised with type 10 or type 11 scope. JP has given a reason >>>> why you >>>> might want type 11 in addition to type 10. This reason is, of >>>> course, >>>> >>>> >> open >> >> >>>> for discussion. >>>> >>>> An interesting feature is that a router advertising an AS-wide mesh >>>> >>>> >> group >> >> >>>> *and* a TE router capability may require that two OSPF router >>>> >>>> >> information >> >> >>>> LSAs are advertised by the router. >>>> >>>> The language in draft-ietf-ospf-cap-07.txt leans towards a router >>>> >>>> >> sending >> >> >>>> *an* OSPF router information LSA. But nowhere does it say that the >>>> >>>> >> router >> >> >>>> cannot send more than one and in section 2.5 we find... >>>> The originating router MAY advertise >>>> multiple RI LSAs as long as the flooding scopes differ. >>>> >>>> Hope this answers the point. >>>> >>>> Adrian >>>> ----- Original Message ----- >>>> From: "LE ROUX Jean-Louis RD-CORE-LAN" >>>> >>>> To: "JP Vasseur" ; "Dimitri Papadimitriou" >>>> ; "Dimitri Papadimitriou" >>>> >>>> Cc: ; >>>> Sent: Thursday, November 17, 2005 6:47 PM >>>> Subject: RE: IGP Extensions - CCAMP Milestones >>>> >>>> >>>> Hi Dimitri, >>>> >>>> Thanks for the comment. >>>> >>>> As just explained by JP, the TE Node Cap TLV carries topology >>>> related >>>> parameters used as constraints in path computation. The leaking >>>> of such >>>> info across areas sounds useless as LSR TE visibility is limited >>>> to one >>>> area anyway... >>>> But this is, of course, open to discussions. By the way, do you >>>> have any >>>> application in mind where such leaking would be useful? >>>> >>>> Regards, >>>> >>>> JL >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>> -----Message d'origine----- >>>>> De : JP Vasseur [mailto:jvasseur@cisco.com] >>>>> Envoy=E9 : jeudi 17 novembre 2005 16:58 >>>>> =C0 : Dimitri Papadimitriou; Dimitri Papadimitriou >>>>> Cc : zzx-adrian@olddog.co.uk; ccamp@ops.ietf.org; LE ROUX >>>>> Jean-Louis RD-CORE-LAN >>>>> Objet : Re: IGP Extensions - CCAMP Milestones >>>>> >>>>> Hi dimitri, >>>>> >>>>> On Nov 16, 2005, at 6:30 PM, dimitri papadimitriou wrote: >>>>> >>>>> >>>>> >>>>> >>>>>> adrian, >>>>>> >>>>>> could you explain the reasoning for having a TE specific TLV in >>>>>> the >>>>>> auto-mesh document with area and AS-wide flooding scope >>>>>> >>>>>> >>>>> >>>>> while the TE >>>>> >>>>> >>>>> >>>>>> router cap TLV is restricted to an area flooding scope ? >>>>>> shouldn't be one way or the other i.e. either restrict all TE =20 >>>>>> info >>>>>> area-local or allow for TE router cap TLV with AS-wide >>>>>> >>>>>> >>>>> >>>>> flooding scope >>>>> >>>>> >>>>> >>>>>> ? >>>>>> >>>>>> note: there is nothing in the TE router cap TLV that would impact >>>>>> scaling more than the TE auto-mesh TLV does >>>>>> >>>>>> >>>>>> >>>>> >>>>> I guess that the reason for allowing both intra and inter-area >>>>> flooding scopes for automesh is obvious (we need to have TE LSP >>>>> mesh >>>>> within areas and spanning multiple areas). >>>>> >>>>> So your question is probably why don't we allow the TE router >>>>> cap TLV >>>>> to be flooded across the domain ? As far as I can remember JL >>>>> already >>>>> answered this question ... JL, could you forward your email =20 >>>>> again ? >>>>> >>>>> In the meantime, I can answer it: the reason is that such TE node >>>>> capabilities are used for TE LSP computation which cannot take =20 >>>>> into >>>>> account nodes that do not reside in the node's area. >>>>> >>>>> Thanks. >>>>> >>>>> JP. >>>>> >>>>> >>>>> >>>>> >>>>>> thanks, >>>>>> - dimitri. >>>>>> >>>>>> Adrian Farrel wrote: >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> Hi, >>>>>>> We have two immediate milestones to address: >>>>>>> Oct 05 First version WG I-D for Advertising TE Node =20 >>>>>>> Capabilities >>>>>>> in ISIS >>>>>>> and OSPF >>>>>>> Oct 05 First version WG I-D for Automatic discovery of >>>>>>> >>>>>>> >>>>> >>>>> MPLS-TE mesh >>>>> >>>>> >>>>> >>>>>>> membership >>>>>>> There are two personal submissions which address these topics: >>>>>>> draft-vasseur-ccamp-te-node-cap-01.txt >>>>>>> draft-vasseur-ccamp-automesh-02.txt >>>>>>> I propose that we move these into the WG and then kick the tires >>>>>>> thoroughly. >>>>>>> Opinions please. >>>>>>> Thanks, >>>>>>> Adrian >>>>>>> . >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>> >>>> >>>> >>>> >>>> . >>>> >>>> >>>> >>> >>> >> > Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 21 Nov 2005 15:21:20 +0000 Message-ID: <00b101c5eeaf$32c0a2a0$7a1810ac@movaz.com> From: "Igor Bryskin" To: , , "JP Vasseur" Cc: , "Adrian Farrel" , "LE ROUX Jean-Louis RD-CORE-LAN" , Subject: Re: IGP Extensions - CCAMP Milestones Date: Mon, 21 Nov 2005 10:21:08 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Dimitri, See my reply to JP. Also see below. ----- Original Message ----- From: "dimitri papadimitriou" To: "JP Vasseur" Cc: "Igor Bryskin" ; ; "Adrian Farrel" ; "LE ROUX Jean-Louis RD-CORE-LAN" ; Sent: Sunday, November 20, 2005 2:40 PM Subject: Re: IGP Extensions - CCAMP Milestones > hi jp, > > indeed, i don't really understand the issue brought up by igor; > > in the present case, one should also underline that, the information > distributed across the OSPF domain using opaque LSAs, is *indirectly* > used by e.g. TE applications (note: RFC2370 allows for this information > to be used directly by OSPF but i think we're not discussing this > alternative) > > this means that these e.g. TE applications can in case of control engine > failure detect this failure and trigger any necessary action in order to > avoid the behaviour described by igor IB>> Two points here: a) all TE LSAs are of the area scope; b) A TE application can detect a control engine failure only within one area. It does not help for LSRs located outside of this area because no LSR (including ABR) is allowed to withdraw somebody else's LSAs - the LSAs could be withdrawn or modified by the LSR that has originated them. Igor > > thanks, > - dimitri. > > JP Vasseur wrote: > > Hi Igor, > > > > On Nov 19, 2005, at 11:16 AM, Igor Bryskin wrote: > > > >> Hi everybody, > >> > >> > >> > >> I'd like to note that although the AS scope flooding is allowed for > >> opaque > >> LSAs, in my experience it does not work. > > > > > > So your experience is different than the one of many people ... Opaque > > LSA have been > > used for quite a few years without any problem. See RFC2370 (July 1998) > > > >> Imagine that some routing > >> controller advertises an AS scope LSA and goes out of service quickly > >> after > >> that. Controllers outside of the area that the dead controller > >> belongs to > >> have no way of detecting its death and, therefore, will keep using the > >> advertising for another 90 min before the LSA times out. > > > > > > I guess that you mean 60 min (Maxage=60mn, Architectural Constant) - > > See RFC2328, but this is not the point, see below. > > > >> Note that the > >> controllers located within the same area do not have such a problem > >> because > >> they can always verify the validity of the advertising by trying to > >> locate a > >> sequence of active adjacencies interconnecting each of them with the > >> advertising controller. If they find at least one such a sequence, the > >> advertising is valid (otherwise, it would be withdrawn); on the other > >> hand, > >> if no such sequences exist, than advertising is likely to be stale > >> and hence > >> could not be trusted. The conclusion is that opaque LSAs should never be > >> flooded within AS, rather, within a single area, and, if there is a > >> need for > >> the information to be propagated beyond the area boundaries, ABRs > >> must relay > >> the advertising into other areas (by originating new area-scope > >> LSAs). Note > >> also that as far as I remember OSPF itself never uses AS scope > >> advertisings > >> for its own needs. For example, an ASBR does not distribute external > >> routes > >> learned by BGP from other ASs using AS scope LSAs, rather, the routes > >> are > >> advertised within a single area and ABRs relay the advertisings into > >> other > >> areas. > > > > > > This is not correct. External routes are redistributed with LSA Type 5 > > which are > > flooded across the entire domain except in stub-area (not generated by > > the ABR as type 3 as you mention). > > > > Anyway, back to the point, one cannot say of course that "Opaque LSA > > Type 11 does not work". There are suitable to some application, this is > > all. You can perfectly reply on an opaque LSA Type 11 to learn the > > capability of a router which does not reside in the local area and rely > > on another mechanism to detect its liveness. There are several such > > examples. > > > > Hope this helps. > > > > JP. > > > > > >> > >> > >> > >> The bottom line is that the TLVs described in the draft should be of the > >> area scope (just like TE LSAs), and hence it is not all that important > >> whether we use new high level TLVs or sub-TLVs of the TE router cap TLV. > >> > >> > >> > >> Igor > >> > >> > >> > >> > >> > >> ----- Original Message ----- > >> > >> From: "dimitri papadimitriou" > >> > >> To: "Adrian Farrel" > >> > >> Cc: "LE ROUX Jean-Louis RD-CORE-LAN" > >> ; > >> "JP Vasseur" ; "Dimitri Papadimitriou" > >> ; > >> > >> Sent: Friday, November 18, 2005 10:57 AM > >> > >> Subject: Re: IGP Extensions - CCAMP Milestones > >> > >> > >> > >> > >>> adrian > >>> > >>> i think JL's reply did partially translate the initial concern > >>> > >>> in brief, there are three well identified TE applications that could > >>> make use of the TE node cap TLVs on both intra and inter-area basis: > >>> - LSP Stitching edge node capability > >>> - Edge nodes connecting/being P2MP TE egresses > >>> - TE auto-mesh > >>> > >>> hence, the question on why keeping separated TLVs as part of the router > >>> capability and not consider these as sub-TLVs of the TE router cap TLV > >>> this would > >>> 1) provide a logical grouping of TE sub-TLVs as part of the same TLV > >>> and > >>> 2) leave the flexibility of flooding scope on a per application need - > >>> > >>> note: that the path computation specific sub-TLVs could still be > >>> restricted with their current area-scope > >>> > >>> hope this clarifies the issue, > >>> > >>> thanks, > >>> - dimitri. > >>> > >>> Adrian Farrel wrote: > >>> > >>> > >>>> If I understand the question it is... > >>>> > >>>> In draft-ietf-ospf-cap-07.txt introduces the OSPF router > >>>> information LSA > >>>> and states that this LSA may have type 9, 10 or 11 scope. > >>>> > >>>> In draft-vasseur-ccamp-te-node-cap-01.txt a new TLV (TE Node > >>>> Capability > >>>> Descriptor) is added to the OSPF router information LSA. This TLV > >>>> (when > >>>> generated) MUST be advertised with type 10 scope. JL has given the > >>>> > >> reason > >> > >>>> why this is limited to type 10. This reason is, of course, open for > >>>> discussion as he says. > >>>> > >>>> In draft-vasseur-ccamp-automesh-02.txt a new TLV (TE-MESH-GROUP) is > >>>> > >> added > >> > >>>> to the OSPF router information LSA. It states that the LSA may be > >>>> advertised with type 10 or type 11 scope. JP has given a reason why > >>>> you > >>>> might want type 11 in addition to type 10. This reason is, of course, > >>>> > >> open > >> > >>>> for discussion. > >>>> > >>>> An interesting feature is that a router advertising an AS-wide mesh > >>>> > >> group > >> > >>>> *and* a TE router capability may require that two OSPF router > >>>> > >> information > >> > >>>> LSAs are advertised by the router. > >>>> > >>>> The language in draft-ietf-ospf-cap-07.txt leans towards a router > >>>> > >> sending > >> > >>>> *an* OSPF router information LSA. But nowhere does it say that the > >>>> > >> router > >> > >>>> cannot send more than one and in section 2.5 we find... > >>>> The originating router MAY advertise > >>>> multiple RI LSAs as long as the flooding scopes differ. > >>>> > >>>> Hope this answers the point. > >>>> > >>>> Adrian > >>>> ----- Original Message ----- > >>>> From: "LE ROUX Jean-Louis RD-CORE-LAN" > >>>> > >>>> To: "JP Vasseur" ; "Dimitri Papadimitriou" > >>>> ; "Dimitri Papadimitriou" > >>>> > >>>> Cc: ; > >>>> Sent: Thursday, November 17, 2005 6:47 PM > >>>> Subject: RE: IGP Extensions - CCAMP Milestones > >>>> > >>>> > >>>> Hi Dimitri, > >>>> > >>>> Thanks for the comment. > >>>> > >>>> As just explained by JP, the TE Node Cap TLV carries topology related > >>>> parameters used as constraints in path computation. The leaking of > >>>> such > >>>> info across areas sounds useless as LSR TE visibility is limited to > >>>> one > >>>> area anyway... > >>>> But this is, of course, open to discussions. By the way, do you > >>>> have any > >>>> application in mind where such leaking would be useful? > >>>> > >>>> Regards, > >>>> > >>>> JL > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>>> -----Message d'origine----- > >>>>> De : JP Vasseur [mailto:jvasseur@cisco.com] > >>>>> Envoyé : jeudi 17 novembre 2005 16:58 > >>>>> À : Dimitri Papadimitriou; Dimitri Papadimitriou > >>>>> Cc : zzx-adrian@olddog.co.uk; ccamp@ops.ietf.org; LE ROUX > >>>>> Jean-Louis RD-CORE-LAN > >>>>> Objet : Re: IGP Extensions - CCAMP Milestones > >>>>> > >>>>> Hi dimitri, > >>>>> > >>>>> On Nov 16, 2005, at 6:30 PM, dimitri papadimitriou wrote: > >>>>> > >>>>> > >>>>> > >>>>>> adrian, > >>>>>> > >>>>>> could you explain the reasoning for having a TE specific TLV in the > >>>>>> auto-mesh document with area and AS-wide flooding scope > >>>>>> > >>>>> > >>>>> while the TE > >>>>> > >>>>> > >>>>>> router cap TLV is restricted to an area flooding scope ? > >>>>>> shouldn't be one way or the other i.e. either restrict all TE info > >>>>>> area-local or allow for TE router cap TLV with AS-wide > >>>>>> > >>>>> > >>>>> flooding scope > >>>>> > >>>>> > >>>>>> ? > >>>>>> > >>>>>> note: there is nothing in the TE router cap TLV that would impact > >>>>>> scaling more than the TE auto-mesh TLV does > >>>>>> > >>>>>> > >>>>> > >>>>> I guess that the reason for allowing both intra and inter-area > >>>>> flooding scopes for automesh is obvious (we need to have TE LSP mesh > >>>>> within areas and spanning multiple areas). > >>>>> > >>>>> So your question is probably why don't we allow the TE router > >>>>> cap TLV > >>>>> to be flooded across the domain ? As far as I can remember JL > >>>>> already > >>>>> answered this question ... JL, could you forward your email again ? > >>>>> > >>>>> In the meantime, I can answer it: the reason is that such TE node > >>>>> capabilities are used for TE LSP computation which cannot take into > >>>>> account nodes that do not reside in the node's area. > >>>>> > >>>>> Thanks. > >>>>> > >>>>> JP. > >>>>> > >>>>> > >>>>> > >>>>>> thanks, > >>>>>> - dimitri. > >>>>>> > >>>>>> Adrian Farrel wrote: > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>>> Hi, > >>>>>>> We have two immediate milestones to address: > >>>>>>> Oct 05 First version WG I-D for Advertising TE Node Capabilities > >>>>>>> in ISIS > >>>>>>> and OSPF > >>>>>>> Oct 05 First version WG I-D for Automatic discovery of > >>>>>>> > >>>>> > >>>>> MPLS-TE mesh > >>>>> > >>>>> > >>>>>>> membership > >>>>>>> There are two personal submissions which address these topics: > >>>>>>> draft-vasseur-ccamp-te-node-cap-01.txt > >>>>>>> draft-vasseur-ccamp-automesh-02.txt > >>>>>>> I propose that we move these into the WG and then kick the tires > >>>>>>> thoroughly. > >>>>>>> Opinions please. > >>>>>>> Thanks, > >>>>>>> Adrian > >>>>>>> . > >>>>>>> > >>>>>> > >>>>>> > >>>> > >>>> > >>>> > >>>> > >>>> . > >>>> > >>>> > >>> > >> > > > > > > . > > > Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 21 Nov 2005 15:15:36 +0000 Message-ID: <00aa01c5eeae$31737ea0$7a1810ac@movaz.com> From: "Igor Bryskin" To: "JP Vasseur" Cc: , , "Adrian Farrel" , "LE ROUX Jean-Louis RD-CORE-LAN" , Subject: Re: IGP Extensions - CCAMP Milestones Date: Mon, 21 Nov 2005 10:13:56 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Hi JP, See in-line. Cheers, Igor ----- Original Message ----- From: "JP Vasseur" To: "Igor Bryskin" Cc: ; ; "Adrian Farrel" ; "LE ROUX Jean-Louis RD-CORE-LAN" ; Sent: Sunday, November 20, 2005 9:57 AM Subject: Re: IGP Extensions - CCAMP Milestones Hi Igor, On Nov 19, 2005, at 11:16 AM, Igor Bryskin wrote: > Hi everybody, > > > > I'd like to note that although the AS scope flooding is allowed for > opaque > LSAs, in my experience it does not work. So your experience is different than the one of many people ... Opaque LSA have been used for quite a few years without any problem. See RFC2370 (July 1998) > Imagine that some routing > controller advertises an AS scope LSA and goes out of service > quickly after > that. Controllers outside of the area that the dead controller > belongs to > have no way of detecting its death and, therefore, will keep using the > advertising for another 90 min before the LSA times out. I guess that you mean 60 min (Maxage=60mn, Architectural Constant) - See RFC2328, but this is not the point, see below. > Note that the > controllers located within the same area do not have such a problem > because > they can always verify the validity of the advertising by trying to > locate a > sequence of active adjacencies interconnecting each of them with the > advertising controller. If they find at least one such a sequence, the > advertising is valid (otherwise, it would be withdrawn); on the > other hand, > if no such sequences exist, than advertising is likely to be stale > and hence > could not be trusted. The conclusion is that opaque LSAs should > never be > flooded within AS, rather, within a single area, and, if there is a > need for > the information to be propagated beyond the area boundaries, ABRs > must relay > the advertising into other areas (by originating new area-scope > LSAs). Note > also that as far as I remember OSPF itself never uses AS scope > advertisings > for its own needs. For example, an ASBR does not distribute > external routes > learned by BGP from other ASs using AS scope LSAs, rather, the > routes are > advertised within a single area and ABRs relay the advertisings > into other > areas. This is not correct. External routes are redistributed with LSA Type 5 which are flooded across the entire domain except in stub-area (not generated by the ABR as type 3 as you mention). IB>> True, that what is written in RFC2328. And my contention here is that if an ASBR advertises LSAs type 5 and dies after that, than OSPF speakers outside of the ASBR's area have good likelihood to use stale external routes for a considerable period of time. There is no remedy to that (OSPF speakers do not use Keep Alive protocol :=). This, however, could be fixed by avoiding using of AS scope flooding, and that's exactly the reason why some OSPF applications that I know of do just that. But this is the discussion for OSPF WG, I suggest not argue about that. See below. Anyway, back to the point, one cannot say of course that "Opaque LSA Type 11 does not work". There are suitable to some application, this is all. You can perfectly reply on an opaque LSA Type 11 to learn the capability of a router which does not reside in the local area and rely on another mechanism to detect its liveness. There are several such examples. IB>> Let's stick to your example. Why is it better to flood router capability LSAs across an AS, rather than flood them within a single area and have ABRs relay the advertisings into other areas by originating their own LSAs? Yes, the AS-scope flooding is simpler. But what I am suggesting has the following advantages: a) Advertisings of a crashed LSR could be withdrawn from use by all AS LSRs immediately after the crash; b) Advertisings could be summarized by an ABR providing scalability improvements; c) What is more important that policies could be applied on ABRs wrt to what information is leaked to external areas. Regretfully, you keep forgetting about the policy aspects, but in the context of AS-scope flooding how can you enforce that an LSR capabilities are advertised into some areas, not advertised into some other areas, and advertised in a modified way into the third set of areas? Igor Hope this helps. JP. > > > > The bottom line is that the TLVs described in the draft should be > of the > area scope (just like TE LSAs), and hence it is not all that important > whether we use new high level TLVs or sub-TLVs of the TE router cap > TLV. > > > > Igor > > > > > > ----- Original Message ----- > > From: "dimitri papadimitriou" > > To: "Adrian Farrel" > > Cc: "LE ROUX Jean-Louis RD-CORE-LAN" > ; > "JP Vasseur" ; "Dimitri Papadimitriou" > ; > > Sent: Friday, November 18, 2005 10:57 AM > > Subject: Re: IGP Extensions - CCAMP Milestones > > > > >> adrian >> >> i think JL's reply did partially translate the initial concern >> >> in brief, there are three well identified TE applications that could >> make use of the TE node cap TLVs on both intra and inter-area basis: >> - LSP Stitching edge node capability >> - Edge nodes connecting/being P2MP TE egresses >> - TE auto-mesh >> >> hence, the question on why keeping separated TLVs as part of the >> router >> capability and not consider these as sub-TLVs of the TE router cap >> TLV >> this would >> 1) provide a logical grouping of TE sub-TLVs as part of the same >> TLV and >> 2) leave the flexibility of flooding scope on a per application >> need - >> >> note: that the path computation specific sub-TLVs could still be >> restricted with their current area-scope >> >> hope this clarifies the issue, >> >> thanks, >> - dimitri. >> >> Adrian Farrel wrote: >> >> >>> If I understand the question it is... >>> >>> In draft-ietf-ospf-cap-07.txt introduces the OSPF router >>> information LSA >>> and states that this LSA may have type 9, 10 or 11 scope. >>> >>> In draft-vasseur-ccamp-te-node-cap-01.txt a new TLV (TE Node >>> Capability >>> Descriptor) is added to the OSPF router information LSA. This TLV >>> (when >>> generated) MUST be advertised with type 10 scope. JL has given the >>> > reason > >>> why this is limited to type 10. This reason is, of course, open for >>> discussion as he says. >>> >>> In draft-vasseur-ccamp-automesh-02.txt a new TLV (TE-MESH-GROUP) is >>> > added > >>> to the OSPF router information LSA. It states that the LSA may be >>> advertised with type 10 or type 11 scope. JP has given a reason >>> why you >>> might want type 11 in addition to type 10. This reason is, of >>> course, >>> > open > >>> for discussion. >>> >>> An interesting feature is that a router advertising an AS-wide mesh >>> > group > >>> *and* a TE router capability may require that two OSPF router >>> > information > >>> LSAs are advertised by the router. >>> >>> The language in draft-ietf-ospf-cap-07.txt leans towards a router >>> > sending > >>> *an* OSPF router information LSA. But nowhere does it say that the >>> > router > >>> cannot send more than one and in section 2.5 we find... >>> The originating router MAY advertise >>> multiple RI LSAs as long as the flooding scopes differ. >>> >>> Hope this answers the point. >>> >>> Adrian >>> ----- Original Message ----- >>> From: "LE ROUX Jean-Louis RD-CORE-LAN" >>> >>> To: "JP Vasseur" ; "Dimitri Papadimitriou" >>> ; "Dimitri Papadimitriou" >>> >>> Cc: ; >>> Sent: Thursday, November 17, 2005 6:47 PM >>> Subject: RE: IGP Extensions - CCAMP Milestones >>> >>> >>> Hi Dimitri, >>> >>> Thanks for the comment. >>> >>> As just explained by JP, the TE Node Cap TLV carries topology >>> related >>> parameters used as constraints in path computation. The leaking >>> of such >>> info across areas sounds useless as LSR TE visibility is limited >>> to one >>> area anyway... >>> But this is, of course, open to discussions. By the way, do you >>> have any >>> application in mind where such leaking would be useful? >>> >>> Regards, >>> >>> JL >>> >>> >>> >>> >>> >>> >>> >>> >>>> -----Message d'origine----- >>>> De : JP Vasseur [mailto:jvasseur@cisco.com] >>>> Envoyé : jeudi 17 novembre 2005 16:58 >>>> À : Dimitri Papadimitriou; Dimitri Papadimitriou >>>> Cc : zzx-adrian@olddog.co.uk; ccamp@ops.ietf.org; LE ROUX >>>> Jean-Louis RD-CORE-LAN >>>> Objet : Re: IGP Extensions - CCAMP Milestones >>>> >>>> Hi dimitri, >>>> >>>> On Nov 16, 2005, at 6:30 PM, dimitri papadimitriou wrote: >>>> >>>> >>>> >>>>> adrian, >>>>> >>>>> could you explain the reasoning for having a TE specific TLV in >>>>> the >>>>> auto-mesh document with area and AS-wide flooding scope >>>>> >>>> >>>> while the TE >>>> >>>> >>>>> router cap TLV is restricted to an area flooding scope ? >>>>> shouldn't be one way or the other i.e. either restrict all TE info >>>>> area-local or allow for TE router cap TLV with AS-wide >>>>> >>>> >>>> flooding scope >>>> >>>> >>>>> ? >>>>> >>>>> note: there is nothing in the TE router cap TLV that would impact >>>>> scaling more than the TE auto-mesh TLV does >>>>> >>>>> >>>> >>>> I guess that the reason for allowing both intra and inter-area >>>> flooding scopes for automesh is obvious (we need to have TE LSP >>>> mesh >>>> within areas and spanning multiple areas). >>>> >>>> So your question is probably why don't we allow the TE router >>>> cap TLV >>>> to be flooded across the domain ? As far as I can remember JL >>>> already >>>> answered this question ... JL, could you forward your email again ? >>>> >>>> In the meantime, I can answer it: the reason is that such TE node >>>> capabilities are used for TE LSP computation which cannot take into >>>> account nodes that do not reside in the node's area. >>>> >>>> Thanks. >>>> >>>> JP. >>>> >>>> >>>> >>>>> thanks, >>>>> - dimitri. >>>>> >>>>> Adrian Farrel wrote: >>>>> >>>>> >>>>> >>>>> >>>>>> Hi, >>>>>> We have two immediate milestones to address: >>>>>> Oct 05 First version WG I-D for Advertising TE Node Capabilities >>>>>> in ISIS >>>>>> and OSPF >>>>>> Oct 05 First version WG I-D for Automatic discovery of >>>>>> >>>> >>>> MPLS-TE mesh >>>> >>>> >>>>>> membership >>>>>> There are two personal submissions which address these topics: >>>>>> draft-vasseur-ccamp-te-node-cap-01.txt >>>>>> draft-vasseur-ccamp-automesh-02.txt >>>>>> I propose that we move these into the WG and then kick the tires >>>>>> thoroughly. >>>>>> Opinions please. >>>>>> Thanks, >>>>>> Adrian >>>>>> . >>>>>> >>>>> >>>>> >>> >>> >>> >>> >>> . >>> >>> >> > Envelope-to: ccamp-data@psg.com Delivery-date: Sun, 20 Nov 2005 21:36:05 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: IGP Extensions - CCAMP Milestones Date: Sun, 20 Nov 2005 22:35:06 +0100 Message-ID: Thread-Topic: IGP Extensions - CCAMP Milestones Thread-Index: AcXrtxthMkATK+ZaQEmpKPeLheHSMACYF3vQ From: "LE ROUX Jean-Louis RD-CORE-LAN" To: , Cc: "JP Vasseur" , , Hi Dimitri=20 > -----Message d'origine----- > De : dimitri papadimitriou [mailto:dpapadimitriou@psg.com]=20 > Envoy=E9 : jeudi 17 novembre 2005 21:40 > =C0 : LE ROUX Jean-Louis RD-CORE-LAN > Cc : JP Vasseur; Dimitri Papadimitriou;=20 > zzx-adrian@olddog.co.uk; ccamp@ops.ietf.org > Objet : Re: IGP Extensions - CCAMP Milestones >=20 > hi jean-louis >=20 > LE ROUX Jean-Louis RD-CORE-LAN wrote: >=20 > > Hi Dimitri, > >=20 > > Thanks for the comment. > >=20 > > As just explained by JP, the TE Node Cap TLV carries=20 > topology related=20 > > parameters used as constraints in path computation. The leaking of=20 > > such info across areas sounds useless as LSR TE visibility=20 > is limited=20 > > to one area anyway... But this is, of course, open to=20 > discussions. By=20 > > the way, do you have any application in mind where such=20 > leaking would=20 > > be useful? >=20 > stitching capability is the major application i see for the=20 > time being - others will more than probably come when=20 > technology specific application will progress (VCAT support=20 > is a good example here but this is for further discussion) OK, we will have to take this point into account and discuss further = what could be the actual need for leaking such capabilites across area = boundaries. Regards, JL >=20 > note: i would like also to point out that "capability"=20 > advertisement that are of the following nature >=20 > 1. exchanged on a per node basis > 2. variation of the information value >>> LS refresh time 3.=20 > usage of the information and setting up LSP across these nodes does > not trigger any LS update >=20 > are not scaling impacting more than any other inter-area=20 > routing information exchanged per current OSPF/IS-IS RFCs >=20 > > Regards, > >=20 > > JL > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >> -----Message d'origine----- De : JP Vasseur=20 > >> [mailto:jvasseur@cisco.com] Envoy=E9 : jeudi 17 novembre 2005 16:58 = =C0 > >> : Dimitri Papadimitriou; Dimitri Papadimitriou Cc : > >> zzx-adrian@olddog.co.uk; ccamp@ops.ietf.org; LE ROUX Jean-Louis=20 > >> RD-CORE-LAN Objet : Re: IGP Extensions - CCAMP Milestones > >>=20 > >> Hi dimitri, > >>=20 > >> On Nov 16, 2005, at 6:30 PM, dimitri papadimitriou wrote: > >>=20 > >>=20 > >>> adrian, > >>>=20 > >>> could you explain the reasoning for having a TE specific=20 > TLV in the=20 > >>> auto-mesh document with area and AS-wide flooding scope > >>=20 > >> while the TE > >>=20 > >>> router cap TLV is restricted to an area flooding scope ?=20 > >>> shouldn't be one way or the other i.e. either restrict=20 > all TE info=20 > >>> area-local or allow for TE router cap TLV with AS-wide > >>=20 > >> flooding scope > >>=20 > >>> ? > >>>=20 > >>> note: there is nothing in the TE router cap TLV that=20 > would impact =20 > >>> scaling more than the TE auto-mesh TLV does > >>>=20 > >>=20 > >> I guess that the reason for allowing both intra and inter-area=20 > >> flooding scopes for automesh is obvious (we need to have=20 > TE LSP mesh=20 > >> within areas and spanning multiple areas). > >>=20 > >> So your question is probably why don't we allow the TE=20 > router cap TLV=20 > >> to be flooded across the domain ? As far as I can remember=20 > JL already=20 > >> answered this question ... JL, could you forward your email again ? > >>=20 > >> In the meantime, I can answer it: the reason is that such TE node =20 > >> capabilities are used for TE LSP computation which cannot=20 > take into=20 > >> account nodes that do not reside in the node's area. > >>=20 > >> Thanks. > >>=20 > >> JP. > >>=20 > >>=20 > >>> thanks, - dimitri. > >>>=20 > >>> Adrian Farrel wrote: > >>>=20 > >>>=20 > >>>=20 > >>>> Hi, We have two immediate milestones to address: Oct 05 First=20 > >>>> version WG I-D for Advertising TE Node Capabilities in ISIS and=20 > >>>> OSPF Oct 05 First version WG I-D for Automatic discovery of > >>=20 > >> MPLS-TE mesh > >>=20 > >>>> membership There are two personal submissions which=20 > address these=20 > >>>> topics: draft-vasseur-ccamp-te-node-cap-01.txt > >>>> draft-vasseur-ccamp-automesh-02.txt I propose that we move these=20 > >>>> into the WG and then kick the tires thoroughly. Opinions please.=20 > >>>> Thanks, Adrian . > >>>=20 > >=20 > >=20 > > . > >=20 >=20 Envelope-to: ccamp-data@psg.com Delivery-date: Sun, 20 Nov 2005 19:42:26 +0000 Message-ID: <4380D135.2080202@psg.com> Date: Sun, 20 Nov 2005 20:40:37 +0100 From: dimitri papadimitriou Reply-To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.11) Gecko/20050728 MIME-Version: 1.0 To: JP Vasseur CC: Igor Bryskin , dimitri.papadimitriou@alcatel.be, Adrian Farrel , LE ROUX Jean-Louis RD-CORE-LAN , ccamp@ops.ietf.org Subject: Re: IGP Extensions - CCAMP Milestones Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit hi jp, indeed, i don't really understand the issue brought up by igor; in the present case, one should also underline that, the information distributed across the OSPF domain using opaque LSAs, is *indirectly* used by e.g. TE applications (note: RFC2370 allows for this information to be used directly by OSPF but i think we're not discussing this alternative) this means that these e.g. TE applications can in case of control engine failure detect this failure and trigger any necessary action in order to avoid the behaviour described by igor thanks, - dimitri. JP Vasseur wrote: > Hi Igor, > > On Nov 19, 2005, at 11:16 AM, Igor Bryskin wrote: > >> Hi everybody, >> >> >> >> I'd like to note that although the AS scope flooding is allowed for >> opaque >> LSAs, in my experience it does not work. > > > So your experience is different than the one of many people ... Opaque > LSA have been > used for quite a few years without any problem. See RFC2370 (July 1998) > >> Imagine that some routing >> controller advertises an AS scope LSA and goes out of service quickly >> after >> that. Controllers outside of the area that the dead controller >> belongs to >> have no way of detecting its death and, therefore, will keep using the >> advertising for another 90 min before the LSA times out. > > > I guess that you mean 60 min (Maxage=60mn, Architectural Constant) - > See RFC2328, but this is not the point, see below. > >> Note that the >> controllers located within the same area do not have such a problem >> because >> they can always verify the validity of the advertising by trying to >> locate a >> sequence of active adjacencies interconnecting each of them with the >> advertising controller. If they find at least one such a sequence, the >> advertising is valid (otherwise, it would be withdrawn); on the other >> hand, >> if no such sequences exist, than advertising is likely to be stale >> and hence >> could not be trusted. The conclusion is that opaque LSAs should never be >> flooded within AS, rather, within a single area, and, if there is a >> need for >> the information to be propagated beyond the area boundaries, ABRs >> must relay >> the advertising into other areas (by originating new area-scope >> LSAs). Note >> also that as far as I remember OSPF itself never uses AS scope >> advertisings >> for its own needs. For example, an ASBR does not distribute external >> routes >> learned by BGP from other ASs using AS scope LSAs, rather, the routes >> are >> advertised within a single area and ABRs relay the advertisings into >> other >> areas. > > > This is not correct. External routes are redistributed with LSA Type 5 > which are > flooded across the entire domain except in stub-area (not generated by > the ABR as type 3 as you mention). > > Anyway, back to the point, one cannot say of course that "Opaque LSA > Type 11 does not work". There are suitable to some application, this is > all. You can perfectly reply on an opaque LSA Type 11 to learn the > capability of a router which does not reside in the local area and rely > on another mechanism to detect its liveness. There are several such > examples. > > Hope this helps. > > JP. > > >> >> >> >> The bottom line is that the TLVs described in the draft should be of the >> area scope (just like TE LSAs), and hence it is not all that important >> whether we use new high level TLVs or sub-TLVs of the TE router cap TLV. >> >> >> >> Igor >> >> >> >> >> >> ----- Original Message ----- >> >> From: "dimitri papadimitriou" >> >> To: "Adrian Farrel" >> >> Cc: "LE ROUX Jean-Louis RD-CORE-LAN" >> ; >> "JP Vasseur" ; "Dimitri Papadimitriou" >> ; >> >> Sent: Friday, November 18, 2005 10:57 AM >> >> Subject: Re: IGP Extensions - CCAMP Milestones >> >> >> >> >>> adrian >>> >>> i think JL's reply did partially translate the initial concern >>> >>> in brief, there are three well identified TE applications that could >>> make use of the TE node cap TLVs on both intra and inter-area basis: >>> - LSP Stitching edge node capability >>> - Edge nodes connecting/being P2MP TE egresses >>> - TE auto-mesh >>> >>> hence, the question on why keeping separated TLVs as part of the router >>> capability and not consider these as sub-TLVs of the TE router cap TLV >>> this would >>> 1) provide a logical grouping of TE sub-TLVs as part of the same TLV >>> and >>> 2) leave the flexibility of flooding scope on a per application need - >>> >>> note: that the path computation specific sub-TLVs could still be >>> restricted with their current area-scope >>> >>> hope this clarifies the issue, >>> >>> thanks, >>> - dimitri. >>> >>> Adrian Farrel wrote: >>> >>> >>>> If I understand the question it is... >>>> >>>> In draft-ietf-ospf-cap-07.txt introduces the OSPF router >>>> information LSA >>>> and states that this LSA may have type 9, 10 or 11 scope. >>>> >>>> In draft-vasseur-ccamp-te-node-cap-01.txt a new TLV (TE Node >>>> Capability >>>> Descriptor) is added to the OSPF router information LSA. This TLV >>>> (when >>>> generated) MUST be advertised with type 10 scope. JL has given the >>>> >> reason >> >>>> why this is limited to type 10. This reason is, of course, open for >>>> discussion as he says. >>>> >>>> In draft-vasseur-ccamp-automesh-02.txt a new TLV (TE-MESH-GROUP) is >>>> >> added >> >>>> to the OSPF router information LSA. It states that the LSA may be >>>> advertised with type 10 or type 11 scope. JP has given a reason why >>>> you >>>> might want type 11 in addition to type 10. This reason is, of course, >>>> >> open >> >>>> for discussion. >>>> >>>> An interesting feature is that a router advertising an AS-wide mesh >>>> >> group >> >>>> *and* a TE router capability may require that two OSPF router >>>> >> information >> >>>> LSAs are advertised by the router. >>>> >>>> The language in draft-ietf-ospf-cap-07.txt leans towards a router >>>> >> sending >> >>>> *an* OSPF router information LSA. But nowhere does it say that the >>>> >> router >> >>>> cannot send more than one and in section 2.5 we find... >>>> The originating router MAY advertise >>>> multiple RI LSAs as long as the flooding scopes differ. >>>> >>>> Hope this answers the point. >>>> >>>> Adrian >>>> ----- Original Message ----- >>>> From: "LE ROUX Jean-Louis RD-CORE-LAN" >>>> >>>> To: "JP Vasseur" ; "Dimitri Papadimitriou" >>>> ; "Dimitri Papadimitriou" >>>> >>>> Cc: ; >>>> Sent: Thursday, November 17, 2005 6:47 PM >>>> Subject: RE: IGP Extensions - CCAMP Milestones >>>> >>>> >>>> Hi Dimitri, >>>> >>>> Thanks for the comment. >>>> >>>> As just explained by JP, the TE Node Cap TLV carries topology related >>>> parameters used as constraints in path computation. The leaking of >>>> such >>>> info across areas sounds useless as LSR TE visibility is limited to >>>> one >>>> area anyway... >>>> But this is, of course, open to discussions. By the way, do you >>>> have any >>>> application in mind where such leaking would be useful? >>>> >>>> Regards, >>>> >>>> JL >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>> -----Message d'origine----- >>>>> De : JP Vasseur [mailto:jvasseur@cisco.com] >>>>> Envoyé : jeudi 17 novembre 2005 16:58 >>>>> À : Dimitri Papadimitriou; Dimitri Papadimitriou >>>>> Cc : zzx-adrian@olddog.co.uk; ccamp@ops.ietf.org; LE ROUX >>>>> Jean-Louis RD-CORE-LAN >>>>> Objet : Re: IGP Extensions - CCAMP Milestones >>>>> >>>>> Hi dimitri, >>>>> >>>>> On Nov 16, 2005, at 6:30 PM, dimitri papadimitriou wrote: >>>>> >>>>> >>>>> >>>>>> adrian, >>>>>> >>>>>> could you explain the reasoning for having a TE specific TLV in the >>>>>> auto-mesh document with area and AS-wide flooding scope >>>>>> >>>>> >>>>> while the TE >>>>> >>>>> >>>>>> router cap TLV is restricted to an area flooding scope ? >>>>>> shouldn't be one way or the other i.e. either restrict all TE info >>>>>> area-local or allow for TE router cap TLV with AS-wide >>>>>> >>>>> >>>>> flooding scope >>>>> >>>>> >>>>>> ? >>>>>> >>>>>> note: there is nothing in the TE router cap TLV that would impact >>>>>> scaling more than the TE auto-mesh TLV does >>>>>> >>>>>> >>>>> >>>>> I guess that the reason for allowing both intra and inter-area >>>>> flooding scopes for automesh is obvious (we need to have TE LSP mesh >>>>> within areas and spanning multiple areas). >>>>> >>>>> So your question is probably why don't we allow the TE router >>>>> cap TLV >>>>> to be flooded across the domain ? As far as I can remember JL >>>>> already >>>>> answered this question ... JL, could you forward your email again ? >>>>> >>>>> In the meantime, I can answer it: the reason is that such TE node >>>>> capabilities are used for TE LSP computation which cannot take into >>>>> account nodes that do not reside in the node's area. >>>>> >>>>> Thanks. >>>>> >>>>> JP. >>>>> >>>>> >>>>> >>>>>> thanks, >>>>>> - dimitri. >>>>>> >>>>>> Adrian Farrel wrote: >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> Hi, >>>>>>> We have two immediate milestones to address: >>>>>>> Oct 05 First version WG I-D for Advertising TE Node Capabilities >>>>>>> in ISIS >>>>>>> and OSPF >>>>>>> Oct 05 First version WG I-D for Automatic discovery of >>>>>>> >>>>> >>>>> MPLS-TE mesh >>>>> >>>>> >>>>>>> membership >>>>>>> There are two personal submissions which address these topics: >>>>>>> draft-vasseur-ccamp-te-node-cap-01.txt >>>>>>> draft-vasseur-ccamp-automesh-02.txt >>>>>>> I propose that we move these into the WG and then kick the tires >>>>>>> thoroughly. >>>>>>> Opinions please. >>>>>>> Thanks, >>>>>>> Adrian >>>>>>> . >>>>>>> >>>>>> >>>>>> >>>> >>>> >>>> >>>> >>>> . >>>> >>>> >>> >> > > > . > Envelope-to: ccamp-data@psg.com Delivery-date: Sun, 20 Nov 2005 14:59:44 +0000 Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: Cc: , , "Adrian Farrel" , "LE ROUX Jean-Louis RD-CORE-LAN" , Content-Transfer-Encoding: quoted-printable From: JP Vasseur Subject: Re: IGP Extensions - CCAMP Milestones Date: Sun, 20 Nov 2005 09:57:01 -0500 To: Igor Bryskin Hi Igor, On Nov 19, 2005, at 11:16 AM, Igor Bryskin wrote: > Hi everybody, > > > > I'd like to note that although the AS scope flooding is allowed for =20= > opaque > LSAs, in my experience it does not work. So your experience is different than the one of many people ... =20 Opaque LSA have been used for quite a few years without any problem. See RFC2370 (July 1998) > Imagine that some routing > controller advertises an AS scope LSA and goes out of service =20 > quickly after > that. Controllers outside of the area that the dead controller =20 > belongs to > have no way of detecting its death and, therefore, will keep using the > advertising for another 90 min before the LSA times out. I guess that you mean 60 min (Maxage=3D60mn, Architectural Constant) - =20= See RFC2328, but this is not the point, see below. > Note that the > controllers located within the same area do not have such a problem =20= > because > they can always verify the validity of the advertising by trying to =20= > locate a > sequence of active adjacencies interconnecting each of them with the > advertising controller. If they find at least one such a sequence, the > advertising is valid (otherwise, it would be withdrawn); on the =20 > other hand, > if no such sequences exist, than advertising is likely to be stale =20 > and hence > could not be trusted. The conclusion is that opaque LSAs should =20 > never be > flooded within AS, rather, within a single area, and, if there is a =20= > need for > the information to be propagated beyond the area boundaries, ABRs =20 > must relay > the advertising into other areas (by originating new area-scope =20 > LSAs). Note > also that as far as I remember OSPF itself never uses AS scope =20 > advertisings > for its own needs. For example, an ASBR does not distribute =20 > external routes > learned by BGP from other ASs using AS scope LSAs, rather, the =20 > routes are > advertised within a single area and ABRs relay the advertisings =20 > into other > areas. This is not correct. External routes are redistributed with LSA Type =20 5 which are flooded across the entire domain except in stub-area (not generated by the ABR as type 3 as you mention). Anyway, back to the point, one cannot say of course that "Opaque LSA Type 11 does not work". There are suitable to some application, this is all. You can perfectly reply on an opaque LSA Type 11 to learn the capability of a router which does not reside in the local area and rely on another mechanism to detect its liveness. There are several such examples. Hope this helps. JP. > > > > The bottom line is that the TLVs described in the draft should be =20 > of the > area scope (just like TE LSAs), and hence it is not all that important > whether we use new high level TLVs or sub-TLVs of the TE router cap =20= > TLV. > > > > Igor > > > > > > ----- Original Message ----- > > From: "dimitri papadimitriou" > > To: "Adrian Farrel" > > Cc: "LE ROUX Jean-Louis RD-CORE-LAN" =20 > ; > "JP Vasseur" ; "Dimitri Papadimitriou" > ; > > Sent: Friday, November 18, 2005 10:57 AM > > Subject: Re: IGP Extensions - CCAMP Milestones > > > > >> adrian >> >> i think JL's reply did partially translate the initial concern >> >> in brief, there are three well identified TE applications that could >> make use of the TE node cap TLVs on both intra and inter-area basis: >> - LSP Stitching edge node capability >> - Edge nodes connecting/being P2MP TE egresses >> - TE auto-mesh >> >> hence, the question on why keeping separated TLVs as part of the =20 >> router >> capability and not consider these as sub-TLVs of the TE router cap =20= >> TLV >> this would >> 1) provide a logical grouping of TE sub-TLVs as part of the same =20 >> TLV and >> 2) leave the flexibility of flooding scope on a per application =20 >> need - >> >> note: that the path computation specific sub-TLVs could still be >> restricted with their current area-scope >> >> hope this clarifies the issue, >> >> thanks, >> - dimitri. >> >> Adrian Farrel wrote: >> >> >>> If I understand the question it is... >>> >>> In draft-ietf-ospf-cap-07.txt introduces the OSPF router =20 >>> information LSA >>> and states that this LSA may have type 9, 10 or 11 scope. >>> >>> In draft-vasseur-ccamp-te-node-cap-01.txt a new TLV (TE Node =20 >>> Capability >>> Descriptor) is added to the OSPF router information LSA. This TLV =20= >>> (when >>> generated) MUST be advertised with type 10 scope. JL has given the >>> > reason > >>> why this is limited to type 10. This reason is, of course, open for >>> discussion as he says. >>> >>> In draft-vasseur-ccamp-automesh-02.txt a new TLV (TE-MESH-GROUP) is >>> > added > >>> to the OSPF router information LSA. It states that the LSA may be >>> advertised with type 10 or type 11 scope. JP has given a reason =20 >>> why you >>> might want type 11 in addition to type 10. This reason is, of =20 >>> course, >>> > open > >>> for discussion. >>> >>> An interesting feature is that a router advertising an AS-wide mesh >>> > group > >>> *and* a TE router capability may require that two OSPF router >>> > information > >>> LSAs are advertised by the router. >>> >>> The language in draft-ietf-ospf-cap-07.txt leans towards a router >>> > sending > >>> *an* OSPF router information LSA. But nowhere does it say that the >>> > router > >>> cannot send more than one and in section 2.5 we find... >>> The originating router MAY advertise >>> multiple RI LSAs as long as the flooding scopes differ. >>> >>> Hope this answers the point. >>> >>> Adrian >>> ----- Original Message ----- >>> From: "LE ROUX Jean-Louis RD-CORE-LAN" >>> >>> To: "JP Vasseur" ; "Dimitri Papadimitriou" >>> ; "Dimitri Papadimitriou" >>> >>> Cc: ; >>> Sent: Thursday, November 17, 2005 6:47 PM >>> Subject: RE: IGP Extensions - CCAMP Milestones >>> >>> >>> Hi Dimitri, >>> >>> Thanks for the comment. >>> >>> As just explained by JP, the TE Node Cap TLV carries topology =20 >>> related >>> parameters used as constraints in path computation. The leaking =20 >>> of such >>> info across areas sounds useless as LSR TE visibility is limited =20 >>> to one >>> area anyway... >>> But this is, of course, open to discussions. By the way, do you =20 >>> have any >>> application in mind where such leaking would be useful? >>> >>> Regards, >>> >>> JL >>> >>> >>> >>> >>> >>> >>> >>> >>>> -----Message d'origine----- >>>> De : JP Vasseur [mailto:jvasseur@cisco.com] >>>> Envoy=E9 : jeudi 17 novembre 2005 16:58 >>>> =C0 : Dimitri Papadimitriou; Dimitri Papadimitriou >>>> Cc : zzx-adrian@olddog.co.uk; ccamp@ops.ietf.org; LE ROUX >>>> Jean-Louis RD-CORE-LAN >>>> Objet : Re: IGP Extensions - CCAMP Milestones >>>> >>>> Hi dimitri, >>>> >>>> On Nov 16, 2005, at 6:30 PM, dimitri papadimitriou wrote: >>>> >>>> >>>> >>>>> adrian, >>>>> >>>>> could you explain the reasoning for having a TE specific TLV in =20= >>>>> the >>>>> auto-mesh document with area and AS-wide flooding scope >>>>> >>>> >>>> while the TE >>>> >>>> >>>>> router cap TLV is restricted to an area flooding scope ? >>>>> shouldn't be one way or the other i.e. either restrict all TE info >>>>> area-local or allow for TE router cap TLV with AS-wide >>>>> >>>> >>>> flooding scope >>>> >>>> >>>>> ? >>>>> >>>>> note: there is nothing in the TE router cap TLV that would impact >>>>> scaling more than the TE auto-mesh TLV does >>>>> >>>>> >>>> >>>> I guess that the reason for allowing both intra and inter-area >>>> flooding scopes for automesh is obvious (we need to have TE LSP =20 >>>> mesh >>>> within areas and spanning multiple areas). >>>> >>>> So your question is probably why don't we allow the TE router >>>> cap TLV >>>> to be flooded across the domain ? As far as I can remember JL >>>> already >>>> answered this question ... JL, could you forward your email again ? >>>> >>>> In the meantime, I can answer it: the reason is that such TE node >>>> capabilities are used for TE LSP computation which cannot take into >>>> account nodes that do not reside in the node's area. >>>> >>>> Thanks. >>>> >>>> JP. >>>> >>>> >>>> >>>>> thanks, >>>>> - dimitri. >>>>> >>>>> Adrian Farrel wrote: >>>>> >>>>> >>>>> >>>>> >>>>>> Hi, >>>>>> We have two immediate milestones to address: >>>>>> Oct 05 First version WG I-D for Advertising TE Node Capabilities >>>>>> in ISIS >>>>>> and OSPF >>>>>> Oct 05 First version WG I-D for Automatic discovery of >>>>>> >>>> >>>> MPLS-TE mesh >>>> >>>> >>>>>> membership >>>>>> There are two personal submissions which address these topics: >>>>>> draft-vasseur-ccamp-te-node-cap-01.txt >>>>>> draft-vasseur-ccamp-automesh-02.txt >>>>>> I propose that we move these into the WG and then kick the tires >>>>>> thoroughly. >>>>>> Opinions please. >>>>>> Thanks, >>>>>> Adrian >>>>>> . >>>>>> >>>>> >>>>> >>> >>> >>> >>> >>> . >>> >>> >> > Envelope-to: ccamp-data@psg.com Delivery-date: Sat, 19 Nov 2005 16:18:11 +0000 Message-ID: <01ae01c5ed24$891c5c70$6601a8c0@movaz.com> From: "Igor Bryskin" To: , , "Adrian Farrel" Cc: "LE ROUX Jean-Louis RD-CORE-LAN" , "JP Vasseur" , "Dimitri Papadimitriou" , Subject: Re: IGP Extensions - CCAMP Milestones Date: Sat, 19 Nov 2005 11:16:01 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Hi everybody, I'd like to note that although the AS scope flooding is allowed for opaque LSAs, in my experience it does not work. Imagine that some routing controller advertises an AS scope LSA and goes out of service quickly after that. Controllers outside of the area that the dead controller belongs to have no way of detecting its death and, therefore, will keep using the advertising for another 90 min before the LSA times out. Note that the controllers located within the same area do not have such a problem because they can always verify the validity of the advertising by trying to locate a sequence of active adjacencies interconnecting each of them with the advertising controller. If they find at least one such a sequence, the advertising is valid (otherwise, it would be withdrawn); on the other hand, if no such sequences exist, than advertising is likely to be stale and hence could not be trusted. The conclusion is that opaque LSAs should never be flooded within AS, rather, within a single area, and, if there is a need for the information to be propagated beyond the area boundaries, ABRs must relay the advertising into other areas (by originating new area-scope LSAs). Note also that as far as I remember OSPF itself never uses AS scope advertisings for its own needs. For example, an ASBR does not distribute external routes learned by BGP from other ASs using AS scope LSAs, rather, the routes are advertised within a single area and ABRs relay the advertisings into other areas. The bottom line is that the TLVs described in the draft should be of the area scope (just like TE LSAs), and hence it is not all that important whether we use new high level TLVs or sub-TLVs of the TE router cap TLV. Igor ----- Original Message ----- From: "dimitri papadimitriou" To: "Adrian Farrel" Cc: "LE ROUX Jean-Louis RD-CORE-LAN" ; "JP Vasseur" ; "Dimitri Papadimitriou" ; Sent: Friday, November 18, 2005 10:57 AM Subject: Re: IGP Extensions - CCAMP Milestones > adrian > > i think JL's reply did partially translate the initial concern > > in brief, there are three well identified TE applications that could > make use of the TE node cap TLVs on both intra and inter-area basis: > - LSP Stitching edge node capability > - Edge nodes connecting/being P2MP TE egresses > - TE auto-mesh > > hence, the question on why keeping separated TLVs as part of the router > capability and not consider these as sub-TLVs of the TE router cap TLV > this would > 1) provide a logical grouping of TE sub-TLVs as part of the same TLV and > 2) leave the flexibility of flooding scope on a per application need - > > note: that the path computation specific sub-TLVs could still be > restricted with their current area-scope > > hope this clarifies the issue, > > thanks, > - dimitri. > > Adrian Farrel wrote: > > > If I understand the question it is... > > > > In draft-ietf-ospf-cap-07.txt introduces the OSPF router information LSA > > and states that this LSA may have type 9, 10 or 11 scope. > > > > In draft-vasseur-ccamp-te-node-cap-01.txt a new TLV (TE Node Capability > > Descriptor) is added to the OSPF router information LSA. This TLV (when > > generated) MUST be advertised with type 10 scope. JL has given the reason > > why this is limited to type 10. This reason is, of course, open for > > discussion as he says. > > > > In draft-vasseur-ccamp-automesh-02.txt a new TLV (TE-MESH-GROUP) is added > > to the OSPF router information LSA. It states that the LSA may be > > advertised with type 10 or type 11 scope. JP has given a reason why you > > might want type 11 in addition to type 10. This reason is, of course, open > > for discussion. > > > > An interesting feature is that a router advertising an AS-wide mesh group > > *and* a TE router capability may require that two OSPF router information > > LSAs are advertised by the router. > > > > The language in draft-ietf-ospf-cap-07.txt leans towards a router sending > > *an* OSPF router information LSA. But nowhere does it say that the router > > cannot send more than one and in section 2.5 we find... > > The originating router MAY advertise > > multiple RI LSAs as long as the flooding scopes differ. > > > > Hope this answers the point. > > > > Adrian > > ----- Original Message ----- > > From: "LE ROUX Jean-Louis RD-CORE-LAN" > > > > To: "JP Vasseur" ; "Dimitri Papadimitriou" > > ; "Dimitri Papadimitriou" > > > > Cc: ; > > Sent: Thursday, November 17, 2005 6:47 PM > > Subject: RE: IGP Extensions - CCAMP Milestones > > > > > > Hi Dimitri, > > > > Thanks for the comment. > > > > As just explained by JP, the TE Node Cap TLV carries topology related > > parameters used as constraints in path computation. The leaking of such > > info across areas sounds useless as LSR TE visibility is limited to one > > area anyway... > > But this is, of course, open to discussions. By the way, do you have any > > application in mind where such leaking would be useful? > > > > Regards, > > > > JL > > > > > > > > > > > > > > > >>-----Message d'origine----- > >>De : JP Vasseur [mailto:jvasseur@cisco.com] > >>Envoyé : jeudi 17 novembre 2005 16:58 > >>À : Dimitri Papadimitriou; Dimitri Papadimitriou > >>Cc : zzx-adrian@olddog.co.uk; ccamp@ops.ietf.org; LE ROUX > >>Jean-Louis RD-CORE-LAN > >>Objet : Re: IGP Extensions - CCAMP Milestones > >> > >>Hi dimitri, > >> > >>On Nov 16, 2005, at 6:30 PM, dimitri papadimitriou wrote: > >> > >> > >>>adrian, > >>> > >>>could you explain the reasoning for having a TE specific TLV in the > >>>auto-mesh document with area and AS-wide flooding scope > >> > >>while the TE > >> > >>>router cap TLV is restricted to an area flooding scope ? > >>>shouldn't be one way or the other i.e. either restrict all TE info > >>>area-local or allow for TE router cap TLV with AS-wide > >> > >>flooding scope > >> > >>>? > >>> > >>>note: there is nothing in the TE router cap TLV that would impact > >>>scaling more than the TE auto-mesh TLV does > >>> > >> > >>I guess that the reason for allowing both intra and inter-area > >>flooding scopes for automesh is obvious (we need to have TE LSP mesh > >>within areas and spanning multiple areas). > >> > >>So your question is probably why don't we allow the TE router > >>cap TLV > >>to be flooded across the domain ? As far as I can remember JL > >>already > >>answered this question ... JL, could you forward your email again ? > >> > >>In the meantime, I can answer it: the reason is that such TE node > >>capabilities are used for TE LSP computation which cannot take into > >>account nodes that do not reside in the node's area. > >> > >>Thanks. > >> > >>JP. > >> > >> > >>>thanks, > >>>- dimitri. > >>> > >>>Adrian Farrel wrote: > >>> > >>> > >>> > >>>>Hi, > >>>>We have two immediate milestones to address: > >>>>Oct 05 First version WG I-D for Advertising TE Node Capabilities > >>>>in ISIS > >>>>and OSPF > >>>>Oct 05 First version WG I-D for Automatic discovery of > >> > >>MPLS-TE mesh > >> > >>>>membership > >>>>There are two personal submissions which address these topics: > >>>>draft-vasseur-ccamp-te-node-cap-01.txt > >>>>draft-vasseur-ccamp-automesh-02.txt > >>>>I propose that we move these into the WG and then kick the tires > >>>>thoroughly. > >>>>Opinions please. > >>>>Thanks, > >>>>Adrian > >>>>. > >>> > > > > > > > > > > . > > > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 18 Nov 2005 16:53:16 +0000 Message-ID: <437E06DD.7090108@psg.com> Date: Fri, 18 Nov 2005 17:52:45 +0100 From: dimitri papadimitriou Reply-To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.11) Gecko/20050728 MIME-Version: 1.0 To: Adrian Farrel CC: ccamp@ops.ietf.org Subject: Re: Draft meeting report Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit hi adrian concerning ason routing solution discussion i think i have stated that it would be somehow helpful to receive as feedback the type of information characterizing the inter/cross-layer relationships thanks, - dimitri. Adrian Farrel wrote: > Hi, > > You can see a draft for the meeting report at > http://www3.ietf.org/proceedings/05nov/minutes/ccamp.html > > Comment welcome. > > According to IETF policy, I have produced a report not verbatim minutes. > Please let me know what you think of this change to previous behanvior. > > Thanks, > Adrian > > > > . > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 18 Nov 2005 15:58:49 +0000 Message-ID: <437DFA01.9080804@psg.com> Date: Fri, 18 Nov 2005 16:57:53 +0100 From: dimitri papadimitriou Reply-To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.11) Gecko/20050728 MIME-Version: 1.0 To: Adrian Farrel CC: LE ROUX Jean-Louis RD-CORE-LAN , JP Vasseur , Dimitri Papadimitriou , ccamp@ops.ietf.org Subject: Re: IGP Extensions - CCAMP Milestones Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit adrian i think JL's reply did partially translate the initial concern in brief, there are three well identified TE applications that could make use of the TE node cap TLVs on both intra and inter-area basis: - LSP Stitching edge node capability - Edge nodes connecting/being P2MP TE egresses - TE auto-mesh hence, the question on why keeping separated TLVs as part of the router capability and not consider these as sub-TLVs of the TE router cap TLV this would 1) provide a logical grouping of TE sub-TLVs as part of the same TLV and 2) leave the flexibility of flooding scope on a per application need - note: that the path computation specific sub-TLVs could still be restricted with their current area-scope hope this clarifies the issue, thanks, - dimitri. Adrian Farrel wrote: > If I understand the question it is... > > In draft-ietf-ospf-cap-07.txt introduces the OSPF router information LSA > and states that this LSA may have type 9, 10 or 11 scope. > > In draft-vasseur-ccamp-te-node-cap-01.txt a new TLV (TE Node Capability > Descriptor) is added to the OSPF router information LSA. This TLV (when > generated) MUST be advertised with type 10 scope. JL has given the reason > why this is limited to type 10. This reason is, of course, open for > discussion as he says. > > In draft-vasseur-ccamp-automesh-02.txt a new TLV (TE-MESH-GROUP) is added > to the OSPF router information LSA. It states that the LSA may be > advertised with type 10 or type 11 scope. JP has given a reason why you > might want type 11 in addition to type 10. This reason is, of course, open > for discussion. > > An interesting feature is that a router advertising an AS-wide mesh group > *and* a TE router capability may require that two OSPF router information > LSAs are advertised by the router. > > The language in draft-ietf-ospf-cap-07.txt leans towards a router sending > *an* OSPF router information LSA. But nowhere does it say that the router > cannot send more than one and in section 2.5 we find... > The originating router MAY advertise > multiple RI LSAs as long as the flooding scopes differ. > > Hope this answers the point. > > Adrian > ----- Original Message ----- > From: "LE ROUX Jean-Louis RD-CORE-LAN" > > To: "JP Vasseur" ; "Dimitri Papadimitriou" > ; "Dimitri Papadimitriou" > > Cc: ; > Sent: Thursday, November 17, 2005 6:47 PM > Subject: RE: IGP Extensions - CCAMP Milestones > > > Hi Dimitri, > > Thanks for the comment. > > As just explained by JP, the TE Node Cap TLV carries topology related > parameters used as constraints in path computation. The leaking of such > info across areas sounds useless as LSR TE visibility is limited to one > area anyway... > But this is, of course, open to discussions. By the way, do you have any > application in mind where such leaking would be useful? > > Regards, > > JL > > > > > > > >>-----Message d'origine----- >>De : JP Vasseur [mailto:jvasseur@cisco.com] >>Envoyé : jeudi 17 novembre 2005 16:58 >>À : Dimitri Papadimitriou; Dimitri Papadimitriou >>Cc : zzx-adrian@olddog.co.uk; ccamp@ops.ietf.org; LE ROUX >>Jean-Louis RD-CORE-LAN >>Objet : Re: IGP Extensions - CCAMP Milestones >> >>Hi dimitri, >> >>On Nov 16, 2005, at 6:30 PM, dimitri papadimitriou wrote: >> >> >>>adrian, >>> >>>could you explain the reasoning for having a TE specific TLV in the >>>auto-mesh document with area and AS-wide flooding scope >> >>while the TE >> >>>router cap TLV is restricted to an area flooding scope ? >>>shouldn't be one way or the other i.e. either restrict all TE info >>>area-local or allow for TE router cap TLV with AS-wide >> >>flooding scope >> >>>? >>> >>>note: there is nothing in the TE router cap TLV that would impact >>>scaling more than the TE auto-mesh TLV does >>> >> >>I guess that the reason for allowing both intra and inter-area >>flooding scopes for automesh is obvious (we need to have TE LSP mesh >>within areas and spanning multiple areas). >> >>So your question is probably why don't we allow the TE router >>cap TLV >>to be flooded across the domain ? As far as I can remember JL >>already >>answered this question ... JL, could you forward your email again ? >> >>In the meantime, I can answer it: the reason is that such TE node >>capabilities are used for TE LSP computation which cannot take into >>account nodes that do not reside in the node's area. >> >>Thanks. >> >>JP. >> >> >>>thanks, >>>- dimitri. >>> >>>Adrian Farrel wrote: >>> >>> >>> >>>>Hi, >>>>We have two immediate milestones to address: >>>>Oct 05 First version WG I-D for Advertising TE Node Capabilities >>>>in ISIS >>>>and OSPF >>>>Oct 05 First version WG I-D for Automatic discovery of >> >>MPLS-TE mesh >> >>>>membership >>>>There are two personal submissions which address these topics: >>>>draft-vasseur-ccamp-te-node-cap-01.txt >>>>draft-vasseur-ccamp-automesh-02.txt >>>>I propose that we move these into the WG and then kick the tires >>>>thoroughly. >>>>Opinions please. >>>>Thanks, >>>>Adrian >>>>. >>> > > > > > . > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 18 Nov 2005 14:09:24 +0000 Message-ID: <054801c5eb89$9f39cf20$d501a8c0@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Cc: , , "'Jean Philippe Vasseur'" Subject: Re: IGP Extensions - CCAMP Milestones Date: Thu, 17 Nov 2005 15:12:44 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Thanks Dimitri, I can't answer your question. The editors presumably can. I hope this doesn't prevent us from making these WG documents, but rather is a small technical point that needs to be resolved in the normal process. Cheers, Adrian ----- Original Message ----- From: "dimitri papadimitriou" To: "Adrian Farrel" Cc: Sent: Wednesday, November 16, 2005 11:30 PM Subject: Re: IGP Extensions - CCAMP Milestones > adrian, > > could you explain the reasoning for having a TE specific TLV in the > auto-mesh document with area and AS-wide flooding scope while the TE > router cap TLV is restricted to an area flooding scope ? shouldn't be > one way or the other i.e. either restrict all TE info area-local or > allow for TE router cap TLV with AS-wide flooding scope ? > > note: there is nothing in the TE router cap TLV that would impact > scaling more than the TE auto-mesh TLV does > > thanks, > - dimitri. > > Adrian Farrel wrote: > > > Hi, > > > > We have two immediate milestones to address: > > > > Oct 05 First version WG I-D for Advertising TE Node Capabilities in ISIS > > and OSPF > > Oct 05 First version WG I-D for Automatic discovery of MPLS-TE mesh > > membership > > > > There are two personal submissions which address these topics: > > draft-vasseur-ccamp-te-node-cap-01.txt > > draft-vasseur-ccamp-automesh-02.txt > > > > I propose that we move these into the WG and then kick the tires > > thoroughly. > > > > Opinions please. > > > > Thanks, > > Adrian > > > > > > > > . > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 18 Nov 2005 14:09:16 +0000 Message-ID: <062501c5ebf2$a0d2cdf0$d501a8c0@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Draft meeting report Date: Fri, 18 Nov 2005 03:46:06 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi, You can see a draft for the meeting report at http://www3.ietf.org/proceedings/05nov/minutes/ccamp.html Comment welcome. According to IETF policy, I have produced a report not verbatim minutes. Please let me know what you think of this change to previous behanvior. Thanks, Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 18 Nov 2005 14:09:10 +0000 Message-ID: <05d401c5ebb8$f343bde0$d501a8c0@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "LE ROUX Jean-Louis RD-CORE-LAN" , "JP Vasseur" , "Dimitri Papadimitriou" , "Dimitri Papadimitriou" Cc: Subject: Re: IGP Extensions - CCAMP Milestones Date: Thu, 17 Nov 2005 20:50:10 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit If I understand the question it is... In draft-ietf-ospf-cap-07.txt introduces the OSPF router information LSA and states that this LSA may have type 9, 10 or 11 scope. In draft-vasseur-ccamp-te-node-cap-01.txt a new TLV (TE Node Capability Descriptor) is added to the OSPF router information LSA. This TLV (when generated) MUST be advertised with type 10 scope. JL has given the reason why this is limited to type 10. This reason is, of course, open for discussion as he says. In draft-vasseur-ccamp-automesh-02.txt a new TLV (TE-MESH-GROUP) is added to the OSPF router information LSA. It states that the LSA may be advertised with type 10 or type 11 scope. JP has given a reason why you might want type 11 in addition to type 10. This reason is, of course, open for discussion. An interesting feature is that a router advertising an AS-wide mesh group *and* a TE router capability may require that two OSPF router information LSAs are advertised by the router. The language in draft-ietf-ospf-cap-07.txt leans towards a router sending *an* OSPF router information LSA. But nowhere does it say that the router cannot send more than one and in section 2.5 we find... The originating router MAY advertise multiple RI LSAs as long as the flooding scopes differ. Hope this answers the point. Adrian ----- Original Message ----- From: "LE ROUX Jean-Louis RD-CORE-LAN" To: "JP Vasseur" ; "Dimitri Papadimitriou" ; "Dimitri Papadimitriou" Cc: ; Sent: Thursday, November 17, 2005 6:47 PM Subject: RE: IGP Extensions - CCAMP Milestones Hi Dimitri, Thanks for the comment. As just explained by JP, the TE Node Cap TLV carries topology related parameters used as constraints in path computation. The leaking of such info across areas sounds useless as LSR TE visibility is limited to one area anyway... But this is, of course, open to discussions. By the way, do you have any application in mind where such leaking would be useful? Regards, JL > -----Message d'origine----- > De : JP Vasseur [mailto:jvasseur@cisco.com] > Envoyé : jeudi 17 novembre 2005 16:58 > À : Dimitri Papadimitriou; Dimitri Papadimitriou > Cc : zzx-adrian@olddog.co.uk; ccamp@ops.ietf.org; LE ROUX > Jean-Louis RD-CORE-LAN > Objet : Re: IGP Extensions - CCAMP Milestones > > Hi dimitri, > > On Nov 16, 2005, at 6:30 PM, dimitri papadimitriou wrote: > > > adrian, > > > > could you explain the reasoning for having a TE specific TLV in the > > auto-mesh document with area and AS-wide flooding scope > while the TE > > router cap TLV is restricted to an area flooding scope ? > > shouldn't be one way or the other i.e. either restrict all TE info > > area-local or allow for TE router cap TLV with AS-wide > flooding scope > > ? > > > > note: there is nothing in the TE router cap TLV that would impact > > scaling more than the TE auto-mesh TLV does > > > > I guess that the reason for allowing both intra and inter-area > flooding scopes for automesh is obvious (we need to have TE LSP mesh > within areas and spanning multiple areas). > > So your question is probably why don't we allow the TE router > cap TLV > to be flooded across the domain ? As far as I can remember JL > already > answered this question ... JL, could you forward your email again ? > > In the meantime, I can answer it: the reason is that such TE node > capabilities are used for TE LSP computation which cannot take into > account nodes that do not reside in the node's area. > > Thanks. > > JP. > > > thanks, > > - dimitri. > > > > Adrian Farrel wrote: > > > > > >> Hi, > >> We have two immediate milestones to address: > >> Oct 05 First version WG I-D for Advertising TE Node Capabilities > >> in ISIS > >> and OSPF > >> Oct 05 First version WG I-D for Automatic discovery of > MPLS-TE mesh > >> membership > >> There are two personal submissions which address these topics: > >> draft-vasseur-ccamp-te-node-cap-01.txt > >> draft-vasseur-ccamp-automesh-02.txt > >> I propose that we move these into the WG and then kick the tires > >> thoroughly. > >> Opinions please. > >> Thanks, > >> Adrian > >> . > > > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 17 Nov 2005 23:27:33 +0000 Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: Cc: "LE ROUX Jean-Louis RD-CORE-LAN" , "Dimitri Papadimitriou" , "Dimitri Papadimitriou" , Content-Transfer-Encoding: quoted-printable From: JP Vasseur Subject: Re: IGP Extensions - CCAMP Milestones Date: Thu, 17 Nov 2005 18:25:11 -0500 To: "Adrian Farrel" On Nov 17, 2005, at 3:50 PM, Adrian Farrel wrote: > If I understand the question it is... > > In draft-ietf-ospf-cap-07.txt introduces the OSPF router =20 > information LSA > and states that this LSA may have type 9, 10 or 11 scope. > > In draft-vasseur-ccamp-te-node-cap-01.txt a new TLV (TE Node =20 > Capability > Descriptor) is added to the OSPF router information LSA. This TLV =20 > (when > generated) MUST be advertised with type 10 scope. JL has given the =20 > reason > why this is limited to type 10. This reason is, of course, open for > discussion as he says. > > In draft-vasseur-ccamp-automesh-02.txt a new TLV (TE-MESH-GROUP) is =20= > added > to the OSPF router information LSA. It states that the LSA may be > advertised with type 10 or type 11 scope. JP has given a reason why =20= > you > might want type 11 in addition to type 10. This reason is, of =20 > course, open > for discussion. > > An interesting feature is that a router advertising an AS-wide mesh =20= > group > *and* a TE router capability may require that two OSPF router =20 > information > LSAs are advertised by the router. > > The language in draft-ietf-ospf-cap-07.txt leans towards a router =20 > sending > *an* OSPF router information LSA. But nowhere does it say that the =20 > router > cannot send more than one and in section 2.5 we find... > The originating router MAY advertise > multiple RI LSAs as long as the flooding scopes differ. > You're 100% correct and this is exactly why we wrote that section in =20 draft-ietf-ospf-cap Thanks. JP. > Hope this answers the point. > > Adrian > ----- Original Message ----- > From: "LE ROUX Jean-Louis RD-CORE-LAN" > > To: "JP Vasseur" ; "Dimitri Papadimitriou" > ; "Dimitri Papadimitriou" > > Cc: ; > Sent: Thursday, November 17, 2005 6:47 PM > Subject: RE: IGP Extensions - CCAMP Milestones > > > Hi Dimitri, > > Thanks for the comment. > > As just explained by JP, the TE Node Cap TLV carries topology related > parameters used as constraints in path computation. The leaking of =20 > such > info across areas sounds useless as LSR TE visibility is limited to =20= > one > area anyway... > But this is, of course, open to discussions. By the way, do you =20 > have any > application in mind where such leaking would be useful? > > Regards, > > JL > > > > > > > >> -----Message d'origine----- >> De : JP Vasseur [mailto:jvasseur@cisco.com] >> Envoy=E9 : jeudi 17 novembre 2005 16:58 >> =C0 : Dimitri Papadimitriou; Dimitri Papadimitriou >> Cc : zzx-adrian@olddog.co.uk; ccamp@ops.ietf.org; LE ROUX >> Jean-Louis RD-CORE-LAN >> Objet : Re: IGP Extensions - CCAMP Milestones >> >> Hi dimitri, >> >> On Nov 16, 2005, at 6:30 PM, dimitri papadimitriou wrote: >> >> >>> adrian, >>> >>> could you explain the reasoning for having a TE specific TLV in the >>> auto-mesh document with area and AS-wide flooding scope >>> >> while the TE >> >>> router cap TLV is restricted to an area flooding scope ? >>> shouldn't be one way or the other i.e. either restrict all TE info >>> area-local or allow for TE router cap TLV with AS-wide >>> >> flooding scope >> >>> ? >>> >>> note: there is nothing in the TE router cap TLV that would impact >>> scaling more than the TE auto-mesh TLV does >>> >>> >> >> I guess that the reason for allowing both intra and inter-area >> flooding scopes for automesh is obvious (we need to have TE LSP mesh >> within areas and spanning multiple areas). >> >> So your question is probably why don't we allow the TE router >> cap TLV >> to be flooded across the domain ? As far as I can remember JL >> already >> answered this question ... JL, could you forward your email again ? >> >> In the meantime, I can answer it: the reason is that such TE node >> capabilities are used for TE LSP computation which cannot take into >> account nodes that do not reside in the node's area. >> >> Thanks. >> >> JP. >> >> >>> thanks, >>> - dimitri. >>> >>> Adrian Farrel wrote: >>> >>> >>> >>>> Hi, >>>> We have two immediate milestones to address: >>>> Oct 05 First version WG I-D for Advertising TE Node Capabilities >>>> in ISIS >>>> and OSPF >>>> Oct 05 First version WG I-D for Automatic discovery of >>>> >> MPLS-TE mesh >> >>>> membership >>>> There are two personal submissions which address these topics: >>>> draft-vasseur-ccamp-te-node-cap-01.txt >>>> draft-vasseur-ccamp-automesh-02.txt >>>> I propose that we move these into the WG and then kick the tires >>>> thoroughly. >>>> Opinions please. >>>> Thanks, >>>> Adrian >>>> . >>>> >>> >>> >> > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 17 Nov 2005 20:40:39 +0000 Message-ID: <437CEAB6.30701@psg.com> Date: Thu, 17 Nov 2005 21:40:22 +0100 From: dimitri papadimitriou Reply-To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.11) Gecko/20050728 MIME-Version: 1.0 To: LE ROUX Jean-Louis RD-CORE-LAN CC: JP Vasseur , Dimitri Papadimitriou , adrian@olddog.co.uk, ccamp@ops.ietf.org Subject: Re: IGP Extensions - CCAMP Milestones Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit hi jean-louis LE ROUX Jean-Louis RD-CORE-LAN wrote: > Hi Dimitri, > > Thanks for the comment. > > As just explained by JP, the TE Node Cap TLV carries topology related > parameters used as constraints in path computation. The leaking of > such info across areas sounds useless as LSR TE visibility is limited > to one area anyway... But this is, of course, open to discussions. By > the way, do you have any application in mind where such leaking would > be useful? stitching capability is the major application i see for the time being - others will more than probably come when technology specific application will progress (VCAT support is a good example here but this is for further discussion) note: i would like also to point out that "capability" advertisement that are of the following nature 1. exchanged on a per node basis 2. variation of the information value >>> LS refresh time 3. usage of the information and setting up LSP across these nodes does not trigger any LS update are not scaling impacting more than any other inter-area routing information exchanged per current OSPF/IS-IS RFCs > Regards, > > JL > > > > > > > >> -----Message d'origine----- De : JP Vasseur >> [mailto:jvasseur@cisco.com] Envoyé : jeudi 17 novembre 2005 16:58 À >> : Dimitri Papadimitriou; Dimitri Papadimitriou Cc : >> zzx-adrian@olddog.co.uk; ccamp@ops.ietf.org; LE ROUX Jean-Louis >> RD-CORE-LAN Objet : Re: IGP Extensions - CCAMP Milestones >> >> Hi dimitri, >> >> On Nov 16, 2005, at 6:30 PM, dimitri papadimitriou wrote: >> >> >>> adrian, >>> >>> could you explain the reasoning for having a TE specific TLV in >>> the auto-mesh document with area and AS-wide flooding scope >> >> while the TE >> >>> router cap TLV is restricted to an area flooding scope ? >>> shouldn't be one way or the other i.e. either restrict all TE >>> info area-local or allow for TE router cap TLV with AS-wide >> >> flooding scope >> >>> ? >>> >>> note: there is nothing in the TE router cap TLV that would impact >>> scaling more than the TE auto-mesh TLV does >>> >> >> I guess that the reason for allowing both intra and inter-area >> flooding scopes for automesh is obvious (we need to have TE LSP >> mesh within areas and spanning multiple areas). >> >> So your question is probably why don't we allow the TE router cap >> TLV to be flooded across the domain ? As far as I can remember JL >> already answered this question ... JL, could you forward your email >> again ? >> >> In the meantime, I can answer it: the reason is that such TE node >> capabilities are used for TE LSP computation which cannot take >> into account nodes that do not reside in the node's area. >> >> Thanks. >> >> JP. >> >> >>> thanks, - dimitri. >>> >>> Adrian Farrel wrote: >>> >>> >>> >>>> Hi, We have two immediate milestones to address: Oct 05 First >>>> version WG I-D for Advertising TE Node Capabilities in ISIS and >>>> OSPF Oct 05 First version WG I-D for Automatic discovery of >> >> MPLS-TE mesh >> >>>> membership There are two personal submissions which address >>>> these topics: draft-vasseur-ccamp-te-node-cap-01.txt >>>> draft-vasseur-ccamp-automesh-02.txt I propose that we move >>>> these into the WG and then kick the tires thoroughly. Opinions >>>> please. Thanks, Adrian . >>> > > > . > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 17 Nov 2005 20:18:22 +0000 Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: Adrian Farrel , ccamp@ops.ietf.org, LE ROUX Jean-Louis RD-CORE-LAN Content-Transfer-Encoding: 7bit From: JP Vasseur Subject: Re: IGP Extensions - CCAMP Milestones Date: Thu, 17 Nov 2005 15:17:18 -0500 To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be On Nov 17, 2005, at 3:08 PM, dimitri papadimitriou wrote: > hi jean-philippe > > JP Vasseur wrote: > > >> Hi dimitri, >> On Nov 16, 2005, at 6:30 PM, dimitri papadimitriou wrote: >> >>> adrian, >>> >>> could you explain the reasoning for having a TE specific TLV in >>> the auto-mesh document with area and AS-wide flooding scope >>> while the TE router cap TLV is restricted to an area flooding >>> scope ? shouldn't be one way or the other i.e. either restrict >>> all TE info area-local or allow for TE router cap TLV with AS- >>> wide flooding scope ? >>> >>> note: there is nothing in the TE router cap TLV that would >>> impact scaling more than the TE auto-mesh TLV does >>> >> I guess that the reason for allowing both intra and inter-area >> flooding scopes for automesh is obvious (we need to have TE LSP >> mesh within areas and spanning multiple areas). >> So your question is probably why don't we allow the TE router cap >> TLV to be flooded across the domain ? As far as I can remember JL >> already answered this question ... JL, could you forward your >> email again ? >> > > would you also send the reply i provided in case > > >> In the meantime, I can answer it: the reason is that such TE node >> capabilities are used for TE LSP computation which cannot take >> into account nodes that do not reside in the node's area. >> > > i am not sure to understand why the path computation domain has to > be limited on a 1:1 basis to a single routing domain > what do you mean by "1:1 basis to a single routing domain" ? JP. > >> Thanks. >> JP. >> >>> thanks, >>> - dimitri. >>> >>> Adrian Farrel wrote: >>> >>> >>> >>>> Hi, >>>> We have two immediate milestones to address: >>>> Oct 05 First version WG I-D for Advertising TE Node >>>> Capabilities in ISIS >>>> and OSPF >>>> Oct 05 First version WG I-D for Automatic discovery of MPLS-TE >>>> mesh >>>> membership >>>> There are two personal submissions which address these topics: >>>> draft-vasseur-ccamp-te-node-cap-01.txt >>>> draft-vasseur-ccamp-automesh-02.txt >>>> I propose that we move these into the WG and then kick the tires >>>> thoroughly. >>>> Opinions please. >>>> Thanks, >>>> Adrian >>>> . >>>> >>> >>> >>> >> . > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 17 Nov 2005 20:09:29 +0000 Message-ID: <437CE339.2010507@psg.com> Date: Thu, 17 Nov 2005 21:08:25 +0100 From: dimitri papadimitriou Reply-To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.11) Gecko/20050728 MIME-Version: 1.0 To: JP Vasseur CC: Dimitri Papadimitriou , Adrian Farrel , ccamp@ops.ietf.org, LE ROUX Jean-Louis RD-CORE-LAN Subject: Re: IGP Extensions - CCAMP Milestones Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit hi jean-philippe JP Vasseur wrote: > Hi dimitri, > > On Nov 16, 2005, at 6:30 PM, dimitri papadimitriou wrote: > >> adrian, >> >> could you explain the reasoning for having a TE specific TLV in the >> auto-mesh document with area and AS-wide flooding scope while the TE >> router cap TLV is restricted to an area flooding scope ? shouldn't be >> one way or the other i.e. either restrict all TE info area-local or >> allow for TE router cap TLV with AS-wide flooding scope ? >> >> note: there is nothing in the TE router cap TLV that would impact >> scaling more than the TE auto-mesh TLV does > > I guess that the reason for allowing both intra and inter-area flooding > scopes for automesh is obvious (we need to have TE LSP mesh within > areas and spanning multiple areas). > > So your question is probably why don't we allow the TE router cap TLV > to be flooded across the domain ? As far as I can remember JL already > answered this question ... JL, could you forward your email again ? would you also send the reply i provided in case > In the meantime, I can answer it: the reason is that such TE node > capabilities are used for TE LSP computation which cannot take into > account nodes that do not reside in the node's area. i am not sure to understand why the path computation domain has to be limited on a 1:1 basis to a single routing domain > Thanks. > > JP. > >> thanks, >> - dimitri. >> >> Adrian Farrel wrote: >> >> >>> Hi, >>> We have two immediate milestones to address: >>> Oct 05 First version WG I-D for Advertising TE Node Capabilities in >>> ISIS >>> and OSPF >>> Oct 05 First version WG I-D for Automatic discovery of MPLS-TE mesh >>> membership >>> There are two personal submissions which address these topics: >>> draft-vasseur-ccamp-te-node-cap-01.txt >>> draft-vasseur-ccamp-automesh-02.txt >>> I propose that we move these into the WG and then kick the tires >>> thoroughly. >>> Opinions please. >>> Thanks, >>> Adrian >>> . >> >> > > . > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 17 Nov 2005 18:50:18 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: IGP Extensions - CCAMP Milestones Date: Thu, 17 Nov 2005 19:47:49 +0100 Message-ID: Thread-Topic: IGP Extensions - CCAMP Milestones Thread-Index: AcXrj8cQ4U/zfvsOS/m1c+x/vBTdUgABnSpw From: "LE ROUX Jean-Louis RD-CORE-LAN" To: "JP Vasseur" , "Dimitri Papadimitriou" , "Dimitri Papadimitriou" Cc: , Hi Dimitri, Thanks for the comment. As just explained by JP, the TE Node Cap TLV carries topology related = parameters used as constraints in path computation. The leaking of such = info across areas sounds useless as LSR TE visibility is limited to one = area anyway...=20 But this is, of course, open to discussions. By the way, do you have any = application in mind where such leaking would be useful? Regards, JL > -----Message d'origine----- > De : JP Vasseur [mailto:jvasseur@cisco.com]=20 > Envoy=E9 : jeudi 17 novembre 2005 16:58 > =C0 : Dimitri Papadimitriou; Dimitri Papadimitriou > Cc : zzx-adrian@olddog.co.uk; ccamp@ops.ietf.org; LE ROUX=20 > Jean-Louis RD-CORE-LAN > Objet : Re: IGP Extensions - CCAMP Milestones >=20 > Hi dimitri, >=20 > On Nov 16, 2005, at 6:30 PM, dimitri papadimitriou wrote: >=20 > > adrian, > > > > could you explain the reasoning for having a TE specific TLV in the=20 > > auto-mesh document with area and AS-wide flooding scope=20 > while the TE=20 > > router cap TLV is restricted to an area flooding scope ? > > shouldn't be one way or the other i.e. either restrict all TE info=20 > > area-local or allow for TE router cap TLV with AS-wide=20 > flooding scope=20 > > ? > > > > note: there is nothing in the TE router cap TLV that would impact=20 > > scaling more than the TE auto-mesh TLV does > > >=20 > I guess that the reason for allowing both intra and inter-area =20 > flooding scopes for automesh is obvious (we need to have TE LSP mesh =20 > within areas and spanning multiple areas). >=20 > So your question is probably why don't we allow the TE router=20 > cap TLV =20 > to be flooded across the domain ? As far as I can remember JL=20 > already =20 > answered this question ... JL, could you forward your email again ? >=20 > In the meantime, I can answer it: the reason is that such TE node =20 > capabilities are used for TE LSP computation which cannot take into =20 > account nodes that do not reside in the node's area. >=20 > Thanks. >=20 > JP. >=20 > > thanks, > > - dimitri. > > > > Adrian Farrel wrote: > > > > > >> Hi, > >> We have two immediate milestones to address: > >> Oct 05 First version WG I-D for Advertising TE Node Capabilities =20 > >> in ISIS > >> and OSPF > >> Oct 05 First version WG I-D for Automatic discovery of=20 > MPLS-TE mesh > >> membership > >> There are two personal submissions which address these topics: > >> draft-vasseur-ccamp-te-node-cap-01.txt > >> draft-vasseur-ccamp-automesh-02.txt > >> I propose that we move these into the WG and then kick the tires > >> thoroughly. > >> Opinions please. > >> Thanks, > >> Adrian > >> . > > >=20 Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 17 Nov 2005 16:00:01 +0000 Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <717B79F2-A8D1-4A1C-ACCD-013A3584B655@cisco.com> Cc: Adrian Farrel , ccamp@ops.ietf.org, LE ROUX Jean-Louis RD-CORE-LAN Content-Transfer-Encoding: 7bit From: JP Vasseur Subject: Re: IGP Extensions - CCAMP Milestones Date: Thu, 17 Nov 2005 10:57:53 -0500 To: Dimitri Papadimitriou , Dimitri Papadimitriou Hi dimitri, On Nov 16, 2005, at 6:30 PM, dimitri papadimitriou wrote: > adrian, > > could you explain the reasoning for having a TE specific TLV in the > auto-mesh document with area and AS-wide flooding scope while the > TE router cap TLV is restricted to an area flooding scope ? > shouldn't be one way or the other i.e. either restrict all TE info > area-local or allow for TE router cap TLV with AS-wide flooding > scope ? > > note: there is nothing in the TE router cap TLV that would impact > scaling more than the TE auto-mesh TLV does > I guess that the reason for allowing both intra and inter-area flooding scopes for automesh is obvious (we need to have TE LSP mesh within areas and spanning multiple areas). So your question is probably why don't we allow the TE router cap TLV to be flooded across the domain ? As far as I can remember JL already answered this question ... JL, could you forward your email again ? In the meantime, I can answer it: the reason is that such TE node capabilities are used for TE LSP computation which cannot take into account nodes that do not reside in the node's area. Thanks. JP. > thanks, > - dimitri. > > Adrian Farrel wrote: > > >> Hi, >> We have two immediate milestones to address: >> Oct 05 First version WG I-D for Advertising TE Node Capabilities >> in ISIS >> and OSPF >> Oct 05 First version WG I-D for Automatic discovery of MPLS-TE mesh >> membership >> There are two personal submissions which address these topics: >> draft-vasseur-ccamp-te-node-cap-01.txt >> draft-vasseur-ccamp-automesh-02.txt >> I propose that we move these into the WG and then kick the tires >> thoroughly. >> Opinions please. >> Thanks, >> Adrian >> . > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 17 Nov 2005 02:17:21 +0000 Message-Id: <200511170207.jAH27CE21152@boreas.isi.edu> To: ietf-announce@ietf.org Subject: RFC 4258 on Requirements for Generalized Multi-Protocol Label Switching (GMPLS) Routing for the Automatically Switched Optical Network (ASON) Cc: rfc-editor@rfc-editor.org, ccamp@ops.ietf.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Wed, 16 Nov 2005 18:07:12 -0800 --NextPart A new Request for Comments is now available in online RFC libraries. RFC 4258 Title: Requirements for Generalized Multi-Protocol Label Switching (GMPLS) Routing for the Automatically Switched Optical Network (ASON) Author(s): D. Brungard, Ed. Status: Informational Date: November 2005 Mailbox: dbrungard@att.com Pages: 22 Characters: 48558 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-ccamp-gmpls-ason-routing-reqts-05.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc4258.txt The Generalized Multi-Protocol Label Switching (GMPLS) suite of protocols has been defined to control different switching technologies as well as different applications. These include support for requesting Time Division Multiplexing (TDM) connections including Synchronous Optical Network (SONET)/Synchronous Digital Hierarchy (SDH) and Optical Transport Networks (OTNs). This document concentrates on the routing requirements placed on the GMPLS suite of protocols in order to support the capabilities and functionalities of an Automatically Switched Optical Network (ASON) as defined by the ITU-T. This document is a product of the Common Control and Measurement Plane Working Group of the IETF. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <051116180602.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc4258 --OtherAccess Content-Type: Message/External-body; name="rfc4258.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <051116180602.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 16 Nov 2005 23:31:05 +0000 Message-ID: <437BC0FD.7030003@psg.com> Date: Thu, 17 Nov 2005 00:30:05 +0100 From: dimitri papadimitriou Reply-To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.11) Gecko/20050728 MIME-Version: 1.0 To: Adrian Farrel CC: ccamp@ops.ietf.org Subject: Re: IGP Extensions - CCAMP Milestones Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit adrian, could you explain the reasoning for having a TE specific TLV in the auto-mesh document with area and AS-wide flooding scope while the TE router cap TLV is restricted to an area flooding scope ? shouldn't be one way or the other i.e. either restrict all TE info area-local or allow for TE router cap TLV with AS-wide flooding scope ? note: there is nothing in the TE router cap TLV that would impact scaling more than the TE auto-mesh TLV does thanks, - dimitri. Adrian Farrel wrote: > Hi, > > We have two immediate milestones to address: > > Oct 05 First version WG I-D for Advertising TE Node Capabilities in ISIS > and OSPF > Oct 05 First version WG I-D for Automatic discovery of MPLS-TE mesh > membership > > There are two personal submissions which address these topics: > draft-vasseur-ccamp-te-node-cap-01.txt > draft-vasseur-ccamp-automesh-02.txt > > I propose that we move these into the WG and then kick the tires > thoroughly. > > Opinions please. > > Thanks, > Adrian > > > > . > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 16 Nov 2005 21:11:57 +0000 Message-ID: <04f501c5eaf2$ca9206c0$d501a8c0@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: IGP Extensions - CCAMP Milestones Date: Wed, 16 Nov 2005 21:14:46 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi, We have two immediate milestones to address: Oct 05 First version WG I-D for Advertising TE Node Capabilities in ISIS and OSPF Oct 05 First version WG I-D for Automatic discovery of MPLS-TE mesh membership There are two personal submissions which address these topics: draft-vasseur-ccamp-te-node-cap-01.txt draft-vasseur-ccamp-automesh-02.txt I propose that we move these into the WG and then kick the tires thoroughly. Opinions please. Thanks, Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 16 Nov 2005 21:07:46 +0000 Message-ID: <04ef01c5eaf1$f3a79030$d501a8c0@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: CCAMP Minutes - Help! Date: Wed, 16 Nov 2005 21:08:48 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi, Two nice people took minutes at CCAMP. I have Deborah's (excellent as usual) I have lost the second set. I can't even recall who took notes! Richard? Any help? Otherwise I will publish what I have (which is pretty complete). Cheers, Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 15 Nov 2005 13:34:39 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Question about Reoptimization draft-ietf-ccamp-loose-path-reopt Date: Tue, 15 Nov 2005 14:34:01 +0100 Message-ID: Thread-Topic: Question about Reoptimization draft-ietf-ccamp-loose-path-reopt Thread-Index: AcXp6H4AXImXS1+9Tn+I7+nXh2bqZwAAFLWw From: "LE ROUX Jean-Louis RD-CORE-LAN" To: , , Hi Faisal, Make before break reoptimization requires a new LSP id, which is under = control of the head-end LSR. Regards, JL > -----Message d'origine----- > De : owner-ccamp@ops.ietf.org=20 > [mailto:owner-ccamp@ops.ietf.org] De la part de Faisal Aslam > Envoy=E9 : mardi 15 novembre 2005 13:17 > =C0 : ccamp@ops.ietf.org > Objet : Question about Reoptimization=20 > draft-ietf-ccamp-loose-path-reopt >=20 > Hi, >=20 > I want to know that if a border router is working in=20 > "Mid-point explicit notification mode" and a link or node has=20 > to go down due to maintenance reasons. Then why not the=20 > mid-point can reoptimize the (sub portion of) path locally=20 > "without" notifying to the ingress node? > The draft says in above case ingress MUST decided to=20 > reoptimize (no other choice) then why to wait for ingress=20 > decision in the first place and not to perform reoptimization locally? > I think that the local node can remember the next-loose-hop=20 > node with which the path was originally signaled and later,=20 > in the event of local maintenance it should reoptimized=20 > without involving ingress (hence save signaling/time). >=20 > Faisal >=20 >=20 Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 15 Nov 2005 13:19:37 +0000 Message-ID: <4379D1D4.9070202@telecom.lth.se> Date: Tue, 15 Nov 2005 14:17:24 +0200 From: Faisal Aslam Reply-To: faisal@telecom.lth.se, faisal@lums.edu.pk User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) MIME-Version: 1.0 To: ccamp@ops.ietf.org Subject: Question about Reoptimization draft-ietf-ccamp-loose-path-reopt Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, I want to know that if a border router is working in "Mid-point explicit notification mode" and a link or node has to go down due to maintenance reasons. Then why not the mid-point can reoptimize the (sub portion of) path locally "without" notifying to the ingress node? The draft says in above case ingress MUST decided to reoptimize (no other choice) then why to wait for ingress decision in the first place and not to perform reoptimization locally? I think that the local node can remember the next-loose-hop node with which the path was originally signaled and later, in the event of local maintenance it should reoptimized without involving ingress (hence save signaling/time). Faisal Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 14 Nov 2005 15:08:24 +0000 Message-ID: <01dd01c5e92d$56df92e0$d501a8c0@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Promoting 3946bis to WG status Date: Mon, 14 Nov 2005 15:08:51 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi, We discussed this I-D in Vancouver. It is clear that we need to update the RFC for minor changes. Editors: - please submit draft-papadimitriou-ccamp-rfc3946bis-00.txt as draft-ietf-ccamp-rfc3946bis-00.txt - please make no changes (except date and document name) - in particular, please leave the notes in place. Thanks, Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 10 Nov 2005 22:39:07 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: Supporting the GELS work Date: Thu, 10 Nov 2005 16:36:54 -0600 Message-ID: <449B2580D802A443A923DABF3EAB82AF0AEF6257@OCCLUST04EVS1.ugd.att.com> Thread-Topic: Supporting the GELS work Thread-Index: AcXk0Wy78IJo9ky1RS6m1xuc3Aeg2ABc52vg From: "Brungard, Deborah A, ALABS" To: , , Support the work (w or w/o WG)- and as other operators noted at the mike, w/o any comment on the proposals at this early phase- Deborah=20 -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Michael.Dueser@t-systems.com Sent: Tuesday, November 08, 2005 9:01 PM To: gels@rtg.ietf.org; ccamp@ops.ietf.org Subject: Supporting the GELS work Hi, I believe that the wrong question was asked at the end of the GELS BoF, which didn't allow me to explicitly express support for forming a GELS working group. I would, therefore, urgently ask everybody with an interest in the GELS work to explicitly express his/her support on the mailing list so we can keep momentum and continue work on this important topic. =20 Many thanks, Michael Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 10 Nov 2005 17:41:04 +0000 Message-ID: <052701c5e61e$14fd7750$cf6d34d1@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Rich Bradford (rbradfor)" , , Cc: Subject: Re: Clarification on object padding for Call-ID in RFC3474 Date: Thu, 10 Nov 2005 17:42:03 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi Richard, RFC3474 documents procedures and protocol elements developed in another SDO, and presents them as an Informational RFC. It is an informational document issued primarily for IANA purposes. That is, in order to reserve the necessary code points, it was desirable to have an RFC. Arguably, this RFC did not need to include the encodings of the various objects, and they are certainly only here in an informational context. I suggest that the best thing to do when you see deficiencies and issues with the content of this RFC is to redirect your questions to the source SDO (is it the OIF or the ITU-T?), but the editors of this RFC may be able to help you. Cheers, Adrian ----- Original Message ----- From: "Rich Bradford (rbradfor)" To: ; Cc: Sent: Thursday, November 10, 2005 3:54 PM Subject: Clarification on object padding for Call-ID in RFC3474 In RFC3474, section 4.1.1 describes the Call-ID. The Call-ID has a variable-length field, the source LSR address toward the end of the object as follows: ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source LSR address | ~ ... ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Local identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Local identifier (continued) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Where the source LSR address length is defined its type: For Type=0x01, the source LSR address is 4 bytes For Type=0x02, the source LSR address is 16 bytes For Type=0x03, the source LSR address is 20 bytes For type=0x04, the source LSR address is 6 bytes For type=0x7f, the source LSR address has the length defined by the vendor Since type=0x04 (and possibly type 0x7f) has a size that is not a multiple of 4 bytes, the issue of padding and alignment is raised. Pad bytes for objects are by default added to the end of an object and not counted in the length (option A below). However, the diagram appears to indicate 32-bit alignment of the Local identifier (Option B below). So, for type=0x4, do we have: A) Source LSR (6 bytes), Local Identifier (8 bytes), pad (2 bytes) Or B) Source LSR (6 bytes), pad (2 bytes), Local Identifier (8 bytes). Thanks for your time, Rich Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 10 Nov 2005 15:57:28 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: Clarification on object padding for Call-ID in RFC3474 Date: Thu, 10 Nov 2005 10:54:58 -0500 Message-ID: <3C292CE901FC634693F24FB2DDC4D332C16E2E@xmb-rtp-20d.amer.cisco.com> Thread-Topic: Clarification on object padding for Call-ID in RFC3474 Thread-Index: AcXmDxm/Wsp7a62AQhOlQkyyyGNcMA== From: "Rich Bradford \(rbradfor\)" To: , Cc: In RFC3474, section 4.1.1 describes the Call-ID. The Call-ID has a variable-length field, the source LSR address toward the end of the object as follows: ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source LSR address | ~ ... ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Local identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Local identifier (continued) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Where the source LSR address length is defined its type: For Type=3D0x01, the source LSR address is 4 bytes For Type=3D0x02, the source LSR address is 16 bytes For Type=3D0x03, the source LSR address is 20 bytes For type=3D0x04, the source LSR address is 6 bytes For type=3D0x7f, the source LSR address has the length defined by the vendor Since type=3D0x04 (and possibly type 0x7f) has a size that is not a multiple of 4 bytes, the issue of padding and alignment is raised. Pad bytes for objects are by default added to the end of an object and not counted in the length (option A below). However, the diagram appears to indicate 32-bit alignment of the Local identifier (Option B below). So, for type=3D0x4, do we have: A) Source LSR (6 bytes), Local Identifier (8 bytes), pad (2 bytes) Or B) Source LSR (6 bytes), pad (2 bytes), Local Identifier (8 bytes). Thanks for your time, Rich Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 09 Nov 2005 23:41:27 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Question about the existence of GELS Date: Thu, 10 Nov 2005 00:40:03 +0100 Message-ID: <7DBAFEC6A76F3E42817DF1EBE64CB02602B79F21@FTRDMEL2.rd.francetelecom.fr> Thread-Topic: Question about the existence of GELS Thread-Index: AcXlB++mw89GValZTESJ5ud9o3kAPgAc40Og From: "MEURIC Julien RD-CORE-LAN" To: , "Zafar Ali \(zali\)" , , , Hello all. Thanks Adrian for having a native English speaker pointing this out. As a non native English speaker who was there, I was so expecting the question about creating a WG that I did not even vote for a 2nd BoF... because I did not want another BoF, but a WG! Anyway, I really keep on supporting the GELS work. Regards, Julien -----Original Message----- From: gels-bounces@rtg.ietf.org [mailto:gels-bounces@rtg.ietf.org] On Behalf Of Adrian Farrel Hi Zafar, > I think there were ONLY 4 or 5 of you. 4 or 5 of whom? 4 or 5 people who did not parse the question? Where I was standing multiple people were confused by the question. I certainly was, and I am a native English speaker. OTOH, I assume we were taking a sense of the room not having a vote, and I think that the major consensus was not to support either of the two questions asked at the time they were asked > Are we not done, or we let it linger? >From my personal perspective, I believe this needs more investingation. Thanks, Adrian > -----Original Message----- > From: owner-ccamp@ops.ietf.org > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of > Michael.Dueser@t-systems.com > Sent: Tuesday, November 08, 2005 8:59 PM > To: gels@rtg.ietf.org; ccamp@ops.ietf.org > Subject: > > Hi, > > I believe that the wrong question was asked at the end of the > GELS BoF, which didn't allow me to explicitly express support > for forming a GELS working group. I would, therefore, > urgently ask everybody with an interest in the GELS work to > explicitly express his/her support on the mailing list so we > can keep momentum and continue work on this important topic. > > Many thanks, > > Michael > _______________________________________________ gels mailing list gels@rtg.ietf.org https://rtg.ietf.org/mailman/listinfo/gels Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 09 Nov 2005 22:30:54 +0000 Message-ID: <03d101c5e57d$60680670$cf6d34d1@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Presenters: please check your slides Date: Wed, 9 Nov 2005 22:31:37 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi, I have wrestled the new meetings tool to the ground, and I think I have all the right slides updated in the right places. Please check the slides and let me know that they are the ones you hoped I would publish. Thanks, Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 09 Nov 2005 17:15:21 +0000 Date: Wed, 09 Nov 2005 09:15:01 -0800 From: lidan 37133 Subject: =?gb2312?B?u9i4tA==?=:Supporting the GELS work To: Michael.Dueser@t-systems.com Cc: gels@rtg.ietf.org, ccamp@ops.ietf.org Message-id: MIME-version: 1.0 Content-type: text/plain; charset=gb2312 Content-language: zh-CN Content-transfer-encoding: quoted-printable Content-disposition: inline I support this GELS work=2E Dan Li ----- =D4=AD=D3=CA=BC=FE ----- =B4=D3=3A Michael=2EDueser=40t-systems=2Ecom =C8=D5=C6=DA=3A =D0=C7=C6=DA=B6=FE=2C =CA=AE=D2=BB=D4=C2 8=C8=D5=2C 2005 = =CF=C2=CE=E76=3A00 =D6=F7=CC=E2=3A Supporting the GELS work =3E Hi=2C =3E = =3E I believe that the wrong question was asked at the end of the GELS = =3E BoF=2C which didn=27t allow me to explicitly express support for = =3E forming a GELS working group=2E I would=2C therefore=2C urgently ask = =3E everybody with an interest in the GELS work to explicitly express = =3E his/her support on the mailing list so we can keep momentum and = =3E continue work on this important topic=2E = =3E = =3E Many thanks=2C =3E = =3E Michael =3E = =3E = =3E Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 09 Nov 2005 17:06:37 +0000 Thread-Topic: Supporting the GELS work thread-index: AcXlUAdpkJrHPDOuQNKe14YUDp71jg== Content-Transfer-Encoding: 7bit Reply-To: "Kim Young Hwa" From: "Kim Young Hwa" To: , , Cc: Bcc: Subject: RE: Supporting the GELS work Date: Thu, 10 Nov 2005 02:07:13 +0900 Comment: GQ19@|@ZEk=E?,18?x, OAM1b MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00B8_01C5E59B.7753F650" Content-Class: urn:content-classes:message This is a multi-part message in MIME format. ------=_NextPart_000_00B8_01C5E59B.7753F650 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: base64 ------=_NextPart_000_00B8_01C5E59B.7753F650 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: base64 PERJViBpZD1tc2dib2R5IHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBTeXN0 ZW0iPg0KPERJVj5IaSw8L0RJVj4NCjxESVY+SSBhbHNvIHN1cHBvcnQgdGhpcyBraW5kIG9mIFdH LjwvRElWPg0KPERJVj5JTUhPLCB0aGlzIGtpbmQgb2YgV0cgaXMgYSBnb29kIGFwcGxpY2F0aW9u IGZvciBHTVBMUyBmaWVsZC48L0RJVj4NCjxESVY+QW5kLCBJIHRoaW5rIHRoYXQgSUVURiBTSE9V TEQgbm90IGJlIGEgcGxhY2UgZm9yIHN1cHBvcnRpbmcgYSBwcm9maXQgb2Ygc3BlY2lhbCAodmVu ZGVyKSBncm91cHMuPC9ESVY+DQo8RElWPkJ1dCwgWWVzdGRheSdzIG1vb2QgaXMgbm90IHNvLjwv RElWPg0KPERJVj48QlI+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08QlI+PEI+U2VuZGVyOjwv Qj4gIk1pY2hhZWwuRHVlc2VyQHQtc3lzdGVtcy5jb20iICZsdDtNaWNoYWVsLkR1ZXNlckB0LXN5 c3RlbXMuY29tJmd0OzxCUj48Qj5EYXRlIFNlbnQ6PC9CPiAyMDA1LTExLTA5Jm5ic3A7QU0gMTE6 MDA6MzQ8QlI+PEI+UmVjZWl2ZXI6PC9CPiAiZ2Vsc0BydGcuaWV0Zi5vcmciICZsdDtnZWxzQHJ0 Zy5pZXRmLm9yZyZndDssICJjY2FtcEBvcHMuaWV0Zi5vcmciICZsdDtjY2FtcEBvcHMuaWV0Zi5v cmcmZ3Q7PEJSPjxCPkNjOjwvQj4gPEJSPjxCPlRpdGxlOjwvQj4gU3VwcG9ydGluZyB0aGUgR0VM UyB3b3JrPEJSPjxCUj48L0RJVj4NCjxESVY+PCEtLSBDb252ZXJ0ZWQgZnJvbSB0ZXh0L3BsYWlu IGZvcm1hdCAtLT48QlI+DQo8UD48Rk9OVCBzaXplPTI+SGksPEJSPjxCUj5JIGJlbGlldmUgdGhh dCB0aGUgd3JvbmcgcXVlc3Rpb24gd2FzIGFza2VkIGF0IHRoZSBlbmQgb2YgdGhlIEdFTFMgQm9G LCB3aGljaCBkaWRuJ3QgYWxsb3cgbWUgdG8gZXhwbGljaXRseSBleHByZXNzIHN1cHBvcnQgZm9y IGZvcm1pbmcgYSBHRUxTIHdvcmtpbmcgZ3JvdXAuIEkgd291bGQsIHRoZXJlZm9yZSwgdXJnZW50 bHkgYXNrIGV2ZXJ5Ym9keSB3aXRoIGFuIGludGVyZXN0IGluIHRoZSBHRUxTIHdvcmsgdG8gZXhw bGljaXRseSBleHByZXNzIGhpcy9oZXIgc3VwcG9ydCBvbiB0aGUgbWFpbGluZyBsaXN0IHNvIHdl IGNhbiBrZWVwIG1vbWVudHVtIGFuZCBjb250aW51ZSB3b3JrIG9uIHRoaXMgaW1wb3J0YW50IHRv cGljLiZuYnNwOzxCUj48QlI+TWFueSB0aGFua3MsPEJSPjxCUj5NaWNoYWVsPEJSPjxCUj48QlI+ PC9GT05UPjwvUD48L0RJVj48L0RJVj48aW1nIHN0eWxlPSJkaXNwbGF5Om5vbmUiIHdpZHRoPTAg aGVpZ2h0PTAgc3JjPSJodHRwOi8vdW1haWwuZXRyaS5yZS5rci9FeHRlcm5hbF9SZWFkQ2hlY2su YXNweD9lbWFpbD1jY2FtcEBvcHMuaWV0Zi5vcmcmbmFtZT1jY2FtcCU0MG9wcy5pZXRmLm9yZyZm cm9tZW1haWw9eWh3a2ltQGV0cmkucmUua3ImbWVzc2FnZWlkPSUzQ2UzYjdiYTRlLTBmYzctNGI3 OC05ZjNlLTBlOGJhYmZkOWUyZUBldHJpLnJlLmtyJTNFIj4= ------=_NextPart_000_00B8_01C5E59B.7753F650-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 09 Nov 2005 09:35:35 +0000 Message-Id: <6.0.1.1.0.20051109102054.05c2adf8@tmspop.telia.se> Date: Wed, 09 Nov 2005 10:32:39 +0100 To: Michael.Dueser@t-systems.com,gels@rtg.ietf.org,ccamp@ops.ietf.org From: Thomas Eriksson Subject: Re: Supporting the GELS work Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Hi, >I believe that the wrong question was asked at the end of the GELS BoF, >which didn't allow me to explicitly express support for forming a GELS >working group. I am not in Vancover so I could not attend the meeting so I do not know what the questions was. > I would, therefore, urgently ask everybody with an interest in the GELS > work to explicitly express his/her support on the mailing list so we can > keep momentum and continue work on this important topic. I support the GELS work continuing in a separate working group. I agree that the momentum must not be lost. Thomas Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 09 Nov 2005 08:30:22 +0000 Message-ID: <024e01c5e508$2118ce20$cf6d34d1@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Zafar Ali (zali)" , , , Subject: Re: Question about the existence of GELS Date: Wed, 9 Nov 2005 08:32:04 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi Zafar, > I think there were ONLY 4 or 5 of you. 4 or 5 of whom? 4 or 5 people who did not parse the question? Where I was standing multiple people were confused by the question. I certainly was, and I am a native English speaker. OTOH, I assume we were taking a sense of the room not having a vote, and I think that the major consensus was not to support either of the two questions asked at the time they were asked > Are we not done, or we let it linger? >From my personal perspective, I believe this needs more investingation. Thanks, Adrian > -----Original Message----- > From: owner-ccamp@ops.ietf.org > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of > Michael.Dueser@t-systems.com > Sent: Tuesday, November 08, 2005 8:59 PM > To: gels@rtg.ietf.org; ccamp@ops.ietf.org > Subject: > > Hi, > > I believe that the wrong question was asked at the end of the > GELS BoF, which didn't allow me to explicitly express support > for forming a GELS working group. I would, therefore, > urgently ask everybody with an interest in the GELS work to > explicitly express his/her support on the mailing list so we > can keep momentum and continue work on this important topic. > > Many thanks, > > Michael > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 09 Nov 2005 07:28:42 +0000 Sensitivity: Subject: Re: Supporting the GELS work To: "Michael.Dueser" Cc: "gels" , "ccamp" Message-ID: From: "Diego Caviglia" Date: Wed, 9 Nov 2005 08:27:25 +0100 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Michael, I support this kind of WG. Regards Diego Michael.Dueser@t-systems.com@ops.ietf.org on 09/11/2005 03.00.34 Sent by: owner-ccamp@ops.ietf.org To: gels@rtg.ietf.org, ccamp@ops.ietf.org cc: Subject: Supporting the GELS work Hi, I believe that the wrong question was asked at the end of the GELS BoF, which didn't allow me to explicitly express support for forming a GELS working group. I would, therefore, urgently ask everybody with an interest in the GELS work to explicitly express his/her support on the mailing list so we can keep momentum and continue work on this important topic. Many thanks, Michael Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 09 Nov 2005 02:23:12 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: Date: Tue, 8 Nov 2005 21:22:48 -0500 Message-ID: Thread-Index: AcXk0VsyoLsY0MGASFi2LLFTWV1lJAAAsPQA From: "Zafar Ali \(zali\)" To: , , Hi,=20 I think there were ONLY 4 or 5 of you. Are we not done, or we let it linger?=20 Thanks Regards... Zafar =20 > -----Original Message----- > From: owner-ccamp@ops.ietf.org=20 > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of=20 > Michael.Dueser@t-systems.com > Sent: Tuesday, November 08, 2005 8:59 PM > To: gels@rtg.ietf.org; ccamp@ops.ietf.org > Subject:=20 >=20 > Hi, >=20 > I believe that the wrong question was asked at the end of the=20 > GELS BoF, which didn't allow me to explicitly express support=20 > for forming a GELS working group. I would, therefore,=20 > urgently ask everybody with an interest in the GELS work to=20 > explicitly express his/her support on the mailing list so we=20 > can keep momentum and continue work on this important topic. =20 >=20 > Many thanks, >=20 > Michael >=20 Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 09 Nov 2005 02:19:30 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: draft-shiomoto-ccamp-lsp-hierarchy-bis-00.txt Date: Tue, 8 Nov 2005 21:18:53 -0500 Message-ID: Thread-Topic: draft-shiomoto-ccamp-lsp-hierarchy-bis-00.txt Thread-Index: AcXULGLn/jq48vKORQ+7wW/v9O6LLAPnk+ZAAEHTiDA= From: "Zafar Ali \(zali\)" To: "Don Fedyk" , Cc: "Adrian Farrel" , "Arthi Ayyangar" , "Richard Rabbat" , "Kohei Shiomoto" > -----Original Message----- > From: owner-ccamp@ops.ietf.org=20 > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Don Fedyk > Sent: Tuesday, November 08, 2005 10:06 AM > To: ccamp@ops.ietf.org > Cc: Adrian Farrel; Arthi Ayyangar; Richard Rabbat; Kohei Shiomoto > Subject: draft-shiomoto-ccamp-lsp-hierarchy-bis-00.txt >=20 > Hi >=20 > Thanks for the presentation yesterday. A thought occurred to=20 > me about the numbered versus unnumbered issue in your draft.=20 > (Note I will not refer to the multiple instances of the=20 > control plane since as discussed > in the meeting I think this should be out of scope). =20 >=20 Don,=20 Do you agree that we need to support di-directional FA-LSP?=20 If we agree that "dynamic FA-LSP" is a good thing, I see no other way around but to have the hooks that are needed to flood the TE link at the Egress properly. E.g., use of RRO will be useful to infer the SRLG and AW for the TE link for flooding.=20 I am not happy that we agree with dynamic FA-LSP, but do not agree with the hooks that are needed to make bi-directional FA-LSP floodable w/o having to apply configurations at the Egress LSR.=20 > What I like about the unnumbered identifiers are they are=20 > hierarchical under the GMPLS node ID. I would suggest that=20 > even when an interface is numbered it could have an=20 > unnumbered identifiers as well Why? Also this is not a valid assumption.=20 > and the numbered interface not=20 > be assumed to be advertised but assumed instead to be an=20 > identifier. It is in my opinion a special case when the=20 > numbered interface is out of the same address plan as the=20 > GMPLS control plane. Generally we should not assume this is=20 > true and separating the local identifier context from the=20 > GMPLS control addressing has advantages. (already=20 > illustrated by your draft).=20 >=20 > If we treated all links this way they could have different=20 > identifiers for the purpose of identification and signaling=20 > in the link identifier space (e.g. IP, MAC, NSAP etc) and=20 > uniformly use unnumbered identifiers for all routing and TE=20 > advertisement. I realize this is not the way that unnumbered=20 > links came about but this might be the more "generalized" way=20 > to address this. >=20 > Did you consider this option? I am not sure if I get what you are proposing a 100%, but it does NOT look like a valid assumption or trivial change. May be we can chat after RTG meeting.=20 Thanks Regards... Zafar=20 >=20 > Regards, > Don=20 >=20 Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 09 Nov 2005 02:00:41 +0000 Message-Id: From: Michael.Dueser@t-systems.com To: gels@rtg.ietf.org, ccamp@ops.ietf.org Subject: Supporting the GELS work Date: Wed, 9 Nov 2005 03:00:34 +0100 MIME-Version: 1.0 Content-Type: text/plain Hi, I believe that the wrong question was asked at the end of the GELS BoF, which didn't allow me to explicitly express support for forming a GELS working group. I would, therefore, urgently ask everybody with an interest in the GELS work to explicitly express his/her support on the mailing list so we can keep momentum and continue work on this important topic. Many thanks, Michael Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 09 Nov 2005 02:00:02 +0000 Message-Id: From: Michael.Dueser@t-systems.com To: gels@rtg.ietf.org, ccamp@ops.ietf.org Subject: Date: Wed, 9 Nov 2005 02:58:45 +0100 MIME-Version: 1.0 Content-Type: text/plain Hi, I believe that the wrong question was asked at the end of the GELS BoF, which didn't allow me to explicitly express support for forming a GELS working group. I would, therefore, urgently ask everybody with an interest in the GELS work to explicitly express his/her support on the mailing list so we can keep momentum and continue work on this important topic. Many thanks, Michael Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 08 Nov 2005 21:38:43 +0000 Message-ID: <43711ABB.30708@lab.ntt.co.jp> Date: Wed, 09 Nov 2005 06:38:03 +0900 From: Kohei Shiomoto User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.7.11) Gecko/20050728 MIME-Version: 1.0 To: Don Fedyk CC: ccamp@ops.ietf.org, Adrian Farrel , Arthi Ayyangar , Richard Rabbat Subject: Re: draft-shiomoto-ccamp-lsp-hierarchy-bis-00.txt Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Don Thank you for your comments. > Hi > > Thanks for the presentation yesterday. A thought occurred to me about > the numbered versus unnumbered issue in your draft. (Note I will not > refer to the multiple instances of the control plane since as discussed > in the meeting I think this should be out of scope). As I noted in the response to Dimitri comments, the target control plane instance is useful when we have multiple layer network where there is a client-server relationship between them. > > What I like about the unnumbered identifiers are they are hierarchical > under the GMPLS node ID. I would suggest that even when an interface is We might want to use unnumbered when we need to save the address space as you said. > numbered it could have an unnumbered identifiers as well and the > numbered interface not be assumed to be advertised but assumed instead > to be an identifier. It is in my opinion a special case when the I am not clear what makes us to assign both numbered and unnumbered address on the same interface. Maybe I miss something. > numbered interface is out of the same address plan as the GMPLS control > plane. Generally we should not assume this is true and separating the > local identifier context from the GMPLS control addressing has > advantages. (already illustrated by your draft). Yes. The local interface identifier should come from different address space of the GMPLS control plane address. > > If we treated all links this way they could have different identifiers > for the purpose of identification and signaling in the link identifier > space (e.g. IP, MAC, NSAP etc) and uniformly use unnumbered identifiers > for all routing and TE advertisement. I realize this is not the way > that unnumbered links came about but this might be the more > "generalized" way to address this. > > Did you consider this option? You are saying that numbered interface is used for GMPLS and different identifier is used for upper layer instance, aren't you (unnumbered address is used in GMPLS domain)? It might be a option when we want to advertise the TE-link in GMPLS control plane as well as in the upper layer instance. Please correct me if I misunderstand your point. Thanks, Kohei > > Regards, > Don Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 08 Nov 2005 21:16:37 +0000 Message-ID: <43711533.7080505@lab.ntt.co.jp> Date: Wed, 09 Nov 2005 06:14:27 +0900 From: Kohei Shiomoto User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.7.11) Gecko/20050728 MIME-Version: 1.0 To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be CC: ccamp@ops.ietf.org, Adrian Farrel , Arthi Ayyangar , Richard Rabbat Subject: Re: I-D ACTION:draft-shiomoto-ccamp-lsp-hierarchy-bis-00.txt Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Dimitri Sorry for not responding sooner. > hi kohei > > Kohei Shiomoto wrote: > >> Hi Dimitri, >> >> dimitri papadimitriou wrote: >> >>> all, >>> >>> i don't think the issues of advertising an LSP as a TE link in >>> another instance of the control plane than the one used for creating >>> the LSP - ditto >>> >>> "[HIERAR] did not consider scenarios where an LSP is created (and >>> maintained) by one instance of the GMPLS control plane, and is used >>> as a (TE) link by another instance of the GMPLS control plane." >>> >>> is only a matter of indicating to which instance this advertisement >>> should be done; >> >> >> I am happy if you could point out what is missing. > > > it is a matter of knowing whether the head-end (of the "LSP") is > 1. within the same area than the tail-end > 2. the advertisement generated by the tail-end is going to reach the > head-end and vice versa (as i think the draft makes no assumption about > the routing adjacencies that allows exchanging this information) - note: > this condition was kind of implicitly guaranteed in the [HIER] document > I assume that the both endpoints are in the same area. Routing adjacency could be brought up on it if needed. >>> now, in addition to the "routing" part, there is the whole discussion >>> about the maintenance of the (inherited) TE link - as we are speaking >>> here about separate instance - some specific mechanism may be needed >>> otherwise after their creation there may be no easy way to >>> communicate their unavailability >> >> >> The draft proposes the method to advertise the LSP created in the GMPLS >> domain to the different routing instance, MPLS domain for instance. > > > the difference is now that either you rely on the signaling capabilities > to tell you (Notify, PathErr) whether the LSP is down - but you have to > pass the information to the upper instance - or you are being made aware > from the upper instance advertisement but the convergence time may be > higher now there is a side issue here a loss of routing adjacency may be > such that you loss a TE link even if the TE link is not down Yes, routing convergence time may be higher. > >>> another more specific question on this document, what is the >>> definition of the value space for the "Target Control Plane Instance" ? >> >> >> Good question. We use a 32-bit space at this time. If you have any >> recommendation, I would be happy to hear that. You think that RD might >> be a good choice for instance, don't you. > > > what do you mean by RD ? i would say for instance the Area ID in OSPF Here I am assuming that several independent service networks are provided on top of a common GMPLS-based network. Target control plane instance is used to identify the service network. Route Distinguisher might be used for this purpose. In addition, it might be a good idea to add Area ID. > >>> a last point, section 4 mentions >>> >>> "This is not believed to be an issue as an informal survey indicated >>> that dynamically signalled numbered FAs had not been deployed. >>> Indeed it was the attempt to implement numbered FAs that gave rise to >>> the work on this document." ... is there a general feeling that >>> having this mechanism will make dynamically triggered numbered FA a >>> reality ? >> >> >> I hope so. > > > it may be a good sense to know whether provisioned numbered FAs where > used before advising a specific mechanism for triggered once - do we > have some feedback on this ? > > thanks, > - dimitri. > >> Thank you for your comments. >> --- >> Kohei >> >> PS >> I am now about to be on trip. I may not be able to respond timely. I >> apologize. >> >> >>> thanks, >>> - dimitri. >>> >>> Internet-Drafts@ietf.org wrote: >>> >>> >>>> A New Internet-Draft is available from the on-line Internet-Drafts >>>> directories. >>>> >>>> >>>> Title : Advertisement of hierarchical and stitchable LSPs >>>> as TE Links Author(s) : K. Shiomoto, et al. >>>> Filename : draft-shiomoto-ccamp-lsp-hierarchy-bis-00.txt >>>> Pages : 15 >>>> Date : 2005-10-18 >>>> This document addresses topics related to hierarchical and >>>> stitched Label Switched Paths (LSPs). It describes extensions to >>>> allow an egress to identify that an LSP will be used as a >>>> dynamically signaled Forwarding Adjacency LSP (FA-LSP) in the case >>>> of numbered FA's. In addition, the document addresses the issue of >>>> how to indicate that an LSP should be advertised as a TE link into a >>>> different instance of the control plane and how to identify the >>>> instance that should be used. A URL for this Internet-Draft is: >>>> http://www.ietf.org/internet-drafts/draft-shiomoto-ccamp-lsp-hierarchy-bis-00.txt >>>> >>>> >>>> To remove yourself from the I-D Announcement list, send a message to >>>> i-d-announce-request@ietf.org with the word unsubscribe in the body >>>> of the message. You can also visit >>>> https://www1.ietf.org/mailman/listinfo/I-D-announce to change your >>>> subscription settings. >>>> >>>> >>>> Internet-Drafts are also available by anonymous FTP. Login with the >>>> username >>>> "anonymous" and a password of your e-mail address. After logging in, >>>> type "cd internet-drafts" and then >>>> "get draft-shiomoto-ccamp-lsp-hierarchy-bis-00.txt". >>>> >>>> A list of Internet-Drafts directories can be found in >>>> http://www.ietf.org/shadow.html or >>>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>>> >>>> >>>> Internet-Drafts can also be obtained by e-mail. >>>> >>>> Send a message to: >>>> mailserv@ietf.org. >>>> In the body type: >>>> "FILE >>>> /internet-drafts/draft-shiomoto-ccamp-lsp-hierarchy-bis-00.txt". >>>> NOTE: The mail server at ietf.org can return the document in >>>> MIME-encoded form by using the "mpack" utility. To use this >>>> feature, insert the command "ENCODING mime" before the "FILE" >>>> command. To decode the response(s), you will need "munpack" or >>>> a MIME-compliant mail reader. Different MIME-compliant mail readers >>>> exhibit different behavior, especially when dealing with >>>> "multipart" MIME messages (i.e. documents which have been split >>>> up into multiple messages), so check your local documentation on >>>> how to manipulate these messages. >>>> Below is the data which will enable a MIME compliant >>>> mail reader >>>> implementation to automatically retrieve the ASCII version of the >>>> Internet-Draft. >>>> >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> >>>> _______________________________________________ >>>> I-D-Announce mailing list >>>> I-D-Announce@ietf.org >> >> >> Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 08 Nov 2005 15:11:34 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: draft-shiomoto-ccamp-lsp-hierarchy-bis-00.txt Date: Tue, 8 Nov 2005 10:06:05 -0500 Message-ID: <34B3EAA5B3066A42914D28C5ECF5FEA40512DB40@zrtphxm2> Thread-Topic: draft-shiomoto-ccamp-lsp-hierarchy-bis-00.txt Thread-Index: AcXULGLn/jq48vKORQ+7wW/v9O6LLAPnk+ZA From: "Don Fedyk" To: Cc: "Adrian Farrel" , "Arthi Ayyangar" , "Richard Rabbat" , "Kohei Shiomoto" Hi Thanks for the presentation yesterday. A thought occurred to me about the numbered versus unnumbered issue in your draft. (Note I will not refer to the multiple instances of the control plane since as discussed in the meeting I think this should be out of scope). =20 What I like about the unnumbered identifiers are they are hierarchical under the GMPLS node ID. I would suggest that even when an interface is numbered it could have an unnumbered identifiers as well and the numbered interface not be assumed to be advertised but assumed instead to be an identifier. It is in my opinion a special case when the numbered interface is out of the same address plan as the GMPLS control plane. Generally we should not assume this is true and separating the local identifier context from the GMPLS control addressing has advantages. (already illustrated by your draft).=20 If we treated all links this way they could have different identifiers for the purpose of identification and signaling in the link identifier space (e.g. IP, MAC, NSAP etc) and uniformly use unnumbered identifiers for all routing and TE advertisement. I realize this is not the way that unnumbered links came about but this might be the more "generalized" way to address this. Did you consider this option? Regards, Don=20 Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 08 Nov 2005 09:10:44 +0000 Message-ID: <00f301c5e444$8f8f00f0$cf6d34d1@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Cc: , "WG Milestone Tracker" Subject: Publication request : draft-ietf-ccamp-gmpls-ason-routing-eval-02.txt Date: Tue, 8 Nov 2005 09:11:32 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi Alex, Not sure quite how this got published before the end of the week, but anyway, here it is. This version of this I-D has been through CCAMP WG last call and has been updated to my satisfaction. Can you please add it to the system for publication as an Informational I-D. Thanks, Adrian ----- Original Message ----- From: To: Cc: Sent: Monday, November 07, 2005 11:50 PM Subject: I-D ACTION:draft-ietf-ccamp-gmpls-ason-routing-eval-02.txt > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. > > Title : Evaluation of existing Routing Protocols > against ASON routing requirements > Author(s) : D. Papadimitriou, et al. > Filename : draft-ietf-ccamp-gmpls-ason-routing-eval-02.txt > Pages : 0 > Date : 2005-11-7 > > The Generalized MPLS (GMPLS) suite of protocols has been defined to > control different switching technologies as well as different > applications. These include support for requesting TDM connections > including SONET/SDH and Optical Transport Networks (OTNs). > > This document provides an evaluation of the IETF Routing Protocols > against the routing requirements for an Automatically Switched > Optical Network (ASON) as defined by ITU-T. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-ason-routing-eval-02.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > > Internet-Drafts are also available by anonymous FTP. Login with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-ccamp-gmpls-ason-routing-eval-02.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-ccamp-gmpls-ason-routing-eval-02.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 07 Nov 2005 23:50:23 +0000 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-gmpls-ason-routing-eval-02.txt Message-Id: Date: Mon, 07 Nov 2005 18:50:01 -0500 --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 : Evaluation of existing Routing Protocols against ASON routing requirements Author(s) : D. Papadimitriou, et al. Filename : draft-ietf-ccamp-gmpls-ason-routing-eval-02.txt Pages : 0 Date : 2005-11-7 The Generalized MPLS (GMPLS) suite of protocols has been defined to control different switching technologies as well as different applications. These include support for requesting TDM connections including SONET/SDH and Optical Transport Networks (OTNs). This document provides an evaluation of the IETF Routing Protocols against the routing requirements for an Automatically Switched Optical Network (ASON) as defined by ITU-T. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-ason-routing-eval-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ccamp-gmpls-ason-routing-eval-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ccamp-gmpls-ason-routing-eval-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-11-7164308.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-gmpls-ason-routing-eval-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-gmpls-ason-routing-eval-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-11-7164308.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 07 Nov 2005 23:31:37 +0000 Message-ID: <00a601c5e3f3$c4417770$cf6d34d1@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Don't forget the GELS BoF on Tuesday 3.10pm Date: Mon, 7 Nov 2005 23:28:16 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Don't forget this BoF on using GMPLS for Ethernet Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 07 Nov 2005 23:11:38 +0000 Thread-Topic: Control Plane Resilience Issue thread-index: AcXj8LccC8GecdF5RS699OdOQWgkHA== Reply-To: "Kim Young Hwa" From: "Kim Young Hwa" To: Cc: Content-Transfer-Encoding: 7bit Bcc: Subject: Control Plane Resilience Issue Date: Tue, 8 Nov 2005 08:12:25 +0900 Comment: GQ19@|@ZEk=E?,18?x, OAM1b MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_06B3_01C5E43C.2706B990" Content-Class: urn:content-classes:message This is a multi-part message in MIME format. ------=_NextPart_000_06B3_01C5E43C.2706B990 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: base64 ------=_NextPart_000_06B3_01C5E43C.2706B990 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: base64 PERJViBpZD1tc2dib2R5IHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBTeXN0 ZW0iPg0KPERJVj5IaSw8L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPlVuZm9ydHVuYXRl bHksIEkgZGlkbid0IGhlYXIgdGhhdCBBZHJpYW4gd2FzIGxvb2tpbmcgZm9yIG1lIG9uIHRoaXMg bWVldGluZy48L0RJVj4NCjxESVY+QXQgdGhhdCB0aW1lLCBJIHdhcyBhdCB0aGUgcmVhciBvZiB0 aGUgcm9vbSwgYnV0IEkgbWlzc2VkIHRoYXQuPC9ESVY+DQo8RElWPkluIGFueSBjYXNlLCBJIHNl bnQgbXkgc2xpZGUgdG8gQWRyaWFuIHdobyB1cGxvYWRlZCB0aGF0IG9uIHRoZSBJRVRGIGhvbWUg cGFnZS48L0RJVj4NCjxESVY+VGhpcyBzbGlkZSBpcyBhdmFpbGFibGUmbmJzcDthdDo8L0RJVj4N CjxESVY+PEEgaHJlZj0iaHR0cDovL29uc2l0ZS5pZXRmLm9yZy9wcm9jZWVkaW5ncy8wNW5vdi9z bGlkZXMvY2NhbXAtMzUucHB0Ij5odHRwOi8vb25zaXRlLmlldGYub3JnL3Byb2NlZWRpbmdzLzA1 bm92L3NsaWRlcy9jY2FtcC0zNS5wcHQ8L0E+PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJ Vj5JJ20gbG9va2luZyBmb3J3YXJkIHRvIHlvdXIgY29tbWVudHMgYW5kIGRpc2N1c3Npb24gYWJv dXQgdGhlIENQIHJlc2lsaWVuY2UgaXNzdWUuPC9ESVY+DQo8RElWPkFuZCwgSSB3aWxsIHVwZGF0 ZSB0aGVzZSBkcmFmdHMgZm9yIHRoZSBuZXh0IG1lZXRpbmcsJm5ic3A7YmFzZWQgb24mbmJzcDtk aXNjdXNzaW9uIGZyb20gdGhlIG1haWxpbmcgbGlzdC48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+ DQo8RElWPlRoYW5rcyw8L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPllvdW5nPC9ESVY+ PC9ESVY+PGltZyBzdHlsZT0iZGlzcGxheTpub25lIiB3aWR0aD0wIGhlaWdodD0wIHNyYz0iaHR0 cDovL3VtYWlsLmV0cmkucmUua3IvRXh0ZXJuYWxfUmVhZENoZWNrLmFzcHg/ZW1haWw9Y2NhbXBA b3BzLmlldGYub3JnJm5hbWU9Y2NhbXAlNDBvcHMuaWV0Zi5vcmcmZnJvbWVtYWlsPXlod2tpbUBl dHJpLnJlLmtyJm1lc3NhZ2VpZD0lM0M5MGRjNjYxNy0xM2Q4LTRlMDQtOWUwOS0wMjE4ZDhlY2Yx NWJAZXRyaS5yZS5rciUzRSI+ ------=_NextPart_000_06B3_01C5E43C.2706B990-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 07 Nov 2005 21:11:13 +0000 Message-ID: <007301c5e3df$fef7ec00$cf6d34d1@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Updated slides Date: Mon, 7 Nov 2005 21:10:27 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi, Those of you that used your own slides or have updates, please send them to me ASAP Cheers, Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Sun, 06 Nov 2005 06:56:21 +0000 Message-ID: <01ed01c5e29e$a43f9e30$d501a8c0@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Reminder - agenda and slides on line Date: Sun, 6 Nov 2005 06:52:16 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit http://www3.ietf.org/proceedings/05nov/agenda/ccamp.html Not all of the slides are uploaded yet. Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Sun, 06 Nov 2005 06:45:51 +0000 Message-ID: <01e501c5e29c$ae78e020$d501a8c0@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Fw: [Isis-wg] RFC 4205 on Intermediate System to Intermediate System(IS-IS) Extensions in Support of Generalized Multi-ProtocolLabel Switching (GMPLS) Date: Sun, 6 Nov 2005 06:37:15 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit I think we missed seeing this announcement on the CCAMP list. Adrian ----- Original Message ----- From: To: Cc: ; Sent: Friday, October 28, 2005 12:14 AM Subject: [Isis-wg] RFC 4205 on Intermediate System to Intermediate System(IS-IS) Extensions in Support of Generalized Multi-ProtocolLabel Switching (GMPLS) > > A new Request for Comments is now available in online RFC libraries. > > > RFC 4205 > > Title: Intermediate System to Intermediate System (IS-IS) > Extensions in Support of Generalized > Multi-Protocol Label Switching (GMPLS) > Author(s): K. Kompella, Ed., Y. Rekhter, Ed. > Status: Informational > Date: October 2005 > Mailbox: kireeti@juniper.net, yakov@juniper.net > Pages: 11 > Characters: 22323 > Updates: 3784 > > I-D Tag: draft-ietf-isis-gmpls-extensions-19.txt > > URL: ftp://ftp.rfc-editor.org/in-notes/rfc4205.txt > > > This document specifies encoding of extensions to the IS-IS routing > protocol in support of Generalized Multi-Protocol Label Switching > (GMPLS). > > This document is a product of the IS-IS for IP Internets Working Group > of the IETF. > > This memo provides information for the Internet community. It does > not specify an Internet standard of any kind. Distribution of this > memo is unlimited. > > This announcement is sent to the IETF list and the RFC-DIST list. > Requests to be added to or deleted from the IETF distribution list > should be sent to IETF-REQUEST@IETF.ORG. Requests to be > added to or deleted from the RFC-DIST distribution list should > be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. > > Details on obtaining RFCs via FTP or EMAIL may be obtained by sending > an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body > help: ways_to_get_rfcs. For example: > > To: rfc-info@RFC-EDITOR.ORG > Subject: getting rfcs > > help: ways_to_get_rfcs > > Requests for special distribution should be addressed to either the > author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless > specifically noted otherwise on the RFC itself, all RFCs are for > unlimited distribution. > > Submissions for Requests for Comments should be sent to > RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC > Authors, for further information. > > > Joyce K. Reynolds and Sandy Ginoza > USC/Information Sciences Institute > > ... > > Below is the data which will enable a MIME compliant Mail Reader > implementation to automatically retrieve the ASCII version > of the RFCs. > -------------------------------------------------------------------------- ------ > _______________________________________________ > Isis-wg mailing list > Isis-wg@ietf.org > https://www1.ietf.org/mailman/listinfo/isis-wg > Envelope-to: ccamp-data@psg.com Delivery-date: Sat, 05 Nov 2005 12:16:51 +0000 Message-ID: <000401c5e1f9$c4e86cc0$0601a8c0@pc6> Reply-To: "Tom Petch" From: "Tom Petch" To: Cc: Subject: draft-otani-ccamp-gmpls-?spf-* Date: Fri, 4 Nov 2005 18:52:50 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit These drafts seem to have some unusual formatting which makes them hard for me to view. Most lines start with 18 characters of white space - too much! - and each page seems to start with something unprintable Tom Petch Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 04 Nov 2005 18:22:54 +0000 Message-ID: <436BA68C.9090103@cisco.com> Date: Fri, 04 Nov 2005 10:21:00 -0800 From: Arun Satyanarayana Organization: Cisco Systems User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) MIME-Version: 1.0 To: "Xie, Feng" CC: "'ccamp@ops.ietf.org'" , "Arun Satyanarayana (asatyana)" Subject: Re: Questions on RSVPTE graceful restart Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Feng, Please see inline. Regards, Arun ============================================================== Xie, Feng wrote: > Hi, > > I have the following questions on RSVPTE graceful restart: > > 1. Should a restarting router change the advertised Recovery Time during a > graceful restart recovery? Suppose a restarting router advertises t0 as the > recovery time after a restart. For any reason, should it advertise a > different value for the Recovery Time while it is still in a graceful > restart recovery? How about the RecoveryPath related flags (T/R/S) bits? The processing of Recovery Time as advertised by the restarting node is covered in the parent specs (RFC3471, RFC3473). This I-D does not change the behaviour. Do you have a specific scenario/application where changing the Recovery Time is useful? Not sure what your question on T/R/S bits is. > 2. If a restarting router is allowed to change the advertised Recovery Time > during a graceful restart recovery, how should a helper react to such a > change? For example, support the advertised Recovery Time is changed from t0 > to t1, should the helper extend/shrink the period when it is helping? If so, > should the helping period start from the time when the first hello is > received (and last for t1) or from the time when the first hello with the > new value is received (and last for t1)? Please see above. > 3. Have the class number of Capability object and the message type of > RecoveryPath (both are defined in draft-ietf-ccamp-rsvp-restart-ext-03) been > assigned? IANA assignments are done as part of the IESG review and approval process - please refer to IETF Standards Track processing docs for more info. > Thanks. > > Feng Xie Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 03 Nov 2005 22:49:10 +0000 Message-ID: <00dc01c5e0c9$2e42b860$61849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Cc: "Kireeti Kompella" Subject: Re: WG Action: RECHARTER: Common Control and Measurement Plane (ccamp) Date: Thu, 3 Nov 2005 22:51:44 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit I hope no-one is too shocked that this happened before the end of 2007. Looks like we now the go-ahead to do some work. Of course, our initial milestones are already behind schedule (which may give you a hint as to how long this has been in the pipeline). We will sort all this out over the next couple of weeks and start to move things forwards. Thanks for your support in getting this to happen. Adrian ----- Original Message ----- From: "The IESG" To: Cc: ; "Kireeti Kompella" ; "Adrian Farrel" Sent: Thursday, November 03, 2005 10:06 PM Subject: WG Action: RECHARTER: Common Control and Measurement Plane (ccamp) > The charter of the Common Control and Measurement Plane (ccamp) working group > in the Routing Area of the IETF has been updated. For additional information, > please contact the Area Directors or the working group Chairs. > > +++ > > Common Control and Measurement Plane (ccamp) > ============================================= > > Current Status: Active Working Group > > Chair(s): > Kireeti Kompella > Adrian Farrel > > Routing Area Director(s): > Bill Fenner > Alex Zinin > > Routing Area Advisor: > Alex Zinin > > Technical Advisor(s): > Alex Zinin > > Mailing Lists: > General Discussion: ccamp@ops.ietf.org > To Subscribe: majordomo@ops.ietf.org > In Body: subscribe ccamp > Archive: https://ops.ietf.org/lists/ccamp > > Description of Working Group: > Organizational Overview > > 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), e.g. O-O and O-E-O optical > switches, ATM and Frame Relay switches, MPLS, GRE, in cooperation > with the MPLS WG. In this context, measurement refers to the > acquisition and distribution of attributes relevant to the setting up > of tunnels and paths. > > CCAMP WG work scope includes: > > - Definition of protocol-independent metrics and parameters > (measurement attributes) for describing links and paths that are > required for routing and signaling. These will be developed in > conjunction with requests and requirements from other WGs to > ensure overall usefulness. > > - Definition of protocol(s) and extensions to them required for > link and path attribute measurement. Link Management Protocol (LMP) > is included here. > > - Functional specification of extensions for routing (OSPF, ISIS) and > signalling (RSVP-TE) required for path establishment. Protocol > formats and procedures that embody these extensions will be done > jointly with the WGs supervising those protocols. > > - Definition of the mechanisms required to determine the route and > properties of an established path (tunnel tracing). > > - Definition of MIB modules and other OAM techniques relevant to the > protocols and extensions specified within the WG. > > CCAMP WG currently works on the following tasks: > > - Define how the properties of network resources gathered by a > measurement protocol can be distributed in existing routing > protocols, such as OSPF and IS-IS. CCAMP defines the generic > description of the properties and how they are distributed in OSPF. > The specifics of distribution within IS-IS are being addressed in > the ISIS WG. > > - Define signaling and routing mechanisms and extensions to allow path > and tunnel setup and maintenance across multiple domains, where a > domain may be an IGP area, an Autonomous System, or any other region > of topological visibility. To this end, work cooperatively with the > PCE and MPLS WGs. > > - Define abstract link and path properties needed for link and path > protection. Specify signalling mechanisms for path protection, > diverse routing and fast path restoration. Ensure that multi-layer > path protection and restoration functions are achievable using the > defined signalling, routing, and measurement protocols, either > separately or in combination. > > - Identify which requirements for signaling and routing for ASON are > not currently met by protocols defined in CCAMP; based on these, > define mechanisms to address these requirements. > > - Document issues and strategies for the migration of MPLS-based > deployments to GMPLS. Based on the outcome, identify protocol > machinery that implementations may have to change to ease the > migration from MPLS to GMPLS. > > In doing this work, the WG will work closely with at least the > following other WGs: MPLS, ISIS, OSPF, IDR, L1VPN and PCE. The > WG will also cooperate with the ITU-T. > > Goals and Milestones: > Done Post strawman WG goals and charter > Done Identify and document a limited set of candidate solutions for > signalling and for measurement. Among candidate control solutions to be > considered are the existing GMPLS drafts. > Done Build appropriate design teams > Done Submit WG document defining path setup portions of common control plane > protocol > Done Submit WG document defining common measurement plane protocol > Done Submit LMP MIB to IESG > Done Submit protection & restoration documents to IESG > Done Submit ASON signaling requirements doc to IESG > Done Submit GMPLS MIBs to IESG > Done Produce CCAMP WG document for generic tunnel tracing protocol > Done Produce CCAMP WG document for multi-area/AS signaling and routing > Done Submit ASON routing requirements doc to IESG > Done Submit revised charter and milestones to IESG for IESG consideration of > more detailed deliverables and determination of usefulness of continuation of WG > > Oct 05 First version WG I-D for Advertising TE Node Capabilities in ISIS and > OSPF > Oct 05 First version WG I-D for Automatic discovery of MPLS-TE mesh > membership > Nov 05 Submit ASON Routing evaluation I-D for IESG review > Nov 05 Cross-WG review of I-D for Advertising TE Node Capabilities in ISIS > and OSPF > Nov 05 First version WG I-D MPLS to GMPLS migration strategies > Dec 05 Submit RSVP-TE extensions for inter-domain signaling I-D for IESG > review > Dec 05 Submit Per-domain path computation signaling I-D for IESG review > Dec 05 First version of WG I-D for ASON Routing solutions > Dec 05 First version WG I-D Requirements for Multi-Layer and Multi-Region > Networks > Dec 05 First version WG I-D for Evaluation of existing protocols for MLN/MRN > > Jan 06 Submit GMPLS signaling in support of Call Management I-D for IESG > review > Jan 06 Submit I-D for Advertising TE Node Capabilities in ISIS and OSPF for > IESG review > Jan 06 First version WG I-D for Protocol solutions for MLN/MRN > Jan 06 First version of WG I-D for OSPF-TE/GMPLS MIB module > Jan 06 First version WG Informational I-D for Analysis of inter-domain issues > for disjoint and protected paths > Feb 06 Submit GMPLS/ASON lexicography I-D for IESG review > Feb 06 Submit LSP Stitching I-D for IESG review > Feb 06 First version WG I-D MPLS-GMPLS interworking requirements and > solutions > Mar 06 Submit I-D for Automatic discovery of MPLS-TE mesh membership for IESG > review > Mar 06 First version WG I-D GMPLS OAM Requirements > Apr 06 Submit GMPLS routing and signaling interoperability advice I-D for > IESG review > Apr 06 First version of WG I-D for additional MIB module to cover RSVP-TE > signaling extensions > Jun 06 Submit Informational I-D for Analysis of inter-domain issues for > disjoint and protected paths for IESG review > Oct 06 Submit MPLS to GMPLS migration strategies I-D for IESG review > Nov 06 Submit ASON Routing solutions I-D for IESG review > Dec 06 Submit Requirements for Multi-Layer and Multi-Region Networks I-D for > IESG review > Jan 07 Submit MPLS-GMPLS interworking requirements and solutions I-D for IESG > review > Feb 07 Submit Evaluation of existing protocols for MLN/MRN for IESG review > Mar 07 Submit OSPF-TE/GMPLS MIB module for MIB doctor and IESG review > Jun 07 Submit GMPLS OAM Requirements I-D for IESG review > Aug 07 Submit Protocol solutions for MLN/MRN I-D for IESG review > Dec 07 Submit MIB module for RSVP-TE signaling extensions for MIB doctor and > IESG review > Dec 07 Recharter or close Working Group > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf-announce > > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 03 Nov 2005 22:08:13 +0000 Content-Type: text/plain Mime-Version: 1.0 To: IETF-Announce@ietf.org Cc: ccamp@ops.ietf.org, Kireeti Kompella , Adrian Farrel From: The IESG Subject: WG Action: RECHARTER: Common Control and Measurement Plane (ccamp) Message-Id: Date: Thu, 03 Nov 2005 17:06:16 -0500 The charter of the Common Control and Measurement Plane (ccamp) working group in the Routing Area of the IETF has been updated. For additional information, please contact the Area Directors or the working group Chairs. +++ Common Control and Measurement Plane (ccamp) ============================================= Current Status: Active Working Group Chair(s): Kireeti Kompella Adrian Farrel Routing Area Director(s): Bill Fenner Alex Zinin Routing Area Advisor: Alex Zinin Technical Advisor(s): Alex Zinin Mailing Lists: General Discussion: ccamp@ops.ietf.org To Subscribe: majordomo@ops.ietf.org In Body: subscribe ccamp Archive: https://ops.ietf.org/lists/ccamp Description of Working Group: Organizational Overview 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), e.g. O-O and O-E-O optical switches, ATM and Frame Relay switches, MPLS, GRE, in cooperation with the MPLS WG. In this context, measurement refers to the acquisition and distribution of attributes relevant to the setting up of tunnels and paths. CCAMP WG work scope includes: - Definition of protocol-independent metrics and parameters (measurement attributes) for describing links and paths that are required for routing and signaling. These will be developed in conjunction with requests and requirements from other WGs to ensure overall usefulness. - Definition of protocol(s) and extensions to them required for link and path attribute measurement. Link Management Protocol (LMP) is included here. - Functional specification of extensions for routing (OSPF, ISIS) and signalling (RSVP-TE) required for path establishment. Protocol formats and procedures that embody these extensions will be done jointly with the WGs supervising those protocols. - Definition of the mechanisms required to determine the route and properties of an established path (tunnel tracing). - Definition of MIB modules and other OAM techniques relevant to the protocols and extensions specified within the WG. CCAMP WG currently works on the following tasks: - Define how the properties of network resources gathered by a measurement protocol can be distributed in existing routing protocols, such as OSPF and IS-IS. CCAMP defines the generic description of the properties and how they are distributed in OSPF. The specifics of distribution within IS-IS are being addressed in the ISIS WG. - Define signaling and routing mechanisms and extensions to allow path and tunnel setup and maintenance across multiple domains, where a domain may be an IGP area, an Autonomous System, or any other region of topological visibility. To this end, work cooperatively with the PCE and MPLS WGs. - Define abstract link and path properties needed for link and path protection. Specify signalling mechanisms for path protection, diverse routing and fast path restoration. Ensure that multi-layer path protection and restoration functions are achievable using the defined signalling, routing, and measurement protocols, either separately or in combination. - Identify which requirements for signaling and routing for ASON are not currently met by protocols defined in CCAMP; based on these, define mechanisms to address these requirements. - Document issues and strategies for the migration of MPLS-based deployments to GMPLS. Based on the outcome, identify protocol machinery that implementations may have to change to ease the migration from MPLS to GMPLS. In doing this work, the WG will work closely with at least the following other WGs: MPLS, ISIS, OSPF, IDR, L1VPN and PCE. The WG will also cooperate with the ITU-T. Goals and Milestones: Done Post strawman WG goals and charter Done Identify and document a limited set of candidate solutions for signalling and for measurement. Among candidate control solutions to be considered are the existing GMPLS drafts. Done Build appropriate design teams Done Submit WG document defining path setup portions of common control plane protocol Done Submit WG document defining common measurement plane protocol Done Submit LMP MIB to IESG Done Submit protection & restoration documents to IESG Done Submit ASON signaling requirements doc to IESG Done Submit GMPLS MIBs to IESG Done Produce CCAMP WG document for generic tunnel tracing protocol Done Produce CCAMP WG document for multi-area/AS signaling and routing Done Submit ASON routing requirements doc to IESG Done Submit revised charter and milestones to IESG for IESG consideration of more detailed deliverables and determination of usefulness of continuation of WG Oct 05 First version WG I-D for Advertising TE Node Capabilities in ISIS and OSPF Oct 05 First version WG I-D for Automatic discovery of MPLS-TE mesh membership Nov 05 Submit ASON Routing evaluation I-D for IESG review Nov 05 Cross-WG review of I-D for Advertising TE Node Capabilities in ISIS and OSPF Nov 05 First version WG I-D MPLS to GMPLS migration strategies Dec 05 Submit RSVP-TE extensions for inter-domain signaling I-D for IESG review Dec 05 Submit Per-domain path computation signaling I-D for IESG review Dec 05 First version of WG I-D for ASON Routing solutions Dec 05 First version WG I-D Requirements for Multi-Layer and Multi-Region Networks Dec 05 First version WG I-D for Evaluation of existing protocols for MLN/MRN Jan 06 Submit GMPLS signaling in support of Call Management I-D for IESG review Jan 06 Submit I-D for Advertising TE Node Capabilities in ISIS and OSPF for IESG review Jan 06 First version WG I-D for Protocol solutions for MLN/MRN Jan 06 First version of WG I-D for OSPF-TE/GMPLS MIB module Jan 06 First version WG Informational I-D for Analysis of inter-domain issues for disjoint and protected paths Feb 06 Submit GMPLS/ASON lexicography I-D for IESG review Feb 06 Submit LSP Stitching I-D for IESG review Feb 06 First version WG I-D MPLS-GMPLS interworking requirements and solutions Mar 06 Submit I-D for Automatic discovery of MPLS-TE mesh membership for IESG review Mar 06 First version WG I-D GMPLS OAM Requirements Apr 06 Submit GMPLS routing and signaling interoperability advice I-D for IESG review Apr 06 First version of WG I-D for additional MIB module to cover RSVP-TE signaling extensions Jun 06 Submit Informational I-D for Analysis of inter-domain issues for disjoint and protected paths for IESG review Oct 06 Submit MPLS to GMPLS migration strategies I-D for IESG review Nov 06 Submit ASON Routing solutions I-D for IESG review Dec 06 Submit Requirements for Multi-Layer and Multi-Region Networks I-D for IESG review Jan 07 Submit MPLS-GMPLS interworking requirements and solutions I-D for IESG review Feb 07 Submit Evaluation of existing protocols for MLN/MRN for IESG review Mar 07 Submit OSPF-TE/GMPLS MIB module for MIB doctor and IESG review Jun 07 Submit GMPLS OAM Requirements I-D for IESG review Aug 07 Submit Protocol solutions for MLN/MRN I-D for IESG review Dec 07 Submit MIB module for RSVP-TE signaling extensions for MIB doctor and IESG review Dec 07 Recharter or close Working Group Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 03 Nov 2005 05:05:56 +0000 From: The IESG To: IETF-Announce Cc: Internet Architecture Board , RFC Editor , ccamp mailing list , ccamp chair , ccamp chair Subject: Document Action: 'A Transport Network View of the Link Management Protocol' to Informational RFC Message-Id: Date: Thu, 03 Nov 2005 00:04:31 -0500 The IESG has approved the following document: - 'A Transport Network View of the Link Management Protocol ' as an Informational RFC This document is the product of the Common Control and Measurement Plane Working Group. The IESG contact persons are Alex Zinin and Bill Fenner. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-transport-lmp-02.txt Technical Summary This memo describes the relationship of the LMP procedures to 'discovery' as defined in the International Telecommunication Union (ITU-T), and on-going ITU-T work. This document provides an overview of LMP in the context of the ITU-T Automatically Switched Optical Networks (ASON) and transport network terminology and relates it to the ITU-T discovery work to promote a common understanding for progressing the work of IETF and ITU-T. Working Group Summary The document has been reviewed by the WG, as well as ITU-T SG15, comments have been addressed. The WG had consensus on progressing this document. Protocol Quality Alex Zinin reviewed this document for the IESG. Note to RFC Editor Section 1. NEW TEXT. Insert immediately after heading. ITU-T Recommendation G.8080 Amendment 1 [G.8080] and ITU-T Recommendation G.7714 [G.7714] provide definitions and mechanisms related to transport plane discovery. Note that in the context of this work, "Transport" relates to the data plane (sometimes called the transport plane or the user plane) and does not refer to the transport layer (layer 4) of the OSI seven layer model, nor to concept of transport intended by protocols such as the Transmission Control Protocol (TCP). Special care must be taken with the acronym "TCP" which within the context of the rest of this document means "Termination Connection Point" and does not indicate the Transmission Control Protocol. Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 02 Nov 2005 22:26:08 +0000 Message-ID: <5551AD75D2C0BC459A85A2CEFAE4F8005C06B8@usvissfp01.win.marconi.com> From: "Xie, Feng" To: "'ccamp@ops.ietf.org'" Cc: "Xie, Feng" Subject: Questions on RSVPTE graceful restart Date: Wed, 2 Nov 2005 20:24:37 -0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Hi, I have the following questions on RSVPTE graceful restart: 1. Should a restarting router change the advertised Recovery Time during a graceful restart recovery? Suppose a restarting router advertises t0 as the recovery time after a restart. For any reason, should it advertise a different value for the Recovery Time while it is still in a graceful restart recovery? How about the RecoveryPath related flags (T/R/S) bits? 2. If a restarting router is allowed to change the advertised Recovery Time during a graceful restart recovery, how should a helper react to such a change? For example, support the advertised Recovery Time is changed from t0 to t1, should the helper extend/shrink the period when it is helping? If so, should the helping period start from the time when the first hello is received (and last for t1) or from the time when the first hello with the new value is received (and last for t1)? 3. Have the class number of Capability object and the message type of RecoveryPath (both are defined in draft-ietf-ccamp-rsvp-restart-ext-03) been assigned? Thanks. Feng Xie Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 02 Nov 2005 18:07:18 +0000 Message-Id: From: owner-ccamp@ops.ietf.org Date: Wed, 02 Nov 2005 18:04:58 +0000 > From Jonathan.Lang@sonos.com Sun Oct 30 06:23:46 2005 Received: from [70.184.40.73] (helo=sb-exchange1.rinconnetworks.com) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EW6ba-0001is-DU for ccamp@ops.ietf.org; Sun, 30 Oct 2005 06:23:46 +0000 Subject: RE: Two Drafts for Resilience of Control Plane From: "Jonathan Lang" To: Sender: owner-ccamp@ops.ietf.org Precedence: bulk Zafar, > > > > > -----Original Message----- > > > > > From: Ong, Lyndon [mailto:Lyong@Ciena.com] > > > > > Sent: Friday, October 28, 2005 1:28 PM > > > > > To: ibryskin@movaz.com; dpapadimitriou@psg.com;=20 > > > > > dimitri.papadimitriou@alcatel.be > > > > > Cc: Drake@movaz.com; Drake, John E; > > > > dimitri.papadimitriou@alcatel.be; > > > > Igor > > > > > Bryskin; Zafar Ali; Kim Young Hwa; ccamp@ops.ietf.org > > > > > Subject: RE: Two Drafts for Resilience of Control Plane > > > > > > > > > > Hi Igor, > > > > > > > > > > Are you referring to controlling the LSP while one of the > > > > controllers is > > > > > still down? That would mean that no restart has yet taken > > > > > place. > > > > > The draft seems to be focused on providing standby control > > > > > channels, > > > > [JD] > > > > > > > > What is the utility of having standby control channels, as > > > > opposed > > > > to just having multiple *active* control channels? > > > > > > > > > > There is no advantage, but there are numerous disadvantages. > > > Having > > > multiple *active* control channels is what I was referring to as > > > let IP > > > layer provide the resilience for Control Plane. In fact there are > > > disadvantages of having active and standby control channel and > > > some > > > other entity have to manage them. Now you have to worry about > > > signaling > > > and control channels to be in-sync, fast switchover, etc. > > > > > > My motivation is to keep is simple, but yet superior. > > [JD] > > > > Years ago, when we first started on LMP, we had the notion of active > > and standby control channels and it was George Swallow that pointed > > out that this was a really *BadIdea*tm. > > > > Good news is that "we" are consistent :-) The bad news is > that LMP newly born RFC still have this notion [no one > listened to George :-( ]. RFC4204 does NOT include the notion of active/standby control channels. RFC4204 does explicitly support using multiple active control channels for an adjacency. > Here are some reasons why "we" > think this way: > > - Redundancy/ HA via IP Layer. > - Taken a CC OOS is simple as putting an IF to the control > network OOS, and other operational simplicities. > - OOS IF can be repair without impacting other links or LMP CC FSM. > - One LMP CC FSM per "N" Egress links to control network. > - LMP CC FSM is up as long as we have connectivity to the neighbor. > - No need to make special arrangements to make signaling and > control channel consistent. I.e., both LMP and RSVP Hellos > fail only when there is no IP connectivity to the neighbor. > - Etc. What you describe is certainly valid within a single control network. Best, Jonathan Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 02 Nov 2005 17:28:14 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Control plane resiliency Date: Wed, 2 Nov 2005 09:26:31 -0800 Message-ID: <626FC7C6A97381468FB872072AB5DDC836974A@XCH-SW-42.sw.nos.boeing.com> Thread-Topic: Control plane resiliency Thread-Index: AcXfxGjeDeYGWo+9QxmGumcYhgyqUgADf0nw From: "Drake, John E" To: "Igor Bryskin" , "Adrian Farrel" , "George Swallow" Cc: , Igor, Please, enough already. Thanks, John > -----Original Message----- > From: Igor Bryskin [mailto:ibryskin@movaz.com] > Sent: Wednesday, November 02, 2005 7:32 AM > To: Adrian Farrel; George Swallow > Cc: ccamp@ops.ietf.org; swallow@cisco.com > Subject: Re: Control plane resiliency >=20 > George, >=20 >=20 >=20 > Although I do agree that mechanisms to control IP and non-IP networks > should > not fundamentally deviate, we still need to bear in mind that there are > things that work well for IP networks and not so well or sufficiently well > for non-IP networks and visa versa. For example, the control and data > planes > are congruent in IP and, generally speaking, not-congruent in transport > networks, which brings additional challenges wrt resiliency/robustness of > the control plane that we have never met in the past. >=20 >=20 >=20 > I recommend to read the paper Diego mentioned in his email, where the > authors described quite accurately some of the problems that I have > referred > to in the thread. >=20 >=20 >=20 > Regards and see you on IETF64. >=20 > Igor >=20 >=20 >=20 > ----- Original Message ----- > From: "George Swallow" > To: "Adrian Farrel" > Cc: ; > Sent: Monday, October 31, 2005 6:42 PM > Subject: Re: Control plane resiliency >=20 >=20 > > Adrian - > > > > Excellent note. In reading through the thread I was beginning to fear > > that having chosen IP as a means of providing a resilient control plane, > > we might totally complicate things and fundamentally deviate from IP at > > this late date. > > > > I believe the exercise of working through requirements, showing how > > existing mechanism can and SHOULD be used to address these, and in the > > process point out any omissions would be a very useful piece of work. > > > > Thanks, > > ///George > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > George Swallow Cisco Systems (978) 936-1398 > > 1414 Massachusetts Avenue > > Boxborough, MA 01719 > > >=20 Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 02 Nov 2005 15:59:07 +0000 Message-ID: <08e901c5dfc5$5923ffd0$4e919ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Adding Control Plane Resiliency to the agenda for Vancouver Date: Wed, 2 Nov 2005 15:51:36 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi, Since it is clear that not everyone is happy about moving on from this discussion, I have jiggled the agenda for Vancouver to allow 10 minutes on this subject. Young will lead the discussions as follows: ================================================================== 16. Control Plane Resiliency Issues (Young Kim, 10) - what components of resiliency and robustness are involved? - for each of the components: - what problems are we trying to solve and in what timescale? - why can't we use existing tools for these problems? Background reading - draft-kim-ccamp-cpr-reqts-01.txt - draft-kim-ccamp-accp-protocol-00.txt ================================================================== Latest agenda available at http://www3.ietf.org/proceedings/05nov/agenda/ccamp.txt Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 02 Nov 2005 15:33:04 +0000 Message-ID: <009c01c5dfc2$9d6ef030$7a1810ac@movaz.com> From: "Igor Bryskin" To: "Adrian Farrel" , "George Swallow" Cc: , Subject: Re: Control plane resiliency Date: Wed, 2 Nov 2005 10:32:20 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit George, Although I do agree that mechanisms to control IP and non-IP networks should not fundamentally deviate, we still need to bear in mind that there are things that work well for IP networks and not so well or sufficiently well for non-IP networks and visa versa. For example, the control and data planes are congruent in IP and, generally speaking, not-congruent in transport networks, which brings additional challenges wrt resiliency/robustness of the control plane that we have never met in the past. I recommend to read the paper Diego mentioned in his email, where the authors described quite accurately some of the problems that I have referred to in the thread. Regards and see you on IETF64. Igor ----- Original Message ----- From: "George Swallow" To: "Adrian Farrel" Cc: ; Sent: Monday, October 31, 2005 6:42 PM Subject: Re: Control plane resiliency > Adrian - > > Excellent note. In reading through the thread I was beginning to fear > that having chosen IP as a means of providing a resilient control plane, > we might totally complicate things and fundamentally deviate from IP at > this late date. > > I believe the exercise of working through requirements, showing how > existing mechanism can and SHOULD be used to address these, and in the > process point out any omissions would be a very useful piece of work. > > Thanks, > ///George > > ======================================================================== > George Swallow Cisco Systems (978) 936-1398 > 1414 Massachusetts Avenue > Boxborough, MA 01719 > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 02 Nov 2005 14:44:39 +0000 Message-ID: <005a01c5dfbb$cea1dd40$7a1810ac@movaz.com> From: "Igor Bryskin" To: "Adrian Farrel" , "Diego Caviglia" Cc: " Subject: Re: Control plane resiliency Date: Wed, 2 Nov 2005 09:43:36 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Diego, I would like to read the paper you mentioned. Igor ----- Original Message ----- From: "Diego Caviglia" To: "Adrian Farrel" Cc: " Sent: Wednesday, November 02, 2005 8:27 AM Subject: Re: Control plane resiliency > > Hi all, > a quick comment in line. > > Regards > > Diego > > > > "Adrian Farrel" @ops.ietf.org on 31/10/2005 23.37.34 > > Please respond to "Adrian Farrel" > > Sent by: owner-ccamp@ops.ietf.org > > > To: > cc: > > Subject: Control plane resiliency > > [CUT] > > 4. *The* controller resiliency issue appears to be: How to manage and > teardown an LSP downstream of a broken controller. I do not understand why > the answer is not one of: > a. Wait for the controller to be repaired > b. Use the management plane > It seems that in-place modification of GMPLS LSPs is not a common > operational feature for an active LSP. This leaves us with teardown. For > teardown, option a does not seem to be very painful, but if it does cause > problems (and alarms *will* be raised) option b is available. > [dc] In last DRCN (http://drcn2005.telecomitalialab.com/) ww presented a > paper that illustrates a possible solution of this issues. > It works using signalling messages. > If someone is interesed in reading the paper please write me and I'll send > the paper. > > > [CUT] > > 8. In a transport network, we must accept an operator's right to entirely > eliminate soft state timeouts. That is, the failure of the control plane > for any length of time, must not impact the traffic (note that even though > RSVP is a soft state protocol, the refresh period may be set so high (32 > bitsworth of milliseconds) as to be practically infinite. Note > specifically that the failure of Hellos is used in RFC3473 to temporarily > "turn off" the soft state nature of RSVP-TE. > [dc] I strongly agree with this. > > [CUT] > > Thanks, > Adrian > > > > > > > > > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 02 Nov 2005 13:29:19 +0000 Sensitivity: Subject: Re: Control plane resiliency To: "Adrian Farrel" Cc: " Message-ID: From: "Diego Caviglia" Date: Wed, 2 Nov 2005 14:27:24 +0100 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Hi all, a quick comment in line. Regards Diego "Adrian Farrel" @ops.ietf.org on 31/10/2005 23.37.34 Please respond to "Adrian Farrel" Sent by: owner-ccamp@ops.ietf.org To: cc: Subject: Control plane resiliency [CUT] 4. *The* controller resiliency issue appears to be: How to manage and teardown an LSP downstream of a broken controller. I do not understand why the answer is not one of: a. Wait for the controller to be repaired b. Use the management plane It seems that in-place modification of GMPLS LSPs is not a common operational feature for an active LSP. This leaves us with teardown. For teardown, option a does not seem to be very painful, but if it does cause problems (and alarms *will* be raised) option b is available. [dc] In last DRCN (http://drcn2005.telecomitalialab.com/) ww presented a paper that illustrates a possible solution of this issues. It works using signalling messages. If someone is interesed in reading the paper please write me and I'll send the paper. [CUT] 8. In a transport network, we must accept an operator's right to entirely eliminate soft state timeouts. That is, the failure of the control plane for any length of time, must not impact the traffic (note that even though RSVP is a soft state protocol, the refresh period may be set so high (32 bitsworth of milliseconds) as to be practically infinite. Note specifically that the failure of Hellos is used in RFC3473 to temporarily "turn off" the soft state nature of RSVP-TE. [dc] I strongly agree with this. [CUT] Thanks, Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 02 Nov 2005 04:05:29 +0000 To: "Adrian Farrel" Cc: ccamp@ops.ietf.org Cc: swallow@cisco.com Subject: Re: Control plane resiliency From: George Swallow Date: Mon, 31 Oct 2005 18:42:48 -0500 Message-Id: <20051031234248.E3F8615F62D@swallow-mini-mac.local> Adrian - Excellent note. In reading through the thread I was beginning to fear that having chosen IP as a means of providing a resilient control plane, we might totally complicate things and fundamentally deviate from IP at this late date. I believe the exercise of working through requirements, showing how existing mechanism can and SHOULD be used to address these, and in the process point out any omissions would be a very useful piece of work. Thanks, ///George ======================================================================== George Swallow Cisco Systems (978) 936-1398 1414 Massachusetts Avenue Boxborough, MA 01719 Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 01 Nov 2005 16:09:17 +0000 Message-ID: <009101c5defe$76018e00$7a1810ac@movaz.com> From: "Igor Bryskin" To: "Adrian Farrel" , Subject: Re: Control plane resiliency Date: Tue, 1 Nov 2005 11:08:12 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Wow, Adrian, do you believe you were sufficiently rude to protect against any future DOS attacks on the IETF process? I guess this is your idea of firewall. See in-line. Igor ----- Original Message ----- From: "Adrian Farrel" To: Sent: Monday, October 31, 2005 5:37 PM Subject: Control plane resiliency > > Hi, > > It is nice to see some traffic on the CCAMP list. > > Some observations based on your discussions (in no particular order). > > 1. There is a distinction to be made between control channel resiliency > and controller resiliency. > > Since the control channel uses IP, it will heal so long as there is IP > connectivity (failing that you're dead anyway); the issue is the speed of > convergence. Other solutions exist to provide control channel redundancy, > but I believe that these are either implementation specific or are > hardware specific. In either case, they are out of scope and (as Zafar > says) the IP connectivity would remain. IB>> Agree > > Controller resiliency is actually a debate about how to manage the data > plane in the absence of a controller. Note that it is perfectly possible > to lose your signaling controller without losing your routing controller, > etc. IB>> Here I'd like to summarize what we cannot do if one, say, LSP transit controller goes out of service while the LSP data plane preserved intact - a very possible situation in GMPLS CP controlled transport network: 1.. tear LSP in upstream or downstream direction 2.. use PathErr notifications 3.. modify any LSP attribute (some of these modifications could be useful even in this case): a) Admin status (e.g. enable/disable data plane alarms); b) ASSOCIATION object ( e.g. moveVCAT group constituents from one group to another) c) SESSION_ATTRIBUTES (e.g. setup/holding priorities); d) POLICY_DATA object (e.g. signal policy change) e) NOTIFY_REQUEST object (e.g. change Notify targets) f) Etc. 4.. gather alarm information; 5.. use restoration schemes that depends on hop-by-hop notification/switchover signaling 6.. In case of P2MP LSP a failure of a controller located close to the root prevents grafting/pruning operations; 7.. In case of P2P or P2MP segment protected LSP a failure of controller prevents adding/removing local protection In summary - pretty much anything. One solution is mb4b rerouting. However, it may not be feasible. Think of a ring topology: there could simply be no resources in the opposite direction of the ring. Hence our choices are: 1) To say we cannot do anything because GMPLS control plane emerged from MPLS where this problem does not exist - just wait for controller to repair and in the mean time manage the LSP via management plane 2) To do something about this: there might be solutions that relatively easy address this problem. (I have at least two of them) > > 2. There is no need to make a distinction between data plane technologies. > That is, for GMPLS this applies equally to PSC and non-PSC. IB>> Well in IP where the control plane is congruent with the data plane the situation I described does not exist, so I disagree > > 3. Dimitri's observation that it may be worthwhile documenting the > concerns and explaining why they are not issues (i.e. how they solve > themselves) may be very valuable. It should suit all people because if the > concerns are real then the attempt at documentation will expose them, > while if the concerns are not real we will have an advisory document for > all time. IB>> Good advise > > 4. *The* controller resiliency issue appears to be: How to manage and > teardown an LSP downstream of a broken controller. I do not understand why > the answer is not one of: > a. Wait for the controller to be repaired > b. Use the management plane > It seems that in-place modification of GMPLS LSPs is not a common > operational feature for an active LSP. This leaves us with teardown. For > teardown, option a does not seem to be very painful, but if it does cause > problems (and alarms *will* be raised) option b is available. IB>> Not just that, see my comment above > > 5. The ability to manage the data plane resources at the node where the > control plane has failed, may still exist in the management plane (in > which case use it!) or may also be gone (in which case, who cares that you > can't free up the resources for another user since another user cannot > make use of the resources). You *might* manage to claim that there is a > safety issue here - anyone know what OSMINE says about loss of management > plane connectivity to a device with lasers? > > 6. There may be a *separate* issue (as raised by Tom) about how to synch > the control plane with the data plane. This might be particularly > important after controller recovery. Such OAM features should be part of a > separate effort (such as a GMPLS OAM requirements draft). > > 7. Lyndon points out that there is scope for a "standby signaling > controller". This could mean two things. > a. An implementation option (as John points out) including, but not > limited to: > i. multiple instances of the software component > ii. multiple instances of a controller CPU > iii. control-plane message replication to distinct devices > b. A protocol option where two entirely different "routers" manage the > same data plane switch. This is pretty much outside our architecture > (although we could handle a "replacement signaling controller" if it > turned up with the same addresses). *If* someone wants to work on this > idea, I suggest they need to develop the requirements and convince the > community that what we have already doesn't provide everything we need > anyway. (Not saying that the standby model is wrong, but am suggesting > that we might not have a need for it at the moment.) > > 8. In a transport network, we must accept an operator's right to entirely > eliminate soft state timeouts. That is, the failure of the control plane > for any length of time, must not impact the traffic (note that even though > RSVP is a soft state protocol, the refresh period may be set so high (32 > bitsworth of milliseconds) as to be practically infinite. Note > specifically that the failure of Hellos is used in RFC3473 to temporarily > "turn off" the soft state nature of RSVP-TE. > > > In summary: > > A. We have decided that observation 3 might be useful. Is anyone planning > to work on this? > B. We have not heard from Young since the start of this debate. I hope the > hot words have not driven him away. > C. Igor appears to be out on a limb here. While I appreciate him pushing a > point that he believes in strongly, such determination in the face of WG > consensus approaches a DOS attack (unintentional, I'm sure) on the IETF > process. Please be careful. IB>> Thanks for the advice, but to be careful is not in my nature. 1.. About the DOS attack: there was the discussion about control plane resiliency (which I didn't initiate), I mentioned that IMO the issue is important and when I was asked to give a specific example, I brought up the problem of control plane partitioned LSPs. Since then I sent only responses to the questions, some of them unrelated like for example " Can you really keep states in the absence of refreshes" and "Why is your problem cannot be resolved via RSVP graceful restart". Isn't this is CCAMP mailing list for? Where do you see the DOS attack? 2.. About consensus. I was in constant discussions with 3 people: John, Dimitri and Zafar. I definitely could not convince John; Dimitri said at the end: "Ok, it is time to write a draft, and we shall see"; and I seem to give all answers to Zafar, but am not sure if succeeded to convince him or not. Suppose none of them bought in, then, including you, Adrian, there are 4 people who did not recognize the problem sufficient enough to work on a standardized solution. On the other hand one person - Neil - openly supported the work, which with me makes us two, plus, I got some supporting private emails (including an invitation to submit a contribution to Q14/15). So, Adrian, please define what you mean by consensus. Maybe we should vote? I am pretty sure you will get the votes, however, I don't think that as of yesterday one could call the situation as a consensus. Igor > > Thanks, > Adrian > > > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 01 Nov 2005 13:36:45 +0000 Message-ID: <00ec01c5dee8$5c8e3650$4e919ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Lambda labels - next steps Date: Tue, 1 Nov 2005 12:11:43 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi, I think some progress got made. There seems to be some agreement that there may be a need to advertise lambda availability, use lambda availability in path computation, and apply explicit label control through the network. These requirements still need to be firmed up a bit (for example, are we aiming for interworking between vendors?). Some say that such requirements imply a global semantic for the lambda label. Others say that it is sufficient to use local semantics applying "translation" at each hop. This item needs debate and resolution since it amounts to "are current protocol elements sufficient *and* optimal for meeting the requirements?" Issues of bundling need to be documented, but don't currently appear to create requirements for new protocol extensions. John and Payam point out that the wavelength on its own may not be enough to guarantee end-to-end interworking in optical systems. Since this interworking is precisely the requirement, we need to set out what information is actually required. As Sidney has said, the actual solution comes later (although, since we are engineers, who can be surprised that we are trying out ideas as we go along). My guess, FWIW, is that if you know the ITU grid identifier and the entry in the grid to which the lambda corresponds then you know everything that you need to know. We have an agenda slot for this work in Vancouver. It would be helpful if the main objective could be to establish consensus on exactly what the requirements are, and that we cannot solve them using existing protocol elements. If we get that far, the rest is easy. Thanks, Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 01 Nov 2005 13:36:37 +0000 Message-ID: <00ea01c5dee8$5c0dbbb0$4e919ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Slides for Vancouver Date: Tue, 1 Nov 2005 11:50:13 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi, We have the Monday morning slot. That means that you can't sit at the back of some other WG meeting and prepare your slides :-( I would like to have all the slides up on the Web in advance so that people can follow them at their own speed. Please send them to me by the end of Saturday. Please look at the agenda to check that you are covering the questions that are listed, and please remember that you are not there to present your I-D! You should be raising questions and encouraging debate/input from the meeting. Thanks, Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 01 Nov 2005 11:41:54 +0000 Message-ID: <004601c5ded8$bdddd060$4e919ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Cc: Subject: Re: Two Drafts for Resilience of Control Plane Date: Tue, 1 Nov 2005 11:38:00 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi Young, Thanks for your thoughtful mail. In focussing on control channel resilience you must answer why it is you are not satisfied with the resilience provided by normal IP mechanisms. For example, in your figure... > ~~~~~~~~~~~~~~~~~~~ > | | > | Intra/extra | >|-----------| network for | >| | control plane | >| | | >| 5 ~~~~~~~~~~~~~~~~~~~ >| | >| | 6 >| 1 | 4 >A-------------------B------------------C >| | | >| 2 | | >|-------------------- | >| | >| 3 | >|--------------------------------------| You correctly identify that there are several control plane routes from A to B > Route-1 : 1 > Route-2 : 2 > Route-3 : 3-4 > Route-4 : 5-6 The option that most people currently consider is that they run an IGP in the control plane. This would mean that a control plane signaling message from the signaling controller at A to the signaling controller at B would be placed in an IP datagram addressed to the control plane address of B. It would be sent along the shortest open path from A to B (route 1). In the event of a failure of link 1, the IGP would converge and the signaling messages would be sent along the next shortest path (route 2). And so on. This mechanism is not sensitive to whether multiple control channels use the same duct or not since the IGP will converge just as well if multiple control channels fail at once. Note that load sharing between control channels is not recommended because it will result in out of order delivery of control messages. Have a look at all of the health warnings about the use of ECMP. So I assume that one of three issues is worrying you. 1. You do not want to implement an IGP in your control plane 2. You do not want to handle IP forwarding in your control plane 3. The speed of convergence of the IGP is not good enough for the use you wish to make of your control plane. Item 1. is an issue of complexity. I can see that it would reduce the complexity of a network device and the control plane if you do not have an IGP. But since you must run the IGP to exchange TE information, it is no additional cost to use it to exchange control plane information. And, to the contrary, by using the IGP you do not need any other mechanisms for control plane resiliency. Item 2. is an implementation issue. The forwarding does not have to be at line speed. In general, software forwarding of control plane packets might be considered adequate. Item 3. would be interesting to hear about. Note that for most cases (such as the switch from route 1 to route 2 in your example) there is no need to wait for IGP convergence since it is the sending node (A) that notices the failed link and can immediately update its routing table. Thus convergence time is only an issue for less direct routes. So I'd like to understand a little more what is motivating your work, and why you think existing techniques are not sufficient. > The other draft that I proposed is a requirement document for > the resilience of control plane, not the one of control channels. > In the requirement document, as a initial comment from Dimitri, > I think that the draft should cover protocol-neutral approaches, > not protocol specific ones. For examples, the various resilience > aspects of control nodes, control entities, control channels, and > etc should be covered. > However, the current draft does not sufficiently cover the > general aspect for the resilience of control plane. > I think that these parts in the requirement document could be > handled in further version with help of ccampers who are > interested in the resilience of control plane. OK. That sounds worth further investigation. Thanks, Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 01 Nov 2005 10:12:24 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5DECC.859AE898" Subject: RE: Two Drafts for Resilience of Control Plane Date: Tue, 1 Nov 2005 10:10:44 -0000 Message-ID: <0536FC9B908BEC4597EE721BE6A3538912275CEC@i2km07-ukbr.domain1.systemhost.net> Thread-Topic: Two Drafts for Resilience of Control Plane Thread-Index: AcXemUHhH9P6Cx1AT1qsB+vhGsbi8gAMjUtw From: To: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C5DECC.859AE898 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Young, please see below.... -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Kim Young Hwa Sent: 01 November 2005 04:04 To: ccamp@ops.ietf.org Subject: RE: Two Drafts for Resilience of Control Plane Hi, =20 First of all, I'd like to appreciate your sending and receiving communication broadly as an initiator of this issue. =20 As most of people know about control plane, it consists of control nodes, control entities, and control channels.=20 Here, the resilience aspect of control nodes could be addressed in the Igor's example=20 or in the duplication of processor cards within a commercial product.=20 The resilience aspect of control entities could be addressed in a protocol itself with GR (graceful restart) capability.=20 And, the resilience aspect of control channels could be identified a link or concatenation of links carrying control packets. =20 Here, I believe that the resilience of control nodes, called controller resiliency,=20 belong to implementation issue (or H/W specific issue), not protocol issue.=20 And, the resilience of control entities belong to protocol issue.=20 However, the scope of resilience in control entities exists between peer control entities, not between physically adjacent nodes.=20 Note that the resilience of control entities belong to only the protocol because a control entity means a protocol that runs a specific function. Some protocols could be run with soft-state nature, others could be run with hard-state nature. The decision on soft-state and hard-state is different from every protocol to be applied. =20 Next is the resilience of control channels.=20 It seems that this could belong to implementation issue as addressed by Adrian. However, if you see the resilience of control channels as implementation issue, I think that we don't need to consider more the resilience of control channels in a protocol approach. But, differently from data plane, control plane has various protocols to keep their control relation. Control channels addressed here are concerned with physically adjacent nodes via direct and indirect connections. And, there could be one or more alternative routes to transfer control packets between physically adjacent nodes. Let's look at an example network. =20 =20 ~~~~~~~~~~~~~~~~~~~ | | | Intra/extra | |-----------| network for | | | control plane | | | | | 5 ~~~~~~~~~~~~~~~~~~~ | | | | 6 | 1 | 4 A-------------------B------------------C | | | | 2 | | |-------------------- | | | | 3 | |--------------------------------------| =20 =20 Above the example, we assume that 1, 2, 3, and 4 control channels share the fate with data channels, and 5 and 6 control channels are used to transfer only control packets. And, the network for control plane could have different capacity in real implementations. Here, we can see several alternatives routes in conveying control packets between physically adjacent nodes. Between A and B nodes have the following routes. =20 Route-1 : 1 Route-2 : 2 Route-3 : 3-4 Route-4 : 5-6 =20 I think that the resilience aspect of control channel should handle reliable (and fast) transfer of control packets between specific nodes. In the example between A and B nodes, these nodes should negotiate active and standby control channels, protocols to be carried on a control channel, and etc. In this sense, I believe that the resilience of control channel could belong to protocol issue. =20 One of two draft that I proposed is a solution for the resilience of control channel, which is based on a concept of the control network, called common channel signaling system used in the traditional PSTN and ISDN.=20 =20 NH=3D> Exactly so. THE major thing you have to be sure of before you = can even start to consider this is the duct graph. If you cannot get physical disjointedness here then you can't even progress. The link-connections of the control/management plane network will, like any other data-plane network, be carried on trails in a lower layer network. You can use an IGP above this to attempt to provide some form of resiliency or you could do what they did in C7 (which is also a pkt-based network BTW) and have a simple load sharing algorithm across a multiple parallel link-set....so if 1 link fails the rest just carry on. Fast, simple, elegant and focussed at the right/relevant problem. So why not use this approach....as noted you have to start with having to ensure the equivalent of disjoint link-set anyway, so use it directly. Note also that 'adding' stuff generally reduces reliability....keep things simple. =20 =20 regards, Neil =20 Of course, there could be other solutions to solve the resilience of control channel. I don't think that the IP connectivity provides a means to be capable of using these various routes. For the resilience of control plane, the IP connectivity is a basic, and additional works should be considered. =20 The other draft that I proposed is a requirement document for the resilience of control plane, not the one of control channels. In the requirement document, as a initial comment from Dimitri, I think that the draft should cover protocol-neutral approaches, not protocol specific ones. For examples, the various resilience aspects of control nodes, control entities, control channels, and etc should be covered. However, the current draft does not sufficiently cover the general aspect for the resilience of control plane. I think that these parts in the requirement document could be handled in further version with help of ccampers who are interested in the resilience of control plane. =20 =20 Regards =20 Young. =20 =20 =20 ------_=_NextPart_001_01C5DECC.859AE898 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Young, please see below....
-----Original Message-----
From:=20 owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On = Behalf Of=20 Kim Young Hwa
Sent: 01 November 2005 04:04
To: = ccamp@ops.ietf.org
Subject: RE: Two Drafts for Resilience of = Control=20 Plane

Hi,
 
First of all, I'd like to appreciate your = sending and=20 receiving communication broadly as an initiator of this = issue.
 
As most of people know about control = plane,
it consists of control nodes, control = entities, and=20 control channels.
Here, the resilience aspect of control = nodes could=20 be addressed in the Igor's example
or in the duplication of processor cards = within a=20 commercial product.
The resilience aspect of control entities = could be=20 addressed in a protocol itself with GR (graceful restart) capability.=20
And, the resilience aspect of control channels = could be=20 identified a link or concatenation of links carrying control=20 packets.
 
Here, I believe that the resilience of control = nodes,=20 called controller resiliency,
belong to implementation issue (or H/W = specific issue),=20 not protocol issue.
And, the resilience of control entities belong = to=20 protocol issue.
However, the scope of resilience in control = entities=20 exists between peer control entities, not between physically adjacent = nodes.=20
Note that the resilience of control entities = belong to=20 only the protocol because a control entity means a protocol that = runs a=20 specific function.
Some protocols could be run with soft-state = nature,=20 others could be run with hard-state nature.
The decision on soft-state and hard-state is = different=20 from every protocol to be applied.
 
Next is the resilience of control channels.=20
It seems that this could belong to = implementation issue=20 as addressed by Adrian.
However, if you see the resilience of control = channels=20 as implementation issue,
I think that we don't need to consider more = the=20 resilience of control channels in a protocol approach. = But,
differently from data plane, control plane has = various=20 protocols to keep their control relation.
Control channels addressed here are concerned = with=20 physically adjacent nodes via direct and indirect = connections.
And, there could be one or more = alternative=20 routes to transfer control packets between physically adjacent=20 nodes.
Let's look at an example network.
 
 
           &n= bsp;~~~~~~~~~~~~~~~~~~~
           =20 = |            =     =20 |
           &n= bsp;|  Intra/extra   =20 |
|-----------|  network=20 for    |
|           |=  control=20 plane   |
|          =20 = |            =     =20 |
| 5         ~~~~~~= ~~~~~~~~~~~~~
|           &= nbsp;      =20 |
|           &= nbsp;      =20 | 6
|        1   =       =20 |         4
A-------------------B------------------C
|           &= nbsp;       |    &= nbsp;           &n= bsp;=20 |
|        2   =       =20 = |            =      =20 |
|--------------------        = ;         =20 |
|           &= nbsp;           &n= bsp;           &nb= sp; =20 |
|           &= nbsp;       3    &= nbsp;           &n= bsp;=20 |
|--------------------------------------|
 
 
Above the example, we assume that 1, 2, 3, = and 4=20 control channels share the fate with data channels, and 5 = and 6=20 control channels are used to transfer only control packets. And, the = network=20 for control plane could have different capacity in real=20 implementations.
Here, we can see several alternatives routes = in=20 conveying control packets between physically adjacent = nodes.
Between A and B nodes have the following=20 routes.
 
     Route-1 : = 1
     Route-2 : = 2
     Route-3 : = 3-4
     Route-4 : = 5-6
 
I think that the resilience aspect of control = channel=20 should handle reliable (and fast) transfer of control packets between = specific=20 nodes.
In the example between A and B nodes, these = nodes should=20 negotiate active and standby control channels, protocols to be carried = on a control channel, and etc. In this sense, I believe that = the=20 resilience of control channel could belong to protocol = issue.
 
One of two draft that I proposed is a solution = for the=20 resilience of control channel, which is based on a concept of the = control=20 network, called common channel signaling system used in the = traditional PSTN=20 and ISDN. 
 
NH=3D> Exactly so.  THE major = thing you have to=20 be sure of before you can even start to consider this is the duct = graph. =20 If you cannot get physical disjointedness here then you can't = even=20 progress.  The link-connections of the control/management plane = network=20 will, like any other data-plane network, be carried on trails in a = lower layer=20 network.  You can use an IGP above this to attempt to provide = some form=20 of resiliency or you could do what they did in C7 (which is also a = pkt-based=20 network BTW) and have a simple load sharing algorithm across a = multiple=20 parallel link-set....so if 1 link fails the rest just carry on.  = Fast,=20 simple, elegant and focussed at the right/relevant problem.  So = why not=20 use this approach....as noted you have to start with having to ensure = the=20 equivalent of disjoint link-set anyway, so use it directly.  Note = also=20 that 'adding' stuff generally reduces reliability....keep things = simple. =20
 
regards,=20 Neil
 
 Of course,=20 there could be other solutions to solve the resilience of control=20 channel.
I don't think that the IP connectivity = provides a means=20 to be capable of using these various routes.
For the resilience of control plane, the IP = connectivity=20 is a basic, and additional works should be = considered.
 
The other draft that I proposed is a = requirement=20 document for the resilience of control plane, not the one of control=20 channels.
In the requirement document, as a initial = comment from=20 Dimitri, I think that the draft should cover protocol-neutral = approaches, not=20 protocol specific ones. For examples, the various resilience aspects = of=20 control nodes, control entities, control channels, and etc should be=20 covered.
However, the current draft does not = sufficiently cover=20 the general aspect for the resilience of control plane.
I think that these parts in the requirement = document=20 could be handled in further version with help of ccampers who are = interested=20 in the resilience of control plane.
 
 
Regards
 
Young.
 
------_=_NextPart_001_01C5DECC.859AE898-- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 01 Nov 2005 04:03:09 +0000 Thread-Topic: Two Drafts for Resilience of Control Plane thread-index: AcXemUHhH9P6Cx1AT1qsB+vhGsbi8g== Content-Transfer-Encoding: 7bit Reply-To: "Kim Young Hwa" From: "Kim Young Hwa" To: Cc: Subject: RE: Two Drafts for Resilience of Control Plane Date: Tue, 1 Nov 2005 13:03:46 +0900 Comment: GQ19@|@ZEk=E?,18?x, OAM1b MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_5274_01C5DEE4.B1CB07F0" Content-Class: urn:content-classes:message This is a multi-part message in MIME format. ------=_NextPart_000_5274_01C5DEE4.B1CB07F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: base64 ------=_NextPart_000_5274_01C5DEE4.B1CB07F0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: base64 PERJViBpZD1tc2dib2R5IHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBTeXN0 ZW0iPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsPkhpLDwvRk9OVD48L0RJVj4NCjxESVY+Jm5ic3A7 PC9ESVY+DQo8RElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsPkZpcnN0IG9mIGFsbCwgSSdkIGxp a2UgdG8gYXBwcmVjaWF0ZSB5b3VyIHNlbmRpbmcgYW5kIHJlY2VpdmluZyBjb21tdW5pY2F0aW9u IGJyb2FkbHkgYXMgYW4gaW5pdGlhdG9yIG9mIHRoaXMgaXNzdWUuPC9GT05UPjwvRElWPg0KPERJ Vj48Rk9OVCBmYWNlPUFyaWFsPjwvRk9OVD4mbmJzcDs8L0RJVj48L0RJVj4NCjxESVY+PEZPTlQg ZmFjZT1BcmlhbD5BcyBtb3N0IG9mIHBlb3BsZSBrbm93IGFib3V0IGNvbnRyb2wgcGxhbmUsPC9G T05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsPml0IGNvbnNpc3RzIG9mIGNvbnRyb2wg bm9kZXMsIGNvbnRyb2wgZW50aXRpZXMsIGFuZCBjb250cm9sIGNoYW5uZWxzLiA8L0ZPTlQ+PC9E SVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWw+SGVyZSwgdGhlIHJlc2lsaWVuY2UgYXNwZWN0IG9m IGNvbnRyb2wgbm9kZXMmbmJzcDtjb3VsZCBiZSZuYnNwO2FkZHJlc3NlZCZuYnNwO2luIHRoZSBJ Z29yJ3MgZXhhbXBsZSA8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWw+b3IgaW4g dGhlIGR1cGxpY2F0aW9uIG9mIHByb2Nlc3NvciBjYXJkcyB3aXRoaW4gYSBjb21tZXJjaWFsIHBy b2R1Y3QuIDwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbD5UaGUgcmVzaWxpZW5j ZSBhc3BlY3Qgb2YgY29udHJvbCBlbnRpdGllcyBjb3VsZCBiZSBhZGRyZXNzZWQgaW4gYSBwcm90 b2NvbCBpdHNlbGYgd2l0aCBHUiAoZ3JhY2VmdWwgcmVzdGFydCkgY2FwYWJpbGl0eS4gPC9GT05U PjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsPkFuZCwgdGhlIHJlc2lsaWVuY2UgYXNwZWN0 IG9mIGNvbnRyb2wgY2hhbm5lbHMgY291bGQgYmUgaWRlbnRpZmllZCBhIGxpbmsgb3IgY29uY2F0 ZW5hdGlvbiBvZiBsaW5rcyBjYXJyeWluZyBjb250cm9sIHBhY2tldHMuPC9GT05UPjwvRElWPg0K PERJVj48Rk9OVCBmYWNlPUFyaWFsPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFj ZT1BcmlhbD5IZXJlLCBJIGJlbGlldmUgdGhhdCB0aGUgcmVzaWxpZW5jZSBvZiBjb250cm9sIG5v ZGVzLCBjYWxsZWQgY29udHJvbGxlciByZXNpbGllbmN5LCA8L0ZPTlQ+PC9ESVY+DQo8RElWPjxG T05UIGZhY2U9QXJpYWw+YmVsb25nIHRvIGltcGxlbWVudGF0aW9uIGlzc3VlIChvciBIL1cgc3Bl Y2lmaWMgaXNzdWUpLCBub3QgcHJvdG9jb2wgaXNzdWUuIDwvRk9OVD48L0RJVj4NCjxESVY+PEZP TlQgZmFjZT1BcmlhbD5BbmQsIHRoZSByZXNpbGllbmNlIG9mIGNvbnRyb2wgZW50aXRpZXMgYmVs b25nIHRvIHByb3RvY29sIGlzc3VlLiA8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJp YWw+SG93ZXZlciwgdGhlIHNjb3BlIG9mIHJlc2lsaWVuY2UgaW4gY29udHJvbCBlbnRpdGllcyBl eGlzdHMgYmV0d2VlbiBwZWVyIGNvbnRyb2wgZW50aXRpZXMsIG5vdCBiZXR3ZWVuIHBoeXNpY2Fs bHkgYWRqYWNlbnQgbm9kZXMuIDwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbD5O b3RlIHRoYXQgdGhlIHJlc2lsaWVuY2Ugb2YgY29udHJvbCBlbnRpdGllcyBiZWxvbmcgdG8gb25s eSB0aGUgcHJvdG9jb2wgYmVjYXVzZSBhIGNvbnRyb2wgZW50aXR5Jm5ic3A7bWVhbnMgYSBwcm90 b2NvbCB0aGF0IHJ1bnMgYSBzcGVjaWZpYyBmdW5jdGlvbi4gPC9GT05UPjwvRElWPg0KPERJVj48 Rk9OVCBmYWNlPUFyaWFsPlNvbWUgcHJvdG9jb2xzIGNvdWxkIGJlIHJ1biB3aXRoIHNvZnQtc3Rh dGUgbmF0dXJlLCBvdGhlcnMgY291bGQgYmUgcnVuIHdpdGggaGFyZC1zdGF0ZSBuYXR1cmUuPC9G T05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsPlRoZSBkZWNpc2lvbiBvbiBzb2Z0LXN0 YXRlIGFuZCBoYXJkLXN0YXRlIGlzIGRpZmZlcmVudCBmcm9tIGV2ZXJ5IHByb3RvY29sIHRvIGJl IGFwcGxpZWQuPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsPjwvRk9OVD4mbmJz cDs8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbD5OZXh0IGlzIHRoZSByZXNpbGllbmNlIG9m IGNvbnRyb2wgY2hhbm5lbHMuIDwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbD5J dCBzZWVtcyB0aGF0IHRoaXMgY291bGQgYmVsb25nIHRvIGltcGxlbWVudGF0aW9uIGlzc3VlIGFz IGFkZHJlc3NlZCBieSBBZHJpYW4uPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFs Pkhvd2V2ZXIsIGlmIHlvdSBzZWUgdGhlIHJlc2lsaWVuY2Ugb2YgY29udHJvbCBjaGFubmVscyBh cyBpbXBsZW1lbnRhdGlvbiBpc3N1ZSw8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJp YWw+SSB0aGluayB0aGF0IHdlIGRvbid0IG5lZWQgdG8gY29uc2lkZXIgbW9yZSB0aGUgcmVzaWxp ZW5jZSBvZiBjb250cm9sIGNoYW5uZWxzIGluIGEgcHJvdG9jb2wgYXBwcm9hY2guIEJ1dCw8L0ZP TlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWw+ZGlmZmVyZW50bHkgZnJvbSBkYXRhIHBs YW5lLCBjb250cm9sIHBsYW5lIGhhcyB2YXJpb3VzIHByb3RvY29scyB0byBrZWVwIHRoZWlyIGNv bnRyb2wgcmVsYXRpb24uPC9GT05UPjwvRElWPg0KPERJVj4NCjxESVY+PEZPTlQgZmFjZT1Bcmlh bD5Db250cm9sIGNoYW5uZWxzIGFkZHJlc3NlZCBoZXJlIGFyZSBjb25jZXJuZWQgd2l0aCBwaHlz aWNhbGx5IGFkamFjZW50IG5vZGVzIHZpYSBkaXJlY3QgYW5kIGluZGlyZWN0IGNvbm5lY3Rpb25z PC9GT05UPjxGT05UIGZhY2U9QXJpYWw+LjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1B cmlhbD5BbmQsIHRoZXJlJm5ic3A7Y291bGQgYmUmbmJzcDtvbmUgb3IgbW9yZSBhbHRlcm5hdGl2 ZSByb3V0ZXMgdG8gdHJhbnNmZXIgY29udHJvbCBwYWNrZXRzIGJldHdlZW4gcGh5c2ljYWxseSBh ZGphY2VudCBub2Rlcy48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWw+TGV0J3Mg bG9vayBhdCBhbiBleGFtcGxlIG5ldHdvcmsuPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNl PSJDb3VyaWVyIE5ldyI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPSJDb3Vy aWVyIE5ldyI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPSJDb3VyaWVyIE5l dyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7fn5+fn5+fn5+fn5+fn5+fn5+fjwvRk9OVD48L0RJVj4NCjxESVY+ PEZPTlQgZmFjZT0iQ291cmllciBOZXciPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IHw8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9IkNvdXJp ZXIgTmV3Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDt8Jm5ic3A7Jm5ic3A7SW50cmEvZXh0cmEmbmJzcDsmbmJz cDsmbmJzcDsgfDwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0iQ291cmllciBOZXciPnwt LS0tLS0tLS0tLXwmbmJzcDsmbmJzcDtuZXR3b3JrIGZvciZuYnNwOyZuYnNwOyZuYnNwOyB8PC9G T05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyI+fCZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3wmbmJz cDtjb250cm9sIHBsYW5lJm5ic3A7Jm5ic3A7IHw8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZh Y2U9IkNvdXJpZXIgTmV3Ij58Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgfDwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0iQ291cmllciBOZXciPnwmbmJz cDs1Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 fn5+fn5+fn5+fn5+fn5+fn5+fjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0iQ291cmll ciBOZXciPnwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgfDwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0iQ291cmllciBOZXciPnwmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCA2PC9GT05UPjwv RElWPg0KPERJVj48Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyI+fCZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzEmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyA0PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPSJDb3Vy aWVyIE5ldyI+QS0tLS0tLS0tLS0tLS0tLS0tLS1CLS0tLS0tLS0tLS0tLS0tLS0tQzwvRk9OVD48 L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0iQ291cmllciBOZXciPnwmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDt8Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHw8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZh Y2U9IkNvdXJpZXIgTmV3Ij58Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7MiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHw8 L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3Ij58LS0tLS0tLS0tLS0t LS0tLS0tLS0mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfDwv Rk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0iQ291cmllciBOZXciPnwmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfDwvRk9OVD48L0RJVj4NCjxE SVY+PEZPTlQgZmFjZT0iQ291cmllciBOZXciPnwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDszJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IHw8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9IkNvdXJp ZXIgTmV3Ij58LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS18PC9GT05UPjwv RElWPjwvRElWPg0KPERJVj4NCjxESVY+PEZPTlQgZmFjZT0iQ291cmllciBOZXciPjwvRk9OVD4m bmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0iQ291cmllciBOZXciPjwvRk9OVD4mbmJzcDs8 L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbD5BYm92ZSB0aGUgZXhhbXBsZSwgd2UgYXNzdW1l IHRoYXQgMSwgMiwgMywgYW5kJm5ic3A7NCBjb250cm9sIGNoYW5uZWxzIHNoYXJlIHRoZSBmYXRl IHdpdGggZGF0YSBjaGFubmVscywgYW5kJm5ic3A7NSBhbmQmbmJzcDs2IGNvbnRyb2wgY2hhbm5l bHMgYXJlIHVzZWQgdG8gdHJhbnNmZXIgb25seSBjb250cm9sIHBhY2tldHMuIEFuZCwgdGhlIG5l dHdvcmsgZm9yIGNvbnRyb2wgcGxhbmUgY291bGQgaGF2ZSBkaWZmZXJlbnQgY2FwYWNpdHkgaW4g cmVhbCBpbXBsZW1lbnRhdGlvbnMuPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFs PkhlcmUsIHdlIGNhbiBzZWUgc2V2ZXJhbCBhbHRlcm5hdGl2ZXMgcm91dGVzIGluIGNvbnZleWlu ZyBjb250cm9sIHBhY2tldHMgYmV0d2VlbiBwaHlzaWNhbGx5IGFkamFjZW50IG5vZGVzLjwvRk9O VD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbD5CZXR3ZWVuIEEgYW5kIEIgbm9kZXMgaGF2 ZSB0aGUgZm9sbG93aW5nIHJvdXRlcy48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJp YWw+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyBSb3V0ZS0xIDogMTwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1B cmlhbD4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgUm91dGUtMiA6IDI8L0ZPTlQ+PC9ESVY+DQo8 RElWPjxGT05UIGZhY2U9QXJpYWw+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFJvdXRlLTMgOiAz LTQ8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWw+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IFJvdXRlLTQgOiA1LTY8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWw+ PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbD5JIHRoaW5r IHRoYXQgdGhlIHJlc2lsaWVuY2UgYXNwZWN0IG9mIGNvbnRyb2wgY2hhbm5lbCBzaG91bGQgaGFu ZGxlIHJlbGlhYmxlIChhbmQgZmFzdCkgdHJhbnNmZXIgb2YgY29udHJvbCBwYWNrZXRzIGJldHdl ZW4gc3BlY2lmaWMgbm9kZXMuPC9GT05UPjwvRElWPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFy aWFsPkluIHRoZSBleGFtcGxlIGJldHdlZW4gQSBhbmQgQiBub2RlcywgdGhlc2Ugbm9kZXMgc2hv dWxkIG5lZ290aWF0ZSBhY3RpdmUgYW5kIHN0YW5kYnkgY29udHJvbCBjaGFubmVscywgcHJvdG9j b2xzIHRvIGJlIGNhcnJpZWQgb24mbmJzcDthIGNvbnRyb2wgY2hhbm5lbCwgYW5kIGV0Yy4gSW4g dGhpcyBzZW5zZSwmbmJzcDtJIGJlbGlldmUgdGhhdCB0aGUgcmVzaWxpZW5jZSBvZiBjb250cm9s IGNoYW5uZWwgY291bGQgYmVsb25nIHRvIHByb3RvY29sIGlzc3VlLjwvRk9OVD48L0RJVj4NCjxE SVY+PEZPTlQgZmFjZT1BcmlhbD48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9 QXJpYWw+T25lIG9mIHR3byBkcmFmdCB0aGF0IEkgcHJvcG9zZWQgaXMgYSBzb2x1dGlvbiBmb3Ig dGhlIHJlc2lsaWVuY2Ugb2YgY29udHJvbCBjaGFubmVsLCB3aGljaCBpcyBiYXNlZCBvbiBhIGNv bmNlcHQgb2YgdGhlIGNvbnRyb2wgbmV0d29yaywgY2FsbGVkIGNvbW1vbiBjaGFubmVsIHNpZ25h bGluZyBzeXN0ZW0gdXNlZCBpbiB0aGUgdHJhZGl0aW9uYWwgUFNUTiBhbmQgSVNETi48L0ZPTlQ+ PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWw+T2YgY291cnNlLCB0aGVyZSBjb3VsZCBiZSBv dGhlciBzb2x1dGlvbnMgdG8gc29sdmUgdGhlIHJlc2lsaWVuY2Ugb2YgY29udHJvbCBjaGFubmVs LjwvRk9OVD48L0RJVj4NCjxESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWw+SSBkb24ndCB0aGlu ayB0aGF0IHRoZSBJUCBjb25uZWN0aXZpdHkgcHJvdmlkZXMgYSBtZWFucyB0byBiZSBjYXBhYmxl IG9mIHVzaW5nIHRoZXNlIHZhcmlvdXMgcm91dGVzLjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQg ZmFjZT1BcmlhbD5Gb3IgdGhlIHJlc2lsaWVuY2Ugb2YgY29udHJvbCBwbGFuZSwgdGhlIElQIGNv bm5lY3Rpdml0eSBpcyBhIGJhc2ljLCBhbmQgYWRkaXRpb25hbCB3b3JrcyBzaG91bGQgYmUgY29u c2lkZXJlZC48L0ZPTlQ+PC9ESVY+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWw+PC9GT05U PiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsPlRoZSBvdGhlciBkcmFmdCB0aGF0 IEkgcHJvcG9zZWQgaXMgYSByZXF1aXJlbWVudCBkb2N1bWVudCBmb3IgdGhlIHJlc2lsaWVuY2Ug b2YgY29udHJvbCBwbGFuZSwgbm90IHRoZSBvbmUgb2YgY29udHJvbCBjaGFubmVscy48L0ZPTlQ+ PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWw+SW4gdGhlIHJlcXVpcmVtZW50IGRvY3VtZW50 LCBhcyBhIGluaXRpYWwgY29tbWVudCBmcm9tIERpbWl0cmksIEkgdGhpbmsgdGhhdCB0aGUgZHJh ZnQgc2hvdWxkIGNvdmVyIHByb3RvY29sLW5ldXRyYWwgYXBwcm9hY2hlcywgbm90IHByb3RvY29s IHNwZWNpZmljIG9uZXMuIEZvciBleGFtcGxlcywgdGhlIHZhcmlvdXMgcmVzaWxpZW5jZSBhc3Bl Y3RzIG9mIGNvbnRyb2wgbm9kZXMsIGNvbnRyb2wgZW50aXRpZXMsIGNvbnRyb2wgY2hhbm5lbHMs IGFuZCBldGMgc2hvdWxkIGJlIGNvdmVyZWQuPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNl PUFyaWFsPkhvd2V2ZXIsIHRoZSBjdXJyZW50IGRyYWZ0IGRvZXMgbm90IHN1ZmZpY2llbnRseSBj b3ZlciB0aGUgZ2VuZXJhbCBhc3BlY3QgZm9yIHRoZSByZXNpbGllbmNlIG9mIGNvbnRyb2wgcGxh bmUuPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsPkkgdGhpbmsgdGhhdCB0aGVz ZSBwYXJ0cyBpbiB0aGUgcmVxdWlyZW1lbnQgZG9jdW1lbnQgY291bGQgYmUgaGFuZGxlZCBpbiBm dXJ0aGVyIHZlcnNpb24gd2l0aCBoZWxwIG9mIGNjYW1wZXJzIHdobyBhcmUgaW50ZXJlc3RlZCBp biB0aGUgcmVzaWxpZW5jZSBvZiBjb250cm9sIHBsYW5lLjwvRk9OVD48L0RJVj4NCjxESVY+PEZP TlQgZmFjZT1BcmlhbD48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWw+ PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsPlJlZ2FyZHM8L0ZPTlQ+ PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWw+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48 Rk9OVCBmYWNlPUFyaWFsPllvdW5nLjwvRk9OVD48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+PC9E SVY+PC9ESVY+PGltZyBzdHlsZT0iZGlzcGxheTpub25lIiB3aWR0aD0wIGhlaWdodD0wIHNyYz0i aHR0cDovL3VtYWlsLmV0cmkucmUua3IvRXh0ZXJuYWxfUmVhZENoZWNrLmFzcHg/ZW1haWw9Y2Nh bXBAb3BzLmlldGYub3JnJm5hbWU9Y2NhbXAlNDBvcHMuaWV0Zi5vcmcmZnJvbWVtYWlsPXlod2tp bUBldHJpLnJlLmtyJm1lc3NhZ2VpZD0lM0M5Mzk5NzA1OS1jYmExLTRlZGItYjNlNS0zZWI4NWFh ODJiYjdAZXRyaS5yZS5rciUzRSI+ ------=_NextPart_000_5274_01C5DEE4.B1CB07F0-- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 01 Nov 2005 00:50:09 +0000 Message-Id: <200511010048.jA10mIL15236@boreas.isi.edu> To: ietf-announce@ietf.org Subject: RFC 4209 on Link Management Protocol (LMP) for Dense Wavelength Division Multiplexing (DWDM) Optical Line Systems Cc: rfc-editor@rfc-editor.org, ccamp@ops.ietf.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Mon, 31 Oct 2005 16:48:18 -0800 --NextPart A new Request for Comments is now available in online RFC libraries. RFC 4209 Title: Link Management Protocol (LMP) for Dense Wavelength Division Multiplexing (DWDM) Optical Line Systems Author(s): A. Fredette, Ed., J. Lang, Ed. Status: Standards Track Date: October 2005 Mailbox: Afredette@HatterasNetworks.com, jplang@ieee.org Pages: 16 Characters: 33906 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-ccamp-lmp-wdm-03.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc4209.txt The Link Management Protocol (LMP) is defined to manage traffic engineering (TE) links. In its present form, LMP focuses on peer nodes, i.e., nodes that peer in signaling and/or routing. This document proposes extensions to LMP to allow it to be used between a peer node and an adjacent optical line system (OLS). These extensions are intended to satisfy the "Optical Link Interface Requirements" described in a companion document. This document is a product of the Common Control and Measurement Plane Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <051031164719.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc4209 --OtherAccess Content-Type: Message/External-body; name="rfc4209.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <051031164719.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart--