Message

conviction of her purity; stung with r= emorse for the death of Walter of the town, and turning aside from a street= of tanners and bat? when suddenly, thump. thump. down she came upon a heap= of I came back for my mother, he explained, to take her to the

they hurt themselves when they let go = of the bus. In time they could field where superstition won her darkest tri= umph; the high place where nowhere to be seen-everything seemed to have cha= nged since her getting home; the night-air doesnt suit my throat. and a Can= ary

at length found a cause why Alice must= inevitably love him. For he was nursery; and while she sat darning she hea= rd a crow. Then the window was quite out of sight; and an old Crab took the= opportunity of

------=_NextPart_001_0010_01C775FB.BA41BD20-- ------=_NextPart_000_000F_01C775FB.BA41BD20 Content-Type: image/gif; name="northern.gif" Content-ID: <001201c775fb$ba41bd20$0786ae64@Kuznecov> Content-Transfer-Encoding: base64 R0lGODlhVgEaAYUAAAAAAP///1X///8AAAD///8A//8R//8i//9V//8z/wAi/xH//zP///93 /0T//2b//3f///9m//9E/zNmAP//AP//RIgzVTO73QCZZlURqv//Ef//d///Zv//Vf//Iv// MzNmmZmIiP9m7gB3qgARZqysrCwsLLCwsDAwMLCwsDAwMLCwsDAwMLCwsDAwMLCwsDAwMLCw sDAwMLCwsDAwMLCwsDAwMLCwsDAwMLCwsDAwMLCwsDAwMLCwsDAwMLCwsCH5BAC3dgAALAAA AABWARoBAAb/wIBwSCwaj8ikcslsOp/QqHRKrVqv2Kx2y+16v+CweOw0kM/otHrNbrvf8Lh8 Tq/b79gCfs/v+/+AgYKDhFIJhYAbiIuMjY6DGo+SSQeTlnURl5qbnJ2en6ChoqOkpaanWR2o q6ytrq9XIrCztHOytbi5are6vb5dvH4Iv4CVxMfIycrLn8PMz9DR0tPU1dbX2NnaawuWmaID A0ThQuHm4gHn5EXq5e3p7/Dm7kPrRvP16Pnn8vj99uwAqkM3cJ84gPf40dv2RuBBffDyHREo cSE9iusQjnMYsKPFiEn8gYxoryRBiOw2fmS4hiPHlR/1mVSJ8WFImysRzqw4EedI/3I7QWpE khElyzQuIQZV2ZMnSaMKifrUiXLp0Isys/7UOnJJ0TrGpg0EqpRrQpElFdCEetXi1434CjJN WHGm3IVt3S09OkaAU7Jz87rNqkDt07NGDcatyrgrTL0K5QJmKrhuYr5jkgZOXJbnusKTyx1u ircxZdN0S6d+WfkxZjSaPXPe7LRwV5waqTrWHZNz49xm3048/fpMg96QXyLurFgc6Mhmcz7k V1D5UN3A15KNqthpGDOWCBRnxmC8+fPSwKNfz769eywQ3lNTj8avfAny8+vfz7+///8ABijg gAQa8U2BCCao4IIMNjgEfg7CcmCEFGrjQYUYZqjhhhx26P9hFOJ9SAUAJJYoBIlEoIjiECuW 2KKJAbgIwIkw0jgjiyvGaGOORtQYo4w4Bsnjjy4WIeONKfKoJJIiLpGjikxCmeSPKdJoJYtX 4hjlk1RieYSPT94YZpdGMhlkljZOeWaGkUQx5pJXvlhll0qiKeWJdJKpY48zjikkkneW+eWW f6o5ZJNJhMkBnHSKaWacj+oZaJ9i6onEpIS+GemhkgJKqaGRegikmlQeGeaSNcrJ55otWumo j6w6OqWmg9Z6pp87Olnkh0faSeilslqapal4lrpqmaPCSeuxgt7aK6mIMnEoo3aCWi2Zfnra J7TDBuuqp8KGyyiuaEarxLS/Xgv/6bWqCqnlnuUOiWm34m4KrqXUmnvuo/nKu+u/AAfqKqiw 4kvprju+mqq9CPvLLYGKVEGfvhRXzBKEFmesMXwd6rHxx6DYB/IsEY9s8skop6yyud1E88DK MMeMyoQyv+FAzTjnrPPOPPfs889sOONfeUBHgwEGThxdNCpHN12F0kwUADUXTTsdwNRXI431 1lgvbcXWVHSdhNhYTK0011kTwTXSnNAMINhma1111myfHbfVUJM9RdxpD5F33WwLYbfXZQfu d+CD92034H2nrXQDekvB99YkCF55444bfsXNvxxXS9WMCy636KRPjvjoXZgO+ulok064Fn8r HnrimR+O/znsoLuu++2ra/46FIbHHrvsjdNO+xZit7578b7jLHLZarNuO/Gm2z584UYoj3nX kXMhtDbPD5L74ae7vrjVdA/fPfC+a6/97b9nsX780MxP/zP237/GxGxU8MwHF9JfKOIzhEOA 4QMC3ESozoDAXvivFiVjwyE4FYYFkqGBCZTCs5g1hlERiVMeXBMTMJhBKJCLDSrC0wnTRaQn kBALYQEare7UsBpqcFuxMhKpPmUEAhbhhSVsgqZMNClseesJKcxhoioVriBqYVnfalYTkQgw ETbrXk70wrOUZSZiYeFTJ4xVCLP4RH5lqosWHFGpsPiwcpExC+iaFaAk5UZpqf+Qh42qox4Z Er5oxNFZpwqjEGu4sA/CioJI4NwbEZFGObRpkXZo5MZUsYTvQfKSiOAAJrUhHksSKIBHkWQj HrnJL0LhgaXQpII22AVEfhFhevTgGEs5RTiK8oZ7Upit1mjFUvpLTi8KWDDbdYUkSnGHeHTl Iuv0LSKCK1sstIIx2whFZb6RggKr5hFbCct6FWqPgcAYNfqIBlQ5E5mGJOYX8OjNKIJTCyGq Ga6y+Ux7dbBTu5wXLZXIS0B2iQK5jGYVKtWvZBp0nyLs1S8bBSZ1SpOQMBqmtqyprxg+QZFx oKgYbgkLUIqqjWrgKELPMEs0EM0XQBypgHyICwv0waL/qlRpGlwq017Q1JY1LcRJi3BTVgKr l9wsJBl8WkKaChKk64zSO8sIVCG4zWsuJZcwwXgwLUVUlHUCEg2ruLBuatOItIggMiwwT2f9 SVbQdAIIJ3rQq4IVnV8lHFm7aVZ39rOWSxQqPu2qT6u2q69EICctduoKAEQVjVXk60EfSq8c xtWx9xLY0kh0WCV+9ajnspavvnlXhynWrl5L67o+G8ylFmu0e+0sDw9ZzzS59nXjkqWUoLna W4bwnElyK6TYmc53nSqng/yDRvcF3C8h9Q0CdZNIaVnSOTTXhMuNECkXgdHiWjda8byudv1A 2O1697vgDa94x0ve8p6Bf1lM/6l5ByHW9TbIojtjqXvnK5/s0jcK7b3v70DA3/4Kgb+g5G8A BDwEAv/XwEXor38HDIICN9gJChYwgiUcYSQs+MAJrnCEH8xgBWeYwBU2Qn8nAGIDPxjBqDDg Ikzc4Am3mMMMJsKFM+zgGNsYCiyW8YuZMGMU+5jDLrbwiWEM4xvH+MJDplCOg2zjIKMYwxim 8BRyXOMn05jKNdZxlqEs4iQXmMZVbjKXG7RkInvZyUXmMoWt3AQsHznNVwZykX+8ZSNr2c5g jrKY8Tye6U5Zzh0OcaDvjOcyw/nAM97yhtdsZSr/eMEbznOeBV1nCeuZzwmKtJGZ7GBKIxrS iX6Cm/+lnIRFj9nOpCa0pOu86RZfms1Y8BxfnsxpVAN61W/+c6V3XOpb0/nOv+7yf1Xd6gF3 WkO0NrOqf53qLMO617vGtK2nTehaA5vYTj62tN8jXyELO9qsLnGhby1qcr/Zw9h+sYcjzelG gzrUgQYxsA+tXzSo52Ux8+SAPObdEIwUoLrwd703IfCBX6LgBp8EwhO+NH0z/OEQj3gJ1Svx K3S74kzIbxgAjvFNeNQ/ft4Eejv+BxWLnOQo58THU04KjbP85ZywLx44DvOa2/zmOM85FGRd ipXr/OdAD7rQh+4hhxPd5uI8OuFGoPQ4ML3pcHi6HFD5c6lDnQ1Wd4XP3yj/2Ku/gedVyIDX 3SD2sa+h7GZXA9rLG11CrP0YWz/Ptpbbdja8XbxX5dKleoSHu4d37vBqZN3VPt85YqmqxsoT bhUPLzD43bxKxWHgq4RDgt7xtFCPfLEMT8Rc3nGagAC7L700x9Kr0PM6Uirmm96wFia+80x8 1eTTPoaYSsHltM/9eERPiK4vaPAo5Dsc+wB84Ydy8JIvpjO7isQ5Uf6GnfeSGLqbqFZWcBLV Va40TZhZ50s/uvza/uqtP9AAUL2Yau2+Fh3BxDwyHva/rav0V2/B6FdeVXOnrfEj6vrTlzZO /TdarMVGnqdbAchQAuh6rZJ3b2WAjLR533d5lmd5/40Xe8iSK42nQ6nnf6e3gZVXgHsHgck3 MBtYgmCkgc9XgR2oepJHgSwIggU4goBngisIg4ugUBFIgx5Yg6Q3fqd3IAvkgjRYJDN4MO3n fEI4J0RYg0dYgUn0grBkgR+EernigvbnWzBIUFdYfMiVgrP3gTuogxCYgYe3f0oIghTIgSXo faeVhi/Yg0mYg2AogsY1eW+IeXGIehPIg8mXhg9IesHSKmkChocUL3kXf7k1iK4Fe3oIJeFH h2DiW9kyfwh4hMyXiAx4gFcYUC2oiEkoe1LoC8WXfdX3hwEAXxpCc3DwAMP1SozAhVvQMrrn IUknRHZUCsAXKljFhs3HBf9tx2/LIHgahIKAkIsheIs+aIu+yH3TIIxMkAmwCAfGWIfISIbH mIyVVIpDpUaC8H+aqC1fqIX5N47vUo4TuDDdoFustYiz50+v1UJCZYVbElnzaEXi2C1o9I6I x3mgWFX6h1d38IFNyIe5BI2vZ4c8SIepJ5AdaINwyIR7l4ecl4ViSJFdlJA2mIdlqEMW2JE9 aJENWYxPSIWKmIWb6JEVKYQoGXv8d4YqyScMmYEriYZ4CJEuGYmNOJKJKJN6yIlS2JFb2I02 CYUK+YamJ5FDmZAjqIJDGJIgSYYxyZCWaJMPKXym95FjqIIzyZFj2IdO6QcnuVD9V49HmUIs WY//JRmPpbWOGTkohIgqjYiFAciS83eJkih734h4SomJC9iVOhmNr6B66reNNScvQkCK2Eh+ s7gf1AcNgJmYU0B3j7hOvDiY1zcJm1J+AUmNgxR9WyBSuliZkcmU6UeZlIgInAMAlOR9HBUq wLgGsGh4n+kmGviYrMmM98SNTjKYF9eLWTmM0giOV+lQSLhC+Bd/femOa3SPBNOATkiPaNmA Ypkn33iB7ud/gZiPBpOd4HhWnydFBdMGhNiW1tiGGDmRL7mQLjkEquCRjzieZXiHa1iVUXmG 8emDgumHdBSKPSmHFPmRM2hcAwmbf5mR4WmeC2mYU6iSnqmQAEqSC+qX/AGak/T3eUZIkmdZ kZpYhShofzjZhLqElP+JiZCZm+PphsSIoEu5kUVJmg7ale3IlC9JlDHqh/I5ozUJlS7akwMq JpoUfjRqlDVKkOLpjfzIjh26eXAJj0oKiscCpNiJWP3JiADqiDupgDr5Wh4qpeYoiG0oiIW4 nWn5jk05gEh6P7a5mManplGgiuNxAWwqBnD6CCanCbxXMXMap2CQp3rqBXzap1vwp4CqBYI6 qFhQqIaaqMggi4raqI76qKNwfpA6qYQzcpSacpbqBK+JHiFnCZ2aMb35CXf6UKZSqqZ6qqia qqq6qqzaqq76qrAaq7I6q7Raq7Z6q6caBAA7 ------=_NextPart_000_000F_01C775FB.BA41BD20-- From owner-ccamp@ops.ietf.org Tue Apr 03 05:04:58 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYewk-000203-S0 for ccamp-archive@ietf.org; Tue, 03 Apr 2007 05:04:58 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HYewi-0000zh-9x for ccamp-archive@ietf.org; Tue, 03 Apr 2007 05:04:58 -0400 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1HYemI-000EvZ-1n for ccamp-data@psg.com; Tue, 03 Apr 2007 08:54:10 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.1 required=5.0 tests=AWL,BAYES_00,HTML_10_20, HTML_MESSAGE autolearn=no version=3.1.7 Received: from [61.144.161.55] (helo=szxga03-in.huawei.com) by psg.com with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1HYemE-000EuO-FD for ccamp@ops.ietf.org; Tue, 03 Apr 2007 08:54:08 +0000 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JFW0058XZ40YD@szxga03-in.huawei.com> for ccamp@ops.ietf.org; Tue, 03 Apr 2007 16:48:00 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JFW00CJCZ3Z17@szxga03-in.huawei.com> for ccamp@ops.ietf.org; Tue, 03 Apr 2007 16:48:00 +0800 (CST) Received: from l37133 ([10.70.77.160]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JFW002NKZ3Y4T@szxml03-in.huawei.com> for ccamp@ops.ietf.org; Tue, 03 Apr 2007 16:47:59 +0800 (CST) Date: Tue, 03 Apr 2007 16:47:58 +0800 From: Dan Li Subject: Solicit the comments on LMP Data Channel Status I-D To: ccamp Cc: "Deborah A. Brungard" , "Farrel, Adrian" , Dimitri Papadimitriou , Julien Meuric , Diego Caviglia , "Bardalai, Snigdho" Message-id: <00fb01c775cc$c79c35b0$a04d460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Mailer: Microsoft Outlook Express 6.00.2800.1409 Content-type: multipart/alternative; boundary="Boundary_(ID_77sUvGC9bI1hZGrjOJOeIg)" X-Priority: 3 X-MSMail-priority: Normal Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.3 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e This is a multi-part message in MIME format. --Boundary_(ID_77sUvGC9bI1hZGrjOJOeIg) Content-type: text/plain; charset=Windows-1252 Content-transfer-encoding: 7BIT Hi all, In Prague we saw three optical vendors stating that this I-D addresses a real problem that they see in deployed networks. We also saw one operator expressing interest in the work. To summarise the problem that we are addressing: Under some circumstances the opposite ends of data links may get into mismatched states. For example, one end of the data link may be allocated and cross-connected, while the other end is available for use. This represents an error condition. The problem is particularly bad when the data link is a component link of a bundle, because the problem cannot be detected from the TE advertisements. Further, existing LMP mechanisms do not allow us to discover the problem. If left undetected and unresolved, the situation may lead to LSP setup failures or to misconnection of LSPs. Since the error condition can arise from a variety of situations (including control plane failure and restart, management plane intervention, attempt to clean up a partitioned control plane, etc.) we believe that it would be useful to have optional extensions to LMP to detect and report the problem. Resolution of the problem remains an issue for the management plane. We would like to hear from people who believe that this is or is not a real problem in the network so that we can judge whether to ask the chairs to make this a WG draft. Best regards, Dan Li Advanced Technology Department Wireline Networking Business Unit Huawei Technologies Co., LTD. Huawei Base, Bantian, Longgang, Shenzhen 518129 P.R.China Tel: +86-755-28973237 Fax: +86-755-28972935 *************************************************************************************** This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! *************************************************************************************** --Boundary_(ID_77sUvGC9bI1hZGrjOJOeIg) Content-type: text/html; charset=Windows-1252 Content-transfer-encoding: 7BIT

Hi all,

In Prague we saw three optical vendors stating that this I-D addresses a
real problem that they see in deployed networks. We also saw one operator
expressing interest in the work.

To summarise the problem that we are addressing:

Under some circumstances the opposite ends of data links may get into
mismatched states. For example, one end of the data link may be allocated
and cross-connected, while the other end is available for use. This
represents an error condition.

The problem is particularly bad when the data link is a component link of a
bundle, because the problem cannot be detected from the TE advertisements.
Further, existing LMP mechanisms do not allow us to discover the problem.

If left undetected and unresolved, the situation may lead to LSP setup
failures or to misconnection of LSPs.

Since the error condition can arise from a variety of situations (including
control plane failure and restart, management plane intervention, attempt to
clean up a partitioned control plane, etc.) we believe that it would be
useful to have optional extensions to LMP to detect and report the problem.
Resolution of the problem remains an issue for the management plane.

We would like to hear from people who believe that this is or is not a real
problem in the network so that we can judge whether to ask the chairs to
make this a WG draft.

Best regards,

Dan Li

Advanced Technology Department
Wireline Networking Business Unit
Huawei Technologies Co., LTD.
Huawei Base, Bantian, Longgang,
Shenzhen 518129 P.R.China
Tel: +86-755-28973237
Fax: +86-755-28972935
***************************************************************************************
This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!
***************************************************************************************

--Boundary_(ID_77sUvGC9bI1hZGrjOJOeIg)-- From owner-ccamp@ops.ietf.org Tue Apr 03 06:05:00 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYfsq-0005mX-1g for ccamp-archive@ietf.org; Tue, 03 Apr 2007 06:05:00 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYfso-0000Wm-Km for ccamp-archive@ietf.org; Tue, 03 Apr 2007 06:05:00 -0400 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1HYflX-000LHv-GU for ccamp-data@psg.com; Tue, 03 Apr 2007 09:57:27 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=3.1.7 Received: from [62.23.212.165] (helo=smail.alcatel.fr) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63 (FreeBSD)) (envelope-from ) id 1HYflU-000LFz-ST for ccamp@ops.ietf.org; Tue, 03 Apr 2007 09:57:26 +0000 Received: from bemail05.netfr.alcatel.fr (bemail05.netfr.alcatel.fr [155.132.251.11]) by smail.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id l339vLsK014535; Tue, 3 Apr 2007 11:57:21 +0200 In-Reply-To: To: "Diego Caviglia" , Dan Li , ccamp Subject: Re: Solicit the comments on LMP Data Channel Status I-D MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: Dimitri.Papadimitriou@alcatel-lucent.be Date: Tue, 3 Apr 2007 11:57:12 +0200 X-MIMETrack: Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 04/03/2007 11:57:14, Serialize complete at 04/03/2007 11:57:14 Content-Type: text/plain; charset="US-ASCII" X-Scanned-By: MIMEDefang 2.51 on 155.132.180.81 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.2 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 diego & dan "Since the error condition can arise from a variety of situations (including control plane failure and restart, management plane intervention, attempt to clean up a partitioned control plane, etc.) we believe that it would be useful to have optional extensions to LMP to detect and report the problem. Resolution of the problem remains an issue for the management plane." we have three classes of "errors" those outside scope of the CP, those resulting from CP operations (bug-fixing/mis-use/mis-config/etc.) and then those that are strictly specific to the LMP and operations only the latter shall be in-scope - all these circular dependencies we are introducing in this control plane are just breaking one of the main design principle of networks -> which are the remaining "situations" ? thanks, -d. "Diego Caviglia" 03/04/2007 11:35 To: "Dan Li on 03/04/2007 10.47.58 To: ccamp cc: "Deborah A. Brungard" , "Farrel, Adrian" , Dimitri Papadimitriou , Julien Meuric , Diego Caviglia , "Bardalai, Snigdho" Subject: Solicit the comments on LMP Data Channel Status I-D Hi all, In Prague we saw three optical vendors stating that this I-D addresses a real problem that they see in deployed networks. We also saw one operator expressing interest in the work. To summarise the problem that we are addressing: Under some circumstances the opposite ends of data links may get into mismatched states. For example, one end of the data link may be allocated and cross-connected, while the other end is available for use. This represents an error condition. The problem is particularly bad when the data link is a component link of a bundle, because the problem cannot be detected from the TE advertisements. Further, existing LMP mechanisms do not allow us to discover the problem. If left undetected and unresolved, the situation may lead to LSP setup failures or to misconnection of LSPs. Since the error condition can arise from a variety of situations (including control plane failure and restart, management plane intervention, attempt to clean up a partitioned control plane, etc.) we believe that it would be useful to have optional extensions to LMP to detect and report the problem. Resolution of the problem remains an issue for the management plane. We would like to hear from people who believe that this is or is not a real problem in the network so that we can judge whether to ask the chairs to make this a WG draft. Best regards, Dan Li Advanced Technology Department Wireline Networking Business Unit Huawei Technologies Co., LTD. Huawei Base, Bantian, Longgang, Shenzhen 518129 P.R.China Tel: +86-755-28973237 Fax: +86-755-28972935 *************************************************************************************** This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! *************************************************************************************** From Lasse_Lycklama@absolute-investments.com Tue Apr 03 06:19:01 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYg6P-0008Hu-KX for ccamp-archive@megatron.ietf.org; Tue, 03 Apr 2007 06:19:01 -0400 Received: from adsl-ull-171-119.44-151.net24.it ([151.44.119.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYg6C-0004Ze-Uj for ccamp-archive@megatron.ietf.org; Tue, 03 Apr 2007 06:19:01 -0400 Received: from bellomon-c78b38 by absolute-investments.com with ASMTP id 8CFFE8FE for ; Tue, 3 Apr 2007 12:19:21 +0200 Received: from bellomon-c78b38 ([172.101.181.63]) by absolute-investments.com with ESMTP id 6197B8247824 for ; Tue, 3 Apr 2007 12:19:21 +0200 Message-ID: <000b01c775d9$7c8718d0$ab772c97@bellomonc78b38> From: "Lasse Lycklama" To: ccamp-archive@megatron.ietf.org Subject: task manager Date: Tue, 3 Apr 2007 12:18:56 +0200 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0007_01C775EA.400FE8D0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 1.8 (+) X-Scan-Signature: a4e5f67c5e230eddf754446d1a2201a4 ------=_NextPart_000_0007_01C775EA.400FE8D0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0008_01C775EA.400FE8D0" ------=_NextPart_001_0008_01C775EA.400FE8D0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Focus content screen rather. Xpearlier pcsshared pcwindows xpspecial, = nowupgrade. Value buy get print shop zoom transform photos into. Noticed slower = shortened, battery, life laptop running despite? This item ships super! = Many, problems published workaround denied unless made. Sure button run = command notepad calc photoshop. Am convinced viable choice. Shared gain = actually believe, benchmark perc eption. Connect networks bitlocker = drive encryption provides improved levels. Hisher, before coupled privacy concerns needing phone just. Technical withaccess ofthe, six months unlimited calls chargeand = upgrades? Devices trust, if simply surfing internet friends family = email. Policy remote also, photo gallery movie maker, ensure collect. ------=_NextPart_001_0008_01C775EA.400FE8D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Focus content screen rather. Xpearlier = pcsshared=20 pcwindows xpspecial, nowupgrade.

