From owner-mpls@UU.NET Wed Jan 1 03:00:18 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01527 for ; Wed, 1 Jan 2003 03:00:17 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnvsq19716 for ; Wed, 1 Jan 2003 08:03:25 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnvsq17403; Wed, 1 Jan 2003 08:02:20 GMT Received: by mail-control.ash.ops.us.uu.net id QQnvsq26509 for mpls-outgoing; Wed, 1 Jan 2003 08:02:02 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnvsq26499 for ; Wed, 1 Jan 2003 08:01:53 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnvsq16629 for ; Wed, 1 Jan 2003 08:00:45 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnvsq16726 for ; Wed, 1 Jan 2003 08:00:44 GMT Received: from evaki.its.uow.edu.au by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: evaki.its.uow.edu.au [130.130.68.32]) id QQnvsq16697 for ; Wed, 1 Jan 2003 08:00:43 GMT Received: from evaki (localhost [127.0.0.1]) by evaki.its.uow.edu.au (8.12.3/8.12.3) with ESMTP id h0180auN011303 for ; Wed, 1 Jan 2003 19:00:36 +1100 (EST) Received: (from sendmail@localhost) by chac.its.uow.edu.au (8.12.3/8.12.3) id h0180ZMf005507 for ; Wed, 1 Jan 2003 19:00:35 +1100 (EST) Received: from aten.its.uow.edu.au (aten.its.uow.edu.au[130.130.68.33]) by chac.its.uow.edu.au (UWSMTPD 1.0) with ESMTP id 1220641.5502; Wednesday, 01 January 2003 19:00:33 +1100 Received: by aten.its.uow.edu.au (8.12.3/8.12.3) id h0180Wg4025531; Wed, 1 Jan 2003 19:00:32 +1100 (EST) Message-Id: <200301010800.h0180Wg4025531@aten.its.uow.edu.au> Subject: Hardware-based MPLS Implementation From: Hoang Lan Nguyen Content-Type: text/plain; charset=iso-8859-1 X-Originating-IP: [130.130.94.3] MIME-Version: 1.0 To: mpls@UU.NET Content-Transfer-Encoding: 8bit Date: Wed, 01 Jan 2003 19:00:32 +1100 User-Agent: IMHO/0.98.3 (Webmail for Roxen) Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit Hi all, Does anyone know how to build a MPLS-controlled switch/router using FPGA technology, how to implement MPLS in hardware ?. Does anyone know any hardware configuration of MPLS enigne (eg, HDL files) ? Thank a lot. Lan ******************************************************* ----------------------- | FPGA is King ! | ----------------------- From owner-mpls@UU.NET Wed Jan 1 11:16:11 2003 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08961 for ; Wed, 1 Jan 2003 11:16:11 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnvtx04173 for ; Wed, 1 Jan 2003 16:19:16 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnvtx01001; Wed, 1 Jan 2003 16:17:34 GMT Received: by mail-control.ash.ops.us.uu.net id QQnvtx06703 for mpls-outgoing; Wed, 1 Jan 2003 16:17:02 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnvtx06698 for ; Wed, 1 Jan 2003 16:17:01 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnvtx25945 for ; Wed, 1 Jan 2003 16:16:50 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnvtx11585 for ; Wed, 1 Jan 2003 16:16:49 GMT Received: from rtp-msg-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-msg-core-1.cisco.com [161.44.11.97]) id QQnvtx11577 for ; Wed, 1 Jan 2003 16:16:49 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id h01GAffi027954 for ; Wed, 1 Jan 2003 11:10:41 -0500 (EST) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id LAA01815 for ; Wed, 1 Jan 2003 11:10:02 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h01GA2Z04784 for mpls@uu.net; Wed, 1 Jan 2003 11:10:02 -0500 (EST) Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnvtw05189 for ; Wed, 1 Jan 2003 16:09:11 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnvtw27759 for ; Wed, 1 Jan 2003 16:08:53 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnvtw24084 for ; Wed, 1 Jan 2003 16:08:53 GMT Received: from aejpx by cmr1.ash.ops.us.uu.net with SMTP (peer crosschecked as: [211.250.48.3]) id QQnvtw24075 for ; Wed, 1 Jan 2003 16:08:51 GMT From: Lola Ingle To: Subject: Attn: Want to be safe online? p Date: Wed, 01 Jan 2003 12:08:00 -0500 Mime-Version: 1.0 Content-Type: text/html Content-Transfer-Encoding: base64 Message-Id: Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: base64 PGh0bWw+PGJvZHk+PHRhYmxlIGJvcmRlcj0xIHdpZHRoPTQ1MCBib3JkZXJjb2xvcmRhcms9 IzAwMDAwMCBzdHlsZT0iYm9yZGVyLWNvbGxhcHNlOiBjb2xsYXBzZSIgYm9yZGVyY29sb3I9 IzExMTExMSBjZWxscGFkZGluZz0wIGNlbGxzcGFjaW5nPTAgYm9yZGVyY29sb3JsaWdodD0j MDAwMDAwPjx0cj48dGQgd2lkdGg9MTExIGJnY29sb3I9I0ZGRkZGRiBhbGlnbj1jZW50ZXIg Ym9yZGVyY29sb3I9IzAwMDAwMCByb3dzcGFuPTI+IDxiPjxmb250IHNpemU9NT5zeW1hbnRl YzwvZm9udD48L2I+PC90ZD48dGQgd2lkdGg9NDQgYmdjb2xvcj0jRkZDQzAwIGFsaWduPWNl bnRlciBib3JkZXJjb2xvcj0jMDAwMDAwPiZuYnNwOzwvdGQ+PHRkIHdpZHRoPTI5NCBiZ2Nv bG9yPSNGRkZGRkYgYWxpZ249Y2VudGVyIGJvcmRlcmNvbG9yPSNGRkZGRkYgcm93c3Bhbj0y IHN0eWxlPSJib3JkZXI6IDFweCBzb2xpZCAjRkZGRkZGIj4gPGI+PGZvbnQgZmFjZT1UYWhv bWEgc2l6ZT00Pk5vcnRvbiBBbnRpVmlydXMgMjAwMzxCUj4gPC9mb250PiA8Zm9udCBmYWNl PVRhaG9tYSBzaXplPTEgY29sb3I9IzMzMzMzMz4qKioqKioqKiogTk9XIFBMQVlJTkcgKioq KioqKioqPC9mb250PjwvYj48L3RkPjwvdHI+PHRyPjx0ZCB3aWR0aD00NCBiZ2NvbG9yPSMw MDAwMDAgYWxpZ249Y2VudGVyIGJvcmRlcmNvbG9yPSMwMDAwMDA+Jm5ic3A7PC90ZD48L3Ry PjwvdGFibGU+PHRhYmxlIGJvcmRlcj0wIHdpZHRoPTQ1MCBoZWlnaHQ9NjYgc3R5bGU9ImJv cmRlci1jb2xsYXBzZTogY29sbGFwc2UiIGJvcmRlcmNvbG9yPSMxMTExMTEgY2VsbHBhZGRp bmc9MCBjZWxsc3BhY2luZz0wPjx0cj48dGQgd2lkdGg9NDQ2IGhlaWdodD0xIGFsaWduPWNl bnRlciBiZ2NvbG9yPSMwMDAwMDA+IDxiPjxmb250IGZhY2U9VGFob21hIHNpemU9NCBjb2xv cj0jRkZDQzAwPkF0dGVudGlvbjwvZm9udD48Zm9udCBmYWNlPVRhaG9tYSBzaXplPTQ+PGZv bnQgY29sb3I9I0ZGQ0MwMD4hIDwvZm9udD4gPGZvbnQgY29sb3I9I0ZGRkZGRj5ORVcgTm9y dG9uIEFWIDIwMDMgUmVsZWFzZWQhPC9mb250PjwvZm9udD48L2I+PC90ZD48L3RyPjx0cj48 dGQgd2lkdGg9NDQ2IGhlaWdodD0xNiBhbGlnbj1jZW50ZXIgYmdjb2xvcj0jRkZDQzAwPiA8 Zm9udCBmYWNlPVRhaG9tYSBzaXplPTI+PGI+VGhlIE1vc3QgUG9wdWxhciBQQyBTb2Z0d2Fy ZSBIYXMgUmV0dXJuZWQgdG8gdGhlIFNjcmVlbiE8L2I+PC9mb250PjwvdGQ+PC90cj48dHI+ PHRkIHdpZHRoPTQ0NiBoZWlnaHQ9MTggYWxpZ249Y2VudGVyIGJnY29sb3I9IzAwMDAwMD4g PGI+PGZvbnQgZmFjZT1UYWhvbWEgc2l6ZT0yIGNvbG9yPSNGRkZGRkY+UHV0IHRoZSBTZXF1 ZWwgdG8gQUxMIEFudGlWaXJ1cyBQcm9ncmFtcyBvbiBZb3VyIFBDITwvZm9udD48L2I+PC90 ZD48L3RyPjx0cj48dGQgd2lkdGg9NDQ2IGhlaWdodD0xNiBhbGlnbj1jZW50ZXIgYm9yZGVy Y29sb3I9IzAwMDAwMCBiZ2NvbG9yPSMwMDAwMDA+PHAgYWxpZ249Y2VudGVyPiA8Zm9udCBj bGFzcz1ibGFjazEwIGZhY2U9VGFob21hIHNpemU9MiBjb2xvcj0jRkZDQzAwPjxiPkVOSEFO Q0VEITwvYj48L2ZvbnQ+PGZvbnQgY2xhc3M9YmxhY2sxMCBjb2xvcj0jRkZGRkZGIGZhY2U9 VGFob21hIHNpemU9Mj4gPGI+QXV0b21hdGljYWxseSByZW1vdmVzIFZpcnVzZXMsIFdvcm1z LCBhbmQgVHJvamFuczwvYj48L2ZvbnQ+PC90ZD48L3RyPjx0cj48dGQgd2lkdGg9NDQ2IGhl aWdodD0xNiBhbGlnbj1jZW50ZXIgYmdjb2xvcj0jMDAwMDAwPjxwIGFsaWduPWNlbnRlcj48 Yj4gPGZvbnQgY2xhc3M9YmxhY2sxMCBmYWNlPVRhaG9tYSBzaXplPTIgY29sb3I9I0ZGQ0Mw MD5ORVchPC9mb250Pjxmb250IGNsYXNzPWJsYWNrMTAgZmFjZT1UYWhvbWEgc2l6ZT0yIGNv bG9yPSNGRkZGRkY+IERldGVjdHMgYW5kIGJsb2NrcyBhbGwgdmlydXNlcyBpbiBpbnN0YW50 IG1lc3NhZ2UgYXR0YWNobWVudHM8L2ZvbnQ+PC9iPjwvdGQ+PC90cj48L3RhYmxlPjx0YWJs ZSBib3JkZXI9MCB3aWR0aD00NTAgaGVpZ2h0PTgxIGJnY29sb3I9I0ZGQ0MwMCBzdHlsZT0i Ym9yZGVyLWNvbGxhcHNlOiBjb2xsYXBzZSIgYm9yZGVyY29sb3I9IzExMTExMSBjZWxscGFk ZGluZz0wIGNlbGxzcGFjaW5nPTA+PHRyPjx0ZCB3aWR0aD00NTIgaGVpZ2h0PTc1IGJnY29s b3I9I0ZGRkZGRiBhbGlnbj1jZW50ZXIgc3R5bGU9ImJvcmRlci1zdHlsZTogc29saWQ7IGJv cmRlci13aWR0aDogNCIgYm9yZGVyY29sb3I9I0ZGQ0MwMD4gPGI+PGZvbnQgZmFjZT1UYWhv bWEgc2l6ZT0yPiZxdW90O0kgaGF2ZSBiZWVuIHVzaW5nIE5BViBmb3IgMyB5ZWFycyBhbmQg aXQgaGFzIE5FVkVSIGNyYXNoZWQgbXkgc3lzdGVtIGFuZCBkZXRlY3RzIEFMTCBlbWFpbCB2 aXJ1c2VzISBUaGVyZSB3YXMgTk8gaW1wYWN0IG9uIHRoZSBwZXJmb3JtYW5jZSBvZiBteSBt YWNoaW5lLiBJIGdpdmUgaXQgdHdvIHRodW1icyB1cCEmcXVvdDs8L2ZvbnQ+PC9iPjxmb250 IGZhY2U9VGFob21hIHNpemU9Mj48YnI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IDxpPi0gSi4gQnJvd24gKE5vcnRvbiBBbnRpVmlydXMqIFVzZXIpPGJyPiA8L2k+PC9mb250 PiA8aT48Zm9udCBmYWNlPVRhaG9tYSBzaXplPTE+PGI+KCpXaW5uZXIgLSZuYnNwOyBQQyBN QUdBWklORSBFRElUT1InUyBDSE9JQ0UgQVdBUkQgLSAzIFllYXJzIGluIGEgUk9XISk8L2I+ PC9mb250PjwvaT48L3RkPjwvdHI+PC90YWJsZT48dGFibGUgYm9yZGVyPTEgd2lkdGg9NDUw IGJvcmRlcmNvbG9yPSMwMDAwODAgYm9yZGVyY29sb3JsaWdodD0jNjY2NjY2IGJvcmRlcmNv bG9yZGFyaz0jMDAwMDAwIHN0eWxlPSJib3JkZXItY29sbGFwc2U6IGNvbGxhcHNlIiBjZWxs cGFkZGluZz0wIGNlbGxzcGFjaW5nPTAgaGVpZ2h0PTMzPjx0cj48dGQgd2lkdGg9MTAwJSBh bGlnbj1jZW50ZXIgYmdjb2xvcj0jMDAwMDAwIGhlaWdodD0zMz48Yj48Zm9udCBzaXplPTQg ZmFjZT1UYWhvbWE+IDxhIGhyZWY9Imh0dHA6Ly93d3cuc29mdHdhcmVzd2FwbWVldC5jb20v bm9ydG9uYXYwMTMuaHRtP24wMj14dnhzdWplZnR4c3draWF5dHlkcWEiIHN0eWxlPSJ0ZXh0 LWRlY29yYXRpb246IG5vbmUgYmxpbms7IGNvbG9yOiAjRkZGRkZGOyBmb250LWZhbWlseTog VGFob21hOyBmb250LXNpemU6IDE0cHQ7IGZvbnQtd2VpZ2h0OiBib2xkIj5DbGljayBIZXJl ICZhbXA7IGdldCB5b3VycyBmb3IgT05MWSAkMjkuOTkhPC9hPjwvZm9udD48L2I+PC90ZD48 L3RyPjwvdGFibGU+PHA+Jm5ic3A7PC9wPjxwPiZuYnNwOzwvcD48cCBhbGlnbj1jZW50ZXI+ Jm5ic3A7PC9wPjx0YWJsZSBib3JkZXI9MCB3aWR0aD00NjA+PHRyPjx0ZCB3aWR0aD0xMDAl PjxwIGFsaWduPWNlbnRlcj48Zm9udCBmYWNlPVRhaG9tYSBzaXplPTEgY29sb3I9IzY2NjY2 Nj5Zb3VyIHBlcnNvbmFsIGVtYWlsIGFkZHJlc3Mgd2FzIG9idGFpbmVkIGZyb20gYW4gb3B0 LWluIGxpc3QuIE9wdC1pbiBVRUMgKFVuaXRlZCBFY29tbWVyY2UgQ29hbGl0aW9uKSBBcHBy b3ZlZCBMaXN0IC0gVHlwZSBOTlMgU3VmZml4ID0gelQlMjJkJUgmYW1wO0VVU0EuJm5ic3A7 VG8gdW5zdWJzY3JpYmUgZnJvbSB0aGlzIGxpc3QsIHBsZWFzZSA8YSBzdHlsZT0iY29sb3I6 ICMwMDAwODAiIGhyZWY9aHR0cDovL3d3dy5zb2Z0d2FyZXN3YXBtZWV0LmNvbS9yZW1vdmUu YXNwPkNsaWNrIGhlcmU8L2E+IC4gWW91IG5lZWQgdG8gYWxsb3cgNSBCdXNpbmVzcyBkYXlz IGZvciByZW1vdmFsLiBXZSBkbyBub3QgY29uZG9uZSBzcGFtIGluIGFueSBzaGFwZSBvciBm b3JtLiBUaGFuayBZb3Uga2luZGx5IGZvciB5b3VyIGNvb3BlcmF0aW9uLjxicj5CYWxkaW5n IENhbmRpZGF0ZSBleGN1c2VkIGhpbXNlbGYgYW5kIHJldHVybmVkIHRvIHRoZSBvZmZpY2Ug YSBmZXcgbWludXRlcyBsYXRlciB3ZWFyaW5nIGEgaGVhZHBpZWNlLjxicj5gQWgsJyBzYWlk IEFydGh1ciwgYHRoaXMgaXMgb2J2aW91c2x5IHNvbWUgc3RyYW5nZSB1c2FnZSBvZiB0aGUg d29yZCAic2FmZSIgdGhhdCBJIHdhc24ndCBwcmV2aW91c2x5IGF3YXJlIG9mLic8L2ZvbnQ+ PC90ZD48L3RyPjwvdGFibGU+PC9ib2R5PjwvaHRtbD4NCg== From owner-mpls@UU.NET Fri Jan 3 17:41:27 2003 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20829 for ; Fri, 3 Jan 2003 17:41:27 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnwcg12449 for ; Fri, 3 Jan 2003 22:44:36 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnwcg08256; Fri, 3 Jan 2003 22:42:22 GMT Received: by mail-control.ash.ops.us.uu.net id QQnwcg08681 for mpls-outgoing; Fri, 3 Jan 2003 22:42:08 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnwcg08675 for ; Fri, 3 Jan 2003 22:41:54 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnwcg21433 for ; Fri, 3 Jan 2003 22:41:19 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnwcg06982 for ; Fri, 3 Jan 2003 22:41:19 GMT Received: from kanmx1.ca.alcatel.com by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: kanfw1.ottawa.alcatel.ca [192.75.23.69]) id QQnwcg06969 for ; Fri, 3 Jan 2003 22:41:18 GMT Received: (qmail 2212 invoked from network); 3 Jan 2003 22:47:46 -0000 Received: (ofmipd 138.120.118.71); 3 Jan 2003 22:47:24 -0000 Received: from alcatel.com ([138.120.62.58]) by kanmail01.ca.newbridge.com (Netscape Messaging Server 3.6) with ESMTP id AAA2909; Fri, 3 Jan 2003 17:41:16 -0500 Date: 3 Jan 2003 17:41:12 -0500 Message-ID: <3E161188.9F92601@alcatel.com> From: "Cheng-Yin Lee" Reply-To: Cheng-Yin.Lee@alcatel.com To: "'mpls@UU.NET'" X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 Subject: Some suggestions for LSP Ping Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hello, Some suggestions that may be helpful for LSP Ping. It seems one could precede an MPLS Ping with the LSP "payload" header to allow the test packet to be (deterministically) exercised by data path and use Router Alert Option to allow the egress to intercept the LSP Ping message : 1) For an LSP with IP traffic, an MPLS Ping may contain e.g.: a) Payload header - IP dst = 192.168.1.1 - Protocol ID = IP or alternatively MPLS_PING_PROT - Option = Router Alert (or alternatively a new Option, e.g. class "debugging & measurement") OR alternatively set TTL=1 b) IP header IP dst = e.g. 127.0.0.1/224.0.0.1 (a specific IP address allowing a local IP/UDP protocol stack to process the message) c) UDP header d) MPLS Ping message [If Protocol ID is MPLS_PING_PROT, the inner header is the MPLS Ping message, no IP & UDP header, but may need checksum in MPLS Ping message] (b)-(d) are the same as in LSP Ping draft, unless stated otherwise above. The Router Alert Option is intended for the egress LSR to intercept the MPLS Ping message (existing implementations may vary). Using TTL=1 instead may have issues as raised in previous email thread "Last call on LSP Ping" If hashing includes Protocol ID, the above require changes such that Protocol ID is set to the actual LSP "payload" Protocol ID, and another field e.g. Router Alert Value or new Option class indicates/implies how to decode rest of message. The above will not work as is if hashing on port is required. 2) For an LSP with inner label, an MPLS Ping may contain eg: (I think a-b may be similar to what Curtis have proposed for labels) a) Payload header - VC label = L - This is suggested by Curtis/Shahram? S' bit not bottom of stack (as a few people pointed out, this requires data path change) OR alternatively TTL=1 (Using TTL may have issues as raised in past email thread "Last call on LSP Ping" and may be trickier, lower layer TTL setting etc) b) IPv4 Explicit NULL label ("indicates that the label stack must be popped, and the forwarding of the packet must then be based on the IPv4 header") c) IP header IP dst = eg. 127.0.0.1/224.0.0.1 d) UDP header e) MPLS Ping message (c)-(e) are as specified in LSP Ping draft, with the exception of the field(s) listed above. If the inner label contains IP traffic, (2b-2e) may be replaced by (1a-1d), (2a) 'S' bit is bottom of stack or TTL=1. Some useful functions when including the "payload" hdr and using Router Alert : - test packet can be exercised on the same path (including ECMP) as the data traffic (by data path) - not necessary for MPLS ping to assume how ECMP is done in LSRs - not necessary to use 127/8 address range - avoiding some TTL issues - not necessary to have intermediate LSRs provide ECMP related information There will be some limitations, e.g. can exercise only one path with one LSP Ping. Other opinions and issues? Anything I missed? Hope some of these are helpful. Happy New Year. Regards, Cheng-Yin From owner-mpls@UU.NET Sat Jan 4 07:01:21 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09767 for ; Sat, 4 Jan 2003 07:01:21 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnwei19912 for ; Sat, 4 Jan 2003 12:04:30 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnwei18696; Sat, 4 Jan 2003 12:03:57 GMT Received: by mail-control.ash.ops.us.uu.net id QQnwei21507 for mpls-outgoing; Sat, 4 Jan 2003 12:03:41 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnwei21491 for ; Sat, 4 Jan 2003 12:03:38 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnwei15520 for ; Sat, 4 Jan 2003 12:03:36 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnwei18521 for ; Sat, 4 Jan 2003 12:03:36 GMT Received: from ganesh.ctd.hctech.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [202.54.64.2]) id QQnwei18512 for ; Sat, 4 Jan 2003 12:03:34 GMT Received: by GANESH with Internet Mail Service (5.5.2653.19) id ; Sat, 4 Jan 2003 17:47:02 +0530 Message-ID: <55E277B99171E041ABF5F4B1C6DDCA0601097B61@haritha.hclt.com> From: "Ramakrishnan.R (Networking) - CTD, Chennai." To: "'mpls@UU.NET'" Subject: Frame Relay Encapsulation Date: Sat, 4 Jan 2003 17:35:52 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Hello, I am working on MPLS over Frame Relay. I would like to know how the MPLS packet is encapsulated in the Frame Relay packet. I would like to know what is the NLPID ( A field in the MPLS header) used for MPLS?. I couldn't get the information about the NLPID anywhere. Thanks in Advance. Regards Ramki From owner-mpls@UU.NET Sat Jan 4 12:38:36 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13852 for ; Sat, 4 Jan 2003 12:38:36 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnwfe08872 for ; Sat, 4 Jan 2003 17:41:44 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnwfe06115; Sat, 4 Jan 2003 17:40:08 GMT Received: by mail-control.ash.ops.us.uu.net id QQnwfe19246 for mpls-outgoing; Sat, 4 Jan 2003 17:39:50 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnwfe19241 for ; Sat, 4 Jan 2003 17:39:40 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnwfe05929 for ; Sat, 4 Jan 2003 17:39:14 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnwfe09831 for ; Sat, 4 Jan 2003 17:39:14 GMT Received: from rtp-msg-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-msg-core-1.cisco.com [161.44.11.97]) id QQnwfe09749 for ; Sat, 4 Jan 2003 17:39:03 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id h04HdgfD017966 for ; Sat, 4 Jan 2003 12:39:42 -0500 (EST) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id MAA10487 for ; Sat, 4 Jan 2003 12:39:02 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h04Hd2G20973 for mpls@uu.net; Sat, 4 Jan 2003 12:39:02 -0500 (EST) Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnwfe19208 for ; Sat, 4 Jan 2003 17:37:30 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnwfe03798 for ; Sat, 4 Jan 2003 17:37:24 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnwfe08588 for ; Sat, 4 Jan 2003 17:37:24 GMT Received: from workhorse.fictitious.org by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: workhorse.fictitious.org [209.150.1.230]) id QQnwfe08573 for ; Sat, 4 Jan 2003 17:37:22 GMT Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id MAA49478; Sat, 4 Jan 2003 12:34:05 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200301041734.MAA49478@workhorse.fictitious.org> To: Cheng-Yin.Lee@alcatel.com cc: "'mpls@UU.NET'" Reply-To: curtis@fictitious.org Subject: Re: Some suggestions for LSP Ping In-reply-to: Your message of "03 Jan 2003 17:41:12 EST." <3E161188.9F92601@alcatel.com> Date: Sat, 04 Jan 2003 12:34:05 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <3E161188.9F92601@alcatel.com>, "Cheng-Yin Lee" writes: > Hello, > Some suggestions that may be helpful for LSP Ping. > It seems one could precede an MPLS Ping with the LSP "payload" header to > allow the test packet to be (deterministically) exercised by data path > and use Router Alert Option to allow the egress to intercept the LSP > Ping message : > > 1) For an LSP with IP traffic, an MPLS Ping may contain e.g.: > a) Payload header > - IP dst = 192.168.1.1 > - Protocol ID = IP or alternatively MPLS_PING_PROT > - Option = Router Alert (or alternatively a new Option, e.g. class > "debugging & measurement") OR alternatively set TTL=1 > b) IP header > IP dst = e.g. 127.0.0.1/224.0.0.1 (a specific IP address allowing a > local IP/UDP > protocol stack to process the message) > c) UDP header > d) MPLS Ping message > [If Protocol ID is MPLS_PING_PROT, the inner header is the MPLS Ping > message, no IP & UDP header, but may need checksum in MPLS Ping message] IP and UDP were picked. With that choice no MPLS Ping checksum is needed. > (b)-(d) are the same as in LSP Ping draft, unless stated otherwise > above. > The Router Alert Option is intended for the egress LSR to intercept the > MPLS Ping > message (existing implementations may vary). Using TTL=1 instead may > have issues as raised in previous email thread "Last call on LSP Ping" Destination is in 127/8 and TTL=1 so it can't be forwarded unless the action taken by the egress LSR on a VPN or PW label is to forward to a specific interface unconditionally. Then router alert in the MPLS payload won't help either. > If hashing includes Protocol ID, the above require changes such that > Protocol ID is set to the actual LSP "payload" Protocol ID, and another > field e.g. Router Alert Value or new Option class indicates/implies how > to decode rest of message. > The above will not work as is if hashing on port is required. If source address, protocol ID and ports are fixed, then a set of destination addresses can be found to exercise a specific path. > 2) For an LSP with inner label, an MPLS Ping may contain eg: (I think > a-b may be similar to what Curtis have proposed for labels) > a) Payload header > - VC label = L > - This is suggested by Curtis/Shahram? > S' bit not bottom of stack (as a few people pointed out, this requires > data path change) > OR alternatively TTL=1 (Using TTL may have issues as raised in past > email thread "Last call on LSP Ping" and may be trickier, lower layer > TTL setting etc) > b) IPv4 Explicit NULL label ("indicates that the label stack must be > popped, and the forwarding of the packet must then be based on the IPv4 > header") > c) IP header > IP dst = eg. 127.0.0.1/224.0.0.1 > d) UDP header > e) MPLS Ping message The S bit is always at the bottom of the stack. The VPN label is no longer on the bottom, but an Explicit NULL label follows. What the egress LSR should do with this is so far undefined. So far no one has indicated that their router could not either 1) disable any unconditional forwarding based on the VPN label and check the next label or 2) process the packet on the egress LSR based on TTL expire of TTL in the VPN shim. > (c)-(e) are as specified in LSP Ping draft, with the exception of the > field(s) listed above. > If the inner label contains IP traffic, (2b-2e) may be replaced by > (1a-1d), > (2a) 'S' bit is bottom of stack or TTL=1. No one has ever suggested that we use the multicast range (224.0.0.1). > Some useful functions when including the "payload" hdr and using Router > Alert : > - test packet can be exercised on the same path (including ECMP) as the > data traffic (by data path) > - not necessary for MPLS ping to assume how ECMP is done in LSRs > - not necessary to use 127/8 address range > - avoiding some TTL issues > - not necessary to have intermediate LSRs provide ECMP related > information > > There will be some limitations, e.g. can exercise only one path with one > LSP Ping. Router alert would eliminate the need to use a destination within 127/8 but has no other advantage. The same procedure is needed to exercise multipath only using a range of real destination addresses may be much worse. See below. > Other opinions and issues? Anything I missed? > Hope some of these are helpful. Lets try to make progress and *not* propose arbitrary changes for no good reason. Proposing to use router alert to eliminate the need to use 127/8 is of use only if people regard using 127/8 as an immense sacrilege. Since the source address must be an address of the router sending MPLS ping, there is still a need to pick from a range to exercise all paths. It is probably a lot better to pick from a range of 127/8 than some other range where a non-MPLS-ping capble router at the egress would happily deliver the MPLS-ping traffic to the final IP destination. There would be a small advantage to ignoring both the IP source and destination address in that for a report of "I can't get there from here" the ISP can put "here" in the source and "there" in the destination, add router alert, and put the MPLS-ping return address in the payload. This is a minor advantage but may be offset if there is a possibility that the test traffic actually gets delivered to the destination and the destination sends ICMP back at the source, either of which could interpret this as a DoS attack and start filtering. That would compund the original problem and make it harder overall to solve. > Happy New Year. > > Regards, > Cheng-Yin Thanks for sharing your ideas. Regards, Curtis From owner-mpls@UU.NET Sat Jan 4 22:01:33 2003 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA19092 for ; Sat, 4 Jan 2003 22:01:33 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnwgq03244 for ; Sun, 5 Jan 2003 03:04:35 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnwgq27358; Sun, 5 Jan 2003 03:01:50 GMT Received: by mail-control.ash.ops.us.uu.net id QQnwgq24115 for mpls-outgoing; Sun, 5 Jan 2003 03:01:22 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnwgq23538 for ; Sun, 5 Jan 2003 03:01:17 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnwgq04302 for ; Sun, 5 Jan 2003 03:00:41 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnwgq20659 for ; Sun, 5 Jan 2003 03:00:41 GMT Received: from squirehome.org by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rdu74-137-145.nc.rr.com [24.74.137.145]) id QQnwgq20614 for ; Sun, 5 Jan 2003 03:00:39 GMT Received: from acm.org (IDENT:msquire@squid.squirehome.org [192.168.168.2]) by squirehome.org (8.11.6/8.11.0) with ESMTP id h0530SW07936; Sat, 4 Jan 2003 22:00:33 -0500 Message-ID: <3E179FCC.6D8B2EB9@acm.org> Date: Sat, 04 Jan 2003 22:00:28 -0500 From: Matt Squire Reply-To: mattsquire@acm.org X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.16-22 i686) X-Accept-Language: en, pdf MIME-Version: 1.0 To: Loa Andersson CC: mpls wg , George Swallow , Scott Bradner Subject: Re: draft-rosen-mpls-in-ip-or-gre-00.txt References: <3DFE024D.8090503@pi.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit I'd like to see it become WG doc. - Matt Loa Andersson wrote: > > All, > > the draft draft-rosen-mpls-in-ip-or-gre-00.txt was presented in Atlanta, > the reception was positive, and there has been no discussion after that > on the mailing list. > > Based on prior response to the mailing list, the response at the > Atlanta meeting and the lack of response after the meeting, it is > the wg chairs intention to make this draft a wg document. > > Please comment before January 7th. > > Loa and George > > -- > Loa Andersson > > Mobile +46 739 81 21 64 > Email loa@pi.se From owner-mpls@UU.NET Sat Jan 4 23:19:16 2003 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA19588 for ; Sat, 4 Jan 2003 23:19:16 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnwgv13012 for ; Sun, 5 Jan 2003 04:21:39 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnwgv05141; Sun, 5 Jan 2003 04:17:34 GMT Received: by mail-control.ash.ops.us.uu.net id QQnwgv28933 for mpls-outgoing; Sun, 5 Jan 2003 04:17:18 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnwgv28928 for ; Sun, 5 Jan 2003 04:17:09 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnwgv04524 for ; Sun, 5 Jan 2003 04:15:12 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnwgv21852 for ; Sun, 5 Jan 2003 04:15:04 GMT Received: from rtp-msg-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-msg-core-1.cisco.com [161.44.11.97]) id QQnwgv21816 for ; Sun, 5 Jan 2003 04:15:03 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id h054FgN0020411 for ; Sat, 4 Jan 2003 23:15:42 -0500 (EST) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id XAA28016 for ; Sat, 4 Jan 2003 23:15:02 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h054F2d21669 for mpls@uu.net; Sat, 4 Jan 2003 23:15:02 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnwgu28378 for ; Sun, 5 Jan 2003 04:13:43 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnwgu24962 for ; Sun, 5 Jan 2003 04:12:59 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnwgu19621 for ; Sun, 5 Jan 2003 04:12:59 GMT Received: from pimout3-ext.prodigy.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pimout3-ext.prodigy.net [207.115.63.102]) id QQnwgu19614 for ; Sun, 5 Jan 2003 04:12:58 GMT Received: from ciena.com (adsl-66-127-241-193.dsl.sntc01.pacbell.net [66.127.241.193]) by pimout3-ext.prodigy.net (8.12.3 da nor stuldap/8.12.3) with ESMTP id h054CmkD184828; Sat, 4 Jan 2003 23:12:48 -0500 Message-ID: <3E17B0BB.8010006@ciena.com> Date: Sat, 04 Jan 2003 20:12:43 -0800 From: Ping Pan User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Loa Andersson , George Swallow CC: mpls wg , Scott Bradner Subject: Re: draft-rosen-mpls-in-ip-or-gre-00.txt References: <3DFE024D.8090503@pi.se> <3E179FCC.6D8B2EB9@acm.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit The draft presents a pretty good idea. Should become a standard from this WG. - Ping > Loa Andersson wrote: > >>All, >> >>the draft draft-rosen-mpls-in-ip-or-gre-00.txt was presented in Atlanta, >>the reception was positive, and there has been no discussion after that >>on the mailing list. >> >>Based on prior response to the mailing list, the response at the >>Atlanta meeting and the lack of response after the meeting, it is >>the wg chairs intention to make this draft a wg document. >> >>Please comment before January 7th. >> >>Loa and George >> >>-- >>Loa Andersson >> >>Mobile +46 739 81 21 64 >>Email loa@pi.se > -- Ping Pan, Ph.D. Principle Engineer Core Networking Voice: (408)-655-6547 CIENA Corp. Fax: (408)-366-4900 From owner-mpls@UU.NET Sun Jan 5 00:58:04 2003 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20883 for ; Sun, 5 Jan 2003 00:58:04 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnwhc03987 for ; Sun, 5 Jan 2003 06:01:13 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnwhb25450; Sun, 5 Jan 2003 05:57:11 GMT Received: by mail-control.ash.ops.us.uu.net id QQnwhb24804 for mpls-outgoing; Sun, 5 Jan 2003 05:56:45 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnwhb24799 for ; Sun, 5 Jan 2003 05:56:44 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnwhb02337 for ; Sun, 5 Jan 2003 05:56:36 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnwhb25038 for ; Sun, 5 Jan 2003 05:56:35 GMT Received: from smtp014.mail.yahoo.com by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: smtp014.mail.yahoo.com [216.136.173.58]) id QQnwhb25026 for ; Sun, 5 Jan 2003 05:56:35 GMT Received: from unknown (HELO yahoo.com) (cheluvi@61.11.55.149 with plain) by smtp.mail.vip.sc5.yahoo.com with SMTP; 5 Jan 2003 05:56:33 -0000 Message-ID: <3E17C99C.79CA7DBB@yahoo.com> Date: Sun, 05 Jan 2003 11:28:52 +0530 From: "v.nagasrinivas" Reply-To: cheluvi@yahoo.com Organization: yvl software X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.19 i686) X-Accept-Language: en MIME-Version: 1.0 To: "Ramakrishnan.R (Networking) - CTD, Chennai." CC: "'mpls@UU.NET'" Subject: Re: Frame Relay Encapsulation References: <55E277B99171E041ABF5F4B1C6DDCA0601097B61@haritha.hclt.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi Ramakrishnan, I think rfc 3034 is explaining how it will do ... I quickly browsed and the following is helping you. http://www.zvon.org/tmRFC/RFC3034/Output/chapter5.html http://www.networksorcery.com/enp/protocol/framerelay.htm and go through frf8.1 for some more information, not relating to MPLS. Thanks, srinivas. "Ramakrishnan.R (Networking) - CTD, Chennai." wrote: > Hello, > I am working on MPLS over Frame Relay. I would like to know how the MPLS > packet is encapsulated in the Frame Relay packet. I would like to know what > is the NLPID ( A field in the MPLS header) used for MPLS?. I couldn't get > the information about the NLPID anywhere. > > Thanks in Advance. > Regards > Ramki -- office ph: 091-40-3607619 From owner-mpls@UU.NET Sun Jan 5 10:21:33 2003 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06399 for ; Sun, 5 Jan 2003 10:21:33 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnwin14430 for ; Sun, 5 Jan 2003 15:24:41 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnwin08544; Sun, 5 Jan 2003 15:21:28 GMT Received: by mail-control.ash.ops.us.uu.net id QQnwin07891 for mpls-outgoing; Sun, 5 Jan 2003 15:21:07 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnwin07739 for ; Sun, 5 Jan 2003 15:21:00 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnwin28671 for ; Sun, 5 Jan 2003 15:20:21 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnwin07891 for ; Sun, 5 Jan 2003 15:20:20 GMT Received: from ns2.vivacenetworks.com by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: [64.221.212.135]) id QQnwin07816 for ; Sun, 5 Jan 2003 15:20:16 GMT Received: from AMALIS.vivacenetworks.com ([10.122.19.102]) by vivacenetworks.com with Microsoft SMTPSVC(5.0.2195.5329); Sun, 5 Jan 2003 07:20:13 -0800 Message-Id: <5.1.0.14.2.20030105101432.04980d98@po1.vivacenetworks.com> X-Sender: vivacenet\amalis@po1.vivacenetworks.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sun, 05 Jan 2003 10:20:09 -0500 To: "Ramakrishnan.R (Networking) - CTD, Chennai." , cheluvi@yahoo.com From: "Andrew G. Malis" Subject: Re: Frame Relay Encapsulation Cc: mpls@UU.NET In-Reply-To: <3E17C99C.79CA7DBB@yahoo.com> References: <55E277B99171E041ABF5F4B1C6DDCA0601097B61@haritha.hclt.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 05 Jan 2003 15:20:13.0958 (UTC) FILETIME=[F1E7A260:01C2B4CD] Sender: owner-mpls@UU.NET Precedence: bulk http://www.ietf.org/rfc/rfc3034.txt is the reference. See section 4 for the encapsulation. As you'll see, it's very straightforward. In particular, no NLPID (for multiprotocol identification) is required because FR VCs used as MPLS LSPs are dedicated to that use. That's why you couldn't find a specific reference. Cheers, Andy -------- At 1/5/2003 11:28 AM +0530, v.nagasrinivas wrote: >Hi Ramakrishnan, > > I think rfc 3034 is explaining how it will do ... I quickly >browsed and the following >is helping you. http://www.zvon.org/tmRFC/RFC3034/Output/chapter5.html > > >http://www.networksorcery.com/enp/protocol/framerelay.htm >and go through frf8.1 for some more information, not relating to MPLS. > >Thanks, >srinivas. > > >"Ramakrishnan.R (Networking) - CTD, Chennai." wrote: > > > Hello, > > I am working on MPLS over Frame Relay. I would like to know how the MPLS > > packet is encapsulated in the Frame Relay packet. I would like to know what > > is the NLPID ( A field in the MPLS header) used for MPLS?. I couldn't get > > the information about the NLPID anywhere. > > > > Thanks in Advance. > > Regards > > Ramki > >-- >office ph: 091-40-3607619 From owner-mpls@UU.NET Sun Jan 5 23:58:10 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA16100 for ; Sun, 5 Jan 2003 23:58:10 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnwkq06862 for ; Mon, 6 Jan 2003 05:01:21 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnwkq04416; Mon, 6 Jan 2003 05:00:15 GMT Received: by mail-control.ash.ops.us.uu.net id QQnwkq07313 for mpls-outgoing; Mon, 6 Jan 2003 05:00:01 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnwkp07186 for ; Mon, 6 Jan 2003 04:59:57 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnwkp13071 for ; Mon, 6 Jan 2003 04:58:13 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnwkp25992 for ; Mon, 6 Jan 2003 04:58:12 GMT Received: from mtsslvpngway by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: [202.54.39.98]) id QQnwkp25943 for ; Mon, 6 Jan 2003 04:58:10 GMT Received: (qmail 32094 invoked from network); 6 Jan 2003 05:01:18 -0000 Received: from unknown (HELO multitech.co.in) (192.168.10.1) by 0 with SMTP; 6 Jan 2003 05:01:18 -0000 Received: from multitech.co.in ([192.168.1.94]) by multitech.co.in (8.12.1/8.12.1) with ESMTP id h064tvnM004775 for ; Mon, 6 Jan 2003 10:25:57 +0530 Message-ID: <3E190B72.28884F88@multitech.co.in> Date: Mon, 06 Jan 2003 10:22:02 +0530 From: Atmesh Srivastava X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: mpls@UU.NET Subject: Label stacking Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi , I have a basic doubt in a Label Stacking scenario. In a PPP network , the label is encapsulated as 20 bit in a MPLS shim header encapsulation . Now for label stacking , say for a depth of 2 , are there 2 MPLS shim headers after the frame header and before the IP header , with the bottom header having the stack bit set ? If not so , then please clarify the encapsulation for label stacking ? Thanks , Regards , Atmesh -- Success is relative; the more success, the more relatives. -Anonymous From owner-mpls@UU.NET Mon Jan 6 03:09:00 2003 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28871 for ; Mon, 6 Jan 2003 03:08:59 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnwlc17118 for ; Mon, 6 Jan 2003 08:12:05 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnwlc06997; Mon, 6 Jan 2003 08:05:52 GMT Received: by mail-control.ash.ops.us.uu.net id QQnwlc02790 for mpls-outgoing; Mon, 6 Jan 2003 08:05:24 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnwlc02781 for ; Mon, 6 Jan 2003 08:05:19 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnwlc29940 for ; Mon, 6 Jan 2003 08:04:08 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnwlc21550 for ; Mon, 6 Jan 2003 08:04:07 GMT Received: from rtp-msg-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-msg-core-1.cisco.com [161.44.11.97]) id QQnwlc21537 for ; Mon, 6 Jan 2003 08:04:07 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id h0684gXt019754 for ; Mon, 6 Jan 2003 03:04:43 -0500 (EST) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id DAA28028 for ; Mon, 6 Jan 2003 03:04:02 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h06841109272 for mpls@uu.net; Mon, 6 Jan 2003 03:04:01 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnwlc26015 for ; Mon, 6 Jan 2003 08:02:32 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnwlc24705 for ; Mon, 6 Jan 2003 08:01:14 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnwlc04268 for ; Mon, 6 Jan 2003 08:01:14 GMT Received: from hoemail2.firewall.lucent.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: hoemail2.lucent.com [192.11.226.163]) id QQnwlc04256 for ; Mon, 6 Jan 2003 08:01:13 GMT Received: from ii0015exch002u.wins.lucent.com (h135-254-246-205.lucent.com [135.254.246.205]) by hoemail2.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id h0681A404137 for ; Mon, 6 Jan 2003 03:01:11 -0500 (EST) Received: from lucent.com (APALANI [135.254.220.107]) by ii0015exch002u.wins.lucent.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id ZDM7623H; Mon, 6 Jan 2003 13:31:08 +0530 Message-ID: <3E1937C3.5542CF64@lucent.com> Date: Mon, 06 Jan 2003 13:31:07 +0530 X-Sybari-Trust: 4c1b960e 6b12b198 dd87bb0f 00000128 From: Palanivelan A Organization: Lucent Technologies India LTD, Bangalore X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: mpls@UU.NET Subject: subscribe Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit From owner-mpls@UU.NET Mon Jan 6 05:18:57 2003 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00668 for ; Mon, 6 Jan 2003 05:18:57 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnwll20629 for ; Mon, 6 Jan 2003 10:22:08 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnwll17433; Mon, 6 Jan 2003 10:20:33 GMT Received: by mail-control.ash.ops.us.uu.net id QQnwll20218 for mpls-outgoing; Mon, 6 Jan 2003 10:20:13 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnwll20213 for ; Mon, 6 Jan 2003 10:20:07 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnwll02814 for ; Mon, 6 Jan 2003 10:19:49 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnwll16664 for ; Mon, 6 Jan 2003 10:19:48 GMT Received: from parsmtp2.rd.francetelecom.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: parsmtp2.rd.francetelecom.com [194.167.105.14]) id QQnwll16658 for ; Mon, 6 Jan 2003 10:19:47 GMT Received: from lanmhs30.rd.francetelecom.fr ([10.193.21.61]) by parsmtp2.rd.francetelecom.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 6 Jan 2003 11:19:47 +0100 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: Label stacking X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Mon, 6 Jan 2003 11:19:45 +0100 Message-ID: <1FB136FD10CE33409C882630E299F5BED0F8A2@lanmhs30.rd.francetelecom.fr> Thread-Topic: Label stacking Thread-Index: AcK1Uowmg3df9wAbTl2c8LxsndzZCwAGiguQ From: "LE ROUX Jean-Louis FTRD/DAC/LAN" To: "Atmesh Srivastava" Cc: X-OriginalArrivalTime: 06 Jan 2003 10:19:47.0199 (UTC) FILETIME=[238840F0:01C2B56D] Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id FAA00668 Hi Atmesh, This is correct, as specified in RFC 3032 section 2.1: 1. Bottom of Stack (S) This bit is set to one for the last entry in the label stack (i.e., for the bottom of the stack), and zero for all other label stack entries. Regards JL -----Message d'origine----- De : Atmesh Srivastava [mailto:atmesh@multitech.co.in] Envoye : lundi 6 janvier 2003 05:52 A : mpls@UU.NET Objet : Label stacking Hi , I have a basic doubt in a Label Stacking scenario. In a PPP network , the label is encapsulated as 20 bit in a MPLS shim header encapsulation . Now for label stacking , say for a depth of 2 , are there 2 MPLS shim headers after the frame header and before the IP header , with the bottom header having the stack bit set ? If not so , then please clarify the encapsulation for label stacking ? Thanks , Regards , Atmesh -- Success is relative; the more success, the more relatives. -Anonymous From owner-mpls@UU.NET Mon Jan 6 07:22:35 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01945 for ; Mon, 6 Jan 2003 07:22:35 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnwlt04266 for ; Mon, 6 Jan 2003 12:25:47 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnwlt01352; Mon, 6 Jan 2003 12:24:05 GMT Received: by mail-control.ash.ops.us.uu.net id QQnwlt05773 for mpls-outgoing; Mon, 6 Jan 2003 12:23:53 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnwlt05768 for ; Mon, 6 Jan 2003 12:23:44 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnwlt11517 for ; Mon, 6 Jan 2003 12:22:06 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnwlt00064 for ; Mon, 6 Jan 2003 12:22:05 GMT Received: from rtp-msg-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-msg-core-1.cisco.com [161.44.11.97]) id QQnwlt00049 for ; Mon, 6 Jan 2003 12:22:04 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id h06CMgE6007446 for ; Mon, 6 Jan 2003 07:22:43 -0500 (EST) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id HAA05329 for ; Mon, 6 Jan 2003 07:22:02 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h06CM1l23426 for mpls@uu.net; Mon, 6 Jan 2003 07:22:01 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnwlt05538 for ; Mon, 6 Jan 2003 12:20:56 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnwlt14104 for ; Mon, 6 Jan 2003 12:20:38 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnwlt12317 for ; Mon, 6 Jan 2003 12:20:37 GMT Received: from sj-msg-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQnwlt12302 for ; Mon, 6 Jan 2003 12:20:37 GMT Received: from asimha-u10.cisco.com (asimha-u10.cisco.com [64.102.48.65]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id h06CKOFp011302; Mon, 6 Jan 2003 04:20:24 -0800 (PST) Received: (asimha@localhost) by asimha-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id HAA06264; Mon, 6 Jan 2003 07:20:24 -0500 (EST) Date: Mon, 6 Jan 2003 07:20:24 -0500 From: Ajay Simha To: Atmesh Srivastava Cc: mpls@UU.NET Subject: Re: Label stacking Message-ID: <20030106122024.GJ5361@cisco.com> References: <3E190B72.28884F88@multitech.co.in> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3E190B72.28884F88@multitech.co.in> User-Agent: Mutt/1.4i Sender: owner-mpls@UU.NET Precedence: bulk On Mon Jan 06 10:22:02 2003, Atmesh Srivastava wrote: > Hi , > > I have a basic doubt in a Label Stacking scenario. > > In a PPP network , the label is encapsulated as 20 bit in a MPLS shim > header encapsulation . Now for label stacking , say for a depth of 2 , > are there 2 MPLS shim headers after the frame header and before the IP > header , with the bottom header having the stack bit set ? yes. -ajay > > If not so , then please clarify the encapsulation for label stacking ? > > Thanks , > > Regards , > Atmesh > > > > > -- > Success is relative; the more success, the more relatives. -Anonymous > From owner-mpls@UU.NET Mon Jan 6 09:42:01 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04309 for ; Mon, 6 Jan 2003 09:42:00 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnwmd07673 for ; Mon, 6 Jan 2003 14:45:07 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnwmc05727; Mon, 6 Jan 2003 14:43:58 GMT Received: by mail-control.ash.ops.us.uu.net id QQnwmc25400 for mpls-outgoing; Mon, 6 Jan 2003 14:43:31 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnwmc25391 for ; Mon, 6 Jan 2003 14:43:23 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnwmc14132 for ; Mon, 6 Jan 2003 14:40:05 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnwmc03632 for ; Mon, 6 Jan 2003 14:40:05 GMT Received: from rtp-msg-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-msg-core-1.cisco.com [161.44.11.97]) id QQnwmc03622 for ; Mon, 6 Jan 2003 14:40:05 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id h06Eehq0021385 for ; Mon, 6 Jan 2003 09:40:43 -0500 (EST) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id JAA11324 for ; Mon, 6 Jan 2003 09:40:02 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h06Ee2u02080 for mpls@uu.net; Mon, 6 Jan 2003 09:40:02 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnwmc24877 for ; Mon, 6 Jan 2003 14:39:16 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnwmc12439 for ; Mon, 6 Jan 2003 14:38:10 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnwmc02538 for ; Mon, 6 Jan 2003 14:38:10 GMT Received: from rtp-msg-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-msg-core-1.cisco.com [161.44.11.97]) id QQnwmc02531 for ; Mon, 6 Jan 2003 14:38:09 GMT Received: from pilgrim.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id h06EcVLk021085; Mon, 6 Jan 2003 09:38:31 -0500 (EST) Received: from tappan-w2k01.cisco.com ([10.83.99.138]) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id JAA07357; Mon, 6 Jan 2003 09:37:49 -0500 (EST) Message-Id: <4.3.2.7.2.20030106092933.0285dc40@pilgrim.cisco.com> X-Sender: tappan@pilgrim.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 06 Jan 2003 09:37:48 -0500 To: "Andrew G. Malis" From: Dan Tappan Subject: Re: Frame Relay Encapsulation Cc: mpls@UU.NET In-Reply-To: <5.1.0.14.2.20030105101432.04980d98@po1.vivacenetworks.com> References: <3E17C99C.79CA7DBB@yahoo.com> <55E277B99171E041ABF5F4B1C6DDCA0601097B61@haritha.hclt.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk At 10:20 AM 1/5/2003 -0500, Andrew G. Malis wrote: >http://www.ietf.org/rfc/rfc3034.txt is the reference. See section 4 for >the encapsulation. As you'll see, it's very straightforward. > >In particular, no NLPID (for multiprotocol identification) is required >because FR VCs used as MPLS LSPs are dedicated to that use. That's why >you couldn't find a specific reference. While the above is technically correct, I don't know of anyone who has actually implemented rfc3034. A more common approach for carrying MPLS across a FR link is to follow rfc2427: using the LLC/SNAP (section 4.1) encapsulation above the rfc3032 encapsulation. >Cheers, >Andy > >-------- > >At 1/5/2003 11:28 AM +0530, v.nagasrinivas wrote: > >>Hi Ramakrishnan, >> >> I think rfc 3034 is explaining how it will do ... I quickly >>browsed and the following >>is helping you. http://www.zvon.org/tmRFC/RFC3034/Output/chapter5.html >> >> >>http://www.networksorcery.com/enp/protocol/framerelay.htm >>and go through frf8.1 for some more information, not relating to MPLS. >> >>Thanks, >>srinivas. >> >> >>"Ramakrishnan.R (Networking) - CTD, Chennai." wrote: >> >> > Hello, >> > I am working on MPLS over Frame Relay. I would like to know how the MPLS >> > packet is encapsulated in the Frame Relay packet. I would like to know >> what >> > is the NLPID ( A field in the MPLS header) used for MPLS?. I couldn't get >> > the information about the NLPID anywhere. >> > >> > Thanks in Advance. >> > Regards >> > Ramki >> >>-- >>office ph: 091-40-3607619 > From owner-mpls@UU.NET Mon Jan 6 10:23:52 2003 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05384 for ; Mon, 6 Jan 2003 10:23:51 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnwmf19768 for ; Mon, 6 Jan 2003 15:26:52 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnwmf13055; Mon, 6 Jan 2003 15:23:23 GMT Received: by mail-control.ash.ops.us.uu.net id QQnwmf19763 for mpls-outgoing; Mon, 6 Jan 2003 15:22:54 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnwmf19756 for ; Mon, 6 Jan 2003 15:22:46 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnwmf07562 for ; Mon, 6 Jan 2003 15:18:13 GMT From: ananth.nagarajan@mail.sprint.com Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnwmf22150 for ; Mon, 6 Jan 2003 15:18:12 GMT Received: from damgwp01.corp.sprint.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: parker2.sprint.com [199.14.91.106]) id QQnwmf22141 for ; Mon, 6 Jan 2003 15:18:12 GMT Received: from kcmgwp02.corp.sprint.com (kcmgwp02 [10.185.6.93]) by damgwp01.corp.sprint.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id h06FPr223158; Mon, 6 Jan 2003 09:25:53 -0600 (CST) Received: from kcopmp04.corp.sprint.com (kcopmp04m [10.79.2.196]) by kcmgwp02.corp.sprint.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id h06FIAw19210; Mon, 6 Jan 2003 09:18:10 -0600 (CST) Received: from localhost (root@localhost) by kcopmp04.corp.sprint.com (8.8.6 (PHNE_17190)/8.8.6) with ESMTP id JAA20848; Mon, 6 Jan 2003 09:18:08 -0600 (CST) X-OpenMail-Hops: 1 Date: Mon, 6 Jan 2003 09:18:07 -0600 Message-Id: Subject: RE: Re: draft-rosen-mpls-in-ip-or-gre-00.txt MIME-Version: 1.0 TO: mpls@UU.NET CC: sob@harvard.edu Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline; filename="BDY.TXT" ;Creation-Date="Mon, 6 Jan 2003 09:18:07 -0600" Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit This should definitely be a WG doc. Ananth > > > Loa Andersson wrote: > > > >>All, > >> > >>the draft draft-rosen-mpls-in-ip-or-gre-00.txt was > presented in Atlanta, > >>the reception was positive, and there has been no > discussion after that > >>on the mailing list. > >> > >>Based on prior response to the mailing list, the response at the > >>Atlanta meeting and the lack of response after the meeting, it is > >>the wg chairs intention to make this draft a wg document. > >> > >>Please comment before January 7th. > >> > >>Loa and George > >> > >>-- > >>Loa Andersson > >> > >>Mobile +46 739 81 21 64 > >>Email loa@pi.se > > > > > -- > Ping Pan, Ph.D. > > Principle Engineer > Core Networking Voice: (408)-655-6547 > CIENA Corp. Fax: (408)-366-4900 > > From owner-mpls@UU.NET Mon Jan 6 10:43:45 2003 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05789 for ; Mon, 6 Jan 2003 10:43:44 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnwmh10188 for ; Mon, 6 Jan 2003 15:46:57 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnwmg03627; Mon, 6 Jan 2003 15:43:22 GMT Received: by mail-control.ash.ops.us.uu.net id QQnwmg20668 for mpls-outgoing; Mon, 6 Jan 2003 15:42:54 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnwmg20661 for ; Mon, 6 Jan 2003 15:42:47 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnwmg05388 for ; Mon, 6 Jan 2003 15:37:04 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnwmg14332 for ; Mon, 6 Jan 2003 15:37:04 GMT Received: from rtp-msg-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-msg-core-1.cisco.com [161.44.11.97]) id QQnwmg14323 for ; Mon, 6 Jan 2003 15:37:03 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id h06Fbgki000749 for ; Mon, 6 Jan 2003 10:37:43 -0500 (EST) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA15504 for ; Mon, 6 Jan 2003 10:37:01 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h06Fb1n07212 for mpls@uu.net; Mon, 6 Jan 2003 10:37:01 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnwmg20440 for ; Mon, 6 Jan 2003 15:36:27 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnwmg29864 for ; Mon, 6 Jan 2003 15:34:54 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnwmg04622 for ; Mon, 6 Jan 2003 15:34:53 GMT Received: from sith.maoz.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sith.maoz.com [205.167.76.10]) id QQnwmg04595 for ; Mon, 6 Jan 2003 15:34:53 GMT Received: (from dmm@localhost) by sith.maoz.com (8.12.6/8.12.6) id h06FZJPw027335; Mon, 6 Jan 2003 07:35:19 -0800 Date: Mon, 6 Jan 2003 07:35:19 -0800 From: David Meyer To: ananth.nagarajan@mail.sprint.com Cc: mpls@UU.NET, sob@harvard.edu Subject: Re: draft-rosen-mpls-in-ip-or-gre-00.txt Message-ID: <20030106073519.A27332@sprint.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from ananth.nagarajan@mail.sprint.com on Mon, Jan 06, 2003 at 09:18:07AM -0600 Sender: owner-mpls@UU.NET Precedence: bulk >> This should definitely be a WG doc. Agree. Dave From owner-mpls@UU.NET Mon Jan 6 11:23:53 2003 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06520 for ; Mon, 6 Jan 2003 11:23:53 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnwmj14221 for ; Mon, 6 Jan 2003 16:27:04 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnwmj10991; Mon, 6 Jan 2003 16:25:35 GMT Received: by mail-control.ash.ops.us.uu.net id QQnwmj12457 for mpls-outgoing; Mon, 6 Jan 2003 16:25:18 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnwmj12449 for ; Mon, 6 Jan 2003 16:25:08 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnwmj01599 for ; Mon, 6 Jan 2003 16:24:51 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnwmj11085 for ; Mon, 6 Jan 2003 16:24:51 GMT Received: from zcars04f.nortelnetworks.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: zcars04f.nortelnetworks.com [47.129.242.57]) id QQnwmj11079 for ; Mon, 6 Jan 2003 16:24:50 GMT Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h06GOcY08487 for ; Mon, 6 Jan 2003 11:24:39 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 6 Jan 2003 11:24:39 -0500 Message-ID: From: "David Allan" To: mpls@UU.NET Subject: RE: Re: draft-rosen-mpls-in-ip-or-gre-00.txt Date: Mon, 6 Jan 2003 11:24:36 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: owner-mpls@UU.NET Precedence: bulk It should be an WG doc... cheers Dave > Loa Andersson wrote: > >>All, >> >>the draft draft-rosen-mpls-in-ip-or-gre-00.txt was presented in Atlanta, >>the reception was positive, and there has been no discussion after that >>on the mailing list. >> >>Based on prior response to the mailing list, the response at the >>Atlanta meeting and the lack of response after the meeting, it is >>the wg chairs intention to make this draft a wg document. >> >>Please comment before January 7th. >> >>Loa and George >> >>-- >>Loa Andersson >> >>Mobile +46 739 81 21 64 >>Email loa@pi.se > From owner-mpls@UU.NET Mon Jan 6 11:43:55 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06944 for ; Mon, 6 Jan 2003 11:43:55 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnwml02878 for ; Mon, 6 Jan 2003 16:47:08 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnwml01502; Mon, 6 Jan 2003 16:46:29 GMT Received: by mail-control.ash.ops.us.uu.net id QQnwml14288 for mpls-outgoing; Mon, 6 Jan 2003 16:46:00 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnwml14283 for ; Mon, 6 Jan 2003 16:45:54 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnwml06527 for ; Mon, 6 Jan 2003 16:45:15 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnwml29847 for ; Mon, 6 Jan 2003 16:45:15 GMT Received: from mailgate.pit.comms.marconi.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6]) id QQnwml29843 for ; Mon, 6 Jan 2003 16:45:14 GMT Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA13751 for ; Mon, 6 Jan 2003 11:45:12 -0500 (EST) Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA06811 for ; Mon, 6 Jan 2003 11:45:13 -0500 (EST) Message-ID: <3E19B2A6.1090907@marconi.com> Date: Mon, 06 Jan 2003 11:45:26 -0500 From: David Charlap Organization: Marconi, Vienna VA User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en, he MIME-Version: 1.0 To: IETF MPLS List Subject: Re: draft-rosen-mpls-in-ip-or-gre-00.txt References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit > the draft draft-rosen-mpls-in-ip-or-gre-00.txt was presented in Atlanta, > the reception was positive, and there has been no discussion after that > on the mailing list. > > Based on prior response to the mailing list, the response at the > Atlanta meeting and the lack of response after the meeting, it is > the wg chairs intention to make this draft a wg document. I'll also vote for making this a WG doc. -- David From owner-mpls@UU.NET Mon Jan 6 16:44:00 2003 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15712 for ; Mon, 6 Jan 2003 16:43:59 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnwnf15283 for ; Mon, 6 Jan 2003 21:47:10 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnwnf14918; Mon, 6 Jan 2003 21:46:59 GMT Received: by mail-control.ash.ops.us.uu.net id QQnwnf09739 for mpls-outgoing; Mon, 6 Jan 2003 21:46:27 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnwnf09727 for ; Mon, 6 Jan 2003 21:46:21 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnwne07994 for ; Mon, 6 Jan 2003 21:44:05 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnwne11140 for ; Mon, 6 Jan 2003 21:44:05 GMT Received: from ns2.vivacenetworks.com by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: [64.221.212.135]) id QQnwne10989 for ; Mon, 6 Jan 2003 21:44:00 GMT Received: from AMALIS.vivacenetworks.com ([10.5.20.13]) by vivacenetworks.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 6 Jan 2003 13:43:48 -0800 Message-Id: <5.1.0.14.2.20030106163318.023e25d0@po1.vivacenetworks.com> X-Sender: vivacenet\amalis@po1.vivacenetworks.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 06 Jan 2003 16:43:44 -0500 To: Dan Tappan From: "Andrew G. Malis" Subject: Re: Frame Relay Encapsulation Cc: mpls@UU.NET In-Reply-To: <4.3.2.7.2.20030106092933.0285dc40@pilgrim.cisco.com> References: <5.1.0.14.2.20030105101432.04980d98@po1.vivacenetworks.com> <3E17C99C.79CA7DBB@yahoo.com> <55E277B99171E041ABF5F4B1C6DDCA0601097B61@haritha.hclt.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 06 Jan 2003 21:43:48.0712 (UTC) FILETIME=[B22E2680:01C2B5CC] Sender: owner-mpls@UU.NET Precedence: bulk Dan, It depends on the usage - if you're using FR switches as LSRs, and using MPLS as the control plane to allocate the DLCIs, then you must use RFC 3034. However, if you're simply tunneling MPLS packets through a FR network which uses a native control plane, or perhaps FRF.5 across an ATM backbone and control plane, then you are correct. I was aware of a couple of implementations of RFC 3034 at the time we were working on the draft. Unfortunately, one of the places has closed up shop, and the other seems to have been either discontinued or never made it into a shipping release. It looks like the RFC may never make it past Proposed .... Cheers, Andy ------- At 1/6/2003 09:37 AM -0500, Dan Tappan wrote: >At 10:20 AM 1/5/2003 -0500, Andrew G. Malis wrote: >>http://www.ietf.org/rfc/rfc3034.txt is the reference. See section 4 for >>the encapsulation. As you'll see, it's very straightforward. >> >>In particular, no NLPID (for multiprotocol identification) is required >>because FR VCs used as MPLS LSPs are dedicated to that use. That's why >>you couldn't find a specific reference. > >While the above is technically correct, I don't know of anyone who has >actually implemented rfc3034. > >A more common approach for carrying MPLS across a FR link is to follow >rfc2427: using the LLC/SNAP (section 4.1) encapsulation above the rfc3032 >encapsulation. > >>Cheers, >>Andy From owner-mpls@UU.NET Mon Jan 6 21:22:21 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21694 for ; Mon, 6 Jan 2003 21:22:21 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnwnx10880 for ; Tue, 7 Jan 2003 02:25:30 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnwnx10775; Tue, 7 Jan 2003 02:25:27 GMT Received: by mail-control.ash.ops.us.uu.net id QQnwnx02402 for mpls-outgoing; Tue, 7 Jan 2003 02:25:08 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnwnx02397 for ; Tue, 7 Jan 2003 02:25:03 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnwnx16366 for ; Tue, 7 Jan 2003 02:24:51 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnwnx26704 for ; Tue, 7 Jan 2003 02:24:51 GMT Received: from kanmx1.ca.alcatel.com by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: kanfw1.ottawa.alcatel.ca [192.75.23.69]) id QQnwnx26698 for ; Tue, 7 Jan 2003 02:24:50 GMT Received: (qmail 29660 invoked from network); 7 Jan 2003 02:31:20 -0000 Received: (ofmipd 138.120.118.71); 7 Jan 2003 02:30:58 -0000 Received: from alcatel.com ([138.120.250.6]) by kanmail01.ca.newbridge.com (Netscape Messaging Server 3.6) with ESMTP id AAA4111; Mon, 6 Jan 2003 21:24:47 -0500 Date: 6 Jan 2003 21:24:29 -0500 Message-ID: <3E1A3A5D.9655709F@alcatel.com> From: "Cheng-Yin Lee" Reply-To: Cheng-Yin.Lee@alcatel.com To: curtis@fictitious.org Cc: "'mpls@UU.NET'" X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 Subject: Re: Some suggestions for LSP Ping References: <200301041734.MAA49478@workhorse.fictitious.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Curtis, Thanks for your analysis of the suggestions. Some comments at the end and a quick question. Curtis Villamizar wrote: > > In message <3E161188.9F92601@alcatel.com>, "Cheng-Yin Lee" writes: > > Hello, > > Some suggestions that may be helpful for LSP Ping. > > It seems one could precede an MPLS Ping with the LSP "payload" header to > > allow the test packet to be (deterministically) exercised by data path > > and use Router Alert Option to allow the egress to intercept the LSP > > Ping message : > > > > 1) For an LSP with IP traffic, an MPLS Ping may contain e.g.: > > a) Payload header > > - IP dst = 192.168.1.1 > > - Protocol ID = IP or alternatively MPLS_PING_PROT > > - Option = Router Alert (or alternatively a new Option, e.g. class > > "debugging & measurement") OR alternatively set TTL=1 > > b) IP header > > IP dst = e.g. 127.0.0.1/224.0.0.1 (a specific IP address allowing a > > local IP/UDP > > protocol stack to process the message) > > c) UDP header > > d) MPLS Ping message > > [If Protocol ID is MPLS_PING_PROT, the inner header is the MPLS Ping > > message, no IP & UDP header, but may need checksum in MPLS Ping message] > > IP and UDP were picked. With that choice no MPLS Ping checksum is > needed. > > > (b)-(d) are the same as in LSP Ping draft, unless stated otherwise > > above. > > The Router Alert Option is intended for the egress LSR to intercept the > > MPLS Ping > > message (existing implementations may vary). Using TTL=1 instead may > > have issues as raised in previous email thread "Last call on LSP Ping" > > Destination is in 127/8 and TTL=1 so it can't be forwarded unless the > action taken by the egress LSR on a VPN or PW label is to forward to a > specific interface unconditionally. Then router alert in the MPLS > payload won't help either. > > > If hashing includes Protocol ID, the above require changes such that > > Protocol ID is set to the actual LSP "payload" Protocol ID, and another > > field e.g. Router Alert Value or new Option class indicates/implies how > > to decode rest of message. > > The above will not work as is if hashing on port is required. > > If source address, protocol ID and ports are fixed, then a set of > destination addresses can be found to exercise a specific path. > > > 2) For an LSP with inner label, an MPLS Ping may contain eg: (I think > > a-b may be similar to what Curtis have proposed for labels) > > a) Payload header > > - VC label = L > > - This is suggested by Curtis/Shahram? > > S' bit not bottom of stack (as a few people pointed out, this requires > > data path change) > > OR alternatively TTL=1 (Using TTL may have issues as raised in past > > email thread "Last call on LSP Ping" and may be trickier, lower layer > > TTL setting etc) > > b) IPv4 Explicit NULL label ("indicates that the label stack must be > > popped, and the forwarding of the packet must then be based on the IPv4 > > header") > > c) IP header > > IP dst = eg. 127.0.0.1/224.0.0.1 > > d) UDP header > > e) MPLS Ping message > > The S bit is always at the bottom of the stack. The VPN label is no > longer on the bottom, but an Explicit NULL label follows. What the > egress LSR should do with this is so far undefined. So far no one has > indicated that their router could not either 1) disable any > unconditional forwarding based on the VPN label and check the next > label or 2) process the packet on the egress LSR based on TTL expire > of TTL in the VPN shim. > > > (c)-(e) are as specified in LSP Ping draft, with the exception of the > > field(s) listed above. > > If the inner label contains IP traffic, (2b-2e) may be replaced by > > (1a-1d), > > (2a) 'S' bit is bottom of stack or TTL=1. > > No one has ever suggested that we use the multicast range (224.0.0.1). > > > Some useful functions when including the "payload" hdr and using Router > > Alert : > > - test packet can be exercised on the same path (including ECMP) as the > > data traffic (by data path) > > - not necessary for MPLS ping to assume how ECMP is done in LSRs > > - not necessary to use 127/8 address range > > - avoiding some TTL issues > > - not necessary to have intermediate LSRs provide ECMP related > > information > > > > There will be some limitations, e.g. can exercise only one path with one > > LSP Ping. > > Router alert would eliminate the need to use a destination within > 127/8 but has no other advantage. The same procedure is needed to > exercise multipath only using a range of real destination addresses > may be much worse. See below. > > > Other opinions and issues? Anything I missed? > > Hope some of these are helpful. > > Lets try to make progress and *not* propose arbitrary changes for no > good reason. > > Proposing to use router alert to eliminate the need to use 127/8 is of > use only if people regard using 127/8 as an immense sacrilege. Since > the source address must be an address of the router sending MPLS ping, > there is still a need to pick from a range to exercise all paths. It > is probably a lot better to pick from a range of 127/8 than some other > range where a non-MPLS-ping capble router at the egress would happily > deliver the MPLS-ping traffic to the final IP destination. > > There would be a small advantage to ignoring both the IP source and > destination address in that for a report of "I can't get there from > here" the ISP can put "here" in the source and "there" in the > destination, add router alert, and put the MPLS-ping return address in > the payload. This is a minor advantage but may be offset if there is > a possibility that the test traffic actually gets delivered to the > destination and the destination sends ICMP back at the source, either > of which could interpret this as a DoS attack and start filtering. > That would compund the original problem and make it harder overall to > solve. I think if the egress is not MPLS Ping capable, there is always a chance of the MPLS Ping leaking to the customer, unless a provider filter egress traffic (MPLS Ping traffic). For e.g. in (2) above, where the inner label may be hashed, if we can't use 'S' bit to indicate whether there is another label underneath the inner label because egress does not check the 'S' bit, using LSP TTT=1 (in the hope of intercepting the LSP Ping at egress) would be a problem as well if the LSP mode is such that the egress copies the TTL of the outer label to the inner label. Since the TTL does not expire, the LSP Ping message would be forwarded to customer. In the long term, forwarding should probably be improved such that transport layer and control information are appropriately processed [e.g. no "residue" header or control frames should be forwarded without prior processing/examination by PE]. Meanwhile (especially for MPLS incapable egress), is it feasible to somehow filter traffic that is not supposed to go to customers? Regarding ECMP, for e.g. to test connectivity between Src A and Dst B, the appropriate path would be verified if the IP src and dst of the test packet are set to Src A and Dst B, respectively (hashing on SA & DA). [Add Router Alert Option to "catch" the test packet at egress]. If "the destination IP address is a (randomly chosen) address from 127/8" instead, how is the appropriate path for Src A & Dst B verified? I think I am missing something here. Could you kindly elaborate a little on the procedure to accomplish this or provide some pointers, pls? Thanks, Cheng-Yin p.s I have intermittent email access this week. From owner-mpls@UU.NET Mon Jan 6 21:48:01 2003 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22009 for ; Mon, 6 Jan 2003 21:48:01 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnwnz00462 for ; Tue, 7 Jan 2003 02:51:13 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnwnz00307; Tue, 7 Jan 2003 02:51:07 GMT Received: by mail-control.ash.ops.us.uu.net id QQnwnz04850 for mpls-outgoing; Tue, 7 Jan 2003 02:50:30 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnwnz04836 for ; Tue, 7 Jan 2003 02:50:21 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnwnz17691 for ; Tue, 7 Jan 2003 02:46:07 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnwnz10515 for ; Tue, 7 Jan 2003 02:46:06 GMT Received: from rtp-msg-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-msg-core-1.cisco.com [161.44.11.97]) id QQnwnz10485 for ; Tue, 7 Jan 2003 02:46:05 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id h072khaT024236 for ; Mon, 6 Jan 2003 21:46:44 -0500 (EST) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id VAA02687 for ; Mon, 6 Jan 2003 21:46:02 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h072k2414148 for mpls@uu.net; Mon, 6 Jan 2003 21:46:02 -0500 (EST) Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnwnz04344 for ; Tue, 7 Jan 2003 02:45:09 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnwny17055 for ; Tue, 7 Jan 2003 02:44:47 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnwny28703 for ; Tue, 7 Jan 2003 02:44:47 GMT Received: from workhorse.fictitious.org by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: workhorse.fictitious.org [209.150.1.230]) id QQnwny28697 for ; Tue, 7 Jan 2003 02:44:46 GMT Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id VAA62993; Mon, 6 Jan 2003 21:41:02 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200301070241.VAA62993@workhorse.fictitious.org> To: Cheng-Yin.Lee@alcatel.com cc: curtis@fictitious.org, "'mpls@UU.NET'" Reply-To: curtis@fictitious.org Subject: Re: Some suggestions for LSP Ping In-reply-to: Your message of "06 Jan 2003 21:24:29 EST." <3E1A3A5D.9655709F@alcatel.com> Date: Mon, 06 Jan 2003 21:41:02 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <3E1A3A5D.9655709F@alcatel.com>, "Cheng-Yin Lee" writes: > I think if the egress is not MPLS Ping capable, there is always a chance > of the MPLS Ping leaking to the customer, unless a provider filter > egress traffic (MPLS Ping traffic). For e.g. in (2) above, where the > inner label may be hashed, if we can't use 'S' bit to indicate whether > there is another label underneath the inner label because egress does > not check the 'S' bit, using LSP TTT=1 (in the hope of intercepting the > LSP Ping at egress) would be a problem as well if the LSP mode is such > that the egress copies the TTL of the outer label to the inner label. > Since the TTL does not expire, the LSP Ping message would be forwarded > to customer. This is true for VPN tunnels. There is always the change that a non-MPLS ping capable router will deliver the packet to the next router. That is different from delivering to the endpoint. If the destination is a real address it goes all the way to the final destination. If the destination is 127/8 it goes no further than one router into the customer LAN (which may be one too many). This problem only exists for MPLS-ping over VPN. There is no reason to make the problem worse by using a destination address not in 127/8. > In the long term, forwarding should probably be improved such that > transport layer and control information are appropriately processed > [e.g. no "residue" header or control frames should be forwarded without > prior processing/examination by PE]. Meanwhile (especially for MPLS > incapable egress), is it feasible to somehow filter traffic that is not > supposed to go to customers? If the CE router is not MPLS capable it will dump all non IP including a packet with MPLS explicit null label. Otherwise it can just filter out any MPLS traffic on its IP VPN. If sending MPLS over the VPN. If the traffic is destined to 127/8 and comes from the provider that could also be filtered. If the CE router is MPLS-ping incapable it will just toss the packet anyway and try to send an ICMP. > Regarding ECMP, for e.g. to test connectivity between Src A and Dst B, > the appropriate path would be verified if the IP src and dst of the test > packet are set to Src A and Dst B, respectively (hashing on SA & DA). > [Add Router Alert Option to "catch" the test packet at egress]. If "the > destination IP address is a (randomly chosen) address from 127/8" > instead, how is the appropriate path for Src A & Dst B verified? I > think I am missing something here. Could you kindly elaborate a little > on the procedure to accomplish this or provide some pointers, pls? You test all paths. We went through that in great detail last month. Check the mailing list archives for "suggested added text for multipath", "suggested clarification to intro parts", "suggested clarification to section 4". > Thanks, > Cheng-Yin > p.s I have intermittent email access this week. Curtis From owner-mpls@UU.NET Tue Jan 7 04:13:40 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07596 for ; Tue, 7 Jan 2003 04:13:39 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnwoz22904 for ; Tue, 7 Jan 2003 09:16:52 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnwoz22813; Tue, 7 Jan 2003 09:16:49 GMT Received: by mail-control.ash.ops.us.uu.net id QQnwoz11635 for mpls-outgoing; Tue, 7 Jan 2003 09:16:23 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnwoz11627 for ; Tue, 7 Jan 2003 09:16:21 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnwoy21838 for ; Tue, 7 Jan 2003 09:12:49 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnwoy22240 for ; Tue, 7 Jan 2003 09:12:49 GMT Received: from ganesh.ctd.hctech.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [202.54.64.2]) id QQnwoy22227 for ; Tue, 7 Jan 2003 09:12:47 GMT Received: by GANESH with Internet Mail Service (5.5.2653.19) id ; Tue, 7 Jan 2003 14:57:02 +0530 Message-ID: <55E277B99171E041ABF5F4B1C6DDCA06010D3E58@haritha.hclt.com> From: "Ramakrishnan.R (Networking) - CTD, Chennai." To: "Andrew G. Malis" , Dan Tappan Cc: mpls@UU.NET Subject: RE: Frame Relay Encapsulation Date: Tue, 7 Jan 2003 14:45:04 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Hi, In case where FR Switches used as LSRs, what is the encapsulation mechanism used? RFC3034 (or) RFC 2427? Regards Ramki -----Original Message----- From: Andrew G. Malis [mailto:Andy.Malis@vivacenetworks.com] Sent: Tuesday, January 07, 2003 3:14 AM To: Dan Tappan Cc: mpls@UU.NET Subject: Re: Frame Relay Encapsulation Dan, It depends on the usage - if you're using FR switches as LSRs, and using MPLS as the control plane to allocate the DLCIs, then you must use RFC 3034. However, if you're simply tunneling MPLS packets through a FR network which uses a native control plane, or perhaps FRF.5 across an ATM backbone and control plane, then you are correct. I was aware of a couple of implementations of RFC 3034 at the time we were working on the draft. Unfortunately, one of the places has closed up shop, and the other seems to have been either discontinued or never made it into a shipping release. It looks like the RFC may never make it past Proposed .... Cheers, Andy ------- At 1/6/2003 09:37 AM -0500, Dan Tappan wrote: >At 10:20 AM 1/5/2003 -0500, Andrew G. Malis wrote: >>http://www.ietf.org/rfc/rfc3034.txt is the reference. See section 4 for >>the encapsulation. As you'll see, it's very straightforward. >> >>In particular, no NLPID (for multiprotocol identification) is required >>because FR VCs used as MPLS LSPs are dedicated to that use. That's why >>you couldn't find a specific reference. > >While the above is technically correct, I don't know of anyone who has >actually implemented rfc3034. > >A more common approach for carrying MPLS across a FR link is to follow >rfc2427: using the LLC/SNAP (section 4.1) encapsulation above the rfc3032 >encapsulation. > >>Cheers, >>Andy From owner-mpls@UU.NET Tue Jan 7 09:30:02 2003 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14924 for ; Tue, 7 Jan 2003 09:30:02 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnwpu11937 for ; Tue, 7 Jan 2003 14:33:16 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnwpu11865; Tue, 7 Jan 2003 14:33:13 GMT Received: by mail-control.ash.ops.us.uu.net id QQnwpu06241 for mpls-outgoing; Tue, 7 Jan 2003 14:32:45 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnwpu06234 for ; Tue, 7 Jan 2003 14:32:27 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnwpu07416 for ; Tue, 7 Jan 2003 14:32:21 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnwpu11074 for ; Tue, 7 Jan 2003 14:32:20 GMT Received: from ns2.vivacenetworks.com by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: [64.221.212.135]) id QQnwpu10810 for ; Tue, 7 Jan 2003 14:32:01 GMT Received: from AMALIS.vivacenetworks.com ([10.5.20.13]) by vivacenetworks.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 7 Jan 2003 06:31:44 -0800 Message-Id: <5.1.0.14.2.20030107093023.0d604858@po1.vivacenetworks.com> X-Sender: vivacenet\amalis@po1.vivacenetworks.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 07 Jan 2003 09:31:41 -0500 To: "Ramakrishnan.R (Networking) - CTD, Chennai." From: "Andrew G. Malis" Subject: RE: Frame Relay Encapsulation Cc: "Andrew G. Malis" , Dan Tappan , mpls@UU.NET In-Reply-To: <55E277B99171E041ABF5F4B1C6DDCA06010D3E58@haritha.hclt.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 07 Jan 2003 14:31:44.0961 (UTC) FILETIME=[80D56B10:01C2B659] Sender: owner-mpls@UU.NET Precedence: bulk Ramki, In that case, you must use RFC 3034. Cheers, Andy ------- At 1/7/2003 02:45 PM +0530, Ramakrishnan.R (Networking) - CTD, Chennai. wrote: >Hi, > In case where FR Switches used as LSRs, what is the encapsulation >mechanism used? RFC3034 (or) RFC 2427? > >Regards >Ramki > >-----Original Message----- >From: Andrew G. Malis [mailto:Andy.Malis@vivacenetworks.com] >Sent: Tuesday, January 07, 2003 3:14 AM >To: Dan Tappan >Cc: mpls@UU.NET >Subject: Re: Frame Relay Encapsulation > > >Dan, > >It depends on the usage - if you're using FR switches as LSRs, and using >MPLS as the control plane to allocate the DLCIs, then you must use RFC >3034. However, if you're simply tunneling MPLS packets through a FR >network which uses a native control plane, or perhaps FRF.5 across an ATM >backbone and control plane, then you are correct. > >I was aware of a couple of implementations of RFC 3034 at the time we were >working on the draft. Unfortunately, one of the places has closed up shop, >and the other seems to have been either discontinued or never made it into >a shipping release. It looks like the RFC may never make it past Proposed >.... > >Cheers, >Andy > >------- > >At 1/6/2003 09:37 AM -0500, Dan Tappan wrote: > > >At 10:20 AM 1/5/2003 -0500, Andrew G. Malis wrote: > >>http://www.ietf.org/rfc/rfc3034.txt is the reference. See section 4 for > >>the encapsulation. As you'll see, it's very straightforward. > >> > >>In particular, no NLPID (for multiprotocol identification) is required > >>because FR VCs used as MPLS LSPs are dedicated to that use. That's why > >>you couldn't find a specific reference. > > > >While the above is technically correct, I don't know of anyone who has > >actually implemented rfc3034. > > > >A more common approach for carrying MPLS across a FR link is to follow > >rfc2427: using the LLC/SNAP (section 4.1) encapsulation above the rfc3032 > >encapsulation. > > > >>Cheers, > >>Andy From owner-mpls@UU.NET Tue Jan 7 10:30:39 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18259 for ; Tue, 7 Jan 2003 10:30:38 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnwpy00096 for ; Tue, 7 Jan 2003 15:33:51 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnwpy24138; Tue, 7 Jan 2003 15:30:47 GMT Received: by mail-control.ash.ops.us.uu.net id QQnwpy29312 for mpls-outgoing; Tue, 7 Jan 2003 15:30:26 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnwpy29306 for ; Tue, 7 Jan 2003 15:30:21 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnwpx23822 for ; Tue, 7 Jan 2003 15:27:22 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnwpx04102 for ; Tue, 7 Jan 2003 15:27:22 GMT Received: from zcars04f.nortelnetworks.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: zcars04f.nortelnetworks.com [47.129.242.57]) id QQnwpx04088 for ; Tue, 7 Jan 2003 15:27:21 GMT Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h07FQtT08973; Tue, 7 Jan 2003 10:26:55 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 7 Jan 2003 10:26:56 -0500 Message-ID: From: "David Allan" To: curtis@fictitious.org, mpls@UU.NET Subject: RE: suggested added text for multipath in draft-ietf-mpls-lsp-pin g-01 Date: Tue, 7 Jan 2003 10:26:55 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: owner-mpls@UU.NET Precedence: bulk Hi Curtis: In general it looks OK, a few questions though.... In 3.4, - hash key type 5 has an unclear role, presumably the TLV length tells me how many label entries to expect. - hash key type 7 has an unclear role. Does no match imply "cannot get there from here...period". - not clear why MP index is requried, downstream mapping would provide a specific label reference which could also be used. Is there any time that MP index would not correspond directly to the offset in the downstream multipath mapping TLV. - I agree that the ability to originate a label stack is required to test load sharing points that only hash the stack, however this means that a traceroute will continue past the end of the LSP being tested, and return FEC mismatch errors as the test progresses past the end of the original top label unless some means of identifying the top label termination exists. What would be best is if the downstream mapping TLV had a field to indicate the label transfer function. If I were to explicitly align with what is defined in the MIBs, this would best be expressed as a pop count and a push count. cheers Dave > -----Original Message----- > From: Curtis Villamizar [mailto:curtis@fictitious.org] > Sent: Monday, December 23, 2002 5:38 PM > To: mpls@UU.NET > Cc: curtis@fictitious.org > Subject: suggested added text for multipath in > draft-ietf-mpls-lsp-ping-01 > > > > The long awaited part 3 of 3. Same format - diffs. This is not to > say the document is done. I didn't address all the comments to the > list as I would expect the authors of the document to do that. > > Curtis > > > @@ -352,26 +451,28 @@ > . > . > | > | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Types are defined below; Length is the length of the > Value field in > octets. The Value field depends on the Type; it is zero padded to > align to a four-octet boundary. > > Type # Value Field > ------ ----------- > 1 Target FEC Stack > 2 Downstream Mapping > - 3 Pad > - 4 Error Code > + 3 Downstream Multipath Mapping > + 4 Multipath Exercise > + 65534 Pad > + 65535 Error Code > > 3.1. Target FEC Stack > > A Target FEC Stack is a list of sub-TLVs. The number of > elements is > determined by the looking at the sub-TLV length fields. > > Sub-Type # Length Value Field > ---------- ------ ----------- > 1 5 LDP IPv4 prefix > 2 17 LDP IPv6 prefix > 3 20 RSVP IPv4 Session Query > 4 56 RSVP IPv6 Session Query > @@ -622,39 +723,179 @@ > LSR X. If a packet with outermost label L and TTL n>1 > arrived at X > on interface I, X must be able to compute which LSRs could receive > the packet with TTL=n+1, and what label they would see. (It is > outside the scope of this document to specify how this computation > may be done.) The set of these LSRs are the downstream > routers (and > their corresponding labels) for X with respect to L. > > The case where X is the LSR originating the echo request > is a special > case. X needs to figure out what LSRs would receive a labelled > packet with TTL=1 when X tries to send a packet to the > FEC Stack that > is being pinged. > > -3.3. Pad TLV > +3.3 Downstream Multipath Mapping > + > + The Downstream Multipath Mapping is an optional TLV in an echo > + request. The Length is 4 octets plus the size of Multipath > + Exercise TLVs and Downstream Mapping TLVs contained within the > + Downstream Multipath Mapping TLV. > + > + The Downstream Multipath Mapping TLV contains one or more pairs of > + Multipath Exercise TLVs and Downstream Mapping TLVs. The > + Downstream Multipath Mapping TLV is used where multiple forwarding > + paths exist. Each Multipath Exercise TLV provides > information that > + can be used to determine how to build test packets to exercise a > + specific next hop. Each corresponding Downstream Mapping TLV > + provides the downstream mapping information for that path. > + > + 0 1 2 3 > + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 > 7 8 9 0 1 > + > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > + | Number of Multipaths | Type of Multipath > | > + > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > + | Life Type | Shelf Life in Milliseconds > | > + > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > + | Multipath Exercise TLV > | > + . > . > + > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > + | Downstream Mapping TLV > | > + . > . > + > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > + ..... more Multipath Exercise / Downstream Mapping TLV > pairs .... > + . > . > + > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > + > + The "Number of Multipaths" gives the number of multipaths and > + determines the number of Multipath Exercise and > Downstream Mapping > + TLV pairs to follow unless TLV or packet size limits cause > + truncation. > + > + The "Type of Multipath" gives the type of multipath split > + performed at the branchpoint. The "Type of Multipath" is needed > + to interpret the Multipath Exercise TLVs. Supported types are: > + > + Type of Multipath Meaning > + ----------------- ------- > + 1 Per packet split (use of this form of > + multipath is highly discouraged). > + 2 Seeded unspecified hash based on > + underlying labels. > + 3 Seeded unspecified hash based on IP > + source and destination. > + 4 Seeded unspecified hash based on IP > + source and destination for stack depth > + of one, based on underlying labels for > + stack depth greater than one. > + 5 Other or unspecified. > + > + The "Shelf Life in Milliseconds" allows the amount of time that > + the multipath mapping will remain in effect to be specified, with > + a range of 1 msec to 16,000 seconds to 4.5 hours. A > value of zero > + indicates the mapping will remain in place at least until a > + topology change occurs. The "Life Type" field is a bit map. The > + MSB (0x80) indicates that the given life time is expressed as a > + maximum shelf life and that the remaining shelf life is not know. > + > + An Echo Request need not include description of all paths and may > + be reduced in size by including only the path under test. If > + packet size limit or TLV size limits (65535 bytes) would prevent > + the entire set of paths from being listed in an Echo > Response TLV, > + the total number of paths should be listed in the "Number of > + Multipaths" field and as many pairs of Multipath > Exercise TLVs and > + Downstream Mapping TLV as fit should be included. > + > +3.4 Multipath Exercise > + > + The Multipath Exercise TLV may appear only within a Downstream > + Multipath Mapping TLV. The Multipath Exercise TLV is omitted when > + "Type of Multipath" is equal to 1. The path is not deterministic. > + The path cannot be determined solely by the packet encapsulation. > + > + The following encapsulation of the Multipath Exercise TLV is > + applicable to "Type of Multipath" values 2-4. The size of the > + Multipath Exercise TLV is 4 octets plus either an addtional 4 > + octets per included "IP Address or Next Label" containing IPv4 > + addresses or MPLS labels or an additional 16 octets for IPv6 > + address. > + > + 0 1 2 3 > + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 > 7 8 9 0 1 > + > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > + | Hash Key Type | Depth Limit | MP Index > | > + > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > + | IP Address or Next Label > | > + > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > + .... > + > + The "Hash Key Type" determines the interpretation of the following > + "IP Address or Next Label" fields. The three formats of the "IP > + Address or Next Label" are a 32 bit field containing an IPv4 > + address, a 32 bit field containing a LSB justified 20 bit MPLS > + label with top 12 bits reserved for future use and set to zero, or > + a 128 bit IPv6 address. > + > + Hash Key Type: IP Address or Next Label > + -------------- ------------------------ > + 1 label 1 or more label > + 2 IPv4 address 1 or more IPv6 address > + 3 label range 1 or more > low/high label pairs > + 4 IPv4 address range 1 or more > low/high address pairs > + 5 no more labels (nothing) > + 6 All IPv4 addresses (nothing) > + 7 no match (nothing) > + 8 IPv6 address 1 or more IPv6 address > + 9 IPv6 address range 1 or more low/high > address pairs > + 10 IPv4 bitmap see encapsulation below > + 11 label bitmap see encapsulation below > + 12 IPv6 bitmap see encapsulation below > + > + The "Depth Limit" is applicable only to a label stack. It gives > + the maximum number of labels considered in the hash or zero for > + unspecified or unlimited. > + > + The "MP Index" is used to number the paths and provides a means to > + refer to them. > + > + The bitmap types each include a single IPv4 address, MPLS > label, or > + IPv6 address, followed by sets of four octets interpreted > as 32 bit > + words. The IPv4 address, MPLS label, or IPv6 address > should be the > + first address equal to or numerically greater than the destination > + address or label of the Echo Request with the lower 5 bits set to > + zero (to avoid complex shift operations at a test ingress if the > + union of bitmaps of multiple branch points must be determined). > + Each bit starting with the least significant bit (MSB sent first) > + is interpreted as one address. A zero in a given bit position > + indicates that the address or label will not exercise this path, a > + one idicates that the path will be exercised. The LSB of > the first > + 32 bit word corresponds to the address or label provided. > + > + Note that if a Downstream Multipath Mapping TLV cannot be > fit in an > + Echo Reply it is preferable to include less addresses or labels in > + each Multipath Exercise TLV than omit information for some paths. > + > +3.5. Pad TLV > > The value part of the Pad TLV contains a variable number (>= 1) of > octets. The first octet takes values from the following > table; all > the other octets (if any) are ignored. The receiver SHOULD verify > that the TLV is received in its entirety, but otherwise > ignores the > contents of this TLV, apart from the first octet. > > Value Meaning > ----- ------- > 1 Drop Pad TLV from reply > 2 Copy Pad TLV to reply > 3-255 Reserved for future use > > -3.4. Error Code > +3.6. Error Code > > The Error Code TLV is currently not defined; its purpose is to > provide a mechanism for a more elaborate error reporting > structure, > should the reason arise. > > > 4. Theory of Operation > > 4.1. Sending an MPLS Echo Request > > An MPLS echo request is a (possibly) labelled UDP packet. The IP > header is set as follows: the source IP address is a > routable address > > > > > @@ -791,24 +1032,170 @@ > > > > > > + > +4.9 Exercising Multipath > + > + A test traffic ingress upon receiving an Echo Reply containing a > + Downstream Multipath Mapping TLV should try to exercise all paths > + listed in the Downstream Multipath Mapping TLV. If the "Type of > + Multipath" is 1, indicating "per packet split", or 5, indicating > + "other or unspecified", then random addresses in the > range of 127/8 > + should be used. > + > + If the "Type of Multipath" in the Downstream Multipath Mapping TLV > + is 2-4, then for test traffic should be sent for each Multipath > + Exercise TLV with a label stack or a destination address > determined > + to exercise each path. > + > + When further testing an individual branch of a multipath, the > + Downstream Multipath Mapping TLV in subsequent Echo > Request packets > + SHOULD contain only the Multipath Exercise TLV and Downstream > + Mapping TLV for the path under test within the Downstream > Multipath > + Mapping TLV. > + > + If an addtional multipath branch is encountered downstream of one > + or more multipath branches, an intersection of the Multipath > + Exercise TLV of the branches under test and each of the > branches at > + the new branch point must be determined. If the > intersection based > + on the available information is the null set, each of the prior > + branch points must be queried with the highest intersecting label > + or address to obtain a new set of Multipath Exercise TLVs from a > + different portion of label or address space. > + > + For example, consider a case where one branchpoint under test has > + returned a bitmap of address in the range 127.0.0.0-127.0.4.255, a > + destination address 127.0.0.7 is used and a second branch point > + returns a sparse bitmap covering 127.0.1.32-127.0.5.31, is > + returned, and for a specific path from the second branch point, > + there is no intersection between the two bitmaps. An Echo Request > + must then be sent with TTL set to deliver the packet to the first > + branch point, with a destination address corresponding to > the first > + destination available in the second bitmap which was beyond the > + range of the first bitmap. This process is repeated > until there is > + an intersection in the returned bitmaps. The intended > path can now > + be tested. > > 5. Reliable Reply Path > > One of the issues that are faced with MPLS ping is to distinguish > between a failure in the forward path (the MPLS path > being 'pinged') > and a failure in the return path. Note that this problem > exists with > vanilla IP ping as well. In the case of MPLS ping, it is assumed > that the IP control and data planes are reliable. > However, it could > be that the forwarding in the return path is via an MPLS LSP. > > In this specification, we give two solutions for this > problem. One > is to set the Router Alert option in the MPLS echo reply. When a > > From owner-mpls@UU.NET Tue Jan 7 22:20:28 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA10085 for ; Tue, 7 Jan 2003 22:20:27 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnwrt10442 for ; Wed, 8 Jan 2003 03:23:41 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnwrt10275; Wed, 8 Jan 2003 03:23:35 GMT Received: by mail-control.ash.ops.us.uu.net id QQnwrt04794 for mpls-outgoing; Wed, 8 Jan 2003 03:23:08 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnwrt04781 for ; Wed, 8 Jan 2003 03:22:53 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnwrt05454 for ; Wed, 8 Jan 2003 03:22:10 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnwrt23544 for ; Wed, 8 Jan 2003 03:22:09 GMT Received: from rtp-msg-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-msg-core-1.cisco.com [161.44.11.97]) id QQnwrt23488 for ; Wed, 8 Jan 2003 03:22:04 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id h083Mhag022830 for ; Tue, 7 Jan 2003 22:22:44 -0500 (EST) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id WAA25230 for ; Tue, 7 Jan 2003 22:22:02 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h083M2D24599 for mpls@uu.net; Tue, 7 Jan 2003 22:22:02 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnwrt04675 for ; Wed, 8 Jan 2003 03:20:42 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnwrt16732 for ; Wed, 8 Jan 2003 03:18:02 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnwrt20385 for ; Wed, 8 Jan 2003 03:18:01 GMT Received: from workhorse.fictitious.org by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: workhorse.fictitious.org [209.150.1.230]) id QQnwrt20337 for ; Wed, 8 Jan 2003 03:17:57 GMT Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id WAA66444; Tue, 7 Jan 2003 22:13:53 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200301080313.WAA66444@workhorse.fictitious.org> To: "David Allan" cc: curtis@fictitious.org, mpls@UU.NET Reply-To: curtis@fictitious.org Subject: Re: suggested added text for multipath in draft-ietf-mpls-lsp-pin g-01 In-reply-to: Your message of "Tue, 07 Jan 2003 10:26:55 EST." Date: Tue, 07 Jan 2003 22:13:52 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message , "Da vid Allan" writes: > > > Hi Curtis: > > In general it looks OK, a few questions though.... > > In 3.4, > > - hash key type 5 has an unclear role, presumably the TLV length tells me > how many label entries to expect. I just wanted to reserve a number for "unspecified" meaning either non-deterministic or proprietary (both are bad - imho). > - hash key type 7 has an unclear role. Does no match imply "cannot get there > from here...period". It has a role. If a prior multipoint branch provided a bit map (or other indication of how to exercise the path that the packet traversed so far) none of the addresses specified as exercising the prior branch will exercise a specific branch at the current multipoint. > - not clear why MP index is requried, downstream mapping would provide a > specific label reference which could also be used. > Is there any time that MP index would not correspond directly to the offset > in the downstream multipath mapping TLV. The index is in case we invent new queries in the future or for some reason want to ask for further information with a MIB (like periodically asking for packet and byte counts). > - I agree that the ability to originate a label stack is required to test > load sharing points that only hash the stack, however this means that a > traceroute will continue past the end of the LSP being tested, and return > FEC mismatch errors as the test progresses past the end of the original top > label unless some means of identifying the top label termination exists. > What would be best is if the downstream mapping TLV had a field to indicate > the label transfer function. If I were to explicitly align with what is > defined in the MIBs, this would best be expressed as a pop count and a push > count. I can't see a clear way to completely eliminate the risk of packets going off the end of the egress on a VPN. All that can be done is recognize that that router is not MPLS-ping capable and omit the last packet if it is both the egress and the next hop in the prior mapping. If you see a solution to this please speak up. I think I understand what you mean by the label transfer function, but I don't see how it helps with the VPN egress problem. The penultimate router either does a swap and passes the packet, or a pop if doing PHP and passed the packet. If the egress is MPLS-ping capable, then it doesn't forward the packet further and provides a Echo Reply. If it is not MPLS-ping capable, it may forward the packet to the VPN. Are you just suggesting that having the additional information would be useful? > cheers > Dave Regards, Curtis > > -----Original Message----- > > From: Curtis Villamizar [mailto:curtis@fictitious.org] > > Sent: Monday, December 23, 2002 5:38 PM > > To: mpls@UU.NET > > Cc: curtis@fictitious.org > > Subject: suggested added text for multipath in > > draft-ietf-mpls-lsp-ping-01 > > > > > > > > The long awaited part 3 of 3. Same format - diffs. This is not to > > say the document is done. I didn't address all the comments to the > > list as I would expect the authors of the document to do that. > > > > Curtis > > > > > > @@ -352,26 +451,28 @@ > > . > > . > > | > > | > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > Types are defined below; Length is the length of the > > Value field in > > octets. The Value field depends on the Type; it is zero padded to > > align to a four-octet boundary. > > > > Type # Value Field > > ------ ----------- > > 1 Target FEC Stack > > 2 Downstream Mapping > > - 3 Pad > > - 4 Error Code > > + 3 Downstream Multipath Mapping > > + 4 Multipath Exercise > > + 65534 Pad > > + 65535 Error Code > > > > 3.1. Target FEC Stack > > > > A Target FEC Stack is a list of sub-TLVs. The number of > > elements is > > determined by the looking at the sub-TLV length fields. > > > > Sub-Type # Length Value Field > > ---------- ------ ----------- > > 1 5 LDP IPv4 prefix > > 2 17 LDP IPv6 prefix > > 3 20 RSVP IPv4 Session Query > > 4 56 RSVP IPv6 Session Query > > @@ -622,39 +723,179 @@ > > LSR X. If a packet with outermost label L and TTL n>1 > > arrived at X > > on interface I, X must be able to compute which LSRs could receive > > the packet with TTL=n+1, and what label they would see. (It is > > outside the scope of this document to specify how this computation > > may be done.) The set of these LSRs are the downstream > > routers (and > > their corresponding labels) for X with respect to L. > > > > The case where X is the LSR originating the echo request > > is a special > > case. X needs to figure out what LSRs would receive a labelled > > packet with TTL=1 when X tries to send a packet to the > > FEC Stack that > > is being pinged. > > > > -3.3. Pad TLV > > +3.3 Downstream Multipath Mapping > > + > > + The Downstream Multipath Mapping is an optional TLV in an echo > > + request. The Length is 4 octets plus the size of Multipath > > + Exercise TLVs and Downstream Mapping TLVs contained within the > > + Downstream Multipath Mapping TLV. > > + > > + The Downstream Multipath Mapping TLV contains one or more pairs of > > + Multipath Exercise TLVs and Downstream Mapping TLVs. The > > + Downstream Multipath Mapping TLV is used where multiple forwarding > > + paths exist. Each Multipath Exercise TLV provides > > information that > > + can be used to determine how to build test packets to exercise a > > + specific next hop. Each corresponding Downstream Mapping TLV > > + provides the downstream mapping information for that path. > > + > > + 0 1 2 3 > > + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 > > 7 8 9 0 1 > > + > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > + | Number of Multipaths | Type of Multipath > > | > > + > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > + | Life Type | Shelf Life in Milliseconds > > | > > + > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > + | Multipath Exercise TLV > > | > > + . > > . > > + > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > + | Downstream Mapping TLV > > | > > + . > > . > > + > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > + ..... more Multipath Exercise / Downstream Mapping TLV > > pairs .... > > + . > > . > > + > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > + > > + The "Number of Multipaths" gives the number of multipaths and > > + determines the number of Multipath Exercise and > > Downstream Mapping > > + TLV pairs to follow unless TLV or packet size limits cause > > + truncation. > > + > > + The "Type of Multipath" gives the type of multipath split > > + performed at the branchpoint. The "Type of Multipath" is needed > > + to interpret the Multipath Exercise TLVs. Supported types are: > > + > > + Type of Multipath Meaning > > + ----------------- ------- > > + 1 Per packet split (use of this form of > > + multipath is highly discouraged). > > + 2 Seeded unspecified hash based on > > + underlying labels. > > + 3 Seeded unspecified hash based on IP > > + source and destination. > > + 4 Seeded unspecified hash based on IP > > + source and destination for stack depth > > + of one, based on underlying labels for > > + stack depth greater than one. > > + 5 Other or unspecified. > > + > > + The "Shelf Life in Milliseconds" allows the amount of time that > > + the multipath mapping will remain in effect to be specified, with > > + a range of 1 msec to 16,000 seconds to 4.5 hours. A > > value of zero > > + indicates the mapping will remain in place at least until a > > + topology change occurs. The "Life Type" field is a bit map. The > > + MSB (0x80) indicates that the given life time is expressed as a > > + maximum shelf life and that the remaining shelf life is not know. > > + > > + An Echo Request need not include description of all paths and may > > + be reduced in size by including only the path under test. If > > + packet size limit or TLV size limits (65535 bytes) would prevent > > + the entire set of paths from being listed in an Echo > > Response TLV, > > + the total number of paths should be listed in the "Number of > > + Multipaths" field and as many pairs of Multipath > > Exercise TLVs and > > + Downstream Mapping TLV as fit should be included. > > + > > +3.4 Multipath Exercise > > + > > + The Multipath Exercise TLV may appear only within a Downstream > > + Multipath Mapping TLV. The Multipath Exercise TLV is omitted when > > + "Type of Multipath" is equal to 1. The path is not deterministic. > > + The path cannot be determined solely by the packet encapsulation. > > + > > + The following encapsulation of the Multipath Exercise TLV is > > + applicable to "Type of Multipath" values 2-4. The size of the > > + Multipath Exercise TLV is 4 octets plus either an addtional 4 > > + octets per included "IP Address or Next Label" containing IPv4 > > + addresses or MPLS labels or an additional 16 octets for IPv6 > > + address. > > + > > + 0 1 2 3 > > + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 > > 7 8 9 0 1 > > + > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > + | Hash Key Type | Depth Limit | MP Index > > | > > + > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > + | IP Address or Next Label > > | > > + > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > + .... > > + > > + The "Hash Key Type" determines the interpretation of the following > > + "IP Address or Next Label" fields. The three formats of the "IP > > + Address or Next Label" are a 32 bit field containing an IPv4 > > + address, a 32 bit field containing a LSB justified 20 bit MPLS > > + label with top 12 bits reserved for future use and set to zero, or > > + a 128 bit IPv6 address. > > + > > + Hash Key Type: IP Address or Next Label > > + -------------- ------------------------ > > + 1 label 1 or more label > > + 2 IPv4 address 1 or more IPv6 address > > + 3 label range 1 or more > > low/high label pairs > > + 4 IPv4 address range 1 or more > > low/high address pairs > > + 5 no more labels (nothing) > > + 6 All IPv4 addresses (nothing) > > + 7 no match (nothing) > > + 8 IPv6 address 1 or more IPv6 address > > + 9 IPv6 address range 1 or more low/high > > address pairs > > + 10 IPv4 bitmap see encapsulation below > > + 11 label bitmap see encapsulation below > > + 12 IPv6 bitmap see encapsulation below > > + > > + The "Depth Limit" is applicable only to a label stack. It gives > > + the maximum number of labels considered in the hash or zero for > > + unspecified or unlimited. > > + > > + The "MP Index" is used to number the paths and provides a means to > > + refer to them. > > + > > + The bitmap types each include a single IPv4 address, MPLS > > label, or > > + IPv6 address, followed by sets of four octets interpreted > > as 32 bit > > + words. The IPv4 address, MPLS label, or IPv6 address > > should be the > > + first address equal to or numerically greater than the destination > > + address or label of the Echo Request with the lower 5 bits set to > > + zero (to avoid complex shift operations at a test ingress if the > > + union of bitmaps of multiple branch points must be determined). > > + Each bit starting with the least significant bit (MSB sent first) > > + is interpreted as one address. A zero in a given bit position > > + indicates that the address or label will not exercise this path, a > > + one idicates that the path will be exercised. The LSB of > > the first > > + 32 bit word corresponds to the address or label provided. > > + > > + Note that if a Downstream Multipath Mapping TLV cannot be > > fit in an > > + Echo Reply it is preferable to include less addresses or labels in > > + each Multipath Exercise TLV than omit information for some paths. > > + > > +3.5. Pad TLV > > > > The value part of the Pad TLV contains a variable number (>= 1) of > > octets. The first octet takes values from the following > > table; all > > the other octets (if any) are ignored. The receiver SHOULD verify > > that the TLV is received in its entirety, but otherwise > > ignores the > > contents of this TLV, apart from the first octet. > > > > Value Meaning > > ----- ------- > > 1 Drop Pad TLV from reply > > 2 Copy Pad TLV to reply > > 3-255 Reserved for future use > > > > -3.4. Error Code > > +3.6. Error Code > > > > The Error Code TLV is currently not defined; its purpose is to > > provide a mechanism for a more elaborate error reporting > > structure, > > should the reason arise. > > > > > > 4. Theory of Operation > > > > 4.1. Sending an MPLS Echo Request > > > > An MPLS echo request is a (possibly) labelled UDP packet. The IP > > header is set as follows: the source IP address is a > > routable address > > > > > > > > > > @@ -791,24 +1032,170 @@ > > > > > > > > > > > > + > > +4.9 Exercising Multipath > > + > > + A test traffic ingress upon receiving an Echo Reply containing a > > + Downstream Multipath Mapping TLV should try to exercise all paths > > + listed in the Downstream Multipath Mapping TLV. If the "Type of > > + Multipath" is 1, indicating "per packet split", or 5, indicating > > + "other or unspecified", then random addresses in the > > range of 127/8 > > + should be used. > > + > > + If the "Type of Multipath" in the Downstream Multipath Mapping TLV > > + is 2-4, then for test traffic should be sent for each Multipath > > + Exercise TLV with a label stack or a destination address > > determined > > + to exercise each path. > > + > > + When further testing an individual branch of a multipath, the > > + Downstream Multipath Mapping TLV in subsequent Echo > > Request packets > > + SHOULD contain only the Multipath Exercise TLV and Downstream > > + Mapping TLV for the path under test within the Downstream > > Multipath > > + Mapping TLV. > > + > > + If an addtional multipath branch is encountered downstream of one > > + or more multipath branches, an intersection of the Multipath > > + Exercise TLV of the branches under test and each of the > > branches at > > + the new branch point must be determined. If the > > intersection based > > + on the available information is the null set, each of the prior > > + branch points must be queried with the highest intersecting label > > + or address to obtain a new set of Multipath Exercise TLVs from a > > + different portion of label or address space. > > + > > + For example, consider a case where one branchpoint under test has > > + returned a bitmap of address in the range 127.0.0.0-127.0.4.255, a > > + destination address 127.0.0.7 is used and a second branch point > > + returns a sparse bitmap covering 127.0.1.32-127.0.5.31, is > > + returned, and for a specific path from the second branch point, > > + there is no intersection between the two bitmaps. An Echo Request > > + must then be sent with TTL set to deliver the packet to the first > > + branch point, with a destination address corresponding to > > the first > > + destination available in the second bitmap which was beyond the > > + range of the first bitmap. This process is repeated > > until there is > > + an intersection in the returned bitmaps. The intended > > path can now > > + be tested. > > > > 5. Reliable Reply Path > > > > One of the issues that are faced with MPLS ping is to distinguish > > between a failure in the forward path (the MPLS path > > being 'pinged') > > and a failure in the return path. Note that this problem > > exists with > > vanilla IP ping as well. In the case of MPLS ping, it is assumed > > that the IP control and data planes are reliable. > > However, it could > > be that the forwarding in the return path is via an MPLS LSP. > > > > In this specification, we give two solutions for this > > problem. One > > is to set the Router Alert option in the MPLS echo reply. When a > > > > > From owner-mpls@UU.NET Tue Jan 7 22:54:00 2003 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11363 for ; Tue, 7 Jan 2003 22:54:00 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnwrv06651 for ; Wed, 8 Jan 2003 03:57:13 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnwrv06423; Wed, 8 Jan 2003 03:57:06 GMT Received: by mail-control.ash.ops.us.uu.net id QQnwrv06460 for mpls-outgoing; Wed, 8 Jan 2003 03:56:53 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnwrv06442 for ; Wed, 8 Jan 2003 03:56:39 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnwrv13803 for ; Wed, 8 Jan 2003 03:50:01 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnwrv06881 for ; Wed, 8 Jan 2003 03:50:01 GMT Received: from wiprom2mx1.wipro.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: wiprom2mx1.wipro.com [203.197.164.41]) id QQnwrv06832 for ; Wed, 8 Jan 2003 03:49:59 GMT Received: from m2vwall5.wipro.com (m2vwall5.wipro.com [10.115.50.5]) by wiprom2mx1.wipro.com (8.11.3/8.11.3) with SMTP id h083nvS18332 for ; Wed, 8 Jan 2003 09:19:57 +0530 (IST) Received: from blr-k1-msg.wipro.com ([10.117.50.99]) by blr-m1-bh2.wipro.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 8 Jan 2003 09:19:52 +0530 Received: from soflt.ipneg.wipro.com ([10.117.3.193]) by blr-k1-msg.wipro.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 8 Jan 2003 09:19:51 +0530 Date: Wed, 8 Jan 2003 09:23:25 +0530 (IST) From: Chetan Kumar S X-X-Sender: chetansk@localhost.localdomain Reply-To: chetan.kumar@wipro.com To: IETF MPLS List Subject: Re: draft-rosen-mpls-in-ip-or-gre-00.txt Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-OriginalArrivalTime: 08 Jan 2003 03:49:52.0066 (UTC) FILETIME=[FFC5C220:01C2B6C8] Sender: owner-mpls@UU.NET Precedence: bulk > the draft draft-rosen-mpls-in-ip-or-gre-00.txt was presented in Atlanta, > the reception was positive, and there has been no discussion after that > on the mailing list. > > Based on prior response to the mailing list, the response at the > Atlanta meeting and the lack of response after the meeting, it is > the wg chairs intention to make this draft a wg document. I vote for this to be a WG doc Thanks Chetan S From owner-mpls@UU.NET Tue Jan 7 23:47:56 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12549 for ; Tue, 7 Jan 2003 23:47:56 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnwrz19262 for ; Wed, 8 Jan 2003 04:51:09 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnwrz19029; Wed, 8 Jan 2003 04:51:02 GMT Received: by mail-control.ash.ops.us.uu.net id QQnwrz27568 for mpls-outgoing; Wed, 8 Jan 2003 04:50:33 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnwrz27549 for ; Wed, 8 Jan 2003 04:50:30 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnwrz04101 for ; Wed, 8 Jan 2003 04:46:07 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnwrz24176 for ; Wed, 8 Jan 2003 04:46:06 GMT Received: from hermes.fm.intel.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: fmr01.intel.com [192.55.52.18]) id QQnwrz24147 for ; Wed, 8 Jan 2003 04:46:05 GMT Received: from petasus.fm.intel.com (petasus.fm.intel.com [10.1.192.37]) by hermes.fm.intel.com (8.11.6/8.11.6/d: outer.mc,v 1.51 2002/09/23 20:43:23 dmccart Exp $) with ESMTP id h084hYa11981 for ; Wed, 8 Jan 2003 04:43:34 GMT Received: from fmsmsxvs041.fm.intel.com (fmsmsxvs041.fm.intel.com [132.233.42.126]) by petasus.fm.intel.com (8.11.6/8.11.6/d: inner.mc,v 1.27 2002/10/16 23:46:59 dmccart Exp $) with SMTP id h084fFL18188 for ; Wed, 8 Jan 2003 04:41:16 GMT Received: from fmsmsx28.fm.intel.com ([132.233.42.28]) by fmsmsxvs041.fm.intel.com (NAVGW 2.5.2.11) with SMTP id M2003010720440902635 ; Tue, 07 Jan 2003 20:44:09 -0800 Received: by fmsmsx28.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 7 Jan 2003 20:46:03 -0800 Message-ID: <12B638FEE763F74696D8544752E7204802FC5413@bgsmsx101.iind.intel.com> From: "Gowda, Sidde" To: "'Loa Andersson'" , mpls wg Cc: George Swallow , Scott Bradner Subject: RE: draft-rosen-mpls-in-ip-or-gre-00.txt Date: Tue, 7 Jan 2003 20:41:16 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Yes, it should be a WG doc. Siddu -----Original Message----- From: Loa Andersson [mailto:loa@pi.se] Sent: Monday, December 16, 2002 10:12 PM To: mpls wg Cc: George Swallow; Scott Bradner Subject: draft-rosen-mpls-in-ip-or-gre-00.txt All, the draft draft-rosen-mpls-in-ip-or-gre-00.txt was presented in Atlanta, the reception was positive, and there has been no discussion after that on the mailing list. Based on prior response to the mailing list, the response at the Atlanta meeting and the lack of response after the meeting, it is the wg chairs intention to make this draft a wg document. Please comment before January 7th. Loa and George -- Loa Andersson Mobile +46 739 81 21 64 Email loa@pi.se From owner-mpls@UU.NET Wed Jan 8 01:25:59 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA16583 for ; Wed, 8 Jan 2003 01:25:58 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnwsf05127 for ; Wed, 8 Jan 2003 06:29:14 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnwsf05056; Wed, 8 Jan 2003 06:29:12 GMT Received: by mail-control.ash.ops.us.uu.net id QQnwsf08419 for mpls-outgoing; Wed, 8 Jan 2003 06:28:52 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnwsf08414 for ; Wed, 8 Jan 2003 06:28:47 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnwsf22611 for ; Wed, 8 Jan 2003 06:27:31 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnwsf29628 for ; Wed, 8 Jan 2003 06:27:31 GMT Received: from caduceus.fm.intel.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: fmr02.intel.com [192.55.52.25]) id QQnwsf29603 for ; Wed, 8 Jan 2003 06:27:30 GMT Received: from petasus.fm.intel.com (petasus.fm.intel.com [10.1.192.37]) by caduceus.fm.intel.com (8.11.6/8.11.6/d: outer.mc,v 1.51 2002/09/23 20:43:23 dmccart Exp $) with ESMTP id h086M8i22492 for ; Wed, 8 Jan 2003 06:22:08 GMT Received: from fmsmsxvs042.fm.intel.com (fmsmsxvs042.fm.intel.com [132.233.42.128]) by petasus.fm.intel.com (8.11.6/8.11.6/d: inner.mc,v 1.27 2002/10/16 23:46:59 dmccart Exp $) with SMTP id h086Mfl15745 for ; Wed, 8 Jan 2003 06:22:41 GMT Received: from FMSMSX018.fm.intel.com ([132.233.42.197]) by fmsmsxvs042.fm.intel.com (NAVGW 2.5.2.11) with SMTP id M2003010722290123755 ; Tue, 07 Jan 2003 22:29:01 -0800 Received: by fmsmsx018.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 7 Jan 2003 22:27:28 -0800 Message-ID: <12B638FEE763F74696D8544752E7204802FC5415@bgsmsx101.iind.intel.com> From: "Gowda, Sidde" To: "'luca@level3.net'" Cc: "'mpls-ops@mplsrc.com'" , mpls@UU.NET Subject: draft-ietf-pwe3-control-protocol-01.txt Date: Tue, 7 Jan 2003 22:22:42 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2B6DE.5981A9E0" Sender: owner-mpls@UU.NET Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2B6DE.5981A9E0 Content-Type: text/plain Hi Please correct me if I am wrong. In the draft-ietf-pwe3-control-protocol-01.txt though VC (old Martini Drafts) is being changed to PW, still the word VC is used in many places. Won't there be inconsistency? Why can't we consider it as PW (VC is implicit here) only? Or is there any specific reason for both being there? Can somebody or the Author clarify this? Thanks in advance SiddeGowda ------_=_NextPart_001_01C2B6DE.5981A9E0 Content-Type: text/html

Hi

 

Please correct me if I am wrong.

In the draft-ietf-pwe3-control-protocol-01.txt though VC (old Martini Drafts) is being changed to PW, still the word VC is used in many places. Won't there be inconsistency? Why can't we consider it as PW (VC is implicit here) only? Or is there any specific reason for both being there?

 

Can somebody or the Author clarify this?

Thanks in advance

 

SiddeGowda

 

------_=_NextPart_001_01C2B6DE.5981A9E0-- From owner-mpls@UU.NET Wed Jan 8 09:26:02 2003 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20933 for ; Wed, 8 Jan 2003 09:26:01 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnwtl09439 for ; Wed, 8 Jan 2003 14:29:13 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnwtl07009; Wed, 8 Jan 2003 14:28:02 GMT Received: by mail-control.ash.ops.us.uu.net id QQnwtl28965 for mpls-outgoing; Wed, 8 Jan 2003 14:27:34 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnwtl28940 for ; Wed, 8 Jan 2003 14:27:26 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnwtl28150 for ; Wed, 8 Jan 2003 14:23:06 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnwtl20951 for ; Wed, 8 Jan 2003 14:23:05 GMT Received: from zcars04f.nortelnetworks.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: zcars04f.nortelnetworks.com [47.129.242.57]) id QQnwtl20943 for ; Wed, 8 Jan 2003 14:23:05 GMT Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h08EMtT04805; Wed, 8 Jan 2003 09:22:56 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 8 Jan 2003 09:22:56 -0500 Message-ID: From: "David Allan" To: curtis@fictitious.org Cc: mpls@UU.NET Subject: RE: suggested added text for multipath in draft-ietf-mpls-lsp-pin g-01 Date: Wed, 8 Jan 2003 09:22:55 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: owner-mpls@UU.NET Precedence: bulk hi Curtis: > > > > - hash key type 5 has an unclear role, presumably the TLV > length tells me > > how many label entries to expect. > > I just wanted to reserve a number for "unspecified" meaning either > non-deterministic or proprietary (both are bad - imho). Not multiple type 5, hash key 5 (no more labels) > > > - hash key type 7 has an unclear role. Does no match imply > "cannot get there > > from here...period". > > It has a role. If a prior multipoint branch provided a bit map (or > other indication of how to exercise the path that the packet traversed > so far) none of the addresses specified as exercising the prior branch > will exercise a specific branch at the current multipoint. OK , so can't get there from here was a correct assumption. > > > - not clear why MP index is requried, downstream mapping > would provide a > > specific label reference which could also be used. > > Is there any time that MP index would not correspond > directly to the offset > > in the downstream multipath mapping TLV. > > The index is in case we invent new queries in the future or for some > reason want to ask for further information with a MIB (like > periodically asking for packet and byte counts). So you are assuming that the local node will administrate a path ingress identifier that will remain constant across load balancing changes. Wouldn't it be simpler to use an I/F index or somthing else already defined (and therefore could provide useful information to a management system) rather than create a new value. I'll risk the flaming and suggest the TTSI from 1711. > > What would be best is if the downstream mapping TLV had a > field to indicate > > the label transfer function. If I were to explicitly align > with what is > > defined in the MIBs, this would best be expressed as a pop > count and a push > > count. > > I can't see a clear way to completely eliminate the risk of packets > going off the end of the egress on a VPN. All that can be done is > recognize that that router is not MPLS-ping capable and omit the last > packet if it is both the egress and the next hop in the prior mapping. > > If you see a solution to this please speak up. Agreed that it cannot be completely and authoritatively eliminated. However if the downstream mapping TLV provided the stack push and pop counts, then if an egress LSR where TTL expired implements LSP ping then the response to the ping originator would provide it with sufficient information to know not to try higher TTL values. If it does not implment PING, there is no response and the originating node will probably try higher TTL values. IMHO this also addresses the issue where an LSP enters a tunnel (which means subsequent TTL values in uniform mode will return FEC errors) as the ping originator would know that the TOP label where TTL expired was not associated with the FECs in the Ping request. > > I think I understand what you mean by the label transfer function, what stack operations are performed. > but > I don't see how it helps with the VPN egress problem. The penultimate > router either does a swap and passes the packet, or a pop if doing PHP > and passed the packet. If the egress is MPLS-ping capable, then it > doesn't forward the packet further and provides a Echo Reply. If it > is not MPLS-ping capable, it may forward the packet to the VPN. Are > you just suggesting that having the additional information would be > useful? Discussed above.... rgds Dave From owner-mpls@UU.NET Wed Jan 8 16:17:08 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07644 for ; Wed, 8 Jan 2003 16:17:08 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnwun15943 for ; Wed, 8 Jan 2003 21:20:17 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnwun15554; Wed, 8 Jan 2003 21:20:06 GMT Received: by mail-control.ash.ops.us.uu.net id QQnwun09425 for mpls-outgoing; Wed, 8 Jan 2003 21:19:53 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnwun09420 for ; Wed, 8 Jan 2003 21:19:39 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnwun08581 for ; Wed, 8 Jan 2003 21:18:11 GMT From: neil.2.harrison@bt.com Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnwun26979 for ; Wed, 8 Jan 2003 21:18:10 GMT Received: from cbibipnt05.hc.bt.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: saturn.bt.com [193.113.57.20]) id QQnwun26967 for ; Wed, 8 Jan 2003 21:18:09 GMT Received: by cbibipnt05.hc.bt.com with Internet Mail Service (5.5.2654.89) id ; Wed, 8 Jan 2003 21:18:19 -0000 Message-ID: <0536FC9B908BEC4597EE721BE6A35389014CFDE7@i2km07-ukbr.domain1.systemhost.net> To: dallan@nortelnetworks.com, curtis@fictitious.org Cc: mpls@UU.NET Subject: RE: suggested added text for multipath in draft-ietf-mpls-lsp-pin g-01 Date: Wed, 8 Jan 2003 21:18:00 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.89) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Dave, 1 minor remark below. regards, Neil > > > - not clear why MP index is requried, downstream mapping > > would provide a > > > specific label reference which could also be used. > > > Is there any time that MP index would not correspond > > directly to the offset > > > in the downstream multipath mapping TLV. > > > > The index is in case we invent new queries in the future or for some > > reason want to ask for further information with a MIB (like > > periodically asking for packet and byte counts). > > So you are assuming that the local node will administrate a > path ingress > identifier that will remain constant across load balancing > changes. Wouldn't > it be simpler to use an I/F index or somthing else already > defined (and > therefore could provide useful information to a management > system) rather > than create a new value. I'll risk the flaming and suggest > the TTSI from > 1711. NH=> You are right to suggest this for sound technical reasons. The source identifier of an LSP should (though 'must' is more appropriate IMO) be an invariant property of the user-plane and decoupled from how that LSP was created (either in the control or management planes). Currently, it seems we have different source identifiers for LSPs that are dependent on the signalling protocol that created them. This creates disjoint MPLS networks, ie a BGP4 LSP access point cannot be connected to a RSVP-TE LSP access point, etc....and whilst this is OK per se, it means defects *between* such LSPs are now not universally resolvable via a common source identifier. You may get flamed for suggesting using the TTSI, but the principle here is actually very sound and should not attract such ridicule. From owner-mpls@UU.NET Wed Jan 8 21:41:52 2003 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17571 for ; Wed, 8 Jan 2003 21:41:52 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnwvj04750 for ; Thu, 9 Jan 2003 02:45:08 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnwvj04650; Thu, 9 Jan 2003 02:45:04 GMT Received: by mail-control.ash.ops.us.uu.net id QQnwvi05573 for mpls-outgoing; Thu, 9 Jan 2003 02:44:36 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnwvi05558 for ; Thu, 9 Jan 2003 02:44:30 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnwvi16197 for ; Thu, 9 Jan 2003 02:40:11 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnwvi20426 for ; Thu, 9 Jan 2003 02:40:11 GMT Received: from rtp-msg-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-msg-core-1.cisco.com [161.44.11.97]) id QQnwvi20422 for ; Thu, 9 Jan 2003 02:40:10 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id h092ei4B006268 for ; Wed, 8 Jan 2003 21:40:50 -0500 (EST) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id VAA20292 for ; Wed, 8 Jan 2003 21:40:02 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h092e2u02809 for mpls@uu.net; Wed, 8 Jan 2003 21:40:02 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnwvi05222 for ; Thu, 9 Jan 2003 02:38:56 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnwvi23869 for ; Thu, 9 Jan 2003 02:33:46 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnwvi27551 for ; Thu, 9 Jan 2003 02:33:46 GMT Received: from workhorse.fictitious.org by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: workhorse.fictitious.org [209.150.1.230]) id QQnwvi27539 for ; Thu, 9 Jan 2003 02:33:45 GMT Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id VAA71711; Wed, 8 Jan 2003 21:32:56 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200301090232.VAA71711@workhorse.fictitious.org> To: neil.2.harrison@bt.com cc: dallan@nortelnetworks.com, curtis@fictitious.org, mpls@UU.NET Reply-To: curtis@fictitious.org Subject: Re: suggested added text for multipath in draft-ietf-mpls-lsp-pin g-01 In-reply-to: Your message of "Wed, 08 Jan 2003 21:18:00 GMT." <0536FC9B908BEC4597EE721BE6A35389014CFDE7@i2km07-ukbr.domain1.systemhost.net> Date: Wed, 08 Jan 2003 21:32:56 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <0536FC9B908BEC4597EE721BE6A35389014CFDE7@i2km07-ukbr.domain1.system host.net>, neil.2.harrison@bt.com writes: > Dave, 1 minor remark below. regards, Neil > > > > > - not clear why MP index is requried, downstream mapping > > > would provide a > > > > specific label reference which could also be used. > > > > Is there any time that MP index would not correspond > > > directly to the offset > > > > in the downstream multipath mapping TLV. > > > > > > The index is in case we invent new queries in the future or for some > > > reason want to ask for further information with a MIB (like > > > periodically asking for packet and byte counts). > > > > So you are assuming that the local node will administrate a > > path ingress > > identifier that will remain constant across load balancing > > changes. Wouldn't > > it be simpler to use an I/F index or somthing else already > > defined (and > > therefore could provide useful information to a management > > system) rather > > than create a new value. I'll risk the flaming and suggest > > the TTSI from > > 1711. > NH=> You are right to suggest this for sound technical reasons. The source > identifier of an LSP should (though 'must' is more appropriate IMO) be an > invariant property of the user-plane and decoupled from how that LSP was > created (either in the control or management planes). Currently, it seems > we have different source identifiers for LSPs that are dependent on the > signalling protocol that created them. This creates disjoint MPLS networks, > ie a BGP4 LSP access point cannot be connected to a RSVP-TE LSP access > point, etc....and whilst this is OK per se, it means defects *between* such > LSPs are now not universally resolvable via a common source identifier. You > may get flamed for suggesting using the TTSI, but the principle here is > actually very sound and should not attract such ridicule. Just currious. Is the TTSI appropriate to handle multipath, which is what we are talking about here? At a midpoint there would be multiple indices, each index representing one branch of the multipath at midpoint. In any case, TTSI should not be used because it created a completely unnecessary tie to an ITU document. Ifindex (and maybe TTSI) would not be appropriate if the multipath split were in a proprietary link bundle. Curtis From owner-mpls@UU.NET Thu Jan 9 09:52:31 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13169 for ; Thu, 9 Jan 2003 09:52:30 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnwxf21078 for ; Thu, 9 Jan 2003 14:55:45 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnwxf20915; Thu, 9 Jan 2003 14:55:41 GMT Received: by mail-control.ash.ops.us.uu.net id QQnwxf09952 for mpls-outgoing; Thu, 9 Jan 2003 14:54:59 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnwxf09943 for ; Thu, 9 Jan 2003 14:54:51 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnwxf21736 for ; Thu, 9 Jan 2003 14:53:10 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnwxf18933 for ; Thu, 9 Jan 2003 14:53:10 GMT Received: from zcars04e.nortelnetworks.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: zcars04e.nortelnetworks.com [47.129.242.56]) id QQnwxf18928 for ; Thu, 9 Jan 2003 14:53:09 GMT Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04e.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h09EhCJ00843; Thu, 9 Jan 2003 09:43:12 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 9 Jan 2003 09:43:12 -0500 Message-ID: From: "David Allan" To: curtis@fictitious.org, neil.2.harrison@bt.com Cc: mpls@UU.NET Subject: RE: suggested added text for multipath in draft-ietf-mpls-lsp-pin g-01 Date: Thu, 9 Jan 2003 09:43:09 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: owner-mpls@UU.NET Precedence: bulk Hi Curtis: > > > Just currious. Is the TTSI appropriate to handle multipath, which is > what we are talking about here? At a midpoint there would be multiple > indices, each index representing one branch of the multipath at > midpoint. TTSI is an access point identifier, so it would work. Some folks wanted to avoid having to request signalling changes by suggesting existing RSVP fields COULD be used to populate TTSI at the egress (tunnel ID) and this has resulted in a lot of confusion as to whether TTSI identified an access point or a path. Each LSP ingress will have a unique TTSI. > > In any case, TTSI should not be used because it created a completely > unnecessary tie to an ITU document. Ifindex (and maybe TTSI) would > not be appropriate if the multipath split were in a proprietary link > bundle. Only suggestion I would make is that MPIndex should then be 32 bits, so that folks that want to use the (albeit poorly named) LSP ID part of TTSI could do so (and this would not require an explicit tie to any ITU documents). A node administered access point identifier should be able to work even for propreitary bundles. cheers Dave From owner-mpls@UU.NET Thu Jan 9 09:57:54 2003 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13362 for ; Thu, 9 Jan 2003 09:57:54 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnwxg17361 for ; Thu, 9 Jan 2003 15:01:11 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnwxg17160; Thu, 9 Jan 2003 15:01:06 GMT Received: by mail-control.ash.ops.us.uu.net id QQnwxg13572 for mpls-outgoing; Thu, 9 Jan 2003 15:00:37 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnwxg12063 for ; Thu, 9 Jan 2003 15:00:19 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnwxf24464 for ; Thu, 9 Jan 2003 14:58:14 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnwxf11282 for ; Thu, 9 Jan 2003 14:58:13 GMT Received: from rtp-msg-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-msg-core-1.cisco.com [161.44.11.97]) id QQnwxf11275 for ; Thu, 9 Jan 2003 14:58:13 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id h09EwnlX020514 for ; Thu, 9 Jan 2003 09:58:49 -0500 (EST) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id JAA25153 for ; Thu, 9 Jan 2003 09:58:02 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h09Ew2p06407 for mpls@uu.net; Thu, 9 Jan 2003 09:58:02 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnwxf10250 for ; Thu, 9 Jan 2003 14:56:29 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnwxf19242 for ; Thu, 9 Jan 2003 14:50:42 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnwxf05819 for ; Thu, 9 Jan 2003 14:50:42 GMT Received: from workhorse.fictitious.org by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: workhorse.fictitious.org [209.150.1.230]) id QQnwxf05811 for ; Thu, 9 Jan 2003 14:50:41 GMT Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id JAA73764; Thu, 9 Jan 2003 09:50:20 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200301091450.JAA73764@workhorse.fictitious.org> To: "David Allan" cc: curtis@fictitious.org, neil.2.harrison@bt.com, mpls@UU.NET Reply-To: curtis@fictitious.org Subject: Re: suggested added text for multipath in draft-ietf-mpls-lsp-pin g-01 In-reply-to: Your message of "Thu, 09 Jan 2003 09:43:09 EST." Date: Thu, 09 Jan 2003 09:50:20 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message , "Da vid Allan" writes: > > > Hi Curtis: > > > > > > > > Just currious. Is the TTSI appropriate to handle multipath, which is > > what we are talking about here? At a midpoint there would be multiple > > indices, each index representing one branch of the multipath at > > midpoint. > > TTSI is an access point identifier, so it would work. Some folks wanted to > avoid having to request signalling changes by suggesting existing RSVP > fields COULD be used to populate TTSI at the egress (tunnel ID) and this has > resulted in a lot of confusion as to whether TTSI identified an access point > or a path. Each LSP ingress will have a unique TTSI. > > > > > In any case, TTSI should not be used because it created a completely > > unnecessary tie to an ITU document. Ifindex (and maybe TTSI) would > > not be appropriate if the multipath split were in a proprietary link > > bundle. > > Only suggestion I would make is that MPIndex should then be 32 bits, so that > folks that want to use the (albeit poorly named) LSP ID part of TTSI could > do so (and this would not require an explicit tie to any ITU documents). A > node administered access point identifier should be able to work even for > propreitary bundles. > > cheers > Dave The intent was that it was an index indicating the Nth branch of the multipath branch point. N would typically ba a small integer and very seldom would have to even approach 100. Curtis From owner-mpls@UU.NET Thu Jan 9 10:05:36 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13698 for ; Thu, 9 Jan 2003 10:05:36 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnwxg09321 for ; Thu, 9 Jan 2003 15:08:52 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnwxg09076; Thu, 9 Jan 2003 15:08:46 GMT Received: by mail-control.ash.ops.us.uu.net id QQnwxg28969 for mpls-outgoing; Thu, 9 Jan 2003 15:08:19 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnwxg28955 for ; Thu, 9 Jan 2003 15:08:18 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnwxg10638 for ; Thu, 9 Jan 2003 15:07:47 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnwxg08014 for ; Thu, 9 Jan 2003 15:07:46 GMT Received: from zcars04f.nortelnetworks.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: zcars04f.nortelnetworks.com [47.129.242.57]) id QQnwxg08010 for ; Thu, 9 Jan 2003 15:07:46 GMT Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h09ErRw07123; Thu, 9 Jan 2003 09:53:27 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 9 Jan 2003 09:53:27 -0500 Message-ID: From: "David Allan" To: curtis@fictitious.org Cc: curtis@fictitious.org, neil.2.harrison@bt.com, mpls@UU.NET Subject: RE: suggested added text for multipath in draft-ietf-mpls-lsp-pin g-01 Date: Thu, 9 Jan 2003 09:53:26 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: owner-mpls@UU.NET Precedence: bulk Hi Curtis: I gathered the intent, I'm just seeking to align MPIndex with some other node administered value (such as TTSI or IFIndex) so we do not require further changes to make the relevant stuff accessable via MIBs or CLI Dave > -----Original Message----- > From: Curtis Villamizar [mailto:curtis@fictitious.org] > Sent: Thursday, January 09, 2003 9:50 AM > To: Allan, David [CAR:NS00:EXCH] > Cc: curtis@fictitious.org; neil.2.harrison@bt.com; mpls@UU.NET > Subject: Re: suggested added text for multipath in > draft-ietf-mpls-lsp-pin g-01 > > > > In message > , "Da > vid Allan" writes: > > > > > > Hi Curtis: > > > > > > > > > > > > > Just currious. Is the TTSI appropriate to handle > multipath, which is > > > what we are talking about here? At a midpoint there > would be multiple > > > indices, each index representing one branch of the multipath at > > > midpoint. > > > > TTSI is an access point identifier, so it would work. Some > folks wanted to > > avoid having to request signalling changes by suggesting > existing RSVP > > fields COULD be used to populate TTSI at the egress (tunnel > ID) and this has > > resulted in a lot of confusion as to whether TTSI > identified an access point > > or a path. Each LSP ingress will have a unique TTSI. > > > > > > > > In any case, TTSI should not be used because it created a > completely > > > unnecessary tie to an ITU document. Ifindex (and maybe > TTSI) would > > > not be appropriate if the multipath split were in a > proprietary link > > > bundle. > > > > Only suggestion I would make is that MPIndex should then be > 32 bits, so that > > folks that want to use the (albeit poorly named) LSP ID > part of TTSI could > > do so (and this would not require an explicit tie to any > ITU documents). A > > node administered access point identifier should be able to > work even for > > propreitary bundles. > > > > cheers > > Dave > > > The intent was that it was an index indicating the Nth branch of the > multipath branch point. N would typically ba a small integer and very > seldom would have to even approach 100. > > Curtis > > From owner-mpls@UU.NET Thu Jan 9 10:08:08 2003 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13783 for ; Thu, 9 Jan 2003 10:08:07 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnwxg04763 for ; Thu, 9 Jan 2003 15:11:23 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnwxg03863; Thu, 9 Jan 2003 15:10:56 GMT Received: by mail-control.ash.ops.us.uu.net id QQnwxg29242 for mpls-outgoing; Thu, 9 Jan 2003 15:10:40 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnwxg29230 for ; Thu, 9 Jan 2003 15:10:30 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnwxg11891 for ; Thu, 9 Jan 2003 15:08:58 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnwxg21146 for ; Thu, 9 Jan 2003 15:08:58 GMT Received: from zcars04e.nortelnetworks.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: zcars04e.nortelnetworks.com [47.129.242.56]) id QQnwxg21135 for ; Thu, 9 Jan 2003 15:08:57 GMT Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04e.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h09F8hJ08316; Thu, 9 Jan 2003 10:08:43 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 9 Jan 2003 10:08:43 -0500 Message-ID: From: "David Allan" To: curtis@fictitious.org Cc: curtis@fictitious.org, neil.2.harrison@bt.com, mpls@UU.NET Subject: RE: suggested added text for multipath in draft-ietf-mpls-lsp-pin g-01 Date: Thu, 9 Jan 2003 10:08:42 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: owner-mpls@UU.NET Precedence: bulk If I have I/F index, I also have the label value from the downstream mapping TLV so I can access counts at the label level. That's what I had in mind when suggesting IF index. cheers Dave > -----Original Message----- > From: Curtis Villamizar [mailto:curtis@fictitious.org] > Sent: Thursday, January 09, 2003 10:04 AM > To: Allan, David [CAR:NS00:EXCH] > Cc: curtis@fictitious.org; neil.2.harrison@bt.com; mpls@UU.NET > Subject: Re: suggested added text for multipath in > draft-ietf-mpls-lsp-pin g-01 > > > > In message > , "Da > vid Allan" writes: > > Hi Curtis: > > > > I gathered the intent, I'm just seeking to align MPIndex > with some other > > node administered value (such as TTSI or IFIndex) so we do > not require > > further changes to make the relevant stuff accessable via > MIBs or CLI > > > > Dave > > > The counter that tells you how much can in for Label L and went out > Path N is different from the counter that tells you how much traffic > went out interface I. So you can't reuse MIB values and get useful > counters. > > For example - It you expect a 50:50 split, its nice to poll a MIB and > see that the result of the hash is at least close. It would also > diagnose different problems. You may see lots of traffic on the > outbound interface, but if you see one of these smaller counters stop > incrementing then you know you have a problem. > > Curtis > > > > > -----Original Message----- > > > From: Curtis Villamizar [mailto:curtis@fictitious.org] > > > Sent: Thursday, January 09, 2003 9:50 AM > > > To: Allan, David [CAR:NS00:EXCH] > > > Cc: curtis@fictitious.org; neil.2.harrison@bt.com; mpls@UU.NET > > > Subject: Re: suggested added text for multipath in > > > draft-ietf-mpls-lsp-pin g-01 > > > > > > > > > > > > In message > > > > , "Da > > > vid Allan" writes: > > > > > > > > > > > > Hi Curtis: > > > > > > > > > > > > > > > > > > > > > > > Just currious. Is the TTSI appropriate to handle > > > multipath, which is > > > > > what we are talking about here? At a midpoint there > > > would be multiple > > > > > indices, each index representing one branch of the > multipath at > > > > > midpoint. > > > > > > > > TTSI is an access point identifier, so it would work. Some > > > folks wanted to > > > > avoid having to request signalling changes by suggesting > > > existing RSVP > > > > fields COULD be used to populate TTSI at the egress (tunnel > > > ID) and this has > > > > resulted in a lot of confusion as to whether TTSI > > > identified an access point > > > > or a path. Each LSP ingress will have a unique TTSI. > > > > > > > > > > > > > > In any case, TTSI should not be used because it created a > > > completely > > > > > unnecessary tie to an ITU document. Ifindex (and maybe > > > TTSI) would > > > > > not be appropriate if the multipath split were in a > > > proprietary link > > > > > bundle. > > > > > > > > Only suggestion I would make is that MPIndex should then be > > > 32 bits, so that > > > > folks that want to use the (albeit poorly named) LSP ID > > > part of TTSI could > > > > do so (and this would not require an explicit tie to any > > > ITU documents). A > > > > node administered access point identifier should be able to > > > work even for > > > > propreitary bundles. > > > > > > > > cheers > > > > Dave > > > > > > > > > The intent was that it was an index indicating the Nth > branch of the > > > multipath branch point. N would typically ba a small > integer and very > > > seldom would have to even approach 100. > > > > > > Curtis > > > > > > > > > From owner-mpls@UU.NET Thu Jan 9 10:14:59 2003 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14057 for ; Thu, 9 Jan 2003 10:14:59 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnwxh00033 for ; Thu, 9 Jan 2003 15:18:14 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnwxh29839; Thu, 9 Jan 2003 15:18:08 GMT Received: by mail-control.ash.ops.us.uu.net id QQnwxh00929 for mpls-outgoing; Thu, 9 Jan 2003 15:17:48 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnwxh00922 for ; Thu, 9 Jan 2003 15:17:41 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnwxg17263 for ; Thu, 9 Jan 2003 15:14:25 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnwxg26236 for ; Thu, 9 Jan 2003 15:14:24 GMT Received: from rtp-msg-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-msg-core-1.cisco.com [161.44.11.97]) id QQnwxg26220 for ; Thu, 9 Jan 2003 15:14:24 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id h09FF2r5023871 for ; Thu, 9 Jan 2003 10:15:02 -0500 (EST) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA26321 for ; Thu, 9 Jan 2003 10:14:08 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h09FE8A09238 for mpls@uu.net; Thu, 9 Jan 2003 10:14:08 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnwxg29909 for ; Thu, 9 Jan 2003 15:12:45 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnwxg01571 for ; Thu, 9 Jan 2003 15:04:15 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnwxg23074 for ; Thu, 9 Jan 2003 15:04:14 GMT Received: from workhorse.fictitious.org by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: workhorse.fictitious.org [209.150.1.230]) id QQnwxg22902 for ; Thu, 9 Jan 2003 15:04:10 GMT Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id KAA73933; Thu, 9 Jan 2003 10:03:55 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200301091503.KAA73933@workhorse.fictitious.org> To: "David Allan" cc: curtis@fictitious.org, neil.2.harrison@bt.com, mpls@UU.NET Reply-To: curtis@fictitious.org Subject: Re: suggested added text for multipath in draft-ietf-mpls-lsp-pin g-01 In-reply-to: Your message of "Thu, 09 Jan 2003 09:53:26 EST." Date: Thu, 09 Jan 2003 10:03:55 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message , "Da vid Allan" writes: > Hi Curtis: > > I gathered the intent, I'm just seeking to align MPIndex with some other > node administered value (such as TTSI or IFIndex) so we do not require > further changes to make the relevant stuff accessable via MIBs or CLI > > Dave The counter that tells you how much can in for Label L and went out Path N is different from the counter that tells you how much traffic went out interface I. So you can't reuse MIB values and get useful counters. For example - It you expect a 50:50 split, its nice to poll a MIB and see that the result of the hash is at least close. It would also diagnose different problems. You may see lots of traffic on the outbound interface, but if you see one of these smaller counters stop incrementing then you know you have a problem. Curtis > > -----Original Message----- > > From: Curtis Villamizar [mailto:curtis@fictitious.org] > > Sent: Thursday, January 09, 2003 9:50 AM > > To: Allan, David [CAR:NS00:EXCH] > > Cc: curtis@fictitious.org; neil.2.harrison@bt.com; mpls@UU.NET > > Subject: Re: suggested added text for multipath in > > draft-ietf-mpls-lsp-pin g-01 > > > > > > > > In message > > , "Da > > vid Allan" writes: > > > > > > > > > Hi Curtis: > > > > > > > > > > > > > > > > > > Just currious. Is the TTSI appropriate to handle > > multipath, which is > > > > what we are talking about here? At a midpoint there > > would be multiple > > > > indices, each index representing one branch of the multipath at > > > > midpoint. > > > > > > TTSI is an access point identifier, so it would work. Some > > folks wanted to > > > avoid having to request signalling changes by suggesting > > existing RSVP > > > fields COULD be used to populate TTSI at the egress (tunnel > > ID) and this has > > > resulted in a lot of confusion as to whether TTSI > > identified an access point > > > or a path. Each LSP ingress will have a unique TTSI. > > > > > > > > > > > In any case, TTSI should not be used because it created a > > completely > > > > unnecessary tie to an ITU document. Ifindex (and maybe > > TTSI) would > > > > not be appropriate if the multipath split were in a > > proprietary link > > > > bundle. > > > > > > Only suggestion I would make is that MPIndex should then be > > 32 bits, so that > > > folks that want to use the (albeit poorly named) LSP ID > > part of TTSI could > > > do so (and this would not require an explicit tie to any > > ITU documents). A > > > node administered access point identifier should be able to > > work even for > > > propreitary bundles. > > > > > > cheers > > > Dave > > > > > > The intent was that it was an index indicating the Nth branch of the > > multipath branch point. N would typically ba a small integer and very > > seldom would have to even approach 100. > > > > Curtis > > > > > From owner-mpls@UU.NET Thu Jan 9 10:52:07 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15304 for ; Thu, 9 Jan 2003 10:52:07 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnwxj22813 for ; Thu, 9 Jan 2003 15:55:21 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnwxj22629; Thu, 9 Jan 2003 15:55:15 GMT Received: by mail-control.ash.ops.us.uu.net id QQnwxj03983 for mpls-outgoing; Thu, 9 Jan 2003 15:54:54 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnwxj03978 for ; Thu, 9 Jan 2003 15:54:52 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnwxj16991 for ; Thu, 9 Jan 2003 15:54:04 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnwxj06419 for ; Thu, 9 Jan 2003 15:54:04 GMT Received: from rtp-msg-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-msg-core-1.cisco.com [161.44.11.97]) id QQnwxj06411 for ; Thu, 9 Jan 2003 15:54:03 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id h09FsiaW001707 for ; Thu, 9 Jan 2003 10:54:44 -0500 (EST) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA01281 for ; Thu, 9 Jan 2003 10:54:02 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h09Fs2X13664 for mpls@uu.net; Thu, 9 Jan 2003 10:54:02 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnwxj03844 for ; Thu, 9 Jan 2003 15:52:46 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnwxj29085 for ; Thu, 9 Jan 2003 15:46:54 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnwxj00292 for ; Thu, 9 Jan 2003 15:46:53 GMT Received: from rtp-msg-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-msg-core-1.cisco.com [161.44.11.97]) id QQnwxj00286 for ; Thu, 9 Jan 2003 15:46:53 GMT Received: from bucket.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id h09FlUlm000350 for ; Thu, 9 Jan 2003 10:47:34 -0500 (EST) Received: from tnadeau-w2k.cisco.com ([161.44.145.36]) by bucket.cisco.com (Mirapoint) with ESMTP id ACJ55560; Thu, 9 Jan 2003 10:46:48 -0500 (EST) Message-Id: <5.2.0.9.2.20030109104353.03e968c8@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 09 Jan 2003 10:46:46 -0500 To: mpls@UU.NET From: "Thomas D. Nadeau" Subject: RE: suggested added text for multipath in draft-ietf-mpls-lsp-pin g-01 In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk At 09:43 AM 1/9/2003 -0500, David Allan wrote: >Hi Curtis: > > > > > > > > Just currious. Is the TTSI appropriate to handle multipath, which is > > what we are talking about here? At a midpoint there would be multiple > > indices, each index representing one branch of the multipath at > > midpoint. > >TTSI is an access point identifier, so it would work. Some folks wanted to >avoid having to request signalling changes by suggesting existing RSVP >fields COULD be used to populate TTSI at the egress (tunnel ID) and this has >resulted in a lot of confusion as to whether TTSI identified an access point >or a path. Each LSP ingress will have a unique TTSI. It is my recollection that the TTSI value as defined in Y.1711 is unusable due to its size. In short, it is too small to identify all of the possibilities. > > In any case, TTSI should not be used because it created a completely > > unnecessary tie to an ITU document. Ifindex (and maybe TTSI) would > > not be appropriate if the multipath split were in a proprietary link > > bundle. > >Only suggestion I would make is that MPIndex should then be 32 bits, so that >folks that want to use the (albeit poorly named) LSP ID part of TTSI could >do so (and this would not require an explicit tie to any ITU documents). I this it is a bad idea to explicit tie to the ITU-defined TTSI value. If it is deemed that we really need some sort of ID, lets make up our own. --Tom >A node administered access point identifier should be able to work even for >propreitary bundles. > >cheers >Dave "The difficult, we do immediately. The impossible takes a little longer." -- Air Force Motto http://www.mkp.com/books_catalog/catalog.asp?ISBN=1-55860-751-X From owner-mpls@UU.NET Thu Jan 9 11:00:08 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15725 for ; Thu, 9 Jan 2003 11:00:07 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnwxk05226 for ; Thu, 9 Jan 2003 16:03:23 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnwxk05064; Thu, 9 Jan 2003 16:03:19 GMT Received: by mail-control.ash.ops.us.uu.net id QQnwxk16064 for mpls-outgoing; Thu, 9 Jan 2003 16:02:54 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnwxk15515 for ; Thu, 9 Jan 2003 16:02:48 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnwxk07916 for ; Thu, 9 Jan 2003 16:00:27 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnwxk03607 for ; Thu, 9 Jan 2003 16:00:27 GMT Received: from zcars04e.nortelnetworks.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: zcars04e.nortelnetworks.com [47.129.242.56]) id QQnwxk03595 for ; Thu, 9 Jan 2003 16:00:27 GMT Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04e.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h09G0BJ18838; Thu, 9 Jan 2003 11:00:12 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 9 Jan 2003 11:00:12 -0500 Message-ID: From: "David Allan" To: "Thomas D. Nadeau" , mpls@UU.NET Subject: RE: suggested added text for multipath in draft-ietf-mpls-lsp-pin g-01 Date: Thu, 9 Jan 2003 11:00:09 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: owner-mpls@UU.NET Precedence: bulk Tom: 2**32 is sufficient for a node to enumerate the number of LSP ingresses it supports (this provides for 2**12 label spaces), which is what it is intended to do. It is too small to enumerate the number of fields required to identify an LSP in all current protocol instantiations, which is what it is not intended to do. No problem exists. cheers Dave > -----Original Message----- > From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > Sent: Thursday, January 09, 2003 10:47 AM > To: mpls@UU.NET > Subject: RE: suggested added text for multipath in > draft-ietf-mpls-lsp-pin g-01 > > > At 09:43 AM 1/9/2003 -0500, David Allan wrote: > > > >Hi Curtis: > > > > > > > > > > > > > Just currious. Is the TTSI appropriate to handle > multipath, which is > > > what we are talking about here? At a midpoint there > would be multiple > > > indices, each index representing one branch of the multipath at > > > midpoint. > > > >TTSI is an access point identifier, so it would work. Some > folks wanted to > >avoid having to request signalling changes by suggesting > existing RSVP > >fields COULD be used to populate TTSI at the egress (tunnel > ID) and this has > >resulted in a lot of confusion as to whether TTSI identified > an access point > >or a path. Each LSP ingress will have a unique TTSI. > > It is my recollection that the TTSI value as defined > in Y.1711 > is unusable due to its size. In short, it is too small to identify all > of the possibilities. > > > > In any case, TTSI should not be used because it created a > completely > > > unnecessary tie to an ITU document. Ifindex (and maybe > TTSI) would > > > not be appropriate if the multipath split were in a > proprietary link > > > bundle. > > > >Only suggestion I would make is that MPIndex should then be > 32 bits, so that > >folks that want to use the (albeit poorly named) LSP ID part > of TTSI could > >do so (and this would not require an explicit tie to any ITU > documents). > > I this it is a bad idea to explicit tie to the > ITU-defined TTSI > value. If it is > deemed that we really need some sort of ID, lets make up our own. > > --Tom > > > >A node administered access point identifier should be able > to work even for > >propreitary bundles. > > > >cheers > >Dave > > "The difficult, we do immediately. The impossible takes a > little longer." > -- Air Force Motto > > http://www.mkp.com/books_catalog/catalog.asp?ISBN=1-55860-751-X > > > > > From owner-mpls@UU.NET Thu Jan 9 11:05:15 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15934 for ; Thu, 9 Jan 2003 11:05:14 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnwxk15002 for ; Thu, 9 Jan 2003 16:08:21 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnwxk07981; Thu, 9 Jan 2003 16:04:37 GMT Received: by mail-control.ash.ops.us.uu.net id QQnwxk21767 for mpls-outgoing; Thu, 9 Jan 2003 16:03:54 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnwxk20304 for ; Thu, 9 Jan 2003 16:03:33 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnwxk03521 for ; Thu, 9 Jan 2003 16:03:15 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnwxk04892 for ; Thu, 9 Jan 2003 16:03:14 GMT Received: from rtp-msg-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-msg-core-1.cisco.com [161.44.11.97]) id QQnwxk04877 for ; Thu, 9 Jan 2003 16:03:14 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id h09G3rVH003673 for ; Thu, 9 Jan 2003 11:03:54 -0500 (EST) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id LAA02756 for ; Thu, 9 Jan 2003 11:03:10 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h09G3An14838 for mpls@uu.net; Thu, 9 Jan 2003 11:03:10 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnwxk14597 for ; Thu, 9 Jan 2003 16:01:39 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnwxj06303 for ; Thu, 9 Jan 2003 15:58:20 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnwxj27746 for ; Thu, 9 Jan 2003 15:58:15 GMT Received: from rtp-msg-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-msg-core-1.cisco.com [161.44.11.97]) id QQnwxj27063 for ; Thu, 9 Jan 2003 15:57:51 GMT Received: from bucket.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id h09FrkVk001551; Thu, 9 Jan 2003 10:53:46 -0500 (EST) Received: from tnadeau-w2k.cisco.com ([161.44.145.36]) by bucket.cisco.com (Mirapoint) with ESMTP id ACJ55727; Thu, 9 Jan 2003 10:53:04 -0500 (EST) Message-Id: <5.2.0.9.2.20030109104933.03e99540@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 09 Jan 2003 10:53:01 -0500 To: curtis@fictitious.org From: "Thomas D. Nadeau" Subject: Re: suggested added text for multipath in draft-ietf-mpls-lsp-pin g-01 Cc: "David Allan" , curtis@fictitious.org, neil.2.harrison@bt.com, mpls@UU.NET In-Reply-To: <200301091503.KAA73933@workhorse.fictitious.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk At 10:03 AM 1/9/2003 -0500, Curtis Villamizar wrote: >In message >, "Da >vid Allan" writes: > > Hi Curtis: > > > > I gathered the intent, I'm just seeking to align MPIndex with some other > > node administered value (such as TTSI or IFIndex) so we do not require > > further changes to make the relevant stuff accessable via MIBs or CLI > > > > Dave > > >The counter that tells you how much can in for Label L and went out >Path N is different from the counter that tells you how much traffic >went out interface I. So you can't reuse MIB values and get useful >counters. There are byte counters in the LSR MIB for example, that will show you per-label traffic counters. So if you are load-sharing at some node and sending out two or more labels, then you can look at the bytes/packetsOut on those outSegments (in LSR MIB terminology). >For example - It you expect a 50:50 split, its nice to poll a MIB and >see that the result of the hash is at least close. It would also >diagnose different problems. You may see lots of traffic on the >outbound interface, but if you see one of these smaller counters stop >incrementing then you know you have a problem. Yes, but this is a difficult strategy at best due to the (typically) large TFIBs of most production LSRs. This is akin to watching routes in the IP routing database, which can be pretty big. Scanning/polling this DB to look for anomalous counters is difficult performance-wise. --Tom >Curtis > > > > > -----Original Message----- > > > From: Curtis Villamizar [mailto:curtis@fictitious.org] > > > Sent: Thursday, January 09, 2003 9:50 AM > > > To: Allan, David [CAR:NS00:EXCH] > > > Cc: curtis@fictitious.org; neil.2.harrison@bt.com; mpls@UU.NET > > > Subject: Re: suggested added text for multipath in > > > draft-ietf-mpls-lsp-pin g-01 > > > > > > > > > > > > In message > > > , "Da > > > vid Allan" writes: > > > > > > > > > > > > Hi Curtis: > > > > > > > > > > > > > > > > > > > > > > > Just currious. Is the TTSI appropriate to handle > > > multipath, which is > > > > > what we are talking about here? At a midpoint there > > > would be multiple > > > > > indices, each index representing one branch of the multipath at > > > > > midpoint. > > > > > > > > TTSI is an access point identifier, so it would work. Some > > > folks wanted to > > > > avoid having to request signalling changes by suggesting > > > existing RSVP > > > > fields COULD be used to populate TTSI at the egress (tunnel > > > ID) and this has > > > > resulted in a lot of confusion as to whether TTSI > > > identified an access point > > > > or a path. Each LSP ingress will have a unique TTSI. > > > > > > > > > > > > > > In any case, TTSI should not be used because it created a > > > completely > > > > > unnecessary tie to an ITU document. Ifindex (and maybe > > > TTSI) would > > > > > not be appropriate if the multipath split were in a > > > proprietary link > > > > > bundle. > > > > > > > > Only suggestion I would make is that MPIndex should then be > > > 32 bits, so that > > > > folks that want to use the (albeit poorly named) LSP ID > > > part of TTSI could > > > > do so (and this would not require an explicit tie to any > > > ITU documents). A > > > > node administered access point identifier should be able to > > > work even for > > > > propreitary bundles. > > > > > > > > cheers > > > > Dave > > > > > > > > > The intent was that it was an index indicating the Nth branch of the > > > multipath branch point. N would typically ba a small integer and very > > > seldom would have to even approach 100. > > > > > > Curtis > > > > > > > > "The difficult, we do immediately. The impossible takes a little longer." -- Air Force Motto http://www.mkp.com/books_catalog/catalog.asp?ISBN=1-55860-751-X From owner-mpls@UU.NET Thu Jan 9 11:17:48 2003 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16390 for ; Thu, 9 Jan 2003 11:17:48 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnwxl00103 for ; Thu, 9 Jan 2003 16:20:59 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnwxl29605; Thu, 9 Jan 2003 16:20:44 GMT Received: by mail-control.ash.ops.us.uu.net id QQnwxl25065 for mpls-outgoing; Thu, 9 Jan 2003 16:20:25 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnwxl25060 for ; Thu, 9 Jan 2003 16:20:24 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnwxk06353 for ; Thu, 9 Jan 2003 16:14:16 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnwxk23808 for ; Thu, 9 Jan 2003 16:14:15 GMT Received: from rtp-msg-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-msg-core-1.cisco.com [161.44.11.97]) id QQnwxk23795 for ; Thu, 9 Jan 2003 16:14:15 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id h09GEtwL005904 for ; Thu, 9 Jan 2003 11:14:55 -0500 (EST) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id LAA03844 for ; Thu, 9 Jan 2003 11:14:12 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h09GECE17910 for mpls@uu.net; Thu, 9 Jan 2003 11:14:12 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnwxk24359 for ; Thu, 9 Jan 2003 16:13:16 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnwxk13522 for ; Thu, 9 Jan 2003 16:08:32 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnwxk13716 for ; Thu, 9 Jan 2003 16:08:32 GMT Received: from workhorse.fictitious.org by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: workhorse.fictitious.org [209.150.1.230]) id QQnwxk13690 for ; Thu, 9 Jan 2003 16:08:30 GMT Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id LAA74215; Thu, 9 Jan 2003 11:07:53 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200301091607.LAA74215@workhorse.fictitious.org> To: "David Allan" cc: curtis@fictitious.org, neil.2.harrison@bt.com, mpls@UU.NET Reply-To: curtis@fictitious.org Subject: Re: suggested added text for multipath in draft-ietf-mpls-lsp-pin g-01 In-reply-to: Your message of "Thu, 09 Jan 2003 10:08:42 EST." Date: Thu, 09 Jan 2003 11:07:53 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message , "Da vid Allan" writes: > > > If I have I/F index, I also have the label value from the downstream mapping > TLV so I can access counts at the label level. That's what I had in mind > when suggesting IF index. > > cheers > Dave The neat thing about multipath is that if there are branch points, there are also merge points. If there is more than one ingress, then it helps to be able to measure each independently. A LSR can be both a merge point for a prior multipath split and a branch point. B E For example: a minimal configuration in which / \ / \ D can be both a merge point and branch point if A D G multipath is used. \ / \ / C F This goes along with the rule of thumb that "if you can count it create a MIB variable for it". Some providers take the trouble to occasionally check that counters that can be cross checked are incrementing in a consistent manner. Another really good example of both a merge point and a branch point is a router supporting proprietary link bundles (for example: Avici CompositeLink tm) in which that router has a bundle of oc192c on the incoming (composite link) interface and the outgoing (composite link) interface. The ifindex gives the sum of the traffic. To figure out the split you have to dig further. [For example, Avici demo'd an 80 Gb link of this type a few years ago made of 8 oc48c before anyone had oc192c working and now can bundle oc192c and mix interface speeds in a bundle. MIB counters on the ifindex or ifindex plus outsegment give the sum of all of the physical interfaces]. More specific counters are good. In an 8 link bundle, each of the 8 incoming physical interfaces gets 1/8 of the traffic and should split the traffic among the 8 out going physical interfaces. If one stops working, 1/64 of the traffic will disappear. A counter that is not incrementing at all points to the problem where one output side interface with 1/8 too little traffic is both not as obvious and doesn't point to the source of the problem. If you just look at the insegment and outsegment MIBs (which sum the physical interface outsegment counters) then 1/64 of the traffic is missing which makes it a little harder to detect and diagnose. The faster such a problem is identified the better. Of course the router should not just happily sit there pitching traffic into a bit bucket, but ISPs don't want to just trust their supplier to do the right thing, they also want as many counters as they can get to verify it. Curtis > > -----Original Message----- > > From: Curtis Villamizar [mailto:curtis@fictitious.org] > > Sent: Thursday, January 09, 2003 10:04 AM > > To: Allan, David [CAR:NS00:EXCH] > > Cc: curtis@fictitious.org; neil.2.harrison@bt.com; mpls@UU.NET > > Subject: Re: suggested added text for multipath in > > draft-ietf-mpls-lsp-pin g-01 > > > > > > > > In message > > , "Da > > vid Allan" writes: > > > Hi Curtis: > > > > > > I gathered the intent, I'm just seeking to align MPIndex > > with some other > > > node administered value (such as TTSI or IFIndex) so we do > > not require > > > further changes to make the relevant stuff accessable via > > MIBs or CLI > > > > > > Dave > > > > > > The counter that tells you how much can in for Label L and went out > > Path N is different from the counter that tells you how much traffic > > went out interface I. So you can't reuse MIB values and get useful > > counters. > > > > For example - It you expect a 50:50 split, its nice to poll a MIB and > > see that the result of the hash is at least close. It would also > > diagnose different problems. You may see lots of traffic on the > > outbound interface, but if you see one of these smaller counters stop > > incrementing then you know you have a problem. > > > > Curtis > > > > > > > > -----Original Message----- > > > > From: Curtis Villamizar [mailto:curtis@fictitious.org] > > > > Sent: Thursday, January 09, 2003 9:50 AM > > > > To: Allan, David [CAR:NS00:EXCH] > > > > Cc: curtis@fictitious.org; neil.2.harrison@bt.com; mpls@UU.NET > > > > Subject: Re: suggested added text for multipath in > > > > draft-ietf-mpls-lsp-pin g-01 > > > > > > > > > > > > > > > > In message > > > > > > , "Da > > > > vid Allan" writes: > > > > > > > > > > > > > > > Hi Curtis: > > > > > > > > > > > > > > > > > > > > > > > > > > > > Just currious. Is the TTSI appropriate to handle > > > > multipath, which is > > > > > > what we are talking about here? At a midpoint there > > > > would be multiple > > > > > > indices, each index representing one branch of the > > multipath at > > > > > > midpoint. > > > > > > > > > > TTSI is an access point identifier, so it would work. Some > > > > folks wanted to > > > > > avoid having to request signalling changes by suggesting > > > > existing RSVP > > > > > fields COULD be used to populate TTSI at the egress (tunnel > > > > ID) and this has > > > > > resulted in a lot of confusion as to whether TTSI > > > > identified an access point > > > > > or a path. Each LSP ingress will have a unique TTSI. > > > > > > > > > > > > > > > > > In any case, TTSI should not be used because it created a > > > > completely > > > > > > unnecessary tie to an ITU document. Ifindex (and maybe > > > > TTSI) would > > > > > > not be appropriate if the multipath split were in a > > > > proprietary link > > > > > > bundle. > > > > > > > > > > Only suggestion I would make is that MPIndex should then be > > > > 32 bits, so that > > > > > folks that want to use the (albeit poorly named) LSP ID > > > > part of TTSI could > > > > > do so (and this would not require an explicit tie to any > > > > ITU documents). A > > > > > node administered access point identifier should be able to > > > > work even for > > > > > propreitary bundles. > > > > > > > > > > cheers > > > > > Dave > > > > > > > > > > > > The intent was that it was an index indicating the Nth > > branch of the > > > > multipath branch point. N would typically ba a small > > integer and very > > > > seldom would have to even approach 100. > > > > > > > > Curtis > > > > > > > > > > > > > > From owner-mpls@UU.NET Thu Jan 9 11:19:47 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16485 for ; Thu, 9 Jan 2003 11:19:47 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnwxl02222 for ; Thu, 9 Jan 2003 16:23:01 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnwxl02018; Thu, 9 Jan 2003 16:22:55 GMT Received: by mail-control.ash.ops.us.uu.net id QQnwxl25258 for mpls-outgoing; Thu, 9 Jan 2003 16:22:26 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnwxl25239 for ; Thu, 9 Jan 2003 16:22:22 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnwxl19506 for ; Thu, 9 Jan 2003 16:17:05 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnwxl28399 for ; Thu, 9 Jan 2003 16:17:04 GMT Received: from zcars04f.nortelnetworks.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: zcars04f.nortelnetworks.com [47.129.242.57]) id QQnwxl28372 for ; Thu, 9 Jan 2003 16:17:04 GMT Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h09GGmw15593; Thu, 9 Jan 2003 11:16:49 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 9 Jan 2003 11:16:49 -0500 Message-ID: From: "David Allan" To: curtis@fictitious.org Cc: curtis@fictitious.org, neil.2.harrison@bt.com, mpls@UU.NET Subject: RE: suggested added text for multipath in draft-ietf-mpls-lsp-pin g-01 Date: Thu, 9 Jan 2003 11:16:46 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: owner-mpls@UU.NET Precedence: bulk So what you are saying is that in your implementation you need counters nested deeper than I/F index + outsegment. OK, if we're going to tolerate all manners of proprietary implementations, I'm still on the reuse page for MP index. Lets just make it 32 bits, and make no further representations as to what you put in it. cheers Dave > -----Original Message----- > From: Curtis Villamizar [mailto:curtis@fictitious.org] > Sent: Thursday, January 09, 2003 11:08 AM > To: Allan, David [CAR:NS00:EXCH] > Cc: curtis@fictitious.org; neil.2.harrison@bt.com; mpls@UU.NET > Subject: Re: suggested added text for multipath in > draft-ietf-mpls-lsp-pin g-01 > > > > In message > , "Da > vid Allan" writes: > > > > > > If I have I/F index, I also have the label value from the > downstream mapping > > TLV so I can access counts at the label level. That's what > I had in mind > > when suggesting IF index. > > > > cheers > > Dave > > > The neat thing about multipath is that if there are branch points, > there are also merge points. If there is more than one ingress, then > it helps to be able to measure each independently. A LSR can be both > a merge point for a prior multipath split and a branch point. > > B E For example: a minimal configuration in which > / \ / \ D can be both a merge point and branch point if > A D G multipath is used. > \ / \ / > C F > > This goes along with the rule of thumb that "if you can count it > create a MIB variable for it". Some providers take the trouble to > occasionally check that counters that can be cross checked are > incrementing in a consistent manner. > > Another really good example of both a merge point and a branch point > is a router supporting proprietary link bundles (for example: Avici > CompositeLink tm) in which that router has a bundle of oc192c on the > incoming (composite link) interface and the outgoing (composite link) > interface. The ifindex gives the sum of the traffic. To figure out > the split you have to dig further. [For example, Avici demo'd an 80 > Gb link of this type a few years ago made of 8 oc48c before anyone had > oc192c working and now can bundle oc192c and mix interface speeds in a > bundle. MIB counters on the ifindex or ifindex plus outsegment give > the sum of all of the physical interfaces]. More specific counters > are good. In an 8 link bundle, each of the 8 incoming physical > interfaces gets 1/8 of the traffic and should split the traffic among > the 8 out going physical interfaces. If one stops working, 1/64 of > the traffic will disappear. A counter that is not incrementing at all > points to the problem where one output side interface with 1/8 too > little traffic is both not as obvious and doesn't point to the source > of the problem. If you just look at the insegment and outsegment MIBs > (which sum the physical interface outsegment counters) then 1/64 of > the traffic is missing which makes it a little harder to detect and > diagnose. The faster such a problem is identified the better. Of > course the router should not just happily sit there pitching traffic > into a bit bucket, but ISPs don't want to just trust their supplier to > do the right thing, they also want as many counters as they can get to > verify it. > > Curtis > > > > > -----Original Message----- > > > From: Curtis Villamizar [mailto:curtis@fictitious.org] > > > Sent: Thursday, January 09, 2003 10:04 AM > > > To: Allan, David [CAR:NS00:EXCH] > > > Cc: curtis@fictitious.org; neil.2.harrison@bt.com; mpls@UU.NET > > > Subject: Re: suggested added text for multipath in > > > draft-ietf-mpls-lsp-pin g-01 > > > > > > > > > > > > In message > > > > , "Da > > > vid Allan" writes: > > > > Hi Curtis: > > > > > > > > I gathered the intent, I'm just seeking to align MPIndex > > > with some other > > > > node administered value (such as TTSI or IFIndex) so we do > > > not require > > > > further changes to make the relevant stuff accessable via > > > MIBs or CLI > > > > > > > > Dave > > > > > > > > > The counter that tells you how much can in for Label L > and went out > > > Path N is different from the counter that tells you how > much traffic > > > went out interface I. So you can't reuse MIB values and > get useful > > > counters. > > > > > > For example - It you expect a 50:50 split, its nice to > poll a MIB and > > > see that the result of the hash is at least close. It would also > > > diagnose different problems. You may see lots of traffic on the > > > outbound interface, but if you see one of these smaller > counters stop > > > incrementing then you know you have a problem. > > > > > > Curtis > > > > > > > > > > > -----Original Message----- > > > > > From: Curtis Villamizar [mailto:curtis@fictitious.org] > > > > > Sent: Thursday, January 09, 2003 9:50 AM > > > > > To: Allan, David [CAR:NS00:EXCH] > > > > > Cc: curtis@fictitious.org; neil.2.harrison@bt.com; mpls@UU.NET > > > > > Subject: Re: suggested added text for multipath in > > > > > draft-ietf-mpls-lsp-pin g-01 > > > > > > > > > > > > > > > > > > > > In message > > > > > > > > > , "Da > > > > > vid Allan" writes: > > > > > > > > > > > > > > > > > > Hi Curtis: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Just currious. Is the TTSI appropriate to handle > > > > > multipath, which is > > > > > > > what we are talking about here? At a midpoint there > > > > > would be multiple > > > > > > > indices, each index representing one branch of the > > > multipath at > > > > > > > midpoint. > > > > > > > > > > > > TTSI is an access point identifier, so it would work. Some > > > > > folks wanted to > > > > > > avoid having to request signalling changes by suggesting > > > > > existing RSVP > > > > > > fields COULD be used to populate TTSI at the egress (tunnel > > > > > ID) and this has > > > > > > resulted in a lot of confusion as to whether TTSI > > > > > identified an access point > > > > > > or a path. Each LSP ingress will have a unique TTSI. > > > > > > > > > > > > > > > > > > > > In any case, TTSI should not be used because it created a > > > > > completely > > > > > > > unnecessary tie to an ITU document. Ifindex (and maybe > > > > > TTSI) would > > > > > > > not be appropriate if the multipath split were in a > > > > > proprietary link > > > > > > > bundle. > > > > > > > > > > > > Only suggestion I would make is that MPIndex should then be > > > > > 32 bits, so that > > > > > > folks that want to use the (albeit poorly named) LSP ID > > > > > part of TTSI could > > > > > > do so (and this would not require an explicit tie to any > > > > > ITU documents). A > > > > > > node administered access point identifier should be able to > > > > > work even for > > > > > > propreitary bundles. > > > > > > > > > > > > cheers > > > > > > Dave > > > > > > > > > > > > > > > The intent was that it was an index indicating the Nth > > > branch of the > > > > > multipath branch point. N would typically ba a small > > > integer and very > > > > > seldom would have to even approach 100. > > > > > > > > > > Curtis > > > > > > > > > > > > > > > > > > > > From owner-mpls@UU.NET Thu Jan 9 13:12:14 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19548 for ; Thu, 9 Jan 2003 13:12:14 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnwxt13181 for ; Thu, 9 Jan 2003 18:15:28 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnwxt12789; Thu, 9 Jan 2003 18:15:17 GMT Received: by mail-control.ash.ops.us.uu.net id QQnwxs11464 for mpls-outgoing; Thu, 9 Jan 2003 18:14:45 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnwxs11459 for ; Thu, 9 Jan 2003 18:14:36 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnwxs07458 for ; Thu, 9 Jan 2003 18:12:06 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnwxs05525 for ; Thu, 9 Jan 2003 18:12:06 GMT Received: from rtp-msg-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-msg-core-1.cisco.com [161.44.11.97]) id QQnwxs05514 for ; Thu, 9 Jan 2003 18:12:05 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id h09ICjrL026315 for ; Thu, 9 Jan 2003 13:12:46 -0500 (EST) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id NAA13093 for ; Thu, 9 Jan 2003 13:12:03 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h09IC3l26629 for mpls@uu.net; Thu, 9 Jan 2003 13:12:03 -0500 (EST) Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnwxs10406 for ; Thu, 9 Jan 2003 18:09:53 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnwxs22745 for ; Thu, 9 Jan 2003 18:08:30 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnwxs02302 for ; Thu, 9 Jan 2003 18:08:29 GMT Received: from workhorse.fictitious.org by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: workhorse.fictitious.org [209.150.1.230]) id QQnwxs02284 for ; Thu, 9 Jan 2003 18:08:28 GMT Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id NAA74633; Thu, 9 Jan 2003 13:08:27 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200301091808.NAA74633@workhorse.fictitious.org> To: "Thomas D. Nadeau" cc: curtis@fictitious.org, "David Allan" , neil.2.harrison@bt.com, mpls@UU.NET Reply-To: curtis@fictitious.org Subject: Re: suggested added text for multipath in draft-ietf-mpls-lsp-pin g-01 In-reply-to: Your message of "Thu, 09 Jan 2003 10:53:01 EST." <5.2.0.9.2.20030109104933.03e99540@bucket.cisco.com> Date: Thu, 09 Jan 2003 13:08:27 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <5.2.0.9.2.20030109104933.03e99540@bucket.cisco.com>, "Thomas D. Nad eau" writes: > > > >For example - It you expect a 50:50 split, its nice to poll a MIB and > >see that the result of the hash is at least close. It would also > >diagnose different problems. You may see lots of traffic on the > >outbound interface, but if you see one of these smaller counters stop > >incrementing then you know you have a problem. > > Yes, but this is a difficult strategy at best due to the (typically) > large TFIBs of most production LSRs. This is akin to watching routes > in the IP routing database, which can be pretty big. Scanning/polling > this DB to look for anomalous counters is difficult performance-wise. > > --Tom The last ISP that I worked at that *did* do fine grained consistency checking did not use a MIB at all. They had a Unix based router and could access the counters more efficiently and produce consistency checks on the router itself. That same provider also *did* capture the routing table on all of the routers and check it for consistency across routers. That also was *not* done with SNMP. I know they did because I did it. OTOH those queries were run regularly only when there were under 20,000 routes. I think we resurected it and ran it when we identified the broken MED processing initially defined for BGP. In case you haven't guessed that ISP was ANS and the routers were the NSS routers that were produced as part of the NSFNET project in the early to mid-1990s. I think we did manage to do similar queries on Bay and Cisco routers using show commands with infinite line counts (using TCP instead of SNMP to gather information). Use what works! MIB access does create some inefficiency. Even with a better way to access the counters, doing the processing in a nearby pizza box creates a bit more inefficiency due to the need to move the data. Neither is all that hard. Some boxes used to fall over if you do too much SNMP query. I hope that is no longer the case. At least some can handle it. Curtis From owner-mpls@UU.NET Thu Jan 9 13:52:36 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20776 for ; Thu, 9 Jan 2003 13:52:36 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnwxv20066 for ; Thu, 9 Jan 2003 18:55:50 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnwxv19844; Thu, 9 Jan 2003 18:55:44 GMT Received: by mail-control.ash.ops.us.uu.net id QQnwxv14753 for mpls-outgoing; Thu, 9 Jan 2003 18:55:28 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnwxv14740 for ; Thu, 9 Jan 2003 18:55:16 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnwxv06352 for ; Thu, 9 Jan 2003 18:52:09 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnwxv08396 for ; Thu, 9 Jan 2003 18:52:08 GMT Received: from rtp-msg-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-msg-core-1.cisco.com [161.44.11.97]) id QQnwxv08389 for ; Thu, 9 Jan 2003 18:52:08 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id h09IqjdT003313 for ; Thu, 9 Jan 2003 13:52:45 -0500 (EST) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id NAA16610 for ; Thu, 9 Jan 2003 13:52:03 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h09Iq3M00396 for mpls@uu.net; Thu, 9 Jan 2003 13:52:03 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnwxv14428 for ; Thu, 9 Jan 2003 18:50:31 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnwxv00986 for ; Thu, 9 Jan 2003 18:50:17 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnwxv15884 for ; Thu, 9 Jan 2003 18:50:16 GMT Received: from workhorse.fictitious.org by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: workhorse.fictitious.org [209.150.1.230]) id QQnwxv15870 for ; Thu, 9 Jan 2003 18:50:15 GMT Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id NAA74706; Thu, 9 Jan 2003 13:49:19 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200301091849.NAA74706@workhorse.fictitious.org> To: "David Allan" cc: curtis@fictitious.org, neil.2.harrison@bt.com, mpls@UU.NET Reply-To: curtis@fictitious.org Subject: Re: suggested added text for multipath in draft-ietf-mpls-lsp-pin g-01 In-reply-to: Your message of "Thu, 09 Jan 2003 11:16:46 EST." Date: Thu, 09 Jan 2003 13:49:19 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message , "Da vid Allan" writes: > > > I'm still on the reuse page for MP index. Lets just make it 32 bits, and > make no further representations as to what you put in it. Fine. We'll make it 32 bits and make no indication of what to put in it as long as the index is unique within the split. Curtis From owner-mpls@UU.NET Thu Jan 9 14:04:14 2003 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22188 for ; Thu, 9 Jan 2003 14:04:14 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnwxw22739 for ; Thu, 9 Jan 2003 19:07:27 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnwxw22376; Thu, 9 Jan 2003 19:07:14 GMT Received: by mail-control.ash.ops.us.uu.net id QQnwxw03763 for mpls-outgoing; Thu, 9 Jan 2003 19:06:44 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnwxw03741 for ; Thu, 9 Jan 2003 19:06:33 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnwxw07888 for ; Thu, 9 Jan 2003 19:05:06 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnwxw20955 for ; Thu, 9 Jan 2003 19:05:06 GMT Received: from rtp-msg-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-msg-core-1.cisco.com [161.44.11.97]) id QQnwxw20951 for ; Thu, 9 Jan 2003 19:05:06 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id h09J5jmf006270 for ; Thu, 9 Jan 2003 14:05:45 -0500 (EST) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA17844 for ; Thu, 9 Jan 2003 14:05:03 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h09J53m02493 for mpls@uu.net; Thu, 9 Jan 2003 14:05:03 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnwxw26250 for ; Thu, 9 Jan 2003 19:03:55 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnwxw09572 for ; Thu, 9 Jan 2003 19:00:09 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnwxw15995 for ; Thu, 9 Jan 2003 19:00:09 GMT Received: from rtp-msg-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-msg-core-1.cisco.com [161.44.11.97]) id QQnwxw15985 for ; Thu, 9 Jan 2003 19:00:09 GMT Received: from bucket.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id h09Iuqo2004382; Thu, 9 Jan 2003 13:56:52 -0500 (EST) Received: from tnadeau-w2k.cisco.com ([161.44.145.36]) by bucket.cisco.com (Mirapoint) with ESMTP id ACJ60038; Thu, 9 Jan 2003 13:56:09 -0500 (EST) Message-Id: <5.2.0.9.2.20030109134939.068c5178@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 09 Jan 2003 13:56:06 -0500 To: curtis@fictitious.org From: "Thomas D. Nadeau" Subject: Re: suggested added text for multipath in draft-ietf-mpls-lsp-pin g-01 Cc: curtis@fictitious.org, "David Allan" , neil.2.harrison@bt.com, mpls@UU.NET In-Reply-To: <200301091808.NAA74633@workhorse.fictitious.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk At 01:08 PM 1/9/2003 -0500, Curtis Villamizar wrote: >In message <5.2.0.9.2.20030109104933.03e99540@bucket.cisco.com>, "Thomas >D. Nad >eau" writes: > > > > > > >For example - It you expect a 50:50 split, its nice to poll a MIB and > > >see that the result of the hash is at least close. It would also > > >diagnose different problems. You may see lots of traffic on the > > >outbound interface, but if you see one of these smaller counters stop > > >incrementing then you know you have a problem. > > > > Yes, but this is a difficult strategy at best due to the > (typically) > > large TFIBs of most production LSRs. This is akin to watching routes > > in the IP routing database, which can be pretty big. Scanning/polling > > this DB to look for anomalous counters is difficult performance-wise. > > > > --Tom > > >The last ISP that I worked at that *did* do fine grained consistency >checking did not use a MIB at all. They had a Unix based router and >could access the counters more efficiently and produce consistency >checks on the router itself. Whatever you feel is the best tool to use is fine with me. In my experience, polling the TFIB for its counters hasn't been a successful approach using any tool. I was only pointing out which MIB objects are available to get the values you were interested in from your initial posting. Of course, everyone has a CLI for those counters too, but I think you were questioning whether such variables exist in MIBs today. >That same provider also *did* capture the routing table on all of the >routers and check it for consistency across routers. That also was >*not* done with SNMP. I know they did because I did it. OTOH those >queries were run regularly only when there were under 20,000 routes. >I think we resurected it and ran it when we identified the broken MED >processing initially defined for BGP. > >In case you haven't guessed that ISP was ANS and the routers were the >NSS routers that were produced as part of the NSFNET project in the >early to mid-1990s. I think we did manage to do similar queries on >Bay and Cisco routers using show commands with infinite line counts >(using TCP instead of SNMP to gather information). Use what works! Again, I don't care which management interface you use as long as it works for you. I still personally don't think that querying/polling 100,000 or more entries frequently is a good idea -- via any interface. >MIB access does create some inefficiency. Even with a better way to >access the counters, doing the processing in a nearby pizza box >creates a bit more inefficiency due to the need to move the data. >Neither is all that hard. > >Some boxes used to fall over if you do too much SNMP query. I hope >that is no longer the case. At least some can handle it. My assertion is that all boxes will eventually fall over given enough work to do. *) --Tom "The difficult, we do immediately. The impossible takes a little longer." -- Air Force Motto http://www.mkp.com/books_catalog/catalog.asp?ISBN=1-55860-751-X From owner-mpls@UU.NET Thu Jan 9 14:59:53 2003 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24688 for ; Thu, 9 Jan 2003 14:59:52 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnwya01933 for ; Thu, 9 Jan 2003 20:03:06 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnwya01475; Thu, 9 Jan 2003 20:02:53 GMT Received: by mail-control.ash.ops.us.uu.net id QQnwya19631 for mpls-outgoing; Thu, 9 Jan 2003 20:02:25 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnwya19573 for ; Thu, 9 Jan 2003 20:02:19 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnwya21317 for ; Thu, 9 Jan 2003 20:02:04 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnwya22221 for ; Thu, 9 Jan 2003 20:02:03 GMT Received: from rtp-msg-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-msg-core-1.cisco.com [161.44.11.97]) id QQnwya22215 for ; Thu, 9 Jan 2003 20:02:03 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id h09K2ibp017021 for ; Thu, 9 Jan 2003 15:02:44 -0500 (EST) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id PAA23462 for ; Thu, 9 Jan 2003 15:02:01 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h09K21S08425 for mpls@uu.net; Thu, 9 Jan 2003 15:02:01 -0500 (EST) Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnwya14134 for ; Thu, 9 Jan 2003 20:00:58 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnwxz19659 for ; Thu, 9 Jan 2003 19:59:51 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnwxz10276 for ; Thu, 9 Jan 2003 19:59:50 GMT Received: from workhorse.fictitious.org by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: workhorse.fictitious.org [209.150.1.230]) id QQnwxz10271 for ; Thu, 9 Jan 2003 19:59:49 GMT Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id OAA75233; Thu, 9 Jan 2003 14:59:44 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200301091959.OAA75233@workhorse.fictitious.org> To: "Thomas D. Nadeau" cc: curtis@fictitious.org, "David Allan" , neil.2.harrison@bt.com, mpls@UU.NET Reply-To: curtis@fictitious.org Subject: Re: suggested added text for multipath in draft-ietf-mpls-lsp-pin g-01 In-reply-to: Your message of "Thu, 09 Jan 2003 13:56:06 EST." <5.2.0.9.2.20030109134939.068c5178@bucket.cisco.com> Date: Thu, 09 Jan 2003 14:59:44 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <5.2.0.9.2.20030109134939.068c5178@bucket.cisco.com>, "Thomas D. Nad eau" writes: > > > >In case you haven't guessed that ISP was ANS and the routers were the > >NSS routers that were produced as part of the NSFNET project in the > >early to mid-1990s. I think we did manage to do similar queries on > >Bay and Cisco routers using show commands with infinite line counts > >(using TCP instead of SNMP to gather information). Use what works! > > Again, I don't care which management interface you use as long > as it works for you. I still personally don't think that querying/polling > 100,000 or more entries frequently is a good idea -- via any interface. The NSS did this the best. A request for the routing table was serviced in a single atomic write to application space. BSD copy-on-write VM semantics are nice to have. From their it was transferred further, like written out to the controlling terminal if doing a netstat -k (netstat -r using the special kernel interface) or processed or transferred by the application by whatever means. Very low overhead compared to the old successive get-next approach. Bulk SNMP trasfer could be done in the same way today. > >MIB access does create some inefficiency. Even with a better way to > >access the counters, doing the processing in a nearby pizza box > >creates a bit more inefficiency due to the need to move the data. > >Neither is all that hard. > > > >Some boxes used to fall over if you do too much SNMP query. I hope > >that is no longer the case. At least some can handle it. > > My assertion is that all boxes will eventually fall over given enoug > h > work to do. *) Wrong! Not with SNMP if there are hardware queues that give SNMP a WFQ queue and are only serviced if the router can handle it. Abusive query, including intentional query at near line rate cannot knock over a router designed that way. SNMP queries will be dropped though. > --Tom Curtis ps - we're off topic now. From owner-mpls@UU.NET Thu Jan 9 15:29:28 2003 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25397 for ; Thu, 9 Jan 2003 15:29:28 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnwyc07170 for ; Thu, 9 Jan 2003 20:32:44 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnwyc06917; Thu, 9 Jan 2003 20:32:36 GMT Received: by mail-control.ash.ops.us.uu.net id QQnwyc00263 for mpls-outgoing; Thu, 9 Jan 2003 20:32:09 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnwyc00254 for ; Thu, 9 Jan 2003 20:31:50 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnwyb29030 for ; Thu, 9 Jan 2003 20:29:37 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnwyb15974 for ; Thu, 9 Jan 2003 20:29:36 GMT Received: from maila.telia.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: maila.telia.com [194.22.194.231]) id QQnwyb15958 for ; Thu, 9 Jan 2003 20:29:36 GMT Received: from d1o888.telia.com (d1o888.telia.com [213.67.172.241]) by maila.telia.com (8.12.5/8.12.5) with ESMTP id h09KTWKc002040; Thu, 9 Jan 2003 21:29:32 +0100 (CET) X-Original-Recipient: mpls@UU.NET Received: from pi.se (h70n2fls31o888.telia.com [213.64.120.70]) by d1o888.telia.com (8.10.2/8.10.1) with ESMTP id h09KTV220424; Thu, 9 Jan 2003 21:29:31 +0100 (CET) Message-ID: <3E1DDACD.8090900@pi.se> Date: Thu, 09 Jan 2003 21:25:49 +0100 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "'mpls@uu.net'" CC: Adrian Farrel Subject: Re: LDP Restart Applicablity Statement - Comments please References: <002b01c29820$fa957730$ef13588a@movaz.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit All, we've had only a few responses to this mail (all of them positive). I would like to invite further comments. Technically we have the 10-20 people having read the document, but it would be good if it did show on the list. I will revisit this end of next week and see if we have support for making it a wg doc. /Loa Adrian Farrel wrote: > Hi, > > I gave a brief overview of draft-farrel0mpls-ldp-restart-applic-01.txt in > Atlanta and asked that it move forward as WG document not least because it was > requested by the chairs and because its existence will help the progress of > draft-ietf-mpls-ldp-ft and draft-ietf-mpls-ldp-restart as they try to become > RFCs. > > It seemed to be the case in Atlanta that very few people had read the draft and > as Bert has commented elsewhere we should at least get 10 or 20 people to read > drafts before they become WG documents. So... > > I believe implementers of LDP need to give serious consideration to at least one > of draft-ietf-mpls-ldp-ft and draft-ietf-mpls-ldp-restart. This applicability > statement should help them decide whether and which to implement. > > It would be a great help if all those concerned with LDP could cast an eye over > the draft and send comments to the mailing list. At the moment, comments such > as "read it, looks good" or "read it, don't like it" would be as useful as > detailed feedback since they will give us some feeling about the value of the > draft. > > Thanks, > Adrian > > > > -- Loa Andersson Mobile +46 739 81 21 64 Email loa@pi.se From owner-mpls@UU.NET Thu Jan 9 15:45:50 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25741 for ; Thu, 9 Jan 2003 15:45:50 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnwyd00894 for ; Thu, 9 Jan 2003 20:49:06 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnwyd00668; Thu, 9 Jan 2003 20:49:00 GMT Received: by mail-control.ash.ops.us.uu.net id QQnwyd01771 for mpls-outgoing; Thu, 9 Jan 2003 20:48:32 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnwyd01749 for ; Thu, 9 Jan 2003 20:48:22 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnwyc17622 for ; Thu, 9 Jan 2003 20:42:13 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnwyc25055 for ; Thu, 9 Jan 2003 20:42:12 GMT Received: from rtp-msg-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-msg-core-1.cisco.com [161.44.11.97]) id QQnwyc25049 for ; Thu, 9 Jan 2003 20:42:12 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id h09Kgpvn024271 for ; Thu, 9 Jan 2003 15:42:51 -0500 (EST) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id PAA27002 for ; Thu, 9 Jan 2003 15:42:04 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h09Kg3313138 for mpls@uu.net; Thu, 9 Jan 2003 15:42:03 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnwyc00946 for ; Thu, 9 Jan 2003 20:41:42 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnwyc03722 for ; Thu, 9 Jan 2003 20:41:38 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnwyc24690 for ; Thu, 9 Jan 2003 20:41:38 GMT Received: from rtp-msg-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-msg-core-1.cisco.com [161.44.11.97]) id QQnwyc24685 for ; Thu, 9 Jan 2003 20:41:38 GMT Received: from bucket.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id h09KgCeP024186; Thu, 9 Jan 2003 15:42:13 -0500 (EST) Received: from tnadeau-w2k.cisco.com ([161.44.145.36]) by bucket.cisco.com (Mirapoint) with ESMTP id ACJ62849; Thu, 9 Jan 2003 15:41:29 -0500 (EST) Message-Id: <5.2.0.9.2.20030109154051.06aa09b8@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 09 Jan 2003 15:41:27 -0500 To: curtis@fictitious.org From: "Thomas D. Nadeau" Subject: Re: suggested added text for multipath in draft-ietf-mpls-lsp-pin g-01 Cc: mpls@UU.NET In-Reply-To: <200301091959.OAA75233@workhorse.fictitious.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk >In message <5.2.0.9.2.20030109134939.068c5178@bucket.cisco.com>, "Thomas >D. Nad >eau" writes: > > > > > >In case you haven't guessed that ISP was ANS and the routers were the > > >NSS routers that were produced as part of the NSFNET project in the > > >early to mid-1990s. I think we did manage to do similar queries on > > >Bay and Cisco routers using show commands with infinite line counts > > >(using TCP instead of SNMP to gather information). Use what works! > > > > Again, I don't care which management interface you use as long > > as it works for you. I still personally don't think that querying/polling > > 100,000 or more entries frequently is a good idea -- via any interface. > >The NSS did this the best. A request for the routing table was >serviced in a single atomic write to application space. BSD >copy-on-write VM semantics are nice to have. From their it was >transferred further, like written out to the controlling terminal if >doing a netstat -k (netstat -r using the special kernel interface) or >processed or transferred by the application by whatever means. Very >low overhead compared to the old successive get-next approach. Bulk >SNMP trasfer could be done in the same way today. > > > >MIB access does create some inefficiency. Even with a better way to > > >access the counters, doing the processing in a nearby pizza box > > >creates a bit more inefficiency due to the need to move the data. > > >Neither is all that hard. > > > > > >Some boxes used to fall over if you do too much SNMP query. I hope > > >that is no longer the case. At least some can handle it. > > > > My assertion is that all boxes will eventually fall over given > enoug > > h > > work to do. *) > >Wrong! Not with SNMP if there are hardware queues that give SNMP a >WFQ queue and are only serviced if the router can handle it. Abusive >query, including intentional query at near line rate cannot knock over >a router designed that way. SNMP queries will be dropped though. I didn't specifically say _which_ work. *) --Tom > > --Tom > >Curtis > >ps - we're off topic now. "The difficult, we do immediately. The impossible takes a little longer." -- Air Force Motto http://www.mkp.com/books_catalog/catalog.asp?ISBN=1-55860-751-X From owner-mpls@UU.NET Thu Jan 9 16:43:41 2003 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27336 for ; Thu, 9 Jan 2003 16:43:41 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnwyh26721 for ; Thu, 9 Jan 2003 21:46:57 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnwyh26422; Thu, 9 Jan 2003 21:46:50 GMT Received: by mail-control.ash.ops.us.uu.net id QQnwyh25457 for mpls-outgoing; Thu, 9 Jan 2003 21:46:33 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnwyh25446 for ; Thu, 9 Jan 2003 21:46:28 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnwyg13095 for ; Thu, 9 Jan 2003 21:44:47 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnwyg24254 for ; Thu, 9 Jan 2003 21:44:47 GMT Received: from dnsmx1pya.telcordia.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: dnsmx1pya.telcordia.com [128.96.20.31]) id QQnwyg24245 for ; Thu, 9 Jan 2003 21:44:46 GMT Received: from notes640.cc.telcordia.com (notes640.cc.telcordia.com [128.96.22.6]) by dnsmx1pya.telcordia.com (8.9.3/8.9.3) with ESMTP id QAA29900 for ; Thu, 9 Jan 2003 16:39:18 -0500 (EST) Subject: RFC2961 clarification To: mpls@UU.NET X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: "Hong Liao" Date: Thu, 9 Jan 2003 16:38:59 -0500 X-MIMETrack: Serialize by Router on notes640/Telcordia(Release 5.0.6a |January 17, 2001) at 01/09/2003 04:39:18 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Hi, I need the clarification for one issue. In spec RFC2961, Section 5.2 'Srefresh messages carrying Message_Identifier fields corresponding to Path state are normally sent with a destination IP address equal to the address carried in the corresponding SESSION objects.' Here the destination ip address and source ip address mentioned in the following paragraph is the one in srefresh ip header or in the Srefresh Message_Id SRC_LIST, or MESSAGE_ID MCAST_LIST object. I think it means the source and destination address in the ip header, can anyone help me to confirm this? Thanks, Julia From owner-mpls@UU.NET Thu Jan 9 17:16:25 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28170 for ; Thu, 9 Jan 2003 17:16:24 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnwyj16417 for ; Thu, 9 Jan 2003 22:19:41 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnwyj16250; Thu, 9 Jan 2003 22:19:37 GMT Received: by mail-control.ash.ops.us.uu.net id QQnwyj16362 for mpls-outgoing; Thu, 9 Jan 2003 22:19:13 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnwyj16357 for ; Thu, 9 Jan 2003 22:19:12 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnwyi18156 for ; Thu, 9 Jan 2003 22:09:27 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnwyi08174 for ; Thu, 9 Jan 2003 22:09:26 GMT Received: from mailgate.pit.comms.marconi.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6]) id QQnwyi08170 for ; Thu, 9 Jan 2003 22:09:26 GMT Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA14911 for ; Thu, 9 Jan 2003 17:08:59 -0500 (EST) Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA18350 for ; Thu, 9 Jan 2003 17:08:00 -0500 (EST) Message-ID: <3E1DF2C7.8000704@marconi.com> Date: Thu, 09 Jan 2003 17:08:07 -0500 From: David Charlap Organization: Marconi, Vienna VA User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en, he MIME-Version: 1.0 To: mpls@UU.NET Subject: Re: RFC2961 clarification References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hong Liao wrote: > > In spec RFC2961, Section 5.2 > > 'Srefresh messages carrying Message_Identifier fields corresponding to Path > state are normally sent with a destination IP address equal to the address > carried in the corresponding SESSION objects.' > > Here the destination ip address and source ip address mentioned in the > following paragraph is the one in srefresh ip header or in the Srefresh > Message_Id SRC_LIST, or MESSAGE_ID MCAST_LIST object. > > I think it means the source and destination address in the ip header, can > anyone help me to confirm this? The RFC is correct. The SESSION address should be the destination, and router alert should be used in order to enable the next-hop to intercept this message. This is required for multicast sessions, since the actual next-hop addres is unknown. For the subset of RSVP that is used by MPLS at this time, you may also use the next-hop address in the IP header (without router alert.) Note the second half of the paragraph your cited: ... The destination IP address MAY be set to the RSVP next hop when the next hop is known to be RSVP capable and either (a) the session is unicast or (b) the outgoing interface is a point-to-point link. ... This should be applicable for most current MPLS implementations. It may actually be applicable to all implementations, since I've never heard of any means for running LSPs over broadcast links. -- David From owner-mpls@UU.NET Thu Jan 9 17:50:55 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28919 for ; Thu, 9 Jan 2003 17:50:55 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnwyl19410 for ; Thu, 9 Jan 2003 22:54:08 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnwyl19124; Thu, 9 Jan 2003 22:54:01 GMT Received: by mail-control.ash.ops.us.uu.net id QQnwyl19153 for mpls-outgoing; Thu, 9 Jan 2003 22:53:34 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnwyl19144 for ; Thu, 9 Jan 2003 22:53:18 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnwyl19861 for ; Thu, 9 Jan 2003 22:50:19 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnwyl20619 for ; Thu, 9 Jan 2003 22:50:18 GMT Received: from ns2.vivacenetworks.com by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: [64.221.212.135]) id QQnwyl20553 for ; Thu, 9 Jan 2003 22:50:14 GMT Received: from AMALIS.vivacenetworks.com ([10.5.20.13]) by vivacenetworks.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 9 Jan 2003 14:49:52 -0800 Message-Id: <5.1.0.14.2.20030109174826.0c927780@po1.vivacenetworks.com> X-Sender: vivacenet\amalis@po1.vivacenetworks.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 09 Jan 2003 17:49:49 -0500 To: Loa Andersson From: "Andrew G. Malis" Subject: Re: LDP Restart Applicablity Statement - Comments please Cc: "'mpls@uu.net'" , Adrian Farrel In-Reply-To: <3E1DDACD.8090900@pi.se> References: <002b01c29820$fa957730$ef13588a@movaz.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 09 Jan 2003 22:49:52.0504 (UTC) FILETIME=[6C060F80:01C2B831] Sender: owner-mpls@UU.NET Precedence: bulk Loa, Absolutely - I will reiterate my support to make it a WG document. Cheers, Andy ------ At 1/9/2003 09:25 PM +0100, Loa Andersson wrote: >All, > >we've had only a few responses to this mail (all of them positive). I >would like to invite further comments. Technically we have the 10-20 >people having read the document, but it would be good if it did show >on the list. > >I will revisit this end of next week and see if we have support for >making it a wg doc. > >/Loa > >Adrian Farrel wrote: >>Hi, >>I gave a brief overview of draft-farrel0mpls-ldp-restart-applic-01.txt in >>Atlanta and asked that it move forward as WG document not least because >>it was >>requested by the chairs and because its existence will help the progress of >>draft-ietf-mpls-ldp-ft and draft-ietf-mpls-ldp-restart as they try to become >>RFCs. >>It seemed to be the case in Atlanta that very few people had read the >>draft and >>as Bert has commented elsewhere we should at least get 10 or 20 people to >>read >>drafts before they become WG documents. So... >>I believe implementers of LDP need to give serious consideration to at >>least one >>of draft-ietf-mpls-ldp-ft and draft-ietf-mpls-ldp-restart. This applicability >>statement should help them decide whether and which to implement. >>It would be a great help if all those concerned with LDP could cast an >>eye over >>the draft and send comments to the mailing list. At the moment, comments >>such >>as "read it, looks good" or "read it, don't like it" would be as useful as >>detailed feedback since they will give us some feeling about the value of the >>draft. >>Thanks, >>Adrian >> > > >-- >Loa Andersson > >Mobile +46 739 81 21 64 >Email loa@pi.se > > From owner-mpls@UU.NET Fri Jan 10 07:56:02 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26738 for ; Fri, 10 Jan 2003 07:56:02 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnxap05880 for ; Fri, 10 Jan 2003 12:59:18 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnxap05729; Fri, 10 Jan 2003 12:59:15 GMT Received: by mail-control.ash.ops.us.uu.net id QQnxap09476 for mpls-outgoing; Fri, 10 Jan 2003 12:59:02 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnxap09469 for ; Fri, 10 Jan 2003 12:58:50 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnxap07448 for ; Fri, 10 Jan 2003 12:58:00 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnxap04747 for ; Fri, 10 Jan 2003 12:57:59 GMT Received: from relay2.clb.oleane.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: relay2.clb.oleane.net [213.56.31.22]) id QQnxap04737 for ; Fri, 10 Jan 2003 12:57:59 GMT Received: from oleane ([194.250.212.114]) by relay2.clb.oleane.net with SMTP id h0ACvwDY019611 for ; Fri, 10 Jan 2003 13:57:58 +0100 Message-ID: <01fc01c2b8a7$e673e780$0601a8c0@oleane.com> From: "Peter Lewis" To: Subject: MPLS World Congress 03 - Interoperability Event Date: Fri, 10 Jan 2003 13:57:57 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01F9_01C2B8B0.47E46320" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_01F9_01C2B8B0.47E46320 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Interop Event at MPLS World Congress: A Great Success=20 12 companies have already decided to participate to the interoperability = showcase performed during the MPLS World Congress next February 4 to 7 = in Paris (list below). The organizers expect to attract 20 companies.=20 . Agilent=20 . Alcatel Belgium=20 . Alcatel Canada=20 . Avici=20 . Cisco Systems=20 . Data Connection=20 . Ixia Netplane=20 . Nortel Networks=20 . Redback=20 . Riverstone=20 . Spirent Communications This event is organized by the MPLS Forum and EANTC, in cooperation with = the ETSI Interoperability Service.=20 Hot topics to be tested during the interoperability event:=20 . Virtual Private Networks (VPNs)=20 . Fast Rerouting=20 Get more details at: = http://www.upperside.fr/mplswc2003/mplswc03intro.htm=20 ------=_NextPart_000_01F9_01C2B8B0.47E46320 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Interop Event at MPLS World = Congress: A Great=20 Success

12 companies have already decided to participate to = the=20 interoperability showcase performed during the MPLS World=20 Congress next February 4 to 7 in Paris (list below). The = organizers=20 expect to attract 20 companies.

• = Agilent=20
• Alcatel Belgium
•=20 Alcatel Canada
• Avici =
• Cisco Systems
• Data=20 Connection
• Ixia Netplane =
• Nortel Networks
• Redback=20
• Riverstone
•=20 Spirent Communications

This event is organized by the = MPLS=20 Forum and EANTC, in cooperation with the ETSI = Interoperability=20 Service.

Hot topics to be tested during the = interoperability=20 event:

• Virtual Private Networks (VPNs)
• = Fast Rerouting=20

Get more details at: http://www.= upperside.fr/mplswc2003/mplswc03intro.htm=20
 
------=_NextPart_000_01F9_01C2B8B0.47E46320-- From owner-mpls@UU.NET Fri Jan 10 09:49:07 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29463 for ; Fri, 10 Jan 2003 09:49:07 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnxax00673 for ; Fri, 10 Jan 2003 14:52:23 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnxax00269; Fri, 10 Jan 2003 14:52:11 GMT Received: by mail-control.ash.ops.us.uu.net id QQnxax24932 for mpls-outgoing; Fri, 10 Jan 2003 14:51:46 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnxax24927 for ; Fri, 10 Jan 2003 14:51:44 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnxax12754 for ; Fri, 10 Jan 2003 14:49:09 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnxax27943 for ; Fri, 10 Jan 2003 14:49:08 GMT Received: from rtp-msg-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-msg-core-1.cisco.com [161.44.11.97]) id QQnxax27885 for ; Fri, 10 Jan 2003 14:49:03 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id h0AEniG9009061 for ; Fri, 10 Jan 2003 09:49:45 -0500 (EST) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id JAA20307 for ; Fri, 10 Jan 2003 09:49:02 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h0AEn2s06954 for mpls@uu.net; Fri, 10 Jan 2003 09:49:02 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnxax24743 for ; Fri, 10 Jan 2003 14:47:50 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnxax26631 for ; Fri, 10 Jan 2003 14:47:30 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnxax26707 for ; Fri, 10 Jan 2003 14:47:30 GMT Received: from rtp-msg-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-msg-core-1.cisco.com [161.44.11.97]) id QQnxax26703 for ; Fri, 10 Jan 2003 14:47:29 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id h0AEm940008870 for ; Fri, 10 Jan 2003 09:48:10 -0500 (EST) Received: from bifocal.cisco.com (bifocal.cisco.com [161.44.172.150]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id JAA20175 for ; Fri, 10 Jan 2003 09:47:27 -0500 (EST) Received: from localhost (swallow@localhost) by bifocal.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id JAA06404 for ; Fri, 10 Jan 2003 09:47:26 -0500 (EST) Message-Id: <200301101447.JAA06404@bifocal.cisco.com> X-Authentication-Warning: bifocal.cisco.com: swallow owned process doing -bs To: mpls@UU.NET Subject: Re: draft-rosen-mpls-in-ip-or-gre-00.txt Date: Fri, 10 Jan 2003 09:47:26 -0500 From: George Swallow Sender: owner-mpls@UU.NET Precedence: bulk The support for making this a WG doc is very solid. Eric - Please resubmit the draft with the appropriate title. I leave it to you to decide whether you want one or two mpls's in the title ;-). ...george ================================================================== George Swallow Cisco Systems (978) 497-8143 250 Apollo Drive Chelmsford, Ma 01824 From owner-mpls@UU.NET Fri Jan 10 10:25:02 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00543 for ; Fri, 10 Jan 2003 10:25:02 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnxaz08505 for ; Fri, 10 Jan 2003 15:28:20 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnxaz08247; Fri, 10 Jan 2003 15:28:14 GMT Received: by mail-control.ash.ops.us.uu.net id QQnxaz16688 for mpls-outgoing; Fri, 10 Jan 2003 15:27:58 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnxaz16678 for ; Fri, 10 Jan 2003 15:27:51 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnxaz07324 for ; Fri, 10 Jan 2003 15:23:18 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnxaz00277 for ; Fri, 10 Jan 2003 15:23:18 GMT Received: from dnsmx1rrc.telcordia.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: dnsmx1rrc.telcordia.com [128.96.20.41]) id QQnxaz00234 for ; Fri, 10 Jan 2003 15:23:17 GMT Received: from notes640.cc.telcordia.com (notes640.cc.telcordia.com [128.96.22.6]) by dnsmx1rrc.telcordia.com (8.9.3/8.9.3) with ESMTP id KAA19785; Fri, 10 Jan 2003 10:22:25 -0500 (EST) Subject: Re: RFC2961 clarification To: David Charlap Cc: mpls@UU.NET X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: "Hong Liao" Date: Fri, 10 Jan 2003 10:22:25 -0500 X-MIMETrack: Serialize by Router on notes640/Telcordia(Release 5.0.6a |January 17, 2001) at 01/10/2003 10:22:26 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Hi, I think you might misunderstand my question. I did not say the spec was wrong. I just want to make sure the destination and source address mentioned in the Srefresh msg is the src or destination address in the ip header of the Srefresh msg or in the object (Message_Id SRC_LIST, or MESSAGE_ID MCAST_LIST object.) of the Srefresh msg. I just need to clarify and confirm this. Can someone give me the idea? Since the spec was not very clear about this. Julia David Charlap cc: (bcc: Hong Liao/Telcordia) Subject: Re: RFC2961 clarification 01/09/03 05:08 PM Hong Liao wrote: > > In spec RFC2961, Section 5.2 > > 'Srefresh messages carrying Message_Identifier fields corresponding to Path > state are normally sent with a destination IP address equal to the address > carried in the corresponding SESSION objects.' > > Here the destination ip address and source ip address mentioned in the > following paragraph is the one in srefresh ip header or in the Srefresh > Message_Id SRC_LIST, or MESSAGE_ID MCAST_LIST object. > > I think it means the source and destination address in the ip header, can > anyone help me to confirm this? The RFC is correct. The SESSION address should be the destination, and router alert should be used in order to enable the next-hop to intercept this message. This is required for multicast sessions, since the actual next-hop addres is unknown. For the subset of RSVP that is used by MPLS at this time, you may also use the next-hop address in the IP header (without router alert.) Note the second half of the paragraph your cited: ... The destination IP address MAY be set to the RSVP next hop when the next hop is known to be RSVP capable and either (a) the session is unicast or (b) the outgoing interface is a point-to-point link. ... This should be applicable for most current MPLS implementations. It may actually be applicable to all implementations, since I've never heard of any means for running LSPs over broadcast links. -- David From owner-mpls@UU.NET Fri Jan 10 12:04:47 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03880 for ; Fri, 10 Jan 2003 12:04:47 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnxbg28103 for ; Fri, 10 Jan 2003 17:08:04 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnxbg27916; Fri, 10 Jan 2003 17:07:59 GMT Received: by mail-control.ash.ops.us.uu.net id QQnxbg29923 for mpls-outgoing; Fri, 10 Jan 2003 17:07:39 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnxbg29918 for ; Fri, 10 Jan 2003 17:07:33 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnxbg10710 for ; Fri, 10 Jan 2003 17:05:01 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnxbg25882 for ; Fri, 10 Jan 2003 17:05:01 GMT Received: from bgslc03.burtongroup.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: host3.tbg.com [63.99.125.3] (may be forged)) id QQnxbg25865 for ; Fri, 10 Jan 2003 17:05:00 GMT X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2B8CA.579512F0" Subject: MPLScon "Call for Presentations" Date: Fri, 10 Jan 2003 10:04:31 -0700 Message-ID: <53BBA8839E91D51194D200902728944E019039FB@bgslc03.burtongroup.com> Thread-Topic: MPLScon "Call for Presentations" Thread-Index: AcK4yoWJN7X2ZCsmQc+AJpOSUJyA2w== From: "Irwin Lazar" To: undisclosed-recipients:; Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C2B8CA.579512F0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable This is a reminder that presentation submissions for MPLScon in New York = City on May 19-22 are due by January 15th, 2003. A copy of the call for = presentations is available at the following URL: http://www.mplscon.com/speaker/submit_pres.html = =20 =20 We are extremely excited about this event as it will be the first = conference squarely focused on enterprise network managers, providing = them with the information they need to evaluate MPLS-based services, as = well as understand the roles that MPLS can play within their own = networks. =20 Thus far we've got commitments from most of the major service providers = and several enterprises to present, and we will also be holding a panel = discussion among those service providers who have chosen not to use MPLS = to provide an alternative perspective. The opening keynote will be = presented by Rose Klimovich, General Manager of IP Infrastructure for = AT&T. We also welcome the involvement of the Wall Street Technology = Association in the event. =20 Please let me know if you have any questions, I look forward to your = involvement in the conference. =20 Sincerely, Irwin Lazar Conference Director, MPLScon E-Mail: ilazar@mplscon.com=20 Phone: 703-742-9659 Cell: 703-402-4119 http://www.mplscon.com/ =20 =20 =20 ------_=_NextPart_001_01C2B8CA.579512F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
This = is a reminder=20 that presentation submissions for MPLScon in New York City on May 19-22 = are due=20 by January 15th, 2003.  A copy of the call for presentations is = available=20 at the following URL:
http://www.mplsc= on.com/speaker/submit_pres.html
 
We are = extremely=20 excited about this event as it will be the first conference squarely = focused on=20 enterprise network managers, providing them with the information they = need to=20 evaluate MPLS-based services, as well as understand the roles that MPLS = can play=20 within their own networks.
 
Thus = far we've got=20 commitments from most of the major service providers and several=20 enterprises to present, and we will also be holding a panel = discussion=20 among those service providers who have chosen not to use MPLS to provide = an=20 alternative perspective.  The opening keynote will be presented by = Rose=20 Klimovich, General Manager of IP Infrastructure for AT&T.  We = also=20 welcome the involvement of the Wall Street Technology Association in the = event.
 
Please = let me know=20 if you have any questions, I look forward to your involvement in the=20 conference.
 
Sincerely,
Irwin=20 Lazar
Conference Director, = MPLScon
E-Mail: ilazar@mplscon.com
Phone: = 703-742-9659
Cell:=20 703-402-4119
http://www.mplscon.com/
=
 
 
 
------_=_NextPart_001_01C2B8CA.579512F0-- From owner-mpls@UU.NET Mon Jan 13 08:32:56 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10648 for ; Mon, 13 Jan 2003 08:32:56 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnxlu15925 for ; Mon, 13 Jan 2003 13:36:07 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnxlu15807; Mon, 13 Jan 2003 13:36:04 GMT Received: by mail-control.ash.ops.us.uu.net id QQnxlu24086 for mpls-outgoing; Mon, 13 Jan 2003 13:35:44 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnxlu24081 for ; Mon, 13 Jan 2003 13:35:40 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnxlu23421 for ; Mon, 13 Jan 2003 13:33:27 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnxlu24235 for ; Mon, 13 Jan 2003 13:33:26 GMT Received: from relay2.clb.oleane.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: relay2.clb.oleane.net [213.56.31.22]) id QQnxlu24222 for ; Mon, 13 Jan 2003 13:33:25 GMT Received: from oleane (upper-side.rain.fr [194.250.212.114]) by relay2.clb.oleane.net with SMTP id h0DDXODY026932 for ; Mon, 13 Jan 2003 14:33:24 +0100 Message-ID: <032b01c2bb08$5ebef2e0$0601a8c0@oleane.com> From: "Peter Lewis" To: Subject: ETHERNET IN THE ACCESS Conference Date: Mon, 13 Jan 2003 14:33:33 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0328_01C2BB10.C0403760" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0328_01C2BB10.C0403760 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ETHERNET IN THE ACCESS Conference=20 Paris, 17-20 June 2003. Ethernet services are now a reality at the metropolitan as well as at = the access level. Carriers and ISPs will deploy such services beside = their Frame Relay, ATM and MPLS networks. Above all, delivering OAMP = capabilities is a key issue for them as they want to leverage their = existing methods and proceedures in the last mile and until now, haven't = been able to with Ethernet.=20 =20 The call for proposals dead line has been extended to February 15th. All details at: http://www.upperside.fr/ethernet2003/ethernet03intro.htm ------=_NextPart_000_0328_01C2BB10.C0403760 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
ETHERNET IN THE=20 ACCESS
Conference =
Paris, 17-20 = June=20 2003.

Ethernet services are now a reality at the metropolitan as = well as=20 at the access level. Carriers and ISPs will deploy such services beside = their=20 Frame Relay, ATM and MPLS networks. Above all, delivering OAMP = capabilities is a=20 key issue for them as they want to leverage their existing methods and=20 proceedures in the last mile and until now, haven't been able to with = Ethernet.=20
 
The call for proposals dead line has been extended to = February=20 15th.
All details at:
http://= www.upperside.fr/ethernet2003/ethernet03intro.htm
 
 
------=_NextPart_000_0328_01C2BB10.C0403760-- From owner-mpls@UU.NET Mon Jan 13 12:56:05 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17974 for ; Mon, 13 Jan 2003 12:56:05 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnxml24282 for ; Mon, 13 Jan 2003 17:59:25 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnxml24125; Mon, 13 Jan 2003 17:59:21 GMT Received: by mail-control.ash.ops.us.uu.net id QQnxml29992 for mpls-outgoing; Mon, 13 Jan 2003 17:59:06 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnxml29985 for ; Mon, 13 Jan 2003 17:59:02 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnxml05098 for ; Mon, 13 Jan 2003 17:57:36 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnxml20941 for ; Mon, 13 Jan 2003 17:57:35 GMT Received: from kanmx1.ca.alcatel.com by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: m115-138.on.tac.net [209.202.115.138] (may be forged)) id QQnxml20937 for ; Mon, 13 Jan 2003 17:57:35 GMT Received: (qmail 16861 invoked from network); 13 Jan 2003 18:03:56 -0000 Received: (ofmipd 138.120.105.217); 13 Jan 2003 18:03:34 -0000 Received: from alcatel.com ([138.120.62.54]) by camail03.ca.alcatel.com (Netscape Messaging Server 4.15) with ESMTP id H8NZ7I00.MW3; Mon, 13 Jan 2003 12:57:18 -0500 Date: 13 Jan 2003 12:57:17 -0500 Message-ID: <3E22FDFD.D5579C5B@alcatel.com> From: "Cheng-Yin Lee" Reply-To: Cheng-Yin.Lee@alcatel.com To: curtis@fictitious.org Cc: "'mpls@UU.NET'" X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 Subject: Re: Some suggestions for LSP Ping References: <200301070241.VAA62993@workhorse.fictitious.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Curtis, Curtis Villamizar wrote: > This is true for VPN tunnels. There is always the change that a > non-MPLS ping capable router will deliver the packet to the next > router. That is different from delivering to the endpoint. > > If the destination is a real address it goes all the way to the final > destination. If the destination is 127/8 it goes no further than one > router into the customer LAN (which may be one too many). I see your point, but filtering LSP Ping messages at egress would also eliminate this problem, right? I would like to understand the tradeoffs of this vs some of the mechanisms (not all are clear to me yet) that are required if 127/8 is used as destination. > > Regarding ECMP, for e.g. to test connectivity between Src A and Dst B, > > the appropriate path would be verified if the IP src and dst of the test > > packet are set to Src A and Dst B, respectively (hashing on SA & DA). > > [Add Router Alert Option to "catch" the test packet at egress]. If "the > > destination IP address is a (randomly chosen) address from 127/8" > > instead, how is the appropriate path for Src A & Dst B verified? > > You test all paths. We went through that in great detail last month. > Check the mailing list archives for "suggested added text for > multipath", "suggested clarification to intro parts", "suggested > clarification to section 4". To verify the connectivity between Src A & Dst B, one would not need to test all paths if the payload & Router Alert Option/new option is included in the payload message, and the path data traffic would take, would be verified. I have some questions regarding "suggested clarification to section 4" + 4.8 Intended Use of Traceroute and Ping Mode As I understand, to verify connectivity between Src A & Dst B: a) do a traceroute to find out if multiple paths are available b) intermediate LSRs return the multipath destination addresses c) ping using the destination address returned by intermediate LSRs d) if multipath handling changes, additionally ping using random addresses (does the latter mean the pings in (c) do not deterministically rule out there is no connectivity?) e) if the pings in (d) fail, do traceroute (what destination addresses should be used?) After doing (a)-(e), can one be sure there is no connectivity, or if the test packet actually traverse the path data traffic take? This seems to involve quite a bit of work on the network to test connectivity. Perhaps you have other thoughts on this? Thanks, Cheng-Yin From owner-mpls@UU.NET Mon Jan 13 14:16:56 2003 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20573 for ; Mon, 13 Jan 2003 14:16:55 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnxmr16054 for ; Mon, 13 Jan 2003 19:20:13 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnxmr15814; Mon, 13 Jan 2003 19:20:07 GMT Received: by mail-control.ash.ops.us.uu.net id QQnxmr13727 for mpls-outgoing; Mon, 13 Jan 2003 19:19:45 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnxmr13722 for ; Mon, 13 Jan 2003 19:19:39 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnxmr16544 for ; Mon, 13 Jan 2003 19:18:05 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnxmr29710 for ; Mon, 13 Jan 2003 19:18:05 GMT Received: from rtp-msg-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-msg-core-1.cisco.com [161.44.11.97]) id QQnxmr29696 for ; Mon, 13 Jan 2003 19:18:04 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id h0DJIkvI008330 for ; Mon, 13 Jan 2003 14:18:47 -0500 (EST) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA11202 for ; Mon, 13 Jan 2003 14:18:02 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h0DJI2k06462 for mpls@uu.net; Mon, 13 Jan 2003 14:18:02 -0500 (EST) Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnxmr13650 for ; Mon, 13 Jan 2003 19:16:54 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnxmq05902 for ; Mon, 13 Jan 2003 19:13:57 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnxmq03733 for ; Mon, 13 Jan 2003 19:13:57 GMT Received: from workhorse.fictitious.org by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: workhorse.fictitious.org [209.150.1.230]) id QQnxmq03707 for ; Mon, 13 Jan 2003 19:13:55 GMT Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id OAA90003; Mon, 13 Jan 2003 14:13:16 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200301131913.OAA90003@workhorse.fictitious.org> To: Cheng-Yin.Lee@alcatel.com cc: curtis@fictitious.org, "'mpls@UU.NET'" Reply-To: curtis@fictitious.org Subject: Re: Some suggestions for LSP Ping In-reply-to: Your message of "13 Jan 2003 12:57:17 EST." <3E22FDFD.D5579C5B@alcatel.com> Date: Mon, 13 Jan 2003 14:13:15 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <3E22FDFD.D5579C5B@alcatel.com>, "Cheng-Yin Lee" writes: > Curtis, > > Curtis Villamizar wrote: > > This is true for VPN tunnels. There is always the change that a > > non-MPLS ping capable router will deliver the packet to the next > > router. That is different from delivering to the endpoint. > > > > If the destination is a real address it goes all the way to the final > > destination. If the destination is 127/8 it goes no further than one > > router into the customer LAN (which may be one too many). > I see your point, but filtering LSP Ping messages at egress would also > eliminate this problem, right? I would like to understand the tradeoffs > of this vs some of the mechanisms (not all are clear to me yet) that are > required if 127/8 is used as destination. Filters are generally not applied after the VPN label is encountered. This is the only case where we have a problem with delivery of MPLS ping into the VPN. > > > Regarding ECMP, for e.g. to test connectivity between Src A and Dst B, > > > the appropriate path would be verified if the IP src and dst of the test > > > packet are set to Src A and Dst B, respectively (hashing on SA & DA). > > > [Add Router Alert Option to "catch" the test packet at egress]. If "the > > > destination IP address is a (randomly chosen) address from 127/8" > > > instead, how is the appropriate path for Src A & Dst B verified? > > > > You test all paths. We went through that in great detail last month. > > Check the mailing list archives for "suggested added text for > > multipath", "suggested clarification to intro parts", "suggested > > clarification to section 4". > To verify the connectivity between Src A & Dst B, one would not need to > test all paths if the payload & Router Alert Option/new option is > included in the payload message, and the path data traffic would take, > would be verified. > > I have some questions regarding "suggested clarification to section 4" > + 4.8 Intended Use of Traceroute and Ping Mode > As I understand, to verify connectivity between Src A & Dst B: > a) do a traceroute to find out if multiple paths are available > b) intermediate LSRs return the multipath destination addresses > c) ping using the destination address returned by intermediate LSRs > d) if multipath handling changes, additionally ping using random addresses (does the latter mean the pings in (c) do not > deterministically rule out there is no connectivity?) > e) if the pings in (d) fail, do traceroute (what destination addresses > should be used?) I would do: traceroute to figure out paths. ping all paths. traceroute to verfy paths have not changed. If all three pass, then you have verified connectivity. Then if VPN or PW need to be verified: ping with each VPN or PW label to verify the FEC mapping. Periodically repeat the traceroute to insure the paths haven't changed. The shelf life provides a good hint regarding how often this needs to be done. > After doing (a)-(e), can one be sure there is no connectivity, or if the > test packet actually traverse the path data traffic take? This seems to > involve quite a bit of work on the network to test connectivity. Perhaps > you have other thoughts on this? Multipath is quite common today. Today ping and traceroute are used primarily for a few purposes. 1. The NOC has received a report that "you can't get there from here" and the NOC needs to follow up. 2. SLAs have to be verified. 3. As a form of proactive monitoring (in addition to checking all sorts of counters for sanity). What we seem most concerned about right now is proactive monitoring. If checking core connectivity, there are at most a few hundred (usually less than 100) LSPs to check. Pings with periodic traceroute to pick up multipath changes seem the best way to monitor the core and does not differ much from current "ping matrix" data gathered by ISPs. For proactive monitoring and SLA verification of VPN or PW the same ping with periodic traceroute will be needed but the number of paths to monitor may be a lot higher. It may help to verify all possible paths from PE to PE and then just ping to verfiy the individual FEC mappings at the egress, thereby doing no traceroutes on a per VPN or PW label basis. > Thanks, > Cheng-Yin Curtis From owner-mpls@UU.NET Mon Jan 13 19:06:04 2003 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28998 for ; Mon, 13 Jan 2003 19:06:03 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnxnk08924 for ; Tue, 14 Jan 2003 00:09:23 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnxnk08673; Tue, 14 Jan 2003 00:09:16 GMT Received: by mail-control.ash.ops.us.uu.net id QQnxnk07304 for mpls-outgoing; Tue, 14 Jan 2003 00:08:49 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnxnk07274 for ; Tue, 14 Jan 2003 00:08:42 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnxnk20836 for ; Tue, 14 Jan 2003 00:07:57 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnxnk07254 for ; Tue, 14 Jan 2003 00:07:56 GMT Received: from kanmx1.ca.alcatel.com by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: m115-138.on.tac.net [209.202.115.138] (may be forged)) id QQnxnk07246 for ; Tue, 14 Jan 2003 00:07:55 GMT Received: (qmail 29151 invoked from network); 14 Jan 2003 00:14:33 -0000 Received: (ofmipd 138.120.105.217); 14 Jan 2003 00:14:11 -0000 Received: from alcatel.com ([138.120.62.54]) by camail03.ca.alcatel.com (Netscape Messaging Server 4.15) with ESMTP id H8OGD600.RZW; Mon, 13 Jan 2003 19:07:54 -0500 Date: 13 Jan 2003 19:07:52 -0500 Message-ID: <3E2354D8.52EBA00F@alcatel.com> From: "Cheng-Yin Lee" Reply-To: Cheng-Yin.Lee@alcatel.com To: curtis@fictitious.org Cc: "'mpls@UU.NET'" X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 Subject: Re: Some suggestions for LSP Ping References: <200301131913.OAA90003@workhorse.fictitious.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Curtis, Curtis Villamizar wrote: > > > > I have some questions regarding "suggested clarification to section 4" > > + 4.8 Intended Use of Traceroute and Ping Mode > > As I understand, to verify connectivity between Src A & Dst B: > > a) do a traceroute to find out if multiple paths are available > > b) intermediate LSRs return the multipath destination addresses > > c) ping using the destination address returned by intermediate LSRs > > d) if multipath handling changes, additionally ping using random > addresses (does the latter mean the pings in (c) do not > > deterministically rule out there is no connectivity?) > > e) if the pings in (d) fail, do traceroute (what destination addresses > > should be used?) > > I would do: > > traceroute to figure out paths. > > ping all paths. > > traceroute to verfy paths have not changed. > > If all three pass, then you have verified connectivity. Then if VPN > or PW need to be verified: > > ping with each VPN or PW label to verify the FEC mapping. > > Periodically repeat the traceroute to insure the paths haven't > changed. The shelf life provides a good hint regarding how often this > needs to be done. ** As I understand, to verify the connectivity, one would not need to test all paths if the "payload" header (which includes fields required for hashing) & Router Alert Option/new option is included in the LSP Ping message. The above can be replaced by a single LSP Ping then. Even if multipath handling changes, the next LSP Ping will be forwarded in the path data traffic would take. This approach seems to require less work in implementation and network then doing the 3 steps above, but I am very opened to be convinced otherwise. > > After doing (a)-(e), can one be sure there is no connectivity, or if the > > test packet actually traverse the path data traffic take? This seems to > > involve quite a bit of work on the network to test connectivity. Perhaps > > you have other thoughts on this? > > Multipath is quite common today. > > Today ping and traceroute are used primarily for a few purposes. > > 1. The NOC has received a report that "you can't get there from > here" and the NOC needs to follow up. > > 2. SLAs have to be verified. > > 3. As a form of proactive monitoring (in addition to checking all > sorts of counters for sanity). > > What we seem most concerned about right now is proactive monitoring. > If checking core connectivity, there are at most a few hundred > (usually less than 100) LSPs to check. Pings with periodic traceroute > to pick up multipath changes seem the best way to monitor the core and > does not differ much from current "ping matrix" data gathered by ISPs. > > For proactive monitoring and SLA verification of VPN or PW the same > ping with periodic traceroute will be needed but the number of paths > to monitor may be a lot higher. It may help to verify all possible > paths from PE to PE and then just ping to verfiy the individual FEC > mappings at the egress, thereby doing no traceroutes on a per VPN or > PW label basis. If one do ** above then, then I think only a ping to verify individual FEC is required. Also is it feasible to verify all possible paths from PE to PE? I still don't quite understand (d) & (e), is the result of the ping deterministic, is it actually verifying the path data traffic take? thanks Cheng-Yin From owner-mpls@UU.NET Tue Jan 14 10:02:16 2003 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25995 for ; Tue, 14 Jan 2003 10:02:15 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnxps08334 for ; Tue, 14 Jan 2003 15:05:31 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnxps07861; Tue, 14 Jan 2003 15:05:16 GMT Received: by mail-control.ash.ops.us.uu.net id QQnxps06117 for mpls-outgoing; Tue, 14 Jan 2003 15:04:54 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnxps06073 for ; Tue, 14 Jan 2003 15:04:49 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnxps04161 for ; Tue, 14 Jan 2003 15:02:21 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnxps27223 for ; Tue, 14 Jan 2003 15:02:21 GMT Received: from rtp-msg-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-msg-core-1.cisco.com [161.44.11.97]) id QQnxps27208 for ; Tue, 14 Jan 2003 15:02:20 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id h0EF3203025620 for ; Tue, 14 Jan 2003 10:03:03 -0500 (EST) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA11686 for ; Tue, 14 Jan 2003 10:02:18 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h0EF2Iu00980 for mpls@uu.net; Tue, 14 Jan 2003 10:02:18 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnxob09683 for ; Tue, 14 Jan 2003 04:19:24 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnxob16585 for ; Tue, 14 Jan 2003 04:17:47 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnxob21831 for ; Tue, 14 Jan 2003 04:17:46 GMT Received: from workhorse.fictitious.org by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: workhorse.fictitious.org [209.150.1.230]) id QQnxob21799 for ; Tue, 14 Jan 2003 04:17:45 GMT Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id XAA92535; Mon, 13 Jan 2003 23:17:13 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200301140417.XAA92535@workhorse.fictitious.org> To: Cheng-Yin.Lee@alcatel.com cc: curtis@fictitious.org, "'mpls@UU.NET'" Reply-To: curtis@fictitious.org Subject: Re: Some suggestions for LSP Ping In-reply-to: Your message of "13 Jan 2003 19:07:52 EST." <3E2354D8.52EBA00F@alcatel.com> Date: Mon, 13 Jan 2003 23:17:12 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <3E2354D8.52EBA00F@alcatel.com>, "Cheng-Yin Lee" writes: > Curtis, > Curtis Villamizar wrote: > > > > > > I have some questions regarding "suggested clarification to section 4" > > > + 4.8 Intended Use of Traceroute and Ping Mode > > > As I understand, to verify connectivity between Src A & Dst B: > > > a) do a traceroute to find out if multiple paths are available > > > b) intermediate LSRs return the multipath destination addresses > > > c) ping using the destination address returned by intermediate LSRs > > > d) if multipath handling changes, additionally ping using random > > addresses (does the latter mean the pings in (c) do not > > > deterministically rule out there is no connectivity?) > > > e) if the pings in (d) fail, do traceroute (what destination addresses > > > should be used?) > > > > I would do: > > > > traceroute to figure out paths. > > > > ping all paths. > > > > traceroute to verfy paths have not changed. > > > > If all three pass, then you have verified connectivity. Then if VPN > > or PW need to be verified: > > > > ping with each VPN or PW label to verify the FEC mapping. > > > > Periodically repeat the traceroute to insure the paths haven't > > changed. The shelf life provides a good hint regarding how often this > > needs to be done. > ** As I understand, to verify the connectivity, one would not need to > test all paths if the "payload" header (which includes fields required > for hashing) & Router Alert Option/new option is included in the LSP > Ping message. The above can be replaced by a single LSP Ping then. > Even if multipath handling changes, the next LSP Ping will be forwarded > in the path data traffic would take. This approach seems to require less > work in implementation and network then doing the 3 steps above, but I > am very opened to be convinced otherwise. One ping packet per path. You need to test the forwarding plane with ping, not the control plane. Thats the whole point. You can use MIBs to check the control plane and still have no traffic flowing. > > > After doing (a)-(e), can one be sure there is no connectivity, or if the > > > test packet actually traverse the path data traffic take? This seems to > > > involve quite a bit of work on the network to test connectivity. Perhaps > > > you have other thoughts on this? > > > > Multipath is quite common today. > > > > Today ping and traceroute are used primarily for a few purposes. > > > > 1. The NOC has received a report that "you can't get there from > > here" and the NOC needs to follow up. > > > > 2. SLAs have to be verified. > > > > 3. As a form of proactive monitoring (in addition to checking all > > sorts of counters for sanity). > > > > What we seem most concerned about right now is proactive monitoring. > > If checking core connectivity, there are at most a few hundred > > (usually less than 100) LSPs to check. Pings with periodic traceroute > > to pick up multipath changes seem the best way to monitor the core and > > does not differ much from current "ping matrix" data gathered by ISPs. > > > > For proactive monitoring and SLA verification of VPN or PW the same > > ping with periodic traceroute will be needed but the number of paths > > to monitor may be a lot higher. It may help to verify all possible > > paths from PE to PE and then just ping to verfiy the individual FEC > > mappings at the egress, thereby doing no traceroutes on a per VPN or > > PW label basis. > If one do ** above then, then I think only a ping to verify individual > FEC is required. > > Also is it feasible to verify all possible paths from PE to PE? > I still don't quite understand (d) & (e), is the result of the ping > deterministic, is it actually verifying the path data traffic take? The traceroute takes the same path as the data. At each N+1 hop, the prior N hops use the forwarding to get there and TTL is the only thing that stops the normal forwarding from occuring. Ping just rechecks the forwarding without verifying that the path has not changed or the mapping of traffic onto a multipath has not changed. A periodic traceroute is used to make sure that the path has not changes such that the current set of pings is not providing complete test coverage of the forwarding path. > thanks > Cheng-Yin Curtis From owner-mpls@UU.NET Tue Jan 14 11:06:56 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29930 for ; Tue, 14 Jan 2003 11:06:55 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnxpw19218 for ; Tue, 14 Jan 2003 16:10:13 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnxpw19098; Tue, 14 Jan 2003 16:10:09 GMT Received: by mail-control.ash.ops.us.uu.net id QQnxpw00135 for mpls-outgoing; Tue, 14 Jan 2003 16:09:47 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnxpw00092 for ; Tue, 14 Jan 2003 16:09:40 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnxpw02938 for ; Tue, 14 Jan 2003 16:03:41 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnxpw00171 for ; Tue, 14 Jan 2003 16:03:41 GMT Received: from kanmx1.ca.alcatel.com by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: m115-138.on.tac.net [209.202.115.138] (may be forged)) id QQnxpw00153 for ; Tue, 14 Jan 2003 16:03:40 GMT Received: (qmail 17157 invoked from network); 14 Jan 2003 16:10:19 -0000 Received: (ofmipd 138.120.105.217); 14 Jan 2003 16:09:57 -0000 Received: from alcatel.com ([138.120.62.54]) by camail03.ca.alcatel.com (Netscape Messaging Server 4.15) with ESMTP id H8POM300.S2I; Tue, 14 Jan 2003 11:03:39 -0500 Date: 14 Jan 2003 11:03:35 -0500 Message-ID: <3E2434D7.3A67F188@alcatel.com> From: "Cheng-Yin Lee" Reply-To: Cheng-Yin.Lee@alcatel.com To: curtis@fictitious.org Cc: "'mpls@UU.NET'" X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 Subject: Re: Some suggestions for LSP Ping References: <200301140417.XAA92535@workhorse.fictitious.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Curtis, Curtis Villamizar wrote: > > In message <3E2354D8.52EBA00F@alcatel.com>, "Cheng-Yin Lee" writes: > > Curtis, > > Curtis Villamizar wrote: > > > > > > > > I have some questions regarding "suggested clarification to section 4" > > > > + 4.8 Intended Use of Traceroute and Ping Mode > > > > As I understand, to verify connectivity between Src A & Dst B: > > > > a) do a traceroute to find out if multiple paths are available > > > > b) intermediate LSRs return the multipath destination addresses > > > > c) ping using the destination address returned by intermediate LSRs > > > > d) if multipath handling changes, additionally ping using random > > > addresses (does the latter mean the pings in (c) do not > > > > deterministically rule out there is no connectivity?) > > > > e) if the pings in (d) fail, do traceroute (what destination addresses > > > > should be used?) > > > > > > I would do: > > > > > > traceroute to figure out paths. > > > > > > ping all paths. > > > > > > traceroute to verfy paths have not changed. > > > > > > If all three pass, then you have verified connectivity. Then if VPN > > > or PW need to be verified: > > > > > > ping with each VPN or PW label to verify the FEC mapping. > > > > > > Periodically repeat the traceroute to insure the paths haven't > > > changed. The shelf life provides a good hint regarding how often this > > > needs to be done. > > ** As I understand, to verify the connectivity, one would not need to > > test all paths if the "payload" header (which includes fields required > > for hashing) & Router Alert Option/new option is included in the LSP > > Ping message. The above can be replaced by a single LSP Ping then. > > Even if multipath handling changes, the next LSP Ping will be forwarded > > in the path data traffic would take. This approach seems to require less > > work in implementation and network then doing the 3 steps above, but I > > am very opened to be convinced otherwise. > > One ping packet per path. > > You need to test the forwarding plane with ping, not the control > plane. Thats the whole point. You can use MIBs to check the control > plane and still have no traffic flowing. Agree. I would like to know if you agree that the ** (payload header & Router Alert Option) approach could be used instead of the 3 steps above (noting there is a chance that LSP Ping may leak to customer). > > > > > After doing (a)-(e), can one be sure there is no connectivity, or if the > > > > test packet actually traverse the path data traffic take? This seems to > > > > involve quite a bit of work on the network to test connectivity. Perhaps > > > > you have other thoughts on this? > > > > > > Multipath is quite common today. > > > > > > Today ping and traceroute are used primarily for a few purposes. > > > > > > 1. The NOC has received a report that "you can't get there from > > > here" and the NOC needs to follow up. > > > > > > 2. SLAs have to be verified. > > > > > > 3. As a form of proactive monitoring (in addition to checking all > > > sorts of counters for sanity). > > > > > > What we seem most concerned about right now is proactive monitoring. > > > If checking core connectivity, there are at most a few hundred > > > (usually less than 100) LSPs to check. Pings with periodic traceroute > > > to pick up multipath changes seem the best way to monitor the core and > > > does not differ much from current "ping matrix" data gathered by ISPs. > > > > > > For proactive monitoring and SLA verification of VPN or PW the same > > > ping with periodic traceroute will be needed but the number of paths > > > to monitor may be a lot higher. It may help to verify all possible > > > paths from PE to PE and then just ping to verfiy the individual FEC > > > mappings at the egress, thereby doing no traceroutes on a per VPN or > > > PW label basis. > > If one do ** above then, then I think only a ping to verify individual > > FEC is required. > > > > Also is it feasible to verify all possible paths from PE to PE? > > I still don't quite understand (d) & (e), is the result of the ping > > deterministic, is it actually verifying the path data traffic take? > > The traceroute takes the same path as the data. At each N+1 hop, the > prior N hops use the forwarding to get there and TTL is the only thing > that stops the normal forwarding from occuring. > > Ping just rechecks the forwarding without verifying that the path has > not changed or the mapping of traffic onto a multipath has not > changed. A periodic traceroute is used to make sure that the path has > not changes such that the current set of pings is not providing > complete test coverage of the forwarding path. Understood and I appreciate your clarification. Actually the questions I have are: 1) if "random addresses" are used as in (d), it sounds like a ping may not exercise the intended path. Is that right? 2) If the pings in (d) fail, what destination addresses should be used in traceroute in (e) ? Thanks, Cheng-Yin From owner-mpls@UU.NET Tue Jan 14 12:23:00 2003 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03957 for ; Tue, 14 Jan 2003 12:22:59 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnxqb04021 for ; Tue, 14 Jan 2003 17:26:14 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnxqb03683; Tue, 14 Jan 2003 17:26:03 GMT Received: by mail-control.ash.ops.us.uu.net id QQnxqb25432 for mpls-outgoing; Tue, 14 Jan 2003 17:25:45 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnxqb25419 for ; Tue, 14 Jan 2003 17:25:38 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnxqb25129 for ; Tue, 14 Jan 2003 17:24:06 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnxqb07211 for ; Tue, 14 Jan 2003 17:24:06 GMT Received: from rtp-msg-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-msg-core-1.cisco.com [161.44.11.97]) id QQnxqb07201 for ; Tue, 14 Jan 2003 17:24:05 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id h0EHOlbk022102 for ; Tue, 14 Jan 2003 12:24:48 -0500 (EST) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id MAA23913 for ; Tue, 14 Jan 2003 12:24:03 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h0EHO3i12463 for mpls@uu.net; Tue, 14 Jan 2003 12:24:03 -0500 (EST) Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnxqb25331 for ; Tue, 14 Jan 2003 17:23:33 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnxqb08678 for ; Tue, 14 Jan 2003 17:22:59 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnxqb13053 for ; Tue, 14 Jan 2003 17:22:59 GMT Received: from workhorse.fictitious.org by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: workhorse.fictitious.org [209.150.1.230]) id QQnxqb13039 for ; Tue, 14 Jan 2003 17:22:58 GMT Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id MAA95325; Tue, 14 Jan 2003 12:22:19 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200301141722.MAA95325@workhorse.fictitious.org> To: Cheng-Yin.Lee@alcatel.com cc: curtis@fictitious.org, "'mpls@UU.NET'" Reply-To: curtis@fictitious.org Subject: Re: Some suggestions for LSP Ping In-reply-to: Your message of "14 Jan 2003 11:03:35 EST." <3E2434D7.3A67F188@alcatel.com> Date: Tue, 14 Jan 2003 12:22:19 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <3E2434D7.3A67F188@alcatel.com>, "Cheng-Yin Lee" writes: > > > > One ping packet per path. > > > > You need to test the forwarding plane with ping, not the control > > plane. Thats the whole point. You can use MIBs to check the control > > plane and still have no traffic flowing. > Agree. > > I would like to know if you agree that the ** (payload header & Router > Alert Option) approach could be used instead of the 3 steps above > (noting there is a chance that LSP Ping may leak to customer). If IP router alert on a VPN IP payload stops the packet from being delivered where adding a explicit null label would not, then fine. I see no reason to think it would. > > Ping just rechecks the forwarding without verifying that the path has > > not changed or the mapping of traffic onto a multipath has not > > changed. A periodic traceroute is used to make sure that the path has > > not changes such that the current set of pings is not providing > > complete test coverage of the forwarding path. > Understood and I appreciate your clarification. > > Actually the questions I have are: > 1) if "random addresses" are used as in (d), it sounds like a ping may > not exercise the intended path. Is that right? I didn't say use random addresses. I said use addresses determined by the prior traceroute. > 2) If the pings in (d) fail, what destination addresses should be used > in traceroute in (e) ? If the (d) and (e) you are referring to is in the document and recommending random addresses as a means to exercise multipath, then it should be removed or it should be stated that this method does not deterministically exercise all paths. If you are just referring to *your* prior email, then yes using random addresses to exercise multipath is not certain to work, but it is not what I'm suggesting. > Thanks, > Cheng-Yin Curtis From owner-mpls@UU.NET Tue Jan 14 14:23:12 2003 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08247 for ; Tue, 14 Jan 2003 14:23:11 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnxqj08587 for ; Tue, 14 Jan 2003 19:26:31 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnxqj08447; Tue, 14 Jan 2003 19:26:26 GMT Received: by mail-control.ash.ops.us.uu.net id QQnxqj12208 for mpls-outgoing; Tue, 14 Jan 2003 19:26:06 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnxqj12015 for ; Tue, 14 Jan 2003 19:25:59 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnxqj23781 for ; Tue, 14 Jan 2003 19:17:57 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnxqj01915 for ; Tue, 14 Jan 2003 19:17:56 GMT Received: from merlot.juniper.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: natint.juniper.net [207.17.136.129]) id QQnxqj01903 for ; Tue, 14 Jan 2003 19:17:55 GMT Received: from kummer.juniper.net (kummer.juniper.net [172.17.12.90]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h0EJHtS35783; Tue, 14 Jan 2003 11:17:55 -0800 (PST) (envelope-from kireeti@juniper.net) Received: from localhost (kireeti@localhost) by kummer.juniper.net (8.11.6/8.9.3) with ESMTP id h0EJHtk45572; Tue, 14 Jan 2003 11:17:55 -0800 (PST) (envelope-from kireeti@juniper.net) X-Authentication-Warning: kummer.juniper.net: kireeti owned process doing -bs Date: Tue, 14 Jan 2003 11:17:55 -0800 (PST) From: Kireeti Kompella To: "Ramakrishnan.R (Networking) - CTD, Chennai." cc: "'mpls@UU.NET'" Subject: Re: Frame Relay Encapsulation In-Reply-To: <55E277B99171E041ABF5F4B1C6DDCA0601097B61@haritha.hclt.com> Message-ID: <20030114111718.J45513-100000@kummer.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk On Sat, 4 Jan 2003, Ramakrishnan.R (Networking) - CTD, Chennai. wrote: > I am working on MPLS over Frame Relay. I would like to know how the MPLS > packet is encapsulated in the Frame Relay packet. SNAP encoding with the Ethertype for MPLS. Kireeti. From owner-mpls@UU.NET Tue Jan 14 17:25:02 2003 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13941 for ; Tue, 14 Jan 2003 17:25:01 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnxqv26902 for ; Tue, 14 Jan 2003 22:28:20 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnxqv26703; Tue, 14 Jan 2003 22:28:14 GMT Received: by mail-control.ash.ops.us.uu.net id QQnxqv20524 for mpls-outgoing; Tue, 14 Jan 2003 22:27:52 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnxqv20504 for ; Tue, 14 Jan 2003 22:27:50 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnxqv04823 for ; Tue, 14 Jan 2003 22:22:36 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnxqv25504 for ; Tue, 14 Jan 2003 22:22:36 GMT Received: from kanmx1.ca.alcatel.com by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: m115-138.on.tac.net [209.202.115.138] (may be forged)) id QQnxqv25492 for ; Tue, 14 Jan 2003 22:22:35 GMT Received: (qmail 19871 invoked from network); 14 Jan 2003 22:29:13 -0000 Received: (ofmipd 138.120.105.217); 14 Jan 2003 22:28:51 -0000 Received: from alcatel.com ([138.120.62.54]) by camail03.ca.alcatel.com (Netscape Messaging Server 4.15) with ESMTP id H8Q65M00.NAI; Tue, 14 Jan 2003 17:22:34 -0500 Date: 14 Jan 2003 17:22:34 -0500 Message-ID: <3E248DAA.C8C055E9@alcatel.com> From: "Cheng-Yin Lee" Reply-To: Cheng-Yin.Lee@alcatel.com To: curtis@fictitious.org Cc: "'mpls@UU.NET'" X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 Subject: Re: Some suggestions for LSP Ping References: <200301141722.MAA95325@workhorse.fictitious.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Curtis, Curtis Villamizar wrote: > > I would like to know if you agree that the ** (payload header & Router > > Alert Option) approach could be used instead of the 3 steps above > > (noting there is a chance that LSP Ping may leak to customer). > > If IP router alert on a VPN IP payload stops the packet from being > delivered where adding a explicit null label would not, then fine. I > see no reason to think it would. Using the payload header and Router Alert option approach, you would only need to send one LSP ping (similar to IP Ping), instead of preceding the (LSP) ping with (LSP) traceroute and follow by (LSP) traceroute (in the 3 step approach described in your previous email). I think the former is simpler, the latter involves more work in implementation and in the network (additional traceroutes), but I'm still opened to be convinced otherwise. A minor point is _if_ hashing involves the IP header as well, then I think the explicit null label cannot be used. BTW, would you know how many 127/8 addresses should be configured in the egress LSR? > > Actually the questions I have are: > > 1) if "random addresses" are used as in (d), it sounds like a ping may > > not exercise the intended path. Is that right? > > I didn't say use random addresses. I said use addresses determined by > the prior traceroute. > > > 2) If the pings in (d) fail, what destination addresses should be used > > in traceroute in (e) ? > > If the (d) and (e) you are referring to is in the document and > recommending random addresses as a means to exercise multipath, then > it should be removed or it should be stated that this method does not > deterministically exercise all paths. If you are just referring to > *your* prior email, then yes using random addresses to exercise > multipath is not certain to work, but it is not what I'm suggesting. I am referring to Section 4.8 from "suggested clarification to section 4 of draft-ietf-mpls-lsp-ping-01": + In the event + that multipath handling changes, randomly selected addresses should + be used in addition to destination addresses determined using + traceroute, rather than solely using those determined by + traceroute. thanks, Cheng-Yin From owner-mpls@UU.NET Tue Jan 14 20:41:38 2003 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18642 for ; Tue, 14 Jan 2003 20:41:37 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnxri19853 for ; Wed, 15 Jan 2003 01:44:57 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnxri19632; Wed, 15 Jan 2003 01:44:50 GMT Received: by mail-control.ash.ops.us.uu.net id QQnxri00711 for mpls-outgoing; Wed, 15 Jan 2003 01:44:35 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnxri00701 for ; Wed, 15 Jan 2003 01:44:25 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnxri14486 for ; Wed, 15 Jan 2003 01:41:12 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnxri04407 for ; Wed, 15 Jan 2003 01:41:12 GMT Received: from rtp-msg-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-msg-core-1.cisco.com [161.44.11.97]) id QQnxri04391 for ; Wed, 15 Jan 2003 01:41:11 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id h0F1flPK023625 for ; Tue, 14 Jan 2003 20:41:50 -0500 (EST) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id UAA00136 for ; Tue, 14 Jan 2003 20:41:01 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h0F1f1q09056 for mpls@uu.net; Tue, 14 Jan 2003 20:41:01 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnxri00296 for ; Wed, 15 Jan 2003 01:40:03 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnxri26629 for ; Wed, 15 Jan 2003 01:31:59 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnxri17532 for ; Wed, 15 Jan 2003 01:31:59 GMT Received: from workhorse.fictitious.org by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: workhorse.fictitious.org [209.150.1.230]) id QQnxri17526 for ; Wed, 15 Jan 2003 01:31:58 GMT Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id UAA99885; Tue, 14 Jan 2003 20:31:14 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200301150131.UAA99885@workhorse.fictitious.org> To: Cheng-Yin.Lee@alcatel.com cc: curtis@fictitious.org, "'mpls@UU.NET'" Reply-To: curtis@fictitious.org Subject: Re: Some suggestions for LSP Ping In-reply-to: Your message of "14 Jan 2003 17:22:34 EST." <3E248DAA.C8C055E9@alcatel.com> Date: Tue, 14 Jan 2003 20:31:14 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <3E248DAA.C8C055E9@alcatel.com>, "Cheng-Yin Lee" writes: > Curtis, > > Curtis Villamizar wrote: > > > I would like to know if you agree that the ** (payload header & Router > > > Alert Option) approach could be used instead of the 3 steps above > > > (noting there is a chance that LSP Ping may leak to customer). > > > > If IP router alert on a VPN IP payload stops the packet from being > > delivered where adding a explicit null label would not, then fine. I > > see no reason to think it would. > Using the payload header and Router Alert option approach, you would > only need to send one LSP ping (similar to IP Ping), instead of > preceding the (LSP) ping with (LSP) traceroute and follow by (LSP) > traceroute (in the 3 step approach described in your previous email). I > think the former is simpler, the latter involves more work in > implementation and in the network (additional traceroutes), but I'm > still opened to be convinced otherwise. > A minor point is _if_ hashing involves the IP header as well, then I > think the explicit null label cannot be used. > > BTW, would you know how many 127/8 addresses should be configured in the > egress LSR? It is easy to configure an entire /8 subnet. That would be one entry. Some routers may require modification to the loopback device driver but that is easily accomplished. > > > Actually the questions I have are: > > > 1) if "random addresses" are used as in (d), it sounds like a ping may > > > not exercise the intended path. Is that right? > > > > I didn't say use random addresses. I said use addresses determined by > > the prior traceroute. > > > > > 2) If the pings in (d) fail, what destination addresses should be used > > > in traceroute in (e) ? > > > > If the (d) and (e) you are referring to is in the document and > > recommending random addresses as a means to exercise multipath, then > > it should be removed or it should be stated that this method does not > > deterministically exercise all paths. If you are just referring to > > *your* prior email, then yes using random addresses to exercise > > multipath is not certain to work, but it is not what I'm suggesting. > > I am referring to Section 4.8 from "suggested clarification to section 4 > of draft-ietf-mpls-lsp-ping-01": > + In the event > + that multipath handling changes, randomly selected addresses should > + be used in addition to destination addresses determined using > + traceroute, rather than solely using those determined by > + traceroute. All that one sentence adds is that providing some randomly selected addresses **in addition** to destination addresses determined using traceroute adds some random testing to the deterministic testing. There is no (d) and (e) in this entire section. > thanks, > Cheng-Yin Curtis From owner-mpls@UU.NET Wed Jan 15 08:04:31 2003 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24790 for ; Wed, 15 Jan 2003 08:04:31 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnxtc21902 for ; Wed, 15 Jan 2003 13:07:51 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnxtc21484; Wed, 15 Jan 2003 13:07:40 GMT Received: by mail-control.ash.ops.us.uu.net id QQnxtc25897 for mpls-outgoing; Wed, 15 Jan 2003 13:07:13 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnxtc25314 for ; Wed, 15 Jan 2003 13:07:08 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnxtc00229 for ; Wed, 15 Jan 2003 13:05:06 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnxtc28569 for ; Wed, 15 Jan 2003 13:05:04 GMT Received: from rtp-msg-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-msg-core-1.cisco.com [161.44.11.97]) id QQnxtc28542 for ; Wed, 15 Jan 2003 13:05:03 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id h0FD5kXT021167 for ; Wed, 15 Jan 2003 08:05:46 -0500 (EST) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id IAA00543 for ; Wed, 15 Jan 2003 08:05:01 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h0FD51k10608 for mpls@uu.net; Wed, 15 Jan 2003 08:05:01 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnxtc20004 for ; Wed, 15 Jan 2003 13:03:41 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnxtc13436 for ; Wed, 15 Jan 2003 13:01:55 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnxtc29484 for ; Wed, 15 Jan 2003 13:01:55 GMT Received: from ietf.org by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: odin.ietf.org [132.151.1.176]) id QQnxtc29477 for ; Wed, 15 Jan 2003 13:01:54 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24395; Wed, 15 Jan 2003 07:58:31 -0500 (EST) Message-Id: <200301151258.HAA24395@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; Cc: mpls@UU.NET From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-mpls-in-ip-or-gre-00.txt Date: Wed, 15 Jan 2003 07:58:31 -0500 Sender: owner-mpls@UU.NET Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : Encapsulating MPLS in IP or GRE Author(s) : T. Worster, Y. Rekhter, E. Rosen Filename : draft-ietf-mpls-in-ip-or-gre-00.txt Pages : 7 Date : 2003-1-14 In various applications of MPLS, label stacks with multiple entries are used. In some cases, it is possible to replace the top label of the stack with an IP-based encapsulation, thereby enabling the application to run over networks which do not have MPLS enabled in their core routers. This draft specifies two IP-based encapsulations, MPLS-in-IP, and MPLS-in-GRE. Each of these is applicable in some circumstances. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-in-ip-or-gre-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mpls-in-ip-or-gre-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mpls-in-ip-or-gre-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-1-14151034.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-in-ip-or-gre-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-in-ip-or-gre-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-1-14151034.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Wed Jan 15 11:07:58 2003 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01354 for ; Wed, 15 Jan 2003 11:07:58 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnxto09081 for ; Wed, 15 Jan 2003 16:11:16 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnxto08762; Wed, 15 Jan 2003 16:11:05 GMT Received: by mail-control.ash.ops.us.uu.net id QQnxto13019 for mpls-outgoing; Wed, 15 Jan 2003 16:10:38 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnxto12846 for ; Wed, 15 Jan 2003 16:10:20 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnxto01478 for ; Wed, 15 Jan 2003 16:08:48 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnxto06656 for ; Wed, 15 Jan 2003 16:08:47 GMT Received: from kanmx1.ca.alcatel.com by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: m115-138.on.tac.net [209.202.115.138] (may be forged)) id QQnxto06632 for ; Wed, 15 Jan 2003 16:08:46 GMT Received: (qmail 3246 invoked from network); 15 Jan 2003 16:15:24 -0000 Received: (ofmipd 138.120.105.217); 15 Jan 2003 16:15:02 -0000 Received: from alcatel.com ([138.120.62.54]) by camail03.ca.alcatel.com (Netscape Messaging Server 4.15) with ESMTP id H8RJIL00.PEO; Wed, 15 Jan 2003 11:08:45 -0500 Date: 15 Jan 2003 11:08:43 -0500 Message-ID: <3E25878B.B8F596B8@alcatel.com> From: "Cheng-Yin Lee" Reply-To: Cheng-Yin.Lee@alcatel.com To: curtis@fictitious.org Cc: "'mpls@UU.NET'" X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 Subject: Re: Some suggestions for LSP Ping References: <200301150131.UAA99885@workhorse.fictitious.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Curtis, Curtis Villamizar wrote: > > I am referring to Section 4.8 from "suggested clarification to section 4 > > of draft-ietf-mpls-lsp-ping-01": > > + In the event > > + that multipath handling changes, randomly selected addresses should > > + be used in addition to destination addresses determined using > > + traceroute, rather than solely using those determined by > > + traceroute. > > All that one sentence adds is that providing some randomly selected > addresses **in addition** to destination addresses determined using > traceroute adds some random testing to the deterministic testing. From your previous email: 1)traceroute to figure out paths. 2)ping all paths. 3)traceroute to verfy paths have not changed. 4)If all three pass, then you have verified connectivity. 5)Then if VPN or PW need to be verified ping with each VPN or PW label to verify the FEC mapping. 6)Periodically repeat the traceroute to insure the paths haven't changed. The shelf life provides a good hint regarding how often this needs to be done. May I know where would you add random testing to the above steps? Thanks, Cheng-Yin From owner-mpls@UU.NET Wed Jan 15 11:45:00 2003 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02933 for ; Wed, 15 Jan 2003 11:45:00 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnxtr19573 for ; Wed, 15 Jan 2003 16:48:18 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnxtr19268; Wed, 15 Jan 2003 16:48:09 GMT Received: by mail-control.ash.ops.us.uu.net id QQnxtr16949 for mpls-outgoing; Wed, 15 Jan 2003 16:47:36 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnxtr16945 for ; Wed, 15 Jan 2003 16:47:34 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnxtq07799 for ; Wed, 15 Jan 2003 16:41:06 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnxtq13940 for ; Wed, 15 Jan 2003 16:41:06 GMT Received: from rtp-msg-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-msg-core-1.cisco.com [161.44.11.97]) id QQnxtq13915 for ; Wed, 15 Jan 2003 16:41:05 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id h0FGflVZ007019 for ; Wed, 15 Jan 2003 11:41:48 -0500 (EST) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id LAA14668 for ; Wed, 15 Jan 2003 11:41:03 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h0FGf3i23272 for mpls@uu.net; Wed, 15 Jan 2003 11:41:03 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnxtq15837 for ; Wed, 15 Jan 2003 16:38:29 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnxtq04406 for ; Wed, 15 Jan 2003 16:37:13 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnxtq10524 for ; Wed, 15 Jan 2003 16:37:13 GMT Received: from workhorse.fictitious.org by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: workhorse.fictitious.org [209.150.1.230]) id QQnxtq10505 for ; Wed, 15 Jan 2003 16:37:12 GMT Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id LAA03916; Wed, 15 Jan 2003 11:36:20 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200301151636.LAA03916@workhorse.fictitious.org> To: Cheng-Yin.Lee@alcatel.com cc: curtis@fictitious.org, "'mpls@UU.NET'" Reply-To: curtis@fictitious.org Subject: Re: Some suggestions for LSP Ping In-reply-to: Your message of "15 Jan 2003 11:08:43 EST." <3E25878B.B8F596B8@alcatel.com> Date: Wed, 15 Jan 2003 11:36:20 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <3E25878B.B8F596B8@alcatel.com>, "Cheng-Yin Lee" writes: > Curtis, > > Curtis Villamizar wrote: > > > I am referring to Section 4.8 from "suggested clarification to section 4 > > > of draft-ietf-mpls-lsp-ping-01": > > > + In the event > > > + that multipath handling changes, randomly selected addresses should > > > + be used in addition to destination addresses determined using > > > + traceroute, rather than solely using those determined by > > > + traceroute. > > > > All that one sentence adds is that providing some randomly selected > > addresses **in addition** to destination addresses determined using > > traceroute adds some random testing to the deterministic testing. > > >From your previous email: > 1)traceroute to figure out paths. > > 2)ping all paths. > > 3)traceroute to verfy paths have not changed. > > 4)If all three pass, then you have verified connectivity. > > 5)Then if VPN or PW need to be verified ping with each VPN or PW label > to verify the FEC mapping. > > 6)Periodically repeat the traceroute to insure the paths haven't > changed. The shelf life provides a good hint regarding how often this > needs to be done. > > May I know where would you add random testing to the above steps? > > Thanks, > Cheng-Yin If you are doing continuous monitoring you would initialize monitoring as you have outlined above. After initialization, pings would be used to verify connectivity and give a first order check on SLA to suppliment MIB based or other statistics. This is where random addresses can be used in addition to the more deterministic addresses obtained from the traceroute. Traceroute would then have to be repeated if one of two events might have occurred, 1) an LSP reroute, 2) a change in the way load is distributed at a multipath branch point. Lets consider these two separately. Testing is initiated by the ingress. For a RSVP/TE LSP the ingress knows if the LSP has been rerouted, because the ingress must initiate that action. For LDP, a reroute would occur only after a topology change which could be noted. If the "shelf life" returned by the LSRs may indicate one of a number of conditions, 1) the multipath distribution never changes, 2) the shelf life duration is known but the start time is unavailable, 3) the remaining shelf life is known. The first case is easy. If there is a topology change, then the traceroute has to be repeated. The third case is also easy, the remaining shelf life allows a traceroute to be scheduled. The second case, where only shelf life duration is known, requires periodic traceroutes initially. Once a transition occurs, the approximate start time is available and a traceroute can be scheduled rather than performed periodically. Between scheduled traceroutes (if any are needed) ping can be performed using both the deterministic addresses and some random addresses. This sort of recommendation can be added to the document (although it would start to get sort of long). I would leave that decision along with the decision to accept any of the prior suggestions I made up to the authors. Curtis From owner-mpls@UU.NET Wed Jan 15 12:27:12 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04210 for ; Wed, 15 Jan 2003 12:27:11 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnxtu03345 for ; Wed, 15 Jan 2003 17:30:26 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnxtu03127; Wed, 15 Jan 2003 17:30:20 GMT Received: by mail-control.ash.ops.us.uu.net id QQnxtt09038 for mpls-outgoing; Wed, 15 Jan 2003 17:29:54 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnxtt09025 for ; Wed, 15 Jan 2003 17:29:46 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnxtt24331 for ; Wed, 15 Jan 2003 17:28:52 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnxtt03964 for ; Wed, 15 Jan 2003 17:28:52 GMT Received: from kanmx1.ca.alcatel.com by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: m115-138.on.tac.net [209.202.115.138] (may be forged)) id QQnxtt03942 for ; Wed, 15 Jan 2003 17:28:51 GMT Received: (qmail 5120 invoked from network); 15 Jan 2003 17:35:29 -0000 Received: (ofmipd 138.120.105.217); 15 Jan 2003 17:35:07 -0000 Received: from alcatel.com ([138.120.62.54]) by camail03.ca.alcatel.com (Netscape Messaging Server 4.15) with ESMTP id H8RN8200.0F5; Wed, 15 Jan 2003 12:28:50 -0500 Date: 15 Jan 2003 12:28:47 -0500 Message-ID: <3E259A4F.840941E8@alcatel.com> From: "Cheng-Yin Lee" Reply-To: Cheng-Yin.Lee@alcatel.com To: curtis@fictitious.org Cc: "'mpls@UU.NET'" X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 Subject: Re: Some suggestions for LSP Ping References: <200301151636.LAA03916@workhorse.fictitious.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Curtis, Curtis Villamizar wrote: > > If you are doing continuous monitoring you would initialize monitoring > as you have outlined above. > > After initialization, pings would be used to verify connectivity and > give a first order check on SLA to suppliment MIB based or other > statistics. This is where random addresses can be used in addition to > the more deterministic addresses obtained from the traceroute. > > Traceroute would then have to be repeated if one of two events might > have occurred, 1) an LSP reroute, 2) a change in the way load is > distributed at a multipath branch point. Lets consider these two > separately. > > Testing is initiated by the ingress. For a RSVP/TE LSP the ingress > knows if the LSP has been rerouted, because the ingress must initiate > that action. For LDP, a reroute would occur only after a topology > change which could be noted. > > If the "shelf life" returned by the LSRs may indicate one of a number > of conditions, 1) the multipath distribution never changes, 2) the > shelf life duration is known but the start time is unavailable, 3) the > remaining shelf life is known. The first case is easy. If there is a > topology change, then the traceroute has to be repeated. The third > case is also easy, the remaining shelf life allows a traceroute to be > scheduled. The second case, where only shelf life duration is known, > requires periodic traceroutes initially. Once a transition occurs, > the approximate start time is available and a traceroute can be > scheduled rather than performed periodically. > > Between scheduled traceroutes (if any are needed) ping can be > performed using both the deterministic addresses and some random > addresses. > > This sort of recommendation can be added to the document (although it > would start to get sort of long). I would leave that decision along > with the decision to accept any of the prior suggestions I made up to > the authors. If your suggestions are accepted, some recommendations as the above in for e.g. the appendix would be useful. My understanding from your clarification above is - this method does not necessarily verify the test packet actually traverse the path data traffic would take. Have you come to the same conclusion? [Note: If you use the payload header & Router Alert option method, that method exercises the test packet on the path data traffic would take] thanks, Cheng-Yin From owner-mpls@UU.NET Wed Jan 15 12:45:45 2003 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04813 for ; Wed, 15 Jan 2003 12:45:45 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnxtv19283 for ; Wed, 15 Jan 2003 17:49:02 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnxtv19057; Wed, 15 Jan 2003 17:48:55 GMT Received: by mail-control.ash.ops.us.uu.net id QQnxtv10100 for mpls-outgoing; Wed, 15 Jan 2003 17:48:35 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnxtv10095 for ; Wed, 15 Jan 2003 17:48:27 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnxtv15113 for ; Wed, 15 Jan 2003 17:45:07 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnxtv15890 for ; Wed, 15 Jan 2003 17:45:07 GMT Received: from rtp-msg-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-msg-core-1.cisco.com [161.44.11.97]) id QQnxtv15881 for ; Wed, 15 Jan 2003 17:45:06 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id h0FHjnnf015937 for ; Wed, 15 Jan 2003 12:45:49 -0500 (EST) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id MAA19973 for ; Wed, 15 Jan 2003 12:45:04 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h0FHj4m28588 for mpls@uu.net; Wed, 15 Jan 2003 12:45:04 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnxtu09600 for ; Wed, 15 Jan 2003 17:43:46 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnxtu05898 for ; Wed, 15 Jan 2003 17:39:30 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnxtu10345 for ; Wed, 15 Jan 2003 17:39:30 GMT Received: from workhorse.fictitious.org by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: workhorse.fictitious.org [209.150.1.230]) id QQnxtu10316 for ; Wed, 15 Jan 2003 17:39:29 GMT Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id MAA05177; Wed, 15 Jan 2003 12:38:37 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200301151738.MAA05177@workhorse.fictitious.org> To: Cheng-Yin.Lee@alcatel.com cc: curtis@fictitious.org, "'mpls@UU.NET'" Reply-To: curtis@fictitious.org Subject: Re: Some suggestions for LSP Ping In-reply-to: Your message of "15 Jan 2003 12:28:47 EST." <3E259A4F.840941E8@alcatel.com> Date: Wed, 15 Jan 2003 12:38:37 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <3E259A4F.840941E8@alcatel.com>, "Cheng-Yin Lee" writes: > Curtis, > > Curtis Villamizar wrote: > > > > If you are doing continuous monitoring you would initialize monitoring > > as you have outlined above. > > > > After initialization, pings would be used to verify connectivity and > > give a first order check on SLA to suppliment MIB based or other > > statistics. This is where random addresses can be used in addition to > > the more deterministic addresses obtained from the traceroute. > > > > Traceroute would then have to be repeated if one of two events might > > have occurred, 1) an LSP reroute, 2) a change in the way load is > > distributed at a multipath branch point. Lets consider these two > > separately. > > > > Testing is initiated by the ingress. For a RSVP/TE LSP the ingress > > knows if the LSP has been rerouted, because the ingress must initiate > > that action. For LDP, a reroute would occur only after a topology > > change which could be noted. > > > > If the "shelf life" returned by the LSRs may indicate one of a number > > of conditions, 1) the multipath distribution never changes, 2) the > > shelf life duration is known but the start time is unavailable, 3) the > > remaining shelf life is known. The first case is easy. If there is a > > topology change, then the traceroute has to be repeated. The third > > case is also easy, the remaining shelf life allows a traceroute to be > > scheduled. The second case, where only shelf life duration is known, > > requires periodic traceroutes initially. Once a transition occurs, > > the approximate start time is available and a traceroute can be > > scheduled rather than performed periodically. > > > > Between scheduled traceroutes (if any are needed) ping can be > > performed using both the deterministic addresses and some random > > addresses. > > > > This sort of recommendation can be added to the document (although it > > would start to get sort of long). I would leave that decision along > > with the decision to accept any of the prior suggestions I made up to > > the authors. > If your suggestions are accepted, some recommendations as the above in > for e.g. the appendix would be useful. > > My understanding from your clarification above is - this method does not > necessarily verify the test packet actually traverse the path data > traffic would take. Have you come to the same conclusion? Your understanding is incorrect. No I have not come to that conclusion. There is very weak basis for some of your prior statements and this one so I may just discontinue this discussion. I am very close to coming to the conclusion that you are trying to waste my time. To more directly address and provide more detail to your latest assertion and question - For the case where the load balance changes, there may be a period in which it is not certain which path some of the prior pings took, but by specifying the shelf life, that period can be made small while minimizing the overhead of repeating traceroutes. > [Note: If you use the payload header & Router Alert option method, that > method exercises the test packet on the path data traffic would take] > > thanks, > Cheng-Yin Curtis From owner-mpls@UU.NET Wed Jan 15 14:15:35 2003 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06982 for ; Wed, 15 Jan 2003 14:15:35 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnxub15201 for ; Wed, 15 Jan 2003 19:18:52 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnxub14939; Wed, 15 Jan 2003 19:18:43 GMT Received: by mail-control.ash.ops.us.uu.net id QQnxub24245 for mpls-outgoing; Wed, 15 Jan 2003 19:18:15 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnxub24221 for ; Wed, 15 Jan 2003 19:18:02 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnxub25768 for ; Wed, 15 Jan 2003 19:15:28 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnxub11982 for ; Wed, 15 Jan 2003 19:15:27 GMT Received: from rtp-msg-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-msg-core-1.cisco.com [161.44.11.97]) id QQnxub11975 for ; Wed, 15 Jan 2003 19:15:27 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id h0FJGAki000512 for ; Wed, 15 Jan 2003 14:16:10 -0500 (EST) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA27939 for ; Wed, 15 Jan 2003 14:15:25 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h0FJFPe05428 for mpls@uu.net; Wed, 15 Jan 2003 14:15:25 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnxua22585 for ; Wed, 15 Jan 2003 19:08:08 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnxua26251 for ; Wed, 15 Jan 2003 19:05:47 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnxua03720 for ; Wed, 15 Jan 2003 19:05:45 GMT Received: from rtp-msg-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-msg-core-1.cisco.com [161.44.11.97]) id QQnxua03702 for ; Wed, 15 Jan 2003 19:05:44 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id h0FJ67Le028805; Wed, 15 Jan 2003 14:06:07 -0500 (EST) Received: from bifocal.cisco.com (bifocal.cisco.com [161.44.172.150]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA27155; Wed, 15 Jan 2003 14:05:22 -0500 (EST) Received: from localhost (swallow@localhost) by bifocal.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id OAA05427; Wed, 15 Jan 2003 14:05:22 -0500 (EST) Message-Id: <200301151905.OAA05427@bifocal.cisco.com> X-Authentication-Warning: bifocal.cisco.com: swallow owned process doing -bs To: Cheng-Yin.Lee@alcatel.com cc: curtis@fictitious.org, "'mpls@UU.NET'" , swallow@cisco.com Subject: Re: Some suggestions for LSP Ping In-reply-to: Your message of "15 Jan 2003 12:28:47 EST." <3E259A4F.840941E8@alcatel.com> Date: Wed, 15 Jan 2003 14:05:22 -0500 From: George Swallow Sender: owner-mpls@UU.NET Precedence: bulk Cheng-Yin > [Note: If you use the payload header & Router Alert option method, that > method exercises the test packet on the path data traffic would take] If what you are trying to accomplish is to diagnose one single VPN flow it might work if: 1. you set the source address to the address of the flow. (this raises some issues on getting the Ping Reply back to where it is needed) 2. the hash includes no other fields than source and dest 3. the hash has not been reseeded or changed by some topological event since the problem occurred. I believe that once an operator discovered a problem they would want to explore all the paths to determine the health of their network. The use of RA also raises three further issues. 1. If a 127/24 addressed packet were to escape from a provider, it would be eaten by the first router it encouters. If you send a ping with RA and it escapses, if the customer's routers don't recognize LSP-Ping, the message will be delivered all the way to the host. 2. If an LSP-Ping were to escape from a broken LSP at a node that did not recognize LSP-Ping, it could end up being successfully forwarded to the destination node causing you to *not* detect the break. 3. If you eliminate use of the 127/24 range, you don't have a set of addresses that you can employ to explore the EMCP paths of an LSP. So I think there is little benefit and many drawbacks to your proposal. ...George ================================================================== George Swallow Cisco Systems (978) 497-8143 250 Apollo Drive Chelmsford, Ma 01824 From owner-mpls@UU.NET Wed Jan 15 15:39:50 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09422 for ; Wed, 15 Jan 2003 15:39:50 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnxug09956 for ; Wed, 15 Jan 2003 20:43:10 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnxug09557; Wed, 15 Jan 2003 20:43:00 GMT Received: by mail-control.ash.ops.us.uu.net id QQnxug19230 for mpls-outgoing; Wed, 15 Jan 2003 20:42:34 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnxug19212 for ; Wed, 15 Jan 2003 20:42:16 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnxug00855 for ; Wed, 15 Jan 2003 20:39:44 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnxug02987 for ; Wed, 15 Jan 2003 20:39:44 GMT Received: from kanmx1.ca.alcatel.com by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: m115-138.on.tac.net [209.202.115.138] (may be forged)) id QQnxug02974 for ; Wed, 15 Jan 2003 20:39:43 GMT Received: (qmail 26950 invoked from network); 15 Jan 2003 20:46:18 -0000 Received: (ofmipd 138.120.105.217); 15 Jan 2003 20:45:56 -0000 Received: from alcatel.com ([138.120.62.54]) by camail03.ca.alcatel.com (Netscape Messaging Server 4.15) with ESMTP id H8RW2100.UID; Wed, 15 Jan 2003 15:39:37 -0500 Date: 15 Jan 2003 15:39:34 -0500 Message-ID: <3E25C706.3AA1F31@alcatel.com> From: "Cheng-Yin Lee" Reply-To: Cheng-Yin.Lee@alcatel.com To: "George Swallow" Cc: curtis@fictitious.org, "'mpls@UU.NET'" X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 Subject: Re: Some suggestions for LSP Ping References: <200301151905.OAA05427@bifocal.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit George, > > [Note: If you use the payload header & Router Alert option method, that > > method exercises the test packet on the path data traffic would take] > > If what you are trying to accomplish is to diagnose one single VPN > flow it might work if: > > 1. you set the source address to the address of the flow. This has been noted in this thread. > (this raises some issues on getting the Ping Reply back to where it > is needed) Good point. Perhaps the return address could be specified in the LSP Ping message. > 2. the hash includes no other fields than source and dest Agree, I noted this in the first email I sent on this thread, and suggested some additional features. > 3. the hash has not been reseeded or changed by some topological event > since the problem occurred. If you do another ping after this event, then the test packet should traverse the path data take. > I believe that once an operator discovered a problem they would want > to explore all the paths to determine the health of their network. > > The use of RA also raises three further issues. > > 1. If a 127/24 addressed packet were to escape from a provider, it > would be eaten by the first router it encouters. If you send a ping > with RA and it escapses, if the customer's routers don't recognize > LSP-Ping, the message will be delivered all the way to the host. Agree, this has been noted in the thread. > 2. If an LSP-Ping were to escape from a broken LSP at a node that did > not recognize LSP-Ping, it could end up being successfully forwarded > to the destination node causing you to *not* detect the break. Wouldn't the destination node/customer node drop it if it is not LSP Ping aware? > 3. If you eliminate use of the 127/24 range, you don't have a set of > addresses that you can employ to explore the EMCP paths of an LSP. If we look at the problem this way, yes. > So I think there is little benefit and many drawbacks to your proposal. I think we should not ignore the advantages of this approach or the disadvantages of the other proposal in drawing the above conclusion. In any case, these suggestions are meant to be helpful and the authors did ask for suggestions. If the consensus is they are not useful, then I am fine with that. Thanks, Cheng-Yin From owner-mpls@UU.NET Wed Jan 15 16:01:45 2003 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09900 for ; Wed, 15 Jan 2003 16:01:45 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnxui17868 for ; Wed, 15 Jan 2003 21:05:06 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnxui17770; Wed, 15 Jan 2003 21:05:04 GMT Received: by mail-control.ash.ops.us.uu.net id QQnxui02115 for mpls-outgoing; Wed, 15 Jan 2003 21:04:50 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnxui01881 for ; Wed, 15 Jan 2003 21:04:36 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnxui25195 for ; Wed, 15 Jan 2003 21:03:31 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnxui16431 for ; Wed, 15 Jan 2003 21:03:31 GMT Received: from kanmx1.ca.alcatel.com by cmr1.ash.ops.us.uu.net with SMTP (peer crosschecked as: m115-138.on.tac.net [209.202.115.138] (may be forged)) id QQnxui16415 for ; Wed, 15 Jan 2003 21:03:30 GMT Received: (qmail 8049 invoked from network); 15 Jan 2003 21:10:10 -0000 Received: (ofmipd 138.120.105.217); 15 Jan 2003 21:09:48 -0000 Received: from alcatel.com ([138.120.62.54]) by camail03.ca.alcatel.com (Netscape Messaging Server 4.15) with ESMTP id H8RX5T00.RJD; Wed, 15 Jan 2003 16:03:29 -0500 Date: 15 Jan 2003 16:03:26 -0500 Message-ID: <3E25CC9E.E5F083B2@alcatel.com> From: "Cheng-Yin Lee" Reply-To: Cheng-Yin.Lee@alcatel.com To: curtis@fictitious.org Cc: "'mpls@UU.NET'" X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 Subject: Re: Some suggestions for LSP Ping References: <200301151738.MAA05177@workhorse.fictitious.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Curtis, Curtis Villamizar wrote: > To more directly address and provide more detail to your latest > assertion and question - For the case where the load balance changes, > there may be a period in which it is not certain which path some of > the prior pings took, I think we are in agreement here, my understanding is the test packet may not traverse the path data traffic would take (if a data packet is sent out at the same time) > but by specifying the shelf life, that period > can be made small while minimizing the overhead of repeating > traceroutes. agree. I agree it is not useful to continue discussion at this point but I hope you appreciate that you have given good clarification to the LSP Ping draft and that documenting functions including scope & limitations is useful. Thanks Cheng-Yin From owner-mpls@UU.NET Wed Jan 15 17:15:29 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11912 for ; Wed, 15 Jan 2003 17:15:28 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnxum18951; Wed, 15 Jan 2003 22:03:58 GMT Received: by mail-control.ash.ops.us.uu.net id QQnxum00630 for mpls-outgoing; Wed, 15 Jan 2003 22:03:38 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnxum00617 for ; Wed, 15 Jan 2003 22:03:37 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnxum01017 for ; Wed, 15 Jan 2003 22:02:49 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnxum18912 for ; Wed, 15 Jan 2003 22:02:48 GMT Received: from smtp1.opnet.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: smtp1.opnet.com [141.156.71.6]) id QQnxum18889 for ; Wed, 15 Jan 2003 22:02:47 GMT Received: from wtn10216.opnet.com (unverified) by smtp1.opnet.com (Content Technologies SMTPRS 4.2.10) with ESMTP id ; Wed, 15 Jan 2003 17:02:36 -0500 Message-Id: <5.0.0.25.2.20030115165018.00afcdd0@mail.opnet.com> X-Sender: skalra@mail.opnet.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Wed, 15 Jan 2003 17:06:12 -0500 To: mpls@UU.NET From: Sachin Kalra Subject: Question about BGP/MPLS VPNs Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Dear MPLS Community: I would appreciate if someone can answer the following question about BGP-MPLS VPNs. Lets say we have the following topology: [CE1] [CE11] \ / [PE1]-----------------[Rtr1]-------------------[PE2] / \ [CE2] [CE22] 1. PE and CEs have static routes configured between each other. i.e. no routing protocol running on the interfaces connecting PEs and CEs. Question. How will a packet going from CE1 and destined to interface on PE2 (that connects PE2 and CE11) reach its destination? The problem is that when PE2 receives a packet destined to its out interface connecting "PE2->CE11". PE2 does not know that the packet is destined to itself. Because it just look at the bottom label of the packet, and as per the entries into its VRF table, PE2 just sends out the packet to CE11. Is this the correct behavior? I appreciate your response. Thanks, Sachin Kalra From owner-mpls@UU.NET Wed Jan 15 17:15:57 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11953 for ; Wed, 15 Jan 2003 17:15:57 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnxun06999 for ; Wed, 15 Jan 2003 22:19:15 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnxun06752; Wed, 15 Jan 2003 22:19:07 GMT Received: by mail-control.ash.ops.us.uu.net id QQnxun03507 for mpls-outgoing; Wed, 15 Jan 2003 22:18:38 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnxun03495 for ; Wed, 15 Jan 2003 22:18:24 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnxun09874 for ; Wed, 15 Jan 2003 22:16:07 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnxun24113 for ; Wed, 15 Jan 2003 22:16:06 GMT Received: from rtp-msg-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-msg-core-1.cisco.com [161.44.11.97]) id QQnxun24102 for ; Wed, 15 Jan 2003 22:16:06 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id h0FMGmdY028850 for ; Wed, 15 Jan 2003 17:16:49 -0500 (EST) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id RAA13150 for ; Wed, 15 Jan 2003 17:16:03 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h0FMG3517826 for mpls@uu.net; Wed, 15 Jan 2003 17:16:03 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnxum02953 for ; Wed, 15 Jan 2003 22:14:37 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnxum01771 for ; Wed, 15 Jan 2003 22:09:41 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnxum29818 for ; Wed, 15 Jan 2003 22:09:41 GMT Received: from sj-msg-core-4.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-4.cisco.com [171.71.163.54]) id QQnxum29809 for ; Wed, 15 Jan 2003 22:09:40 GMT Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-msg-core-4.cisco.com (8.12.2/8.12.6) with ESMTP id h0FM9d0E009844; Wed, 15 Jan 2003 14:09:39 -0800 (PST) Received: from cisco.com (komorow.cisco.com [10.61.160.50]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id ADF29939; Wed, 15 Jan 2003 14:06:32 -0800 (PST) Message-ID: <3E25DC1F.4E3577DC@cisco.com> Date: Wed, 15 Jan 2003 23:09:35 +0100 From: Robert Raszuk Reply-To: raszuk@cisco.com Organization: Signature: http://www.employees.org/~raszuk/sig/ X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Sachin Kalra CC: mpls@UU.NET Subject: Re: Question about BGP/MPLS VPNs References: <5.0.0.25.2.20030115165018.00afcdd0@mail.opnet.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi Sachin, > Because it just look at the bottom label of the packet, > and as per the entries into its VRF table, PE2 just sends out the packet to > CE11. PE2 should based on the information retrived from the VPN label do the vrf lookup which reveals that the packet is destined to itself. There is no need to send it to CE11. R. > Sachin Kalra wrote: > > Dear MPLS Community: > > I would appreciate if someone can answer the following question about > BGP-MPLS VPNs. > > Lets say we have the following topology: > > [CE1] [CE11] > \ / > [PE1]-----------------[Rtr1]-------------------[PE2] > / \ > [CE2] [CE22] > > 1. PE and CEs have static routes configured between each other. i.e. no > routing protocol running on the interfaces connecting PEs and CEs. > > Question. How will a packet going from CE1 and destined to interface on PE2 > (that connects PE2 and CE11) reach its destination? > > The problem is that when PE2 receives a packet destined to its out > interface connecting "PE2->CE11". PE2 does not know that the packet is > destined to itself. Because it just look at the bottom label of the packet, > and as per the entries into its VRF table, PE2 just sends out the packet to > CE11. > > Is this the correct behavior? > > I appreciate your response. > Thanks, > Sachin Kalra From owner-mpls@UU.NET Wed Jan 15 17:35:52 2003 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12734 for ; Wed, 15 Jan 2003 17:35:52 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnxuo15550 for ; Wed, 15 Jan 2003 22:39:12 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnxuo13021; Wed, 15 Jan 2003 22:37:46 GMT Received: by mail-control.ash.ops.us.uu.net id QQnxuo05068 for mpls-outgoing; Wed, 15 Jan 2003 22:37:20 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnxuo05063 for ; Wed, 15 Jan 2003 22:37:09 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnxuo26190 for ; Wed, 15 Jan 2003 22:36:16 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnxuo11815 for ; Wed, 15 Jan 2003 22:36:15 GMT Received: from smtp1.opnet.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: smtp1.opnet.com [141.156.71.6]) id QQnxuo11810 for ; Wed, 15 Jan 2003 22:36:15 GMT Received: from wtn10216.opnet.com (unverified) by smtp1.opnet.com (Content Technologies SMTPRS 4.2.10) with ESMTP id ; Wed, 15 Jan 2003 17:36:09 -0500 Message-Id: <5.0.0.25.2.20030115172459.00b19e40@mail.opnet.com> X-Sender: skalra@mail.opnet.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Wed, 15 Jan 2003 17:39:44 -0500 To: raszuk@cisco.com From: Sachin Kalra Subject: Re: Question about BGP/MPLS VPNs Cc: mpls@UU.NET In-Reply-To: <3E25DC1F.4E3577DC@cisco.com> References: <5.0.0.25.2.20030115165018.00afcdd0@mail.opnet.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_182171919==_.ALT" Sender: owner-mpls@UU.NET Precedence: bulk --=====================_182171919==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Hi Robert: Thanks for the reply. >PE2 should based on the information retrived from the VPN label do the >vrf lookup which reveals that the packet is destined to itself. There is >no need to send it to CE11. But shouldn't PE2 do a "NHLFE lookup" instead of "VRF lookup" when it gets a packet from PE1, with a label. And if PE2 only does a NHLFE lookup then all it gets is an outgoing interface for the label. (In this case out iface will be the one connecting to CE11) Please comment. Thanks, Sachin Kalra ********************************************************************************* Just to be more clear, following is my VRF table at PE2. Where 1. "192.0.5.1" is the interface on PE2 (that connects PE2 and CE11). 2. "192.0.5.2" is the interface on CE11 (that connects CE11 and PE2). 3. "192.0.25.1" is the loopback interface on CE11. 4. "192.0.7.1", "192.0.1.1", "192.0.19.1" are PE1, CE1 and CE2 respectively ====================================================== VRF Table for VRF_A at PE2: Destination Subnet Mask Next Hop Out Iface Bottom Label Top Label ----------- ----------- ------------ --------- ------------ --------- 192.0.5.0 255.255.255.0 192.0.5.1 IF0 31 UNDEF 192.0.25.0 255.255.255.0 192.0.5.2 IF0 32 UNDEF 192.0.1.0 255.255.255.0 192.0.7.1 IF2 31 31 192.0.19.0 255.255.255.0 192.0.7.1 IF2 32 31 ====================================================== At 11:09 PM 1/15/03 +0100, Robert Raszuk wrote: >Hi Sachin, > > > Because it just look at the bottom label of the packet, > > and as per the entries into its VRF table, PE2 just sends out the packet to > > CE11. > >PE2 should based on the information retrived from the VPN label do the >vrf lookup which reveals that the packet is destined to itself. There is >no need to send it to CE11. > >R. > > > Sachin Kalra wrote: > > > > Dear MPLS Community: > > > > I would appreciate if someone can answer the following question about > > BGP-MPLS VPNs. > > > > Lets say we have the following topology: > > > > [CE1] [CE11] > > \ / > > [PE1]-----------------[Rtr1]-------------------[PE2] > > / \ > > [CE2] [CE22] > > > > 1. PE and CEs have static routes configured between each other. i.e. no > > routing protocol running on the interfaces connecting PEs and CEs. > > > > Question. How will a packet going from CE1 and destined to interface on PE2 > > (that connects PE2 and CE11) reach its destination? > > > > The problem is that when PE2 receives a packet destined to its out > > interface connecting "PE2->CE11". PE2 does not know that the packet is > > destined to itself. Because it just look at the bottom label of the packet, > > and as per the entries into its VRF table, PE2 just sends out the packet to > > CE11. > > > > Is this the correct behavior? > > > > I appreciate your response. > > Thanks, > > Sachin Kalra =========================================================== Sachin Kalra Modeling Engineer OPNET Technologies, Inc. (240)-497-3000 x2796 =========================================================== Register for OPNET's Online Technology Workshops (http://www.opnet.com/TechWorkshops/) =========================================================== --=====================_182171919==_.ALT Content-Type: text/html; charset="us-ascii" Hi Robert:

Thanks for the reply.

PE2 should based on the information retrived from the VPN label do the
vrf lookup which reveals that the packet is destined to itself. There is
no need to send it to CE11.

But shouldn't PE2 do a "NHLFE lookup" instead of "VRF lookup" when it gets a packet from PE1, with a label.

And if PE2 only does a NHLFE lookup then all it gets is an outgoing interface for the label. (In this case out iface will be the one connecting to CE11)

Please comment.
Thanks,
Sachin Kalra


*********************************************************************************
Just to be more clear, following is my VRF table at PE2. Where

1. "192.0.5.1" is the interface on PE2 (that connects PE2 and CE11).
2. "192.0.5.2" is the interface on CE11 (that connects CE11 and PE2).
3. "192.0.25.1" is the loopback interface on CE11.
4. "192.0.7.1", "192.0.1.1", "192.0.19.1" are PE1, CE1 and CE2 respectively

======================================================
VRF Table for VRF_A at PE2:
 
Destination       Subnet Mask        Next Hop      Out Iface    Bottom Label   Top Label
-----------            -----------                 ------------        ---------        ------------           ---------
192.0.5.0          255.255.255.0      192.0.5.1       IF0             31                   UNDEF    
192.0.25.0        255.255.255.0      192.0.5.2       IF0             32                   UNDEF    
192.0.1.0          255.255.255.0      192.0.7.1       IF2             31                   31       
192.0.19.0        255.255.255.0      192.0.7.1      IF2             32                   31       
======================================================


At 11:09 PM 1/15/03 +0100, Robert Raszuk wrote:

Hi Sachin,

> Because it just look at the bottom label of the packet,
> and as per the entries into its VRF table, PE2 just sends out the packet to
> CE11.

PE2 should based on the information retrived from the VPN label do the
vrf lookup which reveals that the packet is destined to itself. There is
no need to send it to CE11.

R.

> Sachin Kalra wrote:
>
> Dear MPLS Community:
>
> I would appreciate if someone can answer the following question about
> BGP-MPLS VPNs.
>
> Lets say we have the following topology:
>
> [CE1]                                                             [CE11]
>          \                                                           /
>          [PE1]-----------------[Rtr1]-------------------[PE2]
>          /                                                           \
> [CE2]                                                             [CE22]
>
> 1. PE and CEs have static routes configured between each other. i.e. no
> routing protocol running on the interfaces connecting PEs and CEs.
>
> Question. How will a packet going from CE1 and destined to interface on PE2
> (that connects PE2 and CE11) reach its destination?
>
> The problem is that when PE2 receives a packet destined to its out
> interface connecting "PE2->CE11". PE2 does not know that the packet is
> destined to itself. Because it just look at the bottom label of the packet,
> and as per the entries into its VRF table, PE2 just sends out the packet to
> CE11.
>
> Is this the correct behavior?
>
> I appreciate your response.
> Thanks,
> Sachin Kalra

===========================================================
Sachin Kalra
Modeling Engineer
OPNET Technologies, Inc.
(240)-497-3000 x2796
===========================================================
Register for OPNET's Online Technology Workshops
(http://www.opnet.com/TechWorkshops/)
===========================================================
--=====================_182171919==_.ALT-- From owner-mpls@UU.NET Wed Jan 15 18:16:11 2003 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14141 for ; Wed, 15 Jan 2003 18:16:11 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnxur25485 for ; Wed, 15 Jan 2003 23:19:29 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnxur25299; Wed, 15 Jan 2003 23:19:22 GMT Received: by mail-control.ash.ops.us.uu.net id QQnxur27086 for mpls-outgoing; Wed, 15 Jan 2003 23:19:02 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnxur27081 for ; Wed, 15 Jan 2003 23:18:57 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnxur02938 for ; Wed, 15 Jan 2003 23:16:07 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnxur16682 for ; Wed, 15 Jan 2003 23:16:06 GMT Received: from rtp-msg-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-msg-core-1.cisco.com [161.44.11.97]) id QQnxur16660 for ; Wed, 15 Jan 2003 23:16:05 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id h0FNGlRq005346 for ; Wed, 15 Jan 2003 18:16:48 -0500 (EST) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id SAA17074 for ; Wed, 15 Jan 2003 18:16:02 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h0FNG2s23500 for mpls@uu.net; Wed, 15 Jan 2003 18:16:02 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnxuq26523 for ; Wed, 15 Jan 2003 23:14:53 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnxuq14984 for ; Wed, 15 Jan 2003 23:13:37 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnxuq14585 for ; Wed, 15 Jan 2003 23:13:36 GMT Received: from fire.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: firebird.cisco.com [171.68.227.73]) id QQnxuq14575 for ; Wed, 15 Jan 2003 23:13:36 GMT Received: from cisco.com (sj-cse-155.cisco.com [171.69.88.203]) by fire.cisco.com (8.11.6+Sun/8.8.8) with ESMTP id h0FNDYO05818; Wed, 15 Jan 2003 15:13:34 -0800 (PST) Message-ID: <3E25EB1E.4B6B6C2@cisco.com> Date: Wed, 15 Jan 2003 15:13:34 -0800 From: "Gopal@Cisco" Organization: Cisco Systems Inc. X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Sachin Kalra CC: raszuk@cisco.com, mpls@UU.NET Subject: Re: Question about BGP/MPLS VPNs References: <5.0.0.25.2.20030115165018.00afcdd0@mail.opnet.com> <5.0.0.25.2.20030115172459.00b19e40@mail.opnet.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Sachin, PLs see iinline... Sachin Kalra wrote: > > Hi Robert: > > Thanks for the reply. > > > PE2 should based on the information retrived from the VPN label do > > the > > vrf lookup which reveals that the packet is destined to itself. > > There is > > no need to send it to CE11. > > But shouldn't PE2 do a "NHLFE lookup" instead of "VRF lookup" when it > gets a packet from PE1, with a label. > > And if PE2 only does a NHLFE lookup then all it gets is an outgoing > interface for the label. (In this case out iface will be the one > connecting to CE11) OUtgoing interface is empty for connected routes in NHLFE. Just like this, R3#sho tag for tag 27 Local Outgoing Prefix Bytes tag Outgoing Next Hop tag tag or VC or Tunnel Id switched interface 27 Aggregate 10.10.33.0/24[V] 0 R3# > > Please comment. > Thanks, > Sachin Kalra > > ********************************************************************************* > Just to be more clear, following is my VRF table at PE2. Where > > 1. "192.0.5.1" is the interface on PE2 (that connects PE2 and CE11). > 2. "192.0.5.2" is the interface on CE11 (that connects CE11 and PE2). > 3. "192.0.25.1" is the loopback interface on CE11. > 4. "192.0.7.1", "192.0.1.1", "192.0.19.1" are PE1, CE1 and CE2 > respectively > > ====================================================== > VRF Table for VRF_A at PE2: > > Destination Subnet Mask Next Hop Out Iface Bottom > Label Top Label > ----------- ----------- ------------ > --------- ------------ --------- > 192.0.5.0 255.255.255.0 192.0.5.1 IF0 > 31 UNDEF > 192.0.25.0 255.255.255.0 192.0.5.2 IF0 > 32 UNDEF > 192.0.1.0 255.255.255.0 192.0.7.1 IF2 > 31 31 > 192.0.19.0 255.255.255.0 192.0.7.1 IF2 > 32 31 > ====================================================== > > At 11:09 PM 1/15/03 +0100, Robert Raszuk wrote: > > > Hi Sachin, > > > > > Because it just look at the bottom label of the packet, > > > and as per the entries into its VRF table, PE2 just sends out the > > packet to > > > CE11. > > > > PE2 should based on the information retrived from the VPN label do > > the > > vrf lookup which reveals that the packet is destined to itself. > > There is > > no need to send it to CE11. > > > > R. > > > > > Sachin Kalra wrote: > > > > > > Dear MPLS Community: > > > > > > I would appreciate if someone can answer the following question > > about > > > BGP-MPLS VPNs. > > > > > > Lets say we have the following topology: > > > > > > [CE1] > > [CE11] > > > > > \ / > > > [PE1]-----------------[Rtr1]-------------------[PE2] > > > > > / \ > > > [CE2] > > [CE22] > > > > > > 1. PE and CEs have static routes configured between each other. > > i.e. no > > > routing protocol running on the interfaces connecting PEs and CEs. > > > > > > Question. How will a packet going from CE1 and destined to > > interface on PE2 > > > (that connects PE2 and CE11) reach its destination? > > > > > > The problem is that when PE2 receives a packet destined to its out > > > interface connecting "PE2->CE11". PE2 does not know that the > > packet is > > > destined to itself. Because it just look at the bottom label of > > the packet, > > > and as per the entries into its VRF table, PE2 just sends out the > > packet to > > > CE11. > > > > > > Is this the correct behavior? > > > > > > I appreciate your response. > > > Thanks, > > > Sachin Kalra > > =========================================================== > Sachin Kalra > Modeling Engineer > OPNET Technologies, Inc. > (240)-497-3000 x2796 > =========================================================== > Register for OPNET's Online Technology Workshops > (http://www.opnet.com/TechWorkshops/) > =========================================================== -- Gopal(www-tac/~gnaganab),CCIE#6209,1.408.525.9922,RP-TAC,9:00AM-5:00PM(PST) Cisco Systems Inc.-Changing the Way We Work, Live, Play and Learn From owner-mpls@UU.NET Wed Jan 15 18:17:40 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14189 for ; Wed, 15 Jan 2003 18:17:40 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnxur28745 for ; Wed, 15 Jan 2003 23:20:59 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnxur28428; Wed, 15 Jan 2003 23:20:49 GMT Received: by mail-control.ash.ops.us.uu.net id QQnxur27129 for mpls-outgoing; Wed, 15 Jan 2003 23:20:22 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnxur27121 for ; Wed, 15 Jan 2003 23:20:03 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnxur04755 for ; Wed, 15 Jan 2003 23:16:10 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnxur25065 for ; Wed, 15 Jan 2003 23:16:09 GMT Received: from rtp-msg-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-msg-core-1.cisco.com [161.44.11.97]) id QQnxur25056 for ; Wed, 15 Jan 2003 23:16:09 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id h0FNGlEM005348 for ; Wed, 15 Jan 2003 18:16:53 -0500 (EST) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id SAA17076 for ; Wed, 15 Jan 2003 18:16:02 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h0FNG2u23508 for mpls@uu.net; Wed, 15 Jan 2003 18:16:02 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnxuq26526 for ; Wed, 15 Jan 2003 23:14:53 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnxuq15055 for ; Wed, 15 Jan 2003 23:13:48 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnxuq14716 for ; Wed, 15 Jan 2003 23:13:48 GMT Received: from sj-msg-core-3.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-3.cisco.com [171.70.157.152]) id QQnxuq14708 for ; Wed, 15 Jan 2003 23:13:47 GMT Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id h0FND9jS007873; Wed, 15 Jan 2003 15:13:09 -0800 (PST) Received: from cisco.com (komorow.cisco.com [10.61.160.50]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id ADF36195; Wed, 15 Jan 2003 15:10:39 -0800 (PST) Message-ID: <3E25EB26.6293A786@cisco.com> Date: Thu, 16 Jan 2003 00:13:42 +0100 From: Robert Raszuk Reply-To: raszuk@cisco.com Organization: Signature: http://www.employees.org/~raszuk/sig/ X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Sachin Kalra CC: mpls@UU.NET Subject: Re: Question about BGP/MPLS VPNs References: <5.0.0.25.2.20030115165018.00afcdd0@mail.opnet.com> <5.0.0.25.2.20030115172459.00b19e40@mail.opnet.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Some implementations do only LFIB lookup and send the packet blindely to CE11 (then it bounces back) some use the concept of aggregate VPN label and do VRF lookup after LFIB lookup on PE2 which allows route aggregation among multiple sites connected to the same vrf or loadbalancing. I think the rfc does not mandate the behviour here. Rgs, R. > Sachin Kalra wrote: > > Hi Robert: > > Thanks for the reply. > > > PE2 should based on the information retrived from the VPN label do > > the > > vrf lookup which reveals that the packet is destined to itself. > > There is > > no need to send it to CE11. > > But shouldn't PE2 do a "NHLFE lookup" instead of "VRF lookup" when it > gets a packet from PE1, with a label. > > And if PE2 only does a NHLFE lookup then all it gets is an outgoing > interface for the label. (In this case out iface will be the one > connecting to CE11) > > Please comment. > Thanks, > Sachin Kalra > > ********************************************************************************* > Just to be more clear, following is my VRF table at PE2. Where > > 1. "192.0.5.1" is the interface on PE2 (that connects PE2 and CE11). > 2. "192.0.5.2" is the interface on CE11 (that connects CE11 and PE2). > 3. "192.0.25.1" is the loopback interface on CE11. > 4. "192.0.7.1", "192.0.1.1", "192.0.19.1" are PE1, CE1 and CE2 > respectively > > ====================================================== > VRF Table for VRF_A at PE2: > > Destination Subnet Mask Next Hop Out Iface Bottom > Label Top Label > ----------- ----------- ------------ > --------- ------------ --------- > 192.0.5.0 255.255.255.0 192.0.5.1 IF0 > 31 UNDEF > 192.0.25.0 255.255.255.0 192.0.5.2 IF0 > 32 UNDEF > 192.0.1.0 255.255.255.0 192.0.7.1 IF2 > 31 31 > 192.0.19.0 255.255.255.0 192.0.7.1 IF2 > 32 31 > ====================================================== > > At 11:09 PM 1/15/03 +0100, Robert Raszuk wrote: > > > Hi Sachin, > > > > > Because it just look at the bottom label of the packet, > > > and as per the entries into its VRF table, PE2 just sends out the > > packet to > > > CE11. > > > > PE2 should based on the information retrived from the VPN label do > > the > > vrf lookup which reveals that the packet is destined to itself. > > There is > > no need to send it to CE11. > > > > R. > > > > > Sachin Kalra wrote: > > > > > > Dear MPLS Community: > > > > > > I would appreciate if someone can answer the following question > > about > > > BGP-MPLS VPNs. > > > > > > Lets say we have the following topology: > > > > > > [CE1] > > [CE11] > > > > > \ / > > > [PE1]-----------------[Rtr1]-------------------[PE2] > > > > > / \ > > > [CE2] > > [CE22] > > > > > > 1. PE and CEs have static routes configured between each other. > > i.e. no > > > routing protocol running on the interfaces connecting PEs and CEs. > > > > > > Question. How will a packet going from CE1 and destined to > > interface on PE2 > > > (that connects PE2 and CE11) reach its destination? > > > > > > The problem is that when PE2 receives a packet destined to its out > > > interface connecting "PE2->CE11". PE2 does not know that the > > packet is > > > destined to itself. Because it just look at the bottom label of > > the packet, > > > and as per the entries into its VRF table, PE2 just sends out the > > packet to > > > CE11. > > > > > > Is this the correct behavior? > > > > > > I appreciate your response. > > > Thanks, > > > Sachin Kalra > > =========================================================== > Sachin Kalra > Modeling Engineer > OPNET Technologies, Inc. > (240)-497-3000 x2796 > =========================================================== > Register for OPNET's Online Technology Workshops > (http://www.opnet.com/TechWorkshops/) > =========================================================== From owner-mpls@UU.NET Thu Jan 16 00:09:42 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21052 for ; Thu, 16 Jan 2003 00:09:42 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnxvo09927 for ; Thu, 16 Jan 2003 05:13:01 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnxvo09623; Thu, 16 Jan 2003 05:12:51 GMT Received: by mail-control.ash.ops.us.uu.net id QQnxvo15656 for mpls-outgoing; Thu, 16 Jan 2003 05:12:37 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnxvo15640 for ; Thu, 16 Jan 2003 05:12:32 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnxvo29952 for ; Thu, 16 Jan 2003 05:12:04 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnxvo03650 for ; Thu, 16 Jan 2003 05:12:04 GMT Received: from rtp-msg-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-msg-core-1.cisco.com [161.44.11.97]) id QQnxvo03633 for ; Thu, 16 Jan 2003 05:12:03 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id h0G5Ck62000649 for ; Thu, 16 Jan 2003 00:12:47 -0500 (EST) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id AAA02081 for ; Thu, 16 Jan 2003 00:12:01 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h0G5C1b15223 for mpls@uu.net; Thu, 16 Jan 2003 00:12:01 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnxvo15103 for ; Thu, 16 Jan 2003 05:10:44 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnxvo22254 for ; Thu, 16 Jan 2003 05:05:37 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnxvo27335 for ; Thu, 16 Jan 2003 05:05:37 GMT Received: from workhorse.fictitious.org by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: workhorse.fictitious.org [209.150.1.230]) id QQnxvo27326 for ; Thu, 16 Jan 2003 05:05:36 GMT Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id AAA09496; Thu, 16 Jan 2003 00:04:35 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200301160504.AAA09496@workhorse.fictitious.org> To: "David Allan" cc: curtis@fictitious.org, mpls@UU.NET Reply-To: curtis@fictitious.org Subject: Re: suggested added text for multipath in draft-ietf-mpls-lsp-pin g-01 In-reply-to: Your message of "Tue, 07 Jan 2003 10:26:55 EST." Date: Thu, 16 Jan 2003 00:04:35 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message , "Da vid Allan" writes: > > - hash key type 5 has an unclear role, presumably the TLV length tells me > how many label entries to expect. I still owe you a response of this. > > + > > + Hash Key Type: IP Address or Next Label > > + -------------- ------------------------ > > + 1 label 1 or more label > > + 2 IPv4 address 1 or more IPv6 address > > + 3 label range 1 or more > > low/high label pairs > > + 4 IPv4 address range 1 or more > > low/high address pairs > > + 5 no more labels (nothing) > > + 6 All IPv4 addresses (nothing) > > + 7 no match (nothing) > > + 8 IPv6 address 1 or more IPv6 address > > + 9 IPv6 address range 1 or more low/high > > address pairs > > + 10 IPv4 bitmap see encapsulation below > > + 11 label bitmap see encapsulation below > > + 12 IPv6 bitmap see encapsulation below Hash key 5 is used when doing "per label" hashing and means "if there are no more labels on the stack we'd take this path". Sorry for the delay in responding. Curtis From owner-mpls@UU.NET Fri Jan 17 17:01:44 2003 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05808 for ; Fri, 17 Jan 2003 17:01:43 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnybw28830 for ; Fri, 17 Jan 2003 22:05:05 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnybw28571; Fri, 17 Jan 2003 22:04:57 GMT Received: by mail-control.ash.ops.us.uu.net id QQnybw24712 for mpls-outgoing; Fri, 17 Jan 2003 22:04:28 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnybw24253 for ; Fri, 17 Jan 2003 22:04:11 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnybw19799 for ; Fri, 17 Jan 2003 22:04:05 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnybw27589 for ; Fri, 17 Jan 2003 22:04:04 GMT Received: from rtp-msg-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-msg-core-1.cisco.com [161.44.11.97]) id QQnybw27556 for ; Fri, 17 Jan 2003 22:04:03 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id h0HM4lFw020061 for ; Fri, 17 Jan 2003 17:04:47 -0500 (EST) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id RAA22760 for ; Fri, 17 Jan 2003 17:04:01 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h0HM41O08822 for mpls@uu.net; Fri, 17 Jan 2003 17:04:01 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnybw23075 for ; Fri, 17 Jan 2003 22:03:09 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnybw20094 for ; Fri, 17 Jan 2003 22:02:40 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnybw18243 for ; Fri, 17 Jan 2003 22:02:39 GMT Received: from idylubn by cmr1.ash.ops.us.uu.net with SMTP (peer crosschecked as: [61.175.235.141]) id QQnybw18187 for ; Fri, 17 Jan 2003 22:02:37 GMT From: Georgina Wootton To: Subject: Re: Who taught you to use your PC? f Date: Fri, 17 Jan 2003 18:03:35 -0500 Mime-Version: 1.0 Content-Type: text/html Content-Transfer-Encoding: base64 Message-Id: Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: base64 PGh0bWw+PGJvZHk+PHRhYmxlIGJvcmRlcj0xIHdpZHRoPTQ1MCBib3JkZXJjb2xvcmRhcms9 IzAwMDAwMCBzdHlsZT0iYm9yZGVyLWNvbGxhcHNlOiBjb2xsYXBzZSIgYm9yZGVyY29sb3I9 IzExMTExMSBjZWxscGFkZGluZz0wIGNlbGxzcGFjaW5nPTAgYm9yZGVyY29sb3JsaWdodD0j MDAwMDAwPjx0cj48dGQgd2lkdGg9MTExIGJnY29sb3I9I0ZGRkZGRiBhbGlnbj1jZW50ZXIg Ym9yZGVyY29sb3I9IzAwMDAwMCByb3dzcGFuPTI+IDxiPjxmb250IHNpemU9NT5zeW1hbnRl YzwvZm9udD48L2I+PC90ZD48dGQgd2lkdGg9NDQgYmdjb2xvcj0jRkZDQzAwIGFsaWduPWNl bnRlciBib3JkZXJjb2xvcj0jMDAwMDAwPiZuYnNwOzwvdGQ+PHRkIHdpZHRoPTI5NCBiZ2Nv bG9yPSNGRkZGRkYgYWxpZ249Y2VudGVyIGJvcmRlcmNvbG9yPSNGRkZGRkYgcm93c3Bhbj0y IHN0eWxlPSJib3JkZXI6IDFweCBzb2xpZCAjRkZGRkZGIj4gPGI+PGZvbnQgZmFjZT1UYWhv bWEgc2l6ZT00Pk5vcnRvbiBBbnRpVmlydXMgMjAwMzxCUj4gPC9mb250PiA8Zm9udCBmYWNl PVRhaG9tYSBzaXplPTEgY29sb3I9IzMzMzMzMz4qKioqKioqKiogTk9XIFBMQVlJTkcgKioq KioqKioqPC9mb250PjwvYj48L3RkPjwvdHI+PHRyPjx0ZCB3aWR0aD00NCBiZ2NvbG9yPSMw MDAwMDAgYWxpZ249Y2VudGVyIGJvcmRlcmNvbG9yPSMwMDAwMDA+Jm5ic3A7PC90ZD48L3Ry PjwvdGFibGU+PHRhYmxlIGJvcmRlcj0wIHdpZHRoPTQ1MCBoZWlnaHQ9NjYgc3R5bGU9ImJv cmRlci1jb2xsYXBzZTogY29sbGFwc2UiIGJvcmRlcmNvbG9yPSMxMTExMTEgY2VsbHBhZGRp bmc9MCBjZWxsc3BhY2luZz0wPjx0cj48dGQgd2lkdGg9NDQ2IGhlaWdodD0xIGFsaWduPWNl bnRlciBiZ2NvbG9yPSMwMDAwMDA+IDxiPjxmb250IGZhY2U9VGFob21hIHNpemU9NCBjb2xv cj0jRkZDQzAwPkF0dGVudGlvbjwvZm9udD48Zm9udCBmYWNlPVRhaG9tYSBzaXplPTQ+PGZv bnQgY29sb3I9I0ZGQ0MwMD4hIDwvZm9udD4gPGZvbnQgY29sb3I9I0ZGRkZGRj5ORVcgTm9y dG9uIEFWIDIwMDMgUmVsZWFzZWQhPC9mb250PjwvZm9udD48L2I+PC90ZD48L3RyPjx0cj48 dGQgd2lkdGg9NDQ2IGhlaWdodD0xNiBhbGlnbj1jZW50ZXIgYmdjb2xvcj0jRkZDQzAwPiA8 Zm9udCBmYWNlPVRhaG9tYSBzaXplPTI+PGI+VGhlIE1vc3QgUG9wdWxhciBQQyBTb2Z0d2Fy ZSBIYXMgUmV0dXJuZWQgdG8gdGhlIFNjcmVlbiE8L2I+PC9mb250PjwvdGQ+PC90cj48dHI+ PHRkIHdpZHRoPTQ0NiBoZWlnaHQ9MTggYWxpZ249Y2VudGVyIGJnY29sb3I9IzAwMDAwMD4g PGI+PGZvbnQgZmFjZT1UYWhvbWEgc2l6ZT0yIGNvbG9yPSNGRkZGRkY+UHV0IHRoZSBTZXF1 ZWwgdG8gQUxMIEFudGlWaXJ1cyBQcm9ncmFtcyBvbiBZb3VyIFBDITwvZm9udD48L2I+PC90 ZD48L3RyPjx0cj48dGQgd2lkdGg9NDQ2IGhlaWdodD0xNiBhbGlnbj1jZW50ZXIgYm9yZGVy Y29sb3I9IzAwMDAwMCBiZ2NvbG9yPSMwMDAwMDA+PHAgYWxpZ249Y2VudGVyPiA8Zm9udCBj bGFzcz1ibGFjazEwIGZhY2U9VGFob21hIHNpemU9MiBjb2xvcj0jRkZDQzAwPjxiPkVOSEFO Q0VEITwvYj48L2ZvbnQ+PGZvbnQgY2xhc3M9YmxhY2sxMCBjb2xvcj0jRkZGRkZGIGZhY2U9 VGFob21hIHNpemU9Mj4gPGI+QXV0b21hdGljYWxseSByZW1vdmVzIFZpcnVzZXMsIFdvcm1z LCBhbmQgVHJvamFuczwvYj48L2ZvbnQ+PC90ZD48L3RyPjx0cj48dGQgd2lkdGg9NDQ2IGhl aWdodD0xNiBhbGlnbj1jZW50ZXIgYmdjb2xvcj0jMDAwMDAwPjxwIGFsaWduPWNlbnRlcj48 Yj4gPGZvbnQgY2xhc3M9YmxhY2sxMCBmYWNlPVRhaG9tYSBzaXplPTIgY29sb3I9I0ZGQ0Mw MD5ORVchPC9mb250Pjxmb250IGNsYXNzPWJsYWNrMTAgZmFjZT1UYWhvbWEgc2l6ZT0yIGNv bG9yPSNGRkZGRkY+IERldGVjdHMgYW5kIGJsb2NrcyBhbGwgdmlydXNlcyBpbiBpbnN0YW50 IG1lc3NhZ2UgYXR0YWNobWVudHM8L2ZvbnQ+PC9iPjwvdGQ+PC90cj48L3RhYmxlPjx0YWJs ZSBib3JkZXI9MCB3aWR0aD00NTAgaGVpZ2h0PTgxIGJnY29sb3I9I0ZGQ0MwMCBzdHlsZT0i Ym9yZGVyLWNvbGxhcHNlOiBjb2xsYXBzZSIgYm9yZGVyY29sb3I9IzExMTExMSBjZWxscGFk ZGluZz0wIGNlbGxzcGFjaW5nPTA+PHRyPjx0ZCB3aWR0aD00NTIgaGVpZ2h0PTc1IGJnY29s b3I9I0ZGRkZGRiBhbGlnbj1jZW50ZXIgc3R5bGU9ImJvcmRlci1zdHlsZTogc29saWQ7IGJv cmRlci13aWR0aDogNCIgYm9yZGVyY29sb3I9I0ZGQ0MwMD4gPGI+PGZvbnQgZmFjZT1UYWhv bWEgc2l6ZT0yPiZxdW90O0kgaGF2ZSBiZWVuIHVzaW5nIE5BViBmb3IgMyB5ZWFycyBhbmQg aXQgaGFzIE5FVkVSIGNyYXNoZWQgbXkgc3lzdGVtIGFuZCBkZXRlY3RzIEFMTCBlbWFpbCB2 aXJ1c2VzISBUaGVyZSB3YXMgTk8gaW1wYWN0IG9uIHRoZSBwZXJmb3JtYW5jZSBvZiBteSBt YWNoaW5lLiBJIGdpdmUgaXQgdHdvIHRodW1icyB1cCEmcXVvdDs8L2ZvbnQ+PC9iPjxmb250 IGZhY2U9VGFob21hIHNpemU9Mj48YnI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IDxpPi0gSi4gQnJvd24gKE5vcnRvbiBBbnRpVmlydXMqIFVzZXIpPGJyPiA8L2k+PC9mb250 PiA8aT48Zm9udCBmYWNlPVRhaG9tYSBzaXplPTE+PGI+KCpXaW5uZXIgLSZuYnNwOyBQQyBN QUdBWklORSBFRElUT1InUyBDSE9JQ0UgQVdBUkQgLSAzIFllYXJzIGluIGEgUk9XISk8L2I+ PC9mb250PjwvaT48L3RkPjwvdHI+PC90YWJsZT48dGFibGUgYm9yZGVyPTEgd2lkdGg9NDUw IGJvcmRlcmNvbG9yPSMwMDAwODAgYm9yZGVyY29sb3JsaWdodD0jNjY2NjY2IGJvcmRlcmNv bG9yZGFyaz0jMDAwMDAwIHN0eWxlPSJib3JkZXItY29sbGFwc2U6IGNvbGxhcHNlIiBjZWxs cGFkZGluZz0wIGNlbGxzcGFjaW5nPTAgaGVpZ2h0PTMzPjx0cj48dGQgd2lkdGg9MTAwJSBh bGlnbj1jZW50ZXIgYmdjb2xvcj0jMDAwMDAwIGhlaWdodD0zMz48Yj48Zm9udCBzaXplPTQg ZmFjZT1UYWhvbWE+IDxhIGhyZWY9Imh0dHA6Ly93d3cuc29mdHdhcmVzd2FwbWVldC5jb20v bm9ydG9uYXYwMTMuaHRtP24wMj14Z2FvY21oaWJ2dWJzYmVhYnNreWpkcmJ4a2FndnRodmNq bmd5dW8iIHN0eWxlPSJ0ZXh0LWRlY29yYXRpb246IG5vbmUgYmxpbms7IGNvbG9yOiAjRkZG RkZGOyBmb250LWZhbWlseTogVGFob21hOyBmb250LXNpemU6IDE0cHQ7IGZvbnQtd2VpZ2h0 OiBib2xkIj5DbGljayBIZXJlICZhbXA7IGdldCB5b3VycyBmb3IgT05MWSAkMjkuOTkhPC9h PjwvZm9udD48L2I+PC90ZD48L3RyPjwvdGFibGU+PHA+Jm5ic3A7PC9wPjxwPiZuYnNwOzwv cD48cCBhbGlnbj1jZW50ZXI+Jm5ic3A7PC9wPjx0YWJsZSBib3JkZXI9MCB3aWR0aD00NjA+ PHRyPjx0ZCB3aWR0aD0xMDAlPjxwIGFsaWduPWNlbnRlcj48Zm9udCBmYWNlPVRhaG9tYSBz aXplPTEgY29sb3I9IzY2NjY2Nj5Zb3VyIHBlcnNvbmFsIGVtYWlsIGFkZHJlc3Mgd2FzIG9i dGFpbmVkIGZyb20gYW4gb3B0LWluIGxpc3QuIE9wdC1pbiBVRUMgKFVuaXRlZCBFY29tbWVy Y2UgQ29hbGl0aW9uKSBBcHByb3ZlZCBMaXN0IC0gVHlwZSBOTlMgU3VmZml4ID0gelQlMjJk JUgmYW1wO0VVU0EuJm5ic3A7VG8gdW5zdWJzY3JpYmUgZnJvbSB0aGlzIGxpc3QsIHBsZWFz ZSA8YSBzdHlsZT0iY29sb3I6ICMwMDAwODAiIGhyZWY9aHR0cDovL3d3dy5zb2Z0d2FyZXN3 YXBtZWV0LmNvbS9yZW1vdmUuYXNwPkNsaWNrIGhlcmU8L2E+IC4gWW91IG5lZWQgdG8gYWxs b3cgNSBCdXNpbmVzcyBkYXlzIGZvciByZW1vdmFsLiBXZSBkbyBub3QgY29uZG9uZSBzcGFt IGluIGFueSBzaGFwZSBvciBmb3JtLiBUaGFuayBZb3Uga2luZGx5IGZvciB5b3VyIGNvb3Bl cmF0aW9uLjxicj5BcHBsaWNhbnQgcmVmdXNlZCB0byBzaXQgZG93biBhbmQgaW5zaXN0ZWQg b24gYmVpbmcgaW50ZXJ2aWV3ZWQgc3RhbmRpbmcgdXAuPGJyPiJgTGlmZSwgZG9uJ3QgdGFs ayB0byBtZSBhYm91dCBsaWZlLiciPC9mb250PjwvdGQ+PC90cj48L3RhYmxlPjwvYm9keT48 L2h0bWw+DQo= From owner-mpls@UU.NET Mon Jan 20 08:53:00 2003 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20238 for ; Mon, 20 Jan 2003 08:53:00 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnylr08724 for ; Mon, 20 Jan 2003 13:56:26 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnylr08653; Mon, 20 Jan 2003 13:56:23 GMT Received: by mail-control.ash.ops.us.uu.net id QQnylr22488 for mpls-outgoing; Mon, 20 Jan 2003 13:56:07 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnylr22439 for ; Mon, 20 Jan 2003 13:56:03 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnylr12672 for ; Mon, 20 Jan 2003 13:55:23 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnylr12877 for ; Mon, 20 Jan 2003 13:55:22 GMT Received: from motgate4.mot.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: motgate4.mot.com [144.189.100.102]) id QQnylr12871 for ; Mon, 20 Jan 2003 13:55:21 GMT Received: from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by motgate4.mot.com (Motorola/Motgate4) with ESMTP id h0KDtCC8026649; Mon, 20 Jan 2003 06:55:13 -0700 (MST) Received: [from hpux4.miel.mot.com (hpux4.miel.mot.com [217.1.84.89]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id GAA24024; Mon, 20 Jan 2003 06:55:08 -0700 (MST)] Received: from shruthi.miel.mot.com (shruthi.miel.mot.com [217.1.84.165]) by miel.mot.com (8.9.3/8.9.3) with ESMTP id TAA22522; Mon, 20 Jan 2003 19:25:13 +0530 (IST) Received: from pcwks92 (pcwks92.miel.mot.com [217.1.125.186]) by shruthi.miel.mot.com (8.11.6+Sun/8.11.6) with SMTP id h0KDsiN02470; Mon, 20 Jan 2003 19:24:44 +0530 (IST) From: "Dhananjay S. Patki" To: , Cc: , , , , , , Subject: ping & traceroute in MPLS VPN Date: Mon, 20 Jan 2003 19:31:46 +0530 Message-ID: <003601c2c08c$78e1bed0$ba7d01d9@pcwks92> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hello, I would like to know if anybody has already implemented ping/traceroute mechanisms as described in draft-ietf-mpls-lsp-ping-01.txt. If yes, I would like to take a look at the CLI commands defined for ping and traceroute. Any references to related documentation will be appreciated. Thanks, Dhananjay From owner-mpls@UU.NET Mon Jan 20 09:13:54 2003 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20680 for ; Mon, 20 Jan 2003 09:13:54 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnylt08506 for ; Mon, 20 Jan 2003 14:17:17 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnylt08330; Mon, 20 Jan 2003 14:17:12 GMT Received: by mail-control.ash.ops.us.uu.net id QQnylt12676 for mpls-outgoing; Mon, 20 Jan 2003 14:16:45 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnylt12670 for ; Mon, 20 Jan 2003 14:16:37 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnylt14450 for ; Mon, 20 Jan 2003 14:15:52 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnylt29244 for ; Mon, 20 Jan 2003 14:15:52 GMT Received: from mailhost.avici.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [12.38.212.174]) id QQnylt29231 for ; Mon, 20 Jan 2003 14:15:51 GMT Received: from aatlas-lt.avici.com (b2-pc95.avici.com [10.2.100.125]) by mailhost.avici.com (8.11.0/8.11.0) with ESMTP id h0KEFEG14906; Mon, 20 Jan 2003 09:15:15 -0500 (EST) Message-Id: <5.1.0.14.2.20030120085804.01fdc120@mailhost.avici.com> X-Sender: aatlas@mailhost.avici.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 20 Jan 2003 09:17:20 -0500 To: Ling Li From: Alia Atlas Subject: RE: Last Call on Fast Reroute Cc: "'mpls@UU.NET'" , Ping Pan , Jean Philippe Vasseur , Der-Hwa Gan , mjork@avici.com, dcooper@gblx.net In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Ling, Sorry for the delay in response. At 08:23 PM 12/12/2002 -0500, Ling Li wrote: >The following are my comments and questions on the draft. Your >clarifications are appreciated. --Ling > >1. The assumptions made in the draft: > 1). From Section 7: > "Therefore, an LSR which is on the path > of a protected LSP SHOULD always assume that it is a merge point" > > 2). From Section 8: > "if a DETOUR object is included in the backup LSP's path > message for the sender-template-specific method, the LSRs in the > traffic-engineered network should support the DETOUR object. > > Second, if the Path-Specific Method is to be supported for > the one-to-one backup technique, it is necessary that the LSRs in > the traffic-engineered network be capable of merging detours " > >These are very important assumptions. Could these assumptions be mentioned >in the >Introduction section to avoid confusion when reading the first several >sections? >For example, the hop-limit constraint in Section 4.1 is very confusing >without >assumption 1). How does the following paragraph sound? "For the techniques discussed in this document to function properly, there are three assumptions which must be made. First, an LSR which is on the path of a protected LSP SHOULD always assume that it is a merge point; this is necessary because the facility backup method does not signal backups through a bypass tunnel before failure. Second, if the one-to-one backup method is used and a DETOUR object is included, the LSRs in the traffic-engineered network should support the DETOUR object; this is necessary so that the Path message containing the DETOUR object is not rejected. Understanding of the DETOUR object is required to support the path-specific method which requires that LSRs in the traffic-engineered network be capable of merging detours." >Questions: >1. Is the following assumption implied by the draft: >an LSR which is on the path of a protected LSP SHOULD always assume that >it is a PLR. > >Without this assumption, the NHOP or NNHop bypass may not work as expected. >That is because NHOP bypass can only protect a downstream neighbor link. If >the downstream neighbor node is not a PLR, a failure of the remote >downstream >link is going to be propagated to the current node. If the current node >knows >that its downstream neighbor is not a PLR, it may use NNHop to protect the >neighbor node and the remote downstream links. Since the current node has no >way >to know if the downstream neighbor is PLR, I guess it is assumed. Whether an LSR can function as a PLR determines whether a potential failure condition can be quickly healed. Consider the following diagram. [R1]-------[R2]------[R3]------[R4] \ | \ / [R5]---[R6]-----------[R7] In this diagram, if R3 can not function as a PLR, if the link R3-R4 fails, there is no immediate repair possible at R3. R2 will get a PathErr and can use its backup, if it is NNHOP. Regardless of whether R2's backup is NNHOP or NHOP, the fail-over time is longer than desirable because there is signaling required from R3 to R2. Does this help answer the question? >2. I think the following statements in Section 4.2 is not needed because >of assumption 2). >"LSRs that do not support the DETOUR objects MUST reject any Path message >containing a DETOUR object and send a PathErr to notify the PLR." >If really needed, please provide Error Code and Value. Hard to imagine >anyone >will upgrade their code for not supporting a feature. This PathErr is part of RFC 2205. In Section 3.10 there, it says that for objects with an unknown class-num of the form 0bbbbbbb, "The entire message should be rejected and an "Unknown Object Class" error returned. I will add a reference to this in the draft so that the paragraph at the end of Section 4.2 reads: "The high-order bit of the C-Class is zero; LSRs that do not support the DETOUR objects MUST reject any Path message containing a DETOUR object and send a PathErr to notify the PLR. This PathErr SHOULD be generated as specified in [RSVP] for unknown objects with a class-num of the form "0bbbbbbb"." >Some general comments: >1. in Section 6.2, "For detour LSPs, the destination MUST be the tail-end of >the protected LSP". However the hop-limit constraint is "from current node >(a PLR) >to a MP". It is not easy to enhance cspf to support this constraint if >it is defined this way. I would prefer not setting constraint to MP, but to >the destination, such as what is de fined in Juniper product: >"For fast reroute, how many more routers a detour is allowed to traverse >compared >to the LSP itself" at >http://www.juniper.net/techpubs/software/junos52/swconfig52- >mpls-apps/html/mpls-summary18.html#1014333. This is equivalent. The detour will traverse from the merge point to the egress along the path of the LSP. Therefore, the additional hops are those in the detour not including the PLR or the merge point. This definition came from the initial draft describing the detour method. >2. The following statement is not very clear in Section 5: >"If node protection is desired, the head-end LSR should set the "node >protection desired" flag in the SESSION_ATTRIBUTE object; if only link >protection is desired, this flag should be cleared. " >Could it be changed to use Otherwise after the first half of the statement, >jus as >what is said for "bandwidth protection desired" flag after the statement. Sure, I'll put otherwise in there as "If node protection is desired, the head-end LSR should set the "node protection desired" flag in the SESSION_ATTRIBUTE object; otherwise (i.e. only link protection is desired), this flag should be cleared." >3. The following statement is made is Section 6: >" If the "node protection desired" flag is set, the PLR SHOULD try to > provide node protection; if this is not feasible, the PLR SHOULD > then try to provide link protection." >Can we say the same for "bandwidth protection desired" flag? >" If the "bandwidth protection desired" flag is set, the PLR SHOULD try to > provide bandwidth protection; if this is not feasible, the PLR SHOULD > set the bandwidth constraint to 0 then try to provide protection." We can certainly put in that the PLR SHOULD try to provide bandwidth protection. However, saying that the PLR should set the bandwidth constraint to 0 is, I think, not appropriate for all cases. For instance, with the facility backup, a bypass tunnel may have its bandwidth over-booked such that a bandwidth guarantee can not be provided, but that doesn't mean that the backup can't be created and may have better bandwidth protection than 0. I'll amend the paragraph as follows. "If the "node protection desired" flag is set, the PLR SHOULD try to provide node protection; if this is not feasible, the PLR SHOULD then try to provide link protection. If the "bandwidth protection guaranteed" flag is set, the PLR SHOULD try to provide a bandwidth guarantee; if this is not feasible, the PLR SHOULD then try to provide a backup without a guarantee of the full bandwidth." Does this sound ok? Thanks, Alia > > -----Original Message----- > > From: George Swallow [mailto:swallow@cisco.com] > > Sent: Tuesday, December 03, 2002 5:50 PM > > To: mpls@UU.NET > > Subject: Last Call on Fast Reroute > > > > > > This message begins a workgroup last call on: > > > > Fast Reroute Extensions to RSVP-TE for LSP Tunnels > > > > draft-ietf-mpls-rsvp-lsp-fastreroute-01.txt > > > > The last call ends on Dec 16, 2002 2400H GMT. > > > > George & Loa > > > > ====================================================================== > > George Swallow Cisco Systems (978) 497-8143 > > 250 Apollo Drive > > Chelmsford, Ma 01824 > > > > > > From owner-mpls@UU.NET Mon Jan 20 15:15:40 2003 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29435 for ; Mon, 20 Jan 2003 15:15:40 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnymr21505 for ; Mon, 20 Jan 2003 20:19:02 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnymr21322; Mon, 20 Jan 2003 20:18:57 GMT Received: by mail-control.ash.ops.us.uu.net id QQnymr00359 for mpls-outgoing; Mon, 20 Jan 2003 20:18:38 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnymr00354 for ; Mon, 20 Jan 2003 20:18:28 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnymr25501 for ; Mon, 20 Jan 2003 20:17:13 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnymr04665 for ; Mon, 20 Jan 2003 20:17:13 GMT Received: from merlot.juniper.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: natint.juniper.net [207.17.136.129]) id QQnymr04653 for ; Mon, 20 Jan 2003 20:17:12 GMT Received: from garnet.juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h0KKH2S00168; Mon, 20 Jan 2003 12:17:02 -0800 (PST) (envelope-from ina@juniper.net) Date: Mon, 20 Jan 2003 12:17:02 -0800 (PST) From: Ina Minei To: "Dhananjay S. Patki" cc: , , , , , , , , Subject: Re: ping & traceroute in MPLS VPN In-Reply-To: <003601c2c08c$78e1bed0$ba7d01d9@pcwks92> Message-ID: <20030120121308.W78721-100000@garnet.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Please check the Junos documentation at http://www.juniper.net/techpubs/software/junos/junos56/swcmdref56/html/system-mgmt-monitor16.html Ina On 20 Jan 2003, Dhananjay S. Patki wrote: > Hello, > > I would like to know if anybody has already implemented ping/traceroute > mechanisms as described in draft-ietf-mpls-lsp-ping-01.txt. If yes, I would > like to take a look at the CLI commands defined for ping and traceroute. Any > references to related documentation will be appreciated. > > Thanks, > Dhananjay > > From owner-mpls@UU.NET Tue Jan 21 04:02:55 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24047 for ; Tue, 21 Jan 2003 04:02:54 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnyoq22410 for ; Tue, 21 Jan 2003 09:06:18 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnyoq22334; Tue, 21 Jan 2003 09:06:15 GMT Received: by mail-control.ash.ops.us.uu.net id QQnyoq22346 for mpls-outgoing; Tue, 21 Jan 2003 09:05:58 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnyoq22341 for ; Tue, 21 Jan 2003 09:05:53 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnyoq18037 for ; Tue, 21 Jan 2003 09:05:39 GMT From: riza.cetin@alcatel.be Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnyoq21771 for ; Tue, 21 Jan 2003 09:05:39 GMT Received: from mail.alcatel.be by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: alc239.alcatel.be [195.207.101.239]) id QQnyoq21758 for ; Tue, 21 Jan 2003 09:05:38 GMT Received: from Bemail06.net.alcatel.be (localhost [127.0.0.1]) by mail.alcatel.be (8.10.1/8.11.4) with ESMTP id h0L95Jt17434 for ; Tue, 21 Jan 2003 10:05:19 +0100 (MET) Received: from alcatel.be ([138.203.191.132]) by Bemail06.net.alcatel.be (Lotus Domino Release 5.0.11) with ESMTP id 2003012110051607:1707 ; Tue, 21 Jan 2003 10:05:16 +0100 Message-ID: <3E2D0D4B.5916311F@alcatel.be> Date: Tue, 21 Jan 2003 10:05:15 +0100 X-Mailer: Mozilla 4.72 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: mpls@UU.NET Subject: draft-cetin-mpls-diffServ-te-mib-00.txt X-MIMETrack: Itemize by SMTP Server on BEMAIL06/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 01/21/2003 10:05:16, Serialize by Router on BEMAIL06/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 01/21/2003 10:05:18, Serialize complete at 01/21/2003 10:05:18 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi everyone, Any comments on the MPLS-DiffServ-TE MIB draft (see below). I am looking for feedback specially from those of you who have implemented DiffServ and traffic engineering for MPLS. Thanks, Riza. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-cetin-mpls-diffserv-te-mib-00.txt From owner-mpls@UU.NET Tue Jan 21 04:59:17 2003 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24719 for ; Tue, 21 Jan 2003 04:59:16 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnyou12656 for ; Tue, 21 Jan 2003 10:02:39 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnyou12250; Tue, 21 Jan 2003 10:02:26 GMT Received: by mail-control.ash.ops.us.uu.net id QQnyou07426 for mpls-outgoing; Tue, 21 Jan 2003 10:01:58 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnyou07382 for ; Tue, 21 Jan 2003 10:01:39 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnyou03595 for ; Tue, 21 Jan 2003 10:01:22 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnyou11473 for ; Tue, 21 Jan 2003 10:01:21 GMT Received: from mail2.astaro.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail.astaro.com [213.30.251.2]) id QQnyou11465 for ; Tue, 21 Jan 2003 10:01:20 GMT Received: from [192.168.2.5] (helo=exchange2.intranet.astaro.de) by mail2.astaro.com with smtp (Exim 6.66 #1) id 18av99-0006Cl-00; Tue, 21 Jan 2003 10:56:43 +0100 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: ping & traceroute in MPLS VPN X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Tue, 21 Jan 2003 10:59:53 +0100 Message-ID: <123BD96642CCDE4B83B437F2CD9F2066029A5C@exchange2.astaro.de> Thread-Topic: ping & traceroute in MPLS VPN Thread-Index: AcLAwb3Yp6o+/yfNQESTQZwUp3XjDwAcL1wA From: "Markus Hennig" To: "Ina Minei" , "Dhananjay S. Patki" Cc: , , , , , , , , X-Scanner: exiscan *18av99-0006Cl-00*n6D0DjYEEXs* on Astaro Security Linux Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id EAA24719 any other vendors with a mpls ping? markus > -----Original Message----- > From: Ina Minei [mailto:ina@juniper.net] > Sent: Monday, January 20, 2003 9:17 PM > To: Dhananjay S. Patki > Cc: mpls-ops@mplsrc.com; mpls@UU.NET; kireeti@juniper.net; > nsheth@juniper.net; ppan@ciena.com; dcooper@gblx.net; > swallow@cisco.com; > swadhwa@unispherenetworks.com; ronald.p.bonica@wcom.com > Subject: Re: ping & traceroute in MPLS VPN > > > > Please check the Junos documentation at > > http://www.juniper.net/techpubs/software/junos/junos56/swcmdref56/html/system-mgmt-monitor16.html > > Ina > >On 20 Jan 2003, Dhananjay S. Patki wrote: > > Hello, > > I would like to know if anybody has already implemented ping/traceroute > mechanisms as described in draft-ietf-mpls-lsp-ping-01.txt. If yes, I would > like to take a look at the CLI commands defined for ping and traceroute. Any > references to related documentation will be appreciated. > > Thanks, > Dhananjay > > From owner-mpls@UU.NET Tue Jan 21 07:52:03 2003 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27451 for ; Tue, 21 Jan 2003 07:51:58 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnypf25729 for ; Tue, 21 Jan 2003 12:55:13 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnypf25536; Tue, 21 Jan 2003 12:55:07 GMT Received: by mail-control.ash.ops.us.uu.net id QQnypf05312 for mpls-outgoing; Tue, 21 Jan 2003 12:54:55 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnypf05303 for ; Tue, 21 Jan 2003 12:54:50 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnypf04804 for ; Tue, 21 Jan 2003 12:54:12 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnypf12104 for ; Tue, 21 Jan 2003 12:54:11 GMT Received: from relay1.clb.oleane.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: relay1.clb.oleane.net [213.56.31.21]) id QQnypf12094 for ; Tue, 21 Jan 2003 12:54:11 GMT Received: from oleane ([194.250.212.114]) by relay1.clb.oleane.net with SMTP id h0LCs97T028210 for ; Tue, 21 Jan 2003 13:54:10 +0100 Message-ID: <030501c2c14c$44f86540$0601a8c0@oleane.com> From: "Peter Lewis" To: Subject: MPLS World Congress 03 Date: Tue, 21 Jan 2003 13:54:43 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0302_01C2C154.A67208A0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0302_01C2C154.A67208A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable CONFERENCE - EXHIBITION - INTEROPERABILITY EVENT Already 400 participants have decided to attend MPLS World 2003 Congress = 03. Registration is still open at: http://www.upperside.fr/mplswc2003/mplswc03earlyreg.htm=20 The exhibition is a large success with 30% more companies compared to = the 2002 edition.=20 The brand new event for this 2003 edition is the multivendor = interoperability platform organized by the MPLS Forum and EANTC, in = cooperation with the ETSI Interoperability Service. 14 vendors will = demonstrate their ability to interoperate VPNs and Fast Rerouting = mechanisms.=20 Above all, more than 45 key speakers will bring them all the necessary = information in order to succeed their MPLS network roll-out.=20 Upper Side would again like to thank the members of the scientific = community for the invaluable help they have lent in putting together the = program for 2003. More details at: http://www.upperside.fr/mplswc2003/mplswc03intro.htm=20 ------=_NextPart_000_0302_01C2C154.A67208A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

CONFERENCE - = EXHIBITION -=20 INTEROPERABILITY EVENT

Already 400 participants = have=20 decided to attend MPLS World 2003 Congress = 03.=20 Registration is still open at:
http://w= ww.upperside.fr/mplswc2003/mplswc03earlyreg.htm=20

The exhibition is a large success with 30% more companies = compared to the 2002 edition.

The brand new event for this 2003 = edition=20 is the multivendor interoperability platform organized by the = MPLS Forum=20 and EANTC, in cooperation with the ETSI Interoperability Service. 14=20 vendors will demonstrate their ability to interoperate VPNs and = Fast=20 Rerouting mechanisms.

Above all, more than 45 key = speakers=20 will bring them all the necessary information in order to succeed their = MPLS=20 network roll-out.
Upper Side would again like to thank the members = of the=20 scientific community for the invaluable help they have lent in putting = together=20 the program for 2003.

More details at: http://www.= upperside.fr/mplswc2003/mplswc03intro.htm=20
 
------=_NextPart_000_0302_01C2C154.A67208A0-- From owner-mpls@UU.NET Tue Jan 21 10:23:05 2003 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02250 for ; Tue, 21 Jan 2003 10:23:05 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnypp05722 for ; Tue, 21 Jan 2003 15:26:28 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnypp05569; Tue, 21 Jan 2003 15:26:23 GMT Received: by mail-control.ash.ops.us.uu.net id QQnypp12784 for mpls-outgoing; Tue, 21 Jan 2003 15:25:57 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnypp12774 for ; Tue, 21 Jan 2003 15:25:48 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnypp13360 for ; Tue, 21 Jan 2003 15:25:12 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnypp22922 for ; Tue, 21 Jan 2003 15:25:12 GMT Received: from rtp-msg-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-msg-core-1.cisco.com [161.44.11.97]) id QQnypp22912 for ; Tue, 21 Jan 2003 15:25:11 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id h0LFPuXR022619 for ; Tue, 21 Jan 2003 10:25:56 -0500 (EST) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA28290 for ; Tue, 21 Jan 2003 10:25:09 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h0LFP9h11448 for mpls@uu.net; Tue, 21 Jan 2003 10:25:09 -0500 (EST) Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnymi04771 for ; Mon, 20 Jan 2003 18:01:38 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnymi16754 for ; Mon, 20 Jan 2003 18:01:23 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnymi15615 for ; Mon, 20 Jan 2003 18:01:23 GMT Received: from web41012.mail.yahoo.com by cmr1.ash.ops.us.uu.net with SMTP (peer crosschecked as: web41012.mail.yahoo.com [66.218.93.11]) id QQnymi15607 for ; Mon, 20 Jan 2003 18:01:22 GMT Message-ID: <20030120180121.37533.qmail@web41012.mail.yahoo.com> Received: from [65.241.132.122] by web41012.mail.yahoo.com via HTTP; Mon, 20 Jan 2003 10:01:21 PST Date: Mon, 20 Jan 2003 10:01:21 -0800 (PST) From: Gopalkrishna Panicker Subject: LSP preemption To: mpls@UU.NET MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Hi, I have a couple of questions on the setup/holding priority and its use in RSVP-TE. Consider the following network A-----B-------C--------D | | |-------E--------| Assume for a given session (Sess1) we have two senders S1(ero = ABCD) and S2(ero = ABED). Say SE style is used. Now assume another session (Sess2) is being set up from A to D with a sender S3(ero=ABED). During the session (Sess2) setup node B discovers that bandwidth on the link BE is insufficient. If Sess2 has a higher priority (determined after appropriate validation of both setup and holding pri) will it result in both senders (S1 and S2) of Sess1 being bumped or will only S2 get bumped ? >From the mailing list I gather that there are benefits to associating setup and holding priority to a LSP. If they are maintained on a per LSP basis, then can one LSP bump another from the same session ? Thanks Cheers, Gopal __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com From owner-mpls@UU.NET Tue Jan 21 10:23:11 2003 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02265 for ; Tue, 21 Jan 2003 10:23:11 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnypp11427 for ; Tue, 21 Jan 2003 15:26:32 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnypp11234; Tue, 21 Jan 2003 15:26:26 GMT Received: by mail-control.ash.ops.us.uu.net id QQnypp12789 for mpls-outgoing; Tue, 21 Jan 2003 15:25:59 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnypp12776 for ; Tue, 21 Jan 2003 15:25:52 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnypp12459 for ; Tue, 21 Jan 2003 15:24:28 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnypp22523 for ; Tue, 21 Jan 2003 15:24:28 GMT Received: from rtp-msg-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-msg-core-1.cisco.com [161.44.11.97]) id QQnypp22484 for ; Tue, 21 Jan 2003 15:24:23 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id h0LFP8uJ022466 for ; Tue, 21 Jan 2003 10:25:08 -0500 (EST) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA28242 for ; Tue, 21 Jan 2003 10:24:21 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h0LFOLG11368 for mpls@uu.net; Tue, 21 Jan 2003 10:24:21 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnybg16514 for ; Fri, 17 Jan 2003 18:02:34 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnybf08013 for ; Fri, 17 Jan 2003 17:54:41 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnybf14958 for ; Fri, 17 Jan 2003 17:54:40 GMT Received: from gamma.isi.edu by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: gamma.isi.edu [128.9.144.145]) id QQnybf14948 for ; Fri, 17 Jan 2003 17:54:39 GMT Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id h0HHsbD22490; Fri, 17 Jan 2003 09:54:37 -0800 (PST) Message-Id: <200301171754.h0HHsbD22490@gamma.isi.edu> To: IETF-Announce:; Subject: RFC 3443 on Time To Live (TTL) Processing in Multi-Protocol Label Switching (MPLS) Networks Cc: rfc-editor@rfc-editor.org, mpls@UU.NET From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Fri, 17 Jan 2003 09:54:36 -0800 Sender: owner-mpls@UU.NET Precedence: bulk --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3443 Title: Time To Live (TTL) Processing in Multi-Protocol Label Switching (MPLS) Networks Author(s): P. Agarwal, B. Akyol Status: Standards Track Date: January 2003 Mailbox: puneet@acm.org, bora@cisco.com Pages: 10 Characters: 18749 Updates: 3032 I-D Tag: draft-ietf-mpls-ttl-04.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3443.txt This document describes Time To Live (TTL) processing in hierarchical Multi-Protocol Label Switching (MPLS) networks and is motivated by the need to formalize a TTL-transparent mode of operation for an MPLS label-switched path. It updates RFC 3032, "MPLS Label Stack Encoding". TTL processing in both Pipe and Uniform Model hierarchical tunnels are specified with examples for both "push" and "pop" cases. The document also complements RFC 3270, "MPLS Support of Differentiated Services" and ties together the terminology introduced in that document with TTL processing in hierarchical MPLS networks. This document is a product of the Multiprotocol Label Switching Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <030117095226.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3443 --OtherAccess Content-Type: Message/External-body; name="rfc3443.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <030117095226.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Wed Jan 22 16:39:41 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08233 for ; Wed, 22 Jan 2003 16:39:40 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnyug23828 for ; Wed, 22 Jan 2003 21:43:02 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnyug23461; Wed, 22 Jan 2003 21:42:51 GMT Received: by mail-control.ash.ops.us.uu.net id QQnyug04454 for mpls-outgoing; Wed, 22 Jan 2003 21:42:40 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnyug04449 for ; Wed, 22 Jan 2003 21:42:38 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnyug00137 for ; Wed, 22 Jan 2003 21:42:13 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnyug07378 for ; Wed, 22 Jan 2003 21:42:12 GMT Received: from rtp-msg-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-msg-core-1.cisco.com [161.44.11.97]) id QQnyug07251 for ; Wed, 22 Jan 2003 21:42:08 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id h0MLgrlx015628 for ; Wed, 22 Jan 2003 16:42:54 -0500 (EST) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id QAA20349 for ; Wed, 22 Jan 2003 16:42:06 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h0MLg5c08785 for mpls@uu.net; Wed, 22 Jan 2003 16:42:05 -0500 (EST) Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnyug04249 for ; Wed, 22 Jan 2003 21:40:46 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnyug14970 for ; Wed, 22 Jan 2003 21:40:23 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnyug05471 for ; Wed, 22 Jan 2003 21:40:22 GMT Received: from tnt.isi.edu by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: tnt.isi.edu [128.9.128.128]) id QQnyug05462 for ; Wed, 22 Jan 2003 21:40:22 GMT Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id h0MLeCb19161; Wed, 22 Jan 2003 13:40:12 -0800 (PST) From: Bob Braden Received: (from braden@localhost) by gra.isi.edu (8.8.7/8.8.6) id VAA00937; Wed, 22 Jan 2003 21:40:12 GMT Date: Wed, 22 Jan 2003 21:40:12 GMT Message-Id: <200301222140.VAA00937@gra.isi.edu> To: rsvp@ISI.EDU Subject: IANA Considerations for RSVP Cc: ccamp@ops.ietf.org, mpls@UU.NET, kireeti@juniper.net, braden@ISI.EDU, iana@ISI.EDU, sob@harvard.edu, mankin@psg.com, bwijnen@lucent.com X-Sun-Charset: US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Hardy friends who have stuck it out on the RSVP mailing list: There is a growing unease about IANA assignments of RSVP parameters -- object numbers, CTypes, message types, and error numbers -- for new uses of RSVP. Many of these IANA requests, but not all, originate outside the IETF in other standards bodies. Many of the people from outside the IETF were not part of the RSVP working group and so did not absorb the technical rationale behind RSVP; in fact, they are sometimes barely clued into IETF procedures at all. As a sample, here is a part of a recent message from Kireeti Kompella, co-chair of the CCAMP working group: "The problem I am trying to address is that folks are changing the RSVP spec with *Informational* documents that bypass much of the checks we have. For example, the "GMPLS RSVP-TE for ASON" draft-lin-ccamp-gmpls-ason-rsvpte-04.txt defines new objects for the purpose of "call and connection separation". I don't see any reason for such separation; even in the ITU (where this comes from), there is not a clear consensus that this is needed. However, this document breezed through the IETF "process". Furthermore, it is an *Informational* document. If this really was useful, and someone were to extend this, their document would have to be Informational by normative reference transitivity. The worst part of this is that the base protocols (RSVP, RSVP-TE and RSVP-TE for GMPLS) were IETF protocols -- and then this piece has been usurped by the ITU (where the standards track documents will be defined). What I would like to see is the bulk of each space (messages, objects, class types, etc) being Standards Action, with some space for FCFS and Private Use." This raises a bunch of technical and procedural questions; I will address some of the latter below. Several points should be made. 1. I volunteered several years ago to serve as the "designated expert" for RSVP registrations (RFC 2434), so every RSVP reservation request is referred to me. (Given the amount of recent aggrevation, this may not have been too wise a move for me.) 2. Just before the RSVP WG went dormant, its cochairs put together an IANA Considerations document and published it as an I-D. I believe that it went through a formal WG last call; at least, the WG was given an opporunity to comment on, or object to, it. It did not become an RFC, but it is available on the RSVP web site. (I recently moved it to a more prominent spot in www.isi.edu/rsvp/pub.html). As the designated expert, I follow the rules in that draft. 3. The IANA Considerations draft should be published as an RFC, perhaps after updating. Here are some issues that might affect this update. (A) How to handle requests for RSVP assignments for extensions developed outside IETF? Here is my suggestion: For all assignments of numbers for extensions defined in non-IETF standards bodies, the IANA should use assignment names (e.g., object names) that are prefixed with the name of the responsible standards body. For example, the "SPIFFY_SESSION" object would become "ATM_FORUM_SPIFFY_SESSION" or "ITU-T_SPIFFY_SESSION", etc., object. (B) What policies should be imposed? The document currently divides the assignment space into two subspaces, for "IETF Consensus" and "FCFS". RFC 2434 lists various other possibilities; do we need any? Precisely what do we mean by IETF consensus? Does this require a standards-track document? (We thought it did.) We assumed that non-IETF requests would necessarily go to FCFS, but is it really FCFS + expert opinion? In other words, how much oversight should we try to exert for non-IETF RSVP extensions? I have seen some highly questionable extensions. They tend to be micro-engineering, with no sense of a larger design. (C) What are the appropriate documentation requirements? Must there be an Internet Draft? An RFC? We have tended towards the RFC, but the result is less than satisfactory. These extensions are typically documented in some 373- page document published (or more often hidden) by the other standards body. The I-D/RFC that is written for registration presents only a superficial summary of the data structures to be defined, with no context of explanation, and a reference to the real 373 page document. Bob Braden Former co-chair of the RSVP WG Current designated expert for RSVP assignments by IANA ----- End Included Message ----- From owner-mpls@UU.NET Thu Jan 23 03:40:31 2003 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00266 for ; Thu, 23 Jan 2003 03:40:31 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnyvy11073 for ; Thu, 23 Jan 2003 08:43:54 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnyvy10270; Thu, 23 Jan 2003 08:43:31 GMT Received: by mail-control.ash.ops.us.uu.net id QQnyvy14459 for mpls-outgoing; Thu, 23 Jan 2003 08:43:03 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnyvy14452 for ; Thu, 23 Jan 2003 08:42:46 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnyvy12977 for ; Thu, 23 Jan 2003 08:41:56 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnyvy08602 for ; Thu, 23 Jan 2003 08:41:55 GMT Received: from tama5.ecl.ntt.co.jp by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: tama5.ecl.ntt.co.jp [129.60.39.102]) id QQnyvy08572 for ; Thu, 23 Jan 2003 08:41:54 GMT Received: from vcs3.rdh.ecl.ntt.co.jp (vcs3.rdh.ecl.ntt.co.jp [129.60.39.110]) by tama5.ecl.ntt.co.jp (8.9.3+3.2W/3.7W/10/21/02) with ESMTP id RAA26865 for ; Thu, 23 Jan 2003 17:41:37 +0900 (JST) (envelope-from yasukawa.seisho@lab.ntt.co.jp) Received: from nttmail3.ecl.ntt.co.jp ([127.0.0.1]) by vcs3.rdh.ecl.ntt.co.jp (8.12.6/8.12.6) with ESMTP id h0N8faOO029797 for ; Thu, 23 Jan 2003 17:41:37 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (eclscan3.m.ecl.ntt.co.jp [129.60.5.69]) by nttmail3.ecl.ntt.co.jp (8.12.6/8.12.6) with ESMTP id h0N8faFb010834 for ; Thu, 23 Jan 2003 17:41:36 +0900 (JST) Received: from imc.m.ecl.ntt.co.jp (localhost [127.0.0.1]) by eclscan3.m.ecl.ntt.co.jp (8.9.3/3.7W) with ESMTP id RAA18639; Thu, 23 Jan 2003 17:41:35 +0900 (JST) Received: from barrister.lab.ntt.co.jp by imc.m.ecl.ntt.co.jp (8.9.3/3.7W) with ESMTP id RAA28305; Thu, 23 Jan 2003 17:41:35 +0900 (JST) Message-Id: <5.0.2.5.2.20030123124146.04f7a6d8@imc.m.ecl.ntt.co.jp> X-Sender: sy003@imc.m.ecl.ntt.co.jp X-Mailer: QUALCOMM Windows Eudora Version 5.0.2-J Date: Thu, 23 Jan 2003 17:44:49 +0900 To: "'mpls@UU.NET'" From: Seisho Yasukawa Subject: draft-yasukawa-mpls-rsvp-p2mp-00.txt Cc: yasukawa.seisho@lab.ntt.co.jp Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Hello everyone, Please note that the following draft has been newly posted to MPLS WG. Extended RSVP-TE for Point-to-Multipoint LSP Tunnels A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-yasukawa-mpls-rsvp-p2mp-00.txt This draft specifies the extension to RSVP-TE signaling protocol in support of MPLS P2MP LSP creation/deletion and Leaf initiated Join/Leave signaling. We think P2MP MPLS technology will become increasingly important with the dissemination of new, real-time application, such as content delivery services and video conference, which require P2MP real-time transmission capability with much more bandwidth and stricter QoS control mechanism than conventional IP application. We NTT as a service provider really needs this kind of P2MP MPLS technology because this technology opens the possibility to offer our customer a new broadband service. We think discussion of P2MP technology agrees with the charter of this wg. And, we found that applications of "multicast explicit routing"are a target topic for "RSVP-TE "(RFC3209, Section 4.3.1) and "IP Multicast in a MPLS Environment"(RFC3353, Section.7) Therefore, we want to discuss this P2MP MPLS technology in this wg. Please give us any comments from technology, application and operation sides. We need a lot of discussion and advice for protocol architecture to improve this architecture. Thanks Seisho ------------------------------------------------------------ Please refere followings (contents of this draft). This draft include the contents of "draft-yasukawa-mpls-rsvp-p2mp-01". In this new draft, protocol architecture is modified and the protocol name was changed from "multicast" to "P2MP" to clarify the technology difference. Section 0 describes why this draft suit to this wg. Please see sec.0.4 to know the reason why we introduce P2MP tunnel without IP multicast. Section 4 describes the architecture of this protocol. The new concepts; P2MP LSP tunnel and TERO/TRRO are newly introduced. The TERO is main architecture to realize P2MP TE LSP. Section 5 - 7 describes the detailed signaling mechanisms. Section 11 shows the difference between RSVP multicasting and P2MP TE tunnels. We describe the difference between multicast LSP realized by RSVP-TE&IP multicasting and P2MP TE LSP realized by TERO. --------------------------------------------------------------- From owner-mpls@UU.NET Thu Jan 23 10:55:34 2003 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11001 for ; Thu, 23 Jan 2003 10:55:34 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnyxb28664 for ; Thu, 23 Jan 2003 15:59:00 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnyxb28478; Thu, 23 Jan 2003 15:58:55 GMT Received: by mail-control.ash.ops.us.uu.net id QQnyxb25695 for mpls-outgoing; Thu, 23 Jan 2003 15:58:27 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnyxb25690 for ; Thu, 23 Jan 2003 15:58:11 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnyxb29919 for ; Thu, 23 Jan 2003 15:56:07 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnyxb08770 for ; Thu, 23 Jan 2003 15:56:07 GMT Received: from mailgate.pit.comms.marconi.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6]) id QQnyxb08757 for ; Thu, 23 Jan 2003 15:56:07 GMT Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA03027; Thu, 23 Jan 2003 10:55:15 -0500 (EST) Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA12810; Thu, 23 Jan 2003 10:55:14 -0500 (EST) Message-ID: <3E301086.3000002@marconi.com> Date: Thu, 23 Jan 2003 10:55:50 -0500 From: David Charlap Organization: Marconi, Vienna VA User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en, he MIME-Version: 1.0 To: Bob Braden CC: rsvp@ISI.EDU, ccamp@ops.ietf.org, mpls@UU.NET, kireeti@juniper.net, iana@ISI.EDU, sob@harvard.edu, mankin@psg.com, bwijnen@lucent.com Subject: Re: IANA Considerations for RSVP References: <200301222140.VAA00937@gra.isi.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Bob Braden wrote: > > There is a growing unease about IANA assignments of RSVP parameters -- > object numbers, CTypes, message types, and error numbers -- for new > uses of RSVP. Many of these IANA requests, but not all, originate > outside the IETF in other standards bodies. Many of the people from > outside the IETF were not part of the RSVP working group and so did not > absorb the technical rationale behind RSVP; in fact, they are sometimes > barely clued into IETF procedures at all. I've noticed the same thing. It seems that many non-IETF groups want to use RSVP, and all believe that they must create extensions to the protocol for their features, often without first bothering to check if there are already obects defined by IETF standards that already serve their purposes. And even in those cases where new objects may be required, the proposed objects are often defined as having semantics that differ greatly from the way RSVP usually operates. In other words, these groups seem to want to forcibly change RSVP into a protocol that more closely resembles some other protocol that they're more intimately familiar with. Personally, I don't like this. These groups should step back and decide if RSVP is really what they need. If they require a different protocol, then they should use a different protocol - they should not glom onto RSVP just because it's popular in MPLS and then try to change it into what they really want. This is especially true in those situations where their proposed changes would produce a fundamentally incompatible protocol. Unfortunately, I don't know what can be done about this. These groups seem hell-bent on hacking up RSVP without first learning it's design philosophy. If they don't get assignments from IANA, they'll probably just make their own assignments without any coordinating facility, and we'll wind up with several mutually incompatible protocols that all want to call themselves "RSVP". -- David From owner-mpls@UU.NET Thu Jan 23 11:05:45 2003 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11381 for ; Thu, 23 Jan 2003 11:05:44 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnyxc15769 for ; Thu, 23 Jan 2003 16:09:10 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnyxc15401; Thu, 23 Jan 2003 16:08:58 GMT Received: by mail-control.ash.ops.us.uu.net id QQnyxc14305 for mpls-outgoing; Thu, 23 Jan 2003 16:08:33 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnyxc14260 for ; Thu, 23 Jan 2003 16:08:17 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnyxc09369 for ; Thu, 23 Jan 2003 16:06:55 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnyxc08537 for ; Thu, 23 Jan 2003 16:06:54 GMT Received: from mailserv.hatterasnetworks.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailserv.hatterasnetworks.com [63.89.58.4]) id QQnyxc08503 for ; Thu, 23 Jan 2003 16:06:54 GMT X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: IANA Considerations for RSVP Date: Thu, 23 Jan 2003 11:06:53 -0500 Message-ID: <8052E2EA753D144EB906B7A7AA3997140B4899@mailserv.hatteras.com> Thread-Topic: IANA Considerations for RSVP Thread-Index: AcLC+OcbwxgKzZ6bT1yvaa9ntdugvgAAEKRg From: "Brian Hassink" To: "David Charlap" , "Bob Braden" Cc: , , , , , , , Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA11381 Didn't the IETF set the precedent by extending RSVP from an IntServ protocol to an MPLS protocol? CR-LDP exists as a purpose built alternative, but vendor politics resulted in the above precedent. Just my opinion. Cheers, Brian -----Original Message----- From: David Charlap [mailto:David.Charlap@marconi.com] Sent: Thursday, January 23, 2003 10:56 AM To: Bob Braden Cc: rsvp@ISI.EDU; ccamp@ops.ietf.org; mpls@UU.NET; kireeti@juniper.net; iana@ISI.EDU; sob@harvard.edu; mankin@psg.com; bwijnen@lucent.com Subject: Re: IANA Considerations for RSVP Bob Braden wrote: > > There is a growing unease about IANA assignments of RSVP parameters -- > object numbers, CTypes, message types, and error numbers -- for new > uses of RSVP. Many of these IANA requests, but not all, originate > outside the IETF in other standards bodies. Many of the people from > outside the IETF were not part of the RSVP working group and so did not > absorb the technical rationale behind RSVP; in fact, they are sometimes > barely clued into IETF procedures at all. I've noticed the same thing. It seems that many non-IETF groups want to use RSVP, and all believe that they must create extensions to the protocol for their features, often without first bothering to check if there are already obects defined by IETF standards that already serve their purposes. And even in those cases where new objects may be required, the proposed objects are often defined as having semantics that differ greatly from the way RSVP usually operates. In other words, these groups seem to want to forcibly change RSVP into a protocol that more closely resembles some other protocol that they're more intimately familiar with. Personally, I don't like this. These groups should step back and decide if RSVP is really what they need. If they require a different protocol, then they should use a different protocol - they should not glom onto RSVP just because it's popular in MPLS and then try to change it into what they really want. This is especially true in those situations where their proposed changes would produce a fundamentally incompatible protocol. Unfortunately, I don't know what can be done about this. These groups seem hell-bent on hacking up RSVP without first learning it's design philosophy. If they don't get assignments from IANA, they'll probably just make their own assignments without any coordinating facility, and we'll wind up with several mutually incompatible protocols that all want to call themselves "RSVP". -- David From owner-mpls@UU.NET Thu Jan 23 11:14:46 2003 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11846 for ; Thu, 23 Jan 2003 11:14:45 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnyxd22040 for ; Thu, 23 Jan 2003 16:18:11 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnyxd21800; Thu, 23 Jan 2003 16:18:04 GMT Received: by mail-control.ash.ops.us.uu.net id QQnyxd15917 for mpls-outgoing; Thu, 23 Jan 2003 16:17:49 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnyxd15912 for ; Thu, 23 Jan 2003 16:17:39 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnyxd01508 for ; Thu, 23 Jan 2003 16:15:37 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnyxd27509 for ; Thu, 23 Jan 2003 16:15:36 GMT Received: from mailgate.pit.comms.marconi.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6]) id QQnyxd27503 for ; Thu, 23 Jan 2003 16:15:35 GMT Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA04385; Thu, 23 Jan 2003 11:14:45 -0500 (EST) Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA17186; Thu, 23 Jan 2003 11:14:45 -0500 (EST) Message-ID: <3E301519.4010807@marconi.com> Date: Thu, 23 Jan 2003 11:15:21 -0500 From: David Charlap Organization: Marconi, Vienna VA User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en, he MIME-Version: 1.0 To: Brian Hassink CC: Bob Braden , rsvp@ISI.EDU, ccamp@ops.ietf.org, mpls@UU.NET, kireeti@juniper.net, iana@ISI.EDU, sob@harvard.edu, mankin@psg.com, bwijnen@lucent.com Subject: Re: IANA Considerations for RSVP References: <8052E2EA753D144EB906B7A7AA3997140B4899@mailserv.hatteras.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Brian Hassink wrote: > Didn't the IETF set the precedent by extending RSVP from an IntServ protocol to an MPLS protocol? There's a big difference. MPLS and IntServ are both IETF groups. (And RSVP has/had its own working group anyway). Also, most of the key RSVP people were involved in the development of RSVP-TE. This is very different from what I'm describing - where people who have no prior RSVP experience decide that they can start changing it without understing it, and without even notifying the IETF groups that did all of the development work. I'mnot saying that RSVP should never be extended. I'm saying that those groups that are writing extensions should be consulting with those who have been developing and maintaining it (in the RSVP and MPLS groups) in order to ensure that: - Their goal can't be achieved without extending the language - That their extension doesn't overlap a similar extension from somebody else. - That their extension doesn't significantly change the overall semantics of RSVP. - That their extension is sufficiently flexible so that other groups can build off of it instead of re-inventing the wheel with yet another incompatible extension. Not only isn't this happening, but there appears to be no desire to see this happen. -- David From owner-mpls@UU.NET Thu Jan 23 11:31:33 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12345 for ; Thu, 23 Jan 2003 11:31:32 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnyxe13924 for ; Thu, 23 Jan 2003 16:34:59 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnyxe13813; Thu, 23 Jan 2003 16:34:56 GMT Received: by mail-control.ash.ops.us.uu.net id QQnyxe16927 for mpls-outgoing; Thu, 23 Jan 2003 16:34:31 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnyxe16922 for ; Thu, 23 Jan 2003 16:34:29 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnyxe29422 for ; Thu, 23 Jan 2003 16:33:18 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnyxe12593 for ; Thu, 23 Jan 2003 16:33:18 GMT Received: from fed1mtao03.cox.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: fed1mtao03.cox.net [68.6.19.242]) id QQnyxe12579 for ; Thu, 23 Jan 2003 16:33:17 GMT Received: from ieee.org ([68.6.114.234]) by fed1mtao03.cox.net (InterMail vM.5.01.04.05 201-253-122-122-105-20011231) with ESMTP id <20030123163315.JJVC29396.fed1mtao03.cox.net@ieee.org>; Thu, 23 Jan 2003 11:33:15 -0500 Message-ID: <3E30194A.8040001@ieee.org> Date: Thu, 23 Jan 2003 08:33:14 -0800 From: Jonathan Lang Reply-To: jplang@ieee.org User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: jplang@ieee.org CC: mpls@UU.NET, kireeti@juniper.net, iana@ISI.EDU, sob@harvard.edu, mankin@psg.com, bwijnen@lucent.com Subject: Re: IANA Considerations for RSVP References: <200301222140.VAA00937@gra.isi.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Bob, Bob Braden wrote: >Hardy friends who have stuck it out on the RSVP mailing list: > > > 3. The IANA Considerations draft should be published as an RFC, > perhaps after updating. Here are some issues that might affect > this update. > I concur. There needs to be an IANA Considerations draft published as an RFC. > > (A) How to handle requests for RSVP assignments for > extensions developed outside IETF? > > Here is my suggestion: > > For all assignments of numbers for extensions defined > in non-IETF standards bodies, the IANA should use > assignment names (e.g., object names) that are prefixed > with the name of the responsible standards body. For > example, the "SPIFFY_SESSION" object would become > "ATM_FORUM_SPIFFY_SESSION" or "ITU-T_SPIFFY_SESSION", > etc., object. > This is fine, but I'm not sure it's enough. For example, the following text came from an email posted on the ietf discussion list by Zhi, the editor of "draft-lin-ccamp-gmpls-ason-rsvpte-04.txt", in response to a debate about this very issue. Last time I checked, the IETF didn't change the protocols, individuals did through contributions. The extensions requested for Call/Connection control were submitted by an individual. The fact the ITU weighed in requesting approval of the changes is a separate issue. So if this was an individual contribution, then it wouldn't be tagged "ITU-T_SPIFFY_SESSION"? > > (B) What policies should be imposed? > > The document currently divides the assignment space into > two subspaces, for "IETF Consensus" and "FCFS". RFC > 2434 lists various other possibilities; do we need any? > > Precisely what do we mean by IETF consensus? Does this > require a standards-track document? (We thought it did.) > > We assumed that non-IETF requests would necessarily go to > FCFS, but is it really FCFS + expert opinion? In other > words, how much oversight should we try to exert for > non-IETF RSVP extensions? I have seen some highly > questionable extensions. They tend to be micro-engineering, > with no sense of a larger design. > I would prefer that the majority of the assignments require standards-track documents. A few assignments could be left for "IETF Consensus", which I don't think requires standards track ID. And then a few assignements for "experimental". Thanks, Jonathan > > (C) What are the appropriate documentation requirements? > > Must there be an Internet Draft? An RFC? We have > tended towards the RFC, but the result is less than > satisfactory. These extensions are typically > documented in some 373- page document published (or > more often hidden) by the other standards body. The > I-D/RFC that is written for registration presents only > a superficial summary of the data structures to be > defined, with no context of explanation, and a > reference to the real 373 page document. > >Bob Braden >Former co-chair of the RSVP WG >Current designated expert for RSVP assignments by IANA > > > >----- End Included Message ----- > > > > From owner-mpls@UU.NET Thu Jan 23 11:32:26 2003 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12376 for ; Thu, 23 Jan 2003 11:32:25 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnyxe16659 for ; Thu, 23 Jan 2003 16:35:51 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnyxe16431; Thu, 23 Jan 2003 16:35:44 GMT Received: by mail-control.ash.ops.us.uu.net id QQnyxe16954 for mpls-outgoing; Thu, 23 Jan 2003 16:35:12 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnyxe16945 for ; Thu, 23 Jan 2003 16:34:56 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnyxe22663 for ; Thu, 23 Jan 2003 16:34:05 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnyxe13152 for ; Thu, 23 Jan 2003 16:34:04 GMT Received: from rtp-msg-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-msg-core-1.cisco.com [161.44.11.97]) id QQnyxe13146 for ; Thu, 23 Jan 2003 16:34:04 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h0NGYoJr021197 for ; Thu, 23 Jan 2003 11:34:50 -0500 (EST) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id LAA19448 for ; Thu, 23 Jan 2003 11:34:02 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h0NGY2m13899 for mpls@uu.net; Thu, 23 Jan 2003 11:34:02 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnyxe16880 for ; Thu, 23 Jan 2003 16:33:19 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnyxe19127 for ; Thu, 23 Jan 2003 16:32:05 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnyxe12918 for ; Thu, 23 Jan 2003 16:32:04 GMT Received: from ihemail2.firewall.lucent.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ihemail2.lucent.com [192.11.222.163]) id QQnyxe12901 for ; Thu, 23 Jan 2003 16:32:04 GMT Received: from nj7460exch002h.wins.lucent.com (h135-17-42-35.lucent.com [135.17.42.35]) by ihemail2.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id h0NGW2s15536 for ; Thu, 23 Jan 2003 11:32:03 -0500 (EST) Received: by nj7460exch002h.ho.lucent.com with Internet Mail Service (5.5.2653.19) id ; Thu, 23 Jan 2003 11:32:02 -0500 Message-ID: From: "Lin, Zhi-Wei (Zhi)" To: David Charlap , Bob Braden Cc: rsvp@ISI.EDU, ccamp@ops.ietf.org, mpls@UU.NET, kireeti@juniper.net, iana@ISI.EDU, sob@harvard.edu, mankin@psg.com, bwijnen@lucent.com Subject: RE: IANA Considerations for RSVP Date: Thu, 23 Jan 2003 11:31:59 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Hi David, This seems like an unfair characterization. All requests are submitted by individuals. In terms of changing these protocols... The GMPLS RSVP-TE, which is done in IETF, makes major modifications to RFC3209 and RFC2205 version of RSVP. The rest of the changes been requested are three new objects, new error codes to support these objects. This can hardly be characterized as forcibly changing RSVP or major change in direction... The extensions that's been requested were derived as a result of discussions and efforts involving many IETF people as well (e.g., please look at the author list of the OIF UNI document). Your comment seems to suggest that the work appear out of nowhere with no participation from the IETF RSVP experts...this is clearly not true... If you recall, throughout the development of the GMPLS RSVP-TE, the non-RSVP experts (I guess you would lump me in this category as well) provided major comments. As a non-RSVP expert, I tried my best to understand the original goal of RSVP; however, I did not make the initial decision to use RSVP for supporting control plane for transport network. This decision was made collectively by the sub-IP area and thus the GMPLS RSVP was born... But I think much of this is simply related to the current (lack of) process and procedural issues. These can be dealt with (possibly) at the next meeting, and a clear process should be put in place on how IETF would work with other standards organizations. But this is for the future... Zhi -----Original Message----- From: David Charlap [mailto:David.Charlap@marconi.com] Sent: Thursday, January 23, 2003 10:56 AM To: Bob Braden Cc: rsvp@ISI.EDU; ccamp@ops.ietf.org; mpls@UU.NET; kireeti@juniper.net; iana@ISI.EDU; sob@harvard.edu; mankin@psg.com; bwijnen@lucent.com Subject: Re: IANA Considerations for RSVP Bob Braden wrote: > > There is a growing unease about IANA assignments of RSVP parameters -- > object numbers, CTypes, message types, and error numbers -- for new > uses of RSVP. Many of these IANA requests, but not all, originate > outside the IETF in other standards bodies. Many of the people from > outside the IETF were not part of the RSVP working group and so did not > absorb the technical rationale behind RSVP; in fact, they are sometimes > barely clued into IETF procedures at all. I've noticed the same thing. It seems that many non-IETF groups want to use RSVP, and all believe that they must create extensions to the protocol for their features, often without first bothering to check if there are already obects defined by IETF standards that already serve their purposes. And even in those cases where new objects may be required, the proposed objects are often defined as having semantics that differ greatly from the way RSVP usually operates. In other words, these groups seem to want to forcibly change RSVP into a protocol that more closely resembles some other protocol that they're more intimately familiar with. Personally, I don't like this. These groups should step back and decide if RSVP is really what they need. If they require a different protocol, then they should use a different protocol - they should not glom onto RSVP just because it's popular in MPLS and then try to change it into what they really want. This is especially true in those situations where their proposed changes would produce a fundamentally incompatible protocol. Unfortunately, I don't know what can be done about this. These groups seem hell-bent on hacking up RSVP without first learning it's design philosophy. If they don't get assignments from IANA, they'll probably just make their own assignments without any coordinating facility, and we'll wind up with several mutually incompatible protocols that all want to call themselves "RSVP". -- David From owner-mpls@UU.NET Thu Jan 23 11:43:30 2003 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12768 for ; Thu, 23 Jan 2003 11:43:29 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnyxf04661 for ; Thu, 23 Jan 2003 16:46:52 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnyxf04380; Thu, 23 Jan 2003 16:46:44 GMT Received: by mail-control.ash.ops.us.uu.net id QQnyxf18315 for mpls-outgoing; Thu, 23 Jan 2003 16:46:02 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnyxf18297 for ; Thu, 23 Jan 2003 16:45:57 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnyxf23516 for ; Thu, 23 Jan 2003 16:45:10 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnyxf02025 for ; Thu, 23 Jan 2003 16:45:09 GMT Received: from rtp-msg-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-msg-core-1.cisco.com [161.44.11.97]) id QQnyxf02005 for ; Thu, 23 Jan 2003 16:45:09 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h0NGjtPi023222 for ; Thu, 23 Jan 2003 11:45:55 -0500 (EST) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id LAA20266 for ; Thu, 23 Jan 2003 11:45:07 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h0NGj7816063 for mpls@uu.net; Thu, 23 Jan 2003 11:45:07 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnyxe17760 for ; Thu, 23 Jan 2003 16:43:42 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnyxe06168 for ; Thu, 23 Jan 2003 16:42:18 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnyxe26865 for ; Thu, 23 Jan 2003 16:42:17 GMT Received: from hoemail1.firewall.lucent.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: hoemail1.lucent.com [192.11.226.161]) id QQnyxe26859 for ; Thu, 23 Jan 2003 16:42:17 GMT Received: from nj7460exch002h.wins.lucent.com (h135-17-42-35.lucent.com [135.17.42.35]) by hoemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id h0NGgFd16229 for ; Thu, 23 Jan 2003 11:42:16 -0500 (EST) Received: by nj7460exch002h.ho.lucent.com with Internet Mail Service (5.5.2653.19) id ; Thu, 23 Jan 2003 11:42:15 -0500 Message-ID: From: "Lin, Zhi-Wei (Zhi)" To: David Charlap , Brian Hassink Cc: Bob Braden , rsvp@ISI.EDU, ccamp@ops.ietf.org, mpls@UU.NET, kireeti@juniper.net, iana@ISI.EDU, sob@harvard.edu, mankin@psg.com, bwijnen@lucent.com, "Wesam Alanqar (E-mail)" , "Mark Jones (E-mail)" Subject: RE: IANA Considerations for RSVP Date: Thu, 23 Jan 2003 11:42:14 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Hi David, I responded to an earlier message (you probably haven't seen it yet), but I just want to re-iterate some points here, especially the point about not wanting to work together. I'm not sure whether you've followed the work in CCAMP WG, but I've made the point that the ITU-T has notified and provided status as well as their "draft" documents to IETF consistently and regularly for the last few IEFT CCAMP WG meetings. As such, your point that you gave below I take it to imply that you either (1) have not followed the recent work in CCAMP, or (2) you choose to selectively ignore the work submitted to CCAMP. In either case I don't think this should be blamed on the folks who's (individually) submitted the work to IETF as individuals who are full-fledged members of the IETF community... Zhi -----Original Message----- From: David Charlap [mailto:David.Charlap@marconi.com] Sent: Thursday, January 23, 2003 11:15 AM To: Brian Hassink Cc: Bob Braden; rsvp@ISI.EDU; ccamp@ops.ietf.org; mpls@UU.NET; kireeti@juniper.net; iana@ISI.EDU; sob@harvard.edu; mankin@psg.com; bwijnen@lucent.com Subject: Re: IANA Considerations for RSVP Brian Hassink wrote: > Didn't the IETF set the precedent by extending RSVP from an IntServ protocol to an MPLS protocol? There's a big difference. MPLS and IntServ are both IETF groups. (And RSVP has/had its own working group anyway). Also, most of the key RSVP people were involved in the development of RSVP-TE. This is very different from what I'm describing - where people who have no prior RSVP experience decide that they can start changing it without understing it, and without even notifying the IETF groups that did all of the development work. I'mnot saying that RSVP should never be extended. I'm saying that those groups that are writing extensions should be consulting with those who have been developing and maintaining it (in the RSVP and MPLS groups) in order to ensure that: - Their goal can't be achieved without extending the language - That their extension doesn't overlap a similar extension from somebody else. - That their extension doesn't significantly change the overall semantics of RSVP. - That their extension is sufficiently flexible so that other groups can build off of it instead of re-inventing the wheel with yet another incompatible extension. Not only isn't this happening, but there appears to be no desire to see this happen. -- David From owner-mpls@UU.NET Thu Jan 23 11:47:01 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12938 for ; Thu, 23 Jan 2003 11:47:01 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnyxf05545 for ; Thu, 23 Jan 2003 16:50:26 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnyxf05312; Thu, 23 Jan 2003 16:50:20 GMT Received: by mail-control.ash.ops.us.uu.net id QQnyxf18748 for mpls-outgoing; Thu, 23 Jan 2003 16:49:49 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnyxf18737 for ; Thu, 23 Jan 2003 16:49:43 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnyxf02044 for ; Thu, 23 Jan 2003 16:49:05 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnyxf07043 for ; Thu, 23 Jan 2003 16:49:05 GMT Received: from w2ksjexg01.ciena.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [12.7.169.25]) id QQnyxf07022 for ; Thu, 23 Jan 2003 16:49:04 GMT Received: from wntcsdexg01.csd.ciena.com ([10.34.31.31]) by w2ksjexg01.ciena.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id C2BQNJYY; Thu, 23 Jan 2003 08:48:49 -0800 Received: by webdev-llnt.oni.com with Internet Mail Service (5.5.2653.19) id ; Thu, 23 Jan 2003 08:49:02 -0800 Message-ID: <2135200C183FD5119588009027DE572302836BF4@webdev-owa.oni.com> From: "Ong, Lyndon" To: "'Lin, Zhi-Wei (Zhi)'" , David Charlap , Bob Braden Cc: rsvp@ISI.EDU, ccamp@ops.ietf.org, mpls@UU.NET, kireeti@juniper.net, iana@ISI.EDU, sob@harvard.edu, mankin@psg.com, bwijnen@lucent.com Subject: RE: IANA Considerations for RSVP Date: Thu, 23 Jan 2003 08:48:53 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Folks, Keep in mind also that we are talking about the application of RSVP to switched transport networks (i.e., SDH), not to IP networks directly. This is the scope of the ITU specification that would use these extensions. Cheers, Lyndon Ong From owner-mpls@UU.NET Thu Jan 23 12:03:07 2003 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13383 for ; Thu, 23 Jan 2003 12:03:05 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnyxg04740 for ; Thu, 23 Jan 2003 17:06:29 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnyxg25828; Thu, 23 Jan 2003 17:02:22 GMT Received: by mail-control.ash.ops.us.uu.net id QQnyxg00230 for mpls-outgoing; Thu, 23 Jan 2003 17:02:09 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnyxg00137 for ; Thu, 23 Jan 2003 17:01:55 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnyxg07822 for ; Thu, 23 Jan 2003 17:01:52 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnyxg21791 for ; Thu, 23 Jan 2003 17:01:51 GMT Received: from mailgate.pit.comms.marconi.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6]) id QQnyxg21779 for ; Thu, 23 Jan 2003 17:01:51 GMT Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA07278; Thu, 23 Jan 2003 12:01:00 -0500 (EST) Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA25572; Thu, 23 Jan 2003 12:01:00 -0500 (EST) Message-ID: <3E301FF1.8080605@marconi.com> Date: Thu, 23 Jan 2003 12:01:37 -0500 From: David Charlap Organization: Marconi, Vienna VA User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en, he MIME-Version: 1.0 To: "Lin, Zhi-Wei (Zhi)" CC: Bob Braden , rsvp@ISI.EDU, ccamp@ops.ietf.org, mpls@UU.NET, kireeti@juniper.net, iana@ISI.EDU, sob@harvard.edu, mankin@psg.com, bwijnen@lucent.com Subject: Re: IANA Considerations for RSVP References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Lin, Zhi-Wei (Zhi) wrote: > > The GMPLS RSVP-TE, which is done in IETF, makes major modifications > to RFC3209 and RFC2205 version of RSVP. The rest of the changes been > requested are three new objects, new error codes to support these > objects. This can hardly be characterized as forcibly changing RSVP > or major change in direction... I am not criticizing the existance of GMPLS or the CCAMP work that's being done. All of the IETF people involved in RSVP are aware of this and contribute to it as they feel necessary. I'm far more concerned with non-IETF groups (like ITU, ATM Forum and others) deciding to develop their own incompatible extensions without even informing any IETF groups of their actions. Groups like these should not be extending IETF protocols without consulting with the relevant IETF working groups. Otherwise we end up with extensions that duplicate existing IETF functionality, don't coexist gracefully, and/or break interoperability. And if these extensions become popular in products, the IETF will be forced to include them in the standards in order to prevent future IETF work from breaking them. > The extensions that's been requested were derived as a result of > discussions and efforts involving many IETF people as well (e.g., > please look at the author list of the OIF UNI document). Your comment > seems to suggest that the work appear out of nowhere with no > participation from the IETF RSVP experts...this is clearly not > true... I am not referring to OIF UNI. They are doing consulting with relevant IETF groups as a part of their work. I must have struck a nerve here, because yours is the second response I've gotten from somebody who thinks I'm referring to their specific IETF-approved RSVP extension, even though I specifically said I'm referring to extensions developed without IETF involvement. And I think that was Bob's original issue as well - since he explicitly mentioned IANA RSVP requests coming from non-IETF sources. -- David From owner-mpls@UU.NET Thu Jan 23 12:10:02 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13559 for ; Thu, 23 Jan 2003 12:10:02 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnyxg02643 for ; Thu, 23 Jan 2003 17:13:25 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnyxg02331; Thu, 23 Jan 2003 17:13:15 GMT Received: by mail-control.ash.ops.us.uu.net id QQnyxg09423 for mpls-outgoing; Thu, 23 Jan 2003 17:12:52 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnyxg09418 for ; Thu, 23 Jan 2003 17:12:50 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnyxg01593 for ; Thu, 23 Jan 2003 17:12:05 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnyxg11721 for ; Thu, 23 Jan 2003 17:12:04 GMT Received: from rtp-msg-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-msg-core-1.cisco.com [161.44.11.97]) id QQnyxg11699 for ; Thu, 23 Jan 2003 17:12:04 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h0NHCoGe028510 for ; Thu, 23 Jan 2003 12:12:50 -0500 (EST) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id MAA22525 for ; Thu, 23 Jan 2003 12:12:02 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h0NHC2k20140 for mpls@uu.net; Thu, 23 Jan 2003 12:12:02 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnyxg08986 for ; Thu, 23 Jan 2003 17:10:57 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnyxg26175 for ; Thu, 23 Jan 2003 17:08:49 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnyxg03689 for ; Thu, 23 Jan 2003 17:08:48 GMT Received: from sj-msg-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQnyxg03672 for ; Thu, 23 Jan 2003 17:08:48 GMT Received: from mira-sjc5-a.cisco.com (IDENT:mirapoint@mira-sjc5-a.cisco.com [171.71.163.34]) by sj-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h0NH8HSQ003644; Thu, 23 Jan 2003 09:08:17 -0800 (PST) Received: from cisco.com (sjc-vpn2-769.cisco.com [10.21.115.1]) by mira-sjc5-a.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with SMTP id ADS98032; Thu, 23 Jan 2003 08:57:32 -0800 (PST) Received: by cisco.com (sSMTP sendmail emulation); Thu, 23 Jan 2003 12:08:12 -0500 Date: Thu, 23 Jan 2003 12:08:11 -0500 From: Scott W Brim To: ccamp@ops.ietf.org, mpls@UU.NET Subject: Re: IANA Considerations for RSVP Message-ID: <20030123170810.GA2000@SBRIM-W2K1> Mail-Followup-To: Scott W Brim , ccamp@ops.ietf.org, mpls@UU.NET References: <200301222140.VAA00937@gra.isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200301222140.VAA00937@gra.isi.edu> User-Agent: Mutt/1.4i Sender: owner-mpls@UU.NET Precedence: bulk On Wed, Jan 22, 2003 09:40:12PM +0000, Bob Braden allegedly wrote: > 3. The IANA Considerations draft should be published as an RFC, > perhaps after updating. Here are some issues that might affect > this update. All good ideas, but they still don't lead to integration. In ATM you find a (personal opinion) hodgepodge of overlapping capabilities in the signaling IEs because of the lack of strict control and insistence on coordinated engineering. Keep the idea of a separate name space in the back pocket and try for better. Incrementally, perhaps have just one more name class, "non-IETF" and insist on a statement that the group proposing the new extension document how it interacts with existing ones. But, if you're going to do that, you could insist on that documentation and not have the different categories. Whatever you think we can pull off. > Must there be an Internet Draft? An RFC? We have > tended towards the RFC, but the result is less than > satisfactory. These extensions are typically > documented in some 373- page document published (or > more often hidden) by the other standards body. The > I-D/RFC that is written for registration presents only > a superficial summary of the data structures to be > defined, with no context of explanation, and a > reference to the real 373 page document. There must be an RFC, even if status is informational. documentation must be in space that's visible to users of RSVP, and that means publicly visible, not restricted to members of bodies who are requesting the extensions. ..Scott From owner-mpls@UU.NET Thu Jan 23 12:13:01 2003 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13663 for ; Thu, 23 Jan 2003 12:13:01 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnyxh12294 for ; Thu, 23 Jan 2003 17:16:25 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnyxh11606; Thu, 23 Jan 2003 17:16:07 GMT Received: by mail-control.ash.ops.us.uu.net id QQnyxh09727 for mpls-outgoing; Thu, 23 Jan 2003 17:15:33 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnyxh09706 for ; Thu, 23 Jan 2003 17:15:25 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnyxg03005 for ; Thu, 23 Jan 2003 17:13:05 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnyxg12733 for ; Thu, 23 Jan 2003 17:13:04 GMT Received: from rtp-msg-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-msg-core-1.cisco.com [161.44.11.97]) id QQnyxg12728 for ; Thu, 23 Jan 2003 17:13:03 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h0NHDoi9028644 for ; Thu, 23 Jan 2003 12:13:50 -0500 (EST) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id MAA22606 for ; Thu, 23 Jan 2003 12:13:02 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h0NHD2s20204 for mpls@uu.net; Thu, 23 Jan 2003 12:13:02 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnyxg09399 for ; Thu, 23 Jan 2003 17:12:23 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnyxg22458 for ; Thu, 23 Jan 2003 17:10:48 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnyxg05848 for ; Thu, 23 Jan 2003 17:10:47 GMT Received: from sj-msg-core-3.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-3.cisco.com [171.70.157.152]) id QQnyxg05831 for ; Thu, 23 Jan 2003 17:10:47 GMT Received: from mira-sjc5-a.cisco.com (IDENT:mirapoint@mira-sjc5-a.cisco.com [171.71.163.34]) by sj-msg-core-3.cisco.com (8.12.2/8.12.6) with ESMTP id h0NH9aB6005977; Thu, 23 Jan 2003 09:09:36 -0800 (PST) Received: from cisco.com (sjc-vpn2-769.cisco.com [10.21.115.1]) by mira-sjc5-a.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with SMTP id ADS98103; Thu, 23 Jan 2003 08:58:53 -0800 (PST) Received: by cisco.com (sSMTP sendmail emulation); Thu, 23 Jan 2003 12:09:36 -0500 Date: Thu, 23 Jan 2003 12:09:35 -0500 From: Scott W Brim To: Brian Hassink Cc: David Charlap , Bob Braden , rsvp@ISI.EDU, ccamp@ops.ietf.org, mpls@UU.NET, kireeti@juniper.net, iana@ISI.EDU, sob@harvard.edu, mankin@psg.com, bwijnen@lucent.com Subject: Re: IANA Considerations for RSVP Message-ID: <20030123170935.GB2000@SBRIM-W2K1> Mail-Followup-To: Scott W Brim , Brian Hassink , David Charlap , Bob Braden , rsvp@ISI.EDU, ccamp@ops.ietf.org, mpls@UU.NET, kireeti@juniper.net, iana@ISI.EDU, sob@harvard.edu, mankin@psg.com, bwijnen@lucent.com References: <8052E2EA753D144EB906B7A7AA3997140B4899@mailserv.hatteras.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8052E2EA753D144EB906B7A7AA3997140B4899@mailserv.hatteras.com> User-Agent: Mutt/1.4i Sender: owner-mpls@UU.NET Precedence: bulk On Thu, Jan 23, 2003 11:06:53AM -0500, Brian Hassink allegedly wrote: > Didn't the IETF set the precedent by extending RSVP from an IntServ > protocol to an MPLS protocol? Check the documentation. RSVP is not an intserv protocol. It's (potentially) used by intserv. It's also used for other things. From owner-mpls@UU.NET Thu Jan 23 12:17:46 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13777 for ; Thu, 23 Jan 2003 12:17:46 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnyxh14625 for ; Thu, 23 Jan 2003 17:21:10 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnyxh14350; Thu, 23 Jan 2003 17:21:01 GMT Received: by mail-control.ash.ops.us.uu.net id QQnyxh10370 for mpls-outgoing; Thu, 23 Jan 2003 17:20:34 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnyxh10345 for ; Thu, 23 Jan 2003 17:20:20 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnyxh05453 for ; Thu, 23 Jan 2003 17:19:07 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnyxh21154 for ; Thu, 23 Jan 2003 17:19:05 GMT Received: from rtp-msg-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-msg-core-1.cisco.com [161.44.11.97]) id QQnyxh21075 for ; Thu, 23 Jan 2003 17:19:04 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h0NHJoK5029537 for ; Thu, 23 Jan 2003 12:19:50 -0500 (EST) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id MAA23080 for ; Thu, 23 Jan 2003 12:19:02 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h0NHJ2Q20767 for mpls@uu.net; Thu, 23 Jan 2003 12:19:02 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnyxh10000 for ; Thu, 23 Jan 2003 17:17:18 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnyxh05506 for ; Thu, 23 Jan 2003 17:16:18 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnyxh11956 for ; Thu, 23 Jan 2003 17:16:16 GMT Received: from sj-msg-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQnyxh11914 for ; Thu, 23 Jan 2003 17:16:15 GMT Received: from mira-sjc5-a.cisco.com (IDENT:mirapoint@mira-sjc5-a.cisco.com [171.71.163.34]) by sj-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h0NHFSSQ008366; Thu, 23 Jan 2003 09:15:28 -0800 (PST) Received: from cisco.com (sjc-vpn2-769.cisco.com [10.21.115.1]) by mira-sjc5-a.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with SMTP id ADS98472; Thu, 23 Jan 2003 09:04:42 -0800 (PST) Received: by cisco.com (sSMTP sendmail emulation); Thu, 23 Jan 2003 12:15:22 -0500 Date: Thu, 23 Jan 2003 12:15:21 -0500 From: Scott W Brim To: ccamp@ops.ietf.org, mpls@UU.NET, kireeti@juniper.net, braden@ISI.EDU, iana@ISI.EDU, sob@harvard.edu, mankin@psg.com, bwijnen@lucent.com Subject: Re: IANA Considerations for RSVP Message-ID: <20030123171521.GC2000@SBRIM-W2K1> Mail-Followup-To: Scott W Brim , ccamp@ops.ietf.org, mpls@UU.NET, kireeti@juniper.net, braden@ISI.EDU, iana@ISI.EDU, sob@harvard.edu, mankin@psg.com, bwijnen@lucent.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i Sender: owner-mpls@UU.NET Precedence: bulk Sorry, accidentally narrowed the list. Date: Thu, 23 Jan 2003 12:08:11 -0500 From: Scott W Brim To: ccamp@ops.ietf.org, mpls@UU.NET Subject: Re: IANA Considerations for RSVP On Wed, Jan 22, 2003 09:40:12PM +0000, Bob Braden allegedly wrote: > 3. The IANA Considerations draft should be published as an RFC, > perhaps after updating. Here are some issues that might affect > this update. All good ideas, but they still don't lead to integration. In ATM you find a (personal opinion) hodgepodge of overlapping capabilities in the signaling IEs because of the lack of strict control and insistence on coordinated engineering. Keep the idea of a separate name space in the back pocket and try for better. Incrementally, perhaps have just one more name class, "non-IETF" and insist on a statement that the group proposing the new extension document how it interacts with existing ones. But, if you're going to do that, you could insist on that documentation and not have the different categories. Whatever you think we can pull off. > Must there be an Internet Draft? An RFC? We have > tended towards the RFC, but the result is less than > satisfactory. These extensions are typically > documented in some 373- page document published (or > more often hidden) by the other standards body. The > I-D/RFC that is written for registration presents only > a superficial summary of the data structures to be > defined, with no context of explanation, and a > reference to the real 373 page document. There must be an RFC, even if status is informational. documentation must be in space that's visible to users of RSVP, and that means publicly visible, not restricted to members of bodies who are requesting the extensions. .Scott From owner-mpls@UU.NET Thu Jan 23 12:21:20 2003 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13871 for ; Thu, 23 Jan 2003 12:21:20 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnyxh28349 for ; Thu, 23 Jan 2003 17:24:45 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnyxh28094; Thu, 23 Jan 2003 17:24:38 GMT Received: by mail-control.ash.ops.us.uu.net id QQnyxh10841 for mpls-outgoing; Thu, 23 Jan 2003 17:24:09 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnyxh10824 for ; Thu, 23 Jan 2003 17:23:58 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnyxh11561 for ; Thu, 23 Jan 2003 17:21:39 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnyxh24991 for ; Thu, 23 Jan 2003 17:21:38 GMT Received: from ihemail1.firewall.lucent.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ihemail1.lucent.com [192.11.222.161]) id QQnyxh24976 for ; Thu, 23 Jan 2003 17:21:38 GMT Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id h0NHLU928844; Thu, 23 Jan 2003 12:21:30 -0500 (EST) Received: from lucent.com (sjtrowbridge.lra.lucent.com [135.248.252.19]) by ihmail.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id LAA13652; Thu, 23 Jan 2003 11:21:22 -0600 (CST) Message-ID: <3E30248B.980C42B2@lucent.com> Date: Thu, 23 Jan 2003 10:21:15 -0700 From: Stephen Trowbridge Organization: Lucent Technologies X-Mailer: Mozilla 4.76 [en]C-CCK-MCD EMS-1.5 (Windows NT 5.0; U) X-Accept-Language: en,zh MIME-Version: 1.0 To: David Charlap CC: Brian Hassink , Bob Braden , rsvp@ISI.EDU, ccamp@ops.ietf.org, mpls@UU.NET, kireeti@juniper.net, iana@ISI.EDU, sob@harvard.edu, mankin@psg.com, bwijnen@lucent.com Subject: Re: IANA Considerations for RSVP References: <8052E2EA753D144EB906B7A7AA3997140B4899@mailserv.hatteras.com> <3E301519.4010807@marconi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit David, To read these emails, it sounds as though you think that the people who are doing this are brand new to the technology and never even considered working with IETF to try to solve the problem. Perhaps you haven't followed the ccamp work so closely, but here is some history: - On October 21, 2001, ITU-T Study Group 15 sent IETF ccamp a liaison statement regarding our new documents with requirements and architecture for switched (not necessarily IP) transport networks. This included a protocol- neutral model for call and connection management (signaling). In copies of the ITU-T documents were made available to non-ITU-T members via an ftp site. The liaison was placed on the IESG web site and was presented in the ccamp meeting in Salt Lake City in December. At that same meeting, Maarten Vissers gave a technical presentation in the sub-IP area meeting regarding the ITU-T work in this area. - On February 19, 2002, ITU-T sent IETF ccamp a liaison statement regarding the gaps that had been identified between the ITU-T requirements (sent earlier) and what seemed to be implemented by the GMPLS protocols. Specifically, 1. Call & Connection separation, e.g., a call provides the service relationship, which may support connection operations as part of a call. 2. Additional error codes/values, for example, for connection rejection (invalid connection ID). 3. Restart mechanisms: Depending on the introduction by the ITU of additional control plane resiliency requirements, enhancements of the protocol (RSVP-TE, CR-LDP) "graceful restart" mechanisms may be required. 4. Protocol enhancements in CR-LDP for support of crankback capability from intermediate nodes. This liaison was presented in the Minneapolis IETF meeting during the ccamp working group and posted on the IESG web site. The liaison requested assistance in closing these gaps and invited input from IETF on our work in ITU-T. - At the April/May 2002 meeting of ITU-T Study Group 15 meeting, contributions were considered to close these gaps, resulting in text for draft Recommendations G.7713.2 (our rsvp-te document) and G.7713.3 (our cr-ldp document). Again, we sent a liaison (dated May 10, 2002) to ask for comments on our draft Recommendations (made available on the ftp site), to request alignment, and to ask for IANA code point assignments. To quote from that liaison: "Please consider including the proposed solutions provided in G.7713.2 and G.7713.3 to update the existing GMPLS signaling work in support of ASON requirements. We hope that you can help expedite the assignment of appropriate additional error codes/values by IANA. These are needed for both RSVP-TE and CR-LDP." This liaison was presented at the Yokohama IETF ccamp meeting. To refer to one point raised earlier in the thread, there are other cases where IANA has assigned codepoints for work outside of IETF, including other CCITT/ITU-T work, IEEE, IEC, etc. This request had been made last May, with no response. - Some final work was done on our drafts at a Rapporteur meeting in October, with one result being another liaison (dated October 11, 2002) making another plea for comments and help getting the codepoints assigned. This liaison was presented at the Atlanta IETF ccamp meeting, and still no response or IANA action. To hear now that someone thinks that the ASON work in ITU-T is some kind of secret end-run around IETF, and not involved with or related to the work being done internally in IETF is absurd. At every stage of the work, IETF was kept informed of the work and invited to participate. At the invitation for help to address the additional ITU-T requirements, there was no response. As ITU-T progressed this work and invited further comments and alignment of the base GMPLS protocols, again no response. And to the final pleas for comments and codepoint assignments, no response. I contrast this with our interaction with the ATM forum on the same topic. Certain operators in ITU-T are interested in using the PNNI protocol for this application (rather than rsvp-te or cr-ldp). The ATM forum has responded with a formal liaison into the current ITU-T Study Group 15 meeting where they have given us a diffmarked copy with extremely helpful and constructive suggestions about how to align our G.7713.1 document with their work. After some private communication with the Area directors, we received some advice that one tool that might be used to finally get the IANA codepoint assignment complete would be to publish what we were doing in ITU-T as informational RFCs. This is the stage we are at today, and given the history I describe above, I do not think anybody can say that we are at this point because any of us did not do everything possible to do this work (a) in IETF, with the initial communication of requirements; or (b) in cooperation between ITU-T and IETF, once this work had progressed in ITU-T. But this is all water under the bridge. We are at the point of trying to get some codepoints assigned for ITU-T documents we are trying to complete. Nobody should say "no" at this point because they think we didn't try to work this IN or WITH IETF first. It should be clear to all that this is not the case. Regards, Steve Trowbridge (vice-chairman, ITU-T Study Group 15) David Charlap wrote: > > Brian Hassink wrote: > > Didn't the IETF set the precedent by extending RSVP from an IntServ protocol to an MPLS protocol? > > There's a big difference. MPLS and IntServ are both IETF groups. (And > RSVP has/had its own working group anyway). Also, most of the key RSVP > people were involved in the development of RSVP-TE. > > This is very different from what I'm describing - where people who have > no prior RSVP experience decide that they can start changing it without > understing it, and without even notifying the IETF groups that did all > of the development work. > > I'mnot saying that RSVP should never be extended. I'm saying that those > groups that are writing extensions should be consulting with those who > have been developing and maintaining it (in the RSVP and MPLS groups) in > order to ensure that: > - Their goal can't be achieved without extending the language > - That their extension doesn't overlap a similar extension > from somebody else. > - That their extension doesn't significantly change the overall > semantics of RSVP. > - That their extension is sufficiently flexible so that other > groups can build off of it instead of re-inventing the wheel > with yet another incompatible extension. > > Not only isn't this happening, but there appears to be no desire to see > this happen. > > -- David From owner-mpls@UU.NET Thu Jan 23 12:34:51 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14242 for ; Thu, 23 Jan 2003 12:34:51 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnyxi07380 for ; Thu, 23 Jan 2003 17:38:14 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnyxi06958; Thu, 23 Jan 2003 17:38:02 GMT Received: by mail-control.ash.ops.us.uu.net id QQnyxi12253 for mpls-outgoing; Thu, 23 Jan 2003 17:37:46 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnyxi12240 for ; Thu, 23 Jan 2003 17:37:36 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnyxi03991 for ; Thu, 23 Jan 2003 17:36:45 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnyxi15672 for ; Thu, 23 Jan 2003 17:36:44 GMT Received: from rtp-msg-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-msg-core-1.cisco.com [161.44.11.97]) id QQnyxi15649 for ; Thu, 23 Jan 2003 17:36:44 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h0NHbUe3001944 for ; Thu, 23 Jan 2003 12:37:30 -0500 (EST) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id MAA24423 for ; Thu, 23 Jan 2003 12:36:42 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h0NHag228086 for mpls@uu.net; Thu, 23 Jan 2003 12:36:42 -0500 (EST) Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnyxh11567 for ; Thu, 23 Jan 2003 17:29:50 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnyxh06740 for ; Thu, 23 Jan 2003 17:29:26 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnyxh08151 for ; Thu, 23 Jan 2003 17:29:24 GMT Received: from host19.ipowerweb.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: host19.ipowerweb.com [12.129.206.119]) id QQnyxh08130 for ; Thu, 23 Jan 2003 17:29:23 GMT Received: from h00a0ccd1a9ec.ne.client2.attbi.com ([24.128.219.249] helo=GraIyMage.com) by host19.ipowerweb.com with asmtp (Exim 3.36 #1) id 18bl8x-0007Zi-00; Thu, 23 Jan 2003 09:27:59 -0800 Message-ID: <3E30260A.82698500@GraIyMage.com> Date: Thu, 23 Jan 2003 12:27:38 -0500 From: Eric Gray Reply-To: GraIyMag@GraIyMage.com X-Mailer: Mozilla 4.7 [en]C-CCK-MCD NSCPCD47 (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: David Charlap CC: Bob Braden , rsvp@ISI.EDU, ccamp@ops.ietf.org, mpls@UU.NET, kireeti@juniper.net, iana@ISI.EDU, sob@harvard.edu, mankin@psg.com, bwijnen@lucent.com Subject: Re: IANA Considerations for RSVP References: <200301222140.VAA00937@gra.isi.edu> <3E301086.3000002@marconi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - host19.ipowerweb.com X-AntiAbuse: Original Domain - uu.net X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [0 0] X-AntiAbuse: Sender Address Domain - graiymage.com Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit David, The intent to build a new protocol, rather than bastardize an existing one has gotten a very large number of people burned in recent times. I can't say as I blame external organizations - who, in almost every case, have mostly only seen the flames from prior efforts coloring the sky - from opting to modify an existing protocol. We shouldn't chastise people for making what they feel are the best choices based on the evidence in front of them. We should instead try to determine what they are missing, or otherwise help them to modify those choices. :-) -- Eric Gray David Charlap wrote: > Bob Braden wrote: > > > > There is a growing unease about IANA assignments of RSVP parameters -- > > object numbers, CTypes, message types, and error numbers -- for new > > uses of RSVP. Many of these IANA requests, but not all, originate > > outside the IETF in other standards bodies. Many of the people from > > outside the IETF were not part of the RSVP working group and so did not > > absorb the technical rationale behind RSVP; in fact, they are sometimes > > barely clued into IETF procedures at all. > > I've noticed the same thing. It seems that many non-IETF groups want to > use RSVP, and all believe that they must create extensions to the > protocol for their features, often without first bothering to check if > there are already obects defined by IETF standards that already serve > their purposes. And even in those cases where new objects may be > required, the proposed objects are often defined as having semantics > that differ greatly from the way RSVP usually operates. > > In other words, these groups seem to want to forcibly change RSVP into a > protocol that more closely resembles some other protocol that they're > more intimately familiar with. > > Personally, I don't like this. These groups should step back and decide > if RSVP is really what they need. If they require a different protocol, > then they should use a different protocol - they should not glom onto > RSVP just because it's popular in MPLS and then try to change it into > what they really want. This is especially true in those situations > where their proposed changes would produce a fundamentally incompatible > protocol. > > Unfortunately, I don't know what can be done about this. These groups > seem hell-bent on hacking up RSVP without first learning it's design > philosophy. If they don't get assignments from IANA, they'll probably > just make their own assignments without any coordinating facility, and > we'll wind up with several mutually incompatible protocols that all want > to call themselves "RSVP". > > -- David From owner-mpls@UU.NET Thu Jan 23 12:42:35 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14628 for ; Thu, 23 Jan 2003 12:42:35 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnyxj18934 for ; Thu, 23 Jan 2003 17:45:59 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnyxj18777; Thu, 23 Jan 2003 17:45:54 GMT Received: by mail-control.ash.ops.us.uu.net id QQnyxj13109 for mpls-outgoing; Thu, 23 Jan 2003 17:45:25 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnyxj13062 for ; Thu, 23 Jan 2003 17:45:07 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnyxi05693 for ; Thu, 23 Jan 2003 17:41:08 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnyxi22563 for ; Thu, 23 Jan 2003 17:41:07 GMT Received: from rtp-msg-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-msg-core-1.cisco.com [161.44.11.97]) id QQnyxi22512 for ; Thu, 23 Jan 2003 17:41:05 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h0NHfpbl002538 for ; Thu, 23 Jan 2003 12:41:51 -0500 (EST) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id MAA24723 for ; Thu, 23 Jan 2003 12:41:03 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h0NHf3r28560 for mpls@uu.net; Thu, 23 Jan 2003 12:41:03 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnyxg07162 for ; Thu, 23 Jan 2003 17:03:41 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnyxg17362 for ; Thu, 23 Jan 2003 17:01:27 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnyxg26140 for ; Thu, 23 Jan 2003 17:01:26 GMT Received: from hoemail1.firewall.lucent.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: hoemail1.lucent.com [192.11.226.161]) id QQnyxg26128 for ; Thu, 23 Jan 2003 17:01:26 GMT Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by hoemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id h0NH1Od27887 for ; Thu, 23 Jan 2003 12:01:24 -0500 (EST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id ; Thu, 23 Jan 2003 18:01:23 +0100 Message-ID: From: "Mak, L (Leen)" To: "'David Charlap'" , Bob Braden Cc: rsvp@ISI.EDU, ccamp@ops.ietf.org, mpls@UU.NET, kireeti@juniper.net, iana@ISI.EDU, sob@harvard.edu, mankin@psg.com, "Wijnen, Bert (Bert)" Subject: RE: IANA Considerations for RSVP Date: Thu, 23 Jan 2003 18:01:15 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk David You wrote: > In other words, these groups seem to want to forcibly change > RSVP into a protocol that more closely resembles some other > protocol that they're more intimately familiar with. My recollection of history brings me to a little paraphrasing of your statement: - In other words, the IETF seemed to want to forcibly change - transport networking into a thing that more closely resembles - some other network that they're more intimately familiar with. If you agree, let's than put the pots and the kettles where they belong and join forces on a constructive way forward. That is in our common interest. Leen Mak. From owner-mpls@UU.NET Thu Jan 23 12:52:03 2003 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14941 for ; Thu, 23 Jan 2003 12:52:02 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnyxj12715 for ; Thu, 23 Jan 2003 17:55:25 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnyxj12336; Thu, 23 Jan 2003 17:55:14 GMT Received: by mail-control.ash.ops.us.uu.net id QQnyxj14123 for mpls-outgoing; Thu, 23 Jan 2003 17:54:45 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnyxj14104 for ; Thu, 23 Jan 2003 17:54:36 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnyxj06991 for ; Thu, 23 Jan 2003 17:54:06 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnyxj10776 for ; Thu, 23 Jan 2003 17:54:06 GMT Received: from rtp-msg-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-msg-core-1.cisco.com [161.44.11.97]) id QQnyxj10768 for ; Thu, 23 Jan 2003 17:54:05 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h0NHspPI004268 for ; Thu, 23 Jan 2003 12:54:52 -0500 (EST) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id MAA25752 for ; Thu, 23 Jan 2003 12:54:03 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h0NHs3M02930 for mpls@uu.net; Thu, 23 Jan 2003 12:54:03 -0500 (EST) Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnyxj14022 for ; Thu, 23 Jan 2003 17:53:02 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnyxj14125 for ; Thu, 23 Jan 2003 17:52:24 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnyxj03403 for ; Thu, 23 Jan 2003 17:52:23 GMT Received: from hoemail1.firewall.lucent.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: hoemail1.lucent.com [192.11.226.161]) id QQnyxj03399 for ; Thu, 23 Jan 2003 17:52:23 GMT Received: from nj7460exch001h.wins.lucent.com (h135-17-42-36.lucent.com [135.17.42.36]) by hoemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id h0NHqLm27576 for ; Thu, 23 Jan 2003 12:52:21 -0500 (EST) Received: by nj7460exch001h.ho.lucent.com with Internet Mail Service (5.5.2653.19) id ; Thu, 23 Jan 2003 12:52:20 -0500 Message-ID: From: "Lin, Zhi-Wei (Zhi)" To: GraIyMag@graiymage.com, "Lin, Zhi-Wei (Zhi)" Cc: David Charlap , Bob Braden , rsvp@ISI.EDU, ccamp@ops.ietf.org, mpls@UU.NET, kireeti@juniper.net, iana@ISI.EDU, sob@harvard.edu, mankin@psg.com, bwijnen@lucent.com Subject: RE: IANA Considerations for RSVP Date: Thu, 23 Jan 2003 12:52:17 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Hi Eric, Please see Steve's email on the history. After reading that, I hope you would change your mind about the "fait accompli" remark... Thanks Zhi -----Original Message----- From: Eric Gray [mailto:ewgray@graiymage.com] Sent: Thursday, January 23, 2003 12:43 PM To: Lin, Zhi-Wei (Zhi) Cc: David Charlap; Bob Braden; rsvp@ISI.EDU; ccamp@ops.ietf.org; mpls@UU.NET; kireeti@juniper.net; iana@ISI.EDU; sob@harvard.edu; mankin@psg.com; bwijnen@lucent.com Subject: Re: IANA Considerations for RSVP Zhi, Yours may be an equally unfair characterization. In general, the reaction in the IETF to any intended RFC submitted as a 'fait accompli' is similar to what you are seeing here - regardless of whether it came from an individual or an organization representative. "Lin, Zhi-Wei (Zhi)" wrote: > Hi David, > > This seems like an unfair characterization. All requests are submitted by individuals. In terms of changing these protocols... > ... From owner-mpls@UU.NET Thu Jan 23 13:28:39 2003 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15883 for ; Thu, 23 Jan 2003 13:28:37 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnyxm00451 for ; Thu, 23 Jan 2003 18:30:23 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnyxm00153; Thu, 23 Jan 2003 18:30:15 GMT Received: by mail-control.ash.ops.us.uu.net id QQnyxl05605 for mpls-outgoing; Thu, 23 Jan 2003 18:29:58 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnyxl05599 for ; Thu, 23 Jan 2003 18:29:51 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnyxl01429 for ; Thu, 23 Jan 2003 18:27:34 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnyxl27064 for ; Thu, 23 Jan 2003 18:27:33 GMT Received: from rtp-msg-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-msg-core-1.cisco.com [161.44.11.97]) id QQnyxl27052 for ; Thu, 23 Jan 2003 18:27:33 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h0NISJTl009829 for ; Thu, 23 Jan 2003 13:28:19 -0500 (EST) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id NAA28482 for ; Thu, 23 Jan 2003 13:27:31 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h0NIRV007464 for mpls@uu.net; Thu, 23 Jan 2003 13:27:31 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnyxj13829 for ; Thu, 23 Jan 2003 17:51:12 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnyxi09800 for ; Thu, 23 Jan 2003 17:44:23 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnyxi16891 for ; Thu, 23 Jan 2003 17:44:22 GMT Received: from host19.ipowerweb.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: host19.ipowerweb.com [12.129.206.119]) id QQnyxi16877 for ; Thu, 23 Jan 2003 17:44:22 GMT Received: from h00a0ccd1a9ec.ne.client2.attbi.com ([24.128.219.249] helo=GraIyMage.com) by host19.ipowerweb.com with asmtp (Exim 3.36 #1) id 18blNR-0002jY-00; Thu, 23 Jan 2003 09:42:57 -0800 Message-ID: <3E30298A.881E59C3@GraIyMage.com> Date: Thu, 23 Jan 2003 12:42:34 -0500 From: Eric Gray Reply-To: GraIyMag@GraIyMage.com X-Mailer: Mozilla 4.7 [en]C-CCK-MCD NSCPCD47 (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: "Lin, Zhi-Wei (Zhi)" CC: David Charlap , Bob Braden , rsvp@ISI.EDU, ccamp@ops.ietf.org, mpls@UU.NET, kireeti@juniper.net, iana@ISI.EDU, sob@harvard.edu, mankin@psg.com, bwijnen@lucent.com Subject: Re: IANA Considerations for RSVP References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - host19.ipowerweb.com X-AntiAbuse: Original Domain - uu.net X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [0 0] X-AntiAbuse: Sender Address Domain - graiymage.com Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Zhi, Yours may be an equally unfair characterization. In general, the reaction in the IETF to any intended RFC submitted as a 'fait accompli' is similar to what you are seeing here - regardless of whether it came from an individual or an organization representative. "Lin, Zhi-Wei (Zhi)" wrote: > Hi David, > > This seems like an unfair characterization. All requests are submitted by individuals. In terms of changing these protocols... > ... From owner-mpls@UU.NET Thu Jan 23 13:36:04 2003 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16026 for ; Thu, 23 Jan 2003 13:36:04 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnyxm18322 for ; Thu, 23 Jan 2003 18:39:18 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnyxm17567; Thu, 23 Jan 2003 18:39:00 GMT Received: by mail-control.ash.ops.us.uu.net id QQnyxm06433 for mpls-outgoing; Thu, 23 Jan 2003 18:38:26 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnyxm06410 for ; Thu, 23 Jan 2003 18:38:21 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnyxm28072 for ; Thu, 23 Jan 2003 18:37:39 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnyxm14566 for ; Thu, 23 Jan 2003 18:37:38 GMT Received: from merlot.juniper.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: natint.juniper.net [207.17.136.129]) id QQnyxm14525 for ; Thu, 23 Jan 2003 18:37:37 GMT Received: from kummer.juniper.net (kummer.juniper.net [172.17.12.90]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h0NIbUS65089; Thu, 23 Jan 2003 10:37:30 -0800 (PST) (envelope-from kireeti@juniper.net) Received: from localhost (kireeti@localhost) by kummer.juniper.net (8.11.6/8.9.3) with ESMTP id h0NIbU484088; Thu, 23 Jan 2003 10:37:30 -0800 (PST) (envelope-from kireeti@juniper.net) X-Authentication-Warning: kummer.juniper.net: kireeti owned process doing -bs Date: Thu, 23 Jan 2003 10:37:30 -0800 (PST) From: Kireeti Kompella To: David Charlap cc: , , , Subject: Re: IANA Considerations for RSVP In-Reply-To: <3E301086.3000002@marconi.com> Message-ID: <20030123103057.L83975-100000@kummer.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Hi David, On Thu, 23 Jan 2003, David Charlap wrote: > Bob Braden wrote: > > > > There is a growing unease about IANA assignments of RSVP parameters -- > > object numbers, CTypes, message types, and error numbers -- for new > > uses of RSVP. Many of these IANA requests, but not all, originate > > outside the IETF in other standards bodies. Many of the people from > > outside the IETF were not part of the RSVP working group and so did not > > absorb the technical rationale behind RSVP; in fact, they are sometimes > > barely clued into IETF procedures at all. > > I've noticed the same thing. It seems that many non-IETF groups want to > use RSVP, and all believe that they must create extensions to the > protocol for their features, often without first bothering to check if > there are already obects defined by IETF standards that already serve > their purposes. And even in those cases where new objects may be > required, the proposed objects are often defined as having semantics > that differ greatly from the way RSVP usually operates. Glad to hear you say that! > In other words, these groups seem to want to forcibly change RSVP into a > protocol that more closely resembles some other protocol that they're > more intimately familiar with. No comment :) > Unfortunately, I don't know what can be done about this. It's not that hard. As Bob said, redo the IANA Considerations (and not just for RSVP) to require *well* documented specs that go through tighter screening in the appropriate WGs. Kireeti. From owner-mpls@UU.NET Thu Jan 23 13:41:34 2003 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16178 for ; Thu, 23 Jan 2003 13:41:33 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnyxm00224 for ; Thu, 23 Jan 2003 18:44:58 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnyxm29990; Thu, 23 Jan 2003 18:44:51 GMT Received: by mail-control.ash.ops.us.uu.net id QQnyxm06897 for mpls-outgoing; Thu, 23 Jan 2003 18:44:22 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnyxm06884 for ; Thu, 23 Jan 2003 18:44:15 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnyxm24945 for ; Thu, 23 Jan 2003 18:42:47 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnyxm24486 for ; Thu, 23 Jan 2003 18:42:47 GMT Received: from merlot.juniper.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: natint.juniper.net [207.17.136.129]) id QQnyxm24477 for ; Thu, 23 Jan 2003 18:42:46 GMT Received: from kummer.juniper.net (kummer.juniper.net [172.17.12.90]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h0NIgeS65549; Thu, 23 Jan 2003 10:42:40 -0800 (PST) (envelope-from kireeti@juniper.net) Received: from localhost (kireeti@localhost) by kummer.juniper.net (8.11.6/8.9.3) with ESMTP id h0NIge884144; Thu, 23 Jan 2003 10:42:40 -0800 (PST) (envelope-from kireeti@juniper.net) X-Authentication-Warning: kummer.juniper.net: kireeti owned process doing -bs Date: Thu, 23 Jan 2003 10:42:40 -0800 (PST) From: Kireeti Kompella To: David Charlap cc: Bob Braden , , , , Subject: Re: IANA Considerations for RSVP In-Reply-To: <3E301519.4010807@marconi.com> Message-ID: <20030123103757.B83975-100000@kummer.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Hi David, On Thu, 23 Jan 2003, David Charlap wrote: > This is very different from what I'm describing - where people who have > no prior RSVP experience decide that they can start changing it without > understing it, and without even notifying the IETF groups that did all > of the development work. Just notifying is insufficient. A detailed review, the ability to make comments and changes, going through the IETF process (such as it is) is MANDATORY for protocol changes. Moreover, making the spec standards track means that new specs can cite it *normatively*. > Not only isn't this happening, but there appears to be no desire to see > this happen. Well, it's like pulling teeth. But we're on the first step -- you can thank Bob for that! Kireeti. From owner-mpls@UU.NET Thu Jan 23 13:51:20 2003 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16433 for ; Thu, 23 Jan 2003 13:51:20 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnyxn06329 for ; Thu, 23 Jan 2003 18:54:44 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnyxn06076; Thu, 23 Jan 2003 18:54:38 GMT Received: by mail-control.ash.ops.us.uu.net id QQnyxn08089 for mpls-outgoing; Thu, 23 Jan 2003 18:54:23 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnyxn08082 for ; Thu, 23 Jan 2003 18:54:09 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnyxn02962 for ; Thu, 23 Jan 2003 18:53:18 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnyxn11792 for ; Thu, 23 Jan 2003 18:53:18 GMT Received: from merlot.juniper.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: natint.juniper.net [207.17.136.129]) id QQnyxn11777 for ; Thu, 23 Jan 2003 18:53:17 GMT Received: from kummer.juniper.net (kummer.juniper.net [172.17.12.90]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h0NIqUS66565; Thu, 23 Jan 2003 10:52:30 -0800 (PST) (envelope-from kireeti@juniper.net) Received: from localhost (kireeti@localhost) by kummer.juniper.net (8.11.6/8.9.3) with ESMTP id h0NIqUh84231; Thu, 23 Jan 2003 10:52:30 -0800 (PST) (envelope-from kireeti@juniper.net) X-Authentication-Warning: kummer.juniper.net: kireeti owned process doing -bs Date: Thu, 23 Jan 2003 10:52:30 -0800 (PST) From: Kireeti Kompella To: "Lin, Zhi-Wei (Zhi)" cc: David Charlap , Bob Braden , , , , , , , Subject: RE: IANA Considerations for RSVP In-Reply-To: Message-ID: <20030123104246.W83975-100000@kummer.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Hi Zhi, On Thu, 23 Jan 2003, Lin, Zhi-Wei (Zhi) wrote: > Hi David, > > This seems like an unfair characterization. All requests are submitted > by individuals. In terms of changing these protocols... I beg to differ. The publication request of the original RSVP-TE spec was made *by the MPLS WG*. The publication request of the GMPLS RSVP spec was makde *by the CCAMP WG*. Furthermore, the issue is not who submits the document; it is the degree of scrutiny it gets. *Standards Track* docs go through a much stricter review than informational ones. > The GMPLS RSVP-TE, which is done in IETF, makes major modifications to > RFC3209 and RFC2205 version of RSVP. The rest of the changes been > requested are three new objects, new error codes to support these > objects. This can hardly be characterized as forcibly changing RSVP or > major change in direction... Do you consider deprecating ResvErr and ResvTear not "forcibly changing RSVP or major change in direction"? Kireeti. From owner-mpls@UU.NET Thu Jan 23 13:57:41 2003 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16591 for ; Thu, 23 Jan 2003 13:57:41 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnyxo19584 for ; Thu, 23 Jan 2003 19:00:59 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnyxo19238; Thu, 23 Jan 2003 19:00:50 GMT Received: by mail-control.ash.ops.us.uu.net id QQnyxo11680 for mpls-outgoing; Thu, 23 Jan 2003 19:00:34 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnyxo10800 for ; Thu, 23 Jan 2003 19:00:23 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnyxn03824 for ; Thu, 23 Jan 2003 18:59:12 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnyxn17130 for ; Thu, 23 Jan 2003 18:59:11 GMT Received: from merlot.juniper.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: natint.juniper.net [207.17.136.129]) id QQnyxn17111 for ; Thu, 23 Jan 2003 18:59:10 GMT Received: from kummer.juniper.net (kummer.juniper.net [172.17.12.90]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h0NIx4S67131; Thu, 23 Jan 2003 10:59:04 -0800 (PST) (envelope-from kireeti@juniper.net) Received: from localhost (kireeti@localhost) by kummer.juniper.net (8.11.6/8.9.3) with ESMTP id h0NIx4p84293; Thu, 23 Jan 2003 10:59:04 -0800 (PST) (envelope-from kireeti@juniper.net) X-Authentication-Warning: kummer.juniper.net: kireeti owned process doing -bs Date: Thu, 23 Jan 2003 10:59:04 -0800 (PST) From: Kireeti Kompella To: David Charlap cc: Bob Braden , , , , Subject: Re: IANA Considerations for RSVP In-Reply-To: <3E301FF1.8080605@marconi.com> Message-ID: <20030123105357.M83975-100000@kummer.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk > I must have struck a nerve here, because yours is the second response > I've gotten from somebody who thinks I'm referring to their specific > IETF-approved RSVP extension, even though I specifically said I'm > referring to extensions developed without IETF involvement. If you are under the impression that draft-lin-ccamp-gmpls-ason-rsvpte-04.txt is "IETF approved", I don't blame you. But in fact, it is not (yet). And even if it does get approval, it is as an *Informational* document. But you have struck a nerve with some (and a chord with me :-)) Kireeti. From owner-mpls@UU.NET Thu Jan 23 14:05:31 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16794 for ; Thu, 23 Jan 2003 14:05:30 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnyxo16886 for ; Thu, 23 Jan 2003 19:08:54 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnyxo16654; Thu, 23 Jan 2003 19:08:46 GMT Received: by mail-control.ash.ops.us.uu.net id QQnyxo27048 for mpls-outgoing; Thu, 23 Jan 2003 19:08:14 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnyxo27000 for ; Thu, 23 Jan 2003 19:08:01 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnyxo01094 for ; Thu, 23 Jan 2003 19:06:15 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnyxo00279 for ; Thu, 23 Jan 2003 19:06:07 GMT Received: from rtp-msg-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-msg-core-1.cisco.com [161.44.11.97]) id QQnyxo00243 for ; Thu, 23 Jan 2003 19:06:06 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h0NJ6qAq016263 for ; Thu, 23 Jan 2003 14:06:52 -0500 (EST) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA01963 for ; Thu, 23 Jan 2003 14:06:04 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h0NJ63R12530 for mpls@uu.net; Thu, 23 Jan 2003 14:06:03 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnyxo26483 for ; Thu, 23 Jan 2003 19:04:50 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnyxo25127 for ; Thu, 23 Jan 2003 19:04:23 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnyxo21567 for ; Thu, 23 Jan 2003 19:04:23 GMT Received: from ihemail2.firewall.lucent.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ihemail2.lucent.com [192.11.222.163]) id QQnyxo21548 for ; Thu, 23 Jan 2003 19:04:22 GMT Received: from nj7460exch002h.wins.lucent.com (h135-17-42-35.lucent.com [135.17.42.35]) by ihemail2.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id h0NJ4L327665 for ; Thu, 23 Jan 2003 14:04:21 -0500 (EST) Received: by nj7460exch002h.ho.lucent.com with Internet Mail Service (5.5.2653.19) id ; Thu, 23 Jan 2003 14:04:21 -0500 Message-ID: From: "Lin, Zhi-Wei (Zhi)" To: Kireeti Kompella , "Lin, Zhi-Wei (Zhi)" Cc: David Charlap , Bob Braden , rsvp@ISI.EDU, ccamp@ops.ietf.org, mpls@UU.NET, iana@ISI.EDU, sob@harvard.edu, mankin@psg.com, bwijnen@lucent.com Subject: RE: IANA Considerations for RSVP Date: Thu, 23 Jan 2003 14:04:20 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Hi Kireeti, -----Original Message----- From: Kireeti Kompella [mailto:kireeti@juniper.net] Sent: Thursday, January 23, 2003 1:53 PM To: Lin, Zhi-Wei (Zhi) Cc: David Charlap; Bob Braden; rsvp@ISI.EDU; ccamp@ops.ietf.org; mpls@UU.NET; iana@ISI.EDU; sob@harvard.edu; mankin@psg.com; bwijnen@lucent.com Subject: RE: IANA Considerations for RSVP Hi Zhi, On Thu, 23 Jan 2003, Lin, Zhi-Wei (Zhi) wrote: > Hi David, > > This seems like an unfair characterization. All requests are submitted > by individuals. In terms of changing these protocols... I beg to differ. The publication request of the original RSVP-TE spec was made *by the MPLS WG*. The publication request of the GMPLS RSVP spec was makde *by the CCAMP WG*. Furthermore, the issue is not who submits the document; it is the degree of scrutiny it gets. *Standards Track* docs go through a much stricter review than informational ones. Right. the set of ASON documents are all targeted for informational RFC, though and not standards track. It was recommended that such document should be submitted to assist IANA with codepoint assignment, and that's what was done... In terms of degree of scrutiny, please see Steve's email on the history of trying to get feedback...this was really "like pulling teeth"... > The GMPLS RSVP-TE, which is done in IETF, makes major modifications to > RFC3209 and RFC2205 version of RSVP. The rest of the changes been > requested are three new objects, new error codes to support these > objects. This can hardly be characterized as forcibly changing RSVP or > major change in direction... Do you consider deprecating ResvErr and ResvTear not "forcibly changing RSVP or major change in direction"? I don't understand...where do you see that these are deprecated??? What is said in my document is that these messages we don't create because all teardowns are explicit. But when these are received, then we will take appropriate actions (see document). Do you consider that if we don't transmit a message then this is in violation of the protocol? We're transmitting all messages in accordance with RFC2205/3209/GMPLS-RSVP-TE...There are approximately 20 message types, but GMPLS RSVP-TE only use a sub-set that's important to its function (e.g., DREQ and DREP are not mandatory for GMPLS RSVP-TE)... Kireeti. From owner-mpls@UU.NET Thu Jan 23 14:09:50 2003 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16936 for ; Thu, 23 Jan 2003 14:09:49 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnyxo10215 for ; Thu, 23 Jan 2003 19:13:11 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnyxo09804; Thu, 23 Jan 2003 19:13:00 GMT Received: by mail-control.ash.ops.us.uu.net id QQnyxo28067 for mpls-outgoing; Thu, 23 Jan 2003 19:11:50 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnyxo28053 for ; Thu, 23 Jan 2003 19:11:49 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnyxo23342 for ; Thu, 23 Jan 2003 19:11:08 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnyxo06885 for ; Thu, 23 Jan 2003 19:11:07 GMT Received: from rtp-msg-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-msg-core-1.cisco.com [161.44.11.97]) id QQnyxo06868 for ; Thu, 23 Jan 2003 19:11:06 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h0NJBo96017090 for ; Thu, 23 Jan 2003 14:11:51 -0500 (EST) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA02368 for ; Thu, 23 Jan 2003 14:11:02 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h0NJB2413256 for mpls@uu.net; Thu, 23 Jan 2003 14:11:02 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnyxo27219 for ; Thu, 23 Jan 2003 19:09:06 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnyxo01145 for ; Thu, 23 Jan 2003 19:08:15 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnyxo25004 for ; Thu, 23 Jan 2003 19:08:14 GMT Received: from ihemail2.firewall.lucent.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ihemail2.lucent.com [192.11.222.163]) id QQnyxo24993 for ; Thu, 23 Jan 2003 19:08:14 GMT Received: from nj7460exch002h.wins.lucent.com (h135-17-42-35.lucent.com [135.17.42.35]) by ihemail2.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id h0NJ8C329979 for ; Thu, 23 Jan 2003 14:08:12 -0500 (EST) Received: by nj7460exch002h.ho.lucent.com with Internet Mail Service (5.5.2653.19) id ; Thu, 23 Jan 2003 14:08:12 -0500 Message-ID: From: "Lin, Zhi-Wei (Zhi)" To: Kireeti Kompella , David Charlap Cc: Bob Braden , rsvp@ISI.EDU, ccamp@ops.ietf.org, mpls@UU.NET, iana@ISI.EDU Subject: RE: IANA Considerations for RSVP Date: Thu, 23 Jan 2003 14:08:09 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Hi Kireeti, Please visit the IESG page, go to I-D tracker, and search under the document... If you don't know this site, here it is: https://datatracker.ietf.org/public/pidtracker.cgi Under filename, search for "draft-lin" Then hit the "Detail" button under the "In State: RFC Editor Queue" header. I guess some IETF WG chairs don't pay attention to this... Zhi -----Original Message----- From: Kireeti Kompella [mailto:kireeti@juniper.net] Sent: Thursday, January 23, 2003 1:59 PM To: David Charlap Cc: Bob Braden; rsvp@ISI.EDU; ccamp@ops.ietf.org; mpls@UU.NET; iana@ISI.EDU Subject: Re: IANA Considerations for RSVP > I must have struck a nerve here, because yours is the second response > I've gotten from somebody who thinks I'm referring to their specific > IETF-approved RSVP extension, even though I specifically said I'm > referring to extensions developed without IETF involvement. If you are under the impression that draft-lin-ccamp-gmpls-ason-rsvpte-04.txt is "IETF approved", I don't blame you. But in fact, it is not (yet). And even if it does get approval, it is as an *Informational* document. But you have struck a nerve with some (and a chord with me :-)) Kireeti. From owner-mpls@UU.NET Thu Jan 23 14:14:50 2003 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17107 for ; Thu, 23 Jan 2003 14:14:49 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnyxp19829 for ; Thu, 23 Jan 2003 19:18:02 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnyxp18831; Thu, 23 Jan 2003 19:17:34 GMT Received: by mail-control.ash.ops.us.uu.net id QQnyxp29018 for mpls-outgoing; Thu, 23 Jan 2003 19:17:03 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnyxp28999 for ; Thu, 23 Jan 2003 19:17:02 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnyxp00174 for ; Thu, 23 Jan 2003 19:15:03 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnyxp04275 for ; Thu, 23 Jan 2003 19:15:02 GMT Received: from mailb.telia.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailb.telia.com [194.22.194.6]) id QQnyxp04228 for ; Thu, 23 Jan 2003 19:15:01 GMT Received: from d1o888.telia.com (d1o888.telia.com [213.67.172.241]) by mailb.telia.com (8.12.5/8.12.5) with ESMTP id h0NJEton029410; Thu, 23 Jan 2003 20:14:55 +0100 (CET) X-Original-Recipient: mpls@UU.NET Received: from pi.se (h70n2fls31o888.telia.com [213.64.120.70]) by d1o888.telia.com (8.10.2/8.10.1) with ESMTP id h0NJEt220977; Thu, 23 Jan 2003 20:14:55 +0100 (CET) Message-ID: <3E303D9A.70406@pi.se> Date: Thu, 23 Jan 2003 20:08:10 +0100 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Seisho Yasukawa CC: "'mpls@UU.NET'" Subject: Re: draft-yasukawa-mpls-rsvp-p2mp-00.txt References: <5.0.2.5.2.20030123124146.04f7a6d8@imc.m.ecl.ntt.co.jp> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit All, I've received a couple of questions if this is a working group draft. Answer is that it is not, a previous draft was presented in Atlanta and (I think in Yokohama), the name change makes it go back to -00. In Atlanta we said that "the discusion will contiune on the list". Possibly the misunderstanding comes from the first line in the mail: "Please note that the following draft has been newly posted to MPLS WG." my understanding here is that this a request from the authors to have comments on the draft and discusion on the subject matter. /Loa Seisho Yasukawa wrote: > Hello everyone, > > Please note that the following draft has been newly posted to MPLS WG. > > Extended RSVP-TE for Point-to-Multipoint LSP Tunnels > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-yasukawa-mpls-rsvp-p2mp-00.txt > > This draft specifies the extension to RSVP-TE signaling protocol > in support of MPLS P2MP LSP creation/deletion and Leaf initiated > Join/Leave signaling. > > We think P2MP MPLS technology will become increasingly important > with the dissemination of new, real-time application, such as content > delivery services and video conference, which require P2MP real-time > transmission capability with much more bandwidth and stricter QoS > control mechanism than conventional IP application. > > We NTT as a service provider really needs this kind of P2MP MPLS > technology because this technology opens the possibility to offer > our customer a new broadband service. > > We think discussion of P2MP technology agrees with the charter of this wg. > And, we found that applications of "multicast explicit routing"are a target > topic for "RSVP-TE "(RFC3209, Section 4.3.1) and "IP Multicast in a MPLS > Environment"(RFC3353, Section.7) > > Therefore, we want to discuss this P2MP MPLS technology in this wg. > > Please give us any comments from technology, application and operation > sides. > > We need a lot of discussion and advice for protocol architecture to improve > this architecture. > > > Thanks > > Seisho > > ------------------------------------------------------------ > Please refere followings (contents of this draft). > > This draft include the contents of "draft-yasukawa-mpls-rsvp-p2mp-01". > In this new draft, protocol architecture is modified and the protocol name > was changed from "multicast" to "P2MP" to clarify the technology > difference. > > Section 0 describes why this draft suit to this wg. > Please see sec.0.4 to know the reason why we introduce P2MP tunnel > without IP multicast. > > Section 4 describes the architecture of this protocol. > The new concepts; P2MP LSP tunnel and TERO/TRRO are newly introduced. > The TERO is main architecture to realize P2MP TE LSP. > > Section 5 - 7 describes the detailed signaling mechanisms. > > Section 11 shows the difference between RSVP multicasting and P2MP > TE tunnels. > > We describe the difference between multicast LSP realized by > RSVP-TE&IP multicasting and P2MP TE LSP realized by TERO. > --------------------------------------------------------------- > > > -- Loa Andersson Mobile +46 739 81 21 64 Email loa@pi.se From owner-mpls@UU.NET Thu Jan 23 14:19:41 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17325 for ; Thu, 23 Jan 2003 14:19:41 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnyxp05832 for ; Thu, 23 Jan 2003 19:23:06 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnyxp05607; Thu, 23 Jan 2003 19:23:01 GMT Received: by mail-control.ash.ops.us.uu.net id QQnyxp29653 for mpls-outgoing; Thu, 23 Jan 2003 19:22:31 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnyxp29642 for ; Thu, 23 Jan 2003 19:22:23 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnyxp24021 for ; Thu, 23 Jan 2003 19:21:13 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnyxp03669 for ; Thu, 23 Jan 2003 19:21:12 GMT Received: from hoemail2.firewall.lucent.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: hoemail2.lucent.com [192.11.226.163]) id QQnyxp03665 for ; Thu, 23 Jan 2003 19:21:12 GMT Received: from mvmail.mv.lucent.com (h135-13-96-58.lucent.com [135.13.96.58]) by hoemail2.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id h0NJKOi20587; Thu, 23 Jan 2003 14:20:24 -0500 (EST) Received: from lucent.com (ma0940xuyg.mv.lucent.com [135.13.58.32]) by mvmail.mv.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id OAA18520; Thu, 23 Jan 2003 14:20:22 -0500 (EST) Message-ID: <3E304076.D5AF0CAF@lucent.com> Date: Thu, 23 Jan 2003 14:20:22 -0500 From: Yangguang Xu Organization: Lucent Technologies, Inc. X-Mailer: Mozilla 4.7 [en]C-EMS-1.4 (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: Kireeti Kompella CC: "Lin, Zhi-Wei (Zhi)" , David Charlap , Bob Braden , rsvp@ISI.EDU, ccamp@ops.ietf.org, mpls@UU.NET, iana@ISI.EDU, sob@harvard.edu, mankin@psg.com, bwijnen@lucent.com Subject: Re: IANA Considerations for RSVP References: <20030123104246.W83975-100000@kummer.juniper.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Kireeti, > > The GMPLS RSVP-TE, which is done in IETF, makes major modifications to > > RFC3209 and RFC2205 version of RSVP. The rest of the changes been > > requested are three new objects, new error codes to support these > > objects. This can hardly be characterized as forcibly changing RSVP or > > major change in direction... > > Do you consider deprecating ResvErr and ResvTear not "forcibly changing > RSVP or major change in direction"? > Well, it's my turn to beg to differ :) If you read the document && understand it && don't take any prejudice, then it may be more like specifying rules for using a protocol for an application with some hard requirements. Regards, Yangguang From owner-mpls@UU.NET Thu Jan 23 14:31:40 2003 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17898 for ; Thu, 23 Jan 2003 14:31:39 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnyxq24897 for ; Thu, 23 Jan 2003 19:35:03 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnyxq24587; Thu, 23 Jan 2003 19:34:54 GMT Received: by mail-control.ash.ops.us.uu.net id QQnyxq00648 for mpls-outgoing; Thu, 23 Jan 2003 19:34:27 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnyxq00643 for ; Thu, 23 Jan 2003 19:34:11 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnyxq07758 for ; Thu, 23 Jan 2003 19:31:34 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnyxq18815 for ; Thu, 23 Jan 2003 19:31:33 GMT Received: from lightwave.chromisys.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: lightwave.chromisys.com [63.102.55.206]) id QQnyxq18808 for ; Thu, 23 Jan 2003 19:31:33 GMT Received: by lightwave.chromisys.com with Internet Mail Service (5.5.2653.19) id <4GJZ1WMA>; Thu, 23 Jan 2003 11:31:32 -0800 Message-ID: <9D42C6E086250248810DCADA39CE7EFC97217E@nimbus> From: John Drake To: "'Stephen Trowbridge'" , David Charlap Cc: Brian Hassink , Bob Braden , rsvp@ISI.EDU, ccamp@ops.ietf.org, mpls@UU.NET, kireeti@juniper.net, iana@ISI.EDU, sob@harvard.edu, mankin@psg.com, bwijnen@lucent.com Subject: RE: IANA Considerations for RSVP Date: Thu, 23 Jan 2003 11:31:30 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Stephen, I appreciate all the work you've done keep the IETF informed about what the ITU is doing. All I can say is that it doesn't seem to have worked. Rather than continuing to give us status reports on what the ITU is doing, I think it would make more sense to do the work in the appropriate IETF working groups. That was what I thought was the intent of the Feb 19th Liason: "We wish that as we continue our review of these protocols you will be able to provide us with recommendations on how to close these and future issues." However, a channel of communication has not been established: how should recommendations and issues be communicated? Who makes these, and who communicates them? How does a two-way (or n-way) dialog take place? If, on the other hand, these documents were brought into an IETF WG, the procedures and channels of communication exist and are well-known. Thanks, John -----Original Message----- From: Stephen Trowbridge [mailto:sjtrowbridge@lucent.com] Sent: Thursday, January 23, 2003 9:21 AM To: David Charlap Cc: Brian Hassink; Bob Braden; rsvp@ISI.EDU; ccamp@ops.ietf.org; mpls@UU.NET; kireeti@juniper.net; iana@ISI.EDU; sob@harvard.edu; mankin@psg.com; bwijnen@lucent.com Subject: Re: IANA Considerations for RSVP David, To read these emails, it sounds as though you think that the people who are doing this are brand new to the technology and never even considered working with IETF to try to solve the problem. Perhaps you haven't followed the ccamp work so closely, but here is some history: - On October 21, 2001, ITU-T Study Group 15 sent IETF ccamp a liaison statement regarding our new documents with requirements and architecture for switched (not necessarily IP) transport networks. This included a protocol- neutral model for call and connection management (signaling). In copies of the ITU-T documents were made available to non-ITU-T members via an ftp site. The liaison was placed on the IESG web site and was presented in the ccamp meeting in Salt Lake City in December. At that same meeting, Maarten Vissers gave a technical presentation in the sub-IP area meeting regarding the ITU-T work in this area. - On February 19, 2002, ITU-T sent IETF ccamp a liaison statement regarding the gaps that had been identified between the ITU-T requirements (sent earlier) and what seemed to be implemented by the GMPLS protocols. Specifically, 1. Call & Connection separation, e.g., a call provides the service relationship, which may support connection operations as part of a call. 2. Additional error codes/values, for example, for connection rejection (invalid connection ID). 3. Restart mechanisms: Depending on the introduction by the ITU of additional control plane resiliency requirements, enhancements of the protocol (RSVP-TE, CR-LDP) "graceful restart" mechanisms may be required. 4. Protocol enhancements in CR-LDP for support of crankback capability from intermediate nodes. This liaison was presented in the Minneapolis IETF meeting during the ccamp working group and posted on the IESG web site. The liaison requested assistance in closing these gaps and invited input from IETF on our work in ITU-T. - At the April/May 2002 meeting of ITU-T Study Group 15 meeting, contributions were considered to close these gaps, resulting in text for draft Recommendations G.7713.2 (our rsvp-te document) and G.7713.3 (our cr-ldp document). Again, we sent a liaison (dated May 10, 2002) to ask for comments on our draft Recommendations (made available on the ftp site), to request alignment, and to ask for IANA code point assignments. To quote from that liaison: "Please consider including the proposed solutions provided in G.7713.2 and G.7713.3 to update the existing GMPLS signaling work in support of ASON requirements. We hope that you can help expedite the assignment of appropriate additional error codes/values by IANA. These are needed for both RSVP-TE and CR-LDP." This liaison was presented at the Yokohama IETF ccamp meeting. To refer to one point raised earlier in the thread, there are other cases where IANA has assigned codepoints for work outside of IETF, including other CCITT/ITU-T work, IEEE, IEC, etc. This request had been made last May, with no response. - Some final work was done on our drafts at a Rapporteur meeting in October, with one result being another liaison (dated October 11, 2002) making another plea for comments and help getting the codepoints assigned. This liaison was presented at the Atlanta IETF ccamp meeting, and still no response or IANA action. To hear now that someone thinks that the ASON work in ITU-T is some kind of secret end-run around IETF, and not involved with or related to the work being done internally in IETF is absurd. At every stage of the work, IETF was kept informed of the work and invited to participate. At the invitation for help to address the additional ITU-T requirements, there was no response. As ITU-T progressed this work and invited further comments and alignment of the base GMPLS protocols, again no response. And to the final pleas for comments and codepoint assignments, no response. I contrast this with our interaction with the ATM forum on the same topic. Certain operators in ITU-T are interested in using the PNNI protocol for this application (rather than rsvp-te or cr-ldp). The ATM forum has responded with a formal liaison into the current ITU-T Study Group 15 meeting where they have given us a diffmarked copy with extremely helpful and constructive suggestions about how to align our G.7713.1 document with their work. After some private communication with the Area directors, we received some advice that one tool that might be used to finally get the IANA codepoint assignment complete would be to publish what we were doing in ITU-T as informational RFCs. This is the stage we are at today, and given the history I describe above, I do not think anybody can say that we are at this point because any of us did not do everything possible to do this work (a) in IETF, with the initial communication of requirements; or (b) in cooperation between ITU-T and IETF, once this work had progressed in ITU-T. But this is all water under the bridge. We are at the point of trying to get some codepoints assigned for ITU-T documents we are trying to complete. Nobody should say "no" at this point because they think we didn't try to work this IN or WITH IETF first. It should be clear to all that this is not the case. Regards, Steve Trowbridge (vice-chairman, ITU-T Study Group 15) David Charlap wrote: > > Brian Hassink wrote: > > Didn't the IETF set the precedent by extending RSVP from an IntServ protocol to an MPLS protocol? > > There's a big difference. MPLS and IntServ are both IETF groups. (And > RSVP has/had its own working group anyway). Also, most of the key RSVP > people were involved in the development of RSVP-TE. > > This is very different from what I'm describing - where people who have > no prior RSVP experience decide that they can start changing it without > understing it, and without even notifying the IETF groups that did all > of the development work. > > I'mnot saying that RSVP should never be extended. I'm saying that those > groups that are writing extensions should be consulting with those who > have been developing and maintaining it (in the RSVP and MPLS groups) in > order to ensure that: > - Their goal can't be achieved without extending the language > - That their extension doesn't overlap a similar extension > from somebody else. > - That their extension doesn't significantly change the overall > semantics of RSVP. > - That their extension is sufficiently flexible so that other > groups can build off of it instead of re-inventing the wheel > with yet another incompatible extension. > > Not only isn't this happening, but there appears to be no desire to see > this happen. > > -- David From owner-mpls@UU.NET Thu Jan 23 15:18:57 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19104 for ; Thu, 23 Jan 2003 15:18:56 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnyxt29177 for ; Thu, 23 Jan 2003 20:22:22 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnyxt28415; Thu, 23 Jan 2003 20:22:04 GMT Received: by mail-control.ash.ops.us.uu.net id QQnyxt22493 for mpls-outgoing; Thu, 23 Jan 2003 20:21:51 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnyxt22484 for ; Thu, 23 Jan 2003 20:21:43 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnyxt27136 for ; Thu, 23 Jan 2003 20:21:12 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnyxt01337 for ; Thu, 23 Jan 2003 20:21:11 GMT Received: from mailgate.pit.comms.marconi.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6]) id QQnyxt01323 for ; Thu, 23 Jan 2003 20:21:10 GMT Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA16874; Thu, 23 Jan 2003 15:17:22 -0500 (EST) Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA28631; Thu, 23 Jan 2003 15:17:22 -0500 (EST) Message-ID: <3E304DF6.1070505@marconi.com> Date: Thu, 23 Jan 2003 15:17:58 -0500 From: David Charlap Organization: Marconi, Vienna VA User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en, he MIME-Version: 1.0 To: GraIyMag@GraIyMage.com CC: Bob Braden , rsvp@ISI.EDU, ccamp@ops.ietf.org, mpls@UU.NET, kireeti@juniper.net, iana@ISI.EDU, sob@harvard.edu, mankin@psg.com, bwijnen@lucent.com Subject: Re: IANA Considerations for RSVP References: <200301222140.VAA00937@gra.isi.edu> <3E301086.3000002@marconi.com> <3E30260A.82698500@GraIyMage.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Eric Gray wrote: > > The intent to build a new protocol, rather than bastardize an existing > one has gotten a very large number of people burned in recent times. I > can't say as I blame external organizations - who, in almost every case, > have mostly only seen the flames from prior efforts coloring the sky - > from opting to modify an existing protocol. > > We shouldn't chastise people for making what they feel are the best > choices based on the evidence in front of them. We should instead try > to determine what they are missing, or otherwise help them to modify > those choices. :-) You miss my point. I'm not saying that groups should always build new protocols. Sometimes, there are perfectly good reasons to extend an existing protocol (like GMPLS extended RSVP-TE). But when this is done, it should be done in conjunction with those responsible for the original protocol. A third-party (like IEEE, ITU, ATM Forum, ISO, etc.) should never grab an IETF protocol and make changes to it without involving the appropriate IETF group. (And I am not accusing any organization - these are just examples of the third parties I'm referring to. I am not talking about different groups within the IETF.) This goes the other way around as well. Just as IEEE would object to the IETF unilaterally defining an extension to FireWire (IEEE-1392) protocol, the IETF should similarly object to some outside organization unilaterally defining an extension to IP, or RSVP, etc. Now, I am not saying that every single third-party extension has done this. I am well aware of the fact that some groups do work with the IETF on their extensions. This is good. This is the way it should be. But there are other groups that do not. If your (now speaking to everybody reading this message) group's extension was developed in conjungtion with the IETF, then my criticism is not directed at you, and you should not take offense at my opinion. -- David From owner-mpls@UU.NET Thu Jan 23 15:29:06 2003 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19341 for ; Thu, 23 Jan 2003 15:29:04 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnyxu22243 for ; Thu, 23 Jan 2003 20:32:26 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnyxu21982; Thu, 23 Jan 2003 20:32:18 GMT Received: by mail-control.ash.ops.us.uu.net id QQnyxu23374 for mpls-outgoing; Thu, 23 Jan 2003 20:31:49 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnyxu23369 for ; Thu, 23 Jan 2003 20:31:48 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnyxu15028 for ; Thu, 23 Jan 2003 20:30:11 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnyxu19811 for ; Thu, 23 Jan 2003 20:30:10 GMT Received: from rtp-msg-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-msg-core-1.cisco.com [161.44.11.97]) id QQnyxu19732 for ; Thu, 23 Jan 2003 20:30:09 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h0NKUp9C001704 for ; Thu, 23 Jan 2003 15:30:55 -0500 (EST) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id PAA10853 for ; Thu, 23 Jan 2003 15:30:03 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h0NKU3v21978 for mpls@uu.net; Thu, 23 Jan 2003 15:30:03 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnyxt23076 for ; Thu, 23 Jan 2003 20:29:15 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnyxt08225 for ; Thu, 23 Jan 2003 20:28:16 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnyxt17826 for ; Thu, 23 Jan 2003 20:28:15 GMT Received: from hoemail1.firewall.lucent.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: hoemail1.lucent.com [192.11.226.161]) id QQnyxt17818 for ; Thu, 23 Jan 2003 20:28:15 GMT Received: from nj7460exch002h.wins.lucent.com (h135-17-42-35.lucent.com [135.17.42.35]) by hoemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id h0NKSDF02062 for ; Thu, 23 Jan 2003 15:28:14 -0500 (EST) Received: by nj7460exch002h.ho.lucent.com with Internet Mail Service (5.5.2653.19) id ; Thu, 23 Jan 2003 15:28:13 -0500 Message-ID: From: "Lin, Zhi-Wei (Zhi)" To: Kireeti Kompella , "Lin, Zhi-Wei (Zhi)" Cc: Bob Braden , ccamp@ops.ietf.org, mpls@UU.NET, iana@ISI.EDU Subject: RE: IANA Considerations for RSVP Date: Thu, 23 Jan 2003 15:28:12 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Hi Kireeti, I didn't mean to imply what you said. I apologize if I offended you. Just that the site was not very well publicized by the IESG. I only became aware of it after someone pointed me to it. Zhi -----Original Message----- From: Kireeti Kompella [mailto:kireeti@juniper.net] Sent: Thursday, January 23, 2003 3:22 PM To: Lin, Zhi-Wei (Zhi) Cc: Bob Braden; ccamp@ops.ietf.org; mpls@UU.NET; iana@ISI.EDU Subject: RE: IANA Considerations for RSVP Hi Zhi, On Thu, 23 Jan 2003, Lin, Zhi-Wei (Zhi) wrote: > Please visit the IESG page, go to I-D tracker, and search under the > document... I just did. Oh, well. > I guess some IETF WG chairs don't pay attention to this... And you're implying? My imcompetence, or the fact that this is not the product of a WG? But you're right, this has been approved by the IETF. More accurately, as the email to IETF announce says, by the IESG. Kireeti. From owner-mpls@UU.NET Thu Jan 23 15:36:01 2003 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19495 for ; Thu, 23 Jan 2003 15:36:00 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnyxu22335 for ; Thu, 23 Jan 2003 20:39:25 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnyxu22109; Thu, 23 Jan 2003 20:39:20 GMT Received: by mail-control.ash.ops.us.uu.net id QQnyxu24041 for mpls-outgoing; Thu, 23 Jan 2003 20:38:52 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnyxu24009 for ; Thu, 23 Jan 2003 20:38:47 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnyxu11707 for ; Thu, 23 Jan 2003 20:37:24 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnyxu08204 for ; Thu, 23 Jan 2003 20:37:24 GMT Received: from xover.netplane.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: fwout.maker.com [12.27.183.253] (may be forged)) id QQnyxu08159 for ; Thu, 23 Jan 2003 20:37:23 GMT Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2653.19) id <4B0HTT3R>; Thu, 23 Jan 2003 15:37:15 -0500 Message-ID: <076236BAE727D611943F00508BA0F95906EA14@XOVER.dedham.mindspeed.com> From: "Kullberg, Alan" To: "'Loa Andersson'" , "Yasukawa, Seisho" Cc: "'mpls@UU.NET'" Subject: RE: draft-yasukawa-mpls-rsvp-p2mp-00.txt Date: Thu, 23 Jan 2003 15:37:13 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Hi Loa, You are correct on all points. We would like feedback and discussion regarding our draft. Thanks, Alan > -----Original Message----- > From: Loa Andersson [mailto:loa@pi.se] > Sent: Thursday, January 23, 2003 2:08 PM > To: Seisho Yasukawa > Cc: 'mpls@UU.NET' > Subject: Re: draft-yasukawa-mpls-rsvp-p2mp-00.txt > > > All, > > I've received a couple of questions if this is a working group draft. > Answer is that it is not, a previous draft was presented in Atlanta > and (I think in Yokohama), the name change makes it go back to -00. > In Atlanta we said that "the discusion will contiune on the list". > > Possibly the misunderstanding comes from the first line in > the mail: > "Please note that the following draft has been newly posted > to MPLS WG." > > my understanding here is that this a request from the authors to > have comments on the draft and discusion on the subject matter. > > /Loa > > > Seisho Yasukawa wrote: > > Hello everyone, > > > > Please note that the following draft has been newly posted > to MPLS WG. > > > > Extended RSVP-TE for Point-to-Multipoint LSP Tunnels > > > > > > A URL for this Internet-Draft is: > > > http://www.ietf.org/internet-drafts/draft-yasukawa-mpls-rsvp-p > 2mp-00.txt > > > > This draft specifies the extension to RSVP-TE signaling protocol > > in support of MPLS P2MP LSP creation/deletion and Leaf initiated > > Join/Leave signaling. > > > > We think P2MP MPLS technology will become increasingly important > > with the dissemination of new, real-time application, such > as content > > delivery services and video conference, which require P2MP real-time > > transmission capability with much more bandwidth and stricter QoS > > control mechanism than conventional IP application. > > > > We NTT as a service provider really needs this kind of P2MP MPLS > > technology because this technology opens the possibility to offer > > our customer a new broadband service. > > > > We think discussion of P2MP technology agrees with the > charter of this wg. > > And, we found that applications of "multicast explicit > routing"are a target > > topic for "RSVP-TE "(RFC3209, Section 4.3.1) and "IP > Multicast in a MPLS > > Environment"(RFC3353, Section.7) > > > > Therefore, we want to discuss this P2MP MPLS technology in this wg. > > > > Please give us any comments from technology, application > and operation > > sides. > > > > We need a lot of discussion and advice for protocol > architecture to improve > > this architecture. > > > > > > Thanks > > > > Seisho > > > > ------------------------------------------------------------ > > Please refere followings (contents of this draft). > > > > This draft include the contents of > "draft-yasukawa-mpls-rsvp-p2mp-01". > > In this new draft, protocol architecture is modified and > the protocol name > > was changed from "multicast" to "P2MP" to clarify the technology > > difference. > > > > Section 0 describes why this draft suit to this wg. > > Please see sec.0.4 to know the reason why we introduce P2MP tunnel > > without IP multicast. > > > > Section 4 describes the architecture of this protocol. > > The new concepts; P2MP LSP tunnel and TERO/TRRO are newly > introduced. > > The TERO is main architecture to realize P2MP TE LSP. > > > > Section 5 - 7 describes the detailed signaling mechanisms. > > > > Section 11 shows the difference between RSVP multicasting and P2MP > > TE tunnels. > > > > We describe the difference between multicast LSP realized by > > RSVP-TE&IP multicasting and P2MP TE LSP realized by TERO. > > --------------------------------------------------------------- > > > > > > > > > -- > Loa Andersson > > Mobile +46 739 81 21 64 > Email loa@pi.se > > From owner-mpls@UU.NET Thu Jan 23 17:28:34 2003 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22128 for ; Thu, 23 Jan 2003 17:28:33 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnyyc22834 for ; Thu, 23 Jan 2003 22:31:54 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnyyc22612; Thu, 23 Jan 2003 22:31:48 GMT Received: by mail-control.ash.ops.us.uu.net id QQnyyc10130 for mpls-outgoing; Thu, 23 Jan 2003 22:31:31 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnyyc10124 for ; Thu, 23 Jan 2003 22:31:28 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnyyb06446 for ; Thu, 23 Jan 2003 22:29:07 GMT Received: from merlot.juniper.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: natint.juniper.net [207.17.136.129]) id QQnyxt28847 for ; Thu, 23 Jan 2003 20:22:14 GMT Received: from kummer.juniper.net (kummer.juniper.net [172.17.12.90]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h0NKM8S75012; Thu, 23 Jan 2003 12:22:08 -0800 (PST) (envelope-from kireeti@juniper.net) Received: from localhost (kireeti@localhost) by kummer.juniper.net (8.11.6/8.9.3) with ESMTP id h0NKM8d84795; Thu, 23 Jan 2003 12:22:08 -0800 (PST) (envelope-from kireeti@juniper.net) X-Authentication-Warning: kummer.juniper.net: kireeti owned process doing -bs Date: Thu, 23 Jan 2003 12:22:08 -0800 (PST) From: Kireeti Kompella To: "Lin, Zhi-Wei (Zhi)" cc: Bob Braden , , , Subject: RE: IANA Considerations for RSVP In-Reply-To: Message-ID: <20030123115259.C84637-100000@kummer.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Hi Zhi, On Thu, 23 Jan 2003, Lin, Zhi-Wei (Zhi) wrote: > Please visit the IESG page, go to I-D tracker, and search under the > document... I just did. Oh, well. > I guess some IETF WG chairs don't pay attention to this... And you're implying? My imcompetence, or the fact that this is not the product of a WG? But you're right, this has been approved by the IETF. More accurately, as the email to IETF announce says, by the IESG. Kireeti. From owner-mpls@UU.NET Thu Jan 23 18:23:38 2003 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24075 for ; Thu, 23 Jan 2003 18:23:38 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnyyf14619 for ; Thu, 23 Jan 2003 23:27:03 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnyyf14420; Thu, 23 Jan 2003 23:26:58 GMT Received: by mail-control.ash.ops.us.uu.net id QQnyyf02852 for mpls-outgoing; Thu, 23 Jan 2003 23:26:39 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnyyf02841 for ; Thu, 23 Jan 2003 23:26:36 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnyyf11318 for ; Thu, 23 Jan 2003 23:26:13 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnyyf15922 for ; Thu, 23 Jan 2003 23:26:13 GMT Received: from ihemail1.firewall.lucent.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ihemail1.lucent.com [192.11.222.161]) id QQnyyf15907 for ; Thu, 23 Jan 2003 23:26:12 GMT Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id h0NNQ4705876; Thu, 23 Jan 2003 18:26:04 -0500 (EST) Received: from lucent.com ([135.248.116.65]) by ihmail.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id RAA02764; Thu, 23 Jan 2003 17:25:57 -0600 (CST) Message-ID: <3E3079AF.3010ED7C@lucent.com> Date: Thu, 23 Jan 2003 16:24:31 -0700 From: Stephen Trowbridge Organization: Lucent Technologies X-Mailer: Mozilla 4.76 [en]C-CCK-MCD EMS-1.5 (Windows NT 5.0; U) X-Accept-Language: en,zh MIME-Version: 1.0 To: John Drake CC: David Charlap , Brian Hassink , Bob Braden , rsvp@ISI.EDU, ccamp@ops.ietf.org, mpls@UU.NET, kireeti@juniper.net, iana@ISI.EDU, sob@harvard.edu, mankin@psg.com, bwijnen@lucent.com Subject: Re: IANA Considerations for RSVP References: <9D42C6E086250248810DCADA39CE7EFC97217E@nimbus> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit John, Hmmm... a bit IETF centric. Because some portion of a problem space touches or uses an IETF protocol, then clearly the entire problem must belong to IETF. Consider that the ASON architecture encompasses transport networks where what we call the transport plane (IETF calls the data plane) is not necessarily IP. What if the addresses are NSAP addresses instead of IP addresses? What if some or all of the signaling links employ PNNI as a signaling protocol instead of RSVP-TE or CR-LDP? Does it still all belong to IETF? These are problems that cannot be solved without good cooperation between the standards organizations that are involved. In terms of the existance of a communication channel and procedures for collaborating between IETF and ITU-T, this exists but perhaps, in spite of receiving these liaisons, you have not taken the trouble to become familiar with it. Identical text describing the collaboration process is published as RFC 3356 in IETF and as A.Sup3 in ITU-T. We are following the documented process, and this suggests a different answer than your emails to the question of which side of this communication channel is not holding up their end. Steve John Drake wrote: > > Stephen, > > I appreciate all the work you've done keep the IETF informed about what the > ITU is doing. All I can say is that it doesn't seem to have worked. Rather > than continuing to give us status reports on what the ITU is doing, I think > it would make more sense to do the work in the appropriate IETF working > groups. > > That was what I thought was the intent of the Feb 19th Liason: "We wish that > as we continue our review of these protocols you will be able to provide us > with recommendations on how to close these and future issues." However, a > channel of communication has not been established: how should > recommendations and issues be communicated? Who makes these, and who > communicates them? How does a two-way (or n-way) dialog take place? > > If, on the other hand, these documents were brought into an IETF WG, the > procedures and channels of communication exist and are well-known. > > Thanks, > > John > > -----Original Message----- > From: Stephen Trowbridge [mailto:sjtrowbridge@lucent.com] > Sent: Thursday, January 23, 2003 9:21 AM > To: David Charlap > Cc: Brian Hassink; Bob Braden; rsvp@ISI.EDU; ccamp@ops.ietf.org; > mpls@UU.NET; kireeti@juniper.net; iana@ISI.EDU; sob@harvard.edu; > mankin@psg.com; bwijnen@lucent.com > Subject: Re: IANA Considerations for RSVP > > David, > To read these emails, it sounds as though you think that the people who > are doing this are brand new to the technology and never even considered > working with IETF to try to solve the problem. Perhaps you haven't followed > the ccamp work so closely, but here is some history: > - On October 21, 2001, ITU-T Study Group 15 sent IETF ccamp a liaison > statement > regarding our new documents with requirements and architecture for > switched (not necessarily IP) transport networks. This included a > protocol- > neutral model for call and connection management (signaling). In copies > of the ITU-T documents were made available to non-ITU-T members via an > ftp site. The liaison was placed on the IESG web site and was presented > in the ccamp meeting in Salt Lake City in December. At that same meeting, > Maarten Vissers gave a technical presentation in the sub-IP area meeting > regarding the ITU-T work in this area. > - On February 19, 2002, ITU-T sent IETF ccamp a liaison statement regarding > the gaps that had been identified between the ITU-T requirements (sent > earlier) and what seemed to be implemented by the GMPLS protocols. > Specifically, > 1. Call & Connection separation, e.g., a call provides the service > relationship, which may support connection operations as part of a > call. > 2. Additional error codes/values, for example, for connection rejection > (invalid connection ID). > 3. Restart mechanisms: Depending on the introduction by the ITU of > additional > control plane resiliency requirements, enhancements of the protocol > (RSVP-TE, CR-LDP) "graceful restart" mechanisms may be required. > 4. Protocol enhancements in CR-LDP for support of crankback capability > from > intermediate nodes. > This liaison was presented in the Minneapolis IETF meeting during the > ccamp > working group and posted on the IESG web site. The liaison requested > assistance in closing these gaps and invited input from IETF on our work > in ITU-T. > - At the April/May 2002 meeting of ITU-T Study Group 15 meeting, > contributions > were considered to close these gaps, resulting in text for draft > Recommendations > G.7713.2 (our rsvp-te document) and G.7713.3 (our cr-ldp document). Again, > we sent a liaison (dated May 10, 2002) to ask for comments on our draft > Recommendations (made available on the ftp site), to request alignment, > and > to ask for IANA code point assignments. To quote from that liaison: > "Please consider including the proposed solutions provided in G.7713.2 and > G.7713.3 > to update the existing GMPLS signaling work in support of ASON requirements. > We hope that you can help expedite the assignment of appropriate additional > error codes/values by IANA. These are needed for both RSVP-TE and CR-LDP." > This liaison was presented at the Yokohama IETF ccamp meeting. > > To refer to one point raised earlier in the thread, there are other cases > where IANA has assigned codepoints for work outside of IETF, including > other CCITT/ITU-T work, IEEE, IEC, etc. This request had been made last > May, with no response. > - Some final work was done on our drafts at a Rapporteur meeting in October, > with one result being another liaison (dated October 11, 2002) making > another plea for comments and help getting the codepoints assigned. This > liaison was presented at the Atlanta IETF ccamp meeting, and still no > response or IANA action. > > To hear now that someone thinks that the ASON work in ITU-T is some kind > of secret end-run around IETF, and not involved with or related to the > work being done internally in IETF is absurd. At every stage of the work, > IETF was kept informed of the work and invited to participate. At the > invitation for help to address the additional ITU-T requirements, there > was no response. As ITU-T progressed this work and invited further comments > and alignment of the base GMPLS protocols, again no response. And to the > final pleas for comments and codepoint assignments, no response. > > I contrast this with our interaction with the ATM forum on the same topic. > Certain operators in ITU-T are interested in using the PNNI protocol for > this application (rather than rsvp-te or cr-ldp). The ATM forum has > responded with a formal liaison into the current ITU-T Study Group 15 > meeting where they have given us a diffmarked copy with extremely > helpful and constructive suggestions about how to align our G.7713.1 > document with their work. > > After some private communication with the Area directors, we received some > advice that one tool that might be used to finally get the IANA codepoint > assignment complete would be to publish what we were doing in ITU-T as > informational RFCs. This is the stage we are at today, and given the > history I describe above, I do not think anybody can say that we are > at this point because any of us did not do everything possible to > do this work (a) in IETF, with the initial communication of requirements; > or (b) in cooperation between ITU-T and IETF, once this work had > progressed in ITU-T. > > But this is all water under the bridge. We are at the point of trying > to get some codepoints assigned for ITU-T documents we are trying to > complete. Nobody should say "no" at this point because they think we > didn't try to work this IN or WITH IETF first. It should be clear to > all that this is not the case. > Regards, > Steve Trowbridge > (vice-chairman, ITU-T Study Group 15) > > David Charlap wrote: > > > > Brian Hassink wrote: > > > Didn't the IETF set the precedent by extending RSVP from an IntServ > protocol to an MPLS protocol? > > > > There's a big difference. MPLS and IntServ are both IETF groups. (And > > RSVP has/had its own working group anyway). Also, most of the key RSVP > > people were involved in the development of RSVP-TE. > > > > This is very different from what I'm describing - where people who have > > no prior RSVP experience decide that they can start changing it without > > understing it, and without even notifying the IETF groups that did all > > of the development work. > > > > I'mnot saying that RSVP should never be extended. I'm saying that those > > groups that are writing extensions should be consulting with those who > > have been developing and maintaining it (in the RSVP and MPLS groups) in > > order to ensure that: > > - Their goal can't be achieved without extending the language > > - That their extension doesn't overlap a similar extension > > from somebody else. > > - That their extension doesn't significantly change the overall > > semantics of RSVP. > > - That their extension is sufficiently flexible so that other > > groups can build off of it instead of re-inventing the wheel > > with yet another incompatible extension. > > > > Not only isn't this happening, but there appears to be no desire to see > > this happen. > > > > -- David From owner-mpls@UU.NET Thu Jan 23 19:22:26 2003 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25318 for ; Thu, 23 Jan 2003 19:22:26 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnyyj29085 for ; Fri, 24 Jan 2003 00:25:51 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnyyj28783; Fri, 24 Jan 2003 00:25:43 GMT Received: by mail-control.ash.ops.us.uu.net id QQnyyj25402 for mpls-outgoing; Fri, 24 Jan 2003 00:25:18 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnyyj25396 for ; Fri, 24 Jan 2003 00:25:16 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnyyj15628 for ; Fri, 24 Jan 2003 00:24:00 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnyyj26583 for ; Fri, 24 Jan 2003 00:23:59 GMT Received: from alpha2.tellium.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [65.125.55.125]) id QQnyyj26570 for ; Fri, 24 Jan 2003 00:23:59 GMT Received: from mail3.tellium.com (unverified) by alpha2.tellium.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 23 Jan 2003 19:19:40 -0500 Received: by mail3.tellium.com with Internet Mail Service (5.5.2653.19) id ; Thu, 23 Jan 2003 12:03:29 -0500 Message-ID: <05707214338CD5119BFF0040A5B170D302889721@mail3.tellium.com> From: Bala Rajagopalan To: "'David Charlap'" , Brian Hassink Cc: Bob Braden , rsvp@ISI.EDU, ccamp@ops.ietf.org, mpls@UU.NET, kireeti@juniper.net, iana@ISI.EDU, sob@harvard.edu, mankin@psg.com, bwijnen@lucent.com Subject: RE: IANA Considerations for RSVP Date: Thu, 23 Jan 2003 12:03:26 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Hello, First, the IETF has been instrumental in putting IP/MPLS protoocols for use in the optical control plane. You can't now complain that RSVP is being indiscriminately used for purposes other than intended. To quote a cliche, you can't have the cake intact and modify it too. Second, none of the IETF WGs (specifically, CCAMP) have shown any interest in discussing the (informational) drafts about ASON or OIF at any length. Serious consideration by the WGs should lead to an examination of the solutions proposed and a liaison to ITU-T or OIF or whichever body about tweaks that are out of whack with the protocol architecture. Instead, what we usually end up with are WG Rambos who simply shoot down the entire model of ITU-T or OIF and move on. Finally, it's not so easy to steer away from RSVP altogether (even if it makes sense to do so) due to the installed code base of dominant vendors. In summary, there is a lot of pressure to use RSVP outside of IETF, and the IETF should systematically review the outside work to ensure technical sanity. Regards, Bala Rajagopalan Tellium, Inc. 2 Crescent Pl. Ocean Port, NJ 07757 USA Ph: +1-732-923-4237 Email: braja@tellium.com > -----Original Message----- > From: David Charlap [mailto:David.Charlap@marconi.com] > Sent: Thursday, January 23, 2003 11:15 AM > To: Brian Hassink > Cc: Bob Braden; rsvp@ISI.EDU; ccamp@ops.ietf.org; mpls@UU.NET; > kireeti@juniper.net; iana@ISI.EDU; sob@harvard.edu; mankin@psg.com; > bwijnen@lucent.com > Subject: Re: IANA Considerations for RSVP > > > Brian Hassink wrote: > > Didn't the IETF set the precedent by extending RSVP from an > IntServ protocol to an MPLS protocol? > > There's a big difference. MPLS and IntServ are both IETF > groups. (And > RSVP has/had its own working group anyway). Also, most of > the key RSVP > people were involved in the development of RSVP-TE. > > This is very different from what I'm describing - where > people who have > no prior RSVP experience decide that they can start changing > it without > understing it, and without even notifying the IETF groups > that did all > of the development work. > > I'mnot saying that RSVP should never be extended. I'm saying > that those > groups that are writing extensions should be consulting with > those who > have been developing and maintaining it (in the RSVP and MPLS > groups) in > order to ensure that: > - Their goal can't be achieved without extending the language > - That their extension doesn't overlap a similar extension > from somebody else. > - That their extension doesn't significantly change the overall > semantics of RSVP. > - That their extension is sufficiently flexible so that other > groups can build off of it instead of re-inventing the wheel > with yet another incompatible extension. > > Not only isn't this happening, but there appears to be no > desire to see > this happen. > > -- David > From owner-mpls@UU.NET Thu Jan 23 20:12:11 2003 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26545 for ; Thu, 23 Jan 2003 20:12:11 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnyyn23855 for ; Fri, 24 Jan 2003 01:15:36 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnyyn23641; Fri, 24 Jan 2003 01:15:29 GMT Received: by mail-control.ash.ops.us.uu.net id QQnyym17662 for mpls-outgoing; Fri, 24 Jan 2003 01:14:59 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnyym17653 for ; Fri, 24 Jan 2003 01:14:57 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnyym26208 for ; Fri, 24 Jan 2003 01:13:00 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnyym10873 for ; Fri, 24 Jan 2003 01:13:00 GMT Received: from lightwave.chromisys.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: lightwave.chromisys.com [63.102.55.206]) id QQnyym10855 for ; Fri, 24 Jan 2003 01:12:59 GMT Received: by lightwave.chromisys.com with Internet Mail Service (5.5.2653.19) id <4GJZ1XFM>; Thu, 23 Jan 2003 17:12:55 -0800 Message-ID: <9D42C6E086250248810DCADA39CE7EFC97218C@nimbus> From: John Drake To: "'Scott W Brim'" , Stephen Trowbridge Cc: David Charlap , Brian Hassink , Bob Braden , rsvp@ISI.EDU, ccamp@ops.ietf.org, mpls@UU.NET, kireeti@juniper.net, iana@ISI.EDU, sob@harvard.edu, mankin@psg.com, bwijnen@lucent.com Subject: RE: IANA Considerations for RSVP Date: Thu, 23 Jan 2003 17:12:46 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Scott, You saved me some typing. John > -----Original Message----- > From: Scott W Brim [mailto:sbrim@cisco.com] > Sent: Thursday, January 23, 2003 4:27 PM > To: Stephen Trowbridge > Cc: John Drake; David Charlap; Brian Hassink; Bob Braden; > rsvp@ISI.EDU; > ccamp@ops.ietf.org; mpls@UU.NET; kireeti@juniper.net; iana@ISI.EDU; > sob@harvard.edu; mankin@psg.com; bwijnen@lucent.com > Subject: Re: IANA Considerations for RSVP > > > On Thu, Jan 23, 2003 04:24:31PM -0700, Stephen Trowbridge > allegedly wrote: > > John, > > Hmmm... a bit IETF centric. > > Because some portion of a problem space touches or uses an > IETF protocol, > > then clearly the entire problem must belong to IETF. > > The entire problem of signing off on extensions to the protocol does > belong to the IETF, if you want them to be used outside of some local > network. That's for architectural consistency. > > > Consider that the ASON architecture encompasses transport > networks where > > what we call the transport plane (IETF calls the data plane) is not > > necessarily IP. What if the addresses are NSAP addresses > instead of IP > > addresses? What if some or all of the signaling links employ PNNI > > as a signaling protocol instead of RSVP-TE or CR-LDP? Does it still > > all belong to IETF? These are problems that cannot be solved without > > good cooperation between the standards organizations that > are involved. > > The IETF is responsible for defining the mechanisms by which those > non-IP addresses can be carried in the IP-based protocol. > > > In terms of the existance of a communication channel and > procedures for > > collaborating between IETF and ITU-T, this exists but > perhaps, in spite > > of receiving these liaisons, you have not taken the trouble > to become > > familiar with it. Identical text describing the > collaboration process is > > published as RFC 3356 in IETF and as A.Sup3 in ITU-T. We > are following > > the documented process, and this suggests a different > answer than your > > emails to the question of which side of this communication > channel is > > not holding up their end. > > I agree the communication channels could be used better. I also think > that the best way to communicate is probably NOT those channels, but > rather to bring in parallel technical contributions in each group, to > make sure they are in sync. Take the ideas through the > procedures that > participants actually care about. > > swb > From owner-mpls@UU.NET Thu Jan 23 22:35:35 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29132 for ; Thu, 23 Jan 2003 22:35:34 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnyyw13089 for ; Fri, 24 Jan 2003 03:39:01 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnyyw12670; Fri, 24 Jan 2003 03:38:51 GMT Received: by mail-control.ash.ops.us.uu.net id QQnyyw05542 for mpls-outgoing; Fri, 24 Jan 2003 03:38:37 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnyyw05537 for ; Fri, 24 Jan 2003 03:38:24 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnyyw03417 for ; Fri, 24 Jan 2003 03:36:14 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnyyw05824 for ; Fri, 24 Jan 2003 03:36:12 GMT Received: from rtp-msg-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-msg-core-1.cisco.com [161.44.11.97]) id QQnyyw05608 for ; Fri, 24 Jan 2003 03:36:07 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h0O3arv4017199 for ; Thu, 23 Jan 2003 22:36:53 -0500 (EST) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id WAA05221 for ; Thu, 23 Jan 2003 22:36:04 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h0O3a4L10925 for mpls@uu.net; Thu, 23 Jan 2003 22:36:04 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnyyw05275 for ; Fri, 24 Jan 2003 03:35:30 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnyyw01088 for ; Fri, 24 Jan 2003 03:34:49 GMT Received: from sj-msg-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQnyyj03409 for ; Fri, 24 Jan 2003 00:27:53 GMT Received: from mira-sjc5-a.cisco.com (IDENT:mirapoint@mira-sjc5-a.cisco.com [171.71.163.34]) by sj-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h0O0QxSQ029809; Thu, 23 Jan 2003 16:26:59 -0800 (PST) Received: from cisco.com (sjc-vpn2-370.cisco.com [10.21.113.114]) by mira-sjc5-a.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with SMTP id ADT31976; Thu, 23 Jan 2003 16:16:11 -0800 (PST) Received: by cisco.com (sSMTP sendmail emulation); Thu, 23 Jan 2003 19:26:55 -0500 Date: Thu, 23 Jan 2003 19:26:55 -0500 From: Scott W Brim To: Stephen Trowbridge Cc: John Drake , David Charlap , Brian Hassink , Bob Braden , rsvp@ISI.EDU, ccamp@ops.ietf.org, mpls@UU.NET, kireeti@juniper.net, iana@ISI.EDU, sob@harvard.edu, mankin@psg.com, bwijnen@lucent.com Subject: Re: IANA Considerations for RSVP Message-ID: <20030124002654.GG1856@SBRIM-W2K1> Mail-Followup-To: Scott W Brim , Stephen Trowbridge , John Drake , David Charlap , Brian Hassink , Bob Braden , rsvp@ISI.EDU, ccamp@ops.ietf.org, mpls@UU.NET, kireeti@juniper.net, iana@ISI.EDU, sob@harvard.edu, mankin@psg.com, bwijnen@lucent.com References: <9D42C6E086250248810DCADA39CE7EFC97217E@nimbus> <3E3079AF.3010ED7C@lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3E3079AF.3010ED7C@lucent.com> User-Agent: Mutt/1.4i Sender: owner-mpls@UU.NET Precedence: bulk On Thu, Jan 23, 2003 04:24:31PM -0700, Stephen Trowbridge allegedly wrote: > John, > Hmmm... a bit IETF centric. > Because some portion of a problem space touches or uses an IETF protocol, > then clearly the entire problem must belong to IETF. The entire problem of signing off on extensions to the protocol does belong to the IETF, if you want them to be used outside of some local network. That's for architectural consistency. > Consider that the ASON architecture encompasses transport networks where > what we call the transport plane (IETF calls the data plane) is not > necessarily IP. What if the addresses are NSAP addresses instead of IP > addresses? What if some or all of the signaling links employ PNNI > as a signaling protocol instead of RSVP-TE or CR-LDP? Does it still > all belong to IETF? These are problems that cannot be solved without > good cooperation between the standards organizations that are involved. The IETF is responsible for defining the mechanisms by which those non-IP addresses can be carried in the IP-based protocol. > In terms of the existance of a communication channel and procedures for > collaborating between IETF and ITU-T, this exists but perhaps, in spite > of receiving these liaisons, you have not taken the trouble to become > familiar with it. Identical text describing the collaboration process is > published as RFC 3356 in IETF and as A.Sup3 in ITU-T. We are following > the documented process, and this suggests a different answer than your > emails to the question of which side of this communication channel is > not holding up their end. I agree the communication channels could be used better. I also think that the best way to communicate is probably NOT those channels, but rather to bring in parallel technical contributions in each group, to make sure they are in sync. Take the ideas through the procedures that participants actually care about. swb From owner-mpls@UU.NET Fri Jan 24 05:19:26 2003 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14947 for ; Fri, 24 Jan 2003 05:19:26 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnyzx08228 for ; Fri, 24 Jan 2003 10:22:52 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnyzx07941; Fri, 24 Jan 2003 10:22:45 GMT Received: by mail-control.ash.ops.us.uu.net id QQnyzx13832 for mpls-outgoing; Fri, 24 Jan 2003 10:22:17 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnyzx13827 for ; Fri, 24 Jan 2003 10:22:02 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnyzx01778 for ; Fri, 24 Jan 2003 10:21:07 GMT Received: from mail.alcatel.be by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: alc239.alcatel.be [195.207.101.239]) id QQnyzn23767 for ; Fri, 24 Jan 2003 07:49:29 GMT Received: from bemail05.net.alcatel.be (localhost [127.0.0.1]) by mail.alcatel.be (8.10.1/8.11.4) with ESMTP id h0O7mpS04014; Fri, 24 Jan 2003 08:48:51 +0100 (MET) Received: from alcatel.be ([149.204.0.178]) by bemail05.net.alcatel.be (Lotus Domino Release 5.0.11) with ESMTP id 2003012408484820:1037 ; Fri, 24 Jan 2003 08:48:48 +0100 Message-ID: <3E30EFBB.6A3A90AF@alcatel.be> Date: Fri, 24 Jan 2003 08:48:11 +0100 From: Dimitri.Papadimitriou@alcatel.be Organization: Optical Network Architecture (NTA - Antwerpen) X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Bala Rajagopalan Cc: "'David Charlap'" , Brian Hassink , Bob Braden , rsvp@ISI.EDU, ccamp@ops.ietf.org, mpls@UU.NET, kireeti@juniper.net, iana@ISI.EDU, sob@harvard.edu, mankin@psg.com, bwijnen@lucent.com Subject: Re: IANA Considerations for RSVP References: <05707214338CD5119BFF0040A5B170D302889721@mail3.tellium.com> X-MIMETrack: Itemize by SMTP Server on BEMAIL05/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 01/24/2003 08:48:49, Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 01/24/2003 08:48:58, Serialize complete at 01/24/2003 08:48:58 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit bala, your assertion "none of the IETF WGs (specifically, CCAMP) have shown any interest in discussing the (informational) drafts about ASON or OIF at any length." is not true if you were really participating to the ccamp wg meeting in yokohama you would have heard that the consensus was (as requested by the chair) to send a ason functional spec to the ccamp wg in order for the latter to define the needed extensions - the proposal was to achieve a first cut of these extensions in november '02 but nothing happened everything goes to "informational" the reason why suddenly things gets tunneled until reaching the current situation are still unclear for me (one of the explanation i have is the clear rambo competition played by the oif in backing up these extensions instead of letting the corresponding responsibility to the appropriate body i.e. the ietf) thanks, - dimitri. Bala Rajagopalan wrote: > > Hello, > > First, the IETF has been instrumental in putting > IP/MPLS protoocols for use in the optical control plane. > You can't now complain that RSVP is being indiscriminately > used for purposes other than intended. To quote > a cliche, you can't have the cake intact and modify it > too. > > Second, none of the IETF WGs (specifically, CCAMP) > have shown any interest in discussing the (informational) > drafts about ASON or OIF at any length. Serious > consideration by the WGs should lead to an examination > of the solutions proposed and a liaison to ITU-T or OIF > or whichever body about tweaks that are out > of whack with the protocol architecture. > Instead, what we usually end up with are WG > Rambos who simply shoot down the entire model of > ITU-T or OIF and move on. > > Finally, it's not so easy to steer away from RSVP altogether > (even if it makes sense to do so) > due to the installed code base of dominant vendors. > > In summary, there is a lot of pressure to use RSVP outside > of IETF, and the IETF should systematically review the > outside work to ensure technical sanity. > > Regards, > > Bala Rajagopalan > Tellium, Inc. > 2 Crescent Pl. > Ocean Port, NJ 07757 > USA > Ph: +1-732-923-4237 > Email: braja@tellium.com > > > -----Original Message----- > > From: David Charlap [mailto:David.Charlap@marconi.com] > > Sent: Thursday, January 23, 2003 11:15 AM > > To: Brian Hassink > > Cc: Bob Braden; rsvp@ISI.EDU; ccamp@ops.ietf.org; mpls@UU.NET; > > kireeti@juniper.net; iana@ISI.EDU; sob@harvard.edu; mankin@psg.com; > > bwijnen@lucent.com > > Subject: Re: IANA Considerations for RSVP > > > > > > Brian Hassink wrote: > > > Didn't the IETF set the precedent by extending RSVP from an > > IntServ protocol to an MPLS protocol? > > > > There's a big difference. MPLS and IntServ are both IETF > > groups. (And > > RSVP has/had its own working group anyway). Also, most of > > the key RSVP > > people were involved in the development of RSVP-TE. > > > > This is very different from what I'm describing - where > > people who have > > no prior RSVP experience decide that they can start changing > > it without > > understing it, and without even notifying the IETF groups > > that did all > > of the development work. > > > > I'mnot saying that RSVP should never be extended. I'm saying > > that those > > groups that are writing extensions should be consulting with > > those who > > have been developing and maintaining it (in the RSVP and MPLS > > groups) in > > order to ensure that: > > - Their goal can't be achieved without extending the language > > - That their extension doesn't overlap a similar extension > > from somebody else. > > - That their extension doesn't significantly change the overall > > semantics of RSVP. > > - That their extension is sufficiently flexible so that other > > groups can build off of it instead of re-inventing the wheel > > with yet another incompatible extension. > > > > Not only isn't this happening, but there appears to be no > > desire to see > > this happen. > > > > -- David > > -- Papadimitriou Dimitri E-mail : dimitri.papadimitriou@alcatel.be Private: http://www.rc.bel.alcatel.be/~papadimd/index.html E-mail : dpapadimitriou@psg.com Public : http://psg.com/~dpapadimitriou/ Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium Phone : Work: +32 3 2408491 - Home: +32 2 3434361 From owner-mpls@UU.NET Fri Jan 24 10:48:29 2003 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23045 for ; Fri, 24 Jan 2003 10:48:29 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnzat05892 for ; Fri, 24 Jan 2003 15:51:55 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnzat05580; Fri, 24 Jan 2003 15:51:47 GMT Received: by mail-control.ash.ops.us.uu.net id QQnzat10324 for mpls-outgoing; Fri, 24 Jan 2003 15:51:27 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnzat10319 for ; Fri, 24 Jan 2003 15:51:19 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnzat13118 for ; Fri, 24 Jan 2003 15:49:55 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnzat15762 for ; Fri, 24 Jan 2003 15:49:55 GMT Received: from alpha2.tellium.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [65.125.55.125]) id QQnzat15726 for ; Fri, 24 Jan 2003 15:49:54 GMT Received: from mail3.tellium.com (unverified) by alpha2.tellium.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 24 Jan 2003 10:48:32 -0500 Received: by mail3.tellium.com with Internet Mail Service (5.5.2653.19) id ; Fri, 24 Jan 2003 10:47:19 -0500 Message-ID: <05707214338CD5119BFF0040A5B170D30288972B@mail3.tellium.com> From: Bala Rajagopalan To: "'Dimitri.Papadimitriou@alcatel.be'" , Bala Rajagopalan Cc: rsvp@ISI.EDU, ccamp@ops.ietf.org, mpls@UU.NET Subject: RE: IANA Considerations for RSVP Date: Fri, 24 Jan 2003 10:47:16 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Dimitri: I don't recall the particular Yokohoma consensus you mention, although what you say could very well have happened. All I do remember is the total lack of interest in the audience about most of the drafts discussed. My gripe is basically about the lack of a process in the IETF to rigorously and constructively evaluate on-going work outside. The liaisons obviously haven't worked very well, and the efforts by various people to bring in contributions on OIF and ASON work have been met with cynicism. This is the reason why there's a scramble at the last minute to "right" things. Going forward, I hope the IETF makes it mandatory to have outside work examined in the relevant WGs with the same seriousness as regular WG items (or assign evaluation teams, like design teams). This would bring overall sanity and be beneficial for all groups. regards, Bala Rajagopalan Tellium, Inc. 2 Crescent Pl. Ocean Port, NJ 07757 USA Ph: +1-732-923-4237 Email: braja@tellium.com > -----Original Message----- > From: Dimitri.Papadimitriou@alcatel.be > [mailto:Dimitri.Papadimitriou@alcatel.be] > Sent: Friday, January 24, 2003 2:48 AM > To: Bala Rajagopalan > Cc: 'David Charlap'; Brian Hassink; Bob Braden; rsvp@ISI.EDU; > ccamp@ops.ietf.org; mpls@UU.NET; kireeti@juniper.net; iana@ISI.EDU; > sob@harvard.edu; mankin@psg.com; bwijnen@lucent.com > Subject: Re: IANA Considerations for RSVP > > > bala, > > your assertion "none of the IETF WGs (specifically, CCAMP) > have shown any interest in discussing the (informational) > drafts about ASON or OIF at any length." is not true > if you were really participating to the ccamp wg meeting > in yokohama you would have heard that the consensus was > (as requested by the chair) to send a ason functional > spec to the ccamp wg in order for the latter to define > the needed extensions - the proposal was to achieve > a first cut of these extensions in november '02 but > nothing happened everything goes to "informational" > > the reason why suddenly things gets tunneled until > reaching the current situation are still unclear for > me (one of the explanation i have is the clear rambo > competition played by the oif in backing up these > extensions instead of letting the corresponding > responsibility to the appropriate body i.e. the ietf) > > thanks, > - dimitri. > > Bala Rajagopalan wrote: > > > > Hello, > > > > First, the IETF has been instrumental in putting > > IP/MPLS protoocols for use in the optical control plane. > > You can't now complain that RSVP is being indiscriminately > > used for purposes other than intended. To quote > > a cliche, you can't have the cake intact and modify it > > too. > > > > Second, none of the IETF WGs (specifically, CCAMP) > > have shown any interest in discussing the (informational) > > drafts about ASON or OIF at any length. Serious > > consideration by the WGs should lead to an examination > > of the solutions proposed and a liaison to ITU-T or OIF > > or whichever body about tweaks that are out > > of whack with the protocol architecture. > > Instead, what we usually end up with are WG > > Rambos who simply shoot down the entire model of > > ITU-T or OIF and move on. > > > > Finally, it's not so easy to steer away from RSVP altogether > > (even if it makes sense to do so) > > due to the installed code base of dominant vendors. > > > > In summary, there is a lot of pressure to use RSVP outside > > of IETF, and the IETF should systematically review the > > outside work to ensure technical sanity. > > > > Regards, > > > > Bala Rajagopalan > > Tellium, Inc. > > 2 Crescent Pl. > > Ocean Port, NJ 07757 > > USA > > Ph: +1-732-923-4237 > > Email: braja@tellium.com > > > > > -----Original Message----- > > > From: David Charlap [mailto:David.Charlap@marconi.com] > > > Sent: Thursday, January 23, 2003 11:15 AM > > > To: Brian Hassink > > > Cc: Bob Braden; rsvp@ISI.EDU; ccamp@ops.ietf.org; mpls@UU.NET; > > > kireeti@juniper.net; iana@ISI.EDU; sob@harvard.edu; > mankin@psg.com; > > > bwijnen@lucent.com > > > Subject: Re: IANA Considerations for RSVP > > > > > > > > > Brian Hassink wrote: > > > > Didn't the IETF set the precedent by extending RSVP from an > > > IntServ protocol to an MPLS protocol? > > > > > > There's a big difference. MPLS and IntServ are both IETF > > > groups. (And > > > RSVP has/had its own working group anyway). Also, most of > > > the key RSVP > > > people were involved in the development of RSVP-TE. > > > > > > This is very different from what I'm describing - where > > > people who have > > > no prior RSVP experience decide that they can start changing > > > it without > > > understing it, and without even notifying the IETF groups > > > that did all > > > of the development work. > > > > > > I'mnot saying that RSVP should never be extended. I'm saying > > > that those > > > groups that are writing extensions should be consulting with > > > those who > > > have been developing and maintaining it (in the RSVP and MPLS > > > groups) in > > > order to ensure that: > > > - Their goal can't be achieved without extending > the language > > > - That their extension doesn't overlap a similar extension > > > from somebody else. > > > - That their extension doesn't significantly change > the overall > > > semantics of RSVP. > > > - That their extension is sufficiently flexible so > that other > > > groups can build off of it instead of > re-inventing the wheel > > > with yet another incompatible extension. > > > > > > Not only isn't this happening, but there appears to be no > > > desire to see > > > this happen. > > > > > > -- David > > > > > -- > Papadimitriou Dimitri > E-mail : dimitri.papadimitriou@alcatel.be > Private: http://www.rc.bel.alcatel.be/~papadimd/index.html > E-mail : dpapadimitriou@psg.com > Public : http://psg.com/~dpapadimitriou/ > Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium > Phone : Work: +32 3 2408491 - Home: +32 2 3434361 > From owner-mpls@UU.NET Fri Jan 24 11:22:33 2003 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23999 for ; Fri, 24 Jan 2003 11:22:33 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnzav04937 for ; Fri, 24 Jan 2003 16:25:59 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnzav04694; Fri, 24 Jan 2003 16:25:53 GMT Received: by mail-control.ash.ops.us.uu.net id QQnzav01108 for mpls-outgoing; Fri, 24 Jan 2003 16:25:25 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnzav01101 for ; Fri, 24 Jan 2003 16:25:15 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnzav03188 for ; Fri, 24 Jan 2003 16:24:36 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnzav26560 for ; Fri, 24 Jan 2003 16:24:36 GMT Received: from bridge.axiowave.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ppp-64-115-125-242.broadviewnet.net [64.115.125.242] (may be forged)) id QQnzav26542 for ; Fri, 24 Jan 2003 16:24:35 GMT Message-ID: From: Jeff Parker To: "'Bala Rajagopalan'" , "'Dimitri.Papadimitriou@alcatel.be'" Cc: rsvp@ISI.EDU, ccamp@ops.ietf.org, mpls@UU.NET Subject: RE: IANA Considerations for RSVP Date: Fri, 24 Jan 2003 11:24:11 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk > Going forward, I hope the IETF makes it mandatory > to have outside work examined in the relevant WGs with > the same seriousness as regular WG items (or assign > evaluation teams, like design teams). > > Bala Rajagopalan Given that much of the work done at the IETF is done by volunteers, this bar may not be as high as it seems. I see Last Calls on WG items in a number of groups that elicit little or no comment. It is certainly worth the effort to try to make cooperation between IETF and other bodies easier. But unfunded mandates are difficult to staff. - jeff parker From owner-mpls@UU.NET Fri Jan 24 11:45:17 2003 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24541 for ; Fri, 24 Jan 2003 11:45:16 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnzax01769 for ; Fri, 24 Jan 2003 16:48:44 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnzax01547; Fri, 24 Jan 2003 16:48:37 GMT Received: by mail-control.ash.ops.us.uu.net id QQnzax03172 for mpls-outgoing; Fri, 24 Jan 2003 16:48:10 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnzax03151 for ; Fri, 24 Jan 2003 16:48:00 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnzax24062 for ; Fri, 24 Jan 2003 16:46:42 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnzax01230 for ; Fri, 24 Jan 2003 16:46:42 GMT Received: from ihemail2.firewall.lucent.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ihemail2.lucent.com [192.11.222.163]) id QQnzax01212 for ; Fri, 24 Jan 2003 16:46:41 GMT Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail2.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id h0OGked06632; Fri, 24 Jan 2003 11:46:40 -0500 (EST) Received: from lucent.com (sjtrowbridge.lra.lucent.com [135.248.252.10]) by ihmail.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id KAA27992; Fri, 24 Jan 2003 10:46:36 -0600 (CST) Message-ID: <3E316DE3.2DFBA173@lucent.com> Date: Fri, 24 Jan 2003 09:46:27 -0700 From: Stephen Trowbridge Organization: Lucent Technologies X-Mailer: Mozilla 4.76 [en]C-CCK-MCD EMS-1.5 (Windows NT 5.0; U) X-Accept-Language: en,zh MIME-Version: 1.0 To: Bala Rajagopalan CC: "'Dimitri.Papadimitriou@alcatel.be'" , rsvp@ISI.EDU, ccamp@ops.ietf.org, mpls@UU.NET Subject: Re: IANA Considerations for RSVP References: <05707214338CD5119BFF0040A5B170D30288972B@mail3.tellium.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Bala, Excellent suggestion. Steve Bala Rajagopalan wrote: > > Dimitri: > > I don't recall the particular Yokohoma consensus > you mention, although what you say could very well > have happened. All I do remember is the total lack > of interest in the audience about most of the drafts > discussed. > > My gripe is basically about the lack of a process in > the IETF to rigorously and constructively evaluate > on-going work outside. The liaisons > obviously haven't worked very well, and the efforts > by various people to bring in contributions on OIF > and ASON work have been met with cynicism. This is > the reason why there's a scramble at the last minute > to "right" things. > > Going forward, I hope the IETF makes it mandatory > to have outside work examined in the relevant WGs with > the same seriousness as regular WG items (or assign > evaluation teams, like design teams). This would bring > overall sanity and be beneficial for all groups. > > regards, > > Bala Rajagopalan > Tellium, Inc. > 2 Crescent Pl. > Ocean Port, NJ 07757 > USA > Ph: +1-732-923-4237 > Email: braja@tellium.com > > > -----Original Message----- > > From: Dimitri.Papadimitriou@alcatel.be > > [mailto:Dimitri.Papadimitriou@alcatel.be] > > Sent: Friday, January 24, 2003 2:48 AM > > To: Bala Rajagopalan > > Cc: 'David Charlap'; Brian Hassink; Bob Braden; rsvp@ISI.EDU; > > ccamp@ops.ietf.org; mpls@UU.NET; kireeti@juniper.net; iana@ISI.EDU; > > sob@harvard.edu; mankin@psg.com; bwijnen@lucent.com > > Subject: Re: IANA Considerations for RSVP > > > > > > bala, > > > > your assertion "none of the IETF WGs (specifically, CCAMP) > > have shown any interest in discussing the (informational) > > drafts about ASON or OIF at any length." is not true > > if you were really participating to the ccamp wg meeting > > in yokohama you would have heard that the consensus was > > (as requested by the chair) to send a ason functional > > spec to the ccamp wg in order for the latter to define > > the needed extensions - the proposal was to achieve > > a first cut of these extensions in november '02 but > > nothing happened everything goes to "informational" > > > > the reason why suddenly things gets tunneled until > > reaching the current situation are still unclear for > > me (one of the explanation i have is the clear rambo > > competition played by the oif in backing up these > > extensions instead of letting the corresponding > > responsibility to the appropriate body i.e. the ietf) > > > > thanks, > > - dimitri. > > > > Bala Rajagopalan wrote: > > > > > > Hello, > > > > > > First, the IETF has been instrumental in putting > > > IP/MPLS protoocols for use in the optical control plane. > > > You can't now complain that RSVP is being indiscriminately > > > used for purposes other than intended. To quote > > > a cliche, you can't have the cake intact and modify it > > > too. > > > > > > Second, none of the IETF WGs (specifically, CCAMP) > > > have shown any interest in discussing the (informational) > > > drafts about ASON or OIF at any length. Serious > > > consideration by the WGs should lead to an examination > > > of the solutions proposed and a liaison to ITU-T or OIF > > > or whichever body about tweaks that are out > > > of whack with the protocol architecture. > > > Instead, what we usually end up with are WG > > > Rambos who simply shoot down the entire model of > > > ITU-T or OIF and move on. > > > > > > Finally, it's not so easy to steer away from RSVP altogether > > > (even if it makes sense to do so) > > > due to the installed code base of dominant vendors. > > > > > > In summary, there is a lot of pressure to use RSVP outside > > > of IETF, and the IETF should systematically review the > > > outside work to ensure technical sanity. > > > > > > Regards, > > > > > > Bala Rajagopalan > > > Tellium, Inc. > > > 2 Crescent Pl. > > > Ocean Port, NJ 07757 > > > USA > > > Ph: +1-732-923-4237 > > > Email: braja@tellium.com > > > > > > > -----Original Message----- > > > > From: David Charlap [mailto:David.Charlap@marconi.com] > > > > Sent: Thursday, January 23, 2003 11:15 AM > > > > To: Brian Hassink > > > > Cc: Bob Braden; rsvp@ISI.EDU; ccamp@ops.ietf.org; mpls@UU.NET; > > > > kireeti@juniper.net; iana@ISI.EDU; sob@harvard.edu; > > mankin@psg.com; > > > > bwijnen@lucent.com > > > > Subject: Re: IANA Considerations for RSVP > > > > > > > > > > > > Brian Hassink wrote: > > > > > Didn't the IETF set the precedent by extending RSVP from an > > > > IntServ protocol to an MPLS protocol? > > > > > > > > There's a big difference. MPLS and IntServ are both IETF > > > > groups. (And > > > > RSVP has/had its own working group anyway). Also, most of > > > > the key RSVP > > > > people were involved in the development of RSVP-TE. > > > > > > > > This is very different from what I'm describing - where > > > > people who have > > > > no prior RSVP experience decide that they can start changing > > > > it without > > > > understing it, and without even notifying the IETF groups > > > > that did all > > > > of the development work. > > > > > > > > I'mnot saying that RSVP should never be extended. I'm saying > > > > that those > > > > groups that are writing extensions should be consulting with > > > > those who > > > > have been developing and maintaining it (in the RSVP and MPLS > > > > groups) in > > > > order to ensure that: > > > > - Their goal can't be achieved without extending > > the language > > > > - That their extension doesn't overlap a similar extension > > > > from somebody else. > > > > - That their extension doesn't significantly change > > the overall > > > > semantics of RSVP. > > > > - That their extension is sufficiently flexible so > > that other > > > > groups can build off of it instead of > > re-inventing the wheel > > > > with yet another incompatible extension. > > > > > > > > Not only isn't this happening, but there appears to be no > > > > desire to see > > > > this happen. > > > > > > > > -- David > > > > > > > > -- > > Papadimitriou Dimitri > > E-mail : dimitri.papadimitriou@alcatel.be > > Private: http://www.rc.bel.alcatel.be/~papadimd/index.html > > E-mail : dpapadimitriou@psg.com > > Public : http://psg.com/~dpapadimitriou/ > > Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium > > Phone : Work: +32 3 2408491 - Home: +32 2 3434361 > > From owner-mpls@UU.NET Fri Jan 24 17:21:38 2003 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04042 for ; Fri, 24 Jan 2003 17:21:37 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnzbt07742 for ; Fri, 24 Jan 2003 22:25:02 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnzbt07552; Fri, 24 Jan 2003 22:24:58 GMT Received: by mail-control.ash.ops.us.uu.net id QQnzbt14373 for mpls-outgoing; Fri, 24 Jan 2003 22:24:41 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnzbt14363 for ; Fri, 24 Jan 2003 22:24:39 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnzbt26000 for ; Fri, 24 Jan 2003 22:20:48 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnzbt20906 for ; Fri, 24 Jan 2003 22:20:47 GMT Received: from bridge.axiowave.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ppp-64-115-125-242.broadviewnet.net [64.115.125.242] (may be forged)) id QQnzbt20865 for ; Fri, 24 Jan 2003 22:20:46 GMT Message-ID: From: Ling Li To: "'Alia Atlas'" , Ling Li Cc: "'mpls@UU.NET'" , Ping Pan , Jean Philippe Vasseur , Der-Hwa Gan , mjork@avici.com, dcooper@gblx.net Subject: RE: Last Call on Fast Reroute Date: Fri, 24 Jan 2003 17:20:30 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Hi, Alia, Thanks for the response. Your answers to my comments and questions sound good over all. Some minor comments are inline. My original message was clipped. Thanks, Ling Li Axiowave Networks, Inc. 200 Nickerson Road Marlborough, MA 01752 Phone: (774)348-4618 Fax: (774)348-4008 Email: lli@axiowave.com ======================== > -----Original Message----- > From: Alia Atlas [mailto:aatlas@avici.com] > Sent: Monday, January 20, 2003 9:17 AM > To: Ling Li > Cc: 'mpls@UU.NET'; Ping Pan; Jean Philippe Vasseur; Der-Hwa Gan; > mjork@avici.com; dcooper@gblx.net > Subject: RE: Last Call on Fast Reroute > > > Ling, > > Sorry for the delay in response. > > > How does the following paragraph sound? > > "For the techniques discussed in this document to function properly, > there are three assumptions which must be made. First, an LSR I did not see the third assumption here. Should it be two? > which is on the path of a protected LSP SHOULD always assume that > it is a merge point; this is necessary because the facility backup > method does not signal backups through a bypass tunnel before > failure. Second, if the one-to-one backup method is used and a > DETOUR object is included, the LSRs in the traffic-engineered > network should support the DETOUR object; this is necessary so that > the Path message containing the DETOUR object is not rejected. > Understanding of the DETOUR object is required to support the > path-specific method which requires that LSRs in the > traffic-engineered network be capable of merging detours." > > Whether an LSR can function as a PLR determines whether a > potential failure > condition can be quickly healed. Consider the following diagram. > > [R1]-------[R2]------[R3]------[R4] > \ | \ / > [R5]---[R6]-----------[R7] > > In this diagram, if R3 can not function as a PLR, if the link > R3-R4 fails, > there is no immediate repair possible at R3. R2 will get a > PathErr and can > use its backup, if it is NNHOP. Regardless of whether R2's > backup is NNHOP > or NHOP, the fail-over time is longer than desirable because there is > signaling required from R3 to R2. Does this help answer the question? Thank you! > This PathErr is part of RFC 2205. In Section 3.10 there, it > says that for > objects with an unknown class-num of the form 0bbbbbbb, "The > entire message > should be rejected and an "Unknown Object Class" error returned. > > I will add a reference to this in the draft so that the > paragraph at the > end of Section 4.2 reads: > > "The high-order bit of the C-Class is zero; LSRs that do not support > the DETOUR objects MUST reject any Path message > containing a DETOUR > object and send a PathErr to notify the PLR. This PathErr SHOULD > be generated as specified in [RSVP] for unknown objects with a > class-num of the form "0bbbbbbb"." Sounds good > > This is equivalent. The detour will traverse from the merge > point to the > egress along the path of the LSP. Therefore, the additional > hops are those > in the detour not including the PLR or the merge point. This > definition > came from the initial draft describing the detour method. OK. > Sure, I'll put otherwise in there as > > "If node protection is > desired, the head-end LSR should set the "node protection desired" > flag in the SESSION_ATTRIBUTE object; otherwise (i.e. only link > protection is desired), this flag should be cleared." The point I was trying to make was that NO "node protection desired" is different from "link protection desired". In the first case, an implementation may first try to provide node protection; if not possible, then try to provide link protection. However in the second case, if the flag is cleared means "link protection desired", an implementation has to try to provide link protection first. May I suggest to remove "(i.e. only link protection is desired)" from the above paragraph, or define clearly the behavior of "otherwise" in Section 6? > We can certainly put in that the PLR SHOULD try to provide bandwidth > protection. However, saying that the PLR should set the bandwidth > constraint to 0 is, I think, not appropriate for all cases. > For instance, > with the facility backup, a bypass tunnel may have its bandwidth > over-booked such that a bandwidth guarantee can not be > provided, but that > doesn't mean that the backup can't be created and may have > better bandwidth > protection than 0. I'll amend the paragraph as follows. > > "If the "node protection desired" flag is set, the PLR SHOULD try to > provide node protection; if this is not feasible, the PLR SHOULD > then try to provide link protection. If the "bandwidth protection > guaranteed" flag is set, the PLR SHOULD try to provide a bandwidth > guarantee; if this is not feasible, the PLR SHOULD then try to > provide a backup without a guarantee of the full bandwidth." Very good. From owner-mpls@UU.NET Fri Jan 24 17:59:58 2003 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04778 for ; Fri, 24 Jan 2003 17:59:58 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnzbw26662 for ; Fri, 24 Jan 2003 23:03:20 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnzbw26272; Fri, 24 Jan 2003 23:03:06 GMT Received: by mail-control.ash.ops.us.uu.net id QQnzbw29518 for mpls-outgoing; Fri, 24 Jan 2003 23:02:38 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnzbw27852 for ; Fri, 24 Jan 2003 23:02:24 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnzbw28433 for ; Fri, 24 Jan 2003 23:01:13 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnzbw24360 for ; Fri, 24 Jan 2003 23:01:12 GMT Received: from rtp-msg-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-msg-core-1.cisco.com [161.44.11.97]) id QQnzbw24255 for ; Fri, 24 Jan 2003 23:01:08 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h0ON1q9D003428 for ; Fri, 24 Jan 2003 18:01:53 -0500 (EST) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id SAA12378 for ; Fri, 24 Jan 2003 18:01:02 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h0ON12N17881 for mpls@uu.net; Fri, 24 Jan 2003 18:01:02 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnzbu14788 for ; Fri, 24 Jan 2003 22:30:20 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnzbt02423 for ; Fri, 24 Jan 2003 22:29:37 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnzbt19071 for ; Fri, 24 Jan 2003 22:29:35 GMT Received: from ams-msg-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ams-msg-core-1.cisco.com [144.254.74.60]) id QQnzbt18827 for ; Fri, 24 Jan 2003 22:29:30 GMT Received: from cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h0OMR14F019642; Fri, 24 Jan 2003 23:27:01 +0100 (MET) Received: from JVASSEUR-W2K.cisco.com ([10.21.81.50]) by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id XAA11795; Fri, 24 Jan 2003 23:28:28 +0100 (MET) Message-Id: <4.3.2.7.2.20030124172409.0dee37d0@paris.cisco.com> X-Sender: jvasseur@paris.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 24 Jan 2003 17:28:27 -0500 To: Ling Li From: Jean Philippe Vasseur Subject: RE: Last Call on Fast Reroute Cc: "'Alia Atlas'" , Ling Li , "'mpls@UU.NET'" , Ping Pan , Der-Hwa Gan , mjork@avici.com, dcooper@gblx.net In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Hi Ling, At 17:20 24/01/2003 -0500, Ling Li wrote: >Hi, Alia, > >Thanks for the response. Your answers to my comments and questions sound >good >over all. Some minor comments are inline. My original message was clipped. > >Thanks, > >Ling Li > >Axiowave Networks, Inc. >200 Nickerson Road >Marlborough, MA 01752 >Phone: (774)348-4618 >Fax: (774)348-4008 >Email: lli@axiowave.com >======================== > > > > > -----Original Message----- > > From: Alia Atlas [mailto:aatlas@avici.com] > > Sent: Monday, January 20, 2003 9:17 AM > > To: Ling Li > > Cc: 'mpls@UU.NET'; Ping Pan; Jean Philippe Vasseur; Der-Hwa Gan; > > mjork@avici.com; dcooper@gblx.net > > Subject: RE: Last Call on Fast Reroute > > > > > > Ling, > > > > Sorry for the delay in response. > > > > > > How does the following paragraph sound? > > > > "For the techniques discussed in this document to function properly, > > there are three assumptions which must be made. First, an LSR > >I did not see the third assumption here. Should it be two? > > > which is on the path of a protected LSP SHOULD always assume that > > it is a merge point; this is necessary because the facility backup > > method does not signal backups through a bypass tunnel before > > failure. Second, if the one-to-one backup method is used and a > > DETOUR object is included, the LSRs in the traffic-engineered > > network should support the DETOUR object; this is necessary so that > > the Path message containing the DETOUR object is not rejected. > > Understanding of the DETOUR object is required to support the > > path-specific method which requires that LSRs in the > > traffic-engineered network be capable of merging detours." > > > > > Whether an LSR can function as a PLR determines whether a > > potential failure > > condition can be quickly healed. Consider the following diagram. > > > > [R1]-------[R2]------[R3]------[R4] > > \ | \ / > > [R5]---[R6]-----------[R7] > > > > In this diagram, if R3 can not function as a PLR, if the link > > R3-R4 fails, > > there is no immediate repair possible at R3. R2 will get a > > PathErr and can > > use its backup, if it is NNHOP. Regardless of whether R2's > > backup is NNHOP > > or NHOP, the fail-over time is longer than desirable because there is > > signaling required from R3 to R2. Does this help answer the question? > >Thank you! > > > This PathErr is part of RFC 2205. In Section 3.10 there, it > > says that for > > objects with an unknown class-num of the form 0bbbbbbb, "The > > entire message > > should be rejected and an "Unknown Object Class" error returned. > > > > I will add a reference to this in the draft so that the > > paragraph at the > > end of Section 4.2 reads: > > > > "The high-order bit of the C-Class is zero; LSRs that do not support > > the DETOUR objects MUST reject any Path message > > containing a DETOUR > > object and send a PathErr to notify the PLR. This PathErr SHOULD > > be generated as specified in [RSVP] for unknown objects with a > > class-num of the form "0bbbbbbb"." > >Sounds good > > > > > This is equivalent. The detour will traverse from the merge > > point to the > > egress along the path of the LSP. Therefore, the additional > > hops are those > > in the detour not including the PLR or the merge point. This > > definition > > came from the initial draft describing the detour method. > >OK. > > > Sure, I'll put otherwise in there as > > > > "If node protection is > > desired, the head-end LSR should set the "node protection desired" > > flag in the SESSION_ATTRIBUTE object; otherwise (i.e. only link > > protection is desired), this flag should be cleared." > >The point I was trying to make was that NO "node protection desired" >is different from "link protection desired". In the first case, an >implementation may first try to provide node protection; if not possible, >then try to provide link protection. However in the second case, if the >flag is cleared means "link protection desired", an implementation has to >try to provide link protection first. May I suggest to remove "(i.e. only >link protection is desired)" from the above paragraph, or define clearly >the behavior of "otherwise" in Section 6? ok, let's remove "(i.e. only link protection is desired)" In other words: - flag set: if possible the PLR should always select a backup tunnel avoiding the NHOP. - flag cleared: local PLR decision. Thanks for your comments. JP. > > We can certainly put in that the PLR SHOULD try to provide bandwidth > > protection. However, saying that the PLR should set the bandwidth > > constraint to 0 is, I think, not appropriate for all cases. > > For instance, > > with the facility backup, a bypass tunnel may have its bandwidth > > over-booked such that a bandwidth guarantee can not be > > provided, but that > > doesn't mean that the backup can't be created and may have > > better bandwidth > > protection than 0. I'll amend the paragraph as follows. > > > > "If the "node protection desired" flag is set, the PLR SHOULD try to > > provide node protection; if this is not feasible, the PLR SHOULD > > then try to provide link protection. If the "bandwidth protection > > guaranteed" flag is set, the PLR SHOULD try to provide a bandwidth > > guarantee; if this is not feasible, the PLR SHOULD then try to > > provide a backup without a guarantee of the full bandwidth." > >Very good. > A very happy new year 2003 ! Jean-Philippe Vasseur - jpv@cisco.com CISCO SYSTEMS Technical Leader IOS Engineering - Layer 3 Services 300 Apollo Drive Chelmsford, MA - 01824 USA Phone: 978-497-6238 Fax: 978-497-8126 From owner-mpls@UU.NET Sun Jan 26 01:54:40 2003 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA04275 for ; Sun, 26 Jan 2003 01:54:40 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnzgt01028 for ; Sun, 26 Jan 2003 06:58:06 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnzgt00722; Sun, 26 Jan 2003 06:57:56 GMT Received: by mail-control.ash.ops.us.uu.net id QQnzgt20156 for mpls-outgoing; Sun, 26 Jan 2003 06:57:28 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnzgt20149 for ; Sun, 26 Jan 2003 06:57:19 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnzgt13696 for ; Sun, 26 Jan 2003 06:56:05 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnzgt21352 for ; Sun, 26 Jan 2003 06:56:04 GMT Received: from rtp-msg-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-msg-core-1.cisco.com [161.44.11.97]) id QQnzgt21334 for ; Sun, 26 Jan 2003 06:56:04 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h0Q6upkO021173 for ; Sun, 26 Jan 2003 01:56:52 -0500 (EST) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id BAA10734 for ; Sun, 26 Jan 2003 01:56:02 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h0Q6u2W12295 for mpls@uu.net; Sun, 26 Jan 2003 01:56:02 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnzgt19935 for ; Sun, 26 Jan 2003 06:55:39 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnzgt12497 for ; Sun, 26 Jan 2003 06:55:00 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnzgt20225 for ; Sun, 26 Jan 2003 06:54:59 GMT Received: from wnjdyk by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: www.hakwr-neustadt.ac.at [193.170.208.153]) id QQnzgt20195 for ; Sun, 26 Jan 2003 06:54:55 GMT From: Batty Enet To: Subject: Re: I got laid off Date: Sun, 26 Jan 2003 00:15:16 -0500 Mime-Version: 1.0 Content-Type: text/html Content-Transfer-Encoding: base64 Message-Id: Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD48dGl0bGU+PC90aXRsZT48L2hlYWQ+DQo8Ym9keSBiZ2NvbG9yPSIj RkZGRkZGIj4NCjxkaXYgYWxpZ249ImNlbnRlciI+DQo8cD48YSBocmVmPSJodHRwOi8vd3d3 Lm1wbHNAYWJhaG9zdGluZy5uZXQvaG9tZWJhc2VkYml6Lz9hZmZpZD1vODg4JmU9bXBsc0B1 dS5uZXQiPjxpbWcgc3JjPSJodHRwOi8vMjEwLjIyLjE0NC4xOTgvYml6b3AuZ2lmIiB3aWR0 aD01NTAgaGVpZ2h0PTQwMCBib3JkZXI9MD48L2E+DQo8cD4mbmJzcDs8L3A+DQo8cD48Zm9u dCBmYWNlPUFyaWFsIHNpemU9MSBjb2xvcj1zaWx2ZXI+V291bGQgbGlrZSB0byBsZWF2ZSB1 cz8gPGEgaHJlZj0iaHR0cDovL3d3dy5tcGxzQGFiYWhvc3RpbmcubmV0L3IvIj5zaG93IG1l PC9hPm5kcXN2dnVuZGttb295dmt4bm1wd3ZmYWxrbGQ8YnI+DQpBIGpvYiBhcHBsaWNhbnQg Y2hhbGxlbmdlZCB0aGUgaW50ZXJ2aWV3ZXIgdG8gYW4gYXJtIHdyZXN0bGUuPGJyPmBXaGF0 J3Mgc28gdW5wbGVhc2VudCBhYm91dCBiZWluZyBkcnVuaz8nDQo8L2ZvbnQ+DQo8L2Rpdj4N CjwvYm9keT4NCjwvaHRtbD4NCg== From owner-mpls@UU.NET Sun Jan 26 23:14:00 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA26331 for ; Sun, 26 Jan 2003 23:14:00 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnzkb00048 for ; Mon, 27 Jan 2003 04:17:29 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnzkb29964; Mon, 27 Jan 2003 04:17:26 GMT Received: by mail-control.ash.ops.us.uu.net id QQnzkb05250 for mpls-outgoing; Mon, 27 Jan 2003 04:17:14 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnzkb05245 for ; Mon, 27 Jan 2003 04:17:07 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnzkb01209 for ; Mon, 27 Jan 2003 04:15:06 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnzkb27447 for ; Mon, 27 Jan 2003 04:15:05 GMT Received: from rtp-msg-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-msg-core-1.cisco.com [161.44.11.97]) id QQnzkb27408 for ; Mon, 27 Jan 2003 04:15:04 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h0R4Fqsf027757 for ; Sun, 26 Jan 2003 23:15:52 -0500 (EST) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id XAA13943 for ; Sun, 26 Jan 2003 23:15:03 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h0R4F2F18563 for mpls@uu.net; Sun, 26 Jan 2003 23:15:02 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnzka04721 for ; Mon, 27 Jan 2003 04:14:17 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnzka19680 for ; Mon, 27 Jan 2003 04:10:50 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnzka24051 for ; Mon, 27 Jan 2003 04:10:49 GMT Received: from boreas.isi.edu by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: boreas.isi.edu [128.9.160.161]) id QQnzka24042 for ; Mon, 27 Jan 2003 04:10:49 GMT Received: (from braden@localhost) by boreas.isi.edu (8.11.6/8.11.2) id h0R4AcU23818; Sun, 26 Jan 2003 20:10:38 -0800 (PST) Date: Sun, 26 Jan 2003 20:10:38 -0800 (PST) From: Bob Braden Message-Id: <200301270410.h0R4AcU23818@boreas.isi.edu> To: David.Charlap@marconi.com, braden@ISI.EDU, lmak@lucent.com Subject: Re: [Rsvp] RE: IANA Considerations for RSVP Cc: rsvp@ISI.EDU, ccamp@ops.ietf.org, mpls@UU.NET, kireeti@juniper.net, iana@ISI.EDU, sob@harvard.edu, mankin@psg.com, bwijnen@lucent.com X-Sun-Charset: US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk *> David *> *> You wrote: *> *> > In other words, these groups seem to want to forcibly change *> > RSVP into a protocol that more closely resembles some other *> > protocol that they're more intimately familiar with. *> *> My recollection of history brings me to a little paraphrasing of *> your statement: *> *> - In other words, the IETF seemed to want to forcibly change *> - transport networking into a thing that more closely resembles Sorry, I am unfamiliar with the term "transport networking". Could you explain it please? Thanks, Bob Braden *> - some other network that they're more intimately familiar with. *> *> If you agree, let's than put the pots and the kettles where they *> belong and join forces on a constructive way forward. That is *> in our common interest. *> *> Leen Mak. *> *> *> _______________________________________________ *> Rsvp mailing list *> Rsvp@mailman.isi.edu *> http://mailman.isi.edu/mailman/listinfo/rsvp *> From owner-mpls@UU.NET Sun Jan 26 23:24:18 2003 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA26410 for ; Sun, 26 Jan 2003 23:24:18 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnzkb12026 for ; Mon, 27 Jan 2003 04:27:45 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnzkb11592; Mon, 27 Jan 2003 04:27:32 GMT Received: by mail-control.ash.ops.us.uu.net id QQnzkb06053 for mpls-outgoing; Mon, 27 Jan 2003 04:27:14 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnzkb06048 for ; Mon, 27 Jan 2003 04:27:03 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnzkb05986 for ; Mon, 27 Jan 2003 04:25:07 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnzkb11483 for ; Mon, 27 Jan 2003 04:25:06 GMT Received: from rtp-msg-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-msg-core-1.cisco.com [161.44.11.97]) id QQnzkb11476 for ; Mon, 27 Jan 2003 04:25:06 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h0R4PssA028233 for ; Sun, 26 Jan 2003 23:25:54 -0500 (EST) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id XAA14174 for ; Sun, 26 Jan 2003 23:25:05 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h0R4P5D20174 for mpls@uu.net; Sun, 26 Jan 2003 23:25:05 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnzkb05797 for ; Mon, 27 Jan 2003 04:24:39 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnzkb09876 for ; Mon, 27 Jan 2003 04:23:08 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnzkb06683 for ; Mon, 27 Jan 2003 04:23:07 GMT Received: from boreas.isi.edu by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: boreas.isi.edu [128.9.160.161]) id QQnzkb06670 for ; Mon, 27 Jan 2003 04:23:07 GMT Received: (from braden@localhost) by boreas.isi.edu (8.11.6/8.11.2) id h0R4N0s28487; Sun, 26 Jan 2003 20:23:00 -0800 (PST) Date: Sun, 26 Jan 2003 20:23:00 -0800 (PST) From: Bob Braden Message-Id: <200301270423.h0R4N0s28487@boreas.isi.edu> To: David.Charlap@marconi.com Subject: Re: [Rsvp] Re: IANA Considerations for RSVP Cc: braden@ISI.EDU, rsvp@ISI.EDU, ccamp@ops.ietf.org, mpls@UU.NET, kireeti@juniper.net, iana@ISI.EDU, sob@harvard.edu, mankin@psg.com, bwijnen@lucent.com X-Sun-Charset: US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk David, I would like to mention that I thoroughly support all you have been saying in this thread -- and you have been saying it forcefully and well. Bob Braden From owner-mpls@UU.NET Sun Jan 26 23:43:04 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA26568 for ; Sun, 26 Jan 2003 23:43:04 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnzkd29723 for ; Mon, 27 Jan 2003 04:46:32 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnzkd29486; Mon, 27 Jan 2003 04:46:24 GMT Received: by mail-control.ash.ops.us.uu.net id QQnzkd07615 for mpls-outgoing; Mon, 27 Jan 2003 04:45:41 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnzkd07602 for ; Mon, 27 Jan 2003 04:45:36 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnzkc16351 for ; Mon, 27 Jan 2003 04:44:09 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnzkc27517 for ; Mon, 27 Jan 2003 04:44:08 GMT Received: from rtp-msg-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-msg-core-1.cisco.com [161.44.11.97]) id QQnzkc27472 for ; Mon, 27 Jan 2003 04:44:03 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h0R4ip7k029174 for ; Sun, 26 Jan 2003 23:44:51 -0500 (EST) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id XAA14624 for ; Sun, 26 Jan 2003 23:44:02 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h0R4i2D22575 for mpls@uu.net; Sun, 26 Jan 2003 23:44:02 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnzkc07130 for ; Mon, 27 Jan 2003 04:42:53 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnzkc27010 for ; Mon, 27 Jan 2003 04:39:19 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnzkc23912 for ; Mon, 27 Jan 2003 04:39:19 GMT Received: from boreas.isi.edu by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: boreas.isi.edu [128.9.160.161]) id QQnzkc23906 for ; Mon, 27 Jan 2003 04:39:18 GMT Received: (from braden@localhost) by boreas.isi.edu (8.11.6/8.11.2) id h0R4d7Y06027; Sun, 26 Jan 2003 20:39:07 -0800 (PST) Date: Sun, 26 Jan 2003 20:39:07 -0800 (PST) From: Bob Braden Message-Id: <200301270439.h0R4d7Y06027@boreas.isi.edu> To: David.Charlap@marconi.com, braden@ISI.EDU, rsvp@ISI.EDU, ccamp@ops.ietf.org, mpls@UU.NET, iana@ISI.EDU, sob@harvard.edu, mankin@psg.com, bwijnen@lucent.com Subject: Re: [Rsvp] RE: IANA Considerations for RSVP X-Sun-Charset: US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Friends, In trying to sort out how we should have handled RSVP_TE and all its offspring, it is instructive to read RFC 2814 that describes the Subnet Bandwidth Manager (SBM). Like RSVP-TE and its offspring, the SBM was an RSVP-like protocol for signaling at the link layer. It is carefully documented as a distinct protocol, alhtough in fact there are RSVP extensions for the SBM. It leaves RSVP as a network- (i.e., Internet-)layer protocol, as it was originally designed. I believe using the SBM approach for RSVP-TE would have avoided some of the problems we are seeing today. To imply, as I often see done, that RSVP-TE is "just RSVP with a few extensions" was and is dishonest. Its semantics are fundamentally different in important ways, even if the syntax is the same. There is more to protocols than bit and byte formats. Do we need to have this discussion of 3 large mailing lists? Bob Braden From owner-mpls@UU.NET Sun Jan 26 23:54:55 2003 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA26754 for ; Sun, 26 Jan 2003 23:54:55 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnzkd09127 for ; Mon, 27 Jan 2003 04:58:22 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnzkd08934; Mon, 27 Jan 2003 04:58:17 GMT Received: by mail-control.ash.ops.us.uu.net id QQnzkd08814 for mpls-outgoing; Mon, 27 Jan 2003 04:58:01 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnzkd08809 for ; Mon, 27 Jan 2003 04:57:57 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnzkd23635 for ; Mon, 27 Jan 2003 04:54:15 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnzkd11233 for ; Mon, 27 Jan 2003 04:54:15 GMT Received: from rtp-msg-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-msg-core-1.cisco.com [161.44.11.97]) id QQnzkd11190 for ; Mon, 27 Jan 2003 04:54:11 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h0R4sxVm029680 for ; Sun, 26 Jan 2003 23:54:59 -0500 (EST) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id XAA14884 for ; Sun, 26 Jan 2003 23:54:10 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h0R4sAn24121 for mpls@uu.net; Sun, 26 Jan 2003 23:54:10 -0500 (EST) Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnzkd08408 for ; Mon, 27 Jan 2003 04:53:04 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnzkd16173 for ; Mon, 27 Jan 2003 04:51:50 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnzkd07555 for ; Mon, 27 Jan 2003 04:51:49 GMT Received: from boreas.isi.edu by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: boreas.isi.edu [128.9.160.161]) id QQnzkd07541 for ; Mon, 27 Jan 2003 04:51:49 GMT Received: (from braden@localhost) by boreas.isi.edu (8.11.6/8.11.2) id h0R4j4Q08602; Sun, 26 Jan 2003 20:45:04 -0800 (PST) Date: Sun, 26 Jan 2003 20:45:04 -0800 (PST) From: Bob Braden Message-Id: <200301270445.h0R4j4Q08602@boreas.isi.edu> To: Dimitri.Papadimitriou@alcatel.be, BRaja@tellium.com Subject: Re: [Rsvp] RE: IANA Considerations for RSVP Cc: rsvp@ISI.EDU, ccamp@ops.ietf.org, mpls@UU.NET X-Sun-Charset: US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk *> *> Going forward, I hope the IETF makes it mandatory *> to have outside work examined in the relevant WGs with *> the same seriousness as regular WG items (or assign *> evaluation teams, like design teams). This would bring *> overall sanity and be beneficial for all groups. *> This is one good choice -- the other is to clearly fence off the non-IETF extensions with a surgeon general's warning. Bob Braden *> regards, *> *> *> Bala Rajagopalan *> Tellium, Inc. *> 2 Crescent Pl. *> Ocean Port, NJ 07757 *> USA *> Ph: +1-732-923-4237 *> Email: braja@tellium.com *> *> *> > -----Original Message----- *> > From: Dimitri.Papadimitriou@alcatel.be *> > [mailto:Dimitri.Papadimitriou@alcatel.be] *> > Sent: Friday, January 24, 2003 2:48 AM *> > To: Bala Rajagopalan *> > Cc: 'David Charlap'; Brian Hassink; Bob Braden; rsvp@ISI.EDU; *> > ccamp@ops.ietf.org; mpls@UU.NET; kireeti@juniper.net; iana@ISI.EDU; *> > sob@harvard.edu; mankin@psg.com; bwijnen@lucent.com *> > Subject: Re: IANA Considerations for RSVP *> > *> > *> > bala, *> > *> > your assertion "none of the IETF WGs (specifically, CCAMP) *> > have shown any interest in discussing the (informational) *> > drafts about ASON or OIF at any length." is not true *> > if you were really participating to the ccamp wg meeting *> > in yokohama you would have heard that the consensus was *> > (as requested by the chair) to send a ason functional *> > spec to the ccamp wg in order for the latter to define *> > the needed extensions - the proposal was to achieve *> > a first cut of these extensions in november '02 but *> > nothing happened everything goes to "informational" *> > *> > the reason why suddenly things gets tunneled until *> > reaching the current situation are still unclear for *> > me (one of the explanation i have is the clear rambo *> > competition played by the oif in backing up these *> > extensions instead of letting the corresponding *> > responsibility to the appropriate body i.e. the ietf) *> > *> > thanks, *> > - dimitri. *> > *> > Bala Rajagopalan wrote: *> > > *> > > Hello, *> > > *> > > First, the IETF has been instrumental in putting *> > > IP/MPLS protoocols for use in the optical control plane. *> > > You can't now complain that RSVP is being indiscriminately *> > > used for purposes other than intended. To quote *> > > a cliche, you can't have the cake intact and modify it *> > > too. *> > > *> > > Second, none of the IETF WGs (specifically, CCAMP) *> > > have shown any interest in discussing the (informational) *> > > drafts about ASON or OIF at any length. Serious *> > > consideration by the WGs should lead to an examination *> > > of the solutions proposed and a liaison to ITU-T or OIF *> > > or whichever body about tweaks that are out *> > > of whack with the protocol architecture. *> > > Instead, what we usually end up with are WG *> > > Rambos who simply shoot down the entire model of *> > > ITU-T or OIF and move on. *> > > *> > > Finally, it's not so easy to steer away from RSVP altogether *> > > (even if it makes sense to do so) *> > > due to the installed code base of dominant vendors. *> > > *> > > In summary, there is a lot of pressure to use RSVP outside *> > > of IETF, and the IETF should systematically review the *> > > outside work to ensure technical sanity. *> > > *> > > Regards, *> > > *> > > Bala Rajagopalan *> > > Tellium, Inc. *> > > 2 Crescent Pl. *> > > Ocean Port, NJ 07757 *> > > USA *> > > Ph: +1-732-923-4237 *> > > Email: braja@tellium.com *> > > *> > > > -----Original Message----- *> > > > From: David Charlap [mailto:David.Charlap@marconi.com] *> > > > Sent: Thursday, January 23, 2003 11:15 AM *> > > > To: Brian Hassink *> > > > Cc: Bob Braden; rsvp@ISI.EDU; ccamp@ops.ietf.org; mpls@UU.NET; *> > > > kireeti@juniper.net; iana@ISI.EDU; sob@harvard.edu; *> > mankin@psg.com; *> > > > bwijnen@lucent.com *> > > > Subject: Re: IANA Considerations for RSVP *> > > > *> > > > *> > > > Brian Hassink wrote: *> > > > > Didn't the IETF set the precedent by extending RSVP from an *> > > > IntServ protocol to an MPLS protocol? *> > > > *> > > > There's a big difference. MPLS and IntServ are both IETF *> > > > groups. (And *> > > > RSVP has/had its own working group anyway). Also, most of *> > > > the key RSVP *> > > > people were involved in the development of RSVP-TE. *> > > > *> > > > This is very different from what I'm describing - where *> > > > people who have *> > > > no prior RSVP experience decide that they can start changing *> > > > it without *> > > > understing it, and without even notifying the IETF groups *> > > > that did all *> > > > of the development work. *> > > > *> > > > I'mnot saying that RSVP should never be extended. I'm saying *> > > > that those *> > > > groups that are writing extensions should be consulting with *> > > > those who *> > > > have been developing and maintaining it (in the RSVP and MPLS *> > > > groups) in *> > > > order to ensure that: *> > > > - Their goal can't be achieved without extending *> > the language *> > > > - That their extension doesn't overlap a similar extension *> > > > from somebody else. *> > > > - That their extension doesn't significantly change *> > the overall *> > > > semantics of RSVP. *> > > > - That their extension is sufficiently flexible so *> > that other *> > > > groups can build off of it instead of *> > re-inventing the wheel *> > > > with yet another incompatible extension. *> > > > *> > > > Not only isn't this happening, but there appears to be no *> > > > desire to see *> > > > this happen. *> > > > *> > > > -- David *> > > > *> > *> > -- *> > Papadimitriou Dimitri *> > E-mail : dimitri.papadimitriou@alcatel.be *> > Private: http://www.rc.bel.alcatel.be/~papadimd/index.html *> > E-mail : dpapadimitriou@psg.com *> > Public : http://psg.com/~dpapadimitriou/ *> > Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium *> > Phone : Work: +32 3 2408491 - Home: +32 2 3434361 *> > *> _______________________________________________ *> Rsvp mailing list *> Rsvp@mailman.isi.edu *> http://mailman.isi.edu/mailman/listinfo/rsvp *> From owner-mpls@UU.NET Mon Jan 27 00:04:29 2003 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26865 for ; Mon, 27 Jan 2003 00:04:28 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnzke23648 for ; Mon, 27 Jan 2003 05:07:54 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnzke23271; Mon, 27 Jan 2003 05:07:43 GMT Received: by mail-control.ash.ops.us.uu.net id QQnzke27385 for mpls-outgoing; Mon, 27 Jan 2003 05:07:21 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnzke27375 for ; Mon, 27 Jan 2003 05:07:17 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnzke07647 for ; Mon, 27 Jan 2003 05:07:10 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnzke23396 for ; Mon, 27 Jan 2003 05:07:10 GMT Received: from rtp-msg-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-msg-core-1.cisco.com [161.44.11.97]) id QQnzke23388 for ; Mon, 27 Jan 2003 05:07:09 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h0R57vb7000573 for ; Mon, 27 Jan 2003 00:07:58 -0500 (EST) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id AAA15350 for ; Mon, 27 Jan 2003 00:07:08 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h0R578R26834 for mpls@uu.net; Mon, 27 Jan 2003 00:07:08 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnzke27320 for ; Mon, 27 Jan 2003 05:06:32 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnzke25668 for ; Mon, 27 Jan 2003 05:05:30 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnzke22298 for ; Mon, 27 Jan 2003 05:05:30 GMT Received: from boreas.isi.edu by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: boreas.isi.edu [128.9.160.161]) id QQnzke22276 for ; Mon, 27 Jan 2003 05:05:29 GMT Received: (from braden@localhost) by boreas.isi.edu (8.11.6/8.11.2) id h0R4Kpo27844; Sun, 26 Jan 2003 20:20:51 -0800 (PST) Date: Sun, 26 Jan 2003 20:20:51 -0800 (PST) From: Bob Braden Message-Id: <200301270420.h0R4Kpo27844@boreas.isi.edu> To: David.Charlap@marconi.com, GraIyMag@GraIyMage.com Subject: Re: [Rsvp] Re: IANA Considerations for RSVP Cc: braden@ISI.EDU, rsvp@ISI.EDU, ccamp@ops.ietf.org, mpls@UU.NET, kireeti@juniper.net, iana@ISI.EDU, sob@harvard.edu, mankin@psg.com, bwijnen@lucent.com X-Sun-Charset: US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk *> *> David, *> *> The intent to build a new protocol, rather than bastardize an existing *> one has gotten a very large number of people burned in recent times. Could you cite some specific examples of this? The one that comes to mind is LDP, I suppose. I am not sure anyone was burned by LDP, were they? Bob Braden From owner-mpls@UU.NET Mon Jan 27 01:04:09 2003 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27948 for ; Mon, 27 Jan 2003 01:04:09 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnzki18788 for ; Mon, 27 Jan 2003 06:07:37 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnzki18578; Mon, 27 Jan 2003 06:07:31 GMT Received: by mail-control.ash.ops.us.uu.net id QQnzki20305 for mpls-outgoing; Mon, 27 Jan 2003 06:07:01 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnzki20298 for ; Mon, 27 Jan 2003 06:06:51 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnzki16724 for ; Mon, 27 Jan 2003 06:06:31 GMT Received: from rtp-msg-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-msg-core-1.cisco.com [161.44.11.97]) id QQnzkb03726 for ; Mon, 27 Jan 2003 04:19:33 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h0R4JudX027960 for ; Sun, 26 Jan 2003 23:19:57 -0500 (EST) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id XAA14024 for ; Sun, 26 Jan 2003 23:19:07 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h0R4J7X18701 for mpls@uu.net; Sun, 26 Jan 2003 23:19:07 -0500 (EST) Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnzkb05299 for ; Mon, 27 Jan 2003 04:17:55 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnzkb28863 for ; Mon, 27 Jan 2003 04:17:36 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnzkb00235 for ; Mon, 27 Jan 2003 04:17:36 GMT Received: from boreas.isi.edu by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: boreas.isi.edu [128.9.160.161]) id QQnzkb00141 for ; Mon, 27 Jan 2003 04:17:32 GMT Received: (from braden@localhost) by boreas.isi.edu (8.11.6/8.11.2) id h0R4HQs26211; Sun, 26 Jan 2003 20:17:26 -0800 (PST) Date: Sun, 26 Jan 2003 20:17:26 -0800 (PST) From: Bob Braden Message-Id: <200301270417.h0R4HQs26211@boreas.isi.edu> To: sbrim@cisco.com Subject: Re: [Rsvp] Re: IANA Considerations for RSVP Cc: David.Charlap@marconi.com, braden@ISI.EDU, rsvp@ISI.EDU, ccamp@ops.ietf.org, mpls@UU.NET, kireeti@juniper.net, iana@ISI.EDU, sob@harvard.edu, mankin@psg.com, bwijnen@lucent.com X-Sun-Charset: US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk *> *> On Thu, Jan 23, 2003 11:06:53AM -0500, Brian Hassink allegedly wrote: *> > Didn't the IETF set the precedent by extending RSVP from an IntServ *> > protocol to an MPLS protocol? *> *> Check the documentation. RSVP is not an intserv protocol. It's *> (potentially) used by intserv. It's also used for other things. *> _______________________________________________ Scott, Weeellll, RSVP *was* designed as the signaling protocol for int-serv. Since we believe that generality and extensibility are Good Things, we made it general and extensible. (Again, perhaps a mistake, in retrospect ... ;-( ) Bob From owner-mpls@UU.NET Mon Jan 27 02:10:31 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08560 for ; Mon, 27 Jan 2003 02:10:30 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnzkm07681 for ; Mon, 27 Jan 2003 07:14:00 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnzkm07260; Mon, 27 Jan 2003 07:13:49 GMT Received: by mail-control.ash.ops.us.uu.net id QQnzkm14461 for mpls-outgoing; Mon, 27 Jan 2003 07:13:32 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnzkm14441 for ; Mon, 27 Jan 2003 07:13:28 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnzkm29228 for ; Mon, 27 Jan 2003 07:09:07 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnzkm18109 for ; Mon, 27 Jan 2003 07:09:07 GMT Received: from hotmail.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: dav72.sea2.hotmail.com [207.68.164.207]) id QQnzkm18100 for ; Mon, 27 Jan 2003 07:09:06 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 26 Jan 2003 23:09:06 -0800 X-Originating-IP: [128.107.253.38] From: "Rajesh R A" To: Subject: Router Alert Label Date: Mon, 27 Jan 2003 12:39:05 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00FC_01C2C601.13DD91B0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Message-ID: X-OriginalArrivalTime: 27 Jan 2003 07:09:06.0292 (UTC) FILETIME=[FAE52340:01C2C5D2] Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_00FC_01C2C601.13DD91B0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I am in need of a few clarifications regarding the use of Router Alert = Label.=20 Can the Router Alert label be the only label in the MPLS packet :-/ If = yes, is the packet now IP switched (assuming the packet is an MPLS = encapsulated IP packet) Thanks in anticipation, Rajesh Adrian Rosoga wrote: > Hi. > > I would like to know whether MPLS Router Alert option is used in any > existing product and for what purpose. > > When receiving a Router Alert packet, options would be: > > 1) drop the packet - for the lazy guys > 2) forward the packet based on the next label but do not process the > packet > 3) forward the packet and send a copy locally - as in the specs > > Is it good to use option 1? Would it any interoperability problem in > this case? Does Cisco, Juniper use Router Alert? > > Cheers, > Adrian ------=_NextPart_000_00FC_01C2C601.13DD91B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 
I am in need of a few = clarifications regarding=20 the use of Router Alert Label.
 
Can the Router Alert label be the only = label in the=20 MPLS packet :-/  If yes, is the packet now IP switched (assuming = the packet=20 is an MPLS encapsulated IP packet)
 
Thanks in anticipation,
Rajesh
 
 
Adrian Rosoga wrote:
 
> Hi.
>
> I would like = to know=20 whether MPLS Router Alert option is used in any
> existing product = and for=20 what purpose.
>
> When receiving a Router Alert packet, = options=20 would be:
>
> 1) drop the packet - for the lazy guys
> = 2)=20 forward the packet based on the next label but do not process = the
>=20 packet
> 3) forward the packet and send a copy locally - as in the = specs
>
> Is it good to use option 1? Would it any = interoperability=20 problem in
> this case? Does Cisco, Juniper use Router=20 Alert?
>
> Cheers,
> Adrian
------=_NextPart_000_00FC_01C2C601.13DD91B0-- From owner-mpls@UU.NET Mon Jan 27 15:08:35 2003 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25077 for ; Mon, 27 Jan 2003 15:08:34 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnzmm11157 for ; Mon, 27 Jan 2003 20:12:01 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnzmm10793; Mon, 27 Jan 2003 20:11:53 GMT Received: by mail-control.ash.ops.us.uu.net id QQnzmm09780 for mpls-outgoing; Mon, 27 Jan 2003 20:11:33 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnzmm09775 for ; Mon, 27 Jan 2003 20:11:28 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnzmm27829 for ; Mon, 27 Jan 2003 20:10:15 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnzmm07346 for ; Mon, 27 Jan 2003 20:10:14 GMT Received: from rtp-msg-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-msg-core-1.cisco.com [161.44.11.97]) id QQnzmm07071 for ; Mon, 27 Jan 2003 20:10:05 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h0RKAqLR022562 for ; Mon, 27 Jan 2003 15:10:52 -0500 (EST) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id PAA03376 for ; Mon, 27 Jan 2003 15:10:02 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h0RKA2128254 for mpls@uu.net; Mon, 27 Jan 2003 15:10:02 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnzmm08874 for ; Mon, 27 Jan 2003 20:09:05 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnzmm02039 for ; Mon, 27 Jan 2003 20:08:20 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnzmm29438 for ; Mon, 27 Jan 2003 20:08:19 GMT Received: from workhorse.fictitious.org by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: workhorse.fictitious.org [209.150.1.230]) id QQnzmm29403 for ; Mon, 27 Jan 2003 20:08:18 GMT Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id PAA16128; Mon, 27 Jan 2003 15:04:11 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200301272004.PAA16128@workhorse.fictitious.org> To: Bala Rajagopalan cc: "'Dimitri.Papadimitriou@alcatel.be'" , rsvp@ISI.EDU, ccamp@ops.ietf.org, mpls@UU.NET Reply-To: curtis@fictitious.org Subject: Re: IANA Considerations for RSVP In-reply-to: Your message of "Fri, 24 Jan 2003 10:47:16 EST." <05707214338CD5119BFF0040A5B170D30288972B@mail3.tellium.com> Date: Mon, 27 Jan 2003 15:04:11 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <05707214338CD5119BFF0040A5B170D30288972B@mail3.tellium.com>, Bala R ajagopalan writes: > Dimitri: > > I don't recall the particular Yokohoma consensus > you mention, although what you say could very well > have happened. All I do remember is the total lack > of interest in the audience about most of the drafts > discussed. > > My gripe is basically about the lack of a process in > the IETF to rigorously and constructively evaluate > on-going work outside. The liaisons > obviously haven't worked very well, and the efforts > by various people to bring in contributions on OIF > and ASON work have been met with cynicism. This is > the reason why there's a scramble at the last minute > to "right" things. > > Going forward, I hope the IETF makes it mandatory > to have outside work examined in the relevant WGs with > the same seriousness as regular WG items (or assign > evaluation teams, like design teams). This would bring > overall sanity and be beneficial for all groups. > > regards, > > > Bala Rajagopalan > Tellium, Inc. > 2 Crescent Pl. > Ocean Port, NJ 07757 > USA > Ph: +1-732-923-4237 > Email: braja@tellium.com Any organization or representative may sumbit an internet draft and it may be given consideration by the WG. It carries no more weight than any other individual WG submission. If the WG is not interested, that is the end of it. Curtis From owner-mpls@UU.NET Mon Jan 27 15:31:10 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25715 for ; Mon, 27 Jan 2003 15:31:10 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnzmo03604 for ; Mon, 27 Jan 2003 20:34:38 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnzmo02801; Mon, 27 Jan 2003 20:34:20 GMT Received: by mail-control.ash.ops.us.uu.net id QQnzmo11726 for mpls-outgoing; Mon, 27 Jan 2003 20:33:53 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnzmo11721 for ; Mon, 27 Jan 2003 20:33:36 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnzmo22386 for ; Mon, 27 Jan 2003 20:32:44 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnzmo18515 for ; Mon, 27 Jan 2003 20:32:43 GMT Received: from alpha2.tellium.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [65.125.55.125]) id QQnzmo18505 for ; Mon, 27 Jan 2003 20:32:42 GMT Received: from mail3.tellium.com (unverified) by alpha2.tellium.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 27 Jan 2003 15:31:23 -0500 Received: by mail3.tellium.com with Internet Mail Service (5.5.2653.19) id ; Mon, 27 Jan 2003 15:29:50 -0500 Message-ID: <05707214338CD5119BFF0040A5B170D30288973A@mail3.tellium.com> From: Bala Rajagopalan To: "'curtis@fictitious.org'" Cc: rsvp@ISI.EDU, ccamp@ops.ietf.org, mpls@UU.NET Subject: RE: IANA Considerations for RSVP Date: Mon, 27 Jan 2003 15:29:46 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk > -----Original Message----- > From: Curtis Villamizar [mailto:curtis@fictitious.org] > > Going forward, I hope the IETF makes it mandatory > > to have outside work examined in the relevant WGs with > > the same seriousness as regular WG items (or assign > > evaluation teams, like design teams). This would bring > > overall sanity and be beneficial for all groups. > > > > Any organization or representative may sumbit an internet draft and it > may be given consideration by the WG. It carries no more weight than > any other individual WG submission. > > If the WG is not interested, that is the end of it. > > Curtis > This is precisely the problem. The above mode of operation is fine when considering work to be done within an IETF WG. But it results in the sort of grumbling we heard recently when external orgs do independent work. There needs to be a process to look at external work more rigorously (or, ignore "uninteresting" work completely and not worry about IETF protocol changes elsewhere). Bala From owner-mpls@UU.NET Mon Jan 27 17:14:59 2003 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28891 for ; Mon, 27 Jan 2003 17:14:58 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnzmv04293 for ; Mon, 27 Jan 2003 22:18:21 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnzmv03620; Mon, 27 Jan 2003 22:18:04 GMT Received: by mail-control.ash.ops.us.uu.net id QQnzmv25990 for mpls-outgoing; Mon, 27 Jan 2003 22:17:35 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnzmv25985 for ; Mon, 27 Jan 2003 22:17:20 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnzmv08360 for ; Mon, 27 Jan 2003 22:17:08 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnzmv01721 for ; Mon, 27 Jan 2003 22:17:08 GMT Received: from rtp-msg-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-msg-core-1.cisco.com [161.44.11.97]) id QQnzmv01706 for ; Mon, 27 Jan 2003 22:17:07 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h0RMHqoL010913 for ; Mon, 27 Jan 2003 17:17:52 -0500 (EST) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id RAA12775 for ; Mon, 27 Jan 2003 17:17:02 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h0RMH2804391 for mpls@uu.net; Mon, 27 Jan 2003 17:17:02 -0500 (EST) Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnzmv25779 for ; Mon, 27 Jan 2003 22:15:29 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnzmu02062 for ; Mon, 27 Jan 2003 22:13:56 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnzmu24516 for ; Mon, 27 Jan 2003 22:13:55 GMT Received: from tnt.isi.edu by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: tnt.isi.edu [128.9.128.128]) id QQnzmu24490 for ; Mon, 27 Jan 2003 22:13:55 GMT Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id h0RMDlb25678; Mon, 27 Jan 2003 14:13:47 -0800 (PST) From: Bob Braden Received: (from braden@localhost) by gra.isi.edu (8.8.7/8.8.6) id WAA03652; Mon, 27 Jan 2003 22:13:47 GMT Date: Mon, 27 Jan 2003 22:13:47 GMT Message-Id: <200301272213.WAA03652@gra.isi.edu> To: David.Charlap@marconi.com, braden@ISI.EDU, rsvp@ISI.EDU, ccamp@ops.ietf.org, mpls@UU.NET, iana@ISI.EDU, sob@harvard.edu, mankin@psg.com, bwijnen@lucent.com Subject: Re: [Rsvp] RE: IANA Considerations for RSVP X-Sun-Charset: US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk *> *> *> Friends, *> *> In trying to sort out how we should have handled RSVP_TE and all its *> offspring, it is instructive to read RFC 2814 that describes the *> Subnet Bandwidth Manager (SBM). Like RSVP-TE and its offspring, I apologize for a misstatement here; I should not have singled out RSVP-TE for abuse. In fact, there are at least two or three distinct flavors of RSVP offspring: RSVP-TE for MPLS setup, the OIF folks who have an RSVP-like protocol for link-layer signaling at the UNI, and maybe the ATM folks. (I assume the GMPLS folks fall into the RSVP-TE camp.) The same comment about SBM applies equally to all these "illegitimate offspring" of RSVP. (They are each fine upstanding protocols in their own right, no doubt; it is only their parentage that is shady.) Bob Braden *> the SBM was an RSVP-like protocol for signaling at the link layer. *> It is carefully documented as a distinct protocol, alhtough in *> fact there are RSVP extensions for the SBM. It leaves RSVP as *> a network- (i.e., Internet-)layer protocol, as it was originally *> designed. *> *> I believe using the SBM approach for RSVP-TE would have avoided some of *> the problems we are seeing today. To imply, as I often see done, that *> RSVP-TE is "just RSVP with a few extensions" was and is dishonest. Its *> semantics are fundamentally different in important ways, even if the *> syntax is the same. There is more to protocols than bit and byte *> formats. *> *> Do we need to have this discussion of 3 large mailing lists? *> *> Bob Braden *> _______________________________________________ *> Rsvp mailing list *> Rsvp@mailman.isi.edu *> http://mailman.isi.edu/mailman/listinfo/rsvp *> From owner-mpls@UU.NET Mon Jan 27 17:44:11 2003 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29656 for ; Mon, 27 Jan 2003 17:44:11 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnzmx25677 for ; Mon, 27 Jan 2003 22:47:38 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnzmx25074; Mon, 27 Jan 2003 22:47:23 GMT Received: by mail-control.ash.ops.us.uu.net id QQnzmx28697 for mpls-outgoing; Mon, 27 Jan 2003 22:46:45 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnzmx28688 for ; Mon, 27 Jan 2003 22:46:42 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnzmx11483 for ; Mon, 27 Jan 2003 22:46:07 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnzmx03617 for ; Mon, 27 Jan 2003 22:46:06 GMT Received: from rtp-msg-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-msg-core-1.cisco.com [161.44.11.97]) id QQnzmx03583 for ; Mon, 27 Jan 2003 22:46:05 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h0RMksNd014472 for ; Mon, 27 Jan 2003 17:46:54 -0500 (EST) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id RAA14566 for ; Mon, 27 Jan 2003 17:46:04 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h0RMk4t07298 for mpls@uu.net; Mon, 27 Jan 2003 17:46:04 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnzmx28354 for ; Mon, 27 Jan 2003 22:45:28 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnzmx01182 for ; Mon, 27 Jan 2003 22:45:16 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnzmx20592 for ; Mon, 27 Jan 2003 22:45:16 GMT Received: from workhorse.fictitious.org by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: workhorse.fictitious.org [209.150.1.230]) id QQnzmx20562 for ; Mon, 27 Jan 2003 22:45:15 GMT Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id RAA17542; Mon, 27 Jan 2003 17:41:33 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200301272241.RAA17542@workhorse.fictitious.org> To: Bala Rajagopalan cc: "'curtis@fictitious.org'" , rsvp@ISI.EDU, ccamp@ops.ietf.org, mpls@UU.NET Reply-To: curtis@fictitious.org Subject: Re: IANA Considerations for RSVP In-reply-to: Your message of "Mon, 27 Jan 2003 15:29:46 EST." <05707214338CD5119BFF0040A5B170D30288973A@mail3.tellium.com> Date: Mon, 27 Jan 2003 17:41:33 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <05707214338CD5119BFF0040A5B170D30288973A@mail3.tellium.com>, Bala R ajagopalan writes: > > > > -----Original Message----- > > From: Curtis Villamizar [mailto:curtis@fictitious.org] > > > > Going forward, I hope the IETF makes it mandatory > > > to have outside work examined in the relevant WGs with > > > the same seriousness as regular WG items (or assign > > > evaluation teams, like design teams). This would bring > > > overall sanity and be beneficial for all groups. > > > > > > > Any organization or representative may sumbit an internet draft and it > > may be given consideration by the WG. It carries no more weight than > > any other individual WG submission. > > > > If the WG is not interested, that is the end of it. > > > > Curtis > > > > This is precisely the problem. The above mode of operation is fine > when considering work to be done within an IETF WG. But it > results in the sort of grumbling we heard recently when external > orgs do independent work. There needs to be a process to > look at external work more rigorously (or, ignore "uninteresting" > work completely and not worry about IETF protocol changes elsewhere). > > > Bala Uninteresting in this context usually means that there is no consensus on any good reason for a particular protocol extension to exist or that there is sufficient concensus that the protocol extension represents a poorly engineered solution. Its just when you ask for codepoints for "uninteresting" work that there is trouble. The IETF should not feel obligated to accommodate a study group coming to it that is trying to jam a square peg into a round hole. Curtis From owner-mpls@UU.NET Mon Jan 27 17:50:11 2003 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29772 for ; Mon, 27 Jan 2003 17:50:10 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnzmx21469 for ; Mon, 27 Jan 2003 22:53:37 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnzmx21045; Mon, 27 Jan 2003 22:53:25 GMT Received: by mail-control.ash.ops.us.uu.net id QQnzmx29307 for mpls-outgoing; Mon, 27 Jan 2003 22:53:05 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnzmx29261 for ; Mon, 27 Jan 2003 22:52:52 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnzmx26451 for ; Mon, 27 Jan 2003 22:50:17 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnzmx12385 for ; Mon, 27 Jan 2003 22:50:09 GMT Received: from rtp-msg-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-msg-core-1.cisco.com [161.44.11.97]) id QQnzmx12342 for ; Mon, 27 Jan 2003 22:50:08 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h0RMougG014815 for ; Mon, 27 Jan 2003 17:50:56 -0500 (EST) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id RAA14806 for ; Mon, 27 Jan 2003 17:50:07 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h0RMo7a07491 for mpls@uu.net; Mon, 27 Jan 2003 17:50:07 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnzmx28705 for ; Mon, 27 Jan 2003 22:47:19 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnzmw00106 for ; Mon, 27 Jan 2003 22:44:54 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnzmw00915 for ; Mon, 27 Jan 2003 22:44:54 GMT Received: from workhorse.fictitious.org by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: workhorse.fictitious.org [209.150.1.230]) id QQnzmw00805 for ; Mon, 27 Jan 2003 22:44:51 GMT Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id RAA17537; Mon, 27 Jan 2003 17:40:58 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200301272240.RAA17537@workhorse.fictitious.org> To: Stephen Trowbridge cc: John Drake , David Charlap , Brian Hassink , Bob Braden , rsvp@ISI.EDU, ccamp@ops.ietf.org, mpls@UU.NET, kireeti@juniper.net, iana@ISI.EDU, sob@harvard.edu, mankin@psg.com, bwijnen@lucent.com Reply-To: curtis@fictitious.org Subject: Re: IANA Considerations for RSVP In-reply-to: Your message of "Thu, 23 Jan 2003 16:24:31 MST." <3E3079AF.3010ED7C@lucent.com> Date: Mon, 27 Jan 2003 17:40:58 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <3E3079AF.3010ED7C@lucent.com>, Stephen Trowbridge writes: > John, > Hmmm... a bit IETF centric. > Because some portion of a problem space touches or uses an IETF protocol, > then clearly the entire problem must belong to IETF. > Consider that the ASON architecture encompasses transport networks where > what we call the transport plane (IETF calls the data plane) is not > necessarily IP. What if the addresses are NSAP addresses instead of IP > addresses? What if some or all of the signaling links employ PNNI > as a signaling protocol instead of RSVP-TE or CR-LDP? Does it still > all belong to IETF? These are problems that cannot be solved without > good cooperation between the standards organizations that are involved. > > In terms of the existance of a communication channel and procedures for > collaborating between IETF and ITU-T, this exists but perhaps, in spite > of receiving these liaisons, you have not taken the trouble to become > familiar with it. Identical text describing the collaboration process is > published as RFC 3356 in IETF and as A.Sup3 in ITU-T. We are following > the documented process, and this suggests a different answer than your > emails to the question of which side of this communication channel is > not holding up their end. > Steve Please take careful note of the last sentence. 3.2.2 ITU-T Recognition at ISOC/IETF ITU-T Study Group Chairmen can authorize one or more members to attend an IETF meeting as an official ITU-T delegate speaking authoritatively on behalf of the activities of the Study Group (or a particular Rapporteur Group). The Study Group Chairman sends the ITU-T list of delegates by email to the Working Group chair, with a copy to the Area Directors, and also to the Study Group. Note that, according to IETF process, opinions expressed by any such delegate are given equal weight with opinions expressed by other working group participants. If Sun Microsystems or Microsoft sends someone to authoritatively speak on behalf of a protocol that is documented but otherwise entirely under control of that entity, an IETF may consider documenting its existance in an "informational" document. The same applies to ITU-T sending someone to authoritatively speak on behalf of their work. Any such document is considered to be encumbered by intellectual property restrictions and therefore is treated appropriately. An IESG may consent documenting the existance of an outside effort and IETF WGs are still free to completely ignore it. This may be the case with ASON and other ITU-T requirements documents where the ITU-T has stated some requirements and where the IETF may choose to document the existance of the ITU-T requirements but is free to ignore any or all of them. Part of the reason for the turf (not really jurisdictional) issue is the overlap that occurs when considering TDM over MPLS or IP. A fundamental difference in the way the ITU-T and IETF think about this is the ITU-T sees this as a new layer under the TDM network and the IETF sees this as a means to support legacy TDM service. As with the IP QoS topic of the mid-1990s, what matters is what the providers want to do with their networks and what proves profitable to do. If the view that TDM over MPLS just serves to accommodate a declining TDM customer base proves accurate, then the IETF would be wise to ignore much of what the ITU-T is doing in this area. Back to the original question posed by Bod Braden. It might be possible for IANA or the RSVP experts (Bob) to go to a WG for a recommendation on any given request. Since RSVP is highly extensible the WG could make a recommendation that a code point for an object be added but that the WG's concensus is that the protocol is of no interest to the IETF. As long as code point space is plentiful a portion of the number space could be set aside for such allocations. [This may be the same as Bob'd Surgeon General's warning idea.] Curtis > John Drake wrote: > > > > Stephen, > > > > I appreciate all the work you've done keep the IETF informed about what the > > ITU is doing. All I can say is that it doesn't seem to have worked. Rathe > r > > than continuing to give us status reports on what the ITU is doing, I think > > it would make more sense to do the work in the appropriate IETF working > > groups. > > > > That was what I thought was the intent of the Feb 19th Liason: "We wish tha > t > > as we continue our review of these protocols you will be able to provide us > > with recommendations on how to close these and future issues." However, a > > channel of communication has not been established: how should > > recommendations and issues be communicated? Who makes these, and who > > communicates them? How does a two-way (or n-way) dialog take place? > > > > If, on the other hand, these documents were brought into an IETF WG, the > > procedures and channels of communication exist and are well-known. > > > > Thanks, > > > > John > > > > -----Original Message----- > > From: Stephen Trowbridge [mailto:sjtrowbridge@lucent.com] > > Sent: Thursday, January 23, 2003 9:21 AM > > To: David Charlap > > Cc: Brian Hassink; Bob Braden; rsvp@ISI.EDU; ccamp@ops.ietf.org; > > mpls@UU.NET; kireeti@juniper.net; iana@ISI.EDU; sob@harvard.edu; > > mankin@psg.com; bwijnen@lucent.com > > Subject: Re: IANA Considerations for RSVP > > > > David, > > To read these emails, it sounds as though you think that the people who > > are doing this are brand new to the technology and never even considered > > working with IETF to try to solve the problem. Perhaps you haven't followed > > the ccamp work so closely, but here is some history: > > - On October 21, 2001, ITU-T Study Group 15 sent IETF ccamp a liaison > > statement > > regarding our new documents with requirements and architecture for > > switched (not necessarily IP) transport networks. This included a > > protocol- > > neutral model for call and connection management (signaling). In copies > > of the ITU-T documents were made available to non-ITU-T members via an > > ftp site. The liaison was placed on the IESG web site and was presented > > in the ccamp meeting in Salt Lake City in December. At that same meeting, > > Maarten Vissers gave a technical presentation in the sub-IP area meeting > > regarding the ITU-T work in this area. > > - On February 19, 2002, ITU-T sent IETF ccamp a liaison statement regarding > > the gaps that had been identified between the ITU-T requirements (sent > > earlier) and what seemed to be implemented by the GMPLS protocols. > > Specifically, > > 1. Call & Connection separation, e.g., a call provides the service > > relationship, which may support connection operations as part of a > > call. > > 2. Additional error codes/values, for example, for connection rejection > > (invalid connection ID). > > 3. Restart mechanisms: Depending on the introduction by the ITU of > > additional > > control plane resiliency requirements, enhancements of the protocol > > (RSVP-TE, CR-LDP) "graceful restart" mechanisms may be required. > > 4. Protocol enhancements in CR-LDP for support of crankback capability > > from > > intermediate nodes. > > This liaison was presented in the Minneapolis IETF meeting during the > > ccamp > > working group and posted on the IESG web site. The liaison requested > > assistance in closing these gaps and invited input from IETF on our work > > in ITU-T. > > - At the April/May 2002 meeting of ITU-T Study Group 15 meeting, > > contributions > > were considered to close these gaps, resulting in text for draft > > Recommendations > > G.7713.2 (our rsvp-te document) and G.7713.3 (our cr-ldp document). Again > , > > we sent a liaison (dated May 10, 2002) to ask for comments on our draft > > Recommendations (made available on the ftp site), to request alignment, > > and > > to ask for IANA code point assignments. To quote from that liaison: > > "Please consider including the proposed solutions provided in G.7713.2 and > > G.7713.3 > > to update the existing GMPLS signaling work in support of ASON requirements > . > > We hope that you can help expedite the assignment of appropriate additional > > error codes/values by IANA. These are needed for both RSVP-TE and CR-LDP." > > This liaison was presented at the Yokohama IETF ccamp meeting. > > > > To refer to one point raised earlier in the thread, there are other cases > > where IANA has assigned codepoints for work outside of IETF, including > > other CCITT/ITU-T work, IEEE, IEC, etc. This request had been made last > > May, with no response. > > - Some final work was done on our drafts at a Rapporteur meeting in October > , > > with one result being another liaison (dated October 11, 2002) making > > another plea for comments and help getting the codepoints assigned. This > > liaison was presented at the Atlanta IETF ccamp meeting, and still no > > response or IANA action. > > > > To hear now that someone thinks that the ASON work in ITU-T is some kind > > of secret end-run around IETF, and not involved with or related to the > > work being done internally in IETF is absurd. At every stage of the work, > > IETF was kept informed of the work and invited to participate. At the > > invitation for help to address the additional ITU-T requirements, there > > was no response. As ITU-T progressed this work and invited further comments > > and alignment of the base GMPLS protocols, again no response. And to the > > final pleas for comments and codepoint assignments, no response. > > > > I contrast this with our interaction with the ATM forum on the same topic. > > Certain operators in ITU-T are interested in using the PNNI protocol for > > this application (rather than rsvp-te or cr-ldp). The ATM forum has > > responded with a formal liaison into the current ITU-T Study Group 15 > > meeting where they have given us a diffmarked copy with extremely > > helpful and constructive suggestions about how to align our G.7713.1 > > document with their work. > > > > After some private communication with the Area directors, we received some > > advice that one tool that might be used to finally get the IANA codepoint > > assignment complete would be to publish what we were doing in ITU-T as > > informational RFCs. This is the stage we are at today, and given the > > history I describe above, I do not think anybody can say that we are > > at this point because any of us did not do everything possible to > > do this work (a) in IETF, with the initial communication of requirements; > > or (b) in cooperation between ITU-T and IETF, once this work had > > progressed in ITU-T. > > > > But this is all water under the bridge. We are at the point of trying > > to get some codepoints assigned for ITU-T documents we are trying to > > complete. Nobody should say "no" at this point because they think we > > didn't try to work this IN or WITH IETF first. It should be clear to > > all that this is not the case. > > Regards, > > Steve Trowbridge > > (vice-chairman, ITU-T Study Group 15) > > > > David Charlap wrote: > > > > > > Brian Hassink wrote: > > > > Didn't the IETF set the precedent by extending RSVP from an IntServ > > protocol to an MPLS protocol? > > > > > > There's a big difference. MPLS and IntServ are both IETF groups. (And > > > RSVP has/had its own working group anyway). Also, most of the key RSVP > > > people were involved in the development of RSVP-TE. > > > > > > This is very different from what I'm describing - where people who have > > > no prior RSVP experience decide that they can start changing it without > > > understing it, and without even notifying the IETF groups that did all > > > of the development work. > > > > > > I'mnot saying that RSVP should never be extended. I'm saying that those > > > groups that are writing extensions should be consulting with those who > > > have been developing and maintaining it (in the RSVP and MPLS groups) in > > > order to ensure that: > > > - Their goal can't be achieved without extending the language > > > - That their extension doesn't overlap a similar extension > > > from somebody else. > > > - That their extension doesn't significantly change the overall > > > semantics of RSVP. > > > - That their extension is sufficiently flexible so that other > > > groups can build off of it instead of re-inventing the wheel > > > with yet another incompatible extension. > > > > > > Not only isn't this happening, but there appears to be no desire to see > > > this happen. > > > > > > -- David > From owner-mpls@UU.NET Tue Jan 28 05:27:16 2003 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA20387 for ; Tue, 28 Jan 2003 05:27:15 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnzos03933 for ; Tue, 28 Jan 2003 10:30:44 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnzos03745; Tue, 28 Jan 2003 10:30:38 GMT Received: by mail-control.ash.ops.us.uu.net id QQnzos00401 for mpls-outgoing; Tue, 28 Jan 2003 10:30:15 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnzos00396 for ; Tue, 28 Jan 2003 10:30:12 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnzor26430 for ; Tue, 28 Jan 2003 10:29:26 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnzor27688 for ; Tue, 28 Jan 2003 10:29:26 GMT Received: from p-mail2 by cmr2.ash.ops.us.uu.net with SMTP (peer crosschecked as: p-mail2.rd.francetelecom.com [193.49.124.32]) id QQnzor27678 for ; Tue, 28 Jan 2003 10:29:25 GMT Received: from parsmtp2.rd.francetelecom.com ([10.193.117.129]) by 192.144.74.32 with InterScan Messaging Security Suite; Tue, 28 Jan 2003 11:33:13 +0100 Received: from lanmhs30.rd.francetelecom.fr ([10.193.21.61]) by parsmtp2.rd.francetelecom.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 28 Jan 2003 11:27:18 +0100 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Subject: RE: draft-yasukawa-mpls-rsvp-p2mp-00.txt Date: Tue, 28 Jan 2003 11:27:17 +0100 Message-ID: <1FB136FD10CE33409C882630E299F5BE1EDBEA@lanmhs30.rd.francetelecom.fr> Thread-Topic: draft-yasukawa-mpls-rsvp-p2mp-00.txt Thread-Index: AcLCvCwPXicJgg2SRp+nlpiLXLVzdwD+Q3Hg From: "LE ROUX Jean-Louis FTRD/DAC/LAN" To: "Seisho Yasukawa" Cc: , "LARREUR-HEMON Elodie FTRD/DAC/LAN" X-OriginalArrivalTime: 28 Jan 2003 10:27:18.0272 (UTC) FILETIME=[D57B0800:01C2C6B7] Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id FAA20387 Hi Seisho and all We read your draft with much interest, and consider this is a good approach for multicast MPLS-TE tunnels. We have several comments regarding leaf initiated Joining/pruning procedures, and the interaction with access multicast protocols like IGMP : Why does the Join/ leave messages contain the attributes of the P2MP tunnel (Session, and Sender objects) ? This requires a mechanism for the Join leaf node to dynamicaly learn these attributes. To our mind, it could be more relevant to include (S,G) or (*, G),or ({S}, {G}) in Join /Leave messages, rather than tunnel parameters. Then the sender would have knowledge of (S, G) localization, and could optimise P2MP utilisation (FEC) based on this information. In this scenario, the sender would have to maintain a table indicating the registered (S, G) attached to each leaf node. When a potential leaf node receives an IGMPv3 report message for a new (S, G), it checks if it already receives this (S, G), if no it sends a Join message to the sender node, including the (S, G). Then the sender can either graft an existing P2MP tunnel, or create a new tunnel to reach this leaf node, depending on local optimization criteria. Regards JL and Elodie -----Message d'origine----- De : Seisho Yasukawa [mailto:yasukawa.seisho@lab.ntt.co.jp] Envoye : jeudi 23 janvier 2003 09:45 A : 'mpls@UU.NET' Cc : yasukawa.seisho@lab.ntt.co.jp Objet : draft-yasukawa-mpls-rsvp-p2mp-00.txt Hello everyone, Please note that the following draft has been newly posted to MPLS WG. Extended RSVP-TE for Point-to-Multipoint LSP Tunnels A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-yasukawa-mpls-rsvp-p2mp-00.txt This draft specifies the extension to RSVP-TE signaling protocol in support of MPLS P2MP LSP creation/deletion and Leaf initiated Join/Leave signaling. We think P2MP MPLS technology will become increasingly important with the dissemination of new, real-time application, such as content delivery services and video conference, which require P2MP real-time transmission capability with much more bandwidth and stricter QoS control mechanism than conventional IP application. We NTT as a service provider really needs this kind of P2MP MPLS technology because this technology opens the possibility to offer our customer a new broadband service. We think discussion of P2MP technology agrees with the charter of this wg. And, we found that applications of "multicast explicit routing"are a target topic for "RSVP-TE "(RFC3209, Section 4.3.1) and "IP Multicast in a MPLS Environment"(RFC3353, Section.7) Therefore, we want to discuss this P2MP MPLS technology in this wg. Please give us any comments from technology, application and operation sides. We need a lot of discussion and advice for protocol architecture to improve this architecture. Thanks Seisho ------------------------------------------------------------ Please refere followings (contents of this draft). This draft include the contents of "draft-yasukawa-mpls-rsvp-p2mp-01". In this new draft, protocol architecture is modified and the protocol name was changed from "multicast" to "P2MP" to clarify the technology difference. Section 0 describes why this draft suit to this wg. Please see sec.0.4 to know the reason why we introduce P2MP tunnel without IP multicast. Section 4 describes the architecture of this protocol. The new concepts; P2MP LSP tunnel and TERO/TRRO are newly introduced. The TERO is main architecture to realize P2MP TE LSP. Section 5 - 7 describes the detailed signaling mechanisms. Section 11 shows the difference between RSVP multicasting and P2MP TE tunnels. We describe the difference between multicast LSP realized by RSVP-TE&IP multicasting and P2MP TE LSP realized by TERO. --------------------------------------------------------------- From owner-mpls@UU.NET Tue Jan 28 07:15:40 2003 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23198 for ; Tue, 28 Jan 2003 07:15:39 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnzoz03213 for ; Tue, 28 Jan 2003 12:19:09 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnzoz03015; Tue, 28 Jan 2003 12:19:02 GMT Received: by mail-control.ash.ops.us.uu.net id QQnzoz15250 for mpls-outgoing; Tue, 28 Jan 2003 12:18:45 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnzoz15245 for ; Tue, 28 Jan 2003 12:18:43 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnzoz28548 for ; Tue, 28 Jan 2003 12:15:33 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnzoz14868 for ; Tue, 28 Jan 2003 12:15:32 GMT Received: from tama5.ecl.ntt.co.jp by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: tama5.ecl.ntt.co.jp [129.60.39.102]) id QQnzoz14842 for ; Tue, 28 Jan 2003 12:15:31 GMT Received: from vcs3.rdh.ecl.ntt.co.jp (vcs3.rdh.ecl.ntt.co.jp [129.60.39.110]) by tama5.ecl.ntt.co.jp (8.9.3+3.2W/3.7W/10/21/02) with ESMTP id VAA09112; Tue, 28 Jan 2003 21:15:19 +0900 (JST) (envelope-from yasukawa.seisho@lab.ntt.co.jp) Received: from nttmail3.ecl.ntt.co.jp ([127.0.0.1]) by vcs3.rdh.ecl.ntt.co.jp (8.12.6/8.12.6) with ESMTP id h0SCFJOO025239; Tue, 28 Jan 2003 21:15:19 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (eclscan3.m.ecl.ntt.co.jp [129.60.5.69]) by nttmail3.ecl.ntt.co.jp (8.12.6/8.12.6) with ESMTP id h0SCFIFb018428; Tue, 28 Jan 2003 21:15:18 +0900 (JST) Received: from imc.m.ecl.ntt.co.jp (localhost [127.0.0.1]) by eclscan3.m.ecl.ntt.co.jp (8.9.3/3.7W) with ESMTP id VAA18733; Tue, 28 Jan 2003 21:15:18 +0900 (JST) Received: from barrister.lab.ntt.co.jp by imc.m.ecl.ntt.co.jp (8.9.3/3.7W) with ESMTP id VAA25078; Tue, 28 Jan 2003 21:15:17 +0900 (JST) Message-Id: <5.0.2.5.2.20030128200020.0437fd18@imc.m.ecl.ntt.co.jp> X-Sender: sy003@imc.m.ecl.ntt.co.jp X-Mailer: QUALCOMM Windows Eudora Version 5.0.2-J Date: Tue, 28 Jan 2003 21:16:01 +0900 To: "LE ROUX Jean-Louis FTRD/DAC/LAN" From: Seisho Yasukawa Subject: RE: draft-yasukawa-mpls-rsvp-p2mp-00.txt Cc: mpls@UU.NET, elodie.larreur@rd.francetelecom.com, yasukawa.seisho@lab.ntt.co.jp, akullber@netplane.com, DCheng@PolarisNetworks.com, Dimitri.Papadimitriou@alcatel.be, mjork@avici.com In-Reply-To: <1FB136FD10CE33409C882630E299F5BE1EDBEA@lanmhs30.rd.francet elecom.fr> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Hello JL and Elodie, Thank you for useful comments and suggestions. Please find my answers and comments in-line. >Hi Seisho and all > >We read your draft with much interest, and consider this is a good >approach for multicast MPLS-TE tunnels. > >We have several comments regarding leaf initiated Joining/pruning >procedures, and the interaction with access multicast protocols like >IGMP : > >Why does the Join/ leave messages contain the attributes of the P2MP >tunnel (Session, and Sender objects) ? The reason why these messages contain both objects is that this protocol uses both objects to identify P2MP LSP tunnel uniquely. And this Join/Leave architecture is consistent with other message architecture, like Path/Path(Graft)/Path(Prune) message. This protocol prepare same interface to LSP handler (who setup and modify LSP) in regard to LSP identification. In another word, this protocol assumes that all LSP handler knows same tunnel information. And we think this is also consistent to conventional P2P RSVP-TE idea and architecture. >This requires a mechanism for the Join leaf node to dynamicaly learn >these attributes. Yes, I agree your point. >To our mind, it could be more relevant to include (S,G) or (*, G),or >({S}, {G}) in Join /Leave messages, rather than tunnel parameters. Then >the sender would have knowledge of (S, G) localization, and could >optimise P2MP utilisation (FEC) based on this information. I like this kind of approach. As you suggested, I also think your proposal could be more relevant if a P2MP LSP convey single IP Mcast group traffic. One of my concern is what should we do when a P2MP LSP conveys multiple IP Mcast group traffic. Maybe we can resolve this issue by same mechanism. But, I think we need some sophisticated algorithm in sender/leaf node. And another concern is what should we de when a P2MP LSP conveys non-IP Mcast traffic. Considering these situation, we choose both objects for LSP identifier. >In this scenario, the sender would have to maintain a table indicating >the registered (S, G) attached to each leaf node. >When a potential leaf node receives an IGMPv3 report message for a new >(S, G), it checks if it already receives this (S, G), if no it sends a >Join message to the sender node, including the (S, G). Then the sender >can either graft an existing P2MP tunnel, or create a new tunnel to >reach this leaf node, depending on local optimization criteria. I like this approach. So, if you have any solution to above problems, please teach us your solution. And we think this technology can also applicable to P2MP backbone technology for Wireless LAN (hot spot) and CATV network in addition to content delivery network which is mentioned in draft. Using this technology, we can provide broadcast service in these network economically. We want to discuss service applicability issues with you if you have some interest in this issue. Thanks, Seisho >-----Message d'origine----- >De : Seisho Yasukawa [mailto:yasukawa.seisho@lab.ntt.co.jp] >Envoye : jeudi 23 janvier 2003 09:45 >A : 'mpls@UU.NET' >Cc : yasukawa.seisho@lab.ntt.co.jp >Objet : draft-yasukawa-mpls-rsvp-p2mp-00.txt > > >Hello everyone, > >Please note that the following draft has been newly posted to MPLS WG. > >Extended RSVP-TE for Point-to-Multipoint LSP Tunnels > > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-yasukawa-mpls-rsvp-p2mp-00.txt > >This draft specifies the extension to RSVP-TE signaling protocol >in support of MPLS P2MP LSP creation/deletion and Leaf initiated >Join/Leave signaling. > >We think P2MP MPLS technology will become increasingly important >with the dissemination of new, real-time application, such as content >delivery services and video conference, which require P2MP real-time >transmission capability with much more bandwidth and stricter QoS >control mechanism than conventional IP application. > >We NTT as a service provider really needs this kind of P2MP MPLS >technology because this technology opens the possibility to offer >our customer a new broadband service. > >We think discussion of P2MP technology agrees with the charter of this >wg. >And, we found that applications of "multicast explicit routing"are a >target >topic for "RSVP-TE "(RFC3209, Section 4.3.1) and "IP Multicast in a MPLS >Environment"(RFC3353, Section.7) > >Therefore, we want to discuss this P2MP MPLS technology in this wg. > >Please give us any comments from technology, application and operation >sides. > >We need a lot of discussion and advice for protocol architecture to >improve >this architecture. > > >Thanks > >Seisho > >------------------------------------------------------------ >Please refere followings (contents of this draft). > >This draft include the contents of "draft-yasukawa-mpls-rsvp-p2mp-01". >In this new draft, protocol architecture is modified and the protocol >name >was changed from "multicast" to "P2MP" to clarify the technology >difference. > >Section 0 describes why this draft suit to this wg. >Please see sec.0.4 to know the reason why we introduce P2MP tunnel >without IP multicast. > >Section 4 describes the architecture of this protocol. >The new concepts; P2MP LSP tunnel and TERO/TRRO are newly introduced. >The TERO is main architecture to realize P2MP TE LSP. > >Section 5 - 7 describes the detailed signaling mechanisms. > >Section 11 shows the difference between RSVP multicasting and P2MP >TE tunnels. > >We describe the difference between multicast LSP realized by >RSVP-TE&IP multicasting and P2MP TE LSP realized by TERO. >--------------------------------------------------------------- From owner-mpls@UU.NET Tue Jan 28 08:19:08 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25306 for ; Tue, 28 Jan 2003 08:19:08 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnzpd17097 for ; Tue, 28 Jan 2003 13:22:35 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnzpd16935; Tue, 28 Jan 2003 13:22:30 GMT Received: by mail-control.ash.ops.us.uu.net id QQnzpd08482 for mpls-outgoing; Tue, 28 Jan 2003 13:22:20 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnzpd08472 for ; Tue, 28 Jan 2003 13:22:16 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnzpd14267 for ; Tue, 28 Jan 2003 13:19:13 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnzpd24333 for ; Tue, 28 Jan 2003 13:19:12 GMT Received: from rtp-msg-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-msg-core-1.cisco.com [161.44.11.97]) id QQnzpd24216 for ; Tue, 28 Jan 2003 13:19:03 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h0SDJpl0014328 for ; Tue, 28 Jan 2003 08:19:52 -0500 (EST) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id IAA20323 for ; Tue, 28 Jan 2003 08:19:01 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h0SDJ1t08608 for mpls@uu.net; Tue, 28 Jan 2003 08:19:01 -0500 (EST) Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnzpd08220 for ; Tue, 28 Jan 2003 13:17:52 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnzpd06978 for ; Tue, 28 Jan 2003 13:17:22 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnzpd23121 for ; Tue, 28 Jan 2003 13:17:22 GMT Received: from sj-msg-core-4.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-4.cisco.com [171.71.163.54]) id QQnzpd23113 for ; Tue, 28 Jan 2003 13:17:21 GMT Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-msg-core-4.cisco.com (8.12.2/8.12.6) with ESMTP id h0SDFmap013299; Tue, 28 Jan 2003 05:15:48 -0800 (PST) Received: from cisco.com (ams-rraszuk-vpn5.cisco.com [10.61.160.6]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id ADQ49192; Tue, 28 Jan 2003 05:12:04 -0800 (PST) Message-ID: <3E36827A.1424B474@cisco.com> Date: Tue, 28 Jan 2003 14:15:38 +0100 From: Robert Raszuk Reply-To: raszuk@cisco.com Organization: Signature: http://www.employees.org/~raszuk/sig/ X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Seisho Yasukawa CC: LE ROUX Jean-Louis FTRD/DAC/LAN , mpls@UU.NET, elodie.larreur@rd.francetelecom.com, akullber@netplane.com, DCheng@PolarisNetworks.com, Dimitri.Papadimitriou@alcatel.be, mjork@avici.com Subject: Re: draft-yasukawa-mpls-rsvp-p2mp-00.txt References: <5.0.2.5.2.20030128200020.0437fd18@imc.m.ecl.ntt.co.jp> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi Seisho, > I like this kind of approach. > As you suggested, I also think your proposal could be more relevant > if a P2MP LSP convey single IP Mcast group traffic. > > One of my concern is what should we do when a P2MP LSP conveys > multiple IP Mcast group traffic. I think both cases for p2mp LSP carrying single and multiple multicast groups should be supported. Further it would be up to the IGMP report recepient to make the decision if new LSP needs to be created or if any of his present LSPs can be extended (for example by changing constrains in the shared explicit way) to carry new multicast group(s). > Considering these situation, we choose both objects for LSP identifier. If you are planning to use any P2MP LSP for multiple groups pipe how do you calculate tunnel id ? In other words if all multicast packets will arrive at the egrees unlabed (PHP) or even labeled (no PHP) are you assuming another IP lookup/RPF check to send it to receivers ? In other words maybe at some point just lookup on the LFIB would be in order and label stack would be the tool ? Just trying to make sure that forwarding wise egress performance will be doable. Another interesting point is that there could be cases (transient or permanent) that some received groups should be filtered on the egress of the P2MP LSP rather then always forwarding it to the potential receiver. Dropping them based on the label is much more eficient then processing by CPU and dropping later ;). Also considering that LSPs are unidirectional (well at least today in some implementations :) it would be nice to address explicitely how and if RPF on egrees should be performed. Thx, R. > Seisho Yasukawa wrote: > > Hello JL and Elodie, > > Thank you for useful comments and suggestions. > Please find my answers and comments in-line. > > >Hi Seisho and all > > > >We read your draft with much interest, and consider this is a good > >approach for multicast MPLS-TE tunnels. > > > >We have several comments regarding leaf initiated Joining/pruning > >procedures, and the interaction with access multicast protocols like > >IGMP : > > > >Why does the Join/ leave messages contain the attributes of the P2MP > >tunnel (Session, and Sender objects) ? > > The reason why these messages contain both objects is that this > protocol uses both objects to identify P2MP LSP tunnel uniquely. > And this Join/Leave architecture is consistent with other message > architecture, like Path/Path(Graft)/Path(Prune) message. > This protocol prepare same interface to LSP handler (who setup and > modify LSP) in regard to LSP identification. > In another word, this protocol assumes that all LSP handler knows > same tunnel information. > And we think this is also consistent to conventional P2P RSVP-TE > idea and architecture. > > >This requires a mechanism for the Join leaf node to dynamicaly learn > >these attributes. > > Yes, I agree your point. > > >To our mind, it could be more relevant to include (S,G) or (*, G),or > >({S}, {G}) in Join /Leave messages, rather than tunnel parameters. Then > >the sender would have knowledge of (S, G) localization, and could > >optimise P2MP utilisation (FEC) based on this information. > > I like this kind of approach. > As you suggested, I also think your proposal could be more relevant > if a P2MP LSP convey single IP Mcast group traffic. > One of my concern is what should we do when a P2MP LSP conveys > multiple IP Mcast group traffic. > Maybe we can resolve this issue by same mechanism. > But, I think we need some sophisticated algorithm in sender/leaf node. > And another concern is what should we de when a P2MP LSP conveys > non-IP Mcast traffic. > Considering these situation, we choose both objects for LSP identifier. > > >In this scenario, the sender would have to maintain a table indicating > >the registered (S, G) attached to each leaf node. > >When a potential leaf node receives an IGMPv3 report message for a new > >(S, G), it checks if it already receives this (S, G), if no it sends a > >Join message to the sender node, including the (S, G). Then the sender > >can either graft an existing P2MP tunnel, or create a new tunnel to > >reach this leaf node, depending on local optimization criteria. > > I like this approach. > So, if you have any solution to above problems, please teach us your > solution. > > And we think this technology can also applicable to > P2MP backbone technology for Wireless LAN (hot spot) and CATV network > in addition to content delivery network which is mentioned in draft. > Using this technology, we can provide broadcast service > in these network economically. > > We want to discuss service applicability issues with you > if you have some interest in this issue. > > Thanks, > > Seisho > > >-----Message d'origine----- > >De : Seisho Yasukawa [mailto:yasukawa.seisho@lab.ntt.co.jp] > >Envoye : jeudi 23 janvier 2003 09:45 > >A : 'mpls@UU.NET' > >Cc : yasukawa.seisho@lab.ntt.co.jp > >Objet : draft-yasukawa-mpls-rsvp-p2mp-00.txt > > > > > >Hello everyone, > > > >Please note that the following draft has been newly posted to MPLS WG. > > > >Extended RSVP-TE for Point-to-Multipoint LSP Tunnels > > > > > >A URL for this Internet-Draft is: > >http://www.ietf.org/internet-drafts/draft-yasukawa-mpls-rsvp-p2mp-00.txt > > > >This draft specifies the extension to RSVP-TE signaling protocol > >in support of MPLS P2MP LSP creation/deletion and Leaf initiated > >Join/Leave signaling. > > > >We think P2MP MPLS technology will become increasingly important > >with the dissemination of new, real-time application, such as content > >delivery services and video conference, which require P2MP real-time > >transmission capability with much more bandwidth and stricter QoS > >control mechanism than conventional IP application. > > > >We NTT as a service provider really needs this kind of P2MP MPLS > >technology because this technology opens the possibility to offer > >our customer a new broadband service. > > > >We think discussion of P2MP technology agrees with the charter of this > >wg. > >And, we found that applications of "multicast explicit routing"are a > >target > >topic for "RSVP-TE "(RFC3209, Section 4.3.1) and "IP Multicast in a MPLS > >Environment"(RFC3353, Section.7) > > > >Therefore, we want to discuss this P2MP MPLS technology in this wg. > > > >Please give us any comments from technology, application and operation > >sides. > > > >We need a lot of discussion and advice for protocol architecture to > >improve > >this architecture. > > > > > >Thanks > > > >Seisho > > > >------------------------------------------------------------ > >Please refere followings (contents of this draft). > > > >This draft include the contents of "draft-yasukawa-mpls-rsvp-p2mp-01". > >In this new draft, protocol architecture is modified and the protocol > >name > >was changed from "multicast" to "P2MP" to clarify the technology > >difference. > > > >Section 0 describes why this draft suit to this wg. > >Please see sec.0.4 to know the reason why we introduce P2MP tunnel > >without IP multicast. > > > >Section 4 describes the architecture of this protocol. > >The new concepts; P2MP LSP tunnel and TERO/TRRO are newly introduced. > >The TERO is main architecture to realize P2MP TE LSP. > > > >Section 5 - 7 describes the detailed signaling mechanisms. > > > >Section 11 shows the difference between RSVP multicasting and P2MP > >TE tunnels. > > > >We describe the difference between multicast LSP realized by > >RSVP-TE&IP multicasting and P2MP TE LSP realized by TERO. > >--------------------------------------------------------------- From owner-mpls@UU.NET Tue Jan 28 09:47:49 2003 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26849 for ; Tue, 28 Jan 2003 09:47:48 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnzpj16659 for ; Tue, 28 Jan 2003 14:51:17 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnzpj16206; Tue, 28 Jan 2003 14:51:04 GMT Received: by mail-control.ash.ops.us.uu.net id QQnzpj03758 for mpls-outgoing; Tue, 28 Jan 2003 14:50:38 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnzpj03740 for ; Tue, 28 Jan 2003 14:50:34 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnzpj00953 for ; Tue, 28 Jan 2003 14:49:17 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnzpj08276 for ; Tue, 28 Jan 2003 14:49:16 GMT Received: from p-mail1.rd.francetelecom.com by cmr2.ash.ops.us.uu.net with SMTP (peer crosschecked as: p-mail1.rd.francetelecom.com [193.49.124.31]) id QQnzpj08248 for ; Tue, 28 Jan 2003 14:49:14 GMT Received: from parsmtp2.rd.francetelecom.com ([10.193.117.129]) by p-mail1 with InterScan Messaging Security Suite; Tue, 28 Jan 2003 15:47:59 +0100 Received: from lanmhs30.rd.francetelecom.fr ([10.193.21.61]) by parsmtp2.rd.francetelecom.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 28 Jan 2003 15:47:40 +0100 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Subject: RE: draft-yasukawa-mpls-rsvp-p2mp-00.txt Date: Tue, 28 Jan 2003 15:47:39 +0100 Message-ID: <1FB136FD10CE33409C882630E299F5BE1EDBEB@lanmhs30.rd.francetelecom.fr> Thread-Topic: draft-yasukawa-mpls-rsvp-p2mp-00.txt Thread-Index: AcLGxvN4LcfBQYkcSumNQQUeQzmTGQAB/i4w From: "LE ROUX Jean-Louis FTRD/DAC/LAN" To: "Seisho Yasukawa" Cc: , "LARREUR-HEMON Elodie FTRD/DAC/LAN" , , , , X-OriginalArrivalTime: 28 Jan 2003 14:47:40.0712 (UTC) FILETIME=[352E3280:01C2C6DC] Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id JAA26849 Seisho, >But, I think we need some sophisticated algorithm in sender/leaf node. >And another concern is what should we de when a P2MP LSP conveys >non-IP Mcast traffic. >Considering these situation, we choose both objects for LSP identifier. I agree with you. It is important to well separate mutlicast service from P2MP LSP setup / modification, as P2MP tree can support non-IP Mcast traffic. Thus addtional procedures an message exchanges are required on top of this architecture to support multicast (S, G) Join/ Leave and to allow the sender to hold sufficient information in order to optimise multicast FEC on sender nodes. There are two options : -Use an offline tool for FEC determination and tree computation. The leaf node learns LSP parameters from this tool. -Distributed scenario: Leaf node registers (S, G) to the sender that determines which P2MP tunnel must be used, and intiates grafting. This requires a new (possibly RSVP) message to support such (S, G) registation. (Note that IGMPv2 raises an additional sender localisation issue). Regards JL -----Message d'origine----- De : Seisho Yasukawa [mailto:yasukawa.seisho@lab.ntt.co.jp] Envoye : mardi 28 janvier 2003 13:16 A : LE ROUX Jean-Louis FTRD/DAC/LAN Cc : mpls@UU.NET; LARREUR-HEMON Elodie FTRD/DAC/LAN; yasukawa.seisho@lab.ntt.co.jp; akullber@netplane.com; DCheng@PolarisNetworks.com; Dimitri.Papadimitriou@alcatel.be; mjork@avici.com Objet : RE: draft-yasukawa-mpls-rsvp-p2mp-00.txt Hello JL and Elodie, Thank you for useful comments and suggestions. Please find my answers and comments in-line. >Hi Seisho and all > >We read your draft with much interest, and consider this is a good >approach for multicast MPLS-TE tunnels. > >We have several comments regarding leaf initiated Joining/pruning >procedures, and the interaction with access multicast protocols like >IGMP : > >Why does the Join/ leave messages contain the attributes of the P2MP >tunnel (Session, and Sender objects) ? The reason why these messages contain both objects is that this protocol uses both objects to identify P2MP LSP tunnel uniquely. And this Join/Leave architecture is consistent with other message architecture, like Path/Path(Graft)/Path(Prune) message. This protocol prepare same interface to LSP handler (who setup and modify LSP) in regard to LSP identification. In another word, this protocol assumes that all LSP handler knows same tunnel information. And we think this is also consistent to conventional P2P RSVP-TE idea and architecture. >This requires a mechanism for the Join leaf node to dynamicaly learn >these attributes. Yes, I agree your point. >To our mind, it could be more relevant to include (S,G) or (*, G),or >({S}, {G}) in Join /Leave messages, rather than tunnel parameters. Then >the sender would have knowledge of (S, G) localization, and could >optimise P2MP utilisation (FEC) based on this information. I like this kind of approach. As you suggested, I also think your proposal could be more relevant if a P2MP LSP convey single IP Mcast group traffic. One of my concern is what should we do when a P2MP LSP conveys multiple IP Mcast group traffic. Maybe we can resolve this issue by same mechanism. But, I think we need some sophisticated algorithm in sender/leaf node. And another concern is what should we de when a P2MP LSP conveys non-IP Mcast traffic. Considering these situation, we choose both objects for LSP identifier. >In this scenario, the sender would have to maintain a table indicating >the registered (S, G) attached to each leaf node. >When a potential leaf node receives an IGMPv3 report message for a new >(S, G), it checks if it already receives this (S, G), if no it sends a >Join message to the sender node, including the (S, G). Then the sender >can either graft an existing P2MP tunnel, or create a new tunnel to >reach this leaf node, depending on local optimization criteria. I like this approach. So, if you have any solution to above problems, please teach us your solution. And we think this technology can also applicable to P2MP backbone technology for Wireless LAN (hot spot) and CATV network in addition to content delivery network which is mentioned in draft. Using this technology, we can provide broadcast service in these network economically. We want to discuss service applicability issues with you if you have some interest in this issue. Thanks, Seisho >-----Message d'origine----- >De : Seisho Yasukawa [mailto:yasukawa.seisho@lab.ntt.co.jp] >Envoye : jeudi 23 janvier 2003 09:45 >A : 'mpls@UU.NET' >Cc : yasukawa.seisho@lab.ntt.co.jp >Objet : draft-yasukawa-mpls-rsvp-p2mp-00.txt > > >Hello everyone, > >Please note that the following draft has been newly posted to MPLS WG. > >Extended RSVP-TE for Point-to-Multipoint LSP Tunnels > > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-yasukawa-mpls-rsvp-p2mp-00.tx t > >This draft specifies the extension to RSVP-TE signaling protocol >in support of MPLS P2MP LSP creation/deletion and Leaf initiated >Join/Leave signaling. > >We think P2MP MPLS technology will become increasingly important >with the dissemination of new, real-time application, such as content >delivery services and video conference, which require P2MP real-time >transmission capability with much more bandwidth and stricter QoS >control mechanism than conventional IP application. > >We NTT as a service provider really needs this kind of P2MP MPLS >technology because this technology opens the possibility to offer >our customer a new broadband service. > >We think discussion of P2MP technology agrees with the charter of this >wg. >And, we found that applications of "multicast explicit routing"are a >target >topic for "RSVP-TE "(RFC3209, Section 4.3.1) and "IP Multicast in a MPLS >Environment"(RFC3353, Section.7) > >Therefore, we want to discuss this P2MP MPLS technology in this wg. > >Please give us any comments from technology, application and operation >sides. > >We need a lot of discussion and advice for protocol architecture to >improve >this architecture. > > >Thanks > >Seisho > >------------------------------------------------------------ >Please refere followings (contents of this draft). > >This draft include the contents of "draft-yasukawa-mpls-rsvp-p2mp-01". >In this new draft, protocol architecture is modified and the protocol >name >was changed from "multicast" to "P2MP" to clarify the technology >difference. > >Section 0 describes why this draft suit to this wg. >Please see sec.0.4 to know the reason why we introduce P2MP tunnel >without IP multicast. > >Section 4 describes the architecture of this protocol. >The new concepts; P2MP LSP tunnel and TERO/TRRO are newly introduced. >The TERO is main architecture to realize P2MP TE LSP. > >Section 5 - 7 describes the detailed signaling mechanisms. > >Section 11 shows the difference between RSVP multicasting and P2MP >TE tunnels. > >We describe the difference between multicast LSP realized by >RSVP-TE&IP multicasting and P2MP TE LSP realized by TERO. >--------------------------------------------------------------- From owner-mpls@UU.NET Tue Jan 28 10:58:28 2003 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29041 for ; Tue, 28 Jan 2003 10:58:26 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnzpo04177 for ; Tue, 28 Jan 2003 16:01:51 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnzpo03874; Tue, 28 Jan 2003 16:01:43 GMT Received: by mail-control.ash.ops.us.uu.net id QQnzpo01329 for mpls-outgoing; Tue, 28 Jan 2003 16:01:24 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnzpo01166 for ; Tue, 28 Jan 2003 16:01:13 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnzpo20083 for ; Tue, 28 Jan 2003 16:01:06 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnzpo10709 for ; Tue, 28 Jan 2003 16:01:06 GMT Received: from rtp-msg-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-msg-core-1.cisco.com [161.44.11.97]) id QQnzpo10692 for ; Tue, 28 Jan 2003 16:01:05 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h0SG1ssw007430 for ; Tue, 28 Jan 2003 11:01:54 -0500 (EST) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id LAA00781 for ; Tue, 28 Jan 2003 11:01:04 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h0SG14Q16639 for mpls@uu.net; Tue, 28 Jan 2003 11:01:04 -0500 (EST) Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnzpo25573 for ; Tue, 28 Jan 2003 16:00:04 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnzpn02230 for ; Tue, 28 Jan 2003 15:57:09 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnzpn07278 for ; Tue, 28 Jan 2003 15:57:09 GMT Received: from rtp-msg-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-msg-core-1.cisco.com [161.44.11.97]) id QQnzpn07268 for ; Tue, 28 Jan 2003 15:57:08 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h0SFvM28006596; Tue, 28 Jan 2003 10:57:22 -0500 (EST) Received: from bifocal.cisco.com (bifocal.cisco.com [161.44.172.150]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA00444; Tue, 28 Jan 2003 10:56:31 -0500 (EST) Received: from localhost (swallow@localhost) by bifocal.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id KAA00959; Tue, 28 Jan 2003 10:56:31 -0500 (EST) Message-Id: <200301281556.KAA00959@bifocal.cisco.com> X-Authentication-Warning: bifocal.cisco.com: swallow owned process doing -bs To: "LE ROUX Jean-Louis FTRD/DAC/LAN" cc: "Seisho Yasukawa" , mpls@UU.NET, "LARREUR-HEMON Elodie FTRD/DAC/LAN" , swallow@cisco.com Subject: Re: draft-yasukawa-mpls-rsvp-p2mp-00.txt In-reply-to: Your message of "Tue, 28 Jan 2003 11:27:17 +0100." <1FB136FD10CE33409C882630E299F5BE1EDBEA@lanmhs30.rd.francetelecom.fr> Date: Tue, 28 Jan 2003 10:56:31 -0500 From: George Swallow Sender: owner-mpls@UU.NET Precedence: bulk > Hi Seisho and all > > We read your draft with much interest, and consider this is a good > approach for multicast MPLS-TE tunnels. > > We have several comments regarding leaf initiated Joining/pruning > procedures, and the interaction with access multicast protocols like > IGMP : > > Why does the Join/ leave messages contain the attributes of the P2MP > tunnel (Session, and Sender objects) ? > This requires a mechanism for the Join leaf node to dynamicaly learn > these attributes. > > To our mind, it could be more relevant to include (S,G) or (*, G),or > ({S}, {G}) in Join /Leave messages, rather than tunnel parameters. Then > the sender would have knowledge of (S, G) localization, and could > optimise P2MP utilisation (FEC) based on this information. > > In this scenario, the sender would have to maintain a table indicating > the registered (S, G) attached to each leaf node. > When a potential leaf node receives an IGMPv3 report message for a new > (S, G), it checks if it already receives this (S, G), if no it sends a > Join message to the sender node, including the (S, G). Then the sender > can either graft an existing P2MP tunnel, or create a new tunnel to > reach this leaf node, depending on local optimization criteria. I very much agree. This draft is not simply an extension to RSVP for multicast tunnels. It actually defines a new multicast protocol. As such it is: a) a mis-use of RSVP (note the thread on IANA Considerations for RSVP) b) not completely in the scope of the MPLS wg. While the MPLS wg can look for ways to support multicast, it is not now (or ever likely to be) in the charter of the workgroup to define a new multicast protocol. RSVP should simply be used to build the tree. All of the join/leave activity belongs in a multicast protocol. ...George ================================================================== George Swallow Cisco Systems (978) 497-8143 250 Apollo Drive Chelmsford, Ma 01824 From owner-mpls@UU.NET Wed Jan 29 05:29:09 2003 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14974 for ; Wed, 29 Jan 2003 05:29:09 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnzsk16804 for ; Wed, 29 Jan 2003 10:32:38 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnzsk16651; Wed, 29 Jan 2003 10:32:35 GMT Received: by mail-control.ash.ops.us.uu.net id QQnzsk01365 for mpls-outgoing; Wed, 29 Jan 2003 10:32:20 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnzsk01358 for ; Wed, 29 Jan 2003 10:32:17 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnzsk01817 for ; Wed, 29 Jan 2003 10:30:59 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnzsk15064 for ; Wed, 29 Jan 2003 10:30:58 GMT Received: from relay2.clb.oleane.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: relay2.clb.oleane.net [213.56.31.22]) id QQnzsk15020 for ; Wed, 29 Jan 2003 10:30:57 GMT Received: from oleane (upper-side.rain.fr [194.250.212.114]) by relay2.clb.oleane.net with SMTP id h0TAUuDY028552 for ; Wed, 29 Jan 2003 11:30:56 +0100 Message-ID: <022e01c2c781$a5628100$0601a8c0@oleane.com> From: "Peter Lewis" To: Subject: MPLS interop Event Date: Wed, 29 Jan 2003 11:31:55 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_022B_01C2C78A.06D2FCA0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_022B_01C2C78A.06D2FCA0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Multivendor interoperability event next week in Paris: MPLS is resilient = and scalable. =20 According to the EANTC the hotstaging has been completed successfully.=20 Hot topics tested during the interoperability event: . Virtual Private Networks (VPNs) . Fast Rerouting=20 This event is organized by the MPLS Forum and EANTC, in cooperation with = the ETSI=20 Interoperability Service. =20 Get more details at: http://www.upperside.fr/mplswc2003/mplswc03intro.htm ------=_NextPart_000_022B_01C2C78A.06D2FCA0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Multivendor interoperability event next week in = Paris:=20 MPLS is resilient and = scalable.  
According to the EANTC the hotstaging has = been=20 completed successfully. 
Hot topics tested during the interoperability=20 event:
• Virtual Private Networks (VPNs)
• = Fast Rerouting=20
This event is organized by the MPLS Forum and = EANTC, in=20 cooperation with the ETSI
Interoperability Service.
 
Get more details at:
http://www.= upperside.fr/mplswc2003/mplswc03intro.htm
 
 
------=_NextPart_000_022B_01C2C78A.06D2FCA0-- From owner-mpls@UU.NET Wed Jan 29 05:32:09 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15049 for ; Wed, 29 Jan 2003 05:32:09 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnzsk05678 for ; Wed, 29 Jan 2003 10:35:38 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnzsk05354; Wed, 29 Jan 2003 10:35:31 GMT Received: by mail-control.ash.ops.us.uu.net id QQnzsk01449 for mpls-outgoing; Wed, 29 Jan 2003 10:35:04 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnzsk01438 for ; Wed, 29 Jan 2003 10:34:52 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnzsk05024 for ; Wed, 29 Jan 2003 10:32:58 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnzsk17541 for ; Wed, 29 Jan 2003 10:32:56 GMT Received: from tama5.ecl.ntt.co.jp by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: tama5.ecl.ntt.co.jp [129.60.39.102]) id QQnzsk17448 for ; Wed, 29 Jan 2003 10:32:53 GMT Received: from vcs3.rdh.ecl.ntt.co.jp (vcs3.rdh.ecl.ntt.co.jp [129.60.39.110]) by tama5.ecl.ntt.co.jp (8.9.3+3.2W/3.7W/10/21/02) with ESMTP id TAA29316; Wed, 29 Jan 2003 19:32:41 +0900 (JST) (envelope-from yasukawa.seisho@lab.ntt.co.jp) Received: from nttmail3.ecl.ntt.co.jp ([127.0.0.1]) by vcs3.rdh.ecl.ntt.co.jp (8.12.6/8.12.6) with ESMTP id h0TAWeOO028460; Wed, 29 Jan 2003 19:32:41 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (eclscan3.m.ecl.ntt.co.jp [129.60.5.69]) by nttmail3.ecl.ntt.co.jp (8.12.6/8.12.6) with ESMTP id h0TAWeFb011396; Wed, 29 Jan 2003 19:32:40 +0900 (JST) Received: from imc.m.ecl.ntt.co.jp (localhost [127.0.0.1]) by eclscan3.m.ecl.ntt.co.jp (8.9.3/3.7W) with ESMTP id TAA08253; Wed, 29 Jan 2003 19:32:40 +0900 (JST) Received: from barrister.lab.ntt.co.jp by imc.m.ecl.ntt.co.jp (8.9.3/3.7W) with ESMTP id TAA21926; Wed, 29 Jan 2003 19:32:38 +0900 (JST) Message-Id: <5.0.2.5.2.20030129185820.0446f540@imc.m.ecl.ntt.co.jp> X-Sender: sy003@imc.m.ecl.ntt.co.jp X-Mailer: QUALCOMM Windows Eudora Version 5.0.2-J Date: Wed, 29 Jan 2003 19:35:57 +0900 To: George Swallow , "LE ROUX Jean-Louis FTRD/DAC/LAN" From: Seisho Yasukawa Subject: Re: draft-yasukawa-mpls-rsvp-p2mp-00.txt Cc: mpls@UU.NET, "LARREUR-HEMON Elodie FTRD/DAC/LAN" , swallow@cisco.com In-Reply-To: <200301281556.KAA00959@bifocal.cisco.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Hello George, I understand your concern about our P2MP draft. Let me explain our intention and understanding again. When we propose this draft, we are not intending to develop a new multicast protocol over conventional RSVP-TE framework. I think, defining multicast protocol requires a mechanism which calculates multicast tree in itself. But our proposed draft doesn't have such a mechanism in itself. In our design, TERO (Tree Explicit Object) is introduced and P2MP LSP is established using TERO. This TERO represents P2MP LSP topology but it is provided by external mechanism (e.g. NW management system). In this way, our protocol doesn't define multicast tree calculation mechanism in protocol itself as multicast protocol do. And we evaluate that this extension is consistent with TE extension to RSVP (RSVP-TE) and in the scope of RSVP-TE extension. So we think this is acceptable and in the scope of the MPLS wg. And we want to discuss this extension at MPLS wg because we think this wg is most appropriate place when considering situation discussed over the thread on IANA Considerations for RSVP. But I totally agreed with you in the point that introducing Join/Leave mechanism might enhance the function exceeding the scope of MPLS wg. We want to know what modification is required to our draft in order to fit in the scope. We will modify our specification if necessary because we want this technology. And we want to know how should we process this work in this wg. It is very helpful for us if you or anybody in this list give us some suggestion to these issues. Thanks, Seisho >I very much agree. This draft is not simply an extension to RSVP for >multicast tunnels. It actually defines a new multicast protocol. > >As such it is: > > a) a mis-use of RSVP (note the thread on IANA Considerations for > RSVP) > > b) not completely in the scope of the MPLS wg. > >While the MPLS wg can look for ways to support multicast, it is not >now (or ever likely to be) in the charter of the workgroup to define a >new multicast protocol. > >RSVP should simply be used to build the tree. All of the join/leave >activity belongs in a multicast protocol. > >...George > >================================================================== >George Swallow Cisco Systems (978) 497-8143 > 250 Apollo Drive > Chelmsford, Ma 01824 From owner-mpls@UU.NET Wed Jan 29 05:59:29 2003 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15694 for ; Wed, 29 Jan 2003 05:59:29 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnzsm07319 for ; Wed, 29 Jan 2003 11:02:58 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnzsm07138; Wed, 29 Jan 2003 11:02:53 GMT Received: by mail-control.ash.ops.us.uu.net id QQnzsm16320 for mpls-outgoing; Wed, 29 Jan 2003 11:02:42 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnzsm14798 for ; Wed, 29 Jan 2003 11:02:30 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnzsm00687 for ; Wed, 29 Jan 2003 11:01:45 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnzsm29147 for ; Wed, 29 Jan 2003 11:01:44 GMT Received: from tama5.ecl.ntt.co.jp by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: tama5.ecl.ntt.co.jp [129.60.39.102]) id QQnzsm29131 for ; Wed, 29 Jan 2003 11:01:43 GMT Received: from vcs3.rdh.ecl.ntt.co.jp (vcs3.rdh.ecl.ntt.co.jp [129.60.39.110]) by tama5.ecl.ntt.co.jp (8.9.3+3.2W/3.7W/10/21/02) with ESMTP id UAA05154; Wed, 29 Jan 2003 20:01:38 +0900 (JST) (envelope-from yasukawa.seisho@lab.ntt.co.jp) Received: from nttmail3.ecl.ntt.co.jp ([127.0.0.1]) by vcs3.rdh.ecl.ntt.co.jp (8.12.6/8.12.6) with ESMTP id h0TB1cOO001945; Wed, 29 Jan 2003 20:01:38 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (eclscan3.m.ecl.ntt.co.jp [129.60.5.69]) by nttmail3.ecl.ntt.co.jp (8.12.6/8.12.6) with ESMTP id h0TB1aFb016458; Wed, 29 Jan 2003 20:01:36 +0900 (JST) Received: from imc.m.ecl.ntt.co.jp (localhost [127.0.0.1]) by eclscan3.m.ecl.ntt.co.jp (8.9.3/3.7W) with ESMTP id UAA10009; Wed, 29 Jan 2003 20:01:36 +0900 (JST) Received: from barrister.lab.ntt.co.jp by imc.m.ecl.ntt.co.jp (8.9.3/3.7W) with ESMTP id UAA23845; Wed, 29 Jan 2003 20:01:35 +0900 (JST) Message-Id: <5.0.2.5.2.20030129141715.042e8ec8@imc.m.ecl.ntt.co.jp> X-Sender: sy003@imc.m.ecl.ntt.co.jp X-Mailer: QUALCOMM Windows Eudora Version 5.0.2-J Date: Wed, 29 Jan 2003 20:04:55 +0900 To: "LE ROUX Jean-Louis FTRD/DAC/LAN" From: Seisho Yasukawa Subject: RE: draft-yasukawa-mpls-rsvp-p2mp-00.txt Cc: , "LARREUR-HEMON Elodie FTRD/DAC/LAN" , , , , In-Reply-To: <1FB136FD10CE33409C882630E299F5BE1EDBEB@lanmhs30.rd.francet elecom.fr> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Hello JL, >I agree with you. It is important to well separate mutlicast service >from P2MP LSP setup / >modification, as P2MP tree can support non-IP Mcast traffic. > >Thus addtional procedures an message exchanges are required on top of >this architecture to support multicast (S, G) Join/ Leave and to allow >the sender to hold sufficient information in order to optimise multicast >FEC on sender nodes. I agree with you. I also think we need additional procedures on top of this architecture. >There are two options : > -Use an offline tool for FEC determination and tree computation. >The leaf node learns LSP parameters from this tool. > -Distributed scenario: Leaf node registers (S, G) to the sender >that determines which P2MP tunnel must be used, and intiates grafting. >This requires a new (possibly RSVP) message to support such (S, G) >registation. (Note that IGMPv2 raises an additional sender localisation >issue). Thank you for useful inputs. I think we can attain first option by current design. And I assume second option has a merit in scalability. So how about using (FEC) information instead of (S,G) information for this registration ? I think we can attain non-IP traffic distribution if we use this architecture. And we want to discuss second option for future extension because we need some modification to current design. Regards, Seisho >-----Message d'origine----- >De : Seisho Yasukawa [mailto:yasukawa.seisho@lab.ntt.co.jp] >Envoye : mardi 28 janvier 2003 13:16 >A : LE ROUX Jean-Louis FTRD/DAC/LAN >Cc : mpls@UU.NET; LARREUR-HEMON Elodie FTRD/DAC/LAN; >yasukawa.seisho@lab.ntt.co.jp; akullber@netplane.com; >DCheng@PolarisNetworks.com; Dimitri.Papadimitriou@alcatel.be; >mjork@avici.com >Objet : RE: draft-yasukawa-mpls-rsvp-p2mp-00.txt > > >Hello JL and Elodie, > >Thank you for useful comments and suggestions. >Please find my answers and comments in-line. > > >Hi Seisho and all > > > >We read your draft with much interest, and consider this is a good > >approach for multicast MPLS-TE tunnels. > > > >We have several comments regarding leaf initiated Joining/pruning > >procedures, and the interaction with access multicast protocols like > >IGMP : > > > >Why does the Join/ leave messages contain the attributes of the P2MP > >tunnel (Session, and Sender objects) ? > >The reason why these messages contain both objects is that this >protocol uses both objects to identify P2MP LSP tunnel uniquely. >And this Join/Leave architecture is consistent with other message >architecture, like Path/Path(Graft)/Path(Prune) message. >This protocol prepare same interface to LSP handler (who setup and >modify LSP) in regard to LSP identification. >In another word, this protocol assumes that all LSP handler knows >same tunnel information. >And we think this is also consistent to conventional P2P RSVP-TE >idea and architecture. > > > >This requires a mechanism for the Join leaf node to dynamicaly learn > >these attributes. > >Yes, I agree your point. > > >To our mind, it could be more relevant to include (S,G) or (*, G),or > >({S}, {G}) in Join /Leave messages, rather than tunnel parameters. Then > >the sender would have knowledge of (S, G) localization, and could > >optimise P2MP utilisation (FEC) based on this information. > >I like this kind of approach. >As you suggested, I also think your proposal could be more relevant >if a P2MP LSP convey single IP Mcast group traffic. >One of my concern is what should we do when a P2MP LSP conveys >multiple IP Mcast group traffic. >Maybe we can resolve this issue by same mechanism. >But, I think we need some sophisticated algorithm in sender/leaf node. >And another concern is what should we de when a P2MP LSP conveys >non-IP Mcast traffic. >Considering these situation, we choose both objects for LSP identifier. > > >In this scenario, the sender would have to maintain a table indicating > >the registered (S, G) attached to each leaf node. > >When a potential leaf node receives an IGMPv3 report message for a new > >(S, G), it checks if it already receives this (S, G), if no it sends a > >Join message to the sender node, including the (S, G). Then the sender > >can either graft an existing P2MP tunnel, or create a new tunnel to > >reach this leaf node, depending on local optimization criteria. > >I like this approach. >So, if you have any solution to above problems, please teach us your >solution. > >And we think this technology can also applicable to >P2MP backbone technology for Wireless LAN (hot spot) and CATV network >in addition to content delivery network which is mentioned in draft. >Using this technology, we can provide broadcast service >in these network economically. > >We want to discuss service applicability issues with you >if you have some interest in this issue. > > >Thanks, > >Seisho > > > >-----Message d'origine----- > >De : Seisho Yasukawa [mailto:yasukawa.seisho@lab.ntt.co.jp] > >Envoye : jeudi 23 janvier 2003 09:45 > >A : 'mpls@UU.NET' > >Cc : yasukawa.seisho@lab.ntt.co.jp > >Objet : draft-yasukawa-mpls-rsvp-p2mp-00.txt > > > > > >Hello everyone, > > > >Please note that the following draft has been newly posted to MPLS WG. > > > >Extended RSVP-TE for Point-to-Multipoint LSP Tunnels > > > > > >A URL for this Internet-Draft is: > >http://www.ietf.org/internet-drafts/draft-yasukawa-mpls-rsvp-p2mp-00.tx >t > > > >This draft specifies the extension to RSVP-TE signaling protocol > >in support of MPLS P2MP LSP creation/deletion and Leaf initiated > >Join/Leave signaling. > > > >We think P2MP MPLS technology will become increasingly important > >with the dissemination of new, real-time application, such as content > >delivery services and video conference, which require P2MP real-time > >transmission capability with much more bandwidth and stricter QoS > >control mechanism than conventional IP application. > > > >We NTT as a service provider really needs this kind of P2MP MPLS > >technology because this technology opens the possibility to offer > >our customer a new broadband service. > > > >We think discussion of P2MP technology agrees with the charter of this > >wg. > >And, we found that applications of "multicast explicit routing"are a > >target > >topic for "RSVP-TE "(RFC3209, Section 4.3.1) and "IP Multicast in a >MPLS > >Environment"(RFC3353, Section.7) > > > >Therefore, we want to discuss this P2MP MPLS technology in this wg. > > > >Please give us any comments from technology, application and operation > >sides. > > > >We need a lot of discussion and advice for protocol architecture to > >improve > >this architecture. > > > > > >Thanks > > > >Seisho > > > >------------------------------------------------------------ > >Please refere followings (contents of this draft). > > > >This draft include the contents of "draft-yasukawa-mpls-rsvp-p2mp-01". > >In this new draft, protocol architecture is modified and the protocol > >name > >was changed from "multicast" to "P2MP" to clarify the technology > >difference. > > > >Section 0 describes why this draft suit to this wg. > >Please see sec.0.4 to know the reason why we introduce P2MP tunnel > >without IP multicast. > > > >Section 4 describes the architecture of this protocol. > >The new concepts; P2MP LSP tunnel and TERO/TRRO are newly introduced. > >The TERO is main architecture to realize P2MP TE LSP. > > > >Section 5 - 7 describes the detailed signaling mechanisms. > > > >Section 11 shows the difference between RSVP multicasting and P2MP > >TE tunnels. > > > >We describe the difference between multicast LSP realized by > >RSVP-TE&IP multicasting and P2MP TE LSP realized by TERO. > >--------------------------------------------------------------- From owner-mpls@UU.NET Wed Jan 29 07:07:12 2003 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16912 for ; Wed, 29 Jan 2003 07:07:12 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnzsq26833 for ; Wed, 29 Jan 2003 12:10:36 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnzsq26607; Wed, 29 Jan 2003 12:10:30 GMT Received: by mail-control.ash.ops.us.uu.net id QQnzsq15090 for mpls-outgoing; Wed, 29 Jan 2003 12:10:10 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnzsq15065 for ; Wed, 29 Jan 2003 12:10:02 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnzsq06455 for ; Wed, 29 Jan 2003 12:09:05 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnzsq24299 for ; Wed, 29 Jan 2003 12:09:04 GMT Received: from rtp-msg-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-msg-core-1.cisco.com [161.44.11.97]) id QQnzsq24284 for ; Wed, 29 Jan 2003 12:09:04 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h0TC9rth023901 for ; Wed, 29 Jan 2003 07:09:53 -0500 (EST) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id HAA04920 for ; Wed, 29 Jan 2003 07:09:02 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h0TC92P28765 for mpls@uu.net; Wed, 29 Jan 2003 07:09:02 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnzsq14808 for ; Wed, 29 Jan 2003 12:07:56 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnzsq10442 for ; Wed, 29 Jan 2003 12:06:46 GMT From: francis.arts@alcatel.be Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnzsq17908 for ; Wed, 29 Jan 2003 12:06:45 GMT Received: from mail.alcatel.be by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: alc239.alcatel.be [195.207.101.239]) id QQnzsq17877 for ; Wed, 29 Jan 2003 12:06:44 GMT Received: from Bemail06.net.alcatel.be (localhost [127.0.0.1]) by mail.alcatel.be (8.10.1/8.11.4) with ESMTP id h0TC6h700490 for ; Wed, 29 Jan 2003 13:06:43 +0100 (MET) To: mpls@UU.NET Subject: Vpns vs explicit null label MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: Date: Wed, 29 Jan 2003 13:06:41 +0100 X-MIMETrack: Serialize by Router on BEMAIL06/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 01/29/2003 13:06:42, Serialize complete at 01/29/2003 13:06:42 Content-Type: multipart/alternative; boundary="=_alternative 00428789C1256CBD_=" Sender: owner-mpls@UU.NET Precedence: bulk This is a multipart message in MIME format. --=_alternative 00428789C1256CBD_= Content-Type: text/plain; charset="us-ascii" Hello, I have a question on the explicit null label. Issue ===== Consider a 2-step approach: 1) Step-1: Setup of an LSP between 2 PE routers (say PE-1 and PE-2). ==> During LSP setup PE-2 indicates the use of the explicit null label. 2) Step-2: Send VPN packets through the LSP from PE-1 to PE-2. In this configuration the VPN packets arrive at PE-2 with the VPN label beneath the explicit null label. PE-2 drops the VPN packets since RFC 3032 indicates that the explicit null label can only occur at the bottom of a label stack. Question ======== Then the question is: * How can during the LSP setup between PE-1 and PE-2 be made known to PE-2 that it should not use the explicit null label? OR Should the statement that be relaxed? Thanks for any help you can provide. Francis. --=_alternative 00428789C1256CBD_= Content-Type: text/html; charset="us-ascii"
Hello,

I have a question on the explicit null label.

Issue
=====
Consider a 2-step approach:
1) Step-1: Setup of an LSP between 2 PE routers (say PE-1 and PE-2).
==> During LSP setup PE-2 indicates the use of the explicit null label.
2) Step-2: Send VPN packets through the LSP from PE-1 to PE-2.

In this configuration the VPN packets arrive at PE-2 with the VPN label beneath the explicit null label. PE-2 drops the VPN packets since RFC 3032 indicates that the explicit null label can only occur at the bottom of a label stack.

Question
========
Then the question is:
* How can during the LSP setup between PE-1 and PE-2 be made known to PE-2 that it should not use the explicit null label?
OR
Should the statement that <the explicit null label only occurs at the bottom of the stack> be relaxed?

Thanks for any help you can provide.

        Francis. --=_alternative 00428789C1256CBD_=-- From owner-mpls@UU.NET Wed Jan 29 08:29:15 2003 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18881 for ; Wed, 29 Jan 2003 08:29:14 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnzsw25794 for ; Wed, 29 Jan 2003 13:32:42 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnzsw25439; Wed, 29 Jan 2003 13:32:34 GMT Received: by mail-control.ash.ops.us.uu.net id QQnzsw10632 for mpls-outgoing; Wed, 29 Jan 2003 13:32:06 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnzsw10569 for ; Wed, 29 Jan 2003 13:31:59 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnzsv22105 for ; Wed, 29 Jan 2003 13:27:38 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnzsv05653 for ; Wed, 29 Jan 2003 13:27:38 GMT Received: from tama5.ecl.ntt.co.jp by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: tama5.ecl.ntt.co.jp [129.60.39.102]) id QQnzsv05633 for ; Wed, 29 Jan 2003 13:27:37 GMT Received: from vcs3.rdh.ecl.ntt.co.jp (vcs3.rdh.ecl.ntt.co.jp [129.60.39.110]) by tama5.ecl.ntt.co.jp (8.9.3+3.2W/3.7W/10/21/02) with ESMTP id WAA00291; Wed, 29 Jan 2003 22:27:20 +0900 (JST) (envelope-from yasukawa.seisho@lab.ntt.co.jp) Received: from nttmail3.ecl.ntt.co.jp ([127.0.0.1]) by vcs3.rdh.ecl.ntt.co.jp (8.12.6/8.12.6) with ESMTP id h0TDRKOO017842; Wed, 29 Jan 2003 22:27:20 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (eclscan3.m.ecl.ntt.co.jp [129.60.5.69]) by nttmail3.ecl.ntt.co.jp (8.12.6/8.12.6) with ESMTP id h0TDRJFb009607; Wed, 29 Jan 2003 22:27:19 +0900 (JST) Received: from imc.m.ecl.ntt.co.jp (localhost [127.0.0.1]) by eclscan3.m.ecl.ntt.co.jp (8.9.3/3.7W) with ESMTP id WAA16917; Wed, 29 Jan 2003 22:27:18 +0900 (JST) Received: from barrister.lab.ntt.co.jp by imc.m.ecl.ntt.co.jp (8.9.3/3.7W) with ESMTP id WAA01949; Wed, 29 Jan 2003 22:27:18 +0900 (JST) Message-Id: <5.0.2.5.2.20030129132551.04506ec8@imc.m.ecl.ntt.co.jp> X-Sender: sy003@imc.m.ecl.ntt.co.jp X-Mailer: QUALCOMM Windows Eudora Version 5.0.2-J Date: Wed, 29 Jan 2003 22:30:37 +0900 To: raszuk@cisco.com From: Seisho Yasukawa Subject: Re: draft-yasukawa-mpls-rsvp-p2mp-00.txt Cc: LE ROUX Jean-Louis FTRD/DAC/LAN , mpls@UU.NET, elodie.larreur@rd.francetelecom.com, akullber@netplane.com, DCheng@PolarisNetworks.com, Dimitri.Papadimitriou@alcatel.be, mjork@avici.com, yasukawa.seisho@lab.ntt.co.jp In-Reply-To: <3E36827A.1424B474@cisco.com> References: <5.0.2.5.2.20030128200020.0437fd18@imc.m.ecl.ntt.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Hello Robert, Thank you for useful comment. > > I like this kind of approach. > > As you suggested, I also think your proposal could be more relevant > > if a P2MP LSP convey single IP Mcast group traffic. > > > > One of my concern is what should we do when a P2MP LSP conveys > > multiple IP Mcast group traffic. > >I think both cases for p2mp LSP carrying single and multiple multicast >groups should be supported. I agree with you. Our current design support both cases. >Further it would be up to the IGMP report >recepient to make the decision if new LSP needs to be created or if any >of his present LSPs can be extended (for example by changing constrains >in the shared explicit way) to carry new multicast group(s). > > > Considering these situation, we choose both objects for LSP identifier. > >If you are planning to use any P2MP LSP for multiple groups pipe how do >you calculate tunnel id ? In other words if all multicast packets will >arrive at the egrees unlabed (PHP) or even labeled (no PHP) are you >assuming another IP lookup/RPF check to send it to receivers ? We assume another IP lookup at egress LSR.to send multicast packets to recivers. And we don't assume any RPF check because this draft can be applicable to non-IPmulticast network. >In other words maybe at some point just lookup on the LFIB would be in >order and label stack would be the tool ? Just trying to make sure that >forwarding wise egress performance will be doable. Could you clarify above question in more detail ? We also assume this issue is very important when we implement real P2MP LSR. >Another interesting >point is that there could be cases (transient or permanent) that some >received groups should be filtered on the egress of the P2MP LSP rather >then always forwarding it to the potential receiver. Dropping them based >on the label is much more eficient then processing by CPU and dropping >later ;). I agree that in some case, it is more efficient to filter some group traffic on the egress. Using this technique, we can avoid leaf-initiated Join/Leave mechanism and make IGMP interwork more simple. But I cannot understand detail architecture of your suggestion, Could you clarify the meaning of last sentence. " Dropping them based on the label is ........" >Also considering that LSPs are unidirectional (well at least today in >some implementations :) it would be nice to address explicitely how and >if RPF on egrees should be performed. Yes, we need some mechanism that address explicitely how and if RPF on egress should be performed when we consider system implementation. Thanks, Seisho > > Seisho Yasukawa wrote: > > > > Hello JL and Elodie, > > > > Thank you for useful comments and suggestions. > > Please find my answers and comments in-line. > > > > >Hi Seisho and all > > > > > >We read your draft with much interest, and consider this is a good > > >approach for multicast MPLS-TE tunnels. > > > > > >We have several comments regarding leaf initiated Joining/pruning > > >procedures, and the interaction with access multicast protocols like > > >IGMP : > > > > > >Why does the Join/ leave messages contain the attributes of the P2MP > > >tunnel (Session, and Sender objects) ? > > > > The reason why these messages contain both objects is that this > > protocol uses both objects to identify P2MP LSP tunnel uniquely. > > And this Join/Leave architecture is consistent with other message > > architecture, like Path/Path(Graft)/Path(Prune) message. > > This protocol prepare same interface to LSP handler (who setup and > > modify LSP) in regard to LSP identification. > > In another word, this protocol assumes that all LSP handler knows > > same tunnel information. > > And we think this is also consistent to conventional P2P RSVP-TE > > idea and architecture. > > > > >This requires a mechanism for the Join leaf node to dynamicaly learn > > >these attributes. > > > > Yes, I agree your point. > > > > >To our mind, it could be more relevant to include (S,G) or (*, G),or > > >({S}, {G}) in Join /Leave messages, rather than tunnel parameters. Then > > >the sender would have knowledge of (S, G) localization, and could > > >optimise P2MP utilisation (FEC) based on this information. > > > > I like this kind of approach. > > As you suggested, I also think your proposal could be more relevant > > if a P2MP LSP convey single IP Mcast group traffic. > > One of my concern is what should we do when a P2MP LSP conveys > > multiple IP Mcast group traffic. > > Maybe we can resolve this issue by same mechanism. > > But, I think we need some sophisticated algorithm in sender/leaf node. > > And another concern is what should we de when a P2MP LSP conveys > > non-IP Mcast traffic. > > Considering these situation, we choose both objects for LSP identifier. > > > > >In this scenario, the sender would have to maintain a table indicating > > >the registered (S, G) attached to each leaf node. > > >When a potential leaf node receives an IGMPv3 report message for a new > > >(S, G), it checks if it already receives this (S, G), if no it sends a > > >Join message to the sender node, including the (S, G). Then the sender > > >can either graft an existing P2MP tunnel, or create a new tunnel to > > >reach this leaf node, depending on local optimization criteria. > > > > I like this approach. > > So, if you have any solution to above problems, please teach us your > > solution. > > > > And we think this technology can also applicable to > > P2MP backbone technology for Wireless LAN (hot spot) and CATV network > > in addition to content delivery network which is mentioned in draft. > > Using this technology, we can provide broadcast service > > in these network economically. > > > > We want to discuss service applicability issues with you > > if you have some interest in this issue. > > > > Thanks, > > > > Seisho > > > > >-----Message d'origine----- > > >De : Seisho Yasukawa [mailto:yasukawa.seisho@lab.ntt.co.jp] > > >Envoye : jeudi 23 janvier 2003 09:45 > > >A : 'mpls@UU.NET' > > >Cc : yasukawa.seisho@lab.ntt.co.jp > > >Objet : draft-yasukawa-mpls-rsvp-p2mp-00.txt > > > > > > > > >Hello everyone, > > > > > >Please note that the following draft has been newly posted to MPLS WG. > > > > > >Extended RSVP-TE for Point-to-Multipoint LSP Tunnels > > > > > > > > >A URL for this Internet-Draft is: > > >http://www.ietf.org/internet-drafts/draft-yasukawa-mpls-rsvp-p2mp-00.txt > > > > > >This draft specifies the extension to RSVP-TE signaling protocol > > >in support of MPLS P2MP LSP creation/deletion and Leaf initiated > > >Join/Leave signaling. > > > > > >We think P2MP MPLS technology will become increasingly important > > >with the dissemination of new, real-time application, such as content > > >delivery services and video conference, which require P2MP real-time > > >transmission capability with much more bandwidth and stricter QoS > > >control mechanism than conventional IP application. > > > > > >We NTT as a service provider really needs this kind of P2MP MPLS > > >technology because this technology opens the possibility to offer > > >our customer a new broadband service. > > > > > >We think discussion of P2MP technology agrees with the charter of this > > >wg. > > >And, we found that applications of "multicast explicit routing"are a > > >target > > >topic for "RSVP-TE "(RFC3209, Section 4.3.1) and "IP Multicast in a MPLS > > >Environment"(RFC3353, Section.7) > > > > > >Therefore, we want to discuss this P2MP MPLS technology in this wg. > > > > > >Please give us any comments from technology, application and operation > > >sides. > > > > > >We need a lot of discussion and advice for protocol architecture to > > >improve > > >this architecture. > > > > > > > > >Thanks > > > > > >Seisho > > > > > >------------------------------------------------------------ > > >Please refere followings (contents of this draft). > > > > > >This draft include the contents of "draft-yasukawa-mpls-rsvp-p2mp-01". > > >In this new draft, protocol architecture is modified and the protocol > > >name > > >was changed from "multicast" to "P2MP" to clarify the technology > > >difference. > > > > > >Section 0 describes why this draft suit to this wg. > > >Please see sec.0.4 to know the reason why we introduce P2MP tunnel > > >without IP multicast. > > > > > >Section 4 describes the architecture of this protocol. > > >The new concepts; P2MP LSP tunnel and TERO/TRRO are newly introduced. > > >The TERO is main architecture to realize P2MP TE LSP. > > > > > >Section 5 - 7 describes the detailed signaling mechanisms. > > > > > >Section 11 shows the difference between RSVP multicasting and P2MP > > >TE tunnels. > > > > > >We describe the difference between multicast LSP realized by > > >RSVP-TE&IP multicasting and P2MP TE LSP realized by TERO. > > >--------------------------------------------------------------- From owner-mpls@UU.NET Wed Jan 29 10:09:04 2003 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20952 for ; Wed, 29 Jan 2003 10:09:03 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnztc13052 for ; Wed, 29 Jan 2003 15:12:33 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnztc12846; Wed, 29 Jan 2003 15:12:28 GMT Received: by mail-control.ash.ops.us.uu.net id QQnztc24926 for mpls-outgoing; Wed, 29 Jan 2003 15:12:10 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnztc24905 for ; Wed, 29 Jan 2003 15:12:01 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnztc23130 for ; Wed, 29 Jan 2003 15:09:51 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnztc24562 for ; Wed, 29 Jan 2003 15:09:50 GMT Received: from sj-msg-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQnztc24544 for ; Wed, 29 Jan 2003 15:09:50 GMT Received: from cisco.com (erosen-u10.cisco.com [161.44.134.50]) by sj-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h0TF9aSQ026824; Wed, 29 Jan 2003 07:09:36 -0800 (PST) Message-Id: <200301291509.h0TF9aSQ026824@sj-msg-core-1.cisco.com> To: francis.arts@alcatel.be cc: mpls@UU.NET Subject: Re: Vpns vs explicit null label In-reply-to: Your message of Wed, 29 Jan 2003 13:06:41 +0100. Reply-To: erosen@cisco.com User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.2 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Date: Wed, 29 Jan 2003 10:09:35 -0500 From: Eric Rosen Sender: owner-mpls@UU.NET Precedence: bulk Francis> Should the statement that the bottom of the stack> be relaxed? This statement causes a lot of problems, and no one can seem to remember why it is there. Further, there are a number of cases in which it is awkward to prevent explicit null from appearing in mid-stack. Not only that, but the specs don't really say what you are supposed to do if you do encounter explicit null above another label, or if you are instructed (via LDP) to put explicit null on a packet which already has a label stack. So I would favor removing the requirement that explicit null only appear at the bottom of the stack. From owner-mpls@UU.NET Wed Jan 29 10:10:50 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20994 for ; Wed, 29 Jan 2003 10:10:49 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnztc02723 for ; Wed, 29 Jan 2003 15:14:21 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnztc02549; Wed, 29 Jan 2003 15:14:17 GMT Received: by mail-control.ash.ops.us.uu.net id QQnztc25492 for mpls-outgoing; Wed, 29 Jan 2003 15:13:51 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnztc25462 for ; Wed, 29 Jan 2003 15:13:39 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnztc13817 for ; Wed, 29 Jan 2003 15:11:13 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnztc26127 for ; Wed, 29 Jan 2003 15:11:12 GMT Received: from hotmail.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: oe13.law9.hotmail.com [64.4.8.117]) id QQnztc26117 for ; Wed, 29 Jan 2003 15:11:12 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 29 Jan 2003 07:11:11 -0800 X-Originating-IP: [203.124.140.20] From: "john smith" To: Subject: CSPF query Date: Wed, 29 Jan 2003 20:43:04 +0530 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Message-ID: X-OriginalArrivalTime: 29 Jan 2003 15:11:11.0349 (UTC) FILETIME=[A8661250:01C2C7A8] Sender: owner-mpls@UU.NET Precedence: bulk All, I have certain queries regarding CSPF implementation with OSPF: 1. How is the TED information synchronized? Is it carried out as a part of Database description packets for opaque LSAs?Will this imply that adjacencies keep moving into an "exchange state" ? 2. If not, OSPF by default causes one of the routers to send LS Request packets and the other sends the information as LS Updates. How will this come to a "Full" state if the TED is continuously changing? 2. If not, is there any other mechanism to carry out the same? Pointers to any drafts etc would help. -JS From owner-mpls@UU.NET Wed Jan 29 10:49:06 2003 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22303 for ; Wed, 29 Jan 2003 10:49:05 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnztf06749 for ; Wed, 29 Jan 2003 15:52:32 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnztf06189; Wed, 29 Jan 2003 15:52:16 GMT Received: by mail-control.ash.ops.us.uu.net id QQnztf28418 for mpls-outgoing; Wed, 29 Jan 2003 15:51:46 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnztf28411 for ; Wed, 29 Jan 2003 15:51:35 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnztf23635 for ; Wed, 29 Jan 2003 15:51:21 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnztf19742 for ; Wed, 29 Jan 2003 15:51:20 GMT Received: from sj-msg-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQnztf19724 for ; Wed, 29 Jan 2003 15:51:19 GMT Received: from cisco.com (erosen-u10.cisco.com [161.44.134.50]) by sj-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h0TFp7SQ021312; Wed, 29 Jan 2003 07:51:07 -0800 (PST) Message-Id: <200301291551.h0TFp7SQ021312@sj-msg-core-1.cisco.com> To: ewgray@graiymage.com cc: francis.arts@alcatel.be, mpls@UU.NET Subject: Re: Vpns vs explicit null label In-reply-to: Your message of Wed, 29 Jan 2003 10:42:48 -0500. <3E37F678.4A56367B@GraIyMage.com> Reply-To: erosen@cisco.com User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.2 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Date: Wed, 29 Jan 2003 10:51:07 -0500 From: Eric Rosen Sender: owner-mpls@UU.NET Precedence: bulk Probably an explicit null which is not at the bottom of the stack should not be interpreted as indicating the protocol type of the payload. > others may have hard-coded the condition in which an explicit NULL label > is not bottom of stack as an error Yes, but that would be an example of why "be liberal in what you accept" is a good principle. From owner-mpls@UU.NET Wed Jan 29 10:49:22 2003 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22317 for ; Wed, 29 Jan 2003 10:49:21 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnztf07318 for ; Wed, 29 Jan 2003 15:52:48 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnztf06299; Wed, 29 Jan 2003 15:52:19 GMT Received: by mail-control.ash.ops.us.uu.net id QQnztf28423 for mpls-outgoing; Wed, 29 Jan 2003 15:51:48 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnztf28413 for ; Wed, 29 Jan 2003 15:51:45 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnztf05601 for ; Wed, 29 Jan 2003 15:50:08 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnztf07485 for ; Wed, 29 Jan 2003 15:50:08 GMT Received: from rtp-msg-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-msg-core-1.cisco.com [161.44.11.97]) id QQnztf07386 for ; Wed, 29 Jan 2003 15:50:04 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h0TForxk019517 for ; Wed, 29 Jan 2003 10:50:53 -0500 (EST) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA17077 for ; Wed, 29 Jan 2003 10:50:02 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h0TFo2609302 for mpls@uu.net; Wed, 29 Jan 2003 10:50:02 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnztf28345 for ; Wed, 29 Jan 2003 15:49:26 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnzte29985 for ; Wed, 29 Jan 2003 15:44:44 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnzte02943 for ; Wed, 29 Jan 2003 15:44:44 GMT Received: from host19.ipowerweb.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: host19.ipowerweb.com [12.129.206.119]) id QQnzte02939 for ; Wed, 29 Jan 2003 15:44:43 GMT Received: from h00a0ccd1a9ec.ne.client2.attbi.com ([24.128.219.249] helo=GraIyMage.com) by host19.ipowerweb.com with asmtp (Exim 3.36 #1) id 18duMX-0006oM-00; Wed, 29 Jan 2003 07:42:53 -0800 Message-ID: <3E37F678.4A56367B@GraIyMage.com> Date: Wed, 29 Jan 2003 10:42:48 -0500 From: Eric Gray Reply-To: ewgray@GraIyMage.com X-Mailer: Mozilla 4.7 [en]C-CCK-MCD NSCPCD47 (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: erosen@cisco.com CC: francis.arts@alcatel.be, mpls@UU.NET Subject: Re: Vpns vs explicit null label References: <200301291509.h0TF9aSQ026824@sj-msg-core-1.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - host19.ipowerweb.com X-AntiAbuse: Original Domain - uu.net X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [0 0] X-AntiAbuse: Sender Address Domain - graiymage.com Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Eric, There remains the question of whether a specific "explicit NULL" label might occur or in this case or either IPv4 or IPv6 explicit NULL is acceptable. Realistically, it is going to be an IPv4 explicit NULL label now and for much of the forseeable future, but this is a hole we might also want to address. One reason for bringing this up is that it is conceivable that some implementations might not check the bottom of stack bit when dealing with either explicit NULL label type while others may have hard-coded the condition in which an explicit NULL label is not bottom of stack as an error. If we are going to potentially require people to "fix" these implementations, we should make sure we are not setting them up for more "fixes" down the road. Or at least as sure as possible... -- Eric Gray Eric Rosen wrote: > Francis> Should the statement that Francis> the bottom of the stack> be relaxed? > > This statement causes a lot of problems, and no one can seem to remember why > it is there. Further, there are a number of cases in which it is awkward to > prevent explicit null from appearing in mid-stack. Not only that, but the > specs don't really say what you are supposed to do if you do encounter > explicit null above another label, or if you are instructed (via LDP) to put > explicit null on a packet which already has a label stack. > > So I would favor removing the requirement that explicit null only appear at > the bottom of the stack. From owner-mpls@UU.NET Wed Jan 29 10:56:47 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22509 for ; Wed, 29 Jan 2003 10:56:44 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnztg17597 for ; Wed, 29 Jan 2003 16:00:12 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnztg17399; Wed, 29 Jan 2003 16:00:07 GMT Received: by mail-control.ash.ops.us.uu.net id QQnztf29032 for mpls-outgoing; Wed, 29 Jan 2003 15:59:54 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnztf29021 for ; Wed, 29 Jan 2003 15:59:50 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnztf12797 for ; Wed, 29 Jan 2003 15:57:15 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnztf14058 for ; Wed, 29 Jan 2003 15:57:15 GMT Received: from mailhost.avici.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [12.38.212.174]) id QQnztf14051 for ; Wed, 29 Jan 2003 15:57:14 GMT Received: from aatlas-lt.avici.com (b2-pc95.avici.com [10.2.100.125]) by mailhost.avici.com (8.11.0/8.11.0) with ESMTP id h0TFpq317396; Wed, 29 Jan 2003 10:51:52 -0500 (EST) Message-Id: <5.1.0.14.2.20030129105010.01f6e100@mailhost.avici.com> X-Sender: aatlas@mailhost.avici.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 29 Jan 2003 10:51:22 -0500 To: erosen@cisco.com From: Alia Atlas Subject: Re: Vpns vs explicit null label Cc: francis.arts@alcatel.be, mpls@UU.NET In-Reply-To: <200301291509.h0TF9aSQ026824@sj-msg-core-1.cisco.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk I agree that removing the restriction that an explicit null only occur at the bottom of the stack would be a good idea. It does raise some questions, because there is an IPv4 explicit null and an IPv6 explicit null. What we really want is just an explicit null, which means "pop off this label and then forward based on whatever's underneath". Alia At 10:09 AM 1/29/2003 -0500, Eric Rosen wrote: >Francis> Should the statement that Francis> the bottom of the stack> be relaxed? > >This statement causes a lot of problems, and no one can seem to remember why >it is there. Further, there are a number of cases in which it is awkward to >prevent explicit null from appearing in mid-stack. Not only that, but the >specs don't really say what you are supposed to do if you do encounter >explicit null above another label, or if you are instructed (via LDP) to put >explicit null on a packet which already has a label stack. > >So I would favor removing the requirement that explicit null only appear at >the bottom of the stack. From owner-mpls@UU.NET Wed Jan 29 12:18:50 2003 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23872 for ; Wed, 29 Jan 2003 12:18:49 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnztl15741 for ; Wed, 29 Jan 2003 17:22:16 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnztl15316; Wed, 29 Jan 2003 17:22:03 GMT Received: by mail-control.ash.ops.us.uu.net id QQnztl12648 for mpls-outgoing; Wed, 29 Jan 2003 17:21:44 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnztl12643 for ; Wed, 29 Jan 2003 17:21:37 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnztl12240 for ; Wed, 29 Jan 2003 17:19:51 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnztl13146 for ; Wed, 29 Jan 2003 17:19:50 GMT Received: from rtp-msg-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-msg-core-1.cisco.com [161.44.11.97]) id QQnztl13122 for ; Wed, 29 Jan 2003 17:19:48 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h0THKamU003624 for ; Wed, 29 Jan 2003 12:20:36 -0500 (EST) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id MAA24433 for ; Wed, 29 Jan 2003 12:19:46 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h0THJkC14703 for mpls@uu.net; Wed, 29 Jan 2003 12:19:46 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnztk11850 for ; Wed, 29 Jan 2003 17:13:51 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnztk04511 for ; Wed, 29 Jan 2003 17:13:42 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnztk03858 for ; Wed, 29 Jan 2003 17:13:42 GMT Received: from localhost.localdomain by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail.ipinfusion.com [65.223.109.2]) id QQnztk03849 for ; Wed, 29 Jan 2003 17:13:41 GMT Received: from localhost.localdomain (vprmatrix [127.0.0.1]) by localhost.localdomain (8.12.5/8.12.5) with ESMTP id h0THCa4D001244; Thu, 30 Jan 2003 02:12:36 +0900 Date: Wed, 29 Jan 2003 09:12:36 -0800 Message-ID: <87fzrb3mnv.wl@ipinfusion.com> From: Kunihiro Ishiguro To: "LE ROUX Jean-Louis FTRD/DAC/LAN" Cc: "Seisho Yasukawa" , , "LARREUR-HEMON Elodie FTRD/DAC/LAN" , , , , Subject: Re: draft-yasukawa-mpls-rsvp-p2mp-00.txt In-Reply-To: <1FB136FD10CE33409C882630E299F5BE1EDBEB@lanmhs30.rd.francetelecom.fr> References: <1FB136FD10CE33409C882630E299F5BE1EDBEB@lanmhs30.rd.francetelecom.fr> User-Agent: Wanderlust/2.10.0 (Venus) SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.3 Emacs/21.2.92 (i686-pc-linux-gnu) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk >I agree with you. It is important to well separate mutlicast service >from P2MP LSP setup / >modification, as P2MP tree can support non-IP Mcast traffic. This is good point. We should separate P2MP LSP setup and multicast traffic mapping. I think Yasukawa's main motivation of changing draft name from old 'rsvp-multicast' to 'rsvp-p2mp' resides in it. Actually we can use any kind of P2MP LSP for multicast traffic mapping. At the same time P2MP LSP is not limited to use for multicast traffic. I believe this topic should be discussed at here. -- Kunihiro Ishiguro From owner-mpls@UU.NET Wed Jan 29 12:45:16 2003 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24413 for ; Wed, 29 Jan 2003 12:45:16 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnztn20103 for ; Wed, 29 Jan 2003 17:48:44 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnztn19616; Wed, 29 Jan 2003 17:48:33 GMT Received: by mail-control.ash.ops.us.uu.net id QQnztn14902 for mpls-outgoing; Wed, 29 Jan 2003 17:48:05 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnztn14887 for ; Wed, 29 Jan 2003 17:47:51 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnztn19956 for ; Wed, 29 Jan 2003 17:47:36 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnztn18248 for ; Wed, 29 Jan 2003 17:47:36 GMT Received: from zcars0m9.nortelnetworks.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: zcars0m9.nortelnetworks.com [47.129.242.157]) id QQnztn18240 for ; Wed, 29 Jan 2003 17:47:35 GMT Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h0THjgX01020; Wed, 29 Jan 2003 12:45:42 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 29 Jan 2003 12:45:42 -0500 Message-ID: From: "David Allan" To: Alia Atlas , erosen@cisco.com Cc: francis.arts@alcatel.be, mpls@UU.NET Subject: RE: Vpns vs explicit null label Date: Wed, 29 Jan 2003 12:45:42 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: owner-mpls@UU.NET Precedence: bulk I get the feeling the genie is out of the bottle, and this sort of half-PHP is really the provence of the LSR that originated the label. Only consequence of such a spec change is the upstream LSR should not squawk or place limitations on such a label if received. One potential issue is figuring out who initiated the label in a PHP scenario. The ingress may stack it unsignalled as a PID, the egress may offer it upstream as a half-PHP. If there is PHP-LSP stacked on top of it, technically the PH LSR is clueless as to where the label originated. So long as you are not doing things like PHP of service labels at the egress PE, and muxing test tools on the service label using explicit null at the ingress PE, you should be OK ;-) cheers Dave > -----Original Message----- > From: Alia Atlas [mailto:aatlas@avici.com] > Sent: Wednesday, January 29, 2003 10:51 AM > To: erosen@cisco.com > Cc: francis.arts@alcatel.be; mpls@UU.NET > Subject: Re: Vpns vs explicit null label > > > I agree that removing the restriction that an explicit null > only occur at > the bottom of the stack would be a good idea. > > It does raise some questions, because there is an IPv4 > explicit null and an > IPv6 explicit null. What we really want is just an explicit > null, which > means "pop off this label and then forward based on > whatever's underneath". > > Alia > > At 10:09 AM 1/29/2003 -0500, Eric Rosen wrote: > > >Francis> Should the statement that only occurs at > >Francis> the bottom of the stack> be relaxed? > > > >This statement causes a lot of problems, and no one can seem > to remember why > >it is there. Further, there are a number of cases in which > it is awkward to > >prevent explicit null from appearing in mid-stack. Not > only that, but the > >specs don't really say what you are supposed to do if > you do encounter > >explicit null above another label, or if you are instructed > (via LDP) to put > >explicit null on a packet which already has a label stack. > > > >So I would favor removing the requirement that explicit > null only appear at > >the bottom of the stack. > > > From owner-mpls@UU.NET Wed Jan 29 13:24:47 2003 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25335 for ; Wed, 29 Jan 2003 13:24:46 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnztp15049 for ; Wed, 29 Jan 2003 18:28:17 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnztp14906; Wed, 29 Jan 2003 18:28:13 GMT Received: by mail-control.ash.ops.us.uu.net id QQnztp06173 for mpls-outgoing; Wed, 29 Jan 2003 18:27:59 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnztp06166 for ; Wed, 29 Jan 2003 18:27:47 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnztp17864 for ; Wed, 29 Jan 2003 18:26:48 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnztp08281 for ; Wed, 29 Jan 2003 18:26:47 GMT Received: from qtech1.quarrytech.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: email.quarrytech.com [4.17.144.4]) id QQnztp08266 for ; Wed, 29 Jan 2003 18:26:46 GMT Received: from MDUFFY1.quarrytech.com (MDUFFY1 [10.1.3.40]) by qtech1.quarrytech.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id DZNHHDSB; Wed, 29 Jan 2003 13:26:45 -0500 Message-Id: <5.2.0.9.0.20030129131306.01e43ea8@email.quarrytech.com> X-Sender: mduffy@email.quarrytech.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Wed, 29 Jan 2003 13:27:12 -0500 To: mpls@UU.NET From: Mark Duffy Subject: Re: Vpns vs explicit null label In-Reply-To: <200301291551.h0TFp7SQ021312@sj-msg-core-1.cisco.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Under what circumstances would an LSR expect to receive a packet with one of the explicit null labels? Usually, LSRs only receive packets with labels that the LSR has itself distributed. Is that true for these labels? Presumably not or there would have been no need to reserve specific values for them. So, I presume the idea is that an upstream LSR may apply these labels even though they weren't distributed by the downstream. But under what circumstances would this be done? Is there any reason to apply these labels today? Does anyone have a product that is doing so? Or were these just reserved because they sounded useful at the time and might be used by some future application of MPLS. -- Mark From owner-mpls@UU.NET Wed Jan 29 13:33:27 2003 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25520 for ; Wed, 29 Jan 2003 13:33:27 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnztq29450 for ; Wed, 29 Jan 2003 18:36:56 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnztq29239; Wed, 29 Jan 2003 18:36:51 GMT Received: by mail-control.ash.ops.us.uu.net id QQnztq06802 for mpls-outgoing; Wed, 29 Jan 2003 18:36:35 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnztq06797 for ; Wed, 29 Jan 2003 18:36:31 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnztq08557 for ; Wed, 29 Jan 2003 18:35:14 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnztq27663 for ; Wed, 29 Jan 2003 18:35:14 GMT Received: from sj-msg-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQnztq27650 for ; Wed, 29 Jan 2003 18:35:13 GMT Received: from cisco.com (erosen-u10.cisco.com [161.44.134.50]) by sj-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h0TIYVSQ019055; Wed, 29 Jan 2003 10:34:31 -0800 (PST) Message-Id: <200301291834.h0TIYVSQ019055@sj-msg-core-1.cisco.com> To: Alia Atlas cc: francis.arts@alcatel.be, mpls@UU.NET Subject: Re: Vpns vs explicit null label In-reply-to: Your message of Wed, 29 Jan 2003 10:51:22 -0500. <5.1.0.14.2.20030129105010.01f6e100@mailhost.avici.com> Reply-To: erosen@cisco.com User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.2 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Date: Wed, 29 Jan 2003 13:34:30 -0500 From: Eric Rosen Sender: owner-mpls@UU.NET Precedence: bulk Alia> What we really want is just an explicit null, which means "pop off Alia> this label and then forward based on whatever's underneath". If what's underneath is not MPLS, then the label you just popped off provides the only clue to what is underneath. From owner-mpls@UU.NET Wed Jan 29 13:53:24 2003 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26213 for ; Wed, 29 Jan 2003 13:53:24 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnztr13279 for ; Wed, 29 Jan 2003 18:56:51 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnztr12968; Wed, 29 Jan 2003 18:56:43 GMT Received: by mail-control.ash.ops.us.uu.net id QQnztr08564 for mpls-outgoing; Wed, 29 Jan 2003 18:56:20 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnztr08559 for ; Wed, 29 Jan 2003 18:56:17 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnztr23018 for ; Wed, 29 Jan 2003 18:53:25 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnztr08951 for ; Wed, 29 Jan 2003 18:53:24 GMT Received: from fridge.docomolabs-usa.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: key1.docomolabs-usa.com [216.98.102.225]) id QQnztr08895 for ; Wed, 29 Jan 2003 18:53:23 GMT From: "Xiaoning He" To: Subject: A question regarding rsvp-te Date: Wed, 29 Jan 2003 10:52:36 -0800 Message-ID: <005401c2c7c7$9762d050$3e6015ac@VAIO> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi all Some parts of my research require some knowledge of RSVP-TE and MPLS. I have a simple question and I appreciate if you can give me some idea or link so that I can read the right draft or RFC. My questions is If there is an existing LSP established by RSVP-TE. Now, some segments of the link have to be changed as shown as follows: a---> b--->c to a--->b--->d my question is that is there anyway we don't have to tear down the old path, I mean the label from a-->b doesn't have to be changed? Is that something allowed in RSVP-TE? Thank you very much, Xiaoning He, Ph.D Research Engineer NTT-DoCoMo USA Labs 181 Metro Drive, Suite 300 San Jose, CA 95110 Email: xiaoning@docomolabs-usa.com Phone: +1 (408) 451-4737 Fax: +1 (408) 573-1090 From owner-mpls@UU.NET Wed Jan 29 14:00:46 2003 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26344 for ; Wed, 29 Jan 2003 14:00:45 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnzts01612 for ; Wed, 29 Jan 2003 19:04:15 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnzts01345; Wed, 29 Jan 2003 19:04:08 GMT Received: by mail-control.ash.ops.us.uu.net id QQnzts26032 for mpls-outgoing; Wed, 29 Jan 2003 19:03:40 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnzts25910 for ; Wed, 29 Jan 2003 19:03:22 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnzts07822 for ; Wed, 29 Jan 2003 19:01:47 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnzts29091 for ; Wed, 29 Jan 2003 19:01:47 GMT Received: from sj-msg-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQnzts29072 for ; Wed, 29 Jan 2003 19:01:46 GMT Received: from cisco.com (erosen-u10.cisco.com [161.44.134.50]) by sj-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h0TJ1ASQ009579; Wed, 29 Jan 2003 11:01:10 -0800 (PST) Message-Id: <200301291901.h0TJ1ASQ009579@sj-msg-core-1.cisco.com> To: "David Allan" cc: Alia Atlas , francis.arts@alcatel.be, mpls@UU.NET Subject: Re: Vpns vs explicit null label In-reply-to: Your message of Wed, 29 Jan 2003 12:45:42 -0500. Reply-To: erosen@cisco.com User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.2 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Date: Wed, 29 Jan 2003 14:01:10 -0500 From: Eric Rosen Sender: owner-mpls@UU.NET Precedence: bulk David> this sort of half-PHP is really the provence of the LSR that David> originated the label. Only consequence of such a spec change is the David> upstream LSR should not squawk or place limitations on such a label David> if received. When the egress node E sends an LDP message binding explicit null to a particular FEC, it is telling the penultimate node P that, under certain circumstances, when P receives an MPLS packet from some third node, P should swap the top label of that packet with explicit null. P will do this when the FEC corresponding to the incoming label of the packet is the same FEC to which E has bound explicit null. Strictly speaking E should only bind explicit null to a particular FEC if it somehow knows that any packets which P sees that correspond to that FEC will be carrying label stacks of no more than one label. In practice, though, it is difficult to make E obey this restriction. I think what you're saying is that if E gets a packet with explicit null at the top of the stack, it has gotten what it asked for, and should handle it in the obvious way. I agree with this, and I'd assumed that this is what would generally be done. But the spec never made this clear. So we've seen cases where E throws the packet away as malformed, and I think we've also seen cases where P throws the packet away rather than sending a "malformed" packet. These lead to lack of interoperability. I think we've also seen cases where P, when processing a packet with more than one label, will treat explicit null as if it had been implicit null; this at least is interoperable. So perhaps what should really be required is: - When the egress LSR pops off explicit null, it should attend to the IPv4/v6 type. Other nodes treat the two kinds of explicit null as equivalent. - When asked to put explicit null on the top of a label stack, one MAY do so, but one SHOULD treat explicit null as if it were implicit null. (Not sure about that "should".) - When creating a label stack with explicit null somewhere in the middle, one MAY put it there, but one SHOULD simply remove it. From owner-mpls@UU.NET Wed Jan 29 14:05:34 2003 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26486 for ; Wed, 29 Jan 2003 14:05:33 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnzts08458 for ; Wed, 29 Jan 2003 19:09:03 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnzts08091; Wed, 29 Jan 2003 19:08:55 GMT Received: by mail-control.ash.ops.us.uu.net id QQnzts27148 for mpls-outgoing; Wed, 29 Jan 2003 19:08:21 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnzts27127 for ; Wed, 29 Jan 2003 19:08:16 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnzts16824 for ; Wed, 29 Jan 2003 19:07:41 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnzts07032 for ; Wed, 29 Jan 2003 19:07:41 GMT Received: from sj-msg-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQnzts07026 for ; Wed, 29 Jan 2003 19:07:40 GMT Received: from cisco.com (erosen-u10.cisco.com [161.44.134.50]) by sj-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h0TJ7bSQ014254; Wed, 29 Jan 2003 11:07:37 -0800 (PST) Message-Id: <200301291907.h0TJ7bSQ014254@sj-msg-core-1.cisco.com> To: Mark Duffy cc: mpls@UU.NET Subject: Re: Vpns vs explicit null label In-reply-to: Your message of Wed, 29 Jan 2003 13:27:12 -0500. <5.2.0.9.0.20030129131306.01e43ea8@email.quarrytech.com> Reply-To: erosen@cisco.com User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.2 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Date: Wed, 29 Jan 2003 14:07:36 -0500 From: Eric Rosen Sender: owner-mpls@UU.NET Precedence: bulk Mark> Usually, LSRs only receive packets with labels that the LSR has itself Mark> distributed. Is that true for these labels? Presumably not or there Mark> would have been no need to reserve specific values for them. Reserved values were used because they are easy to look up; it's much quicker to determine that the label is one of a small set of constants than it is to look up a label in your 20-bit lookup table. When a packet with explicit null is received, the explicit null needs to be detected, and then the packet's IP address needs to be looked up. By using a reserved value, the time to look up the label plus the IP address becomes approximately equal to the time to look up the IP address. Without a reserved value, it would be approximately double that. Of course, once a reserved value is used, it does become possible for the penultimate node to put on explicit null even when it hasn't been asked for. By "be liberal in what you accept", this should be handled properly at the egress. From owner-mpls@UU.NET Wed Jan 29 15:00:36 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27980 for ; Wed, 29 Jan 2003 15:00:36 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnztw09088 for ; Wed, 29 Jan 2003 20:04:08 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnztw08969; Wed, 29 Jan 2003 20:04:04 GMT Received: by mail-control.ash.ops.us.uu.net id QQnztw12393 for mpls-outgoing; Wed, 29 Jan 2003 20:03:49 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnztw12030 for ; Wed, 29 Jan 2003 20:03:37 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnztw19244 for ; Wed, 29 Jan 2003 20:03:22 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnztw08407 for ; Wed, 29 Jan 2003 20:03:22 GMT Received: from prattle.redback.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: prattle.redback.com [155.53.12.9]) id QQnztw08396 for ; Wed, 29 Jan 2003 20:03:21 GMT Received: from malt (malt.redback.com [155.53.12.41]) by prattle.redback.com (Postfix) with ESMTP id 68C532680E8; Wed, 29 Jan 2003 12:03:20 -0800 (PST) Date: Wed, 29 Jan 2003 12:03:20 -0800 (PST) From: Rahul Aggarwal X-Sender: rahul@malt To: Eric Rosen Cc: Mark Duffy , mpls@UU.NET Subject: Re: Vpns vs explicit null label In-Reply-To: <200301291907.h0TJ7bSQ014254@sj-msg-core-1.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Hi Eric, A couple of points on my interpretation of explicit null that has been implemented: 1. A penultimate hop router doesn't put on an explicit null on a packet if the outgoing label stack is not empty. Hence it has the intelligence to insert an explicit null only if the outgoing label stack is empty. This takes care of the VPN case, the question on which started this thread. I think this is the right thing as explicit null is needed for payload determination or for MPLS QoS. If there is already a label in the outgoing label stack that should take care of it.. 2. As you said the destination PE does a "fast" lookup using the fact that an explicit null is a reserved value. 3. Destination PE rejects an explicit null if its not at the bottom of stack. I am yet to be convinced that this is not the right thing to do as an explicit null shouldn't show up other than at the bottom of the stack (Point # 1). I am not sure if being liberal on what you accept applies that well to the forwarding path. That said if there is a reason why this can happen, I think its not hard to remove this restriction, unless there is hardware out there that cannot do this. thanks, rahul On Wed, 29 Jan 2003, Eric Rosen wrote: > > Mark> Usually, LSRs only receive packets with labels that the LSR has itself > Mark> distributed. Is that true for these labels? Presumably not or there > Mark> would have been no need to reserve specific values for them. > > Reserved values were used because they are easy to look up; it's much > quicker to determine that the label is one of a small set of constants than > it is to look up a label in your 20-bit lookup table. When a packet with > explicit null is received, the explicit null needs to be detected, and then > the packet's IP address needs to be looked up. By using a reserved value, > the time to look up the label plus the IP address becomes approximately > equal to the time to look up the IP address. Without a reserved value, it > would be approximately double that. > > Of course, once a reserved value is used, it does become possible for the > penultimate node to put on explicit null even when it hasn't been asked > for. By "be liberal in what you accept", this should be handled properly at > the egress. > > > > From owner-mpls@UU.NET Wed Jan 29 15:25:34 2003 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28785 for ; Wed, 29 Jan 2003 15:25:34 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnztx01618 for ; Wed, 29 Jan 2003 20:29:04 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnztx01334; Wed, 29 Jan 2003 20:28:57 GMT Received: by mail-control.ash.ops.us.uu.net id QQnztx22503 for mpls-outgoing; Wed, 29 Jan 2003 20:28:29 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnztx22490 for ; Wed, 29 Jan 2003 20:28:14 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnztx00518 for ; Wed, 29 Jan 2003 20:23:45 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnztx02294 for ; Wed, 29 Jan 2003 20:23:44 GMT Received: from prattle.redback.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: prattle.redback.com [155.53.12.9]) id QQnztx02279 for ; Wed, 29 Jan 2003 20:23:44 GMT Received: from malt (malt.redback.com [155.53.12.41]) by prattle.redback.com (Postfix) with ESMTP id 0F52A2F23E2; Wed, 29 Jan 2003 12:21:47 -0800 (PST) Date: Wed, 29 Jan 2003 12:21:47 -0800 (PST) From: Rahul Aggarwal X-Sender: rahul@malt To: Xiaoning He Cc: mpls@UU.NET Subject: Re: A question regarding rsvp-te In-Reply-To: <005401c2c7c7$9762d050$3e6015ac@VAIO> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk On Wed, 29 Jan 2003, Xiaoning He wrote: > Hi all > > Some parts of my research require some knowledge of RSVP-TE and MPLS. I > have a simple question and I appreciate if you can give me some idea or > link so that I can read the right draft or RFC. > > My questions is > > If there is an existing LSP established by RSVP-TE. Now, some segments > of the link have to be changed as shown as follows: > > a---> b--->c to a--->b--->d > > my question is that is there anyway we don't have to tear down the old > path, I mean the label from a-->b doesn't have to be changed? Is that > something allowed in RSVP-TE? Yes it is. If explicit routes are being used, B will start forwarding PATH messages to D as the new explicit route willl start pointing in that direction. D will reply with a RESV message with its label. B will stasrt using that as the outgoing label and leave the label it sent out to A the same.. > > Thank you very much, > > Xiaoning He, Ph.D > Research Engineer > > NTT-DoCoMo USA Labs > 181 Metro Drive, Suite 300 > San Jose, CA 95110 > > Email: xiaoning@docomolabs-usa.com > Phone: +1 (408) 451-4737 > Fax: +1 (408) 573-1090 > > > > > From owner-mpls@UU.NET Wed Jan 29 16:21:30 2003 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00305 for ; Wed, 29 Jan 2003 16:21:29 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnzub17784 for ; Wed, 29 Jan 2003 21:25:01 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnzub17702; Wed, 29 Jan 2003 21:24:58 GMT Received: by mail-control.ash.ops.us.uu.net id QQnzub15433 for mpls-outgoing; Wed, 29 Jan 2003 21:24:33 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnzub15425 for ; Wed, 29 Jan 2003 21:24:32 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnzub17128 for ; Wed, 29 Jan 2003 21:20:38 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnzub21784 for ; Wed, 29 Jan 2003 21:20:38 GMT Received: from zcars04f.nortelnetworks.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: zcars04f.nortelnetworks.com [47.129.242.57]) id QQnzub21774 for ; Wed, 29 Jan 2003 21:20:37 GMT Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h0TLK9k12084; Wed, 29 Jan 2003 16:20:09 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 29 Jan 2003 16:20:10 -0500 Message-ID: From: "David Allan" To: erosen@cisco.com Cc: Alia Atlas , francis.arts@alcatel.be, mpls@UU.NET Subject: RE: Vpns vs explicit null label Date: Wed, 29 Jan 2003 16:20:02 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: owner-mpls@UU.NET Precedence: bulk Hi Eric: > David> this sort of half-PHP is really the provence of > the LSR that > David> originated the label. Only consequence of such a > spec change is the > David> upstream LSR should not squawk or place limitations > on such a label > David> if received. > > When the egress node E sends an LDP message binding > explicit null to a particular FEC, it is telling the penultimate node P that, > under certain circumstances, Could you elaborate on "under certain circumstances"? I would presume that if that was the offered label binding, the upstream LSR was expected to use it. > when P receives an MPLS packet from some third node, P should > swap the top label of that packet with explicit null. P > will do this when the FEC corresponding to the incoming label of the packet is > the same FEC to which E has bound explicit null. Yes. > > Strictly speaking E should only bind explicit null to a > particular FEC if it somehow knows that any packets which P sees that correspond > to that FEC will be carrying label stacks of no more than one label. Consistent with 3032 > In practice, though, it is difficult to make E obey this restriction. Agreed, although as I note below, of you don't need the V4/V6 part, any label will do and has no wierd semantics assocaited with it... > > I think what you're saying is that if E gets a packet with > explicit null at > the top of the stack, it has gotten what it asked for, and > should handle it > in the obvious way. yes, if it offered it, nothing further required. If it didn't offer it, (for example offered implicit NULL and got explicit NULL as a top label, then I would presume the ingress originated the explicit NULL as an IP PID (although I do not know why it would do so). OR if E offered another label, and when popping that label found an explicit NULL would similarly assume that it originated with the ingress. > I agree with this, and I'd assumed that this is what > would generally be done. But the spec never made this clear. > So we've seen cases where E throws the packet away as malformed, one where it offered explicit NULL? Different teams implementing different features ;-) > and I think we've also seen cases where P throws the packet away rather than > sending a "malformed" packet. This is what I presume removing the restriction would address. > These lead to lack of interoperability. agreed > I think we've also seen cases where P, when processing a packet with more than one > label, will treat explicit null as if it had been implicit null; this > at least is > interoperable. > > So perhaps what should really be required is: > > - When the egress LSR pops off explicit null, it should > attend to the > IPv4/v6 type. Other nodes treat the two kinds of > explicit null as > equivalent. I think it's a bit more subtle. If it is a top and a bottom label at E as a result of any operation (P doing PHP, P not doing PHP and E popping a previous top label etc.), then E attends to the V4/V6 type. If it is a top and not a bottom label at E, then it is just a label and if not offered by E then it is a fault. IMHO this is a bit bizzare and not what I would design from a clean sheet, but seems to correspond to actual usage. Realistically if I did not want to attend to V4/V6 type, ANY label would do to stunt double for the way Explicit NULL is used, the implementation merely needed to pick any one non-reserved value to use where it offered explicit null today and would then be compliant with 3032 as written. > > - When asked to put explicit null on the top of a label > stack, one MAY do > so, but one SHOULD treat explicit null as if it were > implicit null. (Not > sure about that "should".) Not quite clear on the implications of that other than that the link has a "default" label for LSPs terminating at E. > > - When creating a label stack with explicit null somewhere > in the middle, > one MAY put it there, but one SHOULD simply remove it. I think I just talked myself out of removing the restriction ;-) except if we need to document existing practice. cheers Dave From owner-mpls@UU.NET Wed Jan 29 16:58:33 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01539 for ; Wed, 29 Jan 2003 16:58:33 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnzue25483 for ; Wed, 29 Jan 2003 22:02:06 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnzue25387; Wed, 29 Jan 2003 22:02:02 GMT Received: by mail-control.ash.ops.us.uu.net id QQnzue28266 for mpls-outgoing; Wed, 29 Jan 2003 22:01:35 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnzue26673 for ; Wed, 29 Jan 2003 22:01:21 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnzue25375 for ; Wed, 29 Jan 2003 22:00:38 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnzue12075 for ; Wed, 29 Jan 2003 22:00:38 GMT Received: from mailgate.pit.comms.marconi.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6]) id QQnzue12064 for ; Wed, 29 Jan 2003 22:00:37 GMT Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA03356 for ; Wed, 29 Jan 2003 17:00:35 -0500 (EST) Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA19384 for ; Wed, 29 Jan 2003 17:00:37 -0500 (EST) Message-ID: <3E384F0D.20901@marconi.com> Date: Wed, 29 Jan 2003 17:00:45 -0500 From: David Charlap Organization: Marconi, Vienna VA User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en, he MIME-Version: 1.0 To: IETF MPLS List Subject: Re: A question regarding rsvp-te References: <005401c2c7c7$9762d050$3e6015ac@VAIO> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Xiaoning He wrote: > > Some parts of my research require some knowledge of RSVP-TE and MPLS. I > have a simple question and I appreciate if you can give me some idea or > link so that I can read the right draft or RFC. > > My questions is > > If there is an existing LSP established by RSVP-TE. Now, some segments > of the link have to be changed as shown as follows: > > a--->b--->c to a--->b--->d > > my question is that is there anyway we don't have to tear down the old > path, I mean the label from a-->b doesn't have to be changed? Is that > something allowed in RSVP-TE? If there are no explicit routes involved, then the LSP follows the routing table. When the route change propagates to router B, it will send a PathTear to C and a Path to D. When the Resv comes back from D, router B does not have to propagate it further upstream. If there is an explicit route, then the ERO must be changed by the ingress node (A). It can choose to do this in one of three ways. The preferable way is make-before-break. In this, A signals a new LSP along the new ERO. When the new LSP comes up, A redirects data-plane traffic from the old LSP to the new LSP. Then it tears down the original LSP. If the two LSPs belong to the same session and SE-style is used for the reservation, then this can be done without wasting bandwidth on the links that are shared between the two LSPs. A less preferable way is break-before-make. A tears the original LSP, and then establishes a new one with the new ERO. This obviously has the problem of disrupting data-plane traffic. A third way (which I also don't like) is for A to simple change the ERO in a Path refresh. When B gets the updated Path message, it will send a PathTear to C and a Path to D, and the LSP will reroute. The problem with changing the ERO is not obvious from your topology, since you also changed the destination router (which changes the session address, BTW). Most of the time, however, a reroute like this is expected to preserve traffic flow to the same destination. For example, you might have a topology like this: /---C-------D---\ A-----B< >F-----G \-------E-------/ Now, suppose we have an ERO sending traffic along the path A-B-E-F-G. Now we want to reroute it to A-B-C-D-F-G. If we use the make-before-break method, there's no problem. We briefly have two LSPs - one using eath ERO. If SE-style is used, Bandwidth is shared between them on the links that are in common (A-B and F-G). The traffic reroutes when A makes the switchover. If we use break-before-make, obviously, there's an interruption. But observe what happens if we just change the ERO in-line: B receives a Path message where the ERO specifies a new next-hop. B sends a Path message to C and a PathTear to E. C propagates the Path message to D, and then to F. Meanwhile, E propagates a PathTear to F. If the PathTear reaches F before the Path message, F will tear the connection and propagate the PathTear to G. Then the Path arrives at F, which sends it to G. G sends back a Resv, which propagates back to F, then to D, C and B. The data-plane is broken for the time interval between when the PathTear reaches F and when the Resv makes its way back to B. If the Path reaches F before the PathTear message, it may or may not be better. F will receive the Path message and see that the previous-hop router for the LSP has changed. It will then generate a Resv message to send back to D, propagating to C and B. When the Resv reaches B, the data-plane traffic will start following the new Path. But then the PathTear arrives at F. F might ignore the PathTear, since it is arriving on a different interface from the (new) PHOP, but I think it's also legal for it to process that PathTear. This causes the Path from F to G to be torn. When D sends its next refresh, it will then be re-established, but this might not happen for a long time - especially if features like RSVP-Hello and refresh reduction are operating between D and F. In other words, if A simply changes the ERO, there is a very real possibility that the data-plane will be broken for at least a short time, and possibly for a long time. IMO, make-before-break is the only good way to change the route of an LSP with an ERO. -- David From owner-mpls@UU.NET Wed Jan 29 19:44:04 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04323 for ; Wed, 29 Jan 2003 19:44:03 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnzup19085 for ; Thu, 30 Jan 2003 00:47:30 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnzup18998; Thu, 30 Jan 2003 00:47:27 GMT Received: by mail-control.ash.ops.us.uu.net id QQnzup25149 for mpls-outgoing; Thu, 30 Jan 2003 00:47:00 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnzup25132 for ; Thu, 30 Jan 2003 00:46:46 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnzup08545 for ; Thu, 30 Jan 2003 00:45:06 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnzup15742 for ; Thu, 30 Jan 2003 00:45:06 GMT Received: from rtp-msg-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-msg-core-1.cisco.com [161.44.11.97]) id QQnzup15715 for ; Thu, 30 Jan 2003 00:45:04 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h0U0jqjL010170 for ; Wed, 29 Jan 2003 19:45:53 -0500 (EST) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id TAA28062 for ; Wed, 29 Jan 2003 19:45:02 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h0U0j2111777 for mpls@uu.net; Wed, 29 Jan 2003 19:45:02 -0500 (EST) Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnzuo24430 for ; Thu, 30 Jan 2003 00:43:21 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnzuo03743 for ; Thu, 30 Jan 2003 00:41:35 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnzuo23242 for ; Thu, 30 Jan 2003 00:41:35 GMT Received: from host19.ipowerweb.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: host19.ipowerweb.com [12.129.206.119]) id QQnzuo23233 for ; Thu, 30 Jan 2003 00:41:34 GMT Received: from h00a0ccd1a9ec.ne.client2.attbi.com ([24.128.219.249] helo=GraIyMage.com) by host19.ipowerweb.com with asmtp (Exim 3.36 #1) id 18e2k7-0002fe-00; Wed, 29 Jan 2003 16:39:47 -0800 Message-ID: <3E387455.5AEB91C3@GraIyMage.com> Date: Wed, 29 Jan 2003 19:39:49 -0500 From: Eric Gray Reply-To: ewgray@GraIyMage.com X-Mailer: Mozilla 4.7 [en]C-CCK-MCD NSCPCD47 (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: David Allan CC: erosen@cisco.com, Alia Atlas , francis.arts@alcatel.be, mpls@UU.NET Subject: Re: Vpns vs explicit null label References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - host19.ipowerweb.com X-AntiAbuse: Original Domain - uu.net X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [0 0] X-AntiAbuse: Sender Address Domain - graiymage.com Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit David, You and Eric Rosen are dancing around the issue. :-) I believe you missed the point that the fact that the explicit NULL is "well known" means that it is unnecessary (atleast in the opinion of some implementers) for the egress to "offer" the explicit NULL label to the penultimate hop. I argued some time ago that the spec not being tighter about this usage was problematic and was labeled a purist by someone we all know. :-) The issue is that - because the explicit NULL label is well known - it is not acceptable behavior for a "compliant" implementation to not support the explicit NULL label, EVEN IF IT IS INCAPABLE OF OFFERING IT. Notice that it is acceptable behavior for a compiant implementation to _never_ offer an explicit NULL label. The point has been made several times since that an implementation that assumes it is acting as the penultimate hop and uses explicit NULL even though some other label was offered by its downstream (and not necessarily egress) peer is at least highly anti-social. For one thing, it makes it deuced hard to keep per LSP statistics. Also, the fact that any LSR could prefix the explicit NULL label to any peer that it knows to be an LSR - even if it would otherwise forward packets to that peer unlabeled - does not mean that it should do so or even would do so in any implementation I know of. However it is conceivable that an LSR might use an explicit NULL label in forwarding packets to a neighbor LSR that never offered this label. Barring this sort of anti-social behavior, it is usually the case that an LSR receiving an explicit NULL label does so because it has earlier bound explicit NULL to a FEC in relation to the peer from which it receives the so-labeled packet. What this says to me is that an LSR will only receive a mix of labeled and unlabeled packets on an LSP if it has issued the same label (explicit NULL) for a set of traffic it will forward as IP traffic and another set it will forward as MPLS labeled traffic. This _should_ put the egress in control of the situation and the problems discussed here _should_ not arise. This is where Eric may be being a little loose with the term egress. Any LSR that pops an explicit NULL label is acting as an egress. It has no choice, because it certainly cannot have bound an outgoing label to a explicit NULL incoming label. :-) So what seems to meant is that - if the explicit NULL label's stack entry has the BOS bit set - then the IP version is relevant. Otherwise it is not. -- Eric Gray David Allan wrote: > Hi Eric: > > > > David> this sort of half-PHP is really the provence of > > the LSR that > > David> originated the label. Only consequence of such a > > spec change is the > > David> upstream LSR should not squawk or place limitations > > on such a label > > David> if received. > > > > When the egress node E sends an LDP message binding > > explicit null to a particular FEC, it is telling the penultimate node > P that, > > under certain circumstances, > > Could you elaborate on "under certain circumstances"? I would presume that > if that was the offered label binding, the upstream LSR was expected to use > it. > > > when P receives an MPLS packet from some third node, P should > > swap the top label of that packet with explicit null. P > > will do this when the FEC corresponding to the incoming label of the > packet is > > the same FEC to which E has bound explicit null. > > Yes. > > > > > Strictly speaking E should only bind explicit null to a > > particular FEC if it somehow knows that any packets which P sees that > correspond > > to that FEC will be carrying label stacks of no more than one label. > > Consistent with 3032 > > > In practice, though, it is difficult to make E obey this restriction. > > Agreed, although as I note below, of you don't need the V4/V6 part, any > label will do and has no wierd semantics assocaited with it... > > > > I think what you're saying is that if E gets a packet with > > explicit null at > > the top of the stack, it has gotten what it asked for, and > > should handle it > > in the obvious way. > > yes, if it offered it, nothing further required. If it didn't offer it, (for > example offered implicit NULL and got explicit NULL as a top label, then I > would presume the ingress originated the explicit NULL as an IP PID > (although I do not know why it would do so). OR if E offered another label, > and when popping that label found an explicit NULL would similarly assume > that it originated with the ingress. > > > I agree with this, and I'd assumed that this is what > > would generally be done. But the spec never made this clear. > > So we've seen cases where E throws the packet away as malformed, > > one where it offered explicit NULL? Different teams implementing different > features ;-) > > > and I think we've also seen cases where P throws the packet away rather > than > > sending a "malformed" packet. > > This is what I presume removing the restriction would address. > > > These lead to lack of interoperability. > > agreed > > > I think we've also seen cases where P, when processing a packet with more > than one > > label, will treat explicit null as if it had been implicit null; > this > > at least is > > interoperable. > > > > So perhaps what should really be required is: > > > > - When the egress LSR pops off explicit null, it should > > attend to the > > IPv4/v6 type. Other nodes treat the two kinds of > > explicit null as > > equivalent. > > I think it's a bit more subtle. If it is a top and a bottom label at E as a > result of any operation (P doing PHP, P not doing PHP and E popping a > previous top label etc.), then E attends to the V4/V6 type. > > If it is a top and not a bottom label at E, then it is just a label and if > not offered by E then it is a fault. > > IMHO this is a bit bizzare and not what I would design from a clean sheet, > but seems to correspond to actual usage. Realistically if I did not want to > attend to V4/V6 type, ANY label would do to stunt double for the way > Explicit NULL is used, the implementation merely needed to pick any one > non-reserved value to use where it offered explicit null today and would > then be compliant with 3032 as written. > > > > > - When asked to put explicit null on the top of a label > > stack, one MAY do > > so, but one SHOULD treat explicit null as if it were > > implicit null. (Not > > sure about that "should".) > > Not quite clear on the implications of that other than that the link has a > "default" label for LSPs terminating at E. > > > > > - When creating a label stack with explicit null somewhere > > in the middle, > > one MAY put it there, but one SHOULD simply remove it. > > I think I just talked myself out of removing the restriction ;-) except if > we need to document existing practice. > > cheers > Dave > > From owner-mpls@UU.NET Thu Jan 30 10:24:29 2003 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00952 for ; Thu, 30 Jan 2003 10:24:28 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnzwv15905 for ; Thu, 30 Jan 2003 15:27:58 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnzwv15673; Thu, 30 Jan 2003 15:27:51 GMT Received: by mail-control.ash.ops.us.uu.net id QQnzwv05207 for mpls-outgoing; Thu, 30 Jan 2003 15:27:23 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnzwv05202 for ; Thu, 30 Jan 2003 15:27:04 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnzwv19490 for ; Thu, 30 Jan 2003 15:26:39 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnzwv03573 for ; Thu, 30 Jan 2003 15:26:39 GMT Received: from zcars0m9.nortelnetworks.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: zcars0m9.nortelnetworks.com [47.129.242.157]) id QQnzwv03561 for ; Thu, 30 Jan 2003 15:26:38 GMT Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h0UFPe700069; Thu, 30 Jan 2003 10:25:40 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 30 Jan 2003 10:25:40 -0500 Message-ID: From: "David Allan" To: ewgray@graiymage.com Cc: erosen@cisco.com, Alia Atlas , francis.arts@alcatel.be, mpls@UU.NET Subject: RE: Vpns vs explicit null label Date: Thu, 30 Jan 2003 10:25:38 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: owner-mpls@UU.NET Precedence: bulk Hi Eric: > David, > > You and Eric Rosen are dancing around the issue. :-) > > I believe you missed the point that the fact that the > explicit NULL > is "well known" means that it is unnecessary (atleast in the > opinion of > some implementers) for the egress to "offer" the explicit NULL label > to the penultimate hop. > > I argued some time ago that the spec not being tighter about this > usage was problematic and was labeled a purist by someone we all > know. :-) > > The issue is that - because the explicit NULL label is > well known - > it is not acceptable behavior for a "compliant" implementation to not > support the explicit NULL label, EVEN IF IT IS INCAPABLE OF > OFFERING IT. Notice that it is acceptable behavior for a compiant > implementation to _never_ offer an explicit NULL label. Agreed. > > The point has been made several times since that an implementation > that assumes it is acting as the penultimate hop and uses > explicit NULL > even though some other label was offered by its downstream (and not > necessarily egress) peer is at least highly anti-social. For > one thing, it > makes it deuced hard to keep per LSP statistics. Also, the fact that > any LSR could prefix the explicit NULL label to any peer that it knows > to be an LSR - even if it would otherwise forward packets to that peer > unlabeled - does not mean that it should do so or even would do so in > any implementation I know of. I take it this is behavior of at least one implementation? > > However it is conceivable that an LSR might use an explicit NULL > label in forwarding packets to a neighbor LSR that never offered this > label. If, for example, I was trying to use LSP ping to test a PW via injecting LSP-PING into the PW (instead of using a FEC stack at the PSN level)..... > > Barring this sort of anti-social behavior, it is usually > the case that > an LSR receiving an explicit NULL label does so because it has > earlier bound explicit NULL to a FEC in relation to the peer from > which it receives the so-labeled packet. What this says to me is > that an LSR will only receive a mix of labeled and unlabeled > packets on an LSP if it has issued the same label (explicit NULL) > for a set of traffic it will forward as IP traffic and > another set it will > forward as MPLS labeled traffic. This _should_ put the egress in > control of the situation and the problems discussed here _should_ > not arise. I would assume if it was originated by an ingress simply as a PID,then the same would be true. The egress is in control w.r.t. all forwarding layers, and the label only has significance for protocol multiplexing. > > This is where Eric may be being a little loose with the > term egress. > Any LSR that pops an explicit NULL label is acting as an egress. It > has no choice, because it certainly cannot have bound an outgoing > label to a explicit NULL incoming label. :-) Agreed > > So what seems to meant is that - if the explicit NULL > label's stack > entry has the BOS bit set - then the IP version is relevant. > Otherwise > it is not. Reasonable summary of what I concluded. Don't necessarily like it but it seems to document existing practice. cheers Dave From owner-mpls@UU.NET Thu Jan 30 11:22:07 2003 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02914 for ; Thu, 30 Jan 2003 11:22:07 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnzwz25345 for ; Thu, 30 Jan 2003 16:25:38 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnzwz25152; Thu, 30 Jan 2003 16:25:32 GMT Received: by mail-control.ash.ops.us.uu.net id QQnzwz27933 for mpls-outgoing; Thu, 30 Jan 2003 16:25:18 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnzwz27928 for ; Thu, 30 Jan 2003 16:25:09 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnzwz03727 for ; Thu, 30 Jan 2003 16:23:05 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnzwz28919 for ; Thu, 30 Jan 2003 16:23:04 GMT Received: from sj-msg-core-2.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.70.145.30]) id QQnzwz28894 for ; Thu, 30 Jan 2003 16:23:03 GMT Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by sj-msg-core-2.cisco.com (8.12.2/8.12.6) with ESMTP id h0UGMusv020202 for ; Thu, 30 Jan 2003 08:22:56 -0800 (PST) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id LAA12270 for ; Thu, 30 Jan 2003 11:23:02 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h0UGN2222451 for mpls@uu.net; Thu, 30 Jan 2003 11:23:02 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnzwz27706 for ; Thu, 30 Jan 2003 16:21:38 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnzwz27688 for ; Thu, 30 Jan 2003 16:18:10 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnzwz16537 for ; Thu, 30 Jan 2003 16:18:09 GMT Received: from rooster.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: hen.cisco.com [64.102.19.198]) id QQnzwz16528 for ; Thu, 30 Jan 2003 16:18:09 GMT Received: from CPIGNATA-W2K.cisco.com (dhcp-64-102-51-157.cisco.com [64.102.51.157]) by rooster.cisco.com (8.11.6+Sun/8.8.8) with ESMTP id h0UGI8022729; Thu, 30 Jan 2003 11:18:08 -0500 (EST) Message-Id: <4.3.2.7.2.20030130110349.0570f148@rooster> X-Sender: cpignata@rooster X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 30 Jan 2003 11:18:07 -0500 To: mpls@UU.NET From: "Carlos M. Pignataro" Subject: Question on draft-ietf-mpls-ldp-mib-09.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-mpls@UU.NET Precedence: bulk Hi, In draft-ietf-mpls-ldp-mib-09, the mplsLdpAtmSesTable specifies the ATM specific LDP session parameters negotiated. It currently contains the Label Ranges negotiated in the LC-ATM (LR intersection). However, there is another ATM specific parameter negotiated which is the Directionality (D, VC Directionality in RFC-3036). The directionality is configured with mplsLdpEntityAtmVcDirectionality in MplsLdpEntityAtmParmsEntry, but can have a different negotiated value than the one configured. Would it make sense to include the directionality negotiated value in the mplsLdpAtmSesTable as a mplsLdpAtmSesVcDirectionality? Regards, --Carlos. ================================================================= | Carlos Pignataro - CCIE 4619 cisco Systems, Inc. | Escalation RTP | cpignata@cisco.com || || | +1 919 392 7428 - office .||. .||. | +1 919 345 3028 - mobile .||||. .||||. | +1 919 392 6470 - fax .:||||||||:.:||||||||:. | 7025 Kit Creek Road, PO Box 14987 Are you Ready ? | Research Triangle Park, NC 27709 =================================================================