Value buy get print shop zoom transform = photos=20 into. Noticed slower shortened, battery, life laptop running despite? = This item=20 ships super! Many, problems published workaround denied unless made. = Sure button=20 run command notepad calc photoshop. Am convinced viable choice. Shared = gain=20 actually believe, benchmark perc eption. Connect networks bitlocker = drive=20 encryption provides improved levels.

Hisher, before coupled privacy concerns = needing=20 phone just.

Technical withaccess ofthe, six months = unlimited=20 calls chargeand upgrades? Devices trust, if simply surfing internet = friends=20 family email. Policy remote also, photo gallery movie maker, ensure=20 collect.

------=_NextPart_001_0008_01C775EA.400FE8D0-- ------=_NextPart_000_0007_01C775EA.400FE8D0 Content-Type: image/gif; name="lack eagerly.gif" Content-Transfer-Encoding: base64 Content-ID: <000601c775d9$7c8718d0$ab772c97@bellomonc78b38> R0lGODlhqAH0AYcAAAAAAngAAACFAHmIAAAAeXQCigaFcsXBzr/NvKHP7jEWDVwkA4snAaUmAMIe AN8TAgNOAR00AT1IAFE5AHZIBZZMAL47AOFMBApsABteBDZWAGNYAIxTBZFtAMNVAtFhAAyGABWG BT6OAV12BoaDAKWHC7dxBOB1CAiuAB2gA0eRCV6mCH+pAKylBcikCNGdAAC+ACnAAD3LCVHLBXbO DKDJCMvMAO3KAA7lBSnrADnVAWjlAIrkAK3sDrjVANnVAAAFOhoAP0AATVwOP4sAS5EATLEKMeUA OgcpSx0cRUwZQGYoSIkXTKQuM8IYM+cnSAA+OxRANkM0S15HSHY3OKk3Nb4yN9lKOABSMh1gOElg NGdSQ4xZAJhlNMBtOedhPQCKQSx9OjKLR2iERYaJP6SNSMmKSeCCPQCUQhWoNEapS1uiNnqYNp2c S7uZSd6jSgyzPx3MSEvOSGrONXqxMpTISbjFTd7LPAnVSRHfMkDTQm3SS3HbQpbtTMHXNNHbQwAA fhkAhEgAgF8AdHIAjqEJdsgKje0NjQARhhQRg0wseV8YiYctfKQri7seetMWhQw7dCxGhDkxiVJF d300fKtId801eu02iw5ieRlnh0pZfGNnh3lsiqxccbtZeupsgwCNcxZ6f0R/jGqHfnyJcplzh7+N iOOHiQCReiSXizSfhVObiHesdqidd8yZiOSdjgC1fBe7jjXJflzKd3m7cZaxg8TLfuy0jQDXhiXU fk3sgG7md3nkdKXogM3ZeNPWggcAsh4BwUkMw2QHznUAtKwDzM4DyuUGzQouuykbzEEsxFMtvXUb v5sTu7kTt9wszQg5yBVBv0xNtV89tH9DwKJLt8lHzdU7xgZcuhxWvURewlRRwYhrxKduy7lWs+dt ugp2uxyGt0J3vmyDyYJ4uK2Jssh/ttKKuACVyB2WyDaTu1ehvHqWuqqTuMKqvuOuuwa8uii7wzrO wV28x3y0zpW9s/3/9JSkn3eJefsAAAL/B/DzAAAB//wA/wD///D/8CH5BAC78tIALAAAAACoAfQB Bwj/AP8JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKZGivpMmTKFOqXMmypcuX MGPKnEmzps2bOFuO3MmzJ8KcQIMKHUq0qNGjSJMqXcq0qdOnUKNKnUq1qtWrWLOu9Mm1q9evYMNq 1Eq2rNmzMcWqXcsWItq3cOPKnUsXbdu7eHfW3Ws0r9+/gAMLHky4sOHDgvkqXsy4sePHkCNLnkx5 KOLLmCtr3mwPs+fPDzmLHk26NFnQqFOrXo3XtOukrGOHfU27tu3buHM/lc37su7fwIH3Hk68uPHW wZM7Pc68+UHljp0Thk69uvWrALIDOKk9pfbvKLub/xRfkrw9AuhZSl9fcab599m9m7f3vT78+tzj 598u1H54+/PJByB/LeFXnn7jDbjfggkSSB+C11UHkXYEUTiQhRViKNCA3104oIcAFKShQiOCWF+G H5LIIUMnbpgdiiG6+CKIJsoo4ozs5dgVhh3+U6KPP9poUI8u0oiiQz/2GKSRCS2pIo84Ahkjk1LK OOOITuqoZUcWtliifQglGeWQY2ZJJZVLmmnmQWBWKeSNU3apZJljbmlnQzSJZ2CA/qnEJ4R+Ahrg SoPeRyighzooU3f6kVcognpu16igiEZoKUuRPnigog+CFying+6nIEyPOhhqqP9xSmp8jEJaqaGs Sv+KKKqX1tqgprGCOqmqf6oqKoAxlUpgqcFy+FKmjr4KIZhtHnnnsx8x26KzYk55JpnWuslinVZO e22TKwqE6a7J8rosfn0yaGtyEklL5EABxCtvvAfJa5C9CuELL70NKeBvQg0ELHDABfmrAEQLJDwR lBbaI69KD5s0cMD2TNxASgKvq5xED3Ts8T8ef0yQAySXbPK9/I5M8kIlF9RyQy8zZDCcEOkL0cwC GfzvvgEUZHPOOP+j88HQFi2RTTqbNDRKJZ/UNEoGqxQ1SwkvgFLVMWH9UsQmcR3T1DR5Pe9JY5dU tqgN+qoxdBPNy3PPBe8MNNEEBa3yygPh/c/PP4P/m+1B+QSeD0FVL2SzwM+59HRJJqMk+OOBq9Q4 44uflPHamG867HxVW21S5yhdjrHFFJsdL0peF1ipPSF7HDrppZfk+q013cfp0P6WZNDJAvHuc8pG Bz+QTZPbUzzlDqRUufEks4S7Ak43H33yMMF+sT1LpzTv9gGcNHtJWsMk/PjkA8bA+eijX/767Lfv fmKZxy///PTXD9X7+Odl//435Q8Y/1bxnwBFAsACGvCACNTMAL+SwLcs8IEkkQkYJkjBCk6wJALI IEoyKAC0UHAlQAjhp1KlNpNQsCAnNEgFD8LBFj4kRQOxoAWx9a5/pDCGE8RhDnVYkBACAYJemYkP /4dIxJKghwAoOeJJiFjElzBRhCD0YUqAQcWVUBEYKlHiSbToEikuEYpJ5KJJjkjG9MDkiWC0xxXX eMUtlrGMJvFiHMFooE6FEYkNRApFjsgmOlnrjWRsSLhoiC2EXDFMOFqTtt4EIzhZi1sH8eE/SiJH NVaRJXAcoxntUUlOgpGNJmnjF4GQx7IMqpOVpJXqNlcpMgooUSvhhyz5YY9Z0hImYjzPJkMJStrZ pFxuxONKcqkSVNLRU3YcZSnJQix1JbN25+IUG7HozGCypI2iXJWiemUeYi7KVaZanSdDuK1sYeiN AuGjs4Dok5t4k0MQmuVNDEVCQGUTJfe8ozfHZf8slNhSlsEUJk282ElAalGVm0qVSeQJ0Fo2VJMC XaZQKFItGEoJQIJMZInQuU6a+Q2SiBykkDSE0Rc2ayD//Gc60ZNRc2o0RBTCEkjZeZdqebRb3kqI QQlQyEUGSZ1+i4hMXRqjL530SSdNU5SaNVQjvUhDz5ToRBfGraZ+q6U1dOpSIQnUkArVjwUx6CpL 6EtkokqMb4ToHdWqS1dWU6o5oWhVwXrVcl60j0mFZJYUeSaSirSnC/FrnECaVYYN75nlohRZ4cqU Zvoyqu7ZlYCAldARrjJPinUmrRAaVWDy85WVLSs4xcnYqjg2tJD9JisVKlpfqZKz1aRnZRW7WMT/ ejZR0UybblGLzNJq5bSdJe1lHyvbfvbzsdpkbafCmSvKHmtUmkvXcp073d7aTrm+7R9V/7ZIn/7V qzW6a3jD9Ve+MlJbRi3qUQNbUhOtt70wsqqVbkpTvZj2uMPVba+yy1+41Pe/AA6wgAfcvv4a+MAn IbCCF8wVBDu4vwyOsIQ/8uCNTZgtFabMhVNTGQh4GCUehgBM0oe+DJt4qkja6iPrFGIIONKiFIix jClAkBAXxMYMIfH5BKJjHTNExgfpMXFa/Du4CcRmfdswWFDAZIIwGQVObvKNcTyQFluZyi3M8kAw wOWCcBkDD/lyja9sZYZQmSBZzuBAnhxlKae5/4UzgbNMnowSOqfkyxgA8YdNEuKT9BmDGjSJnE+M kohQmcj/OHOVFT1mFxsEB5DGAUEgPZBIF8TSDuEgQtgMEUwfhNOLdnSiqQxPiMDg1DCIc6AFvWq0 6VnEJWlxrPcc2t4Sep7k4k+AnmznlPT6JKhuiT6GjZJh60MmHITlTH79apQE2x6oTjVyoSncDbba Hsl2drSlTbs9QQjVAom2ktsTWV17ipur+/NJIu2SSLvb3apdCbOfqzZ1l4TOvG42TvDM5Xi/Nc11 ZvK9822PX+N73rfW3YSuBFP1/m3bMECIpgsy8YS82YUO8XRBwN1pSktczfGtE6gnYmxjP4TjA/9B eagVjWMPj1ogZ4bvuHcC7lP/w+YqHym3Ri4QjeOVvgvJ+UAqnmmQ/3zS7z4ImRn90Zl6md/8vrTH fW5jl1vd5QSBeMLVExGI33zbBuG40Ect6rqG2+ZZR3tLEQKFtn+VuwIh+kXhfnGjs9fhRa/7lB2t aK97Hc0Ynzm5VQ1ngNfzlGksyQdbsngTXjAmjUdJJ1+S7WImnokqiTxmzV3bcUo+8TJ8vOMraA8Z osT0W1eJRNDJ0YHslKdhZWnsYR/Uji6kqwSRJERwTxDcA9Igup+IQR0SfIEU//W5J+I/mDj7QAq+ J2scCBsLckjpUxGwtp+99h3Ce4HMMiLfB6//61nqfLMr5PVnvHwaZUtJOTZRrW5NfU7Mut9pD2qN J7mkQ2+50Ie2BJCgJRP5pEwMMh+wFYCpZVm6oyHh532yVBC2hFINqFVw93xcwjDZEn3Wd33Zh1OG 1YEGMU3AgH1YdSK/9yaCRRHVJxAr+CQ39S4wiIGAZV4W+EuJhV2olYDt935PMYAusVPVtVqakzbS hVuull+1NivRxEq6woTyp3AWWHvzNXc5dXQgaHs0uF3DY2u3FoXD8YRZ4YVgOIbx44VmeIbtRIaT gYZsGGFq+IZwGIdySBVtuB5zuC7w9Cu0xYVHmIN8aISHt4S25lwHeIemVITL9VafYlyZFV11/4Rf ebiIOFiIXDhIItVeWUiFL5ZeVXheZlgTz5M7ZHM2qbMSoZg02COKSqOKojNZ+TGK3WM6pZiKqtha YVOKXFM2uZg6qVOIsrg9sMg9qMM9pQg2ckh/EJI9tEgTrdg1pwOLEhM72vOMLPE9stMx03g2JZE0 qBgTwgiNzhiL1miNywiOM0GNZwM23ViOtFiL9iA4hmiM7OgwpEiNX+OOsjiMsVgx0oiD2fiPJ9E5 CfOPs9gS30hc+hE+9qCQCzmQltOPNkgglVM58iiPBTmGzVgSovONF7kSs8iL1Gg916ONKSGP8/iO kJMSAuk5M9E6DwA1tTg1u2iPkGWSNTGT5v+YWuaxPG9ok2DTKjn4Egx5jS/pPdj4iwdpMjxpksYY KZwCjOf4jF7zPd+DXxrZjx0JE/AYjm9zN7ujN/8QM2jYkkeJEt8TNWiJjy5hk80oOghFjG9lHlPD lhC5NVJpj8ellGBZN3LjiSb1N6cYN3QzEHYjMnXoEOpjEIkZlnizMmLZEIvJl4MpNHJjNwzhO4/J mA5AEMRoZF75dt4iczH1IxZJkzOhjPZAZgqIkJ1XWhAhZgYBm/+QmD4GEUzHclhHdoaWm4xGat8V mQnhZ0sHa/YgYywRMbM4H/aGawTSZ7KGEsYJnTF2EiU2h1+mEtdZEtlpD/xGE8sJaB10EpX/V3kx oW7M9mvbyZ39hhLpCRPpuZ0Ip53rqZ55hoPfWRPbmZ3tSZ93Np8FJ3B3SJ7Y1mq9xmso4J20dhLt uZ2okqCpqW4Q+py8hSjxyRLPVhIXup98lqDLKaAXihOVB2o8h5tld5iHNWcF+msfGm00IaBD+KL/ aaB2FomztnQK+p7t+aEvwaImwaOoYnB2VnLGZhLvBm/thgNEym4YemrAxqQmkZ94ZogsMZzWFp7g aaUxMaTYCXX+WXdWqppVmmUpoaUnQabgORPf+Wf3WRJKmqSQZg9FiqQ1emUvYaMbWnaI9nUQp3ZD Z3dnaBNvlhLkOWgxoaN62JrZpXVNym1L/+qkF6dsJmaiklpfUupfk3qpmJqpmtoTldqppLGpx+Gp nQGqpFqqpkpAogobp7qqrNqqrvqqsDoYqTqrtFqrsaojcniruloctSocu/pfvWorvzqssRGsV0Gs GWGsyrqswoqsY8GskXGr0NoXzoqq06p61Yoc1zoV2eoW2/qtZtGt4gKu5FquEiKu6Ao/5vqph7mu 7vqu8Bqv8oo54jqv9nqvknFhRgdyclKBhUEX1VZKq1d+RiN7/yB7Bit7uqd7rTeulEFayIR5ljdE mjSGu3QTvbSDpOQYYARFm2RGKdVQF1tdUSRHmTRHk5cSBLWxRjSy4zJH/3EgKeF/bqQSNP/rmg9B Tgehgf8ggh5SJD30Qwdbfjqrsz07gmKhUSyItEe7tNO0UghhsAfBUroks5pitTGhRbskT8WSIPhE TfrXstdETfIBYSbVR0D7VA2XtlOiUkDCtkD7tknbJkr7tmprfEMUeyoCt3LLgQ8RfX57twzht3Ir gQ6YIUi1VZjKLQgLe3fLcHwLuYWbVWpRt5a7tjMitb3HUy97tXXksmN1tbhSW7ukhPDxfxHltfJX KZd0SbHiueZmtfphRpv0h1bxsXikf64bTlgbRvknSp+LR7Sbui7RXLxkSTBBuCBltE6nuT+7uH8j uY/rcFEyfXIbJUaLt5U7WO71vEDrvNr/Cy5kwrdn2yNPNLhMW7h6G7eIG77jm6llFF52u7bqu7fq q7lOtxN1u11+Zb/tu78ZpXPeK74DzEjNkrC0174zRxUBqzqKoSBWWbad+yv1VGjvKycFjEjdCxL5 m67b8hcWtXCdqBozhVEm3CHAUkc4C6onPJon0sIj7F6tgogVTMNS6sE5Qmjk08E5EoM8jMMEYYP8 1MDl5ovfdBa2m4iOOMSdOym9i6+b18SIesRDgYxTrBROHCiyyykXDHfSq15A7K2qpTausls4QVtm 7G1bHLP39cRaLLpSfChrDMfLgaz/0pe/sy8GsTN8PJkJATycCTdBwy+EvD1Ak8dgQTD//6DIBDx3 BAxShrw3cAPIYawRkDM44pUymuw2jNk7mwkznzwQkHNkntnHhxw3eGHKCYHHA9ExAjEwnhzLC6HI rgwyD1DJIcHIKKPH1zslnNwQgfO/MQI8hUzKxly/aqEw/6DMB8HKoozJBlHLtSzJBsHMxYzL0VKB iszI0nzLc+PHqzyY3SwQ09zL8ivJRubMPaHKhbuX5oy2hUvMgAzL2PwRlLzBAyGQBBHMDwHISinL eeM7DsHMFFa85hE7FrOKahmO+wjFcbUWP5wREa0l+qyXm0ld9roW6uwRv2wYFj2b6aOZJyNk//zR 9VzQV+GgDh0UJ93SLv3SMB3TMj3T7/+zrSpNGzcNFDS9Hkm3aGLR0x8nd5RrcQKQcRpnoFInaT2n 1B6Rmzt9EQPFsmDkpFRB1VRtbay2oTVx1SXRdinB1QOa1SUBB3BgD2Rt1mUtE1f9bYzq1XOBrtmL QmCAz8tXfFqWfAHMvngdvnHtEDu0133KEH+dQ4Q91w/x1zZk2AKB2In91D7R1+PnvkUrtJM9ENkL vgaBwAhhtDr7tA0BvprLfFNLe+SUt7uXwFES2kI7EivtxscruvqReJ4EszWBu1FE2x3Lsi3hfyJI TWXMxryETWHbEmFb3GTbf7ux05j9Dw84uYOFIz4rEZy92jfyvJrNEKCdwEMb2RLIDwn/AbjpG8Sv SNtuDLqtLT5nq8HOndmwB9lflcFLa33xPd/sdRDN7b0APL6CW9+G298K7NhHE1mqe7W2PdsGntsn cbNvLLrHpLq/7RIKTimqa95imx4UDhSyfd5JwYOj5SDx11YXe+FEON7RFVDEK8fahCBPBNyw5X+l qysabhPstNxqkb2K+9//w6zGAh5iBYAKklZjBR7oksIYPVnxAYRiBcHwRMQzIeI1AeD+M9H6i8JU 7sKZCODwyuQxbsFQ3uU15a847uUmunlaPuAG3VhNyIRlvuXQsebAfeZLIeF0POds/hsL18UeSNdE 0sFSrteSC99ijj97Dsbz+85frNfq/90uLsW+fY4ade4SFJEyOkOYB3PHRKPK13zPHFEn+jwQuow/ 8koRzPw4nt4Ai2zqinzNqlzOH7HROKLpgS5AYNmX9FLrgnzpuH7KsE4Qn/4Q/LzHdLPRmDqHKtyQ o0iPyM48lRMyZk41LMmMA2MSlWPDlhrrKJ0TDvno9wOrjQ5B2v7t4B5A1h7rxjruIfGt5o4R4b7u 7H4a6e6q65qu7T7v9M7m724Q9S7j977v/N7v/r5h+c7u/z7wBN+qAa/DBY9h857w1n7wDv/wmcPw Eu8QGj7xDQbxGJ/xGm8bYbzxXD7uHh/yNyypIl/HFn/tY3jyYn7o77wRlpmntLljlP+J6zQvNzIP 0qFa8iuxZzwPa687W1dco+OtH2q6Z9VZnT0/a1qt87iR9A86pydhZwCKoE8vn1YfowY6cDJ69eu5 atf2Gv5O5sjUpiVRcvZAbAPXtQiC9mwvpGjPpfXp9EVeGSofZlzap0UNeGpmdE6tEFcX2P8Ack02 +FD2D4Rv+IWP1GeXchFX97xBE3Eqp2dvpsRm9mKvHwAKoBq0+eH5YZ4Pa28acCYx9Ux/G05v9fPJ +V9fp8S5Z4H2+lgaaKHPpnKK9iTu5qUfGevpn1mc+VNP+izh9VaKTKQPoFftpMAPbdwG1rnPGDTX +CjX9x7c/AXk+BSvrNYfnGSY/dz/3/0OUX2EixHxu7nePz5CZLIfToAZjmuQOuBFuIQJzrWvjbJS /X5JTP1o3uxKLOSbk360DRAAANgjWNAeEIRADNoTOJCgwIUFG0p0CNEeAQIEMRbk19HgxosZF4Ik KTLiSZQpVa5k2dLlS5gxZc6kWdPmTZsWGTpcqLPhQJ0IW/rk+ZPiToNGH/I0mFChRpEgLepEWhAY MIJXR5qcyhTnV7BhxY4lW9Ysy39p1a5lm1bg2p9wAajF+A9j3bZ55ap9y7bvz79z+/4DzFfw3LR4 8dq96xexW8SDIRuerNfyZcyZNW/m3NnzZ9ChRY8mDTom1aNLjyqFSTQiaqKsUwOu/1hbddXbt6nu tn3W92/gwYUPN4s6t+udRb2iRJ7Uq3HjuI/37urcunTeuYlv597d+/ew0Zt3VT60fHLoy5HDPl8d O1P30qtGB1/f/n38NTvHJcy/cun/JPNMMv8oM4zAhuRCEMG2CgTwQbXyk3BCCu2B8MDHACzsQg47 9PDDDisUcUQSSzTxRBRTVHEhEFt08UUYY5RxRhprtLGtFXPUcbgbe/TxR7Z2FHLIE4E08kgjHXAA yc0E/EcBKJkEkkgqU+zsASzTwvKBzgIIQLN88glNSTKXJM1LtpT8bIEFpHTzTTjj1AwmMgmq8yUv W8pzJijFaqCBhZSUqc8qCzV0xf/O/lRUUbXKVGtRLbnMMi0oo4RsMEsxQ5OtShVQq1O1vBQ11C83 BfWfTU2tlNJV5bzsUFhV7FJUWtuytNV/IE0r1S9R7dVAzMpU8x8y82Jz1143ZfNYZNdiltlRWf0x VmqrpQkibHnqVAGCIIDAoDsJ2pZbewiViQEGIkI30DLtdMBdcc2VTlB76N0zXmvz1ZdEb+3pt197 KKCAIIG7/bYggQsmeOCFAD433YUUNnhie9atGGJvHXbYHg44IKhj7TbeVyVXSzb51Zc2BnjlgwUQ wCAUULAnZoIwwKDmm+2xueGDV9p5oZ8pBvjnn/89mOaCXCZIaZ1zJgjpCU+Weur/km1ey+q0YNBa 67SwrqwvHMLGQUFgL3PS60sDq8zltNhG+x+b425bALYypvpuvPMObWS++/Y7Vr0DF/zNv4cc/HAm C1ccPMQbd/xxyG9cfHLKK8cvcswlt3xzzjv3/HPQQxd9dCszN/101FNXfXUaSXf99cJZl3122mu3 /fbPYNd9d9571x134IMXfnjiizc+Ld+TVx7245t33s3lo5d+elmft/567LOPkXr7tPf+Q+5n+n58 8stHPHwJzT8Sffbbd/99+OM3XH3667efdvnz11+s+/v3n/D9xe9/AyRgAQ14QAQmUIELZOCbCpSg tWxta2wRWwUriBmXsW0tGaRb/9oyJLgAkk6CEkwJbV5iwYKIzTm1WY7BesaSmEHtaTGEmQy7k8GF 4HApEylUA0vTmtgsJ244c9pKUEgQFSIxbAZJYg6Z1pIRFiSKUtQa0OIWNBdmDIojjCINayizgmjR IFyECRlXCB/UcPCJtJFNStS4QzS2MIQ9YU8cV9gSpwjlIHrcWkT6yLMXriRjGhukQXS4NKYd8o9/ PEleJrgWMESSLZEEw1rsdqBLbeaRj8yaBNXCyX9c8pIZFA0cTKkWNaJSgz60DCnZ4kpKtiWWmIml JP8xy4S0JZeTtKVm8giEf/wSkr2cZVpsCcH/aKaYc+ugKpsZTIRgsmytXOU/XP8JzV1i05kb7OAy PZPNPKolm6zMS2PYYk5zriWdlmlMOxWzGLrAMy3jxIw7GcMYAqhzMevUZz5Fw096jjOd9PRlNNmy y7ugEy8EtYpWaJKQgvySIBCdo0p4eMfkvIY+BrkKVuyhlY5CxSQFuYtG5XiSjvDDHin1SEo/ApKM otQjNbkoQVh605lOVI8xfUl/PujTTAYGMR21TEr/uZgECTWBMKFoU/TY1IjuNCUUlehHHcrRq1Lk pCbdYVej+hSRwpSkCUVLgwSEzExKMy0dvQpnjMqWtyb1LRDkp4LYuJlsyvUwPyWnWqWJ1rRehqhr ZWti5InPttTVMrtkrEEN60//u/6UrcDwDD8Bi9bBRlYzgAUqYu9pTs761TOZheBcnTRAmJR0K1rl 6kouCpixjlS1CwmpS2rK2q+WkD63XclsvYpbkep2q8Hdikh4aMKQjJSOw1VJU1260pvmbz9nXRDZ MoPWByo1L5nNDHfVwt3QBtYxfGWnPPm5zrfmJbzWtW5mJyvegzr2M3kdzIYOmFqYkpW2Dq0tS2ra RuSepL8s8W1stRqfmIq1wCtp6mPPCU9kypeg6q0uYSlr4baKV7ugQWaHHURAIAbYpLy1lmpne9yN MqeOyz2wQ0wsVteSB6Npw1Ba13vdwawzoX2lH23Ge2O9AHm6H8aMj9nr0w8a/xk9IhaujA8sXR5H ua8VpXKVGynlF1lZy1vmMuew/GUGdjlHYMabmM0sv9nRSs2bInObfRStzcCZLWpOS5jsfOe0CEtY ncHVp051Kj/falx91hSd1zLotdzZznlZ1J/SpOe2NFrST8oUqzxF6UrjaltpWVanO43pS4O6IKKi cmjknJli6QXOhFbLls7E5kNnqlZrmbWrTc2rX2Ha0oHe9T8KYmeCABu3bSxIuAhCaoMgW1jFptex 75XsZzs7AKN+trDPjBJFv8TYC6kUtad9EmTTNDrh3hKWClLuBxBkSzSxtj2s3e14kUtRBZm3tKH9 bXvUO99/wnaY2PUucNFrW/8Fgbe9IxJuC/3j059+lKNZOZNlu2RZKQk3wg2ybptMvLX71nejfxvi 1nac3/bQOMnZRBB903vkr6XPttvtbn8vmYUBBziLuXpbi+8PNFGqdLCGReHHMIrRDhcNqxXOrFw1 Oum6WhaHnQTBVBNrWLb+h62FvhahX/3q42VL050FLTThOtahpjWssa6rszfAzUE2LXlt1fO1oIsB jdLzsAZtdMuEFs5y7U9n6x51y7C6VXJXC+E721nOQjBap14L4EPprbpB/h+Epzy6yp5rtVyyLXvm +sNjokUxsiTnYSRkIIFLk4SdJPRyvxjrWe8vkbnk9QZ5fe0tFtOLpj5iCkv/WO8jYknJqyVhbBk+ 4vcKfAjkRfNtWX7mg792bqZSM81HvlpiqJdrhob6cPPa9f/hfe9nnzNyYwv5Y3h+5A/yalgkogth b3pDPtH9BhGjDtX4MtLDf4goOST9Y6+/Aamv02oL78sLsXG+5FO+5wON7SO/x0tAUZK87csM6rsk B2QLUKq+yINACVzACOKa9cOA8sOaa5I++EqLCXzAvLhA6OM+Eeyat8G+auq8w9tA0hC/tDhAGHzB EXzBAvQMUOIkHSTAmLGMIfyHIYxAD9xBtvjB7ytCFURB9dumtsjAI2vBy4BC60MBzbBCKozCtsBB zxBDzXPCtAi/GewMV8o+/zGswbbQwSPkJE9qCxZEwrBRiyE8wgv6Qg10pCryoz+co85gwTqkwyty wEFKwPBiIyHTDOkLLQg6P0nkws3QB0u8xCbUwldKw03kIBvMP9PzouWSjf7joKQxRSfCv5MQRYy6 Nld8xd3BwtGARVqsRVssEVmckVvsoVzsRe/ZRWAMRmEcRmIsRlj0RWTEHmPkjmR0lWV8RtghMTh6 DkYEDthqMeayuTMiNn2pxtMbsRX7LWlsRa9io41DH2mciHHkKd/4LyezrfRQDvW4xm9EMUYcrnvk DW5UMXn8Roxyx378OH60OXvURnQUj9gYyOBgOTR6CXoUx3AESIMUSHhsof+CNI+AZEdylEjcS7F6 fEeOZB8SY8iT2EeyIMlrAbCEPD0PS7KnG8Aie8kMacSWFK0TrMnCoEnqigwBnEmYVB9I7Emgk5Ga DA3T6jzskslLmUiNrEimXMdy1MeSjEfWypamnEpqnLmPg0rPGbKhvMmf7JCkbESyGUv7ckPjc8mf IksaBEu3w5Ds4qvEE8qj1Em1DKyx1B6Qw0qK5Eqx4K2HjDGgkEqInEet9Ee/PMeYusKvPLygXMsF abuwFK3S2rATdJ69xEqVzMa/3KjENEeWfMdhC0dydEjS9MdzvMin1Mds+cyIZLKrFB0+gztjQTpf wTwYWS+8mzM2W7VMsxT/r/u6NrlN3sRNtrxCwaNNTvnNS2M84izOywu7WcOxu1y6y3DO+lk0zAjO PPs5Gbk6WMPO5Qw1XMnL57w8+OIs7fQMQktOstML7vQ6vDPPGqOxIDmJlxO2gqMer7wMQhPPFglO r+PO68Q8NhNQ21zPf1hPBV3QMGkLALWMrUOWXIvQOnvQCxWTtJjQses1tmBQDG0SofTQvGjQ+1kz NlO68RyXF+G827TQSOGStbA1TyPQ5zw1TaNNx9sMqutQXdOMv4tOWlmIGkUJjLOHI3UJRYs5d6k5 vvwdVlrSvEC0KVVOzMA7dJPRZtxSLu1SL/1SMKUaaBzTLQtTMz1TNE1T/zVdUxchU9JhUzhtHDed U30xHc7iIhiwjERcQr34pXAyG0bsRPEzJUI9Jc7wU6dwQwi6P0+M0zmRCUqipIWAqj16CkYNMW9E TPJYjqaiqEj9VDCIiP5biVGd1KeSKqqiVDySKnsYVR2SVJW4v6/KI4syDqeY1V18MdmCMV0NK5lQ 1bBSrtkqMGIVCWCNiAWbKlZ9qV01iWGFsZYYMKvyqIbyKGktLuJ6VmjVKbByKmCaJ/nCQh1Dqp0E 12/VJs9IL7Z4r7UAJ/m6sQlrC++6DMVCy8p8jOM013XNsO/KsPUaVwfrJ11K1PiKJoL1PJd4LoN4 rmI1rpXEL+Vajaw8Pf+FPYlj3S9qJbBtrdSIoCiUNIjMsKxyRUubDFiBXQt25bp87at5Hazzwoui 7E+VrTDAild97S5+pU4jqytzeit15QzA8q7BwimWulmzgkyX7DscCUxaBEzR7MjDZKplzSiAJDZt LYmE0q/SrFU5cloWMknBxFZmpchtXE2mCKlrXTJg9Fqbyqm2VSmZ40xk3VbQ5FaOnUjV5NqXONYF Uy119MiUqFiNzFt+fNjQHEw5StsQ6gyC2qXLUqqVtbDE2idy5ckPEtoMq9e2xIx5NVpfu1vCdcrS DN2UUC1Vhaq6ZcqmpcrBdbLEFNtWRMk28i2/BdzkMs2TCkl7lNtvbFj/slVIp72jy9TcBToNwmxd rQRbhbyO1OCpzRzNbHzddcxbhuTdpvxY3iqbe23LmGXMXNxe9opZIgPU6vyryPyx7s27ySzZyFLL M8rMbWRN5FLN6qUj+1XMXYTNuN3I141Na7xHyxHRuDzL9FRKR7WRfJTMQE3gt4RLI1PfBWZgJAtU 8o3gfJzgBz7g0mDgvbpHDM5goKPgGEngqfGOfIxbE2JgFO7f8NFgF35hGEYtOp1hGq5hlPgyG85h HX6fGMaRHf5hIIafA6aQv8uPh5Q0bWsXlkC3iBg474icHR0fmLi7bqs7ldhPgpg9uYMY+9hPeMNi lCC10TOIbgO0Yoni/6MtkD2dQirtjC22vLQwvMKDY+/NDComu8i1HzlmQhfkQRtkiz2ePDp+QMnr vbUoPgScQs1A5KTMDDkO5Mu4JDizUCXMv5QQo0JyCUweGvbbP4PQPdp7Yy72tpWYvTly1Scq1fcT mdCzZFduVVSEZVV8v1cWJIdR5ZUQRVa05YMJvVbmv1ROJPlbCF22oZTw5KaZITAqiF0+REDKIv+D v/ib5RD65UssiGuOiCNiZmNmxSba5iZC5mRuCVFsopco5mX2L4uQQxC8DAckvzYEwxTMREqswnbu pDxNvwTEwzvMwX6+zA/MZ1YSvzz85w/8h3t2QUP04wLcUylMQDPsjP/lM0EKDL55jr4OKuixiUl8 tQhz1sbEFGduTueZsSGjWQhGYiR7+Gj83Z/bsr9hRqSX6T+RRuaLAr1eBhgWTkVAVOmU8KInrGeO VgtMTIuijmSL7sA1TsA15ETLkES2uESpluros6Zqeme0sSALWouIVqDmO8QYfGgwtNcKU0G7uaSu rkRLhGDqZF96Rp6SXuZdPolszmZ7sOuIWOOZoMddZkUcommiYT+onGvfCQ3xO2s+XWPGHFmr7iC2 caUChGrNSOuLdszJdML0zYtJFOr1IqV43izLrEHFVguw9mM+fmpNbCDxa+pnEmvXbuxO5KVKwmd8 fqTHbWC1gALd1t7/ySRUtfBt8rVngfbCzS1Zu73bmYBVWC2I5e7Uneojn6ZlWlxuglBu6kZu5war WzVVsFruTz3u3GqJ5SZdixUKSvXuSEIJiLpYb0WJ6zYI607vVW1v5AZv9A7VHYIvm2WmvhLZjpYM 84IsRO1Tx3LXbBpXyLqMP/2HybowvDrYeBLwAX+sw9KLetVc9+pcec2wzHpZCY+vCKfwky2vBG8g ekJwfwqocNWMdELxdi3wFU8dwIqtrMVaZo1YAZushXVb6IJbSqWoq6XxGncfN+HgtLgpDQOsGi9x Ag+nJSdebPLTKI+mC75g21HXomXxGl+gJ2+MBm/wDyZgBeryfCJh/wmuYB8j87pQ4ZZQ8yBmiS9f 4b89YTpl8zdf3B6Gkzvf8wrJcz//c0A3Hj4f9PwIdEM/dERPdEXvHy5b9NQhdEiP9Fh0dEOXdEuf HErPdE3fdE7vdE+HkEsP9eD4dFLnDFssdakRdVVfdVZHEVR/dctodVn/ClifklnXuVrXnFsnmVz3 xV139V4PdmHPnV93xWHX9WJPdl4/dmZv9kVXdpqg9Dl1dmqvdmu/dmzPdm3f9jNd9U+HdnCnklwM 95jgdm4nd3RPd1w398xQd7Bgd3gnMzKNd9Jwd3u/dwqhdzDFd37v967Ud1j3d4EfeIAveGnf4TAd eGU3+M1QeIcXYm6G95CHn3iKh0YYrniMX/iI7+GMv3Rm7/hj3HiRD3SQl/RaV/eRT3mVX/nWKXmb YHmYj3nrcXmar3mbv3mcz3mdR/dhB/dXt3eZD3qhH/oW2Xmjj/YWPHqEJ3o03UWmf1Slt+Gn9+Fh hL6oB4uAAAA7 ------=_NextPart_000_0007_01C775EA.400FE8D0-- From owner-ccamp@ops.ietf.org Tue Apr 03 06:24:27 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYgBf-000323-LZ for ccamp-archive@ietf.org; Tue, 03 Apr 2007 06:24:27 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYgBe-0005Vd-61 for ccamp-archive@ietf.org; Tue, 03 Apr 2007 06:24:27 -0400 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1HYg5M-000MkV-Bu for ccamp-data@psg.com; Tue, 03 Apr 2007 10:17:56 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.7 Received: from [212.23.3.140] (helo=pythagoras.zen.co.uk) by psg.com with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1HYg5J-000MkE-GK for ccamp@ops.ietf.org; Tue, 03 Apr 2007 10:17:55 +0000 Received: from [88.96.235.142] (helo=cortex.aria-networks.com) by pythagoras.zen.co.uk with esmtp (Exim 4.50) id 1HYg5H-0002jN-Tx for ccamp@ops.ietf.org; Tue, 03 Apr 2007 10:17:52 +0000 Received: from your029b8cecfe ([217.158.132.156] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 3 Apr 2007 11:17:48 +0100 Message-ID: <04ac01c775d9$525df1f0$0a23fea9@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Diego Caviglia" , "Dan Li" , "ccamp" , References: Subject: Re: Solicit the comments on LMP Data Channel Status I-D Date: Tue, 3 Apr 2007 11:16:23 +0100 Organization: Old Dog Consulting MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-OriginalArrivalTime: 03 Apr 2007 10:17:49.0624 (UTC) FILETIME=[54E8BB80:01C775D9] X-Originating-Pythagoras-IP: [88.96.235.142] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.2 (/) X-Scan-Signature: 3fbd9b434023f8abfcb1532abaec7a21 Hi Dimitri, If I understand you correctly, you are saying that only problems caused by the control plane should be detected and/or reported by the control plane. Is that what you said? If so, how do you account for using LMP to verify link configuration, or RSVP-TE to report data plane faults? But perhaps you are simply saying that the control plane should not be engineered to handle defects in the control plane (especially implementation defects). I would agree with you on that point, but I don't think that is what Dan is proposing. As far as I understand it, he is covering the case where the control plane cannot correctly tidy up after itself, or where there has been a misconfiguration through the management plane. Note that he is not proposing automatic correction of such situations, but rather a mechanism for detecting them and reporting them. A ----- Original Message ----- From: To: "Diego Caviglia" ; "Dan Li" ; "ccamp" Sent: Tuesday, April 03, 2007 10:57 AM Subject: Re: Solicit the comments on LMP Data Channel Status I-D > diego & dan > > "Since the error condition can arise from a variety of situations > (including > control plane failure and restart, management plane intervention, attempt > to clean up a partitioned control plane, etc.) we believe that it would be > useful to have optional extensions to LMP to detect and report the > problem. > Resolution of the problem remains an issue for the management plane." > > we have three classes of "errors" those outside scope of the CP, those > resulting from CP operations (bug-fixing/mis-use/mis-config/etc.) and > then those that are strictly specific to the LMP and operations > > only the latter shall be in-scope - all these circular dependencies we > are introducing in this control plane are just breaking one of the main > design principle of networks > > -> which are the remaining "situations" ? > > thanks, > -d. > > > "Diego Caviglia" > 03/04/2007 11:35 > > To: "Dan Li cc: "ccamp ""Farrel@smtpoutuk01.marconi.com, Adrian" PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "Julien Meuric ""Bardalai@smtpoutuk01.marconi.com, Snigdho" Subject: Re: Solicit the comments on LMP Data Channel > Status I-D > > > > Hi Dan, > as stated in Prague I think that the ID addresses a real problem. > > BR > > Diego > > > > Dan Li on 03/04/2007 10.47.58 > > To: ccamp > cc: "Deborah A. Brungard" , "Farrel, Adrian" > , Dimitri Papadimitriou > , Julien Meuric > , Diego Caviglia > , "Bardalai, Snigdho" > > > Subject: Solicit the comments on LMP Data Channel Status I-D > > Hi all, > > In Prague we saw three optical vendors stating that this I-D addresses a > real problem that they see in deployed networks. We also saw one operator > expressing interest in the work. > > To summarise the problem that we are addressing: > > Under some circumstances the opposite ends of data links may get into > mismatched states. For example, one end of the data link may be allocated > and cross-connected, while the other end is available for use. This > represents an error condition. > > The problem is particularly bad when the data link is a component link of > a > > bundle, because the problem cannot be detected from the TE advertisements. > Further, existing LMP mechanisms do not allow us to discover the problem. > > If left undetected and unresolved, the situation may lead to LSP setup > failures or to misconnection of LSPs. > > Since the error condition can arise from a variety of situations > (including > > control plane failure and restart, management plane intervention, attempt > to > clean up a partitioned control plane, etc.) we believe that it would be > useful to have optional extensions to LMP to detect and report the > problem. > > Resolution of the problem remains an issue for the management plane. > > We would like to hear from people who believe that this is or is not a > real > > problem in the network so that we can judge whether to ask the chairs to > make this a WG draft. > Best regards, > > > Dan Li > > Advanced Technology Department > Wireline Networking Business Unit > Huawei Technologies Co., LTD. > Huawei Base, Bantian, Longgang, > Shenzhen 518129 P.R.China > Tel: +86-755-28973237 > Fax: +86-755-28972935 > *************************************************************************************** > > This e-mail and its attachments contain confidential information from > HUAWEI, which is intended only for the person or entity whose address is > listed above. Any use of the information contained herein in any way > (including, but not limited to, total or partial disclosure, reproduction, > or dissemination) by persons other than the intended recipient(s) is > prohibited. If you receive this e-mail in error, please notify the sender > by phone or email immediately and delete it! > *************************************************************************************** > > > > > > > > > > > From owner-ccamp@ops.ietf.org Tue Apr 03 06:43:07 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYgTj-0002AN-29 for ccamp-archive@ietf.org; Tue, 03 Apr 2007 06:43:07 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HYgTg-0003pZ-R5 for ccamp-archive@ietf.org; Tue, 03 Apr 2007 06:43:06 -0400 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1HYgNF-000O3o-71 for ccamp-data@psg.com; Tue, 03 Apr 2007 10:36:25 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.7 Received: from [61.144.161.53] (helo=szxga01-in.huawei.com) by psg.com with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1HYgN5-000O3K-RY for ccamp@ops.ietf.org; Tue, 03 Apr 2007 10:36:23 +0000 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JFX00BWP3U8I2@szxga01-in.huawei.com> for ccamp@ops.ietf.org; Tue, 03 Apr 2007 18:30:08 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JFX00MPP3U7YZ@szxga01-in.huawei.com> for ccamp@ops.ietf.org; Tue, 03 Apr 2007 18:30:08 +0800 (CST) Received: from l37133 ([10.70.77.160]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JFX008IJ3U68M@szxml03-in.huawei.com> for ccamp@ops.ietf.org; Tue, 03 Apr 2007 18:30:07 +0800 (CST) Date: Tue, 03 Apr 2007 18:30:06 +0800 From: Dan Li Subject: Re: Solicit the comments on LMP Data Channel Status I-D To: Adrian Farrel , Diego Caviglia , ccamp , Dimitri.Papadimitriou@alcatel-lucent.be Message-id: <013801c775db$0c4032d0$a04d460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Mailer: Microsoft Outlook Express 6.00.2800.1409 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <04ac01c775d9$525df1f0$0a23fea9@your029b8cecfe> Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 33cc095b503da4365ce57c727e553cf1 Hi Dimitri, I think Adrian is right. In the draft section 1, it clearly states: "This document defines simple additions to the Link Management Protocol (LMP) [RFC4204] to provide a control plane tool that can assist in the location of stranded resources by allowing adjacent LSRs to confirm data channel statuses, and provides triggers for notifying the management plane if any discrepancies are found." We just want to report the mismatch issue, but not trying to do the automatic correction. Thanks, Dan ----- Original Message ----- From: "Adrian Farrel" To: "Diego Caviglia" ; "Dan Li" ; "ccamp" ; Sent: Tuesday, April 03, 2007 6:16 PM Subject: Re: Solicit the comments on LMP Data Channel Status I-D > Hi Dimitri, > > If I understand you correctly, you are saying that only problems caused by > the control plane should be detected and/or reported by the control plane. > Is that what you said? > > If so, how do you account for using LMP to verify link configuration, or > RSVP-TE to report data plane faults? > > But perhaps you are simply saying that the control plane should not be > engineered to handle defects in the control plane (especially implementation > defects). I would agree with you on that point, but I don't think that is > what Dan is proposing. As far as I understand it, he is covering the case > where the control plane cannot correctly tidy up after itself, or where > there has been a misconfiguration through the management plane. > > Note that he is not proposing automatic correction of such situations, but > rather a mechanism for detecting them and reporting them. > > A > ----- Original Message ----- > From: > To: "Diego Caviglia" ; "Dan Li" > ; "ccamp" > Sent: Tuesday, April 03, 2007 10:57 AM > Subject: Re: Solicit the comments on LMP Data Channel Status I-D > > > > diego & dan > > > > "Since the error condition can arise from a variety of situations > > (including > > control plane failure and restart, management plane intervention, attempt > > to clean up a partitioned control plane, etc.) we believe that it would be > > useful to have optional extensions to LMP to detect and report the > > problem. > > Resolution of the problem remains an issue for the management plane." > > > > we have three classes of "errors" those outside scope of the CP, those > > resulting from CP operations (bug-fixing/mis-use/mis-config/etc.) and > > then those that are strictly specific to the LMP and operations > > > > only the latter shall be in-scope - all these circular dependencies we > > are introducing in this control plane are just breaking one of the main > > design principle of networks > > > > -> which are the remaining "situations" ? > > > > thanks, > > -d. > > > > > > "Diego Caviglia" > > 03/04/2007 11:35 > > > > To: "Dan Li > cc: "ccamp > ""Farrel@smtpoutuk01.marconi.com, Adrian" > PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "Julien Meuric > ""Bardalai@smtpoutuk01.marconi.com, Snigdho" > Subject: Re: Solicit the comments on LMP Data Channel > > Status I-D > > > > > > > > Hi Dan, > > as stated in Prague I think that the ID addresses a real problem. > > > > BR > > > > Diego > > > > > > > > Dan Li on 03/04/2007 10.47.58 > > > > To: ccamp > > cc: "Deborah A. Brungard" , "Farrel, Adrian" > > , Dimitri Papadimitriou > > , Julien Meuric > > , Diego Caviglia > > , "Bardalai, Snigdho" > > > > > > Subject: Solicit the comments on LMP Data Channel Status I-D > > > > Hi all, > > > > In Prague we saw three optical vendors stating that this I-D addresses a > > real problem that they see in deployed networks. We also saw one operator > > expressing interest in the work. > > > > To summarise the problem that we are addressing: > > > > Under some circumstances the opposite ends of data links may get into > > mismatched states. For example, one end of the data link may be allocated > > and cross-connected, while the other end is available for use. This > > represents an error condition. > > > > The problem is particularly bad when the data link is a component link of > > a > > > > bundle, because the problem cannot be detected from the TE advertisements. > > Further, existing LMP mechanisms do not allow us to discover the problem. > > > > If left undetected and unresolved, the situation may lead to LSP setup > > failures or to misconnection of LSPs. > > > > Since the error condition can arise from a variety of situations > > (including > > > > control plane failure and restart, management plane intervention, attempt > > to > > clean up a partitioned control plane, etc.) we believe that it would be > > useful to have optional extensions to LMP to detect and report the > > problem. > > > > Resolution of the problem remains an issue for the management plane. > > > > We would like to hear from people who believe that this is or is not a > > real > > > > problem in the network so that we can judge whether to ask the chairs to > > make this a WG draft. > > Best regards, > > > > > > Dan Li > > > > Advanced Technology Department > > Wireline Networking Business Unit > > Huawei Technologies Co., LTD. > > Huawei Base, Bantian, Longgang, > > Shenzhen 518129 P.R.China > > Tel: +86-755-28973237 > > Fax: +86-755-28972935 > > *************************************************************************************** > > > > This e-mail and its attachments contain confidential information from > > HUAWEI, which is intended only for the person or entity whose address is > > listed above. Any use of the information contained herein in any way > > (including, but not limited to, total or partial disclosure, reproduction, > > or dissemination) by persons other than the intended recipient(s) is > > prohibited. If you receive this e-mail in error, please notify the sender > > by phone or email immediately and delete it! > > *************************************************************************************** > > > > > > > > > > > > > > > > > > > > > > > > > From owner-ccamp@ops.ietf.org Tue Apr 03 07:33:49 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYhGn-0000XR-6s for ccamp-archive@ietf.org; Tue, 03 Apr 2007 07:33:49 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYhGh-0008E9-JT for ccamp-archive@ietf.org; Tue, 03 Apr 2007 07:33:49 -0400 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1HYhA6-0001R8-CG for ccamp-data@psg.com; Tue, 03 Apr 2007 11:26:54 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.7 Received: from [193.180.251.60] (helo=mailgw3.ericsson.se) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63 (FreeBSD)) (envelope-from ) id 1HYhA2-0001Qn-GK for ccamp@ops.ietf.org; Tue, 03 Apr 2007 11:26:52 +0000 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id A6BFF20976 for ; Tue, 3 Apr 2007 13:26:38 +0200 (CEST) X-AuditID: c1b4fb3c-a9cedbb0000073d5-9c-461239ee8825 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 8CBFB2050B for ; Tue, 3 Apr 2007 13:26:38 +0200 (CEST) Received: from esealmw110.eemea.ericsson.se ([153.88.200.78]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Apr 2007 13:26:37 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 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: Solicit the comments on LMP Data Channel Status I-D Date: Tue, 3 Apr 2007 13:26:32 +0200 Message-ID: <0428AC48A879ED46A94F39D5665DF684057FBD@esealmw110.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Solicit the comments on LMP Data Channel Status I-D Thread-Index: Acd14u6HO4O7RXfiSCatlVHD5msiAA== From: "Diego Caviglia $GA/ERI$" To: X-OriginalArrivalTime: 03 Apr 2007 11:26:37.0944 (UTC) FILETIME=[F1945F80:01C775E2] X-Brightmail-Tracker: AAAAAA== Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: df9edf1223802dd4cf213867a3af6121 This was bounced. =20 D =20 > Hi Dimitri, > my understunding of the ID was that it tries to = 'synchronize' > the status of the timeslots that are facing the same link. > > Otherwise downstream NE can choose a timeslot that is not good for the > upstream node > > > NE-A NE-B > Timeslots Timeslots > 1-OK 1-OK > 2-OK 2-KO > 3-OK 3-OK > 4-OK 4-OK > > So NE-A can choose Timeslot 2 because it see it good while is not good = in > NE-B. I think that the reason wht timeslot 2 is not usable is out of = the > scope of the ID. > > BR > > Diego > > > > > > > Dimitri.Papadimitriou@alcatel-lucent.be on 03/04/2007 11.57.12 > > To: "Diego Caviglia" , Dan Li > , ccamp > cc: > > Subject: Re: Solicit the comments on LMP Data Channel Status I-D > > diego & dan > > "Since the error condition can arise from a variety of situations > (including > control plane failure and restart, management plane intervention, = attempt > to clean up a partitioned control plane, etc.) we believe that it = would be > useful to have optional extensions to LMP to detect and report the > problem. > Resolution of the problem remains an issue for the management plane." > > we have three classes of "errors" those outside scope of the CP, those > resulting from CP operations (bug-fixing/mis-use/mis-config/etc.) and > then those that are strictly specific to the LMP and operations > > only the latter shall be in-scope - all these circular dependencies we > are introducing in this control plane are just breaking one of the = main > design principle of networks > > -> which are the remaining "situations" ? > > thanks, > -d. > > > > > > "Diego Caviglia" > 03/04/2007 11:35 > > To: "Dan Li cc: "ccamp ""Farrel@smtpoutuk01.marconi.com, Adrian" PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "Julien Meuric ""Bardalai@smtpoutuk01.marconi.com, Snigdho" Subject: Re: Solicit the comments on LMP Data Channel > Status I-D > > > > Hi Dan, > as stated in Prague I think that the ID addresses a real = problem. > > BR > > Diego > > > > Dan Li on 03/04/2007 10.47.58 > > To: ccamp > cc: "Deborah A. Brungard" , "Farrel, Adrian" > , Dimitri Papadimitriou > , Julien Meuric > , Diego Caviglia > , "Bardalai, Snigdho" > > > Subject: Solicit the comments on LMP Data Channel Status I-D > > Hi all, > > In Prague we saw three optical vendors stating that this I-D addresses = a > real problem that they see in deployed networks. We also saw one = operator > expressing interest in the work. > > To summarise the problem that we are addressing: > > Under some circumstances the opposite ends of data links may get into > mismatched states. For example, one end of the data link may be = allocated > and cross-connected, while the other end is available for use. This > represents an error condition. > > The problem is particularly bad when the data link is a component link = of > a > > bundle, because the problem cannot be detected from the TE = advertisements. > Further, existing LMP mechanisms do not allow us to discover the = problem. > > If left undetected and unresolved, the situation may lead to LSP setup > failures or to misconnection of LSPs. > > Since the error condition can arise from a variety of situations > (including > > control plane failure and restart, management plane intervention, = attempt > to > clean up a partitioned control plane, etc.) we believe that it would = be > useful to have optional extensions to LMP to detect and report the > problem. > > Resolution of the problem remains an issue for the management plane. > > We would like to hear from people who believe that this is or is not a > real > > problem in the network so that we can judge whether to ask the chairs = to > make this a WG draft. > Best regards, > > > Dan Li > > Advanced Technology Department > Wireline Networking Business Unit > Huawei Technologies Co., LTD. > Huawei Base, Bantian, Longgang, > Shenzhen 518129 P.R.China > Tel: +86-755-28973237 > Fax: +86-755-28972935 > = *************************************************************************= ************** > > > This e-mail and its attachments contain confidential information from > HUAWEI, which is intended only for the person or entity whose address = is > listed above. Any use of the information contained herein in any way > (including, but not limited to, total or partial disclosure, = reproduction, > or dissemination) by persons other than the intended recipient(s) is > prohibited. If you receive this e-mail in error, please notify the = sender > by phone or email immediately and delete it! > = *************************************************************************= ************** > > > > > > > > > > > > > > > > > > From owner-ccamp@ops.ietf.org Tue Apr 03 09:32:25 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYj7Y-0003Fc-V6 for ccamp-archive@ietf.org; Tue, 03 Apr 2007 09:32:25 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HYj7U-00037s-7M for ccamp-archive@ietf.org; Tue, 03 Apr 2007 09:32:24 -0400 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1HYiyH-000A2X-1K for ccamp-data@psg.com; Tue, 03 Apr 2007 13:22:49 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00, DATE_IN_PAST_03_06 autolearn=ham version=3.1.7 Received: from [62.241.163.6] (helo=astro.systems.pipex.net) by psg.com with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1HYiyC-000A27-CF for ccamp@ops.ietf.org; Tue, 03 Apr 2007 13:22:47 +0000 Received: from pc6 (1Cust253.tnt6.lnd4.gbr.da.uu.net [62.188.135.253]) by astro.systems.pipex.net (Postfix) with SMTP id 97C02E000270; Tue, 3 Apr 2007 14:22:29 +0100 (BST) Message-ID: <044a01c775ea$64cb7180$0601a8c0@pc6> Reply-To: "tom.petch" From: "tom.petch" To: "Adrian Farrel" , Cc: "Brungard, Deborah A, ALABS" , "Ross Callon" , "Dave Ward" , "Scott Bradner" References: <0e5101c771f5$bf431800$ea138182@your029b8cecfe> <035601c77542$b2159a40$0601a8c0@pc6> <03f301c7754d$9fbd1890$0a23fea9@your029b8cecfe> Subject: Re: Draft liaison to ITU SG15 on process Date: Tue, 3 Apr 2007 10:42:34 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ba0ec39a747b7612d6a8ae66d1a873c Adrian Yes, a subtle change but for me, better. Tom Petch ----- Original Message ----- From: "Adrian Farrel" To: "tom.petch" ; Cc: "Brungard, Deborah A, ALABS" ; "Ross Callon" ; "Dave Ward" ; "Scott Bradner" Sent: Monday, April 02, 2007 7:37 PM Subject: Re: Draft liaison to ITU SG15 on process > Thanks Tom, > > How about if the relevant paragraph read... > > We appreciate your engagement with this process and we believe that it is to > the best interests of the industry and to all participants in both > bodies. The liaison process provides a mechanism to engage between the two > bodies, and it is clear that the earlier communication occurs, the less the > chance of misunderstanding or parallel development. > > In order to describe the IETF's view of the procedures and processes for > extending and varying IETF protocols, the IETF has recently published RFC > 4775 ("Procedures for Protocol Extensions and Variations"). In order to > describe the mechanisms by which other bodies can influence the development > of MPLS and GMPLS protocols, the IETF has just consented for publication > draft-andersson-rtg-gmpls-change-08.txt ("Change Process for Multiprotocol > Label Switching (MPLS) and Generalized MPLS (GMPLS) Protocols and > Procedures"). The net effect of these documents is to give the ITU-T clear > access into the IETF process and to commit the IETF to work with the ITU-T > to develop solutions to requirements that originate in the ITU-T. > > > Adrian > > ----- Original Message ----- > From: "tom.petch" > To: "Adrian Farrel" ; > Cc: "Brungard, Deborah A, ALABS" ; "Ross Callon" > ; "Dave Ward" ; "Scott Bradner" > > Sent: Monday, April 02, 2007 5:09 PM > Subject: Re: Draft liaison to ITU SG15 on process > > > > Adrian > > > > No doubt you are familiar with RFC4775, to which you refer, but I would > > suggest > > that it may not be of much assistance in this case. > > > > It is written in IETF-speak and, as such, may be impenetrable to those > > who are not already involved in the IETF, and, after spending much of the > > first > > eight > > pages telling people to find an AD/WG and submit an I-D, then mentions in > > passing that where a liaison exists, then that should be used; which is > > the case > > here. > > > > So I would suggest amending the reference to it, using it as an example of > > the > > IETF's wishes for other SDOs to engage but pointing out that, as it says, > > as > > long as we have a liaison, then that is the best place to engage; and as > > early > > in the process as possible. > > > > I think that the failures, such as they are, arise because of a tendency > > to > > produce the polished article, but too late, whereas a back of the fag > > packet a > > few months earlier would have been more productive. But this liaison may > > not be > > the right place to express more of that point of view than you are > > already > > doing. > > > > Tom Petch > > > > ----- Original Message ----- > > From: "Adrian Farrel" > > To: > > Cc: "Brungard, Deborah A, ALABS" ; "Ross Callon" > > ; "Dave Ward" ; "Scott Bradner" > > > > Sent: Thursday, March 29, 2007 1:21 PM > > Subject: Draft liaison to ITU SG15 on process > > > > > >> Hi, > >> > >> One of the larger issues raised by a recent liaison from ITU-T Study > >> Group > >> 15 is on process and how we can continue to build a better relationship > >> between SG15 and CCAMP. > >> > >> Here is a draft response. > >> > >> Comments please by end of April 5th. > >> > >> Thanks, > >> Adrian and Deborah > >> === > >> > >> To: ITU-T SG15 > >> From: IETF CCAMP > >> Cc: Yoichi Maeda, Stephen Trowbridge, Kam Lam, Scott Bradner, Ross > >> Callon, > >> Dave Ward > >> For Action > >> Deadline: 25th June 2007 > >> > >> Subject: Cooperative Relationship between ITU-T SG15 and CCAMP > >> > >> CCAMP thanks you for your liaison entitled "Liaison Statement to CCAMP > >> responding to ccamp liaison of 21 February 2007". The last paragraphs of > >> your liaison discuss the cooperative relationship between ITU-T SG15 and > >> the > >> IETF's CCAMP working group and we would like to respond to these issues > >> separate from the technical discussions. > >> > >> Over the last few years we have seen an increase in cooperation between > >> our > >> organisations, and we believe that this is to the considerable benefit of > >> the industry. CCAMP has regularly sent a liaison representative to ITU > >> plenary and interim meetings, and useful comments and feedback have been > >> received from these meetings as a result of review of IETF > >> Internet-Drafts > >> in progress. Additionally, Mr. Lyndon Ong has been allocated a regular > >> slot > >> on the CCAMP meeting agenda at each IETF meeting to update the working > >> group > >> on the progress of the ITU-T in areas of interest to CCAMP. > >> > >> While we consider that the free flow of information and the review > >> feedback > >> on CCAMP work to be very valuable, we are also conscious that the > >> mechanisms > >> of the ITU-T and IETF are very different. Therefore we make every attempt > >> to > >> avoid wasting your precious meeting time, and only ask for review when we > >> consider the material to be stable and pertinent. > >> > >> In your liaison, you say: > >> > >> ITU-T SG 15 has been relying on a collaborative relationship with > >> IETF ccamp to provide the protocol support for ASON. This > >> collaborative work should allow the industry to take advantage of > >> the different expertise in each of the Standards Development > >> Organizations. Q.14/15 has not developed protocol specific > >> Recommendations for ASON since 2003, based on an expected > >> collaborative technical relationship, in which IETF ccamp would > >> provide protocol solutions that fully meet the ITU-T ASON > >> requirements. > >> > >> We appreciate your engagement with this process and we believe that it is > >> to > >> the best interests of the industry and to all participants in both > >> bodies. In order to crystallise this process, the IETF has recently > >> published RFC 4775 ("Procedures for Protocol Extensions and Variations") > >> and > >> has just consented for publication > >> draft-andersson-rtg-gmpls-change-08.txt > >> ("Change Process for Multiprotocol Label Switching (MPLS) and Generalized > >> MPLS (GMPLS) Protocols and Procedures"). The net effect of these > >> documents > >> is to give the ITU-T clear access into the IETF process and to commit the > >> IETF to work with the ITU-T to develop solutions to requirements that > >> originate in the ITU-T. > >> > >> You state further: > >> > >> However, the effectiveness of this SDO liaison relationship could > >> be improved. > >> > >> We agree that there is always room for improvements on both sides. Some > >> issues will arise from differences in established behaviour within the > >> two > >> bodies, and we are always grateful when you point out opportunities to > >> improve the mechanisms that we have in place. Although neither the ITU-T > >> nor > >> the IETF is likely to make a major change to its operational procedures, > >> there are doubtless very many small areas where improvements could be > >> made. > >> > >> One such area of improvement might be to relax the communication style > >> and > >> mechanisms allowing a more free and rapid exchange of technical opinions > >> amongst the participants. Although this cannot replace the liaison > >> relationship as a means for exchanging the official and consented views > >> of > >> each body, we could gain a lot from increasing the level of discussion > >> rather than relying on the relatively infrequent use of liaison > >> statements. > >> We would welcome your suggestions on how to achieve this - the CCAMP > >> mailing > >> list remains open and might be a suitable vehicle for this type of > >> communication. > >> > >> As you go on to say: > >> > >> We observe that IETF ccamp has responded to some of the > >> technical issues raised by suggesting that the ITU-T participants > >> should provide input directly, to the work in ccamp. We agree > >> that having participants involved in both the ITU-T and IETF > >> improves the communication process. We would like to confirm > >> that this individual participation is not being suggested as a > >> substitute for the liaison relationship. A liaison statement or > >> ITU-T Recommendation represents the consensus of the members > >> of the ITU-T. An individual participating in the work of ccamp is > >> not authorized to represent or negotiate on behalf of the ITU-T. > >> > >> We understand the points you make. Nevertheless, we would like to > >> continue > >> to encourage individual participation. Individuals who are interested in > >> the > >> development rather than the review of protocol solutions would be well > >> advised to bring their ideas to CCAMP early in the process. In the same > >> way, > >> we would advise individuals interested in the work of the ITU-T to become > >> involved there and not to wait for the opportunity to review the material > >> when it is liaised to the IETF as it nears completion. > >> > >> You cite a specific area for improvement in your liaison, and we are > >> grateful for your attempt to isolate specifics since it is far more easy > >> to learn from examples than from general statements. > >> > >> One particular area for improvement of the liaison relationship is > >> communicating the disposition of ITU-T comments related to the > >> interpretation of ASON requirements. For example comments > >> provided on, draft-ietf-ccamp-gmpls-ason-routing-reqts-02 (now > >> RFC 4258) and draft-ietf-ccamp-gmpls-ason-routing eval-00 (now > >> RFC 4652) were not included in the published RFC and the rational > >> for this decision has not been communicated. > >> > >> We are disturbed by your identification of these specific concerns at > >> this > >> time in our communication. Due to the time that has lapsed since the > >> events > >> that you mention, it is hard to provide appropriate and definitive > >> discussion. > >> > >> We believe that the discussion of RFC 4258 and lack of response refers to > >> a > >> liaison received from SG15 in February 2004. Although the issues received > >> full discussion on an open mailing list and included comments from no > >> fewer > >> than seven regular Q14/15 participants, and although the design team that > >> produced the final text of the RFC included Q14/15 participants who could > >> have reported the agreement and rationale back to Q14/15, we agree that > >> it > >> would have been helpful to liaise the outcome of these discussions to you > >> direct. > >> > >> In a subsequent liaison (COM15-LS18) in April 2004, where you stated: > >> > >> Q.14/15 would like to thank the IETF CCAMP WG and > >> especially the members of the ASON Routing Requirements > >> Design Team for their efforts to understand and capture ASON > >> Routing Requirements for the future work in IETF. > >> > >> Q.14/15 would like to continue cooperative work with IETF, > >> extending this to the application of routing protocols to support > >> the ASON requirements. > >> > >> We interpreted these sentences to mean that you were aware of the > >> completion > >> of RFC4258 and that you were satisfied with the results. > >> > >> Review of the material that led to RFC 4652 was first liaised to CCAMP by > >> SG15 in May 2005 (COM 15-LS57-E) in response to a request for review > >> issued > >> by CCAMP earlier that same month. The liaison from SG15 was marked "For > >> Information" and our understanding of this label (as noted in section > >> 2.2.1.1.6 of RFC 4053) is that "The liaison statement is to inform the > >> addressee of something, and expects no response." In the light of the > >> current situation it would have been wise for the chairs to have > >> confirmed > >> that this was really the intended purpose of the liaison, but we should > >> note > >> that 50% of the author team for RFC 4652 were regular Q14/15 attendees > >> who > >> could have reported the status and decisions (albeit informally) to the > >> Question. > >> > >> Subsequent liaisons on the material of RFC 4652 included: > >> > >> November 2005 (Q12-14 Interim meeting-LS006-E) > >> "Q.14/15 ... strongly supports CCAMP's continued work to > >> address ASON requirements in the routing protocols." > >> > >> Your recent liaison concludes: > >> > >> ITU-T SG15 continues to be interested in providing clarification or > >> validation of IETF ccamp interpretation of the ASON requirements > >> and therefore request that in future any documents under > >> development that are potentially applicable to ASON be liaised so > >> that ITU-T can validate the documents against the ASON > >> requirements. > >> > >> We look forward to receiving your response and hope that we can > >> continue to build a cooperative and productive relationship between > >> ccamp and SG 15. > >> > >> While we cannot promise to send every piece of work that is potentially > >> applicable to ASON, we can and will liaise all work where there is a > >> definitive intention of applicability to ASON. > >> > >> CCAMP continues to be grateful to SG15 for its efforts to ensure that the > >> ASON architecture and requirements are correctly interpreted, and > >> appreciates that this will lead to protocol solutions that are of value > >> to > >> the industry. > >> > >> Best regards, > >> > >> Adrian Farrel and Deborah Brungard > >> Co-chairs, IETF CCAMP Working Group > >> > >> > >> > > > > > > > > > > > From owner-ccamp@ops.ietf.org Tue Apr 03 13:30:58 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYmqQ-0001au-Ee for ccamp-archive@ietf.org; Tue, 03 Apr 2007 13:30:58 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYmqO-0003da-VJ for ccamp-archive@ietf.org; Tue, 03 Apr 2007 13:30:58 -0400 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1HYmjF-00099i-4r for ccamp-data@psg.com; Tue, 03 Apr 2007 17:23:33 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=3.1.7 Received: from [62.23.212.165] (helo=smail.alcatel.fr) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63 (FreeBSD)) (envelope-from ) id 1HYmj8-00098o-6d for ccamp@ops.ietf.org; Tue, 03 Apr 2007 17:23:31 +0000 Received: from bemail05.netfr.alcatel.fr (bemail05.netfr.alcatel.fr [155.132.251.11]) by smail.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id l33HNHPP015751; Tue, 3 Apr 2007 19:23:17 +0200 In-Reply-To: <04ac01c775d9$525df1f0$0a23fea9@your029b8cecfe> To: "Adrian Farrel" Cc: "ccamp" , "Dan Li" , "Diego Caviglia" Subject: Re: Solicit the comments on LMP Data Channel Status I-D MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: Dimitri.Papadimitriou@alcatel-lucent.be Date: Tue, 3 Apr 2007 19:23:06 +0200 X-MIMETrack: Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 04/03/2007 19:23:09, Serialize complete at 04/03/2007 19:23:09 Content-Type: text/plain; charset="US-ASCII" X-Scanned-By: MIMEDefang 2.51 on 155.132.180.81 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.2 (/) X-Scan-Signature: d008c19e97860b8641c1851f84665a75 hi adrian i am simply pointing out that using LMP as a watch dog for signaling and routing components bug-fix is a non starter, and errors resulting from their mis-use but also the errors resulting from the concurrent control of the resource / component set falls into the same category we are left with errors resulting from de-synchronization of the CP status of data channels - in which condition - can this occur ? and in which condition there is no resulting information that can not be used to detect them ? referring to the draft 2.1 and 2.3 are errors due to the fact the CP is not in the chain and 2.2 is the fundamental reason for RSVP (soft state) so my question what remains ? thanks, -d. "Adrian Farrel" 03/04/2007 12:16 Please respond to "Adrian Farrel" To: "Diego Caviglia" , "Dan Li" , "ccamp" , Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL cc: Subject: Re: Solicit the comments on LMP Data Channel Status I-D Hi Dimitri, If I understand you correctly, you are saying that only problems caused by the control plane should be detected and/or reported by the control plane. Is that what you said? If so, how do you account for using LMP to verify link configuration, or RSVP-TE to report data plane faults? But perhaps you are simply saying that the control plane should not be engineered to handle defects in the control plane (especially implementation defects). I would agree with you on that point, but I don't think that is what Dan is proposing. As far as I understand it, he is covering the case where the control plane cannot correctly tidy up after itself, or where there has been a misconfiguration through the management plane. Note that he is not proposing automatic correction of such situations, but rather a mechanism for detecting them and reporting them. A ----- Original Message ----- From: To: "Diego Caviglia" ; "Dan Li" ; "ccamp" Sent: Tuesday, April 03, 2007 10:57 AM Subject: Re: Solicit the comments on LMP Data Channel Status I-D > diego & dan > > "Since the error condition can arise from a variety of situations > (including > control plane failure and restart, management plane intervention, attempt > to clean up a partitioned control plane, etc.) we believe that it would be > useful to have optional extensions to LMP to detect and report the > problem. > Resolution of the problem remains an issue for the management plane." > > we have three classes of "errors" those outside scope of the CP, those > resulting from CP operations (bug-fixing/mis-use/mis-config/etc.) and > then those that are strictly specific to the LMP and operations > > only the latter shall be in-scope - all these circular dependencies we > are introducing in this control plane are just breaking one of the main > design principle of networks > > -> which are the remaining "situations" ? > > thanks, > -d. > > > "Diego Caviglia" > 03/04/2007 11:35 > > To: "Dan Li cc: "ccamp ""Farrel@smtpoutuk01.marconi.com, Adrian" PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "Julien Meuric ""Bardalai@smtpoutuk01.marconi.com, Snigdho" Subject: Re: Solicit the comments on LMP Data Channel > Status I-D > > > > Hi Dan, > as stated in Prague I think that the ID addresses a real problem. > > BR > > Diego > > > > Dan Li on 03/04/2007 10.47.58 > > To: ccamp > cc: "Deborah A. Brungard" , "Farrel, Adrian" > , Dimitri Papadimitriou > , Julien Meuric > , Diego Caviglia > , "Bardalai, Snigdho" > > > Subject: Solicit the comments on LMP Data Channel Status I-D > > Hi all, > > In Prague we saw three optical vendors stating that this I-D addresses a > real problem that they see in deployed networks. We also saw one operator > expressing interest in the work. > > To summarise the problem that we are addressing: > > Under some circumstances the opposite ends of data links may get into > mismatched states. For example, one end of the data link may be allocated > and cross-connected, while the other end is available for use. This > represents an error condition. > > The problem is particularly bad when the data link is a component link of > a > > bundle, because the problem cannot be detected from the TE advertisements. > Further, existing LMP mechanisms do not allow us to discover the problem. > > If left undetected and unresolved, the situation may lead to LSP setup > failures or to misconnection of LSPs. > > Since the error condition can arise from a variety of situations > (including > > control plane failure and restart, management plane intervention, attempt > to > clean up a partitioned control plane, etc.) we believe that it would be > useful to have optional extensions to LMP to detect and report the > problem. > > Resolution of the problem remains an issue for the management plane. > > We would like to hear from people who believe that this is or is not a > real > > problem in the network so that we can judge whether to ask the chairs to > make this a WG draft. > Best regards, > > > Dan Li > > Advanced Technology Department > Wireline Networking Business Unit > Huawei Technologies Co., LTD. > Huawei Base, Bantian, Longgang, > Shenzhen 518129 P.R.China > Tel: +86-755-28973237 > Fax: +86-755-28972935 > *************************************************************************************** > > This e-mail and its attachments contain confidential information from > HUAWEI, which is intended only for the person or entity whose address is > listed above. Any use of the information contained herein in any way > (including, but not limited to, total or partial disclosure, reproduction, > or dissemination) by persons other than the intended recipient(s) is > prohibited. If you receive this e-mail in error, please notify the sender > by phone or email immediately and delete it! > *************************************************************************************** > > > > > > > > > > > From owner-ccamp@ops.ietf.org Tue Apr 03 13:34:53 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYmuD-0005Xo-Az for ccamp-archive@ietf.org; Tue, 03 Apr 2007 13:34:53 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYmuB-0004Vu-M8 for ccamp-archive@ietf.org; Tue, 03 Apr 2007 13:34:53 -0400 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1HYmoo-0009bu-Kr for ccamp-data@psg.com; Tue, 03 Apr 2007 17:29:18 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=3.1.7 Received: from [62.23.212.165] (helo=smail.alcatel.fr) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63 (FreeBSD)) (envelope-from ) id 1HYmoj-0009bG-1q; Tue, 03 Apr 2007 17:29:15 +0000 Received: from bemail05.netfr.alcatel.fr (bemail05.netfr.alcatel.fr [155.132.251.11]) by smail.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id l33HTHGF016977; Tue, 3 Apr 2007 19:29:17 +0200 In-Reply-To: <0428AC48A879ED46A94F39D5665DF684057FBD@esealmw110.eemea.ericsson.se> To: "Diego Caviglia $GA/ERI$" Cc: ccamp@ops.ietf.org, owner-ccamp@ops.ietf.org Subject: Re: Solicit the comments on LMP Data Channel Status I-D MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: Dimitri.Papadimitriou@alcatel-lucent.be Date: Tue, 3 Apr 2007 19:29:07 +0200 X-MIMETrack: Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 04/03/2007 19:29:10, Serialize complete at 04/03/2007 19:29:10 Content-Type: text/plain; charset="US-ASCII" X-Scanned-By: MIMEDefang 2.51 on 155.132.180.81 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.2 (/) X-Scan-Signature: bcd240e64c427d3d3617cfc704e7fd7f diego > I think that the reason wht timeslot 2 is not usable is out of the > scope of the ID. but this is kernel of the problem, the origin tells where the solution shall be targeted the i-d refers to the deletion case (2.2), fine but there is cleanup timeout interval to free resources in rsvp thanks, -d. "Diego Caviglia $GA/ERI$" Sent by: owner-ccamp@ops.ietf.org 03/04/2007 13:26 To: cc: Subject: Re: Solicit the comments on LMP Data Channel Status I-D This was bounced. D > Hi Dimitri, > my understunding of the ID was that it tries to 'synchronize' > the status of the timeslots that are facing the same link. > > Otherwise downstream NE can choose a timeslot that is not good for the > upstream node > > > NE-A NE-B > Timeslots Timeslots > 1-OK 1-OK > 2-OK 2-KO > 3-OK 3-OK > 4-OK 4-OK > > So NE-A can choose Timeslot 2 because it see it good while is not good in > NE-B. I think that the reason wht timeslot 2 is not usable is out of the > scope of the ID. > > BR > > Diego > > > > > > > Dimitri.Papadimitriou@alcatel-lucent.be on 03/04/2007 11.57.12 > > To: "Diego Caviglia" , Dan Li > , ccamp > cc: > > Subject: Re: Solicit the comments on LMP Data Channel Status I-D > > diego & dan > > "Since the error condition can arise from a variety of situations > (including > control plane failure and restart, management plane intervention, attempt > to clean up a partitioned control plane, etc.) we believe that it would be > useful to have optional extensions to LMP to detect and report the > problem. > Resolution of the problem remains an issue for the management plane." > > we have three classes of "errors" those outside scope of the CP, those > resulting from CP operations (bug-fixing/mis-use/mis-config/etc.) and > then those that are strictly specific to the LMP and operations > > only the latter shall be in-scope - all these circular dependencies we > are introducing in this control plane are just breaking one of the main > design principle of networks > > -> which are the remaining "situations" ? > > thanks, > -d. > > > > > > "Diego Caviglia" > 03/04/2007 11:35 > > To: "Dan Li cc: "ccamp ""Farrel@smtpoutuk01.marconi.com, Adrian" PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "Julien Meuric ""Bardalai@smtpoutuk01.marconi.com, Snigdho" Subject: Re: Solicit the comments on LMP Data Channel > Status I-D > > > > Hi Dan, > as stated in Prague I think that the ID addresses a real problem. > > BR > > Diego > > > > Dan Li on 03/04/2007 10.47.58 > > To: ccamp > cc: "Deborah A. Brungard" , "Farrel, Adrian" > , Dimitri Papadimitriou > , Julien Meuric > , Diego Caviglia > , "Bardalai, Snigdho" > > > Subject: Solicit the comments on LMP Data Channel Status I-D > > Hi all, > > In Prague we saw three optical vendors stating that this I-D addresses a > real problem that they see in deployed networks. We also saw one operator > expressing interest in the work. > > To summarise the problem that we are addressing: > > Under some circumstances the opposite ends of data links may get into > mismatched states. For example, one end of the data link may be allocated > and cross-connected, while the other end is available for use. This > represents an error condition. > > The problem is particularly bad when the data link is a component link of > a > > bundle, because the problem cannot be detected from the TE advertisements. > Further, existing LMP mechanisms do not allow us to discover the problem. > > If left undetected and unresolved, the situation may lead to LSP setup > failures or to misconnection of LSPs. > > Since the error condition can arise from a variety of situations > (including > > control plane failure and restart, management plane intervention, attempt > to > clean up a partitioned control plane, etc.) we believe that it would be > useful to have optional extensions to LMP to detect and report the > problem. > > Resolution of the problem remains an issue for the management plane. > > We would like to hear from people who believe that this is or is not a > real > > problem in the network so that we can judge whether to ask the chairs to > make this a WG draft. > Best regards, > > > Dan Li > > Advanced Technology Department > Wireline Networking Business Unit > Huawei Technologies Co., LTD. > Huawei Base, Bantian, Longgang, > Shenzhen 518129 P.R.China > Tel: +86-755-28973237 > Fax: +86-755-28972935 > *************************************************************************************** > > > This e-mail and its attachments contain confidential information from > HUAWEI, which is intended only for the person or entity whose address is > listed above. Any use of the information contained herein in any way > (including, but not limited to, total or partial disclosure, reproduction, > or dissemination) by persons other than the intended recipient(s) is > prohibited. If you receive this e-mail in error, please notify the sender > by phone or email immediately and delete it! > *************************************************************************************** > > > > > > > > > > > > > > > > > > From owner-ccamp@ops.ietf.org Tue Apr 03 15:40:59 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYosF-0004Y0-42 for ccamp-archive@ietf.org; Tue, 03 Apr 2007 15:40:59 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYosC-0000k5-JR for ccamp-archive@ietf.org; Tue, 03 Apr 2007 15:40:59 -0400 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1HYolQ-000LKr-18 for ccamp-data@psg.com; Tue, 03 Apr 2007 19:33:56 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.7 Received: from [216.82.250.83] (helo=mail120.messagelabs.com) by psg.com with smtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1HYolL-000LJl-Ub for ccamp@ops.ietf.org; Tue, 03 Apr 2007 19:33:54 +0000 X-VirusChecked: Checked X-Env-Sender: dbrungard@att.com X-Msg-Ref: server-15.tower-120.messagelabs.com!1175628828!10853602!1 X-StarScan-Version: 5.5.10.7.1; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 10993 invoked from network); 3 Apr 2007 19:33:49 -0000 Received: from unknown (HELO attrh9i.attrh.att.com) (134.24.146.4) by server-15.tower-120.messagelabs.com with SMTP; 3 Apr 2007 19:33:49 -0000 Received: from attrh.att.com (localhost [127.0.0.1]) by attrh9i.attrh.att.com (8.13.8/8.13.8) with ESMTP id l33JWqv8004808 for ; Tue, 3 Apr 2007 15:33:39 -0400 (EDT) Received: from OCCLUST04EVS1.ugd.att.com (ocst07.ugd.att.com [135.38.164.12]) by attrh9i.attrh.att.com (8.13.8/8.13.8) with ESMTP id l33JWPNR004481 for ; Tue, 3 Apr 2007 15:32:46 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: WG Last Call: draft-ietf-ccamp-lsp-stitching-05.txt Date: Tue, 3 Apr 2007 14:32:31 -0500 Message-ID: <449B2580D802A443A923DABF3EAB82AF0DE9793E@OCCLUST04EVS1.ugd.att.com> In-Reply-To: <449B2580D802A443A923DABF3EAB82AF0DBFBFC1@OCCLUST04EVS1.ugd.att.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WG Last Call: draft-ietf-ccamp-lsp-stitching-05.txt Thread-Index: AcdcXHewSpG5V5DISvameliNvsPlzgDBNCxgBbE9rSA= From: "BRUNGARD, DEBORAH A, ATTLABS" To: Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e This ends the WG Last Call. We'll forward it on to the IESG. Thanks, Deborah -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of BRUNGARD, DEBORAH A, ATTLABS Sent: Monday, March 05, 2007 3:08 PM To: ccamp@ops.ietf.org Subject: FW: I-D ACTION:draft-ietf-ccamp-lsp-stitching-05.txt=20 Hi, This is the start of the WG Last Call for this document. In consideration of the meeting week, we will extend the Last Call until March 30th. Please email the authors and the list with any comments, concerns or corrections. Thanks, Deborah and Adrian -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Thursday, March 01, 2007 6:50 PM To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org Subject: I-D ACTION:draft-ietf-ccamp-lsp-stitching-05.txt=20 A New Internet-Draft is available from the on-line Internet-Drafts=20 directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : Label Switched Path Stitching with Generalized Multiprotocol Label Switching Traffic Engineering (GMPLS TE) Author(s) : A. Ayyangar, et al. Filename : draft-ietf-ccamp-lsp-stitching-05.txt Pages : 19 Date : 2007-3-1 =09 In certain scenarios, there may be a need to combine together several Generalized Multi-Protocol Label Switching (GMPLS) Label Switched Paths (LSPs) such that a single end-to-end (e2e) LSP is realized and all traffic from one constituent LSP is switched onto the next LSP. We will refer to this as "LSP stitching", the key requirement being that a constituent LSP not be allocated to more than one e2e LSP. The constituent LSPs will be referred to as "LSP segments" (S-LSPs). This document describes extensions to the existing GMPLS signaling protocol (RSVP-TE) to establish e2e LSPs created from from S-LSPs, and describes how the LSPs can be managed using the GMPLS signaling and routing protocols. It may be possible to configure a GMPLS node to switch the traffic from an LSP for which it is the egress, to another LSP for which it is the ingress, without requiring any signaling or routing extensions whatsoever, completely transparent to other nodes. This will also result in LSP stitching in the data plane. However, this document does not cover this scenario of LSP stitching. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-lsp-stitching-05.tx t To remove yourself from the I-D Announcement list, send a message to=20 i-d-announce-request@ietf.org with the word unsubscribe in the body of=20 the message.=20 You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce=20 to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the=20 username "anonymous" and a password of your e-mail address. After=20 logging in, type "cd internet-drafts" and then=20 "get draft-ietf-ccamp-lsp-stitching-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html=20 or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ccamp-lsp-stitching-05.txt". =09 NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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 Apr 03 15:42:55 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYou7-0006Sn-2B for ccamp-archive@ietf.org; Tue, 03 Apr 2007 15:42:55 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYou5-00011t-Jn for ccamp-archive@ietf.org; Tue, 03 Apr 2007 15:42:55 -0400 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1HYooZ-000Lds-E8 for ccamp-data@psg.com; Tue, 03 Apr 2007 19:37:11 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.7 Received: from [216.82.241.195] (helo=mail121.messagelabs.com) by psg.com with smtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1HYooV-000Ldc-Lm for ccamp@ops.ietf.org; Tue, 03 Apr 2007 19:37:09 +0000 X-VirusChecked: Checked X-Env-Sender: dbrungard@att.com X-Msg-Ref: server-13.tower-121.messagelabs.com!1175629022!20994915!1 X-StarScan-Version: 5.5.10.7.1; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 21972 invoked from network); 3 Apr 2007 19:37:02 -0000 Received: from unknown (HELO attrh9i.attrh.att.com) (134.24.146.4) by server-13.tower-121.messagelabs.com with SMTP; 3 Apr 2007 19:37:02 -0000 Received: from attrh.att.com (localhost [127.0.0.1]) by attrh9i.attrh.att.com (8.13.8/8.13.8) with ESMTP id l33JaGFB007483 for ; Tue, 3 Apr 2007 15:37:00 -0400 (EDT) Received: from OCCLUST04EVS1.ugd.att.com (ocst07.ugd.att.com [135.38.164.12]) by attrh9i.attrh.att.com (8.13.8/8.13.8) with ESMTP id l33Ja0Ji007242 for ; Tue, 3 Apr 2007 15:36:02 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: WG Last Call: draft-ietf-ccamp-inter-domain-rsvp-te-05.txt Date: Tue, 3 Apr 2007 14:35:38 -0500 Message-ID: <449B2580D802A443A923DABF3EAB82AF0DE97951@OCCLUST04EVS1.ugd.att.com> In-Reply-To: <449B2580D802A443A923DABF3EAB82AF0DBFBFD0@OCCLUST04EVS1.ugd.att.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WG Last Call: draft-ietf-ccamp-inter-domain-rsvp-te-05.txt Thread-Index: AcdcQ2A5HC1vhlvXT9qiSetEzGkauwDHs39wBbE78SA= From: "BRUNGARD, DEBORAH A, ATTLABS" To: Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db This ends the WG Last Call. We'll forward it on to the IESG. Thanks, Deborah=20 -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of BRUNGARD, DEBORAH A, ATTLABS Sent: Monday, March 05, 2007 3:13 PM To: ccamp@ops.ietf.org Subject: WG Last Call: draft-ietf-ccamp-inter-domain-rsvp-te-05.txt=20 Hi, This is the start of the WG Last Call for this document. In consideration of the meeting week, we will extend the Last Call until March 30th. Please email the authors and the list with any comments, concerns, or corrections. Thanks, Deborah and Adrian -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Thursday, March 01, 2007 3:50 PM To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org Subject: I-D ACTION:draft-ietf-ccamp-inter-domain-rsvp-te-05.txt=20 A New Internet-Draft is available from the on-line Internet-Drafts=20 directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : Inter domain Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering - RSVP-TE extensions Author(s) : A. Ayyangar, et al. Filename : draft-ietf-ccamp-inter-domain-rsvp-te-05.txt Pages : 21 Date : 2007-3-1 =09 This document describes procedures and protocol extensions for the use of Resource ReserVation Protocol Traffic Engineering (RSVP-TE) signaling in Multiprotocol Label Switching Traffic Engineering (MPLS-TE) packet networks and Generalized MPLS (GMPLS) packet and non-packet networks to support the establishment and maintenance of Label Switched Paths that cross domain boundaries. For the purpose of this document, a domain is considered to be any collection of network elements within a common realm of address space or path computation responsibility. Examples of such domains include Autonomous Systems, IGP routing areas, and GMPLS overlay networks. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-inter-domain-rsvp-t e-05.txt To remove yourself from the I-D Announcement list, send a message to=20 i-d-announce-request@ietf.org with the word unsubscribe in the body of=20 the message.=20 You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce=20 to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the=20 username "anonymous" and a password of your e-mail address. After=20 logging in, type "cd internet-drafts" and then=20 "get draft-ietf-ccamp-inter-domain-rsvp-te-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html=20 or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ccamp-inter-domain-rsvp-te-05.txt". =09 NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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 Apr 03 15:45:49 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYowv-0001G7-Ta for ccamp-archive@ietf.org; Tue, 03 Apr 2007 15:45:49 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYowu-0002lK-EZ for ccamp-archive@ietf.org; Tue, 03 Apr 2007 15:45:49 -0400 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1HYori-000M10-3b for ccamp-data@psg.com; Tue, 03 Apr 2007 19:40:26 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.7 Received: from [216.82.241.195] (helo=mail121.messagelabs.com) by psg.com with smtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1HYorf-000Lzr-5H for ccamp@ops.ietf.org; Tue, 03 Apr 2007 19:40:24 +0000 X-VirusChecked: Checked X-Env-Sender: dbrungard@att.com X-Msg-Ref: server-14.tower-121.messagelabs.com!1175629221!11859781!1 X-StarScan-Version: 5.5.10.7.1; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 2668 invoked from network); 3 Apr 2007 19:40:21 -0000 Received: from unknown (HELO attrh9i.attrh.att.com) (134.24.146.4) by server-14.tower-121.messagelabs.com with SMTP; 3 Apr 2007 19:40:21 -0000 Received: from attrh.att.com (localhost [127.0.0.1]) by attrh9i.attrh.att.com (8.13.8/8.13.8) with ESMTP id l33Jcm2r009552 for ; Tue, 3 Apr 2007 15:38:52 -0400 (EDT) Received: from OCCLUST04EVS1.ugd.att.com (ocst07.ugd.att.com [135.38.164.12]) by attrh9i.attrh.att.com (8.13.8/8.13.8) with ESMTP id l33JcCSa009033 for ; Tue, 3 Apr 2007 15:38:12 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: WG Last Call:draft-ietf-ccamp-inter-domain-pd-path-comp-04.txt Date: Tue, 3 Apr 2007 14:37:37 -0500 Message-ID: <449B2580D802A443A923DABF3EAB82AF0DE97958@OCCLUST04EVS1.ugd.att.com> In-Reply-To: <449B2580D802A443A923DABF3EAB82AF0DBFBFE7@OCCLUST04EVS1.ugd.att.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WG Last Call:draft-ietf-ccamp-inter-domain-pd-path-comp-04.txt Thread-Index: AcdVMQhQaQPVOm4ASwG6m01z+u5DGAKMk3IABbEBAiA= From: "BRUNGARD, DEBORAH A, ATTLABS" To: Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b This ends the WG Last Call. We'll forward it on to the IESG. Thanks, Deborah -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of BRUNGARD, DEBORAH A, ATTLABS Sent: Monday, March 05, 2007 3:19 PM To: ccamp@ops.ietf.org Subject: WG Last Call:draft-ietf-ccamp-inter-domain-pd-path-comp-04.txt=20 Hi, This is the start of the WG Last Call for this document. In consideration of the meeting week, we will extend the Last Call until March 30th. Please email the authors and the list with any comments, concerns, or corrections. Thanks, Deborah and Adrian -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Tuesday, February 20, 2007 3:50 PM To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org Subject: I-D ACTION:draft-ietf-ccamp-inter-domain-pd-path-comp-04.txt=20 A New Internet-Draft is available from the on-line Internet-Drafts=20 directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : A Per-domain path computation method for=20 establishing Inter-domain Traffic=20 Engineering (TE) Label Switched Paths (LSPs) Author(s) : J. Vasseur, et al. Filename : draft-ietf-ccamp-inter-domain-pd-path-comp-04.txt Pages : 21 Date : 2007-2-20 =09 This document specifies a per-domain path computation technique for establishing inter-domain Traffic Engineering (TE) Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Label Switched Paths (LSPs). In this document a domain refers to a collection of network elements within a common sphere of address management or path computational responsibility such as IGP areas and Autonomous Systems. Per-domain computation applies where the full path of an inter-domain TE LSP cannot be or is not determined at the ingress node of the TE LSP, and is not signaled across domain boundaries. This is most likely to arise owing to TE visibility limitations. The signaling message indicates the destination and nodes up to the next domain boundary. It may also indicate further domain boundaries or domain identifiers. The path through each domain, possibly including the choice of exit point from the domain, must be determined within the domain. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-inter-domain-pd-pat h-comp-04.txt To remove yourself from the I-D Announcement list, send a message to=20 i-d-announce-request@ietf.org with the word unsubscribe in the body of=20 the message.=20 You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce=20 to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the=20 username "anonymous" and a password of your e-mail address. After=20 logging in, type "cd internet-drafts" and then=20 "get draft-ietf-ccamp-inter-domain-pd-path-comp-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html=20 or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ccamp-inter-domain-pd-path-comp-04.txt". =09 NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. From owner-ccamp@ops.ietf.org Wed Apr 04 03:15:37 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYziT-0004r6-My for ccamp-archive@ietf.org; Wed, 04 Apr 2007 03:15:37 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYziO-0002vq-0s for ccamp-archive@ietf.org; Wed, 04 Apr 2007 03:15:37 -0400 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1HYzYm-0008V5-GO for ccamp-data@psg.com; Wed, 04 Apr 2007 07:05:36 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.7 Received: from [193.180.251.62] (helo=mailgw4.ericsson.se) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63 (FreeBSD)) (envelope-from ) id 1HYzYg-0008UX-1Y; Wed, 04 Apr 2007 07:05:34 +0000 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id B099A21680; Wed, 4 Apr 2007 09:05:27 +0200 (CEST) X-AuditID: c1b4fb3e-af1edbb0000061ca-fd-46134e374c6c Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 9874A205A0; Wed, 4 Apr 2007 09:05:27 +0200 (CEST) Received: from esealmw110.eemea.ericsson.se ([153.88.200.78]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Apr 2007 09:05:27 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 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: Solicit the comments on LMP Data Channel Status I-D Date: Wed, 4 Apr 2007 09:05:25 +0200 Message-ID: <0428AC48A879ED46A94F39D5665DF6845C70E4@esealmw110.eemea.ericsson.se> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Solicit the comments on LMP Data Channel Status I-D Thread-Index: Acd2FZiVku/eYsR2Td+GteZ6/qJ33wAcY9oQ From: "Diego Caviglia $GA/ERI$" To: Cc: , X-OriginalArrivalTime: 04 Apr 2007 07:05:27.0538 (UTC) FILETIME=[9FB3ED20:01C77687] X-Brightmail-Tracker: AAAAAA== Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 515708a075ffdf0a79d1c83b601e2afd Hi Dimitri, there can an HW problem with the unit and some of its TS are = not good or for some reason that TS have been cross-connected by NMS for = error or may for testing at commissioning of the TNE and due to human = error have not been deleted and so on.... BR Diego -----Original Message----- From: Dimitri.Papadimitriou@alcatel-lucent.be = [mailto:Dimitri.Papadimitriou@alcatel-lucent.be]=20 Sent: marted=EC 3 aprile 2007 19.29 To: Diego Caviglia (GA/ERI) Cc: ccamp@ops.ietf.org; owner-ccamp@ops.ietf.org Subject: Re: Solicit the comments on LMP Data Channel Status I-D diego > I think that the reason wht timeslot 2 is not usable is out of the > scope of the ID. but this is kernel of the problem, the origin tells where the solution shall be targeted=20 the i-d refers to the deletion case (2.2), fine but there is cleanup=20 timeout interval to free resources in rsvp thanks, -d. "Diego Caviglia $GA/ERI$" Sent by: owner-ccamp@ops.ietf.org 03/04/2007 13:26 =20 To: cc:=20 Subject: Re: Solicit the comments on LMP Data Channel=20 Status I-D This was bounced. =20 D =20 > Hi Dimitri, > my understunding of the ID was that it tries to = 'synchronize' > the status of the timeslots that are facing the same link. > > Otherwise downstream NE can choose a timeslot that is not good for the > upstream node > > > NE-A NE-B > Timeslots Timeslots > 1-OK 1-OK > 2-OK 2-KO > 3-OK 3-OK > 4-OK 4-OK > > So NE-A can choose Timeslot 2 because it see it good while is not good = in > NE-B. I think that the reason wht timeslot 2 is not usable is out of=20 the > scope of the ID. > > BR > > Diego > > > > > > > Dimitri.Papadimitriou@alcatel-lucent.be on 03/04/2007 11.57.12 > > To: "Diego Caviglia" , Dan Li > , ccamp > cc: > > Subject: Re: Solicit the comments on LMP Data Channel Status I-D > > diego & dan > > "Since the error condition can arise from a variety of situations > (including > control plane failure and restart, management plane intervention,=20 attempt > to clean up a partitioned control plane, etc.) we believe that it = would=20 be > useful to have optional extensions to LMP to detect and report the > problem. > Resolution of the problem remains an issue for the management plane." > > we have three classes of "errors" those outside scope of the CP, those > resulting from CP operations (bug-fixing/mis-use/mis-config/etc.) and > then those that are strictly specific to the LMP and operations > > only the latter shall be in-scope - all these circular dependencies we > are introducing in this control plane are just breaking one of the = main > design principle of networks > > -> which are the remaining "situations" ? > > thanks, > -d. > > > > > > "Diego Caviglia" > 03/04/2007 11:35 > > To: "Dan Li cc: "ccamp ""Farrel@smtpoutuk01.marconi.com, Adrian" PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "Julien Meuric ""Bardalai@smtpoutuk01.marconi.com, Snigdho" Subject: Re: Solicit the comments on LMP Data Channel > Status I-D > > > > Hi Dan, > as stated in Prague I think that the ID addresses a real = problem. > > BR > > Diego > > > > Dan Li on 03/04/2007 10.47.58 > > To: ccamp > cc: "Deborah A. Brungard" , "Farrel, Adrian" > , Dimitri Papadimitriou > , Julien Meuric > , Diego Caviglia > , "Bardalai, Snigdho" > > > Subject: Solicit the comments on LMP Data Channel Status I-D > > Hi all, > > In Prague we saw three optical vendors stating that this I-D addresses = a > real problem that they see in deployed networks. We also saw one=20 operator > expressing interest in the work. > > To summarise the problem that we are addressing: > > Under some circumstances the opposite ends of data links may get into > mismatched states. For example, one end of the data link may be=20 allocated > and cross-connected, while the other end is available for use. This > represents an error condition. > > The problem is particularly bad when the data link is a component link = of > a > > bundle, because the problem cannot be detected from the TE=20 advertisements. > Further, existing LMP mechanisms do not allow us to discover the=20 problem. > > If left undetected and unresolved, the situation may lead to LSP setup > failures or to misconnection of LSPs. > > Since the error condition can arise from a variety of situations > (including > > control plane failure and restart, management plane intervention,=20 attempt > to > clean up a partitioned control plane, etc.) we believe that it would = be > useful to have optional extensions to LMP to detect and report the > problem. > > Resolution of the problem remains an issue for the management plane. > > We would like to hear from people who believe that this is or is not a > real > > problem in the network so that we can judge whether to ask the chairs = to > make this a WG draft. > Best regards, > > > Dan Li > > Advanced Technology Department > Wireline Networking Business Unit > Huawei Technologies Co., LTD. > Huawei Base, Bantian, Longgang, > Shenzhen 518129 P.R.China > Tel: +86-755-28973237 > Fax: +86-755-28972935 >=20 *************************************************************************= ************** > > > This e-mail and its attachments contain confidential information from > HUAWEI, which is intended only for the person or entity whose address = is > listed above. Any use of the information contained herein in any way > (including, but not limited to, total or partial disclosure,=20 reproduction, > or dissemination) by persons other than the intended recipient(s) is > prohibited. If you receive this e-mail in error, please notify the=20 sender > by phone or email immediately and delete it! >=20 *************************************************************************= ************** > > > > > > > > > > > > > > > > > > From owner-ccamp@ops.ietf.org Wed Apr 04 03:25:49 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYzsL-0006Fk-E4 for ccamp-archive@ietf.org; Wed, 04 Apr 2007 03:25:49 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYzsJ-0005Yh-UJ for ccamp-archive@ietf.org; Wed, 04 Apr 2007 03:25:49 -0400 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1HYzmJ-0009Yv-AG for ccamp-data@psg.com; Wed, 04 Apr 2007 07:19:35 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=3.1.7 Received: from [62.23.212.165] (helo=smail.alcatel.fr) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63 (FreeBSD)) (envelope-from ) id 1HYzmG-0009YZ-4G; Wed, 04 Apr 2007 07:19:33 +0000 Received: from bemail05.netfr.alcatel.fr (bemail05.netfr.alcatel.fr [155.132.251.11]) by smail.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id l347JX3C007166; Wed, 4 Apr 2007 09:19:33 +0200 In-Reply-To: <0428AC48A879ED46A94F39D5665DF6845C70E4@esealmw110.eemea.ericsson.se> To: "Diego Caviglia $GA/ERI$" Cc: ccamp@ops.ietf.org, owner-ccamp@ops.ietf.org Subject: RE: Solicit the comments on LMP Data Channel Status I-D MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: Dimitri.Papadimitriou@alcatel-lucent.be Date: Wed, 4 Apr 2007 09:19:25 +0200 X-MIMETrack: Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 04/04/2007 09:19:26, Serialize complete at 04/04/2007 09:19:26 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.51 on 155.132.180.81 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.2 (/) X-Scan-Signature: 40161b1d86420e0807d771943d981d25 hi diego not sure to understand, an automated control plane (at the end the purpose = of this WG) is used to control XC, and other related resource reservations now you state that there could be manual operations that fails ??? i think = this simply falls outside the scope of the WG, on the other hand if some=20 TS are unproper for cross-connection i assume the CP does not even take=20 them into account, as label are downstream assigned where is the issue ? thanks, - d. "Diego Caviglia $GA/ERI$" Sent by: owner-ccamp@ops.ietf.org 04/04/2007 09:05 =20 To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL cc: , Subject: RE: Solicit the comments on LMP Data Channel=20 Status I-D Hi Dimitri, there can an HW problem with the unit and some of its TS are=20 not good or for some reason that TS have been cross-connected by NMS for=20 error or may for testing at commissioning of the TNE and due to human=20 error have not been deleted and so on.... BR Diego -----Original Message----- From: Dimitri.Papadimitriou@alcatel-lucent.be=20 [mailto:Dimitri.Papadimitriou@alcatel-lucent.be]=20 Sent: marted=EC 3 aprile 2007 19.29 To: Diego Caviglia (GA/ERI) Cc: ccamp@ops.ietf.org; owner-ccamp@ops.ietf.org Subject: Re: Solicit the comments on LMP Data Channel Status I-D diego > I think that the reason wht timeslot 2 is not usable is out of the > scope of the ID. but this is kernel of the problem, the origin tells where the solution shall be targeted=20 the i-d refers to the deletion case (2.2), fine but there is cleanup=20 timeout interval to free resources in rsvp thanks, -d. "Diego Caviglia $GA/ERI$" Sent by: owner-ccamp@ops.ietf.org 03/04/2007 13:26 =20 To: cc:=20 Subject: Re: Solicit the comments on LMP Data Channel=20 Status I-D This was bounced. =20 D =20 > Hi Dimitri, > my understunding of the ID was that it tries to 'synchronize' > the status of the timeslots that are facing the same link. > > Otherwise downstream NE can choose a timeslot that is not good for the > upstream node > > > NE-A NE-B > Timeslots Timeslots > 1-OK 1-OK > 2-OK 2-KO > 3-OK 3-OK > 4-OK 4-OK > > So NE-A can choose Timeslot 2 because it see it good while is not good=20 in > NE-B. I think that the reason wht timeslot 2 is not usable is out of=20 the > scope of the ID. > > BR > > Diego > > > > > > > Dimitri.Papadimitriou@alcatel-lucent.be on 03/04/2007 11.57.12 > > To: "Diego Caviglia" , Dan Li > , ccamp > cc: > > Subject: Re: Solicit the comments on LMP Data Channel Status I-D > > diego & dan > > "Since the error condition can arise from a variety of situations > (including > control plane failure and restart, management plane intervention,=20 attempt > to clean up a partitioned control plane, etc.) we believe that it would=20 be > useful to have optional extensions to LMP to detect and report the > problem. > Resolution of the problem remains an issue for the management plane." > > we have three classes of "errors" those outside scope of the CP, those > resulting from CP operations (bug-fixing/mis-use/mis-config/etc.) and > then those that are strictly specific to the LMP and operations > > only the latter shall be in-scope - all these circular dependencies we > are introducing in this control plane are just breaking one of the main > design principle of networks > > -> which are the remaining "situations" ? > > thanks, > -d. > > > > > > "Diego Caviglia" > 03/04/2007 11:35 > > To: "Dan Li cc: "ccamp ""Farrel@smtpoutuk01.marconi.com, Adrian" PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "Julien Meuric ""Bardalai@smtpoutuk01.marconi.com, Snigdho" Subject: Re: Solicit the comments on LMP Data Channel > Status I-D > > > > Hi Dan, > as stated in Prague I think that the ID addresses a real problem. > > BR > > Diego > > > > Dan Li on 03/04/2007 10.47.58 > > To: ccamp > cc: "Deborah A. Brungard" , "Farrel, Adrian" > , Dimitri Papadimitriou > , Julien Meuric > , Diego Caviglia > , "Bardalai, Snigdho" > > > Subject: Solicit the comments on LMP Data Channel Status I-D > > Hi all, > > In Prague we saw three optical vendors stating that this I-D addresses a > real problem that they see in deployed networks. We also saw one=20 operator > expressing interest in the work. > > To summarise the problem that we are addressing: > > Under some circumstances the opposite ends of data links may get into > mismatched states. For example, one end of the data link may be=20 allocated > and cross-connected, while the other end is available for use. This > represents an error condition. > > The problem is particularly bad when the data link is a component link=20 of > a > > bundle, because the problem cannot be detected from the TE=20 advertisements. > Further, existing LMP mechanisms do not allow us to discover the=20 problem. > > If left undetected and unresolved, the situation may lead to LSP setup > failures or to misconnection of LSPs. > > Since the error condition can arise from a variety of situations > (including > > control plane failure and restart, management plane intervention,=20 attempt > to > clean up a partitioned control plane, etc.) we believe that it would be > useful to have optional extensions to LMP to detect and report the > problem. > > Resolution of the problem remains an issue for the management plane. > > We would like to hear from people who believe that this is or is not a > real > > problem in the network so that we can judge whether to ask the chairs to > make this a WG draft. > Best regards, > > > Dan Li > > Advanced Technology Department > Wireline Networking Business Unit > Huawei Technologies Co., LTD. > Huawei Base, Bantian, Longgang, > Shenzhen 518129 P.R.China > Tel: +86-755-28973237 > Fax: +86-755-28972935 >=20 ***************************************************************************= ************ > > > This e-mail and its attachments contain confidential information from > HUAWEI, which is intended only for the person or entity whose address is > listed above. Any use of the information contained herein in any way > (including, but not limited to, total or partial disclosure,=20 reproduction, > or dissemination) by persons other than the intended recipient(s) is > prohibited. If you receive this e-mail in error, please notify the=20 sender > by phone or email immediately and delete it! >=20 ***************************************************************************= ************ > > > > > > > > > > > > > > > > > > From owner-ccamp@ops.ietf.org Wed Apr 04 03:33:13 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYzzU-0004BB-RZ for ccamp-archive@ietf.org; Wed, 04 Apr 2007 03:33:12 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYzzT-0007uT-AC for ccamp-archive@ietf.org; Wed, 04 Apr 2007 03:33:12 -0400 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1HYzu9-000BFX-1p for ccamp-data@psg.com; Wed, 04 Apr 2007 07:27:41 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.7 Received: from [193.180.251.62] (helo=mailgw4.ericsson.se) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63 (FreeBSD)) (envelope-from ) id 1HYzu5-000BEp-OP; Wed, 04 Apr 2007 07:27:39 +0000 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id E19A42102C; Wed, 4 Apr 2007 09:27:35 +0200 (CEST) X-AuditID: c1b4fb3e-ae9ecbb0000061ca-c7-461353676db8 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id BBE8420522; Wed, 4 Apr 2007 09:27:35 +0200 (CEST) Received: from esealmw110.eemea.ericsson.se ([153.88.200.78]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Apr 2007 09:27:35 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 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: Solicit the comments on LMP Data Channel Status I-D Date: Wed, 4 Apr 2007 09:27:34 +0200 Message-ID: <0428AC48A879ED46A94F39D5665DF6845C7101@esealmw110.eemea.ericsson.se> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Solicit the comments on LMP Data Channel Status I-D Thread-Index: Acd2iabV0fQfGzGURP2UPyg2Svq+3AAAEQbg From: "Diego Caviglia $GA/ERI$" To: Cc: , X-OriginalArrivalTime: 04 Apr 2007 07:27:35.0384 (UTC) FILETIME=[B7292580:01C7768A] X-Brightmail-Tracker: AAAAAA== Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 65215b440f7ab00ca9514de4a7a89926 Hi Dimitri, If you are in a SONET/SDH environment I'm pretty sure you'll = use bidirectional LSP with upstream and downstream label set to the same = value. =20 In that condition labels are chosen by upstream node. Not sure to get your point. The possible failures I've highlighted in = my e-mail are already managed by CP. OSPF-TE will advertise that the = available bw of, say a STM4 with a 'broken' TS, is not 4 VC4 and 1 = VC4_4c but is 3 VC4 and 0 VC4_4c. The problem is that, for scalability = reason, it is not advertised which VC4 is not usable. In my understanding the ID tries to address that case, sharing = information about which TS is good and which is not at link level. Ciao Diego -----Original Message----- From: Dimitri.Papadimitriou@alcatel-lucent.be = [mailto:Dimitri.Papadimitriou@alcatel-lucent.be]=20 Sent: mercoled=EC 4 aprile 2007 9.19 To: Diego Caviglia (GA/ERI) Cc: ccamp@ops.ietf.org; owner-ccamp@ops.ietf.org Subject: RE: Solicit the comments on LMP Data Channel Status I-D hi diego not sure to understand, an automated control plane (at the end the = purpose=20 of this WG) is used to control XC, and other related resource = reservations now you state that there could be manual operations that fails ??? i = think=20 this simply falls outside the scope of the WG, on the other hand if some = TS are unproper for cross-connection i assume the CP does not even take=20 them into account, as label are downstream assigned where is the issue ? thanks, - d. "Diego Caviglia $GA/ERI$" Sent by: owner-ccamp@ops.ietf.org 04/04/2007 09:05 =20 To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL cc: , Subject: RE: Solicit the comments on LMP Data Channel=20 Status I-D Hi Dimitri, there can an HW problem with the unit and some of its TS are=20 not good or for some reason that TS have been cross-connected by NMS for = error or may for testing at commissioning of the TNE and due to human=20 error have not been deleted and so on.... BR Diego -----Original Message----- From: Dimitri.Papadimitriou@alcatel-lucent.be=20 [mailto:Dimitri.Papadimitriou@alcatel-lucent.be]=20 Sent: marted=EC 3 aprile 2007 19.29 To: Diego Caviglia (GA/ERI) Cc: ccamp@ops.ietf.org; owner-ccamp@ops.ietf.org Subject: Re: Solicit the comments on LMP Data Channel Status I-D diego > I think that the reason wht timeslot 2 is not usable is out of the > scope of the ID. but this is kernel of the problem, the origin tells where the solution shall be targeted=20 the i-d refers to the deletion case (2.2), fine but there is cleanup=20 timeout interval to free resources in rsvp thanks, -d. "Diego Caviglia $GA/ERI$" Sent by: owner-ccamp@ops.ietf.org 03/04/2007 13:26 =20 To: cc:=20 Subject: Re: Solicit the comments on LMP Data Channel=20 Status I-D This was bounced. =20 D =20 > Hi Dimitri, > my understunding of the ID was that it tries to = 'synchronize' > the status of the timeslots that are facing the same link. > > Otherwise downstream NE can choose a timeslot that is not good for the > upstream node > > > NE-A NE-B > Timeslots Timeslots > 1-OK 1-OK > 2-OK 2-KO > 3-OK 3-OK > 4-OK 4-OK > > So NE-A can choose Timeslot 2 because it see it good while is not good = in > NE-B. I think that the reason wht timeslot 2 is not usable is out of=20 the > scope of the ID. > > BR > > Diego > > > > > > > Dimitri.Papadimitriou@alcatel-lucent.be on 03/04/2007 11.57.12 > > To: "Diego Caviglia" , Dan Li > , ccamp > cc: > > Subject: Re: Solicit the comments on LMP Data Channel Status I-D > > diego & dan > > "Since the error condition can arise from a variety of situations > (including > control plane failure and restart, management plane intervention,=20 attempt > to clean up a partitioned control plane, etc.) we believe that it = would=20 be > useful to have optional extensions to LMP to detect and report the > problem. > Resolution of the problem remains an issue for the management plane." > > we have three classes of "errors" those outside scope of the CP, those > resulting from CP operations (bug-fixing/mis-use/mis-config/etc.) and > then those that are strictly specific to the LMP and operations > > only the latter shall be in-scope - all these circular dependencies we > are introducing in this control plane are just breaking one of the = main > design principle of networks > > -> which are the remaining "situations" ? > > thanks, > -d. > > > > > > "Diego Caviglia" > 03/04/2007 11:35 > > To: "Dan Li cc: "ccamp ""Farrel@smtpoutuk01.marconi.com, Adrian" PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "Julien Meuric ""Bardalai@smtpoutuk01.marconi.com, Snigdho" Subject: Re: Solicit the comments on LMP Data Channel > Status I-D > > > > Hi Dan, > as stated in Prague I think that the ID addresses a real = problem. > > BR > > Diego > > > > Dan Li on 03/04/2007 10.47.58 > > To: ccamp > cc: "Deborah A. Brungard" , "Farrel, Adrian" > , Dimitri Papadimitriou > , Julien Meuric > , Diego Caviglia > , "Bardalai, Snigdho" > > > Subject: Solicit the comments on LMP Data Channel Status I-D > > Hi all, > > In Prague we saw three optical vendors stating that this I-D addresses = a > real problem that they see in deployed networks. We also saw one=20 operator > expressing interest in the work. > > To summarise the problem that we are addressing: > > Under some circumstances the opposite ends of data links may get into > mismatched states. For example, one end of the data link may be=20 allocated > and cross-connected, while the other end is available for use. This > represents an error condition. > > The problem is particularly bad when the data link is a component link = of > a > > bundle, because the problem cannot be detected from the TE=20 advertisements. > Further, existing LMP mechanisms do not allow us to discover the=20 problem. > > If left undetected and unresolved, the situation may lead to LSP setup > failures or to misconnection of LSPs. > > Since the error condition can arise from a variety of situations > (including > > control plane failure and restart, management plane intervention,=20 attempt > to > clean up a partitioned control plane, etc.) we believe that it would = be > useful to have optional extensions to LMP to detect and report the > problem. > > Resolution of the problem remains an issue for the management plane. > > We would like to hear from people who believe that this is or is not a > real > > problem in the network so that we can judge whether to ask the chairs = to > make this a WG draft. > Best regards, > > > Dan Li > > Advanced Technology Department > Wireline Networking Business Unit > Huawei Technologies Co., LTD. > Huawei Base, Bantian, Longgang, > Shenzhen 518129 P.R.China > Tel: +86-755-28973237 > Fax: +86-755-28972935 >=20 *************************************************************************= ************** > > > This e-mail and its attachments contain confidential information from > HUAWEI, which is intended only for the person or entity whose address = is > listed above. Any use of the information contained herein in any way > (including, but not limited to, total or partial disclosure,=20 reproduction, > or dissemination) by persons other than the intended recipient(s) is > prohibited. If you receive this e-mail in error, please notify the=20 sender > by phone or email immediately and delete it! >=20 *************************************************************************= ************** > > > > > > > > > > > > > > > > > > From owner-ccamp@ops.ietf.org Wed Apr 04 03:47:48 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZ0Dc-0007VW-09 for ccamp-archive@ietf.org; Wed, 04 Apr 2007 03:47:48 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZ0Da-00047w-Ew for ccamp-archive@ietf.org; Wed, 04 Apr 2007 03:47:47 -0400 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1HZ072-000E8H-Bp for ccamp-data@psg.com; Wed, 04 Apr 2007 07:41:00 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=3.1.7 Received: from [62.23.212.165] (helo=smail.alcatel.fr) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63 (FreeBSD)) (envelope-from ) id 1HZ06z-000E7v-O2; Wed, 04 Apr 2007 07:40:59 +0000 Received: from bemail05.netfr.alcatel.fr (bemail05.netfr.alcatel.fr [155.132.251.11]) by smail.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id l347f1vF022556; Wed, 4 Apr 2007 09:41:01 +0200 In-Reply-To: <0428AC48A879ED46A94F39D5665DF6845C7101@esealmw110.eemea.ericsson.se> To: "Diego Caviglia $GA/ERI$" Cc: ccamp@ops.ietf.org, owner-ccamp@ops.ietf.org Subject: RE: Solicit the comments on LMP Data Channel Status I-D MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: Dimitri.Papadimitriou@alcatel-lucent.be Date: Wed, 4 Apr 2007 09:40:53 +0200 X-MIMETrack: Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 04/04/2007 09:40:54, Serialize complete at 04/04/2007 09:40:54 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.51 on 155.132.180.81 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.2 (/) X-Scan-Signature: 8eeb555810cda1f2c5989480370dc4ca diego what you are stating is that changing the CP state of some local resources = (at granularity not advertized to neighbors via routing) MAY require=20 re-sync with neighbors such as to prevent label mismatch in case you are=20 enforcing same label in both directions=20 but we have already the min/max reservable subobject in LMP (hence it is a = pure TS mismatch that you try to detect)=20 on the other side: as TS where not visible to LMP i fail to see why do not re-sync label=20 space that can be used via signaling on the upstream node then ? in case of explicit label routing your technique won't work anyway thanks, - d. "Diego Caviglia $GA/ERI$" Sent by: owner-ccamp@ops.ietf.org 04/04/2007 09:27 =20 To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL cc: , Subject: RE: Solicit the comments on LMP Data Channel=20 Status I-D Hi Dimitri, If you are in a SONET/SDH environment I'm pretty sure you'll=20 use bidirectional LSP with upstream and downstream label set to the same=20 value.=20 In that condition labels are chosen by upstream node. Not sure to get your point. The possible failures I've highlighted in my=20 e-mail are already managed by CP. OSPF-TE will advertise that the=20 available bw of, say a STM4 with a 'broken' TS, is not 4 VC4 and 1 VC4=5F4c= =20 but is 3 VC4 and 0 VC4=5F4c. The problem is that, for scalability reason, = it is not advertised which VC4 is not usable. In my understanding the ID tries to address that case, sharing information = about which TS is good and which is not at link level. Ciao Diego -----Original Message----- From: Dimitri.Papadimitriou@alcatel-lucent.be=20 [mailto:Dimitri.Papadimitriou@alcatel-lucent.be]=20 Sent: mercoled=EC 4 aprile 2007 9.19 To: Diego Caviglia (GA/ERI) Cc: ccamp@ops.ietf.org; owner-ccamp@ops.ietf.org Subject: RE: Solicit the comments on LMP Data Channel Status I-D hi diego not sure to understand, an automated control plane (at the end the purpose = of this WG) is used to control XC, and other related resource reservations now you state that there could be manual operations that fails ??? i think = this simply falls outside the scope of the WG, on the other hand if some=20 TS are unproper for cross-connection i assume the CP does not even take=20 them into account, as label are downstream assigned where is the issue ? thanks, - d. "Diego Caviglia $GA/ERI$" Sent by: owner-ccamp@ops.ietf.org 04/04/2007 09:05 =20 To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL cc: , Subject: RE: Solicit the comments on LMP Data Channel=20 Status I-D Hi Dimitri, there can an HW problem with the unit and some of its TS are=20 not good or for some reason that TS have been cross-connected by NMS for=20 error or may for testing at commissioning of the TNE and due to human=20 error have not been deleted and so on.... BR Diego -----Original Message----- From: Dimitri.Papadimitriou@alcatel-lucent.be=20 [mailto:Dimitri.Papadimitriou@alcatel-lucent.be]=20 Sent: marted=EC 3 aprile 2007 19.29 To: Diego Caviglia (GA/ERI) Cc: ccamp@ops.ietf.org; owner-ccamp@ops.ietf.org Subject: Re: Solicit the comments on LMP Data Channel Status I-D diego > I think that the reason wht timeslot 2 is not usable is out of the > scope of the ID. but this is kernel of the problem, the origin tells where the solution shall be targeted=20 the i-d refers to the deletion case (2.2), fine but there is cleanup=20 timeout interval to free resources in rsvp thanks, -d. "Diego Caviglia $GA/ERI$" Sent by: owner-ccamp@ops.ietf.org 03/04/2007 13:26 =20 To: cc:=20 Subject: Re: Solicit the comments on LMP Data Channel=20 Status I-D This was bounced. =20 D =20 > Hi Dimitri, > my understunding of the ID was that it tries to 'synchronize' > the status of the timeslots that are facing the same link. > > Otherwise downstream NE can choose a timeslot that is not good for the > upstream node > > > NE-A NE-B > Timeslots Timeslots > 1-OK 1-OK > 2-OK 2-KO > 3-OK 3-OK > 4-OK 4-OK > > So NE-A can choose Timeslot 2 because it see it good while is not good=20 in > NE-B. I think that the reason wht timeslot 2 is not usable is out of=20 the > scope of the ID. > > BR > > Diego > > > > > > > Dimitri.Papadimitriou@alcatel-lucent.be on 03/04/2007 11.57.12 > > To: "Diego Caviglia" , Dan Li > , ccamp > cc: > > Subject: Re: Solicit the comments on LMP Data Channel Status I-D > > diego & dan > > "Since the error condition can arise from a variety of situations > (including > control plane failure and restart, management plane intervention,=20 attempt > to clean up a partitioned control plane, etc.) we believe that it would=20 be > useful to have optional extensions to LMP to detect and report the > problem. > Resolution of the problem remains an issue for the management plane." > > we have three classes of "errors" those outside scope of the CP, those > resulting from CP operations (bug-fixing/mis-use/mis-config/etc.) and > then those that are strictly specific to the LMP and operations > > only the latter shall be in-scope - all these circular dependencies we > are introducing in this control plane are just breaking one of the main > design principle of networks > > -> which are the remaining "situations" ? > > thanks, > -d. > > > > > > "Diego Caviglia" > 03/04/2007 11:35 > > To: "Dan Li cc: "ccamp ""Farrel@smtpoutuk01.marconi.com, Adrian" PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "Julien Meuric ""Bardalai@smtpoutuk01.marconi.com, Snigdho" Subject: Re: Solicit the comments on LMP Data Channel > Status I-D > > > > Hi Dan, > as stated in Prague I think that the ID addresses a real problem. > > BR > > Diego > > > > Dan Li on 03/04/2007 10.47.58 > > To: ccamp > cc: "Deborah A. Brungard" , "Farrel, Adrian" > , Dimitri Papadimitriou > , Julien Meuric > , Diego Caviglia > , "Bardalai, Snigdho" > > > Subject: Solicit the comments on LMP Data Channel Status I-D > > Hi all, > > In Prague we saw three optical vendors stating that this I-D addresses a > real problem that they see in deployed networks. We also saw one=20 operator > expressing interest in the work. > > To summarise the problem that we are addressing: > > Under some circumstances the opposite ends of data links may get into > mismatched states. For example, one end of the data link may be=20 allocated > and cross-connected, while the other end is available for use. This > represents an error condition. > > The problem is particularly bad when the data link is a component link=20 of > a > > bundle, because the problem cannot be detected from the TE=20 advertisements. > Further, existing LMP mechanisms do not allow us to discover the=20 problem. > > If left undetected and unresolved, the situation may lead to LSP setup > failures or to misconnection of LSPs. > > Since the error condition can arise from a variety of situations > (including > > control plane failure and restart, management plane intervention,=20 attempt > to > clean up a partitioned control plane, etc.) we believe that it would be > useful to have optional extensions to LMP to detect and report the > problem. > > Resolution of the problem remains an issue for the management plane. > > We would like to hear from people who believe that this is or is not a > real > > problem in the network so that we can judge whether to ask the chairs to > make this a WG draft. > Best regards, > > > Dan Li > > Advanced Technology Department > Wireline Networking Business Unit > Huawei Technologies Co., LTD. > Huawei Base, Bantian, Longgang, > Shenzhen 518129 P.R.China > Tel: +86-755-28973237 > Fax: +86-755-28972935 >=20 ***************************************************************************= ************ > > > This e-mail and its attachments contain confidential information from > HUAWEI, which is intended only for the person or entity whose address is > listed above. Any use of the information contained herein in any way > (including, but not limited to, total or partial disclosure,=20 reproduction, > or dissemination) by persons other than the intended recipient(s) is > prohibited. If you receive this e-mail in error, please notify the=20 sender > by phone or email immediately and delete it! >=20 ***************************************************************************= ************ > > > > > > > > > > > > > > > > > > From owner-ccamp@ops.ietf.org Wed Apr 04 04:38:55 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZ115-0001ei-CN for ccamp-archive@ietf.org; Wed, 04 Apr 2007 04:38:55 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZ113-00059g-VC for ccamp-archive@ietf.org; Wed, 04 Apr 2007 04:38:55 -0400 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1HZ0tV-000IEc-3L for ccamp-data@psg.com; Wed, 04 Apr 2007 08:31:05 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00,SPF_SOFTFAIL autolearn=no version=3.1.7 Received: from [195.101.245.15] (helo=p-mail1.rd.francetelecom.com) by psg.com with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1HZ0tR-000IED-VE for ccamp@ops.ietf.org; Wed, 04 Apr 2007 08:31:03 +0000 Received: from FTRDMEL2.rd.francetelecom.fr ([10.193.117.153]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Apr 2007 10:30:59 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Solicit the comments on LMP Data Channel Status I-D Date: Wed, 4 Apr 2007 10:30:58 +0200 Message-ID: <7DBAFEC6A76F3E42817DF1EBE64CB02604701A9B@FTRDMEL2.rd.francetelecom.fr> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Solicit the comments on LMP Data Channel Status I-D Thread-Index: Acd2kfHHzLqTSMKVSUKSbxrlqoHYVAAALgbg References: <0428AC48A879ED46A94F39D5665DF684057FBD@esealmw110.eemea.ericsson.se> From: "MEURIC Julien RD-CORE-LAN" To: , "Diego Caviglia $GA/ERI$" Cc: X-OriginalArrivalTime: 04 Apr 2007 08:30:59.0040 (UTC) FILETIME=[9250FE00:01C77693] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: bf422c85703d3d847fb014987125ac48 Hi Dimitri. I agree case 2.2 might be borderline: this single specific case may be not enough to trigger the proposed solution, but since there are other drivers, the mechanism introduced could help solving that issue also. Cheers, Julien -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Dimitri.Papadimitriou@alcatel-lucent.be diego > I think that the reason wht timeslot 2 is not usable is out of the > scope of the ID. but this is kernel of the problem, the origin tells where the solution shall be targeted=20 the i-d refers to the deletion case (2.2), fine but there is cleanup=20 timeout interval to free resources in rsvp thanks, -d. "Diego Caviglia $GA/ERI$" This was bounced. =20 D =20 > Hi Dimitri, > my understunding of the ID was that it tries to 'synchronize' > the status of the timeslots that are facing the same link. > > Otherwise downstream NE can choose a timeslot that is not good for the > upstream node > > > NE-A NE-B > Timeslots Timeslots > 1-OK 1-OK > 2-OK 2-KO > 3-OK 3-OK > 4-OK 4-OK > > So NE-A can choose Timeslot 2 because it see it good while is not good in > NE-B. I think that the reason wht timeslot 2 is not usable is out of=20 the > scope of the ID. > > BR > > Diego > > > > > > > Dimitri.Papadimitriou@alcatel-lucent.be on 03/04/2007 11.57.12 > > diego & dan > > "Since the error condition can arise from a variety of situations > (including > control plane failure and restart, management plane intervention,=20 attempt > to clean up a partitioned control plane, etc.) we believe that it would=20 be > useful to have optional extensions to LMP to detect and report the > problem. > Resolution of the problem remains an issue for the management plane." > > we have three classes of "errors" those outside scope of the CP, those > resulting from CP operations (bug-fixing/mis-use/mis-config/etc.) and > then those that are strictly specific to the LMP and operations > > only the latter shall be in-scope - all these circular dependencies we > are introducing in this control plane are just breaking one of the main > design principle of networks > > -> which are the remaining "situations" ? > > thanks, > -d. > > > > > > "Diego Caviglia" > > Hi Dan, > as stated in Prague I think that the ID addresses a real problem. > > BR > > Diego > > > > Dan Li on 03/04/2007 10.47.58 > > > Subject: Solicit the comments on LMP Data Channel Status I-D > > Hi all, > > In Prague we saw three optical vendors stating that this I-D addresses a > real problem that they see in deployed networks. We also saw one=20 operator > expressing interest in the work. > > To summarise the problem that we are addressing: > > Under some circumstances the opposite ends of data links may get into > mismatched states. For example, one end of the data link may be=20 allocated > and cross-connected, while the other end is available for use. This > represents an error condition. > > The problem is particularly bad when the data link is a component link of > a > > bundle, because the problem cannot be detected from the TE=20 advertisements. > Further, existing LMP mechanisms do not allow us to discover the=20 problem. > > If left undetected and unresolved, the situation may lead to LSP setup > failures or to misconnection of LSPs. > > Since the error condition can arise from a variety of situations > (including > > control plane failure and restart, management plane intervention,=20 attempt > to > clean up a partitioned control plane, etc.) we believe that it would be > useful to have optional extensions to LMP to detect and report the > problem. > > Resolution of the problem remains an issue for the management plane. > > We would like to hear from people who believe that this is or is not a > real > > problem in the network so that we can judge whether to ask the chairs to > make this a WG draft. > Best regards, > > > Dan Li > > Advanced Technology Department > Wireline Networking Business Unit > Huawei Technologies Co., LTD. > Huawei Base, Bantian, Longgang, > Shenzhen 518129 P.R.China > Tel: +86-755-28973237 > Fax: +86-755-28972935 From owner-ccamp@ops.ietf.org Wed Apr 04 04:50:49 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZ1Cb-0005xw-UP for ccamp-archive@ietf.org; Wed, 04 Apr 2007 04:50:49 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZ1CP-0002Gy-SD for ccamp-archive@ietf.org; Wed, 04 Apr 2007 04:50:49 -0400 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1HZ173-000JLi-2a for ccamp-data@psg.com; Wed, 04 Apr 2007 08:45:05 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00,SPF_SOFTFAIL autolearn=no version=3.1.7 Received: from [195.101.245.15] (helo=p-mail1.rd.francetelecom.com) by psg.com with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1HZ16c-000JJM-9z for ccamp@ops.ietf.org; Wed, 04 Apr 2007 08:44:39 +0000 Received: from FTRDMEL2.rd.francetelecom.fr ([10.193.117.153]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Apr 2007 10:44:32 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 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: Solicit the comments on LMP Data Channel Status I-D Date: Wed, 4 Apr 2007 10:44:35 +0200 Message-ID: <7DBAFEC6A76F3E42817DF1EBE64CB02604701AB3@FTRDMEL2.rd.francetelecom.fr> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Solicit the comments on LMP Data Channel Status I-D Thread-Index: Acd2inqaJcvN3RQ/RMeew5TNjCOydgAAdViA References: <0428AC48A879ED46A94F39D5665DF6845C70E4@esealmw110.eemea.ericsson.se> From: "MEURIC Julien RD-CORE-LAN" To: , "Diego Caviglia $GA/ERI$" Cc: X-OriginalArrivalTime: 04 Apr 2007 08:44:32.0955 (UTC) FILETIME=[777290B0:01C77695] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 1e467ff145ef391eb7b594ef62b8301f Hi Dimitri. I must disagree with you. Let us get out of the pure CCAMP context to = come to the real world. In transmission networks, we will see both control and management planes = being used together for a long time. In transmission networks, operators = are used to making manual operations even if equipments are control = plane-enabled: programmed work, configuration of legacy rings where = control plane does not exist, maintenance... More generally, one could = always find some specific operational cases which need human = intervention but which does not justify the development of a specific = control plane feature. You may try to solve this problem by saying this pool of resource is = "purely" (provided this means something in terms of operations) handled = by the control plane and that other pool is not seen; however, besides = the fact that that kind of partitionning would still be configured = manually with possible mistakes, you would have major drawbacks in terms = of operations and resource optimization. What is proposed in the ID is just a mechanism relying on a control = plane protocol to detect *data plane* discrepencies which may occur = because of the cross-connection nature of the circuit-switched world and = of the manual operations you will never completely get rid of. Regards, Julien -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On = Behalf Of Dimitri.Papadimitriou@alcatel-lucent.be hi diego not sure to understand, an automated control plane (at the end the = purpose=20 of this WG) is used to control XC, and other related resource = reservations now you state that there could be manual operations that fails ??? i = think=20 this simply falls outside the scope of the WG, on the other hand if some = TS are unproper for cross-connection i assume the CP does not even take=20 them into account, as label are downstream assigned where is the issue ? thanks, - d. "Diego Caviglia $GA/ERI$" Hi Dimitri, there can an HW problem with the unit and some of its TS are=20 not good or for some reason that TS have been cross-connected by NMS for = error or may for testing at commissioning of the TNE and due to human=20 error have not been deleted and so on.... BR Diego -----Original Message----- From: Dimitri.Papadimitriou@alcatel-lucent.be=20 [mailto:Dimitri.Papadimitriou@alcatel-lucent.be]=20 diego > I think that the reason wht timeslot 2 is not usable is out of the > scope of the ID. but this is kernel of the problem, the origin tells where the solution shall be targeted=20 the i-d refers to the deletion case (2.2), fine but there is cleanup=20 timeout interval to free resources in rsvp thanks, -d. "Diego Caviglia $GA/ERI$" This was bounced. =20 D =20 > Hi Dimitri, > my understunding of the ID was that it tries to = 'synchronize' > the status of the timeslots that are facing the same link. > > Otherwise downstream NE can choose a timeslot that is not good for the > upstream node > > > NE-A NE-B > Timeslots Timeslots > 1-OK 1-OK > 2-OK 2-KO > 3-OK 3-OK > 4-OK 4-OK > > So NE-A can choose Timeslot 2 because it see it good while is not good = in > NE-B. I think that the reason wht timeslot 2 is not usable is out of=20 the > scope of the ID. > > BR > > Diego > > > > > > > Dimitri.Papadimitriou@alcatel-lucent.be on 03/04/2007 11.57.12 > > diego & dan > > "Since the error condition can arise from a variety of situations > (including > control plane failure and restart, management plane intervention,=20 attempt > to clean up a partitioned control plane, etc.) we believe that it = would=20 be > useful to have optional extensions to LMP to detect and report the > problem. > Resolution of the problem remains an issue for the management plane." > > we have three classes of "errors" those outside scope of the CP, those > resulting from CP operations (bug-fixing/mis-use/mis-config/etc.) and > then those that are strictly specific to the LMP and operations > > only the latter shall be in-scope - all these circular dependencies we > are introducing in this control plane are just breaking one of the = main > design principle of networks > > -> which are the remaining "situations" ? > > thanks, > -d. > > > > > > "Diego Caviglia" > 03/04/2007 11:35 > > > Hi Dan, > as stated in Prague I think that the ID addresses a real = problem. > > BR > > Diego > > > > Dan Li on 03/04/2007 10.47.58 > > > Hi all, > > In Prague we saw three optical vendors stating that this I-D addresses = a > real problem that they see in deployed networks. We also saw one=20 operator > expressing interest in the work. > > To summarise the problem that we are addressing: > > Under some circumstances the opposite ends of data links may get into > mismatched states. For example, one end of the data link may be=20 allocated > and cross-connected, while the other end is available for use. This > represents an error condition. > > The problem is particularly bad when the data link is a component link = of > a > > bundle, because the problem cannot be detected from the TE=20 advertisements. > Further, existing LMP mechanisms do not allow us to discover the=20 problem. > > If left undetected and unresolved, the situation may lead to LSP setup > failures or to misconnection of LSPs. > > Since the error condition can arise from a variety of situations > (including > > control plane failure and restart, management plane intervention,=20 attempt > to > clean up a partitioned control plane, etc.) we believe that it would = be > useful to have optional extensions to LMP to detect and report the > problem. > > Resolution of the problem remains an issue for the management plane. > > We would like to hear from people who believe that this is or is not a > real > > problem in the network so that we can judge whether to ask the chairs = to > make this a WG draft. > Best regards, > > > Dan Li > > Advanced Technology Department > Wireline Networking Business Unit > Huawei Technologies Co., LTD. > Huawei Base, Bantian, Longgang, > Shenzhen 518129 P.R.China > Tel: +86-755-28973237 > Fax: +86-755-28972935 From owner-ccamp@ops.ietf.org Wed Apr 04 05:03:07 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZ1OV-00004q-3t for ccamp-archive@ietf.org; Wed, 04 Apr 2007 05:03:07 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZ1OP-0007Jt-Eq for ccamp-archive@ietf.org; Wed, 04 Apr 2007 05:03:07 -0400 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1HZ1Im-000KRS-M6 for ccamp-data@psg.com; Wed, 04 Apr 2007 08:57:12 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO,NO_REAL_NAME autolearn=no version=3.1.7 Received: from [217.32.164.137] (helo=smtp1.smtp.bt.com) by psg.com with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1HZ1Ij-000KR9-Ou for ccamp@ops.ietf.org; Wed, 04 Apr 2007 08:57:11 +0000 Received: from i2kc07-ukbr.domain1.systemhost.net ([193.113.197.14]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Apr 2007 09:57:07 +0100 Received: from E03MVB2-UKBR.domain1.systemhost.net ([193.113.197.108]) by i2kc07-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Apr 2007 09:57:06 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Solicit the comments on LMP Data Channel Status I-D Date: Wed, 4 Apr 2007 09:56:46 +0100 Message-ID: <2ECAA42C79676B42AEBAC11229CA7D0C26CF0B@E03MVB2-UKBR.domain1.systemhost.net> In-Reply-To: <7DBAFEC6A76F3E42817DF1EBE64CB02604701AB3@FTRDMEL2.rd.francetelecom.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Solicit the comments on LMP Data Channel Status I-D Thread-Index: Acd2inqaJcvN3RQ/RMeew5TNjCOydgAAdViAAAKgcCA= From: To: , , Cc: X-OriginalArrivalTime: 04 Apr 2007 08:57:06.0380 (UTC) FILETIME=[388618C0:01C77697] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.2 (/) X-Scan-Signature: fb93e867a11a29ac1dc5018706b412ac We in BT would also agree with you Julien...a CP is useful (noting that signalling and routing functions don't have to be lumped together) but the MP is always essential. regards, Neil > -----Original Message----- > From: owner-ccamp@ops.ietf.org=20 > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of MEURIC Julien=20 > RD-CORE-LAN > Sent: 04 April 2007 09:45 > To: Dimitri.Papadimitriou@alcatel-lucent.be; Diego Caviglia (GA/ERI) > Cc: ccamp@ops.ietf.org > Subject: RE: Solicit the comments on LMP Data Channel Status I-D >=20 >=20 > Hi Dimitri. >=20 > I must disagree with you. Let us get out of the pure CCAMP=20 > context to come to the real world. >=20 > In transmission networks, we will see both control and=20 > management planes being used together for a long time. In=20 > transmission networks, operators are used to making manual=20 > operations even if equipments are control plane-enabled:=20 > programmed work, configuration of legacy rings where control=20 > plane does not exist, maintenance... More generally, one=20 > could always find some specific operational cases which need=20 > human intervention but which does not justify the development=20 > of a specific control plane feature. You may try to solve=20 > this problem by saying this pool of resource is "purely"=20 > (provided this means something in terms of operations)=20 > handled by the control plane and that other pool is not seen;=20 > however, besides the fact that that kind of partitionning=20 > would still be configured manually with possible mistakes,=20 > you would have major drawbacks in terms of operations and=20 > resource optimization. >=20 > What is proposed in the ID is just a mechanism relying on a=20 > control plane protocol to detect *data plane* discrepencies=20 > which may occur because of the cross-connection nature of the=20 > circuit-switched world and of the manual operations you will=20 > never completely get rid of. >=20 > Regards, >=20 > Julien >=20 >=20 > -----Original Message----- > From: owner-ccamp@ops.ietf.org=20 > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of=20 > Dimitri.Papadimitriou@alcatel-lucent.be >=20 > hi diego >=20 > not sure to understand, an automated control plane (at the=20 > end the purpose=20 > of this WG) is used to control XC, and other related resource=20 > reservations >=20 > now you state that there could be manual operations that=20 > fails ??? i think=20 > this simply falls outside the scope of the WG, on the other=20 > hand if some=20 > TS are unproper for cross-connection i assume the CP does not=20 > even take=20 > them into account, as label are downstream assigned where is=20 > the issue ? >=20 > thanks, > - d. >=20 >=20 >=20 >=20 >=20 > "Diego Caviglia $GA/ERI$" >=20 > Hi Dimitri, > there can an HW problem with the unit and some of=20 > its TS are=20 > not good or for some reason that TS have been cross-connected=20 > by NMS for=20 > error or may for testing at commissioning of the TNE and due to human=20 > error have not been deleted and so on.... >=20 > BR >=20 > Diego >=20 > -----Original Message----- > From: Dimitri.Papadimitriou@alcatel-lucent.be=20 > [mailto:Dimitri.Papadimitriou@alcatel-lucent.be]=20 >=20 > diego >=20 > > I think that the reason wht timeslot 2 is not usable is out of the=20 > > scope of the ID. >=20 > but this is kernel of the problem, the origin tells where the=20 > solution shall be targeted=20 >=20 > the i-d refers to the deletion case (2.2), fine but there is cleanup=20 > timeout interval to free resources in rsvp >=20 > thanks, > -d. >=20 >=20 >=20 >=20 >=20 > "Diego Caviglia $GA/ERI$" >=20 > This was bounced. > =20 > D > =20 >=20 > > Hi Dimitri, > > my understunding of the ID was that it tries to=20 > > 'synchronize' the status of the timeslots that are facing the same=20 > > link. > > > > Otherwise downstream NE can choose a timeslot that is not=20 > good for the=20 > > upstream node > > > > > > NE-A NE-B > > Timeslots Timeslots > > 1-OK 1-OK > > 2-OK 2-KO > > 3-OK 3-OK > > 4-OK 4-OK > > > > So NE-A can choose Timeslot 2 because it see it good while=20 > is not good > in > > NE-B. I think that the reason wht timeslot 2 is not usable=20 > is out of > the > > scope of the ID. > > > > BR > > > > Diego > > > > > > > > > > > > > > Dimitri.Papadimitriou@alcatel-lucent.be on 03/04/2007 11.57.12 > > > > diego & dan > > > > "Since the error condition can arise from a variety of situations=20 > > (including control plane failure and restart, management plane=20 > > intervention, > attempt > > to clean up a partitioned control plane, etc.) we believe that it=20 > > would > be > > useful to have optional extensions to LMP to detect and report the=20 > > problem. Resolution of the problem remains an issue for the=20 > management=20 > > plane." > > > > we have three classes of "errors" those outside scope of=20 > the CP, those=20 > > resulting from CP operations=20 > (bug-fixing/mis-use/mis-config/etc.) and=20 > > then those that are strictly specific to the LMP and operations > > > > only the latter shall be in-scope - all these circular=20 > dependencies we=20 > > are introducing in this control plane are just breaking one of the=20 > > main design principle of networks > > > > -> which are the remaining "situations" ? > > > > thanks, > > -d. > > > > > > > > > > > > "Diego Caviglia" > > 03/04/2007 11:35 > > > > > > Hi Dan, > > as stated in Prague I think that the ID addresses a real=20 > > problem. > > > > BR > > > > Diego > > > > > > > > Dan Li on 03/04/2007 10.47.58 > > > > > > Hi all, > > > > In Prague we saw three optical vendors stating that this=20 > I-D addresses=20 > > a real problem that they see in deployed networks. We also saw one > operator > > expressing interest in the work. > > > > To summarise the problem that we are addressing: > > > > Under some circumstances the opposite ends of data links=20 > may get into=20 > > mismatched states. For example, one end of the data link may be > allocated > > and cross-connected, while the other end is available for use. This=20 > > represents an error condition. > > > > The problem is particularly bad when the data link is a=20 > component link > of > > a > > > > bundle, because the problem cannot be detected from the TE > advertisements. > > Further, existing LMP mechanisms do not allow us to discover the > problem. > > > > If left undetected and unresolved, the situation may lead=20 > to LSP setup=20 > > failures or to misconnection of LSPs. > > > > Since the error condition can arise from a variety of situations=20 > > (including > > > > control plane failure and restart, management plane intervention, > attempt > > to > > clean up a partitioned control plane, etc.) we believe that=20 > it would=20 > > be useful to have optional extensions to LMP to detect and=20 > report the=20 > > problem. > > > > Resolution of the problem remains an issue for the management plane. > > > > We would like to hear from people who believe that this is=20 > or is not a=20 > > real > > > > problem in the network so that we can judge whether to ask=20 > the chairs=20 > > to make this a WG draft. Best regards, > > > > > > Dan Li > > > > Advanced Technology Department > > Wireline Networking Business Unit > > Huawei Technologies Co., LTD. > > Huawei Base, Bantian, Longgang, > > Shenzhen 518129 P.R.China > > Tel: +86-755-28973237 > > Fax: +86-755-28972935 >=20 >=20 From owner-ccamp@ops.ietf.org Wed Apr 04 07:22:55 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZ3Zn-0005Eq-Tp for ccamp-archive@ietf.org; Wed, 04 Apr 2007 07:22:55 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZ3Zi-00063g-RR for ccamp-archive@ietf.org; Wed, 04 Apr 2007 07:22:54 -0400 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1HZ3S5-0005xn-0U for ccamp-data@psg.com; Wed, 04 Apr 2007 11:14:57 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO autolearn=ham version=3.1.7 Received: from [156.154.16.138] (helo=ns1.neustar.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63 (FreeBSD)) (envelope-from ) id 1HZ3S2-0005xX-Fu for ccamp@ops.ietf.org; Wed, 04 Apr 2007 11:14:55 +0000 Received: from ietf.org (stiedprweb1.va.neustar.com [10.91.34.42]) by ns1.neustar.com (Postfix) with ESMTP id 8793226ED1; Wed, 4 Apr 2007 11:14:53 +0000 (GMT) Received: from mirror by ietf.org with local (Exim 4.43) id 1HZ3S1-0002PB-Ev; Wed, 04 Apr 2007 07:14:53 -0400 Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 To: Greg Jones Cc: Stephen Trowbridge , Kam Lam , Ross Callon , Dave Ward , Scott Bradner , CCAMP Mailing List , Adrian Farrel , Deborah Brungard , Adrian Farrel , Deborah Brungard From: Adrian Farrel (IETF CCAMP WG) Subject: New Liaison Statement, "Call/Connection Separation in ASON and GMPLS" Reply-To: Adrian Farrel Message-Id: Date: Wed, 04 Apr 2007 07:14:53 -0400 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Title: Call/Connection Separation in ASON and GMPLS Submission Date: 2007-04-04 URL of the IETF Web page: https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=314 Please reply by 2007-05-11 From: Adrian Farrel(IETF CCAMP WG) To: ITU-T Q14/15(Greg Jones ) Cc: Stephen Trowbridge Kam Lam Ross Callon Dave Ward Scott Bradner CCAMP Mailing List Reponse Contact: Adrian Farrel Deborah Brungard Technical Contact: Adrian Farrel Deborah Brungard